gprs family
DESCRIPTION
gprsTRANSCRIPT
GPRS Family
BCC
3G TS 24.069 version 3.1.0
The Broadcast Call Control (BCC) protocol is used by the Voice Group Call Service (VGCS) on the radio interface. It is one of the Connection Management (CM) sublayer protocols (see GSM 04.07).Generally a number of mobiles stations (MS) participate in a broadcast call. Consequently, there is generally more than one MS with a BCC entity engaged in the same broadcast call, and there is one BCC entity in the network engaged in that broadcast call.The MS ignores BCC messages sent in unacknowledged mode and which specify as destination a mobile identity which is not a mobile identity of that MS. Higher layers and the MM sub-layer decide when to accept parallel BCC transactions and when/whether to accept BCC transactions in parallel to other CM transactions.The broadcast call may be initiated by a mobile user or by a dispatcher. The originator of the BCC transaction chooses the Transaction Identifier (TI).The call control entities are described as communicating finite state machines which exchange messages across the radio interface and communicate internally with other protocol (sub)layers. In particular, the BCC protocol uses the MM and RR sublayer specified in GSM 04.08. The network should apply supervisory functions to verify that the BCC procedures are progressing and if not, take appropriate means to resolve the problems.The elementary procedures in the BCC include: Broadcast call establishment procedures, Broadcast call termination procedures Broadcast call information phase procedures Various miscellaneous procedures.All messages have the following header:87654321OctetTransaction identifierProtocol discriminator1Message type2Information elements3-nBCC beader structure.Protocol discriminatorThe protocol discriminator specifies the message being transferredTransaction identifierDistinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:8765TI flagTI valueTransaction identifierTI flagIdentifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.TI valueThe side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface.Message typeThe message type defines the function of each BCC message. The message type defines the function of each BCC message. The following message types exist:0x110001IMMEDIATE SETUP0x110010SETUP0x110011CONNECT0x110100TERMINATION0x110101TERMINATION REQUEST0x110110TERMINATION REJECT0x111000STATUS0x111001GET STATUS0x111010SET PARAMETERInformation elementsEach information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included.Interested in more details about testing this protocol?
BSSAP+
http://www.etsi.org/ GSM 09.18 version 7.1.0 release 1998
BSSAP+ defines use of mobile resources when a mobile station supports both GSM circuit switched services and GSM packet switched services. It defines procedures used on the Serving GPRS Support Node (SGSN) to Visitors Location Register (VLR) for interoperability between circuit and packet switched services. Layer 3 messages on the Gs interface are defined.
BSSAP+
BSSAP+SCCP
SCCPMTP L3
MTP L3MTP L2
MTP L2L1
L1SGSNGsMSC/VLRBSSAP+ protocol layer structure over Gs interface
The Gs interface connects the databases in the MSC/VLR and the SGSN. The procedures the of BSSAP+ protocol are used to co-ordinate the location information of MSs that are IMSI attached to both GPRS and non-GPRS services. The Gs interface is also used to convey some circuit switched related procedures via the SGSN.The basis for the interworking between a VLR and an SGSN is the existence of an association between those entities per MS. An association consists of the SGSN storing the number of the VLR serving the MS for circuit switched services and the VLR storing the number of the SGSN serving the MS for packet switched services. The association is only applicable to MSs in class-A mode of operation and MSs in class-B mode of operation.All the messages in BSSAP+ use the SCCP class 0 connectionless service.When the return option in SCCP is used and the sender receives an N_NOTICE indication from SCCP, the sending entity reports to the Operation and Maintenance system (see ITU-T Q.714).The behaviour of the VLR and the SGSN entities related to the Gs interface are defined by the state of the association for an MS. Individual states per association, i.e. per MS in class-A mode of operation and MS in class-B mode of operation, are held at both the VLR and the SGSN.87654321OctetMessage type1Information elements2-nBSSAP+ beader structure
.The message type uniquely identifies the message being sent. The following BSSAP+ message types exist:ValueMessage type00000000Unassigned: treated as an unknown Message type.00000001BSSAP+-PAGING-REQUEST.00000010BSSAP+-PAGING-REJECT00000011to00001000Unassigned: treated as an unknown Message type.0000100100001001BSSAP+-LOCATION-UPDATE-REQUEST.00001010BSSAP+-LOCATION-UPDATE-ACCEPT.00001011BSSAP+-LOCATION-UPDATE-REJECT.00001100BSSAP+-TMSI-REALLOCATION-COMPLETE.00001101BSSAP+-ALERT-REQUEST.00001110BSSAP+-ALERT-ACK.00001111BSSAP+-ALERT-REJECT.00010000BSSAP+-MS-ACTIVITY-INDICATION.00010001BSSAP+-GPRS-DETACH-INDICATION.00010010BSSAP+-GPRS-DETACH-ACK.00010011BSSAP+-IMSI-DETACH-INDICATION.00010100BSSAP+-IMSI-DETACH-ACK.00010101BSSAP+-RESET-INDICATION.00010110BSSAP+-RESET-ACK.00010111BSSAP+-MS-INFORMATION-REQUEST.00011000BSSAP+-MS-INFORMATION-RESPONSE.00011001Unassigned: treated as an unknown Message type.00011010BSSAP+-MM-INFORMATION-REQUEST.00011101BSSAP+-MOBILE-STATUS.00011110Unassigned: treated as an unknown Message type.00011111BSSAP+-MS-UNREACHABLE.Each message type has specific information elements00000001IMSI.00000010VLR number.00000011TMSI.00000100Location area identifier.00000101Channel Needed.00000110eMLPP Priority.00000111Unassigned: treated as an unknown IEI.00001000Gs cause.00001001SGSN number.00001010GPRS location update type.00001011Unassigned: treated as an unknown IEI.00001100Unassigned: treated as an unknown IEI.00001101Mobile station classmark 1.00001110Mobile identity.00001111Reject cause.00010000IMSI detach from GPRS service type.00010001IMSI detach from non-GPRS service type.00010010Information requested.00010011PTMSI.00010100IMEI.00010101IMEISV.00010110Unassigned: treated as an unknown IEI.00010111MM information.00011000Cell Global Identity.00011001Location information age.00011010Mobile station state.00011011Erroneous message.00011100to11111111Unassigned: treated as an unknown IEI.Interested in more details about testing this protocol?
BSSGP
GSM 08.18 version 6.1.0http://www.etsi.frThe NS transports BSS (base station system) GPRS protocol PDUs between a BSS and an SGSN (serving GPRS support node). The primary functions of the BSSGP include:
Provision by an SGSN to a BSS of radio related information used by the RLC/MAC function (in the downlink).
Provision by a BSS to an SGSN of radio related information derived from the RLC/MAC function (In the uplink).
Provision of functionality to enable two physically distinct nodes, an SGSN and a BSS, to operate node management control functions.
BSSGP PDUs are of the following format:
8
7
6
5
4
3
2
1
Octets
PDU type
1
Other Information Elements
2-n
NS PDU structure
Interested in more details about testing this protocol?
GCC
3G TS 24.068 version 3.1.0
The Group Call Control (GCC) protocol is used by the Voice Group Call Service (VGCS) on the radio interface within the 3GPP system. It is one of the Connection Management (CM) sublayer protocols (see GSM 04.07).Generally a number of mobiles stations (MS) participate in a group call. Consequently, there is in general more than one MS with a GCC entity engaged in the same group call, and there is one GCC entity in the network engaged in that group call.The MS ignores GCC messages sent in unacknowledged mode and which specify as destination a mobile identity which is not a mobile identity of that MS. Higher layers and the MM sub-layer decide when to accept parallel GCC transactions and when/whether to accept GCC transactions in parallel to other CM transactions.The group call may be initiated by a mobile user or by a dispatcher. In certain situations, a MS assumes to be the originator of a group call without being the originator. The originator of the GCC transaction chooses the Transaction Identifier (TI).The call control entities are described as communicating finite state machines which exchange messages across the radio interface and communicate internally with other protocol (sub) layers. In particular, the GCC protocol uses the MM and RR sublayer specified in GSM 04.08. The network should apply supervisory functions to verify that the GCC procedures are progressing and if not, take appropriate means to resolve the problems.The elementary procedures in the GCC include: Group call establishment procedures, Group call termination procedures Call information phase procedures Various miscellaneous procedures.All messages have the following header:87654321OctetTransaction identifierProtocol discriminator1Message type2Information elements3-nGCC beader structure
.Protocol discriminatorThe protocol discriminator specifies the message being transferredTransaction identifierDistinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:8765TI flagTI valueTransaction identifier
TI flagIdentifies who allocated the TI value for this transaction. The purpose of the TI flag is to resolve simultaneous attempts to allocate the same TI value.TI valueThe side of the interface initiating a transaction assigns TI values. At the beginning of a transaction, a free TI value is chosen and assigned to this transaction. It then remains fixed for the lifetime of the transaction. After a transaction ends, the associated TI value is free and may be reassigned to a later transaction. Two identical transaction identifier values may be used when each value pertains to a transaction originated at opposite ends of the interface.Message typeThe message type defines the function of each GCC message. The following message types exist:0x110001IMMEDIATE SETUP0x110010SETUP0x110011CONNECT0x1100100TERMINATION0x110101TERMINATION REQUEST0x110110TERMINATION REJECT0x111000STATUS0x111001GET STATUS0x111010SET PARAMETERInformation elementsEach information element has a name which is coded as a single octet. The length of an information element may be fixed or variable and a length indicator for each one may be included.Interested in more details about testing this protocol?
GMM
GSM 04.08http://www.etsi.orgGPRS uses the GSM MM (Mobility Management) protocol. Here it is known as the GPRS MM protocol (GMM). The main function of the MM sub-layer is to support the mobility of user terminals, for instance, informing the network of its present location and providing user identity confidentiality. A further function of the GMM sub-layer is to provide connection management services to the different entities of the upper Connection Management (CM) sub-layer.The format of the header is shown in the following illustration:87654321OctetProtocol discriminatorSkip indicator1Message type2Information elements3-nGMM beader structure
.Protocol discriminator1000 identifies the GMM protocol.Skip indicatorThe value of this field is 0000.Message typeUniquely defines the function and format of each GMM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GMM message types may be:0 0 0 0 0 0 0 1Attach request0 0 0 0 0 0 1 0Attach accept0 0 0 0 0 0 1 1Attach complete0 0 0 0 0 1 0 0Attach reject0 0 0 0 0 1 0 1Detach request0 0 0 0 0 1 1 0Detach accept0 0 0 0 1 0 0 0Routing area update request0 0 0 0 1 0 0 1Routing area update accept0 0 0 0 1 0 1 0Routing area update complete0 0 0 0 1 0 1 1Routing area update reject0 0 0 1 0 0 0 0P-TMSI reallocation command0 0 0 1 0 0 0 1P-TMSI reallocation complete0 0 0 1 0 0 1 0Authentication and ciphering req0 0 0 1 0 0 1 1Authentication and ciphering resp0 0 0 1 0 1 0 0Authentication and ciphering rej0 0 0 1 0 1 0 1Identity request0 0 0 1 0 1 1 0Identity response0 0 1 0 0 0 0 0GMM status0 0 1 0 0 0 0 1GMM informationInformation elementsVarious information elements.Interested in more details about testing this protocol?
GSM
GSM 04.08http://www.etsi.orgThe main function of the GPRS session management (SM) is to support PDP context handling of the user terminal. The SM comprises procedures for: identified PDP context activation, deactivation and modification, and anonymous PDP context activation and deactivation.The format of the header is shown in the following illustration:87654321OctetProtocol discriminatorSkip indicator1Message type2Information elements3-nGSM beader structure
.Protocol discriminator1010 identifies the GSM protocol.Skip indicatorThe value of this field is 0000.Message typeUniquely defines the function and format of each GSM message. The message type is mandatory for all messages. Bit 8 is reserved for possible future use as an extension bit. Bit 7 is reserved for the send sequence number in messages sent from the mobile station. GSM message types may be:0 1 x x x x x xSession management messages0 1 0 0 0 0 0 1Activate PDP context request0 1 0 0 0 0 1 0Activate PDP context accept0 1 0 0 0 0 1 1Activate PDP context reject0 1 0 0 0 1 0 0Request PDP context activation0 1 0 0 0 1 0 1Request PDP context activation rej.0 1 0 0 0 1 1 0Deactivate PDP context request0 1 0 0 0 1 1 1Deactivate PDP context accept0 1 0 0 1 0 0 0Modify PDP context request0 1 0 0 1 0 0 1Modify PDP context accept0 1 0 1 0 0 0 0Activate AA PDP context request0 1 0 1 0 0 0 1Activate AA PDP context accept0 1 0 1 0 0 1 0Activate AA PDP context reject0 1 0 1 0 0 1 1Deactivate AA PDP context request0 1 0 1 0 1 0 0Deactivate AA PDP context accept0 1 0 1 0 1 0 1SM StatusInformation elementsVarious information elements.Interested in more details about testing this protocol?
GTP
specifies a tunnel control and management protocol which allows the SGSN to provide GPRS network access for an MS. Signalling is used to create, modify and delete tunnels. In the transmission plane, GTP uses a tunnelling mechanism to provide a service for carrying user data packets. The choice of path is dependent on whether the user data to be tunnelled requires a reliable link or not.The GTP protocol is implemented only by SGSNs and GGSNs. No other systems need to be aware of GTP. GPRS MSs are connected to a SGSN without being aware of GTP. It is assumed that there will be a many-to-many relationship between SGSNs and GGSNs. An SGSN may provide service to many GGSNs. A single GGSN may associate with many SGSNs to deliver traffic to a large number of geographically diverse mobile stations.The GTP header is a fixed format 20 octet header used for all GTP messages.8
7
6
5
4
3
2
1
Octets
VersionPT
Spare ' 1 1 1 '
SNN
1
Message type2
Length3-4
Sequence Number
5-6
Flow label7-8
SNDCP N-PDULLC Number
9
Spare ' 1 1 1 1 1 1 1 1 '
10
Spare ' 1 1 1 1 1 1 1 1 '
11
Spare ' 1 1 1 1 1 1 1 1 '
12
TID
13-20
Outline of GTP header
VersionSet to 0 to indicate the first version of GTPReservedReserved bits for future use, set to 1.LFNFlag indicating whether the LLC frame number is included or not.Message TypeType of GTP message.LengthIndicates the length in octets of the GTP message (G-PDU).Sequence numberTransaction identity for signalling messages and an increasing sequence number for tunnelled T-PDUs.Flow labelIdentifies unambiguously a GTP flow.LLC frame numberUsed at the Inter SGSN Routing Update procedure to coordinate the data tranmsission on the link layer between the MS and the SGSN.xSpare bits x indicate the unused bits which are set to 0 by the sending side and are ignored by the receiving side.FNContinuation of LLC frame number.TIDTunnel identifier that points out MM and PDP contexts.The format of the TID is as follows:8
7
6
5
4
3
2
1
Octets
MCC digit 2MCC digit 11
MNC digit 1MCC digit 32
MSIN digit 1MNC digit 23
MSIN digit 3MSIN digit 24
MSIN digit 5MSIN digit 45
MSIN digit 7MSIN digit 66
MSIN digit 9MSIN digit 87
NSAPIMSIN digit 108
TID Format
MCC, MNC, MSIN digitsParts of the IMSI (defined in GMS 04.08).NSAPINetwork service access point identifier.Interested in more details about testing this protocol?
LLC
GSM 04.64 version 6.1.0http://www.etsi.frLLC defines the logical link control layer protocol to be used for packet data transfer between the mobile station (MS) and a serving GPRS support node (SGSN). LLC spans from the MS to the SGSN and is intended for use with both acknowledged and unacknowledged data transfer.
The frame formats defined for LLC are based on those defined for LAPD and RLP. However, there are important differences between LLC and other protocols, in particular with regard to frame delimitation methods and transparency mechanisms. These differences are necessary for independence from the radio path.
LLC supports two modes of operation:
Unacknowledged peer-to-peer operation.
Acknowledged peer-to-peer operation.
All LLC layer peer-to-peer exchanges are in frames of the following format:
8
7
6
5
4
3
2
1
Octets
Address Field
1
Control Field(variable length, max. 36 octets)
2-n
Information Field(variable length, max. N201 octets)
Frame Chack Sequence Field
(3 octets)
LLC frame format
AddressThe address field contains the SAPI and identifies the DLCI for which a downlink frame is intended and the DLCI transmitting an uplink frame. The length of the address field is 1 byte and it has the following format:8
7
6
5
4
3
2
1
PD
C/R
XX
SAPI
Address field structure
PDProtocol Discriminator bit indicates whether a frame is an LLC frame or belongs to a different protocol. LLC frames have the PD bit set to 0. If a frame with the PD bit set to 1 is received, then it is treated as an invalid frame.C/RIdentifies a frame as either a command or a response. The MS side sends commands with the C/R bit set to 0, and responses with the C/R bit set to 1. The SGSN side does the opposite; i.e., commands are sent with C/R set to 1 and responses are sent with C/R set to 0. The combinations for the SGSN side and MS side are as follows.Type
Direction
C/R value
Command
SGSN side to MS side
1
Command
MS side to SGSN side
0
Response
SGSN side to MS side
0
Response
MS side to SGSN side
1
XXReserved.SAPIService Access Point Identifier identifies a point at which LLC services are provided by an LLE to a layer-3 entity.ControlIdentifies the type of frame. Four types of control field formats are specified: Confirmed information transfer (I format)
Supervisory functions (S format)
Unconfirmed information transfer (UI format)
Control functions (U format)
InformationContains the various commands and responses.FCSFrame check sequence field consists of a 24 bit cyclic redundancy check (CRC) code. The CRC-24 is used to detect bit errors in the frame header and information fields.Interested in more details about testing this protocol?
NSGSM 08.16 version 6.1.0http://www.etsi.frThe Network Service performs the transport of NS SDUs between the SGSN (serving GPRS support node) and BSS (base station system). Services provided to the NS user include:
Network Service SDU transfer. The Network Service entity provides network service primitives allowing for transmission and reception of upper layer protocol data units between the BSS and SGSN. The NS SDUs are transferred in order by the Network Service, but under exceptional circumstances order may not be maintained.
Network congestion indication. Congestion recovery control actions may be performed by the Sub-Network Service (e.g. Frame Relay). Congestion reporting mechanisms available in the Sub-Network Service implementation shall be used by the Network Service to report congestion.
Status indication. Status indication shall be used to inform the NS user of the NS affecting events e.g. change in the available transmission capabilities.
NS PDUs are of the following format:
8
7
6
5
4
3
2
1
Octets
PDU type
1
Information Elements
2-n
NS PDU structure
PDU typePDU type may be:NS-ALIVENS-ALIVE-ACKNS-BLOCKNS-BLOCK-ACKNS-RESETNS-RESET-ACKNS-STATUSNS-UNBLOCKNS-UNBLOCK-ACKNS-UNITDATAInformation element valueThe following IEs may be present depending on the PDU type:CauseNS-VCINS PDUBVCINSEIInterested in more details about testing this protocol?
RLP
GSM 04.22 version 7.0.1http://www.etsi.frThe Radio Link Protocol (RLP) for data transmission over the GSM PLMN covers the Layer 2 functionality of the ISO OSI reference model. It has been tailored to the needs of digital radio transmission and provides the OSI data link service. RLP spans from the Mobile Station (MS) to the interworking function located at the nearest Mobile Switching Center (MSC) or beyond. Three versions of RLP exist.Version 0:Single-link basic versionVersion 1:Single-link extended versionVersion 2:Multi-link version.The RLP frames have a fixed length of either 240 or 576 bits consisting of a header, information field and an FCS field.The format of the 240-bit frame is:HeaderInformationFCS16 bit200 bit24 bit24 bit192 bit24 bitRLP 240-bit frame format
The header is 16 bits in versions 0 and 1 and in version 2 (U frames). It is 24 bits in version 2 (S and I+S frames).The format of the 576-bit frame is:The header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames.HeaderContains control information of one of the following 3 types: unnumbered protocol control information (U frames), supervisory information (S frames) and user information carrying supervisory information piggybacked (I+S frames).FCSThis is the Frame Check Sequence field.The RLP entity will be in the Asynchronous Balanced Mode (ABM), which is the data link operation mode; or Asynchronous Disconnected Mode (ADM), which is the data link non-operational mode.Header structure of versions 0 and 1
N(S) is a bit 4 low order bit and N(R) is a bit 11 low order bit.U
C/R
X
X
1
1
1
1
1
1
P/F
M1
M2
M3
M4
M5
X
S
C/R
S1
S2
0
1
1
1
1
1
N(R)
I+S
C/R
S1
S2
N(S)
P/F
N(R)
Bits 1-16
Header structure of version 2
S is a L2R status Bit, N(S) is a bit 1 low order bit, N(R) is a bit 14 low order bit and UP is a UP bit.U
C/R
X
X
1
1
1
1
1
1
P/F
M1
M2
M3
M4
M5
X
S
X
X
X
0
1
1
1
1
1
P/F
S1
S2
N(R)
X
UP
I+S
N(S)
P/F
S1
S2
N(R)
S
UP
Bits 1-24
C/RThe Command Response Bit indicates whether the frame is a command or a response frame. It can have the following values:1command0responseP/FThe Poll/Final bit marks a special instance of command/response exchangeXDon't careUnnumbered Frames (U)
The M1 M2 M3 M4 and M5 bits have the following values in the U frames according to the type of information carried:SABMUADISCDMNULLUIXIDTESTREMAP11100001100010110001111000000111010011110001SABM11100The Set Asynchronous balance mode is used either to initiate a link for numbered information transfer or to reset a link already established.UA00110The Unnumbered Acknowledge is used as a response to acknowledge an SABMM or DISC command.DISC00010The disconnect is used to disestablish a link previously established for information transfer.DM11000The disconnected mode encoding is used as a response message.NULL11110
UI 00000Unnumbered information signifies that the information field is to be interpreted as unnumbered information.XID11101Exchange Identification signifies that the information field is to be interpreted as exchange identification, and is used to negotiate and renegotiate parameters of RLP and layer 2 relay functions.TEST 00111The information field of this frame is test information.REMAP 0001A remap exchange takes place in ABM following a change of channel coding. If an answer is not received within a specific time, then the mobile end enters ADM.S and I+S frames
N(S)The send sequence number contains the number of the I frame.N(R)The Receive sequence number is used in ABM to designate the next information frame to be sent and to confirm that all frames up to and including this bit and been received correctly.SS represents the L2 status bit.The S1, S2 bits can have the following significance in the S and I+S frames:RR00REJ01RNR10SREJ11RRReceive Ready can be used either as a command or a response. It clears any previous busy condition in that area.REJThe Reject encoding is used to indicate that in numbered information transfer 1 or more out-of-sequence frames have been received.RNRThe Receive Not Ready indicates that the entity is not ready to receive numbered information frames.SREJSelective Reject is used to request retransmission of a single frame.UPThis is used in version 2 to indicate that a service level upgrading will increase the throughput.Interested in more details about testing this protocol?
SMSCB
ETSI TS 124 012. (You can download all the ETSI files from www.ETSI.org)
The Short Message Service Cell Broadcast (SMSCB) protocol is a service in which short messages may be broadcast from a PLMN to Mobile Stations (MS)s. SMSCB messages come from different sources (e.g. traffic reports, weather reports). The source and subject of the SMSCB message is identified by a message identifier in the SMSCB message header. A sequence number in the SMSCB message header enables the MS to determine when a new message from a given source is available. SMSCB messages are not acknowledged by the MS. Reception of SMSCB messages by the MS is only possible in idle mode. The geographical area over which each SMSCB message is transmitted is selected by the PLMN operator, by agreement with the provider of the information. A SMSCB message is an end-to-end message that is formatted by/for the SMSCB application, and which is intended for customer viewing. A CB message is any message sent on the basic or extended CBCH. It can be an occurrence of a SMSCB message, or a schedule message. The SMS Cell Broadcast service is designed to minimize the battery usage requirements on a MS. A MS can read the first part of a CB message and then decide whether or not to read the rest of the message. In addition, the network may broadcast Schedule Messages, providing information in advance about the CB messages that will be sent immediately afterwards. The MS may use this scheduling information to restrict reception to those messages the customer is interested in receiving. This SMSCB DRX feature is optional in the network and the MS.
The structure of the SMSCB protocol header is as follows:8
7
6
5
4
3
2
1
Octets
Spare0
Link ProtocolDiscriminator0 1
LastBlock
Sequence number
1
Link Protocol DiscriminatorThe link protocol discriminator.Last BlockWhen the LB bit is set to "0", the next block may contain SMSCB information.
Sequence NumberThe sequence number. Sequence numbers can be as follows:0123415Default
First blockSecond blockThird blockFourth blockFirst schedule blockNULL messageReserved
EnlargeMore DetailsInterested in more details about testing this protocol?
SNDCP
GSM 04.65 version 6.1.0http://www.etsi.frSub-Network Dependant Convergence Protocol (SNDCP) uses the services provided by the LLC layer and the Session Management (SM) sub-layer. The main functions of SNDCP are:
Multiplexing of several PDPs (packet data protocol).
Compression/decompression of user data.
Compression/decompression of protocol control information.
Segmentation of a network protocol data unit (N-PDU) into LLC protocol data units (LL-PDUs) and re-assembly of LL-PDUs into an N-PDU.
The SN-DATA PDU is used for acknowledged data transfer. Its format is as follows:
8
7
6
5
4
3
2
1
Octets
X
C
T
M
NSAPI
1
DCOMP
PCOMP
2
Data
3-n
SN-DATA PDU structure
The SN-UNITDATA PDU is used for unacknowledged data transfer. Its format is as follows:
8
7
6
5
4
3
2
1
Octets
X
C
T
M
NSAPI
1
DCOMP
PCOMP
2
Segment offset
N-PDU number
3
E
N-PDU number (continued)
4
N-PDU number (extended)
5
Data
6-n
SN-UNITDATA PDU structure
NSAPINetwork service access point identifier. Values may be:0
Escape mechanisms for future extensions
1
Point-to-mutlipoint multicast (PTM-M) information
2-4
Reserved for future use
5-15
Dynamicallly allocated NSAPI value
MMore bit. Values may be:0 Last segment of N-PDU1 Not the last segment of N-PDU, more segments to follow.TSN-PDU type specifies whether the PDU is SN-DATA (0) or SN-UNITDATA (1).CCompression indicator. A value of 0 indicates that compression fields, DCOMP and PCOMP, are not included. A value of 1 indicates that these fields are included.XSpare bit is set to 0.DCOMPData compression coding, included if C-bit set. Values are as follows:0
No compression.
1-14
Points to the data compression identifier negotiated dynamically.
15
Reserved for future extensions.
PCOMPProtocol control information compression coding, included if C-bit set. Values are as follows:0
No compression.
1-14
Points to the protocol control information compression identifier negotiated dynamically.
15
Reserved for future extensions.
Segment offsetSegment offset from the beginning of the N-PDU in units of 128 octets.N-PDU number0-2047 when the extension bit is set to 0;2048-524287 if the extension bit is set to 1.EExtension bit for N-PDU number.0 Next octet is used for data.1 Next octet is used for N-PDU number extensions.Interested in more details about testing this protocol?
TOM
ftp://ftp.3gpp.org/Specs 3GPP TS 04.64 version 8.6.0 Release 1999 Annex B. (ETSI TS 101 351 V8.6.0 (2000-12)).Tunnelling of Messages (TOM) is a generic protocol layer used for the exchange of TOM Protocol Envelopes between the MS and the SGSN. TOM uses two LLC SAPs, one for high-priority messages and another for low-priority messages. The TOM Protocol Envelope is composed of a header (containing one or more octets) and a message capsule. The TOM Protocol Header contains information about the specific application using the TOM protocol layer and any other protocol discriminator-specific information. The Message Capsule is the actual payload of information in the TOM Protocol Envelope. One of the uses of the TOM protocol layer is to tunnel signalling messages between an MS and a non-GSM MSC/VLR when GPRS network elements are used in non-GSM networks.The Structure of the TOM protocol header is as follows:8
7
6
5
4
3
2
1
Remaining Length of TOM Protocol Header
TOM Protocol Discriminator
Remaining Octets of TOM Protocol Header (Variable length, max. 14 octets)
Message Capsule (Variable length, max. 220 octets)
TOM Protocol Discriminator0 0 0 00 0 0 11 1 1 1Not specifiedTIA/EIA-136 [22]Reserved for extensionAll other values are reservedIf any other value than 0 0 0 1 is received, then the TOM Protocol Envelope is discarded with no further action
Remaining Length of TOM Protocol HeaderRemaining Length of TOM Protocol Header indicates the number of octets remaining in the TOM-protocol-header part of the TOM Protocol Envelope, and is coded as follows:
bits 8 7 6 50 0 0 0 00 0 0 1 11 1 1 0 141 1 1 1octets remaining in TOM protocol headeroctet remaining in TOM protocol headeroctets remaining in TOM protocol headerReserved for extensionIf the value 1 1 1 1 is received, then the TOM Protocol Envelope is discarded with no further action.Remaining Octets of TOM Protocol HeaderThis field contains the octets following the first octet in the TOM-protocol-header. If present, the interpretation of the information contained in this field is TOM Protocol Discriminator-specific.
Message CapsuleThis field contains TOM Protocol Discriminator-specific payload in the TOM Protocol Envelope (field Length depends on the general length of the frame).Interested in more details about testing this protocol?
TRAU
GSM 08.60. (You can download all the ETSI files from www.ETSI.org)The Transcoding Rate and Adaptation Unit. (TRAU) protocol is an entity that performs a transcoding function for speech channels and RA (Rate Adaptation) for data channels. It works as follows: when the transcoders/rate adaptors are positioned remote to the BTS, the information between the Channel Codec Unit (CCU) and the remote Transcoder/Rate Adaptor Unit (TRAU) is transferred in frames with a fixed length of 320 bits (20 ms). These frames are denoted "TRAU frames". Within these frames, both the speech/data and the TRAU associated control signals are transferred.The Abis interface should be the same if the transcoder is positioned 1) at the MSC site of the BSS or if it is positioned 2) at the BSC site of the BSS. In case 1), the BSC should be considered as transparent for 16 kbit/s channels.In case of 4,8 and 9,6 kbit/s channel coding when data is adapted to the 320 bit frames, a conversion function is required in addition to the conversion/rate adaptation specified in GSM 08.20. This function constitutes the RAA. In case of 14,5 kbit/s channel coding, no RAA rate adaptation is required because V.110 framing is not used.The TRAU is considered a part of the BSC, and the signaling between the BSC and the TRAU (e.g. detection of call release, handover and transfer of O&M information) may be performed by using BSC internal signals. The signaling between the CCU and the TRAU, using TRAU frames as specified here, is mandatory when the Abis interface is applied.The functions inside the TRAU are: "Remote Transcoder and Rate Adaptor Control Function" (RTRACF);
"Remote Speech Handler Function" (RSHF);
The RAA function in case of 4,8 and 9,6 kbit/s channel coding;
The RAA' function in case of 14,5 kbit/s channel coding;
The RA2 function;
The transcoder function.
Optionally the TFO functions (see GSM 08.62).
The protocol header structure of the TRAU protocol is as follows:
8
7
6
5
4
3
2
1
octets
Synchronize
1
2
Syn
Frame Type
3
SynchronizeThe frame synchronization is obtained by means of the first two octets in each frame, with all bits coded binary "0", and the first bit in octet no. 2, 4, 6, 8, ... 38 coded binary "1".
Frame TypeThe Frame Type:25681416202226272831
Full RateO&MAdaptive Multi-RateDataIdle SpeechIdle SpeechData 14.5DataEnhanced Full RateO&MFull RateExtended Data