By sending a RAB Release Request or Iu Release Request message to the SGSN, an Iu mode RAN initiates the release of one or more RABs. The preservation procedure allows the active PDP contexts associated with the released RABs to be preserved in the CN, and the RABs can then be re-established at a later stage, see clause 220.127.116.11 and clause 18.104.22.168.
An Iu mode RAN uses the Iu Release Request to request release of all RABs of an MS, and the RAB Release Request in other cases.
The procedure for re-establishment of RABs allows the SGSN to re-establish RABs for active PDP contexts that don't have an associated RAB.
The MS initiates the re-establishment of RABs by using the Service Request (Service Type = Data) message. This is described in the clause "MS Initiated Service Request Procedure". SGSN shall not establish RABs for PDP contexts with maximum bit rate for uplink and downlink of 0 kbit/s. For these PDP contexts including a TFT with packet filter(s) set by the MS, the MS shall perform a MS-initiated PDP Context Modification or Deactivation procedure. For PDP contexts including a TFT with packet filter(s) set by the network only, the MS does not re-establish the RABs (see clauses 22.214.171.124 and 126.96.36.199).
When RABs for an MS that has no RRC connection needs to be re-established, the CN must first page the MS. The clause "Network Initiated Service Request Procedure" describes this.
When RAB(s) are released in S4 SGSN, the received downlink data packet(s) for the preserved EPS bearer(s) may be buffered in the Serving GW. In this case, at reception of the first downlink data packet for one of those EPS bearers, the Serving GW sends a Downlink Data Notification message to the S4 SGSN. When RABs for a UE in PMM-IDLE needs to be re-established, the S4 SGSN must first page the UE. When RAB(s) need to be re-established for a UE that already has an active RRC connection, the S4 SGSN initiates the re-establishment of RABs for all the preserved PDN connections by using the RAB assignment procedure.
routes and transfers packets between a mobile TE and a packet data network, i.e. between reference point R and reference points Gi or SGi;
routes and transfers packets between mobile TE across different PLMNs, i.e.:
between reference point R and reference point Gi via interface Gp;
between reference point R and reference point SGi via interface S8;
routes and transfers packets between TEs, i.e. between the R reference point in different MSs; and
optionally supports IP Multicast routeing of packets via a relay function in the GGSN and P-GW.
The PDP PDUs shall be routed and transferred between the MS and the GGSN or P-GW as N PDUs. In order to avoid IP layer fragmentation between the MS and the GGSN or P-GW, the link MTU size in the MS should be set to the value provided by the network as a part of the IP configuration. The link MTU size for IPv4 is sent to the MS by including it in the PCO (see TS 24.008). The link MTU size for IPv6 is sent to the MS by including it in the IPv6 Router Advertisement message (see RFC 4861).
When using a packet data network connection of type "non-IP" (clause 188.8.131.52 of TS 23.401), the maximum uplink packet size that the MS shall use may be provided by the network as a part of the session management configuration by encoding it within the PCO (see TS 24.008). To provide a consistent environment for application developers, the network shall use a maximum packet size of at least 128 octets (this applies to both uplink and downlink).
When the MT and the TE are separated, e.g. a dongle based MS, it is not always possible to set the MTU value by means of information provided by the network. The network shall have the capability of transferring N-PDUs containing PDP PDUs, where the PDP PDUs are of 1500 octets, between the MS and GGSN/P-GW.
Between the 2G SGSN and the MS, PDP PDUs are transferred with SNDCP. Between the 3G SGSN and the MS, PDP PDUs are transferred with GTP-U and PDCP.
Between the SGSN and the GGSN when using Gn/Gp, or between the SGSN and the S-GW when using S4, PDP PDUs are routed and transferred with the UDP/IP protocols. The GPRS Tunnelling Protocol (GTP) transfers data through tunnels. A tunnel endpoint identifier (TEID) and an IP address identify a GTP tunnel. When a Direct Tunnel is established, PDP PDUs are routed and transferred directly between the UTRAN and the GGSN using Gn or between UTRAN and the S-GW using S12. On S5/S8 interfaces PMIP may be used instead of GTP (see TS 23.402).
When multiple PDP contexts exist for the same PDP address/APN pair of an MS, the GGSN routes downlink N PDUs to the different GTP tunnels based on the downlink packet filters in the TFTs assigned to the PDP contexts. Upon reception of a PDP PDU, the GGSN evaluates for a match, first the downlink packet filter amongst all TFTs that has the smallest evaluation precedence index and, in case no match is found, proceeds with the evaluation of downlink packet filters in increasing order of their evaluation precedence index. This procedure shall be executed until a match is found, in which case the N PDU is tunnelled to the SGSN via the PDP context that is associated with the TFT of the matching downlink packet filter. If no match is found, the N PDU shall be sent via the PDP context that does not have a TFT assigned to it; if all PDP contexts have a TFT assigned, the GGSN shall silently discard the PDP PDU.
When multiple PDP contexts exist for the same PDP address/APN pair of an MS, the MS routes uplink PDP-PDUs to the different PDP contexts based on either MS-local mapping for 'MS_only' mode, or based on uplink packet filters in the TFTs assigned to these PDP contexts for 'MS/NW' mode.
For 'MS_only' mode (or in 'MS_only' mode after a change from 'MS/NW' mode), upon transmission of a PDP PDU, the MS shall apply local mapping. The MS is responsible for creating or modifying PDP contexts and their QoS. The MS should define TFTs in such a way that downlink PDP PDUs are routed to a PDP context that best matches the QoS requested by the receiver of this PDU (e.g. an application supporting QoS). For each uplink PDP PDU, the MS should choose the PDP context that best matches the QoS requested by the sender of this PDP PDU (e.g. an application supporting QoS). Packet classification and routeing within the MS is an MS-local matter. The GGSN shall not match uplink N PDUs against TFTs.
For 'MS/NW' mode, upon transmission of a PDP PDU, the MS evaluates for a match, first the uplink packet filter amongst all TFTs that has the smallest evaluation precedence index and, in case no match is found, proceeds with the evaluation of uplink packet filters in increasing order of their evaluation precedence index. This procedure shall be executed until a match is found, or all uplink packet filters have been evaluated. If a match is found, the PDP PDU is transmitted on the PDP context that is associated with the TFT of the matching uplink packet filter. If no match is found, the MS shall send the PDP PDU via the PDP context that has not been assigned any uplink packet filter. If all PDP contexts have been assigned uplink packet filter(s), the MS shall silently discard the PDP PDU.
TFTs are used for PDP types IPv4, IPv6, IPv4/v6 and PPP only. For PDP type PPP a TFT is applicable only when PPP is terminated in the GGSN (i.e. GGSN does not provide PDN interworking by means of tunnelled PPP, e.g. by the Layer Two Tunnelling Protocol (L2TP)) and IP traffic is carried over PPP. To support roaming subscribers, and for forward compatibility, the SGSN is not required to know the tunnelled PDP. Every SGSN shall have the capability to transfer PDUs belonging to PDPs not supported in the PLMN of the SGSN.
If packet routing and transfer takes place between the SGSN and the S-GW using S4, or between the UTRAN and the S-GW using S12, PDP contexts need to be mapped into EPS bearer contexts and vice versa. Context mapping is handled by the SGSN when using S4. This is transparent to the MS.
The GGSN and P-GW could also optionally support IP Multicast: this allows the MSs to join multicast groups and start receiving multicast packets. The GGSN duplicates the incoming multicast packets and relays them to the already active TEIDs. These TEIDs are those of MSs that have joined a multicast group.
The relay function of a network node transfers the PDP PDUs received from the incoming link to the appropriate outgoing link. At the RNC, the SGSN the S-GW, and the GGSN or P-GW the relay function stores all valid PDP PDUs until they are forwarded to the next network node or until the maximum holding time of the PDP PDUs is reached. The PDP PDUs are discarded when buffering is longer than their maximum holding time. This maximum holding time is implementation dependent and can be influenced by the PDP type, the QoS of the PDP PDU, the resource load status, and by buffer conditions. The discarding protects resources from useless transfer attempts, especially the radio resource. Impacts on user protocol operation by too short holding time shall be avoided.
In A/Gb mode, the SGSN and GGSN or P-GW relay functions add sequence numbers to PDP PDUs received from SNDCP and from the Gi or SGi reference points, respectively. In Iu mode, the RNC and GGSN or P-GW relay functions add sequence numbers to PDP PDUs received from PDCP and from the Gi or SGi reference points, respectively.
PDP PDUs may be re-sequenced in the RNC, the SGSN, and/or in the GGSN depending on the setting of the delivery order attribute in the QoS profile. In A/Gb mode, the SGSN relay function may perform re-sequencing of PDP PDUs before passing the PDP PDUs to SNDCP. In Iu mode, the SGSN relay function may optionally perform re-sequencing of PDP PDUs before passing the PDP PDUs to Iu GTP-U and before passing the PDP PDUs to Gn GTP-U. The GGSN relay function may perform re-sequencing of PDP PDUs before passing the PDP PDUs to the Gi reference point. The RNC may perform re-sequencing of PDP PDUs before passing the PDP PDUs to PDCP.
The Packet Terminal Adaptation function adapts packets received from and transmitted to the Terminal Equipment to a form suitable for transmission within the PLMN.
A range of MT versions providing different standard interfaces towards the TE can be used, e.g.:
MT with asynchronous serial interface and PAD (Packet Assembly / Disassembly) support. If the PAD function does not exist in the MT, it exists in the TE.
"Embedded MT" integrated with the TE, possibly via an industry-standard application program interface.
GPRS transparently transports PDP PDUs between packet data networks and MSs. All PDP PDUs are encapsulated and decapsulated for routeing purposes. Encapsulation functionality exists at the MS, at the RNC, at the Iu mode BSC, at the SGSN, at the S-GW, and at the GGSN/P-GW. Encapsulation allows PDP PDUs to be delivered to and associated with the correct PDP context in the MS, the SGSN, or the GGSN/P-GW. Two different encapsulation schemes are used; one for the backbone network between two GSNs, between SGSNs and S-GWs, and between an SGSN and an RNC, and one for the A/Gb mode connection between the SGSN and the MS or for the Iu mode RRC connection between the RAN and the MS.
Encapsulation requires that the MS is attached to GPRS, and that the PDP Context Activation procedure has been executed. If the GPRS Attach or PDP Context Activation procedures cannot be successfully executed, then uplink PDP PDUs are discarded in the MS. If these procedures have not been executed when a downlink PDP PDU arrives in the GGSN /P-GW, then the downlink PDP PDU shall be discarded, rejected, or the Network-Requested PDP Context Activation procedure shall be initiated. Network-Requested PDP Context Activation is not supported for connectivity over S4.
Core network nodes encapsulate a PDP PDU with a GPRS Tunnelling Protocol header, and insert this GTP PDU in a UDP PDU that again is inserted in an IP PDU. The IP and GTP PDU headers contain the core network node addresses and tunnel endpoint identifier necessary to uniquely address a PDP context.
For connectivity between SGSNs and between SGSNs and GGSNs based on Gn/Gp, the GTP encapsulation header is defined in TS 29.060. For connectivity between SGSNs and between SGSNs and S-GWs based on S16 and S4, respectively, the GTP encapsulation header is defined in TS 29.274.
Between an SGSN and an MS in A/Gb mode, an SGSN or MS PDP context is uniquely addressed with a temporary logical link identity and a network layer service access point identifier pair. TLLI is derived from the P-TMSI. An NSAPI is assigned when the MS initiates the PDP Context Activation function. The relationship between TLLI / NSAPI and LLC / SNDCP is illustrated in Figure 94. TLLI and NSAPI are described in clause "NSAPI and TLLI for A/Gb mode".
A Home NodeB L-GW should receive and process multicast group membership report messages (e.g. according to RFC 3376 / RFC 3810) sent either by the network accessed by LIPA or by the UE. Based upon these messages, the L-GW should forward multicast IP datagrams messages sent by the UE to the network accessed by LIPA, or from the network accessed by LIPA to the UE, as appropriate.
The UE may implement RFC 3376 or RFC 3810 to report multicast groups that the UE seeks to receive.
To make UPnP/DLNA service advertisements sent with an IP TTL=1 available to UEs that employ LIPA, a proxying function in the L-GW may be implemented, e.g. to retransmit UPnP service advertisements to UEs after changing the source address. This proxying to the UE shall not be performed if the multicast packet is transmitted with an IPv4 or IPv6 link-local source address, RFC 3927, RFC 4291.
This screening mechanism may be performed by routers and firewalls, and performs the selection of which packets to allow and which to deny.
Only network-controlled message screening shall be supported. Network-controlled screening is used to protect the GPRS packet domain PLMN from known security problems, and the screening provided by a certain PLMN is applied independently of the MS user. Network-controlled screening is outside the scope of this specification.
Non-GPRS MSs in A/Gb mode PLMNs that support GPRS shall, without changes, be able to continue operation.
PLMNs that do not support GPRS shall, without changes, be able to continue interworking with PLMNs that do support GPRS.
An A/Gb mode MS shall be able to access GPRS services with GPRS-aware SIMs, and with SIMs that are not GPRS-aware. A GPRS-aware SIM is able to store information in the elementary files EFKcGPRS and EFLOCIGPRS, as defined in TS 51.011.
The compatibility of SIMs and USIMs with A/Gb mode MSs or Iu mode MSs is defined in TS 31.102.
Support for GTPv0 is removed from 3GPP Rel-8 GTPv1 specification. Therefore, the interactions between GTPv0 (R99) and GTPv1(R99) is not defined and supported, for protocol details see "Removing support for GTPv1 to GTPv0" in TS 29.060.
A Gn/Gp SGSN supporting R7 or later shall be configured with knowledge of the Release supported by the Iu-mode RAN. In addition to the QoS profile negotiation mechanism defined in clause "Activation Procedures", the Gn/Gp SGSN shall further select specific values of the QoS profile to be compliant with the Release supported by the Iu-mode RAN, as specified in TS 23.107 for that Release, before contacting the GGSN/P-GW, if appropriate, and performing RAB assignment procedures.
To avoid that bit rates exceeding 16 Mbps are assigned to UEs potentially not capable of handling NAS QoS extensions introduced in Rel 7, the RNC indicates a "Higher bitrates than 16 Mbps flag" in the RANAP Initial UE Message, RANAP Relocation Complete, or RANAP Enhanced Relocation Complete as defined in TS 25.413 to the SGSN. This flag is set depending on the "Access stratum release indicator" defined in TS 25.331. The "Higher bitrates than 16 Mbps flag" is set to "allowed" if the "Access stratum release indicator" is set to a release of Rel 7 or higher. Otherwise, it shall be set to "not allowed".
If the SGSN receives the "Higher bitrates than 16 Mbps flag" in RANAP Initial UE Message, RANAP Relocation Complete, or RANAP Enhanced Relocation Complete, it stores it as received in the MM Context of the UE, unless, based on implementation specific logic, the SGSN derives from other information that the UE either supports bitrates higher than 16 MBit/s or not. If "Higher bitrates than 16 Mbps flag" is not included by RANAP (since the employed version of the RANAP protocol does not support this feature), the SGSN sets the corresponding flag in the MM Context of the UE depending on implementation.
If the "Higher bitrates than 16 Mbps flag" in the MM Context of the UE is set to "not allowed" and if the authorized APN-AMBR is higher than 16 Mbps, the S4-SGSN shall, for non-GBR bearers, restrict the MBR sent to the UE to within 16 Mbps. For GBR bearers, the request shall be rejected if the authorized GBR/MBR is higher than 16 Mbps in the activation and modification procedures.
GPRS idle mode mobility procedures performed by Gn/Gp SGSNs specify a set of sequence number handling functions, e.g. the exchange of sequence numbers during Routing Area Update procedure. E-UTRAN based and S4-SGSN based idle mode mobility procedures don't specify any such sequence number mappings for mobility scenarios. To avoid interoperation issues a network that deploys E-UTRAN and/or S4-SGSNs shall not configure usage of the feature "delivery order required" for PDP contexts of PDP type IPv4, IPv6, IPv4v6 or Non-IP. Also the network shall not configure usage of lossless PDCP of UTRAN and the GERAN SGSN shall not configure usage of acknowledged mode LLC/NSAPI/SNDCP.
A Gn/Gp SGSN or S4-SGSN supporting QoS extensions available from this release of specification shall be configured with knowledge of the Maximum Bit Rate and Guaranteed Bit Rate supported by the Iu-mode RAN. In addition to the QoS profile negotiation mechanism defined in clause 9.2.2"Activation Procedures", the Gn/Gp SGSN or S4-SGSN shall further select specific values of the QoS profile to be compliant with the Maximum Bit Rate supported by the Iu-mode RAN, as specified in TS 23.107 for that release, before performing RAB assignment procedures.
For GBR bearers, the Gn/Gp SGSN shall restrict the Guaranteed Bit Rate in the same way as described for the Maximum Bit Rate above. For GBR bearers, the S4-SGSN shall reject an EPS Bearer Activation or Modification including a Guarantee Bit Rate that is not supported by the Iu-mode RAN. RAB Assignment procedures shall not be initiated in this case.