Subscriber awareness for a mobile private network routing service in a network environment

A method provided in one embodiment includes receiving, at a packet gateway, a first binding update message from a mobile access gateway. The first binding update message has a destination address associated with a local mobility anchor. The method further includes extracting at least one session identifier associated with the mobile access gateway from the first binding update message, constructing an option field including the at least one session identifier, and appending the option field to the first binding update message to form a second binding update message. The method further includes sending the second binding update message to the local mobility anchor.

TECHNICAL FIELD

This disclosure relates in general to the field of communications and, more particularly, to providing subscriber awareness for a mobile private network routing service in a network environment.

BACKGROUND

Mobile operators are increasingly offering business virtual private network (VPN) services over 3G/4G wireless infrastructure. By leveraging wireless access for the last-mile, operators are able to offer services for building enterprise private VPN clouds, similar to dedicated leased-line service offered by fixed line providers. This approach allows operators to eliminate the costs associated with circuit on the last mile and furthermore allows them to monetize their investments in LTE access. A business VPN service allows enterprises to securely link their remote branch offices over a mobile network without the need for dedicated leased lines, or the use of Internet Protocol Security (IPSec)/Secure Sockets Layer (SSL) based VPN services. An enterprise customer may purchase business VPN service in addition to a data connection for their customer premise equipment (CPE) device in a branch office. Service logic in the mobile gateway ensures that the traffic from certain International Mobile Subscriber Identities (IMSI's) is segmented and is virtual routing and forwarding (VRF)-routed to the customer's multiprotocol label switching (MPLS) network. This eliminates provisioning and service management related challenges (typically present with IPsec/SSL based VPN services) for the enterprise IT and at the same time opens up new business opportunities for mobile operators.

Current solutions for enabling this service tie the service logic to the mobile gateways. However, there is significant interest from operators to have this service logic moved out of the evolved packet core (EPC) and have it reside in service nodes outside the packet gateway (PGW) such as in and MPLS Edge, Gi-LAN, or in a partner SP offering MPLS VPN service. In addition to the requirement for moving certain business services out of the EPC, it is also to have some stickiness between those service functions and the EPC elements. In particular, it is desired that the business VPN service function should be able to leverage the LTE service authorization, or other policy elements, and have this service as an extension to the LTE service.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS

Overview

A method is provided in one embodiment and includes receiving, at a packet gateway, a first binding update message from a mobile access gateway. The first binding update message has a destination address associated with a local mobility anchor. The method further includes extracting at least one session identifier associated with the mobile access gateway from the first binding update message, constructing an option field including the at least one session identifier, and appending the option field to the first binding update message to form a second binding update message. The method further includes sending the second binding update message to the local mobility anchor.

In particular embodiments, the method further includes modifying a length field value of a length field of the first binding update message to include a length of the option field and recomputing a checksum field value of a checksum field of the first binding update message. In still other particular embodiments, the option field includes one or more session identity portions associated with each session identifier, each session identity portion including a sub-option type field indicative of a type of the session identifier, a length field indicative of a length of the session identifier, and a subscriber identity field including the session identifier.

In particular embodiments, the at least one session identifier includes one or more of a Mobile Station International Subscriber Directory Number (MSISDN) associated with the mobile access gateway, a Network Access Identifier (NAI) associated with the mobile access gateway, an International Mobile Subscriber Identity (IMSI) associated with the mobile access gateway, an Access Point Name (APN) associated with the mobile access gateway, and a Virtual Routing and Forwarding (VRF) name associated with the mobile access gateway.

In other particular embodiments, the method further includes performing packet inspection for determining the binding update message prior to extracting the at least one session identifier. In still other particular embodiments, the option field is a vendor specific mobility option field. In other particular embodiments, the first binding update message is a proxy binding update (PBU) message.

In particular embodiments, the method further includes receiving the second binding update message by the local mobility anchor, determining if the option field is present within the second binding update message, parsing the option field for the at least one session identifier, and copying the at least one session identifier into a binding cache entry in association with the mobile access gateway.

In still other particular embodiments, the method further includes determining, by the local mobility anchor, an original length field value of the length field of the first binding update message, and restoring the original length field value within a length field of the second binding update message. In other particular embodiments, the method further includes sending a binding acknowledgment message to the mobile access gateway via the packet gateway, and setting up one or more tunnels between the mobile access gateway and the local mobility anchor using the at least one session identifier. In other particular embodiments, the method further includes forwarding traffic between a wired or wireless device connected to the mobile access gateway and a server associated with the wired or wireless device using the one or more tunnels.

Logic encoded in one or more non-transitory media is provided in one embodiment that includes code for execution and when executed by a processor operable to perform operations including receiving, from a packet gateway, a binding update message by a local mobility anchor, and determining if an option field is present within the binding update message including at least one session identifier associated with a mobile access gateway. The operations further include parsing the option field for the at least one session identifier, and copying the at least one session identifier into a binding cache entry in association with the mobile access gateway.

In particular embodiments, the operations further include determining, by the local mobility anchor, an original length field value of the length field of the binding update message, and restoring the original length field value within a length field of the binding update message. In other particular embodiments, the operations further include sending a binding acknowledgment message to the mobile access gateway via the packet gateway, and setting up one or more tunnels between the mobile access gateway and the local mobility anchor using the at least one session identifier. In still other particular embodiments, the operations further including forwarding traffic between a wired or wireless device and a server associated with the wired or wireless device using the one or more tunnels.

A network element is provided in one embodiment and includes a memory element configured to store electronic code, a processor operable to execute instructions associated with the electronic code, and a module coupled to the memory element and the processor. The network element is configured for receiving a first binding update message from a mobile access gateway. The first binding update message has a destination address associated with a local mobility anchor. The network element is further configured for extracting at least one session identifier associated with the mobile access gateway from the first binding update message, constructing an option field including the at least one session identifier, and appending the option field to the first binding update message to form a second binding update message. The network element is still further configured for sending the second binding update message to the local mobility anchor.

A network element is provided in one embodiment and includes a memory element configured to store electronic code, a processor operable to execute instructions associated with the electronic code, a binding cache entry table, and a module coupled to the memory element, the processor and binding cache entry table. The network element is configured for receiving, from a packet gateway, a binding update message by a local mobility anchor, and determining if an option field is present within the binding update message including at least one session identifier associated with a mobile access gateway. The network element is further configured for parsing the option field for the at least one session identifier, and copying the at least one session identifier into a binding cache entry of the binding cache entry table in association with the mobile access gateway. In a particular embodiment, the network element includes a local mobility anchor.

Example Embodiments

Referring now toFIG. 1,FIG. 1is a simplified block diagram of a communication system for providing subscriber awareness for a mobile private network routing service in a network environment in accordance with one embodiment of the present disclosure. Communication system100includes a first enterprise branch location device102a, a second enterprise branch location device102b, a third enterprise branch location device102c, and a fourth enterprise branch location device102d, a first mobile access gateway (MAG)104a(MAG A), a second MAG104b(MAG B), a third MAG104c(MAG C), an LTE network106, a mobile packet core108including a packet gateway110, a service provider's IP edge112including a local mobility anchor (LMA)114, a Multiprotocol Label Switching (MPLS) core network116, and a first enterprise server118a(Enterprise A), a second enterprise server118b(Enterprise B), and a third enterprise server118c(Enterprise C).

First enterprise branch location device102aand second enterprise branch location device102bare in communication with first MAG104alocated at a branch location shared by enterprises Enterprise A and Enterprise B, third enterprise branch location device102cis in communication with second MAG104blocated at an Enterprise B branch location, and fourth enterprise branch location device102dis in communication with third MAG104clocated at an Enterprise C branch location. In one or more embodiments, each of first MAG104a, second MAG104b, and third MAG104care mobile access gateway (MAG) protocol functions hosted within a wireless communication device, such as a long term evolution (LTE) router. In particular embodiments, enterprise branch location devices102a-102dare each in communication with the respective MAGs104a-104cvia a wired connection and/or a wireless communication. In one or more embodiments, first enterprise branch location device102a, second enterprise branch location device102b, third enterprise branch location device102c, fourth enterprise branch location device102d, first MAG104a, second MAG104b, and third MAG104care located at one or more customer premises. In the particular embodiment illustrated inFIG. 1, first enterprise branch location device102a, second enterprise branch location device102b, and MAG A104aare located at a branch location shared by enterprises Enterprise A and Enterprise B; third enterprise branch location device102cand second MAG104bare located at Enterprise B branch location; and enterprise branch location device102dand third MAG104care located at Enterprise C branch location. In particular embodiments, first MAG104ais configured as a multi-tenant Customer Premises Equipment (CPE) to share resources across multiple customers sharing a common premises, such as a building, and common network connectivity; and second MAG104band third MAG104care each configured as single tenant Customer Premise Equipment (CPE) to provide resources to a single customer instance.

One or more of first enterprise branch location device102a, second enterprise branch location device102b, third enterprise branch location device102c, and fourth enterprise branch location device102dcommunicate with respective enterprise servers118a-118cvia their connection to the respective MAGs104a-104c. In particular embodiments, one or more of first enterprise branch location device102a, second enterprise branch location device102b, third enterprise branch location device102c, and fourth enterprise branch location device102dmay include a point-of-sale (POS) machine, a vending machine, an automatic teller machine (ATM), a branch office device, a machine-to-machine (M2M) device, etc.

Each of first MAG104a, second MAG104b, and third MAG104care in communication with PGW110within mobile packet core108via LTE network106. Each of first MAG104a, second MAG104b, and third MAG104cfunctions to manage mobility-related signaling to LMA114on behalf of the respective enterprise branch location devices102a-102dthat are attached to its access link. In particular embodiments, each of first MAG104a, second MAG104b, and third MAG104cmay be located within a mobile router in communication with PGW110via LTE network106.

PGW110is in communication with LMA114within service provider's IP edge112. LMA114functions as a home agent for each of first MAG104a, second MAG104b, and third MAG104cfor each of enterprise branch location devices102a-102dand serves as an anchor point for the home network prefix(es) and is the entity that manages the binding state on behalf of each of enterprise branch location devices102a-102d. In particular embodiments, LMA114has the functional capabilities of a home agent as defined in Mobile IPv6 base specification as defined in RFC3775 with the additional capabilities required for supporting Proxy Mobile IPv6 protocol as defined in this RFC 5213. LMA114is in further communication with each of first enterprise server118a, second enterprise server118b, and third enterprise server118cvia MPLS core network116.

In accordance with one or more embodiments, business VPN service logic is hosted on a network node outside PGW110and defines some interworking between PGW110and the service function. In accordance with one or more embodiments, PGW110in the transit path performs service authorization based on LTE subscription data. PGW110functions as a gatekeeper to the service function and additionally decorates control-plane traffic to the service function with additional information elements related to the LTE service. These information elements aid the service function in enabling the business VPN service to act as an extension to LTE service. Although various embodiments described herein are described using LTE services and business VPN services, it should be understood that other embodiments may be directed to any service provided between a remote mobile device and a server.

In accordance with various embodiments, PGW110ensures that control plane traffic to the service function are from the CPE devices authorized for VPN service and may will include information elements which are essential for service diagnostics and accounting service correlation.

In order to provide a private network routing service to enterprise customers through cellular networks, one or more of MAG104a-104cis equipped with a radio interface module to establish a connection to the LMA114. In a particular embodiment LMA114is located within an access router within the wireless network operator's core MPLS/IP network. In particular embodiments, a communication protocol used between each of MAG104a-104cand LMA114is Proxy Mobile IP v6 (PMIPv6). PMIPv6 is a network-based mobility management protocol standardized by IETF as specified in RFC 5213 for building a common and access technology independent of mobile core networks, accommodating various access technologies such as LTE, WiMAX, 3GPP, 3GPP2 and WLAN based access architectures.

Due to various reasons (e.g. an external radio interface module), LMA114doesn't have a reliable mechanism to get trusted identifiers of the connecting MAG104a-104cvia PMIPv6 signaling. Trusted identifiers for MAG104a-104care crucial for authorizing the enterprise, for accurate accounting and for deploying and operating a private network routing service in the wireless operator's network. In accordance with one or more embodiments, PGW110, situated between MAG104a-104cand LMA114, provides a 3G/4G wireless connection to the radio interface module (RIM) in one or more of MAG104a-104cand has secure access to the RIM identifiers, e.g. IMSI, associated with each of MAG104a-104c. Since the RIM is authenticated, authorized and trusted by the wireless operator's network, PGW110can potentially provide these trusted identifiers to LMA114to address the above identified issue as will be further described herein.

In accordance with various embodiments, PGW110intercepts a PMIPv6 proxy binding update (PBU) message received from a particular MAG104a-104c, inserts subscriber session information needed by LMA114and sends the subscriber session information to LMA114. A PBU message is a PMIPv6 control plane request message sent by a mobile access gateway, such as one or more of MAG104a-104c, to LMA114for establishing a binding between the mobile node's home network prefix(es) assigned to a given interface of a mobile node and its current care-of address (Proxy-CoA). In an example operation of PGW110according to at least one embodiment, when configured for subscriber continuity, PGW119performs Deep Packet Inspection (DPI) on the packets sent by one or more of MAG104ain order to identify the PBU message. In a particular embodiment, the native IPv6 PBU is identified as having a Next Header field=135 in the IPv6 header and IPv4 PBU is identified as having UDP port=5436. Once the PBU message is intercepted, if authorized by the wireless operator's policy, PGW110constructs and appends a new Vendor Specific Mobility Option to the original PBU. This option may include the MAG's International Mobile Subscriber Identity (IMSI), Mobile Station International Subscriber Directory Number (MSISDN), Mobile Directory Number (MDN), Access Point Name (APN), Virtual Routing and Forwarding (VRF) name and other relevant information.

After the PBU message is modified, PGW110delivers the modified message to LMA114. Subsequently, LMA114may send a Proxy Binding Acknowledgement (PBA) message to the MAG (from which it received the PBU) via PGW110. A PBA message is a reply message sent by a LMA114in response to receiving the PBU message. In accordance with one or more embodiments, the PBA message from LMA114is not intercepted/modified by PGW110but is instead passed on to one of MAG104a-104c.

In an example operation of LMA114, if explicitly configured for subscriber continuity LMA114handles the PBU message in a special manner. First, LMA114looks for the presence of the new VSMO. If the VSMO is absent, the PBU message is rejected with a “Administratively prohibited” message. If the VSMO is present in the PBU message, session and/or subscriber related information such as the IMSI, MSISDN, MDN, APN, VRF, etc., is extracted from the VSMO and saved in a binding cache entry of LMA114in association with the particular MAG104a-104cthat sent the PBU message. If all processing of the PBU message succeeds, LMA114sends a successful PBA message to the particular MAG104a-104cto establish the PMIPv6 session.

In one or more embodiments, PGW110performs a VPN service authorization check for the International Mobile Subscriber Identity (IMSI) associated with a GTP-U tunnel on which the PMIPv6 PBU was received, and allows the PMIPv6 control plane traffic to pass PGW110towards LMA114only when the authorization check passes, and dropping the PMIPv6 control plane traffic when the VPN authorization check fails. In particular embodiments, LMA114removes the VMSO and subtracts the length of the VSMO from the length field in the PBU header before performing any integrity checks on the PBU when an authentication option is included. In one or more embodiments, LMA114extracts the information elements from the VMSO, associates them with the PMIPv6 session, and uses them in business VPN service logic. In particular embodiments, LMA114may report the LTE session identifiers in accounting records generated by LMA114for the PMIPv6 session. In other particular embodiments, LMA114may include the session identifiers in a PMIPv6 session command line interface (CLI), enabling an operator to correlate the LTE session and the PMIPv6 sessions. In other embodiments, LMA114may also include the session identifiers in any accounting messages that are generated and sent to one or more authentication, authorization, and accounting (AAA) servers.

Referring now toFIGS. 2A-2C,FIGS. 2A-2Cillustrate a simplified flow diagram depicting a flow200associated with providing subscriber awareness for a mobile private network routing service in a network environment in accordance with one embodiment of the present disclosure. In202, first MAG104a(MAG A) constructs an original proxy binding update (O-PBU) message and sends the original PBU (O-PBU) message addressed to LMA114via PGW110as control plane traffic. In204, PGW110performs packet inspection and intercepts the O-PBU message. In one or more embodiments, PGW110is configured to intercept PMIP control plane traffic having a destination address matching a set of LMA IP addresses associated with LMA114. In a particular embodiment, PGW110intercepts IP user datagram protocol (UDP) packets to a particular destination port (e.g., destination port 5436) and matching a particular destination IP address. In particular embodiments in which an IPv6 protocol is used, PGW110may determine whether the packets match a IPv6 Mobility Header packets having a mobility header (MH) type of PBU.

In206, PGW110determines if the LTE session on which O-PBU was received is authorized for subscriber continuity. if authorized, then PGW110extracts session identifiers from the LTE session in208. In particular embodiments, the session identifiers may include one or more of a Network Access Identifier (NAI), International Mobile Subscriber Identity (IMSI), Mobile Station International Subscriber Directory Number (MSISDN), Access Point Name (APN), and Name of the transport VRF used for the underlying session. In still other embodiments, the session identifiers may include any other suitable identifier. In210, PGW110constructs a Subscriber Continuity Vendor Specific Mobility Option (SC-VSMO) field including one or more of the session identifiers. In212, PGW110appends the SC-VSMO field to the O-PBU forming a new PBU of the format (O-PBU|SC-VSMO). In214, PGW110modifies the length field in the O-PBU mobility header to include the length of SC-VSMO, but does not recompute the contents of Authentication Option in the O-PBU. In215, PGW110recomputes the checksum in PBU header300(FIG. 3) in case a IPv6 protocol is used for transport between MAG104a-104c, PGW100and LMA114. In216, PGW110sends the new PBU to LMA114. If in206, PGW110determines that LMA114is known not to support the Subscriber Continuity feature, then PGW110forwards the O-PBU as it is to LMA114.

In218, LMA114determines whether the SC-VSMO is present in the PBU. If the SC-VSMO is present in the PBU, in220LMA114determines the original mobility header length in the O-PBU (as received by PGW110from first MAG104a), and in222LMA114restores the original mobility header length in the mobility header before validating the authentication option, if present, in the O-PBU. In224, LMA114parses the SC-VSMO and in226LMA114copies the session identifiers from the SC-VSMO into a binding cache entry (BCE) in association with first MAG104a. The BCE contains mobility binding information which allows LMA114to tunnel VPN traffic between first MAG104aand a server, such as first enterprise server118ausing one or more virtual tunnels. In particular embodiment, the session identifiers are displayed in a show binding output. If it is determined in218that the SC-VSMO is not present, whereas LMA114is configured for Subscriber Continuity feature (to expect SC-VSMO in PBU packet), then LMA114discards the PBU. If LMA114is not configured for the Subscriber Continuity feature and the SC-VSMO is present in the PBU, then LMA114ignores the SC-VSMO.

In228, LMA114sends a PBA message addressed to first MAG104avia PGW110. In230, PGW110normally routes the PBA to first MAG104awithout performing any inspection and/or change to the PBA. In232, the PBA is received by first MAG104afrom PGW110. In234, first MAG104aprocesses the PBA message received from LMA114via PGW110. In236, one or more tunnels are setup between first MAG104aand LMA114using the session identifiers. In238, VPN traffic is communicated between first MAG104aand enterprise server118autilizing the one or more tunnels established between first MAG104aand LMA114. In one or more embodiments, first MAG104areceives the VPN traffic communicated between first MAG104aand enterprise server118afrom one or more of first enterprise branch location device102aand second enterprise branch location device102b.

Referring now toFIG. 3A,FIG. 3Aillustrates an example of a proxy binding update (PBU) message format300according to one embodiment. In one or more embodiments, PBU message format300may be used in the PBU message described with respect toFIGS. 2A-2C. The PBU message format300includes a mobility header (MH) type field, an A bit, a reserved field, a checksum field, a sequence number field, a lifetime field, and a mobility options field. The MH type field is an 8-bit field that defines the type of the mobility header. In the particular embodiment illustrated inFIG. 3A, the MH type field includes a value of 5 indicative of the message being a proxy binding update message. The A bit represents an acknowledgement bit that is set by the sending mobile node to request a proxy binding acknowledgement message to be returned upon receipt of the PBU message. The reserved field represents a field that is reserved for later use. The checksum field is 16-bit information for detecting a message transport error, and the sequence number is 16-bit information representing the packet sequence of the PBU message. The lifetime field is 16-bit information representing the lifetime of the PBU message and the mobility options field may include one or more mobility options such as those described by RFC 3775 such as binding update authorization data and/or an alternate care-of-address option. In one or more embodiments, the PBU message may further include one or more mobility options such as those defined in RFC 5213.

Referring now toFIG. 3B,FIG. 3Billustrates an example of a format for a vendor-specific mobility option (VSMO) field302for appending to a PBU message according to one embodiment. In one or more embodiments, the VSMO is appended to a PBU message by PGW110. VSMO format302includes a first portion304and second portion306. First portion304includes a type field indicative of type of the vendor specific option (type19), a length field indicative of the total length of the vendor specific extension, a vendor/organization-ID field indicative of a vendor or organization associated with the vendor specific option, and a sub-type field indicative of a specific extension for the vendor or organization. Second portion306includes one or more subscriber identity portions and/or session identity portions associated with a MAG in communication with a packet gateway (PGW), such as first MAG104a. In one or more embodiments each subscriber/session identity portion includes a sub-option type field indicative of a type of a subscriber/session identity, a length field indicative of a length of the subscriber/session identity, and a subscriber identity field including the subscriber/session identity. The particular embodiment illustrated inFIG. 3Bincludes five different subscriber identifiers within second portion306.

The first subscriber identifier includes a VSE_SubOption_Type field indicative of the subscriber identifier including a Mobile Station International Subscriber Directory Number (MSISDN) (e.g., VSE_SubOption_Type=1), a length field indicative of a length of an MSISDN field that follows, and an MSISDN field including the MSISDN associated with the MAG. The second subscriber identifier includes a VSE_SubOption_Type field indicative of the subscriber identifier including an International Mobile Subscriber Identity (IMSI)-based Network Access Identifier (NAI) (e.g., VSE_SubOption_Type=2), a length field indicative of a length of the IMSI-NAI field that follows, and an IMSI-NAI field including the IMSI-NAI associated with the MAG. The third subscriber identifier includes a VSE_SubOption_Type field indicative of the subscriber identifier including an Access Point Name (APN) (e.g., VSE_SubOption_Type=3), a length field indicative of a length of the APN field that follows, and an APN field including the APN associated with the MAG. The fourth subscriber identifier includes a VSE_SubOption_Type field indicative of the subscriber identifier including a CDMA-NAI (e.g., VSE_SubOption_Type=4), a length field indicative of a length of the CDMA-NAI field that follows, and a CDMA-NAI field including the CDMA-NAI associated with the MAG. The fifth subscriber identifier includes a VSE_SubOption_Type field indicative of the subscriber identifier including a virtual routing and forwarding (VRF) name (e.g., VSE_SubOption_Type=5), a length field indicative of a length of the VRF name field that follows, and a VRF name field including a transport VRF name associated with the MAG.

Referring now toFIG. 3C,FIG. 3Cillustrates an example of a proxy binding acknowledgement (PBA) message format308according to one embodiment. In one or more embodiments, PBA message format308may be used in the PBA message described with respect toFIGS. 2A-2C. The PBA message format308includes a mobility header (MH) type field, a reserved field, a checksum field, a sequence number field, a lifetime field, a status field, and a mobility options field. The MH type field is an 8-bit field that defines the type of the mobility header. In the particular embodiment illustrated inFIG. 3A, the MH type field includes a value of 6 indicative of the message being a proxy binding acknowledgment message. The reserved field represents a field that is reserved for later use. The checksum field is 16-bit information for detecting a message transport error, and the sequence number is 16-bit information representing the packet sequence of the PBA message. The lifetime field is 16-bit information representing the lifetime of the PBA message. The status field includes 16-bit information representing a binding result, and the mobility options field may include one or more mobility options such as those described by RFC 3775, RFC 5123, etc.

Referring now toFIG. 4,FIG. 4is a simplified flowchart400that illustrates example operations associated with a packet gateway (PGW) in accordance with one embodiment. In402, PGW110inspects packets received from MAGs104a-104c. In404, PGW110intercepts a first original PBU (O-PBU) message, having a destination address associated with LMA114. In a particular embodiment, may determine whether the packets match a IPv6 Mobility Header packets having a mobility header (MH) type of PBU or UDP port=5436. In406, PGW110determines if the O-PBU is destined for an LMA e.g., LMA114) that is known to support the subscriber continuity feature. If in406PGW110determines that LMA114is not known to support the subscriber continuity feature, then PGW110forwards the O-PBU to LMA114without change in408and then the operations end.

If in406PGW110determines if the LTE session on which O-PBU was received is authorized for Subscriber Continuity, then PGW110extracts session identifiers from the O-PBU in410. In particular embodiments, the session identifiers may include one or more of a NAI Network Access Identifier (NAI), International Mobile Subscriber Identity (IMSI), Mobile Station International Subscriber Directory Number (MSISDN), Access Point Name (APN), and Name of the VRF used for the underlying session. In412, PGW110constructs a Subscriber Continuity Vendor Specific Mobility Option (SC-VSMO) field. In414, PGW110appends the SC-VSMO field to the O-PBU to generate a second binding update message, such as a new PBU message, of the format (O-PBU|SC-VSMO). In416, PGW110modifies the length field in the O-PBU mobility header to include the length of SC-VSMO, but does not recompute the contents of Authentication Option in the O-PBU. In417, PGW110recomputes the checksum in PBU header300(FIG. 3) if IPv6 protocol transport is used. In418, PGW110sends the new PBU including the O-PBU and the appended SC-VSMO to LMA114. The operations then end.

Referring now toFIG. 5,FIG. 5is a simplified flowchart500that illustrates example operations associated with a local mobility anchor (LMA) in accordance with one embodiment. In502, LMA114receives a PBU from PGW110which may be modified to include an appended SC-VSMO. In504, LMA114determines whether the SC-VSMO is present in the PBU. If it is determined in504that the SC-VSMO is not present whereas the LMA114is configured to expect SC-VSMO in a PBU, then in505LMA114determines whether the SC-VSMO in mandatory. If the SC-VSMO is determined to be mandatory, LMA114discards the PBU in506and the operations end. If the SC-VSMO is not determined to be mandatory, the operations continue to516. If it is determined in504that the SC-VSMO is present in the PBU, in508LMA114determines the original mobility header length in the O-PBU (as received by PGW110from first MAG104a). In510, LMA114restores the original mobility header length in the mobility header before validating the authentication option, if present, in the O-PBU. In512, LMA114parses the SC-VSMO for the subscriber identifiers. In514, LMA114copies the session identifiers from the SC-VSMO into a binding cache entry (BCE) in association with first MAG104a. The BCE contains mobility binding information which allows LMA114to tunnel traffic between first MAG104aand a server, such as first enterprise server118a, using one or more virtual tunnels.

In516, LMA114sends a PBA message addressed to first MAG104avia PGW110in which PGW110normally routes the PBA to first MAG104awithout performing any inspection and/or change to the PBA. In response to receiving and processing of the PBA by first MAG104a, in518one or more tunnels are setup between first MAG104aand LMA114. In520, VPN traffic is communicated between first MAG104aand a server, such as enterprise server118a, utilizing the one or more tunnels established between first MAG104aand LMA114. In one or more embodiments, first MAG104areceives the traffic communicated between first MAG104aand enterprise server118afrom one or more enterprise branch location devices such as first enterprise branch location device102aand second enterprise branch location device102b. The operations then end.

Referring now toFIG. 6,FIG. 6is a simplified block diagram of PGW110in accordance with one embodiment. PGW110includes one or more processors602, a memory element604, and a proxy binding message and subscriber mobility option processing module606. Processor(s)602is configured to execute various tasks of PGW110as described herein and memory element604is configured to store data associated with PGW110. Proxy binding message and subscriber mobility option processing module606is configured to perform the various proxy binding message and subscriber mobility option processing functions of PGW110as described herein.

Referring now toFIG. 7,FIG. 7is a simplified block diagram of LMA114in accordance with one embodiment. LMA114includes one or more processors702, a memory element704, and a proxy binding message and subscriber mobility option processing module706. Processor(s)702is configured to execute various tasks of LMA114as described herein and memory element704is configured to store data associated with LMA114. Proxy binding message and subscriber mobility option processing module706is configured to perform the various proxy binding message and subscriber mobility option processing functions of LMA114as described herein. Binding cache entry table708is configured to store one or more binding cache entries including subscriber identifiers associated with one or more MAGs, such as one or more of MAGs104a-104c. In a particular embodiment, the subscriber identifiers include one or more of a NAI Network Access Identifier (NAI), International Mobile Subscriber Identity (IMSI), Mobile Station International Subscriber Directory Number (MSISDN), Access Point Name (APN), and Name of the VRF used for an underlying session.

In one example implementation, enterprise branch location devices102a-102d, MAGs104a-104c, PGW110, LMA114, and enterprise servers118a-118care network elements that facilitate or otherwise help coordinate subscriber awareness activities (e.g., for networks such as those illustrated inFIG. 1). As used herein in this Specification, the term ‘network element’ is meant to encompass network appliances, servers, routers, switches, gateways, bridges, loadbalancers, firewalls, processors, modules, base stations, or any other suitable device, component, element, or object operable to exchange information in a network environment. Moreover, the network elements may include any suitable hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof. This may be inclusive of appropriate algorithms and communication protocols that allow for the effective exchange of data or information.

In one example implementation, enterprise branch location devices102a-102d, MAGs104a-104c, PGW110, LMA114, and/or enterprise servers118a-118cinclude software to achieve the operations, as outlined herein in this document. In other embodiments, this feature may be provided external to these elements, or included in some other network device to achieve this intended functionality. Alternatively, both elements include software (or reciprocating software) that can coordinate in order to achieve the operations, as outlined herein. In still other embodiments, one or both of these devices may include any suitable algorithms, hardware, software, components, modules, interfaces, or objects that facilitate the operations thereof.

In regards to the internal structure associated with communication system100, each of enterprise branch location devices102a-102d, MAGs104a-104c, PGW110, LMA114, and enterprise servers118a-118ccan include memory elements for storing information to be used in achieving the operations, as outlined herein. Additionally, each of these devices may include a processor that can execute software or an algorithm to perform the activities as discussed in this Specification. These devices may further keep information in any suitable memory element [random access memory (RAM), read only memory (ROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable ROM (EEPROM), 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 should be construed as being encompassed within the broad term ‘memory element.’ The information being tracked or sent to enterprise branch location devices102a-102d, MAGs104a-104c, PGW110, LMA114, and enterprise servers118a-118ccould be provided in any database, register, control list, cache, or storage structure: all of which can be referenced at any suitable timeframe. Any such storage options may be included within the broad term ‘memory element’ as used herein in this Specification. 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 the network elements and mobile nodes can also include suitable interfaces for receiving, transmitting, and/or otherwise communicating data or information in a network environment.

Although the present disclosure has been described in detail with reference to particular arrangements and configurations, these example configurations and arrangements may be changed significantly without departing from the scope of the present disclosure. For example, although the present disclosure has been described with reference to particular communication exchanges involving certain network access, and signaling protocols, communication system100may be applicable to other exchanges, routing protocols, or routed protocols. Moreover, although communication system100has been illustrated with reference to particular elements and operations that facilitate the communication process, these elements and operations may be replaced by any suitable architecture or process that achieves the intended functionality of communication system100.

In a separate endeavor, communication system100may generally be configured or arranged to represent a LTE and/or 3G architecture applicable to LTE and/or UMTS environments in accordance with a particular embodiment. However, the LTE architecture is offered for purposes of example only and may alternatively be substituted with any suitable networking system or arrangement that provides a communicative platform for communication system100. Moreover, the present disclosure is equally applicable to other cellular and/or wireless technology including 3G, CDMA, Wi-Fi, WiMAX, etc.