Method and arrangement in a telecommunication system

DETAILED DESCRIPTION

As mentioned above, the MTU path, that is, the path between the application server and the UE, as shown, for example, in Figure 1, can be affected by numerous impacts including:

- Uncompressed header of the original IP packets (that is, end-to-end user);

- The Sl-U tunneling protocol (GTP-U);

- IPSec Tunnel (Security Association (SA) of Encapsulation Safety Payload (ESP) in tunnel mode) for protection of integrity and confidentiality in the access network between security connection points (SEG);

- An MTU provided by the data link layer in a particular instance of the S1 interface;

- An MTU imposed on a particular administrative domain (and QoS) of the IP network;

The version of the Internet Protocol used (that is, IPv4 or IPv6).

Aspects described in some of the problems above could introduce a variable MTU path, primarily due to user mobility. Another source of the variable MTU path may be link failures and subsequent re-routing over the IP network.

Furthermore, it is very likely that the SAE / LTE network will have the shortest MTU on the end-to-end path.

Every link on the IP network has a defined MTU, and so does the link that is used by the Main Computer IP in the UE. It has been observed to be a problem how to configure an MTU link in the UE. Generally any reasonable default value that is updated with the discovery of the MTU path could be used initially. However, it should be noted that there are a number of configurations / implementations (for example, protection barriers / connection points) that discard the number of IPv4 ICMP messages including the “Too Big Packet” message type. Hence, it can be assumed that end-to-end MTU path discovery is not used in the case of IPv4. This can in turn lead to fragmentation in the network and all the problems associated with such fragmentation. Fragmentation in the case of an array as illustrated in Figure 1 can occur at different levels, including end-to-end datagram fragmentation, Sl-U datagram fragmentation, IPSec tunnel datagram fragmentation.

If the SAE / LTE nodes are made aware of the MTU supported in the SAE / LTE network, the network is enabled to configure the MTU link in the EU in such a way that fragmentation in the SAE / LTE network can be avoided or at least significantly reduced . If this MTU is available for the main computer in the UE, the stack in the UE is able to provide the following behavior to reduce the need for fragmentation on the network:

In the case of a transport layer protocol that has a Maximum Segment Size (MSS), for example, TCP, both transmit and receive MSS can be selected by the UE, considering the MTU “link” configured by the network and, hence, the fragmentation can be avoided at all or at least in the SAE / LTE network domain.

In the case of a transport layer protocol that does not have a Maximum Segment Size (MSS), for example, UDP, the UE can fragment the datagram transmitted at the source according to the MTU “link” configured by the network and, from there, fragmentation can be avoided at least in the direction of the uplink.

In accordance with the present invention, the MTU supported by the SAE / LTE network is signaled to the UE.

The following describes by means of non-exclusive examples, different realizations for signaling the MTU link.

According to a first realization, the MTU link is signaled in a Non-Access Stratum (NAS) message from the Mobility Management Entity (MME). As the signaled MTU link conceptually represents the MTU supported by the SAE support service, and this is explicitly expressed. The NAS signaling for establishing and modifying SAE support is illustrated in Figure 2. Hence, firstly, in a 201 message, a No Access layer (NAS) message from the Mobility Management Entity (MME) including a Support Configuration / Modification Request SAE and the MTU link. In response to message 201, the UE transmits a NAS 203 message acknowledging that the SAE Support Configuration / Modification is completed.

In accordance with an embodiment of the present invention, the MME signals in the NAS SAE support configuration / modification request message (or a similar message) signal the MTU link that can represent a one-way MTU to an SAE support service in a complete network or part of a private SAE / LTE network. The signaled MTU link can, for example, be set to the highest value supported by the SAE / LTE network in such a way that the network does not need to perform EP fragmentation of the original end-to-end datagram or any of the tunneling (nested) datagrams encapsulating the end-to-end datagram. Once the UE receives the MTU link for a particular SAE support in the establishment or modification of the SAE support, the UE can apply the signaled MTU link for the particular SAE support.

According to another embodiment of the present invention, the MTU link is signaled in a radio Resource Control (RRC) message from the Evolved Node B (eNB). The signaled MTU link can, for example, be part of the procedure for establishing / modifying the radio support and can then only implicitly represent the MTU supported by the SAE support service.

The RRC signaling for establishing and re-configuring the radio support is illustrated in Figure 3. According to an embodiment of the present invention, the eNB signals in the Radio RRC 301 support configuration / re-configuration request message (or a similar message ) the MTU link that can implicitly represent an MTU of a path to SAE support service in a complete network or in a part of a private SAE / LTE network as known to an eNB. The signaled MTU link can, for example, be set to the highest value supported by the SAE / LTE network, such that the network does not have to perform IP fragmentation of the original end-to-end datagram or any of the tunneling datagrams ( nested) encapsulating the end-to-end datagram. Once the UE receives the MTU link for a particular radio support in the establishment or re-configuration of the Radio support, the UE is preferably set to apply the signaled MTU link to the particular SAE support. Also, in response to message 303, the UE acknowledges that Radio Support Configuration / Reconfiguration is completed.

When configuring an MTU domain in SGW and eNB, the MTU link is also a property of the administrative domain to which the link belongs. This will typically result in the least capable link defining the MTU for the entire domain. In addition, it can be assumed that very short MTU-s are not used in modern IP networks. Therefore, the minimum MTU link of Sl-U (X2-U) can generally be assumed to be around 1500 octets less the applicable overhead. According to an embodiment of the present invention, eNB-s having x2 interfaces defined between them, are adjusted to belong to the same administrative domain as an IP network. Similarly, the corresponding Sl-U instances in the UPE are preferably part of the same administrative domain.

Furthermore, in order to avoid small variations in the MTU that can result in worse performance, in the sense of gaining a few octets for the specific link, it is preferable to configure the MTU of the administrative domain for each corresponding link in the eNB and UPE. One reason to configure the MTU of the administrative domain for each corresponding link in eNB and SGW is because a “too large packet” functionality can be implemented in eNB and UPE as described below.

There are three methods of fragmentation:

End-to-end IP packet fragmentation: this option is possible only in the case of IPv4 and only if the “do not fragment” (DF) bit has not been set. However, there are a number of implementations that effect fragmentation even if the DF bit has been set. Fragmentation when the DF bit has been set is, for example, used a few times to overcome the limitations for performing MTU path discovery on IPv4 networks.

The benefit of using end-to-end packet fragmentation, regardless of the DF bit setting as described above, is that reassembly is pushed to the main computers at the end and hence the network resources are not spent on reassembly. This is only applicable if SGW and eNB are configured with the MTU link that corresponds to the MTU path Sl-U (X2-U) or if the MTU path discovery is used in Sl-U (X2-U). Additionally, the main computers terminating the end-to-end flow can perform fragmentation / reassembly by themselves, according to the MTU link configured for the link associated with the main computers.

Fragmentation of tunneling IP packets Sl-U (X2-U): If fragmentation is a solution used to process “too large packets”, then fragmentation of tunneling IP packets Sl-U (X2-U) is a preferred option if the end-to-end flow is IPv6 flow. This can also be applied in the case of end-to-end IPv4 flows. Furthermore, fragmentation can be left to the node that interfaces a link with the lowest MTU on the Sl-U path (X2-U) in the case of the IPv4 path on the Sl-U (X2-U). In the case that Sl-U (X2-U) is an IPv6 path, then fragmentation can be performed by eNB / SGW. However, it should be noted that most of the processing and memory intensive process is reassembly and this is therefore done in eNB / SGW and for a very large number of flows.

IPSec tunneling IP packet fragmentation: the principle is almost the same as for IP tunneling fragmentation Sl-U (X2-U). However, a difference is that reassembly has to be carried out at a safety connection point (SEG) while fragmentation can be carried out at the node that interfaces with a link with the lowest MTU on the path Sl-U (X2-U) , in the case of IPSec IPv4 tunnel, while this has to be done by SEG in the case of the IPSec IPv6 tunnel.

Furthermore, the MTU discovery can be divided into different types of MTU discovery, namely: end-to-end MTU path discovery, SlU U (X2-U) MTU path discovery and MTU SEG to SEG discovery.

For end-to-end MTU path discovery, IP primary computers terminating the end-to-end IP flow can perform MTU Path discovery. However, it should be noted that there are a number of configurations / implementations (protection barriers / connection points) that discard the number of IPv4 ICMP messages including “Too Big Packet” messages. Hence, it can be assumed that end-to-end MTU path discovery is not used in the case of IPv4.

On the other hand, in the case of IPv6, main computers have the two options of using 1280 octet MTU (that is, the minimum MTU that each IPvó capable node has to support) or using end-to-end MTU path discovery. Considering the problem related to the discovery of MTU path to TCP, it is preferable to apply MTU path Sl-U (X2-U) common in the complete administrative domain of eNB-s anyway, in order to avoid changing the MTU path from end to end due to mobility. It should be noted that, if common MTU is not applied in the administrative domain of eNB-s, then time restrictions allowed for increasing MTU, effectively disable the gains of “variable” MTU in the administrative domain, as pass-through transfers are of varying magnitudes more frequently.

For MTU Sl-U (X2-U) path discovery, eNB and SGW can use MTU path discovery instead of administratively configured MTU Sl-U (X2-U) path. As Sl-U (X2-U) are defined for accredited networks, it can be assumed that the operator has direct or indirect control over the processing of ICMP messages and hence MTU path discovery can be used regardless of the IP version used for tunneling Sl-U (X2-U).

For MTU SEG discovery SEG to SEG, SEG can use MTU path discovery instead of administratively configured MTU tunnel. However, it can only be used in the case of the IPv6 IPSec tunnel, as it cannot rely on ICMP "Too Big Packet" messages in the case of the IPv4 tunnel.

The eNB can be configured with the MTU link according to the MTU of the administrative domain to which it belongs. Furthermore, it should be considered that the MME is aware of the MTU link configured in the eNB. If that MTU were available to the main computer in the UE, the IP stack in the UE can provide the following behavior, which significantly reduces the need for network fragmentation.

In the case of a transport layer protocol that has an MSS, for example, TCP, both transmit and receive MSS can be selected by the UE, considering the MTU “link” configured by the network and hence, fragmentation can be avoided together (or at least in the SAE / LTE network domain). In the case of a transport layer protocoilo that does not have an MSS, for example, UDP, the UE can fragment the datagram transmitted at the source according to the MTU “link” configured by the network and hence, fragmentation can be avoided at least towards the upper link.

Considering the gains provided by the configuration of the MTU “link” in the UE according to the MTU of the administrative domain to which the eNB belongs, as far as the SAE support is established for the UE, it is recommended to provide functionality to configure the MTU “link” in the establishment / modification of SAE support (for example, included in NAS: establishment / modification of SAE support) according to the MTU Sl-U path known to MME for the respective eNB.