9.3 Packet Routeing and Transfer Function

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

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 [13]). The link MTU size for IPv6 is sent to the MS by including it in the IPv6 Router Advertisement message (see RFC 4861 [98]).

When using a packet data network connection of type "non-IP" (clause 4.3.17.8 of TS 23.401 [89]), 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 [13]). 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).

NOTE 1: Ideally the network configuration ensures that for PDP type IPv4v6 the link MTU values provided to the UE via PCO and in the IPv6 Router Advertisement message are the same. In cases where this condition cannot be met, the MTU size selected by the UE is unspecified.

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.

NOTE 2: The TE when it is separated from the MT can perform MTU configuration itself and this is out of scope of 3GPP standardization. Thus, when the MT component in the terminal obtains MTU configuration from the network, this does not imply that the behavior of the MS considered as a whole will always employ this MTU. In many terminals having a separated TE, the TE component configured by default to use an MTU of 1500 octets.

NOTE 3: In network deployments that have MTU size of 1500 octets in the transport network, providing a link MTU value of 1358 octets to the MS as part of the IP configuration information from the network will prevent the IP layer fragmentation within the transport network between the MS and the GGSN/P-GW. Link MTU considerations are discussed further in Annex C.

NOTE 4: As the link MTU value is provided as a part of the session management configuration information, a link MTU value can be provided during each PDN connection establishments.

NOTE 5: PDP type PPP is supported only when data is routed over a GGSN employing the Gn/Gp interfaces. A P‑GW supports PDP type IPv4, IPv6 and IPv4/v6 only.

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 [90]).

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.

NOTE 6: If the network applies enforcements of uplink PDP PDUs the network might expect the uplink PDP PDUs to be sent on the same PDP contexts as the corresponding downlink N-PDUs of the same traffic flow i.e. traffic flows might be expected to be bi-directional.

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.

NOTE 7: If the MS applies local mapping for an application for ‘MS/NW’ mode, there is a risk that the PDP PDUs will be dropped by the network as there is no specified way to ensure that there are corresponding PCC rules.

NOTE 8: If both the MS and the network are compliant to Rel‑11 or a later version of the specification, then the requirements in clause 9.2.0 ensure that only a PDP context that was activated with the PDP Context activation procedure can have a TFT not including any uplink packet filters

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.