WO2015028058A1

WO2015028058A1 - Method, apparatus and computer program product for determining maximum segment size

Info

Publication number: WO2015028058A1
Application number: PCT/EP2013/067864
Authority: WO
Inventors: Tommy Johannes LINDGREN; Jarkko Henrikki ANSAMAA
Original assignee: Nokia Solutions And Networks Oy
Priority date: 2013-08-29
Filing date: 2013-08-29
Publication date: 2015-03-05

Abstract

A method in a radio access network comprising: determining if size information in a message being between a user equipment and an endpoint needs to be changed; and if so, changing said size information in said message.

Description

DESCRIPTION

TITLE

METHOD, APPARATUS AND COMPUTER PROGRAM PRODUCT FOR

DETERMINING MAXIMUM SEGMENT SIZE

Some embodiments relate to methods and apparatus and in particular but not exclusively to methods and apparatus for use in a radio access network.

A communication system can be seen as a facility that enables communications between two or more entities such as a communication device, e.g. mobile stations (MS) or user equipment (UE), and/or other network elements or nodes, e.g. Node B or base transceiver station (BTS), associated with the communication system. A communication system typically operates in accordance with a given standard or specification which sets out what the various entities associated with the communication system are permitted to do and how that should be achieved.

Wireless communication systems include various cellular or other mobile communication systems using radio frequencies for sending voice or data between stations, for example between a communication device and a transceiver network element. Examples of wireless communication systems may comprise public land mobile network (PLMN), such as global system for mobile communication (GSM), the general packet radio service (GPRS) and the universal mobile telecommunications system (UMTS).

A mobile communication network may logically be divided into a radio access network (RAN) and a core network (CN). The core network entities typically include various control entities and gateways for enabling communication via a number of radio access networks and also for interfacing a single communication system with one or more communication systems, such as with other wireless systems, such as a wireless Internet

Protocol (IP) network, and/or fixed line communication systems, such as a public switched telephone network (PSTN). Examples of radio access networks may comprise the UMTS terrestrial radio access network (UTRAN) and the GSM/EDGE radio access network (GERAN).

A geographical area covered by a radio access network is divided into cells defining a radio coverage provided by a transceiver network element, such as a base station or Node B. A single transceiver network element may serve a number of cells. A plurality of transceiver network elements is typically connected to a controller network element, such as a radio network controller (RNC).

A user equipment or mobile station may be provided with access to applications supported by the core network via the radio access network or to locally supported applications. According to an aspect, there is provided a method in a radio access network comprising: determining if size information in a message being between a user equipment and an endpoint needs to be changed; and if so, changing said size information in said message.

The message may be sent by the user equipment or by the endpoint.

The determining may comprise using said size information and a maximum message size which can be sent between said user equipment and a gateway to determine if said size information is to be changed.

The maximum message size may comprise a maximum transfer unit size.

The determining may comprise comparing said size information and an overhead with said maximum message size.

The size information may be reduced such that said size information and said overhead are together less than or equal to said maximum message size.

The overhead may be dependent on one or more of a protocol which is used and security.

The size information may comprise a maximum segment size.

The message may comprise a packet.

The packet may comprise a TCP packet.

The packet may comprise a SYN packet.

An apparatus may be provided to perform the method. The apparatus may be a server function and/or in a base station.

According to an aspect, there is provided an apparatus in a radio access network comprising: means for determining if size information in a message being sent between a user equipment and an endpoint needs to be changed; and if so, means for changing said size information in said message.

The determining means may be for using said size information and a maximum message size which can be sent between said user equipment and a gateway to determine if said size information is to be changed.

The maximum message size may comprise a maximum transfer unit size.

The determining means may be for comparing said size information and an overhead with said maximum message size.

The changing means may be for reducing said size information such that said size information and said overhead are together less than or equal to said maximum message size.

The overhead may be dependent on one or more of a protocol which is used and security. The size information may comprise a maximum segment size.

The message may comprise a packet.

The packet may comprise a TCP packet.

The packet may comprise a SYN packet.

According to another embodiment, there is provided an apparatus comprising at least one processor and at least one memory including computer code for one or more programs, the at least one memory and the computer code configured, with the at least one processor, to cause the apparatus at least to: determine if size information in a message being sent between a user equipment and an endpoint needs to be changed; and if so, change said size information in said message.

The at least one memory and the computer code may be configured, with the at least one processor, to use said size information and a maximum message size which can be sent between said user equipment and a gateway to determine if said size information is to be changed.

The maximum message size may comprise a maximum transfer unit size.

The at least one memory and the computer code may be configured, with the at least one processor, to compare said size information and an overhead with said maximum message size.

The size information may comprise a maximum segment size.

The message may comprise a packet.

The packet may comprise a TCP packet.

The packet may comprise a SYN packet. The apparatus may be provided in a server function and/or base station of the radio access network.

A computer program comprising program code means adapted to perform the method(s) may also be provided. The computer program may be stored and/or otherwise embodied by means of a carrier medium.

In the above, many different embodiments have been described. It should be appreciated that further embodiments may be provided by the combination of any two or more of the embodiments described above.

Various other aspects and further embodiments are also described in the following detailed description and in the attached claims Embodiments are described below, by way of example only, with reference to the accompanying drawings, in which:

Figure 1 shows a schematic general overview of a radio access network and a core network according to some embodiments;

Figure 2 shows a an example of an architecture used for some break out applications;

Figure 3 shows a radio access inline offload system architecture:

Figure 4 schematically shows inline offload architecture data flows;

Figure 5 schematically shows an arrangement of an embodiment;

Figure 6 shows a control apparatus: and

Figure 7 shows a method of an embodiment.

Embodiments may be used where there are local break out and off load solutions. This may be in the context of a 3GPP radio environment or any other suitable environment. In some embodiments, applications may be deployed to offload points using for example cloud style application deployments.

Local breakout function may provide a mechanism to serve traffic by local applications. In other words, Internet content or the like is brought to a local breakout point. There are many use cases of localization. By way of example, this may be one or more of a local content delivery network (CDN), local transparent caching, local content optimization for a mobile terminal and/or network, local hosting of other kind of services (used by mobile terminals), and local serving of machine-to-machine (M2M) terminals, for example aggregation functions or the like.

Local breakout may be applied alternatively or additionally to other types of radio networks, such as Wi-Fi, WiMax and Femto network. In such embodiments the offload may be between core network and Internet transit/peering.

Some embodiments may integrate a server module or function into the RAN (Radio Access Network). This application server function may be considered to be a RACS (Radio Applications Cloud Server). It should be appreciated that this application server function may be a cloud server or any other suitable server. The RAN may be provided by one or more entities. In some embodiments, the RAN may comprise a BTS (base transceiver station) to which an RNC (radio network controller) has been integrated or RNC in a 3G networks, or an eNB (enhanced Node B) in LTE (Long term evolution). It should be appreciated that other embodiments may alternatively or additionally be used in conjunction with any other suitable standard or system. The application server function may enable the deployment and hosting of local applications at the RAN side in a virtualization computing environment and/or the applying cloud technologies. The "leaky bearer" offload concept may be applied to gain access to the mobile bearer traffic flows. The traffic flows may be IP traffic flows. By way of example the IP traffic flows may comprise one or more of PDP (packet data protocol) context and EPS (evolved packet system) bearer.

Local breakout scenarios are specified in 3GPP release 10 under the name SIPTO (selected IP traffic offload). One of the concepts for 3G networks is the so-called "leaky bearer" traffic flow break-out, also called TOF (Traffic offload). It allows extracting or inserting IP flows of an existing mobile bearer based on activated IP flow traffic filters. This is a flexible break-out concept without involvement of or impact on the UE (user equipment). The concept provides local access to mobile bearer traffic flows and in this way is used for the deployment and execution of applications at the RAN like CDN (content delivery network) solutions, content delivery optimization, caching solutions or others. These local applications may benefit from the proximity to the radio (e.g. location awareness, lower latency) and of having access to radio information, e.g. radio cell load, location, UE's specific radio condition.

It should be appreciated that some embodiments may alternatively or additionally use different local breakout techniques other than those discussed above.

Reference is now made to Figure 1 which shows one example of a schematic architecture. In this example, an application server function 38 may be integrated at the RAN 39 level with an off load capability. The applications which may be supported by the architecture may have distributed and centralized components.

The network architecture broadly comprises a radio access side 32 and a mobile packet core 34. The radio access side comprises user equipment 1 . The user equipment are configured to communicate with a respective radio access network. In Figure 1 , first, second and third radio access networks 39 are shown. Each RAN may comprise one or more access nodes. The access nodes may comprise any suitable access node. Depending on the standard involved, the access node may be a base station such as a node B with at least some RNC functionality or an enhanced node B. The latter refers to the Long Term Evolution (LTE) of the Universal Mobile Telecommunications System (UMTS) standardised by 3GPP (Third Generation Partnership Project). A controller for the base stations may be provided. In some standards, the controller may be a radio network controller. The radio network controller is able to control the plurality of base stations. In other embodiments, a distributed control function is provided and each base station incorporates part of that control function. Each of the RAN shown in Figure 1 is provided with a server such as an application server function. The application server function 38 may be provided by a separate entity or may be integrated with one or more other entities.

The application server function may be integrated with a base station 39 having at least some RNC functionality and/or RNC or any other type of controller. It should be appreciated that other embodiments are additionally or alternatively envisaged such as where server functionality is integrated into a node of the RAN, for example the RNC or the base station having for example RNC functionality. In some embodiments, a physical realisation would be a RNC/base station plus server in a same integrated hardware. In some embodiments the physical realisation or hardware may be different. A physical realization may be different (for example an integrated one), even though the software functionality may be the same or similar, in some embodiments.

The mobile packet core 34 comprises a mobile gateway node 46 and 48. The mobile gateway 46 may be a GGSN (gateway GPRS (General Packet Radio Service) support node) and the mobile gateway 48 may be a (PDN -GW) packet data network gateway. These gateways are by way of example. One or more other types of gateway may additionally or alternatively be provided in different embodiments. Only one type of gateway may be provided in some embodiments. More than one type of gateway may be provided in other embodiments.

The mobile packet core 34 also comprises a mobile network control part 54. This part comprises SGSNs (serving GPRS Support Node) and MMEs (mobile management entities) entities 56 and 58.

In some embodiments, the mobile packet core 34 may comprise a function 60. This function may provide one or more of a lawful intercept function which allows authorised authorities to monitor communications, a policy control function and a charging control function. One or more of these functions may be provided separately and/or in different combinations.

The radio access part 32 is able to communicate with the mobile packet core via connectivity and transport function 62.

The application server function 38 may host applications, which can be accessed by subscribers via leaky bearer traffic offload. For example, a subscriber can access applications hosted by the server 38 via the offload of respective IP flows of the subscriber's mobile bearer to the corresponding application.

Reference is made to Figure 2 which shows the SIPTO system architecture. As mentioned previously, the SIPTO architecture supports the so called 'leaky bearer' traffic flow break out, also called traffic off load (TOF). Figure 2 shows a core network traffic flow. The path between the user equipment 1 and the core network 34 is defined as follows: user equipment to the node B 2 to S-GW 50 to P-GW 48. It should be appreciated that this path may be bidirectional.

Figure 2 also shows offload or SIPTO traffic. For SIPTO traffic, the path is defined as user equipment 1 to the eNodeB 2 to S-GW 50 to L-PGW (local packet gateway) 4. Again, the traffic may be bidirectional.

This concept allows extraction and/or insertion of IP flows of an existing mobile bearer based on activated IP flow traffic filters using L3 (IP Internet Protocol) and L4 header filter rules (TCP/UDP - transmission control protocol/user datagram protocol).

This may be a flexible breakout concept without involving or impacting on the user equipment. Thus, this architecture provides local access to mobile bearer traffic flows and allows for the deployment and execution of applications at the RAN. Such applications may be a CDN (content delivery network), content delivery optimisation, caching solutions and/or the like. These local applications may benefit from the proximity to the radio, for example location awareness, low latency and/or the like, having access to radio information, for example radio cell load, location, a user equipment's specific radio condition and/or the like.

Reference is now made to Figure 3 which shows a radio access in line offload system architecture and three flows associated with different applications.

The arrangement of Figure 3 is applicable to, for example, an E-UTRAN/ network

(evolved UMTS terrestrial radio access network). The off load node, that is the application server functionality 38 may sit between the eNodeB/RNC and S-GW on for example an S1 interface or may be provided between the RNC/BTS and SGSN on an lu-PS interface. These interfaces may be between the eNodeB/RNC and the S-GW/SGSN. It should be appreciated that the offload node or application server functionality can be provided in any suitable location as discussed previously.

Figure 3 shows three different traffic flow scenarios. Flow A is the case where the user equipment communicates with an application A1 located behind the SGi/Gi interface, without offloading. The SGi/Gi interface is between the P-GW/GGSN and the A1 application. In other words, the application is reached via the core network.

Flow B shows an example where the traffic flow is offloaded and the user equipment communicates with a local application A2 at the application server functionality 38. As can be seen, the path between the user equipment and the application A2 is via the eNodeB/RNC 2.

The third flow, flow C represents a hybrid case where the user equipment may communicate with the first application A1 but the traffic is routed through application A3. Application A3 is provided in the application server function. The application A3 may follow or alter the traffic flow between the user equipment and application A1. In other words, the third flow C is defined between the user equipment and the application A1 as follows: user equipment to the eNodeB/RNC 2 to application A3 provided in the local application functionality to S-GW/SGSN 50/58 to P-GW/GGSN 48/46 to the application A1.

Reference is now made to Figure 4 which shows the in-line offload architecture of figure 3 with the data flows. In order to implement offload for the second and third flows B and C, the application server functionality 38 sees all the GTP-U (GPRS (general packet radio service) tunnelling protocol) tunnelled user plane traffic of the S1 or lu-PS interface. The application server functionality 38 has an offload router that works based on L3/L4 filter rules. Prior to this, the application server functionality 38 will need to parse through outer IP, UDP and GTPU headers. The application server functionality may decide if the flow is flow A, flow B or flow C.

The user equipment has an application layer 10 and a PDCP layer (packet data convergence protocol) layer 12. The eNodeB/RNC 2 has a PDCP layer 14, a GTPU layer 16, a UDP layer 18, an IP layer 20 and a (V)LAN (virtual local area network) 22. The application server functionality in addition to the two applications A2 and A3, comprises an off load router 24, a GTPU encapsulation/decapsulation function 26, a UDP encapsulation/decapsulation function 28, an IP encapsulation/decapsulation function 30, a first VLAN 80 interfacing with the eNodeB/RNC 2 and a second VLAN 82 interfacing with the P-GW/GGSN 48/46.

The P-GW/GGSN 48/46 has a first VLAN 92, an IP layer 88, UDP layer 86, a GTPU layer 84, a second IP layer 90 and a second VLAN 94.

For all flows from the UE, the path taken is initially as follows: starting in the user equipment application layer 10 then the PDCP layer 12. Moving next to eNodeB/RNC 2, the flow is the PDCP layer 14 followed by GTPU layer 16 followed by UDP layer 18 followed by the IP layer 20 followed by the VLAN 22.

All of the flows are then proved to the application server functionality 38 and initially to the first VLAN. The path is then to the IP encapsulation/decapsulation function

30, the UDP encapsulation/decapsulation function 28, then the GTPU encapsulation/decapsulation function and the off load router 24. For each of these encapsulation/decapsulation functions, a decapsulation function will be performed. The off load router 24 will route traffic flow B to the second application A2. The offload router will route flow C to the third application A3 which is then returned from that application to the offload router 24. The offload router will route the output flow C from the third application A3 and the flow A traffic back to the GTPU encapsulation/decapsulation function 26, then the UDP encapsulation/decapsulation function 28, then the I P encapsulation/decapsulation function 30 and then to the second VLAN 82. The encapsulation/decapsulation functions from the offload router are performing encapsulation functions.

Flows A and C then follow the same path through the P-GW/GGSN 48/46. This path is the first VLAN 92, I P layer 88, UDP layer 86, GTPU layer 84, second I P layer 90 and the second VLAN 94. From there, flows A and C are routed to the application server 96 supporting the application A1 .

At a physical level, the application server functionality looks like a physical media that passes type A traffic flows through, offloads type B traffic flows and mangles type C flows.

At an Ethernet level, the application server functionality may look like an Ethernet bridge the passes type A flows through, offloads type B traffic flows and mangles type C traffic flows.

At an I P level, the application server function looks like an IP router that passes type A traffic flows through, offloads type B traffic flows and mangles type C flows. The I P level solution may provide flexibility in terms of location and connectivity of the application server function. This may allow the application server functionality to be part of the eNodeB and/or RNC or allow that application server functionality to be remote from the eNodeB and/or RNC. This may also allow one or more L2 nodes between the application server functionality and the eNodeB and/or RNC.

Data transport on the OSI Layer 2 is typically over the Ethernet. Ethernet links have a Maximum Transmission Unit (MTU) parameter defining how big a payload data unit in one Ethernet packet can be. In some arrangements, the default payload is 1500 bytes.

Links may be designed in a way that an upper layer datagram can fit to a lower layer packet payload. If the upper layer data unit can not fit in a lower layer packet, the data is fragmented over two or more packets. Fragmentation of the packet and the subsequent packet re-assembly consume considerable amount of processing power.

In a mobile network, GTP tunnelling is used for transporting user data between the Radio (eN B) 3 and Service Core (Serving Gateway),S-GW 50. This creates overhead to the user data packets.

As network operators use variable transport technologies and providers, the MTU sizes may be link specific. The user data payload size may be negotiated between the client (UE) and a server in the TCP (transmission control protocol) handshake procedure.

The client and the server are not aware of the available MTU sizes in the links between them, and thus they typically use the default MTU of 1500 bytes as a basis for negotiation (used to define maximum segment size to be used in data transfer).

Due to multiple backhaul technologies and providers, the available MTU between the eNB and Gateway differs. For some eNBs so called jumbo frames can be supported, and for other eNBs the total backhaul MTU value may be limited to default Ethernet MTU of 1500. Jumbo frames are ones which are able to contain more than 1500 bytes. In some systems, jumbo frames may be able to support up to 9000 bytes of payload. However, with the default MTU of 1500, GTP tunnelling increases the payload size which means that the end user's 1500 byte datagrams will be fragmented by the tunnelling.

Furthermore, if IPSec (Internet protocol security) is used on the backhaul, a single 1500 payload packet may be fragmented a plurality of times. The packet may first be fragmented on the Gateway in order to fit GTP tunnelling overhead, and then the fragmented packets are in turn fragmented by a security gateway due to IPsec tunnelling overhead.

Fragmentation and re-assembly may have a performance impact on the elements at the link end points.

Path MTU discovery is specified by IETF (Internet Engineering Task Force) for adjusting payload datagrams to fit available links without fragmentation. However path MTU discovery may not work in the Internet e.g. due to firewalls dropping the ICMP (Internet control message protocol) messages or because the server has switched ICMP off.

Maximum Segment Size (MSS) control is a method for manipulating the TCP handshake between the client and server, in order to limit the payload packet size. This is can be for example implemented in a GGSN/PGW) using Policy and Charging Control (PCC rules). The PCC rules identify the TCP handshake using Shallow Packet Inspection (SPI), and change the MSS value on the fly. Approximately every eighth TCP packet go to this process. Changing the MSS value is network wide and not link specific, as having link specific values in the Gateway may not be processing efficient and/or may result in configuration complexities.

A MTU control mechanism is suggested by 3GPP Rel10 or Rel1 1 . However, this solution is also only suitable for network wide control and is not used to control UE packet sizes on a per eNB basis. In some embodiments, each eNB is aware of its link capabilities. The application server function allows the eNB to manipulate user traffic.

Some embodiments provide MSS tweaking or control in the eNB using the application server function. The link capabilities may be automatically inherited by application server function monitoring the TCP handshake procedures. The TCP handshake is between the UE and a server in the IP network behind the PGW (e.g. in the Internet). The link MTU should be available in the eNB and the application server function may be able to get this information from the eNB. The MTU is manually configured in some embodiments and the same value may also be manually configured in the application server function in some embodiments.

Should the UE and server negotiate a higher MSS than would be supported by the link, the application server function overwrites the MSS value on the fly. The application server function re-writes the MSS value. For example if the application server function knows that the link MTU is 1500B and notices that the MSS value is 1460B in handshake between the UE and the server, the application server function can overwrite the MSS value to 1420B so that GTP overhead fits in the MTU without need for fragmentation.

The backhaul capabilities may be fully utilized while preventing unnecessary fragmentation and packet re-assembly in some embodiments..

Some embodiments make it possible to control the UE payload datagrams on a per eNB basis.

In some embodiments, MSS control may only be used at those eNBs that cannot support jumbo frames (where MSS control is not needed). This may lead in some embodiments to an improved backhaul utilization without the need to consume processing power on packet fragmentation and re-assembly.

In some scenarios, 95% of operator traffic is TCP based and as UDP (user datagram protocol) traffic very rarely uses large packet size, MSS control may effectively mitigates issues caused by fragmentation.

Some embodiments may be implemented by an application in the application server function and/or as part of the eNB.

Some backhaul technology may limit the MTU to 1500B. Some UE's may use hard coded values for the MTU which may for example be a global parameter for Ethernet interfaces. The MTU may typically be set to 1500B. When creating TCP connections from the terminal, this MTU value of 1500 B is used as basis for the MSS value (MTU minus TCP and IP header overhead of 40B) so the payload packet typically fills the whole 1500B frame (1460 bytes of data and 40 bytes of header). When adding GTP tunnel overhead between eNB and SGW (and between SGW and PGW) the MTU should be e.g. 1540 Bytes (for 40 additional bytes of GTP over IPv4 transport). In practice there are many different variations possible because of the possibility to use either IPv4 or IPv6 as transport protocol under GTP, and it is possible to use IPsec to secure the backhaul.

If GTP packets are tunnel mode Internet Protocol security (IPsec) protected between a RAN node and the core network and IPv6 is deployed, the user plane packet is encapsulated in a GTP tunnel, which results in 64 octets of GTP overhead made up of 40 octets of IPv6 header, 8 octets of UDP header and 16 octets of extended GTP-U header. The GTP packet is further encapsulated into an IPsec tunnel which adds a further overhead dependent on the security protocol etc used. The additional IPSec overhead may be 78 octets

Reference is made to Figure 5 which schematically illustrates some embodiments and Figure 7 shows a method flow. A eNB or application server function associated with a first backhaul, Backhaul # 1 knows that the available MTU for this backhaul link is 1500. The application server function will use MTU information as well as information as to whether IPv4 or IPv6 is used as transport protocol and if IPsec is used or not. The application server is able to determine what the MSS value should be to avoid fragmentation when GTP and optionally IPSec is added. The eNB or application server function associated with a second backhaul, backhaul #2 supports jumbo frames so no changes will need to be made to the MSS value.

This MTU information may be obtained automatically from eNB configuration, or the available MTU may be configured by the operator O&M when enabling the MSS control application.

In step S1 , the UE send a MSS value in a TCP packet. The packet is destined to a server behind a PGW's SGi interface, e.g. a web server from Google) and is intercepted by the application server function. The packet may be a SYN packet or any other suitable packet.

In step S2, the application server function will look at the MSS value in the packet and see if it will exceed the MTU value of the backhaul connection once the tunneling and optionally the security overhead has been added.

In step S3, the application server will change the MSS value if the MTU value is exceeded.

For example the UE sends a packet with MSS 1460 and the application server function changes this MSS value to 1420 to be able to fit 40 bytes of GTP overhead to the packet without need to fragment the packet into two.

In step S4, the MSS value is unchanged if the MTU value is not exceed. In step S5, the server uses the received MSS value. For example if the server receives the MSS value of 1420, this is used as the upper limit when sending data towards the UE. Thus all downlink data within this TCP connection has a 1460 B payload (1420 B TCP segment + 20 B TCP header + 20 B IP header) leaving room for the PGW and SGW to add a GTP header within the available 1500B MTU.

The application server function thus monitors all SYN packets going through the eNB and change the value to suitable MSS to avoid exceeding the maximum MSS value possible from the backhaul perspective.

Embodiments may be used for modifying messages from a UE to a destination or for modifying messages from an endpoint to a UE.

It should be appreciated that reference has been made to particular protocols, TCP, IPv4, IPv6 and IPSec. It should be appreciated that this is by way of example only and alternative embodiments may use alternative and/or additional protocols.

Figure 6 shows an example of a control apparatus. The control apparatus 300 comprises at least one memory 301 , at least one data processing unit and an input/output interface 304. In the apparatus shown in Figure 6, two processing units 302 and 303 are shown. However in some embodiments, one of these data processing units may be omitted. In other embodiments, more than two processing units may be provided. In the embodiment of Figure 6, one memory is shown. Some embodiments may be provided with more than one memory. Via the interface the control apparatus can be coupled to a receiver and/or transmit data. For example the control apparatus 300 can be configured to execute an appropriate software code to provide the control functions. It should be appreciated that this control apparatus may be provided in the application server functionality and/or the eNode B.

An appropriately adapted computer program code product or products may be used for implementing some embodiments, when loaded on an appropriate data processing apparatus. The program code product for providing the operation may be stored on, provided and embodied by means of an appropriate carrier medium. An appropriate computer program can be embodied on a computer readable record medium. A possibility is to download the program code product via a data network. In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Embodiments may thus be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate. It is also noted herein that while the above describes exemplifying embodiments of the invention, there are several variations and modifications which may be made to the disclosed solution without departing from the scope of the present invention.

Claims

Claims:

1. A method in a radio access network comprising:

determining if size information in a message being between a user equipment and an endpoint needs to be changed; and

if so, changing said size information in said message.

2. A method as claimed in claim 1 , wherein said determining comprising using said size information and a maximum message size which can be sent between said user equipment and a gateway to determine if said size information is to be changed.

3. A method as claimed in claim 2, wherein said maximum message size comprises a maximum transfer unit size.

4. A method as claimed in claim 2 or 3, wherein said determining comprises comparing said size information and an overhead with said maximum message size.

5. A method as claimed in claim 4, wherein said size information is reduced such that said size information and said overhead are together less than or equal to said maximum message size.

6. A method as claimed in claim 4 or 5, wherein said overhead is dependent on one or more of a protocol which is used and security.

7. A method as claimed in any preceding claim, wherein said size information comprises a maximum segment size.

8. A method as claimed in any preceding claim, wherein said message comprises a packet.

9. A method as claimed in claim 8, wherein said packet comprises a TCP packet.

10. A method as claimed in claim 8 or 9, wherein said packet comprises a SYN packet.

1 1 . A computer program product comprising computer executable instruction which when run perform the method of any one of the preceding claims.

12. An apparatus comprising at least one processor and at least one memory including computer code for one or more programs, the at least one memory and the computer code configured, with the at least one processor, to cause the apparatus at least to: determine if size information in a message being sent between a user equipment and an endpoint needs to be changed; and if so, change said size information in said message.

13. An apparatus as claimed in claim 12, wherein the at least one memory and the computer code are configured, with the at least one processor, to use said size information and a maximum message size which can be sent between said user equipment and a gateway to determine if said size information is to be changed.

14. An apparatus as claimed in claim 13, wherein the maximum message size comprises a maximum transfer unit size.

15. An apparatus as claim 13 or 14, wherein the at least one memory and the computer code are configured, with the at least one processor, to compare said size information and an overhead with said maximum message size.

16. An apparatus as claimed in claim 15, wherein the size information is reduced such that said size information and said overhead are together less than or equal to said maximum message size.

17. An apparatus as claimed in claim 15 or 16, wherein the overhead is dependent on one or more of a protocol which is used and security.

18. An apparatus as claimed in any of claims 12 to 17, wherein the size information may comprise a maximum segment size.

19. An apparatus as claimed in any of claims 12 to 18, wherein the message comprises a packet.

20. An apparatus as claimed in claim 19, wherein the packet comprises a TCP packet.

21 . Ann apparatus as claimed in claim 19 or 20, wherein the packet may comprises a SYN packet.