Patent Description:
Wireless networks provide voice and/or data services to User Equipment (UE) such as smartphones, laptops, tablets, and smart watches. Wireless networks may also provide what are known as mobility management services. Mobility management services are used to track/manage a connection between UE and the network as the UE moves across the network. For example, as a UE travels across a city, it may attach to a first base station to initiate a data session, and the network may handover the session to a second base station as the UE moves out of range of the first base station.

Mobility management settings are presently implemented on a network-wide basis. For example, in <NUM> Long Term Evolution (LTE) networks, if a UE is in an active Radio Resource Control (RRC) state for communicating with a base station, then a General Packet Radio Service (GPRS) Tunneling Protocol (GTP) is used to establish a GTP tunnel between the base station and a mobility anchor node, such as a Serving Gateway (SGW). A GTP tunnel is also established between the SGW and an Internet Protocol (IP) anchor node, such as a Packet Data Network (PDN) Gateway (PGW). Whenever the active UE attaches to a new base station, a GTP tunnel is established between the SGW and the new base station in order to preserve an IP address for the UE. However, GTP tunneling is associated with a substantial overhead burden, and GTP tunneling encapsulation and de-encapsulation may only be performed by specific types of router nodes in the network.

Alternatively, if UE is in an idle RRC state, LTE networks use mobility management services to track the UE differently. Specifically, the core network divides the Radio Access Network (RAN) into Tracking Areas (TAs) that each include a set of geographically proximate base stations. If the idle UE crosses the boundary between one TA and another, this change is reported to the core network. If an active connection with the idle UE is then desired (e.g., in order to transmit a packet of data to the UE), the core network triggers a broadcast (page) message using knowledge of the TA where the UE resides to track down the idle UE. <CIT> discloses a device network technology selection and display in multi-technology wireless environments.

Embodiments described herein provide for telecommunication networks that dynamically address the mobility needs of individual wireless devices. By programming elements of the network to address mobility management for wireless devices (and/or their applications) on an individual basis instead of a global basis, the network enhances both its efficiency and efficacy in serving customers. This means that changes in location for different applications and wireless devices may be handled using different techniques. For example, the network may forego tunneling and assign a local IP address for a device that is primarily stationary or nomadic. This helps to conserve network resources in situations where tunneling is neither necessary nor beneficial, while still preserving tunneling for other wireless devices or applications that may benefit from it.

One embodiment is a method for mobility management in a wireless network as claimed in claim <NUM>.

In a further embodiment, selecting the first active mobility setting and the first idle mobility setting from the mobility profile is based on a device type of the wireless device or an application identifier of an application on the wireless device.

In a further embodiment, the mobility profile includes a plurality of active mobility settings with respective ones of the plurality of active mobility settings corresponding with respective applications of the wireless device. Selecting the first active mobility setting includes selecting as the first active mobility setting a one of the plurality of active mobility settings that corresponds with a first application. Providing the first set of instructions to the first one or more network elements of the telecommunication network is based on the first active mobility setting for the first application.

In a further embodiment, the method also includes determining a change in state of the wireless device to the active state or the idle state, providing a set of instructions to a set of network elements in accordance with the first active mobility setting when the change is to the active state, and providing a set of instructions to a set of network elements in accordance with the first idle mobility setting when the change is to the idle state.

In a further embodiment, selecting the first active mobility setting is based on context information selected from the group consisting of: an operator policy that is defined for the telecommunication network and associated with the wireless device, subscriber analytics for the telecommunication network that indicate the behavior of the wireless device, and network analytics for the telecommunication network that indicate a level of traffic at the telecommunication network.

In a further embodiment, the first idle mobility setting indicates that a location of the wireless device should not be tracked by the telecommunication network while the wireless device is not transmitting data.

In a further embodiment, the first active mobility setting indicates that the telecommunication network set up a tunnel to provide Internet Protocol (IP) session continuity when the wireless device moves to a new base station while exchanging packets of data with the PDN.

In a further embodiment, the first active mobility setting indicates that the tunnel cover a limited geographic area of the telecommunication network.

In a further embodiment, the first active mobility setting indicates that the telecommunication network not set up a tunnel to provide Internet Protocol (IP) session continuity when the wireless device moves to a new base station while exchanging packets of data with the PDN.

In a further embodiment, the first idle mobility setting indicates whether to retain, while the UE is not exchanging packets with the PDN, an Internet Protocol (IP) address for the wireless device that was assigned while the wireless device was exchanging packets of data with the PDN.

In a further embodiment, programming the telecommunication network based on the first active mobility setting includes selecting a programmable network element as an Internet Protocol (IP) anchor for the wireless device.

In a further embodiment, programming the telecommunication network based on the first active mobility setting includes selecting a network element to serve as a mobility anchor for the wireless device.

Another embodiment is an apparatus as claimed in claim <NUM>.

Another embodiment is a computer program as claimed in claim <NUM>.

Other exemplary embodiments (e.g., methods and computer-readable media relating to the foregoing embodiments) may be described below.

Some embodiments of the invention are now described, by way of example only, and with reference to the accompanying drawings.

The figures and the following description illustrate specific exemplary embodiments of the invention. It will thus be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the invention and are included within the scope of the invention. Furthermore, any examples described herein are intended to aid in understanding the principles of the invention, and are to be construed as being without limitation to such specifically recited examples and conditions. As a result, the invention is not limited to the specific embodiments or examples described below, but by the claims and their equivalents.

<FIG> is a block diagram of a telecommunication (telecom) network <NUM> in an exemplary embodiment. Network <NUM> comprises any system operable to exchange data with wireless device <NUM> in order to provide voice and/or data services to wireless device <NUM>. Network <NUM> has been enhanced so that its various network elements (which may normally operate as switches/routers) are programmed dynamically in accordance with mobility profiles for individual wireless devices (e.g., smart phones, tablets, smart thermostats, etc.). For example, network control element <NUM> may provide instructions to (e.g., program) one or more network elements <NUM> to act as mobility and IP anchors for specific wireless devices.

In this embodiment, telecom network <NUM> utilizes multiple network elements to exchange data between wireless device <NUM> and PDN <NUM>. Specifically, wireless device <NUM> attaches to one of base stations <NUM> via a Radio Access Network (RAN) protocol in order to establish an air interface connection. The base station <NUM> that wireless device <NUM> is attached to then communicates with other network elements, as determined by network control element <NUM>, to establish a bearer that carries communications from the base station <NUM> to PDN <NUM>.

Network control element <NUM> is capable of providing instructions to the elements of network <NUM> to apply mobility settings from a mobility profile. Thus, in order to properly establish and maintain a bearer, network control element <NUM> (and more specifically controller <NUM>) may, according to the settings for a mobility profile, operator policy for the network, subscriber analytics for the subscriber, and/or network analytics for the network, program a Mobility Management Network Function (MMNF) of network functions <NUM> to track the base station <NUM> to which wireless device <NUM> is currently anchored. For example, the MMNF may further store and process state information associated with the mobility profile and settings provided by the control element <NUM>. If an idle mobility setting specifies idle-mode mobility for wireless device <NUM>, then controller <NUM> may assign a network element to serve as a selected Mobility Anchoring Element <NUM> for wireless device <NUM> and instruct the MMNF to track an area comprising several base stations <NUM> in which the wireless device <NUM> moves. When selected to perform the duties of a mobility anchoring element <NUM>, the network element buffers packets arriving from PDN <NUM> for wireless device <NUM> while the wireless device <NUM> is located by the MMNF. Meanwhile, if an active mobility setting specifies active-mode mobility for an application, a selected Internet Protocol (IP) anchoring element <NUM>, assigned by controller <NUM>, terminates tunnels for IP connections between wireless device <NUM> and applications in PDN <NUM>.

The types of data exchanges described above, where air interfaces and bearers are established/reserved for wireless device <NUM> in order to exchange data with a PDN, are referred to as "sessions," and are utilized by wireless device <NUM> while it is in the active state.

PDN <NUM> may comprise the Internet, a proprietary enterprise network, etc. and the like. Network <NUM> further includes multiple network elements <NUM> that may be programmed by network control element <NUM>, and an interconnection network <NUM> that provides communication channels between the various network elements described above.

In this embodiment, network control element <NUM> utilizes a hardware controller <NUM> (e.g., a processor and memory) and interface <NUM> (e.g., an Ethernet connection) to implement multiple functional modules. For example, a network policy module may apply network rules/policies to the wireless devices of network <NUM>, a wireless network module may program air-interface logic for base stations <NUM>, a network analytics module may track network load and resource usage, and a Software Defined Networking (SDN) module may program paths between switching elements of telecom network <NUM>.

Network control element <NUM> is capable of communicating with and/or accepting instructions from network functions <NUM> (e.g., functions such as mobility management, security, Quality of Service (QoS), network control and monitoring, optimization, etc.) implemented in the network. When network control element <NUM> programs network functions <NUM>, network control element <NUM> may do so based on whether or not mobility and IP anchors should be selected for wireless device <NUM>, based on whether IP addresses of wireless device <NUM> are preserved when wireless device <NUM> moves between base stations <NUM> while in the active state, etc. and the like.

Wireless device <NUM> is in the active state when it is actively communicating with applications to exchange packets of data (e.g., application layer packets) via PDN <NUM> whereas wireless device <NUM> is in an idle state when no packets are being exchanged between the device and applications on PDN <NUM> (i.e., when wireless device <NUM> is not involved in communications with external devices). This means that wireless device <NUM> may continue to perform some signaling in the idle state, but this signaling is not related to application layer content. While in the idle state, wireless device <NUM> may enter a power saving mode whereby a mobility management network function <NUM> may only track the location of the device <NUM> to a granularity consisting of many base stations <NUM> (e.g., a tracking area or the like). In a <NUM> network, the "active" state may correspond with an active RRC state, and the "idle" state may correspond with an idle RRC state.

As used herein, "applications" utilize the application layer of the Open Systems Interconnect (OSI) model, and do not alter the behavior of other layers of network <NUM> such as the transport layer, network layer, data link layer, or physical layer.

Further details of the operation of network <NUM> will be discussed with regard to <FIG>. Assume, for this embodiment, that wireless device <NUM> has just powered on within the range of a base station <NUM> of telecom network <NUM>.

<FIG> is a flowchart illustrating a method <NUM> for transmitting mobility profiles for wireless device <NUM> in an exemplary embodiment. The steps of methods <NUM>-<NUM> are described with reference to network <NUM> of <FIG>, but those skilled in the art will appreciate that methods <NUM>-<NUM> may be performed in other communication networks. The steps of the flowcharts described herein are not all inclusive and may include other steps not shown. The steps described herein may also be performed in an alternative order. <FIG> is provided as an example illustrating one embodiment of how a mobility profile could be indicated to a network control element.

In step <NUM>, a controller of wireless device <NUM> detects a base station <NUM>. For example, the controller may operate a transceiver to detect a periodically transmitted message from base station <NUM> that identifies base station <NUM>.

Once base station <NUM> has been detected, wireless device <NUM> knows that network <NUM> is available to connect with. Thus, the controller of wireless device <NUM> determines what mobility settings it desires to be used when communicating with network <NUM>. To this end, the controller of wireless device <NUM> identifies a mobility profile indicating how the network may perform mobility management for wireless device <NUM> (step <NUM>). These settings may be defined, for example, on an application-by-application basis, based on the capabilities of wireless device <NUM>, etc. and the like.

In step <NUM>, the controller of wireless device <NUM> generates a connection request (or other signaling message) for the base station <NUM> that was detected in step <NUM>. The controller inserts/includes the mobility profile within the connection request (e.g., attach request) in order to inform the network how mobility may be handled. For example, the connection request may explicitly list a preferred mobility setting for wireless device <NUM> (or an application thereof). In one embodiment, the request includes a mobility profile that explicitly lists multiple desired mobility settings.

In step <NUM>, the controller of wireless device <NUM> operates a transceiver to transmit the connection request to the base station <NUM>. After the connection request has been transmitted, wireless device <NUM> awaits a response from the corresponding base station <NUM> in order to receive the selected mobility option from network <NUM>.

<FIG> is a flowchart illustrating a method <NUM> for utilizing mobility profiles for wireless devices in an exemplary embodiment. Method <NUM> may be performed while wireless device <NUM> is waiting for a response to the connection request, and may be triggered in response to a base station <NUM> forwarding all or part of a connection request to network control element <NUM>. In further embodiments not covered by the claims, method <NUM> may be internally triggered by network control element <NUM> in response to changes in network <NUM>.

In step <NUM>, network control element <NUM> identifies a mobility profile that includes at least one active mobility setting, and at least one idle mobility setting for a wireless device. In one embodiment, the mobility profile is included with or identified by a connection request sent from wireless device <NUM> and received at interface <NUM>. Network control element <NUM> may receive the connection request either directly from base station <NUM>, or via an intervening element of network <NUM>. In a further embodiment not covered by the claims, the mobility profile is identified by detecting an event on network <NUM>, and selecting a mobility profile stored in memory that is associated with the event.

In step <NUM>, controller <NUM> selects a first active mobility setting and a first idle mobility setting from the identified mobility profile. The selection process is not limited to selecting/activating just one active mobility setting, but rather may include selecting multiple mobility settings desired for complying with the mobility profile. Selection of the active and idle mobility settings may be based on a variety of factors. For example, the settings selected may depend upon which application(s) are currently active on wireless device <NUM> (as indicated by one or more application identifiers), an operator policy that is defined for the network and associated with a subscriber for wireless device <NUM>, subscriber analytics for the network that indicate the behavior of a subscriber for wireless device <NUM>, a device type for wireless device <NUM>, network analytics for the network that indicate a level of traffic at the network, etc. and the like.

In step <NUM>, controller <NUM> determines, based on the first active mobility setting, a first set of instructions for a first one or more network elements to engage in mobility management while wireless device <NUM> is in an active state exchanging packets of data with PDN <NUM>. For example, controller <NUM> may determine how to program network elements. This may include deciding whether to program one or more network elements <NUM> to operate as mobility and/or IP anchors for wireless device <NUM>, selecting network elements <NUM> to serve in those roles, and other mobility settings that are relevant to servicing data traffic between wireless device <NUM> and PDN <NUM>. In step <NUM>, controller <NUM> determines, based on the first idle mobility setting, a second set of instructions for a second one or more network elements to engage in mobility management for the wireless device while wireless device <NUM> is in an idle state not exchanging packets of data with PDN <NUM>.

At this point, and iteratively in the future as communications change between wireless device <NUM> and PDN <NUM>, controller <NUM> determines in step <NUM> whether or not wireless device <NUM> is presently in the active state or the idle state. When wireless device <NUM> is in the active state, in step <NUM> controller <NUM> provides the first set of instructions to the first one or more network elements in accordance with the first active mobility setting. This may include programming network elements in accordance with the active mobility setting. When wireless device <NUM> is in the idle state, in step <NUM> controller <NUM> provides the second set of instructions to the second one or more network elements in accordance with the first idle mobility setting. In one embodiment, providing instructions to network elements includes selecting a base station or upstream anchor router node that will assign an IP address to wireless device <NUM> (e.g., using an appropriate mechanism such as Dynamic Host Configuration Protocol (DHCP)). Programming the network elements may include operations for implementing a selected mobility setting, and these operations may be based, for example, on the operator policies, subscriber analytics, and network analytics discussed above.

When used in this manner, method <NUM> provides a benefit over prior systems in that they allow individual wireless devices (including, for example, individual applications of a wireless device) to dynamically reduce their footprint in terms of network resources. This enhances the amount of available resources at network <NUM>, without unduly hampering the services that network <NUM> provides. In a further embodiment, mobility settings may be associated with applications (or entire groups of applications) of wireless device <NUM>, and controller <NUM> may select and/or program the network elements to comply with multiple mobility settings (e.g., one or more settings for each application of wireless device <NUM>).

<FIG> is a table <NUM> illustrating mobility settings in an exemplary embodiment. According to <FIG>, mobility settings are grouped into active and idle mobility settings. In this embodiment, active state mobility settings include "No Active Mobility," "Limited Active Mobility," and "High Active Mobility," and idle mobility settings include "No Idle Mobility," and "Idle Mobility.

According to <FIG>, a mobility setting for an application or device that is active may be "No Active Mobility," "Limited Active Mobility," or "High Active Mobility. " "No Active Mobility" is used for static devices, or when there are no applications being operated by the device that require seamless mobility (e.g., via GTP tunneling). "Limited active Mobility" indicates seamless mobility (and therefore GTP tunneling) within a limited geographic area (e.g., one square mile, a city, etc.) serviced by a known group of base stations, and "High Active Mobility" indicates seamless mobility over a wide area, such as when the device is located in a moving car.

According to <FIG>, a mobility setting for a device in an idle state may be "No Idle Mobility" or "Idle Mobility. " A "No Idle Mobility" setting means that a device is not tracked by the network when the device is not transmitting data. The "No Idle Mobility" setting is appropriate for devices that are stationary, for devices that are always active and hence have no need for an idle state mobility management scheme, and for devices that do not have a need to be reached from the network. For example, if communication is always triggered/initiated from the device, then there is no need for the network to track the device while in its idle state. An "Idle Mobility" setting means that the device will tracked by the network when it is idle, meaning that the device is reachable via either a triggering Application Programming Interface (API) or through the IP address that was previously assigned to the device. The "Idle Mobility - Trigger Only" setting refers to keeping the device reachable via an API, and the "Idle Mobility - Retain IP" setting refers to keeping the device reachable via an IP address. A triggering API call may be available even for a device that requires retaining its IP address in the idle state. Furthermore, since multiple IP addresses may be assigned to a device (e.g., one for each active application), multiple IP addresses may be retained in the network in the case of an "Idle Mobility - Retain IP" setting for a device.

Several factors affect how mobility settings are used for devices/applications. The active state mobility setting determines whether IP addresses are preserved as the device moves, and hence determines whether tunneling will be used. This impacts which node in the network will serve as the mobility anchor and the IP anchor (which is where the tunnels from base stations are terminated). A "No Active Mobility" setting means that no IP address preservation or tunneling is used. A "Limited Active Mobility" setting means that the device is expected to move across a small set of base stations and thus the mobility and IP anchor may be a local router. That is, tunneling may not be needed if all the base stations within the mobility area are interconnected by a Layer <NUM> network such as an Ethernet. A "High Active Mobility" setting means that the device will move over a wide area, and hence a mobility and IP anchor in a core network should be assigned.

In one embodiment, the mobility profile includes two sub-profiles, one corresponding to the active state and one corresponding to the idle state. The active state mobility profile applies when the device is in an active state, (i.e., actively exchanging packetized data with an application), while the idle state mobility profile applies when the device is idle (that is, when no applications on the device are actively exchanging data with a PDN). In one embodiment, the idle state profile includes just one setting that applies to the device as a whole, whereas the active state profile may include settings for both the device and one or more applications in the device. Individual mobility settings may be determined for a device as a whole and/or for a specific application (or class of applications) within the device. For example, mobility settings could be "No Active Mobility" for all applications on a device except for conversational applications such as voice. Thus, different application categories within a device may use different active mobility settings within the mobility profile for the device.

The active state profile and idle state profile may be independently defined. For example, if a wireless device is stationary and does not need to be reachable from the network, idle mode mobility setting of "No Idle Mobility" may be used, but when an application becomes active on the wireless device, a "High" or "Limited" active mobility management scheme may be desired to provide seamless service to the wireless device. Similarly, a mobile Machine to Machine (M2M) device may request a level of idle mobility to make it reachable from the network and to save battery power, but may elect not to request active mobility if its application flows are insensitive to momentary link disruptions. Lastly, for a wireless device that is less sensitive to power consumption, it may be desirable to always keep the device active.

<FIG> is a table <NUM> illustrating mobility profiles applied to wireless devices in an exemplary embodiment. According to <FIG>, each wireless device is associated with a mobility profile that includes at least one idle mobility profile, and at least one active mobility profile. The active mobility profile includes multiple active mobility settings, indexed by the application (or application category) that they apply to. For example, a Voice over Internet Protocol (VOIP) application for a smartphone may have an active mobility setting of "High Active Mobility," while a gaming application for the same smartphone may have an active mobility setting of "no active mobility.

In a further embodiment, network control element <NUM> actively changes mobility settings for a device and/or application based on the behavior of the device and/or application with respect to the network. Thus, if an idle device that generally remains static starts to move and is utilizing an application that requires seamless mobility, then network control element <NUM> dynamically reprograms elements of network <NUM> in order to initiate "Idle Mobility" and begin tracking the location of the device. If the device moves to the active state, then network control element <NUM> dynamically initiates "High Active Mobility," assigns an IP anchor to the device, and initiates tunneling of packets for the application used by the device. Similarly, if there are no data flows from an active device for a certain period of time, network control element <NUM> may release the IP anchor for the device, assign a new local IP address to the device, and set "No Active Mobility" for the active mobility setting for the device. The device may then use its new IP address when interacting with corresponding applications.

In a further example embodiment, if the idle state setting of the device is determined by network control element <NUM> to be "Idle Mobility," then a Mobility Management Control Application (MMCA) (one of network functions <NUM>) is configured by network control element <NUM> to track the device while the device is in the idle state. This is done through periodic or location driven Tracking Area (TA) updates sent from the device. In cases where the idle mobility setting is "No Idle Mobility," then the IP address(es) assigned to the device are released when the device is idle and the device is no longer reachable from the network. Further exemplary details of mobility settings and mobility management are provided below.

The mobility profile (including idle and active profiles) may be indicated either explicitly by the device when it first connects to the network or by reference to a profile maintained in the network. For example, devices may request a connection through a signaling link to network control element <NUM> (e.g., through a base station <NUM> and corresponding wireless network controller), and the request may include the mobility profile. In addition, a default mobility profile for each device may be maintained in the network (and referenced by the initial request or otherwise associated with the device, for example based on a device identifier). For example, for an M2M device such as a smart meter, the only mobility settings allowed by a mobility profile for the device could be "No Active Mobility" and "No Idle Mobility. " This does not mean that the smart meter cannot move to an adjacent base station because of changing radio conditions etc., but rather means that on-going connections will be terminated when a handoff to a new base station occurs, as a new IP address may be assigned for the device at that time.

Once the mobility profile has been determined, many factors may influence which mobility settings from the profile are applied to the device (and/or application thereof). Network control element <NUM> considers these factors, decides the applicable mobility settings and instructs the MMCA how to proceed. For example, location and time-of-day parameters may be used to select a mobility setting for the device. Thus, a smart phone that connects to the network from the home of the subscriber early in the morning or late at night could initially be assigned a "No Active Mobility" setting for active mobility since the device is not expected to move outside the home, which is typically covered by a single base station.

Additionally, historical information may be used to predict the most suitable default mobility setting from those included within a mobility profile. For example, historical information could show that a particular device always connects from a small set of base stations on all working days between <NUM> AM and <NUM> PM, presumably because the user of the device is at work in his/her office on most working days.

A specific active mobility setting may also be explicitly requested when an application is triggered. Network control element <NUM> then chooses to accept or deny the request based on the allowable mobility settings in the profile for the device that the application is running on.

The following description illustrates exemplary mobility management procedures that may be used for each mobility setting. These sections address the use of active mobility settings in embodiments where an initial request for connection is received from a device. The idle state mobility settings, and transitions from an idle state to an active state, are discussed after the active mobility settings.

This section described procedures for situations where a network control and monitoring function (one of network functions <NUM>) determines that the active mobility setting for a device/application is "No Active Mobility. " In this case, network control element <NUM> assigns the device a globally routable IP address in the IP subnet of the base station. The address may be assigned by network control element <NUM> itself, or network control element <NUM> may direct a base station <NUM> (or the nearest Layer <NUM> router if the base station <NUM> is not Layer <NUM>) to assign the IP address. Packet forwarding is then performed based on IP routing techniques (e.g., in a similar manner to IP routing on the Internet). Specifically, the base station forwards upstream packets towards the next hop router, and the border routers route downstream packets towards the base station by using the destination IP address of the device. If the device moves to a neighboring base station, that new base station sees the new flow from the device and triggers network control element <NUM> to provide a rule for handling the flow. Network control element <NUM> matches the IP five tuple of the flow to that of the flow in the previous base station, authenticates that the device is authorized, and triggers assignment of a new IP address belonging to the subnet of the new base station to be assigned to the device. When the new IP address is assigned, on-going flows are terminated and the device establishes new connections with its applications using the new IP address.

For the purposes of charging, the base stations <NUM> are directed by network control element <NUM> to meter the flows and periodically report one or more of packet count, byte count, and flow duration information to the network control element <NUM>. For offline charging, network control element <NUM> generates a charging record for the flows/device and sends the record to the charging application. For online charging, the network control element <NUM> compares the packet/byte count against a credit control limit provided by an online charging application. Upon exceeding the limit, network control element <NUM> will either request for additional credit or ask the base station to drop the flows until further credit is available.

If a network control and monitoring function determines that the device/application will use high-speed seamless mobility, then a router node that covers a larger number of base stations <NUM> in network <NUM> is chosen by network control element <NUM> as the mobility anchor. Network control element <NUM> directs this anchor router node to assign the IP address for the device from one of its domains, or network control element <NUM> assigns the address itself. The IP domain need not correspond to the current base station IP addresses, since packets from the device will be tunneled to the anchor node. Tunneling is established by network control element <NUM> to configure flow tables at the base station and the anchor router. The anchor and the tunnel are configured for the device immediately upon initial connection request. The mobility anchor may be chosen based on the domain of mobility expected for the application or device. For example, if prior history indicates that the device moves within a particular neighborhood of a city, then a router that serves the traffic for that region may be chosen as the mobility anchor for applications that require seamless mobility. Packets from the device are encapsulated at the base station using the address of the anchor as the destination and forwarded to the anchor node where the packet is de-encapsulated and forwarded toward the border routers. In the downstream direction, the packets destined for the device are routed towards the anchor since the IP address of the device is assigned from the IP domain of the anchor. At the anchor the packets are encapsulated to indicate the base station as their destination, and are then sent over the network toward the base station. At the base station the packets are de-encapsulated and sent over the air to the device.

When the active device moves from one base station to the next, an air-interface handoff is performed. The device then connects to the new base station and starts sending IP packets with the old IP address. The Layer <NUM> / Layer <NUM> switch part of the new base station sends a query to the controller to determine how to treat the new flow (since there is no flow table entry corresponding to the old IP address being used by the device). This triggers network control element <NUM> to provide a new configuration to the anchor router to handle tunneling to the new base station and also configures the new base station switch with appropriate flow table information to encapsulate and de-encapsulate packets towards the anchor node.

In an alternate embodiment, to ensure a successful handoff, the protocol may be designed so that the handoff is triggered by the old base station sending a request to a mobility management function in order to configure the new base station. In this case, the mobility management function verifies availability of resources at the new base station and then requests that network control element <NUM> configure the flow table in the new base station. Network control element <NUM> then triggers forwarding of unsent packets from the old base station to the new base station. This process may use a specialized handoff signaling protocol between the base stations.

If the device moves outside the area served by the anchor router, then a new router further upstream may be selected as the tunnel end point. This improves the efficiency of the packet flow and prevents triangular routing scenarios from arising. In this case, flow tables entries for the flow are updated in the source and target router end points.

This situation may apply when the active mobility of a device is restricted to a set of base stations that cover a limited geographic region (e.g., a city, neighborhood, building, etc.) and are inter-connected by a Local Area Network (LAN) to a gateway router. In this case, instead of establishing the gateway router node as the anchor with packets tunneled between the base station and the gateway, mobility may be handled by advertising/broadcasting for devices attached on the LAN. Such a scenario is applicable in an enterprise environment. Specifically, when a device moves from one base station to the next on the LAN, the new base station, using Address Resolution Protocol (ARP), informs the other nodes on the LAN (including the gateway node) that the device is now attached to it. This enables the gateway router to forward the packets to the correct base station in the LAN.

If the Idle Mobility setting (e.g., as determined by a network control and monitoring function) is "No Idle Mobility," then the device is not tracked by the network during idle periods. Packets from network based applications to the device with any previously established IP addresses will be dropped. For the device to be reachable by the network as it moves through the network, the device connects to a new base station and executes one of the procedures associated with active mobility.

To conserve battery and reduce network signaling, wireless devices may support "Idle Mobility" settings. When a device attaches to the network, idle mobility management may be instantiated by a network control and monitoring function according to a mobility profile included in the device's request for service and/or available in a stored profile. Furthermore, the mobility profile may include an idle mobility setting that indicates the need for retaining the IP address of the device when it is in idle state, or an idle mobility setting that indicates that applications should trigger the device using a network API to establish a connection, or a mobility setting that indicates that no IP address for the device should be retained. The second scenario is referred to as "Idle Mobility - Retain IP," while the first scenario is referred to as "Idle Mobility - Trigger Only. " If granted by a network control and monitoring function, instantiation of this request takes place in an MMCA which creates a session for the device. In either case, for each device that is in an idle state, the MMCA maintains a service area similar to a tracking area in LTE. Information is then tracked at the MMCA indicating the device's current service area (normally encompassing many base stations). When an idle device crosses into a new service area, it initiates an exchange with the MMCA to update the information at the MMCA. Otherwise the device is not required to exchange information with the network while idle.

In this scenario, when the device initially attaches, or when it re-attaches to a new base station when its active mobility setting is "No Active Mobility," the device is assigned a global IP address from the domain of an anchor switch so that packets coming from network <NUM> that are addressed to the device arrive at the anchor node. In some circumstances, the base station where the device was last active is the anchor, and hence there is no tunnel from the anchor to the serving base station. When the device transitions from active to idle, an SDN module of network control element <NUM> instructs switches of network <NUM> to remove flow tables associated with device flows. When subsequently a packet arrives in the network for the device/application, it arrives at the anchor switch and the switch queries the SDN module for forwarding instructions. The SDN module may queries the MMCA, which locates the appropriate base station by broadcasting messages to page the device.

Based on the access node from which the device responds, the MMCA sends an SDN module the current device location and the location of other anchors associated with applications on the device. The SDN module then sends forwarding instructions to the switches. At this stage the device is in an intermediate "Reactivation State," and the flow tables of all anchors (e.g., including anchors that correspond to other dormant applications) are updated to route packets to the base station where the device is currently attached. No new IP addresses are assigned.

In this case, an application that attempts to reach the device invokes an API call that identifies the device to the MMCA. This may occur whenever the application does not have an active session with the device (or an application thereof) and attempts to establish a new session. In the API call, an application identifier such as the Uniform Resource Locator (URL) of the server where the device is trying to establish a session is passed to the MMCA as a parameter in the API. Upon receiving the API call from an application, the MMCA pages the device with broadcast messages across the service area, and includes the application identifier in the message. Once the device receives this message, it triggers an application client on the device in order to establish an active session with the server. When the first packet is sent from the device, a switching component of the base station has no corresponding flow filter. Hence, the base station sends a query to a SDN module of network control element <NUM>, which in turn queries the MMCA for the mobility state to be used with the application. Upon instruction from network control element <NUM> to service the flow, a new IP address is assigned to the device and an active mobility setting is invoked/applied.

The advantage of the trigger only case (relative to retaining the IP address) is that it avoids the overhead associated with assigning a permanent IP address from a central anchor node. The trigger only case also provides support for dormant applications, combining mobility management with a push service similar to the Google Cloud Messaging and Apple Push Notification services.

When one of the applications on the device attempts to communicate with a network side application or when a trigger is received by the MMCA, the device will transition from idle to active. When transitioning from "No Idle Mobility" or "Idle Mobility - Trigger Only" settings to an active state, any of the above active mobility procedures may be applied (including the assignment of a new IP address to the device/application) in accordance with the active mobility setting for the device/application.

When a network based application sends a packet to an idle device, the device is paged and connects with a new base station. Then, packets are sent between the mobility anchor and the base station where the device is located. When the mobility anchor is not co-located with the base station, tunnels are established by modifying flow table entries. The device is said to be in a "reactivation" state at this point. Network control element <NUM> updates the flow tables of any other anchor in the network (corresponding to other dormant applications) for the device so that any packets from the network for any other dormant application are routed to the device. Subsequently, when any of the applications on the device with a "No Active Mobility" setting are triggered, a new IP address is assigned locally, and appropriate procedures described above are executed in subsequent handoffs. For "High Active Mobility" and "Limited Active Mobility" settings, the IP address retained during the idle state will continue to be used and the above procedure will apply on subsequent handoffs. The device transitions from a reactivation state to an active state after it has been notified by the MMCA that all flow tables associated application anchor points have been updated by the SDN module.

In one embodiment, independent of the active mobility setting used, a tunnel is set up from the anchor to the new base station. This allows packets from the application server to be delivered to the device. This does not affect subsequent behavior which is dependent on the active mobility setting of an application. If an application has "No Active Mobility" as its active mobility setting, then the connection through the tunnel established to provide initial connectivity with the application server is later dropped. If however the application has "High Active Mobility" or "Limited Active Mobility" as its active mobility setting, then the connection through the tunnel established to provide initial connectivity with the application server is maintained when the device moves. In this case the SDN module updates the flow tables at the anchor so that packets are forwarded to the new base station.

In further embodiments, network control element <NUM> is capable of altering the mobility setting and/or profile for a device/application, based on the behavior of the device/application. For example, suppose that a device initially starts operating with a "No Active Mobility" setting, and subsequently requests a "High Active Mobility" setting for a new application. There are several techniques that may be used to address this issue.

According to the first technique, if the application is already active then network control element <NUM> picks a suitable anchor in the network that is on the path towards the current base station and dynamically modifies the flow table in that node to activate tunneling of packets towards the current base station. For example, the anchor could be a border router through which packets were being received at the base station. At the same time, network control element <NUM> also updates the flow table in the base station to perform encapsulation and de-encapsulation for the flows to and from the device. Once the anchor is in place and properly configured, as the device moves, the mobility management algorithm described in previous sections is applied.

According to a second technique, if the application is already active then network control element <NUM> picks the current base station as the anchor. When the device moves, network control element <NUM> updates the flow table in the old base station so packets are forwarded to the new base station. Packets received from the new base station are de-encapsulated at the old base station and forwarded to the application server.

According to a third technique, network control element <NUM> directs the application to use a new IP address corresponding to an anchor in the network. The IP address may be newly assigned, or previously assigned to the device for use by other applications. The application may establish a new session with its application server, but IP session continuity is supported for subsequent handoffs.

In the following examples, additional processes, systems, and methods are described in the context of an example for a bedside sleep monitor, and an example for a mobile phone.

In this example illustrated in block diagram <NUM> of <FIG>, a bedside sleep monitor <NUM> remotely connects to a healthcare application in a hospital via a network <NUM>. The role of the monitor is to periodically upload data to a corresponding application maintained at the hospital. In this example, monitor <NUM> uses Hypertext Transfer Protocol (HTTP) to perform this task. If the connection breaks during an upload of monitoring data, a new connection may be established between monitor <NUM> and base station <NUM> without substantial delay. Therefore, seamless mobility is not required for bedside monitor <NUM>. Monitor <NUM> includes a mobility profile, and the mobility profile indicates the "No Active Mobility" setting for the device. This is because monitor <NUM> stays active, is not expected to move, and remains connected to the network when monitoring a patient. At other times when monitor <NUM> is idle, no network initiated connectivity is required. Hence the mobility profile indicates that monitor <NUM> should use the "No Idle Mobility" setting. A network diagram according to the proposed mobility management scheme is illustrated in <FIG>.

The process for handling monitor <NUM> is as follows. First, monitor <NUM> establishes a signaling connection with a detected base station <NUM> and sends a connection request that includes a mobility profile with settings for "No Idle Mobility" and "No Active Mobility. " Second, a wireless management component (Layer <NUM>, Layer <NUM>, Radio Resource Control (RRC), etc.) of base station <NUM> sends the request to wireless network module <NUM> of network control element <NUM>. A connection to monitor <NUM> is then established (including authentication processes for monitor <NUM>). This involves exchanging information with network functions <NUM>, including mobility management function <NUM> and security function <NUM>.

In a third step, mobility management function <NUM>, upon analyzing the connection request, grants the mobility requested and instructs network control element <NUM> in executing "No Active Mobility" procedures for monitor <NUM>. The mobility management function <NUM> also executes "No Idle Mobility" by not storing idle mobility state information. A fourth step includes SDN module <NUM> configuring/programming a Layer <NUM> switch in base station <NUM> with required information to establish layer <NUM> connections for the device. This includes IP address assignment rules, setting up the flow table for packet forwarding, and setting up flow metering for performing accounting. Base station <NUM> then performs the necessary tasks to allow packet flow between monitor <NUM> and health care network <NUM>.

In a fifth step, packets flow between monitor <NUM> and an application of health care network <NUM> through aggregation router <NUM> and provider edge service router <NUM>. Measurement reports periodically sent from monitor <NUM> may indicate to base station <NUM> that because of changing radio conditions, a new base station <NUM> is preferred. This initiates a sixth step of air-interface handoff signaling between original base station <NUM> and new base station <NUM>. The handoff signaling confirms that there are sufficient resources in new base station <NUM>, and also forwards any untransmitted air-interface packets to new base station <NUM>. This step also includes signaling to inform the device to handover.

In a seventh step, after handover processes initiate, monitor <NUM> starts to send packets to new base station <NUM> with the IP addressed assigned by original base station <NUM>. A switching component of base station <NUM> recognizes a new flow and sends a query to the network control element <NUM> for instructions to handle the flow in an eighth step.

In a ninth step, SDN control module <NUM> in network control element <NUM> determines that it is utilizing a "No Active Mobility" policy for the flow in its policy base as result of the instruction received from mobility management function <NUM> received in step three. Hence network control element <NUM> sends instructions to base station <NUM> to drop the flow and reassign a new IP address to monitor <NUM> from the subnet of base station <NUM>. This is done so that new incoming packets are routed directly to base station <NUM>.

In a tenth step, upon setting up a new connection, packets start flowing through the new base station. Monitor <NUM> then establishes a new Transmission Control Protocol (TCP) connection to the network side application with the new IP address.

In the embodiment shown in block diagram <NUM> of <FIG>, a user of smart phone <NUM> initiates an in-home connection with a video streaming service <NUM>. Assume it is determined that behavioral patterns indicate that the user is likely to remain at home and stay attached to the same base station <NUM> for a long period of time. This determination may be made known to the network based on one or more of the identity of the base station <NUM>, the time when the initial connection is requested (e.g., after working hours), and prior history stored in a profile for the user. Hence, for the initial connection a "No Active Mobility" procedure is followed. However, mobility management function <NUM> (of network functions <NUM>) instructs network control element <NUM> to transition smart phone <NUM> to a "High Active Mobility" setting upon the first handover to a different base station (since this indicates that the user may be leaving the house and traveling to a new location).

The first though eighth steps are performed in the same manner as described for <FIG> (e.g., between elements <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, and <NUM>, and <NUM> as described with regard to their corresponding elements in <FIG>). However, in the third step, mobility management function <NUM> provides a rule that "No Active Mobility" should be switched to "High Active Mobility" upon first handoff event.

In a ninth step for this example, when a request comes from new base station <NUM>, network control element <NUM> selects a suitable mobility anchor for the flows from smart phone <NUM>. There are two possible options for the anchor. In a first embodiment, old base station <NUM> is chosen as the anchor and the SDN module <NUM> configures old base station <NUM> and new base station <NUM> to establish a tunnel to transfer packets on downlink and uplink. The IP address and end-to-end connection are maintained between smart phone <NUM> and applications on video streaming service <NUM>. In a second embodiment, an upstream aggregation router <NUM> is chosen to be the anchor. In this embodiment new base station <NUM> is provided with flow table updates for the flows from smart phone <NUM> to be encapsulated in IP-in-IP tunnels towards aggregation router <NUM>. In this case, the IP address (assigned by old base station <NUM>) and the end-to-end connection are maintained between smart phone <NUM> and the applications of video streaming server <NUM>. Although most packets are intercepted at the anchor, packets that are delivered to old base station <NUM> without going through the aggregation router <NUM> are forwarded to the anchor. Hence, in addition to selecting the anchor, old base station <NUM> is configured to tunnel any packets it receives for smart phone <NUM> to aggregation router <NUM>.

In either case, old base station <NUM> retains the settings for smart phone <NUM>, including the IP address assigned. Subsequently when the IP flow terminates for all applications using that IP address or when smart phone <NUM> goes idle, a new IP address and/or anchor may be assigned, and the client application on smart phone <NUM> will re-register with the corresponding application of video streaming service <NUM>.

In a tenth step for this example, the new anchor is configured by network control element <NUM> by providing instructions to encapsulate packets sent towards the current base station and to de-encapsulate packets sent in opposite direction. The anchor is also configured by network control element <NUM> in order to perform metering.

With respect to this example, in an eleventh step , packets to and from smart phone <NUM> are tunneled between the base station and the anchor. Then in a twelfth step, as smart phone <NUM> continues moving, an additional handoff event is triggered. New base station <NUM> then queries network control element <NUM> to determine how to process flows from base station <NUM> in a thirteenth step. In a fourteenth step, network control element <NUM> reconfigures the tunnel end point in the anchor to new base station <NUM>. Then, in a fifteenth step, network control element <NUM> provides base station <NUM> with the anchor address and tunneling instructions. The IP address of smart phone <NUM> is therefore preserved, and the flow of data continues seamlessly.

Any of the various elements shown in the figures or described herein may be implemented as hardware, software, firmware, or some combination of these. Dedicated hardware elements may be referred to as "processors," "controllers," or some similar terminology. Moreover, explicit use of the term "processor" or "controller" should not be construed to refer exclusively to hardware capable of executing software, and may implicitly include, without limitation, digital signal processor (DSP) hardware, a network processor, application specific integrated circuit (ASIC) or other circuitry, field programmable gate array (FPGA), read only memory (ROM) for storing software, random access memory (RAM), non volatile storage, logic, or some other physical hardware component or module.

Also, an element may be implemented as instructions executable by a processor or a computer to perform the functions of the element. The instructions may be stored on a non-transitory media or storage devices that are readable by the processor.

Claim 1:
A method for mobility management in a wireless network (<NUM>), comprising:
Identifying (<NUM>), by a network control element (<NUM>) at a telecommunication network, a mobility profile (<NUM>) that includes at least one active mobility setting and at least one idle mobility setting for a wireless device (<NUM> O); wherein the mobility profile is included with or identified by a connection request sent from the wireless device;
selecting (<NUM>) by the network control element (<NUM>) a first active mobility setting and a first idle mobility setting from the mobility profile;
determining (<NUM>), by the network control element (<NUM>) based on the first active mobility setting, a first set of instructions for a first one or more network elements (<NUM>) to engage in mobility management for the wireless device while the wireless device is in an active state exchanging packets of data with a Packet Data Network, PDN, via the telecommunication network;
determining (<NUM>), by the network control element (<NUM>) based on the first idle mobility setting, a second set of instructions for a second one or more network elements (<NUM>) to engage in mobility management for the wireless device while the wireless device is in an idle state not exchanging packets of data with the PDN via the telecommunication network;
providing (<NUM>) by the network control element (<NUM>) the first set of instructions to the first one or more network elements in accordance with the first active mobility setting when the wireless device is in the active state; and
providing (<NUM>) by the network control element (<NUM>) the second set of instructions to the second one or more network elements in accordance with the first idle mobility setting when the wireless device is in the idle state.