A Guide to General Packet Radio Service Written by: PsychoSpy and The Clone Date: Sunday September 3, 2000 GPRS (short for General Packet Radio Service) is a data service upgrade for GSM networks. This allows GSM Networks to be completely compatible with the Internet. GPRS uses a packet-mode technique to transfer traffic in bursts. These bursts allow higher efficiency, and therefore higher speeds. The packet bursting technique is also used in DSL modems, and other methods of high-speed internet access. Due to this technique GPRS allows bit rates of 9.6 Kbps to anywhere more than 150 Kbps per user. There are a couple major benefits of using GPRS. These include better use of radio/network resources and a completely transparent support of IP. Radio resources are only used when data is being sent and/or received. GPRS also provides an immediate connection (again like DSL or Cable) and a high throughput. It also allows end user applications to only occupy the network when data is being transferred, and is an almost perfect design for the short data burst which data applications seem to have these days. Applications based on standard protocols (data) like IP and X.25 are supported. Four different quality of service levels are supported by GPRS. To supports data apps, GPRS uses several new network nodes in addition to the GSM PLMN network nodes. They are responsible for traffic routing, and various other internetworking functions with other, external, packet-switched data networks (can anyone say Datapac?), subscriber location, cell selection, roaming and all the other functions which all cellular networks need to operate. Now that we have the general info on what GPRS is, I will talk about a few other protocols which are linked with GPRS. NS ~~ NS (Network Service) transfers the NS SDUs between the SGSN (serving GPRS support node) and BSS (Base station system). There are several services which are provided to the NS user. They include: Network Congestion Indication - The Sub-Network Service (i.e. Frame Relay) perform congestion recovery control actions. The network service uses various congestion reporting mechanisms which are in the Sub-Network Service implementation. Status Indication - Is used to tell the NS user of NS affecting events. An example is a change in the capabilities of transmission. Network Service SDU Transfer - Allows network service primitives. This lets transmission and reception of upper layer protocol data units between the BSS and SGSN. NS SDU's are transferred in order of the Network Service, but under certain circumstances order might not be maintained. The NS PDU format is: 1 byte |----------------------------| | PDU Type | |----------------------------| | Other Information Elements | |----------------------------| The PDU Type can be any of the following: NS-ALIVE NS-ALIVE-ACK NS-BLOCK NS-BLOCK-ACK NS-RESET NS-RESET-ACK NS-STATUS NS-UNBLOCK NS-UNBLOCK-ACK NS-UNITDATA Next we're onto the Information Elements (IEs) of the PDU. The IEs which are present depend on what the PDU type is. The structure of an IE is as follows: 1 byte |------------------------------| | Information Element ID (IEI) | |------------------------------| | Length Indicator | |------------------------------| | Information Element Value | |------------------------------| The first 8th (or octet) of an information element, having the TLV format, contains the IEI of the IE. If the IEI is not known to the PDU, the receiver assumes that the next octet is the first octet of the length indicator. This rule is used to allow the receiver to skip unknown IEs to analyze any other following elements, Next up is the length indicator. This varies in length, and can be either one or two octets long. However, the second octet may not be present. This field has the field extension bit, 0/1 ext, and closely following it is the length of field in octets. The 8th bit of the first octet is reserved for the field extension bit. If the field extension bit is set to zero, the second octet of the length indicator is present. If it is set to one, then the first octet is the final octet of the length indicator. Lastly, the IE Value. The following IEs can be present, but are, once again, dependent on the PDU type: Cause NS-VCI NS PDU BVCI NSEI BSSGP ~~~~~ The primary functions of the BSSGP are: - Provision by an SGSN to a BSS of radio related information used by the RLC/MAC function (in downlink) - Provision by a BSS to an SGSN of radio related information from the RLC/MAC function (in uplink) - Provision of functionality to allow two physically distinct node, an SGSN and a BSS, to operate node management control functions. The BSSGP PDUs format is: 1 byte |----------------------------| | PDU Type | |----------------------------| | Other Information Elements | |----------------------------| LLC ~~~ The LLC (Logical Link Controller) defines the logical link control later protocol to be used for (packet) data transfer between the MS (Mobile Station) and a serving GPRS support node (SGSN). LLC goes from the MS to the SGSN and is intended to be used for both acknowledged and unacknowledged data transfers. LLC's defined frame formats are based on the ones defined for LAPD and RLP. Although, there are major differences between other protocols and LLC, in particular to frame delimitation methods and transparency mechanisms. These differences are necessary for independence from the radio path. Two methods of operation are supported by LLC. These are: - Unacknowledged peer-to-peer operation - Acknowledged peer-to-peer operation All LLC layer peer-to-peer exchanges are in frames of the following format: 1 byte |------------------------------| | Address | |------------------------------| | Control | |------------------------------| | Information | |------------------------------| | FCS | |------------------------------| The address field contains the SAPI and identifies the DLCI which a downlink frame is intended and the DLCI transmitting an uplink frame. The length of the address field is 1 byte, and has the following format: _______________________________ Bit | 8 7 56 4-1 | |------------------------------| | PD C/R XX SAPI | |------------------------------| - The protocol discriminator (PR) shows whether a frames is LLC or belongs to a different protocol. LLC frames have the PD bit set to zero. The frame is treated as invalid if its PD bit is set to 1. - The C/R identifies a frame as either a command or response. The MS side sends commands with the C/R bit set to zero, and responses with it at 1. The SGSN does the opposite (commands are sent with C/R set to 1, and responses are set to 0). - The XX bit is a reserved bit. - Service Access Point Identifier (SAPI) identifies a point where KKC services are provided by an LLE to a layer-3 entity. After the address, comes control. This identifies the type of frame. There are four types of control field formats. They are: - Confirmed information transfer (I format) - Supervisory functions (S format) - Unconfirmed information transfer (UI format) - Control functions (U format) Next is the information bit. This contains various commands and responses. The FCS (Frame Check Sequence) field consists of a 24-bit cyclic redundancy check (CRC) code. CRC-25 is used to detect bit errors in the frame header and information fields. SNDCP ~~~~~ SNDCP (Sub-Network Dependent Convergence Protocol) users the services provided by the LLC Layer, and SM (Session Management) sub-lay. The four 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 a N-PDU Data transfer is acknowledged by the SN-DATA PDU. The format of the SN-DATA PDU is: 8 7 5 6 4-1 |-------------------------------------------| | X | C | T | M | NSAPI | |-------------------------------------------| | DCOMP | PCOMP | |-------------------------------------------| | | | Data | |-------------------------------------------| The SN-UNITDATA PDU (used to Acknowledge data transfer) has a format as follows: 8 7 5 6 4-1 |-------------------------------------------| | X | C | T | M | NSAPI | |-------------------------------------------| | DCOMP | PCOMP | |-------------------------------------------| | Segment offest | N-PDU Number | |-------------------------------------------| | E | N-PDU Number (Cont'd) | |-------------------------------------------| | | | Data | |-------------------------------------------| NSAPI (Network Service Access Point Identifier. The values of this field may be any one of the following: 0 | Escape Mechanism for Future Extensions ----|-------------------------------------------------- 1 | Point-to-multipoint multicast (PTM-M) information ----|-------------------------------------------------- 2-4 | Reserved for future user ----|-------------------------------------------------- 5-15| Dynamically allocated NSAPI value ----|-------------------------------------------------- M is the more bit. It's values may be: ----|------------------------------------------------------- 0 | Last Segment of N-PDU ----|------------------------------------------------------- 1 | Not the last segment of N-PDU, more segments to follow ----|------------------------------------------------------- The T bit, SN-PDU type specifies whether the PDU is SN-DATA (0) or SN-UNITDATA (1). C is the compression indicator. If set to 0, the compression fields DCOMP and PCOMP are not included. While 1 tells that these fields are included. X is the spare bit. This is always set to 0. DCOMP (Data Compression Coding) is included if the C-bit is set. DCOMP values are: ----|-------------------------------------------- 0 | No Compression ----|-------------------------------------------- 1-14| Points to the data compression identifies | negotiated dynamically ----|-------------------------------------------- 15 |Reserved for future extensions ----|-------------------------------------------- PCOMP (Protocol Control Information Compression Coding) is included if the C-bit is set. The PCOMP Values are: ----|-------------------------------------------- 0 | No Compression ----|-------------------------------------------- 1-14| Points to the protocol control information | compression identifier negotiated dynamically ----|-------------------------------------------- 15 |Reserved for future extensions ----|-------------------------------------------- N-PDU Number 0-2047 when the extension bit is set to 0. 2048-524287 if the extension bit is set to 1. RLP ~~~ The Radio Link Protocol (RLP) is used to transmit data over the GSM PLMN. RLP covers the functionality of Layer 2 of the ISO OSI Reference Model. It has been tailored to the needs of digital radio transmissions and provides an OSI data link service. It also spans from the MS (Mobile Station) to the interworking function, which is located at the nearest MSC (Mobile Switching Center) or even further. There are currently three versions of RLP: Version 0 is a Single-link basic version, Version 1 is a Single-Link extended version, And Version 2 is a Multi-link version. RLP frames are fixed in length. The frame can either be 240 or 576 bits. The frame consists 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 | |---------|-----------------|--------| The header is 16 bits in versions 0,1, and in the U frame of version 2. It is 24 bits in the S and I+S frames of version 2. The format of the 576-bit frame is: _____________________________________ | Header | Information | FCS | |---------|-----------------|--------| | 16 bit | 536 bit | 24 bit | |---------|-----------------|--------| | 24 bit | 528 bit | 24 bit | |---------|-----------------|--------| The header is 16 bits in version 1 and in the U frames of version 2. It is 24 bits in the S and I+S frames of version 2. The header contains control information. This control information can be any one of three types: 1) Un-numbered protocol control information (U frames) 2) Supervisory Information (S frames) 3) User Information Carrying Supervisory information piggypacked (I+S Frames) The FCS (Frame Check Sequence) field in the RLP is just like the FCS which is used in LLC which was discussed earlier. RLP can be either in Asynchronous Balanced Mode (ABM) or Asynchronous Disconnected Mode (ADM). ABM is the data link operation mode, while ADM is the data link non-operational mode. Now we're going to get into some, maybe, confusing diagrams. The following diagram shows the Structure of Versions 0 and 1. N(S) is a bit 4 low order bit, and N(R) bit 11 low order bit. Bits 1-16 are as follows: ___________________________________________________________________________ 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 | P/F | N (R) | | | | | | | | | | | | | |-----|----|----|---|---|---|---|---|---|-----|----------------------------| I+S | C/R | S1 | S2 | 0 1 N 1 1 1 | P/F | N (R) | | | | | (S) | | | |-----|----|----|-----------------------|-----|----------------------------| 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. Bits 1-24 ___________________________________________________________________________ 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 | C/R | S1 | S2 | N(R) X UP | |-----|---|---|---|---|---|---|-- |-|-|-----|-----|----|----|----------------|-| I+S | N(S) | | P/F | C/R | S1 | S2 | N(R) S UP | |-----------------------------------|-|-----|-----|----|----|----------------| The C/R (Command Response) bit shows whether the frame is a command or a response frame. It can have only one of two values: 1 Command 0 Response The P/F (Poll/Final) bit shows a special instance of the command/response exchange. The X bits don't really matter. In the Unnumbered Frames (U) the M1 M2 M3 M4 and M5 bits can have any of the following values in the U frames depending on the type of information carried. SABM 11100 UA 00110 DISC 00010 DM 11000 NULL 11110 UI 00000 XID 11101 TEST 00111 REMAP 10001 SABM == Set Asynchronous Balance Mode SABM is used to initiate a link for a numbered information transfer or to reset a link already established. UA == Unnumbered Acknowledge UA is issued as a response to acknowledge a SABMM or DISK command. DISC == Disconnect DISC is used to disestablish a previously established link information transfer link. (duh!) DM == Disconnect Mode DM Encoding is used as a response message NULL == NULL UI == Unnumbered Information UI says that the information f field is to be interpreted as unnumbered information. ID == Exchange Identification ID signifies that the information field should be interpreted as exchange identification, and is used to negotiate and/or renegotiate parameters of RLP and Layer 2 relay functions. TEST == TEST This shows that the information field of the frame is test information. REMAP == REMAP This signifies that a remap exchange takes place in ABM following a change of channel coding. If an answer is not received within a specified time then the module end enters ADM. In the S and I+S Frames the following are present: N(S) == Send Sequence Number N(S) contains the number of the I frame. N(R) == Receive Sequence Number N(R) is used in ABM to designate the next information frame to be sent and to confirm that all frames upto and including this bit have been correctly received. S == L2 Status Bit S1 and 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 RR can be used as a command OR a response. It clears any previous busy condition in that area. REJ == Reject Encoding REJ is used to show that in numbered information transfer, 1 or more out of sequence frames have been received. RNR == Receive Not Ready RNR shows that the entity isn't ready to receive numbered information frames. SREJ == Selective Reject SREJ is used to request a retransmission of a single frame. UP is used in version 2, to indicate that a service level upgrade will increase the throughput. [- {GTP} -] The GPRS Tunnelling Protocol (GTP) is the protocol between GPR Support Nodes (GSNs) which allow multiprotocol packets to be tunnelled through it in the GPRS backbone network. These packets are the collection of data that carry one of two substantial pieces of information; either the user's IP or X.25 packets. Below GTP, the standard protocols (TCP or UDP) are employed to transport the GTP packets within the GPRS backbone network. X.25 expects a reliable data link to be used, thus why TCP is occupied for data transfer. UDP, is simply used for special access to IP-based packet data networks, which don't necessarily expect reliability in the network layer. IP is employed in the network layer to route specific packets through the GPRS backbone. Please note; Ethernet, ISDN, or ATM-based protocols may be used below IP for GTP packeting. Lets summarize shall we? In the GPRS backbone we have an IP/X.25-over-GTP-over-UDP/TCP-over-IP transport architecture. Subnetwork Dependent Convergence Protocol -- The Subnetwork Dependent Convergence Protocol (SNDCP) within the signalling plane, specifies a tunnel control and managment protocol which allows the SGSN is used to transfer data packets between the Serving GPRS Support Node (SGSN) and the Mobile Station (MS). Its functionality includes: * Compression and decompression of user data and redundant header information. * Multiplexing of several connections of the network layer onto one virtual connection in the underlying Logical Link Control (LLC) layer. (Definition; Logical Link Control (LLC): a data link layer protocol for GPRS. This layer assures the reliable transfer of user data across a wireless network.) - In the signaling plane, GTP specifies a tunnel control and management protocol which allows the SGSN to provide GPRS network access for a MS. - Signaling is used to create, modify and delete tunnels. In the transmission plane, GTP uses a tunneling mechanism to provide a service for carrying user data packets. The choice of path is dependent on whether the user data to be tunneled 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's presence. GPRS MSs are connected to an SGSN without being aware of GTP. It is assumed that there will be a "many-to-many" relationship between SGSNs and GGSNs. - A 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. GTP header structure The GTP header is a fixed format 16 octet header used for all GTP messages. Below is a simple diagram of the GTP header structure, hopefully this will give you a general idea of the relevancy of GTP headers. 8 7 6 5 - 2 1 Version Reserved LFN Message type Length Sequence Number Flow Label LLC Frame Number x x x x x x x FN Reserved TID GTP header structure GTP Header Structure; Definitions --------------------------------- - 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 signaling messages and an increasing sequence number for tunneled T-PDUs. - Flow label: Identifies unambiguously a GTP flow. - LLC frame number: Used at the Inter SGSN Routing Update procedure to coordinate the data transmission 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 Mobility Management and PDP contexts. The format of the TID is as follows: 5 - 8 4 - 1 MCC digit 2 MCC digit 1 MNC digit 1 MCC digit 3 MSIN digit 1 MNC digit 2 MSIN digit 3 MSIN digit 2 MSIN digit 5 MSIN digit 4 MSIN digit 7 MSIN digit 6 MSIN digit 9 MSIN digit 8 NSAPI MSIN digit 10 TID Format: MCC, MNC, MSIN digits Parts of the IMSI (defined in GMS 04.08). NSAPI: Network service access point identifier. [- {GMM} -] GMM What is GMM? GMM, or GPRS Mobility Management is a very complex versatile protocol that operates within the signaling plane of GPRS handing such things as: roaming, authentication, and selection of encryption algorithms. The main function of the GMM sub-layer is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. GMM header format: 8 7 6 5 4 3 2 1 Octet Protocol discriminator Skip indicator 1 Message type 2 Information elements 3-n GMM header structure; Definitions --------------------------------- Protocol discriminator - 1000 identifies the GMM protocol. Skip indicator - The value of this field is 0000. Message type - 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 bit types: 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 --- Conclusion; PsychoSpy and I wrote this document as a guide for anyone desiring to learn more about the future of GSM wireless. Within the next couple of years, I guarantee you'll be seeing a vast number of GSM-type phones in Canada (FIDO provider) offering the high-speed GSM add-on technology known as GPRS. So when GPRS is released by 2002, you won't be left out in the cold wondering "now how the hell did they do that?" because you would of read this document! What to look for in the future in regards to our R&D: - A look at GPRS administration, configuration and security analysis - CDMA Protocols; CC, MM, BSSMAP, DTAP (GSM-L3), RR, BTSM, BSSAP - SS7 Protocols; MTP2/MTP3, SCCP (v2.0), TCAP ISUP, TUP, DUP ---- Contact Information; PsychoSpy -- E-mail: PsychoSpy@softhome.net ICQ: 5057653 The Clone -- E-mail: theclone@haxordogs.net ICQ: 79198218 URL: http://www.nettwerked.net ~-= An N&N Production =-~