ETSI ETS 300 949 ed.1 (1997-04)

Digital cellular telecommunications system (Phase 2+) (GSM); Broadcast Call Control (BCC) protocol (GSM 04.69 version 5.0.1)

DE/SMG-030469Q

Digitalni celični telekomunikacijski sistem (faza 2+) – Protokol radiodifuznega klica (BCC) (GSM 04.69, različica 5.0.1)

General Information

• Status: Published
• Publication Date: 11-May-1997
• Technical Committee: SMG 3 - Network Aspects
• Current Stage: 12 - Completion
• Due Date: 18-Apr-1997
• Completion Date: 12-May-1997
• Mandate: UIC
• Ref Project: SIST ETS 300 949 E1:2003 - Digital cellular telecommunications system (Phase 2+) (GSM); Broadcast Call Control (BCC) protocol (GSM 04.69 version 5.0.1)

Standards Content (Sample)

SLOVENSKI STANDARD
01-december-2003
'LJLWDOQLFHOLþQLWHOHNRPXQLNDFLMVNLVLVWHPID]D±3URWRNROUDGLRGLIX]QHJDNOLFD
%&&*60UD]OLþLFD
Digital cellular telecommunications system (Phase 2+) (GSM); Broadcast Call Control
(BCC) protocol (GSM 04.69 version 5.0.1)
Ta slovenski standard je istoveten z: ETS 300 949 Edition 1
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 949
TELECOMMUNICATION April 1997
STANDARD
Source: ETSI TC-SMG Reference: DE/SMG-030469Q
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+);
Broadcast Call Control (BCC) protocol
(GSM 04.69 version 5.0.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
X.400: c=fr, a=atlas, p=etsi, s=secretariat - Internet: [e-mail]
Tel.: [phone] - Fax: [phone]
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 1997. All rights reserved.

Page 2
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
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 949 (GSM 04.69 version 5.0.1): April 1997
Contents
Foreword .5
1 Scope .7
2 Normative references.7
3 Definitions and abbreviations .8
3.1 Definitions .8
3.2 Abbreviations .8
4 Applicability.9
5 Main concepts .9
6 Elementary procedures for Broadcast Call Control.10
6.1 Overview .10
6.1.1 General.10
6.1.2 Broadcast call control states .10
6.1.2.1 Broadcast call control states at the MS side of the
interface.10
6.1.2.1.1 Attributes and Parameters of BCC in
the MS.10
6.1.2.1.2 NULL (U0).11
6.1.2.1.3 MM CONNECTION PENDING (U0.p) .11
6.1.2.1.4 BROADCAST CALL INITIATED (U1).11
6.1.2.1.5 BROADCAST CALL ACTIVE (U2) .11
6.1.2.1.6 BROADCAST CALL PRESENT (U3) .11
6.1.2.1.7 BROADCAST CALL CONNECTION
REQUESTED (U4) .11
6.1.2.1.8 TERMINATION REQUESTED (U5) .11
6.1.2.1.9 RECEIVE MODE ACTIVE (U6) .11
6.1.2.1.10 BCC TIMERS IN THE MS .12
6.1.2.1.11 CONSISTENCY OF PARAMETERS
AND STATES .13
6.1.2.2 BROADCAST CALL CONTROL STATES AT THE
NETWORK SIDE OF THE INTERFACE.13
6.1.2.2.1 NULL (State N0) .13
6.1.2.2.2 BROADCAST CALL INITIATED (N1).13
6.1.2.2.3 BROADCAST CALL ACTIVE (N2) .13
6.1.2.2.4 BROADCAST CALL
ESTABLISHMENT PROCEEDING
(N3).13
6.1.2.2.5 TERMINATION REQUESTED (N4) .13
6.2 Procedures for establishment of a broadcast call.14
6.2.1 Activation of a broadcast call by the network .14
6.2.2 Mobile originated establishment.14
6.2.2.1 Termination during mobile originated establishment.15
6.2.2.2 Abnormal cases.15
6.2.3 Mobile terminating broadcast call establishment in the MS .15
6.3 Procedures during the active state and receive mode active state of a broadcast call .16
6.3.1 Mobile station procedures in the active state .16
6.3.2 Network procedures in the active state .16
6.3.3 Mobile station procedures in the RECEIVE MODE ACTIVE state.16
6.4 Procedures for release, abortion, and termination of a broadcast call .16
6.4.1 Termination procedure .16
6.4.2 Abort and release procedures.17
6.5 Miscellaneous procedures .17

Page 4
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6.5.1 Status procedures. 17
6.5.1.1 Get status procedure . 17
6.5.1.2 Set status procedure. 17
7 Handling of unknown, unforeseen, and erroneous protocol data. 18
7.1 General. 18
7.2 Message too short. 18
7.3 Unknown or unforeseen transaction identifier. 18
7.4 Unknown or unforeseen message type. 18
7.5 Non-semantical mandatory information element errors. 19
7.6 Unknown and unforeseen information elements in the non-imperative message part . 19
7.6.1 Information elements unknown in the message . 19
7.6.2 Out of sequence information elements. 19
7.6.3 Repeated Information elements . 19
7.7 Non-imperative message part errors . 20
7.7.1 Syntactically incorrect optional Information elements. 20
7.8 Messages with semantically incorrect contents . 20
8 Message functional definitions and contents.21
8.1 CONNECT . 22
8.2 GET STATUS. 23
8.2.1 Parameters . 23
8.2.2 Mobile identity . 23
8.3 IMMEDIATE SETUP . 24
8.3.1 Mobile identity . 24
8.4 SET STATUS . 25
8.4.1 Call state. 25
8.4.2 State attributes. 25
8.5 SETUP . 26
8.6 STATUS . 27
8.6.1 Cause 2 . 27
8.6.2 Call state. 27
8.6.3 State attributes. 27
8.7 TERMINATION . 28
8.8 TERMINATION REJECT . 29
8.9 TERMINATION REQUEST. 30
9 Contents of information elements value parts . 31
9.1 General. 31
9.1.1 The context-free syntax description. 31
9.1.2 Description of field contents. 32
9.1.3 Building the bit string of an information element. 32
9.2 Protocol Discriminator .33
9.3 Transaction identifier. 33
9.4 Message Type. 34
9.5 Other information elements. 35
9.5.1 Call Reference. 35
9.5.2 Call state. 36
9.5.3 Cause . 37
9.5.4 Originator indication. 39
9.5.5 Parameters . 40
9.5.6 Spare Half Octet . 40
9.5.7 State attributes. 41
History. 42

Page 5
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
Foreword
This European Telecommunication Standard (ETS) has been produced by the Special Mobile Group
(SMG) Technical Committee (TC) of the European Telecommunications Standards Institute (ETSI).
This ETS specifies the Broadcast Call Control (BCC) protocol within the digital cellular
telecommunications system (Phase 2+).
The contents of this ETS is subject to continuing work within TC-SMG and may change following formal
TC-SMG approval. Should TC-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: 28 March 1997
Date of latest announcement of this ETS (doa): 31 July 1997
Date of latest publication of new National Standard
or endorsement of this ETS (dop/e): 31 January 1998
Date of withdrawal of any conflicting National Standard (dow): 31 January 1998

Page 6
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
Blank page
Page 7
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
1 Scope
This European Telecommunication Standard (ETS) specifies the Broadcast Call Control (BCC) protocol
used by the Voice Broadcast Call Service (VBCS) on the radio interface.
2 Normative references
This ETS incorporates by dated and undated references, 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 telecommunications system (Phase 2+);
Abbreviations and acronyms".
[2] GSM 02.69 (ETS 300 925): "Digital cellular telecommunications system
(Phase 2+); Voice Broadcast Service (VBCS) stage 1".
[3] GSM 03.03 (ETS 300 927): "Digital cellular telecommunications system
(Phase 2+); Numbering, addressing and identification".
[4] GSM 03.67 (ETS 300 932): "Digital cellular telecommunications system
(Phase 2+); enhanced Multi-Level Precedence and Pre-emption service
(eMLPP) - Stage 2".
[5] GSM 03.69 (ETS 300 934): "Digital cellular telecommunications system
(Phase 2+); Voice Broadcast Service (VBCS) stage 2".
[6] GSM 04.06 (ETS 300 938): "Digital cellular telecommunications system
(Phase 2+); Mobile Station - Base Station System (MS - BSS) interface; Data
Link (DL) layer specification"
[7] GSM 04.07 (ETS 300 939): "Digital cellular telecommunications system
(Phase 2+); Mobile radio interface signalling layer 3; General aspects".
[8] GSM 04.08 (ETS 300 940): "Digital cellular telecommunications system
(Phase 2+); Mobile radio interface layer 3 specification".

Page 8
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
3 Definitions and abbreviations
3.1 Definitions
For the purposes of this ETS, the following definitions apply in addition to those listed in GSM 02.69:
attachment of the user connection: See GSM 04.08, subclause 5.2.
broadcast call channel: Downlink channel to be allocated in each cell of the group call area for a
particular broadcast call. All MSs of the listening service subscribers in one cell shall listen to the common
downlink.
broadcast call: Is used in the same sense as "voice broadcast call".
calling user: BCC entity in the Mobile Station (MS) initiating or having initiated a broadcast call.
clearing the context related to the broadcast call establishment: all running BCC timers in the
relevant BCC entity are stopped, all attributes in the relevant BCC entity are deleted.
downlink: Network to MS direction.
group receive mode: See GSM 04.08.
originating mobile station: MS initiating or having initiated the broadcast call.
uplink: Mobile station to network direction.
3.2 Abbreviations
For the purposes of this ETS, the following abbreviation applies in addition to those listed in GSM 01.04.
BCC Broadcast Call Control
Page 9
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
4 Applicability
Support of the broadcast call protocol is optional in the MS and in the network.
5 Main concepts
This ETS describes the broadcast call control (BCC) protocol, which is one of the protocols of the
Connection Management (CM) sublayer (see GSM 04.07).
There is in general more than one MS engaged in a broadcast call. Consequently, there is in general more
than one MS with a BCC entity engaged in the same broadcast call, and there is one BCC entity in the
network engaged in that broadcast call.
Under which conditions a BCC message is passed from lower (sub-)layers to the BCC entity is defined in
the specifications of the sub-layers.
The MS shall ignore BCC messages that it receives which were sent in unacknowledged mode and which
explicitly specify as destination a mobile identity which is not a mobile identity of the MS.
Higher layers and the MM sub-layer decide when to accept parallel BCC transactions and when/whether
to accept BCC transactions in parallel to other CM transactions.
The broadcast call may be initiated by a mobile user or by a dispatcher. Specification of a protocol for
dispatchers is out of the scope of this ETS. Hence, in the scope of this ETS, there are:
- one BCC entity in the network; and
- one or more than one BCC entities in different MSs
engaged in a broadcast call, and one ore none of the MSs is the originator of the broadcast call (called the
originating MS in this ETS).
NOTE: Whereas for the Group Call Control (GCC) protocol (see GSM 04.68), in certain
situations, the GCC entity in a MS assumes to be the originator of a broadcast call
without being the originator, this is not the case for the BCC protocol.
The originator of the BCC transaction chooses the Transaction Identifier (TI). A MS not assuming to be
the originator of the transaction will chose the transaction identifier received from the network, setting the
TI flag to 1+x mod 2 where x is the received TI flag.
This ETS describes the broadcast call control protocol only with regard to two peer entities, one in a MS,
the other one in the network. The call control entities are described as communicating finite state
machines which exchange messages across the radio interface and communicate internally with other
protocol (sub)layers. In particular, the BCC protocol uses the MM and RR sublayer specified in
GSM 04.08. The BCC entity in a MS that is not the originator of the broadcast call shall not send
messages to its peer entity. This description in only normative as far as the consequential externally
observable behaviour is concerned. For simplicity, instead of using the terms "BCC entity in the MS" and
"BCC entity in the network", this ETS often uses the terms "MS" and "network" if no confusion may arise.
Certain sequences of actions of the two peer entities compose "elementary procedures" which are used
as a basis for the description in this ETS. These elementary procedures are defined in clause 6.
The network should apply supervisory functions to verify that the BCC procedures are progressing and if
not, take appropriate means to resolve the problems. This, however, is out of the scope of this ETS.

Page 10
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6 Elementary procedures for Broadcast Call Control
6.1 Overview
6.1.1 General
The elementary procedures may be broadcasted into the following classes:
- broadcast call establishment procedures;
- broadcast call termination procedures;
- broadcast call information phase procedures;
- miscellaneous procedures.
6.1.2 Broadcast call control states
6.1.2.1 Broadcast call control states at the MS side of the interface
The BCC entity of the MS is described as an extended finite state machine. It performs transitions
between states. It has certain parameters and attributes, e.g. configuration parameters and behaviour
parameters, which it sets and changes based on interaction with higher and lower (sub-)layers and on
message exchange with its peer entity. If a configuration parameter is set to a certain value, the MS shall
also adapt the configuration accordingly. Behaviour parameters decide on (part of) the behaviour of the
BCC entity. When the BCC entity in the MS receives a message, it shall first analyse whether it shall
ignore the message, see clauses 5 and 7.
6.1.2.1.1 Attributes and Parameters of BCC in the MS
For the following behaviour parameters, the description is informative.
Parameter Description
ORIG Depending on the context, the MS assumes to be the originator of the call (ORIG=T) or not
to be the originator of the call (ORIG=F).
COMM Depending on the context, the MS assumes that communication with its peer entity is
enabled in both directions (COMM = T) or not (COMM = F).
For the following configuration parameters the MS shall adapt its configuration according to the parameter
value and parameter definition.
Parameter Definition
D-ATT D-ATT = T means that the MS attaches the user connection for the broadcast call in the
downlink.
D-ATT = F means that the MS does not attach the user connection for the broadcast call
in the downlink.
U-ATT U-ATT = T means that the MS attaches the user connection for the broadcast call in the
uplink.
U-ATT = F means that the MS does not attach the user connection for the broadcast call
in the uplink.
Page 11
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6.1.2.1.2 NULL (U0)
No broadcast call exists for the BCC entity. When entering the state, parameters shall be set to the
following values, and configuration shall be adapted to the new values of configuration parameters:
ORIG = F, COMM = F, D-ATT = F, U-ATT = F.
6.1.2.1.3 MM CONNECTION PENDING (U0.p)
The BCC entity has requested the explicit establishment of an MM connection. When entering the state,
parameters shall be set to the following values, and configuration shall be adapted to the new values of
configuration parameters: ORIG = T, COMM = F, D-ATT = F, U-ATT = F.
6.1.2.1.4 BROADCAST CALL INITIATED (U1)
The BCC entity has requested the peer entity in the network to establish a broadcast call. When entering
the state, parameters shall be set to the following values, and configuration shall be adapted to the new
values of configuration parameters: ORIG = T, COMM = T, D-ATT = F, U-ATT = F.
6.1.2.1.5 BROADCAST CALL ACTIVE (U2)
The broadcast call is established at least in one cell. When entering the state, parameters shall be set to
the following values, and configuration shall be adapted to the new values of configuration parameters:
ORIG = T, COMM = F, D-ATT = T, U-ATT = T.
6.1.2.1.6 BROADCAST CALL PRESENT (U3)
The MS has received a notification about an ongoing broadcast call. Higher layers are requested to accept
or reject the call. When entering the state, parameters shall be set to the following values, and
configuration shall be adapted to the new values of configuration parameters: ORIG = F, COMM = F,
D-ATT = F, U-ATT = F.
6.1.2.1.7 BROADCAST CALL CONNECTION REQUESTED (U4)
The MS has received a notification about an ongoing broadcast call. Higher layers have decided to accept
the call. When entering the state, parameters shall be set to the following values, and configuration shall
be adapted to the new values of configuration parameters: ORIG = F, COMM = F, D-ATT = F, U-ATT = F.
6.1.2.1.8 TERMINATION REQUESTED (U5)
The MS which is the originator of the broadcast call has been in state U1 or U2 and has sent a
TERMINATION REQUEST message to the network. When entering the state, parameters shall be set to
the following values, and configuration shall be adapted to the new values of configuration parameters:
ORIG = T, COMM = T, D-ATT = T, U-ATT = T.
6.1.2.1.9 RECEIVE MODE ACTIVE (U6)
The BCC entity in the MS in state U4, BROADCAST CALL CONNECTION REQUESTED, has got an
indication from lower (sub-)layers that RR has entered group receive mode (see GSM 04.08). When
entering the state, parameters shall be set to the following values, and configuration shall be adapted to
the new values of configuration parameters: ORIG = F, COMM = F, D-ATT = T, U-ATT = F.

Page 12
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6.1.2.1.10 BCC TIMERS IN THE MS
Table 6.1 specifies the timers used in BCC. The denotation of columns is defined as follows:
timer: : = name of the timer;
set: : = under which conditions the timer is set (i.e., started);
stopped: : = under which conditions the timer is stopped;
running in state(s): := in which state(s) the timer may be running;
action at expiry: : = which actions the BCC entity shall perform at expiry;
value: : = the duration between setting the timer and expiry of the timer ("s" denotes
"second(s)" "xx - yy" means that any value between xx and yy is permitted).
Table 6.1: Specification of timers used in BCC
timer set stopped running in action at value
state(s) expiry
T in state U6 on receipt of an when leaving U6 or when in U6, see 3 s
no channel
indication from lower receiving in U6 an indication depending
subclause
(sub-)layers that no from lower (sub-)layers that on further 6.3.1
channel is currently a channel is available conditions
available
T when entering U0.p using when leaving U0.p or U1 U0.p, U1 see 5 s
MM-est
the set-up procedure subclause
when entering U1 using 6.2.1
the immediate set-up
procedure
T when sending a when receiving a U5 abort 10 s
term
TERMINATION TERMINATION or broadcast
REQUEST TERMINATION REJECT call
T when entering state U4 when leaving state U4 U4 abort 10-30 s
conn req
broadcast
call
Page 13
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6.1.2.1.11 CONSISTENCY OF PARAMETERS AND STATES
The MS shall consider the following parameter values as inconsistent with the state or sub-state:
ORIG = T is inconsistent with states U3, U4, and U6.
COMM = T is inconsistent with states U0, U3, U4, and U6.
All other values of parameters ORIG, COMM, D-ATT, and U-ATT shall not be considered by the MS as
inconsistent with a state.
6.1.2.2 BROADCAST CALL CONTROL STATES AT THE NETWORK SIDE OF THE
INTERFACE
6.1.2.2.1 NULL (State N0)
No broadcast call exists for the BCC entity.
6.1.2.2.2 BROADCAST CALL INITIATED (N1)
The BCC entity has received the indication that a peer entity in a MS wants to establish a broadcast call
for a certain broadcast identity.
6.1.2.2.3 BROADCAST CALL ACTIVE (N2)
The broadcast call is established in at least one cell; there may be a MS which has seized the uplink or
not; there may be talking dispatchers or not.
6.1.2.2.4 BROADCAST CALL ESTABLISHMENT PROCEEDING (N3)
The BCC entity wants to accept the broadcast call, has initiated establishment of corresponding broadcast
call channels, and, if there is a calling user. has sent a CONNECT message to the calling user.
6.1.2.2.5 TERMINATION REQUESTED (N4)
The BCC entity has asked lower sub-layers to terminate the broadcast call in all cells and waits for a
confirmation that the broadcast call has been terminated in all cells.

Page 14
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6.2 Procedures for establishment of a broadcast call
6.2.1 Activation of a broadcast call by the network
The BCC entity in the network may initiate the activation of a broadcast call with a certain broadcast call
reference and priority in a list of cells by asking lower layers to establish the broadcast call with that
broadcast call reference and priority in those cells. It then waits until it is informed by lower (sub-)layers
that resource activation was sufficiently successful, and enters state N2, BC ACTIVE.
6.2.2 Mobile originated establishment
Higher layers in the MS may ask the BCC entity in state U0, NULL, to establish a broadcast call, either
using the immediate set-up procedure or using the set-up procedure. The request contains a group-id and
may contain a priority indication.
On request of higher layers to establish a broadcast call using the set-up procedure, the BCC entity of the
MS builds an appropriate SETUP message and asks lower (sub-)layers to establish an MM connection
explicitly (i.e. by use of a CM SERVICE REQUEST message) and to transmit the SETUP message. It
then enters state U0.p, MM CONNECTION PENDING. In state U0.p, when informed by lower sub-layers
that an MM connection has been established, the BCC entity in the MS shall stop timer T and enter
MM-est
state U1, BC INITIATED.
On request of higher layers to establish a broadcast call using the immediate set-up procedure, the BCC
entity of the MS builds an appropriate IMMEDIATE SETUP message and asks lower (sub-)layers to
establish an MM connection implicitly (see GSM 04.08) and to transmit the IMMEDIATE SETUP message.
It sets timer T and then enters state U1, BC INITIATED.
MM-est
The network BCC entity in state NULL may receive a set-up message from its peer entity in the originating
MS. This set-up message is either a SETUP message or an IMMEDIATE SETUP message. The network
enters state N1, BC INITIATED.
In state N1, the network decides whether:
a) the establishment is accepted; or
b) the establishment rejected.
In case a), the BCC entity in the network considers the peer entity in the MS having sent the set-up
message to be the calling user and asks lower layers to activate the appropriate resources. It then:
1) waits until it is informed by lower (sub-)layers that resource activation was sufficiently
successful, then sends a CONNECT message to the calling user, and enters state N2, BC
ACTIVE; or
2) sends a CONNECT message to the calling user and enters N3, BC ESTABLISHMENT
PROCEEDING. In state N3, the BCC entity is informed by lower layers whenever the status
of resources for the broadcast call is changed. When informed that activation of resources
was sufficiently successful, the BCC entity in the network enters state N2, ACTIVE.
The CONNECT message specifies the broadcast call reference of the broadcast call and indicates
that the MS is the originator of the broadcast call.
In case b), the further proceeding is as defined in subclause 6.2.2.1.

Page 15
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
In state U0.p or U1, the BCC entity in the MS shall, on receipt of a CONNECT message, establish the
conditions defined for state U2, ACTIVE and the suitable sub-state (see subclause 6.1.2.1), stop timer
T (if running) and enter state U2, ACTIVE. If the immediate set-up procedure has been used, the

MM-est
BCC entity in the MS shall inform lower sub-layers that the MM connection has been implicitly established.
6.2.2.1 Termination during mobile originated establishment
At any time during the mobile originated establishment of a broadcast call, the network may decide to
terminate the connection between the two peer entities in the network and MS. In this case the network
sends a TERMINATION message to the MS specifying the appropriate cause; it may ask lower
(sub-)layers to release associated resources. The further actions are specified in subclause 6.4.
During mobile originated establishment of a broadcast call, the MS may abort the broadcast call, see
subclause 6.4.
6.2.2.2 Abnormal cases
At expiry of T , or radio link failure (see GSM 04.08), the BCC entity in the MS requests lower
MM-est
sub-layers to abort the MM connection establishment and returns to state U0, NULL(this includes clearing
of the context related to the broadcast call establishment).
On receipt of an indication of lower sub-layers that the MM connection establishment was unsuccessful,
the BCC entity in the MS returns to state U0, NULL (this includes clearing of the context related to the
broadcast call establishment).
6.2.3 Mobile terminating broadcast call establishment in the MS
The BCC entity in the MS, being in state U0, NULL, may receive an indication of lower layers that a
broadcast call exists. This indication specifies the broadcast-id and a priority. It shall then inform higher
layers and enter state U3, BC present. This state may be supervised by a timer at expiry of which the BCC
entity clears the context and returns to state U0, NULL.
In state U3, on request of higher layers to join the broadcast call, the BCC entity in the MS stops any
running timer, asks lower sub-layers to join the broadcast call, starts timer T , and enters state U4,
conn req
BC CONNECTION REQUESTED.
In state U4, on indication of lower sub-layers that the broadcast call has been joint (this indication
specifies the mode of the RR connection), the BCC entity in the MS stops any running timer, enters state
U6, RECEIVE MODE ACTIVE, establishes the appropriate configurations (see subclause 6.1) and informs
higher layers (this includes information about the sub-state).

Page 16
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
6.3 Procedures during the active state and receive mode active state of a broadcast call
6.3.1 Mobile station procedures in the active state
In the active state, the BCC entity in the MS performs, on receipt of messages from its peer entity, on
request of higher layers, and on indication of lower sub-layers, actions as defined below.
On request of higher layers, the MS initiates abort or termination of the broadcast call, see subclause 6.4.
If the network initiates broadcast call abortion or termination, the MS reacts as specified in subclause 6.4.
On radio link failure, the MS aborts the broadcast call, see subclause 6.4.
6.3.2 Network procedures in the active state
In the active state the BCC entity in the network performs supervisory functions, maintenance functions
and resource modifications which are not further specified. (This includes through-connection of the
application data stream(s), which is defined in GSM 03.69.)
The network may initiate abort or termination of the broadcast call, see subclause 6.4.
If the MS initiates broadcast call abortion or termination, the network reacts as specified in subclause 6.4.
The network may send a SET STATUS message to the MS in order to ask the MS to set parameters to
certain values and to take consequential actions.
6.3.3 Mobile station procedures in the RECEIVE MODE ACTIVE state
In state U6, RECEIVE MODE ACTIVE, the BCC entity in the MS performs, on receipt of messages from
its peer entity, on request of higher layers, and on indication of lower sub-layers, actions as defined below.
On request of higher layers, the MS initiates abort of the broadcast call, see subclause 6.4.
If the network initiates broadcast call abortion or termination, the MS reacts as specified in subclause 6.4.
Upon indication from lower layers that no channel is available, the BCC entity in the MS informs higher
layers and starts timer T . Then:
no channel
if T expires, the BCC entity in the MS informs higher layers, asks lower sub-layers to abort
no channel
resources and enters the idle state
upon indication from lower layers that a channel is available, the BCC entity in the MS informs higher
layers and stops timer T .
no channel
6.4 Procedures for release, abortion, and termination of a broadcast call
6.4.1 Termination procedure
The MS being the originator of the broadcast call (ORIG = T) shall, on request of higher layers,
initiate the termination procedure by sending a TERMINATION REQUEST message to its peer entity in
the network and setting timer T .
term
The network either accepts the termination by sending a TERMINATION or rejects termination by sending
a TERMINATION REJECT. These messages indicate an appropriate cause.
In state U5, on receipt of a TERMINATION REJECT message, the BCC entity in the MS informs higher
layers and stops T .
term
In state U5, on T expiry, the BCC entity in the MS informs higher layers, asks lower sub-layers to abort
term
the broadcast call, clears the context related to the broadcast call, and returns to state U0, NULL.

Page 17
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
In any state, on receipt of a TERMINATION message, the BCC entity in the MS informs higher layers,
asks lower sub-layers to release the broadcast call, clears the context related to the broadcast call, and
returns to state U0, NULL.
At any time during a broadcast call, the network may decide to terminate the connection between the two
peer entities in the network and MS. In this case the network sends a TERMINATION message to the MS
specifying the appropriate cause; it may ask lower (sub-)layers to release associated resources. The
further actions are specified above in this subclause 6.4.
6.4.2 Abort and release procedures
The network may ask lower sub-layers to abort or release the broadcast call. The MS will detect abort of
the broadcast call by detecting the abort of RR resources, and a broadcast call release by detecting the
release of RR resources. The BCC entity in the MS shall then inform higher layers, ask lower sub-layers to
abort the broadcast call, clear the context related to the broadcast call, and return to state U0, NULL.
The MS shall, on request of higher layers, initiate the release procedure by asking lower sub-layers to
release the broadcast call, clearing the context related to the broadcast call, and returning to state U0,
NULL.
The BCC entity in the MS shall when required by the BCC protocol, abort the broadcast call by requesting
lower layers to abort the broadcast call, informing higher layers, clearing the context related to the
broadcast call, and returning to state U0, NULL.
6.5 Miscellaneous procedures
6.5.1 Status procedures
6.5.1.1 Get status procedure
Upon receipt of a GET STATUS message, the MS shall:
- if COMM = T, respond with a STATUS message, reporting at least the actual values of those
parameters that are requested;
- if COMM = F, ignore the message.
6.5.1.2 Set status procedure
Upon receipt of a SET STATUS message the MS shall first examine whether the message specifies a
state; in this case it shall enter the specified state. Then it shall set parameters to the indicated values, if
they are consistent with the current BCC state and sub-state (see subclause 6.1.2). If they are not:
- if COMM = T, it shall send a STATUS message specifying error cause "message incompatible with
protocol state", the state and, if applicable, sub-state, and the state attributes IE;
- if COMM = F, it shall ignore the message.

Page 18
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
7 Handling of unknown, unforeseen, and erroneous protocol data
7.1 General
This clause specifies procedures for the handling of unknown, unforeseen, and erroneous protocol data
by the receiving BCC protocol entity in the MS. These procedures are called "error handling procedures",
but in addition to providing recovery mechanisms for error situations they define a compatibility
mechanism for future extensions of the protocols. Error handling procedures in the network are for further
study.
Subclauses 7.1 to 7.8 shall be applied in order of precedence.
Most error handling procedures are mandatory for the MS.
In this clause the following terminology is used:
- An IE is defined to be syntactically incorrect in a message if it contains at least one value defined as
"reserved" in clause 10, or if its value part violates rules of clause 10. However it is not a syntactical
error that a TLV encoded IE specifies in its length indicator a greater length than defined in
clause 10.
- A message is defined to have semantically incorrect contents if it contains information which,
possibly dependant on the state of the receiver, is in contradiction to the resources of the receiver
and/or to the procedural part (i.e. clauses 6 and 7) of this ETS.
7.2 Message too short
When a message is received that is too short to contain a complete message type information element,
that message shall be ignored, cf. GSM 04.07.
7.3 Unknown or unforeseen transaction identifier
If COMM = T, the MS shall answer to a message received with TI value "111" by sending a STATUS
message with same TI value, cause "invalid transaction identifier value", and including, if possible, as
diagnostics the complete message received (this may not be possible, e.g., due to length restrictions). If
COMM = F, the MS shall ignore a message received with TI value "111".
For a broadcast call control message received with TI different from "111", the following procedures shall
apply:
Whenever a message is received specifying a transaction identifier which is not recognized as relating to
an active transaction, if COMM = F, the MS shall ignore the message; if COMM = T, the MS shall send a
STATUS message with cause #81 "invalid transaction identifier value" using the received transaction
identifier value and including, if possible, as diagnostics the complete message received (this may not be
possible, e.g., due to length restrictions).
7.4 Unknown or unforeseen message type
If the protocol entity in the MS receives a message with message type not defined for the PD or not
implemented by the receiver, it shall ignore the message except for the fact that, if COMM = T, it shall
return a STATUS message with cause "message type non-existent or not implemented" and including as
diagnostics the message type of the message received.
NOTE: A message type not defined for the PD in the given direction is regarded by the
receiver as a message type not defined for the PD, see GSM 04.07.
If the protocol entity in the MS receives a message not compatible with the protocol state, the MS shall
ignore the message except for the fact that, if COMM = T, it returns a STATUS message with cause
"message type not compatible with protocol state" and including as diagnostics the message type of the
message received.
Page 19
ETS 300 949 (GSM 04.69 version 5.0.1): April 1997
7.5 Non-semantical mandatory information element errors
When on receipt of a message:
- an "imperative message part" error; or
- a "missing mandatory IE" error
is diagnosed or when a message containing:
- a syntactically incorrect mandatory IE; or
- an IE unknown in the message, but encoded as "comprehension required" (see GSM 04.08,
subclause 10.5); or
- an out of sequence IE encoded as "comprehension required" (see GSM 04.08, subclause 10.5);
is received,
- the MS shall, if COMM = F, ignore the message. Otherwise it shall proceed as follows:
The MS shall ignore the message except for the fact that it shall return a STATUS message
with cause "invalid mandatory information" and including, if possible, as diagnostics the
complete message received (this may not be possible, e.g., due to length restrictions).
7.
...