Sys01 PDF

CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5
INTRODUCTION TO GSM GSM AIR INTERFACE GSM AIR INTERFACE COMMON BEARER [2MBIT/S BTS–BSC INTERFACE
INTERFACES REVIEW PROTOCOL LINKS] (A–BIS)
CHAPTER 6 CHAPTER 7 CHAPTER 8 GLOSSARY OF TERMS ANSWERS
BSC–MSC INTERFACE BSS–OMCR INTERFACE SMS CELL BROADCAST
(A-INTERFACE) (OML) LINK
GSM Interfaces
Version 1 Revision 1
SYS01 GSR5.1
Training Manual
FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

SYS01
Training Manual
GSM Interfaces
GSM Interfaces
GSR5.1
SYS01
Training
Positin mark for TED spine
Manual
GSR5.1
SYS01
GSM Interfaces
Motorola 1993, 1994, 1995, 1996, 1997, 1998, 1999

All Rights Reserved
Printed in the U.K.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces i

Copyrights, notices and trademarks
Copyrights
The Motorola products described in this document may include copyrighted Motorola computer
programs stored in semiconductor memories or other media. Laws in the United States and other
countries preserve for Motorola certain exclusive rights for copyright computer programs, including the
exclusive right to copy or reproduce in any form the copyright computer program. Accordingly, any
copyright Motorola computer programs contained in the Motorola products described in this document
may not be copied or reproduced in any manner without the express written permission of Motorola.
Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by
implication, estoppel or otherwise, any license under the copyrights, patents or patent applications of
Motorola, except for the rights that arise by operation of law in the sale of a product.
Restrictions
The software described in this document is the property of Motorola. It is furnished under a license
agreement and may be used and/or disclosed only in accordance with the terms of the agreement.
Software and documentation are copyright materials. Making unauthorized copies is prohibited by
law. No part of the software or documentation may be reproduced, transmitted, transcribed, stored
in a retrieval system, or translated into any language or computer language, in any form or by any
means, without prior written permission of Motorola.
Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola
assumes no liability resulting from any inaccuracies or omissions in this document, or from the use
of the information obtained herein. Motorola reserves the right to make changes to any products
described herein to improve reliability, function, or design, and reserves the right to revise this
document and to make changes from time to time in content hereof with no obligation to notify any
person of revisions or changes. Motorola does not assume any liability arising out of the application
or use of any product or circuit described herein; neither does it convey license under its patent
rights of others.
Trademarks
and MOTOROLA are registered trademarks of Motorola Inc.

Aspira, Intelligence Everywhere, M-Cell and Taskfinder are trademarks of Motorola Inc.
All other brands and corporate names are trademarks of their respective owners.
ii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Important notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Cross references . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Text conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
First aid in case of electric shock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Chapter 1
Introduction to GSM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Introduction to GSM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
GSM System Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
GSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Signalling Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Open Systems Interconnection (OSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
The Layer Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Signalling Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
GSM Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16
Chapter 2
GSM Air Interface Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
GSM Air Interface Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
GSM Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Timing Advance and Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
Mapping Logical Channels onto the TDMA Frame Structure . . . . . . . . . . . . . . . . . . . . . . 2–6
Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
Multiframes and Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
The 26-frame Traffic Channel Multiframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
The 51-frame Control Channel Multiframe – BCCH/CCCH . . . . . . . . . . . . . . . . . . 2–10
GSM Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
BCCH Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
CCCH Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
DCCH Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
The 51-frame Dedicated Control Channel Multiframe – SDCCH and SACCH . . 2–16
The 51-frame Control Channel Multiframe – Combined Structure . . . . . . . . . . . . 2–18
Short Message Service Cell Broadcast (SMSCB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
SMS Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22
Multiple Background Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces iii

Chapter 3
GSM Air Interface Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
GSM Air-interface Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
MS – BTS Interface (Um or Air-interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Air-interface – Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Air-interface – Layer 1 (SACCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Unacknowledged Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Acknowledged Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Data Link Connection Identifier (DLCI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
1. Service Access Point Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
2. Type of Control Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Frame Format Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–20
Frame Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
SAPI – Service Access Point Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
LPD – Link Protocol Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
Control Field Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
P/F – Poll/Final bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
S – Supervisory Function Bit(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
U – Unnumbered Function Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
Length Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
List of System Parameters (LAPDm) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–38
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–40
Radio Resource Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–42
Mobility Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–44
Connection Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–46
Layer 3 – Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–48
Protocol Discriminator/Skip Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–50
Skip Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–50
Transaction Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–52
Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–54
Message Sequence Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–56
Mobile Originating Call Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–58
Mobile Terminating Call Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–60
Location Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–62
Call Clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–64
Message Flow Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–66
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–68
Chapter 4
Common Bearer [2 Mbit/s Links] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Common Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
iv SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Signalling Links – Common Channel Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
Transmission Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
High Density Bipolar 3 (HDB3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Time Division Multiplexing (TDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Rx Buffer/Slip Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
Slip Loss Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
Frame Alignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
N Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Sync Loss Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Sync Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
GCLK Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Remote Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Remote Loss Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Bit Error Rate (BER) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
BER Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
BER Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Cyclic Redundancy Checking (CRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Cyclic Redundancy Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Database Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
High Bit-Rate Digital Subscriber Line (HDSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28
Chapter 5
BTS – BSC Interface (A-bis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
BTS – BSC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
BSC – BTS Interface (A-bis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
A-bis Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Link Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Motorola Defined A-bis Interface (Mobis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Motorola A-bis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Functional Division between BSC and BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
MTP L3/SCCP Preselector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Connectionless Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
SCCP State Machine (SSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Switch Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Cell Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Radio Resource State Machine (RRSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Radio Channel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
Motorola/GSM A-bis Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
GSM A-bis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
Motorola A-bis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces v

Interface Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18

MSI Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–20
Signalling Links Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Radio Signalling Link (RSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Transparent Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Layer 2 Management Link (L2ML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Layer 2 – Link Access Procedure LAPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–24
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–24
Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–26
Definition of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–26
Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Service Access Point Identifier (SAPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Terminal Endpoint Identifier (TEI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
TEI Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–30
Control Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–32
Unnumbered Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Set Asynchronous Balanced Mode Extended (SABME) Command . . . . . . . . . . . 5–34
Disconnect (DISC) Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Unnumbered Information (UI) Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Unnumbered Acknowledgment (UA) Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Alignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Layer 2 timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Timer T203 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Supervisory Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–38
Frame Check Sequence (FCS) Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–40
Layer 3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–42
Complete Layer 2/Layer 3 Message Example (A-bis Defined) . . . . . . . . . . . . . . . . . . . . . 5–44
Encryption Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–44
Message Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–46
Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–48
Global Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–52
Mobile Originated Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–54
Traffic Assignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–56
Traffic Assignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–58
Request Queued – T11 Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–58
Successful Intra-BTS Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–60
Successful Inter-BSC Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–62
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–i
BSC to BTS Interface Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–ii
Part A – Message Types as Defined and Implemented by Motorola . . . . . . . . . . . . . . . . 5–ii
BSC to BTS Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–ii
BTS to BSC Messages as Defined and Implemented by Motorola . . . . . . . . . . . 5–iv
vi SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Part B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–vii
Message Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–vii
1) Message Elements defined by GSM 08.08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–vii
2) Message Elements defined by GSM 08.58 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–ix
3) Message Elements defined by GSM 04.08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–x
4) Message Elements defined by GSM 04.08 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–xi
5) Message Elements defined by Motorola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–xii
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–i
BSC to BTS Interface (A-bis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–ii
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–ii
Chapter 6
BSC–MSC Interface (A-interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
BSC–MSC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
A-interface Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
A-interface specification objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
A-interface Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
GSM Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
08.0x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
A-Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–6
Signalling System No7 (C7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Messages Transfer Part (MTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–10
Level 2 Header Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
LSSU Status Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
Alignment Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
Alignment Status Indications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
Message Signal Unit (MSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Service Information Octet (SIO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–24
Signalling Information Field (SIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Routing Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Router Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Signalling Connection Control Part (SCCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Protocol Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
SCCP Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–30
Establishment Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
SCCP Message Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
SCCP Message Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–36
Called/Calling Party Address Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–38
Radio Subsystem Application Part (BSSAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–40
BSSAP Message Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
BSSAP Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
DTAP Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
BSSMAP Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–46
Complete Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–48
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces vii

BSS Management Application Part (BSSMAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50

Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
Normal Mobile Station (MS) to PSTN Call Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–52
A-Interface Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–54
Normal PSTN to MS Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–56
Call from PSTN to MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–58
Procedures – Global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–60
Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–60
Group Circuit Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–62
Unblocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–64
Resource Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–66
Resource Indication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–66
Global Reset Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–68
Reset at the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–68
Reset at the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–70
Reset Circuit at the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–72
Reset Circuit at the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–72
Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–74
Handover Candidate Enquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–76
Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–76
MSC Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–76
Procedures – Dedicated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–78
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–78
External Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–80
Handover Required Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–80
Handover Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–80
Handover Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–82
Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–84
Classmark Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–86
Cipher Mode Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–88
Initial MS Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–90
Queueing Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–92
Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–94
MTP Level 2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–94
MTP Level 3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–94
BSSMAP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–95
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–i
Appendix A – MSC to BSC Interface (A-interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–ii
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–ii
Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–i
Appendix B – MSC–BSS Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–ii
DTAP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–ii
BSSMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–iii
MSC–BSS Message Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–iv
BSSMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–iv
BSSMAP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–iv
BSSMAP Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–v
viii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Chapter 7
BSS–OMCR Interface (OML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
BSS–OMCR Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
BSS–OMCR Interface (OML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
Motorola Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
Event/Alarm Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
Remote Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
OMC–BSS Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
OML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
X.25 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
Physical Link Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Data Link Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–16
Frame Types – Control field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18
X.25 Packet Level Protocol (PLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Packet Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
Logical Channel Numbers (LCN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Packet Type Identifier (PTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Control Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–28
Additional Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–30
OMC to BSS Communication DTE Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–32
Virtual Call Setup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–34
Chapter 8
SMS Cell Broadcast Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
SMS Cell Broadcast Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1
Short Message Service Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–2
Cell Broadcast Link (CBL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
CBC, Cell Broadcast Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–6
BSS, Cell Broadcast Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
Mobiles Cell Broadcast Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
SMS CB Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–12
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–12
Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–12
CBL Message Flow Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–14
CBL Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–16
Multiple SVC Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–16
Cell Broadcast Messages from BSC to BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–18
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces ix

SMS CB Message Structure (Air-Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–20

DRX Scheduling Message Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–22
New SMS CB Message Bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–24
New SMS CB Message Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–24
Other Message Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–24
Message Description Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–26
First Transmission of an SMS CB within the Schedule Period . . . . . . . . . . . . . . . 8–26
Retransmission Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–26
Free Message Slot, Optional Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–28
Free Message Slot, Reading Advised (not yet implemented by Motorola) . . . . . 8–28
Reserved Codepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–28
Appendix A
The 24-Channel System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–i
The 24-Channel (T1) System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–ii
24-Channel (T1) System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–iv
Channel - associated signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–iv
Common - channel signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–iv
Comparison of T1 and E1 Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–iv
Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glos–1

Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glos–3
A ......................................................................... Glos–4
B ......................................................................... Glos–7
C ......................................................................... Glos–10
D ......................................................................... Glos–14
E ......................................................................... Glos–17
F ......................................................................... Glos–19
G ......................................................................... Glos–21
H ......................................................................... Glos–23
I .......................................................................... Glos–24
K ......................................................................... Glos–26
L ......................................................................... Glos–27
M ......................................................................... Glos–29
N ......................................................................... Glos–33
O ......................................................................... Glos–35
P ......................................................................... Glos–37
Q ......................................................................... Glos–40
R ......................................................................... Glos–41
S ......................................................................... Glos–44
T ......................................................................... Glos–48
U ......................................................................... Glos–51
V ......................................................................... Glos–52
W ........................................................................ Glos–53
x SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

X . ........................................................................ Glos–54
Z ......................................................................... Glos–55
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces xi

xii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 General information
General information
Important notice
If this manual was obtained when attending a Motorola training course, it will not be
updated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If it
was supplied under normal operational circumstances, to support a major software
release, then corrections will be supplied automatically by Motorola in the form of
General Manual Revisions (GMRs).
Purpose
Motorola cellular communications manuals are intended to instruct and assist personnel
in the operation, installation and maintenance of the Motorola cellular infrastructure
equipment and ancillary devices. It is recommended that all personnel engaged in such
activities be properly trained by Motorola.
WARNING
Failure to comply with Motorola’s operation, installation and maintenance
instructions may, in exceptional circumstances, lead to serious injury or death.
These manuals are not intended to replace the system and equipment training offered by
Motorola, although they can be used to supplement and enhance the knowledge gained
through such training.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 1

General information Version 1 Revision 1
Cross references
Throughout this manual, cross references are made to the chapter numbers and section
names. The section name cross references are printed bold in text.
This manual is divided into uniquely identified and numbered chapters that, in turn, are
divided into sections. Sections are not numbered, but are individually named at the top of
each page, and are listed in the table of contents.
Text conventions
The following conventions are used in the Motorola GSM manuals to represent keyboard
input text, screen output text and special key sequences.
Input
Characters typed in at the keyboard are shown like this.
Output
Messages, prompts, file listings, directories, utilities, and environmental
variables that appear on the screen are shown like this.
Special key sequences

Special key sequences are represented as follows:
CTRL-c Press the Control and c keys at the same time.

ALT-f Press the Alt and f keys at the same time.
| Press the pipe symbol key.
CR or RETURN Press the Return (Enter) key. The Return key is
identified with the ↵ symbol on both the X terminal and
the SPARCstation keyboards. The SPARCstation
keyboard Return key is also identified with the word
Return.
2 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 First aid in case of electric shock
First aid in case of electric shock
Warning
WARNING Do not touch the victim with your bare hands until the
electric circuit is broken.
Switch off. If this is not possible, protect yourself with dry
insulating material and pull or push the victim clear of the
conductor.
Artificial
respiration
In the event of an electric shock it may be necessary to carry out artificial respiration.
Send for medical assistance immediately.
Burns treatment
If the patient is also suffering from burns, then, without hindrance to artificial respiration,
carry out the following:
1. Do not attempt to remove clothing adhering to the burn.
2. If help is available, or as soon as artificial respiration is no longer required, cover
the wound with a dry dressing.
3. Do not apply oil or grease in any form.
Whenever a safety issue arises, carry out the following procedure in all instances.
Ensure that all site personnel are familiar with this procedure.
Procedure
Whenever a safety issue arises:
1. Make the equipment concerned safe, for example, by removing power.
2. Make no further attempt to tamper with the equipment.
3. Report the problem directly to the Customer Network Resolution Centre, Swindon
+44 (0)1793 565444 or China +86 10 68437733 (telephone) and follow up with a
written report by fax, Swindon +44 (0)1793 430987 or China +86 10
68423633 (fax).
4. Collect evidence from the equipment under the guidance of the Customer Network
Resolution Centre.
Warning labels
Personnel working with or operating Motorola equipment must comply with any warning
labels fitted to the equipment. Warning labels must not be removed, painted over or
obscured in any way.

First aid in case of electric shock Version 1 Revision 1
High voltage
Certain Motorola equipment operates from a dangerous high voltage of 230 V ac single
phase or 415 V ac three phase supply which is potentially lethal. Therefore, the areas
where the ac supply power is present must not be approached until the warnings and
cautions in the text and on the equipment have been complied with.
To achieve isolation of the equipment from the ac supply, the ac input isolator must be
set to off and locked.
Within the United Kingdom (UK) regard must be paid to the requirements of the
Electricity at Work Regulations 1989. There may also be specific country legislation
which need to be complied with, depending on where the equipment is used.
RF radiation
High RF potentials and electromagnetic fields are present in the base station equipment
when in operation. Ensure that all transmitters are switched off when any antenna
connections have to be changed. Do not key transmitters connected to unterminated
cavities or feeders.
Refer to the following standards:
ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to Human
Exposure to Radio Frequency Electromagnetic Fields, 3 kHz to 300 GHz.
CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields High
Frequency (10 kHz to 300 GHz).
Laser radiation
Do not look directly into fibre optic cables or optical data in/out connectors. Laser
radiation can come from either the data in/out connectors or unterminated fibre optic
cables connected to data in/out connectors.
Lifting
equipment
When dismantling heavy assemblies, or removing or replacing equipment, the competent
responsible person must ensure that adequate lifting facilities are available. Where
provided, lifting frames must be used for these operations. When equipments have to be
manhandled, reference must be made to the Manual Handling of Loads Regulations
1992 (UK) or to the relevant manual handling of loads legislation for the country in which
the equipment is used.
Do not ...
... substitute parts or modify equipment.
Because of the danger of introducing additional hazards, do not install substitute parts or
perform any unauthorized modification of equipment. Contact Motorola if in doubt to
ensure that safety features are maintained.
Lithium batteries
Lithium batteries, if subjected to mistreatment, may burst and ignite. Defective lithium
batteries must not be removed or replaced. Any boards containing defective lithium
batteries must be returned to Motorola for repair.

Version 1 Revision 1 First aid in case of electric shock
Definitions
NOTE The above result applies only in the direction of maximum
radiation of the antenna. Actual installations may employ
antennas that have defined radiation patterns and gains that
differ from the example set forth above. The distances calculated
can vary depending on the actual antenna pattern and gain.
Observe the following cautions during operation, installation and maintenance of the
equipment described in the Motorola manuals. Failure to comply with these cautions or
with specific cautions elsewhere in the Motorola manuals may result in damage to the
equipment. Motorola assumes no liability for the customer’s failure to comply with these
requirements.
Caution labels
Personnel working with or operating Motorola equipment must comply with any caution
labels fitted to the equipment. Caution labels must not be removed, painted over or
obscured in any way.
Specific cautions
Cautions particularly applicable to the equipment are positioned within the text of this
manual. These must be observed by all personnel at all times when working with the
equipment, as must any other cautions given in text, on the illustrations and on the
equipment.
Fibre optics
The bending radius of all fibre optic cables must not be less than 30 mm.
Static discharge
Motorola equipment contains CMOS devices that are vulnerable to static discharge.
Although the damage caused by static discharge may not be immediately apparent,
CMOS devices may be damaged in the long term due to static discharge caused by
mishandling. Wear an approved earth strap when adjusting or handling digital boards.
Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer of
insulation that is susceptible to damage from electrostatic charge. Such a charge applied
to the leads of the device could cause irreparable damage.
These charges can be built up on nylon overalls, by friction, by pushing the hands into
high insulation packing material or by use of unearthed soldering irons.
MOS devices are normally despatched from the manufacturers with the leads shorted
together, for example, by metal foil eyelets, wire strapping, or by inserting the leads into
conductive plastic foam. Provided the leads are shorted it is safe to handle the device.

First aid in case of electric shock Version 1 Revision 1
Special handling
techniques
In the event of one of these devices having to be replaced, observe the following
precautions when handling the replacement:
Always wear an earth strap which must be connected to the electrostatic point
(ESP) on the equipment.
Leave the short circuit on the leads until the last moment. It may be necessary to
replace the conductive foam by a piece of wire to enable the device to be fitted.
Do not wear outer clothing made of nylon or similar man made material. A cotton
overall is preferable.
If possible work on an earthed metal surface. Wipe insulated plastic work surfaces
with an anti-static cloth before starting the operation.
All metal tools should be used and when not in use they should be placed on an
earthed surface.
Take care when removing components connected to electrostatic sensitive
devices. These components may be providing protection to the device.
When mounted onto printed circuit boards (PCBs), MOS devices are normally less
susceptible to electrostatic damage. However PCBs should be handled with care,
preferably by their edges and not by their tracks and pins, they should be transferred
directly from their packing to the equipment (or the other way around) and never left
exposed on the workbench.

Chapter 1
Introduction to GSM Interfaces


Chapter 1
Introduction to GSM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Introduction to GSM Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
GSM System Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
GSM Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Signalling Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Terrestrial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Open Systems Interconnection (OSI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
The Layer Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12


Version 1 Revision 1 Introduction to GSM Interfaces
Introduction to GSM Interfaces
Objectives
On completion of this chapter the student will be able to:
State the BSS terrestrial interfaces protocols and architecture.
Identify the GSM specifications which apply to these protocols.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 1–1

GSM System Entities Version 1 Revision 1
GSM System Entities

Operations and Maintenance Centre (OMC) – A central network entity that controls
and monitors other network entities, including the quality of service provided by the
network.
Mobile Switching Centre (MSC) – The telephone switching exchange for mobile
originated or terminated subscriber traffic.
Base Station System (BSS) – The fixed end of the radio interface that provides control
and radio coverage functions for one or more sites and their associated Mobile Stations
(MS). The Base Station Controller (BSC) and the Base Transceiver Station (BTS) are
part of the BSS.
Base Station Controller (BSC) – The Base Station System Control (BSSC) cabinet is
only used at BSC sites and provides the required expansion capabilities to interface to
the maximum number of remote BTSs allowed by the Motorola GSM BSS offering.
Base Transceiver Station (BTS) – The BTS cabinet is capable of operating as a BTS
with up to six Radio Frequency (RF) carriers in a single cabinet, utilising the
Horizonmacro. The Horizonmicro and Horizoncompact can offer two carrier solutions.
Interworking Function (IWF) – Performs data rate adaption between the Public Land
Mobile Network (PLMN) and other existing land networks.
Transcoder Function (XC) – Converts the signal from 64Kbs A–law to 13Kbs GSM
speech, as well as 3 kbit/s of control information.
Authentication Centre (AUC) – Generates and stores authentication parameters for
subscriber identification.
Equipment Identity Register (EIR) – The database-oriented processing network entity
that contains centralized information for validating MSs based on their international
mobile equipment identity.
Visitor Location Register (VLR) – The database-oriented processing network entity
that temporarily contains information for subscribers roaming in a given location area.
Home Location Register (HLR) – The database-oriented processing network entity that
contains the master database of the subscribers to a PLMN.
Echo Canceller (EC) – Performs echo suppression for all voice circuits.
Mobile Station (MS) – The radio equipment and man-machine interface that a
subscriber needs to access PLMN services.
Cell Broadcast Centre (CBC) – A user facility that allows the broadcast of short
message cell broadcast messages on a per cell, location area or PLMN basis.
1–2 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 GSM System Entities
The GSM System
VLR EC PSTN
HLR
CBC
OMC MSC IWF
(S)
AUC BSS
OMC
EIR XC (R)
MS
BTS BSC BTS
BTS BTS BTS BTS
BTS
MS
CO–LOCATED ENTITIES
SYS01_1_02

GSM Architecture Version 1 Revision 1
GSM Architecture
GSM has defined the interfaces between the various components of the system, so far
as it is necessary to ensure their correct functionality and also that satisfactory
interworking with fixed networks can be provided. Only in this way can the GSM system
function be considered as a truly public telecommunications system.
As such, specific definitions are provided for the functional entities within a GSM system
and the interactions/interfaces between these entities.
The diagram illustrates the generalized architecture of the interfaces.
Several interfaces between these components can be recognized and consideration of
them all is necessary for a complete understanding of the system.
Air-interface MS-BTS
A-bis (Mo-bis) BTS-BSC
A-interface BSS-MSC
B-interface MSC-VLR
C-interface MSC-HLR
D-interface HLR-VLR
E-interface Inter-MSC
F-interface MSC-EIR
G-interface VLR-VLR
R-interface MS-DTE

Version 1 Revision 1 GSM Architecture
GSM Architecture: Interface Types
SMS EIR
Air-interface A-interface
BTS BSS XCDR H
F
BSC
E
MS MSC MSC
R
A-bis (Mo-bis)
B C C B
DTE G
KEY
MS = Mobile Station VLR D D VLR

BSS = Base Station System
BTS = Base Transceiver Station
HLR
BSC = Base Site Controller
MSC = Mobile Switching Centre
VLR = Visitor Location Register I
AUC
AUC = Authentication Centre
RXCDR = Remote Transcoder
DTE = Data Terminating Equipment
SYS01_1_03

Signalling Links Version 1 Revision 1
Signalling Links
Exercise
Using the diagram opposite fill in the signalling links between each of the network
elements, stating the Motorola name of the link and which protocol is used on the link.

Version 1 Revision 1 Signalling Links
Exercise – Signalling Links
NAME: PROTOCOL:
MSC BSC
NAME: PROTOCOL:
BSC RXCDR
NAME: PROTOCOL:
BSC OMC–R
NAME: PROTOCOL:
BSC BTS
NAME: PROTOCOL:
RXCDR OMC–R
NAME: PROTOCOL:
MS BTS
NAME: PROTOCOL:
BSC CBC
SYS01_1_04

Terrestrial Interfaces Version 1 Revision 1
Terrestrial Interfaces
Introduction
From the overall logical diagram of the GSM system, the Terrestrial interfaces comprise
of all the connections between each of the GSM entities, apart from the Air-Interface.
The BSS interfaces and message protocols all conform to ITU-TS recommendations
enabling the system to be connected to different national telecommunications systems.
Terrestrial interfaces transport the traffic across the system and allow the passage of the
thousands of data messages necessary to make the system function. They transport the
data for software downloads and uploads, the collection of statistical information,
implementation of operations and maintenance commands.
The standard interfaces used are as follows;
GSM ‘A-bis’ or ‘Motorola defined-mobis’; – (this is a Motorola interpretation of the
A-bis which offers saving in resources)
Signalling System ITU-TS #7 (‘C7);
Packet Switching X25;
Whatever the interconnecting system, they share a common physical bearer between
two points, referred to as the 2 Mbit/s link.
Acronyms
TUP = Telephone User Part
MAP = Mobile Application Part
BSSAP = BSS Application Part
MOMAP = Managed Objects Management Part
ITU-TS = International Telecommunications Union-Technical Specifications.

Version 1 Revision 1 Terrestrial Interfaces
Terrestrial Interfaces
MAP on C7
MOMAP on X.25
MOMAP on x.25
MAP on C7
OMCR
VLR OMCR
VLR OMCR
HLR
OMCR
AUC
OMCR
OMCS
OMCR
OMC–R
OMCR
MSC OMCR OMCR
MSC MSC EIR
MAP on C7
OMCR EC
OMCR OMCR OMCR
XC EC EC XC
BSSAP on C7 TUP on C7
BSC
GSM A-bis or
Motorola
OMCR
BTS OMCR
BSC OMCR
BTS
BTS OMCR
BTS
OMCR
PSTN
PSTN
OMCR
BTS OMCR
BTS OMCR
BTS
MS
SYS01_1_05

Open Systems Interconnection (OSI) Version 1 Revision 1
Open Systems Interconnection (OSI)
Introduction
Users of information technology operate a wide range of data processing systems, office
automation facilities and telecommunication networks in order to achieve their business
objectives. The majority of such users recognise that there is a desperate need for such
systems to be able to interwork effectively and efficiently. Furthermore, users have
become increasingly unhappy at the prospect of being ‘locked in’ to any one
manufacturer’s range of equipment and proprietary methods of interconnecting systems.
The International Organisation for Standardisation (ISO) began work in 1979 on an open
system architecture which is known as Open Systems Interconnection (OSI). The
ultimate aim of OSI is simple – to provide a means whereby many different sorts of
systems can communicate with each other economically and efficiently.
To achieve this, the ISO has developed a definition of the way systems communicate –
the seven layer reference model.
The use of the model and defined standards should allow ‘open’ systems to be produced
creating an environment in which equipment, similar in function, but from any
manufacturing source, can be interconnected.
The Layer
Concept
The method chosen was to view the total set of functions of a system as being divided
into seven ‘layers’.
When the reference model was being developed a set of guiding principles were set
down:
each layer has a unique and specific task to perform
functions that are similar or highly inter-related are collected together within one
layer
the internal design of a layer is independent of the functions it provides
a layer only knows about its immediately adjacent layers
a layer uses the services of the layer below
a layer provides services to the layer above.
Each layer consists of a set of functions which provide specific services, which can be
thought of as being performed by an abstract ‘entity’. The protocol operating between
equivalent functions in the same layer of two different systems remote from each other is
known as the peer-to-peer protocol.

Version 1 Revision 1 Open Systems Interconnection (OSI)
The Reference Model
7 Application
Users of
Transport
6 Presentation Service
5 Session
4 Transport
3 Network Transport
Network Service
2 Data Link Service
1 Physical
SYS01_1_06

Protocols Version 1 Revision 1
Protocols
The concept of services in the OSI Model leads to an understanding of the data flow
vertically within the architecture. Protocols define the way in which entities in the same
layer, but at different ends of the system, can communicate in a horizontal manner. This
idea is termed ‘peer-to-peer’ protocol.
The requirements of the OSI protocols are achieved by each layer in the model
appending a quantity of data to the data unit ‘handed down’ from the layer above. This
additional data is protocol information which is stripped off and interpreted by the
corresponding peer entity at the remote end of the system.
Layer 1:
Physical; Responsible for the transparent transmission of information across the physical
medium.
Layer 2:
Data Link; responsible for providing reliable transfer between the terminal and network.
Layer 3:
Network; responsible for setting up and maintaining the connection across a network.
Layer 4:
Transport; responsible for the control of quality of service.
Layer 5:
Session; Handles the co-ordination between the user processes.
Layer 6:
Presentation; responsible for ensuring that the information is presented to the eventual
user in a meaningful way
Layer 7:
Application; provides user interface to lower levels.
NOTE:
AH –
Application Header
PH –
Presentation Header
SH –
Session Header
TH –
Transport Header
NH –
Network Header
LH –
Link Header

Version 1 Revision 1 Protocols
OSI Layers
DATA
Interface to lower
APPLICATION AH
LAYER levels
PRESENTATION Formatting and

PH
LAYER code
SESSION Coordination
LAYER SH
TRANSPORT Quality and

TH service
LAYER
NETWORK Setup and

NH Maintenance
LAYER
LINK Reliable data

LAYER LH transfer
PHYSICAL
LAYER BIT STREAM
SYS01_1_07

Signalling Model Version 1 Revision 1
Signalling Model
The complete MSC to MS signalling model is shown opposite:
Connection Management (CM) and Mobility Management (MM) are not interpreted by the
BSS (BSC or BTS) but are transferred using a procedure called Direct Transfer
Application Part (DTAP) which is transparent to the BSS components.
Radio Resource (RR) messages are passed between the BTS and MS, however some
messages have to be forwarded to the BSC. The BTSM (BTS Management) entities
contain procedures for handling these messages and other procedures for managing the
BTS/BSC link.
The BSC to MSC link (A-interface) uses the signalling link structure of C7. The Message
Transfer Part (MTP) serves as a transport system for reliable transfer of messages.
The Signalling Connection Control Part (SCCP) builds on the underlying MTP to provide
a full network service as described by the OSI architecture.
The user function of the SCCP is the BSS Application Part (BSSAP) which uses one
signalling connection per active MS.
NOTE:
CM – Connection Management
MM – Mobility Management
RR – Radio Resource Management
LAPD – Link Access Procedure “D” (Data Channel)
LAPDm – Link Access Procedure “Dm” (Mobile “D” Channel)
BTSM – BTS Management
SCCP – Signalling Connection Control Part
MTP – Message Transfer Part
BSSAP – BSS Application Part
DTAP – Direct Transfer Application Part

Version 1 Revision 1 Signalling Model
Signalling Model
MS BTS BSC MSC
CM CM
MM MM
BSSAP:
DTAP/
RR BSSAP BSSMAP
RR
RR BTSM BTSM
SCCP SCCP
LAPDm LAPDm LAPD LAPD MTP MTP
Physical: Physical: Physical:

Physical
Layer 1 Layer 1 Layer 1
Layer 1
Radio Air–interface A–bis A–Interface

KEY
BTSM = BTS Management
SYS01_1_08

GSM Specifications Version 1 Revision 1
GSM Specifications
The GSM committee has been responsible for the production of the standards and the
theoretical studies. The resultant specifications are divided into several sets of
specifications, each providing a detailed description of a different aspect of the system
together with all the mandatory and optional features. These specifications make
extensive reference to existing ITU, CEPT and ISO standards.
These specifications are arranged under 12 main headings:
1. General
2. Services Aspects
3. Network Aspects
4. MS-BSS interface and Protocols
5. Physical layer on the Radio Path (Radio Sub-system)
6. Speech Coding
7. Terminal Adaptors for MS
8. BSC-MSC Interface
9. Network Interworking
10. Service Interworking
11. Equipment Specification and type approval
12. Network Management (operation and maintenance)
ITU – International Telecommunications Union
NOTE:
ITU-TS was formerly known as CCITT

Version 1 Revision 1 GSM Specifications
GSM Specifications
05
Radio Subsystem
04 08
MS MS–BSS Interface BSS MSC–BSC Interface MSC
06 09
Speech Coding Network Interworking
07 MSC VLR
Terminal Adapters
HLR
10
Service Interworking
PSTN/ISDN
SYS01_1_9


Chapter 2
GSM Air Interface Review


Chapter 2
GSM Air Interface Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
GSM Air Interface Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
GSM Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Timing Advance and Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
Mapping Logical Channels onto the TDMA Frame Structure . . . . . . . . . . . . . . . . . . . . . . 2–6
Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
The 26-frame Traffic Channel Multiframe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
GSM Control Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
BCCH Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
CCCH Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
DCCH Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
The 51-frame Dedicated Control Channel Multiframe – SDCCH and SACCH . . 2–16
The 51-frame Control Channel Multiframe – Combined Structure . . . . . . . . . . . . 2–18
Short Message Service Cell Broadcast (SMSCB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
SMS Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22
Multiple Background Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22


Version 1 Revision 1 GSM Air Interface Review
GSM Air Interface Review
Objectives
Understand the Air-interface Burst Structure.
Understand the Air-interface Frame and multiframe structure.
Understand the Air-interface implementation of SMS CB.

GSM Air Interface Version 1 Revision 1
GSM Air Interface
Bursts
Each carrier frequency used in GSM is divided into 8 independent timeslots and into
each of these timeslots a burst is placed. The diagram shows the general format of a
GSM burst.
The receiver can only receive the burst and decode it if it is received within the timeslot
designated for it. The timing, therefore, must be extremely accurate, however, the
structure does allow for a small margin of error by incorporating a ‘guard period’ as
shown in the diagram. To be precise, the timeslot is 0.577ms long, whereas the burst is
slightly shorter at 0.546ms. Eight bursts occupy one TDMA frame.
The ‘‘flag-bits” are set when the frame has been ‘stolen’ by FACCH (the Fast Associated
Control Channel). The ‘‘training sequence” is used by the receiver’s equaliser as it
estimates the transfer characteristic of the physical path between the base-station and
the mobile.

Version 1 Revision 1 GSM Air Interface
GSM Burst and TDMA Frame
FRAME 1 FRAME 2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
GUARD GUARD
PERIOD NORMAL BURST PERIOD
TRAINING
SEQUENCE
FLAG BITS
TAIL BITS
SYS01_2_2

Timing Advance and Power Control Version 1 Revision 1
Timing Advance and Power Control

To simplify the design of the mobile, the GSM Recommendations specify an offset of
three time-slots between the BSS and MS timing thus avoiding the necessity for the
mobile to transmit and receive simultaneously. The facing diagram illustrates this.
However, the synchronisation of a TDMA system is critical because bursts have to be
transmitted and received within the “real-time” timeslots allotted to them. The further the
mobile is from the base station then, obviously, the longer it will take for the bursts to
travel the distance between them. The GSM base-station caters for this problem by
instructing the MS to advance its timing (i.e. transmit earlier) to compensate for the
increased propagation delay.
This advance is then superimposed upon the 3 timeslot nominal offset, as shown.
‘‘Power Control” is an optional feature of the GSM air interface which allows the operator
to not only compensate for the distance from mobile to base-station as regards timing,
but can also cause the base-station and mobile to adjust their power output to take
account of that distance. The closer the mobile is to the base-station, the less the power
it and the base-station will be required to transmit. This feature saves radio battery
power at the mobile, and helps to reduce co-channel and adjacent channel interference.

Version 1 Revision 1 Timing Advance and Power Control
Timing Advance
FRAME 1
DOWNLINK
0 1 2 3 4 5 6 7
TIMING
ADVANCE BS – MS
FRAME 1
UPLINK 0 1 2 3 4 5 6 7
MS – BS
SYS01_2_3

Mapping Logical Channels onto the TDMA Frame Structure Version 1 Revision 1
Mapping Logical Channels onto the TDMA Frame Structure
Bursts
The diagram shows the five types of burst employed in the GSM air-interface and shows
that all bursts, of whatever type, have to be timed so that they are received within the
appropriate timeslot of the TDMA frame. The ‘‘burst” is the sequence of bits transmitted
by the base-station or mobile – the ‘‘timeslot” is the discrete period of real time within
which it must arrive in order to be correctly decoded by the receiver.
1. Normal Burst. The normal burst carries traffic channels (both voice and data) and all
types of control channels. It is bi-directional.
2. Frequency Correction Burst. This burst carries FCCH downlink to correct the
frequency of the mobile’s local oscillator, effectively locking it to that of the base-station.
3. Synchronisation Burst. So called because its function is to carry SCH downlink,
synchronising the timing of the mobile to that of the base-station.
4. Dummy Burst. Timeslot 0 of the BCCH carrier will always contain control channel
information but depending on configuration the remaining seven timeslots may be used
to support additional control channel information or a traffic channel. If any of the
remaining seven timeslots are idle then Dummy bursts must be inserted as all eight
timeslots on the BCCH carrier must always be active.
5. Access Burst. This burst is of much shorter duration than the other types. The
increased guard period is necessary because the timing of its transmission is unknown –
this is due to the unknown quantity of the mobile’s location and the lack of timing
advance information at this point during the call set-up process.

Version 1 Revision 1 Mapping Logical Channels onto the TDMA Frame Structure
GSM Burst Types
FRAME 1 FRAME 2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
3 NORMAL BURST (NB) 3
TB Encoded Bits Training Sequence Encrypted Bits TB GP

57 26 57
3 FREQ CORRECTION BURST (FB) 3
Fixed Bits
TB 142 TB GP
3 SYNCHRONIZATION BURST (SB) 3

Encrypted Bits Synchronization Sequence Encrypted Bits
TB TB GP
39 64 39
3 DUMMY BURST 3
Fixed Bits Training Sequence Fixed Bits
TB TB GP
57 26 57
8 ACCESS BURST
Synchronization Sequence Encrypted Bits GP
TB TB
41 36 68.25
577 mS
SYS01_2_4

Multiframes and Timing Version 1 Revision 1
Multiframes and Timing

There are eight timeslots within each TDMA frame, enabling eight physical channels to
share a single physical resource – the RF carrier. In turn, each physical channel may be
shared by a number of logical control or traffic channels.
In order to understand how a single physical channel is shared by various logical
channels, it is necessary to introduce the GSM multiframe structures that make it
possible.
The 26-frame
Traffic Channel
Multiframe
The illustration opposite shows the time relationship between time-slot, TDMA frame, and
the 26-frame multiframe. Some of the times shown are approximate numbers as the
GSM Recommendations actually state the exact values as fractions rather than in
decimal form (eg. the exact duration of a timeslot is 15/26ms).
Note that frame 12 (the 13th frame in the 26 frame sequence) is used by SACCH, the
Slow Associated Control Channel which carries link control information to and from the
mobile and base-station. The 8 timeslots of frame 12 accommodate 8 SACCHs – one
per TCH/FS (full-rate speech). Also note that frame 25 is idle. When the GSM
‘‘half-rate” speech channel (TCH/HS) is a reality, this frame will carry the additional 8
SACCHs required. The basic frame/timeslot structure remains identical (full-rate and
half-rate channels will coexist) – each timeslot will carry two 11.4Kb/s channels instead
of one 22.8Kb/s channel. The SACCH bit rate will remain the same, hence the need for
frame 25.

Version 1 Revision 1 Multiframes and Timing
26-Frame Multiframe
0.577 ms
7 6 5 4 3 2 1 0
4.615 ms
2 1 0
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Idle SACCH
Multiframe
25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
119.99mS
Time
SYS01_2_5

The 51-frame
Control Channel
Multiframe –
BCCH/CCCH
The 51-frame structure used for control channels is considerably more complex than the
26-frame structure used for the traffic channels and occurs in several forms, depending
on the type of control channel and the system operator’s requirements.

51-Frame Multiframes – Control Channel
0.577 ms
7 6 5 4 3 2 1 0
4.615 ms
2 1 0
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Multiframe
50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
235.365 mS
Time
SYS01_2_6

GSM Control Channels Version 1 Revision 1
GSM Control Channels

These are: Broadcast Control Channel (BCCH).
Common Control Channel (CCCH).
Dedicated Control Channel (DCCH).
BCCH Group
The Broadcast Control Channels are downlink only (base-station to mobile) and
comprises of the following:
BCCH carries info about the network, a mobiles present cell and the surrounding
cells. It is transmitted continuously as its signal strength is measured by all
mobiles on surrounding cells.
The Synchronising Channel (SCH) carries information for frame synchronisation.
The Frequency Control Channel (FCCH) provides information for carrier
synchronisation.
CCCH Group
The Common Control Channel Group is bi-directional i.e. it works in both the uplink and
downlink directions.
Random Access Channel (RACH) is the ‘uplink’ used by mobiles to gain access to
the system.
Paging Channel (PCH) and Access Granted Channel (AGCH) operate in the
“downlink” direction. The AGCH is used to assign resources to the MS, such as a
Standalone Dedicated Control Channel (SDCCH). The PCH is used by the system
to call a mobile. The PCH and AGCH are never used at the same time.
Cell Broadcast Channel (CBCH) is used to transmit messages to be broadcast to
all mobiles within a cell e.g. traffic information.
DCCH Group
Dedicated Control Channels are assigned to a single mobile for call setup and subscriber
validation. DCCH comprises of the following:
Standalone Dedicated Control Channel (SDCCH) which supports the transfer of
Data to and from the mobile during call setup and validation.
Associated Control Channel. This consists of Slow ACCH which is used for radio
link measurement and power control messages. Fast ACCH is used to pass
“event” type messages e.g. handover messages. Both FACCH and SACCH
operate in uplink and downlink directions.

Version 1 Revision 1 GSM Control Channels
Control Channels
CCH
Control Channel
NB
NB/AB
DCCH BCCH
downlink only
NB/DB
BCCH Sync.
SDCCH ACCH channels
SB FB
FACCH SACCH SCH FCCH
CCCH
AB NB NB
RACH PCH/AGCH CBCH
uplink downlink only downlink
KEY
NB = Normal Burst
FB = Frequency Burst
SB = Synchronization Burst
AB = Access Burst
DB = Dummy Burst
SYS01_2_7

Multiframes and Timing
The 51-frame
Control Channel
Multiframe –
BCCH/CCCH
The BCCH/CCCH 51-frame structure illustrated on the opposite page will apply to
timeslot 0 of each TDMA frame on the ‘BCCH carrier’ (the RF carrier frequency to which
the BCCH is assigned on a per cell basis). In the diagram, each vertical step represents
one repetition of the timeslot (= one TDMA frame), with the first repetition (numbered 0)
at the bottom.
Looking at the uplink (MS – BSS) direction, all timeslot 0s are allocated to RACH. This is
fairly obvious because RACH is the only control channel in the BCCH/CCCH group which
works in the uplink direction. In the downlink direction (BSS – MS), the arrangement is
more interesting. Starting at frame 0 of the 51-frame structure, the first timeslot 0 is
occupied by a frequency burst (‘F’ in the diagram), the second by a synchronising burst
(‘S’) and then the following four repetitions of timeslot 0 by BCCH data (B) in frames 2 –
5. The following four repetitions of timeslot 0 in frames 6 – 9 are allocated to CCCH
traffic (C) – that is, to either PCH (mobile paging channel) or AGCH (Access Grant
Channel). Then follows, in timeslot 0 of frames 10 and 11, a repeat of the frequency and
sychronising bursts (F and S), four further CCCH bursts (C) and so on ... . Note that the
last time-slot 0 in the sequence (the fifty-first frame – frame 50) is idle.

BCCH/CCCH Multiframe
Uplink
0 10 20 30 40 50
RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
Downlink
0 10 20 30 40 50
FS B C FS C C FS C C FS C C FS C C I
KEY
R = RACH (Random)
B = BCCH (Broadcast)
F = FCCH (Frequency)
S = SCH (Sync.)
C = CCCH (Common)
I = Idle
SYS01_2_8

The 51-frame
Dedicated
Control Channel
Multiframe –
SDCCH and
SACCH
The diagram shows the 51-frame structure used to accommodate 8 SDCCHs although,
as it takes two repetitions of the multiframe to complete the entire sequence, it may be
more logical to think of it as a 102-frame structure! This structure will be used on a
physical channel selected by the system operator – it is not placed in a timeslot or on an
RF carrier defined by GSM Recommendations.
Note that the 8 SACCHs (shaded) are associated with the 8 SDCCHs. It is important to
remember that each SDCCH has an SACCH just like a traffic channel.

DCCH Multiframe
Downlink
0 10 20 30 40 50
D0 D1 D2 D3 D4 D5 D6 D7 A0 A1 A2 A3 I I I
D0 D1 D2 D3 D4 D5 D6 D7 A4 A5 A6 A7 I I I
KEY
D = SDDCH/8 (Dedicated)
A = SACCH/C8 (Associated)
I = Idle
Uplink
0 10 20 30 40 50
A5 A6 A7 I I I D0 D1 D2 D3 D4 D5 D6 D7 A0
A1 A2 A3 I I I D0 D1 D2 D3 D4 D5 D6 D7 A4
SYS01_2_9

The 51-frame
Control Channel
Multiframe –
Combined
Structure
The structure illustrated can be used where traffic density is low – perhaps in a rural area
in cells with few RF carriers and only light traffic. Again, as it takes two repetitions of the
51-frame multiframe to complete the sequence, this is really a 102-frame structure.
In this case, all the control channels (with the exception of the ‘frame-stealer’ FACCH)
share the BCCH carrier timeslot 0.

Combined Multiframe
Downlink
0 10 20 30 40 50
FS B C FS C C FS D0 D1 FS D2 D3 FS A0 A1 I
FS B C FS C C FS D0 D1 FS D2 D3 FS A2 A3 I
Uplink
0 10 20 30 40 50
D3 RR A2 A3 RR RR R R R R R R R R R R R R R R R R R RR D0 D1 RR D2
D3 RR A0 A1 R RR R R R R R R R R R R R RR R R R RR R R D0 D1 RR D2
KEY
R = RACH (Random)
B = BCCH (Broadcast)
F = FCCH (Frequency)
S = SCH (Sync.)
C = CCCH (Common)
D = SDCCH/4 (Dedicated)
A = SACCH/4 (Associated)
I = Idle
SYS01_2_10

Short Message Service Cell Broadcast (SMSCB) Version 1 Revision 1
Short Message Service Cell Broadcast (SMSCB)

There are a number of database parameters which control the use of Short Message
Service. The service itself is specified by GSM and can be divided into two functions Cell
Broadcast and Point to Point.
When a short message service cell broadcast (SMSCB) message is to be sent, the
message shall be sent on the Cell Broadcast Channel (CBCH) in four consecutive
multiframes using the block defined on the page opposite.
The SMSCB header shall be sent in the multiframe on TB=0. When SMSCB is in use,
this is indicated in the BCCH data.
If this option is enabled, frequency, slot, and subslot information present within BCCH
system information will cause suitably equipped mobiles to monitor the Cell Broadcast
Channel (CBCH). This channel, when enabled, fits into the 51/102 frame multiframe in
place of SDCCH number 2. It can appear on BCCH or Non-BCCH carriers on timeslots
0-3 inclusive. Only one CBCH will exist within a cell and an algorithm will control its
whereabouts. A cell broadcast block is made up of 23 bytes (184 bits) which is encoded
to produce the familiar 456 bit block, this is then transmitted over four successive air
interface bursts. In the case where the CBCH resides on a BCCH carrier dummy bursts
will be transmitted in the other 4 multiframes.

Version 1 Revision 1 Short Message Service Cell Broadcast (SMSCB)
Short Message Service Cell Broadcast
Downlink
DCCH Multiframe
0 10 20 30 40 50
D0 D1 CBCH D3 D4 D5 D6 D7 A0 A1 A2 A3 I I I
0 1 2 3
D1 CBCH D3 D4 D5 D6 D7 A0 A1 A2 A3 I I I
D0 0 1 2 3
SMSCB
(normal
burst)
Combined Multiframe
0 10 20 30 40 50
FS B C FS C C FS D0 D1 F S CBCH D3 FS A0 A1 I
0 1 2 3
FS B C FS C C FS D0 D1 F S CBCH D3 FS A2 A3 I
0 1 2 3
SMSCB
(normal
burst)
SYS01_2_11

SMS Cell Broadcast Version 1 Revision 1
SMS Cell Broadcast

The GSM defined Cell Broadcast feature is a means of unilaterally transmitting data to
mobiles on a per cell basis, by use of the Cell Broadcast channel. Each BSC should be
connected to a Cell Broadcast Centre, which is responsible for downloading cell
broadcast messages to the BSC, together with repetition rate, and the number of
broadcasts required per message. The BSC is then responsible for transmitting these
updates to the BTS’s affected, which will then ensure that the message is transmitted as
requested. In 1400 the full GSM functionality is available, in particular the BSC to CBC
interface is supported. However, a single operator defined background message may be
entered using the appropriate database command.
The parameters controlling cell broadcast SMS are shown below:
Chg_element cbch_enabled <*><SITE No> cell number = <GSM Cell id>
* 0 disabled 1 enabled
Multiple
Background
Messages
Background messages can be a maximum of 93 characters and will be sent on the
SMSCB channel in the absence of messages originating from the Cell Broadcast Center
(CBC). A maximum of four background messages can be specified using the following
database commands:
chg_smscb_msg <msg_num> <msg_id> <gs> <msg_code> <language>
cell_number= <cell id>
msg_num (0–3)
This number is not sent to the MS, but is used as a message identifier within the
Motorola BSS software.
msg_id (0–65535)
Identifies the logical channel used within the physical CBSMS slot. This corresponds to
the ’channel number’ entered in the MMI of the MS.
gs (0–3)
This field indicates to the MS the geographical area over which the message code is
unique. It also indicates the display mode to the mobile.
0 – Immediate, Cell Wide
1 – Normal, PLMN Wide
2 – Normal, Location Area (LAC) Wide
3 – Normal, Cell Wide
msg_code (0–1023)
This field is used by the MS to differentiate between different messages being broadcast
using the same msg_id.
language (0–12)
This field specifies the alphabet/coding scheme being used in the message. Values
specified in W23.

Version 1 Revision 1 SMS Cell Broadcast
SMS Cell Broadcast
Dummy bursts (BCCH only)
0123456701234567 Each block contains a

51 frame multiframe
4 successive bursts
1234 1234 1234 1234
CBCH
burst burst burst burst
1 2 3 4
57 57 57 57 57 57 57 57
bits bits bits bits bits bits bits bits 8 blocks of 57 bits
456 bits
Fire code and
convolutional coding
184 bits Part of original message
23 bytes 23 bytes 23 bytes 23 bytes
SYS01_2_12

SMS Cell Broadcast Version 1 Revision 1

Chapter 3
GSM Air Interface Protocol


Chapter 3
GSM Air Interface Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
GSM Air-interface Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
MS – BTS Interface (Um or Air-interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Air-interface – Layer 1 (SACCH) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Modes of Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Unacknowledged Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Acknowledged Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Data Link Connection Identifier (DLCI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
1. Service Access Point Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–16
2. Type of Control Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Frame Format Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–20
Frame Delimitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–24
SAPI – Service Access Point Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
LPD – Link Protocol Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–26
Control Field Frame Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
P/F – Poll/Final bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–28
S – Supervisory Function Bit(s) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–30
U – Unnumbered Function Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–32
Length Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–36
List of System Parameters (LAPDm) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–38
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–40
Radio Resource Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–42
Mobility Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–44
Connection Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–46
Layer 3 – Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–48
Protocol Discriminator/Skip Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–50
Skip Indicator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–50
Transaction Identifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–52
Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–54
Mobile Originating Call Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–58
Mobile Terminating Call Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–60
Location Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–62
Call Clearing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–64
Message Flow Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–66
Exercise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–68


Version 1 Revision 1 GSM Air-interface Protocol
GSM Air-interface Protocol
Objectives
State the BSS Air-interface’s protocols and architecture.
Identify the GSM specifications which apply to these protocols.

MS – BTS Interface (Um or Air-interface) Version 1 Revision 1
MS – BTS Interface (Um or Air-interface)
The air-interface supports the logical channels which allow the MS to establish
communication with the GSM terrestrial network (BSS).
The following GSM specifications define the structure and procedures of this interface:
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ

ÑÑÑÑÑÑÑ

$*( $$" )*(+*+( $ ))
ÑÑÑÑÑÑÑ & " * )
ÑÑÑÑÑÑÑ

-( $(" ('+ (#$*)
ÑÑÑÑÑÑÑ

* $! -( -( $(" )&*)
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ

* $! -( -( & * %$

% " ( % $*( ) $"" $ -( $(" )&*)
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ

% " ( % $*( ) $"" $ -( & * %$
ÑÑÑÑÑÑÑ
-( +&&"#$*(- )(, ) )& * %$ $("

ÑÑÑÑÑÑÑ
)&*)
ÑÑÑÑÑÑÑ

% $*.*%.&% $* %(* )) (, )+&&%(* -(
ÑÑÑÑÑÑÑ

%(* )) (, "" (%)* -(
Note:
There are additional parts to the 04.xx series of recommendations, 04.2x details rate
adaption and radio link protocol while the 04.8x series details supplementary services.

Version 1 Revision 1 MS – BTS Interface (Um or Air-interface)
MS – BTS Interface (Air-interface) GSM Recommendations
GSM Recs. Description

04.03 MS–BSS Interface Channel structure and access
capabilities
04.04 Layer 1 General requirements
04.05 Data Link Layer (Layer 2) – General aspects
04.06 Data Link Layer (Layer 2) – Specification
04.07 Mobile radio interface signalling Layer 3 – General
aspects
04.08 Mobile radio interface signalling Layer 3 – Specification
04.10 Layer 3 – Supplementary services specification general
aspects
04.11 Point-to-point Short Message Service support (Layer 3)
04.12 Short Message Service Cell Broadcast (Layer 3)
Note:
There are additional parts to the 04.xx series of recommendations, 04.2x details rate adaption
and radio link protocol while the 04.8x series details supplementary services.
SYS01_3_2

Air-interface – Layer 1 Version 1 Revision 1
Air-interface – Layer 1
The diagram opposite shows the layer relationship between the MS – BTS. From the
diagram we can see that traffic channels are catered for with other functional units, these
interfaces are described in the 06 and 07 series of Technical Specifications and will not
be covered on this course.
The Data Link Layer (Layer 2) is where the control channels are supported (PCH+AGCH,
SACCH etc.), Layer 2 frames are also passed from the Data Link Layer to the Physical
Layer.
The Physical Layer also communicates directly to the Radio Resources Management
layer for the purposes of channel assignment, physical system layer information
(including, measurement results, timing advance etc).

Version 1 Revision 1 Air-interface – Layer 1
MS–BTS Signalling Model (Layers 1–3)
MS BTS
Radio Radio
Resources Resources
Management Management
Physical Physical
(Layer 3) (Layer 3)
Layer Layer
(Layer 1) (Layer 1)
Data Link Data Link

Layer Layer
(Layer 2) (Layer 2)
To Functional To Functional
Units (TCH) Units (TCH)
SYS01_3_3

The Physical Layer supports the transfer of bit streams on the radio medium according to
TS GSM 05-series.
In the OSIRM, Service Access Points (SAPs) of a layer are defined as gates through
which services are offered to an adjacent layer. Through a SAP the Physical Layer offers
services to the Data Link Layer (Layer 2). The SAP is used for both the control of the
service providing entity and the transfer of data. In GSM the SAPs for the Physical Layer
differ from the OSI Layer SAPs; the Layer 3 RR-management instead of the Data Link
Layer (Layer2) controls the SAPs (establishment and release of channels).
On the Physical Layer of GSM system a SAP is defined between the Data Link Layer
and the Physical Layer for each control channel.
Using Primitives (communication between layers) the Physical Layer interacts with Layer
2 and Layer 3, in line with the services required.
OSIRM – Open Systems Interconnect Reference Model

SAPs between the Physical Layer and the Data Link Layer
PCH
BCCH + RACH SDCCH SACCH FACCH
AGCH
Physical Layer (Layer 1)
There is one SAP for each control channel
SYS01_3_4

GSM recommendations define five states that a mobile can be in at any one time. These
five individual states are shown in the table opposite.
From switch on, idle mode and then to dedicated mode, the Mobile Subscriber must go
through these five states in order to establish and maintain a call.

MS – Physical Layer States
In the Physical Layer of the MS the following states are defined:
STATE Description
NULL The equipment is switched off
SEARCHING BCH The Physical Layer tracks the best
BCCH
BCH The Physical Layer listens to a
BCCH/CCCH and is able to do
Random Access
TUNING DCH The Physical Layer seizes on a physical
dedicated channel
DCH The physical layer has seized a
dedicated channel and may establish
and through connect logical channels
Note:
BCH = Bcch/ccch physical CHannel
DCH = Dedicated physical CHannel
SYS01_3_5

Air-interface – Layer 1 (SACCH) Version 1 Revision 1
Air-interface – Layer 1 (SACCH)

On a Dedicated Control Channel, the Physical Layers at both the MS and BSS,
implement a Peer-to-Peer protocol for the control of timing advance and power control.
For this purpose the Physical Layer adds a 2 octet physical header on all SACCH blocks
(a logical channel always present on a dedicated physical channel). This physical header
contains the ordered MS power level and ordered timing advance. If no timing advance
is ordered the timing field is coded with “111 111”. The timing advance is defined in steps
0 to 63, values 64 to 126 are reserved.
Procedures for handling the ordered timing advance, power control, as well as the
response from the MS in the form of actual timing advance, power control are defined in
GSM 05.05/05.08 and GSM 05.10 respectively.

Version 1 Revision 1 Air-interface – Layer 1 (SACCH)
SACCH Block Format (UL & DL)
BSS – MS
8 7 6 5 4 3 2 1
Spare Ordered MS Power Level Octet 1
Spare Ordered Timing Advance Octet 2
Octet 3
Layer 2
and
Layer 3
Information
Octet 23
MS – BSS
8 7 6 5 4 3 2 1
Spare Actual MS Power Level Octet 1
Spare Actual Timing Advance Octet 2
Layer 2
and
Layer 3
Information
Octet 23
SYS01_3_6

The Data Link Layer is the OSI layer 2 entity on the air interface. The Data Link Layer
provides services to Layer 3 and is served by the Physical Layer.
The Data Link Layer uses LAPDm on all the control channels except the RACH (this will
be covered separately on the course).
LAPDm is designed to specifically support :
Multiple Layer 3 entities
Multiple Physical Layer entities
BCCH signalling
PCH signalling
AGCH signalling
DCCH (SDCCH, SACCH, FACCH) signalling
LAPDm includes functions for:

The provision of one or more data link connections on a Dm channel.
Discrimination between the data link connections is by means of a Data Link
Connection Identifier (DLCI).
Organisation of Layer 3 information into frames.
Peer-to-Peer transmission of signalling data in defined frame formats.
Recognition of frame formats.
Establishment, maintenance (supervision) and termination of one or more (parallel)
data links on signalling channels.
Acknowledgement of transmission and reception of information frames (I frames).
Unacknowledged transmission and reception of unnumbered information frames
(UI frames).
Detection of format and operational errors on a data link.
Flow control.
Contention Resolution when establishing data link after an access request has
been made on the RACH.

LAPDm includes functons for:-
!%" ! ! # #"

!"# '! !#
!(#(! #!""" " #

! !#"
# ! !#"

"#"# # "$ !%"
#!# # "
&# !# !"
& #!""" ! #

$$! !# !"
## !# !# !!!"
& #!
## !"$#

Modes of Operation Version 1 Revision 1
Modes of Operation
Unacknowledged
Operation
In unacknowledged operation, Layer 3 information is transmitted in Unnumbered
Information (UI) frames.
At the Data Link Layer, the UI frames are not acknowledged. Flow control mechanisms
and error recovery mechanisms are not defined.
Acknowledged
Operation
In this mode Layer 3, information is transmitted in frames and is acknowledged by the
receiving Data Link Layer. Error recovery by retransmission of unacknowledged frames is
specified. In the case where errors which cannot be recovered by the Data Link Layer, a
procedure exists to notify Layer 3. Flow control procedures are also defined.
Only one form of acknowledged information transfer is defined, ie. Multiple frame
operation.
For Multiple frame operation, Layer 3 information is sent in numbered information frames,
in principle a number of I frames may be outstanding at the same time (K value = 0–7).
However for many applications a window size of 1 is required. The procedure for Multiple
frame operation is initiated by using the Set Asynchronous Balanced Mode (SABM)
The acknowledged mode of information transfer in the Data Link Layer offers
segmentation at the transmitter of Layer 3 message units if the message unit is longer
than the information field of the data layer frames. At the receiver the segmented Layer 3
message units are concatenated such that the integrity of the Layer 3 message unit is
restored.

Version 1 Revision 1 Modes of Operation
Mode of Operation and Allowed SAPI’s
Type of Channel SAPI=0 SAPI=3

BCCH Unacknowledged Not Supported
CCCH Unacknowledged Not Supported
SDCCH Unacknowledged and Acknowledged
acknowledged
SACCH associated with Unacknowledged Not Supported
SDCCH
SACCH associated with TCH Unacknowledged Acknowledged
FACCH Unacknowledged and Not Supported
acknowledged
SYS01_3_8

Data Link Connection Identifier (DLCI) Version 1 Revision 1
Data Link Connection Identifier (DLCI)

The DLCI consists of two elements:
1. Service
Access Point
Identifier
The SAPI is carried in the address field of each frame and determines to which and from
which Layer 3 entity a message is to be transported by Layer 2. On the air interface only
two SAPI values (0 & 3) are currently supported, others may be defined in the future.
The SAPI takes a specific value for the following functions on the Dm channel:
SAPI = 0:
Call Control Signalling (TS GSM 04.08 )
Mobility Management Signalling (TS GSM 04.08 )
Supplementary Services Signalling (TS GSM 04.10)
Radio Resource Management Signalling (TS GSM 04.08 )
SAPI = 3
Short Message Services (TS GSM 04.11)
Priority of SAPIs
On SDCCH:
Highest priority: SAPI = 0
Lowest priority: SAPI = 3
On SACCH
The priority arrangement on the SACCH must ensure that if a SAPI=3 frame is
awaiting transmission, two SAPI=0 frames are not sent in consecutive SACCH
frames. In addition, for the MS to network direction it must also be ensured that
any SAPI=3 frame is followed by at least one SAPI=0 frame.

Version 1 Revision 1 Data Link Connection Identifier (DLCI)
SAPIs

$"
$' $
%!!$"' "&#

# %" $

"$ ## "&#

Data Link Connection Identifier (DLCI) Version 1 Revision 1
2. Type of
Control Channel
The type of control channel on which the Data Link Connection is to be established. This
information is not carried in frames between Data Link Layer peer entities but is managed
locally in each system and is carried in primitives between layers.
Procedure for Transmission of Message Unit

A. The Network Layer (Layer 3) will select the appropriate SAP and DLCI.
B. The Network Layer (Layer 3) will indicate to the Data Link Layer which endpoint
has been chosen.
Procedure upon Receipt of a Message Unit

A. When the Data Link Layer Receives a frame containing a Layer 3 message unit, it
will have also received from the Physical Layer an indication concerning the type
of channel on which the message unit was received.
B. This combined information together with the SAPI will enable the Data Link Layer
to deliver the Layer 3 message unit to the required Data Link connection endpoint
of the indicated SAP.

Version 1 Revision 1 Data Link Connection Identifier (DLCI)
Signalling model showing channels SAPs and SAPIs
Network Layer 3
SAPI = 0 SAPI = 3
Data Data Data Data Data Data Data

Link Link Link Link Link Link Link
Random Procedure Procedure Procedure Procedure Procedure Procedure
Access UI UI MF + UI MF + UI UI MF
Data Link Distribution

Procedure
Data Link Layer 2

Physical Layer 1
RACH BCCH PCH + AGCH SDCCH FACCH SACCH + SDCCH
Key:
UI = Unacknowledged Information
MF = Multiframe Operation
SYS01_3_10

Frame Format
Peer-to-Peer
Communication
A number of different frame formats exist for the Layer 2 peer-to-peer communication
procedure (LAPDm).
Format A
This format is used on a DCCH for frames where there is no real Layer 3 information to
be transmitted.
It often occurs that Layer 2 (the receiving entity) does not have a Layer 3 message to
send after receiving a frame, which requires acknowledging, from its peer. Should this
be the case, the Layer 2 entity will simply transmit an empty frame to acknowledge
receipt of the last frame, but as yet does not have any information to send in response.
The empty frame will contain fill bits, coded with the hexadecimal value 2B or FF.
Format B
This format is used on a DCCH for frames containing an information field.

Layer 2 Frame Structures
Format A
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Octet No
1
Address Field
k
Control Field k+1
k+2
Length Indicator Field
n
n+1
Fill Bits
(Hexadecimal Value 2B or FF) N201+n
SYS01_3_11
Format B
1
Address Field
k
Control Field k+1
k+2
Length Indicator Field
n
n+1
Information Field
N
N+1
Fill Bits
(Hexadecimal Value 2B or FF) N201+n
SYS01_3_12

Frame Format
Peer-to-Peer
Communication
Format Bbis
This format is used only on BCCH, PCH and AGCH.
Only used in the unacknowledging mode of signalling data transfer.
Format C
The random access procedure is not LAPDm. Layer 3 is responsible for generating the 8
bit information content of the random access burst and using the primitives will pass this
information to the Data Link Layer, the primitives will also contain which type of channel
to use.
The Data Link Layer will then using the Physical primitives pass the information to the
Physical Layer who will send the random access burst. The Physical Layer upon sending
the random access burst will inform the Data Link Layer which burst the request was sent
in, the Data Link Layer will pass this information up to Layer 3, again using primitives.
Note:
Primitives are the messages which are passed between each of the OSI layers to enable
them to communicate with each other.

Format B-bis
1
Information Field
N201
SYS01_3_13

Frame Delimitation Version 1 Revision 1
Frame Delimitation
(Start and end of frame and/or information elements)

Frame delimitation is provided by the Physical Layer (Layer 1). See TS GSM 04.04.
Address Field
The address field may contain a variable number of octets. However, for applications on
control channels the field consists of only one octet. The address field identifies the SAP
for which a command frame is intended (note: the type of control channel i.e. BCCH,
SDCCH etc, is determined using the primitives) and the SAP transmitting a response
frame.
EA – Address Field Extension Bit
If this field is coded with a “0” then there is more than one octet to the address field, a “1”
in the field indicates that this is the final octet in the address field.
C/R – Command/Response Field Bit
The C/R bit identifies a frame as either a command or response. The MS shall send
commands with the C/R bit set to “0” and responds with the C/R bit set to “1”.
The BSS shall do opposite; that is commands are sent with the C/R bit set to “1” and
response with the C/R bit set to “0”.

Version 1 Revision 1 Address Field
Address Field
Spare LPD SAPI C/R EA=1 1
BSS and MS combinations:

Type Direction C/R value
Command BS Side to MS Side 1

Command MS Side to BS Side 0
Response BS Side to MS Side 0
Response MS Side to BS Side 1
SYS01_3_14

Address Field Version 1 Revision 1
SAPI – Service
Access Point
Identifier
The SAPI identifies a point at which Data Link Layer services are provided by the Data
Link Layer to the Layer 3 entity.
The SAPI allows 8 service access points to be specified, initially only two have been
specified the remainder are reserved for future use.
LPD – Link
Protocol
Discriminator
The Link Protocol Discriminator can take two values only with all other values reserved:
“00” Corresponds to all other available data link protocols apart from SMSCB
(These are defined within TS GSM 04.06).
“01” Correspond to the data link protocol used for SMSCB.
(These are defined within TS GSM 04.12).
The Link Protocol Discriminator is used for discriminating between the GSM Protocol and
other protocols (national or manufacturer – specific).

Version 1 Revision 1 Address Field
Address Field
SAPI – Service Access Point Identifier:
SAPI Value Related Entity

0 Call Control Signalling
Mobility Management Signalling
Supplementary Services Signalling
Radio Resource Management Signalling
3 Short Message Service
All Others Reserved for future use
LPD Link Protocol Discriminator:

“00” All other Data Link Protocols apart from SMSCB.
“01” Data Link Protocol used for SMSCB.
SYS01_3_15

Control Field Frame Formats Version 1 Revision 1
Control Field Frame Formats

The control field identifies the type of frame and whether it will be either be a command
or a response. The control field will contain receive and send sequence numbers, where
applicable.
Three types of control field formats are specified:
Information format – numbered information transfer between Layer 3 entities.
Supervisory format – performs data link supervisory functions, such as
acknowledgement of I frames, request retransmission of I frames, and request a
temporary suspension of I frames.
Unnumbered format – Additional unnumbered information transfer and control
functions (this format does not contain sequence numbers)
P/F – Poll/Final
bit
The Poll/Final bit serves a function in both command and response frames. In command
frames the P/F bit is referred to ass the “P” bit and in response frames the P/F bit is
referred to as “F”.
The “P” bit set to a “1” is used by the Data Link Layer entity to create a response from
the peer Data Link Layer entity. The “F” bit set to “1” is used by a Data Link Layer peer
entity to indicate the response frame transmitted as a result of a soliciting command.
N(S) – Send Sequence Number
Only I frames contain N(S), the send sequence number of the transmitted I frames.
N(R) – Receive Sequence Number
All I and S frames contain N(R), this is the expected send sequence number of the next
received I frame.
N(R) indicates that the Data Link Layer entity transmitting N(R) has correctly received all
I frames numbered up to and including N(R)–1.

Version 1 Revision 1 Control Field Frame Formats
Control Field Frame Formats
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1
I Frame N(R) P N(S) 0
S Frame N(R) P/F S S 0 1
U Frame U U U P/F U U 1 1
SYS01_3_16

S – Supervisory
Function Bit(s)
The following supervisory commands/responses have been defined using bit 3 and 4 of
the control field.
RR – Receiver Ready
The RR frame is used by the Data Link Layer entity to indicate:
it is ready to receive I frames
acknowledge previously received I frames up to and including N(R)–1
clear a busy condition which was previously indicated by a RNR frame sent by the
same data link entity.
In addition an RR frame with the “P” bit set to a “1” may be used by the Data Link Layer
entity to ask for the status of its peer Data Link Layer entity.
No information field is permitted in the RR frame.
REJ – Reject Command/response

The REJ command is used by a Data Link Layer entity to request retransmission of I
frames starting at N(R). The value 0f N(R) in the REJ frame acknowledges I frames
numbered up to and including N(R)–1.
In addition an REJ frame with the “P” bit set to a “1” may be used by the Data Link Layer
No information field is permitted in the REJ frame.
RNR – Receiver Not Ready

The RNR frame shall be used to by a Data Link Layer entity to indicate a busy condition,
that is temporary inability to accept additional incoming I frames. The value of N(R) in the
RNR frame acknowledges I frames numbered up to and including N(R)–1.
In addition an RNR frame with the “P” bit set to a “1” may be used by the Data Link Layer
No information field is permitted in the RNR frame.

Supervisory Function Bits
Bit 4 Bit 3 Command/Response

0 0 RR – Receiver Ready
0 1 RNR – Receiver Not Ready
1 0 REJ – Receiver Reject
SYS01_3_17

U – Unnumbered
Function Bit
SABM – Set Asynchronous Balanced Mode Command

The SABM is used to place the addressed user side or network side into the modulo 8
multiple frame acknowledged operation (the ability to transfer I frames).
If the SABM is in the MS to BSS direction in order to establish a SAPI=0 data link (for
contention resolution after having transmitted a random access frame on the RACH),
Layer 3 will indicate whether an information field is to be included.
Note:
SABM frames cannot contain Layer 3 frames which have to be segmented.
A Data Link Layer entity confirms acceptance of a SABM command by transmission at
the first opportunity of a UA response. Upon acceptance all variables for the for next
transmitted I frame, next received I frame and acknowledged I frames are set to “0”.
Any currently unacknowledged I frames, remain unacknowledged and shall be discarded,
it is the responsibility of the higher layers to recover form the loss of this information.
DISC – Disconnect Command

The DISC unnumbered command is transmitted to terminate the multiple frame
operation. Prior to actioning this command the Data Link Layer receiving the DISC
command confirms the acceptance of the DISC command by the transmission of a UA
response.
The Data Link Layer entity sending the DISC command terminates multiple frame
operation when it receives the acknowledging UA or DM response.

U – Frames
Command Response 8 7 6 5 4 3 2 1
SABM 0 0 1 P 1 1 1 1
DM 0 0 0 F 1 1 1 1
UI 0 0 0 P 0 0 1 1
DISC 0 1 0 P 0 0 1 1
UA 0 1 1 F 0 0 1 1
SYS01_3_18

U – Unnumbered
Function Bit
UI – Unnumbered Information Command

When a Data Link Layer requests unacknowledged Information transfer, the UI
unnumbered command shall be used to send information to its peer without affecting
data link variables (number of acknowledged I frame, next I frame to be
transmitted/received).
UI frames do not carry a sequence number. Therefore a UI frame may be lost without
notification to the Layer 3 entity if a Data Link Layer exception occurs during transmission
of the command.
UA – Unnumbered Acknowledgement Response

The UA frame is used by a Data Link Layer to acknowledge the receipt and acceptance
of a SABM or DISC commands. The SABM or DISC commands are not actioned until
the UA response is transmitted.
If an information field is present in the received SABM then the UA response shall
contain the same information field as received in the SABM.
The transmission of a UA frame indicates the clearance of a busy condition that was
reported earlier by the transmission of an RNR frame by the same Data Link Layer.
DM – Disconnect Mode Response

The DM unnumbered response is used by a Data Link Layer to report to its peer that the
Data Link Layer is in a state such that multiple frame operation cannot be performed.
A Data Link Layer shall transmit a DM response to any valid command it received which
it cannot action.
No information field is present in the DM response.

U – Frames
Command Response 8 7 6 5 4 3 2 1
SABM 0 0 1 P/F 1 1 1 1
DM 0 0 0 F 1 1 1 1
UI 0 0 0 P 0 0 1 1
DISC 0 1 0 P 0 0 1 1
UA 0 1 1 F 0 0 1 1
SYS01_3_19

Length Indicator
EL – Extension Bit
A “1” in the EL field indicates that this is the final octet of the length indicator field, a “0”
indicates that the length indicator field is extended.
M– More Data Bits

The “M” data bit is used to indicate segmentation of Layer 3 message data units on Data
Link Layer frames. Only I frames shall contain segmented Layer 3 information.
When the “M” bit is set to “1”, it indicates that the information field of the frame contains
only a segment of the Layer 3 message unit.
The “M” bit set to “0” indicates
that the information field contains a complete Layer 3 message unit provided that
the “M” bit of the previous frame was set to “0”
that the information frame contains the last segment of the Layer 3 message unit if
the “M” bit of the previous frame was set to “1”.
Note:
When the “M” bit is set to “1” the information field shall contain the maximum number of
octets, N201 that an information frame can contain.
Frames may contain fill bits, octets containing fill bits shall take the binary value
“00101011” when sent by the network. Octets containing fill bits shall take the binary
value “00101011” or “11111111” when sent by the MS.
Length – length field bits

The length field bits shall be any value from 0–N201 inclusive.
A length= 0 shall be used in frames not containing an information field.

Length Indicator
Length M EL=1
Key:
EL = Extension Bit
M = More Data Bits
Length = length field bits
SYS01_3_20

List of System Parameters (LAPDm) Version 1 Revision 1
List of System Parameters (LAPDm)

Timer T200
T200 is set such that it is possible to receive an acknowledgement from the peer entity of
the transmitting Data Link Layer, taking into account all processing and propagation
delays.
If T200 Expires then the frame transmitted which started T200 is retransmitted and the
counter N200 is incremented.
Counter N200
N200 is the maximum number of transactions between the Data Link Layers of an
unacknowledged frame. For SAPI=0 and SAPI=3 the value of N200 shall be set = 5.
In the state Timer Recovery the value of N200 shall be:
5 for use on SACCH
23 for use on SDCCH
34 for use on FACCH/full rate
29 for use on FACCH/half rate
(Timer recovery is defined in TS GSM 04.06)
Maximum Number of outstanding I frames (k)

The maximum number of sequentially numbered I frames that may be outstanding (that
is unacknowledged) at any given time for SAPI=0 and SAPI=3 the value shall be k=1.
Maximum number of Octets in an I, UI SABM and UA frame information

field (N201)
The maximum number of octets in an information field (N201):
for the SACCH: N201=18
for the FACCH and SDCCH: N201=20
for the BCCH, AGCH + PGH: N201=23

Version 1 Revision 1 List of System Parameters (LAPDm)
System Parameters


Introduction
The Signalling Layer 3 comprises of the following groups of signalling functions:
Call Control (CC)
Short Message Service Support (SMS)
Supplementary Services Support (SS)
Mobility Management (MM)
Radio Resource Management (RR)
These functional groups are realised by separate protocol control entities.
Both RRM and MM have the task to route the messages according to the Protocol
Discriminator (PD) and the Transaction Identifier (TI) which are part of the message
header.
Services provided by Signalling Layer 3 at the MS side

The different classes of services provided by the Signalling Layer 3 at the MS side are
accessible at the following Service Access Points.
Registration Services at the MM REG SAP.
CC services for normal and emergency calls including call related Supplementary
Services at the MNCC–SAP.
Short Message Services support services at the MN SMS–SAP.
Call Independent Supplementary services, support services at the MNSS–SAP.
The registration services (location – updating IMSI attach/detach) are provided at the
service access point MM REG–SAP. These services are provided by and can be directly
accessed at the MM sub-layer.

Layer 3 Signalling Model
MNCC–SAP MNSS–SAP MNSMS–SAP
CONNECTION MANAGEMENT
CALL SUPP SHORT

CONTROL SERVICE MESSAGE
(CC) SUPPORT SERVICE
(SS) (SMS)
MM CC–SAP MMSMS–SAP
MM REG–SAP
MMSS–SAP
TI TI TI
MM CC SS SMS
MOBILITY MANAGEMENT
PD
(MM)
RR RR
PD
RADIO RESOURCES
(RR)
SAPI=0 SAPI=3
RACH BCCH AGC SDCCH SACCH FACCH SDCCH SACCH

H+PG
H
SYS01_3_22

Radio Resource Management Sub-layer Version 1 Revision 1
Radio Resource Management Sub-layer

The sub-layer is responsible for:
The management of the frequency spectrum
The systems reactions to the changing radio environment
The maintenance of a clear channel between the Public Land Mobile Network and
the Mobile Subscriber
These responsibilities will include, channel assignment, power level control, time
alignment and handovers.
The Radio Resource sub-layer handles all the procedures necessary to establish,
maintain and release dedicated radio connections.

Version 1 Revision 1 Radio Resource Management Sub-layer
Radio Resource Sub-layer:

!


Mobility Management Sub-layer Version 1 Revision 1
Mobility Management Sub-layer

The Mobility Management Sub-layer has to deal with all the effects of handling a Mobile
Subscriber that is not directly related to radio functions.
These functions will include all tasks relevant to authorisation of a particular Mobile
Subscriber for connection to the network.
These tasks will include:
Support a user mobility, registration and management of mobility data.
Checking the user and the equipment identity.
Checking if the user is allowed to use the services and what kind of extra services
are allowed.
Support of user confidentiality.
Provision of user security.
Provision of a Mobility Management connection, based on an existing Radio
Resource connection to the Connection Management sub-layer

Version 1 Revision 1 Mobility Management Sub-layer
Mobility Management Sub-layer:


Connection Management Sub-layer Version 1 Revision 1
Connection Management Sub-layer

The Connection Management sub-layer is composed of:
Call Control – GSM 04.08
Supplementary Service Support – GSM 04.11
Short Message Service Support – GSM 04.10
The sub-layer itself manages all the functions necessary for circuit-switched call control
within the GSM Public Land Mobile Network. These functions are provided by the Call
Control entity within the sub-layer, with the other entities providing Supplementary
Services and Short Message Services.

Version 1 Revision 1 Connection Management Sub-layer
Connection Management Sub-layer

!

!

!!

Layer 3 – Frame Structure Version 1 Revision 1
Layer 3 – Frame Structure

The Layer 3 information elements are defined in TS GSM 04.08. Every message, with
the exception of the messages sent on the BCCH, downlink CCCH, SCH, RACH, and
HANDOVER ACCESS message, is a standard Layer 3 message as defined in TS GSM
04.07.
The standard Layer 3 message consists of:

Protocol Discriminator (PD).
Transaction Identifier (TI), or Skip Indicator.
Message Type.
Other information elements as required.

Version 1 Revision 1 Layer 3 – Frame Structure
Layer 3 Header
Transaction Identifier Protocol Discriminator

or Skip Indicator
Message Type
Other information elements as required
SYS01_3_26

Protocol Discriminator/Skip Indicator Version 1 Revision 1
Protocol Discriminator/Skip Indicator

Bits 1 to 4 of the first octet of a standard L3 message contain the Protocol Discriminator
(PD) information element. The PD identifies the L3 protocol to which the standard Layer
3 message belongs. The correspondence between L3 protocols and PDs is one-to-one.
The PD can take the following values:

If the network receives a standard L3 message with a protocol discriminator different

from those specified above the network may ignore the message or initiate the channel
release procedure.
If the mobile station receives a standard L3 message with a protocol discriminator
different from those specified above, the mobile station shall ignore the message.
Skip Indicator
Bits 5 to 8 of the first octet of every Radio Resource management message and Mobility
Management message contains the skip indicator. A message received with skip
indicator different from 0000 shall be ignored. A message received with skip indicator
encoded as 0000 shall not be ignored (unless it is ignored for other reasons). A protocol
entity sending a Radio Resource Management message or a Mobility Management
message shall encode the skip indicator as 0000.

Version 1 Revision 1 Skip Indicator
Layer 3 Message Structure
OCTET 1
TI or Skip
IE TYPE PD
Indicator
4 3 2 1
x x x x
bits 4 3 2 1
0 0 1 1 call control; call related SS messages

0 1 0 1 mobility management messages
0 1 1 0 radio resources management messages
1 0 0 1 SMS messages
1 0 1 1 non call related SS messages
1 1 1 1 reserved for tests procedures described in TS
GSM 11.10
SYS01_3_27

Transaction Identifier Version 1 Revision 1
Transaction Identifier
The Transaction Identifier (TI) is a pointer with a length of four bits. It is used to
distinguish between (possible) multiple parallel Connection Management connections and
between the various transactions over these simultaneous Connection Management
connections.
Bits 5 to 8 of octet 1 of a standard L3 message may contain the Transaction Identifier
(TI) IE.
The TI IE is coded as shown opposite. It is composed of the TI value and the TI flag.
The TI value and the TI flag occupy bits 5–7 and bit 8 of the first octet respectively.
TI values are assigned by the side of the interface initiating a transaction. At the
beginning of a transaction a free TI value (i.e. a value not yet used for the given PD and
with the given originator) is chosen and assigned to this transaction. It then remains
fixed for the life time of the transaction. After a transaction ends, the associated TI value
is free and may be reassigned to a later transaction.
Two identical transaction identifier values may be used when each value pertains to a
transaction originated at opposite ends of the interface. In this case the TI flag should
avoid ambiguity. The transaction identifier flag can take the values “0” or “1”. The TI flag
is used to identify which end of the radio interface originated a TI. The origination side
always sets the TI flag to “0”. The destination side always sets the TI flag to a “1”.
Hence the TI flag identifies who allocated the TI value for this transaction and the only
purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.
TI flag (octet 1) Bit 8
0 The message is sent from the side that originates the TI. 1st
1 The message is sent to the side that originates the TI. 2nd
TI value (octet 1)
7 6 5
0 0 0 TI value 0
0 0 1 – – 1
0 1 0 – – 2
0 1 1 – – 3
1 0 0 – – 4
1 0 1 – – 5
1 1 0 – – 6
1 1 1 Reserved for future extension
Note:
IE – Information Element

Version 1 Revision 1 Transaction Identifier
OCTET 1
IE TYPE TI or Skip PD
Indicator
8 7 6 5
TI TI VALUE
Key: FLAG
IE – Information Elements
TI – Transaction Identifier
PD – Protocol Discriminator
SYS01_3_28

Message Type Version 1 Revision 1
Message Type
The message type element defined in the transparent L3 IEs is defined in TS GSM
04.08. The message defines if the message is for Radio Resource Management,
Mobility Management or Connection Management.
Bit 8 is reserved for possible future use as an extension bit.
The Mobility Management messages and the Connection Management messages using
SAPI= 0 sent from the Mobile Station to the network will specify the send sequence
number N(SD) in bit 7. At the time when such a message is designated for transmission
the value N(SD) for the message to be transferred is not equal to the value of the send
state variable.
In all other standard Layer 3 messages bit 7 is set to 0 by the sending side, the receiving
side shall ignore such messages if bit 7 is set to 1.
For a complete list of the different types of message elements refer to TS GSM 04.08.
Note the information elements are defined in TS GSM 04.08.

Version 1 Revision 1 Message Type
TRANSACTION
INFORMAION PROTOCOL
TYPE OR SKIP
ELEMENTS DISCRIMINATOR
IDENTIFIER
BIT 8 BIT 7
MESSAGE TYPE (RR)
RESERVED
MESSAGE TYPE (MM, CC)
1 OCTET
SYS01_3_29

Message Sequence Scenarios Version 1 Revision 1
Message Sequence Scenarios

The best way of understanding the interface procedures is to examine the common
message sequence scenarios which highlight the flow of messages between the Mobile
Subscriber and the BTS.
The main message sequence scenarios are shown:
Mobile Originating Call Establishment.
Mobile Terminating Call Establishment.
Location Updating.
Call Clearing

Version 1 Revision 1 Message Sequence Scenarios


Mobile
Originating Call
Establishment
The mobile station initiates the call by transmitting a Channel Request. The Network will
respond with an immediate assignment message informing the Mobile Station on which
SDCCH the rest of the call set up procedure will take place. The Mobile Station
establishes contact on the SDCCH by transmitting a SABM LAPDm frame containing the
DTAP message “CM Service Request”.
However, the Network could also respond with an assignment reject message.
The Network may then initiate authentication and may start the ciphering mode setting.
After sending the Ciphering Mode Complete message, the Mobile Station initiates the call
establishment by sending the setup message to the network. The Network answers with
a Call Proceeding message.

Mobile Originating Call Establishment
Mobile Station Network

Access Burst RR
(Channel Request)
Immediate Assignment RR
SABM CM Service Request MM
UA Authentication Request MM
Authentication
Authentication Response MM
Cipher Mode Command RR

Ciphering Mode
Cipher Mode Complete RR Setting
Set up CC
Call
Call Proceeding CC Initialization
Assignment Command RR
Assignment of a
SABM on FACCH Traffic Channel
UA Assignment Complete RR
Alerting CC User Alerting
Connect CC
Call Accepted
Connect Acknowledge CC
Key:
RR – Radio Resources
MM – Mobility Management
CC – Call Control
SYS01_3_31

Mobile
Terminating Call
Establishment
Mobile terminating call establishment is initiated by the Network sending a paging request
message.
Upon receiving this message the Mobile Station initiates the immediate assignment
procedure and responds to the Network by sending the Paging Response message
within a Layer 2 SABM frame. The Network returns a Layer 2 UA frame containing the
same information field as was sent in the SABM frame.
Authentication and ciphering are treated by the Network in the same way as defined for
the Mobile originating call establishment. After ciphering has been started, the Network
sends a setup message to the Mobile Station. The capability of the Mobile Station (at
that time) to accept the call is confirmed when the mobile station returns a call confirmed
message to the Network.

Mobile Terminating Call Establishment

Paging Request
Channel Request
Immediate Assignment
Paging Response
Authentication Request
Authentication
Authentication Response
Cipher Mode Command

Ciphering Mode
Cipher Mode Complete Setting
Set up
Call
Call Confirmed Initialization
Assignment Command
Assignment of a
Assignment Complete Traffic Channel
Alerting User Alerting

Information
Connect
Call Accepted
Connect Acknowledge
SYS01_3_32

Location
Updating
The updating procedure is always initiated by the Mobile Station for example: when the
Mobile Station finds itself in a different location area from the one in which it was
registered before.
The location updating procedure is a general procedure which is used for the following
purposes:
Normal location updating
Periodic updating
IMSI attach
Normal location updating procedure is used to update the registration of the actual
location area of a Mobile Station in the Network.
Periodic updating may be used to notify the availability of the Mobile Station to the
Network.
The IMSI attach procedure is used to indicate the IMSI as active in the Network.
The Network may decide whether to allocate a new TMSI during location updating, this
option is reflected in the example.

Location Updating
Channel Request
Location Updating Request
Authentication Request
Authentication Response
Cipher Mode Command
Cipher Mode Complete
Location Updating Accept
TMSI Reallocation Complete
Channel Release
DISC
UA or DM
SYS01_3_33

Call Clearing
Initiated by the Network:

The Network initiates the clearing of a call by sending a Disconnect message to the
Mobile Station.
Upon receiving the Disconnect message from the Network the Mobile Station sends a
release message to the Network.
Upon receiving the release message from the Mobile Station, the Network sends
Release Complete to the Mobile Station and if the traffic channel is no longer needed
performs the channel release procedure.
Upon receiving the Release Complete message and if the cleared call was the last
activity on the traffic channel, the Mobile Station waits for the release of the channel
which is always initialised by the Network.
Initiated by the Mobile Station:

The Mobile Station initiates the clearing of a call by sending a Disconnect message to the
Network.
Upon receiving the Disconnect message from the Mobile Station the Network sends a
Release Message to the Mobile Station.
Upon receiving the Release Message from the network, the Mobile Station sends a
Release Complete to the Network, which, if the traffic channel is no longer needed
performs the channel release procedure.

Call Clearing Initiated by the Network
Disconnect
Call Clearing
Release
Release Complete
Channel Release
SYS01_3_34
Call Clearing Initiated by the Mobile Station
Disconnect
Call Clearing
Release
Release Complete
Channel Release
SYS01_3_35

Message Flow Scenarios Version 1 Revision 1
Message Flow Scenarios

A practical session to show message flow scenarios across the Um interface will now be
set up by your instructor.
The practical demonstrations will include:

Call setup
Handover
Call clear down
Paging response

Version 1 Revision 1 Message Flow Scenarios

Exercise Version 1 Revision 1
Exercise
The purpose of this exercise is to construct the Layer 2 and Layer 3 information elements
for a MS to network CM Service Request using the SABM.
The MS is to be identified by its TMSI.
No Ciphering Key Sequence Number is available.
The MS is a phase 1 mobile.
A5/1 is available, A5/2 and A5/3 are not available.
The MS is power class 2, GSM 900.
Pseudo synchronisation capability is not present.
Short message capability not present.
The MS does not support the extension band G1 (extended GSM frequency range)
No additional MS capability information is present.
Use the Table opposite for your answer.

Supplementary Screen Indicator is 00
Hint:
You will need to refer to TS GSM 04.07, 04.08 and 04.80 for your answers.

Version 1 Revision 1 Exercise
Exercise
ÑÑÑÑ ÑÑÑ
ÑÑÑ
ÑÑÑ
Ñ ÑÑÑ
ÑÑÑ
ÑÑÑ
Ñ ÑÑÑ
ÑÑÑÑÑÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ

ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ

ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ

Exercise Version 1 Revision 1

Chapter 4
Common Bearer [2 Mbit/s Links]


Chapter 4
Common Bearer [2 Mbit/s Links] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Common Bearer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Signalling Links – Common Channel Signalling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–4
Transmission Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
High Density Bipolar 3 (HDB3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Time Division Multiplexing (TDM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Rx Buffer/Slip Loss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
Slip Loss Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
Frame Alignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
N Bit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Sync Loss Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Sync Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
GCLK Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Remote Alarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Remote Loss Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Bit Error Rate (BER) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
BER Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
BER Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Cyclic Redundancy Checking (CRC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Cyclic Redundancy Check . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Database Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
High Bit-Rate Digital Subscriber Line (HDSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28


Version 1 Revision 1 Common Bearer
Common Bearer
Objectives
Identify the connectivity, using the 2 Mbit/s links.
State the TDM frame format and alignment procedures.
Identify the uses of CRC-4.
Understand the implementation of GCLK synchronization.

Introduction Version 1 Revision 1
Introduction
As previously mentioned the GSM system entities are connected using a common bearer
system – this being the 2 Mbit/s link.
For 75ohm cable termination we use T43 Interconnect Boards (T43IB) and for 120ohm
twisted pair termination we use Balanced Line Interconnect Boards (BIB).
Within the BSU two digital boards are used to interface the 2 Mbit/s links to the TDM
highway.
The first board is the Multiple Serial Interface board (MSI), this board can terminate up to
two 2 Mbit/s links. The second board is the Transcoder Board (XCDR) which only
terminates one 2 Mbit/s link but it also has the ability to perform the GSM defined
transcoding function on up to 30 channels of the 32 channels on the 2 Mbit/s link.

Version 1 Revision 1 Introduction
Common Bearer (2 Mbit/s Link)
PSTN MSC MSC
CBC RXCDR OMC–R
BSC
BTS
BTS
BTS
BTS
BTS BTS
BTS
BTS
SYS01_4_2

Signalling Links – Common Channel Signalling Version 1 Revision 1
Signalling Links – Common Channel Signalling

The signalling links on the GSM terrestrial interfaces utilize common channel signalling.
This means the signalling link is kept separate from the traffic. As the signalling is kept
separate from the traffic, it does not have to follow the same physical route as the traffic.
Using common channel signalling allows a signalling message to be transmitted
whenever a slot becomes available, i.e. there is no dedicated time reserved for a
particular traffic circuit to transmit its signalling data.
The advantages of common channel signalling are:
Signalling possible at any time
Signalling repertoire is increased
Signalling protocols are flexible
Signalling can include processor and network management functions
Signalling is more economical
Signalling speed is increased
The terrestrial signalling links used in the Motorola GSM system are all 64 kbit/s timeslots
on the common bearer (2 Mbit/s link). It is normal to have both traffic and signalling
using a single 2 Mbit/s link for efficient use of the 2 Mbit/s link.

Version 1 Revision 1 Signalling Links – Common Channel Signalling
Signalling Links – Common Channel Signalling
2 Mbit/s Link
Traffic
MSC Channels BSS
Control Control
Processor Processor
Signalling
(64 Kbps Timeslot)
SYS01_4_3

Transmission Code Version 1 Revision 1
Transmission Code
High Density
Bipolar 3 (HDB3)
The transmission of a digital bit stream along a line has two main problems, the first is
the introduction of a DC component. This has the effect of causing
cross-talk/interference with other cable pairs. To overcome this we use a code called
alternate mark inversion. In the diagram opposite a mark is normally a positive voltage.
(In this case every other positive mark is inverted to a negative mark. This prevents the
build up of a DC level on a copper wire, therefore making it easier for the receiving
equipment to distinguish the difference between a ‘1’ and a ‘0’.)
The second problem is that both ends of a digital link are required to be synchronised.
This can be achieved by the transmission of a clock signal, but this will require an
additional cable pair, however, it can also be achieved by using a transmission code.
HDB3 is a type of transmission code which ensures that sufficient marks (1’s) are sent to
line so that the receiver can use the data stream to extract a clock, thus saving on the
number of cable pairs required.
HDB3 checks the data stream for the number of consecutive 0s. If this number reaches
4, the transmitter will alter this to a mark (1). To enable the receiver to determine that the
transmitter has carried out this alteration, the transmitted mark is sent in the same
polarity as the last mark, called a violation. The receiver recognising this violation mark
reinserts the 0.
If the data stream has a further consecutive number of 0s, then the transmitter will insert
two violation bits, to indicate that this is the second count of 0s. These two violation bits
are in the same polarity but the opposite from the last violation mark.
This transmission code ensures that even with data of continuous 0s, there is a 50% duty
cycle rate, thus the receiver can still extract the clock signal for synchronisation.

Version 1 Revision 1 Transmission Code
High Density Bipolar 3 (HDB3)
Data: 0 1 0 1 1 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0
+ve
0v
–ve
Signal Data
TRANSMIT DATA STREAM
+ve
Vm * Vm
0v
Vm * Vm
–ve
HDB3 Code
Key:
Vm = Violation mark inserted
* Balancing bits to ensure consecutive violations are

opposite polarity and hence no dc component is introduced
and the receiver can perform clock extraction.
SYS01_4_4

Time Division
Multiplexing
(TDM)
When using time division multiplexing (TDM) a number of different channels can be
transmitted on a single line by allowing each channel in turn to transmit to the line for a
certain period of time. This period of allocated time is called a timeslot.
The channels are sampled in turn and time division multiplexed before being transmitted,
each channel (timeslot) being represented by an 8 bit code.
The system bit rate (the speed of transmission) can be calculated as follows:
Bit Rate = Sampling Frequency x Number of Bits per sample
x Number of timeslots (Channels)
8000 x 8 x 32 = 2.048 Mbit/s. Usually referred to as 2 Mbit/s systems.
Timeslot (TS) 0 does not carry traffic. Timeslot 0 in each frame is used for frame
alignment purposes.

TDM Frame Format
Frame 0 – 125 sec

(256 bits)
Timeslot
0 1 31
Traffic Timeslots
Alignment
Timeslot
8 bits
SYS01_4_5

Rx Buffer/Slip
Loss
The incoming bit stream is stored in a receive buffer which can accommodate two
complete TDM frames (512 bits). The alignment procedure uses a sliding window to
locate the frame alignment word (FAW), which indicates the start of the frame. The
receiver knows how many bits there are in a single frame (256 bits) and therefore should
be able to locate the complete frame in the buffer store.
Slip loss is when either the frame alignment word or part of the frame structure can not
be located within the buffer storage area. When this occurs the receiver buffer is
required to be reset and consequently the loss of at least one frame.
Slip Loss
Counters
These are database parameters and are equipped for every site, using the
change_element command.
Slip_loss_daily Number of slip errors in 24 hour period.
(Minor alarm generated)
Slip_loss_hourly Number of slip errors in one hour period.
(Major alarm generated)
Slip loss_oos Number of slip errors before the link is taken out of service, within a
24 hour period.
(Critical alarm generated)
Slip_loss_restore Minimum time period of “error-free” before link is restored to service.
(Clear indication generated)
An occurrence of slip loss causes the hourly, daily and out-of-service (OOS) counters
to be incremented.

Receive Buffer
Buffer Storage Area

(512 bits)
128 bits 128 bits

TS
0
FRAME 256 bits
SLIDING WINDOW
8 bits
SYS01_4_6
Slip Loss
Buffer Storage Area
300 bits TS
0
SLIDING WINDOW
8 bits
SYS01_4_7

Frame Alignment Procedures Version 1 Revision 1
Frame Alignment Procedures

Timeslot (TS) 0 contains one of two fixed bit patterns so that the ‘far end’ receive buffer
can discriminate between different frames.
One of the bit patterns is inserted into TS 0 of frame 0 and will be inserted into TS 0 of
each even numbered frames. The other bit pattern will be inserted into each odd
numbered frame.
The two bit patterns are sent alternately and are known as the Frame Alignment Word
(FAW) and Frame Data Word (FDW).

!"
!

!

.$/( %*10 0(1 1- # *) ,-1 20(' &$, %( 20(' )-/ +-3 0.((' '$1$
N Bit
It is possible to set an extra remote alarm bit, the n bit. The bit which is used for this
purpose is bit 4 of the frame data word. The actual use of this bit is specified by the
customer but the bit must be enabled using the modify_value command. Again this bit
can be enabled for all sites using the ‘all’ location index.

Version 1 Revision 1 Frame Alignment Procedures
Frame Structure
TS O TS 31
FAW TS 1
TS O TS 31
FDW TS 1
TS O TS 31
FAW TS 1
TS O TS 31
FDW TS 1
TS O TS 31
FAW TS 1
TS O TS 31
FDW TS 1
TS O TS 31
FAW TS 1
TS O TS 31
FDW TS 1
TS O TS 31
TS 1
FAW
TS O TS 1 TS 31
FDW
TS O TS 31
FAW TS 1
TS O TS 31
FDW TS 1
TS O TS 31
TS 1
FAW
TS O TS 31
TS 1
FDW
TS O TS 31
FAW TS 1
TS O TS 31
FDW TS 1
Key:
FAW = Frame Alignment Word

FDW = Frame Data Word SYS01_4_8

Synchronization Version 1 Revision 1
Synchronization
Synchronization is achieved when the sliding window detects the Frame Alignment Word
(FAW) and sets the frame in the middle of the receiver buffer. Continued synchronization
is dependant upon the window detecting the FAW and Frame Data Word (FDW) at 256
bit intervals.
Note: The synchronization is dependant on BIT 2 of the FAW/FDW toggling.
Synchronization loss occurs when 3 consecutive frame alignment signals (FAW/FDW)
are received with an error. If this occurs then link alignment will recommence.
Sync Loss
Counters
These are database parameters, which are equipped at every site and use the “change_
element”
command.

Sync Timers
sync_time–oos Immediately a synchronization loss occurs the sync_time_oos is
started, this sets the maximum time the error can exist before the link is taken out of
service. At the same time a condition is sent to the distance end.
sync_time_restore sets the minimum time after restoring synchronization, the link has
to be free of sync errors before restoring to service.

Version 1 Revision 1 Synchronization
Synchronization Timers
Increment:
Sync_loss_daily
Sync Error Sync_loss_oos
Sync_loss_hourly
sync_time_oos = started
Expires
Link = Unlock/Disbaled)
Sync restored
sync_time_restore = started
(Link = Unlock/Enabled)
sync_time_restore expires without

any sync_loss_errors
(Link = Unlock/Busy)
SYS01_4_9

GCLK Synchronization Version 1 Revision 1
GCLK Synchronization
The aim of the GCLK synchronization is to provide:
RF carrier frequencies to within +/–0.05ppm
Synchronization of E1 or T1 links to minimise
– Frame slips
– On site calibrations
The network clock should be maintained at +/–0.01ppm of 2,048 MHz E1, or 1.544 MHz
T1. To maintain the link the clock or data should have no breaks greater than 80secs,
this would cause loss of synch.
The synchronization circuit resides on the GCLK board (used in BSC, BTS & RXCDR).
The feature will operate with BTS’s in star, daisy chain and loop topologies.
The network can be run from one high quality, high accuracy clock. There is still the
ability to have two GCLK’s at each Network element (BTS, RXCDR or BSC).
Once synchronization to a “known good clock source” the Network Elements can self
calibrate to this clock (calibration is not eliminated but its occurrence is reduced.

Version 1 Revision 1 GCLK Synchronization
Public Switched
Telephone Network
(PSTN)
Network
MSC Clock
GCLK
RXCDR
E 1 OR T1 Links
GCLK GCLK GCLK GCLK

–1
2 Mbs
BTS BSC BTS BTS
GCLK GCLK
BTS BTS
SYS01_4_10

In order to phase lock, a GCLK must have a span assigned as a reference source.
Parameters in the database can be used to specify priorities applicable to each span at a
site. These priorities will be used to determine the order of selection of spans as a
reference source.
Should the chosen span subsequently go out-of-service a GCLK reference fail alarm will
be initiated. A timer controls the time the system will wait before selecting another span
for extraction. If the current span returns to synch before the timer expires then it will
remain the clock extraction source.

chg_element phase_lock_gclk <*> <site>
* 0 Disable phase locking

1 Enable phase locking
chg_element wait_for_reselection <*><site>
* 0–255 (seconds)
Default Value: 10
SYS01_4_11

To enable the GCLK to synchronize to an E1 or T1 a suitable source must exist. The
priority for source selection is:
1. MMS in service.
2. Priority of MMS (database parameter)
3. Number of times the MMS has gone out-of-service (oos) in a given period
4. If priority and MMS oos are equal the order of selection of sources shall be on a
rotation basis.
The priority of each MMS can be individually set:
modify_value <site> mms_priority <*> mms <mms_id 1> <mms_id 2>

* 0–255 0– MMS will not be selected
1– Lowest priority
255– Highest priority
A count of the number of times the MMS goes oos is kept to enable the prioritizing
algorithm to function. A reset period is used to delimit the time for which an oos count is
held. At the end of each reset period the oos count is reset to zero and the count begins
again.
chg_element clk_src_fail_reset_period <*> <site>

* 1–255 Hours
After initialization of the site the GCLK will attempt to synchronize to the chosen MMS,
the time duration taken for this synchronization will vary depending on the hardware
revision level of the card. If the synchronization has been maintained for
phase_lock_duration the CA will declare the GCLK phase locked. The default value
for this variable is 0 which indicates that there is no change from the minimum period
defined for the revision level of the GCLK. The variable may be set on an MMS basis to
account for different transmission media.
modify_value<site>phase_lock_duration <*> mms <mms_id 1> <mms_id 2>
* 0 – Default, GCLK revision level dependent, any MMS details ignored
1 – 3600 seconds MMS details used

MMS Priority:
modify_value <site> mms_priority <*> mms <mms_id 1>
<mms_id 2>
* 0–255 0– MMS will not be selected
1– Lowest priority
255 – Highest priority
Time for which OOS count is held:

chg_element clk_src_fail_reset_period <*> <site>
* 1–255 Hours
Synchronization period maintained:
modify_value <site>phase_lock_duration <*> mms

<mms_id 1> <mms_id 2>
* 0 – Default, GCLK revision level dependent, any mms details ignored
1 – 3600 seconds mms details used
SYS01_4_12

Remote Alarm
When a synchronisation alarm occurs the sync_time_oos timer is started at the local
end and remote flag alarm is set (bit 3 of the FDW). When the remote flag is detected the
distant end starts a timer (remote_time_oos) and increments the counters,
remote_loss_daily, remote_loss_hourly and remote_loss_oos.
The timer remote_time_oos sets the period in which a remote flag must be received
before the link is taken out of service and passed back to layer 1 for link alignment.
If the link was taken out of service due to remote_time_oos then the link can only be
returned back to service when there have been no remote_loss alarms for the time
specified in timer remote_time_restore.
remote_time_oos
remote_time_restore
Remote Loss
Alarms
Two database parameters are used which indicate the number of remote_loss alarms
that can occur in a given period (hourly/daily) before an alarm message is generated.
Note: these alarms can only be generated once during the given period, e.g. if the alarm
condition for the remote_loss_hourly was met in the first 10 minutes then an alarm
message would be generated, no alarm messages could be generated after this initial
one until the 1 hour period had elapsed and the remote_loss_hourly alarm was reset.
Another parameter is used to set an upper limit to the number of remote_loss alarms
that we will allow in any one day before we take the link out of service,
remote_loss_oos. If this parameter is met then an alarm is generated and the link is
passed back to layer 1 for link realignment.
If the link was taken out of service due to an remote_loss_oos then the link can only be
restored back to service when there are no remote_loss alarms for a period of time
defined in remote_loss_restore.
remote_loss_hourly
remote_loss_daily
remote_loss_oos
remote_loss_restore

Remote Timers
Distant Local
SYNC ALARM
BIT 3 FDW SET (Remote Flag)
remote_time_oos (STARTED) sync_time_oos (STARTED)
Increments: BIT 3 FDW SET (Remote Flag)
REMOTE_LOSS_DAILY
REMOTE_LOSS_HOURLY
REMOTE_LOSS_OOS
remote_time_oos (EXPIRES) BIT 3 FDW SET (Remote Flag) sync_time_oos (EXPIRES)
DISABLE MMS
DISABLE MMS
(SYNCHRONIZATION GAINED)
sync_time_restore (STARTED)
BIT 3 FDW NOT SET
remote_time_restore (STARTED)
BIT 3 FDW NOT SET
remote_time_restore (EXPIRES)
BIT 3 FDW NOT SET
remote_time_restore (EXPIRES) sync_time_restore (EXPIRES)
MMS in service MMS in service
SYS01_4_13

Bit Error Rate

(BER)
After the link has achieved link alignment/synchronisation, it is checked for bit errors over
a period of time, to ensure that this is below a pre-determined value. Typical BER rate
10e–4 eg. 1 error every 10,000 bits.
Bit errors are constantly being checked against the known fixed bits in both the Frame
Alignment Word and Frame Data Word (Bits 2–8 FAW/Bit 2 FDW). If any errors are
detected in these 8 bits (over two frames time periods) a counter will be incremented and
should the total errors over a particular time exceed the counters threshold then the link
will be taken out of service.
BER Timers
These parameters form part of the firmware of the MSI/XCDR card and set the
monitoring periods. The values may be changed using the modify value command.
ber_oos_mon_period The amount of time that an in-service MMS must be
above a set BER rate before it is taken oos.
ber_restore_mon_period The amount of time an oos MMS must be below a set
BER before it is put back in service.
BER Counters
These parameters are part of the database and are set using the “change_element”
command.
Ber_loss_daily Indicates the BER daily alarms.
Ber_loss_hourly Indicates the BER hourly alarms.

BER – Fixed Bits
Frame Alignment
0 0 1 1 0 1 1
* Word
2 Frames
1 _1 _ 1 _ 0 _ _ Frame Data Word

* *0 *
8 Fixed Bits
Bit Error Rate = 10e –4 BER Timers: ber_oos_mon_period

ber_restore_mon_period
1 = Fixed Bit
BER Counters: ber_loss_daily
ber_loss_hourly
SYS01_4_14

Cyclic
Redundancy
Checking (CRC)
Where there is a need to provide additional protection and enhanced error monitoring
capacity, then Cyclic Redundancy Check–4 (CRC–4) procedure is used. All MSI/XCDR
cards are fitted with this procedure but must be capable of interworking with equipment
which does not incorporate the CRC procedures, this being optional.
CRC–4 procedure utilises bit 1 of each frame, over a complete multiframe (16 frames).
This multiframe is further divided into two sub-multiframes (0–7) (8–15) each with a block
size of 2048 bits.
In those frames containing the Frame Alignment Word, bit 1 is used to transmit the
CRC–4 bits designated C1 – C4, for each sub-multiframe. In those frames containing
the frame data word bit 1 is used to transmit a 6-bit CRC–4 multiframe alignment signal
and two CRC–4 error indication bits (E).
This CRC multiframe alignment signal is 001011 spread over frames 1–11. The E-bits
indicate a received error from either of the two sub-multiframes (frame 13 bit 1=
sub-multiframe 1 frame 15 bit 1= sub-multiframe 2).
Cyclic
Redundancy
Check
For each sub-multiframe, which consists of 2048 bits a polynomial is generated M(x).
This polynomial is multiplied by X4 and then divided by the generator polynomial X4 + x +
1. This calculation produces a remainder of 4 bits or less.
This remainder is transmitted to the distant end as the CRC–4 check bits (C–C).
At the distant end the CRC check bits are added to M(x) and the divided by G(x) the
result should equal zero. If it does not then an error has occurred and a remote error will
be transmitted to the distant end.
Database
Command
To enable this command use:
Modify_value <site> CRC <VALUE><LINK TYPE><LINK ID>,
Site= 0 – 40
Value= 0 is enabled
1 is disabled
Link type= RSL, XBL, etc
Link ID= Unique link ID at that site.

Cyclic Redundancy Checking

(Timeslot 0 of a 32 Timeslot Frame)
SUB–MF FRAME BITS 1 TO 8 OF THE FRAME

(SMF) NUMBER 1 2 3 4 5 6 7 8
FAW 0 C1 0 0 1 1 0 1 1
FDW 1 0 1 A X X X X X
FAW 2 C2 0 0 1 1 0 1 1
1
FAW 4 C3 0 0 1 1 0 1 1
FAW 6 C4 0 0 1 1 0 1 1
FAW 8 C1 0 0 1 1 0 1 1
FAW 10 C2 0 0 1 1 0 1 1
2
FAW 12 C3 0 0 1 1 0 1 1
FDW 13 E 1 A X X X X X
FAW 14 C4 0 0 1 1 0 1 1
FDW 15 E 1 A X X X X X
Key:
C1 to C4 are the CRC–4 check bits
Sub–multiframe alignment = 001011
E = CRC–4 error indication bits
A = Alarm Indication (Remote Flag)
X = Spare bits SYS01_4_15

High Bit-Rate Digital Subscriber Line (HDSL) Version 1 Revision 1
High Bit-Rate Digital Subscriber Line (HDSL)

The purpose of HDSL is to allow transmission of high speed data over normal voice
quality 64kbps twisted wire cables, thus reducing interconnectivity costs to the Network
operator. A standard 2.048 Mbps E1 link is converted by a HDSL modem into two
1168kbps data links, each of these being transmitted down a twisted wire pair. Each pair
of wires is capable of operating at full duplex so that the same two pairs can be used for
transmission and reception at either end of the link.
The HDSL modem effectively splits the 2.048 Mbps into two and adds its own coding
information to the resultant data streams. This brings the data rate up to 1168kbps for
each pair of wires. At the distant end the data from the two wires are recombined and
the E1 link is then presented to the terminal equipment as a standard 2.048 E1 format.
The E1 link can be said to be transmitted transparently as when it arrives at the distant
terminal it is exactly the same as when it was transmitted.
There are various modes of operation possible. Single pair mode is where only timeslots
0 to 16 are transported over a single HDSL pair of wires. At the other end a full E1 frame
is reconstituted using idle code for timeslots 17 to 31. Data must be sent in contiguous
blocks when using this mode, i.e. timeslots 1, 2, 3 and 4 is a permitted combination, but
not 1, 3 and 5. Any unused timeslots of 1 to 16 are filled with idle code. This is an
advantage where low capacity sites are used.
There is a minimum quality threshold and this is determined by the gauge of wire used
and the distance of transmission. This leads to maximum possible transmission
distances for each grade of wire. Typically for 0dB of ETSI noise the minimum
transmission range is as follows:

Typical applications are for M-CELLaccess (in buildings) and M-CELLmicro equipment
where site interconnection distances are relatively small and possibly existing twisted
pairs may be used.

Version 1 Revision 1 High Bit-Rate Digital Subscriber Line (HDSL)
HDSL Modes of Operation
Unstructured Mode – Transparent 2.048Mbps E1 transmission

2.048Mbps 2.048Mbps
E1 Link E1 Link
1.168Mbps
Tx/Rx Tx/Rx
HDSL Modem HDSL Modem
Tx/Rx Tx/Rx
1.168Mbps
Single Pair Mode – E1 timeslots 0 – 16 only

2.048Mbps 2.048Mbps
E1 Link E1 Link
1.168Mbps
Tx/Rx Tx/Rx
HDSL Modem HDSL Modem
SYS01_4_16

High Bit-Rate Digital Subscriber Line (HDSL) Version 1 Revision 1

Chapter 5
BTS – BSC Interface (A-bis)


Chapter 5
BTS – BSC Interface (A-bis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
BTS – BSC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
BSC – BTS Interface (A-bis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
A-bis Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Link Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Processors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Motorola Defined A-bis Interface (Mobis) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Motorola A-bis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Functional Division between BSC and BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
MTP L3/SCCP Preselector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Connectionless Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
SCCP State Machine (SSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Switch Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Cell Resource Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Radio Resource State Machine (RRSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Radio Channel Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
Motorola/GSM A-bis Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
GSM A-bis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
Motorola A-bis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
Interface Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
MSI Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–20
Signalling Links Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Radio Signalling Link (RSL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Transparent Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Layer 2 Management Link (L2ML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–22
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–24
Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–26
Definition of Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–26
Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Service Access Point Identifier (SAPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Terminal Endpoint Identifier (TEI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
TEI Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–30
Control Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–32
Unnumbered Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Set Asynchronous Balanced Mode Extended (SABME) Command . . . . . . . . . . . 5–34
Disconnect (DISC) Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Unnumbered Information (UI) Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Unnumbered Acknowledgment (UA) Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Alignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Layer 2 timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36
Timer T203 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–36

Supervisory Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–38

Frame Check Sequence (FCS) Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–40
Layer 3 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–42
Complete Layer 2/Layer 3 Message Example (A-bis Defined) . . . . . . . . . . . . . . . . . . . . . 5–44
Encryption Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–44
Message Discriminator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–46
Message Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–48
Global Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–52
Mobile Originated Connection Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–54
Traffic Assignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–56
Traffic Assignment Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–58
Request Queued – T11 Expiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–58
Successful Intra-BTS Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–60
Successful Inter-BSC Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–62

Version 1 Revision 1 BTS – BSC Interface
BTS – BSC Interface
Objectives
Identify the GSM Recommendations for the BSC – BTS interface.
State the functions of the BSC – BTS interface.
Identify the Layer 2 (LAPD) frame structure.
Identify the limitations of the GSM A-bis interface.
State the major components and functions of the Motorola BSC – BTS A-bis
interface.
Identify the Layer 3 model.
Identify the Layer 3 message structures.

BSC – BTS Interface (A-bis) Version 1 Revision 1
BSC – BTS Interface (A-bis)
Introduction
The interface is defined to be at the terrestrial link of a remote BTS connected to the
BSC.
The BSC–BTS interface is specified by a set of characteristics including:
Physical and electrical parameters
Channel structures
Signalling transfer procedures
Configuration and control procedures
Operation and maintenance support.
The BSC–BTS interface shall be capable of supporting all services offered to the GSM
users and subscribers. In addition, it shall also allow control of the radio equipment and
radio frequency allocation in the BTS.
This interface is known as the A-bis within the GSM specifications, but was not rigorously
defined. This has lead to various manufacturers developing their own specific signalling
protocol.
Motorola’s interpretation of the A-bis link places more functionality at the BTS, this results
in reduced signalling on the A-bis link in comparison to other implementations.

Version 1 Revision 1 BSC – BTS Interface (A-bis)
BSC – BTS Interface (A-bis)
BSC
Motorola’s
implementation
1 x RSL at 64kbp/s per BTS

(minimum)
32 x 64 kb/s timeslots
(2 Mbit/s)
BTS
SYS01_5_2

GSM Specifications
The A-bis interface is defined in the 08.5X series of GSM specifications, which is
designed to support a wide range of possible architecture.
08.51 General aspects of the interface.
08.52 Interface principles: This specification is intended to provide a

unified way of connecting remotely located BTS to a BSC.
08.54 Layer 1 – the physical connectors alignment of the link.
08.56 Layer 2 – specifies the link layer used for signalling with the
Link Access procedure on the D-channel (LAPD) specification.
08.58 Layer 3 – specifies the general structure of layer 3 and traffic

management procedures and messages used on the A-bis
interface to support the signalling procedures.

Version 1 Revision 1 GSM Specifications
GSM Specifications 08.5X
&# $" # #" $

#"#
!$ #

" #!$#

$" "!#

%" %# %"

%"

%" !$ #

Signalling Model Version 1 Revision 1
Signalling Model
The A-bis interface uses a single 64 kbit/s timeslot on the 2 Mbit/s common bearer link.
Motorola have defined this signalling link as the Radio Signalling Link (RSL), which uses
the LAPD frame structure.
Radio Resource (RR) messages are mapped to BSSAP (BSS Application Part) in the
BSC. In the BTS most of them are handled as transparent messages where the BTS
only converts from one message format to another (eg. LAPDm – LAPD). However,
some of them have to be interpreted by BTS (eg. random access).
The BTS Management (BTSM) entities contain procedures for handling these messages
and other procedures for managing the BTS. These provide the mapping between
BTSM and the relevant RR messages on the radio interface.
The Layer 2 protocol over the A-bis interface is based on Link Access Procedure
D-Channel (LAPD). Where each individual BTS site and DRCU/TCU/SCU are
addressed separately using the Terminal Endpoint Identifier (TEI) of LAPD.
There are also a number of different Layer 2 procedures used for traffic management
messages, which are indicated by the Service Access Point Identifier (SAPI).

Version 1 Revision 1 Signalling Model
A-bis Signalling Model
BTS BSC
Radio Signalling Link (RSL)
RR BSSAP
RR BTSM BTSM
SCCP
LAPDm LAPD LAPD
MTP
Layer 1 Layer 1 Layer 1
Air interface
A-bis
BTSM = BTS Management

SYS01_5_4

A-bis Limitations Version 1 Revision 1
A-bis Limitations
Introduction
The main idea of the A-bis interface is to create a Network element, the BTS, which is as
simple as possible in order to minimize the interfacing required to the BSC. Therefore,
due to the simple nature of the A-bis interface, this tends to limit what can be done to the
architecture and the distribution of software functions among the various BSS
components.
Several of these limitations are listed:
Link Capacity
In the A-bis interface a single 64 kbit data link is used to connect the BSC to the BTS and
it has been calculated that this would be inadequate capacity to handle a busy cell.
Processors
One of the implications of keeping the BTS as simple as possible is that minimal call
processing is done at the BTS. Locating most call processing activities at the BSC
places an additional burden on the BSC–BTS data links which are already overloaded
due to Mobility Management procedures (location update, paging etc).
Redundancy
A-bis does not allow redundancy at the BTS level. The A-bis interface states that a
one-to-one correspondence at all times between traffic channels and the megastream
timeslot to the BSC.
Summary
The A-bis interface is lacking in several respects. Redundant control links are not
supported. It also has inadequate capacity to carry the message traffic calculated to
exist on busy cells. It requires the BSC to keep track of the BTS’s current GSM frame
number, which could reduce delays in handovers.

Version 1 Revision 1 A-bis Limitations
GSM A-bis Limitations


Motorola Defined A-bis Interface (Mobis) Version 1 Revision 1
Motorola Defined A-bis Interface (Mobis)
Introduction
To overcome the limitations of the GSM A-bis Motorola has defined its own A-bis
interface. Where possible GSM A-bis message formats are implemented. The message
transfer between the BSC and BTS is done through the internal workings of the Motorola
BSS.
To implement a GSM A-bis interface, the LAPD protocol is used between the two entities
and a translation of the protocol TEI and internal BSS executive references (mailboxes
and logical references) is necessary.
Motorola A-bis
Main areas of improvement within Motorola A-bis are:
Packing of pages; there is an inconsistency within the GSM Specifications as to
when and where this procedure can be carried out. Motorola interface will
implement this procedure at the BTS.
Processing measurement reports/power control; if measurements are sent over
the A-bis link, this increases the traffic flow. The Motorola approach is to have the
measurement reports remain at the BTS, also have the power and timing advance
information calculated here as well. Thus greatly reducing the message flow over
the interface.
Handover Detection; Since the measurements information is at the BTS, the
handover detection algorithm is executed here. When conditions exist for a
handover, an added message, handover_required, is passed over the A-bis
interface.
Reject mode; a message is sent across the A-bis interface which allows Call
Processing to set the “reject mode” at the Radio Subsystem. Having this capacity
reduces the message flow across the interface i.e. if the BSS is in a condition
where every channel request would receive an immediate assignment reject (no
channels available).

Version 1 Revision 1 Motorola Defined A-bis Interface (Mobis)
Motorola Defined A-bis Interface
!

"

!
!


Functional
Division between
BSC and BTS
Under the Motorola system, the control of radio resources/procedures and terrestrial
circuits (BSC to BTS) are split between the BSC and BTS. This split has enabled
Motorola to reduce the number of signalling links required on the A-bis
The BSC retains the processes which control the terrestrial links to the MSC and the
switch manager. It also has the overall control of any handovers required via the SCCP
state machine process.
MTP L3/SCCP
Preselector
This process handles the protocol adaption of messages when transmitting or receiving
messages from the A interface. It also decides what process a particular message is
destined for by the message header and then routes the message to the required
process.
Connectionless
Manager
The Connectionless Manager process deals with the global control of a BSS. This
process deals with the non-connection orientated portion of the C7 Signalling.
SCCP State
Machine (SSM)
The Signalling Control Connection Part State Machine (SSM) is responsible for handling
all the connection orientated portion of the C7 Signalling.
Switch Manager
The function of the Switch Manager is to connect a mobiles terrestrial trunk from the
MSC (designated by the MSC), to the radio channel given to a mobile by the Cell
Resource Manager in the BSS Software.
Cell Resource
Manager
The Cell Resource Manager is responsible for the allocation of radio channels in
response to either a mobile accessing the system or the MSC paging a mobile.
Radio Resource
State Machine
(RRSM)
The Radio Resource State Machine is responsible for maintaining the state of calls.
This process is responsible for the activation of the radio channel on instructions from the
Cell Resource Manager. When a mobile no longer requires a radio channel, the RRSM
is responsible for closing the channel down.

Motorola System
MSC
MTP L3/SCCP Preprocessor
BSC
Connectionless SCCP State Switch
Manager Machine Manager
Radio
Cell
Resource Resource
State
Radio Manager
Machine
Channel
Interface BTS
Radio Radio Radio

subsystem subsystem Channel
Process
SYS01_5_7

Radio Channel
Interface
The Radio Channel Interface process changes the address of a mobile used in the RSS
into the address used by the Layer 3 Call Processing processes.

Motorola System
MSC
MTP L3/SCCP Preprocessor
BSC
Connectionless SCCP State Switch
Manager Machine Manager
Radio
Resource Cell
Resource
State
Machine Radio Manager
Channel
Interface BTS
Radio Radio Radio

subsystem subsystem Channel
Process
SYS01_5_7

Motorola/GSM
A-bis
Comparison
To give a simple example of the advantage Motorola defined A-bis has over GSM A-bis is
the message sequence for the mobile originated connection establishment.
GSM A-bis
The Mobile Station (MS) generates the Access Burst (RACH) which requires the BTS to
request a channel from the BSC.
The BSC responds with a SDCCH channel activation message, which requires
acknowledging, before the BSC initiates the Immediate Assignment Command message.
This in turn initiates the Immediate Assignment message on the AGCH to the MS.
A Total of 4 messages on the BTS–BSC interface.
Motorola A-bis
The Radio Resource State manager (RRSM) and Radio Channel Interface (RCI) are
within the BTS, therefore, no messages required to be sent over the BSC–BTS interface.

Motorola/GSM A-bis Comparison
GSM A-bis
MS BTS BSC
Access Burst
RACH Channel Required Channel Required
SDCCH Channel
Activation
Channel Activation
Acknowledged
AGCH Immediate Command
Assignment
Motorola A-bis
No messages over BTS–BSC interface
SYS01_5_8

Interface Structure Version 1 Revision 1
Interface Structure
The Motorola interpretation of the A-bis interface recognises two types of communication
channels:
Traffic Channels – Carrying speech or data of one air interface radio

channel (13 kbit/s traffic + 3 kbit/s of control)
Signalling channel – 64 kbit/s carrying signal information (both BSC –
BTS and BSC to MSC)
The signalling channel uses a single timeslot of the 2 Mbit/s common bearer.
The A-bis interface software entity is within the RSS subsystem. Messages are passed
between the RSS subsystem and other BSS entities. The A-bis interfaces
communicates within the RSS with Handover/Measurement Evaluation and RSS
Configuration and Fault Management.
The A-bis interface software has the following major functions:
Check downlink message validity
Translate downlink messages into internal RSS address
Translate uplink messages into RSS–CP messages
Redundancy Operations for improved reliability
Reporting/logging or erroneous states or events.

Version 1 Revision 1 Interface Structure
Signalling/Traffic Links
BSC RSL at 64 Kb/s (2 Mbit/s LINK)
BTS Cabinet
MSI TDM highway
(traffic and signalling)
MCAP KSW
TDM highway
(signalling) TDM highway
BTP traffic
LAN
DHP DHP
(RSS) (RSS)
MCAP MCAP
DRIM/ DRIM/
DRCU DRCU
MS MS
SYS01_5_9

Interface Structure Version 1 Revision 1
MSI Defaults
The BTS sites can be connected by multiple 2Mbit/s lines which carry the traffic and
signalling link (RSL). The operator can specify the route between the BSC and BTS by
the software function called “PATH”.
To ensure that the BTS can re-establish the link in the event of a failure and reset
conditions, at least one of these connections must be in the default position.
Up to four default RSL timeslots can be used by the BTS to contact the BSC in ROM to
support code loading during the Initialisation procedure. The IP uses fixed MSI card
locations and fixed 64kbit/sec timeslots at the BTS.
These default links can use the same 64kbit/sec timeslots as the RSL links equipped in
the database for passing signalling traffic to the BTS once the site has been initiated.
Therefore the operator is required to equip a PATH for at least one RSL which will
terminate using one of the default MSI and MMS locations.
DEFAULT POSITIONS ARE:
CAGE 15 SLOT 16 PORT 0 TIMESLOT 1
The function of actually allocating timeslots on 2 Mbit/s lines is carried out by an

algorithm. A timeslot is chosen independently for each 2 Mbit/s line in the PATH.

Version 1 Revision 1 Interface Structure
MSI Defaults
BSC
RSL BTS 1 RSL BTS 2 RSL BTS 3
cage 15 software software
Path 0
MSI slot 16 decision decision
port 0
timeslot 1 (any timeslot) (any timeslot)
BTS 1
Path 1 RSL BTS 2 RSL BTS 3
cage 15 software
MSI slot 16 decision
port 0
timeslot 1 (any timeslot)
BTS 2
RSL BTS 3
cage 15
Path 2 MSI slot 16
port 0
timeslot 1
BTS 3
SYS01_5_10

Signalling Links Logical Channels Version 1 Revision 1
Signalling Links Logical Channels
The addressing of each Radio Channel Unit DRCU/TCU as well as the Base Transceiver
Processor (BTP) and MCU is made using separate Terminal Endpoint Identifiers (TEI).
The Layer 2 protocol over the A-bis interface is based on Link Access Procedure
D-channel (LAPD). There are different logical channels used for traffic management
messages, these different logical channels are addressed using the Service Access Point
identifier (SAPI) which forms part of the Layer 2 address field.
The three logical links are defined for each TEI.
Radio Signalling Link (RSL) used for supporting traffic management procedures
(MS to Network communication).
Operations and Maintenance Link (OML) used for supporting Network
management procedures. One Link per DRCU/TCU and BTP/MCU.
Layer 2 Management Link (L2ML) used for transferring Layer 2 management
messages to DRCU/TCU or BTP/MCU.
Only point to point signalling links are used.
Radio Signalling
Link (RSL)
In every message, there is a message discriminator which is used to distinguish between

transparent messages and non-transparent messages. The discriminator also defines
the message group type.
Radio Link Layer Management
Dedicated Channel Management
Common Channel Management
TRX (Transceiver) Management
Transparent
Messages
Transparent messages are used to convey Layer 3 messages to/from the radio interface
for which the BSC and BTS has no specific action.
These messages are defined in the GSM air-interface 04.08 and are referred to as Direct
Transfer Application Part (DTAP).
Layer 2
Management
Link (L2ML)
This link is used by the BSC/BTS to carry reconfiguration and management messages.

Version 1 Revision 1 Signalling Links Logical Channels
Logical Channels
Logical channels BTS

BSC
DRCU/TCU/SCU
1 x 64 kbit TS TEI
003
BSP
TEI = 0
DRCU/TCU/SCU
TEI
002
BTP/MCU
TEI
RSL (SAPI 0) 001
LTML (SAPI 63)
OML (SAPI 62)
SYS01_5_11

Layer 2 – Link Access Procedure LAPD Version 1 Revision 1
Layer 2 – Link Access Procedure LAPD
Introduction
This bit orientated data Link access protocol is a subset of High Level Data Link Control
(HDLC) using the standard frame structure, with a ISDN address field layout.
Specification GSM 08.56. (ITU–TS Recom Q.921)
The basic functional content of the Layer 2 protocol is shown opposite:
This is achieved by the passage of messages over the data link, normally called frames,
which uses a standardised structure. There are three different frame types:
Information (I) frame – used for the passage of messages both control and
signalling data.
Supervisory (S) frame – used to maintain the link and flow control.
Unnumbered (U) frame – used to establish the link (Layer 2 alignment)

Version 1 Revision 1 Layer 2 – Link Access Procedure LAPD
Link Access Procedure D-channel (LAPD)
&$

'&!%+0+&0'&!%+ !+ /) #!%"* )**!% &+

' /*!# %+!+!* % ,%+!&%# %+!+!*
*! ,%+!&%* &) **!%$%+ % $%$%+
*! ')!&)!+/ ,%+!&%*
*! *,')-!*!&% & #!%"* . % %&+ ))/!% +)!
*(,% &%+)&#
+)%*$!**!&% ))&) &%+)&#
&%+)&# ))&)* %&+ )&-)# / )+)%*$!**!&%

Frame Structure
The signalling information is passed by the LAPD protocol mechanism utilising a
common frame structure.
Each of the three different frames conform to this common frame structure, where each
frame consists of a number of fields each of which is defined to cover the various
functions of the interface protocol
Definition of
Fields
Flag
The Flag pattern (01111110) denotes the start and end of each frame. The end flag can
act as the start of the next frame providing it follows on immediately. The receiver will
always assume that a flag pattern followed by a non flag pattern signifies the beginning of
another frame.
To prevent occurrence of this pattern within the frame a bit-stuffing technique is
employed. This technique inserts an extra ‘0’ after any 5 consecutive ‘1’s detected at
the transmitter, the receiver removes this extra ‘0’ by a process called ‘bit-stripping’.

Frame Structure – Flag
Information Type Frame
8 16 Var 8/16 16 8
Frame check Information

Flag Control Address Flag
sequence (Layer 3)
0 1 1 1 1 1 1 0
Unique Pattern
0 1 1 1 1 1 1 0 – defines beginning and/or end of frame SYS01_5_13

Address Field
The address field identifies the intended receiver within a command frame, and the
transmitter of the response frame, the format of the address field is shown opposite:
This field contains: address field extension (EA) bits; a command/response indication
(C/R) bit; a data link layer Service Access Point Identifier (SAPI) subfield and a Terminal
Endpoint Identifier (TEI) subfield.
The address field can be made up of more than one octet, to indicate this the first bit of
each octet is set to 0, indicating that this is not the final octet. The presence of a 1 in the
first bit of any octet signals that this is the final octet of the address field.
Command/response field bit (C/R): identifies the frame as either a command or response
frame.
Service Access
Point Identifier
(SAPI)
The SAPI identifies a point at which data link layer services are provided and
consequently the Layer 2/3 boundary.
The following SAPI’s are defined for use on the A-bis interface.
SAPI 0= Call control procedures (normally referred to as the RSL)
SAPI 62= Operation and Maintenance procedures (OML)
SAPI 63= Layer 2 management procedures (L2ML)
Terminal
Endpoint
Identifier (TEI)
The TEI identifies a unique function or element within the BSS.

Address Field Format
Frame check
Flag Information Control Address Flag
sequence
EA = Address field extension bit –

“1” signifies end of address field
C/R = Command/response field bit –
“1” – command, “0” = response
SAPI = Service Access Point Identifier
(Valid SAPIs 0, 62, 63)
Octet No 3 Octet No 2
TEI = Terminal Endpoint Identifier
EA EA
TEI SAPI C/R 0
1
SYS01_5_14

Terminal
Endpoint
Identifier (TEI)
The TEI for a point-to-point system is the physical address of a single terminal
equipment. Within the A-bis interface the address indicates the base station master
GPROC (BTP)/MCU, the DRCUs/TCUs at the BTS site and the BSP at the BSC.
Within the Motorola system a single BSC can control upto 40 BTS sites, where each site
must be equipped with a BTP. This BSC can only support a maximum of 50 BTPs/MCU.
Each DRCU/TCU and BTP/MCU would require its own TEI address.
TEI Allocation
The TEI number is assigned when the BSC is initialised and is part of the database set
up. The TEI’s are allocated in the same order as they are equipped in the database.
Example: A BSC controls two remote BTS’s, site 1 and site 2. Site 1 has 3 active
carriers and site 2 has 1 active carrier.
TEI Allocation


TEI Allocation
Assigned when BSC initialized

TEIs allocated as equipped in database
BSC
BSP
Site 1
BTP/MCU
DRCU/TCU/SCU BTP/MCU
DRCU/TCU/SCU DRCU/TCU/SCU
DRCU/TCU/SCU
SYS01_5_15

Control Field Version 1 Revision 1
Control Field
This field identifies the type of frame which can be either a command or a response.
Send sequence number N(S): Only Information (I) frames contain N(S) which is the
number of each transmitted frame.
Receive sequence number N(R): All Information frames and supervisory frames
contain N(R), the expected send sequence number of the next received Information
frame. The value of N(R) also indicates it has correctly received all information frames
numbered up to and including N(R)– 1
All frames contain the Poll/Final (P/F) bit. The P/F bit serves a function in both
command and response frames. In command frames it is a P bit and response as a F
bit. When set to a 1 in either cases indicates a command or response required.
On the A-bis interface, Motorola uses the modulo 128 version of LAPD.

Version 1 Revision 1 Control Field
Control Field
(2 octets)
Frame check
Flag Information Control Address Flag
sequence
Bit positions 8 7 6 5 4 3 2 1
(INFORMATION) Octet
N(S) 0 4
I–frame
N(R) P 5
(SUPERVISORY)
0 0 0 0 0 0 0 1 4
RR C/R
N(R) P/F 5
0 0 0 0 0 1 0 1 4
RNR C/R
N(R) P/F 5
0 0 0 0 1 0 0 1 4
C/R
REJ N(R) 5
P/F
(UNNUMBERED)
SABME 0 1 1 P 1 1 1 1 4 C
DM 0 0 0 F 1 1 1 1 4 R
UI 0 0 0 P 0 0 1 1 4 C
DISC 0 1 0 P 0 0 1 1 4 C
UA 0 1 1 F 0 0 1 1 4 R
C = Command
R = Response
N(S) = Transmitter send sequence number
N(R) = Transmitter receiver sequence number
P/F = Poll bit (P) when as a command

Final bit (F) when as a response
SYS01_5_16

Unnumbered Frames Version 1 Revision 1
Unnumbered Frames
There are a number of different unnumbered frames which are used within the link
alignment procedure.
Set
Asynchronous
Balanced Mode
Extended
(SABME)
Command
The SABME command is used to place the addressed user side or network side into a
modulo 128 multiple frame acknowledged operation. Upon acceptance of this command
both N(S) and N(R) counter will be reset to 0.
Disconnect
(DISC) Command
The DISC command is transmitted in order to terminate a multiframe operation. Either
end can generate a DISC command, but only activate the command after receipt of
either an UA or DM response.
Unnumbered
Information (UI)
Command
Sent when unacknowledged Information Transfer is requested.
Unnumbered
Acknowledgment
(UA) Response
The UA unnumbered response is used to acknowledge the receipt and acceptance of the
mode setting commands (SABME or DISC).
Disconnected mode (DM) response
The DM unnumbered response is used to report to its peer-protocol that multiframe
operation cannot be performed.

Version 1 Revision 1 Unnumbered Frames
Types of U Frame used on the A-bis Link
!


Alignment Procedures Version 1 Revision 1
Alignment Procedures
Once the common bearer (2 Mbit/s) link has achieved synchronisation and checked the
BER rate, the link will initiate a request for multiple frame operation, e.g. Layer 2
alignment. This is set by one end transmitting a SABME command.
This condition causes timer T200 to be started, all existing conditions to be cleared and
the retransmission counter (N200) to be reset.
The distance end receiving this SABME command and is able to enter the multiframe
establish state (e.g Link alignment) will respond with a UA frame, reset the sequence
counter to zero (N(S), N(R)).
On receipt of this UA frame, T200 is reset and sequence counters N(S), N(R) are reset
to zero
Now the link is available for information frames to be transmitted.
If timer T200 expires before receiving the UA frame, then the SABME is retransmitted
and T200 is reset. Also retransmission counter N200 is incremented by a count of 1. If
N200 reaches its maximum value then link is passed back to Layer 1 e.g.
resynchronisation.
Layer 2 timers
T200: This is the maximum time allowed without frames being exchanged.
(eg. acknowledgment of SABME)
Typical Value= 1 second
However Motorola allow this value to be increased to 2.5 seconds when BTS to BSC
links have long propagation delays.
Timer T203
This timer is the maximum time allowed without a frame being exchanged for each TEI.
On an idle link, this will cause an RR frame to be transmitted as a sanity check.

Version 1 Revision 1 Alignment Procedures
Layer 2 Alignment
Successful
BTS 2 Mbit/s Link BSC

SABME
T200 started/N200=0 N(S)=0/N(R)=0
T200 Stopped UA
N(S)=0 (N(R)=0
T200/T203 I FRAME
both started
T200 Reset I FRAME

T203 Reset
Unsuccessful
BTS BSC
SABME
T200 started/N200=0
Not received or
not in synchronization
T200 Expires
N200 Incremented (N200=1) SABME
T200 started
SYS01_5_18

Supervisory Control Version 1 Revision 1
Supervisory Control
The other feature of the control field is to control the sequencing of frames and perform
supervisory control. To do this there are four possible supervisory frames, only three are
used on the A-bis interface.
Receive Ready (RR) command/response

Indicates ready to receive Information (I) frames.
Acknowledges previously received I frames numbered upto and including N(R)–1
Clears a busy condition
Receive not Ready (RNR) command/response

Indicates a busy condition; e.g. a temporary inability to accept additional I frames.
Acknowledges all frames up to N(R)–1
Reject (REJ) command/response

The REJ frame is used to request retransmission of I frames starting with the
frame numbered N(R). All new I frames are held until acknowledgment of the
retransmission frame.
Each I frame increments the N(S) sequence counter, before being transmitted
however the control field only has 7 bits to indicate this number, thus it is restricted
to a count of 0–127. This then is the maximum number (k) of sequentially
numbered I frames that may be transmitted at a given time, before
acknowledgment of one frame is required. To enable the transmission of further I
frames, the distance end must reply with either an I frame or a RR frame with the
appropriate N(R) set.
To avoid infinite loop situations. Retransmissions are limited to a maximum value
(N200) and the maximum wait time to wait for any response (T200).

Version 1 Revision 1 Supervisory Control
Supervisory Control
2 Mbit/s Link
BTS BSC
N(R) N(S)
I Frame
0 0
I Frame
0 1
I Frame
0 2
N(S) N(R)
CLEAR BUFFER OF RR NEXT MSG
– 2
Msg 0 + Msg 1 EXPECTED
I Frame
0 2
I Frame
1 3 – Ack Msg 0
REJ REJECT
– 2 MSG NO2
I Frame Retransmission of
1 2
msg No2
I Frame Retransmission of
1 3
msg No3
Acknowledges RR NEXT Msg

– 4
Msg 2 and Msg 3 EXPECTED
(msg 0+1 already

Acknowledged)
SYS01_5_19

Layer 2 – Link Access Procedure LAPD
Frame Check
Sequence (FCS)
Field
The frame check sequence is a 16 bit cyclic redundancy check which is performed on the
bits found in the following fields:
Address
Control
Information
The FCS is used to detect the presence of errors resulting from transmission. The
ITU–TS defined D+CRC is x16 + x12 + x5 + 1 using this polynomial code we can catch all
single and double errors, all errors with an odd number of bits. All burst errors of length
16 or less, 99.997% of 17 bit error bursts, and 99.998% of 18 bit and longer bursts.
The following method is used to calculate the FCS:
M(x) Message to be transmitted polynomial
G(x) Generator polynomial (x16 +x12 + x5 + 1, CRC)
xk The highest polynomial value in the Generator polynomial
Formula: M(x) . xk
G (x)
The result of this calculation will be a whole number and a remainder (16 bits or less) the
remainder is the FCS which is transmitted to the distant end. At the distant end the Rx
adds the FCS to the Rx message and divides the result by G(x) the answer should equal
0 (no errors) if the answer results in any other value then the frame is rejected.

Frame Check Sequence
ITU–TS – CRC
16 12 5
x +x +x +1
k
M(x) . x
Formula: = whole number + remainder
G (x)
Note:
The remainder is 16 bits or less.
The remainder is Tx as the FCS to the distant end.
SYS01_5_20

Layer 3 Model Version 1 Revision 1
Layer 3 Model
All messages between the BSC and BTS are composed of a number of elements.
The Layer 3 message is formatted as shown opposite.
Executive Header – This is Motorola defined and is Motorola confidential.
Discriminator – Transparent/non-transparent, Radio Link Layer
Management, Dedicated Channel Management,
Common Channel Management, TRX Management
messages and Motorola defined internal messages.
Message Type – The message type is sent with all messages and
uniquely identifies the function of the message being
sent. It is a single octet in length.
This element is defined by either GSM recs. 08.58 or
Motorola.
Information Elements – The information elements are of variable length, the
first octet is called the element identifier this is again
either defined by GSM recs. 08.58 or by Motorola.
Motorola due to their implementation of the BSS functionality do not use a large
proportion of the GSM defined 08.58 messages across the RSL. A list of messages
defined by Motorola and passed across the RSL are shown in Annex A.

Version 1 Revision 1 Layer 3 Model
Message Structure
Frame check
Flag
sequence
Information Control Address Flag L2
Motorola information
elements or A-bis 08.58
messages and/or Message Motorola executive
complete L3 information
Message type
discriminator message header
L3
for transparent messages
(04.08)
Transaction identifier
Information elements Message type Protocol discriminator
or skip indicator
Complete L3 Info as defined in TS GSM 04.08 or TS GSM 08.58

SYS01_5_21

Complete Layer 2/Layer 3 Message Example (A-bis Defined) Version 1 Revision 1
Complete Layer 2/Layer 3 Message Example (A-bis Defined)

As an example of a message on the A-bis link we will look at the CIPHERING MODE
COMMAND which is sent from the MSC to the MS to start ciphering. This message
cannot be sent as a TRANSPARENT message as would be expected but is sent as a
NON-TRANSPARENT message as the BTS requires some of the information to enable
ciphering at the BTS.
Due to this fact the CIPHERING MODE COMMAND is replaced on the A-bis by
ENCRYPTION COMMAND (TS GSM 08.58, section 8).
The ENCRYPTION COMMAND fits in the Layer 2 message in the information field and is
formatted:
Encryption
Command
This message is sent from BSC to BTS to start ciphering mode operation

#//%# "'/!.'*'+0,.
#//%# 02-#
&++#) +1* #.
+!.2-0',+ '+$,.*0',+
'+( "#+0'$'#.
+$,
The L3 Info element contains the complete Ciphering Mode Command message as
defined in Technical Specification GSM 04.08.
Note:
On the Motorola A-bis the CIPHERING MODE COMMAND from the MSC is replaced
with a CIPHERING REQUEST. The definition of the Information elements of this
message are either defined by Motorola or TS GSM 08.08:

#//%# 2-# ,0,.,)

#$#.#+!# 1* #. ,0,.,)
2#. #"#. +$,.*0',+

+!.2-0',+ +$,.*0',+
+


L2/L3 Message Example (GSM A-bis)
MOTOROLA LTD. 2001–2
SAPI identifier Algorithm identifier Which channel ENCRyption Dedicated channel
and channel type and key the message is CoMmanD management
(FACCH/SDCCH) to be sent to message
(SACCH) (non-transparent)

6 octets 2 octets > =3 octets 2 octets 1 octet 1 octet
L3 information
(cipher mode command) Link identifier Encryption information Channel number Message type Message discriminator
2 octets
N(R) P N(S) X
Complete Layer 2/Layer 3 Message Example (A-bis Defined)

SYS01: GSM Interfaces
2 octets 2 octets
EA EA
TEI 1 SAPI C/R
0
Flag Frame check Information Control Address Flag

sequence (Layer 3)
1 octet 2 octet “n” octets 2 octets 2 octets 1 octet

SYS01_5_22
5–45
Complete Layer 2/Layer 3 Message Example (A-bis Defined) Version 1 Revision 1
Message
Discriminator
A 1 octet field is used in all messages to discriminate between Transparent and
Non-Transparent messages and also between Radio Link Layer Management, Dedicated
Channel Management, Common Channel Management and TRX Management
messages.
The T-bit is set to 1 to indicate that the message is to be/was considered transparent by
BTS. All other messages shall have the T-bit set to 0.
The G-bits are used to group the messages as follows:
G7 G6 G5 G4 G3 G2 G1 T Message Group
0 0 0 0 0 0 0 – reserved
0 0 0 0 0 0 1 – Radio Link Layer Management
messages
0 0 0 0 1 0 0 – Dedicated Channel
Management messages
0 0 0 1 0 0 0 – TRX Management messages
0 0 0 0 1 1 0 – Common Channel
Management

Version 1 Revision 1 Complete Layer 2/Layer 3 Message Example (A-bis Defined)
Message Structure
Frame check
Flag Information Control Address Flag L2
sequence
Motorola
information elements
or GSM 05.58 messages Motorola
Message Executive message
or Type
discriminator header
Complete L3 information
(04.08)
G7 G6 G5 G4 G3 G2 G1 T
SYS01_5_23

Message Type Version 1 Revision 1
Message Type
The message Type uniquely identifies the function of the message being sent. It is a
single octet in length. The following are GSM defined A-bis messages.
Bit 8 is the extension bit and is reserved for future use. The following Message Types
are used (all other values are reserved):

)44%*)
%(,1 ,0- %9)3 %0%*)/)05 /)44%*)4
6)45
,'%5,10
,'%5,10
%&.,4+ 6)45
%&.,4+ ,3/
%&.,4+ ,'%5,10
)%4) 6)45
)%4) ,3/
)%4) ,'%5,10
6)45
,'%5,10
1//10 +%00). %0%*)/)05
3/%5,10
,'%5,10
0). )6,3)
,'%5,10
1//%0

31%(%45 6)45
31%('%45 1/%0
# %0%*)/)05 )44%*)4

163') ,'%5,10
,0*
!

)(,'%5)( +%00). %0%*)/)05 /)44%*)4

0). !%5,10
0). !%5,10 018.)(*)
0). !%5,10 )*%5,7)
)'5,10 63)
!
925,10 1/%0
7)3 )'5,10
63)/)05 6.5
$ 6)45
$ 018.)(*)
$ )*%5,7) 018.)(*)
$4,'%. # 6)45
$4,'%. # ,3/
0). )%4)
"
"
)44)( 63)
)44)( 63)/)05 6.5
0). )%4) 018.)(*)

Version 1 Revision 1 Message Type
Message Structure
Frame check
Flag Information Control Address Flag L2
sequence
Motorola
information elements
or GSM 08.58 messages Motorola
Message
or Type Executive message
discriminator
Complete L3 information header
(04.08)
EM Message type
SYS01_5_24


The best way of understanding the interface procedures is to examine the common
message sequence scenarios, which highlight the flow of messages between the MSC,
BSC, BTS and MS.
The messages between the MSC and BSC are defined within the A-interface (TS GSM
08.08) and will be covered later in the course.
The messages between the BSC and the BTS are defined within the A-bis interface (TS
GSM 08.58).
The messages between the BTS and MS are defined within the Air-interface (TS GSM
04.08).
The messages between the MSC and MS, referred to as Direct Transfer Application Part
(DTAP) are transparent to the BSS. These messages/procedures will be covered later in
the course so are not shown.
The main message sequence scenarios are shown:
Mobile Originated Connection Establishment; there are three different scenarios,
successful, rejected by MSC and no radio resources available.
Traffic Assignments four scenarios, successful, failure, Queued and T11 expiry.
Handover procedures: These procedures are defined for both source and target
cell for successful and failed. Also defined in intra-BSS handovers.
Global Reset: Complete reset at either end.



Global Reset
The Global Reset procedure on the A-bis interface is always initiated by the BSC. This
however can be as a result of the BSC receiving a Global Reset command from the
MSC.
The Global Reset is when the BSC has to completely reboot all of its process procedures
and as a consequence, cause each BTS to be taken out of “Call Process” and if need be
rebooted.
If it is the case that each BTS site has to reboot then each must re-register to the BSC.
This procedure is the BTS site indicating to the BSC that each of its cells are in “Call
Processing” mode and is capable of supporting traffic.

Global Reset
BSC BTS
Global
Reset Halt BSS
Halt BSS
Acknowledge
Global Reset
Global Reset
Reboot
Acknowledge
Register
Register Acknowledge Call process

available
Start BSS
Start BSS Traffic

Acknowledge available
SYS01_5_26

Mobile Originated Connection Establishment Version 1 Revision 1
Mobile Originated Connection Establishment

After the BSC and the BTS have completed the registration procedure, calls can be
established.
This is initiated by the Mobile transmitting an Access Burst on the appropriate Common
Control Channel (CCCH). If the Mobile is detected by the BTS, this will generate the
immediate Assignment message and send it over the Access Granted Channel (AGCH).
This control tells the mobile on which Standalone Channel (SDCCH) the rest of the cell
setup procedure will take place.
The Mobile will establish contact on the SDCCH by transmitting a SABM LAPDm frame
containing the DTAP message “CM Service Request”. The BTS carries out two actions.
Send a UA LAPDm frame back to the Mobile.
Generate the “Initial Layer 3 Info” message containing the DTAP message “CM
Service Request” and sends it to the BSC.
It is at this stage that the BSC initiates the connection to the MSC using SCCP
procedures (these will be covered later in the course).
After the connection is made, the MSC can command the Mobile to go to “cipher” mode,
before the rest of the setup procedure is carried out. These other procedures use the
DTAP messages across the A-bis interface and are passed as transparent messages.

Version 1 Revision 1 Mobile Originated Connection Establishment
Mobile Originated Connection Establishment
A interface Mobis LAPDm

MSC BSC BTS MS
Access Burst
SABM
<CM Service Request>
Initial Layer 3 Info
<CM Service Request> UA
SCCP Connections Request
<CM Service Request>
SCCP Connections Confirm
Cipher Mode Command

Ciphering Request
Ciphering Mode Complete
Ciphering Successful Ciphering Mode Complete

Cipher Mode Complete
SET–UP
DTAP <SET-UP>
DT1 <SET-UP>
DT1 <Call Proceeding>

DTAP <Call Proceeding>
Call Proceeding
SYS01_5_27

Traffic
Assignment
Procedures
The traffic assignment procedure is initiated by the MSC sending the Assignment
Request message to the BSC.
This message will contain the type of channel required; classmark of the MS; the timeslot
(traffic channel) on the BSC–MSC link.
The BSC request the BTS to allocate it a traffic channel.
It also starts a timer (assign_successful) which sets the maximum time the BSC will wait
for a reply. If this expires before receiving the Assignment Successful message, it will
generate and Assignment Failure message back to the MSC.
The BTS site after assigning the traffic channel will generate the “Assignment Command”
message and transmits this to the mobile via the SDCCH. It will also start a timer
(bssmap_t10) which is the maximum time the BTS will wait for the mobile to establish
contact on the new traffic channel. This timer is stopped on receipt of the “Assignment
Complete” message from the mobile.
The BTS then generates the “Assignment Successful” message to the BSC and stops
assign_successful.

Traffic Assignment Procedures
Successful
MSC BSC BTS MS
Assignment Request
Information
i.e. Type of channel required
Classmark of the MS
The timeslot Initiate Assignment
Timer
assign_successful
Assignment Command
Timer
bssmap_t10
Assignment Complete
Assignment Successful
Assignment Complete
SYS01_5_28

Traffic Assignment Procedures Version 1 Revision 1
Traffic Assignment Procedures
Request Queued
– T11 Expiry
Upon receipt of the Assignment Request message from the MSC the BSC sends an
Initiate Assignment message to the BTS, if the BTS supports queuing and no resources
are currently available then the BTS will send an Assignment queued message back to
the BSC to indicate that no resources are currently available and the request is queued.
Upon queuing of the Initiate assignment command the BTS starts timer T11
(bssmap_t11) if resources do not become available before T11 expires then a Release
Request message is sent to the BSC, the BSC will then initiate the release of the channel
resources already in use (SDCCH).

Version 1 Revision 1 Traffic Assignment Procedures
Traffic Assignment Queued – T11 Expiry
MSC BSC BTS MS
Assignment Request
Initiate Assignment
Assignment Queued
T11 started
bssmap_t11
Queueing Indication
Release Request
T11 expires
Clear Request
Clear Command
Release Radio Channel
Channel Release
Radio Channel Released
Clear Complete
SCCP Release
SCCP Release Complete
Deallocate SCCP Number
SYS01_5_29

Successful
Intra-BTS
Handover
During a call the MS sends at least one Measurement Report (MR) per second to the
BTS, the MR reports on the best six neighbours and the serving cell. The BTS will
evaluate these MR’s and based upon database values will generate a Handover
Recognised message to the BSC.
When the BTS generates the Handover Recognised message it starts a timer (1), this
timer is the maximum time the BTS will wait for a response before it will generate another
Handover Recognised Message (provided the same cause for the handover exists).
From the Handover Recognised message (this contains a list of the preferred target
cells for a handover) the BSC will select a target BTS and generate an Internal
Handover Request message to the target BTS. The Internal Handover Request
message asks the target BTS to supply a traffic channel. The BSC will also start timer
(2) on issue of the Internal Handover Request message as this is the maximum time
the BSC will wait for the BTS to respond.
The target BTS will respond (providing there is a traffic channel available) with a
Handover Allocation message. the target BTS will now start timer (3), this timer sets
the maximum time the BTS will keep the traffic channel assigned for this handover.
Upon receipt of the Handover Allocation message the BSC will stop timer (2) and issue
a Initiate Handover message to the source BTS and start timer (4). This timer is used
to set the maximum time the BSC waits for an internal handover to complete.
Upon receipt of the Initiate Handover message the source BTS will stop timer (1) and
issues a Handover Command to the MS and start timer (5), this timer sets the
maximum time the source BTS will wait for a successful handover message.
The MS will attempt to establish on the new traffic channel on the target BTS, once the
target BTS detects the MS it generates a Handover Detect message to the BSC. Upon
receipt of a Handover Complete message from the MS the target BTS stops (3) and
issues a Handover Successful message to the BSC.
The BSC on receipt of the Handover Successful message will stop timer (4) and
generate a Handover Performed message to the MSC and a Blast message to the
source BTS to clear down the resources held there.

Handover – BTS to BTS (intra-BTS)
MS BTS BSC BTS BTS
Measurement Report
Timer (1) Handover Recognized
Timer (2) Internal Handover
Request
Handover Allocation Timer (3)
Initiate Handover Timer (4)
Timer (5) Handover Command
Handover Access
Handover Detect
Handover Complete
Handover Successful
Handover Performed
BLAST
SYS01_5_30

Successful Inter-BSC Handover Version 1 Revision 1
Successful Inter-BSC Handover

If after the Handover Recognised message has been passed to the BSC, the target BTS
(cell) is not under control of the same BSC then a External Handover is required,
normally referred to as a inter-BSC handover.
The procedure is the same, but some extra messages are generated with different timers
used. This is due to the extra time required to send/acknowledge these messages both
on the A-bis (BTS–BSC) interface and A-Interface (BSC to MSC).
The diagram opposite shows the complete sequence at each side of the handover.

Version 1 Revision 1 Successful Inter-BSC Handover
Handover – Inter-BSC (Source Cell)
BTS BSC MSC BSC BTS MS
MR
H/O REC
H/O REQ
SCCP CR
H/O REQUEST H/O REQUEST
H/O ALLOC
SCCP CC
H/O REQUEST ACK H/O COMMAND
INITIATE H/O
H/O COMMAND
H/O ACCESS
H/O DETECT
H/O DETECT
H/O COMPLETE
H/O
SUCCESSFUL
H/O COMPLETE
CLEAR
COMMAND
BLAST
SYS01_5_31

Successful Inter-BSC Handover Version 1 Revision 1

Appendix A
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5–i

BSC to BTS Interface Message Types Version 1 Revision 1
BSC to BTS Interface Message Types

Part A – Message Types as Defined and Implemented by Motorola
BSC to BTS
Messages
1. Audit Call
Description: This message is sent periodically per cell between the BSC and BTS
to verify that the call is still active at the other side of the link. The information in
this message is compared with the local information to verify that the BSC and
BTS have consistent call data.
2. Audit RRSM Call Response
Description: This message is sent in response to an Audit Call message.
3. Blast Command
Description: This message is sent to the BTS after an internal handover, to tear
down the dedicated channel resources on the source cell if the handover is
successful or the destination cell if the handover procedure fails. Upon receipt of
this message, the call is released at the BTS and no response is returned to the
BSC.
4. BSS Status
Description: This message is sent to inform the BTS is the BSS BSSMAP
subsystem goes into service or out of service.
5. Ciphering Request
Description: This message is sent to initiate ciphering when a Cipher Mode
Command is received from the MSC.
6. Deallocate SCCP Reference Number
Description: Upon receipt of this message the BTS will mark the given SCCP
reference number as unused.
7. Global Reset
Description: This message is sent to the BTS so that it can reset its state tables
after a global reset.
8. Halt BSS
Description: This message is sent by the BSC when it wishes to halt call
processing activities due to a global reset.
9. Handover Request
Description: This message is sent from the MSC to the BSS to indicate that a
mobile is to be handed over to that BSS. The BSC sends this message to the
BTS if it is contained in the data field of the SCCP Connection Request message.
10. Information Request
Description: This message is sent to the BTS to request information about the idle
resources when Resource Request message is received from the MSC.
11. Initiate Assignment
Description: This message is sent to the BTS upon receipt of an Assignment
Request message from the MSC.
5–ii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 Part A – Message Types as Defined and Implemented by Motorola
12. Initiate Handover

Description: This message is sent to the BTS which manages the source cell of a
handover and includes the allocated destination channel information to be sent to
the MS.
13. Initiate Intra-Cell Handover
Description: This message is sent to the BTS in order to initiate the intra-cell
handover procedure.
14. Internal Handover Initiated Acknowledge
Description: This message is sent to the BTS in response to an Internal handover
Initiated message. This message is used to avoid race conditions that may result
if the MSC initiates a procedure at the same time as the BTS initiates an internal
intra-cell handover.
15. Internal Handover Request
Description: This message is sent to the destination cell BTS in an intra-BSS
handover. The BTS allocates the requested resources.
16. MSC Status
Description: This message is sent to the BTS to inform is of the state of the SCCP
Layer or BSSAP Subsystem at the MSC.
17. Page mobile Request
Description: This message is sent to the BTS to instruct it to send a Paging
Request message when a Paging message is received from the MSC.
18. Register Acknowledge
Description: This message is sent to the BTS to acknowledge registration.
19. Release Radio Channel
Description: This message is sent to the BTS to acknowledge registration.
20. Remove From Queue
Description: This message is sent to the BTS when a Handover Request
message has been queued and guard timer (Tqho) has expired. The BTS
removes the request from the queue and the handover procedure is aborted.
21. Start BSS
Description: This message is to the BTS to allow call processing activities to start.
22. Trace Request
Description: This message is to the BTS when data is required for call trace.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5–iii

Part A – Message Types as Defined and Implemented by Motorola Version 1 Revision 1
BTS to BSC
Messages as
Defined and
Implemented by
Motorola
1. Assignment Queued
Description: This message is sent to the BSC when an assignment request has
been queued by the BTS.
2. Assignment Successful
Description: This message is sent to the BSC when an Assignment Complete is
received from the MS.
3. Audit Call
Description: This message is sent periodically per call between the BSC and BTS
to verify that the call is still active at the other side of the link. The information in
this message is compared with the local information to verify that the BSC and
BTS have consistent call data.
4. Audit SSM Call Response
Description: This message is sent to the BSC in response to an audit call
message.
5. Call Trace Response
Description: This message is sent to the BSC containing trace data that has been
collected at the BTS.
6. Ciphering Successful
Description: This message is sent to the BSC upon receipt of the Cipher Mode
Complete message from the MS.
7. DTAP Message
Description: This message is used to transfer a DTAP message internally
between the BTS and the BSC in either the uplink or downlink direction. Please
note that the DTAP message can be any DTAP message defined in GSM
Recommendation 4.08.
8. Global Reset Acknowledge
Description: This message is sent in response to a Global Reset message to
inform the BSC that all tables at the BTS have been reset.
9. Halt BSS Acknowledge
Description: This message is sent to the BTS to acknowledge that all call
processing activities at the BTS have been stopped.
10. Handover Allocation
Description: This message is sent to the BSC when a resource has been
allocated for an external or internal handover.
11. Handover Detect Received
Description: This message is sent to the BSC when the BTS receives the
handover Access message from the MS. The BSC then sends the Handover
Detect message to the MSC.
5–iv SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 Part A – Message Types as Defined and Implemented by Motorola
12. Handover Failure

Description: This message is contained in the data field of the Connection refused
SCCP message. This message is forwarded to the MSC from the BSC. it
indicates to the MSC that there has been a failure in the resource allocation
process on handover and that the handover has been aborted.
13. Handover Recognised Received
Description: This message is sent to the BSC when Measurement Report
messages from the MS indicate that the specified call requires a handover to a
new cell.
14. Handover Request Queued
Description: This message is sent to the BSC when a handover request has been
queued by the BTS.
15. Handover Resources Not Available
Description: This message is sent to the BSC if the BTS is unable to allocate the
requested resource for an internal handover.
16. Handover Successful
Description: This message is sent to the BSC when the MS has successfully
accessed the allocated radio channel on the destination cell of a handover.
17. Initial Layer 3 Information
Description: This message is sent to initiate a call at the BSC. The BTS sends
this message when the MS had established on a dedicated channel.
18. Internal Handover Initiated
Description: This message is sent to the BSC when the resources for an internal
handover have been successfully allocated.
19. Radio Channel Release
Description: This message is sent to the BSC to indicate that the allocated radio
channel has been released at the BTS.
20. Register
Description: This message is sent by the BTS to inform the BSC that the BTS is
available for call processing activities.
21. Release Request
Description: This message is sent to the BSC when the guard timer on an
assignment request queue times out before the requested resources become
available.
22. Resource Indication
Description: This message is contained in the data field of the UDT SCCP
message and forwarded directly to the MSC in response to a Resource Request
message from the MSC.
23. SCCP Number Assigned
Description: This message is sent to the BSC if an SCCP Connection Request is
received from the MSC without a handover request in the data field. The BTS
assigns an SCCP Reference number and sends it within this message to the BSC.
The BSC then sends an SCCP Connection Confirm to the MSC.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5–v

Part A – Message Types as Defined and Implemented by Motorola Version 1 Revision 1
24. Start BSS Acknowledge

Description: This message is sent in response to a request by the BTS to start call
processing activities.
25. Unsuccessful Assignment
Description: This message is sent to the BSC if the MS is unable to access the
allocated resources in an assignment procedure.
26. Unsuccessful Handover
Description: This message is sent if the MS re-establishes on the source cell after
an unsuccessful attempt to access the destination cell.
27. Update Classmark
Description: This message is sent to the BSC upon receipt of the Classmark
Change message from the MS.
5–vi SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 Part B
Part B
Message Elements
1) Message
Elements defined
by GSM 08.08
1. Circuit Identity Code
This element defines the terrestrial channel over which the call will pass. If a 2048
kbit/s digital path is used then the circuit identification code contains in the 5 least
significant bits of binary representation of the actual number of the timeslot which
is assigned to the circuit. The remaining bits in the CIC are used where
necessary, to identify one among several systems interconnecting an originating
and destination point.
2. Radio Channel Identity
In messages relating to the serving cell the element is coded as:
3. Resource Available
This element gives the number of full and half rate channels available on any given
cell at the time of construction of the message.
It identifies these parameters in terms of the number of channels available in five
interference bands, the boundaries of these bands being set by O & M.
4. Cause
The cause element is used to indicate the reason for particular event to have
occurred.
5. IMSI
The IMSI is coded as a sequence of BCD digits, compressed two into each octet.
This is a variable length element, and includes a length indicator. The end of the
element is indicated by a code 15, if this does not equate to an integral number of
octets in the message then a filter nibble will be added.
6. TMSI
The TMSI is a variable length element, and therefore contains a length indicator.
The TMSI is an unstructured number upto 4 octets in length, it is however an
integral number of octets.
7. Number of MSs
This is fixed length element which indicates the number of handover candidates
that will be sent to the MSC.
8. Layer 3 Header Information
This element is used to supply the BSS with information that needs to be included
in the header of Layer 3 messages over the radio interface.
9. Encryption Information
This element contains the user data encryption information used to control any
equipment at the BSS. It is variable length element.
10. Channel Type
This element contains all of the information that the BSS requires to determine the
radio resource that is required.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5–vii

Message Elements Version 1 Revision 1
11. Periodicity
This element defines the periodicity of a particular procedure is as follows:
12. Cell Identifier
The element uniquely identifies a cell within a BSS and is of variable length.
13. Priority
This element indicates the priority of the request.
14. Classmark Information Type 2
The classmark information type 2 defines certain attributes of the mobile station
equipment in use on a particular transaction.
15. Interference Band to be Used
A bit map indicating which interference bands are acceptable.
16. RR Cause
This fixed length element is passed from the air interface to the MSC transparently,
when received in a specification GSM 4.08 message.
17. Trace Number
A fixed length element giving a 16 bit binary reference number.
18. Complete Layer 3 Information
This is a variable element used to pass layer three messages from the air interface
to the MSC unchanged – it differs from the DTAP message because the BSS
analyses part of the message as it passes through the BSS, it is not therefore a
transparent message as such.
19. DLCI
This is a fixed length element indicating the channel on which the SAPI value over
the air interface that the transaction concerns.
20. Downlink DTX Flag
A fixed length element indicating whether the DTX function in the BSS is to be
disabled on a particular radio channel.
21. Resource Indication Method
This element defines the way the BSS shall transfer the resource information
related to a cell to the MSC.
22. Classmark Information Type 1
The classmark information type 1 defines certain attributes of the Mobile Station
equipment in use on a particular transaction. It is coded as follows:
5–viii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 Message Elements
2) Message
Elements defined
by GSM 08.58
1. Channel Number
The Channel Number is used to identify the physical channel/subchannel.
2. Activation Type
This element is used to indicate the type of activation requested in the Channel
Activation message.
3. L3 Information
This element contains a link layer service data unit (L3 message). It is used to
forward a complete L3 message between the RSS and Call Processing.
4. MS Identity
This element carries the identity of an MS (TMSI or IMSI). It is a variable length
element.
5. Paging Group
This element carries the paging population of an MS to be paged.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5–ix

3) Message
Elements defined
by GSM 04.08
1. Mobile Station Classmark 2
The purpose of the Mobile Station classmark 2 information elements is to provide
the Network with information concerning aspects of both high an low priority of the
MS equipment. This affects the matter in which the Network handles the operation
of the MS.
2. Channel Description
The purpose of the channel description information element is to provide a
description of an allocatable channel together with its SACCH. The channel
description is a type 3 information element with 4 octets length.
3. Mobile Allocation
The purpose of the Mobile allocation information element is to provide that part of
the RF channels belonging to the cell allocation (coded with a “1” in the cell
channel description information element) which is used in the mobile hopping
sequence. The Mobile allocation is a type 4 information element with 10 octets
length maximal.
5–x SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 Message Elements
4) Message
Elements defined
by GSM 04.08
1. SCCP Reference Number
The SCCP reference number is defined to be unique per call and is used by the
BSS to identify a call.
2. Local Cell Identifier
This element is used to identify the logical cell identity.
3. Transaction Number
This value is used in the Global reset message to keep track of the BTSs to which
a Global reset message has been sent. The process must respond with an
acknowledge which contains the same transaction number.
4. Carrier Number
This value is used to indicate the logical carrier number referenced.
5. Channel type
The channel type element is used to determine the type of channel request
queued.
6. Trace Data
This element contains an information element identifier, length of trace data
following and the trace data. This element is included in the trace response
message.
7. Interference Band
This element contains an information element identifier, and both requested and
current interference bands.
8. Audit Result
This element is included in the Audit Call Response message from the RRSM to
the SSM and vice versa to give the CRM reason for deallocating the channel.
9. MSC or BSS Status
This element is included in the MSC Status message from the BSC to the BTS to
give the BTS information on whether to send messages to the MSC or not.
10. Stats Cause
This element is included in the Radio Channel Released message to specify
whether an Assignment Command has been sent to the mobile before the radio
channel was released. This is used for stats collection purposes only.
11. Message Discriminator
The T-bit is set to 1 to indicate that the message is to be/was considered
transparent by the BTS. All other messages shall have the T-bit set to 0.
12. Message Type
The Message Type uniquely identifies the function of the message being sent.
13. Handover Cause
The field is included in handover recognised and Force handover fields. This field
is included to indicate the reason for initiating a handover for the specified mobile.
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5–xi

14. Candidate Cells

This field is included in the Handover Recognised message to indicate the
candidate cells for a handover.
15. Trace Mode
This field is included in Trace Request message.
5) Message
Elements defined
by Motorola
Motorola Confidential Proprietary
5–xii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Appendix B

BSC to BTS Interface (A-bis) Version 1 Revision 1
BSC to BTS Interface (A-bis)
Exercise
1. Construct the Layer 2/Layer 3 message which has to be transmitted on the A-bis
interface from the BSC to the BTS to page mobile subscriber (IMSI=
234101234567890). SAPI 0 is to be used and the TEI at the BTS is 3.
This message is the second to be transmitted on the A-bis for this link and the
BSC/BSP is acknowledging all messages upto and including message 5.
The timeslot (TN) for the paging message to appear on is TN 2. The mobiles
paging group is 4 (defined in TS GSM 05.02).
This transaction requires the use of an SDCCH.
For the purpose of this exercise the FCS is to be set at 1010111010111011.
2. Which message type will the BTS use on the A-bis link to the BSC in response to
the above command assuming the MS responds to the PAGING REQUEST?

Version 1 Revision 1 BSC to BTS Interface (A-bis)


BSC to BTS Interface (A-bis) Version 1 Revision 1

Chapter 6
BSC–MSC Interface (A-interface)


Chapter 6
BSC–MSC Interface (A-interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
BSC–MSC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
A-interface Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
A-interface specification objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
A-interface Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
GSM Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
08.0x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–4
A-Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–6
Signalling System No7 (C7) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Messages Transfer Part (MTP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–10
Level 2 Header Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
LSSU Status Field Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
Alignment Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
Alignment Status Indications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
Message Signal Unit (MSU) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Service Information Octet (SIO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–24
Signalling Information Field (SIF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Routing Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Signalling Connection Control Part (SCCP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Protocol Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
SCCP Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–30
Establishment Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
SCCP Message Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
SCCP Message Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–36
Called/Calling Party Address Parameter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–38
Radio Subsystem Application Part (BSSAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–40
BSSAP Message Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
DTAP Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
BSSMAP Header Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–46
Complete Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–48
BSS Management Application Part (BSSMAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
Normal Mobile Station (MS) to PSTN Call Set. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–52
Normal PSTN to MS Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–56
Call from PSTN to MS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–58
Blocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–60
Group Circuit Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–62
Unblocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–64
Resource Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–66
Resource Indication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–66
Global Reset Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–68
Reset at the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–68

Reset at the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–70

Reset Circuit at the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–72
Reset Circuit at the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–72
Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–74
Handover Candidate Enquiry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–76
Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–76
Procedures – Dedicated . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–78
Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–78
External Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–80
Handover Required Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–80
Handover Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–80
Handover Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–82
Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–84
Classmark Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–86
Cipher Mode Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–88
Initial MS Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–90
Queueing Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–92
Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–94
MTP Level 2 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–94
MTP Level 3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–94
BSSMAP Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–95

Version 1 Revision 1 BSC–MSC Interface
BSC–MSC Interface
Objectives
Identify the functions of the BSC–MSC Interface.
State the GSM Recommendations which apply to the A-interface.
Identify the Signalling Protocol Reference Model.
State the various parts of the CCITT signalling system Number 7.
– Message Transfer Part (MTP)
– Signalling Connection Control Part (SCCP)
Identify the procedure for SCCP establishment.
State the structure of the BSS Application Part (BSSAP).
Identify the Direct Transfer Application Part (DTAP) message type and structure.
Identify the BSS Management Application Part (BSSMAP) procedures.
Identify complete A-interface message flow.

Introduction Version 1 Revision 1
Introduction
A-interface
Capabilities
The BSS–MSC interface shall be capable of supporting all the services offered to GSM
users and subscribers. In addition it also allows for the allocation of suitable radio
resources within the PLMN, and the operation and maintenance of those resources.
A-interface
specification
objectives
The MSC to BSS interface specifications shall allow the following:
Connection of various manufacturers BSSs to the same MSC
The use of several manufacturers MSCs to the same type of BSS
The use of the same BSS in any PLMN
The use of the same MSC in any PLMN
The separate evolution of MSC and BSS technology, and
The separate evolution of O&M facilities
Support of all services defined in the GSM 02 series of Technical Specifications
A-interface
Characteristics
The interface is defined to be at the boundary of the MSC.
The MSC to BSS interface is specified by a set of characteristics, including:
Physical and electromagnetic parameters
Channel structures
Network operating procedures
Operation and Maintenance information support
The definition of the MSC to BSS interface follows a layered approach similar to that in
the ISDN. Layer 3 is for the most part based on Technical Specification GSM 04.08 with
additional procedures added for the control of radio resources and the identification of
transactions using the SCCP. Layer 2 is based on the signalling system No.7 (SS No.7)
Message Transfer Part (MTP). Layer 1 is either digital (at 2048 kbit/s, based on ITU–TS
Rec G703 section 6) or analogue with the data being passed by the use of modems (this
latter case is a national option).

Version 1 Revision 1 Introduction
MSC–BSS Interface (A-interface)
PSTN
MSC MSC BSS
A-interface
(2.048 Mbit/s)
MS
BSS
BSC
BTS BTS
MS MS
SYS01_6_2

GSM Specification Version 1 Revision 1
GSM Specification
08.0x
The A-interface is defined in the 08.0X series of GSM specification, which is designed to
support a wide range of possible architecture on both sides of the interface.
08.01 General Aspects
08.02 Interface Principle. This gives the functional split

between the BSC and the MSC
08.04 Layer 1 (2 Mbit/s)
08.06 Signalling Transport Mechanisms

(ITU–TS Signalling No7)
08.08 Layer 3 Specifications – BSSAP user part.

– BSSOMAP user part

Version 1 Revision 1 GSM Specification
GSM Specification – A-Interface

!

!

A-Interface Functions Version 1 Revision 1
A-Interface Functions
The A-interface provides facilities to the traffic channels and signalling Links for the
following functions:
Terrestrial management: allocation and blocking of terrestrial traffic channels.
Radio channel Management: BSS Management – radio channel
allocations/control.
Mobility Management: location update – transparency between the MS and
MSC.
Call Control: setup for Mobile originating/terminating calls.
Supplementary Services: transparency through the BSS.
The signalling is layered, similar to that in the OSI reference model, however the layers
referred to are not identical. They are specified by ITU–TS Signalling System No7 (C7).
Once a mobile is established on a channel, be it a traffic channel or control channel, all
signalling between the mobile and the MSC are transparent to the BSS software. All the
BSS software undertakes is to maintain the channel to the mobile, whilst passing on any
signalling to the mobile. The BSS software does not track the identity of a mobile.
CLM= Connectionless Manager

SSM= SCCP State Machine
SM= Switch Manager

Version 1 Revision 1 A-Interface Functions
MSC–BSC Interface
Intelligent
Network
Short
PSTN
Message
Service
HLR
MSC
(Call Control) VLR
Supplementary
Services (Mobility
Management)
2 Mbit/s
MTP
BSC CLM SSM SM
(Radio Channel Management)
BTS BTS
BTS
SYS01_6_4

Signalling System No7 (C7) Version 1 Revision 1
Signalling System No7 (C7)
Introduction
The objective of Signalling System C7 is to provide an internationally standardized
general purpose Common Channel Signalling (CCS) system which can:
Be optimized for operation in digital communications networks with stored program
controlled exchanges.
Meet present and further requirements regarding speed, flexibility to handle new
services such as ISDN
Provide a reliable means of transfer of information in correct sequence and without
loss or duplication.
The signalling system is optimized for operation over a 64kbit/s digital channel. It is also
suitable for operation over analogue channels at lower speeds and for point to point links.
The initial specification of C7 was based on circuit related telephony control requirements
and was specified in four functional levels, the MTP (Levels 1–3 Signalling Data Link,
Link control and Signalling Network) and the User Part (Level 4). As new requirements
have emerged, C7 has also evolved to meet these new requirements.
The first was an additional sublayer, added on top of the MTP (the Signalling Connection
Control Part SCCP) to obtain full OSI Layer 3 functionally.
The second is the addition of a common support function called Transaction Capabilities
(TC).
TC forms two elements; Transaction Capabilities Application Part (TCAP) and
Intermittent Service Part (ISP) (not yet defined). TCAP is a functional block residing
above the ISP. It supports the various TC users such as OMAP and MAP. (Operations,
Maintenance and Administration Part (OMAP) – Mobile Application Part (MAP)).
BSS OMAP: Operation and Maintenance Application Part
BSSAP: BSS Application Part which is sub-divided into two separate functions:
The Base Station Management Application Part (BSSMAP), which supports

procedures between the MSC and BSS related to the MS, or to a cell within the
BSS, or to the whole BSS.
The Direct Transfer Application Part (DTAP), used to transfer Call Control (CC)
and Mobility Management (MM) messages to/from the MS.

Version 1 Revision 1 Signalling System No7 (C7)
Signalling Protocol Reference Model
BSS side MSC side

A-interface
Other applications e.g. call control
To other processes Operation and

within the BSS Maintenance
information to
PLMN O & M
BSSAP BSSAP
To air interface
transmission DTAP BSS DTAP BSS
equipment MAP MAP
OSI
MODEL OML OML
Distribution function Distribution function
Layer 4–7
Layer 3
SCCP SCCP To other
users of the
SCCP and
Layer 1–3
MTP MTP MTP
Physical Layer
DTAP: Direct Transfer Application Part
BSSMAP: BSS Management Application Part
BSS OMAP: Operation and Maintenance Application Part
SCCP: Signalling Connection Control Part
MTP: Message Transfer Part
BSS: Base Station System
MSC: Mobile Services Switching Centre
SYS01_6_5

Messages
Transfer Part
(MTP)
Introduction
The MTP serves as a transport system for reliable transfer of messages between users.
It is broken down into three levels which equate to Layers 1–3 of the OSI model.
Signalling Data Link defines the physical, electrical and mechanical interface
requirements. (Recommendations ITU–TS Q.702). The standard signalling rate is
64kbit/s and the basic digital interface would be a 4-wire line using AMI/HDB3 encoding.
The signalling link being assigned to the time slot 16 in a 2048kbits digital path (this is a
typical assignment due to Motorola’s design of the XCDR Board. The MTL may reside
on any available TS).
Signalling Link Control defines the functions and procedures for the controlling of the
transfer of signalling messages over one individual signalling data Link (Recommendation
ITU–TS Q.703)
Signalling Network in principle defines these transport functions and procedures that
are common to and independent of the operation of individual signalling links
(Recommendation ITU–TS Q.704)
The functions fall in to two main categories:
Signalling Message Handling; which directs the message to the proper
signalling Link or User part.
Signalling Network Management; which controls the message routing and the
configuration of the signalling network facilities.

Level Relationships
BSS AP Application
SCCP
Level 4
(virtual circuit – call control)
Signalling Network Level 3

(MTP L3)
Signalling Link Control Message

Level 2 Transfer
(MTP L2)
Part
(MTP)
Signalling Data Link
Level 1
(MSI CARD)
Physical Medium
SYS01_6_6

Messages
Transfer Part
(MTP)
Signalling Unit Format

One of the fundamental concepts adopted for C7 is that of variable message length,
where practically all messages are complete in themselves.
Each message consists of three main parts:
Header
Data User part; which may contain complete messages.
Tail; Frame Check Sequence.
These messages are referred to as Signal Units (SU) of which there are three different
types.
Message Signal Unit (MSU) – Used for passing of higher Level signalling data.
Link Status Signal Unit (LSSU) – To enable the Level 2 MTP to be aligned and
maintain the link.
Fill-in Signal Units (FISU) – If there are no MSU or LSSU to be passed along the
link, then a FISU is periodically sent to maintain the signalling link

C7 Signalling Unit Format
TAIL DATA HEADER
SEQUENCE NUMBER
LENGTH INDICATOR
DATA
(MSU, LSSU, FISU)
FRAME CHECK
SEQUENCE
(ERROR CHECKING)
SIGNALLING UNITS (SU)
SYS01_6_7

Level 2 Header
Part
The header sequence is the same for all types of Signalling Units (SU) and consists of
the following:
Flag (F) – All SUs begin and end with an 8 bit flag. The flag bit pattern is 01111110. The
flag pattern is added by Level 2 before transmission. To ensure a flag pattern is not
contained in the data, a “0” is inserted after any 5 consecutive “1’s” at the transmitter. At
the receiver, the “0” is removed. These processes are called “Bit Stuffing” and “Bit
Stripping”.
Backward Sequence Number (BSN) – The BSN is the sequence number of an MSU
being acknowledged.
Backward Indicator Bit (BIB) – Used with the BSN in the basic error control functions
to perform SU sequence control and acknowledgement.
Forward Sequence Number (FSN) – The FSN is the sequence number of the SU in
which it is being carried. The FSN and BSN are binary coded number in the range
0–127. The FSN and BSN in a particular SU bear no relationship to each other. The
FSN is only incremented when an MSU is transmitted.
Forward Indicator Bit (FIB) – Used with the FSN in the basic error control functions to
perform SU sequence and acknowledgement.
Length Indicator (LI) – The length indicator field allows a cross-check on the closing
flag and pre-allocation of buffer space (normal function of length indicator), the length
indicator also provides the signal unit type.
Message Signal Units have data portions larger than 2 octets.
Link Status Units have a data field of one of two octets.
Fill-in Signal Units have a length zero indicator.

MTP Level 2 Header Part
F B
SPARE LI FSN BSN FLAG
I I
BITS
B B
2 6 1 7 1 7 8
HEADER
Types of SUs:
LI = 0 – FISU
LI = 1 or 2 – LSSU
LI = >2 – MSU
SYS01_6_8

LSSU Status
Field Format
This field is used to indicate the senders view of the actual signalling status of the link.
At present only a single octet Status Field (SF) is defined.
The first three bits of the Status Field are used, the remainder are spare.
C B A Indication
0 0 0 Status ‘O’ – Out of alignment
0 0 1 Status ‘N’ – Normal alignment
0 1 0 Status ‘E’ – Emergency alignment
0 1 1 Status ‘OS’ – Out of Service
1 0 0 Status ‘PO’ – Processor Outage
1 0 1 Status ‘B’ – Busy (Level 2 congestion)
Procedure
Status Indicator ‘O’ is sent during the initial alignment until an LSSU indicating status ‘O’,
‘N’ or ‘E’ is received ie until frame alignment.
Status Indication ‘N’ indicates normal operation.
Status Indication ‘E’ is used for emergency alignment with a short proving period at the
request of the network level.

LSSU Status Field
TAIL Status Field HEADER
Length Indicator = 1 or 2
8 bits
* * * * * C B A
Note: LSSUs have the highest priority of all signal units
= Spare bits
*
SYS01_6_9

Alignment
Procedure
The procedure is applicable to activation and to restoration of the link. The procedure
provides a “normal” proving period for “normal” initial alignment and an “emergency”
proving period for “emergency” initial alignment. The decision to apply either the
“normal” or the “emergency” procedures is made unilaterally at Level 3. Only the
signalling link to be aligned is involved in the initial alignment procedure (i.e. no transfer
of alignment information over other signalling links is required).
Alignment Status
Indications
The initial alignment procedure employs four different alignment status indications:
status indication “O”: Out of alignment
status indication “N”: “Normal” alignment status
status indication “E”: “Emergency” alignment status
status indication “OS”: Out of Service
These indications are carried in the status field of the Link Status Signal Units
Status indication “O” is transmitted when initial alignment has been started and none of
the status indications “O”, “N” or “E” are received from the link. Status indication “N” is
transmitted when, after having started initial alignment, status indication “O”, “N”, or “E” is
received and the terminal is in the “normal” alignment status. Status indication “E” is
transmitted when, after having started initial alignment, status indication “O”, “N” or “E” ie
received and the terminal is in the “emergency” alignment status, i.e. it must employ the
short “emergency” proving period.
Status indication “N” and “E” indicate the status of the transmitting signalling link terminal;
this is not changed by reception of status indications indicating a different status at the
remote signalling link terminal. Hence, if a signalling link terminal with a “normal”
alignment status receives a status indication “E” it continues to send status indication “N”
but initiates the short “emergency”proving period.
Status indication “OS” informs the remote signalling link terminal that for reasons other
than processor outage (e.g. link failure) the signalling link terminal can neither receive nor
transmit message signal units. Status indication OS is sent on completion of “power on”
until initial alignment is started.

Alignment Procedure
BSS MSC
START T1 IDLE SIO

Start T2
Not aligned state

SIO
Stop T2
SIE or SIN
Start T3
Aligned state SIE or SIN

Stop T3 SIE or SIN
Start T4
SIE or SIN
Proving period SIE or SIN
emergency or normal
SIE or SIN
T4 Expires
SIE or SIN
FISU/MSU
Aligned ready state
FISU/MSU
Stop T1
T1 allows for up to four

additional proving attempts
SYS01_6_10

Alignment
Procedure
The alignment procedure passes through a number of states during the initial alignment:
State Idle: the procedure is suspended
State “not aligned”: the signalling link is not aligned and the terminal is sending
status indication “O”. Time-out T23 is started on entry to State and stopped when
State is left.
State “aligned”: the signalling link is aligned and the terminal is sending status
indication “N” or “E”, status indications “N”, “E” or “OS” are not received. Time-out
T3 is started on entry to State and stopped when State is left.
State, “proving”, the signalling link terminal is sending status indication “N” or “E”,
status indication “O” or “OS” are not received, proving has been started.
Proving is the means by which the signalling link terminal validates the link’s ability
to carry signal units correctly by inspecting the signal units. «Proving» must last for
a period of T4 before the link can enter the «aligned ready» link state. Expiry of
timer T4 indicates a successful proving period unless the proving period has been
previously aborted up to four times.
Following successful alignment and proving procedure, the signalling terminal
enters Aligned Ready state and the aligned ready time-out T1 is stopped on entry
in the In service state and the duration of time-out T1 should be chosen such that
the remote end can perform four additional proving attempts.
The nominal values of the proving periods are:
Pn= 216 octets transmission time
Pe= 212 octets transmission time

Alignment Procedure
BSS MSC
START T1 IDLE SIO

Start T2
Not aligned state

SIO
Stop T2
SIE or SIN
Start T3
Aligned state SIE or SIN

Stop T3 SIE or SIN
Start T4
SIE or SIN
Proving period SIE or SIN
emergency or normal
SIE or SIN
T4 Expires
SIE or SIN
FISU/MSU
Aligned ready state
FISU/MSU
Stop T1
T1 allows for up to four

additional proving attempts
SYS01_6_10

Message Signal
Unit (MSU)
Level 3 of the C7 MTP provides the functions and procedures to control the transfer of
messages between the nodes of the signalling network.
The functions can be divided into two basic categories.
Signalling Message Handling
Signalling Network Management – Not Used
Signalling Network Management includes the functions necessary to reconfigure the
Network in the event of failure and to execute traffic flow control.
This facility is not implemented within the GSM A-interface, as only point-to-point
operation is recommended. So the procedures for message re-routing are not required.
Signalling Message Handling ensures that the messages originated by a User Part are
delivered to the corresponding user part at the destination. These functions include,
discrimination, distribution and routing.
The discrimination and distribution functions are controlled by the SCCP and will be
covered later.

Message Signal Unit
Message Signal Unit
Level
TAIL Data Field
2
Signalling Info
Field
Service Info Octet MTP
Level
ROUTING
Data LABEL HEADER 3
MTP
Level
Data HEADER 4
SCCP
Data BSSAP
(DTAP or BSSMAP)
SYS01_6_11

Service
Information Octet
(SIO)
The service information octet only exists in Message Signal Units. It contains the
Service Indicator and the Subservice Field (network indicator).
The Service Indicator is assigned for each user within the message transfer part, this is
then used to indicate which user should receive the message.
The Subservice Field (network indicator) indicates if the traffic is national or international.
Service Indicator
D C B A Indication
0 0 0 0 Signalling network management.
0 0 0 1 Signalling network testing + maintenance
0 0 1 0 Spare
0 0 1 1 Signalling Connection Control Part (SCCP)
0 1 0 0 Telephone User Part (TUP)
0 1 0 1 ISDN User Part
0 1 1 0 Data User Part (Call + cut related)
0 1 1 1 Data User Part (facility registration and cancellation)
1 0 0 0 MTP testing User Part
1 0 0 1
to
1 1 1 1 Spare
Sub-service Field

Note: If “ni” (network identifier) is set incorrectly an error will occur giving an invalid SIO.

Service Information Octet – L3 Header
Data Field
TAIL SIF SIO HEADER MTP

Level 2
8
Bits
SUBSERVICE SERVICE
FIELD INDICATOR
D C B A D C B A
NOTE:
1. No Signalling Network Management in GSM A-interface signalling.
2. All messages via SCCP therefore,
Service indicator set to D C B A
(SCCP) 0 0 1 1
Subservice field set to D C B A

(National network) 1 0 X X
SYS01_6_12

Signalling
Information Field
(SIF)
The signalling Information Field (SIF) is only used in MSU’s and is the position for the
actual signalling messages and accompanying routing information being transferred
between signalling nodes.
The field includes a routing label and the message.
The routing label identifies the address of the destination to which the message is to be
transferred. In the GSM application this is greatly simplified
The interface is only used for point-to-point application, so the routing function in the
MTP will be preset to select the point code appropriate to the parent MSC.
Routing Label
The part of the message label directly used for routing is called the routing label. The
label is 32-bits, 4 octets in length and contains:
14-bit Destination Point Code (DPC)
14-bit Originating Point Code (OPC)
4-bit Signalling Link Selector (SLS)
The origination and destination point code identifies the signalling points e.g. BSS and
MSC of the A-interface link.
The SLS identifies which MTL link to use.
Router Index
To improve the loadsharing of traffic on MTL links in the uplink direction from the BSS to
the MSC. (Loadsharing from the MSC to the BSC is based on the routing function
implemented at the MSC and is beyond the scope of this course.)
This will be done by distribution of signalling traffic originating at the BSS across 64
virtual circuits. A router index in the range of 0 to 63 will be randomly assigned to each
call block when a call is established. Random assignment will result in even distribution of
routing indices to call blocks. The router index identifies the virutal circuit for all signalling
messages associated wit the call block. The BSS MTP Layer 3 routing function will
evenly distribute the 64 virtual circuits over the active MTLs. This routing function is
compliant with the SS7 protocol because the BSS still routes all messaging associated
with a given call over the same physical MTL. Delivery of messages in order is still
guaranteed. A database element will be used for setting the loadshare granularity to
either 16 or 64.
Although the SLS will not be used to perform routing at the BSS, the SLS field will be
filled in. The SLS may be used for message routing by the MSC or some other signalling
point in the SS7 network.

Signalling Information Field
Data Field
MTP
Level 2
TAIL SIF SIO HEADER
Maximum 272 Octets
MTP
MESSAGE DATA ROUTING LABEL
Level 3
Signalling Link Originating Point Destination Point

Selection (SLS) Code (OPC) Code (DPC)
4-bits 14-bits 14-bits

SYS01_6_13

Signalling Connection Control Part (SCCP) Version 1 Revision 1
Signalling Connection Control Part (SCCP)
Introduction
The SCCP builds on the underlying MTP to provide a full network service as described
by the OSI architecture. The SCCP accepts message units from the higher layer users,
adds value in the form of network service features and gives the enhanced message
units to the MTP for delivery.
The SCCP provides two types of message transfer:
Without logical signalling connection (connectionless transfer)
With logical signalling connection (connection-oriented)
“Connectionless message transfer” is used to send single messages to other SCCP
users. The SCCP generates a UDT message from the user data and from the
determined address. This is then transferred to the MTP for transmission.
“Connection-oriented message transfer” is used for an exchange of SCCP users.
When the SCCP receives a request from a user to set up a signalling connection, it
sends a Call Request (CR) message to the SCCP in the opposite signalling point. This
CR message contains the local reference number, which is used to identify the
connection.
Protocol Classes
To satisfy a variety of requirements the SCCP provide four classes of protocol. Two are
associated with the connectionless service and two are connection-orientated.
Class 0– provides a pure connectionless transfer service.
Class 1– Sequenced (MTP) connectionless class.
Class 2– Basic connection-orientated class.
Class 3– Flow control connection-orientated class
GSM Recommendations allows only Classes 0 (BSSMAP messages) and Class 2 (DTAP
+ BSSMAP messages)

Version 1 Revision 1 Signalling Connection Control Part (SCCP)
Signalling Connection Control Part (SCCP)
ITU–TS Recom Q.711–Q.716

Message Transfer
Connection-orientated Connectionless
Protocol Class 2 Protocol Class 0

(DTAP – BSSMAP messages) (BSSMAP messages)
SYS01_6_14

SCCP Message
Format
The SCCP’s objective is to provide the means to establish logical signalling connections
within the C7 common channel signalling network.
Each SCCP message is a message in its own right, where each message uses the
routing label of the MTP. The SCCP message format is as shown, consisting:
MESSAGE TYPE FIELD; identifying one of 16 defined messages.
FIXED MANDATORY PART; This part includes a variable number of parameters each of
fixed length for a particular message type. The order of these parameters are defined for
each message type.
VARIABLE MANDATORY PART; This part includes pointers to locate parameters in the
variable length field. The name of the parameters and the order of listing is defined
within the message type.
OPTIONAL PART; If the message type allows an optional parameter field, the variable
mandatory part will include a pointer to the optional part. The optional part is defined as
parameter name, length of field and the parameter value.

SCCP Message Format
TAIL SIF SIO HEADER MTP

Level 2
MESSAGE DATA ROUTING LABEL MTP

Level 3
Variable Fixed
Optional Part Message SCCP
Mandatory Mandatory
(DTAP or BSSMAP) Type Level 4
Part Part
SYS01_6_15

Establishment
Procedure
A new connection is established when individual information related to a MS transaction
has to be exchanged between a BSS and MSC. This establishment can be initiated by
either the BSS or MSC.
If initiated by the BSS then the user data field of the SCCP Connection Request
message contains the BSSMAP message (COMPLETE L3 INFORMATION).
A typical establishment procedure is for a Connection Request (CR) message to be sent,
the user data field may contain BSSMAP or DTAP messages.
After checking this message the connection confirm (CC) message is returned with the
option of containing BSSMAP or DTAP messages.
Connection Release procedure is always initiated by the MSC. The MSC sends a SCCP
Released (RLSD) message. The user data field of this message is optional and may
contain a transparent Layer 3 message to the MS or be empty.
When receiving this message, the BSS releases all the radio resources allocated to the
relevant MS and sends a SCCP Release Complete (RLC) message back to the MSC.
The transfer of DTAP or BSSMAP data is via the data user field of the SCCP frames.
This is optional in the Connection Request, connection confirm and released messages
(except CR initiated by BSS). The user data field is a mandatory parameter of a Data
message (DT1) which always contain either a DTAP or a BSSMAP message.

!

!

SCCP Establishment Procedure
BSS MSC
(BSSMAP; DTAP) CR
(ssm_t_v_0)
CC (*)
(BSSMAP; DTAP) DTI
DTI (BSSMAP; DTAP)
RLSD (*)
RLC
* CC and RLSD has option
for Data field
SYS01_6_16

SCCP Message
Parameters
Listed below is a brief description of each of the message parameters used with the
relative message type, along with the number of octets for that parameter.
The overhead also shows if the parameter is used in the Fixed (F), Variable (V) or
Optional (O) part of the message.
“Source Local Reference”, parameter field is a 3-octet field containing a reference
number which is generated and used by the local node (BSS or MSC) to identify the
connection section.
“Destination Local Reference” parameter field is a 3-octet field containing a reference
number which outgoing messages, has been allocated by the remote node (BSS or
MSC)
“Protocol Class” parameter field is a four bit field containing the protocol class (i.e.
Class 0 or 2 (connection-orientated/connectionless)).
“Called Party Address” and “Calling Party Address” parameters which identify the
sub-system which messages are using.
“Segmenting/reassembling” parameter field is a 1-octet field and indicates if more data
messages, relating to this message are required (not used in A-interface however the
parameter must be still included for syntax reasons).
“Refusal Cause” parameter field is a 1-octet field containing the reason for the refusal of
the connection (full list ITU–TS Q.713 para 3.11)
“Data” parameter field is a variable length field containing SCCP user data to be
transferred transparently between the SCCP user functions.
“End of Optional Parameter” identifies the end of all the optional parameters, a single
octet set to all zeros.

SCCP Message Parameters
Type Length
Parameters
(F,V,O) (Octets)
Source Local Reference F 3
Destination Local Reference F 3
Protocol Class F 1
Called Party Address V 3 min
Calling Party Address O 4 min
Segmenting/reassembling F 1
Refusal Cause F 1
Release Cause F 1
Data (DTAP/BSSMAP) O/V 3 min
256max
End of Optional
Parameter 0 1
F = Fixed
V = Variable
O = Optional
SYS01_6_17

SCCP Message
Example
This example is a typical SCCP connect request message. It illustrates a connect
request message that contains 3 fixed mandatory parameters:
Message Type Code
Source Local Reference
Protocol Class (class 2)
One variable mandatory parameter:

Called Party Address
Three optional parameters:

Calling Party Address
Data
End of Optional Parameter
The mandatory variable part also contains two pointers:

The first pointer indicates the start of the called party address parameter
The second pointer indicates the start of the optional parameters
NOTE:
When the parameter is part of the Fixed or Variable Mandatory part of the message the
parameter type code octet is not used. e.g. Called Party Address (Variable Mandatory) 3
octets.
Calling Party Address (optional part) 4 Octets.

SCCP Message Example
Message Type: Connection Request (CR)
PARAMETER CODE/INDICATION
Message Type 0000 0001 (CR)
Fixed Source Local Incoming Connection

Mandatory
Reference Identifier
Part
Protocol Class 0000 0010 CLASS 2
Pointer to Variable 0000 0010 (2)
Variable Pointer to optional 0000 0100

Mandatory (4)
Part
Called Party Length Indicator
Address Address Indicator
Subsystem Number
Calling Party Parameter Type Code

Address Length Indicator
Address Indicator
Optional Subsystem Number
Part BSSMAP or DTAP
Data 3 – 130 Octets message
End of Optional 0000 0000

Parameter
SYS01_6_18

Called/Calling
Party Address
Parameter
In order to limit the complexity of the address procedures the BSS exchanges signalling
messages only with its parent MSC i.e. point-to-point working. Therefore, the address
parameters, both Calling and Called Party Address are structured identically. They are
primarily used to indicate the required application part and where to obtain the routing
information.
The A-interface has no global title so the Destination Point Code (DPC) which is coded in
the MTP routing label and subsystem number in the Called Party Address allow the
routing of the message.
The encoding of the address indicator is 01000010 with the subsystem number being
either.
11111110 – – BSSAP
11111101 – – OMAP
Address indicator and subsystem number will always be the same in our messages. For
calling and called party addresses are point to point routing provided with Level 3 (MTP
routing label) OPC and DPC and national addressing (Ni= 2).

Called/Calling Party Address Parameter
LENGTH INDICATOR 00000010
ADDRESS INDICATOR 01000010
SUBSYSTEM NUMBER 1 1 1 1 1 1 1 0 (BSSAP)
SYS01_6_19

Radio Subsystem Application Part (BSSAP) Version 1 Revision 1
Radio Subsystem Application Part (BSSAP)

The user function of the SCCP called Radio Subsystem Application Part (BSSAP) uses
one signalling connection per active Mobile Station for the transfer of Layer 3 messages
related to that transaction. The BSSAP user function is further subdivided into two
separate functions.
The Direct Transfer Application Sub-Part (DTAP) is used to transfer Connection
Management (CM) and Mobility Management (MM) messages to and from the mobile
station (MS). The Layer 3 information in these messages is not interpreted by the BSS
and a complete description is contained in the GSM Recommendation 04.08.
The BSS Management Application Sub-Part (BSSMAP) supports other procedures
between the MSC and BSS related to the MS (i.e. resource management, handover
control), or to a cell within the BSS, or to the whole BSS. The description of the Level 3
protocol for BSSMAP is contained in GSM Recommendation 08.08, with the Radio
resource management contained in GSM Recommendations 04.08.

Version 1 Revision 1 Radio Subsystem Application Part (BSSAP)
BSS Application Part (BSSAP)
Direct Transfer BSS Management Part

Application Part (BSSMAP)
(DTAP)
GSM Rec 04.08
Connection Mobility Management Radio Resource BSS Management

Management (MM) Management BSSMAP
(CM) (RR) GSM 08.08
GSM 04.08
Short Message Call Control Supplementary

Service (SMS) (CC) Service Support
(SSS)
SYS01_6_20

BSSAP Message Structure Version 1 Revision 1
BSSAP Message Structure

The distribution of messages between BSSMAP and DTAP functions are performed by
an intermediate layer of protocol between the BSSAP and SCCP. This is referred to as
the Distribution Sub-layer.
Each SCCP User Data Field contains a distribution data unit as a header, followed by the
Level 3 BSSMAP or Layer 3 transparent DTAP message.
The discrimination parameter indicates which message type is transparent or
non-transparent

Version 1 Revision 1 BSSAP Message Structure
Message Signal Unit
TAIL MTP
Mandatory
E MESSAGE
Optional Variable Fixed TYPE
N (Data) SCCP
D
Transport DTAP
Layer 3 Message Header
(TS GSM 04.08)
either/or
Information Elements BSSMAP

(TS GSM 04.08 and 08.08) Header
SYS01_6_21

BSSAP Message Header Version 1 Revision 1
BSSAP Message Header
DTAP Header
Structure
The discriminator is one octet in length and discriminates between DTAP and BSSMAP
type messages. For DTAP messages the D bit (bit 1 of the octet) is set to 1.
The DLCI parameter is used by the MSC messages to indicate to the BSS the type of
Data Link Connection to be used over the Air-interface. This is a single octet, which
indicates the radio channel identification and the SAPI value used on the radio link.
The LI states the number of octets remaining in the message.
DTAP Message Format:

Discriminator parameter
Data link connection identification parameter
Length indicator
Message (Information elements)

Version 1 Revision 1 BSSAP Message Header
DTAP Header Structure
3 Octets
LI DLCI DISC
(1 Octet) (1 Octet) (1 Octet)
“D” bit = “1”
Data Link Connection Identification (DLCI)
C1 C2 0 0 0 S1 S2 S3
1 Octet
C1, C2 = 00 = FACCH, SDCCH

C1, C2 = 01 = SACCH
S1, S2, S3 = 000 = Call Control
011 = Short Message Service
SYS01_6_22

BSSAP Message Header Version 1 Revision 1
BSSMAP Header
Structure
The BSSMAP messages are to support the MSC to BSC interface and thus do not
require any DLCI field. All messages apply only to the connected MSC/BSC.
The first octet, discriminator, indicates by the first bit, being set to a 0, that the message
contained within this MSU is a BSSMAP type.
This is then followed by an octet indicating the length of the Level 3 message.
BSSMAP Message Format:

Discriminator parameter
Length indicator
Message (Information elements)

Version 1 Revision 1 BSSAP Message Header
BSS Management Application Part Header
2 Octets
Length
Message DISC
Indicator
“D” bit = 0
SYS01_6_23

BSSAP Message Structure Version 1 Revision 1
Complete
Message Format
The Direct Transfer Application Part is used to transfer Call Control (CC) and Mobility
Management (MM) messages to and from the MS. These messages are transferred via
the A-interface in the format shown but the information in these messages are not
interpreted by the BSS at all, except in one case (stated below).
The actual messages are defined in GSM Recommendation 04.08, of these messages
the Radio Resource (RR) Management type are not transferred over the A-interface.
The initial MS message received by the BSS will be analysed to allow the extraction, by
the BSS, of the “Classmark field” (mobile capabilities). The entire initial message (e.g.
CM service request, LOC update request, page response, re-establishment request) is
passed to the MSC piggybacked on the “complete layer 3 information” message.
The BSS uses the “Classmark” information to set timing and power requirements for the
Air-interface.
Note:
LI= Length Indicator
DISC= Discriminator

Version 1 Revision 1 BSSAP Message Structure
BSSAP Message Format
Message Signal Unit
F B
Signal Information MTP
F CK SIO LI I FSN I BSN F
Field Level 2
B B
SCCP Message SLS OPC DPC MTP

Level 3
SCCP
End of Optional Variable Fixed Message
Message (Data) Mandatory Mandatory Type Message
(DT1)
DTAP Message LI DLCI DISC = 1 DTAP

(TS GSM 04.08)
Message
BSSMAP Message Message Type LI DISC = 0 BSSMAP

(TS GSM 08.08)
Message
SYS01_6_24

BSS Management Application Part (BSSMAP) Version 1 Revision 1
BSS Management Application Part (BSSMAP)
Procedures
The BSSMAP supports all procedures between the MSC and BSS that require
interpretation and processing of information related to single calls and resource
management.
There are a total of 18 procedures defined in GSM Recommendations 08.08 which can
be defined into two groups.
“Global”; these procedures concern a complete cell/BSS, they use the connectionless
services of the SCCP (e.g. UDT).
These procedures are defined within GSM Recommendation 08.08 separately, to enable
a more flexible approach to the buildup of complete call sequence.
Global procedures include:
Blocking/Unblocking
Resource Indication
Reset
Reset Circuit
Paging
Handover Candidate Enquiry
Flow Control
“Dedicated”; these procedures concern a single dedicated radio resource on the
radio-orientated services of the SCCP, thus the connection has to be set up to support
the call or transaction.
The procedures are defined separately but in many instances the procedures can exist
simultaneously.
Dedicated procedures include:
Assignment
Handover Required Indication External
Handover Resource Allocation Handover
Handover Execution
Release
Classmark Update
Cipher Mode Control
Initial MS Message
Queuing Indication
Trace Invocation
DataLink Control SAPI not equal to 0

Version 1 Revision 1 BSS Management Application Part (BSSMAP)
BSSMAP
PROCEDURES (18 Total)

GSM Recom 08.08
GLOBAL DEDICATED
(complete cell/BSS) (single radio resource)
Connectionless Connection–orientated
Blocking/Unblocking Assignment
Resource Indication Handover Required Indication
Reset Handover Required Allocation
Reset Circuit Handover Execution
Paging Release
Handover Candidate Enquiry Classmark Update
Flow Control Cipher Mode Control
Initial MS Message
Queueing Indication
Trace Invocation
Data Link Control SAPI not Equal to 0
SYS01_6_25

BSS Management Application Part (BSSMAP) Version 1 Revision 1
Normal Mobile
Station (MS) to
PSTN Call Set.
The CM service request message (DTAP) is enveloped into Connection Request (CR)
(SCCP) message.
* When the Alerting message is received by the MS this generates the ringing tone in the
MS, indicating the distant-end phone is ringing. Ring tone may be sent from the distant
exchange.

Version 1 Revision 1 BSS Management Application Part (BSSMAP)
MS to PSTN Call
Message Flow Type

MSC : BSS
CR – ComL3inf (CM service request)
CC – (SCCP) [BSSMAP/DTAP]
DT1 – Cipher Mode Command (BSSMAP)
DT1 – Cipher Mode Complete (BSSMAP)
DT1 – Set up (DTAP)
DT1 – Call Proceeding (DTAP)
DT1 – Assignment Request (BSSMAP)
DT1 – Assignment Complete (BSSMAP)
DT1 – Alerting (DTAP)
DT1 – Connect (DTAP)
DT1 – Connect Ack (DTAP)
SYS01_6_26

A-Interface Messages Version 1 Revision 1
A-Interface Messages
Normal Mobile Station (MS) to PSTN call setup when call is cleared.

Version 1 Revision 1 A-Interface Messages
MS Clears Call
Message Flow Type

MSC : BSS
DT1 – Disconnect (DTAP)
DT1 – Release (DTAP)
DT1 – Release Complete (DTAP)
DT1 – Clear Command (BSSMAP)
DT1 – Clear Complete (BSSMAP)
RSLD – Released (SCCP)
RLC – Release Complete (SCCP)
SYS01_6_27

Normal PSTN to MS Call Version 1 Revision 1
Normal PSTN to MS Call

The paging request message (BSSMAP) is enveloped into a Unit Data (SCCP) message
and the BSS generates the required paging message over the air-interface
BCCH/CCCH. The call set up is then similar to an MS originated call except for the
Paging Response message (DTAP) enveloped into the ComL3inf message (BSSMAP)
enveloped into the Connection Request (SCCP).

Version 1 Revision 1 Normal PSTN to MS Call
Normal PSTN to MS Call
Message Flow Type

MSC : BSS
UDT – Paging (BSSMAP)
CR – ComL3inf (Paging Response) (BSSMAP/DTAP)
CC – (SCCP)
DT1 – Cipher Mode Command (BSSMAP)
DT1 – Cipher Mode Complete (BSSMAP)
DT1 – Set up (DTAP)
DT1 – Call Confirmed (DTAP)
DT1 – Assignment Request (BSSMAP)
DT1 – Assignment Complete (BSSMAP)
DT1 – Alerting (DTAP)
DT1 – Connect (DTAP)
DT1 – Connect Ack (DTAP)
SYS01_6_28

A-Interface Messages Version 1 Revision 1
A-Interface Messages
Call from PSTN

to MS
After the conversation either party can clear down, which is indicated by either
Disconnect or Release.

Version 1 Revision 1 A-Interface Messages
PSTN User Clears Call
Example: Call Cleared
Message Flow Type

MSC : BSS
# DT1 – Disconnect (DTAP)
DT1 – Release (DTAP)
DT1 – Release Complete (DTAP)
DT1 – Clear Command (BSSMAP)
DT1 – Clear Complete (BSSMAP)
RSLD – Released (SCCP)
RLC – Release Complete (SCCP)
# can be with release message
SYS01_6_29

Procedures – Global Version 1 Revision 1
Procedures – Global
Blocking
The assignment procedure depends upon the MSC choosing the terrestrial resource to
be used. The MSC therefore needs to be informed of any terrestrial circuits that are out
of service at the BSS. This is performed by using a simple blocking/unblocking
procedure. The block messages used to support this procedure are sent as global
messages (i.e. using the SCCP connectionless mode). Each message refers to one or
more terrestrial circuits accessed through the BSS MSC interface. The circuit is
identified by its Circuit Identity Code.
A BSS may block a terrestrial circuit because:
Operation and Maintenance intervention makes the circuit unavailable for use
(Cause value: “O and M intervention”).
An equipment failure makes the circuit unavailable (Cause value: “equipment
failure”)
Radio resource is not accessible from the terrestrial circuit (Cause value: “no radio
resource available”).
When and if the BSS decides to block a terrestrial circuit, the BSS shall immediately
mark that terrestrial circuit as “blocked” (to stop any further allocation of that terrestrial
circuit) and shall then send a block message to the MSC and start timer T1 (T20).
The BLOCK message contains the Circuit Identity Code indicating the terrestrial circuit
that is to be blocked and a Cause Information Element indicating the reason for blocking.
Typical Cause values are: “no radio resources available,” “O and M intervention”,
“equipment failure”.
If the CIRCUIT GROUP BLOCK message is applied by the BSS the circuits to be
blocked are indicated in the status field of the Circuit Identity Code list.
Receipt of a block message (BLOCK or CIRCUIT GROUP BLOCK) at the MSC from the
BSS will indicate to the MSC that the identified circuits are unavailable for reselection. If
a call is in progress on any of the identified terrestrial circuits then it will be unaffected by
this procedure, the circuits will however be “camp on blocked”. Such circuits shall be
blocked as soon as that call is no longer in progress, or active.
An appropriate blocking acknowledge message (BLOCKING ACKNOWLEDGE or
CIRCUIT GROUP BLOCKING ACKNOWLEDGE) will be returned to the BSS by the
MSC to acknowledge receipt of the block message and to indicate that any necessary
action has been taken.
On receipt of the blocking acknowledge the BSS shall stop timer T1 (T20).
The resource involved will be assumed to be blocked by the MSC until either an unblock
(UNBLOCK or CIRCUIT GROUP UNBLOCK) or RESET message is received relevant to
that resource.

Version 1 Revision 1 Procedures – Global
Blocking
Informs the MSC of terrestrial circuits that are out of service at the BSS.
Blocking
BSS MSC
T1 (T20) (BLOCK) UDT
Started
CIC = x
Cause = Equipment fail
T1 (T20) UDT (BLOCKING ACK)
Stopped CIC = x
OR
BSS MSC
(Circuit Group Block) UDT
T1 (T20)
Started
(Circuit Group Block
T1 (T20) Acknowledge) UDT
Stopped
SYS01_6_30

Blocking
If blocking acknowledge message is not received for a block message within T1 (T20)
seconds then the block message will be repeated. If this occurs a second time the
circuits will be kept marked as blocked, and the situation must then be resolved internally
within the BSS or by O&M procedures.
It should be noted that this is a unidirectional procedure and that the MSC does not send
block messages towards the BSS. If the MSC wishes to take a terrestrial circuit out of
service this is achieved by local blocking within the MSC
Note: Timer T1 is used to supervise a single circuit block/unblock procedure whilst T20
is used to supervise the circuit group block/unblock procedure.
If an ASSIGNMENT REQUEST or HANDOVER REQUEST message is received
allocating a circuit which is marked at the BSS as blocked then an ASSIGNMENT
FAILURE message or a HANDOVER FAILURE message (respectively) followed by a
BLOCK message shall be sent to the MSC.
Group Circuit
Procedures
Allows reduced messages across the A-interface. Faster completion of procedures is
achieved by implementing group messages throughout the BSS software.
To enable this function within the BSS the following change_element command must be
entered at the BSC:
chg_element group_block_unblock_allowed <element_value><bsc or 0)
<element_value>
0: Disable – the BSS sends single circuit Block/Unblock
messages to the MSC.
1: Enable – the BSS sends Circuit Group Block/Unblock

To indicate support of group block/unblock at the BSC the following command must be
entered at the RXCDR:
chg_rxcdr_gbu <bsc><bss_grp_block_unblock_allowed>
<bsc> Represents the BSC associated with this RXCDR Range: 0–31
<bss_grp_block_unblock _allowed>off:BSC does not support Group block/unblock
on: BSC does support Group block/unblock

Blocking
Informs the MSC of terrestrial circuits that are out of service at the BSS.
Blocking
BSS MSC
T1 (T20) (BLOCK) UDT
Started
CIC = x
Cause = Equipment fail
T1 (T20) UDT (BLOCKING ACK)
Stopped CIC = x
OR
BSS MSC
(Circuit Group Block) UDT
T1 (T20)
Started
(Circuit Group Block
T1 (T20) Acknowledge) UDT
Stopped
SYS01_6_30

Unblocking
If the BSS wishes to unblock a blocked circuit and return it to service then it shall
immediately mark the circuit as “unblocked” and then send an unblock message, and
start timer T1 (T20).
If an unblock message (UNBLOCK or CIRCUIT GROUP UNBLOCK) is received at the
MSC for a blocked resource then the resource will be marked as available for service and
an unblocking acknowledge message (UNBLOCKING ACKNOWLEDGE or CIRCUIT
GROUP UNBLOCKING ACKNOWLEDGE) will be returned to the BSS. The BSS shall
stop timer T1 (T20) on receipt of this unblocking acknowledge.
If an unblocking acknowledge message is not received for an unblock message before
expiry of timer T1 (T20) then the unblock message will be repeated. If this occurs a
second time, this situation may be reflected to the O&M, which shall resolve the possible
conflict. The unblocking acknowledge message is repeated at most one time. Whatever
the outcome of possible repetitions, the concerned circuits remain “unblocked”.

Unblocking
Informs the MSC of terrestrial circuits which require unblocking and returning
to service.
Unblocking
BSS MSC
T1 (T20) (UNBLOCK) UDT
Started
UDT (UNBLOCKING ACK)

T1 (T20)
Stopped
CIC = Circuit Identity Code
BSS MSC
(Circuit Group Unblock) UDT
(Circuit Group Unblock

Acknowledge) UDT
SYS01_6_31

Resource
Indication
The purpose of the resource indication is to inform the MSC of the amount of radio
resources that are spare at the BSS and available for carrying traffic. This information
may be used by the MSC for external handover decisions.
The procedure is for the MSC to indicate to the BSS one of the four methods of
transferring the required information to the MSC. This is achieved by the MSC sending a
Resource Request message containing the required method and the cell identity.
The four methods are:
“Spontaneous indication expected”; when conditions defined by O+M are met in
the BSS (e.g. traffic thresholds, or time interval between two messages).
“Single indication expected”; immediate one-off response.
“Periodic indication expected”; immediately then periodically, set by MSC (100mS
intervals)
“No indication expected”; BSS to MSC transfer of resource indication information
disabled until receipt of Resource Request
The resource indication message contains two pieces of information for each of the 5
interference bands:
# The number of half rate traffic channels available in each band.
# The number of full rate traffic channels available in each band.
The level of the 5 bands are defined by O+M (user).
Resource
Indication
Procedure
A change_element command has been introduced to enable this message to either
report using the Phase 1 or Phase 2 message formats. In addition an acknowledge
message with no information in the response to the Resource Request from the MSC is
introduced.
chg_element phase 2_resource_ind_allowed<element_value><bsc or 0>
<element_value>
0: Disabled – (default) the BSS sends Resource Indication
messages to the MSC in the GSM phase 1 format.
1: Enabled – the BSS send the resource Indication

messages to the MSC in the GSM phase 2 format.

Resource Indication
Informs the MSC of the amount of radio resources that are available at the BSS.
BSS MSC
<UDT, Resource Request>
<timeout>
<UDT, Resource Indication>
Phase2_resource_ind_allowed=0
BSS MSC
<UDT, Resource Request>
Method:
1. Spontaneous indication expected
<timeout> (acknowledgement
with information) 2. Single indication expected
3. Periodic indication expected
4. No indication expected – Disable reporting

Phase2_resource_ind_allowed=1
SYS01_6_32

Global Reset
Procedure
The purpose of the reset procedure is to initialise the BSS and MSC in the event of a
failure. The procedure is a global procedure applying to a whole BSS, and therefore all
messages relating to the reset procedure are sent as global messages using the
connectionless mode of the SCCP.
If only a limited part of the MSC or BSS has suffered a failure then clearing procedures
can be used to clear only those affected calls.
Reset at the MSC

In the event of a failure at the MSC which has resulted in the loss of transaction
reference information, a RESET message is sent to the BSS. This message is used by
the BSS to release affected calls and erase all affected references.
Upon receipt of a RESET message from the MSC the BSS shall send block messages
(BLOCK or CIRCUIT GROUP BLOCK) for all circuits that were previously blocked, the
MSC shall respond to these with blocking acknowledge messages.
After a guard period of T13 seconds a RESET ACKNOWLEDGE message is returned to
the MSC, indicating that all MSs which were involved in a call are no longer transmitting
and that all references at the BSS have been cleared.
If the MSC sends a RESET message to the BSS and receives no RESET
ACKNOWLEDGE message within a period T16 then it shall repeat the entire reset
procedure. The sending of the RESET message is repeated a maximum of “n” times
where n is an operator matter. After the n-th unsuccessful repetition the procedure is
stopped and the maintenance system is informed.

Reset
MSC
BSS MSC
T13 STARTED UDT (RESET) T16 STARTED
UDT (BLOCK)
UDT (CIRCUIT GROUP BLOCK)
UDT (BLOCKING ACKNOWLEDGE)

UDT (CIRCUIT GROUP BLOCKING
ACKNOWLEDGE)
UDT (RESET ACKNOWLEDGE)

T13 EXPIRES T16 EXPIRES
Max of “N” times for Reset Message
SYS01_6_33

Reset at the BSS Version 1 Revision 1
Reset at the BSS

In the event of a failure at the BSS which has resulted in the loss of transaction reference
information, a RESET message is sent to the MSC. This message is used by the MSC
to release affected calls and erase all affected references, and to put all circuits into the
idle state.
After a guard period of T2 seconds a RESET ACKNOWLEDGE message is returned to
the BSS indicating that all references have been cleared.
After the sending of the RESET to the MSC the BSS shall initiate blocking procedures
(Block or Circuit group block procedures) for all circuits that are blocked, the MSC shall
respond with blocking acknowledge or check group block acknowledge. The sending of
block messages shall be done without waiting for the acknowledgement to the RESET
message.
If the BSS sends a RESET message to the MSC and receives no RESET
ACKNOWLEDGE message within a period T4 then it shall repeat the entire reset
procedure. The sending of the RESET message is repeated a maximum of “n” times
where n is an operator matter. After the n-th unsuccessful repetition the procedure is
stopped and the maintenance system is informed.
To specify the number of repetitions the following change_element command must be
used.
chg_element global_reset_repetitions <element_value><bsc or 0>
<element_value> 0: The Global Reset Message will repeat continuously
until a reset acknowledge is received.
1 to 255: The Global Reset Message will be repeated the
number of times entered and the alarm “No MSC
Acknowledgement” for Global Reset is generated.

Version 1 Revision 1 Reset at the BSS
Reset
BSS
MSC BSS
T2 STARTED UDT (RESET) T4 STARTED
UDT (BLOCK)
UDT (CIRCUIT GROUP BLOCK)
UDT (BLOCKING ACKNOWLEDGE)

UDT (CIRCUIT GROUP BLOCKING
ACKNOWLEDGE)
UDT (RESET ACKNOWLEDGE)

T2 EXPIRES T4 EXPIRES
Max of “N” times for Reset Message
SYS01_6_34

Procedures – Global
Reset Circuit at
the MSC
If a circuit has to be put to idle at the MSC due to an abnormal SCCP-connection
release, a RESET CIRCUIT message will be sent to the BSS. When the BSS receives a
RESET CIRCUIT message, it shall respond with a RESET CIRCUIT ACKNOWLEDGE
message in case the circuit can be put to idle. If the circuit is blocked at the BSS a
BLOCK message shall be returned to the MSC. the MSC shall then respond with a
BLOCKING ACKNOWLEDGE message. If the circuit is unknown at the BSS, the BSS
shall return an UNEQUIPPED CIRCUIT message to the MSC.
Timer T12 is used at the MSC to supervise the reset circuit procedure. If the Timer
elapses before a response (RESET, RESET CIRCUIT ACKNOWLEDGE, UNEQUIPPED
CIRCUIT or BLOCK) the reset circuit procedure is repeated.
Reset Circuit at
the BSS
If the circuit to be put to idle at the BSS due to an abnormal SCCP-connection release, a
RESET CIRCUIT message will be sent to the MSC. When the MSC receives this
message, it clears the possible call and puts the circuit, if known, to the idle state. if the
circuit is known, a RESET CIRCUIT ACKNOWLEDGE message is returned to the BSS.
if the circuit is unknown in the MSC, an UNEQUIPPED CIRCUIT message is returned to
the BSS.
Timer T19 is used at the BSS to supervise the reset circuit procedure. if the timer
elapses before a response (RESET, RESET CIRCUIT ACKNOWLEDGE or
UNEQUIPPED CIRCUIT) is returned to the BSS, the procedure is repeated.
If the BSC receives a message for a circuit identity code that is unequipped then it may
respond with an unequipped circuit message. To enable this function the following
change_element command has to be enabled.
chg_element unequipped_circuit_allowed<element_value><bsc or 0>
<element_value> 0: Disabled (default) the BSS shall not send Unequipped
Circuit messages to the MSC id Unknown circuit Identity
code is received.
1: Enabled the BSS shall send Unequipped Circuit messages
to the MSC.
Note:
This parameter does not apply to RXCDR sites. This parameter requires a location of 0
or BSC. This parameter is used with a Phase 2 optional feature which must be
purchased.

Reset Circuit
MSC
BSS MSC
UDT (RESET CIRCUIT)
T12 STARTED
CIC = Y
T12 STOPPED ON
(RESET CIRCUIT ACK) UDT RECEIPT OF:
CIC = Y RESET CIRCUIT ACK
RESET
(BLOCK) UDT BLOCK UNEQUIPPED
CIRCUIT
UDT (BLOCK ACK)
(UNEQUIPPED CCT)
OR
BSS
BSS MSC
(RESET CIRCUIT) UDT
T19 STARTED
CIC = x
UDT (RESET CIRCUIT ACK)
CIC = x
UNEQUIPPED CIRCUIT
SYS01_6_35

Paging
PAGING messages for all MSs shall be sent via the BSSMAP as a connectionless
message. These will include the IMSI of the MS to allow derivation of the paging
population number; they also include an indication of which combination of channels will
be needed for the subsequent transaction related to the paging. This type of PAGING
message will then be stored and a corresponding radio interface paging message
transmitted over the radio interface at the appropriate time.
It should be noted that each PAGING message on the MSC–BSS interface relates to
only one MS and therefore the BSS has to pack the pages into the relevant Technical
Specification GSM 04.08 radio interface paging message.
If a radio interface PAGING RESPONSE message is received then the relevant
connection is set up towards the MSC as described in Technical Specification GSM
08.06 and the radio interface PAGING RESPONSE message is passed to the MSC in a
COMPLETE LAYER 3 INFORMATION message.
A single PAGING message across the MSC to BSS interface contains information on
the cells in which the page shall be broadcast.

Paging
Contacting Mobile Stations:
MS BSS MSC
UDT (PAGING)
IMSI = X
PAGING BROADCAST TMSI = Y
TMSI = Y CELL Identifier
PAGING RESPONSE
(COML3INF) CR
PAGING RESPONSE
SYS01_6_36

Handover
Candidate
Enquiry
The purpose of this procedure is to allow the MSC to ascertain if it is possible to
handover any MSs that are currently being served by a particular cell to another
nominated cell. The procedure uses both global and dedicated resource messages, and
is relevant to an individual cell.
Flow Control
These procedures are defined to give some degree of flow control.
At the BSS, the BSS processor or CCCH scheduler can indicate overload.
The MSC can indicate to the BSS that it is in a congested state by sending an overload
message.
MSC Overload
If the MSC becomes overloaded, it shall send an OVERLOAD message from the MSC to
the BSS. The BSS receives this message and starts to reduce traffic loading on the MSC
immediately. The BSS reduces the traffic load on the MSC by barring of mobile access
classes within cells in the BSS. When a mobile access class is barred a group of mobile
users are no longer allowed to make calls on the network and hence the load to the MSC
is reduced. This mobile access class information is carried to the mobile subscriber in the
SYSTEM INFORMATION message specified in GSM recommendations.

Handover Candidate Enquiry
BSS MSC
HANDOVER CANDIDATE ENQUIRY
HANDOVER REQUIRED
HANDOVER REQUIRED
HANDOVER REQUIRED
HANDOVER CANDIDATE RESPONSE
Note:
Receipt of the Handover Candidate Enquiry message causes the generation of a Handover
Required message for each of candidate MS. These are sent as connection orientated
messages. When all Handover Required messages have been generated a global
Handover Candidate response message is returned.
SYS01_6_37
MSC Overload
MS BSS MSC
OVERLOAD
(MSC OVERLOAD)
OVERLOAD
OVERLOAD
(BSS OVERLOAD)
OVERLOAD
SYS01_6_38

Procedures – Dedicated Version 1 Revision 1
Procedures – Dedicated
Assignment
The purpose of the assignment procedure is to ensure that the correct dedicated radio
resource can be allocated or re-allocated to a mobile as required. However, the initial
random access by the MS and “immediate assignment” to a DCCH is handled
autonomously by the BSS without reference to the MSC.
The initial SETUP procedure (A-bis) has been assumed to have taken place. E.g. the
MSC has been told type of call; channel required; dialled number etc by the MS.
Then based on this information, an Assignment Request message is sent to the BSS.
This message contains details of the resource that is required e.g. speech rate, channel
type, data adaption priority level etc, it also contains the terrestrial channel that should be
used between the MSC and BSS.
When the BSS is satisfied that the radio Assignment procedure has been successfully
accomplished (e.g. receipt of assignment complete) via Air-interface, it will return an
Assignment Complete message to the MSC.
If the assignment procedure fails for any reason, an Assignment Failure message will be
returned, containing the appropriate cause value.

Version 1 Revision 1 Procedures – Dedicated
Assignment
The purpose of the assignment procedure is to allocate the correct radio

resource to an MS.
MS BSS MSC
DT1 (ASSIGN. REQUEST)
CHAN TYPE
ASSIGN CMD
START T10 Speech rate
(SDCCH) channel type
(Channel = FACCH) data adaption
priority level
SABM (FACCH)
UA (FACCH)
ASSIGN COMP
STOP T10
(FACCH) (ASSIGN COMPL) DT1
If procedure fails, an Assignment Failure message is returned,

containing an appropriate cause value.
SYS01_6_39

External
Handover
This procedure supports handover transitions to and from both DCCH and traffic
channels. The defined procedures which can be used are:
Handover Required Indication
Handover Resource Allocation
Handover Execution
Handover
Required
Indication
The Handover Required Indication procedure allows an BSS to request that a handover
be carried out for a particular mobile, currently allocated a dedicated resource.
This is done by generating a Handover Required message from the BSS to MSC. This
message contains the following information.
Message Type
Cause for Handover (e.g. downlink quality)
Response Request (response required for completion)
Preferred List of Target Cells
Source Cell
Handover
Resource
Allocation
This procedure allows the MSC to request that resources be reserved at a target
BSS/cell for a subsequent handover. However, it does not result in the transmission of
any messages over the radio interface.
In order to support this procedure a SCCP connection is set up to the BSS and is then
used to support all relevant BSSAP messages.
The MSC sends a Handover Request message (piggybacked on SCCP CR message) to
the BSS from which it requires radio resources.
This message contains an indication of the type of channel and the terrestrial circuit to be
used for the traffic channel.
The BSS after allocating the required resources sends a Handover Request
acknowledge message containing the appropriate channel and the radio interface
HANDOVER COMMAND message to the MSC.
The Handover Command message contains all the information the MS requires to
access the new cell/BSS and is passed to the MS via the MSC and current source BSS.
Part of this information is the Handover reference number which is to ensure the current
MS accesses the new BSS radio resource.

Handover Resource Allocation
This procedure allows the MSC to request that resources be reserved at the
target cell/BSS for a subsequent handover.
Target (new)
BSS MSC
CR (Handover Request)
Channel Type Encryption Info
CIC etc.
(Handover Request Ack) CC

Handover Command
(Handover Reference Number)
SYS01_6_40

Handover
Execution
The MSC instructs the MS to handover to the target BSS using the “Handover
Command” previously generated by the target BSS.
A Handover Command message is generated by the MSC and sent to the current source
BSS on which the concerned MS is connected.
Upon receiving the Handover Command message, the BSS starts timer T8. A Handover
Command message is then sent by the BSS to the concerned MS. This message must
contain the handover reference number previously allocated by the target BSS
The timer T8 is used to initiate the BSS clear sequence. The T8 is reset when either the
MS returns to the source BSS (due to handover failure) or the MSC send a Clear
Command (handover complete).
Following reception of the Handover Command the MS accesses the target BSS:
The BSS checks the handover reference number to ensure that it is the same as
expected.
If it is as expected ( the reference number), it is passed to the MSC.
When the MS is successfully in communications, it will send a handover complete
message to the BSS, which is passed to the MSC.
The MSC sends the Clear Command to the old source BSS, to release the radio
resources.
If target BSS, or the MS are unable to establish a connect, or Timer T8 is expires then
the MS returns to the original BSS and the handover failure message is sent to the MSC.
The handover shows the complete Handover procedure:
ËËË
ËËË

Handover Required Indication
ËË
ËË

Handover Resources Allocation
ËËË
ËËË

Handover Execution 3
ËËË

Handover Procedure
Target Source
MS MSC
BSS BSS
(Handover Required)
DT1
1
(Handover Request Ack) CC
2
CR (Handover Request)
DT1 (Handover Command)

Handover Command
Set T8
Access
(FACCH) (Handover Detect) DT1
3
Establish Air–Interface
Handover Complete
(Handover Complete) DT1
DT1 (Clear Command)
Reset T8
(Clear Command) DT1
STS01_6_41

Release
The release procedure is to inform the BSS that the assigned radio resources and
terrestrial resources should be released.
This procedure can be initiated by the BSS, where the BSS generates a Clear Request
message to the MSC. The MSC then initiates the same release procedure.
Before the MSC initiates the MSC/BSS release it must have carried out the MSC/MS
release procedure using the transparent messages via the DTAP protocol.
The MSC will then send a BSSMAP Clear Command indicating that the radio resource
should be released and the cause of the release (e.g. handover successful).
When the BSS receives this clear command, the clearing of the radio resources is
carried out. When completed it then sends a clear complete message to the MSC. The
MSC then releases the assignment terrestrial resources.
The MSC initiates the SCCP connection release by sending a SCCP Released (RSLD).
The BSS returns the SCCP Release Complete RLC to the MSC.

Release
The release procedure informs the BSS that the assigned radio
resource should be released.
MS BSS MSC
DT1 (CLEAR COMMAND)
Cause = ?
Chan Rel SET T10 CIC = X
etc.
DISC
(FACCH)
UA
(CLEAR COMPLETE) DT1 Release
Terrestrial
Resources
RLSD
RLC
The BSS can initiate this procedure by sending Clear request to the MSC.
SYS01_6_42

Classmark
Update
The classmark is a way GSM have defined the types of MS that can be connected to the
network. (e.g. vehicle and portable, portable or handheld). This will obviously have a
bearing on the air-interface connection.
Also these MS equipments may be altered (e.g. portable becomes vehicle while making
a call).
The BSS must be able to inform the MSC of a classmark update, when this is received
from a MS. This message contains information on several transmission parameters
relevant to the MS.
This procedure will normally only be used where the power class of a MS change whilst
the MS has a dedicated resource.
Note:
To enable the MSC to initiate a command enquiring a chg_element command has been
introduced at the BSC.
The new command enables the use of commands enquiry over the A-interface and
supports the MOBILE STATION CLASSMARK 3 MESSAGE (classmark 3 element
indicates the support of the additional encryption algorithms A5/4–A5/7
chg_element phase2_classmark_allowed<element_value><bsc or 0>
<element_value> 0: Disabled (default) the BSS shall send only classmarks
supported in GSM phase 1 to the MSC.
1: Enabled the BSS shall send classmarks supported in
GSM Phase 2 to the MSC (includes classmark 3).

Classmark Update
The BSS uses this procedure to inform the MSC of a MS classmark change.
MS BSS MSC
CLASSMARK CHANGE
DCCH
(SACCH)
(CLASSMARK UPDATE) DT1
MS BSS MSC
DT1
DATA REQUEST (CLASSMARK REQUEST)
(CLASSMARK ENQUIRY)
DATA INDICATION
(CLASSMARK CHANGE)
DT1
(CLASSMARK UPDATE)
SYS01_6_43

Cipher Mode
Control
The cipher mode control procedure allows the MSC to pass cipher mode information to
the BSS to select and load the user data and signalling encryption device with the
appropriate key.
This is achieved by sending the BSS a Cipher Mode Command message. Receipt of the
message at the BSS will invoke the encryption device and generate the Cipher Mode
Command message via the radio interface.
Receipt of the Cipher Mode Complete message via the air-interface is used internally by
the BSS to achieve air-interface synchronisation.
When this has been achieved a cipher mode complete message is returned to the MSC.
If in the cipher_mode_command from the MSC the cipher response mode is present and
it indicates that the International Mobile station Equipment Identity (IMEI) must be
included by the mobile, then the BSC shall request in the ciphering mode command the
mobile station to include its IMEI in the ciphering mode complete message.
Phase 2 GSM recommendations introduced A5/2 encryption algorithm (place holders
exist for additional A5 algorithms) if in the cipher mode command the MSC requests the
BSS to use an A5 algorithm that it does not support the BSS shall return a cipher mode
reject message with the cause clue “Ciphering Algorithm not Supported”. Also, a cipher
mode reject will be returned to the MSC if the MSC requests a change of ciphering
Algorithm when ciphering is already active.
Note:
1. To enable the use of the cipher mode reject message at the BSC the
chg_element command must be used
chg_element ciph_mode_rej_allowed<element_value><bsc or 0>
<element_value> 0: Disabled the BSS shall not sent Cipher mode
reject messages to the MSC.
1: Enabled the BSS may send Cipher Mode Reject
2. The MSC must also support CIPHER_MODE_REJECT.

Cipher Mode Control
The procedure allows the MSC to pass cipher mode information to the BSS (and MS).
MS BSS MSC
DT1 (CIPHER MODE COMMAND)
CIPHERING MODE COMMAND

SACCH
CIPHERING MODE COMPLETE
SDCCH
CIPHER MODE COMPLETE
MS BSS MSC
DT1 (CIPHER MODE COMMAND)
(CIPHER MODE REJECT) DT1

CAUSE VALUE = CIPHERING
ALGORITHM NOT SUPPORTED
SYS01_6_44

Initial MS
Message
The initial L3 message from the MS which has to be passed to the MSC is received
piggybacked on the Set Asynchronous Balanced Mode (SABM) frame. This could be
Cipher Mode (CM)-Service Request, page response, re-establishment request, Location
update request.
Whichever message type the BSS needs to carry out two basic requirements:
perform SCCP connection to the MSC to enable the passing of the message.
analyse part of the MS information to enable correct connection to the MS.
Enabling the BSS to analyse the message to a level which allows the extraction of the
classmark information. However the entire initial message is also passed to the MSC,
using a “Complete Layer 3” information message. This message is piggybacked on to
the SCCP Connection Request (CR) message.
This is a one-off procedure, as all other messages between MSC and MS use the DTAP
transparent protocol.

Initial MS Message
Initial Layer 3 message from MS is analyzed by the BSS to extract the Classmark
Information, before passing to the MSC.
BSS required to carry out two actions:
Maintain (radio resource) link to MS.
Establish SCCP connection to MSC.
MS BSS MSC
Access Burst
RACH
AGCH
SABM
SDCCH
UA Complete L3 Information
SDCCH (CM SERV) CR
CC
CM SERV.REQ = CM Service Request
SYS01_6_45

Queueing
Indication
The purpose of the queueing indication procedure is to inform the MSC about a delay in
the necessary dedication radio resources.
This procedure is only relevant for Traffic Channels (TCH) assignment and /or for
handover of Traffic Channels (TCH).
After receiving the assignment request message but without the necessary TCH
resources available the message is put into a queue. The queueing indication message
is sent to the MSC and a timer T11 set.
If T11 expires before the necessary resources become available an Clear request
message is returned to the MSC.
The procedure is terminated with a successful assignment of the traffic channel by
sending an assignment complete.

Queueing Indication
To inform the MSC about a delay in allocation of the necessay dedicated

radio resources.
MS BSS MSC
DT1 (ASSIGN. REQUEST)
No Resources
Start T11
(Queueing Indication) DT1
Resources Available
ASSIGN CMD
ASSIGN CMP
(ASSIGN. COMPL) DT1
CLEAR REQUEST
T11 Expires
SYS01_6_46

Timers Version 1 Revision 1
Timers
The concept of timers is to ensure that an action/response that is required to be
performed is carried out in the correct sequence and in the required time. If the
system/process fails to carry out this action/response before the timer set has expired,
then this generates another sequence of events, normally release/reset (indicated by
failure message).
Within the GSM system there are a number of different levels of timers, most of which
have to be defined.
The most critical within the A-interface are Message Transfer Part (MTP) Level 2 and
Level 3 timers.
MTP Level 2
Timers
T1 Timer “alignment ready”
T2 Timer “not aligned”
T3 Timer “aligned”
T4 Proving period timer= 216 or 212 octet transmission time
T5 Timer “sending SIB”
T6 Timer “remote congestion”
T7 Timer “excessive delay of acknowledgement”
PE Emergency proving period
PN Normal proving period
MTP Level 3
Timers
T1 Delay to avoid message mis-sequencing on changeover
T2 Waiting for changeover acknowledgement
T3 Time controlled diversion – delay to avoid mis-sequencing on changeback
T4 Waiting for changeback acknowledgement (first attempt)
T5 Waiting for changeback acknowledgement (second attempt)
T6 Delay to avoid message mis-sequencing on controlled rerouting
T7 Waiting for signalling data link connection acknowledgement
T8 Transfer prohibition timer (transient solution)
T9
T10 Waiting to repeat signalling route set test message
T11 Transfer restricted timer
T12 Waiting for uninhibit acknowledgement
T13 Waiting for force uninhibit
T14 Waiting for inhibition acknowledgement
T15 Waiting to start signalling route set congestion test
T16 Waiting for route set congestion status update
T17 Delay to avoid oscillation of initial alignment failure and link restart

Version 1 Revision 1 Timers
BSSMAP Timers
There is a number of timers defined with the GSM Recommendation 08.08 for the
passage of BSSMAP messages. The actual time is set by the system Operations and
Maintenance with the system data base. A complete list of timers in the BSSMAP
procedures is as follows:
Timer Title LOC
T1: Time to receipt of blocking ack BSS
T2: Reset guard period at the MSC MSC
T3: Resource indication periodicity BSS
T4: Time to return of Rest Ack BSS
T5: Overload timer MSC/BSS
T6: Overload timer MS/BSS
T7: Handover required periodicity BSS
T8: Time to receipt of successful handover

information BSS
T10: Time to return of Assignment Complete

or Assignment Failure form MS BSS
T11: Maximum allowed queuing time BSS
T12: Time to receipt of Reset Cit Ack MSC/BSS
T13: Reset guard period at the BSS BSS
T16: Time to return of Reset Ack at the MSC MSC
Tqho: Maximum allowed queuing time for

handover BSS

Timers Version 1 Revision 1

Appendix A

Appendix A – MSC to BSC Interface (A-interface) Version 1 Revision 1
Appendix A – MSC to BSC Interface (A-interface)
Exercise
Construct, using flow diagrams, the message sequence for a Mobile to Mobile call, where
the originating Mobile has the capacity of encryption.
The Network carries out complete authentication for each subscriber before allowing
access to the system.
For this particular call setup the two individual Mobiles are on the same BSC but are held
on different BTS cells.
Your answer should include the BSSAP message type, SCCP message type and in
which direction the message is being passed over the MSC–BSC interface.

Version 1 Revision 1 Appendix A – MSC to BSC Interface (A-interface)


Appendix A – MSC to BSC Interface (A-interface) Version 1 Revision 1

Appendix B

Appendix B – MSC–BSS Message Types Version 1 Revision 1
Appendix B – MSC–BSS Message Types
DTAP Messages
The “A” interface carry’s DTAP messages as defined in TS GSM 04.08. A summary of
the message types is listed below for Call Control and Mobility Management.
Messages for Circuit-switched call control

Call establishment messages: TS GSM 04.08 Reference
ALERTING 9.3.1
CALL CONFIRMED 1) 9.3.2
CALL PROCEEDING 9.3.3
CONNECT 9.3.5
CONNECT ACKNOWLEDGE 9.3.6
EMERGENCY SETUP 1) 9.3.8
PROGRESS 9.3.17
SETUP 9.3.23
Call Information phase message: TS GSM 04.08 Reference
MODIFY 1) 9.3.13
MODIFY COMPLETE 1) 9.3.14
MODIFY REJECT 1) 9.3.15
USER INFORMATION 9.3.31
Call Clearing messages TS GSM 04.08 Reference
DISCONNECT 9.3.7
RELEASE 9.3.18
RELEASE COMPLETE 9.3.19
Messages for supplementary service control: TS GSM 04.08 Reference
FACILITY 9.3.9
HOLD 1) 9.3.10
HOLD ACKNOWLEDGE 1) 9.3.11
HOLD REJECT 1) 9.3.12
RETRIEVE 1) 9.3.20
RETRIEVE ACKNOWLEDGE 1) 9.3.21
RETRIEVE REJECT 1) 9.3.22
Miscellaneous messages: TS GSM 04.08 Reference
CONGESTION CONTROL 9.3.4
NOTIFY 9.3.16
START DTMF 1) 9.3.24
START DTMF ACKNOWLEDGE 1) 9.3.25
START DTMF REJECT 1) 9.3.26
STATUS 9.3.27
STATUS ENQUIRY 9.3.28
STOP DTMF 1) 9.3.29
STOP DTMF ACKNOWLEDGE 1) 9.3.30

Version 1 Revision 1 Appendix B – MSC–BSS Message Types
BSSMAP
Below is a list of the Radio Resource and BSSMAP messages used on the A-Interface.
The message types are defined in TS GSM 04.08 (Radio Resource) and TS GSM 08.08
(BSSMAP).
Messages for Radio Resources management

Channel establishment messages: TS GSM 04.08 Reference
ADDITIONAL ASSIGNMENT 9.1.1
IMMEDIATE ASSIGNMENT 9.1.18
IMMEDIATE ASSIGNMENT EXTENDED 9.1.19
IMMEDIATE ASSIGNMENT REJECT 9.1.20
Ciphering messages: TS GSM 04.08 Reference
CIPHERING MODE COMMAND 9.1.9
CIPHERING MODE COMPLETE 9.1.10
Handover messages: TS GSM 04.08 Reference
ASSIGNMENT COMMAND 9.1.2
ASSIGNMENT COMPLETE 9.1.3
ASSIGNMENT FAILURE 9.1.4
HANDOVER ACCESS 9.1.14
HANDOVER COMMAND 9.1.15
HANDOVER COMPLETE 9.1.16
HANDOVER FAILURE 9.1.17
PHYSICAL INFORMATION 9.1.28
Channel release messages: TS GSM 04.08 Reference
CHANNEL RELEASE 9.1.7
PARTIAL RELEASE 9.1.26
PARTIAL RELEASE COMPLETE 9.1.27
Paging messages: TS GSM 04.08 Reference
PAGING REQUEST TYPE 1 9.1.22
PAGING RESPONSE 9.1.25

MSC–BSS Message Types Version 1 Revision 1
MSC–BSS Message Types
BSSMAP
Messages for Radio Resources management

System Information messages: TS GSM 04.08 Reference
SYSTEM INFORMATION TYPE 1 9.1.31
SYSTEM INFORMATION TYPE 2bis 9.1.33
SYSTEM INFORMATION TYPE 5bis 9.1.37
Miscellaneous messages: TS GSM 04.08 Reference

CHANNEL MODE MODIFY 9.1.5
CHANNEL MODE MODIFY ACKNOWLEDGE 9.1.6
CHANNEL REQUEST 9.1.8
CLASSMARK CHANGE 9.1.11
CLASSMARK ENQUIRY 9.1.12
FREQUENCY REDEFINITION 9.1.13
MEASUREMENT REPORT 9.1.21
SYNCHRONIZATION CHANNEL INFORMATION 9.1.30
RR STATUS 9.1.29
BSSMAP
Messages
Message Name: TS GSM 08.08 Reference
ASSignment REQuest 3.2.1.1
Assignment COMplete 3.2.1.2
BLOck 3.2.1.3
BLocking Acknowledge 3.2.1.4
circuit group block 3.2.1.41
circuit Group blockING acknowledge 3.2.1.42
circuit group unblock 3.2.1.43
circuit group unblockING acknowledge 3.2.1.44
CLear command 3.2.1.21
CLear COMplete 3.2.1.22
CLear REQuest 3.2.1.20
UnBLOck 3.2.1.6
UnBLocking Ack 3.2.1.7
HaNDover CaNDidate ENQuirE 3.2.1.14

Version 1 Revision 1 MSC–BSS Message Types
BSSMAP
Messages
HaNDover CaNDidate RESponse 3.2.1.15
HaNDover REQuest 3.2.1.8
HaNDover ReQuireD 3.2.1.9
HaNDover ReQuired Reject 3.2.1.37
HaNDover ReQuest ACKnowledge 3.2.1.10
HaNDover COMmand 3.2.1.11
HaNDover CoMPlete 3.2.1.12
HaNDover FaiLuRe 3.2.1.16
HaNDover PerForMed 3.2.1.25
HaNDover DETect 3.2.1.40
RESource REQuest 3.2.1.17
ReSeT 3.2.1.23
ReSeT ACK 3.2.1.24
RESource indication 3.2.1.18
Paging 3.2.1.19
Overload 3.2.1.26
MSC Invoke trace 3.2.1.27
BSS Invoke trace 3.2.1.28
Classmark update 3.2.1.29
CLASSMARK REQUEST 3.2.1.46
Cipher Mode Command 3.2.1.30
Cipher Mode Complete 3.2.1.31
Cipher mode Reject 3.2.1.48
Complete layer 3 information 3.2.1.32
Queing indication 3.2.1.33
SAPI “n” reject 3.2.1.34
Reset circuit 3.2.1.38
Reset circuit acknowledge 3.2.1.39
CONFUSION 3.2.1.45
UNEQUIPPED CIRCUIT 3.2.1.47

MSC–BSS Message Types Version 1 Revision 1

Chapter 7
BSS–OMCR Interface (OML)


Chapter 7
BSS–OMCR Interface (OML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
BSS–OMCR Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–1
BSS–OMCR Interface (OML) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–2
Motorola Application Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
File Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
Event/Alarm Reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
Remote Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–4
OMC–BSS Interconnection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–6
OML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–8
X.25 Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–10
Physical Link Layer 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–12
Data Link Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–14
Address Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–16
Frame Types – Control field encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–18
X.25 Packet Level Protocol (PLP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–20
Packet Header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–22
Logical Channel Numbers (LCN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–24
Packet Type Identifier (PTI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–26
Control Packet Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–28
Additional Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–30
OMC to BSS Communication DTE Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–32
Virtual Call Setup Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7–34


Version 1 Revision 1 BSS–OMCR Interface
BSS–OMCR Interface
Objectives
State the BSS–OMCR configurations available.
Identify the structure of the X.25 layers.
Identify the Layer 2 (data link) parameter.
Identify the X.25 packet level protocol.
State the procedure for establishing a X.25 call.

BSS–OMCR Interface (OML) Version 1 Revision 1
BSS–OMCR Interface (OML)
Introduction
The OMC communications requirements are via specific protocols derived from the OSI
Network Management Model.
The main Management interface between the OMC and the BSS is based on Motorola
applications protocols, with CCITT X.25 protocols used as the bearer.
These protocols are used to transfer all Operations and Maintenance data between the
OMC and the BSS.
The application protocols are:
File Transfer
Event/Alarm reporting
Remote Login
At the BSC the DTE address determine which default timeslots/2Mbit/s links we
terminate the OML on.
BSC
0 MSI slot 16 Port 0 TS 1 Cage 0
RXCDR
0 MSI 10 Port 0 TS 1 Cage 0

Version 1 Revision 1 BSS–OMCR Interface (OML)
OMC-R Connections
OMC–R
2 Mbit/s Link
OML (XCDR) OML (BSC)
MSI
RXCDR
MSI
2 Mbit/s Link
MSI
BSC
SYS01_7_2

Motorola Application Layer Version 1 Revision 1
Motorola Application Layer
File Transfer
Files can be transferred from the OMC to BSS and vice versa.
This protocol supports uploading of network element software and data. For example,
backing-up databases, collecting statistics, up-grading Base Station software.
Event/Alarm
Reporting
This protocol provides a BSS with a mechanism for informing the OMC of changes in
operational conditions. For example:
the start of an alarm condition
an indication that a statistics file is ready for collection.
Remote Login
Remote Login allows the OMC to access the MMI of a network element.
The OMC uses this protocol to transfer information between an MMI session at the OMC
and an MMI session at the Base Site.
With the introduction of Software 1.4.1.0 it is now possible to have up to 4 simultaneous
Remote Login sessions at a BSS, each to a different GPROC.
The GPROCs are selected on a round-robin basis, with no GPROC having priority over
any other.

Version 1 Revision 1 Motorola Application Layer
External Communications: OMC to NE
OSI SYSTEM PROCESSOR

Layers
7
LOGIN TO BSS MMI

APPLICATION
EVENT/ALARM
REPORTING
TRANSFER
REMOTE
PRESENTATION 6 Application
FILE
Services
SESSION 5
TRANSPORT 4
NETWORK 3 X.25 PLP
DATA LINK 2 X.25 HDLC X.25

(LAP–B)
PHYSICAL 1 X.21 bis
64Kb port inter-

face
X.25 Packet Switch
2 Mbps
link
NE1 NE2 NE64
SYS01_7_3

OMC–BSS Interconnection Version 1 Revision 1
OMC–BSS Interconnection
Connections from the OMC to the BSS can be made via two methods.
Public/Private X.25 networks using the A-interface (MSC–BSC). Normally via the
Remote Transcoder, where the OML’s are multiplexed on to a 2 Mbit/s Link before
the X.25 network.
A dedicated 2 Mbit/s link to the BSS using one TS.

Version 1 Revision 1 OMC–BSS Interconnection
External Communications: OMC to BSS
OM
SYS-
C
PRO-
TEM
CESSOR
O&M V.35 con-
Pack (seven
Data nections
connec-
ets physical
tions)
PAC
X.
SWI
KET
25
TCH
2 MB MULTI-
2 MB
link PLEXER
link
PSDN
2 MB MSC
link
2 MB 2 MB
link NAILEDlink
(ONE PER
CONNEC-
6O O&M TIME-64
TIM RXC O&
TIONS TIME-
4K SLOT) K
E-&
b/
DR M
SLO
M b/
BS 1 2 MB SLO
s 2 MB T s
S link T link
BSS
n
B 1
BSS
SS B 2 BSS
3 4
SS
PSDN – Public Switched Data Network
SYS01_7_4

OML Version 1 Revision 1
OML
The download of software from the OMC to the BSC can take considerable time, to
decrease this download time dual OML downloading is supported, provided the following
provisions are met.
Two 2 Mbit/s links are required
Two DTE addresses are required (one per link)
Conventional code download only
BSS executes in ROM
Two GPROCs to support PLP processes
If the above conditions are met then the download time is reduced by approximately
40%.
If only one code object is to be downloaded then there is no saving.
Code objects are not shared across the X.25 links, therefore there is no height if only
one code object is to be downloaded.
The OML can now carry out 8 simultaneous uploads.

Version 1 Revision 1 OML
Dual OML Download (BSC)
OMCR
(Transparent to
RXCDR BSCs OMLs)
MSI MSI
TDM
HIGHWAY
PLP PLP
AGENT AGENT
IP
GPROC GPROC
SYS01_7_5

X.25 Layers Version 1 Revision 1
X.25 Layers
Introduction
The X.25 protocol specifies the format and protocols necessary to transfer information
between DTE and DCE nodes for packet mode terminals connected to Public Data
Network (PDN). It conforms to Layers 1, 2 and 3 of the OSI model.
Data Circuit-terminating Equipment (DCE) – The modem or digital interface that links to
the data communications network.
Data Terminal Equipment (DTE) – Any type of data communication equipment accessing
the network.
Virtual circuit – A connection between DTE’s through the network. The connection is not
really patched through but packets are routed from one DTE to the other DTE by the
network. More than one virtual circuit can exist on the physical link.
There are two types of virtual circuits – permanent (PVC) and switched (SVC). The
OMC software does not handle PVCs only SVCs.

Version 1 Revision 1 X.25 Layers
X.25
D D PDN D D
T C C T
(Public Data Net-
E E E E
work)
X.25 X.25
– interface between DTE and DCE for packet mode terminals connected
to Public Data Network (PDN).
DTE = Data Terminal Equipment
DCE = Data Circuit–terminating Equipment
SYS01_7_6

X.25 Layers Version 1 Revision 1
Physical Link
Layer 1
The hardware characteristics that control the physical line between the DTE and the DCE
conforms to (ITV) X.21 bis.
The OMC–BSS Link can be linked via the X.25 network to a MSI/XCDR on a BSC or
RXCDR with Time slot 1 allocated on the 2Mbit/s link.

Version 1 Revision 1 X.25 Layers
X.25 Layers
"-*#% #&$ -)
#* ,* '

+ +' **
'%+! #& - &
'&&+#'& #& -

,&+#'&% (#& ")+)#*+#* #& #&
"-*#% (')+ '&&+#'&

Data Link Layer 2 Version 1 Revision 1
Data Link Layer 2
Overview
This describes how data being carried between DTE and DCE is protected against
errors. A bit-orientated protocol, a subset of High-level Data Link Control (HDLC)
Asynchronous Balanced Mode, called Link Access Procedure Balanced (LAPB) defines
the frame envelope to carry the data across the physical link with a high degree of error
and flow control.
The basic frame structure of the LAPB frame is very similar to the LAPD frame covered
in Section 3 (A-bis interface). Only the differences will be covered in this section.

Version 1 Revision 1 Data Link Layer 2
Frame Structure – Layer 2
FLAG FRAME CHECK INFORMATION CONTROL ADDRESS FLAG

SEQUENCE

SYS01_7_8

Address Field
The address field is a single octet as only two address are required within X.25.
DTE address 03 hex
DCE address 01 hex
All frames are either a Command or Response frame on each Link.

Address Field
Command – 01 hex
Response – 01 hex
DTE Command – 03 hex DCE

Response – 03 hex

SYS01_7_9


Frame Types –
Control field
encoding
There are three types of frames:
I-frame carries a packet for Layer 3, this is always a command, which must be
acknowledged.
S-frame Manages flow of I-frames, usually a response, contains N(R) for
acknowledgment.
U-frame Used to start and stop Layer 2 activity.
# Exchange of SABM + UA opens Link; N(S) is set to 0 at each end.
Exchange of DISC + UA closes Link.
P/F: P=0 in ‘normal’ circumstances no hurry to respond.

P=1 demands an immediate response ie. reduces window size to one.
F in response must match P in command to which it relates.
# Only required from DTE (BSS) to DCE (OMC)
Control Field
Bit/s 1 or 1 and 2 determine which type of frame is being transmitted.
If supervisory frame then bits 3 and 4 determine which type of supervisory frame is being
transmitted.
If unnumbered frame then bits 3, 4, 6, 7 and 8 determine which type of unnumbered
frame is being transmitted.
bit 5 is always the “P” or “F” flag.
Bit 6. 7 and 8 for “I” and “S” frames is coded as N(R)
Bits 2, 3 and 4 for the “I” frame is coded as N (S)

Control Field Encoding
8 7 6 5 4 3 2 1
FOR- COM- RESPONSE ENCOD-

MAT MAND ING
Informa-
I (Informa- N(R P N(S 0
transfer
tion
tion) ) )
RR RR
N(R P/ 0 0 0 1
(Receive (Receive
) F
Ready) Ready)
RNR (Re- RNR (Re-
Supervis- N(R P/ 0 1 0 1
Not
ceive Notceive
Ready)
ory ) F
Ready)
REJ REJ
N(R P/ 1 0 0 1
(Re- (Re-
) F
ject) ject)
SABM
0 0 1 P 1 1 1 1
Asyn(SetBal
Mode)
DIS
0 1 0 P 0 0 1 1
(Discon-
C
nect)
Unnum- D
0 0 0 F 1 1 1 1
(Disconnect
M
bered
Mode)
U
0 1 1 F 0 0 1 1
(Unnumb
A
Ack)
FRMR (Frame 1 0 0 F 0 1 1 1
Rej)
SYS01_7_10

X.25 Packet Level Protocol (PLP) Version 1 Revision 1
X.25 Packet Level Protocol (PLP)

Deals with the final end-to-end control procedure known as the PLP (Packet Level
Protocol) Layer describing packet formats and control procedures for the exchange of
data between the BSS and the OMC. A packet is the smallest unit of information
originated and X.25 protocol stipulates that all packets will consist of whole number
octets. The number of octets transmitted within each packet depends on the packet
type, the minimum length being 3 octets (the header). The X.25 protocol allows packet
lengths of up to 1024 octets, but has been set at a maximum length of 128 octets, within
the OMC-R system.
The packet format can be divided into a packet (control) header (Level 3) and data block,
which forms the information field within the I-frame (Level 2).

Version 1 Revision 1 X.25 Packet Level Protocol (PLP)
X.25 Packet Level Protocol (PLP, Layer 3)
DATA
Packet
DATA LAYER 3
Header
Layer 2 Header Layer 2 Header
FRAM PH
FLAG CHECK DATA CON- AD- FLAG
E
SE- TROL DRESS
QUENCE
INFORMATION FIELD
(Max length 1024 octets)
PH – PACKET HEADER
SYS01_7_11

Packet Header Version 1 Revision 1
Packet Header
All packets have a header consisting of 3 octets.
General Format Identifier (GFI)

Q= qualifier bit used with X29 (control signal for remote PAD Control)
D= delivery bit (not used)
XX= Used to indicate the mode of operation:
01 for modulo 8 working (standard) 10 for modulo 128 working

Version 1 Revision 1 Packet Header
X.25 Packet Header Format
PACKET
DAT
A
Data Header Control Address Flag
3 Octets
8 1 8 1 8 1
PTI LCN GFI LCGN

(1 OCTET) (1 OCTET) (1 OCTET)
LCGN = Logical Channel Group Number

GFI = General Format Identifier
LCN = Logical Channel Number
PTI = Packet Type Identifier
SYS01_7_12

Logical Channel Numbers (LCN) Version 1 Revision 1
Logical Channel Numbers (LCN)

The Logical Channel Number LCN is used between the DTE and DCE to identify specific
connections, it is local to the interface and indicates the virtual circuit. The LCN is
allocated from a table of free LCNs at the call set up time. The DTE allocates the LCN
for outgoing calls and the DCE allocates the LCN for incoming calls, with all packets of
that call (in both directions) having the same LCN.
There are a total of 4096 LCNs available but these have to be shared by all the users,
therefore each user is allocated a group of LCNs to use.
The LCNs have been divided into LCGNs as follows:
16 groups (LCGNs) with 256 LCNs in each group.
BANDLCGN
0 0, 1 Supports PVCs (LCNs 0–511)
1 2, 3 Supports SVC’s incoming only (512 – 1023)
2 4, 5 Supports SVC’s bothways (incoming/outgoing, 1024
1535)
3 6, 7 Supports SVC outgoing (1535 – 2047)
All other LCN’s are not specified and are left open.
Motorola has been allocated LCNs 1024–1055, 32 LCNs in total, as we only have a
maximum of 7 SVCs in use at any time we have no problems with allocation LCNs.
The coding of the LCGN field determines the LCGN group, in Motorola’s case this will
always be LCGN 4, the LCNs for each LCGN group are coded in the range of 0–255 (8
bits).

Version 1 Revision 1 Logical Channel Numbers (LCN)
Logical Channel Number (LCN)
8 7 6 5 4 3 2 1
GFI LCGN
LCN
PTI

!$( ## ( $
$ #$ %!
%$ ## #$ &
## '#$ &
$ " #

SYS01_7_13

Packet Type Identifier (PTI) Version 1 Revision 1
Packet Type Identifier (PTI)

The Packet Type Identifier field is one octet in length. Bit 1 determines whether a data
packet is being sent or a control packet:
Bit 1= 0– Data packet
1– Control packet
Bits 2–7 are coded as shown in the table opposite.

-* ( !, &" * -& *

" * ) $ ) '+ $ $+# (
. !* %( * !* %( " *)
)* " *)

Version 1 Revision 1 Packet Type Identifier (PTI)
Packet Type Identifier (PTI)
Packet Type Octet 3

Bits
From DCE to DTE From DTE to DCE 8 7 6 5 4 3 2 1
Call setup and clearing
Incoming call Call request 0 0 0 0 1 0 1 1
Call connected Call accepted 0 0 0 0 1 1 1 1
Clear indication Clear request 0 0 0 1 0 0 1 1
DCE clear confirmation DTE clear confirmation 0 0 0 1 0 1 1 1
Data and interrupt
DCE data DTE data x x x x x x x 0
DCE interrupt Expidited data DTE interrupt 0 0 1 0 0 0 1 1
DCE interrupt confirmation DTE interrupt confirmation 0 0 1 0 0 1 1 1
Flow control and reset
DCE RR (modulo 8) DTE RR (modulo 8) x x x 0 0 0 0 1
DCE RNR (modulo 8) DTE RNR (modulo 8) x x x 0 0 1 0 1
DTE REJ (modulo 8)* x x x 0 1 0 0 1
Reset request 0 0 0 1 1 0 1 1
DTE reset confirmation 0 0 0 1 1 1 1 1
Restart
Restart indication Restart request 1 1 1 1 1 0 1 1
DCE restart confirmation DTE restart confirmation 1 1 1 1 1 1 1 1
Diagnostic
Diagnostic* 1 1 1 1 0 0 0 1
Registration*
Registration request 1 1 1 1 0 0 1 1
Registration confirmation 1 1 1 1 0 1 1 1
* &) %(('!#- +!## &% +'- %),&'"

&) !) ) ) !( !%!) ( . $- () )& !) ' &' ( '
*( ( !) ' &' &*%)'( !)(
!)
!( % . !)
SYS01_7_14

Control Packet Types Version 1 Revision 1
Control Packet Types

All these packet types are either “Request” or “Confirmation” where the appropriate
confirmation is the only allowed response to the request.
Types:
a) CALL request/Accept.
– carrier full destination address.
– establishes virtual circuit; resets P(S) at each end to zero.
b) CLEAR Request/Confirm
– Releases virtual circuit and LCN
c) RESET Request/Confirm
– clears queues and resets P(S) to zero
d) INTERRUPT Request/Confirm
– this packet can overtake data packets in a queue
– can carry one octet of data
– allows a break facility across the system.
e) RESTART Request/Confirm
– carries LCN 000; clears all virtual circuits
– used to start packet activity.

Version 1 Revision 1 Control Packet Types
Packet Type Identifier
Control packets

$%#"$! '+)*
%$$* &*
$"*"%$ '+)*

$*((+&* $*((+&* %$
$"*"%$ '+)*
()* ()*
$"*"%$ '+)*
)*(* )*(*
SYS01_7_15

Call Request Incoming Call

’00001011’ ’00001011
Call Connected Call Accepted ’
’0000111 ’00001111
1’ ’
DTE DCE DCE DTE
Data
Network
SYS01_7_16

Additional Fields Version 1 Revision 1
Additional Fields
Nearly all packet types contain additional fields along with the 3 octet header.
To summarise these additional fields:
Data Field:
Packet length (set to 128 octets for OMCR)
– option: 16, 32, 64, 256, 512, 1024, 2048, 4096.
Up to 16 octets of data allowed in CALL request packet.
Full 128 octets allowed in CALL Request and clear request packet
(”fast select”).
Address Field:
Always present in call request packet.
Contains both called/calling X.25 address.
Facilities Field:
Always present in call request packet.
Higher protocol can request new packet and window sizes.
Cause and Diagnostics Field:

Always present in restart, reset and clear request packets.
Indicates reason for packet.

Version 1 Revision 1 Additional Fields
Additional Fields
(
( "( #$(#"

) ( #(('
'( ' (
&'' &( # ( ,&

!''
# #""(#" &%)'(
-( &''
-( &'' -( )'&

" +("'#"
('
' (# "#(( "(*#& #$(#"'

$( "(
)' "#'(
"( &'#" #& $(

&'(&( &'( (

OMC to BSS Communication DTE Addresses Version 1 Revision 1
OMC to BSS Communication DTE Addresses

The diagram opposite demonstrates the full implementation of the X.25 DTE address
system used by the Motorola GSM entities. This DTE address used to indicate a single
L3 application at the OMC (OMCR DTE) or a single BSC or RXCDR (BSS DTE).

##
BSS DTE Address
Address 0: 79320101010001
Address 1: Not used
Address 2: Not used
Address 3: Not used

OMCR DTE Address
Address 0: 79310101040141
Address 1: 79310101040142
Address 2: 79310101040143
Address 3: 79310101040144
Address 4: 79310101040145
Address 5: 79310101040146
MOTOROLA LTD. 2001–2

Address 6: 79310101040147
Address 7: Not used
$

# !$
"

##
BSS DTE Address
Address 0: 79320101010002

Address 1: Not used
" Address 2: Not used
Address 3: Not used
OMCR DTE Address

Address 0: 79310101040141
BSS DTE Address Address 1: 79310101040142
Address 0: 79320101010000 Address 2: 79310101040143
Address 1: Not used Address 3: 79310101040144
# OMCR DTE Address Address 6: 79310101040147
Address 0: 7931010104010141 Address 7: Not used

Address 1: 7931010104010142

Address 2: 7931010104010143
Address 3: 7931010104010144

Address 4: 7931010104010145
Address 5: 7931010104010146
Address 6: 7931010104010147
Address 7: Not used
#

$

##
SYS01: GSM Interfaces

BSS DTE Address
Address 0: 79320101010003
Address 1: Not used

Address 2: Not used

## Address 3: Not used
OMCR DTE Address

Address 0: 79310101040141
Address 1: 79310101040142
Address 2: 79310101040143
Address 3: 79310101040144
! Address 4: 79310101040145
Address 5: 79310101040146
Address 6: 7931010104047

Address 7: Not used

##
!

OMC to BSS Communication (DTE Addressing)

" "
BSS DTE Address

Address 0: 79320101010004

Address 1: Not used

Address 2: Not used
Address 3: Not used
OMCR DTE Address
Address 0: 79310101040141
Address 1: 79310101040142
Address 2: 79310101040143
Address 3: 79310101040144
Address 4: 79310101040145
Address 5: 79310101040146
Address 6: 79310101040147
Address 7: Not used
7–33
OMC to BSS Communication DTE Addresses
Virtual Call Setup Procedure Version 1 Revision 1
Virtual Call Setup Procedure

Assuming the Layer 2 Link has been established using LAPB procedures and the
Receiver Ready (RR) packets on the physical link.
The DTE generates the Call Request packet which contains all the required facilities, i.e.
packet length; reverse charging; window size etc. This is sent over the network where
each node along the route checks the facilities requested and set the appropriate LCN for
the duration of that call.

Version 1 Revision 1 Virtual Call Setup Procedure
Virtual Call Setup
DTE DCE DTE
CALL REQUEST
(LCN= 20)
INCOMING CALL
(LCN=3)
CALL ACCEPTED
(LCN=3)
CALL CONNECTED
LCN= 20)
SYS01_7_19

Virtual Call Setup Procedure Version 1 Revision 1

Chapter 8
SMS Cell Broadcast Link


Chapter 8
SMS Cell Broadcast Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
SMS Cell Broadcast Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–1
Short Message Service Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–2
Cell Broadcast Link (CBL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–4
CBC, Cell Broadcast Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–6
BSS, Cell Broadcast Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–8
Mobiles Cell Broadcast Responsibilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–10
SMS CB Database Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–12
Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–12
Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–12
CBL Message Flow Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–14
CBL Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–16
Multiple SVC Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–16
Cell Broadcast Messages from BSC to BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–18
SMS CB Message Structure (Air-Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–20
DRX Scheduling Message Coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–22
New SMS CB Message Bitmap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–24
New SMS CB Message Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–24
Other Message Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–24
Message Description Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–26
First Transmission of an SMS CB within the Schedule Period . . . . . . . . . . . . . . . 8–26
Retransmission Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–26
Free Message Slot, Optional Reading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–28
Free Message Slot, Reading Advised (not yet implemented by Motorola) . . . . . 8–28
Reserved Codepoints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–28


Version 1 Revision 1 SMS Cell Broadcast Link
SMS Cell Broadcast Link
Objectives
Understand the implementation of a CBL.
Understand the operation of a CBL.

Short Message Service Cell Broadcast Version 1 Revision 1
Short Message Service Cell Broadcast

The Cell Broadcast Centre (CBC) is responsible for downloading cell broadcast
messages to the BSC, together with an indication of the repetition rate and the number of
broadcasts per message. The BSC must interpret these messages and transmit each
request to the appropriate BTS(s). Each BTS is responsible for storing and scheduling
cell broadcast messages, as well as ensuring that each broadcast message is
transmitted to cells under its control.
To support interaction with the CBC, this feature shall provide the following functionality:
A real-time interface between the CBC and BSC;
Storage and scheduling of broadcast messages at the Cell Broadcast Scheduler
(CBS);
DRX Schedule Messages, to provide the mobile with information on the next set of
cell broadcast messages;
Enable the operator to monitor and manage the link between the BSC and the
CBC;
Performance measurements for the CBC.
Note: This functionality co-exists with, but does not replace, multiple message
functionality.

Version 1 Revision 1 Short Message Service Cell Broadcast
Short Message Service, Cell Broadcast Provides:
&! ! !$ ! !
! " ! ! !

! "
" ! # ! $!

! ! %! ! !

! ! ! ! !
!$ ! !
"! !

Cell Broadcast Link (CBL) Version 1 Revision 1
Cell Broadcast Link (CBL)

To enable communication between the BSS and the CBC (Cell Broadcast Centre) on
X.25 (LAPB) a link must exist between the BSS and the CBC (64k TIMESLOT). The
BSS is responsible for activating a SVC (Switched Virtual cct) to Upload Information.
The CBC is responsible for activating a SVC to Download Information.
The CBL is a realtime link. The operator is able to manage the CBL device and monitor
its status via the customer MMI.
The application of the X.25 (PLP) is identical to that of the OML implementation.
Note: TYPE 1 and 2 BSCs only support this feature.

Version 1 Revision 1 Cell Broadcast Link (CBL)
Cell Broadcast Link (Terrestrial)
CBE
Customer Cell
Specific Link Broadcast
CBC Entity
CBL (SVS) – 64k

X.25 (LAPB)
CUSTOMER PLP Timeslot Configurable
SIT Real Time
E
(SLAVE)
BSC
(MASTER
Note: The) Cell Broadcast Agent
at the BSC supports the protocol PLP
short stack. Cell
Broadcast
Agent LCF
BTS GPROC
RSL – 64k
Cell LAPD
Broadcast Timeslot Configurable
Scheduler Note: The CBS is responsible for
BTP
the storing and scheduling of Cell
SYS01_8_3 GPROC
Broadcast MSGS.

CBC, Cell Broadcast Responsibilities Version 1 Revision 1
CBC, Cell Broadcast Responsibilities

The CBC has certain functions it should support, specified in GSM 03:41 (Technical
realisation of SMS). The functions are shown opposite.

Version 1 Revision 1 CBC, Cell Broadcast Responsibilities
CBC, Cell Broadcast Responsibilities
! !!"& " %

" !! ! # !
" " !!! " "

"" % !!! % !! & "

""!
!!! " " !
& ! " !! " ! " " ""!

" !! !" !" " "

" !! !" "

" !! !" ! " & "
" "" & ! & !!! !"
" !" ""& ! " "

" ! "" !# " " $ #""& " "

BSS, Cell Broadcast Responsibilities Version 1 Revision 1
BSS, Cell Broadcast Responsibilities

The BSS has certain functions it should support, specified in GSM 03.41 (Technical
The BTS shall detect CBCH overload. If overload is detected the BSS shall reject any
further requests from the CBC for cells with the overloaded CBCH.
Note: Motorola have placed the Cell Broadcast Scheduler and storage functionality at
the BTS. GSM specifies that each message may be broadcast at a different frequency.
It identifies the maximum frequency as once every 30 seconds, the minimum frequency
as once every 32 minutes.
GSM specifies the maximum number of broadcasts of a message as 2880, thereby
enabling the message to be broadcast every 30 seconds for 24 hours. If the
No_of_Broadcast_Requested is set to 0, the BSS shall broadcast the message
indefinitely or until a CBSE_KILL_MESSAGE is received from the CBC.

Version 1 Revision 1 BSS, Cell Broadcast Responsibilities
BSS, Cell Broadcast Responsibilities
" #$ $
# $ ' "#! #$#
$"!"$$ # " $

" $ #" ## "!$$ "$ #
$ &
" $ (%$ # % $
%(%$ ###
%$ ### $ ""$ # #
" #$ %"
# $ ' "#! #$#
" $ & $ #%##% "!$

" #$ # " $
"$ #% ### $ #%
$"### #
#% ###
## ### &" " $"
$ " " #$ ### $ "
% " #$ ### $
$ "

Mobiles Cell Broadcast Responsibilities Version 1 Revision 1
Mobiles Cell Broadcast Responsibilities

The mobile has certain functions it should support, specified in GSM 03:41 (Technical

Version 1 Revision 1 Mobiles Cell Broadcast Responsibilities
Mobiles Cell Broadcast Responsibilities
! $
! # # !

& !
"!#
"!
!
! !
# ! !% ! ! ! # !

& ! $ "!
!% !

# "
!% ! $

! ! ! !

SMS CB Database Commands Version 1 Revision 1
SMS CB Database Commands

The following new command is introduced by this feature:
add_link
Command Line
add_link <mms_a_id_l><mms_a_id_2><timeslot_number_a>
<mms_b_id_l><mms_b_id_2><timeslot_number_b>
The following inputs are inbound from BSC to the RXCDR.
MMS_a_id_1: First ID of T1/E1 line 9 (values 0–50)

MMS_a_id_2: Second ID of T1/E1 line 9 (values 0 or 1)
timeslot_number–a: Specifies timeslot on T1/E1 line 9.
Values T1 – 1 to 24
Values E1 – 1 to 31
The following input parameters are outbound from the RXCDR to the MSC, OMC or
CBC:
MMS_b_id_1: MMS_b_id_2: timeslot_number_b:
Functional
Description
The command add_link shall replace the existing commands add_oml and
add_rxcdr_mtl. It shall enable the operator to establish a link between the following
sites:
The BSC and the MSC.
The BSC and the OMC.
The BSC and the CBC.
This command shall be rejected under the following conditions:
If the MMS timeslot is in use.
If the command is entered outside SYSGEN mode.
If the command is entered at an insufficient security level.
If the command is entered at a non-RXCDR site.
Note: Other commands have been modified to include the new CBL device, i.e. equip
cbl, ins_device, chg_dte and other supporting commands.

Version 1 Revision 1 SMS CB Database Commands
SMSCB Database Commands

!
!

!

CBL Message Flow Scenarios Version 1 Revision 1
CBL Message Flow Scenarios

The establishment of a CBL SVC can be initiated by the CBC or the BSS. The
procedure is shown opposite.
The normal flow of information between CBC and BSS is by means of N_Data
indications, requests and confirm messages.

Version 1 Revision 1 CBL Message Flow Scenarios
CBL Message Flow Scenarios
#$# $ !% !

&
&

&

#$# $ "!

&
&

&


CBL Protocol Version 1 Revision 1
CBL Protocol
The X.25 (LAPB) implementation is identical to that of the OML. The BSS supports a
protocol stack which utilises an application layer convergence function for connecting the
BSS and the CBC. This means it supports the lower 3 OSI layers in what is more
commonly referred to as the short stack by GSM 03.49 (Example Protocol Stacks for
Interconnecting CBC and BSC).
Multiple SVC
Connections
The BSS shall support a maximum of 2 SVC connections – the Upload SVC (BSS to the
CBC) and the Download SVC (CBC to the BSS). The Upload SVC is controlled by the
BSS and is established when the BSS needs to send restart or failure information to the
CBC. The BSS shall tear down the SVC if the SVC is idle for longer than a timeout
period. The Download SVC is established only at the request of the CBC. The BSS has
no control over the Download SVC. It is not able to establish or tear down the
connection, unless the operator requests a lock_device command at the MMI.

Version 1 Revision 1 CBL Protocol
A Protocol Stack which utilizes an Application-Network

layer convergence function for interconnecting CBC and
BSC
Application Layer – CBS Application
Layers 4,
5 & 6 not Convergence Function:
used Maps application entity
protocol (CBSE)
directly to network
Layer 3 layer.
(Network Layer – as defined by X.213)
Layer 2
(Link Layer)
Layer 1
(Physical Layer)
CBSE – Cell Broadcast Short Message Element

SYS01_8_9

Cell Broadcast Messages from BSC to BTS Version 1 Revision 1
Cell Broadcast Messages from BSC to BTS

GSM recommend that 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 (GSM 04.12).
With the SMS BROADCAST REQUEST mode of operation, the 88 octet fixed length
CBS page is split into four 22 octet blocks which are carried in SMS BROADCAST
REQUEST messages as follows:
octets 1–22 are transferred in the 1st SMS BROADCAST REQUEST
with a sequence number (GSM 04.12) indicating first block
octets 23–44 are transferred in the 2nd SMS BROADCAST REQUEST
with a sequence number (GSM 04.12) indicating second block
octets 45–66 are transferred in the 3rd SMS BROADCAST REQUEST
with a sequence number (GSM 04.12) indicating third block
octets 67–88 are transferred in the 4th SMS BROADCAST REQUEST
with a sequence number (see GSM 04.12) indicating fourth block

Version 1 Revision 1 Cell Broadcast Messages from BSC to BTS
Cell Broadcast Messages from BSC to BTS
BSC BTS
64k LAPD (RSL)

CELL CELL
BROADCAST BROADCAST
AGENT SCHEDULER
MOTOROLA IMPLEMENT A SINGLE 88

OCTET MESSAGE FOR SMCB.
SYS01_8_10

SMS CB Message Structure (Air-Interface) Version 1 Revision 1
SMS CB Message Structure (Air-Interface)

GSM specifies that each message to be broadcast shall consist of a number of pages,
where a page is of the following format:
6 octet header
82 octets of user data (93 characters)
GSM identifies a maximum number of pages as 15, with a minimum of 1. This feature
currently supports a single page only.
The BTS stores a maximum of 650 messages, where each message is a single page of
up to 88 octets of message text plus queuing overhead. Each cell can send any or all of
these messages.

Version 1 Revision 1 SMS CB Message Structure (Air-Interface)
SMS CB Message Structure
BLOCK TYPE
The purpose of the Block Type is to identify the function of the block and message being sent.
Bit: 8 7 6 5 4 3 2 1
Octet:
Spare LPD Spare Sequence Number
0 0 1 0 1
LPD = 01 All others are ignored
Bit No: 4 3 2 1
0 0 0 0 First block
0 0 0 1 Second block
0 0 1 0 Third block
0 0 1 1 Fourth block
First schedule block:
1 0 0 0
Message contains
SMSCB scheduling
information
Null message (does

1 1 1 1 not contain valid
SMSCB information)
All other values of bits 4 to 1 are reserved for future use.

The use of a reserved code point shall cause the message to be ignored.
The SMS CB message is a message with four consecutive blocks, with Block Types
“first block”, “second block”, “third block” and “fourth block”.
A null message (which is indicated by the Sequence Number 1111)

(binary) shall have octets 2 to 23, inclusive, filled with the value 2B (hex).
The SMS CB message coding is defined in Technical Specification GSM 03.41.
SYS01_8_11

DRX Scheduling
Message Coding
The BSS shall transmit DRX Schedule Messages (refer to TS GSM 04.12 [3]) to the
Mobile to provide it with information on any following cell broadcast messages. The
Schedule Message enables the Mobile to minimise battery usage, by allowing it to ignore
transmissions of unwanted messages.
The text of the Schedule Message provides information pertaining to the CB messages
sent afterward.
A Schedule Message consists of 4 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 shall be
padded with the hexadecimal value “2B” after 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 on the opposite
page.
Octets following the last part (n+1 to 88 inclusive), if any, shall be ignored.
When bits are indicated as spare, they shall be set to the indicated value (0 or 1) by the
network, and their value shall be ignored by the Mobile Station.

SMSCB Message Structure
DRX SCHEDULE MESSAGE CODING

Bit: 8 7 6 5 4 3 2 1
Octet:
Type Begin Slot Number
0 0 1
spare spare End Slot Number
0 0 2
New CBSMS Message Bitmap
3–8
New CBSMS Message Description

9 – 2m
Other Message Descriptions

(m+1) – n
" "& " ' &

" $#! %
!# !!!
" # # "

If set out of
range then
message is " # #!" " "
ignored # " " $# " "
SYS01_8_12
# "

New SMS CB
Message Bitmap
NM i: The New Message bit i refers to the content of message slot i. Its meaning is as
follows:
1. The message slot contains an SMS CB message which was either not sent during
the previous schedule period, or sent unscheduled during the preceding schedule period;
or, the message is indicated as of free usage, reading advised. The value is 1 both for
the first transmission of a given SMS CB message in the schedule period or a repetition
of it within the schedule period.
0. The message slot is such that value 1 is not suitable.
An SMS CB message fulfilling the criterion for bit value 1 is said in the following to be
“new”. It should be noted that the broadcasting is not necessarily the first one. The
network can choose not to send a given SMS CB message in all schedule periods. In
this case it will be “new” each time it has not been sent in the previous schedule period.
Another case is when a message is scheduled but its first transmission in the schedule
period is pre-empted; the next time the SMS CB message is “new”.
New SMS CB
Message
Description
This 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:
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.
All descriptions pertaining to the first transmission of a new message shall be put at the
beginning, so that mobile stations can determine rapidly where the new messages are.
Other Message
Descriptions
This part contains a one or two octet message description for each of the remaining
message slots in the schedule period, in the order of transmission. This part can be
empty.
The Message Slot Number for each description must be derived from the New SMS CB
Message Bitmap.


$ (!%% !$ ! % "# $$ $!% &% % !!&
'%!
Bit: 8 7 6 5 4 3 2 1
Octet:
NM 1 NM 2 NM 3 NM 4 NM 5 NM 6 NM 7 NM 8 1
SYS01_8_13

Bit: 8 7 6 5 4 3 2 1
Octet
Message Description 1 1
9 – 2m
Message Description p
SYS01_8_13_1

Message
Description
Encoding
Four different encoding formats are specified, respectively: 1) for the first transmission of
an SMS CB message in the schedule period, 2) for the repetition of an SMS CB
message, 3) for a message slot of unindicated usage that Mobile Stations can skip, and
4) for a message slot of unindicated usage that Mobile Stations should not skip. 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 1 indicates a single-octet field, and
value 1 a 2-octet field.
First
Transmission of
an SMS CB
within the
Schedule Period
This describes the content of a message slot which contains the first transmission of an
SMS CB message within the period:
MDT, Message Description Type (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 SMS CB.
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 SMS CB message, as
defined in Technical Specification GSM 03.41.
Retransmission
Indication
When a message slot contains the repetition of an SMS CB message within the schedule
period, the corresponding message description is coded on one octet, as shown
opposite.
MDT, Message Description Type (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 SMS CB message.
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 SMS CB message. The field is encoded in binary, range 1 to 47.


Bit: 8 7 6 5 4 3 2 1
Octet
MDT 1
Message Identifier (high part)
1
Message Identifier (low part) 2

Bit: 8 7 6 5 4 3 2 1
Octet
MDT
Repeated Message Slot Number 1
0 0
SYS01_8_14

Free Message
Slot, Optional
Reading
When no specific information about a message slot is provided, and Mobile Stations
need not read its contents, the Message Description is coded as shown opposite.
MDT, Message Description Type (octet 1 of Message Description): 8-bit field set to
“01000000”. The network can use such a message slot as needed, e.g. for unscheduled
messages or for unscheduled Schedule Messages.
Free Message
Slot, Reading
Advised (not yet
implemented by
Motorola)
When no specific information about a message slot is provided, and Mobile Stations
should read its contents, the Message Description is coded as shown opposite.
MDT, Message Description Type (octet 1 of Message Description): 8-bit field set to
“01000001”. The network can use such a message slot as needed, e.g. for sending
high-priority messages.
Reserved
Codepoints
The values of MDT other than those specified in the previous sections are reserved for
future use. They shall be treated as encoding a one octet message description.


Bit: 8 7 6 5 4 3 2 1 Octet
1
0 1 0 0 0 0 0 0

$ $ % !# # & $$$ $ !%
&% " % & !%!#!
Bit: 8 7 6 5 4 3 2 1 Octet
1
0 1 0 0 0 0 0 1
SYS01_8_15


Appendix A
The 24-Channel System

The 24-Channel (T1) System Version 1 Revision 1
The 24-Channel (T1) System

A digital transmission link with a capacity of 1.544 mbps. T1 uses two pairs of normal
twisted wires, and can normally handle 24 voice conversations, each one digitized at 64
kbp/s.
Digitization and coding of analogue voice signals requires 8000 samples per second (two
times the highest voice frequency of 4000 Hz) and its coding in 8-bit words yields the
fundamental T1 building block of 64 kbp/s for voice.
Combining 24 such voice channels into a serial bit stream using Time Division
Multiplexing (TDM) is performed on a frame by frame basis.
A frame is a sample of 24 channels (24 x 8 = 192) plus a synchronization bit called a
framing bit, which yields a block of 193 bits. Frames are transmitted at a rate of 8,000 per
second (corresponding to the required sampling rate), thus creating a 1.544 mbp/s (8.000
x 193 = 1.544 mbp/s) transmission rate.

Version 1 Revision 1 The 24-Channel (T1) System
The 24-Channel PCM Frame Format
"!

! !
. . . . . . . . . . . . .

!

!

"! !

!
# ! 1 2 3 4 5 6 7 8
! ! " $!

! & ! #% !
!

24-Channel (T1) System Version 1 Revision 1
24-Channel (T1) System

We can associate two types of signalling with a T1 system. Each one has fundamental
differences – each one described below.
Channel -
associated
signalling
Channel-associated signalling for each channel is conveyed in every sixth frame, using
the least-significant bit of each corresponding time-slot, a technique known as “bit
stealing”. This means that for frames 1 to 5 and 7 to 11, 8 bits carry the encoded speech
for each channel, while for frames 6 and 12 only 7 bits of encoded speech are carried.
The perceived degradation to the quality of transmission is negligible. The bit stealing
technique provides a 1.33 khz (i.e. 8 khz/6) signalling capacity for each channel within its
time-slot. The signalling bits for each channel in the sixth and twelfth frames are known
as the “A bit” and “B bit” respectively. The 12-bit frame alignment pattern is carried, one
bit at a time, at the beginning of each odd frame. Similarly, the 12-frame 1.5 ms
multiframe is identified by a 12-bit multiframe alignment pattern carried in the first bits of
even frames.
Common -
channel
signalling
Since a multiframe is not required for common-channel signalling, the first bit of
successive even frames is used to convey common-channel signalling on a T1 system.
This gives only a 4 kbit/s signalling capacity.
However the T1 system can be modified to allow 64 kbit/s Common-channel Signalling to
be carried transparently. This requires the elimination of the bit-7-zero-code-suppression
process normally provided in T1 systems. The suppression process involves the setting
of bit 7 to a 1 for any channel which has eight zeros in a frame. Although this occasional
changing of bit 7 has no perceivable effect on speech transmission, it does prevent the
use of time-slots for carrying 8 bits of data. The T1 system is thus sometimes referred to
as having “non-clear” channels. With the necessary suppression, the T1 system can
carry in its “clear channels” not only 64 kbit/s Common-channel Signalling but also any
other 64 kbit/s data stream. The resulting loss of the zero suppression, with its
consequent reduction in timing content, should not affect the performance of the newer
time-transmission systems. With Clear-channel operation, the T1 system carries one
common-channel signalling channel of 64 kbit/s and 23 traffic channels of 64 kbit/s.
Comparison of
T1 and E1
Systems
There are significant differences between the 30-channel and 24-channel PCM systems.
Apart from the number of speech channels within the frames and the companding laws
used, the systems employ radically different methods of carrying signalling.
The 30-channel system uses a separate dedicated time slot in a bunched format for
channel associated and common-channel signalling, while the 24-channel system uses a
dispersed format with a bit stealing-within time slot method for channel-associated
signalling. Common-channel signalling on a 24-channel PCM (T1) system may be
conveyed over a single-bit separate channel or within one of the 64 kbit//s 8-bit channels.
It is important that these details are appreciated when considering the processes of
digital switching.

Version 1 Revision 1 24-Channel (T1) System
Comparison of PCM Systems
1612%,
!0!,%2%0
%').-!+
3,"%0 .& 8")2 2),% 1+.21
3,"%0 .& 1/%%#( #(!--%+1
3,"%0 .& %-#.$)-' ")21 &.0

7
1/%%#(
-#.$)-' +!5 3
)'-!++)-' #(!--%+8 3-#(%$ )-
")21 /%0 ")2 /%0 #(!--%+ %4%0
!11.#)!2%$ #(!--%+ %4%06 &0!,%1 &0!,%1 *")21
*")21
)'-!++)-' #.,,.-8#(!--%+ 8")2 "62%1 )- ")2 )- %4%06 %4%- &0!,%
*")21
0!,%8!+)'-,%-2 /!22%0- ")21 "3-#(%$ )- .& ")2 1/0%!$ .4%0 .$$ &0!,%1
.$$ &0!,%1
)21 /%0 &0!,%
)2 0!2%
")21
")21
)-% #.$% .0

")21 5(%- #(!--%+8!11.#)!2%$ 1)'-!+ ")2 )1 31%$ %4%06 , &0!,%

-+%11 ,.$)&)%$

24-Channel (T1) System Version 1 Revision 1

Glossary of Terms
MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces Glos–1

Glos–2 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Version 1 Revision 1 Numbers
Numbers
# Number.
2 Mbit/s link As used in this manual set, the term applies to the European
4-wire 2.048 Mbit/s digital line or link which can carry 30
A-law PCM channels or 120 16 kbit/s GSM channels.
4GL 4th Generation Language.

A Version 1 Revision 1
A
A interface Interface between MSC and BSS.
A3 Authentication algorithm that produces SRES, using RAND
and Ki.
A38 A single algorithm performing the function of A3 and A8.
A5 Stream cipher algorithm, residing on an MS, that produces
ciphertext out of plaintext, using Kc.
A8 Ciphering key generating algorithm that produces Kc using
RAND and Ki.
AB Access Burst.
Abis interface Interface between a remote BSC and BTS. Motorola offers a
GSM standard and a unique Motorola Abis interface. The
Motorola interface reduces the amount of message traffic and
thus the number of 2 Mbit/s lines required between BSC and
BTS.
ABR Answer Bid Ratio.
ac–dc PSM AC–DC Power Supply module.
ac Alternating Current.
AC Access Class (C0 to C15).
AC Application Context.
ACC Automatic Congestion Control.
ACCH Associated Control CHannel.
ACK, Ack ACKnowledgement.
ACM Accumulated Call meter.
ACM Address Complete Message.
ACPIM AC Power Interface Module. Used in M-Cell6 indor ac BTS
equipment.
AC PSM AC Power Supply Module. Used in M-Cell6 BTS equipment.
ACSE Associated Control Service Element.
ACU Antenna Combining Unit.
A/D Analogue to Digital (converter).
ADC ADministration Centre.
ADC Analogue to Digital Converter.
ADCCP ADvanced Communications Control Protocol.
ADM ADMinistration processor.
ADMIN ADMINistration.
ADN Abbreviated Dialling Number.
ADPCM Adaptive Differential Pulse Code Modulation.
AE Application Entity.
AEC Accoustic Echo Control.
AEF Additional Elementary Functions.

Version 1 Revision 1 A
AET Active Events Table. Alarms and events are sent to the
Events Log in the GUI. Different operators will have different
subscription lists. All alarms and events are sent to the AET
before they are re-routed to different subscription lists.
AFC Automatic Frequency Control.
AFN Absolute Frame Number.
AGC Automatic Gain Control.
AGCH Access Grant CHannel. A GSM common control channel
used to assign MS to a SDCCH or a TCH.
Ai Action indicator.
AI Artificial Intelligence.
AIB Alarm Interface Board.
AIO A class of processor.
Air interface The radio link between the BTS and the MS.
AM Amplitude Modulation.
AMA Automatic Message Accounting (processor).
AM/MP Cell broadcast mobile terminated message. A message
broadcast to all MSs in a cell.
AoC Advice of Change.
AoCC Advice of Change Charging supplementary service.
AoCI Advice of Change Information supplementary service.
AOC Automatic Output Control.
AP Application Process.
ARFCN Absolute Radio Frequency Channel Number. An integer
which defines the absolute RF channel number.
ARQ Automatic ReQuest for retransmission.
ARP Address Resolution Protocol.
ASCE Association Control Service Element. An ASE which
provides an AP with the means to establish and control an
association with an AP in a remote NE. Maps directly onto
the Presentation layer (OMC).
ASE Application Service Element (OMC)
ASE Application Specific Entity (TCAP).
ASN.1 Abstract Syntax Notation One.
ASP Alarm and Status Panel.
ASR Answer Seizure Ratio.
ATB All Trunks Busy.
ATI Antenna Transceiver Interface.
ATT (flag) ATTach.
ATTS Automatic Trunk Testing Subsystem.
AU Access Unit.
AuC Authentication Centre. A GSM network entity which provides
the functionality for verifying the identity of an MS when
requested by the system. Often a part of the HLR.

A Version 1 Revision 1
AUT(H) AUThentication.
AUTO AUTOmatic mode.

Version 1 Revision 1 B
B Interface Interface between MSC and VLR.

BA BCCH Allocation. The radio frequency channels allocated in a
cell for BCCH transmission.
BAIC Barring of All Incoming Calls supplementary service.
BAOC Barring of All Outgoing Calls supplementary service.
BBBX Battery Backup Board.
BBH Base Band Hopping.
BCC BTS Colour Code.
BCCH Broadcast Control CHannel. A GSM control channel used to
broadcast general information about a BTS site on a per cell
or sector basis.
BCD Binary Coded Decimal.
BCF Base station Control Function. The GSM term for the digital
control circuitry which controls the BTS. In Motorola cell sites
this is a normally a BCU which includes DRI modules and is
located in the BTS cabinet.
BCIE Bearer Capability Information Element.
BCU Base station Control Unit. A functional entity of the BSS
which provides the base control function at a BTS site. The
term no longer applies to a type of shelf (see BSC and BSU).
BCUP Base Controller Unit Power.
BER Bit Error Rate. A measure of signal quality in the GSM
system.
BES Business Exchange Services.
BFI Bad Frame Indication.
BHCA Busy Hour Call Attempt.
BI all Barring of All Incoming call supplementary service.
BIB Balanced-line Interconnect Board. Provides interface to 12
balanced (6-pair) 120 ohm (37-pin D-type connector) lines for
2 Mbit/s circuits (See also T43).
BIC–Roam Barring of All Incoming Calls when Roaming outside the
Home PLMN Country supplementary service.
BIM Balanced-line Interconnect Module.
Bin An area in a data array used to store information.
BL BootLoad. Also known as download. For example, databases
and software can be downloaded to the NEs from the BSS.
BLLNG BiLLiNG.
bit/s Bits per second (bps).
Bm Full rate traffic channel.
BN Bit Number. Number which identifies the position of a
particular bit period within a timeslot.
BPF Bandpass Filter.
BPSM BCU Power Supply Module.

B Version 1 Revision 1
BS Basic Service (group).

BS Bearer Service. A type of telecommunication service that
provides the capability for the transmission of signals
between user-network interfaces. The PLMN connection type
used to support a bearer service may be identical to that used
to support other types of telecommunication service.
BSC Base Station Controller. A network component in the GSM
PLMN which has the digital control function of controlling all
BTSs. The BSC can be located within a single BTS cabinet
(forming a BSS) but is more often located remotely and
controls several BTSs (see BCF, BCU, and BSU).
BSG Basic Service Group.
BSIC Base Transceiver Station Identity Code. A block of code,
consisting of the GSM PLMN colour code and a base station
colour code. One Base Station can have several Base
Station Colour Codes.
BSIC-NCELL BSIC of an adjacent cell.
BSP Base Site control Processor (at BSC).
BSN Backward Sequence Number.
BSS Base Station System. The system of base station equipment
(Transceivers, controllers and so on) which is viewed by the
MSC through a single interface as defined by the GSM 08
series of recommendations, as being the entity responsible
for communicating with MSs in a certain area. The radio
equipment of a BSS may cover one or more cells. A BSS
may consist of one or more base stations. If an internal
interface is implemented according to the GSM 08.5x series
of recommendations, then the BSS consists of one BSC and
several BTSs.
BSSAP BSS Application Part (of Signalling System No. 7) (DTAP +
BSSMAP).
BSSC Base Station System Control cabinet. The cabinet which
houses one or two BSU shelves at a BSC or one or two RXU
shelves at a remote transcoder.
BSSMAP Base Station System Management Application Part (6-8).
BSSOMAP BSS Operation and Maintenance Application Part (of
Signalling System No. 7).
BSU Base Station Unit shelf. The shelf which houses the digital
control modules for the BTS (p/o BTS cabinet) or BSC (p/o
BSSC cabinet).
BT British Telecom.
BT Bus Terminator.
BTC Bus Terminator Card.
BTF Base Transceiver Function.
BTP Base Transceiver Processor (at BTS). One of the six basic
task groups within the GPROC.

Version 1 Revision 1 B
BTS Base Transceiver Station. A network component in the GSM

PLMN which serves one cell, and is controlled by a BSC.
The BTS contains one or more Transceivers (TRXs).
Burst A period of modulated carrier less than one timeslot. The
physical content of a timeslot.

C Version 1 Revision 1
C
C Conditional.
C Interface Interface between MSC and HLR/AUC.
C7 ITU-TSS Signalling System 7 (sometimes referred to as S7 or
SS#7).
CA Cell Allocation. The radio frequency channels allocated to a
particular cell.
CA Central Authority.
CAB Cabinet.
CADM Country ADMinistration. The Motorola procedure used within
DataGen to create new country and network files in the
DataGen database.
CAI Charge Advice Information.
CAT Cell Analysis Tool.
CB Cell Broadcast.
CB Circuit Breaker.
CBC Cell Broadcast Centre.
CBCH Cell Broadcast CHannel.
CBF Combining Bandpass Filter.
CBL Cell Broadcast Link.
CBM Circuit Breaker Module.
CBMI Cell Broadcast Message Identifier.
CBSMS Cell Broadcast Short Message Service.
CBUS Clock Bus.
CC Connection Confirm (Part of SCCP network connectivity).
CC Country Code.
CC Call Control.
CCB Cavity Combining Block, a three way RF combiner. There
are two types of CCB, CCB (Output) and CCB (Extension).
These, with up to two CCB Control cards, may comprise the
TATI. The second card may be used for redundancy.
CCBS Completion of Calls to Busy Subscriber supplementary
service.
CCCH Common Control CHannels. A class of GSM control
channels used to control paging and grant access. Includes
AGCH, PCH, and RACH.
CCCH_GROUP Group of MSs in idle mode.
CCD Common Channel Distributor.
CCDSP Channel Coding Digital Signal Processor.
CCF Conditional Call Forwarding.
CCH Control CHannel. Control channels are channels which carry
system management messages.
CCH Council for Communications Harmonization (referred to in
GSM Recommendations).

Version 1 Revision 1 C
CCIT Comité Consultatif International Télégraphique et

Téléphonique. This term has been superceded by ITU–TSS
(International Telecommunications Union –
Telecommunications Sector).
CCM Current Call Meter.
CCP Capability/Configuration Parameter.
CCPE Control Channel Protocol Entity.
CCS Hundred call-seconds. The unit in which amounts of
telephone traffic are measured. A single call lasting one
hundred seconds is one CCS. See also erlang.
Cct Circuit.
CDB Control Driver Board.
CDE Common Desktop Environment. Part of the SUN software
(crontab – cron job file).
CDR Call Detail Records.
CDUR Chargeable DURation.
CEB Control Equalizer Board (BTS).
CED Called station identifier.
CEIR Central Equipment Identity Register.
Cell By GSM definition, a cell is an RF coverage area. At an
omni-site, cell is synonymous with site; at a sectored site, cell
is synonymous with sector. This differs from analogue
systems where cell is taken to mean the same thing as site.
(See below).
1 Cell =
1 Sector
Omni Site 6-Sector Site

1-Cell Site or
(1 BTS) 6-Cell Site
(6 BTSs)
CEND End of charge point.

CEPT Conférence des administrations Européennes des Postes et
Telecommunications.
CERM Circuit Error Rate Monitor.
CF Conversion Facility.
CF all Call Forwarding services.
CFB Call Forwarding on mobile subscriber Busy supplementary
service.
CFC Conditional Call Forward.
CFNRc Call Forwarding on mobile subscriber Not Reachable
supplementary service.
CFNRy Call Forwarding on No Reply supplementary service.

C Version 1 Revision 1
CFU Call Forwarding Unconditional supplementary service.

Channel A means of one-way transmission. A defined sequence of
periods (for example, timeslots) in a TDMA system; a defined
frequency band in an FDMA system; a defined sequence of
periods and frequency bands in a frequency hopped system.
CIM Coaxial Interconnect Module.
CHP CHarging Point.
CHV Card Holder Verification information.
CKSN Ciphering Key Sequence Number.
CI Cell Identity. A block of code which identifies a cell within a
location area.
CI CUG Index.
CIC Circuit Identity Code.
CIR, C/I Carrier to Interference Ratio.
Ciphertext Unintelligible data produced through the use of encipherment.
CKSN Ciphering Key Sequence Number.
CLI Calling Line Identity.
CLIP Calling Line Identification Presentation supplementary
service.
CLIR Calling Line Identification Restriction supplementary service.
CLK Clock.
CLKX Clock Extender half size board. The fibre optic link that
distributes GCLK to boards in system (p/o BSS etc).
CLM Connectionless Manager.
CLR CLeaR.
CM Configuration Management. An OMC application.
CM Connection Management.
CMD CoMmanD.
CMM Channel Mode Modify.
CMIP Common Management Information Protocol.
CMISE Common Management Information Service Element. An ASE
which provides a means to transfer management information
via CMIP messages with another NE over an association
established by ASCE using ROSE (OMC).
CMR Cellular Manual Revision.
CNG CalliNg tone.
COLI COnnected Line Identity.
Collocated Placed together; two or more items together in the same
place.
Coincident Cell A cell which has a co-located neighbour whose cell boundary
follows the boundary of the said cell. The coincident cell has
a different frequency type, but the same BSIC, as that of the
neighbour cell.
COLP COnnected Line Identification Presentation supplementary
service.

Version 1 Revision 1 C
COLR COnnected Line Identification Restriction supplementary

service.
CODEX Manufacturer’s name for a type of multiplexer and packet
switch commonly installed at the Motorola OMC-R.
COM Code Object Manager.
COM COMplete.
COMB Combiner.
CONNACK CONNect ACKnowledgement.
COMM, Comms COMMunications.
CommsLink Communications Link. (2Mbit/s)
CONF CONFerence circuit.
CONFIG CONFIGuration Control Program.
CP Call Processing.
CPU Central Processing Unit.
C/R Command/Response field bit.
CR Carriage Return (RETURN).
CR Connection Request (Part of SCCP network connectivity).
CRC Cyclic Redundancy Check (3 bit).
CRE Call RE-establishment procedure.
CREF Connection REFused (Part of SCCP network connectivity).
CRM Cell Resource Manager.
CRM-LS/HS Cellular Radio Modem-Low Speed/High Speed. Low speed
modem used to interwork 300 to 2400 bit/s data services
under V.22bis, V.23, or V.21 standards. High speed modem
used to interwork 1200 to 9600 bit/s data services under
V.22bis, V.32, or V.29/V.27ter/V.21 standards.
CRT Cathode Ray Tube (video display terminal).
CSFP Code Storage Facility Processor (at BSC and BTS).
CSP Central Statistics Process. The statistics process in the BSC.
CSPDN Circuit Switched Public Data Network.
CT Call Transfer supplementary service.
CT Channel Tester.
CT Channel Type.
CTP Call Trace Product (Tool).
CTR Common Technical Regulation.
CTS Clear to Send. Method of flow control (RS232 Interface).
CTU Compact Transceiver Unit (M-Cellhorizon radio).
CUG Closed User Group supplementary service.
Cumulative value The total value for an entire statistical interval.
CW Call Waiting supplementary service.

D Version 1 Revision 1
D
D Interface Interface between VLR and HLR.
D/A Digital to Analogue (converter).
DAB Disribution Alarm Board.
DAC Digital to Analogue Converter.
DACS Digital Access Cross-connect System.
DAN Digital ANnouncer (for recorded announcements on MSC).
DAS Data Acquisition System.
DAT Digital Audio Tape.
DataGen Sysgen Builder System. A Motorola offline BSS binary object
configuration tool.
dB Decibel. A unit of power ratio measurement.
DB DataBase.
DB Dummy Burst (see Dummy burst).
DBA DataBase Administration/Database Administrator.
DBMS DataBase Management System.
dc Direct Current.
DCB Diversity Control Board (p/o DRCU).
DCCH Dedicated Control CHannel. A class of GSM control
channels used to set up calls and report measurements.
Includes SDCCH, FACCH, and SACCH.
DCD Data Carrier Detect signal.
DCE Data Circuit terminating Equipment.
DCF Data Communications Function.
DCF Duplexed Combining bandpass Filter. (Used in
Horizonmacro).
DCN Data Communications Network. A DCN connects Network
Elements with internal mediation functions or mediation
devices to the Operations Systems.
DC PSM DC Power Supply Module.
DCS1800 Digital Cellular System at 1800 MHz. A cellular phone
network using digital techniques similar to those used in GSM
900, but operating on frequencies of 1710 – 1785 MHz and
1805 – 1880 MHz.
DDF Dual-stage Duplexed combining Filter. (Used in
Horizonmacro).
DDS DataGen Directory Structure.
DDS Data Drive Storage.
DDS Direct Digital Synthesis.
DEQB Diversity Equalizer Board.
DET DETach.
DFE Decision Feedback Equalizer.
DGT Data Gathering Tool.

Version 1 Revision 1 D
DHP Digital Host Processor.

DIA Drum Intercept Announcer.
DINO E1/HDSL Line termination module.
DINO T1 Line termination module.
DISC DISConnect.
Discon Discontiuous.
DIQ Diversity In phase and Quadrature phase.
DIR Device Interface Routine.
DL Data Link (layer).
DLCI Data Link Connection Identifier.
DLD Data Link Discriminator.
DLNB Diversity Low Noise Block.
DLSP Data Link Service Process.
DLSP Digital Link Signalling Processor.
Dm Control channel (ISDN terminology applied to mobile service).
DMA Deferred Maintenance Alarm. An alarm report level; an
immediate or deferred response is required (see also PMA).
DMA Direct Memory Access.
DMR Digital Mobile Radio.
DMX Distributed Electronic Mobile Exchange (Motorola’s
networked EMX family).
DN Directory Number.
DNIC Data network identifier.
Downlink Physical link from the BTS towards the MS (BTS transmits,
MS receives).
DP Dial/Dialled Pulse.
DPC Destination Point Code. A part of the label in a signalling
message that uniquely identifies, in a signalling network, the
(signalling) destination point of the message.
DPC Digital Processing and Control board.
DPNSS Digital Private Network Signalling System (BT standard for
PABX interface).
DPP Dual Path Preselector.
DPR, DPRAM Dual Port Random Access Memory.
DPSM Digital Power Supply Module.
DRAM Dynamic Random Access Memory.
DRC Data Rate Converter board. Provides data and protocol
conversion between PLMN and destination network for 8
circuits (p/o IWF).
DRCU Diversity Radio Channel Unit. Contains transceiver, digital
control circuits, and power supply (p/o BSS) (see RCU).
(D)RCU Generic term for radio channel unit. May be standard RCU or
diversity radio channel unit DRCU.

D Version 1 Revision 1
DRI Digital Radio Interface. Provides encoding/decoding and

encryption/decryption for radio channel (p/o BSS).
DRIM Digital Radio Interface extended Memory. A DRI with extra
memory.
DRIX DRI Extender half size board. Fibre optic link from DRI to
BCU (p/o BSS).
DRX, DRx Discontinuous reception (mechanism). A means of saving
battery power (for example in hand-portable units) by
periodically and automatically switching the MS receiver on
and off.
DS-2 German term for 2 Mbit/s line (PCM interface).
DSE Data Switching Exchange.
DSI Digital Speech Interpolation.
DSP Digital Signal Processor.
DSS1 Digital Subscriber Signalling No 1.
DSSI Diversity Signal Strength Indication.
DTAP Direct Transfer Application Part (6-8).
DTE Data Terminal Equipment.
DTF Digital Trunk Frame.
DT1 DaTa form 1 (Part of SCCP network connectivity).
DTI Digital Trunk Interface.
DTMF Dual Tone Multi-Frequency (tone signalling type).
DTR Data Terminal Ready signal. Method of flow control (RS232
Interface).
DTRX Dual Transceiver Module. (Radio used in M-Cellarena and
M-Cellarena macro).
DTX, DTx Discontinuous Transmission (mechanism). A means of
saving battery power (for example in hand-portable units) and
reducing interference by automatically switching the
transmitter off when no speech or data are to be sent.
Dummy burst A period of carrier less than one timeslot whose modulation is
a defined sequence that carries no useful information. A
dummy burst fills a timeslot with an RF signal when no
information is to be delivered to a channel.
DYNET DYnamic NETwork. Used to specify BTSs sharing dynamic
resources.

Version 1 Revision 1 E
E
E See Erlang.
E Interface Interface between MSC and MSC.
EA External Alarms.
EAS External Alarm System.
Eb/No Energy per Bit/Noise floor.
EBCG Elementary Basic Service Group.
EC Echo Canceller. Performs echo suppression for all voice
circuits.
ECB Provides echo cancelling for telephone trunks for 30 channels
(EC).
ECID The Motorola European Cellular Infrastructure Division.
ECM Error Correction Mode (facsimile).
Ec/No Ratio of energy per modulating bit to the noise spectral
density.
ECT Event Counting Tool.
ECT Explicit Call Transfer supplementary service.
EEL Electric Echo Loss.
EEPROM Electrically Erasable Programmable Read Only Memory.
EGSM900 Extended GSM900.
EI Events Interface. Part of the OMC-R GUI.
EIR Equipment Identity Register.
EIRP Effective Isotropic Radiated Power.
EIRP Equipment Identity Register Procedure.
EL Echo Loss.
EM Event Management. An OMC application.
EMC ElectroMagnetic Compatibility.
EMF Electro Motive Force.
EMI Electro Magnetic Interference.
eMLPP enhanced Multi-Level Precedence and Pre-emption service.
EMMI Electrical Man Machine Interface.
EMU Exchange office Management Unit (p/o Horizonoffice)
EMX Electronic Mobile Exchange (Motorola’s MSC family).
en bloc Fr. — all at once (a CCITT #7 Digital Transmission scheme);
En bloc sending means that digits are sent from one system
to another ~ (that is, all the digits for a given call are sent at
the same time as a group). ~ sending is the opposite of
overlap sending. A system using ~ sending will wait until it
has collected all the digits for a given call before it attempts to
send digits to the next system. All the digits are then sent as
a group.
EOT End of Tape.
EPROM Erasable Programmable Read Only Memory.

E Version 1 Revision 1
EPSM Enhanced Power Supply Module (+27 V).

EQB Equalizer Board. Control circuit for equalization for 8 time
slots each with equalizing circuitry and a DSP (p/o RCU).
EQCP Equalizer Control Processor.
EQ DSP Equalizer Digitizer Signal Processor.
Erlang International (dimensionless) unit of traffic intensity defined as
the ratio of time a facility is occupied to the time it is available
for occupancy. One erlang is equal to 36 CCS. In the US
this is also known as a traffic unit (TU).
ERP Ear Reference Point.
ERP Effective Radiated Power.
ERR ERRor.
ESP Electro-static Point.
ESQL Embedded SQL (Structured Query Language). An RDBMS
programming interface language.
E-TACS Extended TACS (analogue cellular system, extended).
Ethernet Type of Local Area Network.
ETR ETSI Technical Report.
ETS European Telecommunication Standard.
ETSI European Telecommunications Standards Institute.
ETX End of Transmission.
EXEC Executive Process.

Version 1 Revision 1 F
F Interface Interface between MSC and EIR.

FA Fax Adaptor.
FA Full Allocation.
FA Functional Area.
FAC Final Assembly Code.
FACCH Fast Associated Control Channel. A GSM dedicated control
channel which is associated with a TCH and carries control
information after a call is set up (see SDCCH).
FACCH/F Fast Associated Control Channel/Full rate.
FACCH/H Fast Associated Control Channel/Half rate.
FB Frequency correction Burst (see Frequency correction burst).
FC-AL Fibre Channel Arbitration Loop. (Type of hard disc).
FCCH Frequency Correction CHannel. A GSM broadcast control
channel which carries information for frequency correction of
the mobile (MS).
FCP Fault Collection Process (in BTS).
FCS Frame Check Sequence.
FDM Frequency Division Multiplex.
FDMA Frequency Division Multiple Access.
FDN Fixed Dialling Number.
FDP Fault Diagnostic Procedure.
FEC Forward Error Correction.
FEP Front End Processor.
FER Frame Erasure Ratio.
FFS, FS For Further Study.
FH Frequency Hopping.
FIB Forward Indicator Bit.
FIR Finite Impulse Response (filter type).
FK Foreign Key. A database column attribute; the foreign key
indicates an index into another table.
FM Fault Management (at OMC).
FM Frequency Modulation.
FMIC Fault Management Initiated Clear.
FMUX Fibre optic MUltipleXer.
FN Frame Number. Identifies the position of a particular TDMA
frame within a hyperframe.
FOA First Office Application.
FOX Fibre Optic eXtender.
FR Full Rate. Refers to the current capacity of a data channel on
the GSM air interface, that is, 8 simultaneous calls per carrier
(see also HR – Half Rate).

F Version 1 Revision 1
FRU Field Replaceable Unit.

Frequency correction Period of RF carrier less than one timeslot whose modulation
bit stream allows frequency correction to be performed easily
within an MS burst.
FS Frequency Synchronization.
FSL Free Space Loss. The decrease in the strength of a radio
signal as it travels between a transmitter and receiver. The
FSL is a function of the frequency of the radio signal and the
distance the radio signal has travelled from the point source.
FSN Forward Sequence Number.
FTAM File Transfer, Access, and Management. An ASE which
provides a means to transfer information from file to file
(OMC).
ftn forwarded-to number.
FTP Fault Translation Process (in BTS).
FTP File Transfer Protocol.

Version 1 Revision 1 G
G
G Interface Interface between VLR and VLR.
Gateway MSC An MSC that provides an entry point into the GSM PLMN
from another network or service. A gateway MSC is also an
interrogating node for incoming PLMN calls.
GB, Gbyte Gigabyte.
GBIC Gigabit Interface Converter.
GCLK Generic Clock board. System clock source, one per site (p/o
BSS, BTS, BSC, IWF, RXCDR).
GCR Group Call Register.
GDP Generic DSP Processor board. Interchangeable with the XCDR
board.
GDP E1 GDP board configured for E1 link usage.
GDP T1 GDP board configured for T1 link usage.
GHz Giga-Hertz (109).
GID Group ID. A unique number used by the system to identify a
user’s primary group.
GMB GSM Multiplexer Board (p/o BSC).
GMR GSM Manual Revision.
GMSC Gateway Mobile-services Switching Centre (see Gateway
MSC).
GMSK Gaussian Minimum Shift Keying. The modulation technique
used in GSM.
GND GrouND.
GOS Grade of Service.
GPA GSM PLMN Area.
GPC General Protocol Converter.
GPROC Generic Processor board. GSM generic processor board: a
68030 with 4 to 16 Mb RAM (p/o BSS, BTS, BSC, IWF,
RXCDR).
GPROC2 Generic Processor board. GSM generic processor board: a
68040 with 32 Mb RAM (p/o BSS, BTS, BSC, IWF, RXCDR).
GPRS General Packet Radio Service.
GPS Global Positioning by Satellite.
GSA GSM Service Area. The area in which an MS can be reached
by a fixed subscriber, without the subscriber’s knowledge of
the location of the MS. A GSA may include the areas served
by several GSM PLMNs.
GSA GSM System Area. The group of GSM PLMN areas
accessible by GSM MSs.
GSM Groupe Spécial Mobile (the committee).
GSM Global System for Mobile communications (the system).
GSM MS GSM Mobile Station.
GSM PLMN GSM Public Land Mobile Network.

G Version 1 Revision 1
GSR GSM Software Release.

GT Global Title.
GTE Generic Table Editor. The Motorola procedure which allows
users to display and edit MCDF input files.
Guard period Period at the beginning and end of timeslot during which MS
transmission is attenuated.
GUI Graphical User Interface.
GUI client A computer used to display a GUI from an OMC-R GUI
application which is beingbrun on a GUI server.
GUI server A computer used to serve the OMC-R GUI application
process running locally (on its processor) to other computers
(Gui clients or other MMI processors).
GWY GateWaY (MSC/LR) interface to PSTN.

Version 1 Revision 1 H
H
H Interface Interface between HLR and AUC.
H-M Human-Machine Terminals.
HAD, HAP HLR Authentication Distributor.
HANDO, Handover HANDOver. The action of switching a call in progress from
one radio channel to another radio channel. Handover allows
established calls to continue by switching them to another
radio resource, as when an MS moves from one BTS area to
another. Handovers may take place between the following
GSM entities: timeslot, RF carrier, cell, BTS, BSS and MSC.
HCU Hybrid Combining Unit. (Used in Horizonmacro).
HDLC High level Data Link Control.
HDSL High bit-rate Digital Subscriber Line.
HLC High Layer Compatibility. The HLC can carry information
defining the higher layer characteristics of a teleservice active
on the terminal.
HLR Home Location Register. The LR where the current location
and all subscriber parameters of an MS are permanently
stored.
HMS Heat Management System. The system that provides
environmental control of the components inside the ExCell,
TopCell and M-Cell cabinets.
HO HandOver. (see HANDO above).
HPU Hand Portable Unit.
HOLD Call hold supplementary service.
HPLMN Home PLMN.
HR Half Rate. Refers to a type of data channel that will double
the current GSM air interface capacity to 16 simultaneous
calls per carrier (see also FR – Full Rate).
HS HandSet.
HSI/S High Speed Interface card.
HSM HLR Subscriber Management.
HSN Hopping Sequence Number.
HU Home Units.
HW Hardware.
Hyperframe 2048 superframes. The longest recurrent time period of the
frame structure.

I Version 1 Revision 1
I Information frames (RLP).

IA Incomming Access (closed user group (CUG) SS
(supplementary service)).
IA5 International Alphanumeric 5.
IADU Integrated Antenna Distribution Unit. (The IADU is the
equivalent of the Receive Matrix used on pre-M-Cell BTSs).
IAM Initial Address Message.
IAS Internal Alarm System.
IC Integrated Circuit.
IC Interlock Code (CUG SS).
IC(pref) Interlock Code op the preferential CUG.
ICB Incoming Calls Barred.
ICC Integrated Circuit(s) Card.
ICM In-Call Modification.
ICMP Internet Control Message Protocol.
ID, Id IDentification/IDentity/IDentifier.
IDN Integrated Digital Network.
IDS INFOMIX Database Server. (OMC-R relational database
management system).
IE Information Element (signalling).
IEC International Electrotechnical Commission.
IEEE Institute of Electrical and Electronic Engineers.
IEI Information Element Identifier.
I-ETS Interim European Telecommunication Standard.
IF Intermediate Frequency.
IFAM Initial and Final Address Message.
IM InterModulation.
IMACS Intelligent Monitor And Control System.
IMEI International Mobile station Equipment Identity. Electronic
serial number that uniquely identifies the MS as a piece or
assembly of equipment. The IMEI is sent by the MS along
with request for service.
IMM IMMediate assignment message.
IMSI International Mobile Subscriber Identity. Published mobile
number (prior to ISDN) (see also MSISDN) that uniquely
identifies the subscription. It can serve as a key to derive
subscriber information such as directory number(s) from the
HLR.
IN Intelligent Network.
IN Interrogating Node. A switching node that interrogates an
HLR, to route a call for an MS to the visited MSC.
INS IN Service.

Version 1 Revision 1 I
INS Intelligent Network Service.

InterAlg Interference Algorithm. A single interference algorithm in a
cell.
Interworking The general term used to describe the inter-operation of
networks, services, supplementary services and so on. See
also IWF.
Interval A recording period of time in which a statistic is pegged.
Interval expiry The end of an interval.
I/O Input/Output.
IOS Intelligent Optimization Platform.
IP Initialisation Process.
IP Internet Protocol.
IPC Inter-Process Communication.
IP, INP INtermodulation Products.
IPR Intellectual PRoperty.
IPSM Integrated Power Supply Module (–48 V).
IPX (A hardware component).
ISAM Indexed Sequential Access Method.
ISC International Switching Centre.
ISDN Integrated Services Digital Network. An integrated services
network that provides digital connections between
user-network interfaces.
ISG Motorola Information Systems group (formally CODEX).
ISO International Organisation for Standardization.
ISQL Informix Structured Query Language.
ISUP ISDN User Part (of signalling system No. 7).
IT Inactivity Test (Part of SCCP network connectivity).
ITC Information Transfer Capability.
ITU International Telecommunication Union.
ITU–TSS International Telecommunication Union – Telecommunications
Sector.
IWF InterWorking Function. A network functional entity which
provides network interworking, service interworking,
supplementary service interworking or signalling interworking.
It may be a part of one or more logical or physical entities in a
GSM PLMN.
IWMSC InterWorking MSC.
IWU InterWorking Unit.

K Version 1 Revision 1
K
k kilo (103).
k Windows size.
K Constraint length of the convolutional code.
KAIO Kernal Asynchronous Input/Output.
kb, kbit kilo-bit.
kbit/s, kbps kilo-bits per second.
kbyte kilobyte.
Kc Ciphering key. A sequence of symbols that controls the
operation of encipherment and decipherment.
kHz kilo-Hertz (103).
Ki Individual subscriber authentication Key (p/o authentication
process of AUC).
KIO A class of processor.
KSW Kiloport SWitch board. TDM timeslot interchanger to connect
calls (p/o BSS).
KSWX KSW Expander half size board. Fibre optic distribution of
TDM bus (p/o BSS).
kW kilo-Watt.

Version 1 Revision 1 L
L
L1 Layer 1.
L2ML Layer 2 Management Link.
L2R Layer 2 Relay function. A function of an MS and IWF that
adapts a user’s known layer2 protocol LAPB onto RLP for
transmission between the MT and IWF.
L2R BOP L2R Bit Orientated Protocol.
L2R COP L2R Character Orientated Protocol.
L3 Layer 3.
LA Location Area. An area in which an MS may move freely
without updating the location register. An LA may comprise
one or several base station areas.
LAC Location Area Code.
LAI Location Area Identity. The information indicating the location
area in which a cell is located.
LAN Local Area Network.
LANX LAN Extender half size board. Fibre optic distribution of LAN
to/from other cabinets (p/o BSS etc).
LAPB Link Access Protocol Balanced (of ITU–TSS Rec. x.25).
LAPD Link Access Protocol Data.
LAPDm Link Access Protocol on the Dm channel.
LC Inductor Capacitor (type of filter).
LCF Link Control Function.
LCN Local Communications Network.
LCP Link Control Processor.
LE Local Exchange.
LED Light Emitting Diode.
LF Line Feed.
LI Length Indicator.
LI Line Identity.
LLC Lower Layer Compatibility. The LLC can carry information
defining the lower layer characteristics of the terminal.
Lm Traffic channel with capacity lower than a Bm.
LMP LAN Monitor Process.
LMS Least Mean Square.
LMSI Local Mobile Station Identity. A unique identity temporarily
allocated to visiting mobile subscribers in order to speed up
the search for subscriber data in the VLR, when the MSRN
allocation is done on a per cell basis.
LMT Local Maintenance Terminal.
LNA Low Noise Amplifier.
LND Last Number Dialled.

L Version 1 Revision 1
Location area An area in which a mobile station may move freely without
updating the location register. A location area may comprise
one or several base station areas.
LPC Linear Predictive Code.
LPLMN Local PLMN.
LR Location Register. The GSM functional unit where MS
location information is stored. The HLR and VLR are location
registers.
LSSU Link Stations Signalling Unit (Part of MTP transport system).
LSTR Listener Side Tone Rating.
LTA Long Term Average. The value required in a BTS’s GCLK
frequency register to produce a 16.384 MHz clock.
LTE Local Terminal Emulator.
LTP Long Term Predictive.
LTU Line Terminating Unit.
LU Local Units.
LU Location Update.
LV Length and Value.

Version 1 Revision 1 M
M
M Mandatory.
M Mega (106).
M-Cell Motorola Cell.
M&TS Maintenance and Troubleshooting. Functional area of
Network Management software which (1) collects and
displays alarms, (2) collects and displays Software/Hardware
errors, and (3) activates test diagnostics at the NEs (OMC).
MA Mobile Allocation. The radio frequency channels allocated to
an MS for use in its frequency hopping sequence.
MAC Medium Access Control.
MACN Mobile Allocation Channel Number.
Macrocell A cell in which the base station antenna is generally mounted
away from buildings or above rooftop level.
MAF Mobile Additional Function.
MAH Mobile Access Hunting supplementary service.
MAI Mobile Allocation Index.
MAIDT Mean Accumulated Intrinsic Down Time.
MAINT MAINTenance.
MAIO Mobile Allocation Index Offset.
MAP Mobile Application Part (of signalling system No. 7). The
inter-networking signalling between MSCs and LRs and EIRs.
MAPP Mobile Application Part Processor.
MB, Mbyte Megabyte.
Mbit/s Megabits per second.
MCAP Motorola Cellular Advanced Processor.
MCC Mobile Country Code.
MCDF Motorola Customer Data Format used by DataGen for simple
data entry and retrieval.
MCI Malicious Call Identification supplementary service.
MCSC Motorola Customer Support Centre.
MCU Main Control Unit for M-Cell2/6. Also referred to as the Micro
Control Unit in software.
MCUF Main Control Unit, with dual FMUX. (Used in M-Cellhorizon).
MCU-m Main Control Unit for M-Cell Micro sites (M-Cellm). Also
referred to as the Micro Control Unit in software.
MCUm The software subtype representation of the Field Replaceable
Unit (FRU) for the MCU-m.
MD Mediation Device.
MDL (mobile) Management (entity) - Data Link (layer).
ME Maintenance Entity (GSM Rec. 12.00).

M Version 1 Revision 1
ME Mobile Equipment. Equipment intended to access a set of

GSM PLMN and/or DCS telecommunication services, but
which does not contain subscriber related information.
Services may be accessed while the equipment, capable of
surface movement within the GSM system area, is in motion
or during halts at unspecified points.
MEF Maintenance Entity Function (GSM Rec. 12.00).
MF MultiFrame.
MF Multi-Frequency (tone signalling type).
MF MultiFunction block.
MGMT, mgmt Management.
MGR Manager.
MHS Message Handling System.
MHS Mobile Handling Service.
MHz Mega-Hertz (106).
MI Maintenance Information.
MIB Management Information Base. A Motorola OMC-R
database. There is a CM MIB and an EM MIB.
MIC Mobile Interface Controller.
Microcell A cell in which the base station antenna is generally mounted
below rooftop level. Radio wave propagation is by diffraction
and scattering around buildings, the main propagation is
within street canyons.
min minute(s).
s micro-second (10–6).
BCU Micro Base Control Unit.
MIT Management Information Tree. Name of a file on the
Motorola OMC-R.
MM Man Machine.
MM Mobility Management.
MME Mobile Management Entity.
MMF Middle Man Funnel process.
MMI Man Machine Interface. The method in which the user
interfaces with the software to request a function or change
parameters.
MMI client A machine configured to use the OMC-R software from an
MMI server.
MMI processor MMI client/MMI server.
MMI server A computer which has its own local copy of the OMC-R
software. It can run the OMC-R software for MMI clients to
mount.
MML Man Machine Language. The tool of MMI.
MMS Multiple Serial Interface Link. (see also 2Mbit/s link)
MNC Mobile Network Code.
MNT MaiNTenance.

Version 1 Revision 1 M
MO Mobile Originated.
MO/PP Mobile Originated Point-to-Point messages.
MOMAP Motorola OMAP.
MoU Memorandum of Understanding.
MPC Multi Personal Computer (was p/o OMC).
MPH (mobile) Management (entity) - PHysical (layer) [primitive].
MPTY MultiParTY (Multi ParTY) supplementary service.
MPX MultiPleXed.
MRC Micro Radio Control Unit.
MRN Mobile Roaming Number.
MRP Mouth Reference Point.
MS Mobile Station. The GSM subscriber unit.
MSC Mobile-services Switching Centre, Mobile Switching Centre.
MSCM Mobile Station Class Mark.
MSCU Mobile Station Control Unit.
msec millisecond (.001 second).
MSI Multiple Serial Interface board. Intelligent interface to two
2 Mbit/s digital links (see 2 Mbit/s link and DS-2) (p/o BSS).
MSIN Mobile Station Identification Number.
MSISDN Mobile Station International ISDN Number. Published mobile
number (see also IMSI). Uniquely defines the mobile station
as an ISDN terminal. It consists of three parts: the Country
Code (CC), the National Destination Code (NDC) and the
Subscriber Number (SN).
MSRN Mobile Station Roaming Number. A number assigned by the
MSC to service and track a visiting subscriber.
MSU Message Signal Unit (Part of MTP transport system). A
signal unit containing a service information octet and a
signalling information field which is retransmitted by the
signalling link control, if it is received in error.
MT Mobile Terminated. Describes a call or short message
destined for an MS.
MT (0, 1, 2) Mobile Termination. The part of the MS which terminates the
radio transmission to and from the network and adapts
terminal equipment (TE) capabilities to those of the radio
transmission. MT0 is mobile termination with no support for
terminal, MT1 is mobile termination with support for an S-type
interface and MT2 is mobile termination with support for an
R-type interface.
MTM Mobile-To-Mobile (call).
MTP Message Transfer Part.
MT/PP Mobile Terminated Point-to-Point messages.
MTBF Mean Time Between Failures.
MTK Message Transfer LinK.
MTL MTP Transport Layer Link (A interface).

M Version 1 Revision 1
MTP Message Transfer Part.

MTTR Mean Time To Repair.
Multiframe Two types of multiframe are defined in the system: a
26-frame multiframe with a period of 120 ms and a 51-frame
multiframe with a period of 3060/13 ms.
MU Mark Up.
MUMS Multi User Mobile Station.
MUX Multiplexer.

Version 1 Revision 1 N
N
N/W Network.
NB Normal Burst (see Normal burst).
NBIN A parameter in the hoping sequence.
NCC Network (PLMN) Colour Code.
NCELL Neighbouring (of current serving) Cell.
NCH Notification CHannel.
ND No Duplicates. A database column attribute meaning the
column contains unique values (used only with indexed
columns).
NDC National Destination Code.
NDUB Network Determined User Busy.
NE Network Element (Network Entity).
NEF Network Element Function block.
NET Norme Européennes de Telecommunications.
NETPlan Frequency planning tool.
NF Network Function.
NFS Network File System.
NHA Network Health Analyst. Optional OMC-R processor feature.
NIC Network Interface Card.
NIC Network Independent Clocking.
NIS Network Information Service. It allows centralised control of
network information for example hostnames, IP addresses
and passwords.
NIU Network Interface Unit.
NIU-m Network Interface Unit, micro.
NLK Network LinK processor(s).
Nm Newton metres.
NM Network Management (manager). NM is all activities which
control, monitor and record the use and the performance of
resources of a telecommunications network in order to
provide telecommunication services to customers/users at a
certain level of quality.
NMASE Network Management Application Service Element.
NMC Network Management Centre. The NMC node of the GSM
TMN provides global and centralised GSM PLMN monitoring
and control, by being at the top of the TMN hierarchy and
linked to subordinate OMC nodes.
NMSI National Mobile Station Identification number.
NMT Nordic Mobile Telephone system.
NN No Nulls. A database column attribute meaning the column
must contain a value in all rows.
Normal burst A period of modulated carrier less than a timeslot.
NPI Number Plan Identifier.

N Version 1 Revision 1
NRZ Non Return to Zero.

NSAP Network Service Access Point.
NSP Network Service Provider.
NSS Network Status Summary.
NT Network Termination.
NT Non Transparent.
NTAAB New Type Approval Advisory Board.
NUA Network User Access.
NUI Network User Identification.
NUP National User Part (of signalling system No. 7).
NV NonVolatile.
NVRAM Non-Volatile Random Access Memory.
nW Nano-Watt (10–9).

Version 1 Revision 1 O
O
O Optional.
OA Outgoing Access (CUG SS).
O&M Operations and Maintenance.
OASCU Off-Air-Call-Set-Up. The procedure in which a
telecommunication connection is being established whilst the
RF link between the MS and the BTS is not occupied.
OCB Outgoing Calls Barred within the CUG.
OCXO Oversized Voltage Controlled Crystal Oscillator.
OD Optional for operators to implement for their aim.
OFL % OverFlow.
offline IDS shutdown state.
online IDS normal operatng state.
OIC Operator Initiated Clear.
OLM Off_Line MIB. A Motorola DataGen database, used to modify
and carry out Radio Frequency planning on multiple BSS
binary files.
OLR Overall Loudness Rating.
OMAP Operations and Maintenance Application Part (of signalling
system No. 7) (was OAMP).
OMC Operations and Maintenance Centre. The OMC node of the
GSM TMN provides dynamic O&M monitoring and control of
the PLMN nodes operating in the geographical area
controlled by the specific OMC.
OMC-G Operations and Maintenance Centre — Gateway Part.
(Iridium)
OMC-G Operations and Maintenance Centre — GPRS Part.
OMC-R Operations and Maintenance Centre — Radio Part.
OMC-S Operations and Maintenance Centre — Switch Part.
OMF Operations and Maintenance Function (at BSC).
OML Operations and Maintenance Link.
OMP Operation and Maintenance Processor.
OMS Operation and Maintenance System (BSC–OMC).
OMSS Operation and Maintenance SubSystem.
OOS Out Of Service.
OPC Originating Point Code. A part of the label in a signalling
message that uniquely identifies, in a signalling network, the
(signalling) origination point of the message.
ORAC Olympus Radio Architecture Chipset.
OS Operating System.
OSI Open Systems Interconnection.
OSI RM OSI Reference Model.
OSF Operation Systems Function block.

O Version 1 Revision 1
OSF/MOTIF Open Software Foundation Motif. The basis of the GUI used
for the Motorola OMC-R MMI.
OSS Operator Services System.
Overlap Overlap sending means that digits are sent from one system
to another as soon as they are received by the sending
system. A system using ~ will not wait until it has received all
digits of a call before it starts to send the digits to the next
system. This is the opposite of en bloc sending where all
digits for a given call are sent at one time.

Version 1 Revision 1 P
P
PA Power Amplifier.
PAB Power Alarm Board.
PABX Private Automatic Branch eXchange.
PAD Packet Assembler/Disassembler facility.
Paging The procedure by which a GSM PLMN fixed infrastructure
attempts to reach an MS within its location area, before any
other network-initiated procedure can take place.
PATH CEPT 2 Mbit/s route through the BSS network.
PBUS Processor Bus.
PBX Private Branch eXchange.
PC Personal Computer.
PCH Paging CHannel. A GSM common control channel used to
send paging messages to the MSs.
PCHN Paging Channel Network.
PCHN Physical Channel.
PCM Pulse Code Modulation (see also 2 Mbit/s link which is the
physical bearer of PCM).
PCN Personal Communications Network.
PCR Preventative Cyclic Retransmission. A form of error
correction suitable for use on links with long transmission
delays, such as satellite links.
PCU Packet Control Unit (p/o GPRS).
PCU Picocell Control unit (p/o M-Cellaccess).
pd Potential difference.
PD Protocol Discriminator.
PD Public Data.
PDB Power Distribution Board.
PDF Power Distribution Frame (MSC/LR).
PDN Public Data Networks.
PDU Power Distribution Unit.
PDU Protected Data Unit.
PEDC Pan European Digital Cellular.
Peg A single incremental action modifying the value of a statistic.
Pegging Modifying a statistical value.
PH Packet Handler.
PH PHysical (layer).
PHI Packet Handler Interface.
PI Presentation Indicator.
Picocell A cell site where the base station antenna is mounted within a
building.
PICS Protocol Implementation Conformance Statement.

P Version 1 Revision 1
PID Process IDentifier/Process ID.

PIM PCM Interface Module (MSC).
PIN Personal Identification Number.
PIN Problem Identification Number.
PIX Parallel Interface Extender half size board. Customer alarm
interface (p/o BSS).
PIXT Protocol Implementation eXtra information for Testing.
PK Primary Key. A database column attribute, the primary key is
a not-null, non-duplicate index.
Plaintext Unciphered data.
PlaNET Frequency planning tool.
PLL Phase Lock Loop (refers to phase locking the GCLK in the
BTS).
PLMN Public Land Mobile Network. The mobile communications
network.
PM Performance Management. An OMC application.
PM-UI Performance Management User Interface.
PMA Prompt Maintenance Alarm. An alarm report level; immediate
action is necessary (see also DMA).
PMS Pseudo MMS.
PMUX PCM MUltipleXer.
PN Permanent Nucleus (of GSM).
PNE Présentation des Normes Européennes.
POI Point of Interconnection (with PSTN).
POTS Plain Old Telephone Service (basic telephone services).
p/o Part of.
pp, p-p Peak-to-peak.
PP Point-to-Point.
ppb Parts per billion.
PPE Primative Procedure Entity.
ppm Parts per million (x 10–6).
Pref CUG Preferential CUG.
Primary Cell A cell which is already optimized in the network and has a
co-located neighbour whose cell boundary follows the
boundary of the said cell. The primary cell has a preferred
band equal to the frequency type of the coincident cell.
PROM Programmable Read Only Memory.
Ps Location probability.
PSA Periodic Supervision of Accessability.
PSAP Presentation Services Access Point.
PSM Power Supply Module.

Version 1 Revision 1 P
PSPDN Packet Switched Public Data Network. Public data

communications network. x.25 links required for NE to OMC
communications will probably be carried by PSPDN.
PSTN Public Switched Telephone Network. The UK land line
telephone network.
PSU Power Supply Unit.
PSW Pure Sine Wave.
PTO Public Telecommunications Operator.
PUCT Price per Unit Currency Table.
PVC Permanent Virtual Circuit.
PW Pass Word.
PWR Power.
PXPDN Private eXchange Public Data Network.

Q Version 1 Revision 1
Q
QA Q (Interface) – Adapter.
Q3 Interface between NMC and GSM network.
Q-adapter Used to connect MEs and SEs to TMN (GSM Rec. 12.00).
QAF Q-Adapter Function.
QEI Quad European Interface. Interfaces four 2 Mbit/s circuits to
TDM switch highway (see MSI).
QIC Quarter Inch Cartridge (Data storage format).
QOS Quality Of Service.
Quiescent mode IDS intermediate state before shutdown.

Version 1 Revision 1 R
R
R Value of reduction of the MS transmitted RF power relative to
the maximum allowed output power of the highest power
class of MS (A).
RA RAndom mode request information field.
RAB Random Access Burst.
RACCH Random Access Control CHannel. A GSM common control
channel used to originate a call or respond to a page.
RACH Random Access CHannel.
RAM Random Access Memory.
RAND RANDom number (used for authentication).
RATI Receive Antenna Transceiver Interface.
RAx Rate Adaptation.
RBDS Remote BSS Diagnostic System (a discontinued Motorola
diagnostic facility).
RBER Residual Bit Error Ratio.
RBTS Remote Base Transceiver Station.
RCB Radio Control Board (p/o DRCU).
RCI Radio Channel Identifier.
RCP Radio Control Processor.
RCU Radio Channel Unit. Contains transceiver, digital control
circuits, and power supply (p/o BSS) (see DRCU).
RCVR Receiver.
RDBMS Relational DataBase Management System (INFORMIX).
RDI Radio Digital Interface System.
RDIS Restricted Digital Information.
RDM Reference Distribution Module.
RDN Relative Distinguished Name. A series of RDN form a unique
identifier, the distinguished name, for a particular network
element.
REC, Rec RECommendation.
REJ REJect(ion).
REL RELease.
RELP Residual Excited Linear Predictive.
RELP-LTP RELP Long Term Prediction. A name for GSM full rate (see
full rate).
resync Resynchronize/resynchronization.
REQ REQuest.
Revgen A Motorola DataGen utility for producing an MMI script from a
binary object database.
RF Radio Frequency.

R Version 1 Revision 1
RFC, RFCH Radio Frequency Channel. A partition of the system RF

spectrum allocation with a defined bandwidth and centre
frequency.
RFE Receiver Front End (shelf).
RFEB Receiver Front End Board (p/o DRCU II).
RFI Radio Frequency Interference.
RFM Radio Frequency Module.
RFN Reduced TDMA Frame Number.
RFU Reserved for Future Use.
RJ45 Network cable/Connector type.
RISC Reduced Instruction Set Computer.
RL Remote login.
RLC Release Complete.
RLP Radio Link Protocol. An ARQ protocol used to transfer user
data between an MT and IWF. See GSM 04.22.
RLR Receiver Loudness Rating.
RLSD ReLeaSeD.
RMS Root Mean Square (value).
RMSU Remote Mobile Switching Unit.
RNTABLE Table of 128 integers in the hopping sequence.
ROM Read Only Memory.
ROSE Remote Operations Service Element. An ASE which carries
a message between devices over an association established
by ASCE (a CCITT specification for O & M) (OMC).
Roundtrip Time period between transmit and receive instant of a
timeslot in the BTS, propagation determined by the response
behaviour of the MS and the MS to BTS delay distance.
RPE Regular Pulse Excited.
RPE-LTP Regular Pulse Excitation - Long Term Prediction. The GSM
digital speech coding scheme.
RPOA Recognised Private Operating Agency.
RPR Read Privilege Required. Access to the column is allowed
only for privileged accounts.
RR Radio Resource management.
RR Receive Ready (frame).
RRSM Radio Resource State Machine.
RS232 Standard serial interface.
RSE Radio System Entity.
RSL Radio Signalling Link.
RSLF Radio System Link Function.
RSLP Radio System Link Processor.
RSS Radio SubSystem (replaced by BSS).
RSSI Received Signal Strength Indicator.

Version 1 Revision 1 R
RSZI Regional Subscription Zone Identity.

RTC Remotely Tuneable Channel Combiner.
RTE Remote Terminal Emulator.
RTF Radio Transceiver Function.
RTF Receive Transmit Functions.
RTS Request to Send. Method of flow control (RS232 Interface).
RU Rack Unit.
Run level System processor operating mode.
Rx Receive(r).
RXCDR Remote Transcoder.
RXF Receive Function (of the RTF).
RXLEV-D Received signal level downlink.
RXLEV-U Received signal level uplink.
RXQUAL-D Received signal quality downlink.
RXQUAL-U Received signal quality uplink.
RXU Remote Transcoder Unit. The shelf which houses the
remote transcoder modules in a BSSC cabinet at a remote
transcoder site.

S Version 1 Revision 1
S
S/W SoftWare.
SABM Set Asynchronous Balanced Mode. A message which
establishes the signalling link over the air interface.
SABME SABM Extended.
SACCH Slow Associated Control CHannel. A GSM control channel
used by the MS for reporting RSSI and signal quality
measurements.
SACCH/C4 Slow Associated Control CHannel/SDCCH/4.
SACCH/C8 Slow Associated Control CHannel/SDCCH/8.
SACCH/T Slow Associated Control CHannel/Traffic channel.
SACCH/TF Slow Associated Control CHannel/Traffic channel Full rate.
SACCH/TH Slow Associated Control CHannel/Traffic channel Half rate.
SAGE A brand of trunk test equipment.
SAP Service Access Point. In the reference model for OSI, SAPs
of a layer are defined as gates through which services are
offered to an adjacent higher layer.
SAP System Audits Process.
SAPI Service Access Point Indicator (identifier).
SAW Surface Acoustic Wave.
SB Synchronization Burst (see Synchronization burst).
SBUS Serial Bus.
SC Service Centre (used for Short Message Service).
SC Service Code.
SCCA System Change Control Administration. Software module
which allows full or partial software download to the NE
(OMC).
SCCP Signalling Connection Control Part (6-8).
SCEG Speech Coding Experts Group (of GSM).
SCH Synchronization CHannel. A GSM broadcast control channel
used to carry information for frame synchronization of MSs
and identification of base stations.
SCI Status Control Interface.
SCIP Serial Communication Interface Processor.
SCM Status Control Manager.
SCN Sub-Channel Number. One of the parameters defining a
particular physical channel in a BS.
SCP Service Control Point (an intelligent network entity).
SCSI Small Computer Systems Interface.
SCU Slim Channel Unit.
SCU900 Slim Channel Unit for GSM900.
SDCCH Stand-alone Dedicated Control CHannel. A GSM control
channel where the majority of call setup occurs. Used for
MS to BTS communications before MS assigned to TCH.

Version 1 Revision 1 S
SDL Specification Description Language.

SDT SDL Developement Tool.
SDU Service Data Unit.
SDR Special Drawing Rights (an international “basket” currency for
billing).
SE Support Entity (GSM Rec. 12.00).
Secondary Cell A cell which is not optimized in the network and has a
co-located neighbour whose cell boundary follows the
boundary of the said cell. The secondary cell has a preferred
band the same as that of its own frequency type.
SEF Support Entity Function (GSM Rec.12.00).
SFH Slow Frequency Hopping.
SI Screening Indicator.
SI Service Interworking.
SI Supplementary Information.
SIA Supplementary Information A.
SID Silence Descriptor.
SIF Signal Information Field. The bits of a message signal unit
that carry information for a certain user transaction; the SIF
always contains a label.
SIM Subscriber Identity Module. Removable module which is
inserted into a mobile equipment; it is considered as part of
the MS. It contains security related information (IMSI, Ki,
PIN), other subscriber related information and the algorithms
A3 and A8.
SIMM Single Inline Memory module.
SIMM System Integrated Memory Module.
SIO Service Information Octet. Eight bits contained in a message
signal unit, comprising the service indicator and sub-service
field.
SITE BSC, BTS or collocated BSC-BTS site.
SIX Serial Interface eXtender. Converts interface levels to TTL
levels. Used to extend 2 serial ports from GPROC to external
devices (RS232, RS422, and fibre optics).
SK Secondary Key. A database column attribute, the secondary
key indicates an additional index and/or usage as a
composite key.
SL Signalling Link.
SLNK Serial Link.
SLR Send Loudness Rating.
SLTM Signalling Link Test Message.
SM Switch Manager.
SM Summing Manager.
SMAE System Management Application Entity (CCITT Q795, ISO
9596).
SMCB Short Message Cell Broadcast.

S Version 1 Revision 1
SME Short Message Entity.

SMG Special Mobile Group.
SMP Motorola Software Maintenance Program.
SMS Short Message Service.
SMSCB Short Message Service Cell Broadcast.
SMS-SC Short Message Service - Service Centre.
SMS/PP Short Message Service/Point-to-Point.
Smt Short message terminal.
SN Subscriber Number.
SND SeND.
SNDR SeNDeR.
SNR Serial NumbeR.
SOA Suppress Outgoing Access (CUG SS).
SP Service Provider. The organisation through which the
subscriber obtains GSM telecommunications services. This
may be a network operator or possibly a separate body.
SP Signalling Point.
SP Special Product.
SP SPare.
SPC Signalling Point Code.
SPC Suppress Preferential CUG.
SPI Signalling Point Inaccessible.
SPP Single Path Preselector.
SQE Signal Quality Error.
SQL Structured Query Language.
SRD Service Request Distributor.
SRES Signed RESponse (authentication).
SS Supplementary Service. A modification of, or a supplement
to, a basic telecommunication service.
SS System Simulator.
SSA SCCP messages, Subsystem-allowed (see CCITT Q.712
para 1.15).
SSAP Site System Audits Processor.
SSC Supplementary Service Control string.
SSF Subservice Field. The level 3 field containing the network
indicator and two spare bits.
SSM Signalling State Machine.
SSN SubSystem Number.
SSP Service Switching Point (an intelligent network element).
SSP SCCP messages, Subsystem-prohibited (see CCITT Q.712
para 1.18).
SSP SubSystem Prohibited message.

Version 1 Revision 1 S
SSS Switching SubSystem (comprising the MSC and the LRs).

SS7 ANSI Signalling System No. 7 (alias C7).
STAN Statistical ANalysis (processor).
STAT STATistics.
stats Statistics.
STC System Timing Controller.
STMR Side Tone Masking rating.
SUERM Signal Unit Error Rate Monitor.
STP Signalling Transfer Point.
Superframe 51 traffic/associated control multiframes or 26
broadcast/common control multiframes (period 6.12s).
Super user User account that can access all files, regardless of
protection settings, and control all user accounts.
SURF Sectorized Universal Receiver Front-end (Used in
Horizonmacro).
SVC Switch Virtual Circuit.
SVM SerVice Manager.
SVN Software Version Number.
SW Software.
SWFM SoftWare Fault Management.
sync synchronize/synchronization.
Synchronization burst Period of RF carrier less than one timeslot whose modulation
bit stream carries information for the MS to synchronize its
frame to that of the received signal.
SYS SYStem.
SYSGEN SYStem GENeration. The Motorola procedure for loading a
configuration database into a BTS.

T Version 1 Revision 1
T
T Timer.
T Transparent.
T Type only.
T43 Type 43 Interconnect Board. Provides interface to 12
unbalanced (6-pair) 75 ohm (T43 coax connectors) lines for
2 Mbit/s circuits (See BIB).
TA Terminal Adaptor. A physical entity in the MS providing
terminal adaptation functions (see GSM 04.02).
TA Timing Advance.
TAC Type Approval Code.
TACS Total Access Communications System (European analogue
cellular system).
TAF Terminal Adaptation Function.
TATI Transmit Antenna Transceiver Interface. The TATI consists
of RF combining equipments, either Hybrid or Cavity
Combining. (See CCB).
TAXI Transparent Asynchronous Transmitter/Receiver Interface
(physical layer).
TBD To Be Determined.
TBR Technical Basis for Regulation.
TBUS TDM Bus.
TC Transaction Capabilities.
TCAP Transaction Capabilities Application Part (of Signalling
System No. 7).
TCB TATI Control Board.
TCH Traffic CHannel. GSM logical channels which carry either
encoded speech or user data.
TCH/F A full rate TCH.
TCH/F2.4 A full rate TCH at 2.4 kbit/s.
TCH/FS A full rate Speech TCH.
TCH/H A half rate TCH.
TCH/H2.4 A half rate TCH at 2.4 kbit/s.
TCH/H4.8 A half rate TCH at 4.8 kbit/s.
TCH/HS A half rate Speech TCH).
TCI Transceiver Control Interface.
TCP/IP Transmission Control Protocol/Internet Protocol.
TC-TR Technical Commitee Technical Report.
TCU Transceiver Control Unit.
TDF Twin Duplexed Filter. (Used in M-Cellhorizon).
TDM Time Division Multiplexing.

Version 1 Revision 1 T
TDMA Time Division Multiple Access.

TDU TopCell Digital Unit.
TE Terminal Equipment. Equipment that provides the functions
necessary for the operation of the access protocols by the
user.
Tei Terminal endpoint identifier.
TEI Terminal Equipment Identity.
TEMP TEMPorary.
TEST TEST control processor.
TFA TransFer Allowed.
TFP TransFer Prohibited.
TFTP Trivial File Transfer Protocol.
TI Transaction Identifier.
Timeslot The multiplex subdivision in which voice and signalling bits
are sent over the air. Each RF carrier is divided into 8
timeslots.
Timing advance A signal sent by the BTS to the MS. It enables the MS to
advance the timing of its transmission to the BTS so as to
compensate for propagation delay.
TLV Type, Length and Value.
TM Traffic Manager.
TMI TDM Modem Interface board. Provides analogue interface
from IWF to modems for 16 circuits (p/o IWF).
TMM Traffic Metering and Measuring.
TMN Telecommunications Management Network. The
implementation of the Network Management functionality
required for the PLMN is in terms of physical entities which
together constitute the TMN.
TMSI Temporary Mobile Subscriber Identity. A unique identity
temporarily allocated by the MSC to a visiting mobile
subscriber to process a call. May be changed between calls
and even during a call, to preserve subscriber confidentiality.
TN Timeslot Number.
TON Type Of Number.
Traffic channels Channels which carry user’s speech or data (see also TCH).
Traffic unit Equivalent to an erlang.
Training sequence Sequence of modulating bits employed to facilitate timing
recovery and channel equalization in the receiver.
TRAU Transcoder Rate Adaption Unit.
TRU TopCell Radio unit.
TRX Transceiver(s). A network component which can serve full
duplex communication on 8 full-rate traffic channels according
to specification GSM 05.02. If Slow Frequency Hopping
(SFH) is not used, then the TRX serves the communication
on one RF carrier.
TS Technical Specification.

T Version 1 Revision 1
TS TeleService.
TS TimeSlot (see Timeslot).
TSA TimeSlot Acquisition.
TSA TimeSlot Assignment.
TSDA Transceiver Speech & Data Interface.
TSC Training Sequence Code.
TSI TimeSlot Interchange.
TSDI Transceiver Speech and Data Interface.
TSM Transceiver Station Manager.
TSW Timeslot SWitch.
TTCN Tree and Tabular Combined Notation.
TTL Transistor to Transistor Logic.
TTY TeleTYpe (refers to any terminal).
TU Traffic Unit.
TUP Telephone User Part (SS7).
TV Type and Value.
Tx Transmit(ter).
TXF Transmit Function (of the RTF).
TXPWR Transmit PoWeR. Tx power level in the
MS_TXPWR_REQUEST and MS_TXPWR_CONF
parameters.
TxBPF Transmit Bandpass Filter.

Version 1 Revision 1 U
U
UA Unnumbered Acknowledgment. A message sent from the
MS to the BSS to acknowledge release of radio resources
when a call is being cleared.
UDI Unrestricted Digital Information.
UDP User Datagram Protocol.
UDUB User Determined User Busy.
UHF Ultra High Frequency.
UI Unnumbered Information (Frame).
UIC Union International des Chemins de Fer.
UID User ID. Unique number used by the system to identify the
user.
UL Upload (of software or database from an NE to a BSS).
Um Air interface.
UMTS Universal Mobile Telecommunication System.
UPCMI Uniform PCM Interface (13 bit).
UPD Up to Date.
Uplink Physical link from the MS towards the BTS (MS transmits,
BTS receives).
UPS Uninterruptable Power Supply.
UPU User Part Unavailable.
Useful part of burst That part of the burst used by the demodulator; differs from
the full burst because of the bit shift of the I and Q parts of
the GMSK signal.
USSD Unstructured Supplementary Service Data.
UUS User-to-User Signalling supplementary service.

V Version 1 Revision 1
V
V Value only.
VA Viterbi Algorithm (used in channel equalizers).
VAD Voice Activity Detection. A process used to identify presence
or absence of speech data bits. VAD is used with DTX.
VAP Videotex Access Point.
VBS Voice Broadcast Service.
VC Virtual Circuit.
VCO Voltage Controlled Oscillator.
VCXO Voltage Controlled Crystal Oscillator.
VDU Visual Display Unit.
VGCS Voice Group Call Service.
VLR Visitor Location Register. A GSM network element which
provides a temporary register for subscriber information for a
visiting subscriber. Often a part of the MSC.
VLSI Very Large Scale Integration (in ICs).
VMSC Visited MSC. (Recommendation not to be used).
VOX Voice Operated Transmission.
VPLMN Visited PLMN.
VSC Videotex Service Centre.
V(SD) Send state variable.
VSP Vehicular Speaker Phone.
VSWR Voltage Standing Wave Ratio.
VTX host The components dedecated to Videotex service.

Version 1 Revision 1 W
W
WAN Wide Area Network.
WPA Wrong Password Attempts (counter).
WS Work Station. The remote device via which O&M personnel
execute input and output transactions for network
management purposes.
WSF Work Station Function block.
WWW World Wide Web.

X Version 1 Revision 1
X
X.25 CCITT specification and protocols for public packet-switched
networks (see PSPDN).
X.25 link A communications link which conforms to X.25 specifications
and uses X.25 protocol (NE to OMC links).
XBL Transcoder to BSS Link. The carrier communications link
between the Transcoder (XCDR) and the BSS.
XCB Transceiver Control Board (p/o Transceiver).
XCDR Full-rate Transcoder. Provides speech transcoding and 4:1
submultiplexing (p/o BSS, BSC or XCDR).
XCDR board The circuit board required to perform speech transcoding at
the BSS or (R)XCDR). Also known as the MSI (XCDR)
board. Interchangeable with the GDP board.
XFER Transfer.
XID eXchange IDentifier.
X-Term X terminal window.

Version 1 Revision 1 Z
Z
ZC Zone Code

Z Version 1 Revision 1

Answers


Chapter 1 Answer – Signalling Links

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces Answers–1

Answers–2 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

Chapter 3 – Exercise Answer
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ
", ÑÑÑ
ÑÑÑÑ ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ ÑÑÑ
ÑÑÑÑ ÑÑÑ
ÑÑÑ
",
ÑÑÑÑ
ÑÑÑ
", ", ", ", ", ", $%&,
ÑÑÑ

ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑ

ÑÑÑ
ÑÑÑ
*++ "$
ÑÑÑ

ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑ

ÑÑÑ
ÑÑÑ
'&,*'$ "$
ÑÑÑ

ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑ

ÑÑÑ
ÑÑÑ
& ,! &",'*
ÑÑÑ

ÑÑÑÑ
ÑÑÑ
ÑÑÑ
*',''$ "+*"%"&,'* & #"(
ÑÑÑÑÑÑÑ
ÑÑÑ ÑÑÑ
ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑÑ &",'*
ÑÑÑ

ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑÑÑÑ ÑÑÑÑ
ÑÑÑ ÑÑÑ
ÑÑÑÑ ÑÑÑ
/
ÑÑÑ ÑÑÑÑ
ÑÑÑ ÑÑÑÑÑÑÑÑÑÑÑÑ

++ 0( *."
)-+,
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑÑ
ÑÑÑ
ÑÑÑ
*." 0(
"(!*"& #0 +)-& &-%*

ÑÑÑÑ
ÑÑÑ
ÌÌÌÌ ÑÑÑ
ÌÌÌ ÑÑÑÑ

ÑÑÑ
ÑÑÑ
& ,! ' '"$ ,,"'& $++%*#
ÑÑÑ

ÌÌÌÌ
ÌÌÌ
ÑÑÑÑÑÑÑ

ÑÑÑ
ÑÑÑ
ÑÑÑ

ÑÑÑ
ÑÑÑÑ

ÌÌÌ
ÑÑÑ ÌÌÌÌ
ÌÌÌ
ÌÌÌÌÑÑÑÑÑÑÑÑÑÑÑÑ


,, $++%*#
,, $++%*#
ÑÑÑ

ÑÑÑ

ÑÑÑÑ
ÑÑÑ
ÑÑÑÑ ÑÑÑ
ÑÑÑ ÑÑÑÑ

ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑ ÑÑÑÑ
ÌÌÌ
ÌÌÌÌ
ÑÑÑ
ÌÌÌ ÑÑÑÑ
ÌÌÌ


,, $++%*#
& ,! '"$ &,",0
ÑÑÑ

ÑÑÑÑ
ÑÑÑ ÑÑÑÑ
ÑÑÑ
ÑÑÑ
ÑÑÑ
ÌÌÌ ÑÑÑÑ
ÌÌÌ
,, '"$ &,",0
ÑÑÑ
ÑÑÑÑÑÑÑ
ÑÑÑ
/
ÑÑÑÑ ÑÑÑ
ÑÑÑ
/
ÑÑÑÑ
ÑÑÑ ÑÑÑ
ÑÑÑÑ ÑÑÑ
/
ÑÑÑ ÑÑÑÑ
ÑÑÑ
/
/
/
/
/
/
/
/
/
/
/
/
/
,, ',,
,, ',,
ÑÑÑÑÑÑÑ
ÑÑÑ
/
ÑÑÑÑÑÑÑ ÑÑÑ
ÑÑÑ
/
ÑÑÑÑ
ÑÑÑ ÑÑÑ
ÑÑÑÑ ÑÑÑ
/
ÑÑÑ ÑÑÑÑ
ÑÑÑ
/
/
/
/
/
/
/
/
/
/
/
/
/
,, ',,
,,
',,


Chapter 5 Appendix B – Exercise Answers

1. The A-bis message to be transmitted is PAGING CoMmanD. The BSC receives a PAGING REQUEST
message from the MSC but on the A-bis link this is converted into a PAGING CoMmanD message
(TS GSM 08.58 section 8).
8 7 6 5 4 3 2 1 BIT POSITION
0 1 1 1 1 1 1 0 FLAG
0 0 0 0 0 0 1 0 ADDRESS octet 1
0 0 0 0 0 1 1 1 ADDRESS octet 2
0 0 0 0 0 0 1 0 CONTROL octet 1
0 0 0 0 1 1 0 1 CONTROL octet 2
0 0 0 0 1 1 0 0 MESSAGE DISCRIMINATOR
0 0 0 1 0 1 0 1 MESSAGE TYPE–PAGING COMMAND
0 0 0 0 0 0 0 1 CHANNEL No element identifier
1 0 0 1 0 0 1 0 CHANNEL No octet 2
0 0 0 0 1 1 1 0 PAGING GROUP element identifier
0 0 0 0 0 1 0 0 PAGING GROUP octet 2
0 0 0 0 1 1 0 0 MS IDENTITY element identifier
0 0 0 0 1 0 0 0 MS IDENTITY length indicator
0 0 1 0 1 0 0 1
0 1 0 0 0 0 1 1
0 0 0 0 0 0 0 1
0 0 1 0 0 0 0 1
0 1 0 0 0 0 1 1

0 1 1 0 0 1 0 1
1 0 0 0 0 1 1 1
0 0 0 0 1 0 0 1
0 0 1 0 1 0 0 0 CHANNEL NEEDED element identifier
x x x x x x 0 1 CHANNEL NEEDED octet 2
1 0 1 1 1 0 1 1 FCS octet 1
1 0 1 0 1 1 1 0 FCS octet 2
0 1 1 1 1 1 1 0 FLAG
1. The MS will respond with a RACH (TS GSM 04.08) with an ESTABLISHMENT CAUSE – ANSWER TO
PAGING. The BTS will allocate an SDCCH channel in response to this and send an ESTablish
INDication message type on the A-bis interface to the BSC.


Chapter 6 Appendix A – Answers

NOTE: Where an * appears next to a message denotes the

message flow between the MSC and the CALLED MS
NOTE 2: The CC may carry the authentication request


Sys01 PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Sys01 PDF

Caricato da

Copyright:

Formati disponibili

CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

Motorola 1993, 1994, 1995, 1996, 1997, 1998, 1999

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces i

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

Copyrights, notices and trademarks

and MOTOROLA are registered trademarks of Motorola Inc.

ii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces iii

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

iv SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces v

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

Interface Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18

vi SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces vii

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

BSS Management Application Part (BSSMAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50

viii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces ix

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

SMS CB Message Structure (Air-Interface) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8–20

Glossary of Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Glos–1

x SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces xi

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

xii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 1

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

Special key sequences

CTRL-c Press the Control and c keys at the same time.

2 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

First aid in case of electric shock

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 3

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

4 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 5

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

6 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

Introduction to GSM Interfaces

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces i

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

ii SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces iii

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

iv SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

Introduction to GSM Interfaces

MOTOROLA LTD. 2001–2 SYS01: GSM Interfaces 1–1

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED

GSM System Entities

1–2 SYS01: GSM Interfaces MOTOROLA LTD. 2001–2

FOR TRAINING PURPOSES ONLY – THIS MANUAL WILL NOT BE UPDATED