Patent Description:
Today's Mobile internet traffic traverses many Tunnels and Hops to reach the applications. This results in latency and Internet congestion.

<CIT> describes a method in a Core Network (CN) node for handling a GTP-U tunnel. When the GTP-U tunnel is to be set up, the CN node transmits a first message to a RAN gateway. The first message comprises a request for information identifying the RAN gateway. The CN node receives a second message from the RAN gateway. The second message comprises the requested information identifying the RAN gateway. The CN node determines a first endpoint node and a second endpoint node of the GTP-U tunnel. The first endpoint node is the RAN node and the second endpoint node is the RAN gateway. 3GPP Technical standard <NUM> v <NUM>. <NUM>, relates to the General Packet Radio System (GPRS) Tunnelling Protocol User Plane (GTPv1-U).

<CIT> describes a method for indicating a data transmission mode in a connection procedure in a wireless communication system, may comprise the steps of: receiving a connection request message from a terminal; transmitting an update location request message to an HSS; receiving an update location response message including the subscription information of the terminal as a response to the update location request message; the MME determining an application of a CP mode as the data transmission mode for a PDN connection on the basis of a local policy, wherein the data transmission mode includes a UP mode and the CP mode; and transmitting, to a terminal, a connection grant message including information that indicates an application of the CP mode as a response to the connection request message.

Systems, methods, and devices are disclosed for streamlining processing of mobile user traffic across a Core IP network. The described embodiments comprise a service to detect and identify a source application associated with a data traffic flow and locating a serving device associated with the source application. Once source application associated with the data traffic flow is identified a request for instantiation of a tunnel end point processor is dynamically generated and sent to the serving device. The described embodiments further comprise transferring information associated with the source application traffic to the tunnel end point processor that has been dynamically instantiated at the serving device, and forwarding data traffic associated with the source application directly to the tunnel end point processor on the serving device. The source applications may be installed on one or more mobile devices with the corresponding application end-point located on a third party service provider network. Furthermore, detection and identification of application flow may take place on an Packet Data Network Gateway device. The packet data network gateway device may also be responsible for generation of one or more requests to instantiate one or more tunnel end point processors on the application endpoint device. In some embodiments the technology involves segment routing (SRv6) tunnels established between a Packet Data Network Gateway device, such as a tunneling exchange Segment Router, and third party application host device. The segment routing (SRv6) tunnels may be terminated on one or more SRv6 endpoints dynamically instantiated on the third party application host device in response to request from the tunneling exchange Segment Router.

Mobile phone traffic traverses the internet before reaching a server's CPU/memory. This results in latency and internet congestion. Diversity and amount of traffic generated from mobile applications has significantly increased over the past few years and the trend indicates that it will continue to increase, at least in the near future. This mobile traffic is generally transported via tunnels. Tunneling operation involves encapsulation and decapsulation operations across the Core IP Network. This may increase the delay experienced on the IP network while at the same time negatively impacting packet congestion experienced on the network.

The forgoing challenge with respect to upward scaling of mobile traffic transported over an IP network is addressed through embodiments of the present technology. Some embodiments are directed at cloud-based processing to co-locate an end-point of a tunnel carrying mobile application traffic with the corresponding application server or network device serving as the application endpoint. Co-locating the tunnel end point with the corresponding network resource may be accomplished, in accordance with some embodiments, by dynamically installing a Dynamic Tunnel End Point Processor (DTEPP) on the application server designated as the end-point for the particular mobile application associated with the tunneled traffic flow. Consequently, the corresponding mobile traffic is directly tunneled to the application server and terminated at the Dynamic Tunnel End Point Processor (DTEPP) installed thereon. Thus circumventing decapsulated mobile traffic from traversing the IP network and exacerbating the congestion and delay performance of the network.

Some embodiments of the present technology describe a method involving instantiation of an application-specific tunnel encapsulation/decapsulation processor at the location of the application endpoint where the requested application service is being accessed. Once application flow is detected and source application identified (for example, by a service running on an edge node), a network service locates the corresponding application endpoint. At this point a network edge device such as the Serving Gateway and/or the PDN Gateway facilitates the installation of a tunnel endpoint processor for the mobile application traffic. Subsequently, the mobile application traffic is then directly tunneled to the specified application endpoint, which is often the server device hosting the mobile application, and directly terminated at the dynamically instantiated tunnel end-point processor installed thereon.

The Core Network (CN), also referred to as the Evolved Packet Core (EPC), is responsible for the data routing, accounting, and policy management of traffic generated by mobile user equipment (UE). The Core Network connects the radio network to the public Internet. <FIG> depicts a general Long Term Evolution (LTE) Core Network architecture <NUM>.

With reference to the Core Network Architecture <NUM> in <FIG>, User Equipment (UE), such as a mobile phone device used to access the LTE network, is connected to the EPC over the LTE base stations (eNodeB) in the radio access network. The EPC is composed of the following elements: the Mobility Management Entity (MME), the Serving Gateway (SGW), the Packet data network Packet Gateway (PDN Gateway or PGW), and the Policy and Charging Rules Function (PCRF). The MME and PCRF are pure control function entities, which manage the UE's mobility, authentication, traffic treatment policies and charging. The Serving Gateway is the anchor point of the intra-LTE (devices within the radio network) mobility and between LTE and other external access points. It logically interconnects the eNodeBs with the PDN Gateway.

The PDN Gateway serves as the demarcation point between external IP networks and the mobile operator's network (i.e., the public gateway that connects the mobile carrier to the public internet). The PDN Gateway is the termination point for all external connections, regardless of the protocol. When a mobile device is connected to the carrier network, the IP address of the device is allocated and maintained by the PDN Gateway. Because it is the PDN Gateway that terminates all connections, the device radio state is not tied to application layer connectivity: tearing down the radio context within the radio network terminates the physical radio link between the device and the radio tower, but this does not affect the state of any TCP or UDP sessions. The device radio can be idle, with no link to the local radio tower, while the established connections are maintained by the PDN Gateway. Moreover, PDN Gateway enforces Quality of Service (QoS) policies, performs lawful interception, traffic monitoring and billing, etc. The Policy and Charging Rules Function (PCRF) component is responsible for maintaining and evaluating these rules for the packet data network gateway (PDN Gateway). PCRF is a logical component, meaning it can be part of the PDN Gateway, or it can stand on its own.

When PDN Gateway receives incoming packets from the public Internet for one of the mobile devices on its network it may have no knowledge of the actual location of the user, nor the different tracking areas (collection of radio base stations) within the radio access network. This next step is the responsibility of the Serving Gateway (SGW) and the Mobility Management Entity (MME). Accordingly, the PDN Gateway routes all inbound packets to the Serving Gateway. If the Serving Gateway is not aware of the exact location of the user either, it queries the Mobility Management Entity (MME) for the required information. This function is, in fact, one of the core responsibilities of the MME. The Mobility Management Entity (MME) component is effectively a user database, which manages all the states for every user on the network: user location on the network, type of account, billing status, enabled services, in addition to all other user metadata. Whenever a user enters a different tracking area, its location is updated in the MME, but handoffs between radio base stations within the same tracking area do not trigger an update to the MME. Therefore MME may not know the exact base station (eNodeB) currently servicing the user. When the user turns on their phone, the authentication is performed by the MME.

Accordingly, if the device (UE) is idle, the MME sends a paging message to all the radio base stations in the tracking area, which in turn all broadcast a notification on a shared radio channel, indicating that the device (UE) should reestablish its radio context to receive the inbound data. The device periodically wakes to listen to the paging messages, and if it finds itself on the paging list, then it initiates the negotiation with the radio tower to reestablish the radio context.

Once the radio context is established, the base station that performed the negotiation sends a message back to the MME indicating where the user is. The MME then returns the answer to the Serving Gateway, and the Serving Gateway finally routes the message to the tower, which then delivers the message to the device. Once the device is in a connected state, a direct tunnel is established between the radio base station and the Serving Gateway (SGW), which means that further incoming packets are routed directly to the base station without the signaling overhead.

The General Packet Radio Service (GPRS) Tunneling Protocol (GTP) is used as the communication protocol to support traffic tunneling in Log Term Evolution (LTE) networks. For instance, in-between the SGW and PDN Gateway, the designated protocols are used to carry the control signaling messages and user data packets, respectively. The user data packets are carried over flows, which are bound to bearers. A bearer provides a logical transmission channel between a UE and a Packet Data Network (PDN). To ensure the transmission Quality of Service (QoS), a set of QoS parameters is associated with a bearer, indicating the properties of the transmission channel. A traffic flow passing through the network can be identified by the five-tuple of IP source and destination addresses, the port numbers of source and destination, and the Protocol Identifier (PI). Each bearer is associated with a tunnel, the endpoint of which is identified by a Tunnel Endpoint Identifier.

Once through the Service provider's ingress edge router, the traffic is encapsulated and forwarded across the IP-based infrastructure of the Core Network. Alternatively the traffic may be tunneled across the Core IP Network of the service provider and decapsulated on the interface of the provider's Edge Router that carrier the outgoing traffic to the customer site.

<FIG> illustrate example mobile core system <NUM> according to some embodiments. The example system <NUM> in <FIG> comprises a User Equipment <NUM> connected to base station/eNodeB <NUM>. eNodeB <NUM> established a connection with the Core Network/Evolved Packet core system <NUM> in order to transport user traffic to and from target destinations. The Core Network <NUM> comprises a Service Gateway <NUM> connected to a PDN Gateway <NUM>. Serving Gate way <NUM> is also in communication with Mobility Management Entity <NUM> which it queries for required user-related information. Similarly PDN Gateway <NUM> is in communication with Policy Charging Rules Function <NUM> and comprise an inline/embedded Application Detection and Control (ADC) element <NUM>.

Referring back to <FIG>, as the user starts to send traffic, the Application Detection and Control (ADC) element <NUM> of the PDN Gateway <NUM> may be augmented to send CCR-U (Credit Control Request Update request) to the Policy Charging Rules Function (PCRF) <NUM> requesting an application specific dedicated bearer (logical channel associated with a specific level of packet forwarding treatment which applies to all types of traffic mapped to particular bearer). In the implementation of the aforementioned embodiment, normal User Equipment session establishment and data flow would be unchanged. ADC element <NUM> works in conjunction with PDN Gateway <NUM> to communicates with PCRF <NUM> and identify subscriber-application traffic. In this way ADC service enable policy-based QoS and charging/control actions to be enforced on the traffic flows in real time.

In some embodiments of the present technology, the aforementioned policy-based QoS charging/control action also initiates a Dynamic Tunnel End Point Processing/Processor (DTEPP) request <NUM> that is sent, through the internet <NUM>, to the Elastic Service Controller (ESC) <NUM> of the application end-point server <NUM>. The ESC <NUM> then instantiates one or more Dynamic Tunnel End Point Processor <NUM> on the application end-point server <NUM> of the target application and inform the PDN Gateway <NUM> of the relevant information with regards to the newly created Dynamic Tunnel End Point Processor <NUM>. Once the Dynamic Tunnel End Point Processor <NUM> is ready, PDN Gateway will inform the Serving Gateway <NUM> to transfer the Tunnel Endpoint Identifiers and application specific Traffic Flow Template (TFT) to the Dynamic Tunnel End Point Processor <NUM>. Application traffic is then tunneled directly to the application end-point server via logical connection <NUM> established between boundary device of the Core Network and the particular application server.

Traffic Flow Template (TFT) is a set of information records that is used to map a Service Data Flows to a specific Radio Bearer or that allow the General Packet Radio Service (GPRS) Core Network to classify packets received from an external network into the correct Packet Data Protocol context. The new Dynamic Tunnel End Point Processor <NUM> may also establish a connection to the PCRF <NUM> to inform of billing data.

In way of an example, consider user generated request for an iTunes service. The request is detected by the PDN Gateway. The PDN Gateway initiates a request for a Dynamic Tunnel End Point Processor dispatched to ESC element of the iTunes server located in the iTunes data center. The ESC element of the iTunes server would then initiate a Dynamic Tunnel End Point Processor. Once established, the new dynamically initiated Tunnel End Point Processor on the iTunes server informs the PDN Gateway that the Tunnel End Point Processor is ready. At this point the PDN Gateway informs the Serving Gateway to transfer the user iTunes traffic over to the new Dynamic Tunnel End point Processor.

<FIG> illustrates an example flow chart <NUM> for basic operation implemented in accordance to some embodiments of the present technology. Referencing flow chart <NUM> at step <NUM> User Equipment (i.e., smart phone) established a session to the Evolved Packet Core (EPC) through a corresponding eNodeB base station. Once a connection is established, an application program is launched by the User Equipment (<NUM>). At step <NUM>, the application traffic is detected by Application Detection and Control (ADC) function provided by the EPC boundary device (PDN Gate way). At step <NUM>, the PDN gateway device locates the endpoint server of the requested application and send a request to the associated Elastic Service Controller for a Dynamic End Point Processor to be initiated on the application endpoint server. At step <NUM> The application endpoint server initiates the Tunnel End Point Processor and informs the PDN Gateway of the new tunnel endpoint processor. Accordingly, at step <NUM>, the PDN Gateway device informs the Serving Gateway of the new tunnel endpoint processor on the application endpoint server and request relevant information such as tunnel endpoint identifier and Traffic Flow Template to be transferred to the new tunnel endpoint processor. Once a direct tunnel between EPC boundary device (i.e., Serving Gateway, Packet Gateway) is established, application specific traffic is directly tunneled to the new Tunnel endpoint processor dynamically initiated on application endpoint server located on the application provider network.

The described embodiment results in colocation of mobile tunnel endpoint and the serving device/resources (i.e. Central Processing Unit - CPU, memory). Mobile traffic will then go directly to the Dynamic Tunnel End point Processor (DTEPP), and not result in decapsulated internet traffic. Therefore, embodiments of the present technology, are directed at dynamic instantiation of application specific tunnel encapsulation/decapsulation processor at the application endpoint server, amounting to on-demand per-application user plane function.

Other embodiments may involve the use of Segment Routing with IPv6 forwarding plane (SRv6) technology for dynamically instantiating a SRv6 tunnel endpoint at the servers location. Thereby, streamlining user mobile traffic directly to the location of the server processing the application data. This embodiment is described by the example illustrated in <FIG>.

<FIG> illustrate example implementation according to some embodiments. The example system <NUM> in <FIG> comprises a User Equipment <NUM> connected to base station/eNodeB <NUM>. eNodeB <NUM> established a connection with the Core Network/Evolved Packet core system <NUM> in order to transport user traffic to and from target destinations. The Core Network <NUM> comprises a Service Gateway <NUM> connected to a PDN Gateway <NUM>. Serving Gate way <NUM> is also in communication with Mobility Management Entity <NUM> which it queries for required user-related information. Similarly PDN Gateway <NUM> is in communication with Policy Charging Rules Function <NUM> and comprise an inline/embedded Application Detection and Control (ADC) element <NUM>.

As the user starts to send traffic, the Application Detection and Control (ADC) element <NUM> of the PDN Gateway <NUM> may be augmented to send CCR-U (Credit Control Request Update request) to the Policy Charging Rules Function (PCRF) <NUM> requesting an application specific dedicated bearer (logical channel associated with a specific level of packet forwarding treatment which applies to all types of traffic mapped to particular bearer). In the implementation of the aforementioned embodiment, normal User Equipment session establishment and data flow would be unchanged. ADC element <NUM> works in conjunction with PDN Gateway <NUM> to communicates with PCRF <NUM> and identify subscriber-application traffic. In this way ADC service enable policy-based QoS and charging/control actions to be enforced on the traffic flows in real time.

In some embodiments of the present technology, the PDN Gateway <NUM> also initiate a Dynamic SRv6 tunnel endpoint instance (i.e., SRv6 end. DX2 instance) request <NUM> that is sent, through the internet <NUM>, to the Elastic Service Controller (ESC) <NUM> of the application end-point server <NUM>. The ESC <NUM> then instantiates one or more SRv6 Dynamic Tunnel End Point Processor <NUM> on the application end-point server <NUM> of the target application and inform the PDN Gateway <NUM> of the Segment Identifier (SID) of the newly created Dynamic SRv6 Tunnel endpoints. Once the Dynamic Tunnel End Point Processor <NUM> is ready, PDN Gateway would inform the Tunnel exchange Segment Router <NUM> about the new endpoint. The Tunnel exchange Segment Router <NUM> then updates the SRv6 extension header with the new endpoint. Application traffic is then tunneled directly to the application end-point server via logical connection <NUM> established between tunnel exchange Segment Router <NUM> and the target application server and decrypted/decapsulated by the new dynamic SRv6 endpoint <NUM> located on the application providers network server <NUM>.

<FIG> illustrates an example flow chart <NUM> for basic operation implemented in accordance to aforementioned embodiment of the present technology. Referencing flow chart <NUM> at step <NUM> User Equipment (i.e., smart phone) established a session to the Evolved Packet Core (EPC) through a corresponding eNodeB base station. Once a connection is established, an application program is launched by the User Equipment (<NUM>). At step <NUM>, the application traffic is detected by Application Detection and Control (ADC) function provided by the EPC boundary device (PDN Gate way). At step <NUM>, the PDN gateway device locates the endpoint server of the requested application and send a request to the associated Elastic Service Controller for a Dynamic SRv6 End Point Processor (SRv6 end. DX2) to be initiated on the application endpoint server. At step <NUM>, the application endpoint server initiates the SRv6 End Point Processor and informs the PDN Gateway of the new SID of the endpoint processor. Accordingly, at step <NUM>, the PDN gateway device informs the tunnel exchange Segment Router about the new tunnel endpoint processor on the application endpoint server and request relevant information such as tunnel endpoint identifier and Traffic Flow Template to be transferred to the new tunnel endpoint processor. The tunnel exchange Segment Router accordingly updates the SRv6 extension header with the new endpoint(s). Once a direct tunnel between EPC boundary device (i.e., Serving Gateway, Packet Gateway, tunnel exchange Segment Router) is established, application specific traffic is directly tunneled to the new SRv6 endpoint processor dynamically initiated on the application server located on the application provider network.

Other embodiments of the present technology may include a network initiated switchover that causes the eNodeB to start forwarding the application specific traffic directly to the Dynamic Tunnel End point Processor (DTEPP).

Examples of computer-readable media that may be used to store instructions, information used, and/or information created during methods according to described examples include magnetic or optical disks, flash memory, Universal Serial Bus (USB) devices provided with non-volatile memory, networked storage devices, and so on.

Typical examples of such form factors include laptops, smart phones, small form factor personal computers, personal digital assistants, and so on.

Claim 1:
A computer-implemented method comprising:
detecting (<NUM>), by a Packet Data Network Gateway device, a source application associated with a data traffic flow;
locating (<NUM>), by the Packet Data Network Gateway device, an application server associated with the source application;
requesting (<NUM>), by the Packet Data Network Gateway device, a tunnel end point processor to be dynamically instantiated at the application server;
initiating, by the application server, the tunnel end point processor;
informing (<NUM>), by the application server, the Packet Data Network Gateway device of the tunnel end point processor;
informing (<NUM>), by the Packet Data Network Gateway device a Serving Gateway of the tunnel end point processor;
requesting (<NUM>), by the Packet Data Network Gateway device, that information associated with the source application data traffic flow be transferred to the tunnel end point processor; and
forwarding (<NUM>), by the Serving Gateway, the data traffic flow associated with the source application directly to the tunnel end point processor on the application server.