Content for TS 23.060 Word version: 18.0.0

1… 5… 5.3.8… 5.4… 5.4.2… 5.4.9… 5.6… 5.6.2 5.6.3… 5.6.3.7… 5.7… 6… 6.3… 6.5… 6.6… 6.8… 6.9… 6.9.1.3 6.9.2… 6.9.2.2… 6.9.2.2.2 6.9.2.2.3… 6.9.2.2.5… 6.9.3… 6.10… 6.12… 6.13… 6.13.1.2… 6.13.2… 6.13.2.2 6.14… 8… 8.2 9… 9.2.2… 9.2.2.2 9.2.2.3… 9.2.3… 9.2.3.2… 9.2.3.3… 9.2.4… 9.2.4.2… 9.2.5… 12… 12.5… 12.6… 12.7… 12.8… 13… 14… 15… 15.3… 16… 16.2… A… B…

B Selected IP Traffic Offload at Iu-PS |R10| p. 360

B.1 SIPTO with Traffic Offload Function p. 360

This clause describes one way to perform Selected IP Traffic Offload by the Traffic Offload Function at Iu-PS for UMTS network.

Reproduction of 3GPP TS 23.060, Fig. B.1: Selected IP Traffic Offload from Traffic Offload Function (TOF) deployed at Iu-PS

Figure B.1: Selected IP Traffic Offload from Traffic Offload Function (TOF) deployed at Iu-PS

TOF may include the following functions:

NAS and RANAP message inspection to build/remove local UE context and local session context;
Packet Inspection and Selected IP Traffic Offload enforcement;
Uplink traffic offloaded by removing GTP-U header and performing IPv4-IPv4 Network Address Translation;
Downlink traffic offloaded by reverse IPv4-IPv4 Network Address Translation and adding GTP-U header;
Charging for offloaded traffic;
LI for offloaded traffic;
Offload traffic service continuity during intra-TOF mobility;
Paging.

In this implementation example a deployment is needed that assures that all PS domain signalling from a UE goes through the same TOF instance. The TOF inspects the NAS and RANAP messages to build the local UE context and local session context. When a RAB is requested to be set up and should be offloaded, the SGSN includes the MSISDN, APN and the Charging Characteristics for the requested RAB to enable Iu-ps offload. The details of how the SGSN transfers these RANAP parameters to the TOF are described in the following clause B.2. The TOF records any necessary information e.g. the RAB ID/NSAPI, uplink TEID and downlink TEID, APN, etc. in its local context.

During the data transfer procedure, the TOF performs IPv4-IPv4 Network Address Translation for uplink offload traffic which matches the offload policies, and transparently transfers the non-offload traffic to the CN. The TOF adds the corresponding GTP-U header to the downlink offload traffic which has no GTP-U header, and then sends the downlink traffic to the RNC/HNB GW in the same way as would an SGSN.

When the TOF detects an Iu release message it could start an inactivity timer, which is longer than the RAU Timer. When this inactivity timer expires and the Iu connection is not re-established, the TOF deletes related UE context. The inactivity timer is stopped when the Iu connection is re-established for the UE.

When the TOF is configured to perform paging, the TOF pages a UE in idle mode for downlink offload traffic arriving at the TOF, and when the UE sends a Service Request message as the paging response, the TOF modifies the Service type IE in the Service Request message to indicate "Data" and sends it to the SGSN. When the TOF is configured not to perform paging, the TOF discards the received downlink offload packets for a UE in idle mode.

B.2 Support for SIPTO at Iu-ps p. 361

This clause describes the functionality that an SGSN provides if the SGSN supports the "SIPTO at Iu-ps" function. Support for the "SIPTO at Iu-ps" function is optional in the SGSN.

During the SRNS Relocation Procedures (in clauses 6.9.2.2.1, 6.9.2.2.2 and 6.9.2.2.3):

If the SGSN has valid subscriber data before it sends Relocation Request message to the target RNC, and SIPTO function should be activated for the APN of the RAB to be setup according to the subscriber data and operator policies, the SGSN shall include the MSISDN in the Relocation Request message (in step 4), and include the APN and the Charging characteristics in the RABs to be setup IE for the RAB to be offloaded to enable Iu-ps traffic offload and charging for the offload traffic.
If the SRNS Relocation is inter-SGSN and the new SGSN does not have valid subscriber data before it sends Relocation Request message to the target RNC, and SIPTO function should be activated for the APN of the RAB to be setup according to the subscriber data and operator policies, the new SGSN shall initiate a RAB assignment procedure after Routing Area Update procedure (after step 15) to enable Iu-ps offload and transfer the charging parameters to the Traffic Offload Function. The SGSN includes MSISDN in the RAB Assignment Request message, and includes the APN and the Charging characteristics in the RABs to be setup IE for the RAB to be offloaded.

During Service Request Procedures (in clauses 6.12.1 and 6.12.2):

If SIPTO function should be activated for the APN of the RAB to be setup according to the subscriber data and operator policies, the SGSN shall include the MSISDN in the RAB Assignment Request message (in step 4 of clause 6.12.1, step 6 of clause 6.12.2), and include the APN and the Charging characteristics in the RABs to be setup IE for the RAB to be offloaded to enable Iu-ps traffic offload and charging for the offload traffic.

During the intersystem change procedures from A/Gb mode to Iu mode (in clauses 6.13.1.2.1 and 6.13.2.2.1):

If SIPTO function should be activated for the APN of the RAB to be setup according to the subscriber data and operator policies, the SGSN shall include the MSISDN in the RAB Assignment Request message (step 11 of clause 6.13.1.2.1, step 20 of clause 6.13.2.2.1), and include the APN and the Charging characteristics in the RABs to be setup IE for the RAB to be offloaded to enable Iu-ps traffic offload and charging for the offload traffic.

During RAB Assignment procedure (in clause 12.7.4.1):

If SIPTO function should be activated for the APN of the RAB to be setup according to the subscriber data and operator policies, the SGSN shall include the MSISDN in the RAB Assignment Request message (step 1), and include the APN and the Charging characteristics in the RABs to be setup IE for the RAB to be offloaded to enable Iu-ps traffic offload and charging for the offload traffic.

C Link MTU considerations |R10| p. 362

According to clause 9.3 networks can provide link MTU size for MSs. A purpose of the link MTU size provisioning is to limit the size of the packets sent by the MS to avoid packet fragmentation in the backbone network between the MS and the GGSN/PGW (and/or across the (S)Gi reference point) when some of the backbone links does not support packets larger then 1500 octets. Fragmentation within the backbone network creates a significant overhead. Therefore, operators might desire to avoid it. This Annex presents an overhead calculation that can be used by operators to set the link MTU size provided by the network. A MS may not employ the provided link MTU size, e.g. when the MT and TE are separated, as discussed in clause 9.3. Therefore, providing an MTU size does not guarantee that there will be no packets larger than the provided value. However if MSs follow the provided link MTU value operators will benefit from reduced transmission overhead within backbone networks.

One of the worst case scenarios is when GTP packets, e.g., between a RAN node and the core network, are transferred over IPSec tunnel in an IPv6 deployment. In that case the user packet first encapsulated in a GTP tunnel which results the following overhead:

IPv6 header, which is 40 octets;
UDP overhead, which is 8 octets;
Extended GTP-U header, which is 16 octets.

In this scenario the GTP packet then further encapsulated to an IPSec tunnel. The actual IPSec tunnel overhead depends on the used encryption and integriry protection algorithms. TS 33.210 mandates the support of AES-CBC with a key length of 128 bits and the use of HMAC_SHA-1 for integrity protection. Therefore the overhead with those algorithms is calculated in this Annex:

IPv6 header, which is 40 octets;
IPSec Security Parameter Index and Sequence Number overhead, which is 4+4 octets;
Initialization Vector for the encryption algorithm, which is 16 octets;
Padding to make the size of the encrypted payload a multiple of 16;
Padding Length and Next Header octets (2 octets);
Integrity Check Value, which is 12 octets.

In order to make the user packet size as large as possible a padding of 0 octet is assumed. With this zero padding assumption the total overhead is 144 octets, which results a maximum user packet size of 1358 octets. Note that this user packet size will result in a 1424 octets payload length to be ciphered, which is a multiple of 16, thus the assumption that no padding is needed is correct (see Figure C.1).

Reproduction of 3GPP TS 23.060, Fig. C.1: Overhead for MTU calculation

Figure C.1: Overhead for MTU calculation

The link MTU value that can prevent fragementation in the backbone network between the MS and GGSN/PGW depends on the actual deployement. Based on the above calculation a link MTU value of 1358 is small enough in most of the network deployements.

Note that using a link MTU value smaller than necessary would decrease the efficiency in the network. Moreover a UE may also apply some tunnelling (e.g., DSMIPv6 or VPN). and it is desired to use a link MTU size that assures at least 1280 octets, which is the minimum MTU size in case of IPv6, within the UE tunnel to avoid the fragmentation of the user packets within the tunnel applied in the UE.

Another aspect of the dynamic link MTU provisioning is that in the future when all network links support larger packet sizes than 1500 octets, operators can send a value larger than 1500 octets as a link MTU size to MSs. This option is useful for operators as if an MS uses large packets then it will increase the transport efficiency in the network.