HK1140623A - Method and apparatus for resource management in handover operation - Google Patents

Description

Method and apparatus for resource management in handover operation

Technical Field

The present invention relates to wireless communications.

Background

A wireless transmit/receive unit (WRTU) may be a User Equipment (UE) in some cases, which is subject to handover in communications. The handover may be from a trusted (trusted) non-third generation partnership project (non-3 GPP) Internet Protocol (IP) access system towards a 3GPP access system (evolved universal terrestrial radio access network (E-UTRAN)) or from a 3GPP access system (E-UTRAN) towards a trusted non-3 GPP IP access system.

Furthermore, handover may occur in roaming or non-roaming situations. Fig. 1 shows an example network architecture 100. As defined in fig. 1 and below, the following reference points will apply:

s2 a: related control and mobility support is provided for the user plane between trusted non-3 GPP IP access and a Packet Data Network (PDN) Gateway (GW).

S2 b: related control and mobility support is provided for the user plane between an evolved packet data gateway (ePDG) and a PDN GW.

S2 c: related control and mobility support is provided for the user plane between the WTRU and the PDN GW. The reference point is implemented over trusted and/or untrusted non-3 GPP accesses and/or 3GPP accesses.

S5: user plane tunneling and tunnel management is provided between the serving GW and the PDN GW. If the serving GW needs to implement the necessary PDN connection by connecting to a PDN GW that is not co-located, then this S5 will be used for serving GW relocation due to WTRU mobility.

S6 a: the interface is defined between a Mobility Management Entity (MME) and a Home Subscriber Server (HSS) for authentication and authorization purposes.

S6 c: the reference point is a reference point for performing mobility-related authentication between a PDN GW in a Home Public Land Mobile Network (HPLMN) and a 3GPP authorization, authentication, and accounting (AAA) server, as needed. The reference point may also be used for retrieval and request storage of mobility parameters.

S6 d: this reference point is interposed between the serving gateway and the 3gpp aaa proxy in the Visited Public Land Mobile Network (VPLMN) and performs mobility-related authentication as needed. The reference point may also be used for retrieval and request storage of mobility parameters.

S7: it provides for the transfer of quality of service (QoS) policy and charging rules from a Policy and Charging Rules Function (PCRF) to a policy and charging enforcement Point (PCEF). The allocation of PCEF is under further investigation (FFS).

S8 b: for roaming handling with home routing traffic, it is the roaming interface. It provides relevant control for the user plane between the VPLMN and the gateway of the HPLMN.

S9: it indicates a roaming variant of the S7 reference point in the VPLMN implementing the dynamic control policy from the HPLMN.

SGi: the reference point is between the PDN gateway and the packet data network. The packet data network may be either a public or private data packet network external to the operator or an intra-operator packet data network, e.g. a packet data network for providing IP Multimedia Subsystem (IMS) services. The reference points correspond to Gi and Wi functions and support any of 3GPP and non-3 GPP access systems.

Wa: it connects untrusted non-3 GPP IP access to 3GPP AAA server/proxy and uses secure mode to transfer information related to access authentication, authorization and accounting.

Ta: it connects trusted non-3 GPP IP access with 3GPP AAA server/proxy and employs security mode to transfer information related to access authentication, authorization, mobility parameters and accounting.

Wd: it connects the 3gpp aaa proxy with the 3gpp aaa server, wherein the connection can be made via an intermediate network. The difference from Wd is to be studied further.

Wm: this reference point is located between the 3GPP AAA server/proxy and the ePDG and is used for AAA signaling (transport mobility parameters, tunnel authentication and authorization data).

Wn: it is the reference point between the non-trusted non-3 GPP IP access and the ePDG. On this interface, traffic for the initiated tunnel must be imposed on the ePDG.

Wx: this reference point is located between the 3GPP AAA server and the HSS and is used to transfer authentication data.

It is currently considered to use S6, S8, and S9 to provide static/dynamic policies for visited networks. It is also considered whether there is a difference between the two described S7 interfaces. The S1 interface for E-UTRAN is the same for both architectures.

Fig. 2 is a signal diagram 200 of a conventional handover process from a 3GPP access UTRAN to a trusted non-3 GPP IP access network. The handover scheme involves the S2a reference point and includes a scheme that uses PMIPv6 and mobile IP4(MIP4) in conjunction with a foreign agent care-of address (FACoA). For the FaCoA mode of MIPv4, it can be assumed that S2a is running between the FA in the non-3 GPP system and the PDN GW in the HPLMN. Although the WTRU is connected in the 3GPP access system, PMIPv6 or General Packet Radio Service (GPRS) tunneling protocol (GTP) is used over S5. The dual stack mobile IPv6(DSMIPv6) protocol used at S2c is compliant with the DSMIPv6 specification over the S2a interface, where PMIPv6 is used for non-roaming scenarios. The signaling is performed as follows:

the WTRU discovers a trusted non-3 GPP IP access and decides to initiate a handover from the currently used UTRAN access to the discovered trusted non-3 GPP IP access system. Mechanisms for assisting the WTRU in discovering trusted non-3 GPP IP accesses are specified in the network discovery and selection section. At this time, both uplink and downlink user data are transmitted by means of: a bearer between the WTRU and the source access network, a source 3GPP access network, one or more GTP tunnels between the serving GW and the PDN GW.

2. An L2 procedure dedicated to the initial non-3 GPP access is performed. These procedures are specific to non-3 GPP access and are outside the 3GPP range.

3. Initiate and perform an EAP authentication procedure, wherein the procedure involves the WTRU, a trusted non-3 GPP IP access, and a 3GPP AAA server. In a roaming scenario, where several AAA proxies may be involved. As part of the authentication procedure, the IP address of the PDN GW that needs to be used will be passed to the PMA in the trusted non-3 GPP IP access.

4. After successful execution of authentication and authorization, an L3 additional process is triggered.

5. The PMA function of the trusted non-3 GPP IP access sends a proxy binding update message to the PDN GW.

The PDN GW processes the proxy binding update and creates a binding cache entry for the WTRU. The PDN GW allocates an IP address for the WTRU. The PDN GW then sends a proxy binding acknowledgement to the PMA function in the trusted non-3 GPP IP access, where the acknowledgement includes the IP address or addresses assigned to the WTRU. The assigned IP address is the same as the IP address previously assigned to the WTRU by the 3GPP access.

7.A PMIPv6 tunnel is established between the trusted non-3 GPP IP access and the PDN GW.

8. The L3 additional process is completed. An IP connection is established between the WTRU and the PDN GW for uplink and downlink directions over the trusted non-3 GPP IP access.

9. Resource cleaning for source 3GPP access is initiated by performing the necessary procedures according to the procedures specified in the 3GPP standards.

Figure 3 is a signal diagram 300 of a handover from a conventional trusted non-3 gpp ip access to E-UTRAN with PMIPv6 handover for a non-roaming scenario. The signaling is performed as follows:

UE uses a trusted non-3 GPP access system and is served by PDN GW.

The UE discovers the E-UTRAN access system and determines to transfer (i.e., handover) its current session from the currently used non-3 GPP access system to the discovered E-UTRAN access system. Mechanisms for assisting a UE in discovering an E-UTRAN access system.

The UE sends an attach request and the request is routed by the E-UTRAN to the MME instance in the EPS.

The MME gets in contact with the HSS and authenticates the UE. As part of the authentication procedure, the IP address of the PDN GW that needs to be used is passed to the MME.

5. After successful authentication, the MME performs a location update procedure in conjunction with the HSS.

MME selects a serving GW and sends create default bearer request (IMSI, MME context ID) message to the selected serving GW. It also includes the IP address of the PDN GW provided by the HSS.

7. Upon a create default bearer request from the MME, the serving GW initiates a PMIPv6 registration procedure with the PDNGW by sending a proxy binding update.

The PDN GW acknowledges with a proxy binding ACK and updates its mobility binding which effectively switches PMIPv6 tunnel from the non-3 GPP access network to the serving GW. In the proxy binding ACK, the PDN GW responds with the same IP address or prefix earlier assigned to the UE. Now, there is one PMIPv6 tunnel between the PDN GW and the serving GW.

9. The serving GW returns a create default bearer response message to the MME. The message also contains the IP address of the UE. In addition, this message also serves as an indication to the MME that the binding has been successful.

The MME sends an attach accept message to the UE via the E-UTRAN.

11. A radio bearer and an S1-U bearer are established.

The UE resumes data communication over the E-UTRAN.

Figure 4 is a signal diagram 400 of a handover from a conventional E-UTRAN to a trusted non-3 GPP IP access with a PMIPv6 handover for a non-roaming scenario. The signaling is performed as follows:

UE uses trusted non-3 GPP access system and is served by PDN GW.

The UE discovers the E-UTRAN access system and determines to transfer (i.e., handover) its current session from the currently used non-3 GPP access system to the discovered E-UTRAN access system. Mechanisms for assisting a UE in discovering an E-UTRAN access system are specified in the 3GPP standards.

The UE sends an attach request and the request is routed by the E-UTRAN to the MME instance in EPS as specified in TS 23.401.

The MME gets in contact with the HSS and authenticates the UE. As part of the authentication procedure, the IP address of the PDN GW that needs to be used is passed to the MME.

5. After successful authentication, the MME performs a location update procedure in conjunction with the HSS.

MME selects a serving GW and sends create default bearer request (IMSI, MME context ID) to the selected serving GW. It also contains the IP address of the PDN GW provided by the HSS.

7. The serving GW initiates a PMIPv6 registration procedure to the PDN GW by sending a proxy binding update according to a create default bearer request from the MME.

The PDN GW responds with a proxy binding acknowledgement and updates its mobility binding, which effectively switches the PMIPv6 tunnel from the non-3 GPP access network to the serving GW. In the proxy binding ACK, the PDN GW responds with the same IP address or prefix earlier assigned to the UE. Now, there is one PMIPv6 tunnel between the PDN GW and the serving GW.

9. The serving GW returns a create default bearer response message to the MME. The message also contains the IP address of the UE. In addition, the message also serves as an indication to the MME that the binding has been successful.

The MME sends an attach accept message to the UE via the E-UTRAN.

11. A radio bearer and an S1-U bearer are established.

The UE resumes data communication over the E-UTRAN.

Fig. 5 is a signal diagram 500 of a conventional procedure for implementing a handover from a trusted non-3 GPP IP access system to a 3GPP access system with DSMIPv6 over S2c in a conventional non-roaming scenario. In this scheme, a session is started in a trusted non-3 GPP access system (e.g., E-UTRAN) by using DSMIPv6 in a non-roaming scheme. Subsequently, the session is handed over to the 3GPP access system. The signaling is performed as follows:

UE uses trusted non-3 GPP access system. It has a DSMIPv6 session with the PDN GW.

The UE discovers the 3GPP access system and determines to handover from the currently used trusted non-3 GPP access system to the discovered 3GPP access system. Mechanisms for assisting a UE in discovering a 3GPP access system are specified in the 3GPP specifications.

The UE sends an attach request and the request is routed by the 3GPP to the MME instance in the EPC.

MME gets in touch with HSS/3GPPAAA and authenticates UE. As part of the authentication procedure, the IP address of the PDN GW that needs to be used in the 3GPP access is passed to the MME.

5. After successful authentication, the MME performs a location update procedure in conjunction with the HSS.

MME selects a serving GW and sends create default bearer request (including IMSI, MME context ID and PDN GW IP address) message to the selected serving GW.

7.a) for IETF based S5, the serving GW initiates PMIPv6 registration procedure for the PDN GW by sending a proxy binding update. If the NAI of the subscriber is not contained in step 6, the serving GW must derive the NAI by other means.

b) For GTP-based S5, the serving GW sends a create bearer request message to the PDN GW.

A) for IETF based S5, the PDN GW responds with a proxy binding acknowledgement and updates its mobility binding which effectively switches the DSMIPv6 tunnel from the non-3 GPP access system to the PMIPv6 tunnel connected to the serving GW. In the proxy binding acknowledgement, the PDN GW contains the same IP address or prefix that was earlier assigned to the UE.

b) For GTP-based S5, the PDN GW responds to the serving GW with a create bearer response message. The create bearer response contains the same IP address or prefix that was earlier assigned to the UE.

9. The serving GW returns a create default bearer response message to the MME. The message also contains the IP address of the UE. In addition, the message also serves as an indication to the MME that the binding has been successful.

The MME sends an additional message to the UE over the 3GPP access. The 3GPP access system initiates a radio bearer establishment procedure. And the 3GPP access system responds with an attach complete message.

The UE may send a BU to the PDN GW to deregister its DSMIPv6 binding, which is created when the UE is in a non-3 GPP access system.

Fig. 6 is a signal diagram 600 of a conventional procedure for implementing a handover from a 3GPP access system to a trusted non-3 GPP IP access system with DSMIPv6 over S2c in a non-roaming scenario. In this scenario, the session is started in a 3GPP access (e.g., E-UTRAN) by using GTP on S5, or S5 (co-located serving GW and PDN GW) may not be used. The session is handed over to a trusted non-3 GPP access system that does not use PMIPv6, in which case the UE will receive a different prefix than it uses in the 3GPP access system. The UE will then initiate DSMIPv6 with the PDN GW in order to maintain the IP session. The signaling is performed as follows:

US uses a 3GPP access system. It has an IP address supported on the S5 interface.

2. At this point, the UE decides to initiate a non-3 GPP access procedure. The decision is based on any number of reasons, such as the local policy of the UE.

The UE performs access authentication and authorization procedures in the non-3 GPP access system. The 3GPP aaa server authenticates and authorizes the UE for access in the non-3 GPP system. It should be noted that the PDN GW selection and retrieval process for host-based mobility remains to be further studied.

4. The non-3 GPP access system does not have PMIPv6 capability or it decides not to use PMIPv 6. Thereby, the UE gets an IP address different from the one it used in the 3GPP access system. Since the UE acquires an IP address different from that from the 3GPP system, the UE decides to initiate the DSMIPv6 procedure in order to maintain its IP session.

The UE may discover the PDN GW address using MIPv6 bootstrapping procedure.

The UE may also perform IKEv2 and ipsec sa establishment procedures in conjunction with the PDN GW discovered in step 5. This is done if RFC 4877 is used to establish an SA between the UE and the PDN GW. This step may include authentication and authorization performed by the 3gpp aaa system.

The UE sends a DSMIPv6BU message to the PDN GW in order to register its CoA. The PDN GW performs authentication and authorization for the UE, and the UE sends a BA in reverse, where the BA contains the IP address (home address) used by the UE in 3GPP access.

The UE continues IP services using the same IP address.

Thus, it would be advantageous to provide a method and apparatus for managing system resources after a successful handoff.

Disclosure of Invention

The invention discloses a resource management method and equipment used in a switching operation process. The method includes initiating a handover from a first access network to a second access network. A policy update message is sent and a policy update confirm message is received. Sending a General Packet Radio Service (GPRS) tunneling protocol (GTP) message and a Radio Access Bearer (RAB) release message, and receiving a GTP and RAB release acknowledgement. A connection for uplink and downlink transmissions is established in the second access network.

Drawings

The invention will be understood in more detail from the following description of examples, given by way of example and understood in conjunction with the accompanying drawings, in which:

FIG. 1 shows an example network architecture;

FIG. 2 is a signal diagram of a conventional handover from a 3GPP access UTRAN to a trusted non-3 GPP IP access network;

figure 3 is a signal diagram of a handover from a conventional trusted non-3 gpp ip access to E-UTRAN with PMIPv6 handover for a non-roaming scenario;

figure 4 is a signal diagram of a handover from conventional E-UTRAN to trusted non-3 GPP IP access with PMIPv6 handover for a non-roaming scenario;

fig. 5 is a signal diagram of a conventional procedure for implementing a handover from a trusted non-3 GPP IP access system to a 3GPP access system with DSMIPv6 over S2c in a conventional non-roaming scenario;

fig. 6 is a signal diagram of a conventional procedure for implementing a handover from a 3GPP access system to a trusted non-3 GPP IP access system by means of DSMIPv6 over S2c in a non-roaming scenario;

figure 7 is an exemplary functional block diagram of a WTRU and a base station in wireless communication with each other;

8A-8B are signal diagrams for handover from 3GPP Access (UTRAN) to trusted non-3 GPP IP Access network over S2a with PMIPv 6;

FIGS. 9A-9B are signal diagrams for handover from a trusted non-3 GPP IP access network to E-UTRAN with PMIPv 6;

figures 10A-10B are signal diagrams for handover from E-UTRAN to a trusted non-3 GPP IP access network via PMIPv 6.

11A-11B are signal diagrams for a handover from a trusted non-3 GPP IP access network to a 3GPP access network by way of DSMIPv6 over S2 c;

FIGS. 12A-12B are signal diagrams for a handoff from a 3GPP access network to a trusted non-3 GPP IP access network by way of DSMIPv6 over S2 c; and

fig. 13 is a signal diagram of an LTE _ RA update procedure.

Detailed Description

When referred to hereafter, the terminology "wireless transmit/receive unit (WTRU)" includes but is not limited to a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a Personal Digital Assistant (PDA), a computer, or any other user device capable of operating in a wireless environment. When referred to hereafter, the terminology "base station" includes but is not limited to a node-B, a site controller, an Access Point (AP), or any other interfacing device capable of operating in a wireless environment.

Figure 7 is an example functional block diagram 700 of a WTRU110 and a base station 120. As shown in fig. 7, the WTRU110 communicates with the base station 120.

In addition to the components that may be found in a typical WTRU, the WTRU110 includes a processor 115, a receiver 116, a transmitter 117, and an antenna 118. The receiver 116 and the transmitter 117 are in communication with the processor 115. The antenna 118 is in communication with both the receiver 116 and the transmitter 117 to facilitate the transmission and reception of wireless data. The processor 115 of the WTRU110 is configured to perform handover.

In addition to the components that may be found in a typical base station, the base station 120 includes a processor 125, a receiver 126, a transmitter 127, and an antenna 128. The receiver 126 and the transmitter 127 are in communication with the processor 125. The antenna 128 communicates with both the receiver 126 and the transmitter 127 to facilitate the transmission and reception of wireless data. The processor 125 of the base station is configured to perform a handover.

Figures 8A-8B are signal diagrams 800 of a handover from a 3GPP access (EUTRAN) to a trusted non-3 GPP IP access system via PMIPv6 at S2 a. In the signal diagram 800, an apparatus that performs communication includes: a WTRU110, a 3GPP access device 130, a trusted non-3 GPP access network 140, an SGSN150, a serving SAE GW 160, a PDN SAE GW 170, and an HSS/AAA server 180 and a PCRF 190.

The WTRU110 discovers the trusted non-3 GPP IP access network 140 and decides to initiate a handover from the currently used UTRAN access to the discovered trusted non-3 GPP IP access system (815). At this point, both uplink and downlink user data are transmitted via the bearer between the WTRU110 and the source access network, the GTP tunnel, or multiple tunnels between the source 3GPP access network 130, the serving SAE GW 160, and the PDNSAE GW 170 (810).

An L2 procedure dedicated to the initial non-3 GPP access is then performed between WTRU110 and trusted non-3 GPP IP access network 140 (820). These procedures are specific to non-3 GPP access and are outside the 3GPP range.

EAP authentication and authorization procedures are initiated and performed and involve the WTRU110, the trusted non-3 GPP ip access network 140, and the 3GPP HSS/AAA server 180 (425). In a roaming situation, where several AAA proxies may be involved. As part of the authentication procedure, the IP address of the used PDN SAE GW 170 may be passed to a proxy mobile IP agent (PMA) in the trusted non-3 GPP IP access network 140.

After successful execution of authentication and authorization, a third layer (L3) attach procedure (830) is triggered. The PMA function of the trusted non-3 GPP IP access network sends a proxy binding update message to the PDN SAE GW 170 (835), and the GW processes the proxy binding update message and creates a binding cache entry for the WTRU 110. The PDN SAE GW 170 then allocates an IP address for the WTRU110 and sends a proxy binding Acknowledgement (ACK) message to the PMA function in the trusted non-3 GPP IP access network 140 (840). The proxy binding ACK message (840) may include one or more IP addresses assigned for the WTRU 100. The assigned IP address may be the same as the IP address assigned to the WTRU110 prior to handover from the 3GPP access network 130.

A PMIPv6 tunnel is established between the trusted non-3 GPP IP access network 140 and the PDN SAE GW 170 (845). A policy update message indicating a new GW is sent from PDN SAE GW 170 to PCRF 190 (850). PCRF 190 then sends policy update confirm message 855 to PDNSAE GW 170. The PCRF 190 sends a policy information update message to the trusted non-3 GPP access network 140 (860), where the message contains the new GW. The trusted non-3 GPP access network 140 then sends a policy update confirm message to PCRF 190 (865).

In step 870, GTP tunnel endpoint and Radio Access Bearer (RAB) resources will be released. The PDN SAE GW 170 sends a GTP and RAB release message to the SGSN150 (875), which forwards the RAB release message to the 3GPP access network 130 (876) in order to release the endpoint and radio resources. The 3GPP access network 130 then sends a RAB release ACK message to the SGSN150 (877), which forwards it to the PDN SAE GW 170 in the form of a GTP and RAB release ACK message (878).

At this stage, the L3 additional process is completed (step 880). An IP connection is set up between the WTRU110 and the PDNSAE GW 170 for the uplink and downlink directions over the trusted non-3 GPP IP access network 140. Resource cleanup processing for the source 3GPP access network 130 is then initiated by performing the necessary 3GPP release procedure (890). At this point, the PDN SAE GW 170 should maintain an IP connection for the WTRU 110.

Figures 9A-9B are signal diagrams 900 for handover from a trusted non-3 GPP IP access network to E-UTRAN via PMIPv 6. In signal diagram 900, an apparatus that performs communication includes: WTRU110, trusted non-3 GPP access network 135, E-UTRAN 145, Mobility Management Entity (MME)155, serving GW165, and legacy MME175, PDN GW185, HSS/AAA server 186, and PCRF 190.

In this scenario, the WTRU110 starts operating with the trusted non-3 GPP access network 135 and is served by the PDN GW185 over the PMIPv6 tunnel (step 910). The WTRU110 discovers the LTE E-UTRAN access network 145 and decides to transfer its current session from the currently used non-3 GPP access system to the discovered E-UTRAN access network via handover (step 915).

The WTRU sends an attach request message 920 which is routed by the E-UTRAN access network 145 to the MME 155, and the MME 155 in turn contacts the HSS/AAA186 and authenticates the WTRU110 (step 925). As part of the authentication procedure, the IP address of the PDN GW185 is passed to the MME 155. After successful authentication, the MME 155 performs a location update procedure in conjunction with the HSS/AAA186, where the procedure involves a subscriber data retrieval (step 926).

The MME 155 selects the serving GW165 and sends a create default bearer request (IMSI, MME context ID) message (930) to the selected serving GW165, where the message contains the IP address of the PDN GW185 provided by the HSS/AAA 186.

Upon a create default bearer request from the MME 155, the serving GW165 initiates a PMIPv6 registration procedure with the PDN GW185 by sending a proxy Binding Update (BU) message (935). The PDNGW 185 responds 935 with a proxy binding ACK and updates its mobility binding, thereby effectively handing over the PM IPv6 tunnel from the trusted non-3 GPP access network 135 to the serving GW 165. In the proxy binding ACK message (936), the PDN GW185 responds with the same IP address or prefix earlier specified to the WTRU 110. Now, there is one PMIPv6 tunnel between the PDN GW185 and the serving GW 165.

The serving GW165 returns a create default bearer response message (940) to the MME, and this message contains the IP address of the WTRU 110. In addition, the message also serves as an indication to the MME 155 that the binding has been successful.

The PDN GW185 sends a policy update message to the PCRF 190 (941), and the PCRF 190 responds by sending a policy update confirm message to the PDN GW185 (942).

The MME 155 sends an attach accept message to the WTRU110 through the E-UTRAN 145 (943). The attach accept message (943) contains the IP address of the WTRU 110.

PCRF 190 then sends a policy information update message with information about the new GW to serving GW165 (950), and establishes a radio bearer and an S1 bearer (step 955), and serving GW sends a policy update confirm message to PCRF 190 (956).

To complete the handover, the PDN GW185 sends a message requesting release of the tunnel endpoint and radio resources to the trusted non-3 GPP IP access entity 135 (960), which then returns a release Acknowledgement (ACK) message to the PDN GW185 regarding the release (965). Then, the radio and S1 bearers are established (step 970), and the PMIPv6 tunnel is established (step 975).

Figures 10A-10B are signal diagrams 1000 of handover from E-UTRAN to a trusted non-3 GPP IP access network via PMIPv 6. In the signal diagram 1000, an apparatus that performs communication includes: WTRU110, trusted non-3 GPP access network 135, E-UTRAN 145, MME 155, serving GW165, PDN GW185, HSS/AAA server 186, and PCRF 190. In this scheme, both uplink and downlink user data are transmitted via: radio and SI bearers between the WTRU110 and the source access network (1011), and one or more GTP tunnels between the source 3GPP access network, the serving GW165, and the PDN GW185 (1010).

The WTRU110 discovers the trusted non-3 GPP IP access system 135 and decides to initiate a handover from the currently used E-UTRAN access network 145 to the discovered trusted non-3 GPP IP access system 135 (step 1015). The L2 procedure dedicated to the initial 3GPP access is performed (step 1020).

EAP authentication and authorization procedures are initiated and performed (step 1025) and involve the WTRU110, the trusted non-3 GPP IP access system 350, and the 3GPP HSS/AAA server 186. In the roaming state, several AAA proxies may be involved. As part of the authentication and authorization process, the IP address of the used PDN SAE GW 170 may be passed to the PMA in the trusted non-3 GPP IP access system 135. After successful execution of authentication and authorization, an L3 attach procedure is triggered (1030).

The PMA function of the trusted non-3 GPP IP access system 135 sends a proxy binding update message to the PDN GW185 (1035), and the PDN GW185 processes the proxy binding update and creates a binding cache entry for the WTRU110 and allocates an IP address for the WTRU 110. The PDNGW 185 then sends a proxy binding acknowledgement message (1040) to the PMA function in the trusted non-3 GPP IP access system 135, where the message contains the one or more IP addresses assigned for the WTRU 110. The assigned IP address is the same as the address assigned to the WTRU110 on the 3GPP access.

A PMIPv6 tunnel is established between the trusted non-3 GPP IP access system 135 and the PDN GW185 (step 1045).

PDN GW185 sends a policy update message to PCRF 190 (1046), which responds with a policy update confirm message (1047). PCRF 190 then sends a policy information update message to trusted non-3 GPP IP access entity 135 with information about the new GW (1048). The trusted non-3 GPP IP access entity then sends a policy update confirm message back to PCRF 190 (1050).

To complete the handover, the PDN GW185 sends a message (1055) requesting release of the tunnel endpoint and radio resources to the serving GW165, the serving GW165 forwards a GPRS Tunneling Protocol (GTP) and Radio Access Bearer (RAB) release request message (1060) to the MME 155, and the message is forwarded to the E-UTRAN 145. The E-UTRAN 145 sends a GTP and RAB release ACK message 1065 to the MME 155, which forwards the release ACK message to the PDN GW 185. At this point, the L3 attach process is complete (step 1075). An IP connection between the WTRU110 and the PDN GW185 is established for uplink and downlink directions at the trusted non-3 GPP IP access entity 135.

11A-11B are signal diagrams 1100 for a handover from a trusted non-3 GPP IP access network to a 3GPP access network by way of DSMIPv6 over S2 c. In signal diagram 1100, an apparatus that performs communication includes: WTRU110, trusted non-3 GPP access network 135, E-UTRAN 145, Mobility Management Entity (MME)155, serving GW165, and legacy MME175, PDN GW185, HSS/AAA186, and PCRF 190.

In this scenario, the session is started in a trusted non-3 GPP access system (e.g., E-UTRAN) using DSMIPv6 in a non-roaming scenario and via a DSMIPv6 tunnel 1110 between the WTRU110 and the PDN GW 185.

In step 1115, the WTRU110 discovers the 3GPP access system and determines to switch from the currently used trusted non-3 GPP access system 135 to the discovered 3GPP access system. The WTRU110 sends an attach request message (1120), and the message is routed by the 3GPP access system to the MME 155. The MME 155 contacts the HSS/AAA server 186 and authenticates the WTRU110 (step 1125). As part of the authentication procedure, the IP address of the PDN GW185 used in the 3GPP access is passed to the MME 155. After successful authentication, the MME 155 performs a location update procedure with the HSS/AAA server 186 (step 1130).

The MME 155 selects the serving GW165 and sends a create default bearer request (including IMSI, MME context ID, and PDN GW IP address) message to the selected serving GW165 (1135).

For IETF based S5, the serving GW165 initiates a PMIPv6 registration procedure with the PDN GW185 by sending a proxy binding update message (1140). If the user's NAI is not contained, the serving GW165 may deduce it. The PDN GW185 responds with a proxy binding ACK message (1145) and updates its mobility binding, which effectively switches the DSMIPv6 tunnel from the non-3 GPP access network to the PMIPv6 tunnel connected to the serving GW 165. In the proxy binding ACK message (1145), the PDN GW185 contains the same IP address or prefix as was earlier specified for the WTRU 110.

For GTP-based S5, the serving GW165 sends a create bearer request message (1146) to the PDN GW185, and the PDN GW185 responds to the serving GW165 with a create bearer response message (1147). The create bearer response message (1147) contains the same IP address or prefix as was earlier designated to the WTRU 110.

The serving GW165 returns a create default bearer response message to the MME 155 (1155). The message also contains the IP address of the WTRU 110. In addition, the message also serves as an indication to the MME 155 that the binding has been successful. A policy update message indicating a new GW is sent from the PDN GW185 to the PCRF 190 (1150). And PCRF 190 sends policy update confirm message 1156 to PDN GW 185.

PCRF 190 sends policy information update message 1157 to serving GW165, which serving GW165 responds with policy update confirm message 1159.

In step 1158, Radio Bearer (RB) and S1-U bearer establishment processing are performed, and additional processing in EUTRAN is completed. This may be done in conjunction with the MME 155 sending an attach accept message to the WTRU110 through the 3GGP access and the 3GPP access system initiating the radio bearer establishment procedure. The 3GPP access system may respond with an additional complete message. Radio and S1 bearers are then established (step 1160) and a PMIPv6/GTP tunnel is established between the serving GW165 and the PCRF 190 (step 1161).

The PDN GW185 sends a release resource message to the trusted non-3 GPP IP access system 135 (1165), and the trusted non-3 GPP IP access system 135 sends a release acknowledgement message 1170 to the PDN GW 185.

At this time, the WTRU110 may send a BU to the PDN GW185 to revoke the DSMIPv6 binding that was created when the WTRU110 was in a non-3 GPP access system (step 1175).

Fig. 12A-12B are signal diagrams 1200 of a handover from a 3GPP access network to a trusted non-3 GPP IP access network by means of DSMIPv6 over S2 c. In the signal diagram 1200, an apparatus that performs communication includes: WTRU110, trusted non-3 GPP access network 135, E-UTRAN 145, Mobility Management Entity (MME)155, serving GW165, and old MME175, PDN GW185, HSS/AAA server 186, and PCRF 190. In this scheme, a session is started in a 3GPP access (e.g., in E-UTRAN) by using PMIPv6 or GTP on S5. Alternatively, S5 is not used, for example, if the serving GW165 is co-located with the PDN GW 185. The session is handed over to the trusted non-3 GPP access system 135 that does not use PMIPv6, in which case the WTRU110 receives a different prefix than it uses in the 3GPP access system. The WTRU110 then initiates DSMIPv6 with the same PDN GW185 in order to maintain the IP session.

In step 1210, the WTRU110 uses a 3GPP access system and has an IP address supported on the S5 interface. In addition, there is a PMIPv6/GTP tunnel between the serving GW165 and the PDN GW 185.

The WTRU110 discovers the trusted non-3 GPP access system 135 and initiates a non-3 GPP access procedure (step 1215). The decision may be based on a variety of reasons, such as local policy of the WTRU 110.

In step 1220, the WTRU110 performs access authentication and authorization in the non-3 GPP access system. The 3GPP HSS/AAA server 186 authenticates and authorizes the WTRU110 for access in non-3 GPP systems.

CoA configuration is performed between the WTRU110 and the trusted non-3 GPP IP access system 135 (step 1225). The non-3 GPP IP access system 135 may not have PMIPv6 capability or it may not use PMIPv 6. Thus, it is possible for the WTRU110 to receive an IP address that is different from the IP address it uses in the 3GPP access system. Since the WTRU110 acquires an IP address different from the address from the 3GPP system, the WTRU110 may initiate a DSMIPv6 procedure in order to maintain its IP session.

In step 1230, WTRU110 may discover the address of PDNGW 185 by using MIPv6 bootstrap procedure. WTRU110 may also perform IKEv2 and IPSec SA establishment in conjunction with the PDN GW (step 1235). This process is performed if RFC 4877 is used to establish an SA between the WTRU110 and the PDN GW 185. The process may also include authentication and authorization performed by the 3gpp sss/AAA system 186 (step 1236).

The WTRU110 then sends a DSMIPv6BU message (1240) to the PDN GW185 to register its CoA. The PDN GW185 authenticates and authorizes the WTRU110, and the WTRU110 sends a BA in reverse, where the BA includes the IP address or home address used by the WTRU110 in the 3GPP access system. Further, a policy update message indicating a new GW is sent from the PDN GW185 to the PCRF 190 (1245), and the PCRF 190 responds to the PDN GW185 with a policy update confirm message.

PCRF 190 then sends a policy information update message to trusted non-3 GPP IP access system 135 (1246). The trusted non-3 GPP IP access system 135 then sends a policy update confirm message to PCRF 190.

The DSMIPv6 tunnel is established (step 1250) and GTP tunnel endpoints and RAB resources are released (step 1255). This process may be accomplished by the PDN GW185 by sending a release GTP tunnel endpoint and RAB resources message 1260 to the serving GW165, which in turn forwards a RAB release message 1261 to the E-UTRAN 145. The E-UTRAN 145 sends a RAB release acknowledgement message 1265 to the serving GW165, which serving GW165 forwards the GTP and RAB release ACK message 1270 to the PDN GW 185. At this point, the WTRU110 may continue IP services by using the same IP address.

Fig. 13 is a signal diagram 1300 of an LTE _ RA update procedure. In fig. 13, the devices performing the communication are the LTE WTRU110, the enodeb 120, and the LTE MME/UPE 155.

In step 1310, the mobile (moving) LTE WTRU110 is in LTE _ IDLE state (CELL _ PCH). The LTE WTRU110 enters a new LTE _ RA (i.e., changes its CELL), camps on a new BCCH, and receives a system information broadcast (CELL _ ID) to determine the new LTE _ RA to which the CELL belongs (step 1315).

In step 1340, the LTE WTRU110 is in LTE-active state (CELL _ DCH) and performs an LTE _ RA update procedure by sending an LTE RA update message (1325) containing the temporary identity of the LTE WTRU 110. The new enodeb 120 determines the target MME/UPE155 (step 1330) and routes the LTE _ RA update message (1335) to the correct MME/UPE 155. In step 1340, the LTE MME/UPE155 recognizes that the LTE WTRU110 is in LTE-active state (CELL _ DCH) and sends an LTE _ RA update confirm message 1345, which assigns the LTE WTRU110 to a new LTE _ RA and commands it to return to LTE _ IDLE state.

The LTE WTRU110 sends an LTE _ RA update complete message to the LTE MME/UPE155 (1350). The LTE WTRU110 then re-enters the LTE _ IDLE state (CELL _ PCH) (step 1360). Due to the many-to-many (multi-to-multi) relationship between the eNode-B120 and the LTE MME/UPE155, the number of occurrences of network attachment processing may be reduced.

Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. The methods or flow charts provided in the present invention may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium, examples of which include Read Only Memory (ROM), Random Access Memory (RAM), registers, buffer memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs), for execution by a general purpose computer or a processor.

For example, suitable processors include: a general-purpose processor, a special-purpose processor, a conventional processor, a Digital Signal Processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any Integrated Circuit (IC), and/or a state machine.

A processor in association with software may be used to implement a radio frequency transceiver for use in a Wireless Transmit Receive Unit (WTRU), user equipment, terminal, base station, radio network controller, or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a video circuit, a speakerphone, a vibration device, a speaker, a microphone, electricalVideo transceiver, hands-free earphone, keyboard and BluetoothA module, a Frequency Modulation (FM) radio unit, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any of a Wireless Local Area Network (WLAN) module or an Ultra Wideband (UWB) module.

Examples

1. A method for resource management during handover operations.

2. The method of embodiment 1 further comprising initiating a handover from the first access network to the second access network.

3. A method as in any preceding embodiment, further comprising sending a policy update message.

4. The method of any preceding embodiment, further comprising receiving a policy update confirmation message.

5. The method of any preceding embodiment, further comprising sending a General Packet Radio Service (GPRS) tunneling protocol (GTP) and Radio Access Bearer (RAB) release message.

6. A method as in any preceding embodiment, further comprising receiving a GTP and RAB release Acknowledgement (ACK).

7.A method as in any preceding embodiment, further comprising establishing connections for uplink and downlink transmissions in the second access network.

8.A method as in any preceding embodiment wherein the policy update message contains information relating to a Gateway (GW) in the second access network.

9. A method as in any preceding embodiment, further comprising releasing resources in the first access network.

10. A method as in any preceding embodiment, wherein the first network is a third generation partnership project (3GPP) access network and the second network is a trusted non-3 GPP Internet Protocol (IP) access network.

11. The method according to any of the preceding embodiments, wherein the policy update message, the policy update confirmation message, the GTP and RAB release message, and/or the GTP and RAB release ACK is sent via the S5 interface.

12. The method of any preceding embodiment, wherein the first network is a trusted non-third generation partnership project (3GPP) Internet Protocol (IP) access network and the second network is a Long Term Evolution (LTE) evolved universal terrestrial radio access network (E-UTRAN).

13. The method according to any of the preceding embodiments, wherein the policy update message, the policy update confirmation message, the GTP and RAB release message, and/or the GTP and RAB release ACK is sent via the S2c interface.

14. A method as in any preceding embodiment, further comprising initiating a handover from a first access network to a second access network.

15. A method as in any preceding embodiment, further comprising receiving a policy update message.

16. A method as in any preceding embodiment, further comprising sending a policy update confirmation message.

17. A method as in any preceding embodiment, further comprising sending a policy information update message.

18. The method of any preceding embodiment, further comprising receiving a policy information update confirmation message.

19. A method as in any preceding embodiment wherein the policy update message contains information relating to a Gateway (GW) in the second access network.

20. A method as in any preceding embodiment wherein the policy information update message comprises information relating to a gateway in the second access network.

21. The method according to any of the preceding embodiments, wherein the policy update message, the policy update confirmation message, the policy information update message and/or the policy information update confirmation message is sent via the S5 interface.

22. A method as in any preceding embodiment, wherein the first network is a third generation partnership project (3GPP) access network and the second network is a trusted non-3 GPP Internet Protocol (IP) access network.

23. A base station configured to perform the method of any preceding embodiment.

24. The base station of embodiment 23, further comprising a receiver.

25. The base station as in any one of embodiments 23-24 further comprising a transmitter.

26. A base station as in any of embodiments 23-25, further comprising a processor in communication with the receiver and the transmitter, the processor configured to send a policy update message, receive a policy update confirmation message, send a General Packet Radio Service (GPRS) tunneling protocol (GTP) and Radio Access Bearer (RAB) release message, receive a GTP and RAB release Acknowledgement (ACK), and/or establish a connection for uplink and downlink transmissions in the second access network.

27. A base station as in any of embodiments 23-26, wherein the policy update message comprises information related to a Gateway (GW) in the second access network.

28. The base station according to any of embodiments 23-27, wherein the processor is further configured to release resources in the first access network.

29. The base station according to any of embodiments 23-28, wherein the policy update message, the policy update confirmation message, the GTP and RAB release message, and/or the GTP and RAB release ACK is sent via an S5 interface.

Claims (16)

1. A method for resource management during handover operations, the method comprising:

initiating a handover from a first access network to a second access network;

sending a policy update message;

receiving a policy update confirmation message;

sending a General Packet Radio Service (GPRS) tunneling protocol (GTP) and a Radio Access Bearer (RAB) release message;

receiving a GTP and RAB release Acknowledgement (ACK); and

establishing a connection for uplink and downlink transmissions in the second access network.

2. The method of claim 1, wherein the policy update message comprises information related to a Gateway (GW) in the second access network.

3. The method of claim 1, further comprising releasing resources in the first access network.

4. The method of claim 1, wherein the first network is a third generation partnership project (3GPP) access network and the second network is a trusted non-3 GPP Internet Protocol (IP) access network.

5. The method of claim 4, wherein the policy update message, the policy update confirmation message, the GTP and RAB release message, and the GTP and RAB release ACK are sent via an S5 interface.

6. The method of claim 1, wherein the first network is a trusted non-third generation partnership project (3GPP) Internet Protocol (IP) access network and the second network is a Long Term Evolution (LTE) evolved universal terrestrial radio access network (E-UTRAN).

7. The method of claim 6, wherein the policy update message, the policy update confirmation message, the GTP and RAB release message, and the GTP and RAB release ACK are sent via an S2c interface.

8.A method for resource management during handover operations, the method comprising:

initiating a handover from a first access network to a second access network;

receiving a policy update message;

sending a strategy updating confirmation message;

sending a strategy information updating message; and

and receiving a strategy information updating confirmation message.

9. The method of claim 8, wherein the policy update message includes information related to a Gateway (GW) in the second access network.

10. The method of claim 8, wherein the policy information update message includes information related to a Gateway (GW) in the second access network.

11. The method of claim 8, wherein the policy update message, policy update confirmation message, policy information update message, and policy information update confirmation message are sent via an S5 interface.

12. The method of claim 8, wherein the first network is a third generation partnership project (3GPP) access network and the second network is a trusted non-3 GPP Internet Protocol (IP) access network.

13. A base station, the base station comprising:

a receiver;

a transmitter; and

a processor in communication with the receiver and the transmitter, the processor configured to send a policy update message, receive a policy update confirmation message, send a General Packet Radio Service (GPRS) tunneling protocol (GTP) and Radio Access Bearer (RAB) release message, receive a GTP and RAB release Acknowledgement (ACK), and establish a connection for uplink and downlink transmissions in the second access network.

14. The base station of claim 13, wherein the policy update message includes information related to a Gateway (GW) in the second access network.

15. The base station of claim 13, wherein the processor is further configured to release resources in the first access network.

16. The base station of claim 13, wherein the policy update message, the policy update confirmation message, the GTP and RAB release message, and the GTP and RAB release ACK are sent via an S5 interface.