Cell Broadcast

Nokia Siemens Networks GSM/EDGE BSS, rel. RG20(BSS), operating documentation, issue 02

Functional area description

Cell Broadcast

DN9814202

Issue 14-1

Confidential

2 DN9814202Issue 14-1

Cell Broadcast

Id:0900d8058058f01aConfidential

The information in this document is subject to change without notice and describes only the product defined in the introduction of this documentation. This documentation is intended for the use of Nokia Siemens Networks customers only for the purposes of the agreement under which the document is submitted, and no part of it may be used, reproduced, modified or transmitted in any form or means without the prior written permission of Nokia Siemens Networks. The documentation has been prepared to be used by professional and properly trained personnel, and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes customer comments as part of the process of continuous development and improvement of the documentation.

The information or statements given in this documentation concerning the suitability, capacity, or performance of the mentioned hardware or software products are given "as is" and all liability arising in connection with such hardware or software products shall be defined conclusively and finally in a separate agreement between Nokia Siemens Networks and the customer. However, Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions contained in the document are adequate and free of material errors and omissions. Nokia Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which may not be covered by the document.

Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION IN IT.

This documentation and the product it describes are considered protected by copyrights and other intellectual property rights according to the applicable laws.

The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark of Nokia Corporation. Siemens is a registered trademark of Siemens AG.

Other product names mentioned in this document may be trademarks of their respective owners, and they are mentioned for identification purposes only.

Copyright © Nokia Siemens Networks 2010. All rights reserved

f Important Notice on Product Safety Elevated voltages are inevitably present at specific points in this electrical equipment. Some of the parts may also have elevated operating temperatures.

Non-observance of these conditions and the safety instructions can result in personal injury or in property damage.

Therefore, only trained and qualified personnel may install and maintain the system.

The system complies with the standard EN 60950 / IEC 60950. All equipment connected has to comply with the applicable safety standards.

The same text in German:

Wichtiger Hinweis zur Produktsicherheit

In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.

Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-zungen und Sachschäden führen.

Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die Anlagen installiert und wartet.

Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.

DN9814202Issue 14-1

3

Cell Broadcast


Table of contentsThis document has 28 pages.

Summary of changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1 Overview of Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Technical description of Cell Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . 7

3 Functionality of Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1 Basic Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2 Cell Broadcast center interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3 A BSC-CBC connection example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4 Effect of Cell Broadcast on interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 174.1 Effect on Abis interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Effect on air interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5 User interface of Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4 DN9814202Issue 14-1

Cell Broadcast


List of figuresFigure 1 Environment of the cell broadcast service . . . . . . . . . . . . . . . . . . . . . . . 10Figure 2 Overview of the TPP service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Figure 3 A BSC-CBC connection example, part 1 . . . . . . . . . . . . . . . . . . . . . . . . 14Figure 4 A BSC-CBC connection example, part 2 . . . . . . . . . . . . . . . . . . . . . . . . 15Figure 5 CBCH Load Indication message content . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 6 CBCH Load Information IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Figure 7 SMS Broadcast Request message content . . . . . . . . . . . . . . . . . . . . . . 18Figure 8 SMSCB Information IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figure 9 Block content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 10 Block type content. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 11 Sequence number coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19Figure 12 Schedule message coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20Figure 13 New SMSCB Message Bitmap coding . . . . . . . . . . . . . . . . . . . . . . . . . . 20Figure 14 New SMSCB Message Description coding. . . . . . . . . . . . . . . . . . . . . . . 21Figure 15 Other Messages Part coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21Figure 16 Message Description coding, first transmission of an SMSCB . . . . . . . . 22Figure 17 Message Description coding, retransmission of an SMSCB. . . . . . . . . . 22Figure 18 Message Description coding, free message slot, optional reading. . . . . 22Figure 19 Serial Number content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23Figure 20 Data Coding Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Figure 21 Data Coding Scheme continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Figure 22 Data Coding Scheme continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

DN9814202Issue 14-1

5

Cell Broadcast Summary of changes

Id:0900d8058058f008Confidential

Summary of changesChanges between document issues are cumulative. Therefore, the latest document issue contains all changes made to previous issues.

Changes made between issues 14-1 and 14-0Information on InSite BTS has been removed.

Changes made between issues 14-0 and 13-0The maximum storage capacity of Cell Broadcast message pages for BSC3i has been updated from 15000 to 30000.

Information on OSI over TCP/IP has been added.

Changes made between issues 13-0 and 12-0Information on PrimeSite BTSs and 2nd generation BTSs has been removed.

Changes made between issues 12-0 and 11-0The maximum storage capacity of Cell Broadcast message pages was updated from 5400 to 8068 for BSCi/BSC2i and to 15000 for BSC3i.

6 DN9814202Issue 14-1

Cell Broadcast

Id:0900d8058058f00bConfidential

Overview of Cell Broadcast

1 Overview of Cell BroadcastCell Broadcast (CB) provides the BSC with the short message service cell broadcast (SMSCB) capabilities as defined by the GSM recommendations. The SMSCB is a basic teleservice that is used for broadcasting short messages to GSM mobile stations in a specified area within the PLMN.Cell Broadcast includes discontinuous reception (DRX) which enables the saving of MS battery consumption. The DRX adds the possibility for mobile stations to receive only the needed part of the cell broadcast channel (CBCH). This is done by sending a schedule message indicating what messages are coming during the next schedule period to the MS in advance.

The input for CB messages is MMI, local or remote. Optionally, the cell broadcast centre (CBC) interface can be used: it offers a centralised means to operate Cell Broadcast; the broadcast of several BSCs can be operated through one CBC. When the CBC con-nection is used in the BSC, it replaces the existing MML commands. Only local or remote output of CB messages and CBCH loads is possible. The CBC interface offers the same basic services as the MMI.

Related topics in Cell Broadcast

• Technical description of Cell Broadcast • Functionality of Cell Broadcast • Effect of Cell Broadcast on interfaces • User interface of Cell Broadcast

Other related topics

• Reference • Commands

• MML Commands • EC - SMS Cell Broadcast Handling

• Interface Specifications • BSC-CBC Interface DX 200

DN9814202Issue 14-1

7

Cell Broadcast Technical description of Cell Broadcast

Id:0900d8058058f00eConfidential

2 Technical description of Cell BroadcastThe short messages broadcasted with the short message service cell broadcast (SMSCB) can be used for giving information on, for example, PLMN news, emergen-cies, traffic reports, road accidents, delayed trains, weather reports, theatre pro-grammes, telephone numbers, or tariffs. The cell broadcast (CB) service is characterised by the following aspects:

• No acknowledgment is sent from the MS. • The CB message is sent on control channels in a limited area, defined by the origi-

nator of the message by an agreement with the PLMN. • Reception is only possible when the MS is in idle mode. • CB messages are sent continuously so that all messages are sent in turn and then

repeated. The repetition rate of a message should be frequent enough for it to be received by travellers moving through a group of cells.

• A given message is likely to be received repeatedly although the user only wants to see the same message once. The network gives the message a serial number (see 3GPP TS 03.41 Technical Realization of Short Message Service - Cell Broadcast). If the MS has received a message with an identical message identifier and serial number, it ignores the new, repeated message. If the message information is updated, the message is given a new serial number so that it will be recognised and received.

• CB messages are mobile-terminated only. • The maximum number of user characters in each CB message page depends on

the coding group. The maximum length can vary from 40 to 93 characters. The con-catenation mechanism, which allows up to 15 of these message pages to be treated as segments of a longer message, is described in 3GPP TS 03.41 Technical Real-ization of Short Message Service - Cell Broadcast.

Cell Broadcast (CB) messages are stored in the BSC in the Cell Broadcast Message File and they are managed through the MMI system. Once they have been entered to the BSC and activated, the BSC broadcasts them cyclically and conveys them transparently through the BTS to the MS.

It is possible to reduce battery consumption with the help of Last Block information and the DRX. Last Block information enables the MS to receive only the needed blocks of the SMSCB messages. The Last Block information indicates to the MS whether the next block contains SMSCB information or not.

The DRX adds the possibility for MSS to receive only the needed part of a CBCH. This is done by sending the MS in advance a schedule message, which provides the MS with information on messages that are coming during the next schedule period. The messages are defined in the schedule message by their message identifiers. The schedule messages are sent on the CBCH as normal SMSCB messages. The schedule period is the length of time covered by the SMSCB messages referred to in a schedule message. In a Nokia BSC, the schedule period is roughly one minute.

Cell broadcast capacityThe size of a broadcast area can vary from a whole PLMN to a single cell. Typically, it takes 1.88 seconds for a message to be transmitted, permitting almost 64 messages to be sent in a period of 2 minutes to the specified broadcast area.

8 DN9814202Issue 14-1

Cell Broadcast


Technical description of Cell Broadcast

A maximum of 60 different active CB messages per cell can be defined. The maximum storage capacity is 8068 CB message pages for BSCi/BSC2i and 30000 CB message pages for BSC3i. Multi-page messages up to 15 pages are possible.

The BSC can store 80 most recent broadcast counters of CB messages per cell.

RestrictionsThe CBCH can be configured only to a BCCH TRX, that is, CBCH+BCCH+SDCCH/4 in TSL 0 or CBCH+SDCCH/8 in TSLs 1 - 3. This is because the mobile station has to listen to the PCH and the CBCH simultaneously, which is not possible if they are on different frequencies.

InterworkingThe Connection-oriented Transport Service (10350) is a prerequisite for using the Transport Pipe Provider (TPP).

The database-oriented OSI management implementation, the OSI Environment Support Services (10302), must be supported.

Configuration requirementsBTS: Flexi EDGE, UltraSite EDGE, MetroSite EDGE, Talk-family

BSC: S6 or later

MS: Only MSs of phase 2 that have SMSCB DRX specially implemented support Cell Broadcast

Signalling requirementsThe signalling system used in the BSC-CBC interface is X.25, ISO CLNP or OSI over TCP/IP. Transport layer flow control must also be supported in the CBC.

For more information, see BSC-CBC Interface DX 200 under Reference.

SMS Cell Broadcast HandlingWhen entering a CB message to the BSC, a new message is created. The message is saved after you have finished entering it (1 to 15 pages). Each stored message is allo-cated a unique message index which can be used when referring to a CB message. Messages in different languages must be entered individually.

A CB message must be entered to the BSC before it can be activated for broadcasting. The message is activated by linking cell indexes to it. A message can be activated using certain keywords such as all existing cells within the BSC, or only certain specified cells. New cells are not activated automatically, but must be activated separately. Activated messages are automatically broadcasted in the next schedule period.

Partial deactivation of a CB message is done by unlinking it from a certain cell or cells. Complete deactivation of a message is done by unlinking it from all the cells to which it was earlier linked. Deactivated messages are automatically left out of broadcasting in the next schedule period.

Deactivating a cell or cells means that all active CB messages within that cell or those cells are deactivated. After the deactivation, there will be no cell broadcasting during the next schedule period.

When modifying a CB message, the old message is read, and after the modifications, the modified message is saved. The BSC increases the message number by one. The old message is deleted after the current schedule period.

DN9814202Issue 14-1

9

Cell Broadcast Technical description of Cell Broadcast


A CB message can be deleted only when it has no links to cell indexes. Therefore the message must be deactivated completely before deletion. One or several messages can be deleted using certain keywords such as all messages within the BSC, or a message or messages with specified message indexes.

One or several CB messages can be displayed using certain keywords such as all messages within the BSC, all active messages within a certain cell, or one or several messages with specified message indexes.

For information on managing CB messages through the MMI, see EC -SMS Cell Broad-cast Handling under Reference.

For information on managing CB messages through the CBC interface, see CBC-BSC procedures in BSC-CBC Interface DX 200 under Reference.

10 DN9814202Issue 14-1

Cell Broadcast


Functionality of Cell Broadcast

3 Functionality of Cell Broadcast

3.1 Basic Cell Broadcast

Figure 1 Environment of the cell broadcast service

Cell Broadcast Services The Cell Broadcast Services (CBS) handles cell broadcast files, the MMI and CBC inter-faces. It manages the reading and writing of cell broadcast (CB) messages to the cell broadcast files as well as the correct timing of CB messages and the transmitting of CB messages to the MS. If the DRX is supported, the Cell Broadcast Services creates schedule messages and transmits them to the MS and supports the Cell Broadcast Channel (CBCH) flow control.

The cell broadcast files are located in the Marker and Cellular Management Unit (MCMU) of the BSC. Cell Broadcast Message File stores CB messages. Cell Active Messages File indicates active CB messages of cells. Cell Broadcast Counter File indi-cates broadcast counters of CB messages/cell.

The cell broadcast files, if changed, are updated to the hard disc regularly.

The Cell Broadcast Services reads radio network configuration information from the BSS Radio Network Configuration Database.

CB, schedule message broadcasting procedures and Abis interfaceThe BSC receives CBCH LOAD INDICATION messages from the BTS. The BSC creates for each cell a broadcast list containing a schedule message(s) if applicable, and

Cell BroadcastServices

RW RW RW

Cell BroadcastCounter File

Cell BroadcastMessage File

Cell ActiveMessages File

OSIProtocols

Cell BroadcastService Handling

CBC Interface

Cell Broadcast MML

BTS

MSCBC

DN9814202Issue 14-1

11

Cell Broadcast Functionality of Cell Broadcast


all the CB messages connected to that cell. The BSC broadcasts messages on that list cyclically from the first message to the last one, and then starts the cycle again. If nec-essary, it updates the lists after message deactivation, for example. After the update, the broadcasting starts again from the top of the broadcast list after the present schedule period has been sent.

The BSC divides long messages into several pages when necessary. It finds out from the BSC database on a cell basis which Base Station Controller Signalling Unit (BCSU) and transceiver (TRX) the message should be transmitted to. It then sends the CB and schedule messages to the BCSU. For more information, see 3GPP TS 03.41 Technical Realization of Short Message Service - Cell Broadcast and 3GPP TS 04.12 Short Message Service Cell Broadcast - Support on Mobile Radio Interface.

The BSC divides the CB and schedule messages into four separate blocks, as instructed in 3GPP TS 04.12 Short Message Service Cell Broadcast - Support on Mobile Radio Interface, and these blocks are sent individually to the BTS via the Abis interface in the SMS BROADCAST REQUEST message, which is defined in 3GPP TS 08.58 Base Station Controller - Base Transceiver Station (BCS-BTS) Interface Layer 3 Spec-ification. The SMSCB information in the SMS BROADCAST REQUEST message contains 24 octets. The element includes a frame which is ready to be transmitted on the Cell Broadcast Channel (CBCH) on the radio path. It includes a Layer 2 header for the radio path and a 23-octet block as defined in Effect on Abis interface.

The SMSCB information element is transmitted from the BTS to the MS on the CBCH in four consecutive multiframes. For more information, see 3GPP TS 05.02 Multiplexing and Multiple Access on the Radio Path.

CBCH flow controlTo keep schedule periods consistent in the radio interface, a CBCH flow control proce-dure is defined. If the BTS finds that its message buffer is going to be either underflowed or overflowed, it sends a CBCH LOAD INDICATION message to the BSC, telling it either to immediately broadcast some messages or to stop broadcasting for a while. The BTS defines in the message the exact number of messages it needs or the number of the message slots during which the broadcasting should be stopped in the BSC.

If the DRX is not supported in the BSC, the CBCH flow control is not supported either.

For more information, see Effect on Abis interface.

3.2 Cell Broadcast center interfaceThe BSC has a user-friendly interface to the connection-oriented transport service (COTS) for taking care of the following tasks:

• routing of outgoing connection requests to the correct computer unit offering the COTS (Transport and Session Layers of OSI Stack (class 0 or 4))

• routing of incoming connection requests to the correct application or terminating of connections

• flow control of COTS user data transmission • access control of incoming connection using the services of the Network Operator

Authorization System (NEOPAC).

Transport and Session Layers of OSI Stack (class 0) provide a COTS interface via a connection-oriented network service.

12 DN9814202Issue 14-1

Cell Broadcast



Transport and Session Layers of OSI Stack (class 4) provide a COTS interface via a connectionless network service.

The TPP and COTS providers inquire the OSI application database with the help of the OSI Stack Addressing and Routing by sending query messages to it. The COTS provid-ers also send connection control messages to the OSI Stack Addressing and Routing each time a transport connection has been established or released.

The Cell Broadcast center interface implements the application entity protocol, CBSE, which is defined in CBSE definition.

An Application Entity name (AE name) is assigned to the Cell Broadcast center interface and the remote COTS user.

A presentation address consisting of T selector and network address (NSAP) is also assigned to the Cell Broadcast center interface and the remote COTS user.

The Cell Broadcast Service Handling implements the BSC functionality of the CBC inter-face service defined in CBC-BSC procedures in BSC-CBC Interface DX 200 under Ref-erence.

OSI protocolsThe BSC implements the OSI protocol software. The Transport Pipe Provider (TPP) enables processes on different network elements to communicate with each other. Using the DX message interface of the TPP, the Transport Pipe Users (TPUs), for example the Cell Broadcast center interface, gain access to communication services provided by the OSI transport protocol. This means that the service is not dependent on the communication subnetwork used (X.25, OSI/LAN, OSI over TCP/IP).

The service provided by the TPP corresponds to the Connection-Oriented Transport Layer Service (OSI COTS) specification.

The following figure presents an overview of communication using the TPP.

Figure 2 Overview of the TPP service

The Operation and Maintenance Unit (OMU) implements the TPP in the BSC. Imple-mentation of OSI Stack Transport (class 4) and the Session Layer implementing the COTS interface are located in the same computer units where the plug-in units offering the corresponding network service reside.

DX200/MSC/HLR/BSC

Remote System

TPP

COTSinterface

OSI/LAN or X.25

Applicationsusing COTSservices

OSItransportprotocol

OSItransportprotocol

TransportPipe User

TPUinterface

COTSinterface

DN9814202Issue 14-1

13



Security-related operationsThe security-related operations perform tasks related to network user access control. They can also be used for handling data on network user authorities.

The NEOPAC offers a mechanism for username/password checking. TPP users must be created before incoming calls via the TPP interface are allowed (not in use in the BSC).

For more information on the BSC-CBC Interface, see BSC-CBC Interface DX 200 under Reference.

3.3 A BSC-CBC connection exampleR_COTS refers to the transport service of a remote system and R_USER to the user of that service.

14 DN9814202Issue 14-1

Cell Broadcast



Figure 3 A BSC-CBC connection example, part 1

CBS CB i/f NEOPAC TPP(CH) TPP(M) R_COTS R_USER

1

The CBSE Bind Service

Transportand

SessionLayers

2

3

4

5

6

7

8

10

11

12

13

14

15

17

18

19

The delivery of username/password

The access control procedure

The sending of approval/disapproval

The delivery of Write_Replace

Write_Req

connect_request

t_connect_indication_s

t_connect_indication_s

t_connect_response_s

connect_response

data_PDU

t_data_indication_s

ftam_access_control_req_s

ftam_access_control_rsp_s

t_data_request_s

data_PDU

data_PDU

t_data_indication_s

receive_tpp_data_req_s(C314)

cbh_write_replace_ind_s

cbi_report_resp_s

receive_tpp_data_rsp_s(C309)

send_tpp_data_req_s(C323)

16

9

DN9814202Issue 14-1

15



Figure 4 A BSC-CBC connection example, part 2

2. Not necessary if a CBC- or BSC-initiated connection exists.




12. If the access is denied, the procedure stops here and the response status is > 0. Normally, the access is approved with a response status equal to 0.

14. A 5-minute connection supervision timer is set.

15. If the local CBS application, that is, the Cell Broadcast center interface, is not registered to the OSI database, it is done automatically during incoming data. (A valid registration of the local CBS application is also needed if the BSC wants to send data and a registration does not exist. In this case it is done by the Cell Broadcast center interface. The remote AE name is used in registration.) Valid connection identifiers are received by the Cell Broadcast center interface.

16. If the BSC does not support the BSC-CBC interface, a Reject primitive message with the cause cbc_interface_not_supported is returned to the CBC.

18. The TPP(CH) generates a credit message to the CBC, allowing the CBC to send more data. The allowed amount of data is indicated in the message.

t_data_request_s20

send_tpp_data_rsp_s(C322)

21cbh_report_resp_ack_s

22data_PDU

23Report_Conf

24

disconnect_request25

t_disconnect_indication_s

26t_disconnect_response_s

27disconnect_response

28t_disconnect_request_s

29disconnect_request

30registration_cancelled_s(C306)

31

The delivery of Report

The CBSE Unbind Service

CBS CB i/f NEOPAC TPP(CH) TPP(M) R_COTS R_USER

Transportand

SessionLayers

16 DN9814202Issue 14-1

Cell Broadcast



19. The BSC's acknowledgement is sent to the CBC using the connection that the CBC has opened. The duration of the connection is prolonged with another 5 minutes. Only one connection is maintained. If there exist both BSC- and CBC-initiated connections, the BSC chooses the CBC-initiated one and disconnects the BSC-initiated one.

25. Not necessary if the CBC wants to leave the connection on for further use.

29. If there is no traffic before the 5-minute connection supervision timer expires and the connection is not released by R_COTS. (The release of BSC-initiated connections is always left for the supervision timer).

31. If the connection is initiated by the CBC. In that case the Cell Broadcast center interface loses valid connection identifiers.

DN9814202Issue 14-1

17

Cell Broadcast Effect of Cell Broadcast on interfaces


4 Effect of Cell Broadcast on interfaces

4.1 Effect on Abis interfaceCBCH Load Indication messageThis message is sent from the BTS to the BSC to indicate a CBCH underflow/overflow situation in the BTS and to request the BSC to accelerate or pause the cell broadcast for a period indicated by the BTS.

1) The SMSCB Channel Indicator information element (IE) indicates the CBCH that will be used for broadcasting the data. If this information element is not present, the basic CBCH will be used. For more information, see 3GPP TS 05.02 Multiplexing and Multiple Access on the Radio Path. The SMSCB Channel Indi-cator IE is not used.

Figure 5 CBCH Load Indication message content

The CBCH Load information element indicates the load situation in CBCH (under-flow/overflow) and information about the requested acceleration/suspension period of cell broadcast.

Figure 6 CBCH Load Information IE

The CBCH Load Type field (bit 8 of octet 2) indicates either an underflow or an overflow situation of CBCH in the BTS. It is coded as follows:

Value CBCH Load Type0 Underflow1 Overflow

The Message Slot Count field (bits 1 - 4 of octet 2) indicates either the number of sched-uled SMSCB messages that the BTS immediately needs or the amount of delay in message slots that the BTS immediately needs, depending on the value of the CBCH Load Type field. It is coded as follows:

INFORMATION ELEMENT

Message discriminator

Message type 0001 1110

Channel number

CBCH Load Information

SMSCB Channel Indicator

REFERENCE

9.1

9.2

9.3.1

9.3.43

9.3.44

PRESENCE

M

M

M

M

O 1)

FORMAT

V

V

TV

TV

TV

LENGTH

1

1

2

2

2

Element Identifier

Spare Message Slot Count

0 0 1 0 1 1 0 1

8 7 6 5 4 3 2 1

0 0 0

CBCHLoadType

18 DN9814202Issue 14-1

Cell Broadcast


Effect of Cell Broadcast on interfaces

CBCH Load Type Message Slot Count0 indicates the number of scheduled SMSCB messages (1 - 15) that are needed immediately by the BTS1 indicates the amount of delay in message slots (1 - 15) that is needed immediately by the BTS

SMS Broadcast Request messageThis message is sent from the BSC to the BTS to request the sending of a Short Message Service Cell Broadcast message.

1) The SMSCB Channel Indicator IE indicates the CBCH that will be used for broadcasting the data. If this information element is not present, the basic CBCH will be used. For more information, see 3GPP TS 05.02 Multiplexing and Multiple Access on the Radio Path. The SMSCB Channel Indicator IE is not used.

Figure 7 SMS Broadcast Request message content

The SMSCB IE contains the complete information to be broadcast on the CBCH as defined in 3GPP TS 04.12 Short Message Service Cell Broadcast - Support on Mobile Radio Interface (including the Layer 2 header to be used on the radio path).

The SMSCB Information IE is used to convey a complete frame to be broadcast on the CBCH including the Layer 2 header for the radio path.

Figure 8 SMSCB Information IE

4.2 Effect on air interfaceMessage format on BTS-MS interfaceA cell broadcast (CB) message consists of 88 octets of information. The 88-octet block is segmented into four 22-octet blocks. A 1-octet Block type (=layer 2 header) is added as a header to each 22-octet block. The overall blocks are thus 23 octets in length.

Block contentThe 23-octet blocks are coded as follows:

INFORMATION ELEMENT REFERENCE PRESENCE FORMAT LENGTH

Message discriminator 9.1 M V 1

Message type 9.2 M V 1

Channel number 9.3.1 M TV 2

SMSCB Information 9.3.36 M TV 24

SMSCB Channel Indicator 9.3.44 O 1) TV 2

Element identifier 1

2SMSCB frame

24

. .

8 7 6 5 4 3 2 1

DN9814202Issue 14-1

19



Figure 9 Block content

Figure 10 Block type content

In an SMSCB message the last block containing SMSCB information is signalled by the Last Block (LB) bit. For more information, see 3GPP TS 03.41 Technical Realization of Short Message Service - Cell Broadcast. When the LB bit is set to 0, the next block may contain SMSCB information. When the LB bit is set to 1, the remaining block(s) do(es) not contain SMSCB information.

Figure 11 Sequence number coding

The information field in the block contents includes either 22 bytes of a schedule message or 22 bytes of a CB message page.

Schedule message structureA schedule message consists of four consecutive blocks with block types 'first schedule block', 'second block', 'third block' and 'fourth block'. A schedule message containing scheduling data which does not fill the 88 octets is padded with the hexadecimal value '2B' at the end of the used part of the message. The schedule message comprises a 2-octet header followed by three parts, the first of them of 6 octets, and the two others of variable length, as indicated in the following figure:

Bit: 8Octet:

Block type 1

Information 2

23

. .

7 6 5 4 3 2 1

Bit:

Octet:

1

8 8 8 8 8 8 8 8

0 0 1

Spare LPD LB Sequence Number

Bit No

First block

Second block

Third block

Fourth block

4 3 3 1

0 0 0 0

0 0 0 1

0 0 1 0

0 0 1 1

1 0 0 0

1 1 1 1 Null message (does not containvalid SMSCB information)

First schedule block:Message contains SMSCBscheduling information

20 DN9814202Issue 14-1

Cell Broadcast



Figure 12 Schedule message coding

Octets following the last part (n+1 to 88 inclusive), if any, are ignored. In the following sections, when bits are indicated as spare, the network sets them to the indicated value (0 or 1), and the mobile station ignores their value.

Type (octet 1): Set to 00 for messages formatted as specified earlier. The receiver ignores the schedule messages with another 'Type' value.

Begin Slot Number (octet 1): Message slot number, relative to the schedule period, of the message slot following the schedule message.

End Slot Number (octet 2): Last message slot number described by this schedule message. The Begin Slot Number and the End Slot Number fields are coded in binary. Their values are implemented as 1 and 31 respectively.

The New SMSCB Message Bitmap 6-octet field encodes one bit per message slot, with the following indexing:

Figure 13 New SMSCB Message Bitmap coding

The New Message (NM) bit 'i' refers to the content of message slot 'i'. Its meaning is as follows:

1 The message slot contains an SMSCB message page which was not sent during the previous schedule period. The value is 1 for both the first transmission of a given SMSCB message page or a repetition of it within a schedule period.

Bit: 8Octet:

Type Begin Slot Number0 1

spare spare End Slot Number0 0 2

New SMSCB Message Bitmap 3 - 8

New SMSCB Message Description 9 - 2m

Other Message Descriptions (m+1)-n

0

7 6 5 4 3 2 1

Bit:Octet:

1

2

3

4

5

6

Bit: 8 7 6 5 4 3 2 1

NM01 NM02 NM03 NM04 NM05 NM06 NM07 NM08






DN9814202Issue 14-1

21



0 The message slot is such that value 1 is not suitable.

An SMSCB message fulfilling the criterion for bit value 1 is referred to as 'new' in the following sections.

The New SMSCB Message Description part contains as many message descriptions as there are bits set to 1 in the New Message Bitmap. This part can then be empty. A message description is 1 or 2 octets long:

Figure 14 New SMSCB Message Description coding

New Message Description 'j': This one- or two-octet long field contains information about what is sent in the jth message slot for which NM i is set to 1. The different possible encodings are specified in Message description encoding. All descriptions pertaining to the first transmission of a new message are put at the beginning, so that mobile stations can determine rapidly where the new messages are.

The Other Message Descriptions part contains a one- or two-octet message description for each of the remaining message slots in the schedule period, in the order of transmis-sion. This part can also be left empty.

Figure 15 Other Messages Part coding

The Message Slot Number for each description must be derived from the New SMSCB Message Bitmap. The different cases are encoded as specified in Message description encoding.

Message description encodingThree different encoding formats are used in message description encoding:

1) for the first transmission of an SMSCB message within the schedule period

2) for the repetition of an SMSCB message

3) for a message slot of unindicated use that mobile stations can skip

Bit:Octet:

Message Description 1 1

Message Description p

: :

8 7 6 5 4 3 2 1

8Octet:

Message Description 1 1

Message Description p

: :

Bit: 7 6 5 4 3 2 1

22 DN9814202Issue 14-1

Cell Broadcast



The different encoding formats are identified by the Message Description Type (MDT) field. The MDT field is of variable length. The length of a description can be determined from the value of bit 8 of the first octet, which can then be understood as a 'more' bit: value 0 indicates a single-octet field, and value 1 a 2-octet field.

The first transmission of an SMSCB message within the schedule period describes the content of a message slot which contains the first transmission of an SMSCB message page within the period:

Figure 16 Message Description coding, first transmission of an SMSCB

Message Description Type (MDT; octet 1 of Message Description, bit 8): 1-bit field set to 1 for the message description of a message slot containing the first transmission during the schedule period of a given SMSCB message page. Message identifier (octet 1 bits 7 to 1 and octet 2 of Message Description) consists of the low-order 15 bits of the corresponding field of the SMSCB message.

For more information, see 3GPP TS 02.03 Teleservices supported by a GSM PLMN.

Note that this restricts the Message Identifier area in the BSC to be from 0 to 32767.

When a message slot contains the repetition of an SMSCB message page within the schedule period, the corresponding message description is coded on one octet, as follows:

Figure 17 Message Description coding, retransmission of an SMSCB

MDT (octet 1 of Message Description, bits 8 and 7): 2-bit field set to '00' for the message description of a message slot containing the repetition of an SMSCB message page.

Repeated Message Slot Number (octet 1 of Message Description, bits 6 to 1): This field encodes the message slot number of the first transmission during the schedule period of the repeated SMSCB message page. The field is encoded in binary, range 1 to 30.

When no specific information about a message slot is provided, and mobile stations need not read its contents, the Message Description is coded as follows:

Figure 18 Message Description coding, free message slot, optional reading

Bit:Octet:

Message Identifier (high part) 1

Message Identifier (low part) 2

8 7 6 5 4 3 2 1

MDT1

Bit:Octet:

MDT0 Repeated Message Slot Number 10

8 7 6 5 4 3 2 1

Bit:Octet:

MDT10 1 0 0 0 0 0 0

8 7 6 5 4 3 2 1

DN9814202Issue 14-1

23



MDT (octet 1 of Message Description): 8-bit field set to '01000000'. The network can use such a message slot as needed, for example for instructing the BTS to send Null mes-sages.

The values of MDT not specified here are reserved for future use. They are treated as encoding a one-octet message description, and understood as Free Message Slot, optional reading.

CB message structureA CB message page consists of 4 consecutive blocks with Block Types 'first block', 'second block', 'third block', and 'fourth block'. A CB message can consist of several CB message pages. The BTS sends each CB message page to the MS as a fixed block of 88 octets. The 88 octets of CB message page information consist of a 6-octet header and 82 user octets, as shown below.

Octet No. 1-2 Serial Number 3-4 Message Identifier 5 Data Coding Scheme 6 Page Parameter 7-88 Contents of Message

These octets are transmitted in order, starting with octet 1. The bits within these octets are numbered from 0 to 7; bit 0 is the low order bit and is transmitted first. The fields are used as follows:

1. The Serial Number is a 16-bit integer which identifies a particular message (which may be one to 15 pages in length) from the source indicated by the message iden-tifier and is altered every time the message with a given message identifier is changed.The two octets of the serial number field are divided into a 2-bit Geographical Scope indicator, a 10-bit Message Code and a 4-bit Update Number in the following struc-ture:

Figure 19 Serial Number contentThe most significant bit of the message code is octet 1 bit 5 and the least significant bit of the message code is octet 2 bit 4. The most significant bit of the update number is octet 2 bit 3.The message code differentiates between messages from the same source and type (with the same message identifier). Message codes are for allocation by PLMN operators.The Geographical Scope (GS) indicates the geographical area over which the message code is unique, and the display mode. The message is not necessarily broadcast by all cells within the geographical area. When two messages are received with identical Serial Numbers/Message Identifiers in two different cells, the Geographical Scope may be used to determine if the messages are indeed identical. The coding of this field that indicates the scope of the message is:

CODE DISPLAY MODE GEOGRAPHICAL SCOPE 00 Immediate Cell wide 01 Normal PLMN wide

Octet 1 Octet 2

GS Message Code Update Number

7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0

24 DN9814202Issue 14-1

Cell Broadcast



10 Normal Location Area wide 11 Normal Cell wide

Immediate = default direct display Normal = default display under user interaction

NOTE: Code 00 is intended for use by the network operators for base station IDs.

The update number differentiates between older and newer versions of the same message, within the indicated geographical area. A new message has update number 0000; which is incremented by 1 for each update. Any update number eight or lower (module 16) than the last received update number is considered as more recent, and is treated as a new message, provided the mobile has not been switched off.

2. The Message Identifier identifies the source and type of message. A number of messages may originate from the same source and/or be of the same type. Such messages are distinguished by a serial number. The Message Identifier is coded in binary.The use/application of the Message Identifiers is as follows:

0000 - 03E7 (hex) to be allocated by PLMN operator associations. These values are transmitted by the BSC.03E8 - 0FFF (hex) intended for standardisation in future versions of 3GPP TS 23.041. These values are not transmitted by the BSC.

1000 - 10FF (hex) intended for Data Download to the SIM (see 3GPP TS 23.041). These values are transmitted by the BSC.

Note: Message identifiers in the range 0000 - 03E7 (hex) can also be used for Cell Broadcast Data Download to the SIM.

1100 - FFFE (hex) intended for standardisation in future versions of 3GPP TS 23.041. These values are not transmitted by the BSC.

FFFF (hex) Not supported.In the list above, octet 3 of the Message Identifier is shown first, followed by octet 4. Thus '1234' (hex) represents octet 3 = 0001 0010 and octet 4 = 0011 0100.

3. The Data Coding Scheme indicates the intended handling of the message at the MS, the alphabet/coding, and the language (when applicable). This is defined in 3GPP TS 23.038 Alphabets and language-specific information, which is fully sup-ported by the BSC.

4. The page parameter is coded as two 4-bit fields. The first field (bits 0-3) indicates the binary value of the total number of pages in the message and the second field (bits 4-7) indicates the binary value of the page number within that sequence. The coding starts at 0001, with 0000 reserved.

DN9814202Issue 14-1

25



Cell Broadcast Data Coding SchemeThe Cell Broadcast Data Coding Scheme indicates the intended handling of the message at the MS, the alphabet/coding, and the language (when applicable). Any reserved codings are assumed to be the default alphabet (the same as codepoint 0000 1111) by a receiving entity. The octet is used according to a coding group which is indi-cated in bits 7 - 4. The octet is then coded as follows:

Figure 20 Data Coding Scheme

Coding GroupBits7 - 4 Use of bits 3 - 0

0000

0001

language indication0000 Default alphabet; message preceded by

Language using the default alphabetUnspecified handling at the MS

0001 UCS2; message preceded by language indication

0010 - 1111 Reserved for European languages

The message starts with a two 7-bit defaultalphabet character representation of thelanguage encoded according to ISO 639.This is padded to the octet boundary withtwo bits set to 0 and then followed by 40characters of UCS2-encoded message.Older mobiles will display the two-charac-ter language identifier and then an appar-ently random string of characters.

The first 3 characters of the message area two-character representation of thelanguage encoded according to ISO 639,followed by a CR character. The CR charac-ter is then followed by 90 characters oftext. Older mobiles will overwrite thestart of the message up to the CR and pre-sent only the text.

GermanEnglishItalianFrenchSpanishDutchSwedishDanishPortugueseFinnishNorwegianGreekTurkishReserved for European languagesLanguage unspecified

Bits 3 - 0 indicate the language:00000001001000110100010101100111100010011010101111001101 - 11101111

26 DN9814202Issue 14-1

Cell Broadcast



Figure 21 Data Coding Scheme continued

Figure 22 Data Coding Scheme continued

These codings can also be used for USSD and MMI/display purposes.

Coding GroupBits7 - 4 Use of bits 3 - 0

0010 - 0011

01xx

Bits 3 and 2 indicate the alphabet being used, as follows:

Reserved for European languages using the defaultalphabet, with unspecified handling at the MS

0 1

01

11

Bit 10

Bit 00

Bit 30011

Bit 20101

Bit 4, if set to 0, indicates that bits 1 to 0 arereserved and have no message class meaning.Bit 4, if set to 1, indicates that bits 1 to 0 have amessage class meaning:

Bit 5, if set to 0, indicates the text is uncompressed.Bit 5, if set to 1, indicates the text is compressedusing the GSM standard compressing algorithm.(yet to be specified)

General Data Coding indicationBits 5 - 0 indicate the following:

Message Class:Class 0 (direct display, no memory

required in MS)Class 1 Default meaning:ME-specific. (direct display,

memory required in MS)Class 2 SIM-specific message.Class 3 Default meaning:TE-specific (see GSM TS 07.05)

Alphabet:Default alphabet8 bitUCS2 (16 bit)Reserved

Use of bits 3 - 0

1000 - 1110 Reserved coding groups

1111 Data coding / message handling

Bit 3 is reserved, set to 0.

Message coding:Default alphabet8-bit data

Message Class:No message class. (= Class 0)Class 1 user-defined.Class 2 user-defined.Class 3default meaning: TE-specific(see 3GPP TS 07.05)

Bit 00101

Coding GroupBits7 - 4

Bit 201

Bit 10011

DN9814202Issue 14-1

27



Messages using the default alphabet are coded with the 7-bit alphabet given in subsec-tion 6.2.1 of 3GPP TS 03.41 Technical Realization of Short Message Service - Cell Broadcast. The message then consists of 93 user characters.

Messages using 8-bit data have user-defined coding, and are 82 octets in length.

UCS2 alphabet indicates that the message is coded in UCS2. The General notes spec-ified in subsection 6.1.1 of 3GPP TS 03.41 Technical Realization of Short Message Service - Cell Broadcast override any contrary specification in UCS2. For example, even in UCS2, a <CR> character causes the MS to return to the beginning of the current line and overwrite any existing text with the characters that follow the <CR>. Messages encoded in UCS2 consist of 41 characters.

Class 1 and Class 2 messages may be routed by the mobile equipment (ME) to user-defined destinations, but the users may override the default meaning and select their own routing.

Class 3 messages will normally be selected for transfer to a TE, in cases where an ME supports an SMS/CBS interface to a TE, and the TE requests 'TE-specific' cell broad-cast messages (see 3GPP TS 07.05). Users may be able to override the default meaning and select their own routing.

All coding groups are supported by MMI and the CBC interface.

28 DN9814202Issue 14-1

Cell Broadcast


User interface of Cell Broadcast

5 User interface of Cell BroadcastMML commandsThe following MML command groups and commands are related to Cell Broadcast:

• EC - SMS Cell Broadcast Handling • ER - Transceiver Handling: the CBCH is configured to the cell with the ERM

command. • EQ - Base Transceiver Station Handling in BSC: the cell broadcast facility is set on

to the cell with the EQM command. The facility bit prevents the broadcast of mes-sages.

• WO - Parameter Handling: the WOC command is used for handling functionality-specific control parameters.

• QD - OSI Environment Application Data Handling: The local and remote OSI appli-cations must be created using the MMLs of this command group, to make commu-nication available between a Transport Pipe User (TPU), that is, CBS application, and remote Connection-Oriented Transport Service (COTS) user, that is, remote CBS application in the CBC. The corresponding OSI applications and addresses must be configured to the remote system according to the instructions of the remote system.When you use the CBC connection, you can only use the output commands in the EC command group.

For more information, see Technical description of Cell Broadcast.

ParametersCell Broadcast-specific control parameters:

• SMS_CBC_USD_IN_BSC: defines whether the BSC supports the BSC-CBC interface • SMSCB_INDEPEN_MULTIPAGE

• SMSCB-LAST_BLOCK_INFO: controls whether Last Block information is sent to the mobile or not. The Last Block information signals to the MS the last block (from the four blocks in the air interface) containing useful information.

• CBC_INDIC_FILT_TIMER

For a description of the parameters, see PRFILE and FIFILE Parameter List under Ref-erence.

CountersTransmitted CB and schedule messages in the TRX can be found in the counter 003003 SMS BC REQUEST MESSAGES SENT TO BTS.

For more information, see 3 Resource Access Measurement under Reference.

AlarmsThe alarm 2988 EXCESSIVE ERRORS IN CBC-CONNECTION indicates failures in the data transmission from the BSC to the CBC. The alarm is raised when the error ratio of transmission in the CBC interface exceeds the permitted limit.

The alarm is cancelled when the error ratio is again within permitted limits.

For more information, see Failure Printouts (2000-3999) under Reference.

Cell Broadcast

Documents

Transcript of Cell Broadcast