A-Bis Over IP Interface v02 00

ip.
access
A-BIS OVER IP
Interface Specification
Neil Piercy
02 June 2008
© ip.access Ltd
COMPANY CONFIDENTIAL A-bis_over_IP_interface_v02_00_changesHidden.doc
The information contained in this document is commercially confidential
and must not be disclosed to third parties without prior consent.
© ip.access Ltd
REVISION HISTORY
Version Change Summary Date Author

2.00 Release frozen for SR3.x, and previous history 2nd June NPP
removed. 2008
DOCUMENT APPROVAL
Approved by ......................................................................... Date
© ip.access Ltd
CONTENTS PAGE
1 INTRODUCTION 1
1.1 Overview 1
1.2 Purpose 1
1.3 Scope 1
1.4 Deployment Scenarios 1
1.5 Terminology 1
1.6 References 1
2 CHANNELS 3
2.1 Physical Layer 3
2.2 Layer 2 Signalling 3
2.3 Traffic 3
2.4 Signalling Message Transports 4
2.4.1 Framed TCP Transport 4
2.4.2 SCTP 5
2.4.3 UDP Transport 5
3 O&M SIGNALLING MESSAGES 6

3.1 Unsupported O&M messages 6
3.1.1 Unsupported O&M Attributes 6
3.2 Manufacturer-Defined O&M Messages 6
3.2.1 Connect IP Signalling 7
3.2.2 Disconnect IP Signalling 7
3.2.3 Spare 8
3.2.4 Spare 8
3.2.5 Spare 8
3.2.6 Set NV Attributes 8
3.2.7 Get NV Attributes 10
3.2.8 Set Attributes 11
3.2.9 Attribute Value Change Event 13
3.2.10 SW Deactivate 14
© ip.access Ltd
CONTENTS PAGE
3.3 O&M Signalling Attributes 14

3.3.1 O&M Manufacturer-Defined Message Type 14
3.3.2 O&M Manufacturer-Defined Attribute Identifiers 15
3.3.3 Destination IP Address 16
3.3.4 Destination IP Port 16
3.3.5 Spare 16
3.3.6 Spare 16
3.3.7 Spare 16
3.3.8 Stream Identifier 17
3.3.9 NV Config Flags 17
3.3.10 Frequency Control 19
3.3.11 Primary and Secondary OML Config 19
3.3.12 IP Interface Config 20
3.3.13 IP Gateway Config 21
3.3.14 In Service Time 21
3.3.15 Location 21
3.3.16 Paging Configuration 22
3.3.17 Unit Id 22
3.3.18 Spare 23
3.3.19 Unit Name 23
3.3.20 SNMP Config 23
3.3.21 Primary OML Config List 24
3.3.22 Primary OML Fallback Timeout 24
3.3.23 Current SW Configuration 25
3.3.24 Timing Bus 26
3.3.25 CGI 27
3.3.26 RAC 27
3.3.27 Object Version 27
3.3.28 GPRS Paging Configuration 28
3.3.29 NSEI 28
© ip.access Ltd
CONTENTS PAGE
3.3.30 BVCI 28
3.3.31 NSVCI 28
3.3.32 NS Configuration 29
3.3.33 BSSGP Configuration 29
3.3.34 NS Link Configuration 30
3.3.35 RLC Configuration 30
3.3.36 Alarm Threshold List 31
3.3.37 Monitored Value List 32
3.3.38 Timing Bus Control 33
3.3.39 Supported Features 33
3.3.40 Coding Schemes 34
3.3.41 RLC Configuration 2 34
3.3.42 Heartbeat Timeout 35
3.3.43 Up Time 35
3.3.44 RLC Configuration 3 35
3.3.45 SSL Configuration 36
3.3.46 Security Possible 36
3.3.47 IML SSL State 37
3.3.48 Revocation Date 37
3.4 Manufacturer Dependent Information Elements 37
3.4.1 Additional Info 37
3.4.2 Additional Text 38
3.4.3 Event Type 38
3.4.4 File Data 38
3.4.5 File Id 38
3.4.6 File Version 39
3.4.7 HW Description 39
3.4.8 List of Required Attributes 40
3.4.9 Manufacturer Dependent State 40
3.4.10 Manufacturer Dependent Thresholds 41
© ip.access Ltd
CONTENTS PAGE
3.4.11 Manufacturer Id 41
3.4.12 Nack Causes 41
3.4.13 Physical Config 41
3.4.14 Specific Problems 42
3.4.15 Test No 42
3.4.16 Test Report Info 43
3.4.17 Perceived Severity 44
3.4.18 Probable Cause 45
3.4.19 Channel Combination 45
3.4.20 Measurement Identifier 45
3.4.21 Measurement Results 46
3.4.22 Object Class 47
3.4.23 Object Instance 48
3.4.24 SW Configuration 48
3.4.25 Get Attributes Response Info 49
3.4.26 Overload Period 49
3.5 Embedded Information elements 49
3.5.1 ARFCN Lists 50
3.5.2 Frequency Error List 52
3.5.3 Channel Usage List 52
3.5.4 BCCH Information Type 53
3.5.5 BCCH Information 54
3.5.6 RXLEV Threshold 55
3.5.7 Configuration 55
3.5.8 Result Details 56
3.5.9 Frequency Sync Options 56
3.5.10 MAC Address 57
3.5.11 HW-SW Compatibility Number 57
3.5.12 Manufacturer Serial Number 57
3.5.13 OEM Id 57
© ip.access Ltd
CONTENTS PAGE
3.5.14 Date and time of Manufacture and Calibration 58

3.5.15 Beacon Information 58
3.5.16 Frequency Error 58
3.5.17 SNMP Community String 59
3.5.18 SNMP Trap Address 59
3.5.19 SNMP Trap Port 59
3.5.20 SNMP Manager Address 59
3.5.21 SNMP System Contact 60
3.5.22 Factory Id 60
3.5.23 Factory Serial Number 60
3.5.24 Logged Event Indicator 61
3.5.25 Localised Additional Text Information 61
3.5.26 BTS Identifier 61
3.5.27 Broadcast L3 Message 62
3.5.28 Frequency Bands 62
3.5.29 Max Timing Advance 62
3.5.30 Ciphering Algorithms 62
3.5.31 Channel Types 63
3.5.32 Channel Modes 64
3.5.33 GPRS Coding Schemes 65
3.5.34 RTP Features 65
3.5.35 RSL Features 65
3.5.36 BTS Hardware Class 66
3.6 Manufacturer Extensions to existing O&M messages 66
3.6.1 Set BTS Attributes 66
3.6.2 Set Alarm Thresholds 66
3.6.3 Perform Test 67
3.6.4 Load Data Initiate 67
3.6.5 Set Radio Carrier Attributes 67
3.6.6 Set Channel Attributes 67
© ip.access Ltd
CONTENTS PAGE
3.6.7 State Changed Event Report 67

3.6.8 SW Activated Report 67
3.6.9 Get Attributes Response 67
3.6.10 Measurement Procedure Nacks 68
3.6.11 Load Data Abort 68
3.6.12 Reinitialise 69
3.7 Manufacturer Extensions to existing O&M Attributes 69
3.7.1 Autonomously Report 69
3.7.2 Power Class 69
3.8 Object Model and Attribute Mapping 70
3.8.1 Object Model 70
3.8.2 Object Attribute mappings 72
3.9 Object Version Number Assignments 76
3.9.1 Version Dependence common to all Object Classes 76
3.9.2 Site Manager 84
3.9.3 BTS 84
3.9.4 Baseband Transceiver 84
3.9.5 Radio Carrier 84
3.9.6 Channel 84
3.9.7 GPRS NSE 86
3.9.8 GPRS Cell 86
3.9.9 GPRS NSVC 86
4 RSL SIGNALLING MESSAGES 87

4.1 RSL Message Formats and Contents 87
4.1.1 Create Connection 87
4.1.2 Create Connection Acknowledge 88
4.1.3 Create Connection Negative Acknowledge 89
4.1.4 Modify Connection 89
4.1.5 Modify Connection Acknowledge 90
© ip.access Ltd
CONTENTS PAGE
4.1.6 Modify Connection Negative Acknowledge 90

4.1.7 Delete Connection Indication 91
4.1.8 Delete Connection 91
4.1.9 Delete Connection Acknowledge 92
4.1.10 Delete Connection Negative Acknowledge 92
4.1.11 Measurement Pre-processing Defaults 92
4.1.12 Directed Retry Enquiry 94
4.1.13 Handover Candidate Enquire 95
4.1.14 Handover Candidate Response 95
4.1.15 Paging Command 95
4.1.16 PDCH Activation 96
4.1.17 PDCH Activation Ack 96
4.1.18 PDCH Activation Nack 97
4.1.19 CCCH Load Indication 97
4.1.20 PDCH Deactivation 97
4.1.21 PDCH Deactivation Ack 97
4.1.22 PDCH Deactivation Nack 98
4.1.23 Create Multiplex Connection 98
4.1.24 Create Multiplex Connection Ack 98
4.1.25 Create Multiplex Connection Nack 99
4.1.26 Delete Multiplex Connection 99
4.1.27 Delete Multiplex Connection Ack 99
4.1.28 Delete Multiplex Connection Nack 99
4.1.29 Modify Multiplex Connection 100
4.1.30 Modify Multiplex Connection Ack 100
4.1.31 Modify Multiplex Connection Nack 100
4.2 RSL Information Elements 100
4.2.1 RSL Manufacturer-Defined Identifiers 101
4.2.2 Destination IP Address 101
4.2.3 Destination IP Port 101
© ip.access Ltd
CONTENTS PAGE
4.2.4 Source IP Port 101

4.2.5 IP Speech Mode 102
4.2.6 Source IP Address 103
4.2.7 RTP Payload Type 103
4.2.8 Connection Statistics 103
4.2.9 BS Power 104
4.2.10 Physical Context 104
4.2.11 Uplink Measurements 105
4.2.12 Message Discriminator 105
4.2.13 Message Type 105
4.2.14 Cause 106
4.2.15 MS Power Parameters 106
4.2.16 BS Power Parameters 107
4.2.17 Pre-processing Parameters 108
4.2.18 Pre-processed Measurements 108
4.2.19 Handover Candidate Parameters 109
4.2.20 Connection Id 109
4.2.21 RTP CSD Format 110
4.2.22 Channel Number 110
4.2.23 Resource Information 111
4.2.24 Paging Load 111
4.2.25 RTP Jitter Buffer Control 111
4.2.26 RTP Compression Control 112
4.2.27 RTP Payload Type 2 113
4.2.28 Channel Mode 113
4.2.29 Multiplex Control 114
4.2.30 Multiplex Connection ID 114
4.2.31 SRTP Configuration 114
4.2.32 BSC Proxy UDP Port 115
4.2.33 BTS Multiplexer Keep Alive Timeout 115
© ip.access Ltd
CONTENTS PAGE
4.3 08.58 Message Embedded Information Elements 115

4.3.1 RXLEV Embedded Information Element 115
4.3.2 RXQUAL Embedded Information Element 115
4.3.3 Frequency Error Embedded Information Element 116
4.3.4 Frame Timing Error Embedded Information Element 116
4.3.5 Measurement Averaging Configure 116
4.3.6 BS Power Control Thresholds 117
4.3.7 MS Power Control Thresholds 117
4.3.8 Handover Thresholds 117
4.3.9 NCell Defaults 118
4.3.10 NCell List 118
4.3.11 PC Threshold Comparators 119
4.3.12 HO Threshold Comparators 120
4.3.13 Handover Cause 120
4.3.14 Handover Candidates 121
4.3.15 NCell BA-list Change List 121
4.3.16 Number of MSs 122
4.3.17 Handover Candidates Extension 122
4.3.18 NCell Defaults Extension 123
4.3.19 NCell List Extension 124
4.3.20 Master Key 125
4.3.21 Master Salt 125
5 USER TRAFFIC MESSAGES 126

5.1 RTP Traffic Packet Format 126
5.1.1 RTP Header 126
5.1.2 Spare 127
5.1.3 Spare 127
5.1.4 Spare 127
5.2 Spare 127
© ip.access Ltd
CONTENTS PAGE
5.3 Spare 127

5.4 Spare 127
5.5 TRAU-like Payloads 127
5.6 Non-TRAU Payloads 127
5.6.1 FR Speech 128
5.6.2 EFR Speech 128
5.6.3 HR Speech 128
5.6.4 Idle Speech 129
5.6.5 Data/16kbps 129
5.6.6 Extended Data/16kbps 129
5.6.7 Idle Data 129
5.6.8 Data/8kbps 130
5.6.9 FR O&M 130
5.6.10 HR O&M 130
5.6.11 AMR Speech 130
5.7 TRAU within the BTS 131
5.7.1 RA2 - Intermediate Rates and Sub-Channels 132
5.7.2 RA1 - Transparent and Non-Transparent services at
14.4kb/s 132
5.7.3 RA1/RA1’ - Transparent and Non-Transparent services at
9.6kb/s 132
5.7.4 RA1/RA1’ - Transparent and Non-Transparent services at
4.8kb/s 132
5.7.5 RA1/RA1’ - Transparent services at 2.4kb/s and below 132
5.8 IWF-free BTS-BTS data 133
5.8.1 Transparent Services 133
5.8.2 Non-Transparent Services 133
6 PROCEDURES 134
6.1 Channel Establishment procedures 134
6.1.1 Primary OML Establishment 134
© ip.access Ltd
CONTENTS PAGE
6.1.2 RSL Establishment 135

6.1.3 Traffic Channel Establishment 136
6.1.4 Secondary OML Establishment 137
6.1.5 Rules on Usage of Primary and Secondary OML 137
6.2 Spare 138
6.3 Error Handling 138
6.3.1 Message Errors 138
6.3.2 Stream Connectivity Loss and Recovery 139
6.3.3 Loss of Primary OML 140
6.3.4 Loss of RSL 140
6.3.5 Channel and PDCH Activation and Release errors 140
6.4 Usage of Stream Ids in A-bis 141
6.5 NWL Test Procedures 141
6.5.1 General interaction with normal operation 142
6.5.2 Channel Usage Test 142
6.5.3 BCCH Channel Usage Test 143
6.5.4 Frequency Synchronisation Test 143
6.5.5 BCCH Information Test 143
6.5.6 Beacon Transmit Test 144
6.5.7 SysInfo Monitor Test 144
6.5.8 BCCH and CCCH Monitor Test 144
6.6 Code Download Procedures 145
6.6.1 12.21-based Code Download 145
6.6.2 TFTP Code Download 145
6.7 Management States 145
6.7.1 Operating normally 146
6.7.2 Administratively LOCKED 146
6.7.3 Operationally DISABLED 148
6.7.4 Administratively SHUTTING DOWN 148
6.8 Object Initialisation, Creation and Deletion 149
© ip.access Ltd
CONTENTS PAGE
6.8.1 Initialisation 149

6.8.2 Creation 149
6.8.3 Deletion 149
6.8.4 Set and Get Attributes during initialisation 150
6.8.5 Procedures during initialisation 150
6.9 Object Versions 150
6.10 Measurement Pre-Processing 151
6.11 Performance Management Measurements 152
6.12 Downlink DTX 153
7 SPARE 155
8 ASSIGNED NUMBERS 156

8.1 Port Numbers 156
8.2 Payload Type 156
© ip.access Ltd
1 INTRODUCTION
1.1 Overview
This document specifies the A-bis over IP interface used by the BTS which communicates
using IP to the BSC and the rest of the core PLMN rather than the traditional E1 or nx64
circuits.
1.2 Purpose
The document is intended for designers of the IP-capable BTS and the BSC.
1.3 Scope
The document refers to GSM specifications for message formats of messages which are
identical to the GSM requirements, and includes the definitions of proprietary messages or
customisations. It also defines those areas which do not conform to the GSM
specifications.
This document does not include details of the internal design and implementation of the
BTS.
1.4 Deployment Scenarios
A. This A-bis over IP interface has been designed to support local VoIP traffic
switching, by including media route control messages at connection establishment time. It
may be used with both Circuit BSC and local VOIP traffic switching (by switching the
media streams to the Circuit gateway rather than another BTS).
1.5 Terminology
Standard GSM terminology may be found in [GSM 01.04].
1.6 References
[SIG-IP] Signalling over IP, Neil Piercy.
[TIPHON-GSM] Using GSM speech codecs within ITU-T Recommendation H.323, ETSI
TIPHON TS 101318 v1.1.1.
[MUX-FD] RTP Multiplexing Feature Definition
[SRTP-FD] Secure A-bis RTP Traffic Feature Definition
[SSL-FD] SSL Secured OML and RSL Feature Definition
© ip.access Ltd
-1-
The following GSM/3GPP references are the GSM/3GPP specifications which were the
Release 1999 specifications. Where no Release 1999 specification has been produced,
the latest version of the last Release is referred to. Following standard GSM/3GPP
practice, no version numbers are specified, as the latest version shall be used unless
otherwise stated.
[GSM 08.52] Base Station Controller – Base Transceiver Station (BSC-BTS) Interface –
Interface Principles, ETSI TS 100 593 Release 1999.
Layer 2 Specification, ETSI TS 100 595 Release 1999.
Layer 3 Specification, ETSI TS 100 595 Release 1999.
[GSM 12.21] Network Management (NM) procedures and messages on the A-bis
Interface, ETS 300 623 Release 1996.
[PM] SRx.y Measurement Definitions, SR-specific CENGxxxx (supplied with

System Release documentation), Neil Piercy, ip.access Ltd.
[ALARMS] Alarm Specification XML.
© ip.access Ltd
-2-
2 CHANNELS
The A-bis over IP interface essentially replaces the logical channels carried over the A-bis
physical and LAPD data link layers of [GSM 08.52] and [GSM 08.56] by a set of
corresponding channels carried over IP using [SIG-IP]. The layer 3 A-bis messages
defined in [GSM 08.58] and [GSM 12.21] carried over the Radio Signalling Link (RSL) and
the Operations and Maintenance Link (OML) respectively are unchanged except as
defined in this specification.
All multi-octet fields defined in this specification shall be sent in network byte order.
All Reserved fields shall be transmitted as zero.
2.1 Physical Layer
The 2048kb/s or 64kb/s physical channels specified in [GSM 08.52] shall be replaced by a
single IP interface. The physical interface carrying this IP interface may be any suitable
interface, including:-
• Ethernet
• ISDN BRI or PRI carrying PPP
The manner in which the IP address of the physical interface(s) is assigned may be
controlled by the O&M messages within this specifications.
2.2 Layer 2 Signalling
The set of one or more SAPI=63 Layer 2 Management Links to each TRX and optionally
the BCF, as defined in [GSM 08.56] shall not be used.
The set of one or more SAPI=62 Operations and Maintenance Links to each TRX and
optionally the BCF, as defined in [GSM 08.56] shall be replaced by a single stream
between the BTS and the BSC.
The set of one or more SAPI=0 RSL links to each TRX distinguished by TEI, as defined in
[GSM 08.56] shall be replaced by a single stream between each TRX in the BTS and the
BSC.
Details of the transport connections which may be used to carry the signalling message
streams are given in [SIG-IP].
2.3 Traffic
The set of 8kb/s, 16kb/s, or 64kb/s traffic channels between each TRX and the BSC
carrying the user traffic in TRAU frames shall be replaced by one or more UDP streams.
© ip.access Ltd
-3-
These UDP streams are conformant to RTP, and carry a payload of a single channel
traffic streams. Alternatively multiple RTP streams may be combined into a single RTP
stream as specified in [MUX_FD].
These RTP streams are configured at connection setup by extensions to [GSM 08.58].
2.4 Signalling Message Transports
The Signalling messages may be carried by any suitable pre-agreed IP-based transport
between the BSC and the BTS. The requirements placed on the transport are primarily:
• Reliable transport: messages shall be reliably delivered, or a break in the

signalling link detected and reported.
• In sequence transport: the messages belonging to a single stream shall be
delivered in the order of transmission.
• Stream identification to distinguish between the OML and the RSL messages to
each TRX.
Secondary requirements on the transport are:
• Security: it should be possible to authenticate and encrypt the transport link –

details of this beyond the scope of this specification, as they are common to all
GSM IP-based links, and dependent on the security level required by the operator.
• Congestion and flow control: the signalling channel should be well behaved in the
presence of network congestion, and should not cause or prolong of congestion.
This requirement should be viewed in the light of the VoIP traffic requirement
which is generally intolerant of congestion, and will normally flow between the
same endpoints.
The manners in which currently defined transports are used to carry the Signalling
messages are described in [SIG-IP]. It is envisaged that any given BTS or BSC will be
configured (e.g. in a software image) to be only capable of supporting one of these
transports.
2.4.1 Framed TCP Transport
The A-bis interface may use the Framed TCP transport of [SIG-IP] in place of the OMLs
and RSLs.
The stream identifier is used to distinguish between the various logical links: different
stream identifiers are used for OML messages, and for the RSL messages to the different
TRXs.
The framed TCP transport shall use of the Identification procedure at connection
establishment in order to allow the connection server to determine the type and identity of
the unit initiating the connection, and thence the type of connection. In the case of the
Primary OML, the Unit Id shall be the Unit Id of the Site Manager object (see 3.3.17). In
© ip.access Ltd
-4-
the case of the RSL, the Unit Id shall be that of the Baseband Transceiver object
associated with the RSL.
The framed TCP transport at the BTS should use the heartbeat procedure (see [SIG-IP])
to ensure detection by the BTS of the loss of communication with the BSC. The BSC may
use the same procedure to enable notification to the O&M system of loss of
communications with the BTS.
The maximum value of the Connection Frame Length shall be [273].
OML messages and RSL messages should be carried over separate TCP connections,
but may be carried over a single TCP connection.
2.4.2 SCTP
SCTP may be used to carry the signalling messages. The OML and RSL messages shall
be carried by a single SCTP transport service. The OML messages and the RSL
messages to each TRX shall be carried on different SCTP streams, as identified by the
assigned Stream Identifier.
2.4.3 UDP Transport
The BTS should support the UDP transport of [SIG-IP] only for the Identification procedure
(see [SIG-IP]). It should support the receipt of broadcast or unicast Identity Request
messages and reply with an appropriate unicast Identity message to the sender of the
request.
© ip.access Ltd
-5-
3 O&M SIGNALLING MESSAGES
The OML messages shall be as defined in [GSM 12.21], subject to the manufacturer
dependencies and defined in this specification.
All attributes in messages shall be transmitted in the order specified in the message
definition tables below.
3.1 Unsupported O&M messages
The following O&M messages defined in [GSM 12.21] are not supported:
Establish TEI
Connect Terrestrial Signalling
Disconnect Terrestrial Signalling
Connect Terrestrial Traffic
Disconnect Terrestrial Traffic
Connect Multi-Drop Link
Disconnect Multi-Drop Link
Support for all other messages by any particular IP BTS release is as determined by its
Technical Specification.
In addition, the Get Attributes Response message was not specified in earlier versions of
[GSM 12.21], and is supported only in the modified format specified below.
3.1.1 Unsupported O&M Attributes
The following O&M attributes defined in [GSM 12.21] are not supported:
A-bis Channel
Multi-drop BSC Link
Multi-drop next BTS Link
TEI
3.2 Manufacturer-Defined O&M Messages
The following manufacturer-defined messages shall be carried in messages formatted

according to [GSM 12.21 section 8.1.4]. Each of these messages requires a response by
an Ack or a Nack. The procedures used in the handling of these messages shall be as in
© ip.access Ltd
-6-
[GSM 12.21 section 6.1], and the format of the Ack and Nack messages shall be as
described for the formatted O&M messages in [GSM 12.21 section 8.2].
The values of the ManId Length Indicator and Manuf. Indicator fields shall be:
ManId Length Indicator: 13 (decimal)

Manuf. Indicator: “com.ipaccess”
NOTE: the Manuf. Indicator is coded as a NULL-terminated ASCII coded string of length
13 characters including the terminating NULL.
3.2.1 Connect IP Signalling
NOTE: This message is being replaced by the use of Set Attributes message.
This message is used to provision an RSL to carry the 08.58 messages (c.f. [GSM 12.21
section 8.4.2], Connect Terrestrial Signalling), and assign the Stream Identifier (c.f. [GSM
12.21 section 8.4.2]) associated with a Baseband Transceiver.
Information Element Ref Presence Format Length

Manufacturer-Defined Message Type 3.3.1 M V 1
Object Class 3.4.22 M V 1
Object Instance 3.4.23 M V 3
Stream Identifier 3.3.8 M TV 2
Destination IP Address 3.3.3 O TV 5
Destination IP Port 3.3.4 O TV 3
The Object Class shall be “Baseband Transceiver”, and the Object Instance shall include
a NULL Radio Timeslot Number, and non-NULL other octets. If the IP Address and/or IP
Port are omitted, the BTS shall open a new channel to the same IP address and/or IP Port
as was originally used to open the channel carrying the OML stream being used for the
Baseband Transceiver. If the port is specified to be the well-known secure RSL port then
this instructs the BTS to attempt a secure connection. Any other value of port is an
instruction to use an insecure RSL connection.
If the BTS is instructed to use more signalling links than it can support it should Nack the
message.
3.2.2 Disconnect IP Signalling
NOTE: This message is being replaced by the use of Set Attributes message.
This message is used to de-provision an RSL (c.f. [GSM 12.21 section 8.4.3], Disconnect
Terrestrial Signalling).
© ip.access Ltd
-7-
Stream Identifier 3.3.8 M TV 2
The Object Class shall be “Baseband Transceiver”, and the Object Instance shall include
a NULL Radio Timeslot Number, and non-NULL other octets. The IP Address and/or IP
Port should only be included if the signalling stream is not using the same IP address
and/or IP Port as is being used to carry the OML stream.
3.2.3 Spare
3.2.4 Spare
3.2.5 Spare
3.2.6 Set NV Attributes
This message is used to set non-volatile configuration attributes for the specified object. It
does not modify the attribute value currently in use if the modification of such attributes in
use requires a reset of the object (see individual attribute descriptions for details).
© ip.access Ltd
-8-
NV Config Flags 3.3.9 O TLV >=4
Frequency Control 3.3.10 O TV 3
Primary OML Config 3.3.11 O TV 7
Primary OML Config List 3.3.21 O TLV >=3
Primary OML Fallback Timeout 3.3.22 O TLV 7
Secondary OML Config 3.3.11 O TV 7
IP Interface Config 3.3.12 O TV 9
IP Gateway Config 3.3.13 O TV 13
Location 3.3.15 O TLV >=3
Unit Id 3.3.17 O TLV >=3
Unit Name 3.3.19 O TLV >=3
SNMP Config 3.3.20 O TLV >=3
Current SW Configuration 3.3.23 O TLV >=10
Alarm Threshold List 3.3.36 O TLV >=3
Timing Bus Control 3.3.38 O TLV 4
SSL Configuration 3.3.45 O TLV 3
There may be one or more NV attribute Information Elements included in the message.
Unless otherwise specified, there is a single NV storage for each NV attribute per BTS
Equipment, independent of the object class(es) or object instance(s) hosted on that
equipment. The effect of this is that a SET NV ATTRIBUTES of an attribute shall change
this attribute for all objects and instances hosted on that BTS Equipment. See table below
for details of storage instances.
Changes to the NV attributes may take effect immediately, but many of the attributes only
control the startup behaviour of the BTS Equipment and/or objects. The table below
describes when the changes take effect.
© ip.access Ltd
-9-
Attribute Takes Effect Storage instances
NV Config Flags See 3.3.9 1 per equipment
Frequency Control Immediate 1 per equipment
Primary OML Config Next connection attempt 1 per equipment
Primary OML Config List Next connection attempt 1 per equipment
Primary OML Fallback Timeout Next connection attempt 1 per equipment
Secondary OML Config Immediate 1 per equipment
IP Interface Config Next reboot 1 per equipment
IP Gateway Config Next reboot 1 per equipment
Location Immediate 1 per equipment
Unit Id Next reboot 1 per equipment
Unit Name Immediate 1 per equipment
SNMP Config Next reboot 1 per equipment
Current SW Configuration Next reboot 1 per equipment
Alarm Threshold List Immediate 1 per equipment
Timing Bus Control Immediate 1 per Equipment
SSL Configuration Next reboot 1 per equipment
3.2.7 Get NV Attributes
This message is used to get the specified non-volatile configuration attributes for the
specified object. It does not get the attribute value currently in use if that value may be
different from the value stored in non-volatile storage (i.e. the NV value is only used at
boot time - see individual attribute descriptions for details).

List of Required Attributes 3.4.8 M TLV >=3
The List of Required Attributes may only include:

• attribute identifiers which may be included in the Set NV Attributes message for
the corresponding object
• the In Service Time attribute identifier
The addressed object shall include the requested attributes as separate Attributes in the
Get NV Attributes Response message which is sent in response to this message. This
Response message should not include the List of Required Attributes attribute, but shall
include the Get Attributes Response Info attribute if any of the requested attributes cannot
be included in the Response (c.f. Get Attributes Response 3.6.9). It shall therefore be of
the following format:
© ip.access Ltd
- 10 -
Any Reported Attribute C
: :
Get Attributes Response Info 3.4.25 C TLV >=4
3.2.8 Set Attributes
This message is used to set volatile configuration attributes for the specified object. It may
be used to configure all objects except the BTS, Radio Carrier or Channel objects, which
have standard 12.21 class-specific Set * Attribute messages. The optional attributes listed
below may be conditionally included in the message if the object to which the message is
addressed supports the relevant attributes – see section 3.8. For clarity, the following
subsections show the supported optional attributes in the Set Attributes message for each
supported object class.
The Object Version may only be set prior to the OpStart of the object.
3.2.8.i Set Attributes to the Site Manager

Object Version 3.3.27 O TLV >=3
Heartbeat Timeout 3.3.42 O TLV 6
The Heartbeat Timeout configures the period of inactivity on the Primary OML before the
BTS sends a Signalling over IP Heartbeat message – see [SIG-IP].
3.2.8.ii Set Attributes to the Baseband Transceiver

Stream Identifier 3.3.8 O TV 2
Heartbeat Timeout 3.3.42 O TLV 6
© ip.access Ltd
- 11 -
Modification of the Stream Identifier, Destination IP Address or Destination IP Port values
shall result in the disconnection of the existing RSL (if any), and, if the Stream Identifier is
a valid non-NULL value, shall cause the connection of the RSL with the new parameters.
If the Destination IP Address and/or Destination IP Port are NULL, the BTS shall open the
channel for the RSL to the same IP address and/or IP Port as was originally used to open
the channel carrying the OML stream being used for the Baseband Transceiver. If the
BTS is instructed to use more signalling links than it can support it should Nack the
message.
The Heartbeat Timeout configures the period of inactivity on the RSL before the BTS
sends a Signalling over IP Heartbeat message – see [SIG-IP].
3.2.8.iii Set Attributes to the GPRS NSE

NSEI 3.3.29 O TLV 5
NS Configuration 3.3.32 O TLV 10
BSSGP Configuration 3.3.33 O TLV 14
3.2.8.iv Set Attributes to the GPRS Cell

RAC 3.3.26 O TLV 4
GPRS Paging Configuration 3.3.28 O TLV 5
BVCI 3.3.30 O TLV 5
RLC Configuration 3.3.35 O TLV 11
Coding Scheme Control 3.3.40 O TLV 5
RLC Configuration 2 3.3.41 O TLV 8
RLC Configuration 3 3.3.44 O TLV 4
© ip.access Ltd
- 12 -
3.2.8.v Set Attributes to the GPRS NSVC

NSVCI 3.3.31 O TLV 5
NS Link Configuration 3.3.34 O TLV 11
3.2.9 Attribute Value Change Event
This message is used to notify the manager that the listed attributes for the specified
object have been changed as a result of intervention by another management agent (e.g.
local craft terminal), have changed autonomously as a result of internal processes (e.g. In
Service Time) or as a by-product of another management procedure (e.g. a software
download may change the SW Configuration attribute). It should not be sent to a manager
which caused the change using a Set (*) Attributes or Set NV Attributes – these should be
acknowledged in the normal manner.

Any supported attribute M
Any supported attribute O
The message should contain all the attributes which have changed, just as the relevant
Acknowledge message does for attributes which changed as a result of a Set (*)
Attributes message.
Changes to all attributes listed in section 3.8 for the relevant objects shall be have
changes notified, with the following exceptions:
GSM Time
Site Inputs
Operation State (#)
Availability Status (#)
Administrative State (#)
NOTE: The state and status attributes marked (#) have their changes notified using the
State Changed Event Report.
© ip.access Ltd
- 13 -
3.2.10 SW Deactivate
This message is used to return the object to its start up state (i.e. Operational State
Disabled, Availability Status Not Installed). Note that the object may automatically attempt
SW Activation by issuing a SW Activate Request.

The effect of this message shall be as if the object was Administratively LOCKED and
then returned to its start up state, as described above. This message may be sent when
the object is in any state, subject only to the normal rule of a single Elementary Procedure
– see 12.21 v5.0.0 section 6.1.
3.3 O&M Signalling Attributes
The custom Attributes used in the O&M signalling messages are defined below.
3.3.1 O&M Manufacturer-Defined Message Type
Manufacturer-Defined Message Type 1
The Manufacturer-Defined Message Type octet used in the O&M messages is coded with
the following hexadecimal values:
Start Measurement Ack 0xDE

Stop Measurement Ack 0xDF
Connect IP Signalling 0xE0
Connect IP Signalling Ack 0xE1
Connect IP Signalling Nack 0xE2
Disconnect IP Signalling 0xE3
Disconnect IP Signalling Ack 0xE4
Disconnect IP Signalling Nack 0xE5
Reserved 0xE6
Reserved 0xE7
Reserved 0xE8
Reserved 0xE9
Reserved 0xEA
Reserved 0xEB
Reserved 0xEC
Reserved 0xED
Reserved 0xEE
Set NV Attributes Req 0xEF
Set NV Attributes Ack 0xF0
© ip.access Ltd
- 14 -
Set NV Attributes Nack 0xF1
Get NV Attributes Req 0xF2
Get NV Attributes Response 0xF3
Get NV Attributes Nack 0xF4
Set Attributes Req 0xF5
Set Attributes Ack 0xF6
Set Attributes Nack 0xF7
Attribute Value Change Event 0xF8
SW Deactivate 0xF9
SW Deactivate Ack 0xFA
SW Deactivate Nack 0xFB
Measurement Result Request Nack 0xFC
Start Measurement Nack 0xFD
Stop Measurement Nack 0xFE
3.3.2 O&M Manufacturer-Defined Attribute Identifiers
The Manufacturer-Defined Attribute Identifier octet used in the O&M messages is coded
with the following hexadecimal values:
Destination IP Address 0x80

Destination IP Port 0x81
Reserved 0x82
Reserved 0x83
Reserved 0x84
Stream Identifier 0x85
NV Config Flags 0x86
Frequency Control 0x87
Primary OML Config 0x88
Secondary OML Config 0x89
IP Interface Config 0x8a
IP Gateway Config 0x8b
In Service Time 0x8c
Reserved 0x8d
Location 0x8e
Paging Configuration 0x8f
File Data 0x90
Unit Id 0x91
Reserved 0x92
Unit Name 0x93
SNMP Config 0x94
Primary OML Config List 0x95
Primary OML Fallback Timeout 0x96
Current SW Configuration 0x97
Timing Bus 0x98
CGI 0x99
RAC 0x9a
© ip.access Ltd
- 15 -
Object Version 0x9b
GPRS Paging Configuration 0x9c
NSEI 0x9d
BVCI 0x9e
NSVCI 0x9f
NS Configuration 0xa0
BSSGP Configuration 0xa1
NS Link Configuration 0xa2
RLC Configuration 0xa3
Alarm Threshold List 0xa4
Monitored Value List 0xa5
Timing Bus Control 0xa6
Supported Features 0xa7
Coding Schemes 0xa8
RLC Configuration 2 0xa9
Heartbeat Timeout 0xaa
Up Time 0xab
RLC Configuration 3 0xac
SSL Configuration 0xad
Security Possible 0xae
IML SSL State 0xaf
Revocation Date 0xb0
3.3.3 Destination IP Address
Manufacturer-Defined Attribute Identifier 1

Destination IP Address 2-5
The Destination IP Address shall be NULL if the value is set to 0.0.0.0.
3.3.4 Destination IP Port

Destination IP Port 2-3
The Destination IP Port shall be NULL if the value is set to 0.
3.3.5 Spare
3.3.6 Spare
3.3.7 Spare
© ip.access Ltd
- 16 -
3.3.8 Stream Identifier

Stream Identifier 2
The Stream Identifier shall be coded with one octet, and shall identify the stream used to
carry messages in both directions on the A-bis link.
The values used for the Stream Identifier shall be:
0..31 RSL message Streams (assigned by the BSC)

128 NULL
129..253 Reserved
254 Control Channel message Stream
255 OML message Stream
3.3.9 NV Config Flags
This is an NV attribute with the following format:
8 7 6 5 4 3 2 1
Length (2N) 2-3
F8 F7 F6 F5 F4 F3 F2 F1 4
M8 M7 M6 M5 M4 M3 M2 M1 5
. . . . . . . . .
F(8N) F(8N-1) F(8N-2) F(8N-3) F(8N-4) F(8N-5) F(8N-6) F(8N-7) 2N+2
M(8N) M(8N-1) M(8N-2) M(8N-3) M(8N-4) M(8N-5) M(8N-6) M(8N-7) 2N+3
This attribute defines the value of one or more of the NVRAM configuration flags, which
are in the Site Manager object. It is used by the OMC in a Set NV Attributes Req to set
one or more flags (Fi), with a mask bit (Mi) for each flag bit defining whether that flag is
being modified or not. It is used by the BTS in a NV Get Attributes Ack to report the states
of the flag bits, with the mask bits defining which flag bits have valid values and usage in
the BTS.
In both cases the length field defines the number of octets following, which shall be a
multiple of 2. Each pair of octets defines 8 flag bits and their mask bits.
The Mi bits define whether the corresponding Fi bits are being set or not, and if they are,
the Fi bit determines the value being set. The possible value combinations and their
meaning are thus:
© ip.access Ltd
- 17 -
Mi Fi Set Meaning Get Ack Meaning
0 0 Flag(i) unaltered Flag(i) unknown/invalid
0 1 Reserved Reserved
1 0 Flag(i) Disabled Flag(i) Disabled
1 1 Flag(i) Enabled Flag(i) Enabled
The flags and their meanings are:
Flag Name Behaviour when Enabled Behaviour when Disabled

F1 Static IP Interface The current IP Interface config The current IP Interface
Config in NV cannot be altered by Config in NV may be altered
DHCP by DHCP
F2 Static IP Gateway The current IP Gateway config The current IP Gateway
Config in NV cannot be altered by config in NV may be altered
DHCP by DHCP
F3 Static VSI Config The current Config in NV The current Config in NV
cannot be altered by DHCP may be altered by DHCP VSI
VSI
F4 DHCP The DHCP process occurs at The DHCP process does not
boot occur at boot
F5 Reserved
F6 Reserved
F7 LED The LED indicates status of The LED is disabled
the BTS
F8 Reserved
F9 Secondary OML The BTS should allow The BTS should not allow
Enable connections to the secondary connections to any of the
OML port. secondary OML ports.
F10 Diag Enable The BTS should allow The BTS should not allow
(Manufacturer use connections to the Diagnostics connections to the
only) port Diagnostics port
F11 CLI Enable The BTS should allow The BTS should not allow
(Manufacturer use connections to the CLI port connections to the CLI port
only)
F12 HTTP Enable The BTS should enable the The BTS should disable the
(Manufacturer use HTTP server HTTP server
only)
F13 POST Enable The BTS should enable The BTS should disable
Power-On SelfTest Power-On SelfTest
F14 SNMP Enable The BTS should enable SNMP The BTS should disable
support SNMP support
Notes:
1) There is interaction between some flags (e.g. the setting of the Static VSI
Config flag is irrelevant to BTS behaviour if the DHCP flag is disabled).
© ip.access Ltd
- 18 -
2) Attempting to set a flag which will result in improper operation (e.g.
disabling DHCP when there is no valid IP Interface Config and IP Gateway
Config in the NVRAM) shall be NACKed, and no flags updated.
3) Flags F1-F4 changes only take effect at the next boot time. Their NV
values are those that would be used at the next reboot. All other non-
reserved flags take immediate effect, and their current values should
always be equal to their NV values. Note that some flags (e.g. F9-F13) may
only affect the ability of the BTS to accept new connections over the
specified services, and may not terminate any existing connections.
4) The behaviour of some flags may be overridden (e.g. in special operational
modes) – these are detailed in the sections describing the usage of the
flags.
5) Modifying a reserved flag shall be allowed, and have no effect other then in
the reporting of that flag in a Get NV Attribute Response
The default value of this attribute on an unconfigured unit shall have F4, F7, F9, F13 and
F14 enabled, and the rest disabled.
3.3.10 Frequency Control
8 7 6 5 4 3 2 1
Frequency Control (msb) 2
Frequency Control (lsb) 3
The Frequency Control value is a twos complement 16 bit integer value which represents
the last saved setting of the internal oscillator relative to its nominal value in units of parts
per billion (ppb). The Frequency Control has a nominal value of zero, and indicates the
feedback or control applied to keep the frequency accurate.
The Frequency Control attribute may be set through the Set NV Attributes and read by the
Get NV Attributes messages. The Frequency Control attribute may have a more restricted
range than the integer range due to hardware limitations of the object. Attempts by the
OMC to set this value beyond its capability shall be NACKed.
The default value of this NV attribute shall be set through calibration of the unit.
3.3.11 Primary and Secondary OML Config
Note: the direct use of the Primary OML Config attribute has been removed – see Primary
OML Config List attribute.
© ip.access Ltd
- 19 -
OML IP Address 2-5
OML TCP Port 6,7
The Primary OML destination configuration may be set in or read from NV storage with
this attribute embedded in a Primary OML Config List attribute – see section 3.3.21.
The Primary OML configuration is an NV attribute consisting of:

• IP Address: if configured, this is the IP Address to which the object should attempt
to connect the Primary OML. This IP address is used for both secure and insecure
connections. If unconfigured, this IP Address and TCP Port shall be ignored.
• TCP Port: if configured, this is the port to which the object should attempt to
connect the insecure Primary OML. If unconfigured, the object should attempt to
connect to the default well-known port. When attempting secure OML connections,
the TCP port number is ignored and the well-known port numbers defined in 8.1
are used instead.
The Secondary OML configuration is an NV attribute consisting of:

• IP Address: if configured, this is the only IP Address allowed to connect to both the
secure and insecure secondary OML servers, otherwise there is no restriction on
the originating IP Address.
• TCP Port: if configured, this is the port on which the object should accept
connections for the insecure Secondary OML. If unconfigured, the object may still
accept connections on a default well-known port. The secure secondary OML
server ignores the TCP port number and accepts connections on the well-known
port numbers defined in 8.1 instead.
The IP Address 0.0.0.0 and the TCP Port 0 shall be used as NULL values, indicating that
the respective values are unconfigured in NV storage. These shall be the default values in
an unconfigured unit.
3.3.12 IP Interface Config

IP Address 2-5
Subnet Mask 6-9
This attribute carries the basic IP configuration for the object IP interfaces.
The value 0.0.0.0 shall indicate a NULL IP Address or Subnet Mask. A NULL Subnet
Mask shall indicate use of the standard Class A, B or C network masks, as indicated by
the IP Address. These shall be the default values in an unconfigured unit.
© ip.access Ltd
- 20 -
3.3.13 IP Gateway Config

Network Address 2-5
Subnet Mask 6-9
Gateway Address 10-13
This attribute carries the basic IP configuration for the object IP routing tables.
The value 0.0.0.0 shall indicate a NULL Network Address, Subnet Mask or Gateway
Address. A NULL Network Address may be used to configure the Default Gateway. A
NULL Subnet Mask shall indicate use of the standard Class A, B or C network masks, as
indicated by the Network Address. Setting a NULL Gateway address may be used to
delete a routing table entry. A Get NV Attributes which requests this attribute should be
replied to with a set of these IEs, one for each current table entry.
The NULL values shall be the default values in an unconfigured unit.
3.3.14 In Service Time

In Service Time 2-5
This attribute carries the total cumulative time (in hours) that the module which hosts the
object has been operating.
This attribute may not be set using Set NV Attributes, and has the initial value zero at
manufacture, but no default value.
3.3.15 Location

Length (L) 2-3
Location 4-(L+3)
This attribute carries the free format ASCII text string describing the physical location of
the object. It is for O&M information only, and is not used within the object except in the A-
bis messages. The maximum length of the string may be limited by object capabilities.
The default value of this attribute in an unconfigured unit shall be the NULL (empty) string.
© ip.access Ltd
- 21 -
3.3.16 Paging Configuration

Paging Repeat Time 2
Paging Repeat Count 3
This attribute of the BTS object carries the Paging configuration used by the BTS. The
Paging Repeat Time is in units of a 51 frame multiframe (235.4ms). The valid ranges for
these parameters are defined below. If this configuration is not supplied, the BTS should
use default values below.
Default Min Max

Paging Repeat Time 16 0 127
Paging Repeat Count 0 0 4
The Paging Repeat Time of zero is only valid if the Paging Repeat Count is also zero.
3.3.17 Unit Id

Length (L) 2-3
Unit Id 4-(L+3)
This attribute carries the Unit Id of the object. It is a NULL-terminated ASCII string of the
form “a/b/c”, where the numerical values a, b and c determine the objects which are
hosted on the hardware unit, and their instance addresses. The NULL value may be
represented by omission of a value, e.g. “a//c” has a NULL value for the middle
component of the Unit Id.
This general representation in this version of the A-bis interface is used as follows. The
three components are “siteId/btsId/trxId”. All objects contained within the same Site
Manager have the same “siteId”. All objects contained within the same BTS have the
same “siteId/btsId”. The trxId is the identifier of the Baseband Transceiver, Radio Carrier
objects. A unit which has a NULL value for a component Id does not host an instance of
that object, e.g. “125//” denotes a unit which hosts Site Manager instance 125, but does
not host any BTS or baseband transceiver, radio carrier or channel objects. A unit which
has a zero for a component Id hosts the zero instance of that object as well as the
instance of the containing object, e.g. “125/1/0” denotes a unit which hosts BTS 1 in Site
125, as well as hosting TRX 0, and “125/0/0” denotes a unit which hosts the Site Manager
and BTS 0 of Site 125 as well as TRX 0 of that BTS and Site.
The valid range of values for the siteId is determined by the [GSM 12.20] object model, in
which it is an ASN.1 Integer, but in this specification it is restricted to the smaller range of
© ip.access Ltd
- 22 -
0…65534. The valid range of values for the btsId and trxId is determined by the GSM
12.21 Object Instance numbers, and is 0…254.
Note: The UnitId value of an object gives the UnitId of the hardware unit which provides
the object’s functionality. As such, several objects may have the same UnitId value.
Changing the UnitId of an object through the Set NV Attributes may therefore affect the
UnitId and behaviour of several objects.
The default value of this attribute in an unconfigured unit which can support any of the
objects shall be the value “//0”, which is a special case value which does not attempt
connection of the Primary OML nor attempt connection to any BTS or Site Manager host
unit. It does however contain instances of the Baseband Transceiver, Radio Carrier and
Channel objects, and if connected to over the secondary OML, it shall attempt SW
Activation of the these objects. It allows the normal messages and procedures to these
objects both prior to SW Activation (see 6.8.4 and 6.8.5), specifically those which allow
the NV configuration to be modified, and after SW Activation (if successfully completed).
3.3.18 Spare
3.3.19 Unit Name

Length (L) 2-3
Unit Name 4-(L+3)
This attribute carries the Unit Name of the object. It is a NULL terminated ASCII string.
The default value of this attribute in an unconfigured unit shall be the NULL (empty) string.
3.3.20 SNMP Config

Length (L) 2-3
Embedded Information Element 4-…
… …
Embedded Information Element …-(L+3)
This attribute carries the SNMP configuration of the object. It carries a set of Embedded
Information Elements with the various details of the SNMP Configuration. The Embedded
Information Elements which may be included in this attribute are:
© ip.access Ltd
- 23 -
SNMP Community String
SNMP Trap Address
SNMP Trap Port
SNMP Manager Address
SNMP System Contact
The OMC shall include in a Set NV Attributes any Embedded IEs which it wishes to
modify, omitting any which it wishes to leave at their current values.
The BTS shall include in a Get NV Attributes all the Embedded IEs which it supports,
including those which have a NULL value.
The default value of this attribute in an unconfigured unit shall be the defaults specified for
the embedded IEs.
3.3.21 Primary OML Config List
Note: this attribute supersedes the direct use of the Primary OML Config attribute, which
only allows the carrying of a single set of IP Address and port – see section 3.3.11.

Length (7N) 2-3
Primary OML Config 4-12
:
7N-3,
Primary OML Config
7N+3
The list of Primary OML destination configurations may be set in or read from NV storage
with this attribute. A Set NV Attributes containing this attribute shall cause the current list
in NV to be completely replaced.
The default value of this attribute in an unconfigured unit shall be the empty list.
Each primary OML Config entry specifies the IP address and port used to open an
insecure primary OML connection. When attempting secure primary OML connections,
the BTS replaces the configured port with the well-known port specified in 8.1. Note that it
is not possible to configure or update the secure primary OML port.
3.3.22 Primary OML Fallback Timeout
© ip.access Ltd
- 24 -
Length (2) 2-3
Primary OML Fallback Timeout 4-5
This attribute carries the Primary OML Fallback Timeout value as a binary value in
seconds. This controls the time before the attempts to connect to the current Primary OML
IP address are abandoned, and attempts are made to connect to the next address in the
list. A timeout value of zero implies only a single connection attempt is made to each
address in the list before moving to the next address in the list.
The default value of this attribute in an unconfigured unit shall be zero.
3.3.23 Current SW Configuration
This attribute has an identical format to the SW Configuration attribute of [GSM 12.21
v5.0.0 section 9.4.61], but lists the actual SW Descriptions of the SW which is currently
running, or has been run to provide the current functionality of the object (e.g. includes
any SW Descriptions of any Boot Code used by the equipment hosting the object). It is the
active subset of the SW Configuration attribute for the object.
Prior to completion of SW Activation, the Current SW Configuration shall include the SW

Descriptions for all software which is currently executing, on which the object will be
dependent, independent of the choice of SW Descriptions presented during SW
Activation, or has been executed to achieve the current state (e.g. should include SW
Description for any Boot Code).
It may also be addressed as an NV attribute, where it controls the default Current SW

Configuration which will take effect at the next reinitialisation of the unit hosting the
object(s).
In a Set NV Attributes, it may contain a single SW Description for each type of SW which
the unit hosting the object may store, and has one or more such images in store - i.e. it
may include the SW Description of any Boot SW. This shall only modify the default values
for the types of SW for which a SW Description is included, and shall leave the defaults for
all other types of SW unmodified. Each SW Description in the Current SW Configuration
shall be identical to one of the SW Descriptions in the SW Configuration for the same
object, or the Current SW Configuration shall be in error.
The response to a Get NV Attributes shall contain one SW Description for each type of
SW the unit hosting the object may store, and has one or more such images in store. The
returned Current SW Configuration shall be that which should become the Current SW
Configuration after the next reinitialisation of the unit.
The default value of this NV attribute in an unconfigured unit shall include the SW
Description of the running SW and an arbitrary choice of SW Description for any SW not
yet activated for which there is a choice.
© ip.access Ltd
- 25 -
3.3.24 Timing Bus
8 7 6 5 4 3 2 1
Length (3) 2-3
F FN V O R Active Source 4
Available Clock Sources 5
Supported Clock Sources 6
This attribute identifies the current state of the timing bus within the Site as seen by the
addressed object, and the Supported and currently Available Clock Sources.
The Timing Bus State bits are used as follows:
Bit Name 0 1
F Frame Frame pulses not received Frame pulses received
FN Frame Number Frame Number not received Frame Number received
V Valid Clock is not valid Clock is valid
O Output Control Output Control not supported Output Control supported
R Reserved Reserved Reserved
The Output Control bit indicates whether the Timing Bus output is able to be controlled
through the Timing Bus Control attribute. If output control is not supported, the Timing Bus
Control attribute is fixed at the default value.
The Supported and the Available Clock Sources fields contain a bit map of the Clock
Sources, with bit values coded as follows:
Internal OCXO 0x01

TIB Clock input 0x02
10 MHz input 0x04
The Supported Clock Sources defines those sources which the object has capability to
support. The Available Clock Sources defines those sources which are currently capable
of providing a clock.
The Active Source value identifies which of the Available Clock Sources is being used,
and is the binary value of the bit number of the Clock Sources, with 0 being the LSB and 7
the MSB.
© ip.access Ltd
- 26 -
3.3.25 CGI

Length (7) 2-3
MCC digit 2 MCC digit 1 4
MNC digit 3 MCC digit 3 5
MNC digit 2 MNC digit 1 6
LAC 7-8
CI 9-10
This attribute carries the full Cell Global Identity of the BTS. If only a 2 digit MNC is use,
MNC Digit 3 carries the value 0xf.
3.3.26 RAC

Length (1) 2-3
RAC 4
This attribute carries the GPRS Routing Area Code of the BTS.
3.3.27 Object Version

Length (L) 2-3
Object Version Number 4
: :
Object Version Number L+3
This attribute carries the list of Object Version Number supported by the object, in order of
preference of the object.
It shall be included in the SW Activated Report to allow the BSC to determine the
management capability of the object, to allow its correct configuration to be supplied. It
may be set after SW Activation and prior to opStart by its inclusion within an appropriate
Set Attributes message for the object concerned, containing a single Object Version
Number. Once set, only that value shall be returned in any subsequent Get Attributes until
the object is re-activated. If it is not set prior to opStart the object shall default to the first
Object Version Number included in the SW Activated Report.
© ip.access Ltd
- 27 -
3.3.28 GPRS Paging Configuration

Length (2) 2-3
GPRS Paging Repeat Time 4
GPRS Paging Repeat Count 5
This attribute carries the Paging configuration used by the GPRS RLC. The Paging
Repeat Time is in units of 50 ms intervals). The valid ranges for these parameters are
defined below.
Min Max
GPRS Paging Repeat Time 0 250
Paging Repeat Count 0 40
Note: the value of 0 for the above Timers is only valid if the corresponding Repeat Count
value is also zero.
3.3.29 NSEI

Length (2) 2-3
NSEI 4-5
This attribute carries the GPRS NSE Identifier.
3.3.30 BVCI

Length (2) 2-3
BVCI 4-5
This attribute carries the GPRS BVC Identifier for the PTP BVC of the Cell.
3.3.31 NSVCI

Length (2) 2-3
NSVCI 4-5
This attribute carries the GPRS NSVC Identifier.
© ip.access Ltd
- 28 -
3.3.32 NS Configuration

Length (7) 2-3
(Un)Blocking Timer 4
(Un)Blocking Retries 5
Reset Timer 6
Reset Retries 7
Test Timer 8
Alive Timer 9
Alive Retries 10
This attribute carries the configuration of the NS layer of the Gb interface (see GSM
08.16). All timers are in units of seconds. The configurational limits are as specified below.
Parameter Minimum Maximum

(Un)Blocking Timer 1 120
(Un)Blocking Retries 0 255
Reset Timer 1 120
Reset Retries 0 255
Test Timer 1 60
Alive Timer 1 10
Alive Retries 0 255
3.3.33 BSSGP Configuration

Length (11) 2-3
Blocking Timer (T1) 4
Blocking Retries 5
Unblocking Retries 6
Reset Timer (T2) 7
Reset Retries 8
Suspend Timer (T3) Units: 100ms 9
Suspend Retries 10
Resume Timer (T4) Units: 100ms 11
Resume Retries 12
Capability Update Timer (T5) 13
Capability Update Retries 14
This attribute carries the configuration of the BSSGP layer of the Gb interface (see GSM
08.18). All timers are in units of seconds unless otherwise stated. The configurational
limits are as specified below.
© ip.access Ltd
- 29 -
Blocking Timer (T1) 1 30
Blocking Retries 0 255
Unblocking Retries 0 255
Reset Timer (T2) 1 120
Reset Retries 0 255
Suspend Timer (T3) Units 100ms 1 100
Suspend Retries 0 255
Resume Timer (T4) Units 100ms 1 100
Resume Retries 0 255
Capability Update Timer (T5) 1 30
Capability Update Retries 0 255
3.3.34 NS Link Configuration

Length (8) 2-3
Remote UDP Port 4-5
Remote IP Address 6-9
Local UDP Port 10-11
This attribute carries the configuration of the NS Link of the Gb interface (see GSM
08.16).
If the Local Port value is NULL (zero), it may be dynamically selected by the BTS.
3.3.35 RLC Configuration

Length (9) 2-3
T_3142 4
T_3169 5
T_3191 6
T_3193 7
T_3195 8
N_3101 9
N_3103 10
N_3105 11
Countdown Value 12
This attribute carries the configuration of the RLC of the GPRS Air Interface (see GSM
04.60). The Countdown Value is the initial value of the RLC CV at which the countdown
procedure is started. All timers are in units of seconds unless otherwise stated. The
configurational limits are as specified below.
© ip.access Ltd
- 30 -
T_3142 1 255
T_3169 1 255
T_3191 1 255
T_3193 (units: 10ms) 8 255
T_3195 1 255
N_3101 8 255
N_3103 1 255
N_3105 1 255
Countdown Value 1 15
3.3.36 Alarm Threshold List
Note: this NV attribute supersedes the direct use of the Manufacturer Dependent
Thresholds attribute, and the Set Alarm Thresholds message, which only allows the
carrying of a single alarm threshold – see section 3.4.10.

Length (L) 2-3
Monitored Value Threshold 4…
:
Monitored Value Threshold ...L+3
The list of Alarm Threshold configurations may be set in or read from NV storage with this
attribute. A Set NV Attributes containing this attribute shall cause the current list in NV to
be completely replaced. Any thresholds not included in the list shall become NULL, and
their alarm monitoring disabled. A Get NV Attributes on this attribute shall return the
complete list supported by the BTS equipment, including NULL values of the disabled
alarm thresholds.
This attribute contains a list of zero or more complete Monitored Value Threshold fields,
as defined in the following section.
The default value of this attribute in an unconfigured unit shall have NULL values for the
thresholds for all supported monitored values.
3.3.36.i Monitored Value Threshold field
The Monitored Value Threshold field shall be coded with the following format:
© ip.access Ltd
- 31 -
8 7 6 5 4 3 2 1
UL Monitored Value Type 1
Length (K) 2-3
Monitored Value 4..K+3
The UL bit determines whether it is an Upper (maximum) or Lower (minimum) threshold

being defined. The Monitored Value Type field shall be coded with the following values:
Monitored Value Type Monitored Value Length Monitored Value format

Type values (K)
Input supply voltage 0x00 1 Percentage (-20…120)
Internal temperature 0x01 1 Percentage (-20…120)
Input supply current 0x02 1 Percentage (-20…120)
Input supply power 0x03 1 Percentage (-20…120)
All other Monitored Value Type values are reserved.
The type “percentage” is of the nominal working range of the corresponding value (e.g. for
a unit with nominal input supply voltage range of 40 – 56 V, setting the Input supply
voltage max to 90% would set the threshold at 40+0.90*(56-40) = 54.4 V). The value –128
shall be used as a NULL value: setting a threshold to the NULL value disables this
threshold, resulting in no alarms for that threshold type.
The current values of the Monitored Values may be obtained through a Get Attributes of
the Monitored Values List attribute.
3.3.37 Monitored Value List
Note: this attribute supersedes the use of Get Attributes on the Manufacturer Dependent
Thresholds attribute – see section 3.4.10.

Length (L) 2-3
Current Monitored Value 4…
:
Current Monitored Value ...L+3
The list of current values of the Monitored Values (being monitored against the Alarm
Threshold List – see 3.3.36) may be read through this attribute. A Get Attributes on this
attribute shall return the complete list of Monitored Values supported by the BTS
equipment.
This attribute contains a list of zero or more Current Monitored Value fields: these are of
identical format to the Monitored Value Threshold fields, as defined in section 3.3.36.i,
except that the UL bit is reserved.
© ip.access Ltd
- 32 -
3.3.38 Timing Bus Control
8 7 6 5 4 3 2 1
Length (1) 2-3
Reserved TIB Out 4
This attribute controls the timing bus within the addressed object. It is only modifiable if
the Timing Bus attribute indicates that this object supports control of the Timing Bus
output.
The TIB Out bits are defined as follows:
Bits Meaning
00 Auto (default)
01 TIB out Enabled
10 TIB out Disabled
11 Reserved
The value “Auto” shall be used to allow the object to automatically enable or disable the
TIB output, as required by the BTS equipment to perform normal operation of the BTS as
a whole. In a multi-TRX BTS the TIB output may be determined by the current state of the
BTS objects and the integrity of the TIB cabling between them.
3.3.39 Supported Features

Length (L) 2-3
… …
Embedded Information Element …-(L+3)
This attribute reports the supported features of the object. It carries a set of Embedded
Information Elements which details each supported feature. The Embedded Information
Elements which may be included in this attribute by each object class are given in the
following table.
Embedded IE Object Classes

Frequency Band Radio Carrier
Max Timing Advance BTS
Ciphering Algorithms Baseband Transceiver
Channel Types Baseband Transceiver
Channel Modes Baseband Transceiver
GPRS Coding Schemes GPRS Cell
RTP Features Baseband Transceiver
RSL Features Baseband Transceiver
© ip.access Ltd
- 33 -
The objects shall include this attribute in a Get Attributes with all the Embedded IEs which
it supports, including those which have a NULL value.
3.3.40 Coding Schemes
8 7 6 5 4 3 2 1
Attribute Identifier 1
Length (2) 2-3
MCS Res Res Res CS4 CS3 CS2 CS1 4
9 erve erve erve
d d d
MCS MCS MCS MCS MCS MCS MCS MCS 5
8 7 6 5 4 3 2 1
This attribute controls the (E)GPRS (Modulation and) Coding Schemes allowed to be
used by the PCU. A value 1 in each bit field indicates that the relevant scheme is allowed
to be used, and a 0 indicates it is not allowed. The rates actually available to be used are
therefore the logical AND of this attribute and the corresponding GPRS Coding Schemes
embedded IE in the Supported Features attribute.
The default values of the 2 octets shall be 0xff, which allows the object to use its full
capability, as indicated in the GPRS Coding Schemes embedded IE in the Supported
Features attribute.
NOTE: The use of MCS3 and MCS6 with padding for retransmission of packets with
padding from MCS8 is controlled by the normal control of MCS3 and MCS6 respectively.

Length (5) 2-3
T Downlink TBF Extension (10ms) 4-5
T Uplink TBF Extension (10ms) 6-7
Initial GPRS Coding Scheme 8
This attribute carries additional configuration of the RLC of the GPRS Air Interface. All
timers are in units of seconds unless otherwise stated. The configurational limits and
defaults are as specified below.
Parameter Minimum Maximum Default

T Downlink TBF Extension (10ms) 0 500 100
T Uplink TBF Extension (10ms) 0 500 50
The Initial GPRS Coding Scheme is coded as follows:
Value Meaning
© ip.access Ltd
- 34 -
1 CS1
2 CS2
3 CS3
4 CS4
All other values are reserved. The default value is CS2.
3.3.42 Heartbeat Timeout

Length (2) 2-3
Heartbeat Timeout 4-5
This attribute carries the value of the inactivity period on the associated link before the
BTS transmits a Heartbeat message (see [SIG-IP]) on the link associated with the
addressed object (the Primary OML for the Site Manager, the RSL for the Baseband
Transceiver). The value is in seconds.
If this value is omitted, the default of 20 seconds is used (and this value is always used on
the Secondary OML). The value zero disables the Heartbeat messages from the BTS.
3.3.43 Up Time

Length (4) 2-3
Up Time 4-7
This attribute carries the value of the time in seconds since the containing object was last
initialised (after power on) or reinitialised (due to reset or management reinitialisation).

Length (1) 2-3
Initial EGPRS Coding Scheme 4
This attribute carries additional configuration of the RLC of the GPRS Air Interface.
The Initial EGPRS Coding Scheme is coded as follows:
Value Meaning
1 MCS1
2 MCS2
3 MCS3
4 MCS4
5 MCS5
© ip.access Ltd
- 35 -
6 MCS6
7 MCS7
8 MCS8
9 MCS9
All other values are reserved. The default value is MCS6.
3.3.45 SSL Configuration
This IE is used to update the SSL Configuration stored in non-volatile memory on the
BTS. The SSL configuration attribute affects the OML, RSL and IML links.
8 7 6 5 4 3 2 1
Length (1) 2-3
SSL 4
Reserved
Control
The SSL Control can take the following values:
Value Meaning
0 SSL Disabled
1 SSL Optional
2 SSL Mandatory
3.3.46 Security Possible
This IE is used to show whether the Baseband Transceiver has a valid certificate and
whether it is currently in use.
8 7 6 5 4 3 2 1
Length (1) 2-3
Security 4
Reserved
Possible
Security Possible can take the following values:
Value Meaning
0 No Certificate
1 Certificate available but not in use
2 Certificate in use
© ip.access Ltd
- 36 -
3.3.47 IML SSL State
This IE is used to show the state of the IML link between this Baseband Transceiver and
the master Baseband Transceiver.
8 7 6 5 4 3 2 1
Length (1) 2-3
IML 4
Reserved SSL
State
IML SSL State can take the following values:
Value Meaning
0 Insecure
1 Secure
Note that on the master Baseband Transceiver, the IML SSL State is reported as secure.
3.3.48 Revocation Date
This IE contains the issue date of the revocation file on the Baseband Transceiver.
8 7 6 5 4 3 2 1
Length (L) 2-3
Revocation Date 4-(L+3)
The Revocation Date is a NULL terminated ASCII string containing the issue date from
the revocation file.
The default value of this attribute in unit without a revocation file shall be the NULL
(empty) string.
3.4 Manufacturer Dependent Information Elements
The following Information elements defined in 12.21 as containing manufacturer-

dependent values, or extended to do so by this specification, shall be coded as described
in the following sections.
3.4.1 Additional Info
This Information Element shall be coded as follows:
© ip.access Ltd
- 37 -
Length (N) 2-3
Embedded Information element 4
… …
Embedded Information element N+3
The Embedded Information Elements used in this attribute are:
Embedded IE
Logged Event Indicator O 3.5.24
Localised Additional Text Information O 3.5.25
The Embedded Information Elements shall be included in order of increasing Embedded

Information Element Identifier.
3.4.2 Additional Text
This field shall contain an ASCII text string which describes in English the fault reported. It
should be terminated by an ASCII NULL (0x00).
3.4.3 Event Type
This Information Element has a manufacturer dependent range 0x10 to 0xFF, which shall
be coded as follows:
General Software Fault 0x10
NOTE: use of the value for “Generic Software Fault” is deprecated: this coding should be
replaced by the standard ITU coding “Processing Failure”.
3.4.4 File Data
The format of the File Data field within the File Data attribute is a manufacturer dependent
value, and is only of relevance between the BTS vendor and the BTS. The Attribute
Identifier for the File Data Attribute may be the manufacturer extension value defined in
section 3.3.2, or may be the value defined in [GSM 12.21 v5.0.0 section 9.4], which was
omitted from earlier versions of that specification: the objects should accept either
attribute Id, and reply with the same attribute identifier value.
3.4.5 File Id
The File Id information element [GSM 12.21 sec 9.4.18] shall be coded as:
© ip.access Ltd
- 38 -
Length (N) 2-3
File Id 4…N+3
The File Id shall be an ASCII string, which shall enable the manufacturer to uniquely
identify the functional capabilities of the software.
When used in the SW Description of the Load Data Initiate message, the File Id field may
start with the string “bank<n>://”, where “<n>” is an integer. This commands that the
downloaded software must be saved in the designated software storage bank. If this
storage bank is not supported by this BTS, the message shall be NACked with the Nack
Cause “Resource not implemented”.
NOTE: This feature is only intended for use in the factory population of the nanoBTS
software banks, and may lead to the BTS being unbootable if used inappropriately.
3.4.6 File Version
The File Version information element [GSM 12.21 sec 9.4.19] shall be coded as:
Length (N) 2-3
File Version 4…N+3
The File Version shall be an ASCII string, which, together with the File Id field, shall
enable the manufacturer to uniquely identify the version of the software.
3.4.7 HW Description
The HW Description information element [GSM 12.21 sec 9.4.23] shall be coded as:
Equipment Id Length 2-3
Equipment Id 4-…
Equipment Type Length
Equipment Type
Equipment Version Length
Equipment Version
Location Length
Location
Man Dep. Info Length
Embedded Information element
…
Embedded Information element N
All length fields above are 2 octets long.
© ip.access Ltd
- 39 -
The Equipment Id, Equipment Type, Equipment Version and Location fields are variable
length character strings consistent with the associated GSM 12.20 attributes, where:
• Equipment Id distinguishes a piece of equipment out of others of same type.
• Equipment Type codes the type of piece of equipment (e.g. Baseband Transceiver
Unit).
• Equipment Version codes the version of the piece of equipment.
The Embedded Information Elements which are used in the HW Description are:
Embedded IE Inclusion
MAC Address O
HW-SW Compatibility Number O
Manufacturer Serial Number O
OEM Id O
Date and time of Manufacture O
Date and time of Calibration O
Factory Id O
Factory Serial Number O
Frequency Bands O
BTS Hardware Class O
Objects should include as many Embedded IEs in the HW Description as they have valid
values for.

3.4.8 List of Required Attributes
The List of Required Attributes [GSM 12.21 section 9.4.26] IE used in the Get Attributes
shall be able to include:
1. the standard 12.21 attributes supported by this specification, excluding those not
supported by this specification (see 3.1.1)
2. the Manufacturer-defined Attribute Identifiers defined in section 3.3.2 above,
except those supported under Get/Set NV only – see 3.8.2..
The attribute may also be used in the Get NV Attributes message, in which it may contain
only the NV attributes - see 3.8.2..
3.4.9 Manufacturer Dependent State
No values currently defined.
© ip.access Ltd
- 40 -
3.4.10 Manufacturer Dependent Thresholds
The Manufacturer Dependent Threshold attribute is no longer supported. Its functionality

has been replaced by the Alarm Threshold List NV attribute (3.3.36). For details of how
this attribute was supported, see v0.13 of this specification.
3.4.11 Manufacturer Id
The value of the Manufacturer Id field shall be a null-terminated ASCII text string which
uniquely identifies the manufacturer. It should use the “reverse domain name” notation
(e.g. for ip.access it shall be the 13 octet ASCII text string “com.ipaccess”).
This attribute shall be supported on all objects, including the BTS object (not included in
[GSM 12.21]).
3.4.12 Nack Causes
This Information Element has a manufacturer dependent range 0x80 to 0xFE, which shall
Test Precedence Limitation 0x80
3.4.13 Physical Config
The Physical Config information element [GSM 12.21 sec 9.4.40] shall be coded as:
Length (N) 2-3
Test Precedence 4
Embedded Information element 5
… …
Embedded Information element N+3
The Test Precedence field is coded as follows:
0x01 The object to which the Perform Test is issued must be administratively locked or
not yet Op Started by the O&M system in order to perform the test.
0x02 The object to which the Perform Test is issued, and any of its dependent child
objects must not have any active dedicated channels (i.e. not including BCCH,
FCCH, SCH , CCCH, and CBCH) in order to perform the test.
0x03 The object to which the Perform Test is issued must be unconfigured and not yet Op
Started by the O&M system in order to perform the test.
Other required conditions may be defined in the future (e.g. no precondition – immediately
terminate all activity to carry out the test). If an unknown Test Precedence value is
© ip.access Ltd
- 41 -
received, the Perform Test shall be NACKed with reason code “Parameter value outside
permitted range” (value 0x0e). If the required Test Precedence condition is not met, the
Perform Test shall be NACKed with reason code “Physical Configuration cannot be
performed” (value 0x1e).
The Embedded Information Elements which are used in the Physical Config for each of
the Tests are:
Channel BCCH Frequency BCCH Transmit BCCH BCCH

Usage Channel Synchronisation Information Beacon Monitor &
Usage CCCH
Monitor
ARFCN O O O O - - -
Whitelist
ARFCN O O O O - - -
Blacklist
BCCH - - - O - - -
Information
Type
Configuration O O O O - O O
RXLEV O O O O - - -
Threshold
Frequency - - O - - - -
Sync Options
Beacon - - - - M - -
Information
BTS Identifier - - - - - M M

3.4.14 Specific Problems
No values currently defined.
3.4.15 Test No
Channel Usage x40

BCCH Channel Usage x41
Frequency Synchronisation x42
BCCH Information x43
Transmit Beacon x44
SysInfo Monitor x45
BCCH & CCCH Monitor x46
All other values are reserved.
© ip.access Ltd
- 42 -
All the above tests may be performed on the BTS and Radio Carrier objects only. (NOTE:
Future extensions may allow some or all of these tests to be performed on other objects).
The Perform Test message for all of the above tests shall include the Physical Config
Information element, and may include the optional Test Duration information element. It
shall also support the use of Autonomous and non-Autonomous reporting options in the
Autonomously Report information element. Support for all these options shall be included
in the BTS.
The optional “Test Duration” information element shall be supported, and is used as a limit
on the overall duration of the test, which should be terminated autonomously by the BTS
after the specified duration, with a partially complete Test Report if appropriate.
3.4.16 Test Report Info
The Test Report Info information element [GSM 12.21 sec 9.4.57] shall be coded as:
Length 2-3
Result Code 4
Embedded Information element 5-…
…
Embedded Information element …-N
The Result Code field shall have the following coding:
Success 0x00
Timeout 0x01
No Suitable Channels 0x02
Partial Results – more to follow 0x03
Test Stopped 0x04
All other codes shall denote (partial at least) failure of the test, and the remainder of the
Test Report Info may contain either nothing or only partial results. The Result Code
“Partial Results – more to follow” may be used to segment the results into two or more
messages, which in the case of Autonomous reporting may be issued at intervals during
the test. The final message of such a set should contain one of the other Result Code
values, as appropriate, and may contain no following Embedded Information Elements.
If a test is terminated by a Stop Test message the BTS may issue a Test Report message
carrying any unsent partial results in the Test Report Info, together with Result Code “Test
Stopped”. If sent, such a Test Report shall be sent before sending the Stop Test Ack
message.
If a test is terminated by a timeout, the BTS shall issue a Test Report with Result Code
“Timeout”, which may also contain any unsent partial results in the Test Report Info.
© ip.access Ltd
- 43 -
The Result Code “No Suitable Channels” shall be used to indicate that the test completed
normally, but that none of the channels met the criteria to include them in the results, so
the results shall be empty. It should be noted that in the case of a frequency
synchronisation test which is meant to adjust the clock to match the measured offset (see
section 3.5.9), this result code also indicates that the adjustment could not be performed.
The Embedded Information Elements which are used in the Test Report Info for each of
the Tests are:
Channel BCCH Frequency BCCH Transmit SysInfo BCCH &

Usage Channel Synchronisation Information Beacon Monitor CCCH
Usage Monitor
Frequency - - M(2) - - - -
Error List
Frequency - - M(3) - - - -
Error
Channel M(1) M(1) - - - - -
Usage List
BCCH - - - M(1) - - -
Information
Result O O O O - O O
Details
Broadcast - - - - - O O
L3 Message
Notes:
1. Only Mandatory for successfully completed test outcomes, otherwise optional.
2. Mandatory only if requested in the Physical Config in the Perform Test, otherwise
omitted.
3. Mandatory unless a List without Set operation is requested in the Physical Config
in the Perform Test, otherwise omitted.
3.4.17 Perceived Severity
The use of the Indeterminate Failure value of [GSM 12.21 section 9.4.63] shall be
deprecated.
Logged Failure Ceased 0x80

Logged Critical Failure 0x81
Logged Major Failure 0x82
Logged Minor Failure 0x83
Logged Warning Level Failure 0x84
Logged Indeterminate Failure 0x85
NOTE: the “logged” Perceived Severity values have the corresponding “non-logged”
versions (coded with a value 0x80 lower), but are used for errors which have been logged
© ip.access Ltd
- 44 -
to an internal store at a previous time when it was not possible to transmit them to the
OMC, and are now being transmitted, and the internal store emptied.
Use of these codes is deprecated, and has been superseded by the use of the Logged
Event Indicator in the Additional Info attribute - see 3.4.1.
All other values are reserved.
3.4.18 Probable Cause
The Probable Cause Value field used for a Probable Cause Types 3 and beyond
(Manufacturer specific values and other reserved values) are specified in [ALARMS].
3.4.19 Channel Combination
The Channel Combination attribute [GSM 12.21 sec 9.4.13] shall be extended to include
the following additional values:
PDCH PDTCH/F+PACCH/F+PTCCH/F 0x0d

cPDCH PCCCH+PDTCH/F+PACCH/F+PTCCH/F 0x0c
bPDCH PBCCH+PCCCH+PDTCH/F+PACCH/F+PTCCH/F 0x0b
TCHFull/PDCH TCHFull or PDCH dynamic 0x80
TCHFull/TCHhalf TCHFull or TCHHalf dynamic 0x81
The combinations which contain either a circuit or a packet channel cause the BTS to
default to an inactive channel, and require an extended 08.58 PDCH activation procedure
(see 4.1.16) to invoke the packet channel. They may be switched at any time between the
packet options and idle using the extended 08.58 PDCH activation and RF Channel
Release procedures. They may be activated for circuit use using the normal 08.58
Channel Activation and RF Channel Release procedures.
3.4.20 Measurement Identifier
This Information Element (also referred to as Measurement Type in [GSM 12.21]) has a
manufacturer dependent range 0x40 to 0xFF, which shall be coded for the various object
classes as follows. The Object Version column denote the range of the Object Class
Version number for which this Measurement is valid.
Measurement Identifier Object Object Description

Value Class Version
CCCH Utilisation MF 0x40 BTS 2- See [PM]
SDCCH Usage MF 0x41 BTS TBD See [PM]
Measurement Processing MF 0x42 BTS 2- See [PM]
RTP Usage MF 0x43 BTS 2- See [PM]
RTP Perfomance MF 0x44 BTS 2- See [PM]
GPRS CCCH MF 0x45 GPRS NSE 2- See [PM]
PCCCH Utilisation MF 0x46 GPRS NSE TBD See [PM]
© ip.access Ltd
- 45 -
Measurement Identifier Object Object Description
Value Class Version
GPRS CCCH Details MF 0x47 GPRS NSE 2- See [PM]
Establishment MF 0x48 GPRS NSE 2- See [PM]
Uplink TBF MF 0x49 GPRS NSE 2- See [PM]
Downlink TBF MF 0x4a GPRS NSE 2- See [PM]
TBF Details MF 0x4b GPRS NSE TBD See [PM]
TBF Usage MF 0x4c GPRS NSE 2- See [PM]
LLC Data MF 0x4d GPRS NSE 2- See [PM]
PDCH Usage MF 0x4e GPRS NSE 2- See [PM]
Power Control MF 0x4f GPRS NSE TBD See [PM]
Link Adaptation MF 0x50 GPRS NSE 2- See [PM]
TCH Usage Details MF 0x51 BTS 30- See [PM]
AMR MF 0x52 BTS 30- See [PM]
RTP Multiplex Performance MF 0x53 BTS 35- See [PM]
RTP Multiplex Usage MF 0x54 BTS 35- See [PM]
SRTP Multiplex Usage MF 0x55 BTS 35- See [PM]
Reserved 0x56-0xFF
3.4.21 Measurement Results
This Information Element shall be coded as follows:
Length (N) 2-3
Embedded Measurement 4
… …
Embedded Measurement N+3
The Embedded Measurements which are used for the various Measurement Identifiers
are of the general form:
Embedded Measurement Identifier 1

Length (N) 2-3
Embedded Measurement Value 4..N+3
The Embedded Measurement Identifiers are only guaranteed to be unique within a single
Measurement Type (as described by the Measurement Identifier). The following sections
describe the Embedded Measurements for each Measurement Type.
The Embedded Measurements shall be included in ascending order of their Identifier

values. Unknown Identifier values should be discarded by the receiver and the remaining
known values accepted.
© ip.access Ltd
- 46 -
3.4.21.i Measurement Function Values
For Measurements which require a single value, the format of the value field of the BTS
12.21 embedded IE shall be a 32 bit signed integer value.
For Measurement Function attributes which require a list of values by cause or other
single byte index variable, the format of the embedded IEs shall be:
Embedded IEI 1
Length(5n) 2-3
Cause(0) 4
Measurement(cause(0)) 5-8
: :
Cause(n) 5n-1
Measurement(cause(n)) 5n-5n+3
The cause values shall be in order of increasing value, and only causes with non-zero
Measurements shall be included.
3.4.21.ii Manufacturer Alarm Values
Embedded Embedded Length Format Description

Measurement Measurement
Identifier
Input Supply TBD 1 Percentage The Input current value
Voltage (-20-120) monitored by the Manufacturer
Thresholds (see 3.4.10)
Internal TBD 1 Percentage The Input current value
Temperature (-20-120) monitored by the Manufacturer
Current (-20-120) monitored by the Manufacturer
Power (-20-120) monitored by the Manufacturer
The values at the extreme of range (i.e. –20 or 120) indicate that value or lesser/greater
values, as appropriate.
3.4.22 Object Class
The Object Class attribute [GSM 12.21 sec 9.2] shall be extended to include the following
additional values:
© ip.access Ltd
- 47 -
GPRS NSE 0xf0
GPRS Cell 0xf1
GPRS NSVC 0xf2
3.4.23 Object Instance
The Object Instance attribute [GSM 12.21 sec 9.3] shall be extended to include the
following additional uses and limitations.
BTS number or GPRS NSE number 1

Baseband Transceiver or Radio Carrier number or GPRS Cell or GPRS NSVC 2
Radio Timeslot number 3
When the object class is GPRS NSE, octet 1 shall be a binary presentation of the identifier
of the addressed GPRS NSE. Octets 2 and 3 shall be coded NULLs. If the GPRS NSE
number is NULL, it shall be understood as referring to all GPRS NSEs under the Site
Manager.
When the object class is GPRS Cell or GPRS NSVC, octet 2 shall be a binary presentation
of the identifier of the addressed GPRS Cell or GPRS NSVC object, and octet 1 is the
identifier of the GPRS NSE above it. Octet 3 is coded NULL. If the Baseband Transceiver
or Radio Carrier number is NULL, it shall be understood as referring to all instances of the
class under the GPRS NSE.
The BTS object with Instance Number 0, if present, shall be hosted on the same BTS
Equipment as hosts the Site Manager object.
The Baseband Transceiver and Radio Carrier objects with the numerically equal Instance
Numbers shall be hosted on the same BTS Equipment. The Baseband Transceiver and
Radio Carrier objects with Instance Number 0 shall be hosted on the same BTS
Equipment as hosts the containing BTS object.
The GPRS Cell Number shall have the same numerical value as the BTS Instance
Number of the BTS object with which it is associated.
The GPRS NSE object shall be hosted on the same BTS Equipment as hosts the BTS
object with the numerically equal Instance Number.
3.4.24 SW Configuration
The SW Configuration attribute shall contain zero or more SW Descriptions, as defined in

[GSM 12.21].
In a Get Attributes Response, each object’s SW Configuration shall contain a SW

Description for each version of each of the SW image types on which the object depends.
(An object depends on a software image if the physical item that it represents requires the
image to be executed before it can provide any service.) The SW Configuration attribute
© ip.access Ltd
- 48 -
of all objects shall therefore contain at least the SW Description for any boot code (if
separate from the application) as well as one or more SW Descriptions of the
application(s) which provides the object’s functionality.
In the Activate SW Request, the SW Configuration attribute should include at least one
SW Description for each type of image that the object requesting activation is dependent
on, excluding boot code. If, when an object sends a SW Activate Request, a version of an
image that it depends on has already been activated (e.g. due to activation of a containing
or related object), it shall only include that version’s SW Description, otherwise it includes
a SW Description for each version of the image that is available for activation. Note that
the value of the SW Configuration attribute in a SW Activate Request message sent by an
object is therefore not the same as that of the SW Configuration attribute obtained by
sending a Get Attributes message to the object.
Where a SW Activate Request contains more than one SW Description for a given image
type, the first one is the “default” image: if a SW Activate is returned with no SW
Configuration, it shall result in the default SW Description(s) being activated, and thus
becoming part of the Current SW Configuration (see 3.3.23).
3.4.25 Get Attributes Response Info
The Get Attributes Response Info attribute shall not contain the Reported attributes as
defined in GSM 12.21 9.4.64 (see 3.2.7 and 3.6.9). Its format shall therefore be:
Length (N) 2-3
Count of non-reported Attributes 4
Non-reported attribute Id 5
…
Non-reported attribute Id N+3
3.4.26 Overload Period
The Overload Period attribute of [GSM 12.21 section 9.4.39] shall be in units of seconds,
and shall have a valid range of 0…255, and shall thus be a single octet long.
3.5 Embedded Information elements
The embedded information elements used in the above Manufacturer defined information
elements are defined by the general structure:
Embedded Information element Identifier 1

Length (N) 2-3
Information 4-N+3
© ip.access Ltd
- 49 -
The Length field defines the length of the following Information field (N). The specific
embedded information elements are defined in the following sections, and have
Embedded Information element Identifier values of:
ARFCN Whitelist 0x01

ARFCN Blacklist 0x02
Frequency Error List 0x03
Channel Usage List 0x04
BCCH Information Type 0x05
BCCH Information 0x06
Configuration 0x07
Result Details 0x08
RXLEV Threshold 0x09
Frequency Sync Options 0x0a
MAC Address 0x0b
HW-SW Compatibility Number 0x0c
Manufacturer Serial Number 0x0d
OEM Id 0x0e
Date and time of Manufacture 0x0f
Date and time of Calibration 0x10
Beacon Information 0x11
Frequency Error 0x12
SNMP Community String 0x13
SNMP Trap Address 0x14
SNMP Trap Port 0x15
SNMP Manager Address 0x16
SNMP System Contact 0x17
Factory Id 0x18
Factory Serial Number 0x19
Logged Event Indicator 0x1a
Localised Additional Text Information 0x1b
Frequency Bands 0x1c
Max Timing Advance 0x1d
Ciphering Algorithms 0x1e
Channel Types 0x1f
Channel Modes 0x20
GPRS Coding Schemes 0x21
RTP Features 0x22
RSL Features 0x23
BTS Hardware Class 0x24
BTS Identifier 0x25
Broadcast L3 Message 0x26
3.5.1 ARFCN Lists
The ARFCN Whitelist and ARFCN Blacklist embedded information elements shall have
the following structure:
© ip.access Ltd
- 50 -
Length (2N) 2-3
Channel 1 MSB 4
Channel 1 LSB 5
… …
… …
Channel x MSB 2N+2
Channel x LSB 2N+3
The 16 bit Channel values are:
8 7 6 5 4 3 2 1
R Reserved ARFCN( 1
msb)
ARFCN(lsb) 2
The fields are defined as:
Range (R) If set to 00, the ARFCN in the Channel field is a single value
If set to 01, the ARFCN in the Channel field is the start of a range, which
is terminated by the ARFCN in the following Channel field.
If set to 10, the ARFCN in the Channel field is the end of a range, which
was started by the ARFCN in the previous Channel field.
11 reserved.
A range of ARFCNs is defined by a pair of Channel entries, the first of which has the R
bits set to 01, and the second of which has the R bits set to 10, and defines all ARFCNs
from the first to the second inclusive. The value of the first ARFCN in a range definition
shall be lower than that of the second ARFCN. It is an error to have the R bits set to
indicate a start of a range without it being immediately followed by an indication of the end
of the range, or to indicate the end of a range without being immediately preceded by the
start of a range.
The ARFCN Whitelist embedded information element defines a set of ARFCNs which may
be used in the test. The ARFCN Blacklist embedded information element defines a set of
ARFCNs which may not be used in the test.
The Physical Config in the Perform Test may optionally include either an ARFCN
Whitelist, or an ARFCN Blacklist, or both. These are used to define the set of channels to
be used in the test. If neither is included, all channels which the BTS can receive may be
used in the test (subject to other constraints which other Physical Config elements may
impose). If only an ARFCN Blacklist is included, all ARFCNs except those listed may be
used. If only an ARFCN Whitelist is included, only the listed channels shall be used. If
both an ARFCN Whitelist and an ARFCN Blacklist are included, only those ARFCNs
which are included in the Whitelist and are not included in the Blacklist shall be used.
© ip.access Ltd
- 51 -
Any channels listed in the ARFCN Blacklist or the ARFCN Whitelist are outside the
capabilities of the receiver, or are listed in the ARFCN Blacklist but not listed in the
supplied ARFCN Whitelist, should be silently ignored by the BTS, and all other eligible
channels included in the test. If a test has no remaining eligible channels, the Perform
Test should be Nacked by the BTS.
NOTE: These rules are designed to allow the configuration of the test to be independent
of the capabilities of the TRXs within a BTS.
3.5.2 Frequency Error List
The Frequency Error List embedded information element shall have the following
structure:
8 7 6 5 4 3 2 1
Length (4N) 2-3
Frequency Error 1 4-5
Frequency Quality 1 ARFCN( 6
msb)
ARFCN(lsb) 7
… …
Frequency Error N 4N,4N+1
Frequency Quality N ARFCN 4N+2
(msb)
ARFCN N(lsb) 4N+3
The Frequency Error field is a signed value measured in ppb. It is the amount by which
the home BTS’s timebase frequency exceeds the monitored channel’s BTS timebase
frequency.
The Frequency Quality value is a monotonically increasing measure of quality of the

estimate of frequency error derived by the BTS. The value zero is the lowest quality.
3.5.3 Channel Usage List
The Channel Usage List embedded information element shall have the following structure:
© ip.access Ltd
- 52 -
Length (2N) 2-3
Channel 1 usage MSB 4
Channel 1 usage LSB 5
… …
… …
Channel x usage MSB 2N+2
Channel x usage LSB 2N+3
The Channel usage 16 bit values are:
8 7 6 5 4 3 2 1
RXLEV ARFCN(msb) 1
ARFCN(lsb) 2
3.5.4 BCCH Information Type
The BCCH Information Type embedded information element shall have the following
structure:

Length (=2) 2-3
BCCH Info Type (octet 1) 4
BCCH Info Type (octet 2) 5
The BCCH Info Type field is a bit mask, with a “1” to denote that a field of BCCH
Information is required, and a “0” to denote that it is not. The bits and their corresponding
BCCH Information fields are:
Octet Bit BCCH Information validity

1 1 RXLEV
1 2 RXQUAL
1 3 Frequency Error & Quality
1 4 Frame Offset
1 5 Frame Number Offset
1 6 BSIC
1 7 Cell Global Identity
1 8 Neighbour BCCH Allocation List – SysInfo 2
2 1 Neighbour BCCH Allocation List – SysInfo 2-bis
2 2 Neighbour BCCH Allocation List – SysInfo 2-ter
2 3 Cell Allocation List
2 4..8 Reserved
All remaining bits in the second octet are reserved. If omitted, all the possible information
is requested by the Perform Test.
© ip.access Ltd
- 53 -
3.5.5 BCCH Information
The BCCH Information embedded information element shall have the following structure:
8 7 6 5 4 3 2 1
Length 2-3
BCCH Info Type 4-5
Frequency Quality ARFCN( 6
msb)
ARFCN(lsb) 7
Reserved RXLEV 8
Reserved RXQUAL 9
Frequency Error (MSB) 10
Frequency Error (LSB) 11
Frame Offset (MSB) 12
Frame Offset (LSB) 13
Frame Number Offset (MSB) 14
Frame Number Offset 15
Frame Number Offset 16
Frame Number Offset (LSB) 17
Reserved BSIC 18
CGI(MCC) (Sysinfo 3) 19
… …
CGI(CI) 25
BA List (SysInfo 2) (Opt +16)
BA List (SysInfo 2-bis) (Opt +16)
BA List (SysInfo 2-ter) (Opt +16)
CA List (SysInfo 1) (Opt +16)
The BCCH Info Type field is formatted as described in section 3.5.4 above and indicates
which of the following fields carry valid data. Other fields should be treated as reserved
fields, and should be set to zero by the BTS and ignored by the receiver.
The Frequency Error and Frequency Quality fields are as defined in section 3.5.2 above.
The Frame Offset field is measured in units of quarter bits, and is an unsigned 16 bit
integer, which shall not exceed 4999 (5000 being a frame offset). It is the amount by
which the home BTS’s frame timing is in advance of the monitored channel’s frame timing.
The Frame Number Offset is measured in units of a whole GSM frame, and is an
unsigned 32 bit integer, which does not exceed 2715647 (2715648 being the number of
frames in a hyperframe 51*26*2048). It is the amount by which the home BTS Frame
Number exceeds the monitored channel’s Frame Number.
© ip.access Ltd
- 54 -
The BSIC field is the BSIC value from the synchronisation channel of the monitored
channel.
The Cell Global Identity field contains the Location Area Identity (MCC+NCC+LAC) and
the Cell Identity of the monitored channel, as derived from the System Information. The
LAI is in the first 5 octets of the CGI field, starting with the MCC part, and the CI is in the
last 2 octets, both of which are coded as in the system Information messages.
The BCCH Info Type field defines the inclusion or not of the 3 Neighbour Cell lists (from
SysInfo 2, SysInfo 2-bis and SysInfo 2-ter) and the Cell Allocation list in the BA Lists and
CA List fields respectively. The BA List and CA List fields contain the complete BA List
and CA List from the System Information, in the format of those System Information
messages. The fields, if indicated as present in the BCCH Info Type field, are all of length
16 octets. If absent they are omitted from the Information Element (i.e. the IE is shorter by
16 octets for each omitted field).
3.5.6 RXLEV Threshold
The RXLEV Threshold embedded information element shall have the following structure:
8 7 6 5 4 3 2 1
Length 2-3
Reserved RXLEV 4
The Physical Config in the Perform Test may optionally include the RXLEV Threshold
which defines the lower limit on RXLEV which determines if a channel is sufficiently strong
to be included in the measurement. If RXLEV Threshold is not included, all channels
which are received with sufficient strength to perform the test shall be included.
3.5.7 Configuration
The Configuration embedded information element shall have the following structure:

Length 2-3
Configuration Data 4..N+3
The Physical Config in the Perform Test may optionally include the Configuration which
defines parameters for the test configuration (e.g. number of samples to monitor for the
test, minimum separation of samples). If Configuration is not included the BTS shall use
default values for the Configuration Data. This is intended to allow developers to control
the details of the test, and may only be used in operational scenarios with Configuration
Data values supplied by the manufacturer.
© ip.access Ltd
- 55 -
3.5.8 Result Details
The Result Details embedded information element shall have the following structure:

Length 2-3
Result Details Data 4..N+3
The Test Report Info in the Test Report may optionally include the Result Details which
describes detailed information produced by the test (e.g. number of samples to monitor for
the test, minimum separation of samples). It is only produced if so required by a
corresponding Configuration information element in the Perform Test. This is intended to
allow developers to extract detailed data from the test, and may only be used in
operational scenarios with Configuration Data values supplied by the manufacturer, and
the Results Details Data is only to be interpreted by the manufacturer.
3.5.9 Frequency Sync Options
The Frequency Sync Options embedded information element shall have the following
structure:

Length (N) 2-3
Frequency Quality Threshold L S 4
Freq Config Params 5..N+3
The fields are defined as:
Set (S) If set to 0, the frequency measurements shall only be reported

If set to 1, the clock shall be also adjusted to correct the reported errors, as well
as reporting the error
List (L) If set to 0, only a single Frequency Error value shall be reported in the
Frequency Error embedded IE in the report, which shall be the output value of
the algorithm used to combine the errors on all the measured channels
If set to 1, the List of the individual Frequency Errors of all the measured
channels shall be reported with a Frequency Error List embedded IE in the
Report.
The Frequency Quality Threshold sets a threshold value for the measured Frequency
Quality. Channels for which the measured Frequency Quality is below the set threshold
shall not be included in the test.
The Freq Config Params field contains binary configuration information used by the BTS
in its assessment of the frequency errors, and in its combining of the measurements of
errors from different channels into a single Frequency Error estimate and Frequency
Quality. If not included, default values shall be used by the BTS. This is intended to allow
© ip.access Ltd
- 56 -
developers to control the details of the test, and may only be used in operational
scenarios with Freq Config Params values supplied by the manufacturer.
3.5.10 MAC Address

Length(6) 2-3
MAC Address 4…9
3.5.11 HW-SW Compatibility Number

Length(N) 2-3
HW-SW Compatibility Number 4…N+3
The HW-SW Compatibility Number is an opaque octet array which allows the
manufacturer to uniquely identify the type of hardware from a software interface point of
view.
3.5.12 Manufacturer Serial Number

Length(N) 2-3
Manufacturer Serial Number 4…N+3
The Manufacturer Serial Number is an opaque octet array which allows the manufacturer
to uniquely identify the unit.
3.5.13 OEM Id

Length(N) 2-3
OEM Id 4…N+3
The OEM Id is an opaque octet array which allows the manufacturer to uniquely identify
the OEM that the unit was manufactured for.
© ip.access Ltd
- 57 -
3.5.14 Date and time of Manufacture and Calibration

Length(6) 2-3
Year 4
Month (1-12) 5
Day (1-31) 6
Hour (0-23) 7
Minute (0-59) 8
Second (0-59) 9
The values are binary representations of the relevant values. The year field is the number
of years since 1900.
3.5.15 Beacon Information
The Beacon Information embedded information element shall have the following structure:
8 7 6 5 4 3 2 1
Length 2-3
Reserved ARFCN( 4
msb)
ARFCN(lsb) 5
Reserved BSIC 6
Power 7
The ARFCN field contains the ARFCN value to be used for the beacon transmission, and
the Power field contains the twos-complement binary representation of the absolute
transmit power in units of dBm (-128…+127) with which the beacon should be transmitted.
The BSIC field contains the BSIC value to be used in the synchronisation channel of the
BCCH on the beacon.
3.5.16 Frequency Error
The Frequency Error embedded information element shall have the following structure:
8 7 6 5 4 3 2 1
Length (3) 2-3
Frequency Error 4-5
Frequency Quality Reserve 6
d
© ip.access Ltd
- 58 -
The Frequency Error field is a signed value measured in ppb. It is the amount by which
the home BTS’s timebase frequency was estimated to be in error by the test.
The Frequency Quality field is as described in the Frequency Error List.
3.5.17 SNMP Community String
Embedded Information Element Identifier 1

Length (L) 2-3
Community String 4…(L+3)
This attribute contains the SNMP Community String for SNMP v2c and above. It is a
NULL terminated ASCII string. A NULL string shall indicate the use of the “public”
community, and shall be the default for an unconfigured unit.
3.5.18 SNMP Trap Address

Length (4) 2-3
Trap Address 4…7
This attribute contains the destination IP address to which SNMP Traps are sent. It is an
IP address in network byte order. The address 0.0.0.0 shall disable the sending of SNMP
Traps, and shall be the default in an unconfigured unit.
3.5.19 SNMP Trap Port

Length (2) 2-3
Trap Port 4…5
This attribute contains the destination UDP port to which SNMP Traps are sent. The
default NULL value of 0 shall cause traps to be sent to the IANA well known port value of
162, and shall be the default in an unconfigured unit..
3.5.20 SNMP Manager Address
© ip.access Ltd
- 59 -
Length (4N) 2-3
Manager Address 4…7
: :
Manager Address 4N…4N+3
This attribute contains the IP address(es) which are allowed to manage the BTS through
its SNMP interface. The single NULL value 0.0.0.0, which is the default, allows the BTS to
be managed from any IP address. The default in an unconfigured unit shall be the empty
list, which is equivalent to a single NULL entry.
3.5.21 SNMP System Contact

Length (L) 2-3
System Contact 4…L+3
This attribute contains the SNMP System Contact (“SysContact”) string for the SNMP
MIB. It is an ASCII encoded string with a terminating NULL. It defaults to the value “Not
Known” in an unconfigured unit.
3.5.22 Factory Id

Length(N) 2-3
Factory Id 4…N+3
The Factory Id is an opaque octet array which allows the manufacturer to uniquely identify
the Factory where the unit was manufactured.
3.5.23 Factory Serial Number

Length(N) 2-3
Factory Serial Number 4…N+3
The Factory Serial Number is an opaque octet array which allows the manufacturer to
uniquely identify the unit within the Factory in which it was manufactured.
© ip.access Ltd
- 60 -
3.5.24 Logged Event Indicator

Length(N) 2-3
Delay Time 4..7
The Logged Event Indicator may be included in an Event Report to indicate that the Event
has been stored in the BTS due to it being unable to be transmitted on an OML at the time
it was raised (e.g. due to lack of OML).
Since the BTS does not timestamp the Events, the management system should interpret
the presence of this embedded IE as indication that the time of receipt of the Event is not
a good indication of the time of the original raising of this Event.
The embedded IE may optionally contain a Delay Time field which shall contain the time
offset in seconds since the original Event was raised and logged until it was actually
transmitted.
The BTS shall transmit Logged Events at the earliest reasonable opportunity on the OML.
3.5.25 Localised Additional Text Information

Length(N) 2-3
Format Resource Id 4..7
Format Data 7..N+3
The Localised Additional Text Information embedded IE may be included in Events to

provide the management system with information to allow it to construct a localised
version of the Additional Text attribute. It consists of an integer Resource Id which
identifies “printf” style format string to be used for the localised display string, optionally
followed by the data to be used by the printf format string.
3.5.26 BTS Identifier
8 7 6 5 4 3 2 1
Length 2-3
BSIC ARFCN( 4
msb)
ARFCN(lsb) 5
This embedded IE identifies a BTS uniquely within a local area.
© ip.access Ltd
- 61 -
3.5.27 Broadcast L3 Message
8 7 6 5 4 3 2 1
Length 2-3
Frame Number (Mod 51) 4
L3 Message 5-27
This embedded IE contains a complete L3 RR message from the BCCH or CCCH, as

defined in [04.18], together with the Frame Number (modulo 51) on the originating BTS
when the message was transmitted.
3.5.28 Frequency Bands
8 7 6 5 4 3 2 1
Length 2-3
450 480 850 PCS DCS R-GSM E-GSM P-GSM 4
This embedded IE indicates the frequency bands supported (see GSM 05.01). A value 1
in each bit field indicates that the relevant band is supported, and a 0 indicates it is not.
NOTE: if one of the extended bands (R-GSM or E-GSM) is supported, the relevant
included band shall also be indicated as supported (i.e. E-GSM and/or P-GSM).
3.5.29 Max Timing Advance

Length 2-3
Max Timing Advance 4
This embedded IE indicates the maximum supported Timing Advance value supported by
the object. The Max Timing Advance field is coded as the 12.21 Max Timing Advance
attribute.
3.5.30 Ciphering Algorithms
8 7 6 5 4 3 2 1
Length 2-3
A5/8 A5/7 A5/6 A5/5 A5/4 A5/3 A5/2 A5/1 4
This embedded IE indicates the Ciphering Algorithms supported. A value 1 in each bit
field indicates that the relevant Ciphering Algorithm is supported, and a 0 indicates it is
not.
© ip.access Ltd
- 62 -
3.5.31 Channel Types
8 7 6 5 4 3 2 1
Length 2-3
C8 C7 C6 C5 C4 C3 C2 C1 4
: : : : : : : : :
Cn Cn-1 . . . . . . L+3
This embedded IE indicates the Channel Types supported. A value 1 in each bit field
indicates that the relevant Channel Type is supported, and a 0 indicates it is not.
The Channel Type bits are coded:
Bit Channel Type

C1 TCH/F
C2 TCH/H
C3 SDCCH/8
C4 Main BCCH
C5 Combined BCCH
C6 BCH
C7 Combined BCCH + CBCH
C8 SDCCH/8 + CBCH
C9 PDCH/F
C10 TCH/F or PDCH/F (dynamic)
C11 TCH/H + PDCH/H
C12 TCH/F or TCH/H (dynamic)
Notes:
1. This EIE only details the capability of the hardware and the software to support
the specified channel or channel combinations, not whether it is legal in the GSM
specifications to use this channel on this object. It may be used together with the
permitted Channel Combinations (GSM 05.02) and carrier number of the object to
determine the detailed set of combinations supported by the set of channels within
the BTS.
2. This is a variable length EIE, which may be extended in future versions of this
specification to have capcity to indicate additional combinations. A receiver shall
truncate or extend with zero bits to match the number of combinations it is
expecting, including reserved bits in partially complete octets.
© ip.access Ltd
- 63 -
3.5.32 Channel Modes
8 7 6 5 4 3 2 1
Length 2-3
M8 M7 M6 M5 M4 M3 M2 M1 4
: : : : : : : : :
Mn Mn-1 . . . . . . L+3
This embedded IE indicates the Channel Modes supported. A value 1 in each bit field
indicates that the relevant Channel Mode is supported, and a 0 indicates it is not.
The Channel Mode bits are coded:
Bit Channel Mode

M1 FR
M2 EFR
M3 AMR/FS
M4 HR
M5 AMR/HS
M6- Reserved
M8
M9 6kb/s AIR NT CSD
M10 12kb/s AIR NT CSD
M11 14.5kb/s AIR NT CSD
M12- Reserved
M16
M17 1200/75b/s UR T CSD
M18 600b/s UR T CSD
M19 1.2kb/s UR T CSD
M24 Reserved
Notes:
1. This is a variable length EIE, which may be extended in future versions of this
specification to have capacity to indicate additional combinations. A receiver shall
truncate or extend with zero bits to match the number of combinations it is
expecting, including reserved bits in partially complete octets.
© ip.access Ltd
- 64 -
3.5.33 GPRS Coding Schemes
8 7 6 5 4 3 2 1
Length 2-3
MCS9 Reserv Reserv Reserv CS4 CS3 CS2 CS1 4
ed ed ed
MCS8 MCS7 MCS6 MCS5 MCS4 MCS3 MCS2 MCS1 5
This embedded IE indicates the GPRS (Modulation and) Coding Schemes supported. A
value 1 in each bit field indicates that the relevant scheme is supported, and a 0 indicates
it is not.
3.5.34 RTP Features
8 7 6 5 4 3 2 1
Length 2-3
MUX Reserve IR C 4
SRTP d
This embedded IE indicates the RTP features supported – see 4.2.21 and 4.2.26. A value
1 in each bit field indicates that the relevant feature is supported, and a 0 indicates it is
not.
The fields are coded:
Bit
C(1) RTP Compression Control
IR(2) 8kb/s Intermediate Rate
6 Unused
Mux(7) RTP Multiplexing
SRTP(8) SRTP Multiplexing
3.5.35 RSL Features
8 7 6 5 4 3 2 1
Length 2-3
Reserved PT2 DP P 4
This embedded IE indicates the RSL features supported. A value 1 in each bit field
indicates that the relevant feature is supported, and a 0 indicates it is not.
© ip.access Ltd
- 65 -
The fields are coded:
Bit
P Physical Context procedure
DP Dynamic PDCH Activation procedure
PT2 RTP Payload Type 2 IE
3.5.36 BTS Hardware Class
8 7 6 5 4 3 2 1
Length 2-3
BTS Hardware Class 4
This embedded IE indicates the class of BTS Hardware on which the object is hosted.
The BTS Hardware Class field is coded as:
Value Meaning
0x00 Single TRX nanoBTS
0x01 Multi-TRX nanoBTS
0x02 EDGE Multi-TRX nanoBTS
3.6 Manufacturer Extensions to existing O&M messages
The following sections describe extensions and modifications to the behaviour or allowed
use of the existing [GSM 12.21] O&M messages.
3.6.1 Set BTS Attributes
The Set BTS Attributes message may additionally include the Paging Configuration
Attribute (see section 3.3.16).
The Set BTS Attributes message may additionally include the Object Version Attribute
(see section 3.3.27). The Object Version may only be set prior to the OpStart of the
object.
The Set BTS Attributes message may additionally include the CGI Attribute (see section
3.3.25).
3.6.2 Set Alarm Thresholds
The Set Alarm Thresholds message has been removed, and its functionality replaced by
the Alarm Threshold List NV Attribute – see v0.13 of this specification for details.
© ip.access Ltd
- 66 -
3.6.3 Perform Test
The Physical Config attribute shall be mandatory in the Perform Test for all NWL tests.
3.6.4 Load Data Initiate
The mandatory SW Description may be ignored by an object if the File Data later
transferred to the object carries the SW Description (or equivalent information) embedded
within it.
3.6.5 Set Radio Carrier Attributes
The Set Radio Carrier Attributes message may additionally include the Object Version
Attribute (see section 3.3.27). The Object Version may only be set prior to the OpStart of
the object.
3.6.6 Set Channel Attributes
The Set Channel Attributes message may additionally include the Object Version Attribute
(see section 3.3.27). The Object Version may only be set prior to the OpStart of the
object.
3.6.7 State Changed Event Report
The State Changed Event Report may optionally include the Administrative State
Attribute, and shall be issued by and object when it autonomously transitions from the
Administrative Shutting Down state to the Locked state when the last service user ceases
to use the object service. It may be issued on any change of Administrative state – see
3.2.9.
3.6.8 SW Activated Report
The SW Activated Report of [GSM 12.21 section 8.3.6] may optionally include the
additional attribute Object Version (section 3.3.27), to inform the BSC of the capabilities of
the object just activated, and thus its configurational requirements. If omitted, the BSC
should assume only the basic capabilities of version 0 of the object, which conforms to a
previous version of this specification, prior to the introduction of this Object Version
attribute.
The Channel objects of 12.21 do not request SW Activation, and have no SW download
procedure, but shall be extended to additionally support the SW Activated Report.
3.6.9 Get Attributes Response
The Get Attributes Response message (which was originally unspecified in earlier
versions of [GSM 12.21]) uses a standard formatted O&M message (not the manufacturer
© ip.access Ltd
- 67 -
dependent message format), and contains an attribute for every element of the Attribute
List in the original Get Attributes message. If there are any attributes specified in the
Attribute List for which no attributes are returned, they shall be included in a Get Attributes
Response Info attribute, which shall only contain the count of non-reported attributes and
the attribute Ids of such non-reported attributes. The Attribute Response Info attribute is
conditionally included only if there are one or more such non-reported attributes. It shall
therefore be of the following format:

: :
Get Attribute Response Info 3.4.25 C TLV >=4
This is different from the format specified in the latest versions of [GSM 12.21, v5.0.0] in
that the reported attributes are each contained within the Get Attributes Response
message at the top level, not within the Get Attributes Response Info attribute of [GSM
12.21, v5.0.0].
Note: 12.21 is inconsistent about the detailed names: singular or plural Attribute(s) - it
uses Get Attributes and Get Attribute Response (and the same for the contained Get
Attribute Response Info). In this specification the plural is always used.
3.6.10 Measurement Procedure Nacks
The 12.21 v5.0.0 messages Measurement Results Request, Start Measurement ad Stop
Measurement have no defined corresponding Nack Message Types in section 9.1 of that
specification. These messages should be Nacked using the Message Type values defined
in 3.3.1 of this specification, but they shall be formatted as standard 12.21 message
Nacks (i.e. as a copy of the message being Nacked, with the Message Type changed to
the Nack value, and the addition of the Cause attribute on the end), rather than formatted
as a manufacturer-defined O&M message.
3.6.11 Load Data Abort
The Load Data Abort message of 12.21 v5.0.0 section 8.3.3 is extended as follows to
allow optional additional attributes to aid diagnostics reporting:
© ip.access Ltd
- 68 -
Message Type GSM 12.21 M V 1
section 9.1
Probable Cause 3.4.18 O TV 4
Additional Text 3.4.1 O TLV >=2
Additional Info 3.4.2 O TLV >=2
3.6.12 Reinitialise
The Reinitialise message of 12.21 v5.0.0 section 8.9.3 is clarified to be able to be sent
and thus received at any time, including during an elementary procedure of the same
object.
3.7 Manufacturer Extensions to existing O&M Attributes
The following sections describe extensions to the behaviour or allowed use of the existing
[GSM 12.21] O&M Attributes.
3.7.1 Autonomously Report
The Autonomously Report attribute used in the Perform Test message shall have the
additional codings:
Autonomously Report and maintain Test configuration 0x81
This coding may be used in the Perform Test message to instruct the BTS to perform the
test, Autonomously report on completion, and to maintain the test configuration to await a
follow-on test: in essence the test is still ongoing. Once the BTS has issued the only Test
Report (or final Test Report of a set of Test Reports – see section 3.4.16) at the end of the
actual test, the OMC may:
• issue a further Perform Test message, which completes the previous test and
initiates the new test, or
• issue a Stop Test message, which completes the previous test and returns the
BTS to the normal, non-test state.
If the BTS does not receive either of the above within the original Timeout value of the
test, the Test is silently aborted, and normal operation resumes.
3.7.2 Power Class
The Power Class attribute of the Radio Carrier object is a single octet, and is defined in
[GSM 12.21] as the binary representation of the Power Class value in [GSM 05.05], but
this specification uses the textural descriptions “M1”, “M2”, “M3”, and “P1” for the Micro-
and Pico-basestation power classes. This specification therefore defines this attribute as:
© ip.access Ltd
- 69 -
8 7 6 5 4 3 2 1
Class Power Class value 2
The Class field shall have the following values:

0. Normal BTS (a.k.a. Macro-BTS)
1. Micro-BTS
2. Pico-BTS
3. Reserved
The Power Class Value field shall be the binary representation of Power Class as defined
in [GSM 05.05], omitting the “M” or “P” prefix.
The P1 pico-BTS shall, for example, have the attribute value 0x81.
3.8 Object Model and Attribute Mapping
3.8.1 Object Model
The containment model of 12.21 is extended to support GPRS within the BTS as shown
below.
© ip.access Ltd
- 70 -
SITE
0 - NBTS
GPRS NSE
0 - 255 0 - NBTS 0 - 255 (NBTS)
0-1 1
GPRS NSVC GPRS Cell BTS
0 - 255 0 - 255
BBT RC
0-8
CHANNEL
Note: Each GPRS Cell must have an associated BTS (This is shown as the dotted line in
the above diagram. In effect any GPRS Cells are implicitly co-located with a BTS.
3.8.1.i GPRS NSE Object
The GPRS NSE object represents the termination of the NS link and the signalling BVC
for a set of cells (BTSs). It handles the management of the Gb link to the SGSN and the
management of the Gb stack (NS and BSSGP layers) within the NS Entity. The GPRS
NSE object has child NSVC objects to manage the NSVC aspects of the NS layer.
This object supports the Locked and Unlocked states of the Administrative State.
© ip.access Ltd
- 71 -
3.8.1.ii GPRS Cell Object
There may be one or more instances of the GPRS Cell object within the GPRS NSE, each
of which manages a single Cell which supports GPRS. The GPRS Cell object represents
the termination of a PTP-BVC at a single cell (BTS) that supports GPRS. If GPRS is
implemented in a cell there is therefore a 1-to-1 relationship between the GPRS Cell
Object and the 12.21 BTS object. Its primary purpose is to manage the air interface
aspects of GPRS for the cell.
3.8.1.iii GPRS NSVC Object
There may be one or more instances of this object within the NSE, each of which
manages a single NSVC for the NSE.
3.8.2 Object Attribute mappings
The following table describes the object model in terms of the attributes and procedures
which may be supported on each object. It is based on the [GSM 12.21] model but also
shows the changes introduced in this specification. Attributes which may only be
accessed through the Set/Get NV Attributes are marked (*). Attributes which may be
accessed through the Set/Get NV Attributes to set/get their default values, but may be
accessed through Get Attributes to get their current values are marked (#).
Object class Attributes Procedures/Messages

Site Availability Status Equipment Management
Manager HW Configuration Get Attributes
Manufacturer Dependent State Get NV Attributes
Manufacturer Dependent Thresholds Measurement Management
Manufacturer Id Set Site Outputs
Operational State Set NV Attributes
Site Inputs State Management and Event Report
Site Outputs SW Download Management
SW Configuration Test Management
Current SW Configuration Set Attributes
Object Version
Heartbeat Timeout
BTS Administrative State Equipment Management
Availability Status Get Attributes
BCCH ARFCN (Note 2) Measurement Management
BSIC (Note 1) Report Procedures
BTS Air Timer Set BTS Attributes
CCCH Load Ind. Period State Management and Event Report
CCCH Load Threshold SW Download Management
Connection Failure Criterion Test Management
GSM Time
HW Configuration
Intave Parameter
© ip.access Ltd
- 72 -
Interference Level Boundaries
Manufacturer Dependent State
Manufacturer Id
Max Timing Advance
Ny1
Operational State
Overload Period
RACH Busy Threshold
RACH Load Averaging Slots
SW Configuration
Current SW Configuration
T200
Paging Configuration
CGI (Note 1)
Object Version
Supported Features
© ip.access Ltd
- 73 -
Radio Carrier Administrative State Equipment Management
ARFCN List (Note 1) Get Attributes
Availability Status Measurement Management
HW Configuration Set Radio Carrier Attributes
Manufacturer Dependent State State Management and Event Report
Manufacturer Id SW Download Management
Operational State Test Management
Power Class
RF Max Power Reduction
SW Configuration
Object Version
Timing Bus
Timing Bus Control(*)
Supported Features
Baseband Administrative State Connect IP Signalling
Transceiver Availability Status Disconnect IP Signalling
HW Configuration Equipment Management
Manufacturer Dependent State Get Attributes
Manufacturer Id Get NV Attributes
Operational State Measurement Management
SW Configuration Set NV Attributes
Current SW Configuration(#) State Management and Event Report
Destination IP Address SW Download Management
Destination IP Port Test Management
Stream Identifier Set Attributes
NV Config Flags(#)
Frequency Control(*)
IP Interface Config(#)
IP Gateway Config(#)
In Service Time(#)
Primary OML Config(#)
Primary OML Config List(#)
Primary OML Fallback Timeout(#)
Secondary OML Config(#)
Location(#)
Unit Id(#)
Unit Name(#)
SNMP Config(#)
Alarm Threshold List(#)
Monitored Value List
Object Version
Supported Features
Heartbeat Timeout
Up Time
SSL Configuration(#)
Security Possible
IML SSL State
Revocation Date
Channel Administrative State Equipment Management
ARFCN List (Note 1) Get Attributes
Availability Status Measurement Management
Channel Combination (Note 1) Set Channel Attributes
HW Configuration State Management and Event Report
HSN (Note 1) SW Download Management
MAIO (Note 1) Test Management
© ip.access Ltd
- 74 -
Operational State
SW Configuration
TSC (Note 1)
Object Version
GPRS NSE Administrative State Equipment Management
HW Configuration Get NV Attributes
Current SW Configuration State Management and Event Report
Object Version Test Management
NSEI (Note 1) Set Attributes
NS Configuration
BSSGP Configuration
GPRS Cell Administrative State Equipment Management
BVCI (Note 1) Set Attributes
RAC (Note 1)
RLC Configuration
GPRS Paging Configuration
Supported Features
Coding Scheme Control
RLC Configuration 2
RLC Configuration 3
GPRS NSVC Administrative State Equipment Management
NSVCI (Note 1) Set Attributes
NS Link Configuration (Note 1)
Notes:
1. These attributes may only be modified whilst the object or one of its parent objects
is Administratively LOCKED, or by using the Starting Time attribute in the Set
message (if supported).
2. This attribute may only be modified whilst the object or one of its parent objects is
Administratively LOCKED, or all Radio Carriers which contribute to both the old
and the new BCCH ARFCN are Administratively LOCKED, or by using the Starting
Time attribute in the Set message (if supported).
© ip.access Ltd
- 75 -
3.9 Object Version Number Assignments
The following sections describe the behaviour of each version of the objects. The
descriptions are based on the overall mapping of attributes and procedures in the above
section.
3.9.1 Version Dependence common to all Object Classes
This section describes common aspects of the Version dependence of the object classes.
3.9.1.i Version 0
The Version 0 of all objects do not support the Object Version attribute, and no GPRS
objects are supported at version 0.
This version of objects is only capable of supporting a single BTS, with a single Baseband
Transceiver and Radio Carrier. The Radio Carrier shall be non-hopping.
This version of the object classes has support for the following messages. Unless
otherwise stated, the support of a message supports only those attributes which are listed
in the attribute table below, subject to the attribute restrictions listed. For messages
included in GSM 12.21, the support is as standard in GSM 12.21 v5.0.0 unless otherwise
stated.
Supported Procedures
Elementary Procedure Support Restrictions

Load Data Initiate See 3.6.4
Load Data Segment
Load Data Abort
Load Data End
SW Activate Request
Activate SW
SW Activated Report As GSM 12.21,not this specification
Set BTS Attributes See 3.6.1 of v0.13
Set Radio Carrier Attributes
Set Channel Attributes
Perform Test BTS and Radio Carriers only, see 3.6.3
Test Report BTS and Radio Carriers only
Send Test Report BTS and Radio Carriers only
Stop Test BTS and Radio Carriers only
State Changed Event Report See 3.6.7
Failure Event Report
Change Administrative State
OpStart
Reinitialise
Get Attributes See 3.6.9
Set Alarm Threshold Site Manager only, see 3.6.2 of v0.13
Connect IP Signalling
Set Default SW See 3.2.5 of v0.13
© ip.access Ltd
- 76 -
Set NV Attributes Site Manager only
Get NV Attributes Site Manager only
Supported Attributes
Attribute Support Restrictions

Additional Text See 3.4.2
Administrative State
ARFCN List Only a single entry supported
Autonomously Report See 3.7.1 – only values 0x01 and 0x81 are supported.
Availability Status
BCCH ARFCN
BSIC
BTS Air Timer
Channel Combination See Channel object restrictions
Connection Failure Criterion Only the Criterion “Radio Link Timeout” is supported
Event Type See 3.4.3
File Data See 3.4.4
File Id See 3.4.5
File Version See 3.4.6
HW Configuration
HW Description See 3.4.7, v0.13
Intave Parameter
Interference Level Boundaries
List of Required Attributes See 3.4.8, restricted by this table
Manufacturer Dependent Thresholds See 3.4.10 of v0.13
Manufacturer Id See 3.4.11
Max Timing Advance Only on Long Range Capable BTSs
Nack Causes
NY1
Operational State
Physical Config See 3.4.13
Power Class See 3.7.2
Probable Cause See 3.4.18 v0.14
RF Max Power Reduction
T200
Test Duration See 6.5.1
Test No See 3.4.15- only manufacturer range (0x40-0x44) supported.
Test Report Info See 3.4.16
Window Size
TSC
SW Configuration
SW Description
Perceived Severity See 3.4.17
Destination IP Address Baseband Transceiver object class only
Destination IP Port Baseband Transceiver object class only
Stream Identifier
NV Config Flags See 3.3.9, v0.13
Frequency Control
Primary OML Config
Secondary OML Config
IP Interface Config
IP Gateway Config
In Service Time
Location
© ip.access Ltd
- 77 -
Paging Configuration
Unit Id See A-bis over IP v0.13
Parent Unit Id See A-bis over IP v0.13
Unit Name
Supported Embedded IEs
Embedded IE Support Restrictions

ARFCN Whitelist
ARFCN Blacklist
Frequency Error List
Channel Usage List
BCCH Information Type
BCCH Information
RXLEV Threshold
Frequency Sync Options Freq Config field not supported.
MAC Address
HW-SW Compatibility Number
Manufacturer Serial Number
OEM Id
Date and Time of Manufacture
Date and Time of Calibration
Beacon Information
Frequency Error
3.9.1.ii Version 1
The Version 1 of all objects add support for the Object Version attribute and for Version 1
GPRS objects.
Transceiver and Radio Carrier, optionally supporting GPRS. The Radio Carrier shall be
non-hopping. There shall be a single GPRS NSE object, single GPRS Cell object and up
to two GPRS NSVC objects supported.
This version of the object classes has support for the following changes to Version 0 of
the messages and attributes, as defined in the following tables.
Supported Procedures – Changes since Version 0

SW Activated Report See 3.6.8, Added Object Version
Set BTS Attributes See 3.6.1, Added Object Version
Set Radio Carrier Attributes See 3.6.5, Added Object Version
Set Channel Attributes See 3.6.6, Added Object Version
Set Alarm Threshold Removed – see Alarm Threshold List attribute
Set Default SW Removed – see Current SW Configuration attribute
Set NV Attributes Baseband Transceiver only (was Site Manager), added NV
attributes
Get NV Attributes Baseband Transceiver only (was Site Manager), added NV
attributes
Set Attributes New
© ip.access Ltd
- 78 -
Get Attributes Updated in line with changes to Supported Attributes (below)
Supported Attributes – Changes since Version 0

Additional Info New
Channel Combination Addition of Full BCCH and SDCCH/8 – see 3.9.6.
CCCH Load Indication New
CCCH Load Threshold New
HW Description See 3.4.7, additional embedded IEs
List of Required Attributes See 3.4.8, restricted by this table
Manufacturer Dependent Thresholds Removed – see Alarm Threshold List attribute
Overload Period New
Probable Cause See 3.4.18 updated for GPRS
Perceived Severity Logged values now deprecated - See 3.4.17
NV Config Flags See 3.3.9 NV Alarm Threshold & TFTP controls removed
Primary OML Config Removed – see Primary OML Config List
Unit Id Modified Format – see 3.3.17
Parent Unit Id Removed
SNMP Config New
Primary OML Config List New, maximum of 2 entries supported
Primary OML Fallback Timeout New
Current SW Configuration New
CGI New
RAC New
Object Version New
GPRS Paging Configuration New
NSEI New
BVCI New
NSVCI New
NS Configuration New
BSSGP Configuration New
NS Link Configuration New
RLC Configuration New
Alarm Threshold List New – replaces Set Alarm Thresholds
Monitored Value List New – replaces Manufacturer Defined Thresholds
Supported Embedded IEs – Changes from Version 0

SNMP Community String New
SNMP Trap Address New
SNMP Trap Port New
SNMP Manager Address New – single address supported.
SNMP System Contact New
Factory Id New
Factory Serial Number New
Logged Event Indicator New
3.9.1.iii Version 2
Transceiver and Radio Carrier, optionally supporting GPRS. The Radio Carrier shall be
© ip.access Ltd
- 79 -
non-hopping. There shall be a single GPRS NSE object, single GPRS Cell object and up
to two GPRS NSVC objects supported.

Measurement Result Request New
Measurement Result Response New
Stop Measurements New
Start Measurements New

Channel Combinations Addition of Dynamic PDCH support – see 3.9.6.
Measurement Result New
Measurement Type New

None None
3.9.1.iv Version 4
The Version 4 of all objects add support for the GPRS Coding Scheme Control.

Set Attributes (GPRS Cell) See 3.3.40, Added Coding Schemes (CS1-4 only)

Coding Scheme Control New (CS1-4 only)
© ip.access Ltd
- 80 -
3.9.1.v Version 20
The Version 20 of all objects add support for the multiple Baseband Transceivers and
their associated Radio Carriers, optionally supporting GPRS on C0. The Radio Carrier
shall be non-hopping. There shall be a single BTS, up to four Baseband Transceivers and
their associated Radio Carriers and set of Channel objects, a single GPRS NSE object,
single GPRS Cell object and up to two GPRS NSVC objects supported.

Set Attributes (GPRS Cell) Added RLC Configuration 2
Set Radio Carrier Attributes Added Timing Bus Control
SW Deactivate New

Timing Bus Control New
Timing Bus New
Supported Features New
RLC Configuration 2 New
Up Time New

Frequency Bands New
Max Timing Advance New
Ciphering Algorithms New
Channel Types New
Channel Modes New
GPRS Coding Schemes New
RTP Features New
RSL Features New
3.9.1.vi Version 30
The Version 30 of all objects has the same overall object instance support as for version
20.
© ip.access Ltd
- 81 -
Set Attributes (GPRS Cell) Added RLC Configuration 3

Channel Combination Addition of support for Dynamic TCH/F and TCH/H channel
HW Description Addition of BTS Hardware Class and Frequency Bands
RLC Configuration 3 New
BCCH ARFCN Modified restriction as to when it may be Set

BTS Hardware Class New
3.9.1.vii Version 35

Get NV Attributes Added SSL Configuration
Set NV Attributes Added SSL Configuration

SSL Configuration New
Security Possible New
IML SSL State New
Revocation Date New
RTP Features Additional RTP features defined
File Id Addition of bank control

None None
3.9.1.viii Unsupported features
This section lists the Procedures, Attributes and embedded IEs which are not yet
supported by any version of the objects.
Unsupported Procedures
© ip.access Ltd
- 82 -
Establish TEI
Connect Terrestrial Signalling
Disconnect Terrestrial Signalling
Connect Terrestrial Traffic
Disconnect Terrestrial Traffic
Connect Multi-Drop Link
Disconnect Multi-Drop Link
Stop Sending Event Reports
Restart Sending Event Reports
Change Administrative State Request
Report outstanding Alarms
Changeover
Set Site Outputs
Change HW Configuration
Disconnect IP Signalling
Attribute Value Change Report
Deactivate SW
Unsupported Attributes

Abis Channel
Destination
GSM Time
Heartbeat Timeout
HSN
HW Conf Change Info
MAIO
Manufacturer Dependent State
Multi-drop BSC Link
Multi-drop next BTS Link
Outstanding Alarm Sequence
Power Output Thresholds
RACH Busy Thresholds
RACH Load Averaging Slots
Radio Sub Channel
Site Inputs
Site Outputs
Source
Specific Problems
Starting Time
TEI
VSWR Thresholds
Unsupported Embedded IEs

Configuration
Results Details
Localised Additional Text Information
© ip.access Ltd
- 83 -
3.9.2 Site Manager
3.9.2.i Version 0
This version of the Site Manager supports all NV attributes (later moved to the Baseband
Transceiver object class).
3.9.2.ii Version 1
This version of the Site Manager no longer supports NV attributes (moved to the
Baseband Transceiver object class).
3.9.3 BTS
3.9.3.i Version 0
This version of the BTS supports the Network Listen Tests (see 6.5).
3.9.4 Baseband Transceiver
3.9.4.i Version 1
This version of the Baseband Transceiver object supports NV attributes (moved from the
Site Manger Version 0).
3.9.5 Radio Carrier
No version specific behaviour other than the general changes listed above.
3.9.6 Channel
3.9.6.i Version 0
This version of the Channel only supports the following Channel Combinations:
• Timeslot 0: Combined BCCH (optionally with CBCH)
• Timeslots 1-7: TCH/F.
3.9.6.ii Version 1
• Timeslot 0: Combined BCCH (optionally with CBCH) or Full BCCH
• Timeslots 1-7: SDCCH/8 (optionally with CBCH if timeslot 0 is Full BCCH), TCH/F
or PDCH.
© ip.access Ltd
- 84 -
3.9.6.iii Version 2
• Timeslots 1-7: SDCCH/8 (optionally with CBCH if timeslot 0 is Full BCCH), TCH/F,
PDCH, or dynamic PDCH or TCH/F.
3.9.6.iv Version 4
• Timeslot 1: SDCCH/8 (optionally with CBCH if timeslot 0 is Full BCCH), or the
same options as timeslots 2-7 below.
• Timeslots 2-7: TCH/F, PDCH, or dynamic PDCH or TCH/F.
3.9.6.v Version 20
First Baseband Transceiver (C0):

• Timeslots 2-7: TCH/F, PDCH, or dynamic PDCH or TCH/F.
Second and subsequent Baseband Transceivers (Cn):

• Timeslot 1: SDCCH/8, or the same options as timeslots 2-7 of C0 above.
• Timeslots 0, 2-7: the same options as timeslots 2-7 of C0 above.
3.9.6.vi Version 30
First Baseband Transceiver (C0):

• Timeslots 2-7: TCH/F, 2*TCH/H, PDCH, dynamic PDCH or TCH/F, or dynamic
TCH/F or 2*TCH/H.
Second and subsequent Baseband Transceivers (Cn):

• Timeslot 1: SDCCH/8, or the same options as timeslots 2-7 of C0 above.
• Timeslots 0, 2-7: the same options as timeslots 2-7 of C0 above.
© ip.access Ltd
- 85 -
3.9.7 GPRS NSE
No version 0 existed, and no version specific behaviour other than the general changes
listed above.
3.9.8 GPRS Cell
listed above.
3.9.9 GPRS NSVC
listed above.
© ip.access Ltd
- 86 -
4 RSL SIGNALLING MESSAGES
The RSL messages shall be as defined in [GSM 08.58], subject to the manufacturer
dependencies defined in this specification.
All information elements and embedded information elements in messages shall be

transmitted in the order specified in the message definition tables below.
4.1 RSL Message Formats and Contents
The RSL messages shall be as defined in [GSM 08.58 section 8], except for the
extensions to support the A-bis over IP functionality defined in the following sub-sections.
4.1.1 Create Connection
A new CREATE CONNECTION message shall be supported with the following

information elements:
Message Discriminator 4.2.12 M V 1

Message Type 4.2.13 M V 1
Channel Number [GSM 08.58 M TV 2
sec 9.3.1]
IP Speech Mode 4.2.5 O TV 2
RTP Payload Type 4.2.7 O TV 2
RTP CSD Format 4.2.21 O TV 2
RTP Jitter Buffer Control 4.2.25 O TV 3
RTP Compression Control 4.2.26 O TV 3
RTP Payload Type 2 4.2.27 O TV 2
Multiplex Connection ID 4.2.30 O TV 2
BSC Proxy UDP Port 4.2.32 C TV 3
BTS Proxy Keep Alive Timeout 4.2.33 C TV 2
This message is sent by the BSC to request that the BTS creates a connection between
the specified Radio Channel and an RTP stream on the IP interface. If included, the IP
Address and IP Port information elements specify the destination of the RTP traffic stream
for the connection being created. If no Destination IP Address and Destination IP Port
value are supplied, any data arriving from the radio channel shall be discarded. A
destination IP address of 0.0.0.0 instructs the Baseband Transceiver to open the
connection to the same address as used for the RSL connection. If included, the RTP
© ip.access Ltd
- 87 -
Payload Type or RTP Payload Type 2 IE defines the dynamic PT value assigned by the
peer to be used by the BTS in the RTP packets it sends to the peer, and in the case of the
RTP Payload Type IE, by the peer to the BTS – see sections 4.2.7 and 4.2.27 for further
details. Only one or none of these two IEs may be included. The RTP payload IE is
deprecated, and should not be used.
The presence of the Multiplex Connection ID instructs the BTS to include the call over the
specified multiplex connection. If the Multiplex Connection ID is present then the BSC
Proxy UDP port and the BTS Proxy Keep Alive Timeout are mandatory IEs. If the
Multiplex Connection ID is not present then the BSC Proxy UDP Port and the BTS Proxy
Keep Alive Timeout are not permitted.
When using multiplex connections, the destination IP address and port specify the final
destination of the RTP stream, and the BSC Proxy UDP port specifies the source UDP
port used on the BSC Proxy when sending the RTP stream to the final destination. The
BTS Proxy keep alive timeout specifies the maximum period of inactivity for the RTP
stream as specified in [PROXY_FD].
For the behaviour when other optional IEs are omitted, see the relevant IE section listed
above.
4.1.2 Create Connection Acknowledge
A new CREATE CONNECTION ACK message shall be supported with the following

sec 9.3.1]
Connection Id 4.2.20 M TV 3
Source IP Port 4.2.4 C TV 3
Source IP Address 4.2.6 C TV 5
RTP Payload Type 2 4.2.27 C TV 2
This message is sent by the BTS to confirm the creation of the connection, and returns
the Connection Id allocated by the BTS which is used to identify this connection in future
messages. For non-multiplexed connections, it also specifies the source IP port and the
source IP address selected by the BTS to carry the RTP traffic stream for the connection
being created. For multiplexed connections the source IP address and port are not
included.
The RTP Payload Type 2 should be included if the Create Connection did not include the
RTP Payload Type IE (even if it did include the RTP Payload Type 2 IE) and the codec
used on the connection is not the GSM FR codec, which has a static IANA assigned
Payload Type of 3. It specifies the Payload Type that the peer should use in the RTP
© ip.access Ltd
- 88 -
stream to the BTS, which should be from the IANA dynamic PT range – see 4.2.27 for
further details.
4.1.3 Create Connection Negative Acknowledge
A new CREATE CONNECTION NACK message shall be supported with the following

sec 9.3.1]
Cause 4.2.14 M TLV >=3
This message is sent by the BTS to reject the creation of the connection for the specified
Cause. The Destination IP Address and Destination IP Port are included if they were
included in the CREATE CONNECTION message being negatively acknowledged.
4.1.4 Modify Connection
A new MODIFY CONNECTION message shall be supported with the following information
elements:

sec 9.3.1]
Connection Id 4.2.20 O TV 3
IP Speech Mode 4.2.5 O TV 2
RTP Payload Type 4.2.7 O TV 2
RTP CSD Format 4.2.21 O TV 2
RTP Jitter Buffer Control 4.2.25 O TV 3
RTP Compression Control 4.2.26 O TV 3
This message is sent by the BSC to request that the BTS modifies the parameters of the
existing connection between the specified Radio Channel and the specified RTP stream
destination. If the Connection Id is omitted, all connections to the specified Channel
Number are modified. If included, only the specified connection, which must already exist,
is modified. The other optional IEs shall have the same meanings as their usage in Create
Connection, treat their controls as being unmodified from their current values if omitted.
© ip.access Ltd
- 89 -
The RTP Payload Type IE may only be included if it was included in the original Create
Connection. The RTP Payload Type 2 IE may not be included if this or the Create
Connection included the RTP Payload Type IE.
Note that it is not possible to modify a connection to switch from using a multiplex
connection to not using a multiplex connection or vice-versa. It is also not possible to
modify a connection to move it from one multiplex connection to another multiplex
connection.
4.1.5 Modify Connection Acknowledge
A new MODIFY CONNECTION ACK message shall be supported with the following

sec 9.3.1]
Source IP Port 4.2.4 C TV 3
Source IP Address 4.2.6 C TV 5
This message is sent by the BTS to confirm the modification to the connection. The
Connection Id is included if it was included in the MODIFY CONNECTION message being
acknowledged. The Source IP Port and Source IP Address IEs shall be individually
included if their respective values have been changed as a result of the Modify
Connection, and have the same meanings as when included in the Create Connection
Acknowledge. For multiplexed connections the source IP address and port are not
included.
The RTP Payload Type 2 IE shall be included if the Payload Type value is changed as a
result of the Modify Connection, which it should be if the Modify Connection includes a
change of Speech Codec or CSD data rate (or a change between CSD and speech or
vice-versa). The RTP Payload Type 2 IE may not be included if this or the Create
Connection included the RTP Payload Type IE.
4.1.6 Modify Connection Negative Acknowledge
A new MODIFY CONNECTION NACK message shall be supported with the following
© ip.access Ltd
- 90 -
sec 9.3.1]
This message is sent by the BTS to reject the modification to the connection for the
specified Cause. The Connection Id is included if it was included in the MODIFY
CONNECTION message being negatively acknowledged.
4.1.7 Delete Connection Indication
A new DELETE CONNECTION IND message shall be supported with the following

sec 9.3.1]
Connection Id 4.2.20 M TV 3
Connection Statistics 4.2.8 M TV
This message may be sent by the BTS to inform the BSC that the connection between the
specified Radio Channel and the specified RTP stream destination has been deleted for
the specified Cause. The Connection Statistics IE provides the RTP statistics for the
connection being deleted. If more than one connection has been deleted, there shall be a
separate message for each such connection.
4.1.8 Delete Connection
A new DELETE CONNECTION message shall be supported with the following information
elements:

sec 9.3.1]
This message may be sent by the BSC to request that the BTS deletes the existing
connection between the specified Radio Channel and the specified RTP stream
destination. If the Connection Id is omitted, all connections to the specified Channel
Number are deleted. If included, only the specified connection, which must already exist,
is deleted.
© ip.access Ltd
- 91 -
4.1.9 Delete Connection Acknowledge
A new DELETE CONNECTION ACK message shall be supported with the following

sec 9.3.1]
Connection Statistics 4.2.8 C TV
This message is sent by the BTS to confirm the deletion of the connection. The
Connection Id is included if it was included in the DELETE CONNECTION message being
acknowledged.
The Connection Statistics IE provides the RTP statistics for the connection being deleted.
If the Connection Id IE is omitted, the Connection Statistics IE shall also be omitted,
otherwise it shall be included.
4.1.10 Delete Connection Negative Acknowledge
A new DELETE CONNECTION NACK message shall be supported with the following

sec 9.3.1]
This message is sent by the BTS to reject the deletion of the connection for the specified
Cause. The Connection Id is included if it was included in the DELETE CONNECTION
message being negatively acknowledged.
4.1.11 Measurement Pre-processing Defaults
A new MEASUREMENT_PREPROCESSING_DEFAULTS message shall be supported

as a (extended) TRX Management message, with the following information elements:
© ip.access Ltd
- 92 -
MS Power GSM 08.58 C TV 2
9.3.13
BS Power 4.2.9 C TV 2
MS Power Parameters 4.2.15 O TLV >=2
BS Power Parameters 4.2.16 O TLV >=2
Pre-processing Parameters 4.2.17 C TLV >=3
This message shall be sent on every RSL, and shall be applied to all TRXs which receive
their signalling through that RSL.
In the following descriptions, “xS” shall denote that the description is applied to both the
BS and MS.
The inclusion of the xS Power IE indicates maximum xS power that may be applied by xS
Power control within the BTS, which shall also be the maximum xS Power that may be
applied by default on all new connections to the TRX(s). If it is not included, xS Power
control may still be supplied with default configuration with the xS Power Parameters IE,
but shall be disabled by default on all new connections to the TRX(s), until a enabled on
that connection by the Channel Activation or subsequent xS Power Control message on
that connection.
Note that a default MS Power cannot take into consideration the MS Power class. The MS
Power IE which is supplied on a specific connection (either in an MS Power Control
message or in the Channel Activation message) shall carry the maximum power capability
of the MS, as dictated by its power class. The BTS shall then use the lower of the default
MS Power value and the connection specific MS Power value as the maximum power to
which the MS Power may be commanded by the BTS. The connection specific MS Power
value may also be used in handover determination as the maximum power which that MS
may use in other cells (subject also to the default maximum in those cells).
As the complete set of default configuration may be large, a set of several such messages
may be sent on each link, each containing part of the total default configuration, subject to
the following limitations (which only apply if multiple messages are sent):
1. If any of the MS Power, MS Power Parameters, BS Power, BS Power Parameters

IEs are required, they shall be included in the first message only, which shall then
not contain the Pre-processing Parameters IE.
2. All subsequent messages of the set shall carry the Pre-processing Parameters IE,
and the P bit of this IE shall be “1”.
3. A set of messages shall be terminated by a final message containing only a
minimally sized Pre-processing Parameters IE of length 3 octets.
Note:
© ip.access Ltd
- 93 -
a) To disable default measurement pre-processing, the only a minimally sized Pre-
processing Parameters IE of length 3 octets is required, and the set of multiple
messages shall not be used.
b) A single message may be used to set the default configuration, containing (if
required) the xS Power and/or xS Power Parameters together with the complete
Pre-processing Parameters IE.
c) The effects of the IEs included in this message (and when overridden by the same
IEs contained in the dedicated channel messages) is only partially cumulative:
inclusion of an Embedded IE in this IE completely replaces the configuration
supplied by the same Embedded IE type in a previous message, but does not
affect the configuration supplied in other Embedded IEs in previous message.
4.1.12 Directed Retry Enquiry
A new DIRECTED_RETRY_ENQUIRY message shall be supported as a (extended)

Dedicated Channel Management message, with the following information elements:

Channel Number GSM 08.58 M TV 2
9.3.1
On receipt of this message for the dedicated channel:
1. If the BTS has stored measurement results from the MS for at least T_dr_min, it
will respond immediately with a candidate list ranked according to the normal pre-
processing handover candidate rules in a Pre-Processed Measurement Results
message with the Handover Cause “Enquiry” included.
2. If the BTS has no stored measurement results from the MS it shall start a Directed
Retry timer T_dr_max.
3. On receipt of a measurement report(s) for a duration of at least T_dr_min from the
MS with any candidates whilst the Directed Retry timer is running, the BTS shall
send the Pre-Processed Measurement Results message as above, and stop the
timer.
4. If the Directed Retry timer expires, the BTS shall send a Pre-Processed
Measurement Results message to the BSC with the Cause “Enquiry Failed”
included, and no candidate list.
5. If any further Directed Retry Enquiry messages are received whilst the timer is
running, the Directed Retry timer should be restarted.
6. If the normal pre-processing of measurements results in the need for a handover
fo causes other than Power Budget whilst the Directed Retry timer is running, the
BTS shall send a Pre-Processed Measurement Results message to the BSC with
the Causes determeined by the measurement pre-processing, and the Cause
Directed Retry, and shall stop the Directed Retry timer.
If this message is received when measurement pre-processing is not enabled on the

connection, it shall be ignored.
© ip.access Ltd
- 94 -
4.1.13 Handover Candidate Enquire
A new HANDOVER_CANDIDATE_ENQUIRE message shall be supported as a

(extended) TRX Management message, with the following information elements:

Handover Candidate Parameters 4.2.19 M TLV >=4
On receipt of this message:

• The TRX shall select the MSs which may be handed over to any cell in the
supplied Destination Cell List (or to any cell if this Destination Cell List is
unspecified).
• For those MSs selected for which the Handover Required Timer is not running, the
TRX shall immediately send a Preprocessed Measurement Results with cause
“Enquiry”, and shall NOT start the Handover Required Timer
• For those MSs selected for which the Handover Required Timer is running, the
TRX shall at the next expiry of the timer send a Preprocessed Measurement
Results with cause “Enquiry” as the primary cause, together with any other causes
which apply in their normal order, and shall restart the Handover Required Timer if
any other causes are included.
• On completion of sending of the Preprocessed Measurement Results for all the
selected MSs, the TRX shall also send a Handover Candidate Response
message, indicating the number of MSs for which Preprocessed Measurement
Results have been sent as a result of the Handover Candidate Enquire.
4.1.14 Handover Candidate Response
A new HANDOVER_CANDIDATE_RESPONSE message shall be supported as a

(extended) TRX Management message, with the following information elements:

Handover Candidate Parameters 4.2.19 M TLV >=4
This message is sent in response to the Handover Candidate Enquire message, and
contains the number of MSs for which Preprocessed Measurement Results have been
sent as a result of the Handover Candidate Enquiry.
4.1.15 Paging Command
The [GSM 08.58 v8.4.0 section 8.5.5] Paging Command should conditionally include a
second MS Identity IE after the standard optional IEs defined in that specification. This MS
Identity shall be of identical format to the standard MS Identity IE of [GSM 08.58 v8.4.0
© ip.access Ltd
- 95 -
section 9.3.12] except that it shall only carry the IMSI of the MS being paged, and should
be included if the mandatory MS Identity IE contains a TMSI.
This is to allow a BTS-based GPRS PCU to route the paging message over the packet
channels for MSs which are currently in a TBF.
4.1.16 PDCH Activation
A new PDCH Activation message shall be supported with the following information
elements:

Channel Number 4.2.22 M TV 2
This message requests that the BTS activates a currently idle channel which has a
Channel Combination provisioned as dynamically switchable between TCH and PDCH
(see 3.4.19) as a PDCH. It may be issued by the BSC at any time after connection of the
RSL from the TRX. Loss of the RSL shall cause both the BTS and the BSC to locally
deactivate the channel as a PDCH, and thus require this message to be sent again on
RSL reconnection if the Channel is to be reactivated as a PDCH.
4.1.17 PDCH Activation Ack
A new PDCH Activation Ack message shall be supported with the following information
elements:

Frame Number [GSM 08.58 M TV 3
section 9.3.8]
This message shall be used by the BTS to acknowledge that it has successfully
completed activation of the channel as a PDCH of the type determined by the Channel
Number.
The Frame Number element is used by BSC to calculate the Starting Time parameter
when required.
The indicated Channel Number shall remain active as a PDCH until deactivated through a
PDCH Deactivation procedure.
© ip.access Ltd
- 96 -
4.1.18 PDCH Activation Nack
A new PDCH Activation Nack message shall be supported with the following information
elements:

This message shall be used by the BTS to indicate that it was unable to perform the
PDCH Activation requested.
4.1.19 CCCH Load Indication
The [GSM 08.58, section 8.5.2] CCCH Load Indication shall be extended to include
indication of Paging Load below threshold, using the special value of the Paging Load IE
defined in 4.2.24. This indication of Paging Load below threshold shall be issued at the
end of a CCCH Load Indication Period which started above the CCCH Load Indication
Threshold, but is now below the CCCH Load Indication Threshold.
4.1.20 PDCH Deactivation
A new PDCH Deactivation message shall be supported with the following information
elements:

This message requests that the BTS deactivates a currently active PDCH channel which
has a Channel Combination provisioned as dynamically switchable between TCH and
PDCH (see 3.4.19). It may be issued by the BSC at any time after PDCH Activation.
4.1.21 PDCH Deactivation Ack
A new PDCH Deactivation Ack message shall be supported with the following information
elements:

This message shall be used by the BTS to acknowledge that it has successfully
completed deactivation of the PDCH channel determined by the Channel Number.
© ip.access Ltd
- 97 -
The indicated Channel Number shall remain idle until activated as a TCH or PDCH
through a Channel Activation or PDCH Activation procedure respectively.
4.1.22 PDCH Deactivation Nack
A new PDCH Deactivation Nack message shall be supported with the following

This message shall be used by the BTS to indicate that it was unable to perform the
PDCH Deactivation requested.
4.1.23 Create Multiplex Connection
This message is sent by the BSC to create a multiplex connection between the BTS and
the BSC Multiplexer.

Multiplex Connection ID 4.2.30 M TV 2
Destination IP Address 4.2.2 M TV 5
Destination IP Port 4.2.3 M TV 3
Multiplex Control 4.2.29 M TV 9
BTS Multiplexer Keep-Alive Timeout 4.2.33 M TV 2
SRTP Configuration 4.2.31 O TLV >=61
The presence of the SRTP configuration IE instructs the BTS to create a secure multiplex
connection defined by the parameters in the SRTP configuration. A destination IP address
of 0.0.0.0 instructs the Baseband Transceiver to open the Multiplex Connection to the
same address as used for the RSL connection.
4.1.24 Create Multiplex Connection Ack
This message is sent by the BTS to acknowledge the creation of a new multiplex
connection.

© ip.access Ltd
- 98 -
4.1.25 Create Multiplex Connection Nack
This message is sent by the BTS to reject the creation of a new multiplex connection.

Possible cause values are:

• Connection already exists
• Optional feature not supported (if RTP multiplexing is not supported)
4.1.26 Delete Multiplex Connection
This message is sent by the BSC to instruct a BTS to delete the multiplex connection
specified by the Multiplex Connection ID.

4.1.27 Delete Multiplex Connection Ack
This message is sent by the BTS to acknowledge that the specified connection has been
deleted.

4.1.28 Delete Multiplex Connection Nack
This message is sent by the BTS if the specified multiplex connection could not be
deleted.


• Connection invalid (If the specified multiplex connection does not exist)
• Connection In Use
© ip.access Ltd
- 99 -
4.1.29 Modify Multiplex Connection
This message is sent by the BSC to modify an existing multiplex connection.

Destination IP Address 4.2.2 M TV 5
Destination IP Port 4.2.3 M TV 3
Multiplex Control 4.2.29 M TV 9
BTS Multiplexer Keep-Alive Timeout 4.2.33 M TV 2
Note that it is not possible to modify the SRTP configuration.
4.1.30 Modify Multiplex Connection Ack
This message is sent by the BTS to acknowledge that the specified connection has been
modified.

4.1.31 Modify Multiplex Connection Nack
This message is sent by the BTS if the specified multiplex connection could not be
modified.


• Connection invalid (If the specified multiplex connection does not exist)
4.2 RSL Information Elements
The Information Elements of the RSL messages shall be as defined in [GSM 08.58
section 9], except for the extensions to support the A-bis over IP functionality defined in
the following sub-sections.
Some of the [GSM 08.58] information elements include manufacturer-defined variable

length fields. The use of these fields is defined below. In general they contain one of more
“embedded information elements”, which are defined in section 4.3.
© ip.access Ltd
- 100 -
4.2.1 RSL Manufacturer-Defined Identifiers
The Manufacturer-Defined Identifier octet in the RSL message information elements is

coded with the following hexadecimal values:
Destination IP Address 0xF0

Destination IP Port 0xF1
RTP Payload Type 0xF2
Source IP Port 0xF3
IP Speech Mode 0xF4
Source IP Address 0xF5
Connection Statistics 0xF6
Handover Candidate Parameters 0xF7
Connection Id 0xF8
RTP CSD Format 0xF9
RTP Jitter Buffer Control 0xFA
RTP Compression Control 0xFB
RTP Payload Type 2 0xFC
Multiplex Control 0xFD
Multiplex Connection ID 0xFE
Value 0xFF is specified as “Not Used” by 08.58.
SRTP Configuration 0xE0

BSC Proxy UDP Port 0xE1
BTS Proxy Keep Alive Timeout 0xE2
4.2.2 Destination IP Address
See section 3.3.3 above.
4.2.3 Destination IP Port
See section 3.3.4 above.
4.2.4 Source IP Port
Manufacturer-Defined Identifier 1
Source IP Port 2-3
This information element is used by the BTS to inform the BSC of the IP Port number
assigned by the BTS for the RTP stream.
© ip.access Ltd
- 101 -
4.2.5 IP Speech Mode
This information element is used by the BSC to configure the format of the speech traffic
data in the RTP traffic streams. It may only be included if the GSM Channel Mode
indicates that the channel is carrying speech. The Speech Mode codec field shall match
that of the GSM Channel Mode unless the BTS supports speech transcoding.
The IP Speech Mode information element is defined as:
8 7 6 5 4 3 2 1
Reserved M S 2
The S bits control the speech codec format to be used in the RTP stream, and have the
following codings:
S bits Codec
0000 GSM FR codec (GSM type 1, FS)
0001 GSM EFR codec (GSM type 2, FS)
0010 GSM AMR/FR codec (GSM type 3, FS)
0011 GSM HR codec (GSM type 1, HS)
0100 Reserved
0101 GSM AMR/HR codec (GSM type 3,HS)
0110- Reserved
1110
1111 As specified by RTP Payload Type IE
The coding “1111” requires the use of a IANA assigned standard Payload Type value in
the RTP Payload Type IE, and requires the BTS to transcode the speech traffic to the
specified media format.
The M bits control the RTP stream mode, and have the following codings:
M bits Mode
00 Send and Receive
01 Receive Only
10 Send Only
11 Reserved
If this information element is omitted, the IP media stream uses the same codec type as
used for the air interface (as defined in the Channel Mode information element), and the
stream shall be in Send and Receive mode.
© ip.access Ltd
- 102 -
4.2.6 Source IP Address
Source IP Address 2-5
This information element is used by the BTS to inform the BSC of the IP Address of the
interface carrying the RTP stream. If this IE is omitted, the IP address used shall be that of
the RSL interface.
4.2.7 RTP Payload Type
Use of this IE is deprecated –see RTP Payload Type 2 IE (section 4.2.27).
8 7 6 5 4 3 2 1
R RTP Payload Type 2
This information element is used by the BSC to configure the RTP payload and Payload
Type value to be included in the RTP streams both to and from the BTS. It may be omitted
for a Channel Mode indicating a standard GSM FR codec type, as this already has an
IANA assigned static Payload Type of 3.
It (or the RTP Payload Type 2 IE) should be included for all other RTP stream payload
formats, and should be in the IANA dynamic PT range.
The R bit is reserved.
Note: This IE is replaced by the RTP Payload Type 2 IE (section 4.2.27) for controlling the
use of asymmetric dynamically assigned Payload Type values. This RTP Payload Type IE
may still be used by the BSC in the Create Connection to the BTS if the Payload Type
value to be used by the BTS must be fixed and used in both the sending and receiving
RTP streams.
4.2.8 Connection Statistics
Length (= 28) 2
Number of Packets Sent 3-6
Number of Octets Sent 7-10
Number of Packets Received 11-14
Number of Octets Received 15-18
Number of Packets Lost 19-22
Inter-arrival Jitter 23-26
Average Transmission Delay 27-30
© ip.access Ltd
- 103 -
This information element is used by the BTS to inform the BSC of the RTP Connection
Statistics for a connection. The detailed definitions of these parameters may be found in
[RFC 1889].
4.2.9 BS Power
The BS Power information element defined in [GSM 08.58 section 9.3.4] shall have the
following modified structure:
8 7 6 5 4 3 2 1
BS Power Element Identifier (= 0x04) 1
Reserved FPC Power Level 2
The FPC bit shall be as defined in [GSM 08.58 v8.4.0].
The coding for Power Level shall be:
Value Power Level

0000 Pn
0001 Pn – 2 dB
0010 Pn – 4 dB
1110 Pn – 28dB
1111 Receive Only
The value of “Receive Only” is an extension to support dedicated channel monitoring in

BTSs which can support the downlink Network Listen functionality.
4.2.10 Physical Context
The Physical Context information element defined in [GSM 08.58 section 9.3.16] shall
have the following structure:
8 7 6 5 4 3 2 1
Physical Context Element Identifier (= 0x10) 1
Length (= N-2) 2
Embedded Information Element …-N
When included in the Channel Activation message the Embedded Information elements
define the measurements to be made by the BTS on the received channel data, and their
value fields shall be reserved.
© ip.access Ltd
- 104 -
4.2.11 Uplink Measurements
The Uplink Measurements information element defined in [GSM 08.58 section 9.3.25] may
include a Supplementary Measurement Information field which shall take the following
structure:
8 7 6 5 4 3 2 1
4.2.12 Message Discriminator
The codings of the Message Discriminator information element defined in [GSM 08.58,
section 9.1] shall be extended with the following values:
01111110 Connection Control Messages

01100110 Multiplex Connection Control Messages
4.2.13 Message Type
The codings of the Message Type information element defined in [GSM 08.58, section
9.2] shall be extended with the following values:
0100…. Extended Dedicated Channel Management messages:

….0000 Directed Retry Enquiry
….0001 (Reserved for Location Information as per GSM 08.58 v8.4.0
onwards)
….1000 PDCH Activation
….1001 PDCH Activation Ack
….1010 PDCH Activation Nack
….1011 PDCH Deactivation
….1100 PDCH Deactivation Ack
….1101 PDCH Deactivation Nack
0110…. Extended Common Channel Management/TRX Management

messages:
….0000 Measurement Pre-processing Defaults
….0001 Handover Candidate Enquire
….0002 Handover Candidate Response
The following messages are sent with the Message Discriminator set to Connection
Control Messages.
0111…. Connection Control Messages:
….0000 Create Connection
….0001 Create Connection Ack
….0010 Create Connection Nack
© ip.access Ltd
- 105 -
….0011 Modify Connection
….0100 Modify Connection Ack
….0101 Modify Connection Nack
….0110 Delete Connection Ind
….0111 Delete Connection
….1000 Delete Connection Ack
….1001 Delete Connection Nack
The following messages are sent with the Message Discriminator set to Multiplex
Connection Control Messages.0101…. Multiplex Connection Control
Messages
….0000 Modify Multiplex Connection
….0001 Modify Multiplex Connection Ack
….0010 Modify Multiplex Connection Nack
….0011 Create Multiplex Connection
….0100 Create Multiplex Connection Ack
….0101 Create Multiplex Connection Nack
….0110 Delete Multiplex Connection
….0111 Delete Multiplex Connection Ack
….1000 Delete Multiplex Connection Nack
Note: all of these values are within the (rather large) range starting 01, which 08.58 from
v8.4.0 onwards have defined for Location Services messages. So far only the single value
noted above has been defined within this range.
4.2.14 Cause
The codings of the Cause information element defined in [GSM 08.58, section 9.3.26]
shall be extended with the following values:
101 0001 Radio Channel not activated/allocated

101 0010 Connection invalid
101 0011 Connection in use
101 0100 Connection already exists
4.2.15 MS Power Parameters
The MS Power Parameters information element defined in [GSM 08.58 section 9.3.31]
shall have the following structure:
© ip.access Ltd
- 106 -
8 7 6 5 4 3 2 1
MS Power Parameters Element Identifier (= 0x1f) 1
Length (= N-2) 2
The Embedded IES which may be present in this IE are:
INFORMATION ELEMENT REFERENCE PRESENCE FORMAT LENGTH

Measurement Averaging Configure 4.3.5 O TLV >=4
MS Power Control Threshold 4.3.7 O TV 4
PC Threshold Comparators 4.3.11 O 1) TV 11
Note 1) The same PC Threshold Comparators values apply to both MS and BS Power
control procedures, and the same Measurement Averaging Configure values apply to MS
and BS Power control and Handover processing procedures. When both the MS Power
Parameters IE and the BS Power Parameters IE are contained in a GSM 08.58 message
or set of messages, the Measurement Averaging Configure and PC Threshold
Comparators embedded information elements should only be in one of the set of IEs or
messages.
4.2.16 BS Power Parameters
The BS Power Parameters information element defined in [GSM 08.58 section 9.3.32]
shall have the following structure:
8 7 6 5 4 3 2 1
BS Power Parameters Element Identifier (= 0x20) 1
Length (= N-2) 2
The Embedded IEs which may be present in this IE are:

BS Power Control Threshold 4.3.6 O TV 4
PC Threshold Comparators 4.3.11 O 1) TV 11
Note 1) The same PC Threshold Comparators values apply to both MS and BS Power
control procedures, and the same Measurement Averaging Configure values apply to MS
and BS Power control and Handover processing procedures. When both the MS Power
Parameters IE and the BS Power Parameters IE are contained in a GSM 08.58 message
or set of messages, the Measurement Averaging Configure and PC Threshold
© ip.access Ltd
- 107 -
Comparators embedded information elements should only be in one of the set of IEs or
messages.
4.2.17 Pre-processing Parameters
The Pre-processing Parameters information element defined in [GSM 08.58 section

9.3.33] shall have the following structure:
8 7 6 5 4 3 2 1
Pre-processing Parameters Element Identifier (= 0x21) 1
Length (= N-2) 2
Reserved P 3
The P bit is as described in [GSM 08.58 section 9.3.33
The pre-processing parameters could consist of any number of the IE’s specified below.
As this could create an extremely long message, they may be split into smaller groups
and sent in a series of messages – see section 4.1.11.

Handover Thresholds 4.3.8 O TV 7
NCell Defaults 4.3.9 O TV 4
NCell List 4.3.10 O TLV >=4
HO Threshold Comparators 4.3.12 O TV 10
NCell BA-list Change List 4.3.15 O TLV >=2
NCell Defaults Extension 4.3.18 O TV >=3
NCell List Extension 4.3.19 O TLV >=4
4.2.18 Pre-processed Measurements
The Pre-processed Measurements information element defined in [GSM 08.58 section

9.3.34] shall have the following structure:
8 7 6 5 4 3 2 1
Pre-processed Measurements Element Identifier (= 0x22) 1
Length (= N-2) 2
© ip.access Ltd
- 108 -
INFORMATION ELEMENT REFERENC PRESENC FORMAT LENGTH
E E
Handover Cause 4.3.13 C TLV >=2
Handover Candidates 4.3.14 C TLV >=2
Handover Candidates Extension 4.3.17 O TLV >=2
The Handover Cause EIE and the Handover Candidates EIE shall both be included if a
handover is required, but shall be omitted if the Pre-processed Measurements IE is to
indicate that a handover is no longer required.
4.2.19 Handover Candidate Parameters
The Handover Candidate Parameters information element shall have the following
structure:
8 7 6 5 4 3 2 1
Handover Candidate Parameters Element Identifier (= 0xF7) 1
Length (= N-2) 2
The Embedded IEs which may be present in this IE are:

Number of MSs 4.3.16 M TV 2
Handover Candidates 4.3.14 C TLV >=2
Handover Candidates Extension 4.3.17 C TLV >=2
The Handover Candidates and the Handover Candidates Extension may only be included
in this IE when in the Handover Candidate Enquire message. If omitted, there is no
restriction as to destination cell for the handover. The Handover Candidates Extension
may only be included following a Handover Candidates. When used in this IE, the
Handover Candidate shall not include the serving cell in the list of candidates.
4.2.20 Connection Id
Connection Id 2-3
This information element carries the opaque Connection Id value allocated by the BTS
when a new RTP connection is created, and used in subsequent Modify and Delete
messages to identify the connection.
© ip.access Ltd
- 109 -
4.2.21 RTP CSD Format
This information element is used by the BSC to configure the format of the Circuit
Switched Data traffic data in the RTP traffic streams. It may only be included if the GSM
Channel Mode indicates that the channel is carrying circuit-switched data.
The RTP CSD Format information element is defined as:
8 7 6 5 4 3 2 1
Reserved IR D 2
The D bits control the RTP payload format to be used in the RTP stream, and have the
following coding:
D bits Codec
0000 External TRAU format (see 5.5)
0001 Non-TRAU Packed format (see 5.6)
0010 TRAU within the BTS (see 5.7)
0011 IWF-Free BTS-BTS data (see 5.8)
0100- Reserved
1111
The IR bits control the Intermediate Rate to be used in the RTP stream, and have the
following coding:
IR bits Intermediate Rate

00 8kb/s
01 16kb/s
10 32kb/s
11 64kb/s
If this information element is omitted and the GSM Channel Mode indicates that the
channel is carrying circuit-switched data, the RTP media stream uses the default TRAU
format (D = 0000) with 16kb/s Intermediate Rate (IR= 01).
4.2.22 Channel Number
The codings of the Channel Number information element defined in [GSM 08.58, section
9.3.1] shall be extended with the following values for the C1…C5 bits:
C5..C1
11101 PDCH PDTCH/F+PACCH/F+PTCCH/F
11110 cPDCH PCCCH+PDTCH/F+PACCH/F+PTCCH/F
11111 bPDCH PBCCH+PCCCH+PDTCH/F+PACCH/F+PTCCH/F
© ip.access Ltd
- 110 -
4.2.23 Resource Information
The codings of the Resource Information information element defined in [GSM 08.58,
section 9.3.21] shall be extended by the modification of the Interference Level octet to the
following format:
8 7 6 5 4 3 2 1
Interference Band Idle Time 1
The Interference Band shall be as defined in GSM 08.58 section 9.3.21. The Idle Time
field shall be coded as follows:
0 Idle Time = 100%

1 96% <= Idle Time < 100%
2 92% <= Idle Time < 96%
:
25 0% <= Idle Time < 4%
26..31 Reserved
The Idle Time is the percentage of the measurement period during which the Channel was
idle, i.e. the slot was not assigned to be able to be used for traffic. This is only relevant to
slots which are provisioned as static PDCHs, or as dynamic TCH/PDCHs and have been
activated as PDCHs. The BSC may monitor such slots through the Resource Information
to determine whether they might be better used for new circuit switched connections, or
whether alternative PDCH slots should be allocated for interference reasons. The Idle
Time indicated shall be the minimum percentage of the uplink Idle Time and the downlink
Idle Time. Slots which were assigned for PRACH shall not be considered idle, even if no
transmission was made in them. PDCHs which have been idle for 0% of time over the last
measurement period shall be reported as being in the same Interference Band as
reported in the previous Resource Information element.
4.2.24 Paging Load
The [GSM 08.58, section 9.3.15] Paging Load IE shall be extended to include the value
0xFFFF, which shall have the meaning “CCCH Paging Load below the trigger threshold.
4.2.25 RTP Jitter Buffer Control
This information element is used by the BSC to configure the receive jitter buffer for the
RTP traffic streams.
The RTP Jitter Buffer Control information element is defined as:
© ip.access Ltd
- 111 -
8 7 6 5 4 3 2 1
Initial Jitter Allowance 2
B Adaptation Rate 3
The Initial Jitter Allowance field is used to tell the BTS that it should initialise its jitter buffer
to cope with packet jitter of the specified amount before packet loss occurs, and has the
following coding:
Value Initial Jitter Allowance

0-250 Initial Jitter Allowance 0…1250ms (units
of 5ms)
251-255 Reserved
The Adaptation Rate field is used to control the rate at which the BTS should respond to
changes in jitter in adapting its jitter buffer, and has the following coding:
Value Adaptation Rate

0 Immediate adaptation
1-100 Adaptation Period 1s…100s (units of 1s)
101-126 Reserved
127 Do not adapt – fixed jitter allowance
The B bit controls whether the BTS should apply adaptation (if B=1) in both directions (i.e.
both growing and shrinking the jitter buffer) if supported, or (if B=0) only in one direction
(growing the buffer only).
If this information element is omitted, the BTS should default to using an Initial Jitter
Allowance of zero, and only growing buffer (B=0) with immediate adaptation (Adaptation
Rate=0).
If this information element is included, but includes some values not supported by the
BTS, the unsupported values shall be ignored, and the above defaults used in their place.
4.2.26 RTP Compression Control
This information element is used by the BSC to configure the compression used in the
RTP streams.
The RTP Compression Control information element is defined as:
8 7 6 5 4 3 2 1
Reserved U 2
© ip.access Ltd
- 112 -
The U bit control the use of UDP Checksums to allow better UDP compression by external
equipment:
U Meaning
0 UDP Checksums disabled
1 UDP Checsums enabled (default)
If all values are to be used at default, this IE may be omitted.
If this information element is included, but includes some values not supported by the
BTS, the unsupported values shall be ignored, and the above defaults used in their place.
4.2.27 RTP Payload Type 2
8 7 6 5 4 3 2 1
R RTP Payload Type 2
This information element is used by the BTS and BSC to specify the Payload Type values
to be included in the RTP stream. It may be omitted for a Channel Mode indicating a
standard GSM FR codec type, as this already has an IANA assigned static Payload Type
of 3. It (or the RTP Payload Type IE) should be included for all other RTP stream payload
formats, and then should be in the IANA dynamic PT range.
The BSC sends to the BTS the Payload Type which the BTS shall use in the RTP stream
sent to the peer, and the BTS sends the Payload Type which the peer shall use in the
RTP stream to the BTS.
The R bit is reserved.
Note: This IE replaces the RTP Payload Type IE (section 4.2.7) for controlling the use of
asymmetric dynamically assigned Payload Type values. The RTP Payload Type IE may
still be used by the BSC in the Create Connection to the BTS if the Payload Type value to
be used by the BTS must be fixed and used in both the sending and receiving RTP
streams, but this is deprecated, and does not allow support of the Alternate Speech and
Data service.
4.2.28 Channel Mode
The Channel Mode information element shall be as defined in [GSM 08.58 section 9.3.6],
with the modification that the “DTXd” field shall indicate that Silence Suppression (that is
the deliberate non-transmission of RTP packets when there is no speech detected) is in
use on the downlink to the TRX, and that the TRX should use Downlink DTX on the
channel (if it is not transmitting on the BCCH Frequency, on which DTX is never invoked).
See section 6.12 for further details.
© ip.access Ltd
- 113 -
4.2.29 Multiplex Control
This information element is used by the BSC to configure the BTS Multiplexer and the
BSC Multiplexer. The uplink parameters are used by the BTS Multiplexer, the downlink
parameters are used by the BSC Multiplexer. The downlink parameters are sent to the
BTS which forwards them on to the BSC Multiplexer.
Downlink Maximum Multiplex RTP Packet Size (bytes) 2-3
Uplink Maximum Multiplex RTP Packet Size (bytes) 4-5
Downlink Maximum Multiplex RTP Time Interval
(multiples of 20msec) 6-7
Uplink Maximum Multiplex RTP Time Interval
(multiples of 20msec) 8-9
The range of the RTP packet size is 64 to 1472 bytes. The range of the time interval is 1
to 10 corresponding with a range of values from 20ms to 200ms.
4.2.30 Multiplex Connection ID
This information element is used by the BTS to inform the BSC about the multiplex
connection ID of a newly created multiplex connection. It is used in subsequent messages
between the BTS and the BSC to identify a specific multiplex connection.
Multiplex Connection ID 2
4.2.31 SRTP Configuration
This information element is sent by the BSC when creating a secure multiplex connection.
It provides the information needed by the BTS to initiate secure communication with the
secure BSC Multiplexer.
Length 1
Embedded Information Element Variable
Embedded Information Element Variable
The Embedded IEs which are present in this IE are:

Master Key 4.3.20 M TLV >=2
Master Salt 4.3.21 M TLV >=2
© ip.access Ltd
- 114 -
4.2.32 BSC Proxy UDP Port
This information element defines the source port used at the BSC Proxy when forwarding
an RTP packet to the RTP endpoint.
BSC Proxy UDP Port 2-3
4.2.33 BTS Multiplexer Keep Alive Timeout
This information element defines the maximum acceptable period of RTP inactivity on an
individual RTP stream. Once this timeout expires a zero length RTP Multiplex packet is
used to keep the RTP stream open. A timeout of zero disables this feature.
BTS Multiplexer Keep Alive Timeout 2
(seconds)
The range of the keep-alive timeout is 0 to 60 seconds.
4.3 08.58 Message Embedded Information Elements
These manufacturer-defined embedded information elements are used in [GSM 08.58]

messages in the manufacturer-defined fields.
4.3.1 RXLEV Embedded Information Element
The RXLEV embedded information element is structured as follows.
8 7 6 5 4 3 2 1
Embedded RXLEV Identifier (= 0x00) 1
Reserved RXLEV 2
The value of RXLEV shall be that calculated from the received data to which the message
carrying this IE is derived (e.g. in the Channel Required message the value of RXLEV
shall be that calculated from the access burst only).
4.3.2 RXQUAL Embedded Information Element
The RXQUAL embedded information element is structured as follows.
8 7 6 5 4 3 2 1
Embedded RXQUAL Identifier (= 0x01) 1
Reserved RXQUAL 2
© ip.access Ltd
- 115 -
The value of RXQUAL shall be that calculated from the received data to which the
message carrying this IE is derived (e.g. in the Channel Required message the value of
RXQUAL shall be that calculated from the access burst only).
4.3.3 Frequency Error Embedded Information Element
The Frequency Error embedded information element is structured as follows.
Embedded Frequency Error Identifier (= 0x02) 1

Frequency Error 2-3
The Frequency Error value is in units of ppb, but the resolution and accuracy depend on
the actual BTS hardware and measurement configuration.
4.3.4 Frame Timing Error Embedded Information Element
The Frame Timing Error embedded information element is structured as follows.
Embedded Frame Timing Error Identifier (= 0x03) 1

Frame Timing Error 2
The Frame Timing Error value is in units of quarter bits (a.k.a. qbits), but the resolution
and accuracy depend on the actual BTS hardware and measurement configuration.
4.3.5 Measurement Averaging Configure
8 7 6 5 4 3 2 1
Embedded Measurement Averaging Configure Identifier (= 0x04) 1
Length (= n-2) 2
reserved Param Id H_REQAVE 3
Averaging Method H_REQT 4
Averaging :
Parameters n
This IE carries the parameters used to configure the basic measurement averaging for
each of the measurement parameters RxLev, RXQual and MS-BTS distance. For details
of the units, ranges and uses of these, see [GSM 05.08]. This IE may be repeated up to 3
times in a single message, each carrying a different Param Id value.
Param Id 0 = RxLev
1 = RxQual
2 = MS-BTS Distance
H_REQT range 1 to 31
H_REQAVE range 1 to 31
Averaging Method 0=Un-weighted average
1=Weighted Average
© ip.access Ltd
- 116 -
2=Modified median calculation
Averaging Parameters not required for Ave. Method = 0.
TBD for other methods.
Notes:
1) A picoBTS does not need to average the MS-BTS distance.
2) The BTS has only a single set of averaging parameters for each Param Id, which
are used for all subsequent power control and handover processing.
3) H_REQT x H_REQAVE < 32
4.3.6 BS Power Control Thresholds
8 7 6 5 4 3 2 1
Embedded BS Power Control Threshold Identifier (= 0x05) 1
Reserved L_RXLEV_DL_P 2
Reserved U_RXLEV_DL_P 3
Reserved L_RXQUAL_DL_P Reserved U_RXQUAL_DL_P 4
For details of the field units, ranges and uses, see [GSM 05.08].
4.3.7 MS Power Control Thresholds
8 7 6 5 4 3 2 1
Embedded MS Power Control Threshold Identifier (= 0x06) 1
Reserved L_RXLEV_UL_P 2
Reserved U_RXLEV_UL_P 3
Reserved L_RXQUAL_UL_P Reserved U_RXQUAL_UL_P 4
4.3.8 Handover Thresholds
8 7 6 5 4 3 2 1
Embedded Handover Threshold Identifier (= 0x07) 1
Reserved L_RXLEV_UL_H 2
Reserved L_RXLEV_DL_H 3
Reserved RXLEV_UL_IH 4
Reserved RXLEV_DL_IH 5
Reserved L_RXQUAL_DL_H Reserved L_RXQUAL_UL_H 6
Reserved MS_RANGE_MAX 7
© ip.access Ltd
- 117 -
4.3.9 NCell Defaults
8 7 6 5 4 3 2 1
Embedded NCell Limits Defaults Identifier (= 0x08) 1
Reserved RXLEV_MIN_DEF 2
Reserved HO_MARGIN_DEF 3
Reserved MS_TXPWR_MAX_DEF 4
4.3.10 NCell List
8 7 6 5 4 3 2 1
Embedded NCell List Identifier (= 0x09) 1
Length (N) 2
Ext. Length(1) BSIC(1) 3
Reserved BA- BCCH-FREQ-NCELL(1a) 4
Used(1a)
0 0 BA- BCCH-FREQ-NCELL(1b) :
Used(1b)
0 1 RXLEV_MIN(1) :
1 0 Reserved HO_MARGIN(1) :
1 1 Reserved MS_TXPWR_MAX(1) :
Ext. Length(2) BSIC(2) n
Reserved BA BCCH-FREQ-NCELL(2a) n+1
Used(2a)
0 0 BA BCCH-FREQ-NCELL(2b) :
Used(2b)
: :
: N+2
This embedded IE is used to configure the NCell list with:
1. two values of BCCH-FREQ-NCELL with different BA-used flag values which both
refer to the same NCell, and/or
2. non-default values of the RXLEV_MIN, HO_MARGIN and MS_TXPWR_MAX
parameters to associate with the NCell.
The IE contains a set of entries, each defining one NCell. Each entry shall have a
minimum of 3 octets and maximum of 6 octets, as indicated by the Extension Length field,
which contains the value (entry length – 3). The first octet shall contain this Extension
Length field together with the BSIC of the NCell. The second octet shall contain the first
(or only) {BA-Used, BCCH-FREQ-NCELL} pair associated with the NCell. The third and
subsequent octets in each entry shall contain one of:
0. a second {BA-Used, BCCH-FREQ-NCELL} pair

1. RXLEV_MIN
© ip.access Ltd
- 118 -
2. HO_MARGIN
3. MS_TXPWR_MAX
The type of value contained in each of these octets is indicated by the most significant 2
bits of each octet, which is coded with a 2-bit “Type” field with the values illustrated above.
NCells which are associated with only a single {BA-Used, BCCH-FREQ-NCELL} pair and
use default values of RXLEV_MIN, HO_MARGIN and MS_TXPWR_MAX need not be
defined in this list, and shall still be processed correctly in the BTS Handover processing.
NCells which are statically associated with two {BA-Used, BCCH-FREQ-NCELL} pairs
(whether using default values of RXLEV_MIN, HO_MARGIN and MS_TXPWR_MAX, or
not) should be defined in this list. This static association may be used when the SysInfo
messages on BCCH contain a different BA-list and thus BA-Used flag and BCCH-FREQ-
NCELL index set from the SysInfo messages configured for SACCH fill.
For details of the RXLEV_MIN, HO_MARGIN and MS_TXPWR_MAX field units, ranges
and uses, see [GSM 05.08].
This IE with no entries shall indicate a change of BA-list with no supplied mapping, and
shall cause the NCell List configurations to be discarded, and defaults assumed for all
NCells.
4.3.11 PC Threshold Comparators
8 7 6 5 4 3 2 1
Embedded PC Threshold Comparators Identifier (= 0x0a) 1
Reserved P1 2
Reserved N1 3
Reserved P2 4
Reserved N2 5
Reserved P3 6
Reserved N3 7
Reserved P4 8
Reserved N4 9
Reserved TIMER_PWR_CON_INTERVAL a
POWER_INC_STEP_SIZE POWER_RED_STEP_SIZE b
© ip.access Ltd
- 119 -
4.3.12 HO Threshold Comparators
8 7 6 5 4 3 2 1
Embedded HO Threshold Comparators Identifier (= 0x0b) 1
Reserved P5 2
Reserved N5 3
Reserved P6 4
Reserved N6 5
Reserved P7 6
Reserved N7 7
Reserved P8 8
Reserved N8 9
Reserved TIMER_HO_RQD_INTERVAL a
Reserved Reserved b
For details of the other field units, ranges and uses, see [GSM 05.08].
4.3.13 Handover Cause
8 7 6 5 4 3 2 1
Embedded Handover Cause Identifier (= 0x0c) 1
Length (N) 2
Handover Cause Value 3
: :
Handover Cause Value N+2
Handover Cause Value:

HO_RQD_CAUSE_L_RXLEV_UL_H 0x01
HO_RQD_CAUSE_L_RXLEV_DL_H 0x02
HO_RQD_CAUSE_L_RXQUAL_UL_H 0x03
HO_RQD_CAUSE_L_RXQUAL_DL_H 0x04
HO_RQD_CAUSE_RXLEV_UL_IH 0x05
HO_RQD_CAUSE_RXLEV_DL_IH 0x06
HO_RQD_CAUSE_MAX_MS_RANGE 0x07
HO_RQD_CAUSE_POWER_BUDGET 0x08
HO_RQD_CAUSE_ENQUIRY 0x09
HO_RQD_CAUSE_ENQUIRY_FAILED 0x0a
All other values may be used by future extensions to indicate other causes required, and
should be accepted as valid cause values by the BSC. All causes which apply at the time
of the results message being sent shall be included in the list.
© ip.access Ltd
- 120 -
4.3.14 Handover Candidates
8 7 6 5 4 3 2 1
Embedded Handover Candidates Identifier (= 0x0d) 1
Length (N) 2
Reserved BSIC(Candidate 1) 3
Reserved S BA BCCH-FREQ-NCELL(Candidate 1) 4
used
: :
Reserved BSIC(Candidate n) :
Reserved S BA BCCH-FREQ-NCELL(Candidate n) N+2
used
The serving cell may be the first entry in the candidate list (for an internal intra-cell
handover), in which case the S bit for that entry shall be “1”, otherwise it shall be “0”.
The BA Used bit shall indicate the value of the BA Used flag relevant to the BCCH-FREQ-
NCELL index value.
4.3.15 NCell BA-list Change List
This IE allows the measurement history for NCells to be maintained when an MS on a

dedicated channel is instructed to use a new BA List in the SysInfo carried on the SACCH
on that dedicated channel.
8 7 6 5 4 3 2 1
Embedded NCell BA-list Change List Identifier (= 0x0e) 1
Length (N) 2
Ext. Length(1) BSIC(1) 3
Reserved BA- BCCH-FREQ-NCELL(1o) 4
Used(1o)
0 0 BA- BCCH-FREQ-NCELL(1n) :
Used(1n)
Ext. Length(2) BSIC(2) n
Reserved BA BCCH-FREQ-NCELL(2o) n+1
Used(2o)
0 0 BA BCCH-FREQ-NCELL(2n) :
Used(2n)
: :
: N+2
Its format is similar to the NCell List IE (section 4.3.10), except that each entry in the list
shall include only the BSIC and two {BA-Used, BCCH-FREQ-NCELL} pairs. The first of
these defines the old {BA-Used, BCCH-FREQ-NCELL}, and the second defines the new
{BA-Used, BCCH-FREQ-NCELL}. The Extension Length field in the first octet shall be
used identically to that in section 4.3.10, and should be zero.
© ip.access Ltd
- 121 -
The message shall not modify the values of the RXLEV_MIN, HO_MARGIN and
MS_TXPWR_MAX parameters associated with the NCell, and may contain NCells which
use default or non-default values of these parameters, i.e. the old {BA-Used, BCCH-
FREQ-NCELL} may not have occurred in a previous NCell List IE.
This IE with no entries shall indicate a change of BA-list with no supplied mapping from
old to new, and shall cause the measurement histories on the dedicated channel (or on all
dedicated channels if included in a TRX management message) to be discarded.
4.3.16 Number of MSs
8 7 6 5 4 3 2 1
Embedded Number of MSs Identifier (= 0x10) 1
Number of MSs 2
This IE indicates the maximum number of candidates being requested by a Handover

Candidate Enquire message, or the number of candidates actually found in a Handover
Candidate Response message.
4.3.17 Handover Candidates Extension
8 7 6 5 4 3 2 1
Embedded Handover Candidates Extension Identifier (= 0x11) 1
Length (N) 2
Parameter Octets(entry1)
:
End of Extension Marker(entry1) (0xff)
:
:
End of Extension Marker(entry:n-1) (0xff)
Parameter Octets(entry:n)
:
End of Extension Marker(entry:n) (0xff) N+2
This embedded IE may be used to add additional parameters describing each handover
candidate which cannot be included in the Handover Candidates embedded IE (see
4.3.14). The format of this embedded attribute allows for additional parameters to be
included in the future, and ignored by a BSC which do not understand them, whilst still
allowing the BSC to use the parameters it does understand.
Inclusion of this embedded IE requires that the Handover Candidates embedded IE is also
included, prior to this embedded IE. There is an entry in the Handover Candidates
Extension for each entry in the Handover Candidates, in the same order as they are
© ip.access Ltd
- 122 -
included in the Handover Candidates embedded IE. Each entry ends with a marker octet
(0xff), which may not occur as part of the entry parameter data octets. There may be zero
or more parameters in each entry, and each entry may have different numbers and types
of parameters. The BTS should include all parameters for which it has valid values.
Each included parameter in the Handover Candidates Extension starts with an octet which
has one or more bits to describe the parameter included, and is followed by the parameter
value. Each such parameter shall be a whole number of octets. There may be one or
more parameters in this embedded IE. None of the parameter octets shall take the value
0xff.
The parameters allowed are listed below in the order in which they shall be included in
each entry:
0 0 0 0 Cell Handover Preference 1
This parameter describes the Cell Handover Preference value of the potential target cell
as derived from the handover algorithm used.
4.3.18 NCell Defaults Extension
8 7 6 5 4 3 2 1
Embedded NCell Limits Defaults Identifier (= 0x12) 1
Length (N) 2
:
Parameter Octets(entry1) N+2
This embedded IE may be used to configure the NCell defaults with additional parameters
which cannot be included in the NCell Defaults embedded IE (see 4.3.9). The format of
this embedded attribute allows for additional parameters to be included in the future, and
to be ignored by BTSs which do not understand them, whilst still allowing the BTS to use
the parameters it does understand.
Each included parameter in the NCell Defaults Extension starts with an octet which has
one or more bits to describe the parameter included, and is followed by the parameter
value. Each such parameter shall be a whole number of octets. There may be one or
more parameters in this embedded IE. None of the parameter octets shall take the value
0xff – see 4.3.19.
The parameters allowed are listed below in the order in which they shall be included:
0 0 0 0 Handover Priority 1
This parameter describes the default Handover Priority for a cell – see GSM 12.20.
© ip.access Ltd
- 123 -
0 0 0 1 GSM Band 1
This parameter describes the GSM Band which the default cell is assumed to be in, coded
as follows:-
Value GSM Band

1 GSM (900)
2 DCS (1800)
3 PCS (1900)
If omitted, the cell is assumed to be in the same GSM Band as the serving cell. This
allows the correct MS_TXPWR_MAX_DEF coding to be known to the BTS.
4.3.19 NCell List Extension
8 7 6 5 4 3 2 1
Embedded NCell List Extension Identifier (= 0x13) 1
Length (N) 2
:
End of Extension Marker(entry1) (0xff)
:
:
End of Extension Marker(entry:n-1) (0xff)
:
End of Extension Marker(entry:n) (0xff) N+2
This embedded IE may be used to configure the NCell list with additional attributes which
cannot be included in the standard NCell List embedded IE (see 4.3.10). The format of the
embedded attribute allows for additional parameters to be included in the future, and
ignored by BTSs which do not understand them, whilst still allowing them to use the
parameters it does understand.
Inclusion of this embedded IE requires that the NCell embedded IE is also included, prior
to this embedded IE. There is an entry in the NCell Extension List for each entry in the
NCell List, in the same order as they are included in the NCell List embedded IE. Each
entry ends with a marker octet (0xff), which may not occur as part of the entry parameter
data octets. There may be zero or more parameters in each entry, and each entry may
have different numbers and types of parameters. If a parameter is excluded in an entry,
that NCell shall use the default value for that parameter (see 4.3.18).
© ip.access Ltd
- 124 -
The parameters allowed in each NCell entry and their format are identical to those which
may be included in the NCell Defaults Extension embedded IE in section 4.3.18.
4.3.20 Master Key
Embedded Master Key Identifier (= 0x14) 1

Length 2
Master Key 3..
This defines the master key used by the BTS when setting up an SRTP session.
4.3.21 Master Salt
Embedded Master Salt Identifier (= 0x15) 1

Length 2
Master Salt 3..
This defines the master salt used by the BTS when setting up an SRTP session.
© ip.access Ltd
- 125 -
5 USER TRAFFIC MESSAGES
The GSM user traffic shall be carried in one or more RTP connection streams [RFC 1889].
The GSM user traffic messages shall be carried in a single RTP data packet (which may
be fragmented by the underlying IP layers). Each packet shall carry 20ms duration of
traffic for a single traffic channel.
There may be one or more configured RTP traffic streams. If there are no active traffic
channels of those configured to use a given RTP traffic stream, there may be no
messages currently being transferred over that stream. RTCP shall be used, and shall
conform to [RFC 1889].
5.1 RTP Traffic Packet Format
The use of standard RTP payloads shall be supported. This allows interfacing to standard
RTP-based VoIP systems, optionally with local switching of the traffic media stream to the
terminal endpoint or to a gateway device to such a terminal. The BTS may only support
the native GSM data rate or speech codec type used over the air interface for the traffic
stream if there is no support for transcoding or rate adaptation (TRAU) in the BTS, but
may optionally include the TRAU within the BTS. The BTS may also optionally include
IWF features to allow direct BTS-BTS traffic routing for CSD.
5.1.1 RTP Header
The UDP traffic packets shall carry an RTP [RFC 1889] header:-
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
V=2 P X CC M PT Sequence Number
Timestamp
Synchronisation Source (SSRC) identifier
The fields in the header shall be transmitted as:
Version (V) = 2 RTP version 2

Padding control (P)= 0 No terminating padding
Extension (X) Set if a header extension is included – none currently
supported
CSRC Count (CC) = 0 No CSRC records following this header
Marker (M) = 0 Depends on payload type
Payload Type (PT) RTP payload type (see 4.2.7)
Sequence Number As RTP
© ip.access Ltd
- 126 -
Timestamp As RTP
SSRC As RTP
5.1.2 Spare
5.1.3 Spare
5.1.4 Spare
5.2 Spare
5.3 Spare
5.4 Spare
5.5 TRAU-like Payloads
This section describes the data format in which the standard GSM traffic payloads or the
stream control data are carried in the Payload Data on the A-bis Traffic streams. It may
normally be used by BTSs which support deployment scenario A, but may be optionally
used for other deployment scenarios.
The “TRAU-like” formats are as defined in [GSM 08.60] and [GSM 08.61] except for the
following modifications:
1. The leading one (for 8kb/s multiplex) or two (for 16kb/s multiplex) octets of zero
bits are omitted
2. The middle 34 octets with all bits set to 1 of Idle speech frames are omitted
3. TRAU frame shortening (T1…T4 bit omission) is not supported
4. Downlink TRAU frame time alignment is not supported
The remaining sections below define the byte-oriented non-TRAU-like codings (T=0).
5.6 Non-TRAU Payloads
This section describes the data format in which the standard GSM traffic payloads are
carried in the Payload Data on the A-bis Traffic streams.
Definitions of any payload types not defined below are TBD.
© ip.access Ltd
- 127 -
The speech formats are defined in [TIPHON-GSM], based on [Internet Draft draft-ietf-avt-
profile-new].
The payload type shall be the same type used over the GSM air interface unless support
for transcoding is included in the BTS, and is requested by the IP Speech Mode
information element (see 4.2.5) in the setup of the connection.
There shall be a 20ms buffer of speech or data in each RTP packet payload, as defined
by the implementation or its configuration. The maximum number of buffers per RTP
payload which may be received is implementation dependent.
5.6.1 FR Speech
The format of the FR Speech payload is defined in [TIPHON-GSM]. The FR Speech is

basically a 4 bit signature, 0xd, followed by the 260 bits of GSM speech data, packed
together into a 33 octet buffer. The detailed ordering of the speech data is defined in
[Internet Draft draft-ietf-avt-profile-new] or in [TIPHON-GSM].
Note that SID frames are carried identically to normal frames: the receiver is responsible
for implementing the SID/DTX functions required for TFO operation. Uplink frames with
BFI set should not be transmitted over the RTP stream.
5.6.2 EFR Speech
The format of the EFR Speech payload is defined in [ETSI TS 101 318]. The EFR Speech
is basically a 4 bit signature, 0xc, followed by the 244 bits of GSM speech data, packed
together into a 31 octet buffer. The detailed ordering of the speech data is defined in
[ETSI TS 101 318].
for implementing the SID/DTX functions required for TFO operation. Uplink frames with
BFI set should not be transmitted over the RTP stream.
5.6.3 HR Speech
The format of the HR Speech payload is defined in [ETSI TS 101 318]. The HR Speech is
basically the 112 bits of GSM speech data, packed together into a 14 octet buffer. There
are no preceding signature bits. The detailed ordering of the speech data is defined in
[ETSI TS 101 318].
for implementing the SID/DTX functions required for TFO operation.
© ip.access Ltd
- 128 -
5.6.4 Idle Speech
Idle (bad) frames (which may result from poor radio reception, or from invocation of DTX
functions) shall result in no buffers for RTP transmission.
5.6.5 Data/16kbps
The format of the Data/16kbps payload is defined in terms of the bits defined in [GSM
08.60] as:
0 1 2 3 4 5 6 7
D1 D2 D3 D4 D5 D6 D7 D8 1
D9 D10 D11 D12 D13 D14 D15 D16 2
D249 D250 D251 D252 Reserved 34
Reserved fields should be transmitted as a 0, and should be ignored by the receiver.
5.6.6 Extended Data/16kbps
The format of the Extended Data/16kbps payload is defined in terms of the bits defined in
[GSM 08.60] as:
0 1 2 3 4 5 6 7
M1 M2 Reserved 1
D1 D2 D3 D4 D5 D6 D7 D8 2
D9 D10 D11 D12 D13 D14 D15 D16 3
D281 D282 D283 D284 D285 D286 D287 D288 37
5.6.7 Idle Data
The format of the Idle Data payload is defined in terms of the bits defined in [GSM 08.60]
as:
0 1 2 3 4 5 6 7
Reserved 1
In deployments which use standard RTP streams for local switching (scenario C) idle data
is not actively transmitted in the RTP stream: it causes a suspension of the RTP stream
as described in the RTP RFC.
© ip.access Ltd
- 129 -
5.6.8 Data/8kbps
The format of the Data/8kbps payload is defined in terms of the bits defined in [GSM
08.60] as:
0 1 2 3 4 5 6 7
D1 D2 D3 D4 D5 D6 D7 D8 1
D9 D10 D11 D12 D13 D14 D15 D16 2
D121 D122 D123 D124 D125 D126 Reserved 16
5.6.9 FR O&M
The format of the FR O&M payload is defined in terms of the bits defined in [GSM 08.60]
as:
0 1 2 3 4 5 6 7
D1 D2 D3 D4 D5 D6 D7 D8 2
D9 D10 D11 D12 D13 D14 D15 D16 3
D257 D258 D259 D260 D261 D262 D263 D264 34
This format is only used in deployments which use a standard TRAU (scenarios A and B).
5.6.10 HR O&M
The format of the HR O&M payload is defined in terms of the bits defined in [GSM 08.61]
as:
0 1 2 3 4 5 6 7
D1 D2 D3 D4 D5 D6 D7 D8 1
D9 D10 D11 D12 D13 D14 D15 D16 2
D113 D114 D115 D116 D117 D118 D119 D120 15
This format is only used in deployments which use a standard TRAU (scenarios A and B).
5.6.11 AMR Speech
The format of the AMR Speech payload is defined in [RFC3267]. Only the Octet Aligned
mode of operation is supported. The use of Interleaving or CRC is not supported. Only a
single 20ms speech frame from a single channel is supported in each RTP payload.
© ip.access Ltd
- 130 -
The AMR Speech is basically a header followed by a variable number of payload speech
or SID octets, depending on the AMR rate. The header includes the Codec type of the
payload (which implicitly defines its length) as well as the Codec Mode Request (CMR)
which defines what the sender wishes to receive. The BTS shall issue CMRs in the uplink
RTP streams to control the AMR codec it wishes to receive in the RTP downlink stream
for the same channel.
The detailed specification of the RTP payload is defined in [RFC3267].
5.7 TRAU within the BTS
carried in the Payload Data on the A-bis Traffic streams when the BTS includes the TRAU
functions (see 4.2.21). The RTP streams carry V.110 frames or their modified versions
(referred to generically below as “network frames”), as described in [GSM 08.20]. These
formats allow the BTS to pass the traffic data streams to the core network at the A
interface without further transcoding or rate adaptation (see [GSM 08.60 Figure 4.2]). The
BTS includes the RA1/RA1’ and RA2 rate adaptation functions for 9.6kb/s Air Interface
rates and below, and RAA’ and RA2 for the 14.5kb/s Air Interface rate.
There may be one or more 20ms buffers of data in each RTP packet payload, as defined
by the implementation or its configuration. The maximum number of buffers per RTP
payload which may be received is implementation dependent. The RTP payload
transmitted by the BTS to the network shall be aligned with the network frames, i.e.
contain an integral number of complete network frames, and for the Non-Transparent
services, shall be aligned with the RLP frame multi-frame.
The RTP payload transmitted by the network to the BTS may not be aligned to the
network frame boundaries and thus not the RLP frame boundaries either. The 64kb/s IR
shall be octet-aligned, and the 32kb/s and 16kb/s IRs shall be 4-bit and 2-bit aligned
respectively (see RA2 below). The BTS shall perform the initial synchronisation,
synchronisation monitoring and synchronisation recovery procedures defined in [GSM
08.20].
The RTP payload shall comprise the standard network frame payload at the A interface at
the Intermediate Rate indicated in the RTP CSD Format IE. The detailed formats for the
payload data is defined in [GSM 08.20], which refers extensively to [GSM 04.21] and [ITU
V.110].
The remainder of this section and subsections are mainly informative: in the case of
conflict, [GSM 08.20] and its referred specifications shall be normative. See also [BTS
TRAU IWF] for a digest of GSM CSD as it applies to the BTS.
© ip.access Ltd
- 131 -
5.7.1 RA2 - Intermediate Rates and Sub-Channels
The Air Interface User Rate (AIUR) determines the Intermediate Rate (IR) required to
carry the data in the fixed network (see [GSM 08.20]). If a higher IR is requested in the
RTP CSD Format IE (see 4.2.21), the standard [ITU I.460] RA2 rate adaptation shall be
used.
An 8kb/s sub-channel shall be carried in a 64kb/s channel by use of only bit 1 of each
octet, the remaining bits 2..7 being set to 1. A 16kb/s sub-channel shall be carried in a
64kb/s channel by use of only bits 1 and 2 of each octet, the remaining bits 3..7 being set
to 1. A 32kb/s sub-channel shall be carried in a 64kb/s channel by use of only bits 1..4 of
each octet, the remaining bits 5..7 being set to 1.
The adaptation of low IR to a sub-channel less than 64kb/s shall be equivalent to the
adaptation of the IR as above to 64kb/s followed by the adaptation of the 64kb/s to the
second (higher) IR as above. This adaptation need not be supported by the BTS.
5.7.2 RA1 - Transparent and Non-Transparent services at 14.4kb/s
The Transparent and Non-Transparent services of 14.4kb/s are carried across the Air
Interface (AI) at the AIUR of 14.5kb/s in a 290 bit frame composed of 8 36 bit data frames
and 2 control bits every 20ms (see below). The BTS shall adapt these to the IR of 16kb/s
using A-TRAU frames (see [GSM 08.20]). Note that the A-TRAU frames are a GSM-
specific format, and do not conform to the ITU V.110 standard. They require a GSM-
specific Framing Pattern Substitution processing to avoid false synchronisation in the
data.
5.7.3 RA1/RA1’ - Transparent and Non-Transparent services at 9.6kb/s
The Transparent and Non-Transparent services of 9.6kb/s are carried across the Air
Interface (AI) at the AIUR of 12kb/s in 60 bit modified V.110 frames every 5ms (see
below). The BTS shall adapt these to the IR of 16kb/s using standard V.110 frames by the
addition of the synchronisation bits (octet 0 is 0, and bit 1 of octets 1..9 are 1), and the
addition of E1, E2 and E3.
5.7.4 RA1/RA1’ - Transparent and Non-Transparent services at 4.8kb/s
The Transparent and Non-Transparent services of 4.8kb/s is carried across the Air
Interface (AI) at the AIUR of 6kb/s in 60 bit modified V.110 frames every 10ms. The BTS
shall adapt these identically to those of the corresponding 9.6kb/s services to the IR of
8kb/s.
5.7.5 RA1/RA1’ - Transparent services at 2.4kb/s and below
The Transparent services of 2.4kb/s and below are carried across the Air Interface (AI) at
the AIUR of 3.6kb/s in 36 bit modified V.110 frames every 10ms. The BTS shall adapt
© ip.access Ltd
- 132 -
these to V.110 80 bit frames at the IR of 8kb/s by the addition of the synchronisation bits
and E1, E2 ad E3 (as for the 9.6kb/s Transparent Service) and by the duplication of each
data bit. The action to be taken on receipt of two data bits with different values when they
should have the same value is FFS. A BTS may discard either of the bits without
notification in constructing the air interface 36 bit frames.
Note that in the MS and the IWF, the 300b/s rate is adapted to 600b/s by the addition of
stop bits, and adaptation of 600b/s and 1200b/s to 2.4kbit/s is performed by 4 times and 2
time consecutive duplication of each user data bit respectively. No action is required in the
BTS for these variants of the 3.6kb/s AIUR other than the correct setting of the E1, E2 and
E3 bits.
5.8 IWF-free BTS-BTS data
carried in the Payload Data on the A-bis Traffic streams when the BTS includes the TRAU
and basic IWF capability to allow CSD to be carried BTS to BTS directly without an
intervening IWF.
In all cases the BTS shall transmit on the uplink to the remote BTS the same data formats
described in section 5.7, and shall thus receive the uplink format on the downlink from the
remote BTS. It is the responsibility of the BTS receiving the downlink data to provide the
IWF functions on this downlink data prior to transmission over the radio interface to the
MS.
The remainder of this section and subsections are mainly informative: in the case of
conflict, [GSM 29.007] and its referred specifications shall be normative. See also [BTS
TRAU IWF] for a digest of GSM CSD as it applies to the BTS, including the provision of an
IWF within the BTS.
5.8.1 Transparent Services
Both BTS to MS links of a connection of the transparent service shall have the same Air
Interface User Rate.
This capability is FFS.
5.8.2 Non-Transparent Services
This capability is FFS.
© ip.access Ltd
- 133 -
6 PROCEDURES
6.1 Channel Establishment procedures
6.1.1 Primary OML Establishment
The Site Manager shall obtain the {IP address, IP port} pairs list for the Primary BSC OML
connection through procedures beyond the scope of this section (e.g. DHCP, NV
attributes of 3.2.6). The BSC(s) shall maintain a listening OML process at the specified
port. The Site Manager shall be responsible for the establishment (and if subsequently
necessary, re-establishment) of this Primary OML by opening a stream to the specified IP
Address and port on the BSC(s). Following a reset, the Site Manager shall wait a random
delay of up to 10 seconds before trying to establish the Primary OML (although if the Site
Manager host has used DHCP to obtain its IP Address, the random delay used by DHCP
is sufficient).
The Site Manager constructs a list of IP addresses, ports with which to attempt primary
OML connections. For each entry in the list, the BTS attempts secure connections if the
port is the well-known secure port, and insecure connections for all other port values.
If the NV attribute SSL control is set to DISABLED then the list is a copy of the primary
OML config list, with all connection attempted insecurely.
If the NV attribute SSL control is set to MANDATORY then the list is a copy of the primary
OML config list with the port numbers replaced by the well-known secure primary OML
port.
If the NV attribute SSL control is set to OPTIONAL then the list is a copy of the primary
OML config list with the port numbers replaced by the well-known secure primary OML
port. This is followed by a second copy of the primary OML config list with the ports
unmodified.
The Site Manager should attempt to connect the Primary OML to each of the IP
addresses and ports in the constructed list in the order specified in the list, moving on to
the next address/port in the list if it cannot connect within the Primary OML Fallback
Timeout period. Should an attempt to connect fail before the end of the Primary OML
Fallback Timeout period, the Site Manager should retry the same IP address after a delay
of Primary OML Reconnect Timeout, provided this is still within the original Primary OML
Fallback Timeout. On failing to connect to the last entry in the list, it should restart the
procedure at the first entry in the list until a successful connection is achieved, but it
should not restart at the first entry in the list until at least the Primary OML Reconnect
Timeout has elapsed since the previous attempt at the first entry. Once connected, it
should maintain that connection until it fails (see 6.3.3) or the Site Manager is reinitialised.
On such failure of the Primary OML connection, the last connected IP address should be
retried for the Primary OML Fallback Timeout period, again with at least Primary OML
Reconnect Timeout between retries to the same IP address. If it has not managed to
reconnect within the Primary OML Fallback Timeout period, the Site Manager should
continue attempts as above with the next IP address in the list.
© ip.access Ltd
- 134 -
The Primary OML Reconnect Timeout shall be a random value between 5 and 15
seconds duration.
On establishment of a secure Primary OML connection, authentication and encryption

processes should be enacted by the Site Manager and the BSC prior to further message
exchange (see [Security Framework]). If a TCP framed channel is used, the framing
procedure defined in [SIG-IP] shall then be established on the link. If no secure
authentication has already occurred (e.g. use of IPSEC), the Identification procedure shall
then be invoked by both Site Manager and BSC, and shall be completed before the peer
may send any other messages over this link.
The BSC shall configure the Site, BTSs and their contained managed objects with
signalling.
6.1.2 RSL Establishment
The BSC shall maintain a listening RSL process at the specified port(s) (if different from
the OML connection). The BTS Baseband Transceivers shall then be responsible for the
establishment (and if subsequently necessary, re-establishment) of the RSL by opening a
stream to the specified port on the BSC.
The BSC instructs the BTS in the Connect IP Signalling message which IP address and
port to connect to. If the BSC specifies the well-known secure RSL port, the BTS attempts
a secure connection. If the BSC specifies any other port the BTS attempts and insecure
connection.
On establishment of this RSL, any required authentication and encryption processes

should be enacted by the BTS Baseband Transceivers or the BSC prior to further
message exchange (see [Security Framework]). If a TCP framed channel is used, the
framing procedure defined in [SIG-IP] shall then be established on the link. If no secure
authentication has already occurred (e.g. use of IPSEC), the Identification procedure shall
then be invoked by both BTS Baseband Transceivers and BSC, and shall be completed
before the peer may send any other messages over this link.
Once established, all required Common Channel Management and TRX Management
procedures for the channels served by the RSL shall be performed by the BSC:-
• TRX Management:
o MEASUREMENT PRE-PROCESSING DEFAULT message(s) shall be sent
by the BSC to the BTS if the BTS is required to perform Measurement Pre-
Processing and the BSC does not send the Pre-Process Configure on
every connection establishment
o SACCH FILLING message(s) shall be sent for each System Information
message which the BTS is required to transmit on SACCH – the BTS shall
assume all System Information messages not provided after an RSL
establishment are not to be transmitted on SACCH.
© ip.access Ltd
- 135 -
• Common Channel Management shall be sent on C0 RSL only (as the common
channels are only supported on C0):
o BCCH INFORMATION message(s) shall be sent for each System
Information message which the BTS is required to transmit on BCCH – the
BTS shall assume all System Information messages not provided after an
RSL establishment are not to be transmitted on BCCH.
o SMS BROADCAST COMMAND messages for the SMS CB Default
message shall be sent by the BSC if
There is an SMS Cell Broadcast Channel configured
There is a SMS-CB Default message provisioned and supported by
the BSC (rather then sending all SMS-CB messages using SMS-
BROADCAST REQUEST messages).
Following the establishment of RSL and the sending of the required information described
above, the information is resent if its contents are changed (e.g. as a result of
management configuration changes). If a System Information message is no longer
required, an empty BCCH INFORMATION or SACCH FILLING message shall be sent,
identifying the relevant System Information message. If a CBCH Default message is no
longer required, an empty SMS BROADCAST COMMAND shall be sent.
6.1.3 Traffic Channel Establishment
For traffic channels provisioned using the Connect IP Traffic messages (deployment
scenarios A and B) the BTS Baseband Transceiver shall initiate the sending of traffic
packets to the specified {IP address, IP port} when required by receipt of a CHANNEL
ACTIVATION message that requires user data traffic to the BSC/TRAU. In response to
the receipt of the traffic packets, the BSC/TRAU shall respond with traffic packets to the
originating port on the BTS Baseband Transceiver.
For traffic channels configured by the new Connection Control RSL messages, the BTS
Baseband Transceiver and its RTP peer shall, in accordance with normal RTP practices,
not transmit RTP packets when there are no valid packets to be transmitted. If the BTS
Baseband Transceiver or its peers receive traffic to be transmitted to the other over RTP
prior to the RTP destination address being known, they shall discard the traffic.
The connections between the RTP stream Source Ports and the Radio Channels
managed by the RSL Connection Control messages may be either:
1. Dynamic: the connection(s) are created after the Radio Channel is activated and
are deleted before the Radio Channel is released.
2. Persistent: the connections may be created at any time following configuration of
the Radio Channels as TCH, and persist across Channel Activations and RF
Channel releases.
In both cases the Destination Port and IP addresses do not persist outside of the Radio
Channel activation period: release of the RF channel results in the BTS Baseband
© ip.access Ltd
- 136 -
Transceiver effectively deleting the connection and immediately re-creating it without IP
Destination parameters.
If the BTS Baseband Transceiver does not wish to support persistent connections, it may
reject the Create Connection if Radio Channel is not active, and may issue a Delete
Connection Ind if a RF Channel Release is received whilst there is an active connection.
If the BSC does not wish to use persistent connections it may manage the connections in
the dynamic manner.
If supported by both BTS Baseband Transceiver and BSC, persistent connections may be
used to avoid setup delays, as the BSC already has the RTP Source port information for
the BTS Baseband Transceiver.
6.1.4 Secondary OML Establishment
The host equipment for all BTS managed object classes shall maintain a process awaiting
the establishment of a Secondary OML signalling link by the OMC on up to two well-
known or configured ports. The OMC shall be responsible for the establishment (and if
subsequently necessary, re-establishment) of this secondary OML by opening a stream to
one of the specified ports on the BTS equipment.
If the Secondary OML connection is established through the secure Secondary OML
server then authentication and encryption processes should be enacted by the BTS
equipment prior to further message exchange (see [Security Framework]). If a TCP
framed channel is used, the framing procedure defined in [SIG-IP] shall then be
established on the link. If no secure authentication has already occurred (e.g. use of
IPSEC), the Identification procedure shall then be invoked by both BTS equipment and
OML, and shall be completed before the peer may send any other messages on this link.
6.1.5 Rules on Usage of Primary and Secondary OML
If the Primary OML is established, any elementary procedure or structured procedure

initiated by the BTS objects shall be initiated and subsequently completed using the
Primary OML. If the Primary OML is not established and the Secondary OML is
established, the BTS should initiate and subsequently complete any elementary
procedure or structured procedure over the Secondary OML.
The OMC or a local craft terminal may use this Secondary OML to initiate any O&M
elementary procedure or structured procedure to any objects hosted within the unit (see
3.3.17) to which the secondary OML connection has been made, or to objects contained
by these objects in the object hierarchy. The BTS and OMC shall complete any such
procedure over the Secondary OML.
Loss of either OML within a structured procedure carried out over the OML that is lost
shall not cause the procedure to continue on the other link. Loss of either OML shall not
disrupt any procedures on the other OML, except as required by any state changes
© ip.access Ltd
- 137 -
caused by the loss (e.g. loss of primary OML causes the objects to become (DISABLED,
Not Installed), so any ongoing procedure on the other OML which is not valid in that state
shall be failed, but ongoing procedures which are still valid in that state shall be ablem to
continue without disruption).
Connection of the Primary OML by any objects which are being managed over the
Secondary OML connection shall cause those objects which have been activated to be
reinitialised autonomously by the BTS, and thus attempt to carry out normal SW Activation
over the Primary OML.
Upon connection of either primary or secondary OML, the BTS shall issue State Changed
Event Reports for all objects addressable through the connection, listing their current
Operational State and Availability Status.
6.2 Spare
6.3 Error Handling
The following general error handling procedures shall be used unless specific procedures
are defined in the relevant sections of this specification. In this section, the phrase
“without notification” indicates that the A-bis peer is not informed of the event. An
implementation may report the event to its local O&M process or to a local user interface,
as required.
6.3.1 Message Errors
Reserved Fields shall be discarded by the receiver without notification.
Receipt of a message with a reserved value in a non-reserved mandatory field in an

optional part of the message shall cause that optional part of the message to be
discarded, and the remainder of the message shall be processed as if the discard part
had not been sent.
Receipt of a message with a reserved value in a non-reserved mandatory field shall cause
the message to be discarded. If there is a defined mechanism to NACK the message to
the peer it shall be used, and the message shall be discarded.
Receipt of a message or part of a message with a reserved value in a non-reserved

optional field shall be treated as if the optional field had not been included.
Receipt of an unknown, unexpected, out of order, or unexpectedly duplicated attribute or

information element in a message which follows the complete, ordered and valid set of
mandatory attributes or elements for a message shall cause the attribute or element and
anything which follows it to be discarded, and the prior parts of the message to be
processed normally. This shall not apply to the 12.21 Set (*) Attributes messages (for
which all the attributes being set are optional): receipt of an unknown, unexpected, out of
© ip.access Ltd
- 138 -
order, or unsupported attribute for the class in a Set (*) Attributes message shall cause
the message to be NACKed.
Receipt of an unknown 12.21 message shall cause the message to be discarded, raising
an Error Report to the peer if no specific error handling is elsewhere defined.
Receipt of a message which has corrupt header structure and thus does not allow
extraction of the message type shall cause:
• the BTS equipment to send a Failure Event Report( Event Type = Comms,
Perceived Severity = Major, Probable Cause = Manufacturer:Corrupt 12.21
Message, Additional Text = "Corrupt 12.21 Message received", Additional Info =
<message>), and the message shall be discarded.
• the BSC to discard the message without notification to the BTS (but it may raise an
internal O&M Event).
Receipt of a message of unknown or unsupported Message Type shall cause:

• the BTS equipment to send a Failure Event Report( Event Type = Comms,
Perceived Severity = Major, Probable Cause = Manufacturer:Unsupported 12.21
Message, Additional Text = "Unknown/Unsupported 12.21 Message received",
Additional Info = <message>), and the message shall be discarded.
• the BSC to discard the message without notification to the BTS (but it may raise an
internal O&M Event).
Note that 08.58 defines an Error Report message to specifically allow the reporting of
08.58 message discards.
6.3.1.i Attribute Length field errors
An attribute which includes a length field which is received with a value which does not
match the expected value shall cause the attribute to be discarded, but the message shall
continue to be processed, including any attributes following the discarded attribute, as if
the discarded attribute had not been included in the message. If the attribute was
mandatory this shall lead to the message being handled as missing a mandatory attribute.
6.3.1.ii 12.21 Acks to messages in error
If a message arrives with errors as described above which cause parts of the messages to
be discarded by the receiver, but the receiver continues to accept the validity message,
the Ack message which it sends shall include the complete original message.
6.3.2 Stream Connectivity Loss and Recovery
The detected loss of connectivity of the stream shall be notified to the higher layers, as
shall the initial establishment and any subsequent reestablishment. Their behaviour on
receipt of these notifications is beyond the scope of this specification, except as specified
below.
© ip.access Ltd
- 139 -
6.3.3 Loss of Primary OML
If the Primary OML is disconnected, the BSC shall consider all objects with the Site
Manager as having Operational State “Disabled”, with the Availability Status “Not
Installed”.
The Site Manager should then attempt to reconnect the Primary OML to each of the IP
addresses in the Primary OML IP Address attribute in the order specified in the list, as for
initial connection – see 6.1.1.
6.3.4 Loss of RSL
If the RSL is disconnected, the Channel objects which are configured to connect over this
RSL or rely on this RSL (e.g. TCHs, SDCCHs, BCCHs within the associated Baseband
Transceiver) shall have their Operational State become “Disabled”, with Availability Status
“Dependency”.
The Baseband Transceiver associated with this RSL shall attempt to re-establish the RSL,
as if it were to receive further Connect IP Signalling messages identical to that last
received.
6.3.5 Channel and PDCH Activation and Release errors
Receipt of an RF Channel Release message on a channel which is in the Idle state shall
cause the RF Channel Release Ack to be returned to the BSC, and a management alarm
raised.
Receipt of an PDCH Activation message on a channel which is in the Idle state shall
cause the PDCH Activation Ack to be returned to the BSC, and a management alarm
raised.
Receipt of an PDCH Deactivation message on a channel which is in the Idle state shall
cause the PDCH Deactivation Ack to be returned to the BSC, and a management alarm
raised.
Receipt of a Channel Activation on a static TCH channel which is not Idle shall cause a
Channel Activation Nack to be issued to the BSC, and a management alarm raised.
All other sync problems detected by BTS (PDCH Activate or PDCH Deactivate on an
active TCH, or Channel Activation or RF Channel Release on an active PDCH) shall
cause an 08.58 Error Report, with Cause "Dynamic PDCH sync error - active TCH" or
"Dynamic PDCH sync error - active PDCH" as appropriate.
In all the above error cases, the BTS shall not make any changes to the channel state or
usage as a result of the above errors occurring.
© ip.access Ltd
- 140 -
6.4 Usage of Stream Ids in A-bis
It should be noted that the Stream Id is not included as an Identity. This implies that the
BSC/OMC receiving TCP connections from BTSs shall allocate Stream Ids, IP Addresses
and TCP Port numbers for the TCP connections for OML and RSL so that it may uniquely
identify the BTS Sites and Stream Ids to associate with each TCP connection. A
BSC/OMC is thus typically faced with the following options:
• Different TCP connections may be used for the RSL(s) to different TRXs and for
the OML(s) within a single BTS Site, with different {IP Address, (ephemeral) TCP
Port} pairs used for the different sets of Stream Ids allocated by the OMC to each
BTS Site. The Stream Ids within a single TCP connection shall be unique. The
Identification procedure (or any other suitable means, e.g. originating IP address)
to determine which BTS Site has connected.
• Unrestricted allocation of Stream Id and TCP connections if the BSC does not use
ephemeral TCP ports for the connections for OML and RSL, provided the Stream
Ids are unique within a single TCP connection. The full Identification procedure is
not required if the BSC/OMC may infer the BTS Site which has connected from the
IP Address or TCP port number used for the connection.
6.5 NWL Test Procedures
The NWL functionality in is based on a set of manufacturer-defined Tests, conformant with

the [GSM 12.21] Test Management messages and procedures. (NOTE: Future updates
may have additional methods of invocation and control, including extensions to 08.58
messages and additional 12.21 Object Classes).
As far as NWL is concerned, a TRX may be in either normal operation, in the beacon
transmit test mode, or in one of the downlink receive modes described below. The modes
apply to the TRX as a whole, not individual timeslots.
• Downlink Asynchronous RSSI Monitoring: This mode applies to a TRX which is not
transmitting, with all timeslots being unavailable for assignment by the BSC. There
is no transmission from any TRX of this BTS. The TRX is using the NWL downlink
receiver to monitor the C0 of a BTS (or Cn, or indeed any other signal source) to
which this TRX is not synchronised, and need not be synchronised to, as it may
only make measurements of the RSSI in this mode.
• Downlink Asynchronous BCCH Monitoring: This mode applies to a TRX which is

not transmitting, with all timeslots being unavailable for assignment by the BSC.
There is no transmission on any TRX of this BTS. The TRX is using the NWL
downlink receiver to monitor the BCCH (together with FCCH and SCH) on C0 of a
BTS to which this TRX is not synchronised, and may be extracting frequency, time
and system information.
© ip.access Ltd
- 141 -
• Beacon Transmit: This mode applies to a TRX which is transmitting, but not acting
as a normal TRX, with all timeslots being unavailable for assignment by the BSC.
There is continuous transmission by the TRX. There is no reception on the TRX.
The transmission has a normal GSM slot and frame structure, with full BCCH
channel configuration on slot 0 and all remaining slots transmitting dummy bursts.
The TRX is able to be monitored by other BTSs running NWL or by test receivers.
6.5.1 General interaction with normal operation
The NWL Perform Test messages may be sent to the BTS or Radio Carrier objects. If
sent to the BTS object, the BTS may distribute the test tasks between the available TRXs
as it sees fit to best perform the test. If sent to the Radio Carrier object, the tests shall be
carried out by that Radio Carrier. The NWL Tests may not support the “Not Autonomously
Report” mode of operation.
The manner in which the NWL Tests interact with the normal GSM operation of the BTS is
controlled by the Test Precedence field included in the Physical Config element of the
Perform Test message. Future releases may support additional codings of this value, and
may also support additional controls on its usage, e.g. global or object specific control
attributes which limit the valid settings off this Test Precedence value.
The Availability Status of the object performing the test should be “In test”, and the
operational state shall be disabled. The consequence of this is that all objects contained
within the object under test shall become non-operational, and all downlink transmissions
shall cease for the duration of the test. The previous status (unless anything has
subsequently happened to affect it) shall be restored at the end of the test.
The Manufacturer-define coding of the Autonomously Report (see section 3.7.1) attribute
in the Perform Test message may be used to allow multiple tests to be performed one
after the other without reverting to normal operation between the tests.
Only one NWL test may be in progress at any time to the same object or their dependent
child objects. If a Perform Test is received whilst another Test is still in progress before
the final Test Report (see section 3.7.1), it should be NACKed.
6.5.2 Channel Usage Test
The Channel Usage test uses the NWL downlink receiver to monitor one or more GSM
radio carriers to determine their signal levels. The test requires the Downlink
Asynchronous RSSI Monitoring mode of operation described in section 6.5. To perform
this test the BTS need not demodulate the monitored channel.
The Test Report should include a Channel Usage list, which lists the channels actually
measured and their measurement results.
© ip.access Ltd
- 142 -
6.5.3 BCCH Channel Usage Test
The BCCH Channel Usage test uses the NWL downlink receiver to monitor one or more
GSM radio carriers only if they carry BCCH, to determine their signal levels. The test may
be used to construct a list of C0 frequencies which may then be monitored by the BCCH
Information Test or Frequency Synchronisation Test below. This requires the Downlink
Asynchronous BCCH Monitoring mode of operation described in section 6.5, but only to
detect the presence of BCCH (e.g. detecting SCH and/or FCCH).
The Test Report should include a Channel Usage list, which lists the channels actually
measured and their measurement results. Only those channels which are found to carry a
BCCH are included in the results.
6.5.4 Frequency Synchronisation Test
The Frequency Synchronisation test uses the NWL downlink receiver to monitor one or
more GSM radio carriers, and if suitable BCCH carriers are found, measure the frequency
error of the local oscillator relative to the measured references. The local oscillator may
then be adjusted automatically to correct the error. The algorithm by which the BTS
combines the measured values to determine the single error value is an internal detail,
and may include configurable parameters carried in the Freq Config Params field of the
Frequency Sync Options. This requires the Downlink Asynchronous BCCH Monitoring
mode of operation described in section 6.5, but only to extract the frequency information,
not to decode the System Information on BCCH.
The Physical Config in the Perform Test may optionally include the Frequency Sync
Options, which determine the behaviour and reporting of the test. If omitted, the control
bits shall be considered to be zero. The S bit only affects whether the reported error is
used to correct the local oscillator, and not how it is reported. The L bit only affects the
reporting of the frequency errors: if separate reporting is required, the Frequency Error
List shall contain an entry for each eligible channel, but otherwise contains only a single
Frequency Error, which is the single output of the combining algorithm used by the BTS
on all the measurements taken to derive the overall estimate of error. When performing
this test the BTS makes an assessment of the quality of the error estimate, using an
internal algorithm. This quality estimate may also be used to threshold those
measurements which are included in the test using the Frequency Quality Threshold field
in the Frequency Synch Options. If omitted, the threshold shall default to zero (i.e. all
measurements included).
The Test Report shall, if requested by the L bit, include a Frequency Error List giving the
measured frequency error(s) (before adjustment if the test is to carry out an adjustment).
6.5.5 BCCH Information Test
The BCCH Information test uses the NWL downlink receiver to extract information from
the BCCH on one or more GSM radio carriers. This requires the Downlink Asynchronous
BCCH Monitoring mode of operation described in section 6.5.
© ip.access Ltd
- 143 -
The Test Report shall include a BCCH Information element for each of the channels
measured giving the results.
6.5.6 Beacon Transmit Test
This test may only be performed before the BTS is configured or Op Started by the O&M
system.
The Beacon Transmit test uses the normal downlink transmitter to transmit a continuous
beacon signal on the channel and at the power specified in the Physical Config. The
beacon transmission conforms to the normal GSM slot, frame and multiframe structures.
Slot 0 carries a full BCCH channel combination, and all other slots carry idle TCH (i.e.
contain Dummy Bursts). Slot 0 has the normal FCCH and SCH, which carries the
specified BSIC. The BCCH carries SysInfo 2, SysInfo 3 and SysInfo 4, but the CCCH
channels are empty and Dummy Bursts are transmitted as required. The SysInfo
messages mark the cell as barred with no neighbour lists or cell allocation lists. The
PLMN shall be indicated as the well-known GSM Test PLMN, 001-01.
The Test Report contains no information.
6.5.7 SysInfo Monitor Test
The SysInfo Monitor test uses the NWL downlink receiver to extract information from the
BCCH for a particular BTS, identified by its BSIC and ARFCN. This requires the Downlink
Asynchronous BCCH Monitoring mode of operation described in section 6.5. The aim of
the test is to report the full set of System Information messages being broadcast by a
particular BTS, and, if Autonomously Report is enabled, to report any changes to the set
during the duration of the test.
A set of Test Reports shall be sent, each containing a single Broadcast L3 Message.
If Autonomously Report is enabled, the BTS shall issue a partial result Test Report as it
encounters each System Information message. It shall not repeatedly report the same
System Information message during a test unless its contents change. On termination of
the test it shall send a Test Report (which may be empty) which indicates that it is the final
Test Report.
If Autonomously Report is not specified, the BTS shall report the last complete set of
System Information messages it received.
6.5.8 BCCH and CCCH Monitor Test
The BCCH and CCCH Monitor test uses the NWL downlink receiver to continuously
monitor and report the BCCH and CCCH for a particular BTS, identified by its BSIC and
ARFCN. This requires the Downlink Asynchronous BCCH Monitoring mode of operation
described in section 6.5. The aim of the test is to continuously report all BCCH, and
© ip.access Ltd
- 144 -
CCCH (AGCH, PCH) messages being broadcast by a particular BTS. This test requires
the Start Test to set Autonomously Report to be enabled.
A set of Test Reports shall be sent, each containing a single Broadcast L3 Message.
The BTS shall issue a partial result Test Report whenever it successfully decodes a
BCCH or CCCH message. On termination of the test it shall send a Test Report (which
may be empty) which indicates that it is the final Test Report.
6.6 Code Download Procedures
The supported code download options are described in the following sections.
6.6.1 12.21-based Code Download
The standard 12.21 Code Download procedure may be used, at any time after the BTS
has sent the Activate SW Request, to update the BTS code with the following extensions
and limitations:
• This procedure may be invoked at any time after Activate SW Request, i.e.
including after configuration and OpStart;
• The standard 12.21 Code Download procedure only downloads the new code, it
does not set it as the default code to be used at the next boot, nor does it cause it
to be invoked in any way.
• It is not possible to overwrite either the currently active SW nor the default SW for
the next boot (if different) – the BTS shall fail any download which would require
such overwrite due to its storage limitations.
• The Set/Get NV Attributes of the Current SW Configuration may be used to specify
and view which SW Configuration is to be used at the next boot.
• The Reinitialise message may be used to invoke a complete reset of the hardware
and software to invoke the current default boot image.
• The download and activation procedure may be carried out over either the primary
or secondary OML port.
6.6.2 TFTP Code Download
TFTP Code Download during DHCP operation is no longer supported.
6.7 Management States
The behaviour of the BTS over the air interface and to the BSC over the RSL shall be
affected by the O&M management states as described in this section. The Administrative
state reflects the service state commanded by the OMC, where as the Operational State
reflects the objects ability to provide service. A third standard management State, the
Usage State (which is not explicitly considered in 12.21, but is described in ITU X.731 on
© ip.access Ltd
- 145 -
which 12.21 is loosely based) describes the current service being provided, has one of
three states:
• IDLE – there are no current users of the service which the object provides
• ACTIVE – there are some current users of the service which the object provides,
but more service is available to new users
• BUSY – the object is providing service to its capacity limits.
These states are used to clarify the operation of the objects in the other states.
The Usage states are:
• A Channel object with all its dedicated channels active shall be BUSY
• A Channel object with some but not all of its dedicated channels active shall be
ACTIVE
• A Channel object with none of its dedicated channels active shall be IDLE
• Any common channels assigned to a Channel object do not contribute to the
Usage state of the Channel
• A Site Manager, BTS, Baseband Transceiver, or Radio Carrier objects shall be
IDLE if all their associated dependent child objects are IDLE, and BUSY if they are
all BUSY, and ACTIVE otherwise.
The managed objects are considered to be in a hierarchical structure, as described in the

diagram in section 5.1 of [GSM 12.21]. An object which is below and associated with
another is said to be a child of the above object. Objects which are on the same level and
associated with each other are said to be peers. An object which is above another and
associated with it is said to be a parent of the object.
6.7.1 Operating normally
The term “operating normally” is used to denote that an object is both Administratively
UNLOCKED and Operationally ENABLED. In this state the object is providing a normal
service to users. The Usage state may be at any value.
6.7.2 Administratively LOCKED
An object which is Administratively LOCKED cannot be providing service to any users. On

command from the OMC to become LOCKED, an object which is providing service shall
immediately and forcibly stop providing the service to the users. It may be Operationally
ENABLED or DISABLED. The Usage state is by definition IDLE.
On transitions to this state:
• A Channel object shall

o If it is Channel 0 on Radio Carrier 0, cause the BTS to become
DISABLED(dependency).
© ip.access Ltd
- 146 -
o If it was Active with a dedicated channel, issue a Connection Failure
Indication with cause “O&M intervention” (it need not await a subsequent
RF channel Release before becoming inactive)
o Negatively Acknowledge any Channel Activations with Cause “O&M
Intervention”
o Start producing dummy bursts on the downlink and ignoring any data
received on the uplink (note: this may not result in any transmissions due to
downlink DTX or due to the transmitter being off for other reasons)
o Continue to accept RSL common channel commands (e.g. BCCH INFO,
PAGING CMD, IMMEDIATE ASSIGN COMMAND, SMS BROADCAST
REQUEST and SMS BROADCAST COMMAND) and process them
normally in Layer 2, but any resultant layer 1 transmission shall be
discarded (NOTE: the effect of this is that on UNLOCKING the channel the
effect of these messages will not have been discarded, including the
possibility of Paging Repeats being carried out).
• A Baseband Transceiver object shall
o Operationally DISABLE(dependency) the contained Channel objects
(which if it is the Baseband Transceiver associated with carrier 0, will also
cause the BTS to become disabled – see above)
o Continue to accept RSL TRX Management commands (e.g. SACCH FILL)
saving the results (NOTE: the effect of this is that on UNLOCKING the
channel the effect of these messages will not have been discarded).
o Continue to accept all RSL Common Channel Management, Radio Link
Layer and Dedicated Channel Management messages and route them to
the appropriate Channel.
• A Radio Carrier object shall
o Cease downlink transmissions and provide no uplink data
o If it is Radio Carrier 0, cause the BTS to become operationally
• A BTS object shall
o Operationally DISABLE(dependency) the associated Baseband
Transceiver, Radio Carrier, and Channel objects
• A GPRS NSE object shall
o Operationally DISABLE(dependency) the contained GPRS Cell and GPRS
NSVC objects (and consequential blocking of the NSVCs)
• A GPRS Cell object shall
o Block the associated PTP BVC
o Reject MS Channel Requests
• A GPRS NSVC object shall
o Block the associated NSVC
Transitions from this state ENABLE the corresponding Operational states described
above, and in the case of the Radio Carrier object, allow downlink transmission and uplink
reception (subject to the normally operating DTX rules).
© ip.access Ltd
- 147 -
6.7.3 Operationally DISABLED
An object which is Operationally DISABLED (whether it be due to dependency on other

objects, failure of equipment, incorrect configuration etc.) cannot provide service to users.
It may be Administratively LOCKED or UNLOCKED. The Usage state is by definition
IDLE.
Transitions to this state shall be as described for the transitions to the Administratively
LOCKED state in section 6.7.2 above, except that the object which is associated with the
underlying failure should additionally emit a Failure Event Report with the Cause value
“Equipment Failure”, “O&M Intervention” etc., as appropriate (with the most appropriate
Cause value if more than one applies).
A GPRS NSE with no operating contained GPRS NSVCs shall be

DISABLED(dependency), and consequently so will all the contained GPRS Cell objects.
A GPRS NSE with no operating contained GPRS Cells shall be DISABLED(dependency),

and consequently so will all the contained GPRS NSVC objects.
6.7.4 Administratively SHUTTING DOWN
An object which is Administratively SHUTTING DOWN shall continue to provide service to

existing users, but not provide new service. It shall immediately transition to LOCKED
once the last existing user has left the service (i.e. the Usage state has become IDLE).
Note that an object which is Administratively SHUTTING DOWN is by definition
Operationally ENABLED: if it were not, it would immediately transition to being
Administratively LOCKED. The Usage state is by definition ACTIVE or BUSY: if it were
IDLE, it would immediately transition to being Administratively LOCKED.
On transitions to this state:
• A Channel object shall

o Await the normal deactivation of any active dedicated channels, on which
case it shall transition to LOCKED
o Negatively Acknowledge any Channel Activations with Cause “O&M
Intervention”
o If providing BCCH or other common channels, continue to process Page
Requests and Channel Required messages, CBCH etc
An object which is a child of an object which is Administratively SHUTTING DOWN shall

behave as if it too were in this state, but without any transition to LOCKED. When the
parent object transitions to LOCKED, the child objects shall become operationally
© ip.access Ltd
- 148 -
6.8 Object Initialisation, Creation and Deletion
All objects unless otherwise stated, shall support a common set of initialisation, creation
and deletion procedures, based on the 12.21 section 5.3.2 Figure 2. The initialisation shall
comprise the SW Activation, optionally including SW download, object configuration, and
opStart. The details of these procedures are described below.
The Channel objects do not support SW Activation or SW Download: these procedures

are implicitly linked with the procedures on the containing Baseband Transceiver objects.
The Channel objects shall be extended to issue a SW Activated Report (containing their
Object Version) once the SW Activated Report for the Baseband Transceiver has been
issued. The BSC should then continue with attribute setting on the Channels prior to
opStart of the containing Baseband Transceiver object.
6.8.1 Initialisation
Upon connection of the Primary OML (or Secondary OML if no Primary OML is connected
and the object is not yet initialised), each object shall initiate the initialisation. The
initialisation of many objects may occur in parallel, with the order controlled by the objects
starting the process by issuing a SW Activate Request, but requires that any containing
objects shall have successfully completed SW Activation prior to initiation of SW
Activation of its contained objects.
A BSC which has been provisioned with the relevant object instance shall continue the
initialisation process by responding with a SW Activate Request Ack, and then proceed
with SW download if required, SW Activation, Attribute setting and any other required
configuration, and finally perform the opStart procedure.
A BSC which has not been provisioned with the relevant object instance shall terminate
the initialisation process by responding with a SW Activate Request Nack (cause = object
instance unknown). The object in the BTS equipment should then await the object
Creation process, but may continue to request SW activation periodically, with at least [60]
seconds between requests.
6.8.2 Creation
If a new 12.21 object is created by provisioning within the BSC and is associated with an
OML which is connected, the BSC may request the SW Configuration and HW
Configuration of the object, and should initiate the object creation over 12.21 by sending
an Activate SW message to the object. The normal initialisation procedure should then
ensue.
6.8.3 Deletion
If a 12.21 object is deleted by de-provisioning within the BSC and is associated with an
OML which is connected, and has been SW Activated, the BSC shall send a Deactivate
© ip.access Ltd
- 149 -
SW to the object. The object shall then cease normal operation and return to the initial
state, and should attempt the SW Activation procedure.
6.8.4 Set and Get Attributes during initialisation
Prior to completion of the SW Activation procedure, the objects are only required to
support the Get Attributes for the following attributes:
• HW Configuration
• SW Configuration
• Manufacturer Id
• Current SW Configuration
• Administrative State
• Operational State (always DISABLED prior to SW Activation)
• Availability Status (always “Not Installed” prior to SW Activation)
• Object Version
• Timing Bus
• Supported Features
• Power Class
• Up Time
Once the SW Activation has completed, an object shall support the Set or Get of any of
the supported attributes, and the Availability Status value shall no longer include the “Not
Installed” value.
The objects shall support the Get NV Attributes and Set NV Attributes, and (where
supported to allow the current value rather than the NV initial value to be obtained) Get
Attributes of any NV attributes at any time.
6.8.5 Procedures during initialisation
Prior to completion of the SW Activation procedure, the objects only support the following
procedures:
• SW Activation
• SW Download
• Reinitialisation
• Get Attributes
• Get NV Attributes
• Set NV Attributes
6.9 Object Versions
Each object shall support the Object Version attribute. The use of this attribute by the
managed objects and by the BSC is described in section 3.3.27. This section describes
how the values of this attribute are assigned.
© ip.access Ltd
- 150 -
The Object Version Number describes the MIB behaviour of an object. Upon completion
of SW Activation, the combination of the HW Description which describes the capabilities
of the equipment which hosts an object, and the SW Description which is activated for the
object determines the behaviour, or optional behaviours which the object may obtain, and
each of the optional behaviours is described by an Object Version Number within the
Object Version attribute in the SW Activated Report from the object. The Object Version
Numbers shall be included in preference order.
The BSC may set the Object Version to a single Object Version Number prior to opStart,
and thus determine the actual behaviour of the object. Prior to setting the Object Version
Number, the object shall behave as the first, preferred Object Version Number in the ist
(apart from the behaviour described in this section). If the BSC does not set the Object
Version attribute, the object shall continue to assume the first, preferred Object Version
Number at opStart. Following the selection of the actual Object Version Number (either by
the Set, or by opStart without a Set), the Object Version attribute shall contain only the
single selected value.
The Object Version Number describes the behaviour as specified in this specification. As
the behaviour changes over versions of this specification, a new unique Object Version
Number to describe the modified behaviours shall be assigned. The changes in behaviour
which require a new unique Object Version Number to be assigned are:
• Addition or removal of support for messages or procedures

• Addition or removal of attributes
• Addition or removal of support for values of mandatory fields of write-able
attributes or of attributes within action messages (e.g. Test No in test management
messages).
Note:
• Modification of a write-able attribute is equivalent to the removal of the old format
and addition of an attribute with the new format, and hence requires a modification
of the Object Version Number.
• Modification of supported values within optional fields or in read-only fields
provided the attributes remain parse-able under the old version behaviour (e.g.
additional embedded IEs in read-only attributes) does not require a change of
Object Version umber, but such a change of Object Version Number may be made
to enhance the capability of the BSC to manage the managed objects.
6.10 Measurement Pre-Processing
The BTS may be configured (using the Pre-processing Parameters IE within the
Measurement Pre-processing Defaults or the Pre-process Configure messages) to
perform measurement pre-processing for power control and handover candidate
determination. If so configured, the BTS shall perform the measurement pre-processing,
and issue Pre-processed Measurement Results messages containing the Pre-processed
Measurements IE, which may contain the embedded IEs Handover Cause and Handover
Candidates, each of which contains a list.
© ip.access Ltd
- 151 -
When the BTS first issues a Pre-processed Measurement Results on a connection, it shall
start timer T_ho, and record the set of Handover Cause values sent in the message. If
further measurement pre-processing occurs whilst T_ho is running, the list of Handover
Cause values which result shall be compared by the BTS to the recorded set. If all
Handover Cause values are already in the recorded set, no further action shall be taken
by the BTS. If there are one or more Handover Cause values not in the recorded set, a
new Pre-processed Measurement Results shall be issued with the current set of
Handover Cause values, and the recorded Cause values shall be updated to add the new
Cause values. On expiry of the T_ho timer, the BTS shall send a Pre-Processed
Measurement Result message with the current list of Handover Causes (which may be
empty), and the recorded list of Cause values shall be set to the current list, and if the
Handover Cause list is not empty, restart T_ho.
6.11 Performance Management Measurements
The basic Measurement messages and processes are as described in [GSM1221].
The MeasurementId (also called Measurement Type in 12.21) is a single octet with 0x00-
0x3f reserved and 0x40-0xff manufacturer-specific 1. The BTS zeros the measurement
values after sending the response and continues to collect afresh until stopped.
There is no defined configuration method (e.g. periodicity, granularity) of the

measurements: measurements are continuously collected within the BTS until Stopped or
Requested 2.
These standard 12.21 facilities will be used between the BTS and BSC with the following
enhancements:-
1. The Measurement Results IE contain a set of one or more embedded IEs, each
containing a single measurement value or an array of measurement values of the
same type, as determined by the embedded IEI (see section 3.4.21.i). The set of
embedded IEs returned is determined by the MeasurementId. (12.21 defined only
a single MSB-first multi-octet result value). Each embedded IE shall typically
correspond to values needed for a single attribute of a Measurement Function –
see MIB for details.
1
The use of a single octet for the MeasurementId restricts the number of distinct measurements
per object class. If this becomes a limitation in the future the MeasurementId shall be modified or
replaced with a new MeasurementId attribute which is a TLV, and shall (initially at least) carry a 16
bit integer value. This is not required initially.
2
This introduces some measurement skew both for the collection of reports across object classes
within the same BTS, and across the same or different classes across multiple BTSs. It is
envisaged that this skew should be negligible compared to the minimum 5 minute granularity of
measurement. If this is not the case, the above 12.21 measurement capabilities would be extended
to include synchronous results capture, with asynchronous collection as above (e.g. include a
granularity period in the Start Measurements, synchronised to GSM frame, and have the Request
Measurement Results collect only complete measurements after each period.
© ip.access Ltd
- 152 -
The BSC shall be responsible for the Starting, Stopping and Requesting results from the
BTS as required to satisfy the Measurement Function object instances (e.g. Start
measurements when the corresponding Measurement Function is created, Stop when it is
deleted, and send Measurement Results Request whenever a scanner requires the data.
Any loss of communication between BTS and BSC (e.g. BTS reset) requires the BSC to
mark the collected data as suspect, and may require it to restart the measurements within
the BTS (e.g. at BTS configuration time) if the BTS or some of its contained objects were
to restart.
A single Measurement Id value on a single object shall typically be defined to provide all
the measurement values needed by the BSC to satisfy all the measurement attributes
needed from the BTS for a single instance of a Measurement Function object. The
detailed mappings are described in the detailed definitions of the Measurement Functions
in the MIB.
The units of all measurements involving time shall be as described in the MIB, but
typically seconds unless otherwise stated.
6.12 Downlink DTX
The BSC shall use the DTXd field of the GSM 08.58 Channel Mode IE to indicate whether
Silence Suppression is applied on the downlink RTP stream to the TRX or not (see
section 4.2.28) for the associated air interface traffic channel, and also controls the
downlink DTX behaviour.
If the value of the DTXd field is zero, Silence Suppression is not in use on the downlink to
the TRX on the specified traffic channel, and the TRX should not invoke DTX on the air
interface downlink to the MS, i.e. the channel is constantly transmitted. If, due to packet
loss or excessive delay on the A-bis link, the TRX does not have an RTP payload to
transmit to the MS at the point of transmission it should:
• For FR and EFR speech: transmit an empty Layer 2 frame on FACH

• For AMR: transmit an AMR INVALID SPEECH frame
• For CSD: transmit an empty Layer 2 frame on FACH
If the value of the DTXd field is one, Silence Suppression is in use on the downlink to the
TRX on the specified traffic channel. The TRX should be receiving SID frames prior to
periods of no RTP packets (but may not due to packet loss or excessive delay). If, due to
packet loss or excessive delay on the A-bis link, the TRX does not have an RTP payload
to transmit to the MS at the point of transmission it should:
• FR and EFR speech: transmit the last received SID frame (if available) or an
empty Layer 2 frame on FACH
• AMR: the TRX should receive SID ONSET and SID UPDATE frames prior to
periods of silence, so if it fails to receive an RTP frame without an immediately
© ip.access Ltd
- 153 -
preceding SID UPDATE (and have no L3 message to send on FACCH) it should
send INVALID SPEECH, but if it has immediately preceding received SID
UPDATE, it should repeat that SID UPDATE.
• CSD: transmit an empty Layer 2 frame on FACH
Also, if the value of the DTXd field is one, the radio power may be turned off to invoke
downlink DTX for that timeslot if:
• the timeslot is not being transmitted on the BCCH frequency, and
• the timeslot contains only a Layer 2 Idle frame, a repeated_FR or EFR SID frame,
an AMR INVALID SPEECH frame or a repeated_AMR SID UPDATE frame, and
• it is not a mandatory frame for transmission
© ip.access Ltd
- 154 -
7 SPARE
© ip.access Ltd
- 155 -
8 ASSIGNED NUMBERS
8.1 Port Numbers
The default values of the Primary and Secondary OML port numbers shall be the following
pending IANA registration:
Primary OML Port (at BSC): 3002/TCP

Secure Primary OML Port (at BSC): 3022/TCP
Secondary OML Port (at BTS): 3006/TCP
Secure Secondary OML Port (at BTS): 3026/TCP
Primary OML Proxy (at BSC) 3005/TCP
BTS Finder Port (at BTS): 3006/UDP
IANA registration is being sought for a single value to be used for all ports.
In addition, the following ports are used by convention, but may be configured to other
values by normal O&M procedures:
RSL Port (at BSC) 3003/TCP

Secure RSL Port (at BSC) 3023/TCP
RTP port range: (at BTS) 4000-4031/UDP
NS over IP port (at BTS) 23000/UDP
NS over IP port (at SGSN) 23000/UDP
SNMP port (at BTS) 161/UDP
SNMP Trap Port (at manager) 162/UDP
SITE IML Port (at BTS) 3013/TCP
Secure Site IML Port 3033/TCP
BTS IML Port (at BTS) 3014/TCP
Secure BTS IML Port 3034/TCP
RTP Multiplex Port (at BSC) 3998/UDP
SRTP Multiplex Port (at BSC) 3996/UDP
RTP port range (from BSC proxy to media gateway) 4000+/UDP
8.2 Payload Type
The following RTP payload types are recommended for use from the BTS to the BSC:
Speech:
GSM FR 0x03
GSM EFR 0x61
GSM AMR FR 0x62
GSM AMR HR 0x63
GSM HR 0x64
© ip.access Ltd
- 156 -
CSD:
8kb/s RTP Rate 0x65
16kb/s RTP Rate 0x66
Between the RTP Multiplexers the following RTP payload type is recommended:
MULTIPLEXED 0x60
End of Document
© ip.access Ltd
- 157 -

A-Bis Over IP Interface v02 00

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

A-Bis Over IP Interface v02 00

Hochgeladen von

Copyright:

Verfügbare Formate

ip.

Version Change Summary Date Author

Approved by ......................................................................... Date

3 O&M SIGNALLING MESSAGES 6

3.3 O&M Signalling Attributes 14

3.5.14 Date and time of Manufacture and Calibration 58

3.6.7 State Changed Event Report 67

4 RSL SIGNALLING MESSAGES 87

4.1.6 Modify Connection Negative Acknowledge 90

4.2.4 Source IP Port 101

4.3 08.58 Message Embedded Information Elements 115

5 USER TRAFFIC MESSAGES 126

5.3 Spare 127

6.1.2 RSL Establishment 135

6.8.1 Initialisation 149

8 ASSIGNED NUMBERS 156

1.4 Deployment Scenarios

Standard GSM terminology may be found in [GSM 01.04].

[SIG-IP] Signalling over IP, Neil Piercy.

[PM] SRx.y Measurement Definitions, SR-specific CENGxxxx (supplied with

[ALARMS] Alarm Specification XML.

All Reserved fields shall be transmitted as zero.

2.1 Physical Layer

2.2 Layer 2 Signalling

2.4 Signalling Message Transports

• Reliable transport: messages shall be reliably delivered, or a break in the

Secondary requirements on the transport are:

• Security: it should be possible to authenticate and encrypt the transport link –

2.4.1 Framed TCP Transport

The maximum value of the Connection Frame Length shall be [273].

2.4.3 UDP Transport

All Reserved fields shall be transmitted as zero.

3.1 Unsupported O&M messages

3.1.1 Unsupported O&M Attributes

3.2 Manufacturer-Defined O&M Messages

The following manufacturer-defined messages shall be carried in messages formatted

ManId Length Indicator: 13 (decimal)

3.2.1 Connect IP Signalling

Information Element Ref Presence Format Length

3.2.2 Disconnect IP Signalling

3.2.6 Set NV Attributes

3.2.7 Get NV Attributes

Information Element Ref Presence Format Length

The List of Required Attributes may only include:

3.2.8 Set Attributes

3.2.8.i Set Attributes to the Site Manager

Information Element Ref Presence Format Length

Information Element Ref Presence Format Length

3.2.8.iii Set Attributes to the GPRS NSE

Information Element Ref Presence Format Length

3.2.8.iv Set Attributes to the GPRS Cell

Information Element Ref Presence Format Length

Information Element Ref Presence Format Length

3.2.9 Attribute Value Change Event

Information Element Ref Presence Format Length

Information Element Ref Presence Format Length

3.3 O&M Signalling Attributes

3.3.1 O&M Manufacturer-Defined Message Type

Manufacturer-Defined Message Type 1

Start Measurement Ack 0xDE

3.3.2 O&M Manufacturer-Defined Attribute Identifiers

Destination IP Address 0x80

Manufacturer-Defined Attribute Identifier 1