WO2015028058A1 - Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale - Google Patents

Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale Download PDF

Info

Publication number
WO2015028058A1
WO2015028058A1 PCT/EP2013/067864 EP2013067864W WO2015028058A1 WO 2015028058 A1 WO2015028058 A1 WO 2015028058A1 EP 2013067864 W EP2013067864 W EP 2013067864W WO 2015028058 A1 WO2015028058 A1 WO 2015028058A1
Authority
WO
WIPO (PCT)
Prior art keywords
size
packet
size information
message
maximum
Prior art date
Application number
PCT/EP2013/067864
Other languages
English (en)
Inventor
Tommy Johannes LINDGREN
Jarkko Henrikki ANSAMAA
Original Assignee
Nokia Solutions And Networks Oy
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nokia Solutions And Networks Oy filed Critical Nokia Solutions And Networks Oy
Priority to PCT/EP2013/067864 priority Critical patent/WO2015028058A1/fr
Publication of WO2015028058A1 publication Critical patent/WO2015028058A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/36—Flow control; Congestion control by determining packet size, e.g. maximum transfer unit [MTU]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/19—Flow control; Congestion control at layers above the network layer
    • H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related

Definitions

  • 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 device e.g. mobile stations (MS) or user equipment (UE)
  • UE user equipment
  • BTS base transceiver station
  • 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.
  • 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).
  • PLMN public land mobile network
  • GSM global system for mobile communication
  • GPRS general packet radio service
  • UMTS universal mobile telecommunications system
  • 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
  • radio access networks may comprise the UMTS terrestrial radio access network (UTRAN) and the GSM/EDGE radio access network (GERAN).
  • UTRAN UMTS terrestrial radio access network
  • GERAN GSM/EDGE radio access network
  • 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).
  • RNC radio network controller
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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
  • FIG. 3 shows a radio access inline offload system architecture
  • FIG. 4 schematically shows inline offload architecture data flows
  • Figure 5 schematically shows an arrangement of an embodiment
  • Figure 6 shows a control apparatus
  • 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.
  • Internet content or the like is brought to a local breakout point.
  • localization 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.
  • CDN local content delivery network
  • M2M machine-to-machine
  • Local breakout may be applied alternatively or additionally to other types of radio networks, such as Wi-Fi, WiMax and Femto network.
  • the offload may be between core network and Internet transit/peering.
  • the RAN may be provided by one or more entities.
  • 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.
  • the IP traffic flows may comprise one or more of PDP (packet data protocol) context and EPS (evolved packet system) bearer.
  • 3GPP release 10 under the name SIPTO (selected IP traffic offload).
  • 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.
  • radio e.g. location awareness, lower latency
  • FIG. 1 shows one example of a schematic architecture.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • GGSN gatewayway GPRS (General Packet Radio Service) support node
  • PDN -GW packet data network gateway
  • 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.
  • SGSNs serving GPRS Support Node
  • MMEs mobile management entities
  • 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.
  • 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.
  • FIG. 2 shows the SIPTO system architecture.
  • 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.
  • 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).
  • L3 IP Internet Protocol
  • L4 header filter rules TCP/UDP - transmission control protocol/user datagram protocol
  • 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.
  • CDN content delivery network
  • 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.
  • FIG. 3 shows a radio access in line offload system architecture and three flows associated with different applications.
  • 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.
  • FIG. 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.
  • 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.
  • 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.
  • FIG. 4 shows the in-line offload architecture of figure 3 with the data flows.
  • 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.
  • 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.
  • the UDP encapsulation/decapsulation function 28 then the GTPU encapsulation/decapsulation function and the off load router 24.
  • 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.
  • 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.
  • 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.
  • 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.
  • Ethernet links have a Maximum Transmission Unit (MTU) parameter defining how big a payload data unit in one Ethernet packet can be.
  • MTU Maximum Transmission Unit
  • 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.
  • 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.
  • 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).
  • the available MTU between the eNB and Gateway differs.
  • jumbo frames are ones which are able to contain more than 1500 bytes.
  • jumbo frames may be able to support up to 9000 bytes of payload.
  • GTP tunnelling increases the payload size which means that the end user's 1500 byte datagrams will be fragmented by the tunnelling.
  • IPSec Internet protocol security
  • 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.
  • 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.
  • ICMP Internet control message protocol
  • 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).
  • 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 .
  • this solution is also only suitable for network wide control and is not used to control UE packet sizes on a per eNB basis.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • MTU MTU minus TCP and IP header overhead of 40B
  • the MTU should be e.g. 1540 Bytes (for 40 additional bytes of GTP over IPv4 transport).
  • IPv4 or IPv6 transport protocol under GTP, and it is possible to use IPsec to secure the backhaul.
  • GTP packets are tunnel mode Internet Protocol security (IPsec) protected between a RAN node and the core network and IPv6 is deployed
  • IPsec Internet Protocol security
  • 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
  • FIG. 5 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.
  • 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.
  • 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.
  • step S3 the application server will change the MSS value if the MTU value is exceeded.
  • 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.
  • step S4 the MSS value is unchanged if the MTU value is not exceed.
  • 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.
  • FIG. 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.
  • 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.
  • one memory is shown. Some embodiments may be provided with more than one memory.
  • the control apparatus Via the interface the control apparatus can be coupled to a receiver and/or transmit data.
  • 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.
  • 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.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé dans un réseau d'accès radioélectrique consistant: à déterminer si des informations de taille dans un message entre un équipement utilisateur et un point d'extrémité doivent être modifiées; et le cas échéant, à modifier lesdites informations de taille dans ledit message.
PCT/EP2013/067864 2013-08-29 2013-08-29 Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale WO2015028058A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2013/067864 WO2015028058A1 (fr) 2013-08-29 2013-08-29 Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2013/067864 WO2015028058A1 (fr) 2013-08-29 2013-08-29 Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale

Publications (1)

Publication Number Publication Date
WO2015028058A1 true WO2015028058A1 (fr) 2015-03-05

Family

ID=49111178

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2013/067864 WO2015028058A1 (fr) 2013-08-29 2013-08-29 Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale

Country Status (1)

Country Link
WO (1) WO2015028058A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016190641A1 (fr) * 2015-05-22 2016-12-01 엘지전자(주) Procédé d'émission et de réception de données dans un système de communication sans fil et dispositif associé
DE102019125799A1 (de) * 2019-09-25 2021-03-25 Deutsche Telekom Ag Vermeidung der IP-Datenfragmentierung für TCP beim internationalen Datenroaming
CN114390121A (zh) * 2022-01-12 2022-04-22 深圳艾灵网络有限公司 数据传输方法、装置、设备及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006050753A1 (fr) * 2004-11-15 2006-05-18 Telefonaktiebolaget Lm Ericsson (Publ) Procede de modification de la taille maximale de segment
US20080101382A1 (en) * 2006-10-26 2008-05-01 Bannerjee Dwip N Efficient method for discovering path mtu for tcp connections
US20130155856A1 (en) * 2011-12-15 2013-06-20 Telefonaktiebolaget L M Ericsson (Publ) Method and Network Node For Handling TCP Traffic

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006050753A1 (fr) * 2004-11-15 2006-05-18 Telefonaktiebolaget Lm Ericsson (Publ) Procede de modification de la taille maximale de segment
US20080101382A1 (en) * 2006-10-26 2008-05-01 Bannerjee Dwip N Efficient method for discovering path mtu for tcp connections
US20130155856A1 (en) * 2011-12-15 2013-06-20 Telefonaktiebolaget L M Ericsson (Publ) Method and Network Node For Handling TCP Traffic

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016190641A1 (fr) * 2015-05-22 2016-12-01 엘지전자(주) Procédé d'émission et de réception de données dans un système de communication sans fil et dispositif associé
US10321358B2 (en) 2015-05-22 2019-06-11 Lg Electronics Inc. Method for transmitting and receiving data in wireless communication system, and device therefor
DE102019125799A1 (de) * 2019-09-25 2021-03-25 Deutsche Telekom Ag Vermeidung der IP-Datenfragmentierung für TCP beim internationalen Datenroaming
DE102019125799B4 (de) 2019-09-25 2023-08-17 Deutsche Telekom Ag Vermeidung der IP-Datenfragmentierung für TCP beim internationalen Datenroaming
CN114390121A (zh) * 2022-01-12 2022-04-22 深圳艾灵网络有限公司 数据传输方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
US10588044B2 (en) System and method for offloading data in a communication system
US11595300B2 (en) Traffic shaping and end-to-end prioritization
US9614656B2 (en) Providing in-line services through radio access network resources under control of a mobile packet core in a network environment
JP6087444B2 (ja) ソフトウェアで定義されたネットワークオーバーレイ
US10798638B2 (en) Apparatus and method for controller and slice-based security gateway for 5G
US9565553B2 (en) Localizing a mobile data path in a radio access network under control of a mobile packet core in a network environment
US10511640B2 (en) Providing cellular-specific transport layer service by way of cell-site proxying in a network environment
EP2811779A1 (fr) Système, équipement d'utilisateur et procédé pour la mise en uvre d'une transmission conjointe sur une pluralité de réseaux
EP2987278B1 (fr) Procédé et commutateur pour interception légale
EP3571815A1 (fr) Système et procédé pour faciliter des opérations de passerelle de desserte sans état dans un environnement de réseau
US8676159B1 (en) Mobile network interoperability
WO2015028058A1 (fr) Procédé, appareil produit programme d'ordinateur pour déterminer une taille de segment maximale
WO2017084688A1 (fr) Procédé permettant d'améliorer l'acheminement de paquets de données
EP3340532B1 (fr) Procédé, dispositif, et système de traitement de service

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13756436

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13756436

Country of ref document: EP

Kind code of ref document: A1