Patent Publication Number: US-9888422-B2

Title: System and method for adaptive access and handover configuration based on prior history in a multi-RAT environment

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application claims the benefit of U.S. Provisional Patent Application No. 61/830,567, filed Jun. 3, 2013, and U.S. Provisional Patent Application No. 61/892,378, filed Oct. 17, 2013, each of which is incorporated by reference herein in its entirety. 
    
    
     FIELD OF THE INVENTION 
     This application relates generally to wireless networks and, more specifically, to handovers between networks using different radio access technologies. 
     BACKGROUND 
     Wireless technologies have become an integral part of communications used by individuals. Traditional cellular networks have evolved to provide both voice and data services to users. In addition, networks such as wireless LANs (e.g., 802.11) and WiMAX (e.g., 802.16e) networks have emerged to provide wireless connectivity to data networks such as the Internet. Because of the increased availability of multiple types of wireless networks, user devices have been developed to work on multiple types of wireless networks. 
     These user devices supporting multiple networks typically do not operate on two different networks simultaneously. As a result, the device is required to select a network for communications. Cellular networks (e.g., 3G, 4G, LTE networks) typically have larger coverage areas than wireless data networks (e.g., 820.11). Therefore, in some areas, a user may only be able to access and utilize voice and data services through a cellular network. However, when a user enters an area covered by a cellular network and a wireless data network (e.g., 802.11), the device must select a network for communications. For certain types of traffic such as data, it may be beneficial to hand over the communication from a cellular network to the data network. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES 
       The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the embodiments of the present disclosure and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the pertinent art to make and use the embodiments. 
         FIG. 1  illustrates an exemplary operating environment for optimizing handover and/or predicting the need for a handover, according to embodiments of the present disclosure. 
         FIG. 2  depicts an exemplary user device, according to embodiments of the present disclosure. 
         FIG. 3A  depicts a multi-RAT controller for optimizing access and handover decisions, according to embodiments of the present disclosure. 
         FIG. 3B  depicts a multi-RAT controller for predicting the need for further handovers and preparing for predicted handovers, according to embodiments of the present disclosure. 
         FIG. 4  depicts an exemplary pathway performance metrics profile for one or more applications, according to embodiments of the present disclosure. 
         FIG. 5  depicts a flowchart of a method for generating performance metrics for a user device application, according to embodiments of the present disclosure. 
         FIG. 6  depicts a flowchart of a method for generating performance metrics for a user device application, according to embodiments of the present disclosure. 
         FIG. 7  depicts a further operating environment for predicting the need for a future handover, according to embodiments of the present disclosure. 
         FIG. 8  depicts a flowchart for a method of predicting the need for a future handover and preparing for future handovers, according to embodiments of the present disclosure. 
     
    
    
     The embodiments of the present disclosure will be described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number. 
     DETAILED. DESCRIPTION 
     In the following description, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the present disclosure. However, it will be apparent to those skilled in the art that the embodiments, including structures, systems, and methods, may be practiced without these specific details. The description and representation herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring aspects of the invention. 
     References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. 
     Systems and methods for adaptive access and handover configuration based on historical data are provided. In an embodiment, access and handover decisions are optimized in a multiple radio access technology environment using historical data associated with network performance. In another embodiment, future needs for access and handovers are predicted using historical data associated with the user and historical data associated with network performance. Preparations for the predicted handovers can then be made prior to the handover event. 
       FIG. 1  depicts an exemplary operating environment  100  for optimizing handovers and/or predicting the need for a future handover in a multi-RAT environment, according to embodiments of the present invention. Operating environment  100  includes multiple types of wireless networks—network A  120 , network B  140 , and network C  160 . Each network utilizes a different radio access technology (RAT) for communication between a device and the network access component (e.g., base station, evolved NodeB (eNB) or access point) over the air interface. A RAT is typically directed to certain types of traffic. For example, CDMA, FDMA, OFDMA, GSM are directed to voice traffic and 802.11 and 802.16(e) are directed to data traffic. 
     Network A  120  may be a cellular network such as a third generation (3G), fourth generation (4G), or LTE network. The RAT utilized by Network A may be, for example, CDMA, W-CDMA, CDMA2000, FDMA, OFDMA or similar. Network A includes multiple base stations  122  (or eNBs) and a core network  130 . Core network  130  includes multiple switching or routing elements  132 . In embodiments, core network  130  is a public switched telephone network (PSTN). 
     Network B  140  may be a cellular network utilizing a different RAT than Network A or may be a broadband wireless network such as a network utilizing 802.16 (WiMAX). Network B includes multiple base stations  142  and a core network  150 . Core network  150  includes multiple switching or routing elements  152 . 
     Network C  160  may be a wireless data network such as a wireless local area network (LAN) based on IEEE 802.11. Network C includes multiple access points (APs)  162  and a core network  170 . Core network  170  includes multiple routers  172 . In embodiments, core network  170  is a public data network such as the Internet, a private data network, or a combination thereof. 
     Operating environment  100  includes multiple user devices  110 . A user device  110  may be any wireless device such as a mobile phone, laptop, PDA, etc. In embodiments, user device  110  supports multiple RATs (e.g., CDMA, GSM and/or WLAN). When user device  110  travels between coverage areas, a handover occurs. During a handover (also referred to as a handoff), a wireless device changes its primary association from the current serving network access device (e.g., base station or access point) to another network access device. A handover may be triggered by a variety of factors such as a decrease in link quality or network loading. When user device  110  travels between coverage areas using the same RAT, a horizontal handover occurs. When user device  110  travels between coverage areas between networks using different RATs (e.g., Network A and Network B), a vertical handover occurs (i.e., RAT changed). 
       FIG. 2  depicts an exemplary user device  210 , according to embodiments of the present disclosure. User device  210  is a multi-RAT device. Therefore, user device  210  includes at least two RAT communications modules  214 . Each RAT module  214  is configured to support a specific radio access technology. For example, RAT module  214   a  may support a cellular protocol such as CDMA, OFDMA, or GSM and RAT module  214   n  may support a data network protocol such as 802.11. 
     User device  210  further includes a processor  216  configured to execute one or more applications  212 . Applications  212  may include, for example, e-mail, a video player, an audio player, games, etc. User device  210  also include multi-RAT access handover module  218 . In an embodiment, multi-RAT access handover module  218  is configured to generate performance metrics associated with the device and/or applications running on the device and report these metrics to the network. For example, the multi-RAT access handover module  218  may periodically send reports to the multi-RAT controller  180  via one of its RAT modules  214 . In an alternate embodiment, multi-RAT access handover module  218  is configured to make a determination of whether to accept the handover request from the network or initiate a handover request. For example, user device  210  may store a history that indicates a predicted upcoming need for heavy usage beyond the capability of a soon to be available AP and avoid a handover to that AP. 
     Returning to  FIG. 1 , operating environment  100  further includes a multi-RAT controller  180 . Multi-RAT controller  180  is coupled to one or more components in Network A, one or more components in Network B, and one or more components in Network C. In an embodiment, multi-RAT controller  180  is configured to optimize access and handover decisions in a multi-RAT operating environment such as the environment of  FIG. 1 . In a further embodiment, multi-RAT controller  180  is configured to predict a future need for handovers and to make preparation for the predicted handovers. Although illustrated as a centralized controller, in embodiments, multi-RAT controller  180  can be distributed or cloned in one or more networks. 
       FIG. 3A  depicts a multi-RAT controller  380 A for optimizing access and handover decisions, according to embodiments of the present disclosure. Multi-RAT controller  380 A includes storage  382 A and a performance metric module  386 A and a multi-RAT access and handover module  388 A. Performance metric module  386 A is configured to receive network performance metrics for an application from user devices  110  and network nodes. Performance metric module  386 A is further configured to compile these metrics into historical application profiles and/or to generate a performance map for each application. Performance metric module  386  may access a network topology map when compiling the application profile and/or generating the performance map. An exemplary operation performed by performance metric module  186  is described in  FIG. 5  below. 
     The performance metrics may include communication performance indicia or any other type of information regarding the operation of any node in a network. The performance metrics may indicate observed network latency, network stability information, a number of connected users, Q-depth, RF environment information such as a number of communication channels, frequency, bandwidth, error rates, network loading information, quality of service (QoS) information, a node address and/or identification, security information, date and/or time of day, and/or operational information above one or more network access devices such as battery life and/or operational status. 
     Performance metrics may include any of the aforementioned metrics specific to a particular pathway between a user device and a destination element (e.g., server). A network element (e.g., node) may include functionality to monitor and/or measure performance metrics and send these performance metrics to the multi RAT controller. 
     Multi-RAT access and handover module  388 A is configured to determine the optimal handover path for a device running an application, according to embodiments of the present disclosure. An exemplary operation performed by multi-RAT access and handover module  388 A is described in  FIG. 6  below. 
     Storage  382 A is configured to store historical profiles for one or more user applications (pathway performance metrics profile)  383 A and an optional performance map  384 A for each application. In addition, storage  382 A may include a topology map  385 A for one or more networks served by multi-RAT controller  380 A. Topology map  385 A may include a listing of network elements present in the network and the interconnection options for the network elements. 
       FIG. 4  depicts an exemplary pathway performance metrics profile  483  for one or more applications, according to embodiments of the present disclosure. Pathway performance metrics profile  483  may include pathway metrics for multiple applications. As illustrated in  FIG. 4 , for an application, metrics for an application are compiled for network nodes in a path. These metrics can then be used to generate a performance map for each application. 
     In embodiments, a network operator may use the pathway performance metrics profile  483  to indicate whether a network node requires upgrading or replacement. For example, a network operator may upgrade a network node that is frequently used for high bandwidth applications for given performance metric criteria. 
       FIG. 5  depicts a flowchart  500  of a method for generating performance metrics for a user device application, according to embodiments of the present disclosure. Flowchart  500  is described with reference to  FIGS. 1, 2 and 3A . However, flowchart  500  is not limited to those embodiments. 
     In step  510 , the user device launches and runs an application. The application communicates with a terminating device such as a server while running the application. For example, user device  120  may launch and run a video streaming application having content stored on a network server. 
     In step  520 , the user device generates performance metrics for the application and reports these metrics to the multi-RAT controller  180 . For example, the report may be sent through a network access point to the multi-RAT access and handover controller. 
     In step  530 , each node in the communications path generates performance metrics for the application and reports these metrics to the multi-RAT controller. 
     In step  540 , the multi-RAT controller compiles the received measurements and generates or updates the pathway performance profile for the application. Over time, a geography mapped interface plus time map can be generated for the application. 
       FIG. 6  depicts a flowchart  600  of a method for generating performance metrics for a user device application, according to embodiments of the present disclosure. Flowchart  600  is described with reference to  FIGS. 1, 2 and 3A . However, flowchart  600  is not limited to those embodiments. 
     In step  610 , user device  110  synchronizes with a network access device such as a base station  122  or access point  162 . 
     In step  620 , user device  110  launches an application  212 . During operation, application  212  accesses a network device such as a server. 
     In step  630 , a handover is indicated for user device  110 . For example, if user device  110  is moving, user device  110  may leave the coverage area of one network access device and enter the coverage area of one or more network access devices. 
     In step  640 , user device  110  takes measurements and reports available network access devices. For example, user device  110  may perform a scan and identify a set of access points available for handover. 
     In step  650 , the identified handover options are transmitted to multi-RAT controller  180 . In embodiments, additional information may also be provided to multi-RAT controller such as an identification of the application, identification of any streams associated with the application, and/or performance metrics associated with the current connection. For example, the receiving network may forward the identified handover options and information regarding the application being used by the user device to the multi-RAT controller. 
     In step  660 , multi-RAT controller  180  selects the optimal handover path for the application running on user device  110  based on the stored profiles. For example, multi-RAT controller  180  may access the network performance map for the application. Using the map, the multi-RAT controller identifies the path and/or network nodes that have historically provided the best performance for the application. If user device  110  is running multiple applications, multi-RAT controller  180  may access the network map for both applications and select a path that provides the optimal performance for both applications. In alternate embodiments, multi-RAT controller  180  uses the pathway performance profile for an application when selecting the optimal handover path. 
     In step  670 , the handover path is communicated to the network access device currently serving user device  110 . The handover path indicates the network access device (e.g., an access point) to handover the connection. 
     In step  680 , a handover to the network access device in the handover path is initiated. 
       FIG. 7  depicts a further operating environment  700  for predicting the need for a future handover, according to embodiments of the present disclosure.  FIG. 7  depicts a predicted travel path for a user device  710  over a specified time period (t 0  to t 4 ). As described further below, the predicted travel path may be estimated using historical travel patterns for user device. 
     In an embodiment, user device  710  is running an application that requires connection to device  790  (referred to as a “terminating device”). Device  790  may be a server, another network node, or an end user device. User device  710  may be connected to device  790  via a number of paths during the time period (t 0  to t 4 ). For example, path A may be through base station  712   a  and switch  732   b  to device  790 . Path B may be through AP  762   a  through routers  768   a  and  768   b  to device  790 . Path C may be through AP  762   b  through routers  768   a  and  768   b  to device  790 . Additional paths can be formed through AP  762   c , AP  762   d , AP  762   e  and base station  722   b . As would be appreciated by persons of skill in the art, various routing or switching paths can be used in each core network  730 ,  770 . 
     In an embodiment, multi-RAT controller  780  of  FIG. 7  is configured to predict optimal handovers for user device  710  during the prediction time period t 0  to t 4 . The handover prediction may be based on a number of factors including user mobility, device or application need for signaling, historical performance of available paths, and data associated with other users or applications having similar attributes as the user. Once future handovers are predicted, multi-RAT controller  780  is configured to make preparation for those handovers by communicating information to the potential service access devices (e.g., AP  162   c , AP  162   e , etc.) 
       FIG. 3B  depicts a multi-RAT controller  380 B for optimizing access and handover decisions, according to embodiments of the present disclosure. Multi-RAT controller  380 B includes storage  382 B, performance metric module  386 B and multi-RAT access and handover module  388 B. Performance metric module  386 B was described above in relation to  FIG. 3A  and  FIG. 5 . 
     Multi-RAT access and handover module  388 B is configured to predict a future need to handover a communication connection using historical user data, application profiles, and historical network performance metrics for the application. In addition, multi-RAT access and handover module  388 B is further configured to prepare for the predicted handovers in advance of a handover event. Exemplary operation of multi-RAT access and handover module  388  is described in further detail in  FIG. 8  below. 
     Storage  382 B includes user historical data  381 , application profiles  387 , pathway performance metrics profiles  838 B, application performance maps  384 B, and network topology maps  835 B. Pathway performance metric profiles  838 B, application performance maps  384 B, and network topology maps  835 B were described above with reference to  FIG. 3A . 
     User device profile  381  may include historical travel patterns for the user device, usage patterns for the user device, and optionally an identification of a user device affinity group. The historical travel patterns reflect the movement of the user device. The historical travel patterns can be used to identify network access points such as APs, base stations, or eNBs that are likely accessible to the user device during the specific time period of the prediction. 
     The usage patterns for the user device may track the applications used by the user device (e.g., e-mail, video, audio, or games) and time periods that each application is likely to be used. An affinity group for the user device includes an identification of user devices having similarities with user a device. The affinity group may be generated a priori based on travel and usage patterns for a user device. Alternatively, the affinity group may be generated in real-time. 
       FIG. 8  depicts a flowchart  800  for a method of predicting the need for a future handover and preparing for future handovers, according to embodiments of the present disclosure. Flowchart  800  is described with continued reference to  FIGS. 7 and 3B . However, flowchart  800  is not limited to those embodiments. 
     In step  810 , user device  710  turns on and synchronizes with a base station such as base station  722   a.    
     In step  820 , multi-RAT access and handover controller  780  predicts the need for handovers over a specific period of time (e.g., 30 minutes). During the prediction process, the multi-RAT access and handover controller  380  may take into consideration various factors and/or approaches for determining the need for a handover including user mobility, device or application need for signaling, historical performance of available paths, and data associated with other users or applications having similar attributes as the user. 
     To perform the handover prediction, multi-RAT access and handover controller  780  may access a profile for the user device  710 . The user device profile  381  may include historical travel patterns for the user device, usage patterns for the user device, and in embodiments, an identification of a user device affinity group. The historical travel patterns reflect the movement of the user device. For example, the historical travel pattern may show that on weekdays from 7 am to 8 am, a 90% probability exists that the user device will follow a specific path (e.g., user commutes to work every morning using the same route) and on weekdays from 6 pm to 7 pm, a 90% probability exists that the user device will follow a specific path (e.g., user returns home following work using the same route). The historical travel patterns can be used to identify network access points such as APs, base stations, or eNBs that are likely accessible to user device  710  during the specific time period of the prediction. 
     In addition, the usage patterns for the user device may track the applications used by the user device (e.g., e-mail, video, audio, or games) and time periods that each application is likely to be used. For example, user device  780  may be more likely to use an e-mail application from 7 am-9 am and a video game application for 6 pm to 7 pm. Multi-RAT controller  780  may use these usage patterns to determine the application that the user device is most likely to use during the time period of the prediction. Knowing the type of application and associated data traffic can assist multi-RAT controller  780  to select the optimal paths for the communication during the time period and in turn the handovers necessary to achieve these optimal paths. 
     Multi-RAT controller  780  may further include indication of an affinity group for the user device. The affinity group for the user device includes an identification of user devices having similarities with user device  780 . The affinity group may be generated a priori based on travel and usage patterns for a user device. Alternatively, the affinity group may be generated in real-time. In embodiments, multi-RAT controller  780  may access profiles associated with user devices in user device  780 &#39;s affinity group. Multi-RAT controller  780  can then use this information to predict potential applications that user device  780  may access during the time period for the prediction. 
     After applications likely to be used by the user device are identified, profiles associated with these applications may be accessed by the multi-RAT access and handover controller  780 . The application profile may indicate the signaling and/or data usage needs for the application. This data may also be used as a factor in selecting the optimal path for communications during the time period of the prediction. 
     Finally, multi-RAT controller  780  may access historical performance of potential paths identified for user device communication during the time period of the prediction. For each application, performance criteria for the application may be provided for the path, as a whole, and/or for each node (including the AP) in the path. In embodiments, the data may further be broken down per user device. Using this data, multi-RAT access and handover controller  780  identifies the paths and associated handovers necessary during the time period of the prediction. 
     In step  825 , a determination is made whether a handover is predicted during the time period. If one or more handovers are predicted, the operation proceeds to step  840 . If no handovers are predicted operation proceeds to step  830 . 
     In step  830 , normal operation occurs. 
     In step  835 , a determination is made whether the prediction process should be repeated for a different time period. If the prediction process is to be repeated, operation returns to step  820 . If the prediction process is not to be predicted, operation returns to step  830 . Step  835  may be repeated periodically. 
     In step  840 , multi-RAT controller  780  prepares for the identified handovers. If a handover prediction is made, a reservation process begins where details regarding the anticipated communications flow needs, collected as part of the prediction process of step  820 , is used to lock-in resources before handover event occurs. The advance preparation may further include delivering communication information and characteristics to be used over the time period to all pathway nodes include the user device, APs and other AP/routers. 
     In step  850 , a handover process is initiated. In an embodiment, the serving base station instructs the user device to take measurements. For example, the user device may suspend communication with base station. The user device may then switch to receive signals using another RAT module. If the RAT is a cellular protocol, the user device acquires a pilot, synchronizes with the cell and takes measurements. If the RAT is 802.11, the user device scans for beacon messages sent out by APs and generates a list of APs and their associated measurements. The user device then sends the measurements to its serving base station. The user device may switch to each available RAT module to take measurements. If the AP predicted for the handover is on the list found by the user device, serving base station may then instruct the user device to initiate a handover to the AP identified in step  830 . In an alternate embodiment, the base station instructs the user device to the AP identified for handover without taking measurements. 
     Embodiments of the disclosure may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the disclosure may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include non-transitory machine-readable mediums such as read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others. As another example, the machine-readable medium may include transitory machine-readable medium such as electrical, optical, acoustical, or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc. 
     The present disclosure has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.