Method and apparatus for performing handover procedure in wireless communication system

Abstract

A method for performing a handover procedure in a wireless communication system is provided. A first eNodeB (eNB) of a 3rd generation partnership project (3GPP) long term evolution (LTE) system receives information on an access point (AP) of a wireless local area network (WLAN) system, which is located at neighborhood of a second eNB, to which data of the first eNB can be offloaded, from a user equipment (UE) or a second eNB, and decides whether to handover the UE to the second eNB based on the received information on the AP.

Claims

1. A method for performing, by a first evolved Node-B (eNB) of a third generation partnership project (3GPP) long term evolution (LTE) system, a handover procedure in a wireless communication system, the method comprising: receiving, from a user equipment (UE), a measurement report including information on an access point (AP) of a wireless local area network (WLAN) system when the first eNB connected with the UE does not have an AP to which data of the first eNB can be offloaded, wherein the information on the AP informs the first eNB that at least one AP to which data can be offloaded is located in a coverage of a second eNB, wherein the information on the AP includes a service set identifier (SSID) of the AP which is located in the coverage of the second eNB, and wherein the information on the AP is acquired by the UE based on system information including the SSID of the AP, which is transmitted from the second eNB to the UE; upon receiving the measurement report from the UE, determining whether or not the AP located in the coverage of the second eNB supports a certain resource required for the UE; when the AP located in the coverage of the second eNB supports the certain resource, determining to handover the UE to the second eNB; and upon the determining to handover the UE to the second eNB, transmitting a handover request message to the second eNB.

2. The method of claim 1, further comprising: receiving, from the second eNB, the information on the AP of the WLAN system via a load information message.

3. The method of claim 1, further comprising: receiving, from the second eNB, the information on the AP of the WLAN system via a resource status response message or a resource status update message.

4. The method of claim 1, wherein the information on the AP includes load information of the WLAN system.

5. The method of claim 1, wherein the handover request message includes an indicator indicating that the handover request message is for data offloading to the WLAN system.

6. The method of claim 1, further comprising: receiving a handover request acknowledge message from the second eNB as a response to the handover request message.

7. The method of claim 1, further comprising: transmitting a radio resource control (RRC) connection reconfiguration message including mobility information to the UE.

8. The method of claim 7, wherein the mobility information includes an indicator indicating that the handover is for data offloading to the WLAN system.

9. The method of claim 7, wherein the mobility information includes a service set identifier (SSID) of the AP.

10. A first evolved Node-B (eNB) of a third generation partnership project (3GPP) long term evolution (LTE) system in a wireless communication system, the first eNB comprising: a transceiver configured to transmit or receive a radio signal; and a processor coupled to the transceiver, that: controls the transceiver to receive, from a user equipment (UE), a measurement report including information on an access point (AP) of a wireless local area network (WLAN) system when the first eNB connected with the UE does not have an AP to which data of the first eNB can be offloaded, wherein the information on the AP informs the first eNB that at least one AP to which data can be offloaded is located in a coverage of a second eNB, wherein the information on the AP includes a service set identifier (SSID) of the AP which is located in the coverage of the second eNB, and wherein the information on the AP is acquired by the UE based on system information including the SSID of the AP, which is transmitted from the second eNB to the UE; upon the transceiver receiving the measurement report from the UE, determines whether or not the AP located in the coverage of the second eNB supports a certain resource required for the UE; when the AP located in the coverage of the second eNB supports the certain resource, makes a decision to handover the UE to the second eNB; and upon the processor making the decision to handover the UE to the second eNB, controls the transceiver to transmit a handover request message to the second eNB.

Description

BRIEF DESCRIPTION OF DRAWINGS

(1) FIG. 1 shows LTE system architecture.

(2) FIG. 2 shows a control plane of a radio interface protocol of an LTE system.

(3) FIG. 3 shows a user plane of a radio interface protocol of an LTE system.

(4) FIG. 4 shows an example of a physical channel structure.

(5) FIGS. 5 and 6 show an intra-MME/S-GW handover procedure.

(6) FIG. 7 shows an example of 3GPP-WLAN interworking architecture.

(7) FIG. 8 shows an example of a method for acknowledging presence of an AP according to an embodiment of the present invention.

(8) FIG. 9 shows an example of a method for acknowledging presence of an AP according to another embodiment of the present invention.

(9) FIG. 10 shows an example of a method for performing a handover procedure according to an embodiment of the present invention.

(10) FIG. 11 shows a wireless communication system to implement an embodiment of the present invention.

MODE FOR THE INVENTION

(11) The technology described below can be used in various wireless communication systems such as code division multiple access (CDMA), frequency division multiple access (FDMA), time division multiple access (TDMA), orthogonal frequency division multiple access (OFDMA), single carrier frequency division multiple access (SC-FDMA), etc. The CDMA can be implemented with a radio technology such as universal terrestrial radio access (UTRA) or CDMA-2000. The TDMA can be implemented with a radio technology such as global system for mobile communications (GSM)/general packet ratio service (GPRS)/enhanced data rate for GSM evolution (EDGE). The OFDMA can be implemented with a radio technology such as institute of electrical and electronics engineers (IEEE) 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802-20, evolved UTRA (E-UTRA), etc. IEEE 802.16m is an evolution of IEEE 802.16e, and provides backward compatibility with an IEEE 802.16-based system. The UTRA is a part of a universal mobile telecommunication system (UMTS). 3rd generation partnership project (3GPP) long term evolution (LTE) is a part of an evolved UMTS (E-UMTS) using the E-UTRA. The 3GPP LTE uses the OFDMA in downlink and uses the SC-FDMA in uplink LTE-advance (LTE-A) is an evolution of the 3GPP LTE.

(12) For clarity, the following description will focus on the LTE-A. However, technical features of the present invention are not limited thereto.

(13) Handover (HO) is described. It may be referred to Section 10.1.2.1 of 3GPP TS 36.300 V11.4.0 (2012-12).

(14) The intra E-UTRAN HO of a UE in RRC_CONNECTED state is a UE-assisted network-controlled HO, with HO preparation signaling in E-UTRAN: Part of the HO command comes from the target eNB and is transparently forwarded to the UE by the source eNB; To prepare the HO, the source eNB passes all necessary information to the target eNB (e.g., E-UTRAN radio access bearer (E-RAB) attributes and RRC context): When carrier aggregation (CA) is configured and to enable secondary cell (SCell) selection in the target eNB, the source eNB can provide in decreasing order of radio quality a list of the best cells and optionally measurement result of the cells. Both the source eNB and UE keep some context (e.g., C-RNTI) to enable the return of the UE in case of HO failure; UE accesses the target cell via RACH following a contention-free procedure using a dedicated RACH preamble or following a contention-based procedure if dedicated RACH preambles are not available: the UE uses the dedicated preamble until the handover procedure is finished (successfully or unsuccessfully); If the RACH procedure towards the target cell is not successful within a certain time, the UE initiates radio link failure recovery using the best cell; No robust header compression (ROHC) context is transferred at handover.

(15) First, C-plane handling is described. The preparation and execution phase of the HO procedure is performed without EPC involvement, i.e., preparation messages are directly exchanged between the eNBs. The release of the resources at the source side during the HO completion phase is triggered by the eNB. In case an RN is involved, its donor eNB (DeNB) relays the appropriate S1 messages between the RN and the MME (S1-based handover) and X2 messages between the RN and target eNB (X2-based handover); the DeNB is explicitly aware of a UE attached to the RN due to the S1 proxy and X2 proxy functionality.

(16) FIGS. 5 and 6 show an intra-MME/S-GW handover procedure.

(17) 0. The UE context within the source eNB contains information regarding roaming restrictions which were provided either at connection establishment or at the last TA update.

(18) 1. The source eNB configures the UE measurement procedures according to the area restriction information. Measurements provided by the source eNB may assist the function controlling the UE's connection mobility.

(19) 2. The UE is triggered to send measurement reports by the rules set by i.e., system information, specification, etc.

(20) 3. The source eNB makes decision based on measurement reports and radio resource management (RRM) information to hand off the UE.

(21) 4. The source eNB issues a handover request message to the target eNB passing necessary information to prepare the HO at the target side (UE X2 signalling context reference at source eNB, UE S1 EPC signalling context reference, target cell identifier (ID), K.sub.eNB*, RRC context including the cell radio network temporary identifier (C-RNTI) of the UE in the source eNB, AS-configuration, E-RAB context and physical layer ID of the source cell+short MAC-I for possible radio link failure (RLF) recovery). UE X2/UE S1 signalling references enable the target eNB to address the source eNB and the EPC. The E-RAB context includes necessary radio network layer (RNL) and transport network layer (TNL) addressing information, and quality of service (QoS) profiles of the E-RABs.

(22) 5. Admission Control may be performed by the target eNB dependent on the received E-RAB QoS information to increase the likelihood of a successful HO, if the resources can be granted by target eNB. The target eNB configures the required resources according to the received E-RAB QoS information and reserves a C-RNTI and optionally a RACH preamble. The AS-configuration to be used in the target cell can either be specified independently (i.e., an establishment) or as a delta compared to the AS-configuration used in the source cell (i.e., a reconfiguration).

(23) 6. The target eNB prepares HO with L1/L2 and sends the handover request acknowledge to the source eNB. The handover request acknowledge message includes a transparent container to be sent to the UE as an RRC message to perform the handover. The container includes a new C-RNTI, target eNB security algorithm identifiers for the selected security algorithms, may include a dedicated RACH preamble, and possibly some other parameters, i.e., access parameters, SIBs, etc. The handover request acknowledge message may also include RNL/TNL information for the forwarding tunnels, if necessary.

(24) As soon as the source eNB receives the handover request acknowledge, or as soon as the transmission of the handover command is initiated in the downlink, data forwarding may be initiated.

(25) Steps 7 to 16 in FIGS. 6 and 7 provide means to avoid data loss during HO.

(26) 7. The target eNB generates the RRC message to perform the handover, i.e., RRC-ConnectionReconfiguration message including the mobilityControlInformation, to be sent by the source eNB towards the UE. The source eNB performs the necessary integrity protection and ciphering of the message. The UE receives the RRCConnectionReconfiguration message with necessary parameters (i.e. new C-RNTI, target eNB security algorithm identifiers, and optionally dedicated RACH preamble, target eNB SIBs, etc.) and is commanded by the source eNB to perform the HO. The UE does not need to delay the handover execution for delivering the HARQ/ARQ responses to source eNB.

(27) 8. The source eNB sends the sequence number (SN) status transfer message to the target eNB to convey the uplink PDCP SN receiver status and the downlink PDCP SN transmitter status of E-RABs for which PDCP status preservation applies (i.e., for RLC AM). The uplink PDCP SN receiver status includes at least the PDCP SN of the first missing UL service data unit (SDU) and may include a bit map of the receive status of the out of sequence UL SDUs that the UE needs to retransmit in the target cell, if there are any such SDUs. The downlink PDCP SN transmitter status indicates the next PDCP SN that the target eNB shall assign to new SDUs, not having a PDCP SN yet. The source eNB may omit sending this message if none of the E-RABs of the UE shall be treated with PDCP status preservation.

(28) 9. After receiving the RRCConnectionReconfiguration message including the mobilityControlInformation, UE performs synchronization to target eNB and accesses the target cell via RACH, following a contention-free procedure if a dedicated RACH preamble was indicated in the mobilityControlInformation, or following a contention-based procedure if no dedicated preamble was indicated. UE derives target eNB specific keys and configures the selected security algorithms to be used in the target cell.

(29) 10. The target eNB responds with UL allocation and timing advance.

(30) 11. When the UE has successfully accessed the target cell, the UE sends the RRC-ConnectionReconfigurationComplete message (C-RNTI) to confirm the handover, along with an uplink buffer status report, whenever possible, to the target eNB to indicate that the handover procedure is completed for the UE. The target eNB verifies the C-RNTI sent in the RRCConnectionReconfigurationComplete message. The target eNB can now begin sending data to the UE.

(31) 12. The target eNB sends a path switch request message to MME to inform that the UE has changed cell.

(32) 13. The MME sends a modify bearer request message to the serving gateway.

(33) 14. The serving gateway switches the downlink data path to the target side. The Serving gateway sends one or more end marker packets on the old path to the source eNB and then can release any U-plane/TNL resources towards the source eNB.

(34) 15. The serving gateway sends a modify bearer response message to MME.

(35) 16. The MME confirms the path switch request message with the path switch request acknowledge message.

(36) 17. By sending the UE context release message, the target eNB informs success of HO to source eNB and triggers the release of resources by the source eNB. The target eNB sends this message after the path switch request acknowledge message is received from the MME.

(37) 18. Upon reception of the UE context release message, the source eNB can release radio and C-plane related resources associated to the UE context. Any ongoing data forwarding may continue.

(38) 3GPP-wireless local area network (WLAN) interworking and integration is currently supported by the 3GPP system at the core network (CN) level, including both seamless and non-seamless mobility to the WLAN system. Currently, it has been agreed to study potential radio access network (RAN) level enhancements for 3GPP-WLAN interworking in 3GPP LTE rel-12. The followings are issues which should be taken into account for 3GPP-WLAN interworking. Operator deployed WLAN networks are often under-utilized; User experience is suboptimal when UE connects to an overloaded WLAN network; Unnecessary WLAN scanning may drain UE battery resources.

(39) Discussion for 3GPP-WLAN interworking may be divided in two phases. In the first phase, identifying the requirements for RAN level interworking and clarifying the scenarios to be considered while taking into account existing standardized mechanisms may be discussed. In the second phase, identifying solutions addressing the requirements identified in the first phase which cannot be solved using existing standardized mechanisms may be discussed.

(40) The following may be assumed for 3GPP-WLAN interworking. There is no need to distinguish between indoor and outdoor deployment scenarios. Solutions developed should not rely on standardized interface between 3GPP and WLAN RAN nodes.

(41) The candidate solutions to be considered should meet the following requirements. Solutions should provide improved load balancing between WLAN and 3GPP radio access networks in order to provide improved system capacity. Solutions should improve performance (3GPP-WLAN interworking should not result in decreased but preferable in better user experience). Solutions should improve the utilization of the WLAN system when it is available and not congested. Solutions should reduce or maintain battery consumption (e.g. due to WLAN scanning/discovery). Solutions should be compatible with all existing CN WLAN related functionality, e.g., seamless and non-seamless offload, trusted and non-trusted access, multiple access connectivity (MAPCON) and IP flow mobility (IFOM). Solutions should be backward compatible with existing 3GPP and WLAN specifications, i.e., work with legacy UEs even though legacy UEs may not benefit from the improvements provided by these solutions. Solutions should rely on existing WLAN functionality and should avoid changes to IEEE and Wi-Fi Alliance (WFA) specifications.

(42) For data offloading in 3GPP-WLAN interworking, it is important to discover the

(43) WLAN system to which the data can be offloaded. For this, policies for network selection have been defined in WLAN_NS. In addition, scenarios for 3GPP-WLAN interworking have been defined in 3GPP RAN2 WG, and for scenarios for 3GPP-WLAN interworking, a stand-alone deployment scenario and a co-located deployment scenario have been discussed.

(44) For offloading data to the WLAN system, a user equipment (UE), which is connected to a NodeB (NB) or eNodeB (eNB) of the 3GPP system, should discover an access point (AP) of the WLAN system to which data can be offloaded. Specifically, in the co-located deployment scenario, data may be offloaded through the AP which is co-located to the UE connected to the eNB.

(45) FIG. 7 shows an example of 3GPP-WLAN interworking architecture. Referring to FIG. 7, a UE has a connection with a packet data network (PDN) gateway (PGW) through the eNB in the 3GPP system, and has a connection with the PGW through the AP in the WLAN system. That is, the UE is connected to the eNB, the eNB may interwork with the AP.

(46) However, a handover procedure considering 3GPP-WLAN interworking has not yet discussed. Accordingly, a method for performing a handover procedure considering offloading to the WLAN system may be required.

(47) Hereinafter, when 3GPP-WLAN interworking is supported, a method for performing a handover procedure for a UE to an eNB which can interwork with a WLAN system is described according to embodiments of the present invention. According to embodiments of the present invention, firstly, a first eNB which serves a UE currently may acknowledge that an AP to which data can be offloaded exists in the neighborhood. The first eNB may acknowledge the presence of the AP in the neighborhood through various methods, which are described later. Then the first eNB may handover the UE to a second eNB which can interwork with the AP for data offloading to the WLAN system. Therefore, load of the 3GPP system can be reduced, and resource utilization of the WLAN system can be improved.

(48) A method for acknowledging, by an eNB, that an AP to which data can be offloaded exists in the neighborhood is described. The eNB may acknowledge the presence of the AP to which data can be offloaded in the neighborhood, and accordingly, may acknowledge the presence of another eNB connected to the AP to which data can be offloaded.

(49) FIG. 8 shows an example of a method for acknowledging presence of an AP according to an embodiment of the present invention.

(50) A first method is that a UE notifies a first eNB of presence of an AP which is available in the neighborhood of the UE by transmitting a measurement report to the first eNB. The UE may be connected to the first eNB, but first eNB may not have a connection with an AP to which data of the first eNB can be offloaded. The UE may scan WLAN signals from an AP in the neighborhood of the UE during channel measurement, may also receive system information from a second eNB. The system information received from the second eNB may include an indicator indicating that the second eNB has a connection with the AP to which data can be offloaded. The system information may further include service set identifier (SSID) of the AP. Upon scanning the AP in the neighborhood and receiving the system information from the second eNB, the UE transmits the measurement report to the first eNB in order to notify that the second eNB which has the connection with the AP to which data can be offloaded exists in the neighborhood. Upon receiving the measurement from the UE, the first eNB may transmit a handover request to the second eNB.

(51) FIG. 9 shows an example of a method for acknowledging presence of an AP according to another embodiment of the present invention.

(52) A second method is that a second eNB directly notifies a first eNB of presence of an AP to which data can be offloaded in the neighborhood of the second eNB. To notify the first eNB, the existing message in 3GPP LTE may be used. For example, a load information message in 3GPP LTE may be used. It may be referred to Section 9.1.2.1 of 3GPP TS 36.423 V11.2.0 (2012-09). The load information message may be sent by an eNB to neighboring eNBs to transfer load and interference co-ordination information. Table 1 shows an example of the load information message.

(53) TABLE-US-00001 TABLE 1 IE type and Semantics Assigned IE/Group Name Presence Range reference description Criticality Criticality Message Type M YES ignore Cell Information M YES ignore >Cell Information 1 . . . <maxCellineNB> EACH ignore Item >>Cell ID M ECGI Id of the source cell >>UL Interference O Overload Indication >>UL High Interference 0 . . . <maxCellineNB> Information >>>Target Cell ID M ECGI Id of the cell for which the HII is meant >>>UL High Interference M Indication >>Relative O Narrowband Tx Power (RNTP) >>ABS Information O 9.2.54 YES ignore >>Invoke Indication O 9.2.55 YES ignore

(54) To notify the first eNB of presence of an AP to which data can be offloaded in the neighborhood of the second eNB, the load information may further include a WLAN indication. Table 2 shows an example of the load information message which further includes the WLAN indication according to an embodiment of the present invention.

(55) TABLE-US-00002 TABLE 2 IE type and Semantics Assigned IE/Group Name Presence Range reference description Criticality Criticality Message Type M YES ignore Cell Information M YES ignore >Cell Information 1 . . . <maxCellineNB> EACH ignore Item >>Cell ID M ECGI Id of the source cell >>UL Interference O Overload Indication >>UL High Interference 0 . . . <maxCellineNB> Information >>>Target Cell ID M ECGI Id of the cell for which the HII is meant >>>UL High Interference M Indication >>Relative O Narrowband Tx Power (RNTP) >>ABS Information O 9.2.54 YES ignore >>Invoke Indication O 9.2.55 YES ignore >>WLAN Information O 9.2.XXX Can include WLAN AP's SSID, Load information, etc

(56) Referring to Table 2, the load information message includes the WLAN information IE, which indicates information on an AP to which data can be offloaded in the neighborhood of the second eNB. The WLAN information IE may include an SSID of an AP, load information of the WLAN system, etc.

(57) Alternatively, a resource status response message in 3GPP LTE may be used. It may be referred to Section 9.1.2.12 of 3GPP TS 36.423 V11.2.0 (2012-09). The resource status response message may be sent by a second eNB to indicate that the requested measurement, for all or for a subset of the measurement objects included in the measurement is successfully initiated. Table 3 shows an example of the resource status response message.

(58) TABLE-US-00003 TABLE 3 IE type and Assigned IE/Group Name Presence Range reference Semantic description Criticality Criticality Message Type M 9.2.13 YES reject eNB1 Measurement M INTEGER Allocated by eNB.sub.1 YES reject ID (1 . . . 4095, . . . ) eNB2 Measurement M INTEGER Allocated by eNB.sub.2 YES reject ID (1 . . . 4095, . . . ) Criticality Diagnostics O 9.2.7 YES ignore Measurement 0 . . . 1 List of all cells in YES ignore Initiation Result which measurement objects were requested, included when indicating partial success. >Measurement 1 . . . <maxCellineNB> EACH ignore Initiation Result Item >>Cell ID M ECGI 9.2.14 >>Measurement 0 . . . 1 It indicates that Failure Cause eNB.sub.2 could not List initiate the measurement for at least one of the requested measurement objects in the cell. >>>Measurement 1 . . . <maxFailedMeasObjects> EACH ignore Failure Cause Item >>>>Measurement M BITSTRING Each position in Failed Report (SIZE(32)) the bitmap Characteristics indicates measurement object that failed to be initiated in the eNB.sub.2. First Bit = PRB Periodic, Second Bit = TNL load Ind Periodic, Third Bit = HW Load Ind Periodic, Fourth Bit = Composite Available Capacity Periodic, Fifth Bit = ABS Status Periodic. Other bits shall be ignored by the eNB.sub.1. >>>>Cause M 9.2.6 Failure cause for measurement objects for which the measurement cannot be initiated.

(59) Like the load information message, the resource status response message may also include a WLAN indication in order to notify the first eNB of presence of an AP to which data can be offloaded in the neighborhood of the second eNB. The WLAN information IE may include an SSID of an AP, load information of the WLAN system, etc.

(60) Alternatively, a resource status update message in 3GPP LTE may be used. It may be referred to Section 9.1.2.14 of 3GPP TS 36.423 V11.2.0 (2012-09). The resource status update message may be sent by a second eNB to neighboring first eNB to report the results of the requested measurements. Table 4 shows an example of the resource status update message.

(61) TABLE-US-00004 TABLE 4 IE type and Semantics Assigned IE/Group Name Presence Range reference description Criticality Criticality Message Type M 9.2.13 YES ignore eNB1 Measurement M INTEGER Allocated YES reject ID (1 . . . 4095, . . . ) by eNB.sub.1 eNB2 Measurement M INTEGER Allocated YES reject ID (1 . . . 4095, . . . ) by eNB.sub.2 Cell Measurement 1 YES ignore Result >Cell Measurement 1 . . . <maxCellineNB> EACH ignore Result Item >>Cell ID M ECGI 9.2.14 >>Hardware Load O 9.2.34 Indicator >>S1 TNL Load O 9.2.35 Indicator >>Radio Resource O 9.2.37 Status >>Composite O 9.2.44 YES ignore Available Capacity Group >>ABS Status O 9.2.58 YES ignore

(62) Like the load information message, the resource status update message may also include a WLAN indication in order to notify the first eNB of presence of an AP to which data can be offloaded in the neighborhood of the second eNB. The WLAN information IE may include an SSID of an AP, load information of the WLAN system, etc.

(63) When an eNB acknowledges that an AP to which data can be offloaded exists in the neighborhood, a method for performing a handover procedure for data offloading by using received information is described.

(64) FIG. 10 shows an example of a method for performing a handover procedure according to an embodiment of the present invention.

(65) In step S100, a second eNB transmits a load information message to a first eNB. The load information message may include WLAN information notifying presence of an AP to which data can be offloaded in the neighborhood of the second eNB. The load information may use Table 2 described above. Alternatively, the WLAN information may be transmitted via the resource status response message or resource status update message as described above.

(66) In step S110, a UE transmits a measurement report to the first eNB. The measurement report may include the WLAN information which includes information on an AP in the neighborhood of the UE. Alternatively, the measurement report may not include the WLAN information.

(67) In step S120, upon receiving the measurement report from the UE, the first eNB decides whether to handover the UE to the second eNB. In this case, the first eNB may decide whether to handover the UE to the second eNB by taking into account the WLAN system, i.e., the AP in the neighborhood of the second eNB. The first eNB may decide whether to handover the UE to the second eNB according to whether the AP can support required resources for the UE.

(68) In step S130, upon deciding to handover the UE to the second eNB, the first eNB transmits a handover request message to the second eNB. The handover request message may include an indicator indicating that the handover request is for data offloading from the 3GPP system to the WLAN system. In step S140, upon receiving the handover request message from the first eNB, the second eNB transmits a handover request acknowledge message to the first eNB as a response to the handover request message. The handover request acknowledge message may indicate that the handover request acknowledge is for data offloading from the 3GPP system to the WLAN system.

(69) In step S150, upon receiving the handover request acknowledge message, the first eNB transmits a RRCConnectionReconfiguration message including the mobilityControlInformation. The mobilityControlInformation may include an indicator indicating that the handover is for data offloading from the 3GPP system to the WLAN system. The mobilityControlInformation may further include information on the AP such as SSID of the AP, etc.

(70) In step S160, a handover execution procedure and handover completion procedure are performed as the conventional handover execution procedure and handover completion procedure.

(71) In step S170, the second eNB and the AP perform data offloading. Accordingly, data of the 3GPP system can be offloaded to the WLAN system.

(72) FIG. 11 shows a wireless communication system to implement an embodiment of the present invention.

(73) A first eNB 800 includes a processor 810, a memory 820, and a radio frequency (RF) unit 830. The processor 810 may be configured to implement proposed functions, procedures, and/or methods in this description. Layers of the radio interface protocol may be implemented in the processor 810. The memory 820 is operatively coupled with the processor 810 and stores a variety of information to operate the processor 810. The RF unit 830 is operatively coupled with the processor 810, and transmits and/or receives a radio signal.

(74) A second eNB 900 may include a processor 910, a memory 920 and a RF unit 930. The processor 910 may be configured to implement proposed functions, procedures and/or methods described in this description. Layers of the radio interface protocol may be implemented in the processor 910. The memory 920 is operatively coupled with the processor 910 and stores a variety of information to operate the processor 910. The RF unit 930 is operatively coupled with the processor 910, and transmits and/or receives a radio signal.

(75) The processors 810, 910 may include application-specific integrated circuit (ASIC), other chipset, logic circuit and/or data processing device. The memories 820, 920 may include read-only memory (ROM), random access memory (RAM), flash memory, memory card, storage medium and/or other storage device. The RF units 830, 930 may include baseband circuitry to process radio frequency signals. When the embodiments are implemented in software, the techniques described herein can be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. The modules can be stored in memories 820, 920 and executed by processors 810, 910. The memories 820, 920 can be implemented within the processors 810, 910 or external to the processors 810, 910 in which case those can be communicatively coupled to the processors 810, 910 via various means as is known in the art.

(76) In view of the exemplary systems described herein, methodologies that may be implemented in accordance with the disclosed subject matter have been described with reference to several flow diagrams. While for purposed of simplicity, the methodologies are shown and described as a series of steps or blocks, it is to be understood and appreciated that the claimed subject matter is not limited by the order of the steps or blocks, as some steps may occur in different orders or concurrently with other steps from what is depicted and described herein. Moreover, one skilled in the art would understand that the steps illustrated in the flow diagram are not exclusive and other steps may be included or one or more of the steps in the example flow diagram may be deleted without affecting the scope and spirit of the present disclosure.