Click here for more information on GPRS decoding and analysis.

GPRS (general packet radio service) is used as a data services upgrade to any GSM network. It allows GSM networks to be truly compatible with the Internet. GPRS uses a packet-mode technique to transfer bursty traffic in an efficient manner. It allows transmission bit rates from 9.6 Kbps to more than 150 Kbps per user.

The two key benefits of GPRS are a better use of radio and network resources and completely transparent IP support. GPRS optimizes the use of network and radio resources. It uses radio resources only when there is data to be sent or received. As a true packet technology it allows end user applications to only occupy the network when a payload is being transferred, and so is well adapted to the very bursty nature of data applications. Another important feature of GPRS is that it provides immediate connectivity and high throughput.

Applications based on standard data protocols such as IP and X.25 are supported. In GPRS four different quality of service levels are supported. To support data applications GPRS utilizes several new network nodes in addition to the network nodes in the GSM PLMN. These nodes are responsible for traffic routing and other interworking functions with external packet-switched data networks, subscriber location, cell selection, roaming and many other functions that any cellular network needs for operation.

GPRS in relation to the OSI model

Protocols described here include:

• NS
• BSSGP
• BSSAP+
• BCC
• GCC
• GMM
• GSM
• GTP
• LLC
• RLP
• SNDCP

See SS7 for a description of SS7 protocols.
See Cellular for a description of GSM protocols.

NS

GSM 08.16 version 6.1.0 http://www.etsi.fr/

The 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:

PDU type
PDU type may be:
NS-ALIVE
NS-ALIVE-ACK
NS-BLOCK
NS-BLOCK-ACK
NS-RESET
NS-RESET-ACK
NS-STATUS
NS-UNBLOCK
NS-UNBLOCK-ACK
NS-UNITDATA

Information Elements
The particular IEs present in a PDU depend on the PDU type. The structure of IEs is as shown here:

Information element ID
The first octet of an information element having the TLV format contains the IEI of the information element. If this octet does not correspond to an IEI known in the PDU, the receiver assumes that the next octet is the first octet of the length indicator field. This rule allows the receiver to skip unknown information elements and to analyze any following information elements.

Length indicator
Information elements may be variable in length. The length indicator is one or two octets long, the second octet may be absent. This field consists of the field extension bit, 0/1 ext, and the length of the value field which follows, expressed in octets. The field extension bit enables extension of the length indicator to two octets. Bit 8 of the first octet is reserved for the field extension bit. If the field extension bit is set to 0 (zero), then the second octet of the length indicator is present. If the field extension bit is set to 1 (one), then the first octet is the final octet of the length indicator.

Information element value
The following IEs may be present depending on the PDU type:
Cause
NS-VCI
NS PDU
BVCI
NSEI

BSSGP

GSM 08.18 version 6.1.0 http://www.etsi.fr/

The 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:

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		SCCP
MTP L3		MTP L3
MTP L2		MTP L2
L1		L1
SGSN	Gs	MSC/VLR
BSSAP+ 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.

8	7	6	5	4	3	2	1	Octet
Message type								1
Information elements								2-n
BSSAP+ beader structure

The message type uniquely identifies the message being sent. The following BSSAP+ message types exist:

Value	Message type
00000000	Unassigned: treated as an unknown Message type.
00000001	BSSAP+-PAGING-REQUEST.
00000010	BSSAP+-PAGING-REJECT
00000011
to
00001000	Unassigned: treated as an unknown Message type.
00001001	00001001BSSAP+-LOCATION-UPDATE-REQUEST.
00001010	BSSAP+-LOCATION-UPDATE-ACCEPT.
00001011	BSSAP+-LOCATION-UPDATE-REJECT.
00001100	BSSAP+-TMSI-REALLOCATION-COMPLETE.
00001101	BSSAP+-ALERT-REQUEST.
00001110	BSSAP+-ALERT-ACK.
00001111	BSSAP+-ALERT-REJECT.
00010000	BSSAP+-MS-ACTIVITY-INDICATION.
00010001	BSSAP+-GPRS-DETACH-INDICATION.
00010010	BSSAP+-GPRS-DETACH-ACK.
00010011	BSSAP+-IMSI-DETACH-INDICATION.
00010100	BSSAP+-IMSI-DETACH-ACK.
00010101	BSSAP+-RESET-INDICATION.
00010110	BSSAP+-RESET-ACK.
00010111	BSSAP+-MS-INFORMATION-REQUEST.
00011000	BSSAP+-MS-INFORMATION-RESPONSE.
00011001	Unassigned: treated as an unknown Message type.
00011010	BSSAP+-MM-INFORMATION-REQUEST.
00011101	BSSAP+-MOBILE-STATUS.
00011110	Unassigned: treated as an unknown Message type.
00011111	BSSAP+-MS-UNREACHABLE.

Each message type has specific information elements

00000001	IMSI.
00000010	VLR number.
00000011	TMSI.
00000100	Location area identifier.
00000101	Channel Needed.
00000110	eMLPP Priority.
00000111	Unassigned: treated as an unknown IEI.
00001000	Gs cause.
00001001	SGSN number.
00001010	GPRS location update type.
00001011	Unassigned: treated as an unknown IEI.
00001100	Unassigned: treated as an unknown IEI.
00001101	Mobile station classmark 1.
00001110	Mobile identity.
00001111	Reject cause.
00010000	IMSI detach from GPRS service type.
00010001	IMSI detach from non-GPRS service type.
00010010	Information requested.
00010011	PTMSI.
00010100	IMEI.
00010101	IMEISV.
00010110	Unassigned: treated as an unknown IEI.
00010111	MM information.
00011000	Cell Global Identity.
00011001	Location information age.
00011010	Mobile station state.
00011011	Erroneous message.
00011100
to
11111111	Unassigned: treated as an unknown IEI.

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:

8	7	6	5	4	3	2	1	Octet
Transaction identifier				Protocol discriminator				1
Message type								2
Information elements								3-n
BCC beader structure

Protocol discriminator
The protocol discriminator specifies the message being transferred

Transaction identifier
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:

8	7	6	5
TI flag	TI value
Transaction identifier

TI flag
Identifies 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 value
The 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 type
The message type defines the function of each BCC message. The message type defines the function of each BCC message. The following message types exist:

0x110001	IMMEDIATE SETUP
0x110010	SETUP
0x110011	CONNECT
0x110100	TERMINATION
0x110101	TERMINATION REQUEST
0x110110	TERMINATION REJECT
0x111000	STATUS
0x111001	GET STATUS
0x111010	SET PARAMETER

Information elements
Each 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.

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:

8	7	6	5	4	3	2	1	Octet
Transaction identifier				Protocol discriminator				1
Message type								2
Information elements								3-n
GCC beader structure

Protocol discriminator
The protocol discriminator specifies the message being transferred

Transaction identifier
Distinguishes multiple parallel activities (transactions) within one mobile station. The format of the transaction identifier is as follows:

8	7	6	5
TI flag	TI value
Transaction identifier

TI flag
Identifies 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 value
The 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 type
The message type defines the function of each GCC message. The following message types exist:

0x110001	IMMEDIATE SETUP
0x110010	SETUP
0x110011	CONNECT
0x1100100	TERMINATION
0x110101	TERMINATION REQUEST
0x110110	TERMINATION REJECT
0x111000	STATUS
0x111001	GET STATUS
0x111010	SET PARAMETER

Information elements
Each 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.

GMM

GSM 04.08 http://www.etsi.org

GPRS 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:

8	7	6	5	4	3	2	1	Octet
Protocol discriminator				Skip indicator				1
Message type								2
Information elements								3-n
GMM beader structure

Protocol discriminator
1000 identifies the GMM protocol.

Skip indicator
The value of this field is 0000.

Message type
Uniquely 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 1	Attach request
0 0 0 0 0 0 1 0	Attach accept
0 0 0 0 0 0 1 1	Attach complete
0 0 0 0 0 1 0 0	Attach reject
0 0 0 0 0 1 0 1	Detach request
0 0 0 0 0 1 1 0	Detach accept
0 0 0 0 1 0 0 0	Routing area update request
0 0 0 0 1 0 0 1	Routing area update accept
0 0 0 0 1 0 1 0	Routing area update complete
0 0 0 0 1 0 1 1	Routing area update reject
0 0 0 1 0 0 0 0	P-TMSI reallocation command
0 0 0 1 0 0 0 1	P-TMSI reallocation complete
0 0 0 1 0 0 1 0	Authentication and ciphering req
0 0 0 1 0 0 1 1	Authentication and ciphering resp
0 0 0 1 0 1 0 0	Authentication and ciphering rej
0 0 0 1 0 1 0 1	Identity request
0 0 0 1 0 1 1 0	Identity response
0 0 1 0 0 0 0 0	GMM status
0 0 1 0 0 0 0 1	GMM information

Information elements
Various information elements.

GSM

GSM 04.08 http://www.etsi.org

The 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:

8	7	6	5	4	3	2	1	Octet
Protocol discriminator				Skip indicator				1
Message type								2
Information elements								3-n
GSM beader structure

Protocol discriminator
1010 identifies the GSM protocol.

Skip indicator
The value of this field is 0000.

Message type
Uniquely 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 x	Session management messages
0 1 0 0 0 0 0 1	Activate PDP context request
0 1 0 0 0 0 1 0	Activate PDP context accept
0 1 0 0 0 0 1 1	Activate PDP context reject
0 1 0 0 0 1 0 0	Request PDP context activation
0 1 0 0 0 1 0 1	Request PDP context activation rej.
0 1 0 0 0 1 1 0	Deactivate PDP context request
0 1 0 0 0 1 1 1	Deactivate PDP context accept
0 1 0 0 1 0 0 0	Modify PDP context request
0 1 0 0 1 0 0 1	Modify PDP context accept
0 1 0 1 0 0 0 0	Activate AA PDP context request
0 1 0 1 0 0 0 1	Activate AA PDP context accept
0 1 0 1 0 0 1 0	Activate AA PDP context reject
0 1 0 1 0 0 1 1	Deactivate AA PDP context request
0 1 0 1 0 1 0 0	Deactivate AA PDP context accept
0 1 0 1 0 1 0 1	SM Status

Information elements
Various information elements.

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 16 octet header used for all GTP messages.

8	7	6	5	4	3	2	1	Octet
Version			Reserved				LFN	1
Message type								2
Length								3
Flow label								4
LLC frame number								5
X	X	X	X	X	X	X	FN	6
Reserved
TID
GTP header structure

Version
Set to 0 to indicate the first version of GTP

Reserved
Reserved bits for future use, set to 1.

LFN
Flag indicating whether the LLC frame number is included or not.

Message Type
Type of GTP message.

Length
Indicates the length in octets of the GTP message (G-PDU).

Sequence number
Transaction identity for signalling messages and an increasing sequence number for tunnelled T-PDUs.

Flow label
Identifies unambiguously a GTP flow.

LLC frame number
Used at the Inter SGSN Routing Update procedure to coordinate the data tranmsission on the link layer between the MS and the SGSN.

x
Spare bits x indicate the unused bits which are set to 0 by the sending side and are ignored by the receiving side.

FN
Continuation of LLC frame number.

TID
Tunnel identifier that points out MM and PDP contexts.The format of the TID is as follows:

MCC, MNC, MSIN digits
Parts of the IMSI (defined in GMS 04.08).

NSAPI
Network service access point identifier.

LLC

GSM 04.64 version 6.1.0 http://www.etsi.fr/

LLC 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:

Address
The 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:

C/R
Identifies 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

XX
Reserved.

SAPI
Service Access Point Identifier identifies a point at which LLC services are provided by an LLE to a layer-3 entity.

Control
Identifies 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)

Information
Contains the various commands and responses.

FCS
Frame 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.

RLP

GSM 04.22 version 7.0.1 http://www.etsi.fr

The 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 version
Version 1:	Single-link extended version
Version 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:

Header	Information	FCS
16 bit	200 bit	24 bit
24 bit	192 bit	24 bit
RLP 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:

Header	Information	FCS
16 bit	536 bit	24 bit
24 bit	528 bit	24 bit
RLP 576-bit frame format

The header is 16 bits in version 1 and version 2 (U frames), and 24 bits in version 2 (S and I+S) frames.

Header
Contains 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).

FCS
This 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/R
The Command Response Bit indicates whether the frame is a command or a response frame. It can have the following values:

1	command
0	response

P/F
The Poll/Final bit marks a special instance of command/response exchange

X
Don't care

Unnumbered 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:

SABM	11100
UA	00110
DISC	00010
DM	11000
NULL	11110
UI	00000
XID	11101
TEST	00111
REMAP	10001

SABM11100
The Set Asynchronous balance mode is used either to initiate a link for numbered information transfer or to reset a link already established.

UA00110
The Unnumbered Acknowledge is used as a response to acknowledge an SABMM or DISC command.

DISC00010
The disconnect is used to disestablish a link previously established for information transfer.

DM11000
The disconnected mode encoding is used as a response message.

NULL11110

UI 00000
Unnumbered information signifies that the information field is to be interpreted as unnumbered information.

XID11101
Exchange 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 00111
The information field of this frame is test information.

REMAP 0001
A 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.

S
S represents the L2 status bit.

The S1, S2 bits can have the following significance in the S and I+S frames:

RR	00
REJ	01
RNR	10
SREJ	11

RR
Receive Ready can be used either as a command or a response. It clears any previous busy condition in that area.

REJ
The Reject encoding is used to indicate that in numbered information transfer 1 or more out-of-sequence frames have been received.

RNR
The Receive Not Ready indicates that the entity is not ready to receive numbered information frames.

SREJ
Selective Reject is used to request retransmission of a single frame.

UP
This is used in version 2 to indicate that a service level upgrading will increase the throughput.

SNDCP

GSM 04.65 version 6.1.0 http://www.etsi.fr/

Sub-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:

The SN-UNITDATA PDU is used for unacknowledged data transfer. Its format is as follows:

NSAPI
Network 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

M
More bit. Values may be:
0 Last segment of N-PDU
1 Not the last segment of N-PDU, more segments to follow.

T
SN-PDU type specifies whether the PDU is SN-DATA (0) or SN-UNITDATA (1).

C
Compression 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.

X
Spare bit is set to 0.

DCOMP
Data 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.

PCOMP
Protocol 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 offset
Segment offset from the beginning of the N-PDU in units of 128 octets.

N-PDU number
0-2047 when the extension bit is set to 0;
2048-524287 if the extension bit is set to 1.

E
Extension bit for N-PDU number.
0 Next octet is used for data.
1 Next octet is used for N-PDU number extensions.