Home / Call Flows / LTE / LTE CMAS Notification Procedure

LTE CMAS Notification Procedure Call Flow

call-flow LTE | CMAS | Warning | Broadcast | Paging

LTE CMAS Notification Procedure is the LTE warning-delivery path used when Commercial Mobile Alert System information has to be exposed to UEs through the broadcast and warning-related LTE context.

It depends on the same broadcast-side foundations as other warning flows: valid system information, warning-related SIB handling, and idle-side awareness where the UE must notice a change.

Introduction

The LTE CMAS Notification Procedure is a public-alert broadcast path rather than a normal UE-specific signaling transaction. The main question is whether the UE could actually see the warning-related LTE context when it mattered.

Use this page when the problem is not basic LTE access, but whether the alert-related broadcast context became visible and current at the UE.

What Is LTE CMAS Notification Procedure in Simple Terms?

What starts the procedure: The network activates CMAS-related warning broadcasting for the cell or area.
What the UE and network want to achieve: Expose the alert-related LTE broadcast context clearly to the UE.
What success looks like: The UE reads the alert-related broadcast path in time and the warning context becomes visible.
What failure means: The alert-related broadcast path is stale, incomplete, or missed at the UE.

Why this procedure matters

CMAS analysis is mainly about the visibility of the alert-related broadcast path. A UE can look healthy from the ordinary LTE service point of view while still missing the warning-side update that mattered most.

Quick Fact Sheet

Procedure name	LTE CMAS Notification Procedure
Domain	LTE public alert broadcast
Main trigger	CMAS warning activation by the network
Start state	UE is camped or monitoring LTE broadcast behavior in the alert area
End state	UE has the CMAS-related LTE context needed for the alert path
Main nodes	UE, eNB
Main protocols	RRC broadcast information, paging-side reachability where relevant
Main success outcome	The alert-related broadcast context is visible to the UE
Main failure outcome	The alert path is stale, incomplete, or missed
Most important messages	SIB1, warning-related SIB family, Paging where relevant
Main specs	TS 36.331, TS 36.300

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

Preconditions

The UE already has the basic LTE broadcast context for the cell.
The cell or area is configured to expose CMAS-related warning information.
The UE is in a state where broadcast refresh or warning visibility can be observed.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
UE	Reads the alert-related LTE broadcast context and reacts to it.
eNB	Schedules the alert-related LTE information and any related alerting path.
Broadcast warning context	Provides the CMAS-related alert information visible to UEs in the affected area.

Interfaces used

Interface	Path	Role
LTE Uu	UE <-> eNB	Carries the CMAS-related LTE warning path.
BCCH / DL-SCH	eNB -> UE	Carry the warning-related system-information content.
Paging-side path	eNB -> UE	May support idle awareness of warning-related changes.

End-to-End Call Flow

UE                         eNB / alert context
|--idle monitoring----------->|
|<--Paging (if used)----------|
|<--SIB1 / SI change----------|
|<--CMAS-related broadcast----|

Major Phases

Phase	What happens
1. Alert activation	The network activates the CMAS-related alert path.
2. Idle-side awareness or refresh	The UE becomes aware that warning-related broadcast context matters.
3. Alert-related broadcast read	The UE reads the CMAS-related LTE warning context.
4. Alert visibility at the UE	The alert-related LTE path is now visible as either complete or incomplete.

Step-by-Step Breakdown

Start from the broadcast baseline

Sender -> receiver: UE

Message(s): SIB1 and existing LTE system-information view

Purpose: Anchor CMAS analysis in the current broadcast state of the cell.

State or context change: The UE has the normal broadcast baseline needed before alert-specific analysis.

Note: A broken broadcast baseline can make the alert path look worse than it really is.

Check whether the UE was alerted to refresh

Sender -> receiver: eNB -> UE

Message(s): Paging or SI-change-driven continuation

Purpose: Explain how the UE would have noticed the alert-related update.

State or context change: The UE is positioned to observe the later alert-related broadcast content.

Note: The exact pattern can differ, so keep the paging and broadcast views together.

Read the alert-related broadcast context

Sender -> receiver: eNB -> UE

Message(s): Warning-related SIB family within LTE system information

Purpose: Expose CMAS-related warning information to the UE.

State or context change: The UE now has the warning-related LTE context needed for the alert path.

Note: The warning-related SIB family on this site is covered through the broader LTE system-information reference.

Correlate the alert visibility

Sender -> receiver: UE

Message(s): Warning handling continuation

Purpose: Check whether the CMAS-related context was actually visible at the UE when needed.

State or context change: The alert path is now visible as complete or incomplete.

Note: The main question is timing and visibility, not only theoretical broadcast configuration.

Important Messages

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
System Information Block Type 1	RRC	eNB -> UE	Provides the scheduling and change-detection baseline.	Check whether the UE had the right baseline before the warning update.
Paging	RRC	eNB -> UE	May support idle awareness of warning-related updates.	Check whether the UE had a clear reason to return attention to the warning path.
LTE System Information Reference	RRC	eNB -> UE	Maps the warning-related SIB family used for CMAS analysis.	Check the public-warning blocks through the LTE system-information reference.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Alert-area context	The cell or area scope where the alert should be visible.	Broadcast and idle context	Needed to confirm the UE was in the intended alert scope.	The UE was outside the relevant alert-side LTE context.
Baseline broadcast view	The broadcast state before the alert-related update.	SIB1 and earlier system-information read	Shows whether the UE had the correct starting point for alert analysis.	The alert path is blamed even though the broadcast baseline was already broken.
Warning-related SIB visibility	Whether the public-warning SIB family was present and current.	LTE system-information view	Shows whether the alert content was really visible to the UE.	The alert path is assumed without proving the warning block was readable.
Idle awareness path	How the UE became aware of the alert-related change while idle.	Paging and SI-change context	Useful when the UE had to refresh broadcast context.	The UE never refreshed the broadcast view after the alert was activated.
Alert timing	When the alert-related information became visible compared with UE monitoring time.	Across activation and refresh timing	Important in time-sensitive alert analysis.	The UE monitoring window and alert broadcast window do not match.

Successful Completion

Success means the CMAS-related warning context became visible to the UE through a valid LTE broadcast path.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
The alert should have been visible, but the UE shows no warning-side behavior	The alert-related broadcast path may have been stale, absent, or never refreshed at the UE.	SIB1, paging-side context, and the warning-related SIB family.	SIB1, Paging, warning-related SIBs	LTE Uu	Check how the UE would have learned that the warning-related broadcast set changed.
The cell configuration looks right, but the warning still seems missed	The problem may be visibility timing rather than baseline configuration.	Alert activation timing and the UE refresh window.	Warning-related system information	LTE Uu	Keep timing visible instead of treating the warning path as static.

What to Check in Logs and Traces

Prove the broadcast baseline first.
Check how the UE would have refreshed or noticed alert-related changes while idle.
Use the LTE system-information reference for the public-warning SIB family.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

Notes

This page treats CMAS as an LTE broadcast warning path. The site’s deep-reference layer for the warning-related SIB family is the LTE system-information page.

FAQ

What is the LTE CMAS Notification Procedure?

It is the LTE alert-related broadcast path used to expose CMAS warning information to UEs.

What should I inspect first in a CMAS-related LTE trace?

Start with the normal broadcast baseline, then check how the UE would have refreshed or noticed the warning-related broadcast change.