Context aware application level triggering mechanism for pre-authentication, service adaptation, pre-caching and handover in a heterogeneous network environment

BACKGROUND OF THE INVENTION

[0001] 1. Field of the Invention

[0002] The present invention relates to the field of wireless networks.

[0003] 2. Discussion of Related Art

[0004] The wireless networks of today are homogeneous. There are many different types of wireless networks available today like mobile, such as the networks known as 2.5G, 3G etc., wireless LANs, such as the networks known as 802.11 and HIPERLAN, and short range wireless, such as the network known as Bluetooth, etc. However, there is no interoperability between these wireless networks. In other words, the user of one network is not able to seamlessly handover to another type of network. It is envisioned by the present invention that it will be possible in the future to seamlessly handover between heterogeneous networks. In such a heterogeneous environment there is need for mechanisms that allow seamless transition between different networks.

[0005] Traditionally, handovers between networks are initiated on the basis of the received signal strength, which is measured at the network and the mobile device. However, the present invention envisions that in the future heterogeneous environment the decision of when and where to handover will most often be made by application layer entities, especially in the case of vertical (intra-access technology) handovers.

[0006] In order to support such a seamless environment, the present invention requires mechanisms that allow devices to seamlessly handover between heterogeneous networks and allow services to adapt to changing network conditions. Although the present invention can encompass various techniques to realize the seamless handover, the description of the present invention focuses on the application level triggering mechanisms for seamless mobility.

[0007] A typical heterogeneous network environment <b>100</b> is schematically shown in FIG. 1. In particular, the network environment includes a mobile terminal, such as a cell phone <b>102</b>, that is connected to an IP backbone <b>104</b> (Internet) through a wireless base station <b>106</b> and a Universal Mobile Telecommunications System (as identified in Europe)/WCDMA (as identified in Japan) network <b>108</b>. In particular, the mobile terminal is first connected to the base station <b>106</b>, then all traffic generated by the mobile terminal goes to the network <b>108</b> and goes out to the Internet. In a heterogeneous environment there will be many different base stations of different access technologies to which the mobile terminal <b>102</b> can possibly handover. As shown in FIG. 1, such a heterogeneous environment can include: 1) wireless base station <b>110</b> and a CDMA2000 network <b>112</b>, 2) wireless base station <b>114</b> for Bluetooth network and 3) wireless base station <b>116</b> for a WLAN (IEEE 802.11A or IEEE 802.11B) network.

[0008] While it is possible to initiate the handover processor manually via the mobile terminal, it is preferred that a process is developed where the handover is done automatically. In the case of automatic handover, it is very important for the mobile terminal <b>102</b> to know when to do the handover and to which network in a heterogeneous environment such as shown in FIG. 1. It is known that the handover decision can be based on a number of factors. First, information about the network topology and target base stations is required. This may include information about the coverage areas of (geographically) nearby base stations, the type of services supported by the (handover) target base stations, the available bandwidth, available security mechanisms, QoS (Quality of Service) and cost associated with accessing the networks etc. Such information can be made available to the mobile device by a location server that continuously updates this information for base stations in a certain geographical region. It is also possible to determine network topology in the manner described in 1) F. Watanabe etc al., “Using subnet relations to conserve power in a wireless communication device,” currently apply to IPR and 2) G. Wu, P. J. M. Havinga, and M. Mizuno, “MIRAI architecture for heterogeneous network,” IEEE Commun. Mag., February 2002.

[0009] A second factor to consider is that some information is locally available on the mobile device. Such information can include information about the geographical location of the mobile device, signal strength with the current point of attachment, signal strength of the target network, type of applications that are running along with application specific, QoS, bandwidth, security requirements and battery consumption level etc.

[0010] A third factor to consider is that user context information is required in order to make effective triggering decisions. This context information will include user preferences for services and networks depending on different factors such as location, time, nearby people, battery resources etc, information about user schedules/agendas, activity e.g. running, walking, driving a car etc and past usage behavior. This context information may be stored locally on the mobile device or it may reside on some database in the network. It should be noted that the IETF Seamoby working group has proposed an IP level context transfer along the forwarding path of a mobile node in order to provide seamless mobility (see http://www.ietf.org/html.charters/seamoby-charter.html). In its standardization efforts, Seamoby discusses AAA context transfer between AAA servers as the mobile terminal moves between different IP subnets. In addition, the IEEE802.11 Task Group f has standardized the inter-access point protocol, which will exchange user context information transfer between the new access point (AP) and the old AP (see IEEE Std 802.11f/D2.0, Draft Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE802.11 Operation, July 2001). Note that the access point has a station functionality and provides access to the Intranet and the Internet via wireless medium.

[0011] A fourth factor is that the user may be running different services on the mobile terminal that need to adapt to the new network conditions. For example, a video conference between two mobile users on a cellular network will have different parameters as compared to a video conference between the same users if they handover to a wireless LAN network. Mobile IP guarantees session continuity but does not provide service adaptability. See D. Johson and C. Perkins, “Mobility Support in IPv6,” http://search.ietf.org/internet-drafts/draft-ietf-mobileip-ipv6-15.txt.

[0012] A fifth factor is that battery resources are very critical for a handheld device because of limited battery capacity. In the past a number of approaches have been adopted for enhancing battery performance as well as to make the applications themselves battery aware. In a heterogeneous environment there will be a large number of access networks that a mobile device can potentially connect to. Software Defined Radios may be the key enabling technology in providing this type of connectivity. See K. C. Chen, R. Prasad, H. V. Poor, “Software Radio,” IEEE Pers. Mag., vol.6, no.4, August 1999. The problem is how the mobile device knows when to scan for which access network types.

[0013] Based on the above-described systems, there is no technology at this time that can provide seamless handover to other networks in next generation wireless networks.

SUMMARY OF THE INVENTION

[0014] One aspect of the present invention regards a method of handing over from a first network to a second network that includes operating a mobile terminal via a first network, evaluating at least one criteria of either the first network or a second network and initiating a trigger that causes a handover from the first network to the second network so that the mobile terminal operates via the second network.

[0015] A second aspect of the present invention regards a network selection system that includes a mobile terminal in communication with a first network, a second network in communication with the first network and an application layer triggering mechanism that determines which one of a plurality of triggers is required in a certain set of circumstances to provide a particular application.

[0016] Each of the above aspects of the present invention provides the advantage of having a mobile terminal itself acquiring the information required to make an effective handover decision.

[0017] Each of the above aspects of the present invention provides the advantage of acting as a triggering mechanism, such as for context transfer mechanisms proposed by the IETF Seamoby working group.

[0018] Each of the aspects of the present invention provides the advantage of pre-authenticating a mobile terminal with the target network before the actual handover takes place.

[0019] Each of the above aspects of the present invention provides the advantage of authenticating context transfer between the AM servers of the source/destination networks.

[0020] Each aspect of the present invention provides the advantage of allowing running services to adapt to a new network situation.

[0021] Each aspect of the present invention provides the advantage of allowing for a trigger for direct pre-caching between the service provider and the nearest cache server or for cache handoff mechanisms.

[0022] Each aspect of the present invention provides the advantage of providing a user a more seamless experience by triggering pre-authentication, pre-caching and service adaptability before the actual handover takes place.

[0023] Each aspect of the present invention provides the advantage of providing substantial saving of battery resources on a mobile terminal.

[0024] The present invention, together with attendant objects and advantages, will be best understood with reference to the detailed description below in connection with the attached drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0025]FIG. 1 schematically illustrates a possible known heterogeneous environment for operating a mobile terminal;

[0026]FIG. 2 shows a flowchart that regards an embodiment of a triggering mechanism according to the present invention;

[0027]FIG. 3 schematically illustrates an embodiment of an access network according to the present invention;

[0028]FIG. 4 schematically shows an embodiment of a trigger module component according to the present invention;

[0029]FIG. 5 schematically shows an embodiment of an application detection component according to the present invention to be used with the trigger module component of FIG. 4;

[0030]FIG. 6 schematically shows an embodiment of an application interface according to the present invention between the trigger module component of FIG. 4 and an application; and

[0031]FIG. 7 schematically shows available information at the access network of FIG. 3 and an external database server.

DETAILED DESCRIPTION OF THE INVENTION

[0032] The following description of the method of the present invention will be with respect to a heterogeneous environment such as the environment <b>100</b> shown in FIG. 1. It should be understood that the present invention can be applied to other types of environments as well.

[0033] In accordance with the present invention, a mobile terminal, such as a lap top computer, a PDA or the cell phone <b>102</b> shown in FIG. 1 is modified so that it acquires network topology information in order to make triggering decisions. Since knowledge of wireless coverage area of a certain network may not necessarily guarantee wireless connectivity due to a number of factors, including multipath fading, congestion and interference, etc., there is a need for error resilience. One way of doing this is to have the mobile device always check the target network signal levels before actually making the handover to the target network.

[0034] An algorithm for an application layer triggering mechanism is shown and described in FIG. 2. As will be described below, the application layer triggering mechanism <b>200</b> determines which type of trigger is required in a certain set of circumstances and to provide the required trigger to applications.

[0035] There are four types of triggers contemplated: 1) a pre-authentication trigger signal <b>202</b> (PT) that triggers pre-authentication initiation of the mobile terminal with the handover target network(s), 2) a service adaptability trigger signal <b>204</b> (ST) that signals an application that it can perform any necessary adaptation in anticipation of an impending handover, 3) a pre-caching trigger signal <b>206</b> (CT) that sends a trigger signal to a cache management system in order to pre-cache content at the cache server nearest to the target base station and 4) a handover trigger signal <b>208</b> (HT) that initiates the handover process with the target network.

[0036] A certain set of criteria need to be met in order to signal one or more of the above-mentioned trigger signals. This set of criteria corresponds to the many different aspects that need to be considered before making a triggering decision. The triggering mechanism <b>200</b> evaluates these criteria in parallel. The results of this evaluation are combined to determine a composite triggering criteria. If the composite triggering criteria are satisfied, then the triggering mechanism <b>200</b> checks the remote (target) network signal criteria and if that is also satisfied it may initiate one or more trigger signals with or without user input depending on the situation or pre-defined settings.

[0037] In operation, the triggering mechanism <b>200</b> is started at step <b>210</b> and results in application criteria <b>212</b> being defined as the set of application specific conditions that must be met in order to initiate a trigger. Upon defining the set of application specific conditions, the triggering mechanism <b>200</b> performs a query at step <b>214</b> as to whether a particular application state is present. For example, if the application state corresponds to “No applications running” and designated as A000, then the triggering system saves the state information per step <b>216</b>. With identification of state A000, pre-authentication, service adaptability and pre-caching triggers are not needed because they are only relevant when an application is running.

[0038] In case of an incoming application, either a non realtime application or a real time application, the mobile terminal always connects to the access network, which supports a paging mechanism. Currently, a mobile communication system supports a paging scheme, which ensures that the mobile terminal is always connected to the mobile communication system when it is a dormant mode. Consequently, all incoming applications will reach to the mobile terminal through the mobile communication system, and then an appropriate access network will be selected based on the application requirement described above.

[0039] Should the application state be determined to correspond to “Non realtime application running” and designated A100, then other application specific criteria, such as cost criteria <b>218</b> and QoS criteria <b>220</b> are evaluated in parallel with one another. Should the application state be determined to correspond to “Realtime application running” and designated A300, then the location criteria <b>222</b> is also evaluated in parallel with the cost criteria <b>218</b> and the QoS criteria <b>220</b>. Examples of realtime applications are streaming audio/video or audio/visual call, etc.

[0040] The location criteria <b>222</b> depend on location related information in order to make triggering decision. The location criteria look at such factors as:

[0041] Position of the mobile terminal;

[0042] Position of the mobile terminal in relation to the coverage area of the current point of attachment;

[0043] State of the mobile terminal e.g. stationary or moving;

[0044] If moving, then speed and direction of the mobile terminal and whether moving towards the point of attachment or away; and

[0045] Position of mobile terminal in relation to (possibly) overlapping coverage areas of other nearby networks.

[0046] As shown in FIG. 2, the location criteria <b>222</b> is only evaluated when a realtime application is identified. The reason for this is that realtime applications require maximum response time to adapt in order to ensure seamless operation.

[0047] For example, if a real-time application is running and the user is moving away from the current point of attachment at a certain speed and is about to reach the limit of wireless coverage for the current point of attachment, then the trigger mechanism <b>200</b> can trigger pre-authentication trigger signal <b>202</b>, service adaptability trigger signal <b>204</b> and pre-caching trigger signal <b>206</b> should the location criteria be met per step <b>224</b>. If the location criteria are not met by the real time application, then the application state information will be saved per step <b>226</b>.

[0048] Cost criteria <b>218</b> depend on application specific costs associated with different networks. For example, cost criteria <b>218</b> may look at such factors as:

[0049] Cost of (running) application with current point of attachment; and

[0050] Cost of (running) application with other available networks.

[0051] The cost criteria <b>218</b> is evaluated at step <b>228</b> for all running applications, including realtime and non-realtime. The cost criteria <b>218</b> is met if an application is cheaper to run on target networks(s) as compared to the current point of attachment. If the cost criteria <b>218</b> is not met by the application, then the application state information will be saved per step <b>230</b>.

[0052] QoS criteria <b>220</b> depend on application specific QoS information. In reality, QoS information can be constantly changing due to different factors such as the number of users using a network and the type of services being used. For example, a wireless LAN network at an airport will have constantly changing QoS information depending on the number of people using the network and the time of day (e.g. rush hour) etc. In such a scenario, if a handover decision is based on QoS information, and the QoS information suddenly degrades after the handover, it will lead to the mobile device constantly handing over to different networks in search of better QoS information and will lead to a Ping Pong effect. The problem becomes even worse if many mobile devices try to handover based on a QoS information at the same time because it will lead to dramatically changing QoS information based on available networks in that area.

[0053] In order to avoid the above-mentioned problems, two possible solutions are employed. First, the target base station can tell the mobile device interested in handover about its best case QoS information, its average QoS information, its worst case QoS information and a measure of the degree of stability of its QoS information. The mobile device can then make its decision based on this information. A second solution is to have the base station support a resource reservation scheme in which bandwidth resources can be reserved for mobile devices that have specific QoS requirements. The mobile devices that make handover decision based on QoS information can be assured of bandwidth availability on the target network.

[0054] With the above solutions in mind, the QoS criteria <b>220</b> looks at such factors as:

[0055] Application specific QoS information at a current point of attachment;

[0056] Expected application specific QoS information on other available network(s); and

[0057] QoS stability of the target network

[0058] As shown in FIG. 2, the QoS criteria <b>220</b> will be evaluated at step <b>232</b> for all running applications, including realtime and non-realtime. The QoS criteria <b>220</b> will be met if an application has better QoS information on target networks(s) as compared to the current point of attachment or if the target network has more stable QoS information than the current network. If the QoS criteria <b>220</b> is not met by the real time application, then the application state information will be saved per step <b>234</b>.

[0059] As shown in FIG. 2, the trigger mechanism <b>200</b> evaluates other criteria, such as network criteria <b>236</b>, user (context) criteria <b>238</b>, local signal criteria <b>240</b> and battery criteria <b>242</b>, in parallel with the application criteria <b>212</b>.

[0060] In the case of the network criteria <b>236</b>, it evaluates the target network for the purpose of handover. Important factors in the network criteria <b>236</b> include:

[0061] Cost associated with accessing the target network(s) (not application specific);

[0062] Operator associations of target network; and

[0063] Security schemes and other services provided by the target network.

[0064] The network criteria <b>236</b> are evaluated in step <b>244</b> and are met if the target network(s) are better than the current network. If the network criteria <b>236</b> is not met, then the application state information will be saved per step <b>246</b>.

[0065] The user context criteria <b>238</b> depend on the user context information. Such user context criteria <b>238</b> may look at such factors as:

[0066] User location specific service and network preferences;

[0067] User general service and network preferences;

[0068] User schedule/agenda;

[0069] User activity; and

[0070] User past behavior.

[0071] The user context criteria <b>238</b> is such that it is appropriate to select one of the variety of triggers. For example, if the user's preference is to always handover to the high bandwidth network with best QoS when he is using his mobile device for business (e.g. user location is in office, talking to boss etc.) and select the least costly network when the user is using his mobile device for personal use (e.g. user location is in house, user is on vacation etc.), then a network handover trigger and any additional triggers that may be required will be selected if those criteria are met per step <b>248</b>. How the context information is to be interpreted for making triggering decisions may be decided by the user himself (manually), by the operator depending on past history or any other heuristics. If user (context) criteria <b>238</b> are not met, then the application state information will be saved per step <b>250</b>.

[0072] Local signal criteria <b>240</b> look at signal strength of the current point of attachment. Some possible signal strength states are: 1) SL000—No signal; 2) SL100—Extremely bad signal; 3) SL200—Poor signal; 4) SL300—Acceptable signal; 5) SL400—Good signal and 6) SL500—Excellent signal. Local signal criteria <b>240</b> is evaluated at step <b>252</b> and is satisfied when the signal strength with the current point of attachment becomes poor or worst (states &lt;SL300).

[0073] The local signal criteria <b>240</b> is a qualitative criteria, which is derived from a quantitative criteria that is specific to access technology. For example, a good signal strength is specified by the vender and the operator depending on the wireless system (e.g., 6.1 dB). Note that should the local signal criteria <b>240</b> not be met, then the application state information will be saved per step <b>254</b>.

[0074] The battery criteria <b>242</b> look at battery usage information in order to make a triggering decision. Battery criteria <b>242</b> look at such factors as:

[0075] The expected battery resource usage in associating with the current network;

[0076] The application specific expected battery resource usage in associating with the current network;

[0077] The expected battery resource usage when associating with target network(s); and

[0078] The application specific expected battery resource usage when associating with target network(s).

[0079] The battery criteria <b>242</b> are evaluated at step <b>256</b> and satisfied if battery resources can be enhanced by handover to a different network. If the battery criteria <b>242</b> are not met, then the application state information will be saved per step <b>258</b>.

[0080] All the criteria <b>212</b>, <b>222</b>, <b>218</b>, <b>220</b>, <b>236</b>, <b>238</b>, <b>240</b> and <b>242</b> are continuously evaluated and results in the evaluation being sent to the composite trigger selector <b>272</b>, which determines what type(s) of trigger(s) may be required. Only if the composite trigger selector <b>272</b> determines the need for one or more triggers, then a remote signal criteria <b>260</b> is applied. This helps in saving battery resources on the mobile device because the mobile device does not have to scan for target networks at all times. In particular, the remote signal criteria <b>260</b> look at signal strength of target point(s) of attachment. In the remote signal criteria <b>260</b>, remote signal states are defined. Examples of such remote signal states are given below:

[0081] SR000: No Signal.

[0082] SR100: Extremely Bad Signal.

[0083] SR200: Poor Signal.

[0084] SR300: Acceptable Signal.

[0085] SR400: Good Signal.

[0086] SR500: Excellent Signal.

[0087] The remote signal criteria <b>260</b> are satisfied when the signal strength with the target point(s) of attachment is acceptable (states &gt;SR200). The signal criteria described here is a qualitative criteria, which is derived from a quantitative criteria that is specific to access technology.

[0088] Should the remote signal criteria <b>260</b> not be satisfied, then the next available network will be identified per step <b>262</b> and the remote signal criteria <b>260</b> will be applied to that network. Should the remote signal criteria <b>260</b> be satisfied, then a cost of handover criteria <b>264</b> will be applied.

[0089] The cost of handover criteria <b>264</b> compares the cost of handover in terms of effort required to do the handover versus the advantage of handing over to the new network. This criteria will not be evaluated for user initiated handover requests. This criteria will be effective in cases where the current network and the target network are very similar to each other. For example, if a mobile device is connected to a WCDMA base station of one operator and another WCDMA base station of other operator has slightly better QoS, than this criteria will deny the handover request. If the handover request is denied, then the next available network is identified in step <b>262</b> and the remote signal criteria <b>260</b> and the cost of handover criteria <b>264</b> are applied to the network in the manner described above. If the handover request is accepted in step <b>264</b>, then it is determined in step <b>266</b> whether or not the triggering process should be performed automatically or manually. If the triggering process is to be done manually, then the user initiates handover per step <b>249</b> by deciding when and which networks participate in handover. The manual handover input is gathered through some user interface per step <b>268</b>. In practical systems, the user will most likely be asked for manual selection in case of handover triggers only.

[0090] Once the triggering is entered either manually or automatically, the triggering is initiated per step <b>270</b> so that either the pre-authentication trigger <b>202</b>, the service adaptability trigger <b>204</b>, the pre-caching trigger <b>206</b> or the handover trigger <b>208</b> is initiated.

[0091] Note that the above example regards the situation where all criteria are satisfied. Such a situation will not occur often. Instead, there will often be times when the various criteria are in conflict with each other. Therefore, there is a need for a composite trigger selector <b>272</b> that can evaluate the recommendations of the various criteria and determine which triggers are required at that point.

[0092] The various criteria evaluators will send their recommendations (in favor or against handover) to the composite trigger selector <b>272</b>, which will make the final decision based on whether the criteria are met per step <b>274</b>. If the criteria are not met then the process is returned to step <b>210</b> per step <b>276</b>. As shown in FIG. 2, the composite trigger selector <b>272</b> will look at target network signal strength <b>260</b> and cost of handover criteria <b>264</b> before initiating automatic or manual triggering process.

[0093] Table 1 below shows a sample prioritization scheme for different criteria in favor of handover. The criteria priority is a number ranging from 0 to 100 that quantifies the relative importance of a certain criteria and the dependency. The criteria priority is used to resolve conflicts between conflicting criteria. Also some criteria will have more importance than others. Assigning a certain priority to each criterion will help in resolving these conflicts and make correct triggering decisions. Initial values for criteria priorities will be determined by the operator after extensive testing/simulations and statistical analysis. The criteria priority may however, change over time based on user's own preferences or context. <tables id="TABLE-US-00001" num="1"><table frame="none" colsep="0" rowsep="0"><tgroup align="left" colsep="0" rowsep="0" cols="1"><colspec colname="1" colwidth="217PT" align="center" /><thead><row><entry namest="1" nameend="1" align="center">TABLE 1</entry></row></thead><tbody valign="top"><row>&lt;entry /&gt;</row><row><entry namest="1" nameend="1" align="center" rowsep="1" /></row><row><entry>Criteria prioritization for handover</entry></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="21PT" align="center" /><colspec colname="2" colwidth="63PT" align="left" /><colspec colname="3" colwidth="28PT" align="center" /><colspec colname="4" colwidth="42PT" align="left" /><colspec colname="5" colwidth="63PT" align="left" /><tbody valign="top"><row>&lt;entry /&gt;&lt;entry /&gt;<entry>Criteria</entry>&lt;entry /&gt;&lt;entry /&gt;</row><row><entry>No.</entry><entry>Criteria</entry><entry>Priority</entry><entry>Dependency</entry><entry>Comments</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup><tgroup align="left" colsep="0" rowsep="0" cols="5"><colspec colname="1" colwidth="21PT" align="char" char="." /><colspec colname="2" colwidth="63PT" align="left" /><colspec colname="3" colwidth="28PT" align="char" char="." /><colspec colname="4" colwidth="42PT" align="left" /><colspec colname="5" colwidth="63PT" align="left" /><tbody valign="top"><row><entry>1</entry><entry>Remote Signal</entry><entry>100</entry><entry>Any of 2, 3,</entry><entry>Must be met for a</entry></row><row>&lt;entry /&gt;<entry>Criteria</entry>&lt;entry /&gt;<entry>4, 5, 6, 7, 8,</entry><entry>trigger/handover to</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>9, 10</entry><entry>occur</entry></row><row><entry>2</entry><entry>User Initiated</entry><entry>90</entry><entry>1</entry><entry>User may be warned</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>about conflicting</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>criteria e.g. cost,</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>QoS etc.</entry></row><row><entry>3</entry><entry>Cost of Handover</entry><entry>80</entry><entry>1</entry><entry>Will not be</entry></row><row>&lt;entry /&gt;<entry>Criteria</entry>&lt;entry /&gt;&lt;entry /&gt;<entry>evaluated for user</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>initiated handover</entry></row><row>&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;&lt;entry /&gt;<entry>case</entry></row><row><entry>4</entry><entry>Local Signal</entry><entry>80</entry><entry>1</entry></row><row>&lt;entry /&gt;<entry>Criteria</entry></row><row><entry>5</entry><entry>Network Criteria</entry><entry>70</entry><entry>1</entry></row><row><entry>6</entry><entry>User Context</entry><entry>70</entry><entry>1</entry></row><row>&lt;entry /&gt;<entry>Criteria</entry></row><row><entry>7</entry><entry>Application Criteria</entry><entry>60</entry><entry>1</entry></row><row><entry>8</entry><entry>Cost Criteria</entry><entry>60</entry><entry>1, 6</entry></row><row><entry>9</entry><entry>QoS Criteria</entry><entry>50</entry><entry>1, 6</entry></row><row><entry>10</entry><entry>Location Criteria</entry><entry>50</entry><entry>1, 6</entry></row><row><entry>11</entry><entry>Battery Criteria</entry><entry>50</entry><entry>1</entry></row><row><entry namest="1" nameend="5" align="center" rowsep="1" /></row></tbody></tgroup></table></tables>

[0094] Such prioritization schemes for different criteria will be very dynamic and defined by the operator as well as the user's own preferences and context.

[0095] If the handover is user initiated, then the target network signal level is tested to see if it is acceptable. If it is acceptable, then handover to the new network is performed irrespective of other criteria. In all other cases, it is determined whether to stay with the current network or to handover to a new network based on the factor NAF_T(i) and NAF_Lthat are derived from the following formulas: <maths id="MATH-US-00001" num="1"><math overflow="scroll"><mtable><mtr><mtd><mrow><msub><mi>NAF</mi><mrow><mi>T</mi><mo></mo><mrow><mo>(</mo><mi>i</mi><mo>)</mo></mrow></mrow></msub><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>3</mn></mrow><mi>J</mi></munderover><mo></mo><mrow><msub><mi>CP</mi><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></msub><mo>×</mo><msub><mi>CF</mi><mrow><mo>(</mo><mi>K</mi><mo>)</mo></mrow></msub></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>1</mn><mo>)</mo></mrow></mtd></mtr></mtable></math><img file="US20030193910A1-20031016-M00001.TIF" id="EMI-M00001" he="25.9119" wi="216.027" img-format="tif" img-content="mf" /><attachments><attachment idref="MATHEMATICA-00001" attachment-type="nb" file="US20030193910A1-20031016-M00001.NB" /></attachments></maths>

[0096] Where:

[0097] NAF_T(i)

[0098] Is the Network Attachment Factor for target network ‘i’. It is a numerical measure of overall value in attaching with target network ‘i’. NAF_Tiis calculated for each of the handover target networks and is based on remote network criteria.

[0099] CP(_k)

[0100] Is the Criteria Priority for any one of the criteria (k) described in Table 1.

[0101] CF_(k)

[0102] Is the Confidence Factor for any of the criteria (k) described in Table 1. CF_kis determined during each criteria evaluation (FIG. 2) and is a numerical measure of the confidence behind each criteria specific recommendation. The method for determination of the Confidence Factor will be criteria specific and is set by the operator. For example, in the case of local and remote signal criteria, the higher the accuracy of signal strength measurement, the higher will be the Confidence Factor. Similarly, in the case of Location criteria, the higher the accuracy of location measurement, the higher will be the Confidence Factor. . . . <maths id="MATH-US-00002" num="2"><math overflow="scroll"><mtable><mtr><mtd><mrow><msub><mi>NAF</mi><mi>L</mi></msub><mo>=</mo><mrow><munderover><mo>∑</mo><mrow><mi>k</mi><mo>=</mo><mn>3</mn></mrow><mi>J</mi></munderover><mo></mo><mrow><msub><mi>CP</mi><mrow><mo>(</mo><mi>k</mi><mo>)</mo></mrow></msub><mo>×</mo><msub><mi>CF</mi><mrow><mo>(</mo><mi>K</mi><mo>)</mo></mrow></msub></mrow></mrow></mrow></mtd><mtd><mrow><mo>(</mo><mn>2</mn><mo>)</mo></mrow></mtd></mtr></mtable></math><img file="US20030193910A1-20031016-M00002.TIF" id="EMI-M00002" he="25.9119" wi="216.027" img-format="tif" img-content="mf" /><attachments><attachment idref="MATHEMATICA-00002" attachment-type="nb" file="US20030193910A1-20031016-M00002.NB" /></attachments></maths>

[0103] Where:

[0104] NAF_L

[0105] Is the Network Attachment Factor for the current network. It is a numerical measure of overall value in remaining attached with the current network and is based on local criteria and so differs from NAF_T(i)

[0106] CP_(k)

[0107] Is the Criteria Priority for any one of the criteria (k) described in Table 1.

[0108] CF_(k)

[0109] Is the Confidence Factor for any of the criteria (k) described in Table 1. CF_kis determined during each criteria evaluation (FIG. 2) and is a numerical measure of the confidence behind each criteria specific recommendation.

[0110] Assuming there are N handover target networks and TSF_iis the Target Signal Factor for target network ‘i’ and is a numeric representation of signal strength of target network ‘i’, the algorithm for handover target selection is as follows:

[0111] For i=1 to i=N {If (NAF_Ti&gt;NAF_L) Add to AcceptableTarget[i] list} and sort the Acceptable Target[i] list in descending order, where the higher a network is listed the higher its NAF_Tvalue.

[0112] Assuming there are Y acceptable handover target networks, then

[0113] For i=1 to i=Y {If((NAF_Ti×TSF_ifor Acceptable Target (i))&gt;NAF_L) then do handover and any necessary triggers. In other words, handover is done with the first network to satisfy the equation.

[0114]FIG. 3 shows an access network <b>300</b> that includes an access network system server <b>302</b>, external database server <b>304</b>, pre-authentication arrangement controller <b>306</b>, network context information database <b>308</b> at access network <b>300</b>, and the cache server <b>310</b>. The service operator <b>312</b>, which has contract with different access networks, will own a number of servers, such as the external database server <b>304</b>, cache server <b>310</b>, and pre-authentication arrangement controller <b>306</b>. In addition, these components can be shared with some access networks, content service providers, and service operators.

[0115] The pre-authentication arrangement controller <b>306</b> will be able to arrange the authentication with different access networks and content service providers before the mobile terminal, such as a lap top computer <b>314</b> establishes connection with an access network. Therefore, the pre-authentication arrangement controller <b>306</b> will send the user's necessary information to different access networks and content service providers in advance. The cache server <b>310</b> will cache current application content/data before the handoff occurs in order to have seamless communications and maintain the quality of service (QoS). The external database server <b>304</b> stores access network location map information and network context information. The external database server <b>304</b> will correct access network location map information and network context information from its experience, which the external database server <b>304</b> handles previous handovers and Mobile IP binding (home agent and foreign agent) information. In addition, the external database server <b>304</b> can communicate with different access networks to correct some location and context information. To realize the access network location map, an approximate location map based on the Mobile IP update binding is contemplated based on the article “Method and Associated Apparatus for Location Detection, Paging, Authentication, Association and Activate Access Network in Heterogeneous Access Networks, by F. Watanabe et al., currently apply to IPR and is the subject of U.S. Provisional Patent Application Serial No. 60/354,568, filed on Feb. 6, 2002, U.S. patent application Ser. No. ______, filed ______, entitled “Using Subnet Relations to Conserve Power in a Wireless Communication Device” (attorney docket no. 10745/92) and U.S. patent application Ser. No. ______, filed ______, entitled “Using Subnet Relations to Determine Paging Areas in a Wireless Communication Device” (attorney docket no. 10745/94), the entire contents of each of which is incorporated herein by reference.

[0116] In order to make advance arrangement such as pre-authentication, service adaptation, pre-caching before the handoff, the following process will be performed in a trigger module component <b>400</b>, as shown in FIG. 4, to make a trigger decision. The trigger module component <b>400</b> is located within the mobile device as shown in FIG. 6. The trigger module component <b>400</b> first detects what kind of application <b>402</b> is running in the mobile device via the application detection component <b>404</b>. As shown in FIG. 5, the application detection component <b>404</b> includes information stored in an operating system process table <b>500</b>, an application port number <b>502</b>, an IP type of service (TOS) field <b>504</b> and an explicit notification by application <b>506</b> itself. Based on this stored information, the kind/class of application, e.g. real time, non-real time, application with QoS requirement is detected per step <b>508</b>.

[0117] After the kind/class of application is detected, triggering criteria are checked from the context external information database <b>406</b>, the context local/internal information database <b>408</b> and the current access network signal level <b>409</b> that measures the current active access network signal level. The context external information database <b>406</b> stores necessary information, which is obtained from the external database server <b>304</b> at the access network shown in FIG. 3. The context external information database <b>406</b> includes the user context <b>410</b>, the network cost <b>412</b>, the application cost <b>414</b>, the access network location map <b>416</b>, and the access network QoS <b>418</b>. The user context <b>410</b> includes user preference, user authentication information, user charging information, and current application requirements. The network cost <b>412</b> is the subscribing charging, e.g., price for minimum charge even if there is no usage. The application cost <b>414</b> indicates the application specific cost, which can include volume of traffic, packet switch or circuit switch usage fee. The access network location map <b>416</b> will give an idea of the terminal location so that the mobile terminal can roughly or exactly know which access network(s) are currently available in the geographical vicinity. The access network QoS <b>418</b> indicates the current access network conditions and supported QoS. For example, if the packet delay is large due to high traffic, the access network QoS <b>418</b> will give current possible packet delay.

[0118] The context local information database <b>408</b> will store the mobile terminal information, which is available locally, such as application battery consumption check <b>420</b>, user context <b>422</b>, application cost <b>424</b>, and application QoS requirement <b>426</b>. The application battery consumption check <b>420</b> indicates how much battery the specified application will consume based on the coding, access network card usage, CPU etc. The user context <b>422</b> includes the user preference, e.g., which access network is the user's preference, which application is the user's preference, and which method is the user's preference. The application cost <b>424</b> indicates the price of application costs when we use. The application QoS requirement <b>426</b> indicates what level and what kind of QoS requirement are necessary to support the specified application.

[0119] After each criteria is evaluated, recommendations are sent to the composite decision <b>428</b> where final evaluation and triggering decisions are made. If the triggering criteria are met, we may make a trigger request to the access network based on the total evaluation. Often, some criteria will be met while others are not. In this case, the composite decision <b>428</b> makes a decision to send a trigger request, which is transmitted to an application running on the mobile terminal, the access network, service operator or content service provider etc.

[0120] In some cases, the user may initiate the handover request or pre-authentication request, service adaptation request and pre-caching request. These kind of user's explicit requests are handled by the user request <b>430</b>. After the decision is made at the composite decision <b>428</b>, the network interface card (NIC), which meets criteria, is selected at the NIC selection <b>432</b>. One or more NIC can be selected at the NIC selection <b>432</b>. If the selected NIC does not have enough signal level, other access network signal levels will be checked at the other access network signal level <b>434</b>. Furthermore, the cost of handoff check <b>436</b> will compare the cost of handoff in terms of effort required to do the handoff versus the advantage of handoff to the new access network in a manner described previously. Finally, the user can select which access network (NIC) to use at the user network selection <b>438</b>.

[0121] In concert with the NIC selection <b>432</b>, a NIC switch off <b>439</b> switches on/off the NIC for a particular access network. The switching on/off of the NIC is relayed to the Tx/Rx <b>441</b>, wherein each Tx/Rx is a transmitter and receiver of packets for different access networks.

[0122] Another case is when the user sets up the NIC selection automatically, the automatic network selection <b>440</b> will select the best possible access network.

[0123] Then, one of the following requests from the request information component <b>442</b>, decided upon by the composite decision <b>428</b>, such as pre-authentication request <b>444</b>, service adaptation request <b>446</b>, handoff initiation request <b>448</b>, and pre-caching request <b>450</b>, will be transmitted to the appropriate destination through the message analyzer/creator <b>452</b>. The appropriate destination means that pre-authentication request <b>444</b> has to be transmitted to the pre-authentication arrangement center <b>320</b>, for instance. As shown in FIGS. 3 and 6, service adaptation request <b>446</b> will be sent to any one of the applications <b>402</b> through the application interface <b>600</b>, the service operator <b>312</b>, content service provider <b>316</b>, access network system server <b>302</b> or the peer entity depending on which component handles this service adaptation. Handoff initiation request <b>448</b> is sent to the access network system server <b>302</b> where handoff is handled. In addition, this handoff initiation request <b>448</b> may need to be sent to the service operator <b>312</b> because the network level handoff has to be arranged. Pre-caching request <b>450</b> will be sent to the cache server <b>310</b> located in the access network <b>300</b> or the service operator <b>312</b>. At the same time, when the trigger requests are transmitted, the trigger module component <b>400</b> will inform the application about this trigger request through application interface <b>600</b>.

[0124] To update the context external information database <b>406</b> and the context local information database <b>408</b>, the mobile terminal, such as cell phone <b>102</b> or lap top computer <b>314</b>, which includes the trigger module component <b>400</b>, will obtain information from the network context information database <b>308</b> at the access network <b>318</b> and the external database server <b>304</b> located in the service operator <b>312</b> shown in FIGS. 3 and 7. The external database server <b>304</b> may be located in another place besides the service operator <b>312</b>.

[0125] As shown in FIGS. 3 and 7, the access network <b>318</b> includes a network condition <b>700</b> that stores the current access network condition such as the number of current active user, possible support QoS level etc. Network cost information <b>702</b> stores current access network association costs. User context information <b>704</b> stores information related to user, e.g., authentication, usage consist, user preference. Application cost information <b>706</b> is the cost information based on the application specific. For instance, price for the specific application includes the price in order to meet QoS and high volume transmission etc.

[0126] At the external database server <b>304</b>, information about access network location map <b>708</b> and network context information database <b>710</b> is stored. The access network location map <b>708</b> has network structure information that is obtained from the access network operator and GPS of mobile terminal. Network context information <b>710</b> will include the access network condition information, which contacts with the service operator <b>312</b>. The mobile terminal, such as cell phone <b>102</b> or lap top computer <b>314</b>, can obtain other/future/target access network context information through the service operator <b>312</b> through the current access network.

[0127] The foregoing description is provided to illustrate the invention, and is not to be construed as a limitation. Numerous additions, substitutions and other changes can be made to the invention without departing from its scope as set forth in the appended claims.