Method for transferring a communication session from a first to a second terminal, and terminal

ES 2 283 804 T3

DESCRIPTION

A method and system of user-initiated handover between devices, between systems, and between internet protocol (IP) addresses.

Background

Internet Protocol (IP) traffic can typically be transferred (that is, passed through) when it is a single terminal operating on the same system and using the same IP address. Some systems can accommodate a single terminal that works between systems and in which the IP addresses may be different. However, there are no systems that provide the possibility of transferring an existing session between two terminals, in which two systems and two different IP addresses are involved.

As a general background, reference is made to the article "Supporting Personal Mobility For Nomadic Computing Over The Internet" by Li and Leung, in Mobile Computing and Communication Review, pp. 22-31, vol. 1, n ° 1 (XP-000720423) that describes the concept and design of the “Universal Personal Computing” system “Universal Personal Computing” - (UPC), in which mobile users can access computing sources anywhere , network services and customized computing environments using any available terminal.

Also, general reference is made to patent US-6201962, which refers to wireless communication systems involving multiple local area networks.

Summary

A transfer (that is, a handover) of internet protocol (IP) traffic between two different terminals operating with two different technology standards and in two different systems with two different IP addresses can be voluntarily initiated by the subscriber or initiated by the subscriber. subscriber in response to the network request, where the handover process is performed using a dynamic IP routing optimizer (MIP).

Brief description of the drawings

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

Figure 1 is a system diagram of the approved interoperability scenario 2;

Figure 2 is a system diagram of the interworking approach to scenario 3;

Figure 3 is a system diagram illustrating how to achieve handover with this configuration without any change in the WLAN (Wireless Local Area Network);

Figure 4 is a block listing of handover triggers;

Figure 5 is a method flow illustrating the general handover scenario (with the target HLR (Home Localization Register) / HSS (Home Subscriber Server / Home Subscriber Server) access);

Figure 6 is a method flow illustrating the general handover scenario (with the target HLR / HSS access);

Figure 7 is a method flow illustrating handover from a WLAN to a UMTS (Universal Mobile Telecommunications System);

Figure 8 is a method flow illustrating handover from UMTS to WLAN (with interworking);

^Y

Figure 9 is a method flow illustrating the handover scenario from UMTS to WLAN (no interworking).

Detailed description of the preferred embodiments

The present invention describes an apparatus and a method wherein internet protocol (IP) traffic can be transferred (i.e., passed through) between two different terminals operating according to two different technology standards in two different systems with two IP addresses. different. For example, handover between a wireless local area network (WLAN) terminal and a 3GPP UMTS terminal or between a CDMA2000 (Code Division Multiple Access) terminal and a 3GPP UMTS terminal. The invention can be used by terminals that can be physically independent entities or independent logical entities that are encapsulated in a common enclosure.

ES 2 283 804 T3

The invention is based on handover procedures initiated by the user (service subscriber) between the two terminals. The subscriber can initiate the handover procedure based on the request from the network (for example, the network informs the user that WLAN coverage is available in this geographic proximity) or based on unsolicited action by the subscriber (for For example, the subscriber is conducting a transaction over the WLAN and decides that he needs to leave the WLAN and continue the same transaction at his UMTS terminal).

There are several mechanisms by which the user initiates an application-based handover. For example, the software session (or the terminal itself) may include a button that triggers the initiation of session handover procedures. The trigger of the session handover may also request the target system / terminal / IP address to which the session will be transferred. The request may be part of a program stored in the subscriber's terminal or, alternatively, sent directly to the subscriber requesting the target IP address, terminal telephone number, or terminal identification number. In a second approach, the source system queries the profile of the subscriber in the home location register / home subscriber server (HLR / HSS) to obtain the target address for the handover. If the subscriber has more than one terminal, the source system may request the subscriber to choose the desired target terminal. In the case where the desired terminal is disconnected, the source system can request the subscriber to connect the terminal and activate its IP connection (i.e. obtain the IP address or activate the Packet Data Protocol (PDP) context ) before proceeding with the handover. In the case where the second terminal (for example, UMTS) is busy and no IP address has been assigned (that is, an idle PDP context), the source system can activate the target system to perform the context activation procedures PDP started on the network.

When the target system, target terminal, and target IP address have been identified, the handover process can be completed using optimized routing dynamic IP version 4 (MIPv4) to direct session traffic directly to the triple target (system, IP address, terminal). Once the traffic is rerouted to the new destination, the source system can inform the subscriber that the handover is complete and that the subscriber can terminate this connection and shut down the current terminal, after which all sources can be released.

Explaining the present invention in greater detail and with reference to the drawings, Figure 1 represents the current state of the art, in which a personal computer (PC) 10 having a WLAN card 12 is capable of communicating with an access point (AP) 20 from a WLAN 19. The WLAN has only limited access to the Third Generation Telephony Collaboration Agreement (3GPP) system. The PC 10 communicates with an IP Internet protocol network 24 to send and receive messages. However, the PC 10 has access to the 3GPP 25 system only for authentication and billing through the AAA function 22 of the WLAN AP 20, the AAA function 26 of UTRAN (Terrestrial Radio Access Network). terrestrial) 25 and the HSS 28. There is no possibility of a handover between the PC 10 and a wireless user equipment (UE) 15. The possibility shown in figure 1 shows the interworking according to the approved scenario 2. Although Figure 1 shows PC 10 and user equipment 15 as separate entities, it should be understood that they may be logical entities contained in a common housing (not shown).

Figure 2 shows an interworking employing a new approach to scenario 3 that differs from the arrangement shown in Figure 2 with the addition of the IMS 34 instant messaging system. Scenario 3 provides access to the packet switched service (PS) to through the server GSN (SGSN - Serving GPRS Support Node - GPRS Server Support Node) that is part of the GSN 30 in the 3GPP 25 system in scenario 3. The PC 10, in addition to having access to the HSS 28 for authentication and billing, is also capable of obtaining services from the instant messaging system (IMS) through the IP network 24, using the IMS 34. However, there is no possibility handover between PC 10 and UE 15.

Figure 3 shows an arrangement in which a handover is achieved without any change in the WLAN 20. The PC 10 is shown conducting a data session between the WLAN 20 and the support service center (SC) 36 through the IP network 24. The data session connection is transferred to the Ue 15 which operates wirelessly through the UMTS network of the 3GPP system 25 on the tower 32.

Figure 4 is a flow chart showing the available handover procedures.

A handover procedure is triggered (see step S1) which can be user-initiated or run-initiated. Given a user-initiated handover (S2), the start can be requested by the network (branch to S3), where the network informs the user that the network is available, for example a WLAN. In the event of an unsolicited handover activation, the user can initiate the handover (HO) himself. In the activation of requested (S3) or unsolicited (S4) handover, the handover is immediate.

An HO can be initiated by execution (branch from S1 to S5), where the start can be based on a power measurement (branch to S6). However, WLANs do not currently support a run-initiated HO based on power measurement.

An HO can be initiated based on a frame error rate (FER) that branches from S5 to S7. 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.

ES 2 283 804 T3

An Internet Protocol FER (IP FER) results in a very slow handover and it should be noted that the Internet Protocol (IP) has no cyclic redundancy control (CRC).

Fig. 5 is a flowchart showing a generalized HO scenario employing a target home location register / home subscriber server (HLR / HSS) access. In step S11, an HO is initiated when a subscriber, which may be, for example, a PC equipped with a WLAN card, decides to transfer a current session from a system A, which may be, for example, a WLAN, to a second system B, which can be, for example, a universal mobile telecommunications system (UMTS). After making this decision, the subscriber operates a handover button B arranged as part of the subscriber's unit, such as the PC 10 shown in Figure 3. In response to the operation of the HO button, the subscriber is presented with a list of optional target systems such as, for example, WLAN, CDMA 2000, UMTS, etc. (S13).

The routine advances to S14, at which time a determination is made as to whether there are connections between the terminals, such as the PC 10 and the UE 15 shown in Figure 3. If there is a connection, the routine branches to S15 to initiate a confirmation process, ensuring the connectivity of the other terminal, for example a UMTS.

In the case that there is no connection between the terminals, the routine branches from S14 to S16, which asks the subscriber to confirm that the other terminal, for example the terminal in the UMTS system, is switched on and connected to system B. The routine then proceeds to S17 to ask if system A, such as, for example, a WLAN, has any information regarding the triple objective which includes the ID of system B, the ID of the terminal communicating with system B, and the IP address. In case system A does not have the triple target information, the subscriber is requested to provide the target information.

In case system A has the target information, the routine branches to S19 to retrieve the necessary information about the connections with the target system, that is, system B. As described above, the retrieved information is obtained from the system A or subscriber. The routine then proceeds to S20, where the database of the target system, for example the HLR / HSS, is contacted for information retrieval, verification and authorization. When the necessary criterion is present, the routine branches to S21, where system A initializes the service on target system B and informs the service provider, that is, the session partner to reroute the session traffic to the system. B. In the event that the current session is the only session running on system A, a question may be asked of the subscriber to determine if the subscriber would like to terminate the connection with system A or continue the operation.

Figure 6 shows a generalized HO scenario in which a target HLR / HSS is missed. For the sake of simplicity, only steps not shown in Figure 5 will be described in detail.

Steps S11 to S17 are substantially identical to the corresponding steps S11 to S17 shown in the figure

5. However, in step S17, in the case that the system A does not have the triple target information, the routine branches to step S22 to obtain the target IP address information of the subscriber.

Proceeding from step S15, the necessary information regarding the connections with the target system is retrieved in S19, obtaining the target information from the system A (S17) or the target address information provided by the subscriber (S22). The routine then branches to S23, where the target system can be contacted for information retrieval, verification and authentication. Next, if the appropriate criteria are met, the routine advances to step S21, which is substantially the same as the corresponding step S21 of FIG. 5.

Figure 7 shows a HO scenario from a WLAN to a UMTS. Steps S11 and S12 are substantially identical to the corresponding initial steps S11 and S12 of Figures 5 and 6. After actuation of the HO start button, the routine advances to step S27, providing a window to the subscriber inviting the subscriber to select the target system from the displayed options and further ensure that the terminal intended to communicate with the target system is turned on and connected. The routine then proceeds to step 28, which is substantially identical to step S17 shown in the routines of Figures 5 and 6, where a question is asked regarding whether the WLAN has information regarding the triple target. In the case that the UMTS does not have the triple target information, the routine branches to step S29 in order to obtain the subscriber system and / or terminal information. Returning to step S28, the routine loops here until the requested information is obtained. Although not shown, you can get out of the routine in the event that the requested information is not obtained after a given number of attempts, for example three (3) attempts. However, fewer or more attempts can be programmed before aborting.

When the triple information is obtained, the routine branches to step S30, after which the HLR / HSS of the target system is contacted. The routine proceeds to step S31 to determine if the terminal is on. In the case where the terminal is powered on, the routine branches to step S33 to determine whether the packet data protocol (PDP) is active. In the case that the PDP is not active, the routine branches to step S34 to activate the PDP context and then obtain the IP address (S35), followed by performing the rerouting process (S36).

Returning to S33, in the case that the PDP is active, the IP address is obtained (S35) and the rerouting process is performed (S36).

ES 2 283 804 T3

Returning to S31, if the terminal is off, the routine branches to S32, which requests the subscriber to turn on the terminal and confirm. The routine advances to S37 to determine if the confirmation has been received. If the confirmation has been received, the routine branches to S39, where a predetermined delay is provided before the target system is contacted (S30).

In the event that the confirmation is not received, the routine branches to S38 and the HO is aborted.

Figure 8 shows an HO scenario from a UMTS to a WLAN using interworking.

The HO routine is started when the subscriber makes the decision to transfer a current session from a UMTS to a WLAN (S40) and then activates the HO procedure button during the current UMTS session (S41), after which the subscriber he is invited to select the target system from a screen provided to the subscriber and is further alerted to ensure that the terminal to be connected to the WLAN, for example a PC with a WLAN card, is turned on and connected to the WLAN.

Next, a question is asked as to whether the UMTS has the triple objective information. In the case that the UMTS does not have the target information, the routine branches to S44 to obtain the system terminal information and / or the subscriber IP information, returning again to S43. When the target information is available, the routine branches to S45, after which the HSS contacts the UMTS. The routine then proceeds to S46 to determine if the WLAN terminal is on. In the event that the WLAN terminal is turned off, the routine branches to S47, requesting the subscriber to activate the WLAN terminal and confirm the activation. It should be noted that step S47 is substantially identical to the corresponding step S32 shown in FIG. 7 and the identity of these steps is shown by locating "(S32)" next to step S47. Thus, steps S48 to S50 function in substantially the same way as steps S37 to S39 of Figure 7 and are shown with the associated equivalent step number of Figure 7 in parentheses. Therefore, in connection with the execution of steps S48 to S50, reference should be made to the description of steps S37 to S39 set forth above.

Referring to step S50, the HSS in the UMTS is contacted after a predetermined interval (S45) in response to the completion of step S50.

When the WLAN terminal is identified as being powered on (S46), the target IP address is obtained and the rerouting process is performed (S52).

Figure 9 shows the scenario for HO from UMTS to a WLAN without interworking. Referring to Figure 9, steps S40 to S43 are substantially identical to corresponding steps S40 to S43 shown in Figure 8 and reference should be made to the description of these corresponding steps as set forth above.

In the case that the UMTS does not have the target information, the program branches to step S44, which is substantially similar to the corresponding step 44 in FIG. 8 and the description of which is set forth above.

Once the target information is obtained, the routine branches to S53 to extract the target IP address. The existence of the IP address is checked in step S54. If the confirmation is positive (S55), the rerouting process is performed (S56). In case the confirmation has not been received, the routine branches to S57 to instruct the subscriber to turn on the terminal and provide information that these steps have been performed. In step S58, once the confirmation is received, the routine then branches to S59 and the routine returns to S43. Steps S43 to S55 are repeated again and, in the event that no confirmation is received (S55), and this is the second question, the routine branches to S57 A, after which the HO attempt is aborted (S60 ).