Digital cellular telecommunications system (Phase 2+) (GSM); Technical realization of Short Message Service Cell Broadcast (SMSCB) (GSM 03.41 version 5.8.1)

RE/SMG-040341QR6

Digitalni celični telekomunikacijski sistem (faza 2+) – Tehnična realizacija storitve kratkih sporočil (SMS) – Izvedba s celično radiodifuzijo (SMSCB) (GSM 03.41, različica 5.8.1)

General Information

Status
Published
Publication Date
16-Jun-1998
Technical Committee
Current Stage
12 - Completion
Due Date
19-Jun-1998
Completion Date
17-Jun-1998
Standard
ETS 300 902 E4:2003
English language
30 pages
sale 10% off
Preview
sale 10% off
Preview
e-Library read for
1 day

Standards Content (Sample)


SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHP ID]D ±7HKQLþQDUHDOL]DFLMDVWRULWYH
NUDWNLKVSRURþLO 606 ±,]YHGEDVFHOLþQRUDGLRGLIX]LMR 606&%  *60
UD]OLþLFD
Digital cellular telecommunications system (Phase 2+) (GSM); Technical realization of
Short Message Service Cell Broadcast (SMSCB) (GSM 03.41 version 5.8.1)
Ta slovenski standard je istoveten z: ETS 300 902 Edition 4
ICS:
33.070.50 Globalni sistem za mobilno Global System for Mobile
telekomunikacijo (GSM) Communication (GSM)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN ETS 300 902
TELECOMMUNICATION June 1998
STANDARD Fourth Edition
Source: SMG Reference: RE/SMG-040341QR6
ICS: 33.020
Key words: Digital cellular telecommunications system, Global System for Mobile communications (GSM)
R
GLOBAL SYSTEM FOR
MOBILE COMMUNICATIONS
Digital cellular telecommunications system (Phase 2+);
Technical realization of
Short Message Service Cell Broadcast (SMSCB)
(GSM 03.41 version 5.8.1)
ETSI
European Telecommunications Standards Institute
ETSI Secretariat
Postal address: F-06921 Sophia Antipolis CEDEX - FRANCE
Office address: 650 Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE
Internet: secretariat@etsi.fr - http://www.etsi.fr - http://www.etsi.org
Tel.: +33 4 92 94 42 00 - Fax: +33 4 93 65 47 16
Copyright Notification: No part may be reproduced except as authorized by written permission. The copyright and the
foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 1998. All rights reserved.

Page 2
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
Whilst every care has been taken in the preparation and publication of this document, errors in content,
typographical or otherwise, may occur. If you have comments concerning its accuracy, please write to
"ETSI Editing and Committee Support Dept." at the address shown on the title page.

Page 3
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
Contents
Foreword .5
1 Scope .7
1.1 Normative references .7
1.2 Abbreviations .7
2 General description .8
3 Network Architecture.9
4 CBE Functionality.9
5 CBC Functionality.9
6 BSC Functionality.10
7 BTS Functionality .10
8 MS Functionality.11
9 Protocols and Protocol Architecture.11
9.1 CBC-BSC Primitives .13
9.1.1 Identification of a message .13
9.1.2 WRITE-REPLACE Request/Indication.14
9.1.3 KILL Request/Indication .16
9.1.4 REPORT Response/Confirm .16
9.1.5 STATUS-CBCH-QUERY Request/Indication.16
9.1.6 STATUS-CBCH-QUERY Response/Confirm.16
9.1.7 STATUS-MESSAGE-QUERY Request/Indication .17
9.1.8 STATUS-MESSAGE-QUERY Response/Confirm .17
9.1.9 REJECT Response/Confirm .17
9.1.10 RESTART-INDICATION Request/Indication.17
9.1.11 RESET Request/Indication.18
9.1.12 FAILURE-INDICATION Request/Indication .18
9.1.13 SET-DRX Request/Indication.18
9.1.14 SET-DRX- REPORT Response/Confirm .19
9.2 Parameters .19
9.2.1 Message-Identifier.19
9.2.2 Old-Serial-Number .19
9.2.3 New-Serial-Number.19
9.2.4 Number-of-Pages.19
9.2.5 Cell-List .19
9.2.5.1 Cell-List sent from CBC to BSC.20
9.2.5.2 Cell-List sent from BSC to CBC.20
9.2.6 Channel Indicator .20
9.2.7 Category.20
9.2.8 Repetition-Period.20
9.2.9 No-of-Broadcasts-Requested.21
9.2.10 No-of-Broadcasts-Completed-List.21
9.2.11 Cell-Identifier .21
9.2.12 Schedule-Period.22
9.2.13 Reserved-Slots.22
9.2.14 Failure-List.22
9.2.15 CBCH-Loading-List .22
9.2.16 Cause .23
9.2.17 Diagnostic.23

Page 4
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
9.2.18 Data Coding Scheme. 23
9.2.19 CBS-Message-Information-Page n. 24
9.2.20 CBS-Message-Information-Length n . 24
9.2.21 Recovery-Indication . 24
9.3 Message Format on BTS-MS Interface . 24
9.3.1 General Description. 24
9.3.2 Message Content. 24
9.4 CBS Compression. 27
10 SMSCB Index . 27
Annex A (informative): Protocols for interconnecting CBC and BSC . 29
History. 30

Page 5
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
Foreword
This European Telecommunications Standard (ETS) has been produced by the Special Mobile Group
(SMG) of the European Telecommunications Standards Institute (ETSI).
This ETS defines the Cell Broadcast short message service (CBS). It defines the primitives over the Cell
Broadcast Centre - Base Station System (CBC-BSS) interface and the message formats over the Base
Station System - Mobile Station (BSS-MS) interface for Teleservice 23 within the digital cellular
telecommunications system (Phase 2+).
The contents of this ETS is subject to continuing work within SMG and may change following formal SMG
approval. Should SMG modify the contents of this ETS, it will be resubmitted for OAP by ETSI with an
identifying change of release date and an increase in version number as follows:
Version 5.x.y
where:
y the third digit is incremented when editorial only changes have been incorporated in the
specification;
x the second digit is incremented for all other types of changes, i.e. technical enhancements,
corrections, updates, etc.
Transposition dates
Date of adoption of this ETS: 5 June 1998
Date of latest announcement of this ETS (doa): 30 September 1998
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 March 1999
Date of withdrawal of any conflicting National Standard (dow): 31 March 1999

Page 6
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
Blank page
Page 7
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
1 Scope
This European Telecommunications Standard (ETS) describes the Cell Broadcast short message service
(CBS). It defines the primitives over the Cell Broadcast Centre - Base Station System (CBC-BSS)
interface and the message formats over the Base Station System - Mobile Station (BSS-MS) interface for
Teleservice 23 as specified in GSM 02.03 [2].
1.1 Normative references
This ETS incorporates by dated and undated reference, provisions from other publications. These
normative references are cited at the appropriate places in the text and the publications are listed
hereafter. For dated references, subsequent amendments to or revisions of any of these publications
apply to this ETS only when incorporated in it by amendment or revision. For undated references, the
latest edition of the publication referred to applies.
[1] GSM 01.04 (ETR 350): "Digital cellular telecommunication system (Phase 2+);
Abbreviations and acronyms".
[2] GSM 02.03 (ETS 300 905): "Digital cellular telecommunication system
(Phase 2+); Teleservices supported by a GSM Public Land Mobile Network
(PLMN)".
[3] GSM 03.38 (ETS 300 900): "Digital cellular telecommunication system
(Phase 2+);"Alphabets and language-specific information".
[4] GSM 03.40 (ETS 300 901): "Digital cellular telecommunication system
(Phase 2+); Technical realization of the Short Message Service (SMS) Point to
Point (PP)".
[5] GSM 03.47 (ETR 354): "Digital cellular telecommunication system; Example
protocol stacks for interconnecting Service Centre(s) (SC) and Mobile-services
Switching Centre(s) (MSC)".
[6] GSM 03.49: "Digital cellular telecommunication system (Phase 2+); Example
protocol stacks for interconnecting Cell Broadcast Centre (CBC) and Mobile-
services Switching Centre (MSC)".
[7] GSM 04.12 (ETS 300 943): "Digital cellular telecommunication system
(Phase 2+); Short Message Service Cell Broadcast (SMSCB) support on the
mobile radio interface".
[8] GSM 05.02 (ETS 300 908): "Digital cellular telecommunication system
(Phase 2+); Multiplexing and multiple access on the radio path".
[9] GSM 07.05: "Digital cellular telecommunication system (Phase 2+); Use of Data
Terminal Equipment - Data Circuit terminating Equipment (DTE - DCE) interface
for Short Message Service (SMS) and Cell Broadcast Service (CBS)".
[10] GSM 08.52: "Digital cellular telecommunication system; Base Station Controller
- Base Transceiver Station (BSC - BTS) interface Interface principles".
[11] GSM 08.58: "Digital cellular telecommunication system (Phase 2+); Base
Station Controller - Base Transceiver Station (BSC - BTS) interface Layer 3
specification".
[12] CCITT Recommendation X.210: "Open systems interconnection layer service
definition conventions".
1.2 Abbreviations
Abbreviations used in this ETS are listed in GSM 01.04 [1].

Page 8
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
2 General description
The CBS service is analogous to the Teletex service offered on television, in that like Teletex, it permits a
number of unacknowledged general messages to be broadcast to all receivers within a particular region.
CBS messages are broadcast to defined geographical areas known as cell broadcast areas. These areas
may comprise of one or more cells, or may comprise the entire PLMN. Individual CBS messages will be
assigned their own geographical coverage areas by mutual agreement between the information provider
and the PLMN operator. CBS messages may originate from a number of Cell Broadcast Entities (CBEs),
which are connected to the Cell Broadcast Centre. CBS messages are then sent from the CBC to the
BTSs, in accordance with the CBS's coverage requirements.
The CBS message comprises of 82 octets, which, using the default character set, equates to
93 characters. Up to 15 of these messages (pages) may be concatenated to form a macromessage. Each
page of such macromessages will have the same message identifier (indicating the source of the
message), and the same serial number. Using this information, the MS is able to identify and ignore
re-broadcasts of already received messages.
CBS messages are broadcast cyclically by the BTS at a frequency and for a duration specified by the
information provider. The frequency at which messages are repeatedly transmitted will be dependent on
the information that they contain; for example, it is likely that dynamic information such as road traffic
information, will require more frequent transmission than weather information. The repetition period will
also be affected by the desire for messages to be received by high speed mobiles which rapidly traverse
cells. All suitably equipped mobiles within the catchment area of the transmitting BTS will be able to
receive the broadcast messages, provided that they are switched on and in the idle state.
CBS messages may be broadcast on two different cell broadcast channels, which are characterized by
different QoS. A MS is always able to read the basic channel (see [8]). The reading of the extended
channel may collide with other tasks of the MS. Therefore the probability of receiving a CBS message on
the extended channel is smaller than on the basic channel. The reading of the extended channel for MSs
is optional. The scheduling on the channels will be done independently.
To permit mobiles to selectively display only those messages required by the MS user, CBS messages
are assigned a message class which categorises the type of information that they contain and the
language in which the message has been compiled. Through the use of appropriate MMI, the user is then
able to ignore message types that he does not wish to receive, e.g. advertising information or messages
in an unfamiliar language.
Page 9
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
3 Network Architecture
The basic network structure of CBS is depicted by figure 1.
outside scope of GSM Specs. inside scope of GSM Specs.
BTSs
3 4
MSs
1 3 4
CBE
2 MSs
BSC
CBC 3 4
MSs
CBE 1 2
Figure 1
- message transfer on link 1 is outside the scope of GSM Specifications;
- message transfer on link 2 is described in Section 9.1;
- message transfer on link 3 is described in GSM 08.58;
- message transfer on link 4 is described in GSM 04.12 and the timing of messages transferred on
link 4 is described in GSM 05.02.
4 CBE Functionality
The functionality of the CBE is outside of the scope of GSM Specifications; however it is assumed that the
CBE is responsible for all aspects of formatting CBS, including the splitting of a CBS message into a
number of pages.
5 CBC Functionality
As the CBC (and any originating point for cell broadcast short messages) is regarded as a node outside
the PLMN, only the requirements placed upon the CBC by CBS functionality are specified by this
specification.
The CBC may be connected to several BSCs. The CBC may be connected to several CBEs. The CBC
shall be responsible for the management of cell broadcast short messages including:
- allocation of serial numbers;
- modifying or deleting messages held by the BSC;
- initiating broadcast by sending fixed length cell broadcast short messages to a BSC for each
language provided by the cell, and where necessary padding the message with the appropriate
character to a length of 82 octets;
- determining the set of cells/BTSs to which a message should be broadcast, and indicating within
the Serial Number the geographical scope of each message;
- determining the time at which a message should commence being broadcast;

Page 10
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
- determining the time at which a message should cease being broadcast and subsequently
instructing each BSC to cease broadcast of the message;
- determining the period at which broadcast of the message should be repeated;
- determining the cell broadcast channel, on which the message should be broadcast.
To work efficiently on the interfaces, the BSC - which is normally controlling more than one cell of a
broadcast area - should be used as a concentrator as far as CB message handling is concerned. Hence,
the CBC should work on lists of cells when issuing CB related requests towards the BSC.
6 BSC Functionality
The BSC shall interface to only one CBC. A BSC may interface to several BTSs as indicated by
GSM 08.52. The BSC shall be responsible for:
- interpretation of commands from the CBC;
- storage of cell broadcast messages;
- scheduling of cell broadcast messages on the CBCH;
- providing an indication to the CBC when the desired repetition period cannot be achieved;
- providing to the CBC acknowledgement of successful execution of commands received from the
CBC;
- reporting to the CBC failure when a command received from the CBC is not understood or cannot
be executed;
- routing cell broadcast messages to the appropriate BTSs;
- transferring CBS information to each appropriate BTS via a sequence of 4 SMS BROADCAST
REQUEST messages or 1 SMS BROADCAST COMMAND message (see GSM 08.58), indicating
the channel which shall be used.
- optionally generating Schedule Messages, indicating the intended schedule of transmissions (see
GSM 04.12);
- optionally receiving CBCH Load Indication messages and reacting by broadcasting a burst of
scheduled SMSCB messages or by suspending the broadcast for a period indicated by BTS (see
GSM 08.58);
To work efficiently on the interfaces, the BSC should forward CB related messages to the CBC using cell
lists as far as applicable.
7 BTS Functionality
The BTS is responsible for conveying CBS information received via SMS BROADCAST REQUEST or
SMS BROADCAST COMMAND messages over the radio path to the MS.
- optionally generating CBCH Load Indication messages, indicating an underflow or overflow situation
on the CBCH (see GSM 08.58).
Page 11
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
8 MS Functionality
The MS is responsible for recombination of the blocks received via the radio path to reconstitute the cell
broadcast short message. The precise method of display of cell broadcast short messages is outside the
scope of GSM Specifications, however it is assumed that an MS will:
- discard sequences transferred via the radio path (see GSM 04.12) which do not consist of
consecutive blocks;
- have the ability to discard CBS information which is not in a suitable data coding scheme;
- have the ability to discard a message which has a message identifier indicating that it is of subject
matter which is not of interest to the MS;
- have the ability to ignore repeat broadcasts of messages already received (message has not
changed since it was last broadcast i.e. sequence number has not changed within the message's
indicated geographical area);
- have the ability to transfer a message via the R interface when the R interface is supported;
- optionally enter SMSCB DRX mode based upon received Schedule Messages (see GSM 04.12);
- optionally skip reception of the remaining block(s) of a cell broadcast message which do(es) not
contain cell broadcast information (see GSM 04.12);
- optionally read the extended channel.
9 Protocols and Protocol Architecture
Commands interpreted by the BSC will result in a sequence of 4 SMS BROADCAST REQUEST
messages or 1 SMS BROADCAST COMMAND message being sent to a BTS, which in turn result in a
sequence of 4 messages being transferred via the BTS-MS interface (see GSM 04.12).
With the SMS BROADCAST REQUEST mode of operation, the 88 octet fixed length CBS page which is
specified in Section 9.3 is split into four 22 octet blocks which are carried in SMS BROADCAST
REQUEST messages as follows:
st
octets 1-22 are transferred in the 1 SMS BROADCAST REQUEST
with a sequence number (see GSM 04.12) indicating first block
nd
octets 23-44 are transferred in the 2 SMS BROADCAST REQUEST
with a sequence number (see GSM 04.12) indicating second block
rd
octets 45-66 are transferred in the 3 SMS BROADCAST REQUEST
with a sequence number (see GSM 04.12) indicating third block
th
octets 67-88 are transferred in the 4 SMS BROADCAST REQUEST
with a sequence number (see GSM 04.12) indicating fourth block.
Figure 2 illustrates the protocol architecture and the scope of the various GSM Specifications for the SMS
BROADCAST REQUEST mode of operation.

Page 12
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
GSM 03.41
GSM 03.41 Section 9.3
Section 9.1
GSM 08.58 GSM 04.12
CBC BSC BTS MSs
Write-Replace
SMS BROADCAST REQUEST 1
Report-Success
SMS BROADCAST REQUEST 2
SMS BROADCAST REQUEST 3
SMS BROADCAST REQUEST 4
Figure 2
With the SMS BROADCAST COMMAND mode of operation, the BSC sends to the BTS in one single
message the 88 octet fixed length CBS page. The BTS then splits the page into four 22 octet blocks, adds
the sequence number (see GSM 04.12) and transmits the four resulting blocks on the air.
Figure 3 illustrates the protocol architecture and the scope of the various GSM Specifications for the SMS
BROADCAST COMMAND mode of operation.

Page 13
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
GSM 03.41
GSM 03.41 Section 9.3
Section 9.1
GSM 08.58 GSM 04.12
CBC BSC BTS MSs
Write-Replace
SMS BROADCAST COMMAND
Report-Success
Figure 3
9.1 CBC-BSC Primitives
The term primitive is used to indicate "an abstract, implementation independent interaction between a
service user and a service provider" (see CCITT X.210). For the CBC-BSC interface, the service provider
would be the protocol interconnecting CBC and BSC. A Primitive may therefore be viewed as an abstract,
implementation independent request/indication or response/confirm interaction between the service user
(CBC or BSC) and the service provider (protocol). A set of primitives for use between the CBC and BSC is
specified appropriate to the functionality assigned to the CBC and BSC in Sections 5 and 6. In order to
allow future extensions to the primitives, where possible a primitive shall not be rejected because a
parameter is not recognised; the recipient shall ignore the parameter in question and process the
remainder of the primitive’s parameters as usual. No mandatory protocol between the CBC and the BSC
is specified by GSM, this is a matter of agreement between CBC and PLMN operators. GSM 03.49 (see
also annex A of this ETS) provides example protocol stacks using the primitives defined as follows.
NOTE: In the following definitions, M indicates "mandatory parameter" and O indicates
"optional parameter".
9.1.1 Identification of a message
Within a CBC-BSC interface, a message is uniquely identified by the quartet (message_identifier,
serial_number, Cell Identifier, Channel Indicator). This means that even when two messages have the
same semantic containts (for example the same weather forecast) but in different languages or coding
schemes, they are considered as different and must therefore be identified by a different quartet.
The serial number is managed cyclically and therefore this does not prevent the re-use of the same
quartet for a different message when the serial number have been incremented a sufficient number of
times. How to manage the ambiguity is described subsequently.
This unique identification of a message across the CBC-BSC interface is used in all the primitives defined
hereafter. This means that the quartet will be implicitly or explicitly present in every interface primitive
which applies to a given message.

Page 14
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
This unique quartet will be referred in the rest of the document as the « message reference ».
9.1.2 WRITE-REPLACE Request/Indication
PARAMETER REFERENCE PRESENCE
Message-Identifier 9.2.1 M
Old-Serial-Number 9.2.2 O
New-Serial-Number 9.2.3 M
Cell-List 9.2.5.1 M
Channel Indicator 9.2.6 O
Category 9.2.7 O
Repetition-Period 9.2.8 M
No-of-Broadcasts-Requested 9.2.9 M
Number-of-Pages 9.2.4 M
Data Coding Scheme 9.2.18 M
CBS-Message-Information-Page 1 9.2.19 M
CBS-Message-Information-Length 1 9.2.20 M
CBS-Message-Information-Page 2 9.2.19 O
CBS-Message-Information-Length 2 9.2.20 O
::
CBS-Message-Information-Page n 9.2.19 O
CBS-Message-Information-Length n 9.2.20 O
This primitive is sent by the CBC to the BSC. As this primitive can be used either to broadcast a new
message or replace a message already broadcast, the CBC will use the presence and content of the Old-
Serial-Number and New-Serial-Number fields in this primitive to instruct the BSC as follows:-
- Old-Serial-Number not present/New-Serial-Number present
This is a write request which will be interpreted by the BSC as an instruction to broadcast a new
message in all the cells of the Cell list and on the channel derived by the Channel Indicator (see the
section on parameters that describes the implicit value of the Channel Indicator when not present in
the message). The following table identifies the BSC’s behaviour:
Success/Failure of write BSC behaviour
request
The BSC completes the following parameters to be returned in the
Report PDU:
Success
• a ‘0’ value is entered in the number of broadcasts completed list
for the cell
• no entry is made in the failure list for the cell
The BSC completes the following parameters to be returned in the
Report PDU:
• no entry is made in the number of broadcasts completed list for
Failure the cell
• an entry is made in the failure list for the new message
identifying the failure cause for the cell
The BSC will build as many message references as the number of cells in the list. These message
references will be used in particular in the subsequent primitives.
When a message reference is already known by the BSC for certain cells in the list (even if the
Update field of the Serial-Number is different), the primitive will be rejected with the cause
« message reference already used ». The list of cells where the message reference is not valid will

Page 15
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
be provided in the REPORT message. No entry will be made in the number of broadcasts
completed parameter.
- Old-Serial-Number present/New-Serial-Number present
This is a replace request which will be interpreted by the BSC as a kill request for the message with
the old serial number, followed by a write request for the message with the new serial number. The
handling of the new serial number in the write part of this request, is as described above in the write
request where no Old-Serial-Number is supplied. These two kill and write requests are executed
sequentially. If the kill request is unsuccessful, the BSC does not proceed to execute the write
request. The kill request will stop broadcast of, and cause all information currently associated with
the combination of message identifier, old serial number, Channel Indicator and the list of cells in
the Cell list to be deleted from the cells in the BSC (i.e. for all cells provided in the Cell-List
parameter). If the kill request is successful, the subsequent write request information conveyed in
the primitive replaces the killed message. The following table identifies the BSC’s behaviour:
Success/Failure of kill BSC behaviour
request
The BSC proceeds to execute the write request:
• Write successful: the BSC completes the following parameters
to be returned in the Report PDU:

an entry is made in the number of broadcasts completed
list for the cell
• no entry is made in the failure list for the cell
• Write unsuccessful: the BSC completes the following
parameters to be returned in the Report PDU:
Success
• an entry is made in the number of broadcasts completed
list for the cell
• an entry is made in the failure list for the new message
identifying the failure cause for the cell
The BSC does not proceed to execute the write request, and
completes the following parameters to be returned in the Report
PDU:
Failure • no entry is made in the number of completed broadcasts list
• an entry is made for the old message in the failure list
identifying the failure cause for the cell
All cells which should perform the broadcasting are mentioned in the Cell-List parameter.
The broadcast of the referenced message in the cells which are not mentioned in the Cell-List remains
unaffected.
If no category is present, the default category is interpreted by the BSC, see the parameter section.
This primitive is responded by a REPORT or REJECT primitive.
NOTE: in the case of multipage messages, the individual pages are considered as
independent by the BSC scheduling algorithm.

Page 16
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
9.1.3 KILL Request/Indication
PARAMETER REFERENCE PRESENCE
Message-Identifier 9.2.1 M
Old-Serial-Number 9.2.2 M
Cell-List 9.2.5.1 M
Channel Indicator 9.2.6 O
This primitive is sent by the CBC to the BSC. The CBC will use this primitive to kill the message indicated
by the combination of message identifier, serial number, Channel Indicator and the cells indicated in the
Cell-List of this KILL request, i.e. the primitive will halt broadcast of the message in the indicated cells and
remove any knowledge of the message from the BSC for these cells. The broadcast of the referenced
message in the cells which are not mentioned in the Cell-List remains unaffected. This primitive is
responded with a REPORT or REJECT primitive.
9.1.4 REPORT Response/Confirm
PARAMETER REFERENCE PRESENCE
Message-Identifier 9.2.1 M
Serial-Number 9.2.2 M
Channel Indicator 9.2.6 O
No-of-Broadcasts-Completed-List 9.2.10 O
Failure-List 9.2.14 O
This primitive will be sent by the BSC to the CBC in response to WRITE-REPLACE and KILL primitives.
The Serial-Number field will contain the old serial number if this primitive is sent in response to a KILL
primitive, and the new serial number if the primitive is sent in response to a WRITE-REPLACE primitive.
The No-of-Broadcasts-Completed-List if present, may contain for each cell the number of broadcasts of
the (replaced or killed) CB message with the old message reference sent to this particular cell for
broadcast. The serial number information element in the case of a WRITE-REPLACE does not refer to the
message for which the number of broadcasts completed information is supplied. The Failure-List if
present, may contain those cells which were present in the related WRITE-REPLACE or KILL primitive
and failed the requested operation.
9.1.5 STATUS-CBCH-QUERY Request/Indication
PARAMETER REFERENCE PRESENCE
Cell-List 9.2.5.1 M
Channel Indicator 9.2.6 O
This primitive is sent by the CBC to the BSC in order to obtain the current loading of the CBCH of
particular cells referenced in the Cell-List parameter. This primitive is responded by a STATUS-CBCH-
QUERY Response/Confirm or a REJECT primitive.
9.1.6 STATUS-CBCH-QUERY Response/Confirm
PARAMETER REFERENCE PRESENCE
CBCH-Loading-List 9.2.15 O
Failure-List 9.2.14 O
Channel Indicator 9.2.6 O
This primitive will be sent by the BSC in response to the STATUS-CBCH-QUERY Request/Indication
primitive.
The CBCH-Loading-List, if present, may contain each cell which successfully performed the requested
operation and for each of these cells the CBCH loading of this particular cell. (Note that for cells with DRX
the load caused by the schedule messages will be included in the CBCH load). The CBCH-Loading-List
will not be present if all cells indicated in the related STATUS-CBCH-QUERY Request/Indication failed the
requested operation.
Page 17
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
The Failure-List, if present, may contain all cells for which the requested operation failed (e.g. because the
cells CBCH is not available). The STATUS-CBCH-QUERY Response/Confirm will not contain the
Failure-List parameter if none of the cells in the Cell-List of the related STATUS-CBCH-QUERY Request
failed the requested operation.
9.1.7 STATUS-MESSAGE-QUERY Request/Indication
PARAMETER REFERENCE PRESENCE
Message-Identifier 9.2.1 M
Old-Serial-Number 9.2.2 M
Cell-List 9.2.5.1 M
Channel Indicator 9.2.6 O
This primitive is sent by the CBC to the BSC in order to obtain the current status of a CB-message for the
cells referenced in the Cell-List parameter. This primitive is responded by the STATUS-MESSAGE-
QUERY Response/Confirm or by a REJECT Response/Confirm.
9.1.8 STATUS-MESSAGE-QUERY Response/Confirm
PARAMETER REFERENCE PRESENCE
Message-Identifier 9.2.1 M
Old-Serial-Number 9.2.2 M
No-of-Broadcasts-Completed-List 9.2.10 O
Failure-List 9.2.14 O
Channel Indicator 9.2.6 O
This primitive will be sent by the BSC to the CBC in response to a STATUS-MESSAGE-QUERY
Request/Indication primitive.
The No-of-Broadcasts-Completed-List, if present, may contain each cell which successfully performed the
requested operation and for each of these cells the number of times this CB message has been sent to
this particular cell for broadcast (parameter Number-of-Broadcasts-Completed; this parameter is not
included for the cell if the old message reference is not known to the BSC, and an entry is made in the
failure list). The No-of-Broadcasts-Completed-List will not be present if all cells indicated in the related
STATUS-MESSAGE-QUERY Request failed the requested operation.
The Failure-List may contain all cells for which the requested operation failed (e.g. because the broadcast
of the requested message was never requested before or because the cells CBCH is not available). The
STATUS-MESSAGE-QUERY Response/Confirm will not contain the Failure-List parameter if none of the
cells in the Cell-List of the related STATUS-MESSAGE-QUERY Request failed the requested operation.
9.1.9 REJECT Response/Confirm
PARAMETER REFERENCE PRESENCE
Cause 9.2.16 M
Diagnostic 9.2.17 O
Message-Identifier 9.2.1 O
Serial Number 9.2.2 O
This primitive is sent by the BSC to the CBC in response to any primitive which is not understood (e.g.
invalid parameter or parameter value).
9.1.10 RESTART-INDICATION Request/Indication
PARAMETER REFERENCE PRESENCE
Cell-List 9.2.5.2 M
Recovery Indication 9.2.20 O
The RESTART-INDICATION Request is used by the BSC to indicate to the CBC a CB related restart
situation in one or more of its cells (e.g. when an existing or a new cell becomes operational during normal
BSC operation or when the BSC initialises).

Page 18
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
Any referenced cell are again in CB-operational state (have resumed CB operation). The parameter
Recovery Indication, if present, indicates whether CB related data are lost for the cells referenced in the
Cell-List and have to be re-loaded. If the Recovery Indication parameter is absent, the CBC shall interpret
it as the Recovery Indication with the value data lost.
The CBC upon receiving a RESTART INDICATION indication, marks the cell as operational again. It will
usually generate WRITE-REPLACE requests for this cell, according to the actual CB message loading at
the moment of the restart.
Note that a RESTART INDICATION indication may be triggered from the CBC by a RESET Request. This
allows to recover from situations, where a PDU occasionally may be lost.
9.1.11 RESET Request/Indication
PARAMETER REFERENCE PRESENCE
Cell-List 9.2.5.1 M
The RESET Request is used by the CBC to force one or more cells (BTSs) of one BSC into CB-idle state.
The RESET Request may also be used by the CBC to ask for the CB operational state of cells earlier
indicated to have failed (polling CB operational state).
If a base station controller (BSC) receives a RESET Indication, the indicated cells enter idle state (same
state as after "power on"). All CB related information concerning earlier CB messages in a referenced cell
is lost.
The BSC acknowledges the RESET Indication for each cell by an RESTART- or, if not adequate, by a
FAILURE-INDICATION request.
Of course, several responses may be combined using a cell list in the RESTART or FAILURE
INDICATION.
9.1.12 FAILURE-INDICATION Request/Indication
PARAMETER REFERENCE PRESENCE
Cell-List 9.2.5.2 M
The FAILURE-INDICATION Request is used by the BSC to indicate to the CBC a CB related problem
situation in one or more of its cells.
Any referenced cell enters CB-not-operational state. The status of the CB messages is undefined until the
Restart-Indication is sent. It remains in not-operational state until a RESTART-INDICATION request (see
9.1.10) indicates normal CB operation (again).
The CBC upon receiving a FAILURE indication, marks this cell as failed. It will generally not generate
further WRITE-REPLACE requests for this cell, up to the point, when the CBC is informed by a RESTART
indication, that the cell has resumed CB operation.
The BSC refuses further WRITE-REPLACE requests from the CBC with the cause “cell-broadcast-not-
operational” when any referenced cell is in the CB-not-operational state.
Note, that a Failure-Indication may be triggered by a RESET Request. This allows to recover from
situations, where a PDU occasionally may be lost.
9.1.13 SET-DRX Request/Indication
PARAMETER REFERENCE PRESENCE
Cell-List 9.2.5.1 M
Schedule-Period 9.2.12 O
Reserved-Slots 9.2.13 O
Channel Indicator 9.2.6 O
Page 19
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
The SET-DRX Request is used by the CBC to set DRX specific parameters i.e. the schedule period and
the number of slots reserved for high priority messages, see GSM 04.12. At least one of the Schedule-
Period or Reserved-Slots parameters must be present in the primitive. If this primitive is not supported,
the BSC may use default values.
If a base station controller (BSC) receives a SET-DRX Indication, the new DRX parameters will be taken
into account starting from the next schedule period in each cell, see GSM 04.12.
If a BSC receives a SET-DRX Indication, the new DRX parameters will be applied for all cells that do not
handle any broadcast message (null loading).
9.1.14 SET-DRX- REPORT Response/Confirm
PARAMETER REFERENCE PRESENCE
Cell-List 9.2.5.2 O
Failure-List 9.2.14 O
Channel Indicator 9.2.6 O
This primitive will be sent by the BSC to the CBC in response to a SET-DRX Request/Indication primitive.
The Failure-List will contain those cells which were present in the Request message and which failed the
requested operation.
If the new schedule period parameters are not acceptable on a cell due to the load of the cell, the cause
“bss-capacity-exceeded” is used in the Failure-list.
9.2 Parameters
9.2.1 Message-Identifier
identifies source/type of message.
9.2.2 Old-Serial-Number
This enables a particular existing message, from the source/type indicated by the message identifier, to
be identified.
9.2.3 New-Serial-Number
This enables message change to be indicated since it is altered every time the message is changed. The
serial number identifies a particular message, which may be several pages in length, from the source
indicated by the message identifier.
9.2.4 Number-of-Pages
enables the number of pages in the message to be indicated.
9.2.5 Cell-List
The cell-list identifies a sequence of one or more cells to which the primitives apply.
The cells in the list are described as per section 3.2.2.17 of GSM 08.08 and can be identified by the CBC
or BSC in LAC and CI format or CI format only.
In addition (as described in GSM 08.08) it is possible for the CBC to refer to all cells in a LAC or in a
complete BSC. If supplied, the Cell-List parameter must refer to at least one cell.
Given the above differences between cell identification in the two directions, a cell list sent from the CBC
to the BSC has a different structure compared to a cell list sent from the BSC to the CBC. The different
cell lists are described in sections 9.2.5.1 and 9.2.5.2.

Page 20
ETS 300 902 (GSM 03.41 version 5.8.1): June 1998
9.2.5.1 Cell-List sent from CBC to BSC
The CBC to BSC Cell-List contains a length parameter identifying the number of cell-identifications
present in the list, a Cell-Id-Discriminator, which is common for all cell-identifications in the list, and a
sequence of cell-identifications.
Description of list elements:
PARAMETER PRESENCE
Length M
Cell-Id-Discriminator M
Cell-Identification M
The Cell-Id-Discriminator is described as per section 3.2.2.27 of GSM 08.08 and has one of the following
formats:
- LAC and CI;
- CI only;
- all cells in the BSC belonging to a certain Location Area;
- all cells in the BSC.
The Cell-identification is repeated for each cell included in the list. The Cell-List must refer to at least one
cell.
9.2.5.2 Cell-List sent from BSC to CBC
The BSC to CBC Cell-List contains a sequence of cell-identifiers as defined in 9.2.11. The Cell-List must
contain at least one cell-identifier as defined in 9.2.11.
9.2.6 Channel Indicator
This parameter indicates the CB channel, which shall be used for broadcasting the data.
basic channel;
extended channel (supporting such a channel by the
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...