Method and system for user initiated inter-device, inter-system, and inter-internet protocol address handoff

CROSS REFERENCE TO RELATED APPLICATION(S)

0001This application is a continuation of U.S. patent application Ser. No. 10/653,577, filed Sep. 2, 2003, which claims the benefit of U.S. Provisional Application Ser. No. 60/408,475 and filed Sep. 3, 2002, which is incorporated by reference as if fully set forth.

BACKGROUND

0002Internet Protocol (IP) traffic can typically be transferred (i.e. handoff) when dealing with a single terminal operating with the same system and employing the same IP address. Some systems can accommodate a single terminal operating between systems and wherein the IP addresses may be different. However, there are no systems which provide the capability of transferring an existing session between two terminals, in which two systems and two different IP addresses are involved.

SUMMARY

0003A transfer (i.e. handoff) of internet protocol (IP) traffic between two different terminals operating under two different technology standards and in two different systems with two different IP addresses may be either subscriber initiated voluntarily or subscriber-initiated responsive to network solicitation, wherein the handoff process is effected employing optimizing routing mobile IP-(MIP).

BRIEF DESCRIPTION OF THE DRAWING(S)

0004The present invention will be understood from a consideration of the accompanying description and drawings wherein like elements are designated by like numerals and wherein:

0005<figref idref="DRAWINGS">FIG. 1</figref> is a system diagram of the interworking approved Scenario<b>2</b>;

0006<figref idref="DRAWINGS">FIG. 2</figref> is a system diagram of the interworking approach to Scenario <b>3</b>;

0007<figref idref="DRAWINGS">FIG. 3</figref> is a system diagram illustrating how to achieve Handoff with this configuration without any changes to WLAN;

0008<figref idref="DRAWINGS">FIG. 4</figref> is a block listing of Handoff Triggers;

0009<figref idref="DRAWINGS">FIG. 5</figref> is a method flow illustrating general handover scenario (with target HLR/HSS access);

0010<figref idref="DRAWINGS">FIG. 6</figref> is a method flow illustrating general handover scenario (with target HLR/HSS access);

0011<figref idref="DRAWINGS">FIG. 7</figref> is a method flow illustrating handover from WLAN to UMTS;

0012<figref idref="DRAWINGS">FIG. 8</figref> is a method flow illustrating handover scenario from UMTS to WLAN (with Interworking); and

0013<figref idref="DRAWINGS">FIG. 9</figref> is a method flow illustrating handover scenario from UMTS to WLAN (without Interworking).

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)

0014The present invention discloses apparatus and method wherein Internet Protocol (IP) traffic can be transferred (i.e., handoff) between two different terminals operating according to two different technology standards in two different systems with two different IP addresses. For example, session handoff between a Wireless Local Area Network (WLAN) terminal and 3GPP UMTS terminal or between CDMA2000 terminal and 3GPP UMTS terminal. The invention may be utilized by terminals which can be either physically separate entities or separate logical entities that are encapsulated in a common enclosure.

0015The invention is based on the user (service subscriber) initiating handoff procedures between the two terminals. The subscriber may initiate the handoff process based on network solicitation (e.g., the network advises the user that WLAN coverage is available in this geographic vicinity) or based on unsolicited action by the subscriber (e.g., the subscriber is performing a transaction over WLAN and decides that he needs to leave the WLAN and continue the same transaction on his UMTS terminal).

0016There are several mechanisms by which the user initiates an application based handoff. For example, the software session (or the terminal itself) may include a button that triggers initiation of session handoff procedures. The session handoff trigger may also request the target system/terminal/IP address to which the session will be transferred. The request may be part of a stored program in the subscriber's terminal or alternatively be sent directly to the subscriber asking for the target IP address, terminal phone number, or terminal identification number. In a second approach, the source system queries the subscriber profile at the Home Location Registry/-Home Subscriber Service (HLR/HSS) to obtain the target address for handoff. If the subscriber has more than one terminal, the source system may request the subscriber to choose the desired target terminal. In a case where the desired terminal is switched off, the source system may ask the subscriber to switch the terminal ON and activate its IP connection (i.e., obtain the IP address or activate the packet data protocol (PDP) context) before proceeding with the handoff. In a case where the second terminal (e.g., UMTS) is attached and no IP address is allocated (i.e., inactive PDP context), the source system may trigger the target system to perform network initiated PDP context activation procedures.

0017When the target system, target terminal, and target IP address have been identified, the handoff process can be finalized using optimized routing mobile IP version 4 (MIPv4) to direct the session traffic directly to the target triplet (system, IP address, terminal). Once the traffic is rerouted to the new destination, the source system can advise the subscriber that the handoff is completed and that the subscriber can terminate this connection, and switch off the current terminal after which all resources can be released.

0018Setting forth the present invention in greater detail, and with reference to the drawings, <figref idref="DRAWINGS">FIG. 1</figref> represents the present state of the art wherein a personal computer (PC) <b>10</b> having a WLAN card <b>12</b> is capable of communicating with an access point (AP) <b>20</b> of a WLAN <b>19</b>. The WLAN <b>19</b> has only limited access to the 3rd generation partnership project (3GPP) system. The PC <b>10</b> communicates with an internet protocol (IP) network <b>24</b> to send and receive messages. However, PC <b>10</b> has access to the 3GPP system <b>25</b> only for authentication and billing through the AAA function <b>22</b> of the WLAN AP <b>20</b>, the AAA function <b>26</b> of UTRAN <b>25</b> and the HSS <b>28</b>. There is no capability of a handoff as between PC <b>10</b> and a wireless user equipment (UE) <b>15</b>. The capability shown in <figref idref="DRAWINGS">FIG. 1</figref> shows inter-working in accordance with approved Scenario <b>2</b>. Although <figref idref="DRAWINGS">FIG. 1</figref> shows the PC <b>10</b> and a user equipment <b>15</b> as separate entities, it should be understood that they may be logical entities contained with a common housing (not shown).

0019<figref idref="DRAWINGS">FIG. 2</figref> shows an interworking employing a new approach to Scenario <b>3</b>, which differs from the arrangement shown in <figref idref="DRAWINGS">FIG. 2</figref> with the addition of instant messaging system IMS <b>34</b>. Scenario <b>3</b> provides access to packet switching (PS) service via the serving GSN (SGSN) forming part of GSN <b>30</b> in 3GPP system <b>25</b> in scenario <b>3</b>. PC <b>10</b>, in addition to having access to HSS <b>28</b> for authentication and billing, is further capable of obtaining instant message system (IMS) services through IP network <b>24</b>, utilizing IMS <b>34</b>. Nevertheless, there is no handoff capability between PC <b>10</b> and UE <b>15</b>.

0020<figref idref="DRAWINGS">FIG. 3</figref> shows an arrangement in which a handoff is achieved without any changes in the WLAN <b>20</b>. PC <b>10</b> is shown conducting a data session between WLAN <b>20</b> and supporting service center (SC) <b>36</b> through IP network <b>24</b>. The data session connection is transferred to UE <b>15</b> operating wirelessly over the UMTS network of the 3 GPP system <b>25</b> over tower <b>32</b>.

0021<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram showing available handoff procedures.

0022A handoff procedure is triggered (see step S<b>1</b>) and may either be user-initiated or performance-initiated. Given a user-initiated handoff (S<b>2</b>) the initiation may be solicited by the network (branching to S<b>3</b>) wherein the network informs the user that the network, for example, a WLAN, is available. In the case of an unsolicited handoff trigger, the user may initiate the handoff (HO) on his own. In either the solicited (S<b>3</b>) or unsolicited (S<b>4</b>) handoff trigger, the handoff is immediate.

0023An HO may be performance-initiated (branching from S<b>1</b> to S<b>5</b>) wherein initiation may be based upon a power measurement (branching to S<b>6</b>). However, WLANs do not presently support a performance-initiated HO based on power measurement.

0024An HO may be initiated based on frame error rate (FER) branching from S<b>5</b> to S<b>7</b>. However, a physical layer FER (PHY FER) is not supported by a WLAN. A medium access control FER (MAC FER) may not be supported by a WLAN and results in a slow procedure.

0025An internet protocol FER (IP FER) results in a very slow handoff and it should further be noted that the internet protocol (IP) does not have cyclic redundancy check (CRC).

0026<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram showing a generalized HO scenario employing target home location register/home subscriber server (HLR/HSS) access. At step S<b>11</b> an HO is initiated when a subscriber, which may, for example, be a PC equipped with a WLAN card, decides to transfer a current session from one system, A, which may, for example, be a WLAN, to a second system, B, which may, for example, be a universal mobile telecommunications system (UMTS). Upon making this decision, the subscriber operates a handoff button B provided as part of the subscriber unit, such as PC <b>10</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>. Responsive to operation of the HO button, the subscriber is presented with a list of option target systems such as, for example, WLAN, CDMA 2000, UMTS, etc. (S<b>13</b>).

0027The routine advances to S<b>14</b> at which time a determination is made as to whether there are any connections between terminals, such as PC <b>10</b> and UE <b>15</b> shown in <figref idref="DRAWINGS">FIG. 3</figref>. If there is a connection, the routine branches to S<b>15</b> to initiate a confirmation process ensuring the connectivity of the other terminal, for example a UMTS.

0028In the event that there is no connection between terminals, the routine branches from S<b>14</b> to S<b>16</b> which asks the subscriber to confirm that the other terminal, for example, the terminal in the UMTS system is on and is connected with system B. The routine then advances to S<b>17</b> to inquire if system A, such as for example a WLAN, has any information regarding the target triplet which includes the ID of system B, the ID of the terminal communicating with system B and the IP address. In the event that system A does not have the target triplet information, the subscriber is requested to provide the target information.

0029In the case where system A has the target information, the routine branches to S<b>19</b> to retrieve the necessary information about the connections to the target system, i.e. system B. As is described above, the retrieved information is obtained either from system A or from the subscriber. The routine then advances to S<b>20</b> wherein the target system data base, for example, the HLR/HSS, is contacted for information retrieval, verification and authorization. When the necessary criteria is present, the routine branches to S<b>21</b> wherein system A initializes the service at the target system B and informs the service provider, i.e., the session partner to reroute the session traffic to system B. In the event the current session is the only running session in system A, an inquiry may be made to the subscriber to determine if the subscriber would like to terminate the connection to the system A or to continue operation.

0030<figref idref="DRAWINGS">FIG. 6</figref> shows a generalized HO scenario in which a target HLR/HSS is omitted. For purposes of simplicity, only those steps which are not shown in <figref idref="DRAWINGS">FIG. 5</figref> will be described in detail.

0031Steps S<b>11</b> through S<b>17</b> are substantially identical to the corresponding steps S<b>11</b> through S<b>17</b> shown in <figref idref="DRAWINGS">FIG. 5</figref>. However, at step S<b>17</b>, in the event that system A does not have the target triplet information, the routine branches to step S<b>22</b> to obtain the target IP address information from the subscriber.

0032Advancing from step S<b>15</b>, the necessary information regarding connections to the target system are retrieved at S<b>19</b>, the target information either being obtained from system A (S<b>17</b>) or from the target address information provided by the subscriber (S<b>22</b>). The routine then branches to S<b>23</b> wherein the target system may be contacted for information retrieval, verification and authorization. Thereafter if the appropriate criteria are met, the routine advances to step S<b>21</b> which is substantially the same as corresponding step S<b>21</b> in <figref idref="DRAWINGS">FIG. 5</figref>.

0033<figref idref="DRAWINGS">FIG. 7</figref> shows an HO scenario from a WLAN to a UMTS. Steps S<b>11</b> and S<b>12</b> are substantially identical to the corresponding initial steps S<b>11</b> and S<b>12</b> of <figref idref="DRAWINGS">FIGS. 5 and 6</figref>. Upon operation of the HO initiation button, the routine advances to step S<b>27</b>, providing a window to the subscriber inviting the subscriber to select the target system from among the choices displayed and to further ensure that the terminal intended to communicate with the target system is on and connected. The routine then advances to step S<b>28</b> which is substantially identical to step S<b>17</b> shown in the routines of <figref idref="DRAWINGS">FIGS. 5 and 6</figref> wherein an inquiry is made as to whether the WLAN has information regarding the target triplet. In the event that the UMTS does not have target triplet information, the routine branches to step S<b>29</b> in order to obtain the system and/or terminal information from the subscriber. Returning to step S<b>28</b>, the routine loops here until the requested information is obtained. Although not shown, the routine may be exited in the event that the requested information is not obtained after a given number of tries, for example, three (3) tries. However, a lesser or greater number of tries may be programmed before aborting.

0034When the triplet information is obtained, the routine branches to step S<b>30</b> whereupon the HLR/HSS of the target system is contacted. The routine advances to step S<b>31</b> to determine if the terminal is on. In the event that the terminal is on, the routine branches to step S<b>33</b> to determine if the packet data protocol (PDP) is active. In the event that the PDP is not active, the routine branches to step S<b>34</b> to activate the PDP context and thereafter obtain the IP address (S<b>35</b>), followed by performing the re-routing process (S<b>36</b>).

0035Returning to S<b>33</b>, in the event that the PDP is active, the IP address is obtained (S<b>35</b>) and the rerouting process is performed (S<b>36</b>).

0036Returning to S<b>31</b>, if the terminal is not on, the routine branches to S<b>32</b> requesting the subscriber to switch on and confirm. The routine advances to S<b>37</b> to determine if the confirmation has been received. If the confirmation has been received, the routine branches to S<b>39</b> wherein a predetermined delay is provided before the target system is contacted (S<b>30</b>).

0037In the event that a confirmation is not received, the routine branches to S<b>38</b> and the HO is aborted.

0038<figref idref="DRAWINGS">FIG. 8</figref> shows an HO scenario from a UMTS to a WLAN which utilizes interworking.

0039The HO routine is initiated when the subscriber makes a decision to transfer a current session from UMTS from WLAN (S<b>40</b>) and thereafter triggers the HO procedure button during the current UMTS session (S<b>41</b>), whereupon the subscriber is invited to select the target system from a display provided to the subscriber and is further alerted to assure that the terminal to be connected to the WLAN, for example, a PC with a WLAN card, is on and connected to the WLAN.

0040Thereafter, an inquiry is made as to whether the UMTS has the target triplet information. In the event that the UMTS does not have the target information, the routine branches to S<b>44</b> to obtain the system terminal and/or IP information from the subscriber, looping back to S<b>43</b>. When the target information is available, the routine branches to S<b>45</b> whereupon the HSS in the UMTS is contacted. The routine then advances to S<b>46</b> to determine if the WLAN terminal is on. In the event the WLAN terminal is off, the routine branches to S<b>47</b> requesting the subscriber to activate the WV % LAN terminal and confirm activation. It should be noted that step S<b>47</b> is substantially identical to corresponding step S<b>32</b> shown in <figref idref="DRAWINGS">FIG. 7</figref> and the identity of these steps is shown by placing “(S<b>32</b>)” adjacent to step S<b>47</b>. Steps S<b>48</b> through S<b>50</b> operate in substantially the same manner as steps S<b>37</b> through S<b>39</b> of <figref idref="DRAWINGS">FIG. 7</figref> and are shown with the associated equivalent step number of <figref idref="DRAWINGS">FIG. 7</figref> in parenthesis. Reference to performance to steps S<b>48</b> to S<b>50</b> should therefore be made to the description of steps S<b>37</b> through S<b>39</b> set forth above.

0041Making reference to step S<b>50</b>, the HSS in the UMTS is contacted after a predetermined interval (S<b>45</b>) responsive to completion of step S<b>50</b>.

0042When the WLAN terminal is identified as being on (S<b>46</b>) the target IP address is obtained (S<b>51</b>) and the rerouting process is performed (S<b>52</b>).

0043<figref idref="DRAWINGS">FIG. 9</figref> shows the scenario for HO from UMTS to WLAN without interworking. Making reference to <figref idref="DRAWINGS">FIG. 9</figref>, steps S<b>40</b> through S<b>43</b> are substantially identical to corresponding steps S<b>40</b> through S<b>43</b> shown in <figref idref="DRAWINGS">FIG. 8</figref> and reference should be made to the description of these corresponding steps as set forth above.

0044In the event that the UMTS does not have the target information, the program branches to step S<b>44</b> which is substantially similar to corresponding step <b>44</b> in <figref idref="DRAWINGS">FIG. 8</figref> and the description thereof is set forth above.

0045Once the target information is obtained, the routine branches to S<b>53</b> to extract the target IP address. The existence of the IP address is checked at step S<b>54</b>. If the confirmation is positive (S<b>55</b>), the rerouting process is performed (S<b>56</b>). In the event that confirmation has not been received, the routine branches to S<b>57</b> to instruct the subscriber to turn the terminal on and provide information that these steps have been performed. At step S<b>58</b>, once the confirmation is received, the routine then branches to S<b>59</b> and the routine returns to S<b>43</b>. Steps S<b>43</b> through S<b>55</b> are again repeated and in the event that confirmation is not received (S<b>55</b>), and this is the second inquiry, the routine branches at S<b>57</b> A whereupon the HO effort is aborted (S<b>60</b>).