The packet routeing and transfer function:

• 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 4.3.17.8 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.
• MT with synchronous serial 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.

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.

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.