Telecom engineering reference for protocols, messages, call flows, troubleshooting, releases, and tools.
Menu
LTE RRCLTEeNodeB -> UE3GPP TS 36.331
LTE RRC Counter Check
Downlink LTE RRC message used by the eNodeB to ask the UE to verify PDCP COUNT synchronization for one or more DRBs.
Message Fact Sheet
Protocol
lte-rrc
Network
lte
Spec
3GPP TS 36.331
Spec Section
5.3.12, 6.2.2
Direction
eNodeB -> UE
Message Type
Integrity and Synchronization Control
Full message name
LTE RRC Counter Check
Protocol
LTE-RRC
Technology
LTE
Direction
eNodeB -> UE
Interface
Uu
Signaling bearer / channel
SRB1 / DL-DCCH
Typical trigger
The network wants the UE to verify DRB COUNT state, usually around connected-mode continuity, handover-related context movement, or integrity-sensitive bearer handling.
Main purpose
Starts the LTE counter-check procedure so the network can confirm that the UE and eNodeB remain aligned on PDCP COUNT state for the configured DRBs.
Downlink LTE RRC message used by the eNodeB to ask the UE to verify PDCP COUNT synchronization for one or more DRBs.
Starts the LTE counter-check procedure so the network can confirm that the UE and eNodeB remain aligned on PDCP COUNT state for the configured DRBs.
Why this message matters
Counter Check is the LTE RRC message the network uses to ask the UE to verify PDCP COUNT state for selected DRBs.
Where this message appears in the call flow
Counter check procedure
In the basic counter-check procedure, Counter Check starts the DRB COUNT verification step and CounterCheckResponse returns the UE-side result.
Call flow position: Downlink request that starts the LTE PDCP COUNT verification exchange.
Typical state: UE is in protected connected mode and has active DRB context to verify.
Preconditions:
AS security is already active.
The configured DRBs have valid PDCP context.
Next likely message: CounterCheckResponse
Handover continuation
In handover continuation, Counter Check can appear as a continuity checkpoint when the network wants confirmation that DRB COUNT state remains aligned.
Call flow position: Integrity-related checkpoint used when bearer context continuity needs verification across mobility handling.
Typical state: The connected context continues, but the network wants confirmation that DRB COUNT state is aligned.
Preconditions:
Connected-mode mobility or context movement has already taken place or is being validated.
The UE still has the relevant DRB context.
Next likely message: CounterCheckResponse followed by normal continuation
Call flow position
Previous message(s): Protected connected-mode LTE RRC signaling, Reconfiguration or mobility-related context before the check
Next message(s):CounterCheckResponse, Later connected-mode continuation or recovery handling
Message direction and transport
Sender and receiver: eNodeB -> UE
Interface: Uu
Domain: Access-side radio control integrity handling
Signaling bearer: SRB1
Logical channel: DL-DCCH
Transport / encapsulation: RRC over DCCH on SRB1 in protected connected mode
Security context: This message is part of protected connected-mode LTE RRC signaling and is used only after AS security is active.
Message Structure Overview
CounterCheck is a compact control message whose main payload is the DRB COUNT MSB information list.
The useful read is which DRBs are included and whether the later CounterCheckResponse confirms alignment.
This message is best read together with the surrounding mobility or continuity path, not in isolation.
Start with the DRB identities included in the list.
Check the COUNT MSB values per DRB and compare them with the later response.
The main value is whether the check confirms continuity or exposes a mismatch.
Important Information Elements
IE
Required
Description
rrc-TransactionIdentifier
Yes
Transaction identifier used to match CounterCheck with CounterCheckResponse.
drb-CountMSB-InfoList
Yes
List of DRB identifiers and associated COUNT MSB values used for the verification step.
drb-Identity
Yes
Identifies the DRB whose COUNT state is being checked.
countMSB-Uplink
Yes
Reference uplink COUNT MSB used by the network for the UE-side check.
countMSB-Downlink
Yes
Reference downlink COUNT MSB used by the network for the UE-side check.
lateNonCriticalExtension / nonCriticalExtension
Optional
Release-extension branch for later additions.
Detailed field explanation
rrc-TransactionIdentifier
Transaction identifier used to match CounterCheck with CounterCheckResponse.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
drb-CountMSB-InfoList
List of DRB identifiers and associated COUNT MSB values used for the verification step.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
drb-Identity
Identifies the DRB whose COUNT state is being checked.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
countMSB-Uplink
Reference uplink COUNT MSB used by the network for the UE-side check.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
countMSB-Downlink
Reference downlink COUNT MSB used by the network for the UE-side check.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
lateNonCriticalExtension / nonCriticalExtension
Release-extension branch for later additions.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
What to check in logs and traces
Confirm the message appears in protected connected mode.
Check which DRBs are included in drb-CountMSB-InfoList.
Record the uplink and downlink COUNT MSB values per DRB.
Correlate the transaction identifier with CounterCheckResponse.
Place the check inside the wider mobility, continuity, or bearer-validation sequence.
Common Issues and Troubleshooting
CounterCheck appears but no CounterCheckResponse follows.
Likely cause: The continuity check may have been interrupted, the trace may be incomplete, or later signaling moved into failure handling.
What to inspect: Check the transaction identifier, later UL-DCCH activity, and the surrounding protected signaling path.
Next step: Keep reading forward to see whether the continuity branch broke after the request.
The counter-check procedure appears around handover and continuity still looks unstable.
Likely cause: The network may be validating DRB COUNT alignment because bearer continuity is already under question.
What to inspect: Read CounterCheck together with earlier reconfiguration, mobility context, and the later CounterCheckResponse.
Next step: Use the counter-check branch as part of the wider continuity analysis, not as an isolated event.
The included DRB list is smaller or different than expected.
Likely cause: Only selected DRBs may be part of the verification step.
What to inspect: Compare the DRB list here with the active bearer context from the surrounding reconfiguration path.
Next step: Check whether the missing DRBs were inactive, released, or simply not part of the requested check.
LTE / 5G / Variant Comparison
Compared with CounterCheckResponse
Counter Check starts the verification step. CounterCheckResponse is the UE reply that confirms the outcome of that check.
Compared with RRCConnectionReconfiguration
RRCConnectionReconfiguration changes radio or bearer configuration. Counter Check verifies continuity of PDCP COUNT state for selected DRBs.
FAQ
What is Counter Check in LTE?
It is the downlink LTE RRC message the eNodeB sends to ask the UE to verify PDCP COUNT state for selected DRBs.
What comes after Counter Check?
The normal follow-up is CounterCheckResponse from the UE.
What should I inspect first in Counter Check?
Start with drb-CountMSB-InfoList, the included DRB identities, and the COUNT MSB values per DRB.
Why is Counter Check useful in troubleshooting?
It helps place PDCP COUNT continuity issues inside a wider mobility or connected-mode continuity path.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.
