Home / Call Flows / LTE / LTE MBMS Counting Procedure

LTE MBMS Counting Procedure Call Flow

call-flow LTE | MBMS | Counting | RRC

LTE MBMS Counting Procedure is the LTE control path used when the network wants MBMS-related feedback from interested UEs before later service decisions are made.

It is not the same as actual MBMS content delivery. It is the counting branch that estimates UE interest through connected-mode MBMS control signaling.

Introduction

The LTE MBMS Counting Procedure starts from existing MBMS context and then moves into counting request and response exchange between the eNB and interested UEs.

Use this page when the main question is whether MBMS demand-estimation signaling happened correctly before later MBMS service handling.

What Is LTE MBMS Counting Procedure in Simple Terms?

What starts the procedure: The network wants MBMS counting feedback for one or more MBMS services.
What the UE and network want to achieve: Estimate UE interest before later MBMS-related service decisions.
What success looks like: The network sends a counting request and interested UEs return counting responses.
What failure means: The counting branch is incomplete, responses are missing, or the counting context is misread.

Why this procedure matters

MBMS counting is the branch that turns MBMS interest into visible control-plane evidence. If this step is missing or misread, later MBMS service decisions can look disconnected from actual UE demand.

Quick Fact Sheet

Procedure name	LTE MBMS Counting Procedure
Domain	LTE MBMS control
Main trigger	MBMS demand-estimation request from the network
Start state	MBMS context is already relevant in the LTE cell
End state	The network has MBMS counting feedback from interested UEs
Main nodes	UE, eNB
Main protocols	RRC MBMS control
Main success outcome	MBMS counting feedback is collected and can be used for later decisions
Main failure outcome	The counting branch is incomplete or the response set is unclear
Most important messages	MBMS Counting Request r10, MBMS Counting Response r10
Main specs	TS 36.331

LTE MBMS Counting Procedure Call Flow — Click the diagram to open the full-size in a new tab.

Preconditions

The LTE cell already has MBMS-relevant context.
The network has a reason to estimate MBMS interest.
The UE is in the correct state to receive and answer the MBMS counting request.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Returns MBMS counting feedback when its MBMS interest matches the request.
eNB	Starts the counting branch and collects the UE responses.
MBMS context	Provides the service-interest background needed before counting makes sense.

Interfaces used

Interface	Path	Role
DL-DCCH	eNB -> UE	Carries the MBMS counting request in connected mode.
UL-DCCH	UE -> eNB	Carries the MBMS counting response back to the network.
LTE Uu	UE <-> eNB	Carries the overall MBMS counting branch.

End-to-End Call Flow

UE                         eNB
|<--MBMS Counting Request----|
|--MBMS Counting Response---->|
|--later MBMS continuation--->|

Major Phases

Phase	What happens
1. MBMS counting start	The network decides to estimate MBMS interest.
2. Downlink request	The eNB sends the MBMS counting request.
3. Uplink response	Interested UEs return MBMS counting responses.
4. Counting result use	The network uses the collected feedback in later MBMS handling.

Step-by-Step Breakdown

Start from the MBMS context

Sender -> receiver: eNB and UE

Message(s): SIB13 and existing MBMS context

Purpose: Anchor the counting branch in the MBMS service context already visible in the cell.

State or context change: The MBMS background exists before counting begins.

Note: Counting should not be analyzed as an isolated branch with no MBMS context behind it.

Send MBMS Counting Request

Sender -> receiver: eNB -> UE

Message(s): MBMS Counting Request r10

Purpose: Ask interested UEs for MBMS counting feedback.

State or context change: The counting branch is now active and waiting for UE feedback.

Note: This message starts the demand-estimation step, not the actual MBMS delivery path.

Return MBMS Counting Response

Sender -> receiver: UE -> eNB

Message(s): MBMS Counting Response r10

Purpose: Return MBMS interest feedback for the requested services.

State or context change: The network now has UE-side counting evidence.

Note: The response is valuable only when read against the request that triggered it.

Correlate the result with later MBMS handling

Sender -> receiver: eNB

Message(s): Counting aggregation and later MBMS continuation

Purpose: Use the counting result in the next MBMS decision path.

State or context change: The counting branch has completed and later MBMS handling can be understood in context.

Note: Do not stop at the response. Check what the network did with the result.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
System Information Block Type 13	RRC	eNB -> UE	Provides the MBMS area context behind the counting branch.	Check whether the cell had the expected MBMS context before counting started.
MBMS Counting Request r10	RRC	eNB -> UE	Starts the MBMS counting branch.	Check which MBMS services or interest items were being counted.
MBMS Counting Response r10	RRC	UE -> eNB	Returns the UE-side MBMS counting feedback.	Check whether the response matches the earlier request and MBMS interest context.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Counting target	The MBMS services or items included in the counting request.	MBMS Counting Request	Shows what the network was trying to measure.	The response is analyzed without checking what was actually requested.
UE MBMS interest	The MBMS interest that made a response relevant.	Response context	Explains why a given UE did or did not respond.	The absence of a response is treated as a failure when the UE had no matching interest.
Counting timing	When the request and response happened relative to later MBMS handling.	Across the counting branch	Useful when later MBMS decisions seem disconnected from the feedback.	Counting is read without the later MBMS continuation.
MBMS area context	The MBMS service area or context already visible before counting.	SIB13 and MBMS background	Shows whether the counting branch belonged to the expected MBMS environment.	Counting is blamed while the underlying MBMS context was wrong.
Response completeness	Whether the expected MBMS responses actually appeared.	After the request	Explains whether the counting branch completed cleanly.	The network expected more responses than the trace or UE state could support.

Successful Completion

Success means the counting request and the relevant counting responses are both visible and tied to the same MBMS demand-estimation branch.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The network appears to start counting, but the responses are unclear	The request context or UE interest correlation is incomplete.	Counting request, counting response, and MBMS background context.	MBMS Counting Request r10, MBMS Counting Response r10	LTE Uu	Read the request and response together and keep the MBMS background visible.
Later MBMS handling looks disconnected from UE demand	The counting branch may have been missed or not read through to the result.	Counting exchange and the later MBMS continuation.	Counting request and response	LTE Uu	Follow the branch past the response into the later MBMS handling.

What to Check in Logs and Traces

Anchor the counting branch in the MBMS context first.
Read MBMS Counting Request and Response as one pair.
Check what the network did after the counting feedback arrived.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

MBMS counting is an MBMS demand-estimation branch. It should not be confused with actual MBMS bearer delivery.

FAQ

What is the LTE MBMS Counting Procedure?

It is the LTE control branch used to collect MBMS counting feedback from interested UEs.

Is MBMS counting the same as MBMS service delivery?

No. It is a demand-estimation step before later MBMS handling.