LTE RRC Counter Check Response

Message Fact Sheet

Protocol	lte-rrc	Network	lte
Spec	3GPP TS 36.331	Spec Section	5.3.12, 6.2.2
Direction	UE -> eNodeB	Message Type	Integrity and Synchronization Response

Full message name	LTE RRC Counter Check Response
Protocol	LTE-RRC
Technology	LTE
Direction	UE -> eNodeB
Interface	Uu
Signaling bearer / channel	SRB1 / UL-DCCH
Typical trigger	The UE receives Counter Check and returns the response as part of the DRB COUNT verification procedure.
Main purpose	Completes the LTE counter-check procedure so the network can confirm whether the UE-side DRB COUNT state remains aligned with the network view.
Main specification	3GPP TS 36.331, 5.3.12, 6.2.2
Release added	Release 8
Procedures where used	Counter check procedure, Connected-mode continuity verification, Handover continuation

What is LTE RRC Counter Check Response in simple terms?

Uplink LTE RRC message used by the UE to reply to Counter Check and confirm the outcome of the PDCP COUNT verification step.

Completes the LTE counter-check procedure so the network can confirm whether the UE-side DRB COUNT state remains aligned with the network view.

Why this message matters

Counter Check Response is the LTE UE reply that completes the PDCP COUNT verification step started by Counter Check.

Where this message appears in the call flow

Counter check procedure

Call flow position: Uplink response that completes the LTE PDCP COUNT verification exchange.

Typical state: UE is in protected connected mode and returns the result of the COUNT check.

Preconditions:

Counter Check has already been received.
The UE still has the relevant DRB context available for verification.

Next likely message: Later connected-mode continuation

Handover continuation

Call flow position: Continuity response used after the network asks the UE to confirm DRB COUNT alignment during connected mobility handling.

Typical state: The mobility path continues and the UE returns the counter-check outcome before normal continuation is assumed.

Preconditions:

Counter Check was sent in a continuity-sensitive mobility context.
The UE can return the verification outcome on SRB1.

Next likely message: Normal continuation or wider continuity analysis

Call flow position

Previous message(s): CounterCheck, Protected connected-mode continuity signaling

Next message(s): Later connected-mode continuation, Mobility or recovery interpretation

Message direction and transport

Sender and receiver: UE -> eNodeB

Interface: Uu

Domain: Access-side radio control integrity handling

Signaling bearer: SRB1

Logical channel: UL-DCCH

Transport / encapsulation: RRC over DCCH on SRB1 in protected connected mode as the UE response to Counter Check

Security context: This message is part of protected connected-mode LTE RRC signaling and appears only after AS security activation and after a preceding Counter Check request.

Message Structure Overview

CounterCheckResponse is structurally small and mainly useful through its placement after Counter Check.
The key practical read is whether the request-response exchange completed and whether connected continuity continued normally afterward.
This message is best read together with the earlier Counter Check request and the wider continuity path.

ASN.1 for LTE RRC Counter Check Response

CounterCheckResponse ::= SEQUENCE {
  rrc-TransactionIdentifier RRC-TransactionIdentifier,
  criticalExtensions CHOICE {
    c1 CHOICE {
      counterCheckResponse-r8 CounterCheckResponse-r8-IEs,
      spare3 NULL,
      spare2 NULL,
      spare1 NULL
    },
    criticalExtensionsFuture SEQUENCE {}
  }
}

CounterCheckResponse-r8-IEs ::= SEQUENCE {
  lateNonCriticalExtension OCTET STRING OPTIONAL,
  nonCriticalExtension CounterCheckResponse-v8a0-IEs OPTIONAL
}

How to read this ASN.1

The message itself is simple. The useful analysis comes from matching it with Counter Check and verifying what happened before and after the request-response pair.

LTE RRC Counter Check Response - Example Dump

UL-DCCH-Message
  message c1 : counterCheckResponse : {
    rrc-TransactionIdentifier 6,
    criticalExtensions c1 : counterCheckResponse-r8 : {
    }
  }

How to read this dump

Start by matching the transaction identifier to the earlier Counter Check.
This message has little payload depth, so its main value is procedural confirmation.
The next useful read is whether connected continuity continues normally after the response.

Important Information Elements

IE	Required	Description
`rrc-TransactionIdentifier`	Yes	Transaction identifier matching the preceding Counter Check message.
`criticalExtensions`	Yes	Versioned wrapper carrying the CounterCheckResponse payload.
`nonCriticalExtension`	Optional	Release-extension branch used by later releases.

Detailed field explanation

`rrc-TransactionIdentifier`

Transaction identifier matching the preceding Counter Check message.

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.

`criticalExtensions`

Versioned wrapper carrying the CounterCheckResponse payload.

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.

`nonCriticalExtension`

Release-extension branch used by later releases.

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 follows Counter Check.
Verify the transaction identifier matches the earlier request.
Check whether the request-response sequence completed cleanly.
Read the response inside the wider mobility, continuity, or recovery path.
If continuity still fails afterward, keep reading forward instead of treating the response itself as the root cause.

Common Issues and Troubleshooting

CounterCheckResponse is missing after Counter Check.

Likely cause: The request-response branch may have been interrupted, the trace may be incomplete, or later protected signaling may have failed.

What to inspect: Check the transaction identifier, later UL-DCCH activity, and the surrounding continuity path.

Next step: Keep reading forward and confirm whether the counter-check branch broke before the response.

CounterCheckResponse appears but continuity still looks unstable.

Likely cause: The request-response pair completed, but the wider mobility or bearer continuity problem may still exist elsewhere.

What to inspect: Read the earlier Counter Check, the surrounding reconfiguration or mobility path, and the later DRB continuity behavior.

Next step: Use the response as a checkpoint, not as final proof that the whole bearer path is healthy.

The response appears in a mobility path and the meaning is unclear.

Likely cause: CounterCheckResponse is mainly procedural confirmation and has to be read in the wider handover or continuity branch.

What to inspect: Place the response between the earlier Counter Check and the later continuation or failure handling.

Next step: Read backward into the request and forward into the later continuity result.

LTE / 5G / Variant Comparison

Compared with Counter Check

Counter Check starts the verification step and carries the DRB COUNT MSB list. Counter Check Response is the UE reply that completes the exchange.

Compared with RRCConnectionReconfiguration

RRCConnectionReconfiguration changes configuration. Counter Check Response only confirms the outcome of the COUNT verification branch.

FAQ

What is Counter Check Response in LTE?

It is the uplink LTE RRC message the UE sends in reply to Counter Check to complete the PDCP COUNT verification step.

What comes before Counter Check Response?

The normal previous message is Counter Check from the eNodeB.

What should I inspect first in Counter Check Response?

Start with the transaction identifier and confirm that it matches the earlier Counter Check request.

Why is Counter Check Response useful in troubleshooting?

It shows whether the request-response continuity check actually completed before later signaling continued.

Related message pages

Related Procedures

Related Tools

Use This Reference in Practice

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.