Source: https://patents.google.com/patent/US20120082132A1/en
Timestamp: 2018-09-22 08:07:29
Document Index: 662522384

Matched Legal Cases: ['art 200', 'art 300', 'art 400', 'art 500', 'art 600', 'art 700', 'art 800']

US20120082132A1 - System and method for offloading data in a communication system - Google Patents
System and method for offloading data in a communication system Download PDF
US20120082132A1
US20120082132A1 US13179538 US201113179538A US2012082132A1 US 20120082132 A1 US20120082132 A1 US 20120082132A1 US 13179538 US13179538 US 13179538 US 201113179538 A US201113179538 A US 201113179538A US 2012082132 A1 US2012082132 A1 US 2012082132A1
US13179538
US9031038B2 (en )
A method is provided in one example embodiment and includes receiving a data packet over a first link at a first network element; establishing an out-of-band channel over a second link between the first network element and a second network element; and receiving instructions at the first network element to offload the data packet from the first link. In more particular embodiments, the first network element is a mobile enabled router, and the second network element is a gateway general packet radio service support node or a packet data network gateway. The method can also include receiving a discovery message from the second network element, the discovery message triggering the establishment of the out-of-band channel. In certain cases, the data packet is offloaded based on a type of data in the data packet.
DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview Discovery
Turning to FIG. 1, FIG. 1 is a simplified block diagram of an example embodiment of a communication system 10, which can be associated with a mobile wireless network in a particular implementation. The example architecture of FIG. 1 includes multiple instances of user equipment (UE) 12 a-c: each of which may connect wirelessly to a respective eNode B (eNB) 14 a-c. Each eNB 14 a-c may be coupled to a mobility enabled router (MER) 50 a-c, which can be tasked with providing offload functionalities for the architecture, as discussed herein. Note that the broad term ‘offload’ as used herein in this Specification is used to characterize any suitable change in routing, path management, traffic management, or any other adjustment that would affect packet propagation. This can further involve any type of re-routing, directing, managing, hop designation, adjustment, modification, or changes to a given routing path (at any appropriate time).
MERs 50 a-c can be connected to an Ethernet backhaul 18 in certain non-limiting implementations. Communication system 10 can also include various network elements 22 a-f, which can be used to exchange packets in a network environment. As illustrated in this example implementation, the architecture of communication system 10 can be logically broken into a cell site segment, a mobile telephone switching office (MTSO) segment, a regional sites segment, and a mobile data center (DC) segment. A default path 60 generally indicates the default routing path for traffic propagating in communication system 10.
Note that user equipment 12 a-c can be associated with clients, customers, or end users wishing to initiate a communication in system 10 via some network. In one particular example, user equipment 12 a-c reflects devices configured to generate wireless network traffic. The term ‘endpoint’ and ‘end-station’ are included within the broad term user equipment, as used herein. User equipment 12 a-c can include devices used to initiate a communication, such as a computer, a personal digital assistant (PDA), a laptop or electronic notebook, a cellular telephone, an iPhone, a Blackberry, an Android, a smartphone, a tablet, an iPad, an IP phone, or any other device, component, element, equipment, or object capable of initiating voice, audio, video, media, or data exchanges within communication system 10. User equipment 12 a-c may also include a suitable interface to the human user, such as a microphone, a display, or a keyboard or other terminal equipment. User equipment 12 a-c may also be any device that seeks to initiate a communication on behalf of another entity or element, such as a program, a database, or any other component, device, element, or object capable of initiating an exchange within communication system 10. Data, as used herein in this document, refers to any type of numeric, voice, video, media, or script data, or any type of source or object code, or any other suitable information in any appropriate format that may be communicated from one point to another.
Control plane packets commonly include packets that are generated by a network element (e.g., a router or a switch), as well as packets received by the network that may be used for the creation and operation of the network itself. Control plane packets may have a receive destination IP address. Protocols that “glue” a network together, such as address resolution protocol (ARP), border gateway protocol (BGP), and open shortest path first (OSPF), often use control plane packets. In a mobile network, the control plane may be responsible for session management, call setup support requirements, interfacing with external servers (e.g., querying for per-user policy and control information), managing high availability for a gateway, and configuring and managing the data plane. Packet overloads on an IP router's control plane can inhibit the routing processes and, as a result, degrade network service levels and user productivity, as well as deny specific users or groups of users' service entirely.
In typical cellular networks, mobile traffic is sent over the Radio Access Network to eNBs 14 a-c (or a Node B (UMTS)). From there, mobile traffic is further processed by mobile packet network elements, (e.g., RNC/SGSN/gateway GPRS support node (GGSN) (UMTS) or MME/SGW/packet data network gateway (PGW) (LTE/EPC).) Throughout the cellular network, there are many more eNBs than mobile packet elements and, hence, cellular traffic should be backhauled from the cell site to the mobile packet core elements. There are different backhaul network technologies available; however, backhaul network technologies differ in terms of speeds, feeds, costs, and quality. RAN Backhaul (from the cell site) is relatively expensive but relatively cheaper connections from the cell site will often not come with the necessary Service Level Agreements (SLAs), etc.
Once an endpoint becomes dormant, the GTP-U tunnel associated with the endpoint (e.g., end user 12 a) may disappear, and subsequently be reestablished with a different TEID. Similarly, TEIDs may be reused after some time interval. Therefore, the MERs (upstream and downstream) may maintain an inactivity timer used to detect potentially stale TEIDs. The inactivity timer may be preset based on the time it would take for an endpoint (and thus a GTP-U tunnel) to be deemed dormant. In addition, the MERs may check for TEIDs being assigned to another endpoint prior to expiration of the inactivity timer. If the inactivity timer has expired, or if a TEID has been assigned to another endpoint, then the discovery procedure can be triggered again to determine the new TEID.
Turning to FIG. 2A, FIG. 2A is a simplified block diagram illustrating one possible set of details associated with communication system 10. FIG. 2A includes handset 12 a and MER 50 a. FIG. 2A further includes cell sites 30 a-c, a radio network controller (RNC) 32, a serving general packet radio service (GPRS) support node/serving gateway (SGSN/S-GW) 34, routers 52, and GGSN/PGW 54. In a particular embodiment, GGSN/PGW 54 is a MER-CA, which includes the control agent functions being discussed herein.
In general terms, cell sites 30 a-c are a site where antennas and electronic communications equipment are used (e.g., provisioned on a radio mast or tower) to create a cell in communication system 10. Routers 52 may be enhanced and converted to MERs. (MER 50 a and MER 50 b are an enhanced version of a router 52 deployed in communication system 10.) The elements shown in FIG. 2A may couple to one another through simple interfaces (as illustrated) or through any other suitable connection (wired or wireless), which provides a viable pathway for network communications. Additionally, any one or more of these elements may be combined or removed from the architecture based on particular configuration needs.
In a particular embodiment, handset 12 a communicates data to one or more cell sites 30 a-c. From cell sites 30 a-c, the data propagates to either RNC 32, which communicates the data to MER 50 a, or directly to MER 50 a. The data is communicated from MER 50 a to a core network 56 (e.g., an IP or a multiprotocol label switching (MPLS) network) through SGSN/SGW 34, routers 52 and 52 b, and GGSN/PGW 54 on default path 60. Operationally, MER 50 a may be configured to breakout the data (or a packet of data) and communicate the data to a destination that is not on default path 60. For example, MER 50 a may communicate the data to Internet 58 using a breakout path 106.
Note that data may travel on default path 60 in various manners. For example, in a particular embodiment, communication system 10 may include a GPRS core network. The GPRS core network transmits IP packets to external networks such as core network 56 and, further, provides mobility management, session management, and transport for Internet Protocol packet services in GSM and WCDMA networks. The GPRS core network may also provide support for other additional functions such as billing and lawful interception. The GPRS core network may use tunneling to allow UE 12 a to be moved from place to place, while continuing to be connected to communication system 10. In a particular embodiment, the tunneling is created using a GPRS tunneling protocol. The protocol allows end users (or users of UE 12 a) to move, while continuing to connect as if from one location (e.g., at GGSN/PGW 54) by carrying the end user's data from the SGSN to the GGSN/PGW tasked with handling the subscriber's session.
Typically, when data from UE 12 a is initially communicated to communication system 10, a first upstream tunnel and second downstream tunnel are created from RNC 32, through MER 50 a, to SGSN 34. In addition, a second upstream tunnel and a first downstream tunnel are created from SGSN 34 to GGSN 54. Each tunnel can have a unique TEID/source IP address.
RNC 32 may be configured as a governing element in a universal mobile telecommunications system (UMTS) (one of the third-generation (3G) mobile telecommunications technologies, also being developed into a 4G technology) or in a radio access network universal terrestrial radio access network (UTRAN), and can be responsible for controlling any node B (e.g., eNBs 14 a-c that are connected to RNC 32). [Note that node B (eNB 14 a-c) is a term used in UMTS, and is generally equivalent to the base transceiver station (BTS) description used in GSM, and, further, reflects the hardware that is connected to the mobile phone network that communicates directly with mobile handsets.]
RNC 32 can carry out radio resource management, mobility management functions, and may be the point where encryption (if any) is performed before data is sent to (and from) UE 12 a. RNC 32 communicates the data to MER 50 a. MER 50 a may route some or all of the data to SGSN/SGW 34 along default path 60 and, further, may route some or all of the data to a destination other than SGSN/SGW 34 on breakout path 106. [Note that this includes using breakout path 106 to allow MER 50 a to directly communicate with GGSN/PGW (e.g., using a GRE tunnel) as is described below.] In a particular embodiment, there is more than one breakout path 106 and the number of breakout paths 106 may depend on the networks or elements in communication with MER 50 a.
GGSN/PGW 54 may be a component of a GPRS network and reflects the anchor point, which affords mobility to UE 12 a in communication system 10 (e.g., the GPRS/UMTS networks.) GGSN/PGW 54 maintains the routing used to tunnel protocol data units (PDUs) to the SGSN/PGW (e.g., SGSN/SGW 34), which services UE 12 a. GGSN/PGW 54 is the tunnel endpoint for a GGSN/PGW specific GTP-tunnel. GGSN/PGW 54 can be (indirectly) selected by the end user at setup of a packet data protocol (PDP) context. From an addressing perspective, GGSN/PGW 54 represents the point of presence for ‘logged on’ end users (i.e., end users with an established PDP-context). Addresses can be dynamically assigned (fetched from an external server or a pool of owned addresses) or statically assigned. GGSN/PGW 54 may be configured to perform functions such as tunnel management, IP address management, charging data collection/output, security management, packet filtering, packet routing/tunneling, QoS management, and element management (particularly MER 50 a management).
GGSN/PGW 54 may be configured for the interworking between elements of communication system 10 and external packet switched networks (e.g., like core network 56). From a network external to communication system 10, GGSN/PGW 54 can appear as a router to a sub-network, because GGSN/PGW 54 may “hide” the infrastructure of communication system 10 from the external network. In a particular embodiment, GGSN/PGW 54 can determine if a specific user (UE 12 a) is active when GGSN/PGW 54 receives data addressed to the specific user. If the specific user is active, GGSN/PGW 54 can forward the received data to SGSN/SGW 34 serving the specific user. However, if the specific user is inactive, then the data may be discarded. In a particular embodiment, mobile-originated packets are routed to the correct network by GGSN/PGW 54.
GGSN/PGW 54 can convert the GPRS packets (propagating from SGSN/SGW 34) into the appropriate packet data protocol (PDP) format (e.g., IP or X.25), and then communicate the packets on a corresponding packet data network. In the other direction, PDP addresses of incoming data packets can be mapped to a particular GTP tunnel and then sent on that GTP tunnel (towards SGSN/SGW 34, or, if a direct tunnel is used in 3G, the data packets may be sent to RNC 32. The readdressed packets are sent to the responsible SGSN/SGW 34. For this purpose, GGSN/PGW 54 may store the current SGSN/SGW 34 address and profile of the user in a location register. GGSN/PGW 54 can be responsible for IP address assignment and may be the default router for the connected specific user (UE 12 a). GGSN/PGW 54 may also perform authentication and billing/charging functions. Other functions include subscriber screening, IP Pool management and address mapping, QoS, and PDP context enforcement.
An out-of-band channel 73 can be used by GGSN/PGW 54 and MER 50 a to communicate data without having to send the data on default path 60. By not using default path 60, the data may be on a path with different attributes (e.g., a more reliable and redundant path or a less expensive, lower quality path, etc.) than default path 60. In addition, the data being communicated between GGSN/PGW 54 and MER 50 a does not add to the traffic already on default path 60. Using out-of-band channel 73, GGSN/PGW 54 can control MER 50 a and can communicate offload instructions and other information (such as configuration parameters) to MER 50 a.
Turning to FIG. 2B, FIG. 2B is a simplified flowchart 200 illustrating one potential operation associated with the present disclosure. In 202, a data packet is communicated to a MER from a UE. For example, UE 12 a may communicate a data packet to MER 50 a. In 204, based on instructions from a GGSN/PGW, the MER determines if the data packet should be offloaded from a default path. If the MER determines that the data packet should not be offloaded, then the data packet can continue along a default path, as illustrated in 206. For example, the data packet may continue along default path 60. If the MER determines that the data packet should be offloaded, then the data packet can be offloaded from the default path, as illustrated in 208. For example, MER 50 may offload the data packet from default path 60 using breakout path 106 and, subsequently, communicate the data packet to Internet 58.
Turning to FIG. 3A, FIG. 3A is a simplified block diagram illustrating one possible set of details associated with communication system 10. FIG. 3A includes handset 12 a, (e)NB 14 a, RNC 32, MER 50 a, SGSN/SGW 34, and GGSN/PGW 54. MER 50 a includes a respective processor 64 a, a traffic offload module 66, and a respective memory element 68 a. GGSN/PGW 54 includes a respective processor 64 b, a MER control module 74, and a respective memory element 68 b. A first upstream tunnel 76 connects RNC 32 to SGSN/SGW 34 through MER 50. A second upstream tunnel 78 connects SGSN/SGW 34 to GGSN/PGW 54. Second upstream tunnel 78 may propagate through a router (e.g., router 52 shown in FIG. 2A) or a MER similar to MER 50 a but located further upstream (for example, if router 52 was configured to be MER 50 b).
In a particular embodiment, MER 50 a is located at the borders between networks/network segments. While MER 50 a may be almost any enhanced network element in communication system 10, the closer that MER 50 a is to UE 12 a, the earlier MER 50 a can offload traffic from default path 60. A first downstream tunnel 80 can connect GGSN/PGW 54 to SGSN/SGW 34. A second downstream tunnel 82 can connect SGSN/SGW 34 to RNC 32 through MER 50 a. Second upstream tunnel 78 and first downstream tunnel 80 may couple through a router (e.g., router 52 shown in FIG. 2A) or a MER similar to MER 50 b shown in FIG. 2A.
GGSN/PGW 54 can use MER control module 74 to control MER 50 a and enable MER 50 a to perform user-plane functions for both packet and circuit mode communication, particularly offloading traffic from the core network (e.g., default path 60). MER 50 a uses traffic offload module to perform the user-plane functions and, further, offload traffic as instructed by GGSN/PGW 54. MER 50 a may also be configured to handle media processing (e.g., speech coding. conference call bridging etc), media generation of tones etc., setup and release of user data bearers, provision of traffic/charging info for packet mode communication, security management, routing and switching QoS management, and element management.
Out-of-band channel 73 is a separate signaling channel established between MER 50 a and GGSN/PGW 54. Out-of-band signaling 72 references communication between MER 50 a and GGSN/PGW 54 that does not occur over default path 60. In-band signaling 70 references communication between MER 50 a and GGSN/PGW 54 (and other elements) using default path 60. In a particular embodiment, the out-of-band signaling 72 association is M:N meaning that any GGSN/PGW 54 may control several MERs, and any MER may be controlled by several GGSNs/PGWs 54. Out-of-band channel 73 is used to establish a GRE tunnel 84 between MER 50 a and GGSN/PGW 54. GRE tunnel 84 is used to loopback traffic to MER 50 a during handovers and discovery procedures and, further, may be used to communicate data to GGSN/PGW 54 that cannot be processed or serviced by MER 50 a. Buffering of user traffic during these procedures can be performed on either GGSN/PGW 54 or MER 50 a or both (implementation dependent).
First upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 can be part of default path 60. In addition first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 may be GTP-U tunnels and each may have a unique TEID/source IP address. Initially, MER 50 a does not know the TEID for first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 and, therefore, cannot control UE 12 a's traffic without knowing the TEIDs for first upstream tunnel 76 and second downstream tunnel 82. Using out-of-band channel 73 and TEID discovery procedure, GGSN/PGW 54 communicates the TEID for first upstream tunnel 76 and second downstream tunnel 82 such that MER 50 a knows which UE's traffic is to be controlled and how the UE's traffic should be controlled (e.g., if any traffic from UE 12 a should be offloaded).
GGSN/PGW 54 does not actually know the TEIDs (unless a direct tunnel has been created). Hence, GGSN/PGW 54 relies on MER 50 a to perform TEID discovery and communicate the TEIDs to GGSN/PGW 54 (this may be indirectly through a GTP-U tunneled path). GGSN/PGW 54 in turn, sends a packet back towards MER 50 a thereby enabling download TEID discovery, as well as determining if the upstream TEID (GTP-U tunnel) really was to be off-loaded in the first place (e.g. overlapping IP-addresses could cause a false trigger in the MER). Once TEID discovery is done, GGSN/PGW 54 and MER 50 a can communicate directly (e.g. through GRE tunnel 84) and exchange information about what traffic needs to be off-loaded based on the TEID information exchanged.
Once MER 50 a knows the TEID of first upstream tunnel 76 and second downstream tunnel 82, traffic can be offloaded from default path 60, and when the traffic for UE 12 a is returned, MER 50 a can communicate the data in the returned traffic to UE 12 a. In a particular embodiment, if data is returned to MER 50 a and the returned data needs to propagate through GGSN/PGW 54, then MER 50 a can communicate that data to GGSN/PGW 54 using GRE tunnel 84. GGSN/PGW 54 may similarly return the data to MER 50 a using GRE tunnel 84 or using first downstream tunnel 80.
Turning to FIG. 3B, FIG. 3B is a simplified flowchart 300 illustrating one potential operation associated with the present disclosure. In 302, a data packet can be sent from user equipment requesting a connection to the mobile network. For example, a data packet may be sent from UE 12 a to RNC 32. In 304, GTP-U tunnels are established. For example, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 may be established. In 306, an out-of-band channel is established between a MER and a GGSN. For example, out-of-band channel 73 may be established between MER 50 a and GGSN/PGW 54. In 308, using the out-of-band channel, the MER can receive data packet offload information from the GGSN. For example, GGSN/PGW 54 may communicate data packet offload information (including TEIDs) to MER 50 a using out of channel band 73.
Turning to FIG. 4A, FIG. 4A is a simplified block diagram of communication system 10, which (in this particular implementation) may include UE 12 a, cell site 30 a-d, RNCs 32 a-g, MER 50 a-c, SGSN/SGW 34 a-c, and GGSN/PGW 54 a-c. When UE 12 a attaches to the mobile network and requests connection through control plane messages, several GTP-U (user plane) tunnels may be established, (for example, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 may be established on default path 60). The user plane data packet may propagate through one of cell sites 30 a-d (e.g., cell site 30 d) and through one of RNC 32 a-g (e.g., RNC 32 e). The data packet can travel through first upstream tunnel 76 to MER 50 b. In a particular embodiment, at MER 50 b, a MER identifier is added to a new data packet (in-band message) using the same tunnel identifier as the received user data and the new data packet is communicated to SGSN/SGW 34 b and on to GGSN/PGW 54 a via second upstream tunnel 78. The MER identifier may be an identifier that identifies MER 50 b and informs GGSN/PGW 54 a that MER 50 b is not just a router, but has been enhanced and configured to behave as a MER.
GGSN/PGW 54 a sends a MER discovery message (which can be triggered by the first upstream packet arriving at GGSN/PGW 54 a or immediately after first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 are established) to SGSN/SGW 34 b via first downstream tunnel 80. The MER discovery message travels from SGSN/SGW 34 b to MER 50 b via second downstream tunnel 82. Typically, the message would pass through MER 50 b and onto RNC 32 e; however, MER 50 b intercepts the MER discovery message and establishes out-of-band channel 73 with GGSN/PGW 54 a. By establishing out-of-band channel 73 between MER 50 b and GGSN/PGW 54 a, GGSN/PGW 54 a can control MER 50 b and, further, can communicate offload instructions and other information (such as configuration parameters) for MER 50 b.
While it is possible to manually configure static associations of each MER with RNCs/SGSNs, such a paradigm can be error-prone, lack flexibility, present management issues, and failed to work in many deployment scenarios. In a particular embodiment, each GGSN/PGW 54 a in communication system 10 may be configured to discover which MER in the network is currently forwarding the traffic from/to a specific UE (e.g., UE 12 a), send session control instructions to the discovered MER related to the required treatment of the specific UE's traffic, discover when the specific UE moves from one MER to another (e.g., in a handover scenario), and send control information to the new MER.
In one particular embodiment, a MER identifier is not added to the data packet by MER 50 b. Usage of in-band signaling (not shown) can allow GGSN/PGW 54 a to embed discovery messages in the GTP-U tunnels that were already established for a specific UE. For example, after GGSN/PGW 54 a first receives the data from UE 12 a, GGSN/PGW 54 a can send the discovery message to MER 50 b using first downstream tunnel 80 and second downstream tunnel 82.
Because the discovery message can follow the same path as UE's 12 a traffic, if a MER is present in the path, the MER can always be discovered without prior configurations. No special procedures would be required on other network nodes to pass through such traffic. Interception and interpretation of the embedded messages within these discovery messages can be performed at the MER. Note that such messages are not forwarded to end users (end points) in particular implementations of the present disclosure. Because of the establishment of direct/secure signaling channels between MERs and because control of GGSN/PGWs occurs without prior configurations, the MER discovery procedure is dynamic in nature, does not require manual associations, and operates in a multitude of deployment scenarios.
Dynamic discovery of MER 50 b is enabled by passing IP addresses/ports and protocols, supported by GGSN/PGW 54 a within the in-band discovery message. Further, when UE's 12 a traffic moves from one MER to another MER (e.g., traffic is moved from MER 50 b to MER 50 a), the new MER (MER 50 a) initially forwards such traffic to GGSN/PGW 54 a since it does not yet have instructions from GGSN/PGW 54 a regarding UE's 12 a traffic. Upon receiving the traffic from the new MER (MER 50 a), the GGSN/PGW 54 a is triggered to initiate another MER discovery procedure in which GGSN/PGW 54 a discovers the new MER (MER 50 a) and instructs the new MER to perform the appropriate handling. During the MER discovery procedure, UE's 12 a traffic in the upstream direction, if any, can be buffered at either the new MER or GGSN/PGW 54 a or both (i.e., it can be implementation dependent). The MER discovery procedure can be used in both direct tunnel (DT) and non-DT cases.
Turning to FIG. 4B, FIG. 4B is a simplified flowchart 400 illustrating one potential operation associated with the present disclosure. In 402, a subscriber attaches to a network and requests a connection. For example, a subscriber may use UE 12 a to attach to communication system 10 and request a connection with cell site 30 d. In 404, GPRS-U tunnels are established for the subscriber's traffic. For example, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 may be established on default path 60 for UE's 12 a traffic. In 406, GGSN sends (to a MER) a discovery message via the GPRS tunnels. For example, GGSN/PGW 54 a may send MER 50 b a discovery message using first downstream tunnel 80, and second downstream tunnel 82.
In 408, the mobile enabled router intercepts the discovery message. For example, MER 50 b may intercept the MER discovery message sent from GGSN/PGW 54 a. In 410, the MER can establish a direct communication channel (out-of-band channel) with the GGSN. For example, MER 50 b may establish out-of-band channel 73 with GGSN/PGW 54 a. In 412, the MER identifies itself to the GGSN, confirms receipt of the discovery request, and obtains session control instructions and other configuration parameters. For example, using out-of-band channel 73, MER 50 b may be configured to identify itself to GGSN/PGW 54 a, confirm receipt of the discovery request, and obtain session control instructions and other configuration parameters from GGSN/PGW 54 a.
Turning to FIG. 5A, FIG. 5A is a simplified block diagram of communication system 10, which (in this particular implementation) may include UE 12 a, cell sites 30 a-d, RNCs 32 a-g, MER 50 a-c, SGSN/SGW 34 a-c, and GGSN/PGW 54 a-c. In most deployment scenarios, multiple GTP-U tunnels can be established for the same subscriber's traffic. For example, first upstream tunnel 76 (UL-TEID-1) and second downstream tunnel 82 (DL-TEID-2) can be established between SGSN/SGW 34 b and RNC 32 e, and second upstream tunnel 78 (UL-TEID-3) and first downstream tunnel 80 (DL-TEID-4) can be established between SGSN/SGW 34 b and GGSN/PGW 54 a.
GGSN/PGW 54 a can identify the TEID for second upstream tunnel 78 (UL-TEID-3) and first downstream tunnel 80 (DL-TEID-4). Depending on the scenario, MER 50 b may know only the TEID for first upstream tunnel 76 (UL-TEID-1) and second downstream tunnel 82 (DL-TEID-2), or MER 50 b may not know any TEIDs. Thus, if GGSN/PGW 54 a attempts to instruct MER 50 b about the treatment of UE's 12 a traffic, there is no simple common reference. Furthermore, the inner IP address assigned to UE 12 a is not unique either (i.e., it cannot be used as a common reference), because overlapping IP address support is commonly required. Hence, a TEID discovery procedure needs to be employed to discover the TEID of first upstream tunnel 76 (UL-TEID-1), second downstream tunnel 82 (DL-TEID-2), second upstream tunnel 78 (UL-TEID-3), and first downstream tunnel 80 (DL-TEID-4) and the bindings of these tunnels to UE 12 a.
In a particular embodiment, when a data packet is first sent from UE 12 a through communication system 10, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, and second downstream tunnel 82 may be established (e.g., on default path 60). The data packet can be communicated to cell site 30 d and to RNC 32 e. Using first upstream tunnel 76, from RNC 32 e, the packet can be communicated to SGSN/SGW 34 b, through MER 50 b. Using second upstream tunnel 78, from SGSN/SGW 34 b, the data packet can also be communicated to GGSN/PGW 54 a.
GGSN/PGW 54 a can receive the data packet and, in response, communicate a MER discovery message to SGSN/SGW 34 b using first downstream tunnel 80. Using the second download link tunnel 82, SGSN/SGW 34 b communicates the MER discovery message to MER 50 b. Typically, the message would pass through MER 50 b and onto RNC 32 e; however, MER 50 b can intercept the MER discovery message and establish out-of-band channel 73 with GGSN/PGW 54 a, if one does not yet exist. By establishing out-of-band channel 73 between MER 50 b and GGSN/PGW 54 a, GGSN/PGW 54 a can control MER 50 b and, further, communicate offload instructions and other information (such as configuration parameters) to MER 50 b.
In order to be able to control the traffic of a specific UE (e.g., UE 12 a), each GGSN/PGW 54 a in communication system 10 can be configured to discover which MER in the network is currently forwarding the traffic from/to that UE (e.g., because GGSN/PGW 54 a received traffic from UE 12 a, and GGSN/PGW 54 a has the intelligence to discover the particular MER that is handling the traffic for UE 12 a). In addition, each GGSN/PGW 54 a in communication system 10 can be configured to send session control instructions to the discovered MER related to the required treatment of the UE's traffic and, further, discover when the UE moves from one MER to another (as in a handover scenario) and subsequently send control information to the new MER.
In a particular embodiment, MER 50 b sends an in-band message (GTP-U packet) in first upstream tunnel 76 in an attempt to discover the associated TEIDs of first upstream tunnel 76 (TEIDs-1-4 bindings in this example). Within the in-band message, UL-TEID-1 is embedded in the payload and the type of message is set to loopback. When the in-band message arrives at SGSN/SGW 34 b, SGSN/SGW 34 b can treat the packet as any other user packet and change the TEID to match the TEID of the second upstream tunnel 78 (TEID-3, in this example), and pass the packet to the appropriate GGSN/PGW 54 a. (Note that the contents of the embedded payload are not necessarily modified by SGSN/SGW 34 b, just the outer tunnel could be modified.)
When the in-band message arrives at GGSN/PGW 54 a, GGSN/PGW 54 a can intercept (i.e., receive) the in-band message and form the requested loopback function based on the embedded message type. If the MER did not include such information in the message, as is applicable to certain deployment cases, GGSN/PGW 54 a may add TEID-¾ mapping to the payload of an in-band loopback packet (the loopback response to the in-band message) before performing the loopback. GGSN/PGW 54 a can communicate the in-band loopback packet to SGSN/SGW 34 b on first downstream tunnel 80. Using second downstream tunnel 82, SGSN/SGW 34 b can communicate the in-band loopback packet to RNC 32 e.
When the in-band loopback packet arrives at MER 50 b, on the way to RNC 32 e, MER 50 b intercepts and interprets the embedded message, which may include the TEIDs bindings (as well as other parameters, such as the assigned IP address to UE 12 a and GGSN/PGW 54 a). At this juncture, MER 50 b understands which UE's 12 a traffic is to be controlled and is ready to implement whatever policies the GGSN/PGW 54 a may dictate related to traffic from UE 12 a. In one particular embodiment, MER 50 b may also establish out-of-band channel 73 with GGSN/PGW 54 a.
Turning to FIG. 5B, FIG. 5B is a simplified flowchart 500 illustrating one potential operation associated with the present disclosure. In 502, a MER sends an in-band message packet in a tunnel that the MER is attempting to discover. In a particular embodiment, a TEID can be embedded in the payload of the packet, where the message is set to loopback. For example, MER 50 b may send an in-band message packet on first upstream tunnel 76, and the TEID (UL-TEID-1) can be embedded in the payload of the packet. (The message can be embedded in the payload such that a GGSN/PGW would be able to determine the TEID of first upstream tunnel 76.)
In 504, when the packet arrives at an SGSN, the SGSN treats the packet as any other UE packet by changing the TEID and communicating the packet to an appropriate GGSN. (Note that the contents of the embedded payload are not modified by the SGSN, simply the outer tunnel is modified.) For example, SGSN/SGW 34 b may change the outer tunnel TEID from UL-TEID-1 to UL-TEID-3 and communicate the packet to GGSN/PGW 54 a. In 506, when the packet arrives at the GGSN, the GGSN intercepts and interprets the in-band message packet. For example, when the packet arrives at GGSN/PGW 54 a, GGSN/PGW 54 a intercepts and interprets the in-band message packet.
In 508, the GGSN can add TEID bindings (as well as other parameters such as the assigned IP address of the UE) and perform the requested loopback function. In a particular embodiment, the GGSN may add TEID-3/4 mapping to the payload of the message (if the MER did not include such information in the message) before performing the loopback. In 510, the GGSN can communicate the loopback packet to the appropriate SGSN, which forwards it to an appropriate RNC. For example, using first downstream tunnel 80, GGSN/PGW 54 a may communicate the in-band loopback packet to SGSN/SGW 34 b and SGSN/SGW 34 b may communicate the in-band loopback packet to RNC 32 e. In 512, when the loopback packet arrives at the MER (in route to the RNC), the MER intercepts and interprets the embedded message, which may include the TEIDs bindings (as well as other parameters, such as the assigned IP address to the subscriber). At this point, MER 50 b understands which UE's 12 a traffic is to be controlled, and is ready to enforce policies being dictated (e.g., by GGSN/PGW 54 a) for UE's 12 a traffic.
In a particular embodiment, the TEID discovery procedure described above may be repeated when the TEIDs at MER 50 b become stale due to inactivity/timeout, or when TEID conflicts are detected (such as the same TEID is reused by another subscriber after UE 12 a has become dormant). The TEID discovery procedure may not be needed in the case of DT deployments in which just one pair of TEIDs can be used, where both the GGSN/PGW 54 a and MER 50 b identify the same pair. The TEID discovery procedure can be used with non-DT deployments.
Turning to FIG. 6A, FIG. 6A is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, cell site 30 a, MER 50 a, MER 50 b, RNC 32, SGSN/SGW 34 a, GGSN/PGW 54 a, and a data transmission network 62. MER 50 a can be in communication with GGSN/PGW 54 a through out-of-band signaling channel 73 a. MER 50 b can be in communication with GGSN/PGW 54 a through out-of-band signaling channel 73 b. In one particular embodiment, data transmission network 62 may include service provider digital subscriber line (DSL) network 114, fiber to the x (FTTx) network 116 (which is a generic term for any broadband network architecture that uses optical fiber in last-mile), Ethernet network 118, and a synchronous optical networking/synchronous digital hierarchy (SONET/SDM) network 120. Each network in data transmission network 62 may have a cost-to-quality ratio, where the cost of using the network is related to the quality of the network.
In a particular embodiment, certain classes of traffic are defined such that low quality traffic propagates over one network (for example, data may be sent over a low quality network such as DSL network 114) while high quality traffic propagates over another network (for example, a voice call may be sent over a high quality network such as SONET/SDM network 120). Traffic may be sent over a path based on a variety of factors such as a type or level of service purchased by a user, the type of data, the current amount of traffic on a specific network, etc. Because both MER 50 a and MER 50 b should know which type of data should be sent on a network, GGSN/PGW 54 a should send a discovery message to MER 50 a and MER 50 b in order to establish communications with MER 50 a and MER 50 b. The discovery process is similar to the discovery process described above except, both MER 50 a and 50 b should be discovered. When the discovery message reaches MER 50 b, MER 50 b communicates the discovery message to MER 50 a. After receiving the discovery message MER 50 a establishes out-of-band channel 73 a with GGSN/PGW 54 a and MER 50 b establishes out-of-band channel 73 b with GGSN/PGW 54 a and each identifies themselves to GGSN/PGW 54 a.
For example, once a user session has been established using UE 12 a, and traffic for that session is a candidate for selective backhaul link routing, GGSN/PGW 54 a can identify the upstream MER (MER 50 a) and the downstream MER (MER 50 b). To identify MER 50 a and MER 50 b, GGSN/PGW 54 a can use a downstream MER discovery procedure, whereby GGSN/PGW 54 a sends an in-band discovery message towards UE 12 a. The in-band discover message is communicated along default path 60 to MER 50 b (pre-agg/agg router), as well as to MER 50 a (cell site router, provided there is one cell site router per cell site (which is normally the case)).
Both MER 50 a and MER 50 b can identify themselves to GGSN/PGW 54 a and establish out-of-band channels 73 a and 73 b respectively. Out-of-band channel 73 a can be used by GGSN/PGW 54 a to instruct MER 50 a about which upstream traffic should be sent over which link. Out-of-band channel 73 b can be used by GGSN/PGW 54 a to instruct MER 50 b about which downstream traffic should be sent over which link. In addition, in a particular embodiment, MER 50 b is identified, and a GRE tunnel (e.g., GRE tunnel 84 (not shown)) is created between MER 50 b and GGSN/PGW 54 a.
In a particular embodiment, MER 50 a and/or MER 50 b may communicate to GGSN/PGW 54 a about specific links available. GGSN/PGW 54 a can then specify which links to use for particular types of traffic. In another particular embodiment, GGSN/PGW 54 a can simply communicate predefined classes of traffic to MER 50 a and MER 50 b. MER 50 a and/or MER 50 b can then map those classes of traffic to suitable backhaul links available (e.g., “low quality Internet,” “high quality TDM,” etc.).
In one particular embodiment, MER 50 a can establish a backhaul link selection for the upstream traffic. To achieve the backhaul link selection, MER 50 a can perform upstream TEID discovery as described above (except, because end user traffic is not necessarily broken out, but rather just backhauled differently, there is no new IP address and associated NAT bindings being established). [Note that this makes the overall scheme somewhat simpler than a general MER and TEID discovery procedure (including handover), since routing (backhaul) paths can be changed on the fly without affecting an established session (in contrast to the anchor breakout described in the general MER solution).]
Once the signaling described above has been completed, downstream traffic for a particular session may be communicated over different paths by the pre-agg/agg MER (MER 50 b), in accordance with the instructions provided by GGSN/PGW 54 a. Similarly, upstream traffic may be communicated over different upstream paths by the cell site MER (MER 50 a), in accordance with instructions provided by GGSN/PGW 54 a. By routing traffic across an appropriate network, an acceptable cost-to-quality ratio may be achieved for the architecture.
Turning to FIG. 6B, FIG. 6B is a simplified flowchart 600 illustrating one potential operation associated with the present disclosure. In 602, a MER receives network traffic. For example, MER 50 a may receive traffic from cell site 30 a. In 604, the MER can determine which type of traffic was received. In 606, the MER determines which type of network may be used to communicate the traffic and, subsequently, communicates the traffic using the determined network. For example, MER 50 a may determine that the traffic is data traffic and that DSL network 114 can be used to communicate the traffic. MER 50 a may then communicate the traffic over DSL network 114.
Turning to FIG. 7A, FIG. 7A is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, cell sites 30 a-d, RNCs 32 a-g, MERs 50 a-c, SGSN/SGWs 34 a-c, and GGSN/PGWs 54 a-c. First, upstream tunnel 76 and first downstream tunnel 82 connects RNC 32 e with SGSN/SGW 34 b. Second, upstream tunnel 78 and second downstream tunnel 80 connects SGSN/SGW 34 b with GGSN/PGW 54 a.
Mobile terminals often shift to dormant mode to save power. Note that the term ‘dormant’ as used herein in this Specification encompasses any type of staleness characteristic, timeout, timing parameter expiration, or any other suitable characteristic that would be indicative of some type of dormancy. During dormancy events, the assigned first upstream tunnel 76 and first downstream tunnel 82 between RNC 32 e and SGSN/SGW 34 b can be released. The first upstream tunnel 76 and first downstream tunnel 82 may be reassigned to other subscribers. In certain deployment scenarios, specifically when direct tunneling is employed, GGSN/PGW 54 a can become aware of such events and instruct MER 50 b accordingly. However, in a general deployment case, it is possible that neither GGSN/PGW 54 a nor MER 50 b know that the first upstream tunnel 76 and first downstream tunnel 82 have been released (and possibly reassigned). [Note that second upstream tunnel 78 and second downstream tunnel 80 may stay active during this process.]
Turning to FIG. 7B, FIG. 7B is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, RNC 32 e, MER 50 b, SGSN/SGW 34 b, and GGSN/PGW 54 a. In one example, an UE active indicator 96 illustrates that UE 12 a is active. First upstream tunnel 76 and first downstream tunnel 82 connect RNC 32 e with SGSN/SGW 34 b and second upstream tunnel 78 and second downstream tunnel 80 connect SGSN/SGW 34 b with GGSN/PGW 54 a.
In another example, an UE inactive indicator 98 illustrates that UE 12 a is not active and first upstream tunnel 76 and first downstream tunnel 82 have been released. Because the tunnels have been released and are no longer active, MER 50 b is unable to route any data to UE 12 a. If MER 50 b does not receive any data from or destined to UE 12 a during this state, the issue is not a problem. However, if such traffic is received at MER 50 b, then new tunnels should be established for the data to reach UE 12 a. In yet another example, an UE re-active indicator 100 illustrates that UE 12 a has been reactivated and a new first upstream tunnel 86 and a new downstream tunnel 92 have been created.
Using a dormant detection process, where the inactivity timer and the stale state are monitored, MER 50 a is able to determine that first upstream tunnel 76 and second downstream tunnel 82 have been released, and new first upstream tunnel 86 and new second downstream tunnel 92 have been created. If MER 50 a determines that first upstream tunnel 76 and second downstream tunnel 82 have been released, MER 50 a can send an in-band message to GGSN/PGW 54 a to obtain the new association/binding of new first upstream tunnel 86 and new second downstream tunnel 92 through the existing tunnels (tunnels 78 and 80). From GGSN/PGW 54 a, MER 50 b is able to determine the TEID for new first upstream tunnel 86 and new downstream tunnel 92, and route data to/from the user device.
Turning to FIG. 7C, FIG. 7C is a simplified flowchart 700 illustrating one potential operation associated with the present disclosure. (Note that FIG. 7C (due to its length) has been broken into two segments: 7C-1, 7C-2.) In 702, a MER receives a downstream packet. For example, MER 50 a may receive a downstream packet from default path 60, or from breakout path 106 that was created when a packet was offloaded. In 704, the MER determines if network address and port translation (NAPT) binding still exists. If NAPT binding does not still exist, then the packet is dropped, as in 706. If NAPT binding does still exist, then the MER determines if an inactivity timer has expired, as shown in 708. If the inactivity time has expired, then both upstream and downstream tunnels are marked as stale, as shown in 710 and the packet is buffered (depicted in 714). If the inactivity timer has not expired, then the MER determines if the stale state is set, as shown in 712.
If the stale state is not set, then the MER sends the packet to an RNC, as illustrated in 716. In 718, the MER then determines if an error message is received from the RNC (indicating that the downstream tunnel TEID is not correct or no longer valid.) If an error message was not received, then the MER considers the downstream tunnel TEID to be correct. If an error message was received, then both upstream and downstream tunnels are marked as stale, as shown in 710, and the packet is buffered, as depicted in 714. In 720, the MER sends an in-band message to a GGSN/PGW to obtain the identity of the new tunnels. For example, MER 50 a may send an in-band message to GGSN/PGW 54 a using GRE tunnel 84. In 722, the GGSN/PGW sends in-band message towards a SGSN/SGW 34 b using an existing second downstream tunnel, which triggers the SGSN/SGW to start a paging procedure and establish new tunnels to the RNC. For example, GGSN/PGW 54 a may send an in-band message towards SGSN/SGW 34 b using existing second downstream tunnel 80, which triggers SGSN/SGW 34 b to start a paging procedure and establish new tunnels (86 and 92) to RNC 32 e. In 724, the MER receives a MER discovery message from the GGSN that includes the TEID of the new upstream and downstream tunnels. In 726, using the TEID of the new tunnels, the buffer is drained and the packet is sent to the RNC.
Turning to FIG. 8A, FIG. 8A is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, cell sites 30 a-c, RNC 32, MER 50 a-c, SGSN/SGW 34, GGSN/PGW 54, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, second downstream tunnel 82, out-of-band channel 73, GRE tunnel 84, core network 56, and Internet 58. FIG. 8A further includes an IP point of attachment 124.
In accordance with one example implementation, packets from UE 12 a are communicated to MER 50 a. Based on instructions from GGSN/PGW 54, MER 50 a determines which traffic to offload, where it uses IP-based routing to act as an anchor point. The offloaded traffic 108 is communicated on breakout path 106. Use of IP-based routing, allows for mid-flow breakout of traffic and also avoids NAT-ing at MER 50 a. MER 50 a can act as an upstream router instead of incurring the cost of the mobile plane, as the routing offload point is where the subscriber is hosted and MER 50 a acts as the upstream point to external networks (such as Internet 58).
In a particular embodiment, MER 50 a assigns IP addresses to each traffic flow for which MER 50 a serves as the anchor router. In a particular embodiment, a range of IP addresses that are the last hop for MER 50 a or GGSN/PGW 54 (which can be configured at different regularities) are assigned to each traffic flow. In another particular embodiment, IP addresses are dynamically distributed between MER 50 a and GGSN/PGW 54. The assigned IP address allows for traffic to be returned to either MER 50 a or GGSN/PGW 54.
In a particular embodiment, traffic is de-capsulated at MER 50 a. MER 50 a can determine if a de-capsulated packet matches an inner IP access control list, a TEID, or both. For example, for global ACL configurations for PDPs, inner destination IP address is not at the provider content network (i.e., traffic is toward distributed or Internet content), and for per-PDP ACL, a 5-tuple match for inner IP flow of a PDP context. Further packet analysis on the gateway can be used to determine IP flows of the default bearer, and the secondary PDP/dedicated bearer is set for breakout. If the packet does match, then an IP address can be assigned to the packet such that MER 50 a would serve as the anchor or host router. If the packet does not match, then the packet can be communicated to SGSN/SGW 34.
In accordance with one example implementation, MER 50 a can receive downstream traffic from Internet 58 and also communicate the traffic to UE 12 a. In another example implementation, MER 50 a receives downstream traffic from Internet 58; however, based on the type of traffic, services should be applied to the packet flow and MER 50 a is not necessarily capable of performing those services. In this case, the operator serviced traffic 122 that needs the services applied (such as transactions or charging (e.g., Layer 7 billing), firewall capabilities, etc.) can be communicated to GGSN/PGW 54 using GRE tunnel 84. In a particular embodiment, the operator-serviced traffic 122 cannot be serviced by GGSN/PGW 54 and the operator-serviced traffic 122 is offloaded to core network 56 for servicing. In this manner, downstream traffic is received by MER 50 a and, if further or special services are needed, operator serviced traffic 122 is communicated from MER 50 a to GGSN/PGW 54 (using GRE tunnel 84 such that the traffic is offloaded to core network 56). MER 50 a may be capable of performing some services depending on the number of data plane levels available on MER 50 a.
Turning to FIG. 8B, FIG. 8B is a simplified flowchart 800 illustrating one potential operation associated with the present disclosure. In 802, traffic is received at a MER. For example, upstream or downstream traffic may be received at MER 50 a. In 804, the MER can determine if the traffic is GTP-U encapsulated. If the traffic is not GTP-U encapsulated, then the MER can determine if the traffic is mobile traffic, at 806. If the traffic is not mobile traffic, then standard routing functions are performed, at 808. If the traffic is mobile traffic, then the functions as specified by a MER-CA are performed on the traffic, at 810. If the traffic is GTP-U encapsulated, then the MER can determine if the traffic is upstream traffic or downstream traffic, at 812.
If the traffic is upstream traffic, then the MER de-capsulates the packet, and can determine if the de-capsulated packet matches an inner IP access control list, a TEID, or both, as shown in 820. If the MER determines that the de-capsulated packet does match an inner IP access control list, a TEID, or both, then an IP address is assigned to the de-capsulated packet and the de-capsulated packet is broken out, as shown in 822. If the MER determines that the de-capsulated packet does not match an inner IP access control list, a TEID, or both, then the de-capsulated packet is communicated on to a GGSN, as shown in 824. For example, using GRE tunnel 84, MER 50 a may communicate to GGSN/PGW 34, a de-capsulated packet that needs a service performed.
Turning to FIG. 8C, FIG. 8C is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, cell sites 30 a-c, RNC 32, MER 50 a-c, SGSN/SGW 34, GGSN/PGW 54, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, second downstream tunnel 82, out-of-band channel 73, GRE tunnel 84, core network 56, and Internet 58. FIG. 8C may also include an embedded NAT 110. FIG. 8C is similar to FIG. 8A except for the addition of embedded NAT 110. When a packet in the traffic flow needs extra processing outside GGSN/PGW 54 (CDR generation, complex CDRS, voice) and those packets still have the source IP address originally assigned by MER 50 a. The addition of embedded NAT 110 can help facilitate the extra processing and ensure the traffic is returned to GGSN/PGW 54.
NAT-ing is the process of modifying IP address information in the IP packet header of the packet in the traffic flow, while the packet is in transit across MER 50 a. The simplest type of NAT provides a one-to-one translation of IP addresses (e.g., basic NAT or one-to-one NAT). In this type of NAT, the IP addresses, IP header checksum, and/or any higher-level checksums (that include the IP address) are changed. The rest of the packet can be left untouched (at least for basic TCP/UDP functionality, some higher-level protocols may need further translation).
In accordance with one example implementation described in FIG. 8A, downstream traffic ended up at MER 50 a and MER 50 a determined whether or not the traffic could be communicated to UE 12 a, or if the traffic needed to shift to GGSN/PGW 54 for services. When flows are not being offloaded (or flow through the GRE tunnel), and have services applied, in order to return the downstream packets for a user (for a non-broken out flow) NAT 110 assigns the user a different IP address. For example, some complex services can be applied at GGSN/PGW 54 using core network 56.
The upstream traffic with the complex services is communicated to GGSN/PGW 54 and is NAT-ed before it is communicated to core network 56 so the traffic will return to GGSN/PGW 54. Otherwise, the traffic can be offloaded, FIG. 8A, and the source address of the upstream is still the one that was assigned to the user. If the traffic is not uploaded, it still has the source address of the user. Hence, NAT 110 assigns a different IP address before the traffic is sent to core network 56. That new source address allows the packet to return back to the GGSN/PGW 54 and not MER 50 a.
Turning to FIG. 9A, FIG. 9A is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, cell sites 30 a-c, RNC 32, MER 50 a, routers 52, SGSN/SGW 34, GGSN/PGW 54, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, second downstream tunnel 82, out-of-band channel 73, GRE tunnel 84, core network 56, embedded NAT 110, IP point of attachment 124, and Internet 58.
In accordance with one example implementation, packets from UE 12 a are communicated to MER 50 a. MER 50 a determines which traffic to offload and uses embedded NAT 110 to act as an anchor point. Use of NAT allows for a mid-flow breakout of traffic and does not require MER 50 a to be an anchor point. For example, if UE 12 a is mobile, MER may be moved to a new MER and the new MER could become the new anchor MER. MER 50 a acts as the upstream point of attach to external networks (such as Internet 58). When the anchor point moves to the new MER, the IP session may be kept. In a particular embodiment, a tunnel is established between the anchor MER and the new MER to provide a mobile support.
In a particular embodiment, traffic is de-capsulated at MER 50 a. MER 50 a determines if a de-capsulated packet matches an inner IP access control list, a TEID, or both. (For example, if global configurations ACL for PDPs: inner destination IP address is not at provider content network (i.e., traffic is toward distributed or Internet content), per-PDP ACL: 5-tuple match for inner IP flow of a PDP context. DPI on GW is used to determine IP flows of PDP context, and entire secondary PDP/dedicated bearer is set for breakout.) If the packet does match, then the inner IP of the packet is NAT-ed such that MER 50 a will be the anchor router. If the packet does not match, then the packet is communicated to SGSN/SGW 34. Because the packet is NAT-ed, the anchor point for the offloaded packet is MER 50 a. MER 50 a receives the offloaded packet as downstream traffic from Internet 58 and communicates the packet to UE 12 a. In a particular embodiment, MER 50 a determines if services should be applied to the offloaded packet. If services are necessary, then the offloaded packet may be NAT-ed such that the offloaded packet will return to GGSN/PGW 54 where the services can be applied. Hence, the packet would not be returned to MER 50 a and then tunneled back to GGSN/PGW 54, the packet would go directly to GGSN/PGW 54.
If the traffic is upstream traffic, the MER determines if a packet matches an inner IP access control list, a TEID, or both, as in 910. If the MER determines that the packet does not match, then the packet is communicated on to an SGSN/SGW, as in 912. For example, if MER 50 a determines that the packet does not match, then the packet is communicated on to an SGSN/SGW 34. If the MER determines that the packet does match, then the packet is de-capsulated and the de-capsulated packet is NAT-ed and broken out, as shown in 914.
Turning to FIG. 9C, FIG. 9C is a simplified block diagram of communication system 10, which (in this particular implementation) includes UE 12 a, cell sites 30 a-c, RNC 32, MER 50 a, routers 52, SGSN/SGW 34, GGSN/PGW 54, first upstream tunnel 76, second upstream tunnel 78, first downstream tunnel 80, second downstream tunnel 82, out-of-band channel 73, GRE tunnel 84, core network 56, carrier grade NAT (CGN) 112, IP point of attachment 124, and Internet 58. In accordance with one example implementation, packets from UE 12 a are communicated to MER 50 a. MER 50 a determines which traffic to offload and uses carrier grade NAT (CGN) 112 to act as an anchor point.
Turning to FIG. 10A, FIG. 10A is a simplified block diagram of a portion of communication system 10 depicting one example of an asymmetric routing 102 a. Asymmetric routing 102 a can include RNC 32, MER 50 a, MER 50 b, and SGSN/SGW 34. In this example, link 126 connects RNC 32 with MER 50 a, link 128 connects RNC 32 with MER 50 b, link 130 connects MER 50 a with SGSN/SGW 34, and link 132 connects MER 50 b with SGSN/SGW 34.
In some deployments, routers or MERs may be configured to operate in an active/active mode instead of active/standby mode. For example, MER 50 a and MER 50 b may be configured to operate in an active/active mode where both are active. In this case, UE's traffic may be loadbalanced between MER 50 a and MER 50 b without UE's awareness. As a result, traffic from one UE may traverse through different routers (or MERs) and the control of such traffic becomes more challenging. In one particular embodiment, policy based routing (PBR) may be used to bring mobile-related traffic to one MER for service enforcement. The service enforcement is in active/standby mode while the routers are in active/active mode. In another particular embodiment, a new function to MER is added such that the service enforcement forwards mobile traffic of specific subscribers to peers responsible for the control of such subscribers.
FIG. 10B is a simplified schematic diagram illustrating possible examples of a link (e.g., link 126 or link 130) to MER 50 a becoming disabled. For example, 102 b depicts link 126 becoming disabled (e.g., due to a loss of connection between RNC 32 and MER 50 a). In a particular embodiment, PBR is used to reroute traffic 104 a (that was communicated from MER 50 a to RNC 32 over link 126) from MER 50 b to RNC 32 (over link 128). Because link 130 is still active and not disabled, traffic 104 c continues to flow from/to MER 50 a to/from SGSN/SGW 34 over link 130.
In a similar example, 102 c depicts link 130 becoming disabled (e.g., due to a loss of connection between MER 50 a and SGSN/SGW 34). In a particular embodiment, PBR is used to reroute traffic 104 c (that was communicated from MER 50 a to SGSN/SGW 34 over link 130) from MER 50 b to SGSN/SGW 34 over link 132. Because link 126 is still active and not disabled, traffic 104 a continues to flow from/to MER 50 a to/from RNC 32 over link 126.
FIG. 10C is a simplified schematic diagram illustrating possible examples of a link (e.g., link 128 or link 132) to MER 50 b becoming disabled. For example, 102 d depicts link 128 becoming disabled (e.g., due to a loss of connection between RNC 32 and MER 50 b). In a particular embodiment, PBR is used to reroute traffic 104 b (that was communicated from MER 50 b to RNC 32 over link 128) from MER 50 a to RNC 32 (over link 126). Because link 132 is still active and not disabled, traffic 104 d continues to flow from/to MER 50 b to/from SGSN/SGW 34 over link 132.
In a similar example, 102 e depicts link 132 becoming disabled (e.g., due to a loss of connection between MER 50 b and SGSN/SGW 34). In a particular embodiment, PBR is used to reroute traffic 104 d (that was communicated from MER 50 b to SGSN/SGW 34 over link 132) from MER 50 a to SGSN/SGW 34 over link 130. Because link 128 is still active and not disabled, traffic 104 b continues to flow from/to MER 50 b to/from RNC 32 over link 128.
FIG. 10D is a simplified schematic diagram illustrating two possible examples of a MER (e.g., MER 50 a or MER 50 b) becoming disabled. For example, 102 f depicts MER 50 b becoming disabled (e.g., due to a mechanical failure of MER 50 b). In a particular embodiment, PBR can be used to reroute traffic 104 b that was communicated from MER 50 b to RNC 32 over link 128, and to reroute traffic 104 d that was communicated from MER 50 b to SGSN/SGW 34 over link 132. Because links 126 and 130 are still active and not disabled, traffic can be communicated from MER 50 a to RNC 32 over link 126, and to SGSN/SGW 34 over link 130.
In a similar example, 102 g illustrates a scenario in which MER 50 a has become disabled (e.g., due to a mechanical failure of MER 50 a). In a particular embodiment, PBR can be used to reroute traffic 104 a that was communicated from MER 50 a to RNC 32 over link 126, and reroute traffic 104 c that was communicated from MER 50 b to SGSN/SGW 34 over link 130. Because links 128 and 132 are still active and not disabled, traffic can be communicated from MER 50 b to RNC 32 over link 128, and to SGSN/SGW 34 over link 132.
FIG. 10E is a simplified schematic diagram illustrating an example of when link 130 has become disabled (e.g., due to a loss of connection between MER 50 a and SGSN/SGW 34) and the link failure does not trigger a MER switchover. As shown in the example, traffic 104 a, 104 b, 104 c, and 104 d should first propagate through MER 50 a and then be rerouted through MER 50 b. As a result, inter-chassis traffic becomes extreme (i.e., may require additional physical links to be installed on both routers).
FIG. 10F is a simplified schematic diagram illustrating a graphical example of when link 130 has become disabled (e.g., due to a loss of connection between MER 50 a and SGSN/SGW 34), and the link failure triggers a MER switchover. As shown in the example, traffic 104 b, 104 c, and 104 d does not first propagate through MER 50 a and then be rerouted through MER 50 b. Instead, traffic 104 a is routed from MER 50 b to MER 50 a. As a result, inter-chassis traffic does not becomes extreme (i.e., does not require additional physical links to be installed on both routers). In order to achieve the re-routing of traffic, certain link failures may trigger MER switchover based on configured policies and available inter-chassis bandwidth
Turning to FIG. 11, FIG. 11 is a simplified block diagram of an in-band signaling packet 134. In-band signaling packet 134 may include an outer tunnel IP header 136, an inner packet IP header 138, and a payload 140. Fields 102 and fields 142 (or a subset) indicate parameters that can be configured by MER 50 a and/or a MER-CA (e.g., GGSN/PGW 54). Fields 144 (or a subset) indicate parameters that should be used without modifications.
Payload 140 may contain in-band protocol data elements. For example, payload 140 may contain the type of message, the IP assigned to UE (e.g., UE 12 a), downstream and upstream TEIDs, packet hashes, MER CA and MER Control Plane/Data Plane (CP/DP) address/port to be used, MER and MER CA ID, and future extensions, which can include other elements. The message type may be a MER discovery message, a TEID discovery/loopback, an end-marker, a paging trigger, or future extensions.
In one example implementation, MER 50 a and/or MER-CA (e.g., GGSN/PGW 54) may include software (e.g., provisioned as traffic offload module 66, MER control module 74, etc.) in order to achieve the data communication functions outlined herein. These devices may further keep information in any suitable memory element [random access memory (RAM), ROM, EPROM, EEPROM, ASIC, etc.], software, hardware, or in any other suitable component, device, element, or object where appropriate and based on particular needs. Any of the memory items discussed herein (e.g., database, tables, trees, queues, caches, etc.) should be construed as being encompassed within the broad term ‘memory element.’ Similarly, any of the potential processing elements, modules, and machines described in this Specification should be construed as being encompassed within the broad term ‘processor.’ Each of these elements (e.g., MER 50 a and MER-CA (e.g., GGSN/PGW 54)) can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.
MER 50 a and MER-CA (e.g., GGSN/PGW 54) are network elements configured to perform the traffic offloading activities disclosed herein. As used herein in this Specification, the term ‘network element’ may include any suitable hardware, software, components, modules, interfaces, or objects operable to exchange information in a network environment. Further, the term network element as discussed herein encompasses (but is not limited to) devices such as routers, switches, gateways, bridges, loadbalancers, firewalls, inline service nodes, proxies, clients, servers processors, modules, or any other suitable device, component, element, proprietary device, network appliance, or object operable to exchange information in a network environment. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.
receiving a data packet over a first link at a first network element;
establishing an out-of-band channel over a second link between the first network element and a second network element; and
receiving instructions at the first network element to offload the data packet from the first link.
2. The method of claim 1, wherein the first network element is a mobile enabled router, and the second network element is a gateway general packet radio service support node or a packet data network gateway.
receiving a discovery message from the second network element, the discovery message triggering the establishment of the out-of-band channel.
4. The method of claim 1, wherein the data packet is offloaded based on a type of data in the data packet.
5. The method of claim 1, wherein predefined classes of traffic are provisioned such that the first network element is configured to map certain classes of traffic to available backhaul links.
establishing a generic routing encapsulation (GRE) tunnel between the first network element and the second network element using the out-of-band channel.
7. The method of claim 6, wherein the GRE tunnel is used to loopback traffic to the first network element during handover activities involving a user equipment.
8. The method of claim 1, wherein the first network element is configured to use the out-of-band channel to identify itself, confirm receipt of a discovery request, and obtain session control instructions.
9. Logic encoded in one or more non-transitory media that includes code for execution and when executed by a processor is operable to perform operations comprising:
10. The logic of claim 9, wherein the first network element is a mobile enabled router, and the second network element is a gateway general packet radio service support node or a packet data network gateway.
12. The logic of claim 9, wherein the data packet is offloaded based on a type of data in the data packet.
13. The logic of claim 9, wherein predefined classes of traffic are provisioned such that the first network element is configured to map certain classes of traffic to available backhaul links.
15. The logic of claim 14, wherein the GRE tunnel is used to loopback traffic to the first network element during handover activities involving a user equipment.
16. The logic of claim 9, wherein the first network element is configured to use the out-of-band channel to identify itself, confirm receipt of a discovery request, and obtain session control instructions.
a traffic offload module configured to interface with the memory element and the processor, wherein the apparatus is configured for:
receiving a data packet over a first link;
establishing an out-of-band channel over a second link with a network element; and
receiving instructions to offload the data packet from the first link.
receiving a discovery message from the network element, the discovery message triggering the establishment of the out-of-band channel.
19. The apparatus of claim 17, wherein the data packet is offloaded based on a type of data in the data packet, and wherein predefined classes of traffic are provisioned such that the apparatus is configured to map certain classes of traffic to available backhaul links.
20. The apparatus of claim 17, wherein the apparatus is configured to use the out-of-band channel to identify itself, confirm receipt of a discovery request, and obtain session control instructions.
US13179538 2010-10-05 2011-07-10 System and method for offloading data in a communication system Active US9031038B2 (en)
US13179538 US9031038B2 (en) 2010-10-05 2011-07-10 System and method for offloading data in a communication system
US20120082132A1 true true US20120082132A1 (en) 2012-04-05
US9031038B2 US9031038B2 (en) 2015-05-12
US (7) US8787303B2 (en)
US20150139075A1 (en) * 2013-11-21 2015-05-21 Cisco Technology, Inc. Providing cellular-specific transport layer service by way of cell-site proxying in a network environment
US8787303B2 (en) 2014-07-22 grant
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:ANDREASEN, FLEMMING S.;LEUNG, KENT K.;KHOUDERCHAH, MICHEL;AND OTHERS;SIGNING DATES FROM 20110707 TO 20110708;REEL/FRAME:026566/0009