Just in terms of user experience, CBS may look like a kind of Short Message service(SMS) or USSD (your device would popup a notification signal or text string as it recieves CBS message). But if you gets into a little bit deeper, you would notice that CBS and SMS/USSD has completely different foundation.

First, you would see high level difference as follows :

• SMS is one to one message and CBS is a message broadcast to many people simultaneously.
• SMS can be bidirectional (you can send and receive the message) and CBS is usually unidirectional (subscribers can only receive the message).

The topics on this page are listed below.

• Which channel carries CBS?
• When does the UE read the CTCH?
• What does a CBS message contain?
• Reference

Which channel carries CBS?

More importantly, CBS and SMS/USSD are transmitted by completely different channel and mechanism. Whereas SMS/USSD is transmitted by DCCH->DPCH as normal signaling message, CBS is using its own independent channel (CTCH-> SCCPCH) as shown below. (Channel Configuration for CBS is configured in SIB5 or SIB5bis)

The diagram below puts the channel chain beside a decoded SysInfoType5. On the left, the logical channel CTCH maps onto the transport channel FACH, and FACH maps onto the physical channel SCCPCH. On the right, the brackets mark which part of SIB5 configures that chain and which part schedules it.

The CBS channel chain and the SIB5 fields behind it. One SCCPCH entry carries the FACH for CBS, and cbs-DRX-Level1Information tells the UE when to read it.

• Two SCCPCH entries : sCCPCH-SystemInformationList holds 2 entries. The bracket points at the second one, with fach-PCH-InformationList = 2, as the TrCH and PHY configuration for CBS transmission.
• The CTCH sits on only one S-CCPCH : 25.331 clause 8.5.16 states this. If more than one CTCH is defined, the UE uses the first S-CCPCH in the list that carries a CTCH.
• cbs-DRX-Level1Information is the schedule : ctch-AllocationPeriod = 16 and cbs-FrameOffset = 0. The next section turns these two numbers into radio frames.
• A UE in connected mode ignores SIB6 for CTCH : 25.331 clause 8.5.16 tells it to use the CTCH configuration of SIB5 or SIB5bis only.

So CBS never reaches the UE on a dedicated channel. Every UE in the cell reads the same S-CCPCH, which is why one message can reach thousands of UEs at the same cost as one. Above RLC, the BMC protocol of 25.324 frames the messages, and RLC carries them in UM, because a broadcast has no receiver to send an acknowledgement.

• CTCH to FACH to SCCPCH : this chain, not DCCH to DPCH, carries CBS.
• SIB5 or SIB5bis configures it : the S-CCPCH list gives the channel, and cbs-DRX-Level1Information gives the timing.
• BMC over RLC UM : 25.324 defines BMC messages with RLC-SAP UM and logical channel CTCH.

When does the UE read the CTCH?

A UE would drain its battery if it decoded the S-CCPCH in every radio frame to catch a CBS message. 25.331 therefore limits CBS data to fixed CTCH occasions, and SIB5 announces them with two numbers. The UE wakes for those frames only, and 25.331 calls this information CBS DRX Level 1.

The diagram below matches those two numbers against a protocol log. The SIB5 tree at the top is the one from the previous section. Below it, the log lists the primitives on the CTCH and the FACH, with the progress time in the right column. A blue arrow ties ctch-AllocationPeriod = 16 to the gap between two PHY_DATA_REQ lines.

CTCH occasions in a protocol log. One RLC UM PDU on the CTCH leaves the PHY as a run of FACH transmissions, one in each CTCH occasion.

• One RLC_UM_DATA_REQ, five MAC and five PHY requests : the first group at 000:00:23.14 shows one RLC UM PDU on the CTCH, split into five MAC_DATA_REQ lines, and then five PHY_DATA_REQ lines on the FACH.
• The PHY requests are 160 ms apart : they read 23.15, 23.31, 23.47, 23.63 and 23.79 seconds.
• The annotation 16 ms = 16 TTI is off by a factor of ten : 25.331 counts the period N in radio frames of 10 ms. So N = 16 is 160 ms, which is 16 TTIs only for a 10 ms FACH TTI. The log timing agrees with 160 ms, not with 16 ms.
• The next RLC PDU starts 800 ms later : the second group begins at 23.94, after five occasions of 160 ms.

25.331 clause 8.5.16 gives the rule behind the log. The CTCH occasions fall on SFN = K + mN, for m = 0, 1, 2 and so on, up to SFN 4095. N is ctch-AllocationPeriod, K is cbs-FrameOffset, and both count radio frames. Both are multiples of M_TTI, the number of radio frames in one TTI of the FACH that carries the CTCH.

In 25.331 v19.0.1, ctch-AllocationPeriod is INTEGER (1..256) and cbs-FrameOffset is INTEGER (0..255). With the values of this capture, N = 16 and K = 0, so the occasions are SFN 0, 16, 32 and so on. The occasions restart with the SFN cycle, with no modulo calculation.

Level 1 only tells the UE when CBS data may arrive, not whether it wants that data. For that, the BMC Schedule Message of 25.324 describes the next CBS schedule period, message by message. Rel-6 added the Period of BMC scheduling messages, P, to the same IE, so a Schedule Message starts in every P-th occasion. A UE that follows the schedule can skip the occasions that carry messages outside its search list. This is the second stage of CBS DRX, and BMC runs it.

• N and K are in radio frames : N = 16 is 160 ms, whatever the drawing says.
• Level 1 is fixed by SIB5 : SFN = K + mN, with N between M_TTI and 256.
• The second stage comes from BMC : the Schedule Message lets the UE skip content it does not want.

What does a CBS message contain?

CBS Message parameter and an example is shown here. The diagram below has two parts. At the top is the message parameter table of 23.041 clause 9.4.1.2, with octet numbers on the left. Below it is a decoded BMC message from the same kind of log, with the decoder's reading of each field on the right.

A CBS message and the fields that identify it. Message ID says what kind of message it is, and Serial Number says which version of it the UE is looking at.

• The table is the GSM format : 23.041 clause 9.4.1.2 describes the fixed 88 octet GSM page: Serial Number in octets 1-2, Message Identifier in 3-4, DCS in 5, Page Parameter in 6 and content in 7-88.
• The decode follows the UMTS format : Message Type comes first and reads BMC CBS Message. Message ID, Serial Number, Data Coding Scheme and CB Data follow, as in 23.041 Table 9.4.2.2-1.
• Message ID 0003 : the decoder labels it 'To be allocated by PLMN'. In 23.041 v20.0.0, the range 0000 to 03E7 hex is 'To be allocated by GSMA', see GSMA AD.26. The capture is not corrected here.
• Serial Number splits into three fields : Geographical Scope 01 means PLMN wide with normal display mode. Message Code 0 and Update Number 0 follow it.
• Data Coding Scheme 00000001 : 23.038 clause 5 reads this as English in the GSM 7 bit default alphabet.
• CB Data : number of Page = 1, and the text hello1 is 6 characters long, which matches number of character = 6.

Why does UMTS change the format? In GSM, the CBCH carries fixed pages of 88 octets, so each page carries its own page parameter. In UMTS, 23.041 clause 9.4.2.1 sends the whole CBS message as one unit on the CTCH. So the page count moves into CB Data, which holds Number-of-Pages and then up to 15 pairs of an 82 octet information page and its length octet. The Message Type octet also appears, because 25.324 carries three BMC messages on the same CTCH: CBS Message = 1, Schedule Message = 2 and CBS41 Message = 3.

The UE decides what to display from Message ID and Serial Number. It receives only the messages whose Message ID is in its search list, taken from the USIM and from the UE's own list. Geographical Scope, Message Code and Update Number then tell it whether a message is new or a repeat of one it has already shown. The range 4352 to 6399, 1100 to 18FF hex, is reserved for the Public Warning System, which includes ETWS and CMAS.

• Two message formats : 23.041 clause 9.4.1.2 for GSM and clause 9.4.2.2 for UMTS. The table in the diagram is the GSM one.
• Message ID selects, Serial Number versions : the UE filters on the first and detects updates with the second.
• Warning messages use the same frame : a Message ID from 1100 to 18FF hex marks a public warning message.

Reference

• 25.324  Broadcast/Multicast Control BMC - v19.0.0, clauses 10.2 and 11.1
• 23.041 Technical realization of Cell Broadcast Service (CBS) - v20.0.0, clauses 9.4.1.2 and 9.4.2.2
• 25.331 Radio Resource Control - v19.0.1, clause 8.5.16 Configuration of CTCH occasions and clause 10.3.8.3 CBS DRX Level 1 information
• 23.038 Alphabets and language-specific information - v20.0.0, clause 5 CBS Data Coding Scheme