12 Transmission
23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS
12.1 Transmission Modes
In A/Gb mode, the LLC and RLC protocols offer various transmission modes. The combinations of the LLC and RLC transmission modes define the QoS attributes SDU error ratio and residual bit error ratio.
In Iu mode, the RLC protocol provides various transmission modes to support user data transmission with different QoS.
The RLC protocol for A/Gb mode and the RLC protocol for Iu mode are distinct protocols.
12.1.1 GTP‑U Transmission Modes
One mode of operation of the GTP‑U layer is supported for information transfer between the GGSN and SGSN, unacknowledged (UDP/IP). This is also used between SGSN and S‑GW, between S‑GW and P‑GW, and between RNC and S‑GW. In Iu mode, GTP‑U is also used on the Iu interface for user data transport. Only the unacknowledged mode (UDP/IP) is supported on the Iu interface.
12.1.2 LLC Transmission Modes (A/Gb mode)
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 is 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 traffic 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.
The RLC for A/Gb mode is described in TS 44.060 [77], and for Iu mode in TS 25.322 [55].
12.2 Logical Link Control Functionality (A/Gb mode)
The Logical Link Control (LLC) protocol provides a reliable logical link between the MS and its SGSN. As shown in clause "User and Control Planes", the LLC layer is situated below the SNDC layer.
12.2.1 Addressing
TLLI is used for addressing at the LLC layer. TLLI is described in clause "NSAPI and TLLI for A/Gb mode".
12.2.2 Services
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.
12.2.3 Functions
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 (A/Gb mode)
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 clause "User and Control Planes". A variety of network layers are supported; e.g. IP. The network-layer packet data protocols share the same SNDCP, which performs multiplexing of data coming from the different sources to be sent across the LLC. This is illustrated in Figure 80.
Figure 80: 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.
12.3.1 Services
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.
12.3.2 Subfunctions
Figure 81: 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, and traffic class. In case BSS packet flow contexts are created all NSAPIs that are multiplexed onto the same LLC SAPI shall share the same BSS packet flow context.
– Compression of redundant protocol control information and user data. This may include e.g. TCP/IP header compression and V.42 bis [32] data compression. Compression may be performed independently for each QoS traffic handling priority and traffic class. If several network layers use the same QoS traffic handling priority and traffic class, one common compressor may be used for these network layers. The relationship between NSAPIs, compressors, and SAPIs is defined in TS 44.065 [16]. Compression parameters are negotiated between the MS and the SGSN. Compression is an optional SNDC function. The GGSN may indicate to the SGSN during PDP Context Activation and during Update PDP Context to negotiate no data compression for the PDP context.
– Segmentation and reassembly. The output of the compression subfunctions are segmented to maximum-length LLC frames.
12.4 PDCP (Iu mode)
The Packet Data Compatibility Protocol (PDCP) transmission functionality maps network-level characteristics onto the characteristics of the underlying network. PDCP can support several network layer protocols by providing protocol transparency for the users of the service. PDCP provides protocol control information compression. PDCP is located in the MS and the RAN and is described in TS 25.323 [57].
12.5 Point-to-Point Protocol Functionality
The PPP protocol is specified in RFC 1661 [44].
PDP Type PPP is only supported when using Gn/Gp.
12.5.1 User Plane for PDP Type PPP
The user plane for the PDP type PPP consists of a PPP protocol stack above SNDCP for A/Gb mode or above PDCP for Iu mode 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 82: A/Gb mode User Plane for PDP Type PPP
Figure 83: Iu mode User Plane for PDP Type PPP
12.5.2 Functions
The PPP peers at the MS and the GGSN handle the PPP protocol as specified in RFC 1661 [44]. PPP requires in-sequence packet delivery by the underlying protocols. Concerning GTP, this shall be achieved by negotiation of the delivery order attribute in the QoS profile upon PDP context activation. In A/Gb mode, concerning SNDCP, out-of-sequence packets, that may be present if LLC operates in unacknowledged mode, shall be discarded. SNDCP for A/Gb mode, and PDCP for Iu mode, 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 [44] Network Control Protocol establishment phase.
12.6 Gb Interface (A/Gb mode)
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.
A/Gb mode signalling and user data are sent in the same user 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 bit rate of an E1 trunk).
12.6.1 Physical Layer Protocol
Several physical layer configurations and protocols are possible, as defined in TS 48.014 [19].
The physical resources shall be allocated by O&M procedures.
12.6.2 Link Layer Protocols
Several Gb interface link layer configurations and protocols are possible as defined in TS 48.016 [20].
12.6.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 the BSS, to operate node management control functions.
Figure 84: 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. If the BSS applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the BSS must have one BSSGP protocol machine for each SGSN to which it applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes.
The main functions of 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;
– support multiple layer 2 links between the SGSN and one BSS; and
– Provide tools for control of the flow of data between the SGSN and the BSS during PS Handover procedures, as defined in TS 48.018 [78].
BSSGP is defined in TS 48.018 [78].
12.6.3.1 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 4: Mapping of High-level Functions Across the Gb Architecture
|
Network Node and Function |
MS |
BSS |
SGSN |
|
LLC: |
Same as for the SGSN. |
Provides transfer of frames between the SGSN and MS. |
|
|
BSSGP: |
MS←PLMN: MS→PLMN: 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. |
|
|
Network Service: |
Same as for SGSN |
Provides a multiplexing, variable-bandwidth, frame-based, link layer transport mechanism across the Gb interface, and load balancing. |
12.6.3.2 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.
12.6.3.3 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 radio resource capacity that is available on a radio cell for one SGSN. If the BSS applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the BSS must share the total available radio resource capacity for a radio cell between all the BVCI contexts representing this radio cell, where each of these BVCI contexts represents the radio cell for one SGSN.
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. If the BSS applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the BSS must have for each cell supporting GPRS and belonging to one pool area, one BVCI context for each of the SGSNs associated with this pool area.
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.
12.6.3.4 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, per MS and optionally per one or more PFCs 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 packet flow. 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, for a single MS on that BVCI and optionally for one or more PFCs of a single MS on a certain BVCI. The SGSN schedules the BSSGP downlink traffic of all MSs of a BVCI and, optionally of all PFCs of an MS, according to the maximum and guaranteed bit rate attributes and to the QoS profile related to each LLC PDU. The scheduling algorithm is implementation dependent.
– In the BSS, queues per BVCI context are provided at the BSSGP level. These queues may be split further, e.g. per MS or per packet flow. Depending on the queuing conditions and the available radio resource capacity in the cell, the BSS indicates the allowed BSSGP throughput per BVCI context and the default allowed BSSGP throughput for each individual MS of that BVCI context by BSSGP flow control messages to the SGSN. Additionally, the BSS may change the allowed BSSGP throughput for one or more PFCs of an individual MS or for an individual MS by a BSSGP flow control message. As more than one SGSN may send downlink data at the same time for a radio cell when the BSS applies Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the BSS has to share the total possible downlink traffic between the SGSNs that can access a radio cell. The BSS should use the existing flow control procedure on BVCI level to control each of the SGSNs in a way not to violate the total possible traffic for the radio cell. How the BSS decides to share the downlink traffic between each of the SGSNs is an implementation specific issue.
12.6.3.5 BSS Context
The SGSN may provide a BSS with information related to ongoing user data transmission in A/Gb mode. The information is given as BSS packet flow contexts, which describe QoS characteristics for the data transmission. Network support of BSS packet flow procedures is indicated in the system information as specified in TS 44.060 [77], the MS support is indicated in MS network capability as specified in TS 24.008 [13].
All BSS packet flow contexts related to one MS are stored in an MS specific BSS context. The BSS may contain BSS contexts for several MSs. Within a BSS context the BSS packet flow contexts are identified by a packet flow identifier, which is assigned by the SGSN. A BSS packet flow context is shared by one or more LLC SAPIs of the same MS with identical or similar negotiated QoS profiles. The data transfers related to LLC SAPIs that share the same BSS packet flow context constitute one packet flow.
Four packet flows are pre-defined, and identified by four reserved packet flow identifier values. The BSS shall not negotiate BSS packet flow contexts for these pre-defined packet flows with the SGSN. One pre-defined packet flow is used for best-effort service, one is used for SMS, one is used for TOM (Tunnelling of Messages) and one is used for signalling. The SGSN can assign the best-effort or SMS packet flow identifier to any PDP context. In the SMS case, the BSS shall handle the packet flow for the PDP context with the same QoS with which it handles SMS. A non-reserved packet flow identifier value is only significant for an MS when the SGSN provided the BSS with a packet flow context for this packet flow identifier value for this MS.
The combined BSS QoS profile for the PDP contexts that share the same packet flow is called the aggregate BSS QoS profile. The aggregate BSS QoS profile is considered to be a single parameter with multiple data transfer attributes as defined in clause "Quality of Service Profile". It defines the QoS that must be provided by the BSS for a given packet flow between the MS and the SGSN, i.e. for the Um and Gb interfaces combined. The aggregate BSS QoS profile is negotiated between the SGSN and the BSS. In order to control UE-AMBR, the SGSN shall group all non-GBR PDP contexts for an MS into a single aggregate BBS QoS profile and set the MBR parameter of that profile to equal the UE-AMBR.
NOTE: In order to maintain relative priority, associated with PDP contexts, of packets, implementation should ensure that packets are prioritised/scheduled appropriately before being passed into the BSS packet flow context.
A BSS packet flow timer indicates the maximum time that the BSS may store the BSS packet flow context. The BSS packet flow timer shall not exceed the value of the READY timer for this MS. The BSS packet flow timer is started when the BSS packet flow context is stored in the BSS and when an LLC frame is received from the MS. When the BSS packet flow timer expires, the BSS shall delete the BSS packet flow context.
When a PDP context is activated, modified or deactivated, the SGSN may create, modify, or delete BSS packet flow contexts.
PS Handover procedure is used to handover an MS with one or more packet flows from a source cell to a target cell. Handling of the BSS packet flows during PS Handover procedures over the BSSGP are described in TS 43.129 [87] and TS 48.018 [78].
12.6.3.5.1 BSS Packet Flow Context Creation Procedure
On receiving a request to transmit an uplink or downlink LLC PDU for which no BSS packet flow context exists in the BSS, the BSS may request the download of the BSS packet flow context from the SGSN.
If MS and BSS supports BSS packet flow procedures the SGSN may at any time request the creation of a BSS packet flow context, e.g. due to the activation of a PDP context.
If a request to create a BSS Packet Flow is received in the BSS for an MS during the ongoing PS Handover procedure, then the BSS shall ignore the request and apply the procedures as described in TS 48.018 [78].
The BSS Packet Flow Context Creation procedure is illustrated in Figure 85.
Figure 85: BSS Packet Flow Context Creation Procedure
1) The BSS receives a request to transfer an uplink or downlink user data LLC PDU for which it currently does not have a BSS packet flow context. In the uplink case, TLLI, Radio Priority, and Packet Flow Id are received from the MS as defined in TS 44.060 [77]. In the downlink case, TLLI and Packet Flow Id are received from the SGSN as defined in TS 48.018 [78]. If Packet Flow Id does not indicate a pre-defined value the BSS sends a Download BSS Packet Flow Context Request (RAI, TLLI, Packet Flow Id) message to the SGSN. Until the BSS receives the BSS packet flow context, the BSS shall handle uplink and downlink transfers according to a default aggregate BSS QoS profile. For uplink transfers, the default profile is specific to the radio priority level.
2) The SGSN sends a Create BSS Packet Flow Context Request (IMSI, TLLI, Packet Flow Id, Aggregate BSS QoS Profile Requested, BSS Packet Flow Timer) message to the associated BSS. The SGSN derives Aggregate BSS QoS Profile Requested from the QoS profile negotiated for the PDP contexts that share a packet flow as follows: The SGSN shall divide the transfer delay attribute in the QoS profile in one core network part and one BSS part. The SGSN estimates the transfer delay in the core network and subtracts this from the GPRS bearer service transfer delay. The result only covers the delay in the MS to SGSN segment of the GPRS PLMN. Since the BSS transports LLC PDUs obtained after segmentation of SDUs by the SNDCP layer, the SGSN shall convert the values of the GPRS bearer service attributes maximum SDU size, SDU error ratio, residual bit error ration, maximum bit rate, guaranteed bit rate and the resulting transfer delay to values applicable to the LLC PDUs. All other attributes in Aggregate BSS QoS Profile shall be the same as the corresponding GPRS bearer service attribute, see TS 23.107 [58]. The SGSN may also include the Allocation / Retention Priority Information Element in the Create BSS Packet Flow Context Request.
3) The BSS may restrict the requested aggregate BSS QoS profile given its capabilities and the current load. If the Allocation / Retention Priority Information Element is included by the SGSN in the Create BSS Packet Flow Context Request, the BSS may use it to perform queuing of the packet flow context creation or to pre-empt other packet flow contexts. The BSS creates a BSS packet flow context and inserts the parameters in its BSS context. The BSS returns a Create BSS Packet Flow Context Accept (IMSI, Packet Flow Id, Aggregate BSS QoS Profile Negotiated) message to the SGSN. The BSS uses the negotiated aggregate BSS QoS profile when allocating radio resources and other resources such as buffer capacity. The detailed operation is defined in TS 48.018 [78]. If the SGSN Aggregate BSS QoS Profile requested by the SGSN was restricted by the BSS, the SGSN takes the BSS restriction into account when indicating to the MS the negotiated QoS of the associated PDP context(s).
12.6.3.5.2 SGSN-Initiated BSS Packet Flow Context Modification Procedure
The SGSN may at any time request the modification of the contents of an existing BSS packet flow context, e.g. due to the activation, modification, or deactivation of a PDP context, or modification of the UE-AMBR value. The BSS Packet Flow Context Creation procedure shall be used in this case, and the BSS shall instead of creating a BSS packet flow context overwrite the existing parameters with the modified parameters.
The BSS Packet Flow Context Modification procedure will never be initiated for an MS during the ongoing PS Handover procedure as described in TS 48.018 [78].
12.6.3.5.3 BSS-Initiated BSS Packet Flow Context Modification Procedure
The BSS can at any time request modification of the contents of an existing BSS packet flow context, e.g. due to a change in the resource availability at the BSS.
The BSS-Initiated BSS Packet Flow Context Modification procedure is illustrated in Figure 86.
Figure 86: BSS-Initiated BSS Packet Flow Context Modification Procedure
1) The BSS sends a Modify BSS Packet Flow Context Request (IMSI, Packet Flow Id, Aggregate BSS QoS Profile Requested) message to the SGSN.
2) The SGSN may restrict the requested aggregate BSS QoS profile given its capabilities and the current load. The SGSN returns a Modify BSS Packet Flow Context Accept (IMSI, TLLI, Packet Flow Id, Aggregate BSS QoS Profile Negotiated, BSS Packet Flow Timer) message to the BSS. The BSS inserts the modified parameters in its BSS context.
12.6.3.5.4 BSS Packet Flow Context Deletion Procedures
The BSS may, due to e.g. memory restrictions or user inactivity, at any time delete a BSS packet flow context without notifying the SGSN.
If the BSS is no longer able to support the aggregate BSS QoS profile of a BSS packet flow context, it may, especially for conversational or streaming traffic class, request the SGSN to delete or modify the BSS packet flow context. The SGSN should either modify or delete the BSS packet flow context. In addition the SGSN may need to initiate the PDP Context Modification or PDP Context Deletion procedure.
If a Delete BSS Packet Flow Context Request is received for an MS during the ongoing PS Handover procedure, the procedures applied are described in TS 48.018 [78].
Figure 86a: BSS-Initiated BSS Packet Flow Context Deletion Procedure
1) The BSS sends a Delete BSS Packet Flow Context Request (TLLI, Packet Flow Id, Cause) to the SGSN.
2) The SGSN should start either the SGSN-initiated BSS packet flow context modification procedure or the deletion of the BSS packet flow context. In addition the SGSN may need to initiate the PDP Context Modification or PDP Context Deletion procedure.
The SGSN may request the deletion of a BSS packet flow context with the SGSN-Initiated BSS Packet Flow Context Deletion procedure, as illustrated in Figure 87.
Figure 87: SGSN-Initiated BSS Packet Flow Context Deletion Procedure
1) The SGSN sends a Delete BSS Packet Flow Context Request (TLLI , Packet Flow Id) message to the BSS. The BSS deletes the corresponding BSS packet flow context from its BSS context.
2) The BSS returns a Delete BSS Packet Flow Context Accept (TLLI, Packet Flow Id) message to the SGSN.
12.7 Iu Interface (Iu mode)
The Iu interface connects the UTRAN or Iu mode GERAN and the Core Network allowing the exchange of signalling information and user data. The user plane of the Iu interface shall allow user data from 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.
In Iu mode only user data is transmitted on this shared physical medium. Signalling data is transferred via an SCCP connection. Two different options exist for the transport of signalling and user data over Iu: the ATM transport option and the IP transport option. The different protocol stacks applicable to the Iu interface are described in TS 25.412 [56] for the control plane and TS 25.414 [64] for the user plane.
12.7.1 Consistent Sequence Numbering of PDUs on Iu and Gn Interfaces
The GTP‑U PDU sequence numbers allocated by the GGSN (downlink) and SRNS/SBSS (uplink) are kept unchanged irrespective of the number of GTP tunnels the PDU is transferred over. Therefore, SGSN shall use on the Iu interface for downlink PDUs the GTP‑U sequence number received from the GGSN, and shall use on the Gn interface for uplink PDUs the GTP‑U sequence number received from the SRNS/SBSS. In case of SRNS/SBSS relocation and inter-system change, the SRNS/SBSS and SGSN shall tunnel PDUs without changing the GTP‑U sequence numbers.
12.7.2 RAB Release Procedure
12.7.2.1 RAB Release Procedure using Gn/Gp
UTRAN initiates a RAB release procedure to release one or several RABs. The RAB Release procedure is illustrated in Figure 88a.
Figure 88a: RAB Release Procedure Using Gn/Gp
1) UTRAN initiates the procedure by sending a RAB Release Request (For each RAB to be released: RAB ID, Cause) message to the SGSN.
1a) If PDP Contexts associated with the released RABs are using streaming or conversational traffic class and to be preserved, or Direct Tunnel was established the SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between SGSN and GGSN. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN shall not negotiate the QoS attributes. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. See clause12.7.2.2 when S4 interface is used.
2) The SGSN sends a RAB Assignment Request (For each RAB to be released: RAB ID, Cause) to the UTRAN.
3) The Radio Bearer(s) are released if still existing.
4) UTRAN sends a RAB Assignment Response (For each released RAB: RAB ID, GTP SND, GTP SNU) to the SGSN. GTP SND and GTP SNU enable the SGSN to restore the values in case the PDP context is maintained and the RAB is re-established at a later stage.
If the RAB for the LIPA PDP Context is released, the HNB informs the collocated L-GW by internal signalling to release the direct user plane path between the L-GW and HNB of the LIPA PDP context.
12.7.2.2 RAB Release Procedure using S4
The following illustrates the procedure between SGSN and S‑GW when RAB Release Procedures takes place over S4. The procedure between MS and SGSN is same as specified in clause 12.7.2.1.
Figure 88b: RAB Release Procedure Using S4
A. The SGSN deactivates affected PDP context using streaming or conversational traffic class as specified in clause 9.2.4.2. For all other traffic classes, the SGSN preserves the affected PDP context.
If PDP Contexts associated with the released RAB is to be preserved and Direct Tunnel is established the SGSN sends Release Access Bearers Request to the S‑GW concerned to remove RNC address and TEID.
B. S‑GW sends Release Access Bearers Response to SGSN. The SGSN update the Address for User Plane and TEID for downlink data.
12.7.3 Iu Release Procedure
12.7.3.1 Iu Release Procedure Using Gn/Gp
This procedure is used to release the Iu interface. This procedure also triggers the release of all the Iu connections and changes the 3G‑SGSN PMM state to PMM‑IDLE. Both RAN-initiated and SGSN-initiated Iu release procedures are shown in Figure 89a.
NOTE 1: Message 1 is only sent when the RAN-initiated Iu release procedure is considered.
NOTE 2: Message 1 is not sent but message 2 is sent when the SGSN-initiated Iu release procedure is considered.
Figure 89a: Iu Release Procedure Using Gn/Gp
1) The RAN notices that the RRC connection has been released or detects a need to release the radio resources. It sends an Iu Release Request (Cause) message to the SGSN. Cause indicates the reason for the release (e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated Integrity Checking Failure, or Release due to UE generated signalling connection release). User Inactivity means that the RAN decided to release an MS that shows no more activity, in the case where the MS has only non real-time RABs established, in order to optimise the radio usage after the RRC-Connection-Release timer expired.
1a) If PDP Contexts associated with the released RABs are using streaming or conversational traffic class and to be preserved, or Direct Tunnel was established the SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between SGSN and GGSN. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN(s) shall not negotiate the QoS attributes. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. See clause 12.7.3.2 when S4 interface is used.
2) The SGSN releases the Iu by sending the Iu Release Command (Cause) message to the RAN. This message may be triggered either by an Iu Release Request message, or by another SGSN event (e.g. authentication failure, detach or the subscription to the CSG ID expires). The SGSN shall take the responsibility to release the Iu interface when the UE has no active PDP context, either immediately or after some timeout. It is optional for the SGSN to send the Iu Release Command message after an Iu Release Request message with Cause set to User Inactivity is received from the RAN.
3) If the RRC connection is not already released (Cause = User Inactivity), the RAN sends a Release RRC Connection message to the MS.
4) The MS returns a Release RRC Connection Acknowledge message to the RAN.
5) The RAN confirms the Iu release by returning an Iu Release Completion (for each released RAB: RAB ID, GTP SND, GTP SNU) message to the SGSN. GTP SND and GTP SNU enable the SGSN to restore the values in case the PDP context is maintained and the RAB is re-established at a later stage.
If the RNC does not receive the Release RRC Connection Acknowledge message and if Cause is different from Authentication Failure or Detach, it should send a failure message to the SGSN, and the SGSN should stay in the MM‑CONNECTED state.
If LIPA is active for a PDN connection, the HNB informs the collocated L-GW by internal signalling to release the direct user plane path between the L-GW and the HNB.
After Iu release, the MS and the SGSN shall modify PDP context(s) that use streaming or conversational traffic class according to the rules in clause "RNC-Initiated PDP Context Modification Procedure".
12.7.3.2 Iu Release Procedure Using S4
The following illustrates the procedure between SGSN and S‑GW when Iu Release Procedures takes place over S4. The procedure between MS and SGSN is same as specified in clause 12.7.3.1.
Figure 89b: Iu Release Procedure Using S4
A. The SGSN deactivates the PDP contexts using streaming or conversational traffic class as specified in clause 9.2.4.2. For all other cases, the SGSN preserves the PDP contexts.
In case of RNC Failure, SGSN may based on operator policy either preserve all bearers or initiate the Dedicated Bearer Deactivation procedure. See clause 9.2.4.1A.2.
If PDP Contexts associated with the released RABs are to be preserved and:
– if ISR is activated or Direct tunnel is established, the SGSN shall send Release Access Bearers Request to the S‑GW. For Direct Tunnel, the S‑GW removes RNC address for user plane and downlink S12 GTP-U TEID. Otherwise the S‑GW removes the SGSN addresses for user plane and downlink S4 GTP-U TEIDs.
– in other cases the SGSN can optionally send a Release Access Bearers Request to the SGW to remove the downlink user plane on S4.
B. The S‑GW returns a Release Access Bearers Response to SGSN.
12.7.4 RAB Assignment Procedure
12.7.4.1 RAB Assignment Procedure Using Gn/Gp
The purpose of the RAB Assignment procedure is to enable establishment of new RABs for a given MS and/or modification and/or release of already established RABs. When this procedure is executed and if there is any PDP context without radio access bearer assigned, the SGSN will decide which RABs to re-establish. The same messages are used for the three mentioned actions and it is only the content carried by the messages that is different. The RAB Assignment procedure, which is shown below, is specified in TS 25.413 [56b]. The RRC protocol is specified in TS 25.331 [52].
Figure 90a: RAB Assignment Procedure Using Gn/Gp
For LIPA or SIPTO at the local network with L-GW function collocated with the HNB PDN connection, when the L-GW receives the downlink data for an MS after the direct user plane path between the HNB and L-GW is released for that PDP context as defined in clause 12.7.2, the L GW sends the first downlink user packet to the SGSN and buffers all other downlink user packets.
1) The SGSN sends a RAB Assignment Request (MSISDN, APN, Charging characteristics) message to the RAN to establish, modify, or release one or several RABs. For each requested RAB or modified, if the RAB is allowed for queuing and the resource situation requires it, the RAN may place the RAB in the establishment queue. If Direct Tunnel is used the SGSN provides to the RNC the GGSN’s Address(es) for User Plane and TEID(s) for Uplink data. If any Release 7 new QoS IEs i.e. extended maximum bitrate and/or extended guaranteed bitrate are requested, QoS negotiation should be allowed. For RABs belonging to a PDP context/PDN connection for local IP access or SIPTO at the Local Network with L-GW function collocated with the HNB, the RAB Assignment Request message includes a Correlation ID for enabling the direct user plane path between the HNB and the L‑GW. For RABs belonging to a PDP context/PDN connection for SIPTO at the Local Network with L‑GW function collocated with the HNB, the RAB Assignment Request message includes a SIPTO Correlation ID for enabling the direct user plane path between the HNB and the L‑GW.
NOTE 1: In this release of the 3GPP specification the Correlation ID and SIPTO Correlation ID is set equal to the user plane GGSN TEID that the Gn-SGSN has revceived in step 4 of clause 9.2.2.1 or the user plane PDN GW TEID that the S4-SGSN has received in step D of clause 9.2.2.1A. For more detailed description on the usage of Correlation ID and SIPTO Correlation ID refer to TS 23.401 [89].
The SGSN may add, modify or remove the UE-AMBR in parallel to any requested RAB procedures. If the Access Restriction is present in the MM context, the Service Handover related information shall be included by S4-SGSN for the RAB Assignment Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.
2) The RAN establishes, modifies, or releases the appropriate radio bearers.
3) The RAN returns a RAB Assignment Response message to the SGSN. If the request to establish or modify one or several RABs has been queued, the RAN will report the outcome of the establishment or modification in subsequent RAB Assignment Response messages. The RAN returned MBR and/or GBR shall not exceed the maximum value corresponding to the 3GPP release the UE supports. If the SGSN receives a RAB Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided (e.g. "Requested Maximum Bit Rate not Available"), then the SGSN may send a new RAB Assignment Request message with different QoS profile(s). The number of re-attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent. If the LIPA or SIPTO at the Local Network with L-GW function collocated with the HNB PDP context is requested in the RAB Assignment, the internal direct user plane path is established between the HNB and L-GW. The downlink packet in the SGSN is forwarded to the HNB and the packets buffered in the L-GW are forwarded to the HNB on the direct user plane path.
4) If the SGSN established Direct Tunnel it shall send Update PDP Context Request to the GGSN(s) concerned and include the RNC’s Address for User Plane, downlink TEID for data, No QoS negotiation indication and the DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8, The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN(s) shall not negotiate the QoS attributes. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. See clause 12.7.4.2 when S4 interface is used.
12.7.4.2 RAB Assignment Procedure Using S4
The following illustrates the procedure between SGSN and S‑GW when RAB Assignment Procedures takes place over S4. The procedure between MS and SGSN is same as specified in clause 12.7.4.1.
For LIPA PDN connection, the downlink data handling in the L-GW as described in clause 12.7.4.1 is applied with one difference: If the SGSN established direct tunnel, the L-GW sends the first downlink user packet to the Serving GW. Otherwise, if the SGSN did not establish the direct tunnel, the L-GW sends the first downlink user packet to the SGSN.
If the SGSN receives a RAB Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided, the SGSN shall not re-attempt to send a new RAB Assignment Request message with different QoS profile(s) and also the step A and B below shall not be performed for the non-established RABs.
Figure 90b: RAB Assignment Procedure Using S4
A. If the SGSN established Direct Tunnel it shall send Modify Bearer Request to the S‑GW concerned and include the RNC’s Address for User Plane, downlink TEID for data, No QoS negotiation indication and the DTI. DTI is used to instruct the S‑GW to apply Direct Tunnel specific error handling as described in clause 13.8.
B. The S‑GW update the Address for User Plane and TEID for downlink data and return a Modify Bearer Response to S‑GW.
12.7.5 Location Reporting Procedure
This procedure is used by an SGSN to request the RAN to report where the MS is currently located, or to report when the MS moves into or out of a given service area. This procedure is defined for Iu mode and may be used for services that require location information (e.g. CAMEL and emergency calls).
Figure 91: Location Reporting Procedure
1) The SGSN detects from the subscriber data the need to monitor in which service area an MS in the PMM‑CONNECTED state with an Iu interface connection is located. The SGSN sends a Location Reporting Control (Service Area Code(s), Reporting Type) message to the RAN. The RAN stores the Service Area Code(s) as reporting area(s) for this MS. For example, a service area may be a location area with restricted access. Reporting Type indicates whether the message is intended to start a reporting period or trigger a stand-alone report about the current location of the MS.
2) The RAN detects that the MS moves into or out of a reporting area. Alternatively, the RAN derives the current location of the MS if this was requested by the SGSN.
3) The RAN sends a Location Report message informing the SGSN about where the MS is located. When the SGSN has requested the current location of the MS, the RAN shall include the requested location information , i.e. the Service Area Indication, in the Location Report message, if the RAN cannot determine current Service Area of the mobile, it indicates that the request could not be fulfilled, and may report Last Known Service Area with an indication of how long has past since the mobile was known to be in the indicated Service Area. The SGSN may then perform specific actions.
4) The SGSN can send a Cancel Location Reporting message to inform the RAN that it should terminate location reporting for a given MS. This message is needed only when the reporting was requested for a reporting period.
The procedure is implicitly cancelled at SRNC/SBSC relocation. If the service is still required in the new SRNC/SBSC or new SGSN, a new Location Reporting Control message shall be sent.
12.8 Abis Interface (A/Gb mode)
When the MAC and RLC layer functions are positioned remote to the BTS, the information between the Channel Codec Unit (CCU) and the remote 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 TS 48.060 [22]. Within these frames both GPRS data and the 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 92) or at the SGSN site (option C in Figure 92). 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 using BSC internal signals may provide the signalling between the BSC and the PCU. The in-band 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 92).
Figure 92: Remote Packet Control Unit (PCU) Positions
The PCU is responsible for the following MAC and RLC layer functions as defined in TS 43.064 [11]:
– 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 / Nack;
– 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;
– radio channel measurement functions, including received quality level, received signal level and information related to timing advance measurements; and
– for EGPRS, in case of incremental redundancy mode of operation, enhanced channel coding functions.
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.8.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. Inband signalling provides the remote control by using the control bits (C‑bits) in each PCU frame.
12.9 Gn Interface (A/Gb mode)
During the PS handover procedure the PS Handover Request Context containing packet flow specific information needs to be transferred between SGSNs. The detailed description of the procedures used during PS handover from GERAN A/Gb mode to GERAN A/Gb mode or GERAN A/Gb mode to Iu mode and vice-versa are described in TS 29.060 [26].