Terrestrial Interfaces: Francesco Menichella Hanoi, January 2012

CODICE-DAT
Terrestrial Interfaces
Francesco Menichella
Hanoi, January 2012
Le informazioni contenute in questo documento sono di proprietà di Value Team S.p.A. e del destinatario del documento. Tali informazioni sono strettamente legate ai commenti orali che le hanno accompagnate, e possono essere utilizzate solo dalle
persone che hanno assistito alla presentazione. Copiare, pubblicare o distribuire il materiale contenuto in questo documento è proibito e può essere illegale.
CODICE-DAT
GSM Network PSTN PLMN

Legend
GSM Protocol family PSTN PLMN
GERAN
Utran
Core Network
Circuit Switched Mc
Core Network Nb MGW
Registers
Core Networks
Packet Switched
A
MSC B
Mc GMSC
E
MGW Nc
Ab
BTS is er Iu-CS
At
TRAU
VLR
C
is
Ab
G
MSC
E
B
BSC
D
F
PCU RNC
IuR
BTS
H
AUC PDN
Um
IuPS
Gb GMSC VLR
Iub Gc
Gd HLR Gi Inter-PLMN
EIR r Gs Backbone
RNC G
#5
Uu Gf
NodeB Gn
GGSN Gp
#5
SGSN
BG
Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 2
CODICE-DAT
Functions mapping in BSC and BTS
The in-field BSS implementations foresees the fact that BTS is an independent and remote
network element respect to the BSC that is its controller.
This approach lead to a repartition between such two entities with the definition of the Abis
interface. Differently from other interface totally standardized and open as the A interface, the
Abis interface allows a degree of freedom mainly because of the fact that the BTS and the BSC
are very often from the same manufacturer, and so some functions could be made in BTS or in
BSC depending of the Manufacturer itself, such functionalities are e.g..:
• Voice Transcoding,
• Transmission Measurement elaboration,
• Power control
• partly also of Handover.
This freedom lead to the fact that is quite impossible to connect a Vendor x BTS to a Vendor y
without some abis changes. For example some changes are made to connect the Siemens BTS to
a Nokia BSC (Gemini) and Motorola BTS to Nokia BSC (MotoGP).
The guideline are to concentrate the control features in BSC and to demand the transmission
functions to BTS (in duality with the MS) in order to don’t overload the BSC.

CODICE-DAT
Typical BSC functions.
• Radio Network (BTSs and related TRXs) Control and Supervision
• Terrestrial Channels Connections handling, this between the A/Ater and Abis interfaces,
implying the BSC as switching element
• Radio Connection to/from MS handling, including paging (only retrasmission), handover

(intra-BSS), ...
• BSS O&M handing of the previous bullet
• Call queueing

CODICE-DAT
Typical BTS functions
• Radio Channel Handling
• Uplink transmission measurement
• Timing advance: calculation and control
• Free channel status handling
• Encryption, paging, main HO tasks, ... (in general execution tasks).

CODICE-DAT
BSC/TRAU or BTS functionalities depending on Vendor
• Transmission measurement pre-elaboration
• transmission power control
• Transcoding/Rate Adaptation

CODICE-DAT
Functions Split I
Functions BTS BSC NSS (MSC, VLR, HLR)

CODICE-DAT
Functions Split II
Functions BTS BSC NSS (MSC, VLR, HLR)

CODICE-DAT
BSS interfaces: Generalities
In the BSS we can see the following main interfaces:
• Um
• Abis
• Ater
• A
• Gb
We’ll focus on Abis, Ater and A as terrestrial ones,

Gb will be handled in Packet Services Session.

CODICE-DATA
BSS interfaces: Generalities
Two important properties that are relevant for the “internal” BSS interfaces are:
• Submultiplexing tecnique. This made possible by the physical availability of Ater interface
means the use of an external physical TRAU differentiated from BTS and BSC.
If such TRAU is co-located to the MSC and so often remote respct to BSC it could be interesting
boundle in a 64kbps terrestrial channel 4 Full Rate channels @16kbps (or 8 Half rate channels
@8kbps), this is the above mentioned Submultiplexing allowing interesting money saving for
the Operator becasue of the cost of PCM lines.
The same tecnique, illustrated in the ITU-T I.460 is used for the same purpose on the Abis
interface.

CODICE-DATA
TRAU frames
• The payload carried in the channels between BTS and TRAU and switched on BSC adopts the
“TRAU Frames” format. Such frames are specified according to ITU-T V.110 and are different
depending on the channel type (speech or data, and bit rate).
• Depending if uplink or downlink the Trau frames:

• are created in the BTS, they pass the BSC and via Ater are converted in PCM format in the
TRAU on the A interface
• are created in the TRAU, they pass the BSC and via Abis are converted in the GSM format
in the BTS.
• The behaviour above requires an ad hoc synchronization that is achieved via TRAU frames
themselves.

CODICE-DATA
TRAU frames
Also compressions and format conversions in the network are performed by the
Transcoder and Rate Adaptation Unit
Information on the A bis and A ter interfaces is encoded in TRAU frames
TRAU voice frames represent 20 ms. of audio
• FR channels - TRAU frames are 320 bits = 40 bytes
• HR channels - TRAU frames are 160 bits = 20 bytes
The TRAU frames are transported over FR and HR channels
Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina

CODICE-DATA
TRAU frames
• The information carried by the TRAU-frames is of three types:
• Speech
• Data structures of N bytes repeated each 20 ms
• O&M
C = Control bit
D = Data bit
T = Time alignment bit
Speech channels TCH/F TRAU frames

N= 40 for 16kbps
N = 20 for 8 kbps
CODICE-DATA
TRAU frames
• The TRAU frame format as indicated in the previous slide is organized in structures of N bytes
repeated, on the transmission media, every 20 ms (where N = 40 for 16 kpbs channels and N=
20 for 8 kbps channels).
• The meaning of each bit of such structure is fixed.

• The main part of the bits – D bits – are a part of the signal of the payload.
• The remaining part (C or T bits) are the auxiliaty informations needed for the correct
transmission between BTS and TRAU, the so called in-band signalling and are the Control and
Time alignment bits.
• Taking in consideration the above bit meaning, there are so net bit rate of 13 kbps and 5,6
kbps with an overhead of 3 and 2,4 kbps for FR/EFR and HR respectively.

CODICE-DATA
Trau Frames
If we take for example the Full Rate (FR), the TRAU frame specifications are as follows:
Total bits per frame: 320
Synchronization bits: 25
Control bits: C1 to 15
C17 to 21 (frame dependent and for future applications)
There are four variants for the C, D and T bits,
depending on the frame type:
1. Speech frame
Data bits: D1 to 260
Control bits: C16 to 21
TA bits: T1 to 4
2. O&M frame
Spare bits: S1 to 6
3. Data frame
First bit of odd octets (5 to 39) is “1”
4. Idle speech frame
Like the speech frame, but all data bits are set to “1”

CODICE-DATA
Trau Frames
The protocol used on the Abis interface is LAPD, which is adapted from ISDN. LAPD provides the following
frame types (mentioned here even if not really TRAU frames) and that can be divided into three groups:
± the unnumbered frames (SABM, DISC, UA, DM, UI),

± the information transfer frame (I)
± the supervisory frames (RR, RNR, REJ, FRMR).
In addition to the radio signaling procedures the Abis interface also provides a means of transport for
operation and maintenance procedures for BTSs, as well as a transport mechanism for Layer 2 management
procedures inherited directly from ISDN standards.

CODICE-DATA
TRAU frames
• The infos carried via in-band signalling are:
• Synchronization (Time Alignment and Frame Alignmeent) between BTS and TRAU
• Payload type (speech, data, O&M) and channel type
• Information of codec and if DTX is used or not
• CRC control bits (for HR only)
When the payload (speech) there are some pauses “idle TRAU Frames” there are inserted
and they are used to assure the synchronization between BTS and TRAU. Note that in the
case that in Ater @ 16kbps about the half of the bits carried in the TRAU frames are idle
TRAU frames.

CODICE-DATA
A interface
• The A interface interconnects the BSS with the related MSC.
• From physical location point of view there could be 2 cases depending on where the TRAU is
located.
• TRAU co-located to MSC
• TRAU remote respect to MSC

CODICE-DATA
A interface
• The A interface is a PCM-standard interface towards the MSC. It is specified by the GSM
08.01 to 08.20 recommendations for GSM 900 and GSM 1800 mobile networks, and by
the T1P1 (J-STD-024) recommendations for the GSM 850 and GSM 1900 mobile networks.
• 64 kbps channels for traffic and signalling (TS of PCM stream).
• It deals with the traffic channels as well as the signaling channels used for the
common channel signaling system no. 7 (SS7) between the BSC and the MSC.
• The CCSS No. 7 signaling, even if not 1:1 applicable in the US terrestrial network (where the equivalent
ANSI no. 7 is mandatory), is used within the MSC and the BSS. As a consequence, the MSC typically
performs the required inter-working functions towards the North American terrestrial network
• Phone Signalling Codec: PCM G.711 (Europe: A law. North-America: m law).

CODICE-DATA
A interface
Physical layer and transmission media
The TRAU and the MSC link interfaces allow the interconnection of 2 Mbps lines with
120 Ohm (symmetrical pair) or 75 Ohm (coaxial cable).
Further main characteristics of these 2 Mbps (or 1.414 Mbps in case of ANSI/SONET T1) links
include (European std considering):
• 2 Mbps transfer rate conforming to the G.703 recommendations

• Frame structure, synchronization and timing conforming to the G.705 recommendations
• Frame alignment loss and recovery conforming to the G.732 recommendations
• Fault condition management conforming to the G.732 recommendations
• CRC4 checks conforming to the G.704 recommendations to supervise the line

CODICE-DATA
A interface
• The information carried are:
• Speech @64 kbps (G.703 – G.711) or data
• (C)SS7 Signalling divided in two protocols:

• BSSMAP, that is related to the RRM (Radio Resource Management) functions
• DTAP, that is related to CM (Connection Management) and MM (Mobility
Managemet)
• O&M related BSS and OMC (see next slide), this kind of infomations are transparently
passed by the MSC without entering in its meaning (sometetimes referred also as Nailed
Connection). This is an alternative choice respect to the trasfer from BSC to OMC via packet
network.

CODICE-DATA
GSM network
NMC
with O&M and N-Itf
SMLC/CBC/LMUs N-Itf N-Itf
O&M Centers
OMC
PSTN PLMN
OMC SMLC
PSTN PLMN
CBC-SMLC
External LCS Client
Le
CBC SMLC
Nb MGW Mc
Q-Itf
LMU
Type A Lb Ls
Gateway
Lc
Q- Itf MLC
MSC GMSC
Nc
MGW
LAPD Iu-CS
TRAU Lh
BTS Q- Itf C
(LMU Type B) VLR
gsmSCF
MSC
LAPD
BSC
PCU RNC
IuR
BTS
IuPS AUC PDN

Gb GMSC VLR
HLR Gc Inter-PLMN
LMU EIR Gs Backbone
RNC
Type B Iub
#5
GGSN
Uu
NodeB
SGSN
#5
BG
CODICE-DATA
Ater Interface
• Is the interface between BSC and TRAU.
• The Transcoding and Rate Adaptation function are typical BSS functions.
• In the very first GSM Systems such capabilities was performed by BTS, now are more often
made in BSC, if it has the TRAU integrated in BSC or by MSC and MSC if there is a dedicated
NE for the TRAU.
• In this latter case so we can talk of Ater interfaces. Such interface is optional and not
completelly standardized among different vendors, in fact some Vendors call it with other
names (e.g. Ex Siemens systems use the term Asub interface).
• With the use of the Ater the TRAU frames and submultiplexing are used.

CODICE-DATA
Ater Interface
• Physical:
• PCM Transmission Media (G.703/ G.704 /G.705). Type E1 for GM900 and DCS1800 and
Type T1 for PCS1900
• The number of host channels in each TS @64kbps via submultiplexing

• 4 channels @16kbps, for FR and EFR traffic
• 8 channels @8kbps for HR traffic
• other channels (typically @64kbps) for signalling and O&M.
• Speech coding: it is the one adopted in the BSS for the considered TCH (FR, HR, ...), the
transcoding functions are performed in the TRAU NE.

CODICE-DATA
Ater Interface
• Carried information between BSC and TRAU are:
• speech @16kbps or @8kbps or data in TRAU Frames format (Racc. GSM 08.60 and GSM
08.061).
• In- band signalling including control and synchronization.
• O&M signalling Vendor Specific for the Operation and Administration of the TRAU
• TRAU transparent signalling between MSC and BSS/MS
• DTAP between MSC and MS (transparent also for the BSS)
• BSSMAP between MSC and BSS and elaborated in BSS
• CCS7 signalling between MSC and BSC, carried on dedicated links.
• Any O&M data trasferred between BSS and OMC (as for the A interface).

CODICE-DATA
Abis Interface
• The Abis interface in priciple is optional (as the Ater) because teoretically in the BSS the RX-TX
functions and control could be not split, but it is a very common approach to have the BTS and
BSC as two separate entities.
• in such case the Abis interface is defined and it is standardized even if with some degree of
freedom that make such interface vendor specific and BSC and BTS from different Vendors
could inter-communicate only with some modifications (e.g. Gemini and MotoGP).

CODICE-DATA
Abis Interface
• Physical:
• PCM Transmission Media (racc GSM 08.54)

• Type E1 for GM900 and DCS1800 and Type T1 for PCS1900
• The number of host channels in each TS @64kbps via submultiplexing (as in the Ater)
• 4 channels @16kbps, for FR and EFR traffic
• 8 channels @8kbps for HR traffic
• other channels (typically @64kbps) for signalling and O&M.
• Note that in the past there was also some TRAU functions witohout submux and
so realised using just 64kbps.

CODICE-DATA
Abis Interface
• Speech coding:
• it is the one adopted in the BSS for the considered TCH (FR, HR, ...) when the
transcoding functions are performed in the TRAU NE.
• it became PCM in the case the transcoding is realised in BTS (this solution is no
more used).
• Payload format: Trau frames
• Air channel – transmission channel corrispondance 1:1 not blocking and O&M
configurable.

CODICE-DATA
MOBIS
The Motorola defined BSC-to-BTS interface is a modification of the Abis standard called Mobis.
It distributes functionality between the BSC and the remote BTS equipment, and Motorola
claims offering some features as:
• Reduced signalling link traffic, which permits efficient use of E1 links. The BTS performs
handover data processing which reduces the amount of data sent to the BSC over the
signalling link. This significantly reduces the amount of processing required in the BSC.
• Better synchronization of the BSC and BTS ensures better handover from one traffic
channel to another.
• Improved overload control and fault recovery algorithms.
• Efficient use of the paging and access grant channels.
• Control of more than one BTS (sectors) on a single control link.

CODICE-DATA
Abis Interface
• Possible Abis Configurations
The TS on the Physical Media could be assigned to one or more BTS as the following typical
network configurations
Star Configuration
Serial (or Multidrop) Configuration
Ring Configuration

CODICE-DATA
Abis Interface
• Star Configuration
• In this configuration known also as point-to-point each BTS is connected to the BSC with a
PCM line. Typically there is a waste of TSs.

CODICE-DATA
Abis Interface
• Multirop (or Serial) Configuration
• More BTSs (or sites) are connected to BSC usign a single PCM line, each BTS uses a certain
number of the TS of such PCM. Respect to the the Star configuration, the PCM utilization is
more efficient but a fault causes the outage of the subsequent BTSs.

CODICE-DATA
Abis Interface
• Loop (or Ring) Configuration

• Starting from the Multidrop Configuration the last site (BTS) is connected to the BSC making
so a ring.
• The main advantage of such configuration is the reliability, if there is a fault on the PCM
line, the system is re-configured in two independent multidrop and there are less service
problem.

CODICE-DATA
Abis Interface
• Control Channel Multiplexing and common link signalling.

• The messages of Control Channel at Um interface are multiplexed in common links for
signalling in Abis Interface; it could be at single TRX level (so per 8TS carrier) or per Site. The
link bit rate could be 16, 32 (rare) or 64 kbps, according to GSM 08.52.
• Transport capacity at Abis Interface

• In order to understand the capacity of radio channels on Um interface let’s take in
consideration a BTS with 2TRX, with each 7TCH/F and with the BCCH on the first TRX and 8
SDCCH on the second TRX (i.e. a “classical” configuration for small BTSs).
• The signalling and control messages caming from BCCH and SDCCH could be multiplexed in
a single 16kbps link, while the 14 TCH/F takes 14 16kbps links on transmission media;
totally are used 15 links @16kbps on PCM line on (3,75) 4 TS @ 64kbps.
From the considerations above it comes the rough rule that each TRX load 2TS on the Abis
interface.

CODICE-DATA
CM divided in the sub-protocols

Call Control (CC), BSSAP allows the “adaptation” of
Short Message Services (SMS) the CCS7 in a “radio context”
BSS interface Protocol Stack Supplementary Serices (SS)
MS Um BTS Abis BSC A MSC

AP BSS AP
CM CM
DTAP DTAP
(04.08) MM MM (04.08) B
L S
3 RR* RR*
BSS MAP BSS MAP S
RR (04.08)
A
(04.08) RR’ P
RR’ BTSM BTSM (08.08) (08.08)
(04.08) (08.58) (08.58)
Distr. Funct. Distr. Funct.
SCCP (Q.71X) SCCP (Q.71X)

LAPDm LAPDm LAPD LAPD
(04.05) (04.05) (08.56) (08.56) MTP (Q.70X) MTP (Q.70X)
L1 (05.xy) L1 (05.xy) L1 (08.54) L1 (08.54) L1 (08.04) L1 (08.04)
Physical Medium (05.05) Physical Medium (G.7xx) Physical Medium (G.7xx)

Legenda: L1, L3 = Layer 1 , Layer 3 NOTE. Distribution
AP = Application Process LAPD/Dm = Link Access Protocol D/Dm Function is
BSSAP = BSS Application Part MM = Mobility Management between
BTSM = BTS Management MTP = Message Transfer Part DTAP and
CM = Connection Management RR = Radio Resource (Management) BTS MAP
DTAP = Direct Transfer Application Part SCCP = Signalling Connection Control Part
G. 7xx = G.703, G.705, G.732

CODICE-DATA
BSS Protocols
• Generality.
• The CCS7 (SS7) is supported in BSS by the BSSAP protocol and from the layers MTP/SCCP.
• The BSSAP allows the “adaptation” of the CCS7 in a “radio context”, see previous slide.
• Physical Level (including L1)

• PCM channel G.703 @64kbps on Abis and A interface
• Racc GSM 05.xy series on Um interface
• BSS Link Layer Protocols, used on Um, Abis and A interface

• Lev. 2 MTP on A interface; it handles with payload of 62 bytes
• LAPD, it is used on Abis interface and optionally on Ater for the O&M functions for
the TRAU from the BSC. LAPD is derived subset of Signalling System for ISDN (ITU-T
Q.920/921) and it is also handled in ETS 300.125 and Racc. GSM 08.56.
• LAPDm, it is used on Um and is derived from LAPD with modification for its use on
radio channels. Racc. 04.05.

CODICE-DATA
BSS Protocols
• Network Layer
• MTP+SCCP level 3 on A interface
• Ad hoc L3 that include other signalling functionalities, see protocol slide, for the Abis and Um
interfaces. Note that even if referred as OSI Level 3 protocols, they handle functionalites that are
typically of higher levels.
• BSSAP protocol
• It is related to A interface and it covers the communication between MSC and BSC/MS.
• on A interface it is divided in two parts:
• BSS management Application Part (BSSMAP – Racc GSM 08.08). It is related to the Radio
Resource handling functions and it is terminated on BSS.
• Direct Transfer Application Part (DTAP – Racc GSM 04.08). It supports a communication
between MSC and MS. The BSS offers just a transparent transport that maps the payload in
the Link Layer protocols, pratically it changes the headers and it is divided again in two
protocols:
• Connection Management (CM) that is related to the call handling and MS services divided
in the sub-protocols Call Control (CC), Short Message Services (SMS) and Supplementary
Serices (SS)
• Mobility Management (MM) is related to the handling of the MS mobility.

CODICE-DATA
BSS Protocols
• From BSS point of view, it is possible distinguishing (distribution function) the DTAP messages
from the BSSMAP messages via a bit of the discriminator present in the BSSAP header. The
messages to/from BTS are made in order to fill a payload of 272 bytes that is a value sufficient
for quite all the BSSAP signalling messages.
BSSAP messages include the following fields:
• Discrimination
Distribution between the two sub-protocols: BSSMAP and DTAP.
• DLCI
Only for DTAP. Used in MSC to BSS messages to indicate the type of origination data link
connection over the radio interface.
• Length
Subsequent Layer3 message parameter length.
• SCCP protocol transfers signalling information in bot CL (ConnectionLess) and CO (Connection

Oriented) modes, the CL mode is used for the “global” procedures (eg.g a cell or a whole BSS),
the CO for “dedicated” connections (i.e. Related to one single MS).

CODICE-DATA
BSSAP (from Cellular Protocols: http://www.protocols.com/pbook/telephony.htm)
GSM 08.06 http://www.etsi.fr
The MTP and the SCCP are used to support signalling messages between the Mobile
Services Switching Center (MSC) and the Base Station System (BSS).
One user function of the SCCP, called BSS Application Part (BSSAP) is defined.
In the case of point-to-point calls the BSSAP uses one signalling connection per active
mobile station having one or more active transactions for the transfer of layer 3 messages.
In the case of a voice group or broadcast call there is always one connection per cell
involved in the call and one additional connection per BSS for the transmission of layer 3
messages. There is an additional connection for the speaker in a broadcast call or the first
speaker in a voice group call up to the point at which the network decides to transfer
them to a common channel. Additional connections may also be required for any mobile
stations in the voice group or broadcast call which the network decides to place on a
dedicated connection

CODICE-DATA
BSSAP
The BSSAP user function is further subdivided into two separate functions:
The Direct Transfer Application sub-Part (DTAP), also called GSM L3, is used to transfer
messages between the MSC and the MS (Mobile Station); the layer-3 information in these
messages is not interpreted by the BSS. The descriptions of the layer 3 protocols for the MS-
MSC information exchange are contained in the 04- series of GSM Technical Specifications.
The BSS Management Application sub-Part (BSSMAP) supports other procedures between
the MSC and the BSS related to the MS (resource management, handover control), or to a cell
within the BSS, or to the whole BSS. The description of the layer 3 protocol for the BSSMAP
information exchange is contained in Recommendation GSM 08.08.

CODICE-DATA
BSSAP
Both connectionless and connection-oriented procedures are used to support the BSSMAP.
Rec. GSM 08.08 explains whether connection oriented or connectionless services should be
used for each layer 3 procedure. Connection oriented procedures are used to support the
DTAP. A distribution function located in BSSAP, which is reflected in the protocol specification
by the layer 3 header, performs the discrimination between the data related to those two
subparts.
BSSAP messages include the following fields:

• Discrimination
Distribution between the two sub-protocols: BSSMAP and DTAP.
• DLCI
Only for DTAP. Used in MSC to BSS messages to indicate the type of origination data
link connection over the radio interface.
• Length
Subsequent Layer3 message parameter length.

CODICE-DATA
BSSMAP (from Cellular Protocols: http://www.protocols.com/pbook/telephony.htm)
BSSMAP
The BSS Management Application Part (BSSMAP) supports all of the procedures between the MSC and the
BSS that require interpretation and processing of information related to single calls, and resource
management. Some of the BSSMAP procedures result in, or are triggered by, Radio Resource (RR)
management messages defined in GSM 04.08.
The format of the BSSMAP protocol is as follows:
1 byte
Message type
Information Element
Message Type
A one octet field defining the message type. This mandatory field uniquely defines the function and format
of each BSSMAP message.
Information Element
Each IE has an identifier which is coded as a single octet. The length of an IE may be fixed or variable and
may or may not include a length indicator.

CODICE-DATA
GSM L3 (from Cellular Protocols: http://www.protocols.com/pbook/telephony.htm)
GSM L3 (DTAP Direct Transfer Application Part )

The signalling layer 3 provides the functions to establish, maintain and terminate circuit-switched
connections across a GSM PLMN and other networks to which the GSM PLMN is connected. It provides the
necessary supporting functions related to supplementary services control and short messages service
control.
Furthermore it includes the functions necessary for mobility management and radio resource
management.
The layer 3 is composed of the following sublayers comprising:
• Radio Resource Management (RR)

• Mobility management (MM) (part of DTAP)
• Connection Management (CM) (part of DTAP)

CODICE-DATA
The Connection Management (CM) sublayer is composed of:
• Call Control (CC)

• Sort Message Support (SMS)
• Supplementary Services Support (SS)

CODICE-DATA
 The call control (CC) protocol (GSM 04.08 http://www.etsi.fr) is one of the protocols of the Connection
Management (CM) sublayer. Every mobile station must support the call control protocol. If a mobile
station does not support any bearer capability at all then it must respond to a SETUP message with a
RELEASE COMPLETE message. In the call control protocol, more than one CC entity are defined. Each CC
entity is independent from each other and communicates with the correspondent peer entity using its
own MM connection. Different CC entities use different transaction identifiers.
Certain sequences of actions of the two peer entities compose elementary procedures. These elementary
procedures may be grouped into the following classes:
• Call establishment procedures.
• Call clearing procedures.
• Call information phase procedures.
 Miscellaneous procedures.
The terms "mobile originating" or "mobile originated" (MO) are used to describe a call initiated by the
mobile station. The terms "mobile terminating" or "mobile terminated" (MT) are used to describe a call
initiated by the network.

CODICE-DATA
 SMS (GSM 04.11 http://www.etsi.fr)

The purpose of the Short Message Service (SMS) is to provide the means to transfer messages between a
GSM PLMN Mobile Station and a Short Message Entity via a Service Center, as described in TS GSM 03.40.
The terms "MO" - Mobile Originating - and "MT" - Mobile Terminating - are used to indicate the direction in
which the short message is sent.
The SMS structure is as follows for control messages:
4 4
Protocol Discriminator Transaction ID
Message type
Common Information Element (variable lenght)
Protocol discriminator
1001 identifies the SMS protocol.

CODICE-DATA
BSS Protocols
• Abis Protocols
• BTS Management Protocol (BTSM – Racc. GSM 08.58).

• it handles the Radio Resources for the BTS and it is terminated in the BTS. Such functions are:
• Radio Link Layer Management
• Dedicated Channel Management
• Common Channel Management
• TRX Management
Such functions include the HO execution and paging.
• Radio Resource Control (RR* - RR part of Racc GSM 04.08). It is related to the functions for the Radio
Resource handling not handled by the BTS (e.g. The MS channel assignment messages, HO commands
or Sys Info). It is transparently trasferred from the BTS to/from Um.
• Um Radior Resource Control Protocols (they are not terrestrial)
• RR’ (RR part of Racc GSM 04.08), it derives from the BTSM protocol and it is related to the RR
functions in the BTS
• RR*

CODICE-DATA
BSS Protocols
• BSS Link Layer Protocols
• The link Layer Protocols (LAPD and LAPDm) are part of the HDLC protocols and in such way they have the
frames structure and have some fucntions of HDLC protocol family:
• Handling, between controlled entities of the physical signalling connections (Signalling Link) and logical
(Logical Links). Each physical connection is at 16kbps or 64kbps link on the Abis or a radio channel on
the Um interface.
• Information Frames exchange from/to Lev.1, it means:
• Reception of frames and control of the errors not recovered by the Channel Coding
• Insertion of info frames on physical transport media
• Peer-to-peer handshake with the corresponding entity, it means:
• managementof the handshake, that could be acknowledged or unacknowledged.
• Information transfer
• Message transfer and service performing from/to Lev 3, it implies:
• Received Messages sequence control
• Flow control
• Priority management

CODICE-DATA
BSS Protocols: LAPD
• LAPD, Link Access Procedure --- D-Channel ref. ITU-T Q.921, handles three types of frames, distinguished
one each other from the field “Control”, as illustrated in the next slide figure:
• I Type: it is used for carrying the information to/from Level 3.

• S type: it is used for carrying supervision information (flow control and error control).
• U type: for information transport without information.
• In such structure, divided in 8 bytes, it is possible highlighting the following field between the two Flags.
• Address Field = SAPI + TEI (Service Access Point Identifier e Terminal Endpoint Identifier) information
type (C/R + E/A) where:
• SAPI and TEI identify the logical and physical link respectively.
• the C/R bit distinguishes Command frames respect to Response frames.
• the two E/A bits indicate /when there is 1) the end of the Address field.
• Control field distinguishes the frame type (it is not present in the U type frames)
• I type frames: it contains the frame number N(S) for the transmitted frames and N(R) for the
received frames, and the P/F bit used to indicate if the Frame is a generic one (Poll) or the last of
a procedure sequence (Final); such information are useful for the sequence and flow control.

CODICE-DATA
BSS Protocols: LAPD
N0 bit 8 8x2 8x2 8xn (n < 260) 8x2 8

Address
F S F
T F
L A C E E Control INFO L
EI C
A PI / A A (Optional) A
G R S G
Frame I 0 N(S) P/F N(R)
Frame S 1 Bit S * P/F N(R)
Legenda
FLAG : SU Begin/End TEI : Terminal End-Point Identifier
C/R : Command/Response N(R) : Sequential number of received frames
SAPI : Service Access Point Identifier N(S): Sequential number of transmitted frames
EA : Address Extension bit P/F: Poll/Final* S bits means S Frame type

CODICE-DATA
BSS Protocols: LAPD
• S type frames: it contains the 2 S bits that indicate the supervision function to activate and the number
N(R) of correct received frames and again the P/F frame; such informations are useful to understand if there
are re-transmissions of corrupted frames, to send acknowledge or to command transmission interruptions.
• Optional field Info: it is up to 260 bytes to/from Level 3, that are the 272 bytes indicated in the previous
slides without counting the control fiels. The Info field contains the effective signalling message.
• Frame Check Sequence (FCS) field: it makes a CRC error control on the received frames introducing a
16bit redundancy with the following polynomial generator:
• X16+X12+X5+1
• Flag - The value of the flag is always (0x7E).” Bit Stuffing” technique is used in order to ensure that the bit
pattern of the frame delimiter flag does not appear in the data field of the frame.

CODICE-DATA
BSS Protocols: LAPD
• It is also important consider the following addressing peculiarities for the LAPD
• the SAPI field indicates for each TEI a service type offered by Level 2
• SAPI = 0 for the Radio Signalling services/procedures (level 3 interest)
• SAPI = 62 for the O&M services/procedures (level 3 interest)
• SAPI = 63 for the Link Layer Management services/procedures (e.g. TEI management)
• the TEI parameter is used to address 126 different destinations (TRX or BCF) and the related point-to-
point connections in the BTS itself, pre-assigned by the Mobile Network Operator (MNO) and half of them
related assigned by the network, and one more assigned for the point-multipoint connections; the
addressing capacity is so of 128 different physical links (at 16 or 64 kbps) in which more logical links could
be multiplexed.
• The logical links carry Level 3 messages exchanged between BSC and TRX or BCF; such messages have a
Message Type that indicates the meaning and a Message Discriminator that indicates if a message needs
an elaboration in the BTS (BTSM protocol) or directly sent to the destination (RR* protocol)

CODICE-DATA
BSS Protocols: LAPDm
• The LAPDm derives from an adaptation to the Um interface of LAPD, hereafter the main differences are
listed:
• 6 possible frame formats, all derived from the LAPD general one.
• The Um interface asynchronous structure allow to avoid begin and end frames.
• in the control filed, the E/A and P/F bits have different meaning respect to the LAPD case.
• FCS fields are not present, and the error correction is made only by the Channel Coding.
• Addressing doesn’t use TEI, and for only DTAP messages, it is based on DLCI (Data Link Connection
Identifier) that indicates the channel type (FACCH, DCCH, SACCH) and Message Type; for the BSSMAP
and RR messages the possible channels are more (FACCH, DCCH, SACCH, BCCH, AGCH, RACH, PCH,
NCH) and are related to Message type; SAPI has only two values that indicate the priority: high priority
= 0 for the RR services and low priority = 3 for the SMS.

CODICE-DATA
BSS Protocols: LAPDm
• The Radio frame capacity needs to have a shorter message (21 bytes for the Info and 184 bits for the 2
Headers) and a Segmentation and Reassembly function for the L3 signalling messages when lenght is
more than a frame of 4 consecutive bursts. For different radio channels different trames are used.
• Because the message lenght is variable, in order to fill a frame it could be possible that some Fill Bits
are needed; in the Header there is a Lenght Indicator field (LI) that shows the effective message
lenght.
• The BCCH and CCCH channels have only the Not-Acknowledged mode with SAPI = 0.
• The RACH messages handling is different (burst mode) respct to the other channels: LAPDm relay them
directly to Level 3 (in which is performed a contention resolution functions), while in the other
channels there is apreliminary activation of the level 2 services (not allowed for such RACH messages).

CODICE-DATA
GSM protocols

CODICE-DATA
R99 Interfaces and Protocols

GSM User Plane PS
Application
IP, etc. IP, etc.
Relay
SNDCP SNDCP GTP -U GTP -U
LLC LLC
UDP UDP
Relay
RLC RLC BSSGP BSSGP
IP IP
MAC MAC Network Network L2 L2
Service Service
GSM RF GSM RF L1bis L1bis L1 L1
Um Gb Gn Gi
MS BSS SGSN GGSN

CODICE-DATA
R99 Interfaces and Protocols

UMTS User Plane PS
Application
E.g., IP, E.g., IP,

PPP, PPP,
OSP OSP
Relay Relay
PDCP PDCP GTP-U GTP-U GTP-U GTP-U
RLC RLC UDP/IP UDP/IP UDP/IP UDP/IP
MAC MAC AAL5 AAL5 L2 L2
L1 L1 ATM ATM L1 L1
Uu Iu-PS Gn Gi
MS UTRAN 3G-SGSN 3G-GGSN

Terrestrial Interfaces: Francesco Menichella Hanoi, January 2012

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Terrestrial Interfaces: Francesco Menichella Hanoi, January 2012

Uploaded by

Copyright:

Available Formats

CODICE-DAT

GSM Network PSTN PLMN

Functions mapping in BSC and BTS

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 3

Typical BSC functions.

• Radio Network (BTSs and related TRXs) Control and Supervision

• Radio Connection to/from MS handling, including paging (only retrasmission), handover

• BSS O&M handing of the previous bullet

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 4

Typical BTS functions

• Radio Channel Handling

• Uplink transmission measurement

• Timing advance: calculation and control

• Free channel status handling

• Encryption, paging, main HO tasks, ... (in general execution tasks).

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 5

BSC/TRAU or BTS functionalities depending on Vendor

• Transmission measurement pre-elaboration

• transmission power control

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 6

Functions BTS BSC NSS (MSC, VLR, HLR)

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 7

Functions BTS BSC NSS (MSC, VLR, HLR)

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 8

BSS interfaces: Generalities

In the BSS we can see the following main interfaces:

We’ll focus on Abis, Ater and A as terrestrial ones,

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 9

BSS interfaces: Generalities

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 10

• Depending if uplink or downlink the Trau frames:

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 11

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina

• The information carried by the TRAU-frames is of three types:

T = Time alignment bit

Speech channels TCH/F TRAU frames

• The meaning of each bit of such structure is fixed.

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 14

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 15

± the unnumbered frames (SABM, DISC, UA, DM, UI),

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 16

• The infos carried via in-band signalling are:

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 17

• The A interface interconnects the BSS with the related MSC.

• TRAU co-located to MSC

• TRAU remote respect to MSC

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 18

• 64 kbps channels for traffic and signalling (TS of PCM stream).

• Phone Signalling Codec: PCM G.711 (Europe: A law. North-America: m law).

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 19

Physical layer and transmission media

• 2 Mbps transfer rate conforming to the G.703 recommendations

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 20

• The information carried are:

• Speech @64 kbps (G.703 – G.711) or data

• (C)SS7 Signalling divided in two protocols:

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 21

IuPS AUC PDN

• Is the interface between BSC and TRAU.

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 23

• The number of host channels in each TS @64kbps via submultiplexing

Per le condizioni di utilizzo di questo documento si rimanda alla pagina di copertina 24

• Carried information between BSC and TRAU are: