03.603GPPGeneral Packet Radio Service (GPRS)Release 1998Service descriptionStage 2TS
12.1 Transmission Modes
The GTP, LLC, and RLC protocols offer various transmission modes. The combinations of the GTP, LLC, and RLC transmission modes define the QoS reliability classes (see subclause "Reliability Class").
12.1.1 GTP Transmission Modes
Two modes of operation of the GTP layer are supported for information transfer between the GGSN and SGSN; unacknowledged (UDP/IP) and acknowledged (TCP/IP). The GTP layer shall support both modes simultaneously.
12.1.2 LLC Transmission Modes
Two modes of operation of the LLC layer are defined for information transfer; unacknowledged and acknowledged. The LLC layer shall support both modes simultaneously.
– In acknowledged mode, the receipt of LL‑PDUs are confirmed. The LLC layer retransmits LL‑PDUs if confirmation has not been received within a timeout period.
– In unacknowledged mode, there is no confirmation required for LL‑PDUs.
Signalling and SMS shall be transferred in unacknowledged mode.
In unacknowledged mode, the LLC layer shall offer the following two options:
– transport of "protected" information, such that errors within the LLC information field result in the frame being discarded; and
– transport of "unprotected" information, such that errors within the LLC information field do not result in the frame being discarded.
The LLC layer shall support several different QoS delay classes with different transfer delay characteristics.
12.1.3 RLC Transmission Modes
Two modes of operation of the RLC layer are defined for information transfer; unacknowledged and acknowledged. The RLC layer shall support both modes simultaneously.
12.2 Logical Link Control Functionality
The Logical Link Control (LLC) protocol provides a reliable logical link between the MS and its SGSN. As shown in subclause "Transmission and Signalling Planes", the LLC layer is situated below the SNDC layer.
TLLI is used for addressing at the LLC layer. TLLI is described in subclause "NSAPI and TLLI".
LLC provides the services necessary to maintain a ciphered data link between an MS and an SGSN. The LLC layer does not support direct communication between two MSs.
The LLC connection is maintained as the MS moves between cells served by the same SGSN. When the MS moves to a cell being served by a different SGSN, the existing connection is released and a new logical connection is established with the new SGSN.
LLC shall be independent of the underlying radio interface protocols. In order to allow LLC to operate with a variety of different radio interface protocols, and to ensure optimum performance, it may be necessary to adjust e.g., the maximum LLC PDU length and the LLC protocol timer values. Such adjustments can be made through negotiation between the MS and the SGSN. The maximum length of an LLC PDU shall not be greater than 1 600 octets minus the BSSGP protocol control information.
The Logical Link Control layer supports:
– service primitives allowing the transfer of SNDCP Protocol Data Units (SN‑PDUs) between the Subnetwork Dependent Convergence layer and the Logical Link Control layer;
– procedures for transferring LL‑PDUs between the MS and SGSN, including:
– procedures for unacknowledged delivery of LL‑PDUs between the MS and the SGSN; and
– procedures for acknowledged, reliable delivery of LL‑PDUs between the MS and SGSN;
– procedures for detecting and recovering from lost or corrupted LL‑PDUs;
– procedures for flow control of LL‑PDUs between the MS and the SGSN; and
– procedures for ciphering of LL‑PDUs. The procedures are applicable to both unacknowledged and acknowledged LL‑PDU delivery.
The layer functions are organised in such a way that ciphering resides immediately above the RLC/MAC layer in the MS, and immediately above the BSSGP layer in the SGSN.
12.3 Subnetwork Dependent Convergence Functionality
The Subnetwork Dependent Convergence (SNDC) protocol is situated below the network layer and above the Logical Link Control layer in the MS and the SGSN, as shown in subclause "Transmission and Signalling Planes". A variety of network layers are supported, e.g., IP and X.25. The network-layer packet data protocols share the same SNDCP, that then performs multiplexing of data coming from the different sources to be sent across LLC. This is illustrated in Figure 46.
Figure 46: Multiplexing of Network Protocols
The following identities and control information is needed:
– NSAPI identifies the network layer. The SNDCP control part contains compression information.
– TLLI identifies the MS. The LLC control part contains the rest of the LLC protocol header including ciphering information.
The Subnetwork Dependent Convergence function is defined in terms of offered services and sub-functions.
The SNDC function provides the following services to the network layer:
– transmission and reception of N‑PDUs in acknowledged and unacknowledged LLC mode. In acknowledged mode, the receipt of data shall be confirmed at the LLC layer, and the data shall be transmitted and received in order per NSAPI. In unacknowledged mode, the receipt of data shall not be confirmed at the SNDCP layer nor at the LLC layer;
– transmission and reception between the MS and SGSN of variable-length N‑PDUs;
– transmission and reception of N‑PDUs between the SGSN and MS according to the negotiated QoS profile;
– transfer of the minimum amount of data possible between the SGSN and MS through compression techniques.
The SNDC function requires the following services from the LLC layer:
– acknowledged and unacknowledged data transfer;
– ciphered transmission of SN‑PDUs;
– in-order delivery of SN‑PDUs per LLC SAPI;
– support for variable-length SN‑PDUs.
Figure 47: Sequential Invocation of SNDC Functionality
SNDCP performs the following subfunctions:
– mapping of SNDC primitives received from the network layer into corresponding LLC primitives to be passed to the LLC layer, and vice versa;
– multiplexing of N‑PDUs from one or several NSAPIs onto one LLC SAPI. NSAPIs that are multiplexed onto the same SAPI shall use the same radio priority level, QoS delay class, and precedence class;
– compression of redundant protocol control information and user data. This may include e.g., TCP/IP header compression and V.42 bis  data compression. Compression may be performed independently for each QoS delay class and precedence class. If several network layers use the same QoS delay class and precedence class, then one common compressor may be used for these network layers. The relationship between NSAPIs, compressors, and SAPIs is defined in GSM 04.65. Compression parameters are negotiated between the MS and the SGSN. Compression is an optional SNDC function;
– segmentation and reassembly. The output of the compression subfunctions are segmented to maximum-length LLC frames.
12.4 Point-to-Point Protocol Functionality
The PPP protocol is specified in RFC 1661 .
12.4.1 Transmission Plane for PDP Type PPP
The transmission plane for the PDP type PPP consists of a PPP protocol stack above SNDCP in the MS and above GTP in the GGSN. The GGSN may either terminate the PPP protocol and access the packet data network at the IP level, or further tunnel PPP PDUs via e.g., L2TP.
In case the application above PPP uses a different protocol than IP (e.g., IPX or AppleTalk), the interconnection to the packet data network is outside the scope of this specification.
Figure 48: Transmission Plane for PDP Type PPP
The PPP peers at the MS and GGSN handle the PPP protocol as specified in RFC 1661. PPP requires in-sequence packet delivery by the underlying protocols. Concerning GTP, this shall be achieved by enabling Reordering Required upon GTP tunnel establishment. Concerning SNDCP, out-of-sequence packets, which may be present if LLC operates in unacknowledged mode, shall be discarded. SNDCP shall not use TCP/IP header compression because PPP may not carry IP packets at all, or because PPP may carry IP packets with already compressed TCP/IP headers. These PPP options are negotiated during the RFC 1661 Network Control Protocol establishment phase.
12.5 Gb Interface
The Gb interface connects the BSS and the SGSN, allowing the exchange of signalling information and user data. The Gb interface shall allow many users to be multiplexed over the same physical resource. Resources are given to a user upon activity (when data is sent or received) and are reallocated immediately thereafter. This is in contrast to the A interface where a single user has the sole use of a dedicated physical resource throughout the lifetime of a call irrespective of activity.
GPRS signalling and user data are sent in the same transmission plane. No dedicated physical resources are required to be allocated for signalling purposes.
Access rates per user may vary without restriction from zero data to the maximum possible line rate (e.g., 1 984 kbit/s for the available bitrate of an E1 trunk).
12.5.1 Physical Layer Protocol
Several physical layer configurations and protocols are possible, as defined in GSM 08.14 .
The physical resources shall be allocated by O&M procedures.
12.5.2 Link Layer Protocols
The Gb interface link layer is based on Frame Relay, as defined in GSM 08.16. Frame Relay virtual circuits are established between SGSN and BSS. LLC PDUs from many users are multiplexed on these virtual circuits. The virtual circuits may be multi-hop and traverse a network of Frame Relay switching nodes. Frame Relay shall be used for signalling and data transmission.
The following characteristics apply for the Frame Relay connection:
– the maximum Frame Relay information field size shall be 1 600 octets;
– the Frame Relay address length shall be 2 octets;
– the BSS and the SGSN shall both implement Frame Relay DTE functionality. The SGSN may optionally also implement DCE functionality;
– frame Relay PVCs shall be used;
– the Frame Relay layer offers detection of but no recovery from transmission errors;
– one or more Frame Relay PVCs shall be used between one SGSN and one BSS to transport BSSGP PDUs.
12.5.3 BSS GPRS Protocol
The primary function of BSSGP is to provide the radio-related, QoS, and routeing information that is required to transmit user data between a BSS and an SGSN. In the BSS, it acts as an interface between LLC frames and RLC/MAC blocks. In the SGSN, it forms an interface between RLC/MAC-derived information and LLC frames. A secondary function is to enable two physically distinct nodes, the SGSN and BSS, to operate node management control functions.
Figure 49: BSSGP Protocol Position
There is a one-to-one relationship between the BSSGP protocol in the SGSN and in the BSS. If one SGSN handles multiple BSSs, the SGSN has to have one BSSGP protocol machine for each BSS.
The main functions for the BSSGP protocol are to:
– provide a connection-less link between the SGSN and the BSS;
– transfer data unconfirmed between the SGSN and the BSS;
– provide tools for bi-directional control of the flow of data between the SGSN and the BSS;
– handle paging requests from the SGSN to the BSS;
– give support for flushing of old messages in the BSS e.g., when an MS changes BSS; and
– support multiple layer 2 links between the SGSN and one BSS.
BSSGP is defined in GSM 08.18.
188.8.131.52 Inter-dependency of the BSSGP and LLC Functions
The functions of the BSSGP shall be defined in the context of the LLC function in order to avoid duplication of functions and information flows. The following functional model indicates each layer’s functional responsibilities.
Table 3: Mapping of High-level Functions Across the Gb Architecture
Network Node and Function
Same as for the SGSN.
Provides transfer of frames between the SGSN and MS.
Same as for SGSN.
Individual MS radio-related information is used by the BSS to transfer LLC frames across the Gb and Um.
Provides flow control and unconfirmed data delivery services across the Gb interface (not the Um – this is the function of the LLC and RLC/MAC function).
Provides SGSN-BSS node management functions.
Same as for SGSN
Provides a multiplexing, variable-bandwidth, frame-based, link layer transport mechanism across the Gb interface, and load balancing.
184.108.40.206 BSSGP Addressing
For information transfer between the SGSN and the BSS the BSSGP is using a BSSGP Virtual Connection Identifier (BVCI) for addressing. Additionally, QoS profile, and the MS identification, e.g., TLLI, may be used to create queues and contexts in both the SGSN and the BSS. The flow control mechanism is then based on these queues and contexts.
220.127.116.11 BVCI Contexts in BSS and in SGSN
A BVCI context in the BSS consists of at least one queue for LLC PDUs and of the available radio resource capacity.
The BVCI context in the BSS is allocated for each cell supporting GPRS. For each new GPRS cell introduced in the BSS area, a new BVCI context shall be allocated.
In the SGSN the BVCI context consists of at least one queue for LLC PDUs and the allowed throughput on BSSGP. The allowed throughput is updated by BSSGP flow control messages.
18.104.22.168 Flow Control Between SGSN and BSS over the Gb Interface
The flow control mechanism controls the loading of the BSS LLC PDU queues per BVCI and per MS between the SGSN and the BSS in the downlink direction. No flow control is performed in the uplink direction. Buffers and link capacity shall be dimensioned to avoid loss of uplink data.
The downlink flow control mechanism is based on the following principles:
– in the SGSN, queues for LLC PDUs are provided per BVCI. These queues may be split further, e.g., per MS or per QoS delay class or precedence class. The SGSN shall pass LLC PDUs to LLC via BSSGP to the BSS as long as the allowed BSSGP throughput is not exceeded. The allowed BSSGP throughput is given per BVCI and for a single MS on that BVCI. The SGSN schedules the BSSGP downlink traffic of all MSs of a BVCI according to both throughput parameters and to the QoS profile related to each LLC PDU. The scheduling algorithm is implementation dependent;
– in the BSS, queues per BVCI are provided at the BSSGP level. These queues may be split further, e.g., per MS or per QoS delay class or precedence class. Depending on the queuing conditions and the available radio resource capacity in the cell the BSS indicates the allowed BSSGP throughput per BVCI and the default allowed BSSGP throughput for each individual MS of that BVCI by BSSGP flow control messages to the SGSN. Additionally, the BSS may change the allowed BSSGP throughput for an individual MS by a BSSGP flow control message.
12.6 Abis Interface
When the GPRS MAC and RLC layer functions are positioned remote to the BTS the information between the Channel Codec Unit (CCU) and the remote GPRS Packet Control Unit (PCU) is transferred in frames with a fixed length of 320 bits (20 ms). In the present document these frames are denoted "PCU Frames" and are an extension to the "TRAU frames" defined in GSM 08.60 . Within these frames both GPRS data and the GPRS RLC/MAC associated control signals are transferred.
The Abis interface should be the same if the PCU is positioned at the BSC site (option B in Figure 50) or at the SGSN site (option C in Figure 50). In option B, the PCU could be implemented as an adjunct unit to the BSC. In option C, the BSC should be considered as transparent for 16†kbit/s channels. In configurations B and C the PCU is referred to as being a remote PCU.
The remote PCU is considered a part of the BSC, and the signalling between the BSC and the PCU may be performed by using BSC internal signals. The inband signalling between the CCU and the PCU functions, using PCU frames is required when the Abis interface is applied (options B and C in Figure 50).
Figure 50: Remote Packet Control Unit (PCU) Positions
The PCU is responsible for the following GPRS MAC and RLC layer functions as defined in GSM 03.64:
– LLC layer PDU segmentation into RLC blocks for downlink transmission;
– LLC layer PDU reassembly from RLC blocks for uplink transmissions;
– PDCH scheduling functions for the uplink and downlink data transfers;
– PDCH uplink ARQ functions, including RLC block ack / nak;
– PDCH downlink ARQ function, including buffering and retransmission of RLC blocks;
– channel access control functions, e.g., access requests and grants; and
– radio channel management functions, e.g., power control, congestion control, broadcast control information, etc.
The functions inside the Channel Codec Unit (CCU) are:
– the channel coding functions, including FEC and interleaving; and
– radio channel measurement functions, including received quality level, received signal level and information related to timing advance measurements.
The BSS is responsible for allocation and de-allocation of radio resources. A PCU frame shall be transferred between the PCU and the CCU every 20 ms.
12.6.1 Remote Packet Control Unit
When the Packet Control Unit (PCU) is remote to the BTS, the Channel Codec Unit (CCU) in the BTS may control some of the functions in the remote PCU in the BSC. As well, the PCU may control some of the functions of the CCU. This remote control is performed by inband signalling carried by the control bits (C-bits) in each PCU frame.