This application is related to wireless communications.
Current efforts for the Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) program is to develop new technology and new architectures for new methods and configurations in order to provide improved spectral efficiency, reduced latency and better utilization of radio resources for faster user experiences and richer applications and services with less cost. As part of this evolution, 3GPP is considering the support of handover to non-3GPP Radio Access Technologies (RATs), such as WiMAX and technologies developed by 3GPP2, such as CDMA2000, for example, with a minimum delay.
The packet data protocol (PDP) Context or Internet protocol (IP) addresses and their associated evolved packet system (EPS) bearer parameters, (e.g., uplink/downlink (UL/DL) traffic flow template (TFT), radio bearer mappings, and the like), may need to be configured in the WTRU and the target evolved Node B (eNB) to allow for fast handover upon transition to the target. The IP address along with the bearer parameters and associated UL and DL TFTs represent an EPS bearer context. Accordingly, it would be beneficial to provide a method and apparatus for handling mobility between 3GPP and non-3GPP networks.
A method and apparatus for handling mobility between a non-third generation partnership project (3GPP) radio access technology (RAT) and a 3GPP RAT is disclosed. The method includes utilizing services provided by the non-3GPP RAT. A need to utilize services provided by the 3GPP RAT is determined and a 3GPP non-access stratum (NAS) state is entered. 3GPP messages are tunneled to the 3GPP EPC network over the non-3GPP access RAT and a transition is made from the non-3GPP RAT to the 3GPP RAT. A 3GPP NAS state transition is made and a transition to a second 3GPP NAS state occurs.
A more detailed understanding may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
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 type of 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 type of interfacing device capable of operating in a wireless environment.
Hereinafter, Third Generation Partnership Project (3GPP) may collectively refer to Long Term Evolution (LTE), Wideband Code Divisional Multiple Access (WCDMA), Global System for Mobile telecommunications (GSM) and related technologies, such as high speed packet access (HSPA). For example, references to LTE_Idle, LTE_Active, and tracking areas may be extended to equivalents in other technologies, such as PMM_Idle, PMM_Connected, and routing areas.
Additionally, the phrase ‘tunnel’ as used hereinafter refers to any method that allows 3GPP messages to be sent over a non-3GPP network to the 3GPP stack in the WTRU 410. This may not take the form of an explicit “tunnel” but may be some other mechanism. Similarly, “tunnel establishment” refers to setting up the above mechanism, and it may not be necessary or may be pre-existing.
The methods and apparatus described herein are applicable to handover between 3GPP and non-3GPP radio access technology (RAT).
In addition to the components that may be found in a typical WTRU, the WTRU 410 includes a processor 415, a receiver 416, a transmitter 417, and an antenna 418. The receiver 416 and the transmitter 417 are in communication with the processor 415. The antenna 418 is in communication with both the receiver 416 and the transmitter 417 to facilitate the transmission and reception of wireless data. The processor 415 of the WTRU 410 is configured to handle mobility between non-3GPP to 3GPP networks.
In addition to the components that may be found in a typical eNB, the eNB 420 includes a processor 425, a receiver 426, a transmitter 427, and an antenna 428. The receiver 426 and the transmitter 427 are in communication with the processor 425. The antenna 428 is in communication with both the receiver 426 and the transmitter 427 to facilitate the transmission and reception of wireless data. The processor 425 of the eNB 420 is configured to handle mobility between non-3GPP to 3GPP networks.
WTRU procedures, and associated state machines, such as non-access stratum (NAS) mobility management/session management (MM/SM) and radio resource control (RRC), for example, may enable the 3GPP stack in the WTRU to perform signaling, such as NAS/RRC, for example, over a non-3GPP tunnel, despite not having performed procedures such as obtaining a RRC connection or performing formal public land mobile network (PLMN)/Cell-selection.
In the 3GPP NAS Non-3GPP_DETACHED state 615, certain WTRU behavior may be defined. For example, the RRC layer may be in any defined RRC state. Specifically the RRC layer may be in RRC_NULL_NON-3GPP or Idle_Non-3GPP. An allocated WTRU ID is the international mobile subscriber identity (IMSI) and the WTRU's position may not be known by the 3GPP network. There is no RRC context in the 3GPP network nor is there any DL or UL activity over any 3GPP access. In this state the WTRU 410 is not registered with the 3GPP network and uses its non-3GPP access to communicate with the non-3GPP network using procedures specific to the type of non-3GPP access. WTRU Mobility may be restricted to at least one of public land mobile network (PLMN) selection, cell selection, modified cell or PLMN selection, or no WTRU based mobility at all.
In the LTE_DETACHED state 620, there is no signaling connection with the network and the RRC layer is not monitoring paging channels, nor is it camped on a cell. In addition, there may not be an RRC context in the network or any DL or UL activity over the LTE access. The WTRU ID is the IMSI. WTRU Mobility is restricted to PLMN and/or cell selection. There is no WTRU context in the EPC network. The NAS EMM (EPS Mobility Management) layer is in EMM-DEREGISTERED or EMM-NULL or EMM-REGISTERED-INITIATED state) and there is no signaling connection established either (i.e. WTRU is in EMM-IDLE mode).
In the 3GPP NAS Non-3GPP_IDLE state 630, the NAS layer, (e.g. the EMM layer), in the WTRU 410 is registered with the 3GPP network, (e.g., using a non-3GPP L2 access tunnel or upon handover from 3GPP to non-3GPP without detaching from the network), but utilizes non-3GPP layer 2 access. The 3GPP LTE RRC layer may not be camped on a 3GPP LTE cell and may not be searching for other 3GPP cells. In addition, the 3GPP LTE RRC layer may be in an RRC_NULL_NON-3GPP state, an Idle_Non-3GPP state, or in some other RRC state, (e.g. NULL). The WTRU 410 context in the EPC network may include information to enable fast transition to the LTE_ACTIVE state 650. For example, the context information may include security key information. Allocated WTRU IDs may include the IMSI and a Globally Unique Temporary Identity (GUTI). The WTRU 410 may have been allocated at least one unique tracking area (TA) ID and one or more IP addresses. The WTRU's position may be known by the network at the TA level. WTRU Mobility may include handover or cell reselection or modified cell reselection between non-3GPP and 3GPP technology and DL/UL activity may include the WTRU 410 being configured with a discontinuous reception (DRX) period. Alternatively, there may be no WTRU mobility in this state as defined by 3GPP procedures. The WTRU 410 may choose not to perform cell selection and/or re-selection and/or PLMN selection, or may perform modified versions of these procedures, (e.g. with low frequency).
In the LTE_IDLE state 640, the RRC layer is in RRC_IDLE. In this state, the WTRU 410 has registered with the network but there is no signaling connection established with the network. The NAS EMM layer may be in any state corresponding to the existence of an established context, (e.g., EMM-REGISTERED state), but as there may be no signaling connection, the WTRU 410 is in EMM-IDLE mode. Context in the network includes information to enable fast transition to the LTE_ACTIVE state 650. For example, the context information may include NAS security key information. Allocated WTRU IDs may include the IMSI, a GUTI, at least one unique TA ID, or one or more IP addresses, (i.e., the WTRU 410 may be in EMM-REGISTERED state). The WTRU's position may be known by the network at the TA level. WTRU Mobility may include cell reselection between non-3GPP access and LTE and DL/UL activity may include the WTRU 410 being configured with a discontinuous reception (DRX) period over the non-3GPP access.
In the LTE_ACTIVE state 650, the RRC is in an RRC_CONNECTED state. Context in the network includes all information necessary for communication. The allocated WTRU ID may include the IMSI, a GUTI, at least one unique TA ID, a unique cell radio network temporary identifier (C-RNTI), or one or more IP addresses. The WTRU's position may be known by the network at the cell level. WTRU Mobility includes handover and the WTRU 410 may be configured with a discontinuous transmission (DTX)/discontinuous reception (DRX) period. Thus the LTE_ACTIVE state represents a WTRU context in the network, (e.g., the WTRU 410 NAS EMM is in the EMM-REGISTERED state), and the availability of a signaling connection with the network, (e.g., the WTRU 410 NAS EMM is in EMM-IDLE mode and/or the WTRU 410 RRC is in the RRC-CONNECTED state).
The Non-3GPP_IDLE state 630 and the non-3GPP_DETACHED state 615 may differ from the normal LTE_Idle and LTE_Detached states 640 and 620, respectively, because the properties of the WTRU 410 in these states may be different. The WTRU 410 may not monitor LTE paging channels in the non-3GPP_Idle state 630 whereas it may monitor paging channels in the LTE_Idle state 640.
The states and functionalities described herein may be incorporated as WTRU functions in different ways, (e.g., as sub-states of existing NAS EMM states, as new EMM states, or as new EMM modes). Also different and new functions may be defined for these states that are consistent with merging two states into one. Different names may be also be utilized for the NAS EMM states which incorporate these functionalities.
Continuing to refer to
ST 1 may be triggered by a handover to 3GPP from non-3GPP, (e.g., LTE), (possibly with target cell info), power down or radio link failure of the non-3GPP RAT, or an internal trigger in the WTRU 410. In this case, the WTRU 410 begins in the Non-3GPP_IDLE state 630 and proceeds to the LTE_ACTIVE state 650.
ST 2 may be triggered by a network initiated detach, unavailable 3GPP coverage, failure of an NAS procedure, (e.g., such as tracking area update (TAU), authentication, expiration of timers, and the like), or an internal trigger in the WTRU 410 such as the expiry of a timer. The timer may represent the duration for which the WTRU 410 may maintain its registration status and context with the EPC without the availability of an underlying 3GPP layer 2 access before it transitions to a different EMM state. In this case, the WTRU 410 begins in the Non-3GPP_IDLE state 630 and proceeds to the Non-3GPP_DETACHED state 615. Alternatively upon expiration of the timer, the WTRU 410 may move to an EMM-NULL state or some other sub-state of EMM-DEREGISTERED such as the EMM-DEREGISTERED.NO-CELL-AVAILABLE sub-state.
ST 3 may be triggered by a handover to 3GPP, possibly without target cell info, re-selection to a 3GPP cell from a non-3GPP access, or an internal trigger in the WTRU 410, such as a manual trigger to move to LTE. The command to handover to a 3GPP access network such as LTE may be signaled per a non-3GPP access-specific protocol, (e.g. a CDMA2000 message).
ST 4 may be triggered by a switch to 3GPP mode, (e.g., automatic/user selection), without any target 3GPP cell indication or WTRU internal trigger. In this case, the WTRU 410 begins in the Non-3GPP_IDLE state 630 and proceeds to the LTE_DETACHED state 620.
ST 5 may be triggered by completion of an attach, authentication, or service request over a non-3GPP L2 tunnel, or WTRU internal trigger. In this case, the WTRU 410 begins in the Non-3GPP_DETACHED state 615 and proceeds to the Non-3GPP_IDLE state 630.
ST 6 and ST 7 may be triggered by a WTRU internal trigger, (e.g., manual command to use 3GPP access such as LTE). In case ST 6, the WTRU 410 begins in the Non-3GPP_DETACHED state 615 and proceeds to the LTE_ACTIVE state 650. In case ST 7, the WTRU 410 begins in the Non-3GPP_DETACHED state 615 and proceeds to the LTE_IDLE state 640. In case ST 7 the WTRU 410 may perform pre-registration with the 3GPP network over its non-3GPP layer 2 access before moving to the target LTE cell.
ST 8 may be triggered by a switch to 3GPP mode, (e.g., automatic/user selection), or WTRU internal trigger. In this case, the WTRU 410 begins in the Non-3GPP_DETACHED state 615 and proceeds to the LTE_DETACHED state 620.
ST 9 may be triggered by a switch to non-3GPP mode, such as handover, and possibly without an explicit indication to the network or WTRU internal trigger. The indication to handover may be by using LTE RRC signaling and may include an explicit or implicit indication to detach from the 3GPP network upon completing the handover to the target non-3GPP access. In this case, the WTRU 410 begins in the LTE_ACTIVE state 650 and proceeds to the Non-3GPP_DETACHED state 615. Alternatively the WTRU 410 NAS may move to the state EMM-NULL or the EMM-DEREGISTERED.NO-CELL-AVAILABLE sub-state upon handover to the non-3GPP target cell. The WTRU 410 NAS may receive the indication of handover to the non-3GPP access network from the Access Stratum, (e.g., RRC), and/or from the non-3GPP access protocol stack in the WTRU 410.
ST 10 may be triggered by a switch to non-3GPP mode, (e.g., handover to CDMA2000 network), or a WTRU internal trigger. The indication to handover may be signaled by using LTE RRC signaling and may include an explicit or implicit indication to remain attached to the 3GPP network upon completing the handover to target non-3GPP access. In this case, the WTRU 410 begins in the LTE_ACTIVE state 650 and proceeds to the Non-3GPP_IDLE state 630. Alternatively, the WTRU 410 NAS may move to an EMM-REGISTERED.NO-CELL-AVAILABLE sub-state upon handover to a non-3GPP target cell. The WTRU 410 NAS may receive the indication of handover to the non-3GPP network from the Access Stratum (e.g. RRC) and/or from the non-3GPP access protocol stack in the WTRU 410.
ST 11 may be triggered by a switch to non-3GPP mode, (e.g., re-selection or user initiated), or a WTRU internal trigger. In this case, the WTRU 410 begins in the LTE_IDLE state 640 and proceeds to the Non-3GPP_DETACHED state 610. This case may be applicable if the WTRU 410 re-selected to the non-3GPP network with an attempt to detach from the 3GPP network.
ST 12 may be triggered by a re-selection to a non-3GPP cell or WTRU internal trigger. In this case, the WTRU 410 begins in the LTE_IDLE state 640 and proceeds to the Non-3GPP_IDLE state 630. This case may be applicable if the WTRU 410 re-selected to a non-3GPP technology without completing or attempting a detach procedure with the 3GPP EPC network.
ST 13 may be triggered by a switch to a non-3GPP mode (automatic/user selection) or a WTRU internal trigger. In this case, the WTRU 410 begins in the LTE_DETACHED state 620 and proceeds to the Non-3GPP_DETACHED state 610.
ST 14 may be triggered by a WTRU internal trigger. In this case, the WTRU 410 begins in the LTE_DETACHED state 620 and proceeds to the Non-3GPP_IDLE state 610.
Additionally, the WTRU 410 may move into a NULL, (i.e., Power Off), state, (e.g., EMM-NULL—not shown), from any of the depicted states in
Also, the events described for some state transitions may be used in others. The WTRU 410 internal triggers may be messages, signals, parameters, or primitives passed by any part of the WTRU 410. For example, an application, AT command, access stratum (AS), measurements, timers, commands, and the like may be utilized.
A NAS message sent in non-3GPP_DETACHED state 615 or non-3GPP IDLE state 630 may be sent to a session access point interface (SAPI) other than the one between the NAS and AS during normal procedures in 3GPP mode. As an example, it may be sent by the NAS to an interface between the NAS and the non-3GPP access protocol stack in the WTRU 410.
Other functions may also be performed in the various states described in
Other functions that may be performed by the 3GPP stack in the WTRU 410 while the WTRU 410 is in the non-3GPP_DETACHED state 615 include:
Also, when in the non-3GPP_DETACHED state, the 3GPP stack in the WTRU 410 may be informed of the candidate or target LTE cell, or cells, by the non-3GPP network. This information may contain at least one of target cell ID, downlink center frequency and bandwidth of target cell. Some context may be retained from or to the previous or next state when entering or leaving the non-3GPP_DETACHED state. Additionally, the functions may reside in the NAS and/or AS of the 3GPP stack in the WTRU 410.
In the non-3GPP Idle state, the following conditions or functions may be associated with the 3GPP stack in the WTRU 410:
When entering or leaving the 3GPP Idle state, some context information may be retained from the previous state or sent to the next state. In the cases described above the functionalities may reside in the NAS and/or AS of the 3GPP stack in the WTRU 410. The WTRU 410 may initiate tunnel establishment based on, for example, degrading radio conditions.
In another example, the WTRU 410 could re-select to an LTE cell from a non-3GPP cell. By performing tunnel establishment, pre-authentication, and registration before re-selecting, the initial access procedure in the target LTE may be expedited. Steps may be taken to ensure that the cell re-selected by non-3GPP RAT is given priority when the WTRU 410 transitions to LTE Mode. The prioritization may include that when the WTRU 410 moves to LTE mode from non-3GPP access instead of initiating a full PLMN and cell search, the WTRU 410 may try to camp on the cell re-selected to by the non-3GPP RAT.
A WTRU internal trigger may trigger any of the state transitions. The WTRU trigger may include a state transition within the non-3GPP stack, procedure in the non-3GPP protocol stack, timers, commands or primitives.
In order to accommodate the behavior of the 3GPP stack when the non-3GPP stack in the WTRU 410 is active, the RRC state machine, which currently consists of the states NULL, Idle, and Connected, may be modified. One way of modifying it may be by adding additional states, such as RRC_NULL_non-3GPP and RRC_Idle_non-3GPP. The functionalities of these states are described below and may be incorporated into existing RRC states as sub-states, distributed over the NAS or AS, or be merged into a single state.
In the RRC_NULL_non-3GPP state, the 3GPP stack in the WTRU 410 may scan and measure available LTE cells, and additionally may attempt to ensure that there are no higher order PLMNs available by performing periodic background scans of higher priority PLMNs using LTE technology using gaps in the transmission/reception of the non-3GPP access. The 3GPP stack may be instructed by the non-3GPP stack to detect and measure specific cells identified by at least one of physical cell identification, a broadcast level cell identification, a centre frequency and bandwidth, and report the results to the non-3GPP stack.
The 3GPP stack in the WTRU 410 may report the measured parameters, read the SIBs/MIBs of the target cells, identified by at least one of physical cell identification, a broadcast level cell identification, a centre frequency and bandwidth, and report or store the read parameters. In addition, the 3GPP stack in the WTRU 410 may report the detected tracking areas to the NAS, and may decide the target candidate cell.
In the RRC_Idle_non-3GPP state, the WTRU 410 may have a candidate or target LTE cell to monitor that may be selected by the WTRU 410 or the network. The WTRU 410 may seek better LTE cells that are available, report other measured cells periodically, using, for example, a non-3GPP tunnel, or it may make its own decisions regarding a best cell.
In the RRC_Idle state, the WTRU 410 may monitor paging channels at intervals scheduled by the network. Since the non-3GPP stack in the WTRU 410 has access to a single radio in the RRC_Idle_non-3GPP state, the WTRU 410 may monitor paging channels when the non-3GPP stack in the WTRU 410 does not have radio access. The WTRU 410 may receive a page over the non-3GPP tunnel, while it may not receive any page or monitor paging channel. The WTRU 410 may simulate the monitoring of paging channels to the NAS. In addition, the transitions between the various proposed and existing RRC states may be caused by the same, or similar, causes described above in
The non-3GPP stack in the WTRU 410 may be presented as a 3GPP stack to the NAS or AS. This may be similar to the Generic Access Network (GAN) approach. Unlike GAN however, the non-3GPP RAT may be presented as any 3GPP technology. For example, the non-3GPP RAT may be presented as a “limited access technology” to the NAS or AS, where the NAS or AS may perform a limited set of operations. A logical layer may abstract the limited access technology from the 3GPP NAS or AS.
In step 710, the WTRU 410 attaches/authenticates to a 3GPP network over a non-3GPP tunnel. During this time, the WTRU 410 may choose to not indicate any TAs, (e.g., in an attach/service request). Also, the WTRU 410 may choose to include Cell ID(s)/eNB ID(s) of detected or measured cells as part of its ATTACH REQUEST procedure. It may also be the case that no TAs may be assigned to the WTRU 410 as part of the ATTACH ACCEPT message or service request procedure.
Upon handoff to LTE, the WTRU 410 may perform a TA update (step 720) even if it received a Tracking Area as part of it pre-registration procedures with the EPC network over the non-3GPP access network. During measurement of LTE cells by the WTRU 410 (step 730), the TAs with which the cells are associated may be read and stored by the WTRU 410 and provided to the NAS. The TA associated with the LTE cell may be reported as part of a non-3GPP RAT signaling or measurement report or as part of the messages sent over the non-3GPP tunnel.
The MME may use the measured or candidate LTE handover cell, provided by a non-3GPP network or by the WTRU 410 across a tunnel, and its own geographical knowledge of which cell is in which tracking area to assign TAs to the WTRU 410. It may do so without the WTRU having requested a tracking area update (TAU). Additionally, a mapping between TAs may be maintained along with an equivalent of TAs in non-3GPP networks. By knowing the TA equivalent of the non-3GPP RAT, the network knows the TA that the 3GPP RAT WTRU 410 is in.
The network may allocate, then to the WTRU 410, one or more TAs for use when it is in a non-3GPP network (step 740). This can allow the MME to re-direct any incoming calls to the appropriate non-3GPP network.
The 3GPP and non-3GPP networks may be synchronized so that the WTRU 410 is paged over the 3GPP network at a time when the non-3GPP stack in the WTRU 410 is not using a radio. The 3GPP stack in the WTRU 410 listens to paging cycles during these intervals. To this end, the 3GPP stack in the WTRU 410 may request, based on an internal clock, knowledge of the non-3GPP stack silent periods and knowledge of the timing of the LTE cells. In this way, it can be configured with appropriate DRX periods in 3GPP Idle mode. This allows the WTRU 410 to tune away from the non-3GPP RAT and listen to pages over the LTE cell. The non-3GPP network may resolve the MME ID based on WTRU detection.
The “always-on” design of the LTE PS domain may mean that the WTRU 410 always has a default EPS bearer context assigned to it, even when in Idle mode. When the WTRU 410 is using a non-3GPP RAT, it is possible that the WTRU 410 has an IP address from the non-3GPP stack. Accordingly, it may be beneficial to manage a EPS context in the 3GPP stack.
In step 805, the WTRU 410 transitions from one network to another. For example, the WTRU 410 may transition from a 3GPP to a non-3GPP network (step 810). Alternatively, the WTRU 410 may be in a non-3GPP network and include a non-3GPP tunnel that carries the 3GPP NAS signaling (step 820). Also, the WTRU 410 may transition from a non-3GPP network to a 3GPP network (step 830).
When the WTRU 410 transitions from a 3GPP network to a non-3GPP network, such as in step 810, it may perform a variety of functions. For example, the WTRU 410 may delete any combination of existing EPS contexts (step 811). The WTRU 410 may also re-use any combination of existing EPS contexts in the non-3GPP network (step 812), and/or store any combination of existing EPS contexts for re-use when the WTRU 410 returns to the LTE network (step 813).
When the WTRU 410 is in non-3GPP network and has a non-3GPP tunnel carrying 3GPP NAS signaling, as in step 820, the 3GPP network may assign the WTRU 410 an EPS bearer context for use when handoff to the 3GPP LTE network is performed (step 821). Alternatively, the 3GPP network may not provide any EPS bearer contexts (step 822), or assign the WTRU 410 the same IP address in the EPS bearer context as that being used in the non-3GPP network (step 823).
When the WTRU 410 transitions to a 3GPP network from a non-3GPP network (step 830), the WTRU 410 may use any previously stored 3GPP assigned EPS bearer Context (step 831). Also, the WTRU 410 may re-use the EPS bearer Context equivalent or IP address of the non-3GPP network in the 3GPP network (step 832). The WTRU 410 may use any EPS bearer context assigned by the 3GPP network over the non-3GPP tunnel (step 833), or the WTRU 410 may request the activation of an EPS bearer Context (step 834).
In all of the transitions described above in
Additional functions may be performed when the WTRU 410 transitions to an LTE cell from a non-3GPP cell. For example, the WTRU 410 may perform a tracking area update and obtain a new EPS bearer context in one step. This may be performed in the initial NAS/RRC signaling over the target LTE cell. This round trip signaling may also include information necessary for beginning RRC and U-plane security as well as radio bearer configurations.
The radio bearers may be configured and resources reserved during handover preparation by the target eNB 420 and the configuration set may have an ID that was provided to the WTRU 410 during preparation. During the round trip, the WTRU 410 may provide a radio bearer configuration set ID that would allow the target to retrieve the configuration reserved and indicate it to the WTRU 410.
Alternatively the target eNB 420 could retrieve and signal the radio bearers configured for a particular WTRU 410 using the cell radio network temporary identifier (C-RNTI) that the WTRU 410 is using for access since the C-RNTI is allocated by the target eNB 420 to the WTRU 410 during handover preparation.
Since the WTRU 410 is capable of performing the attach and authentication procedure in LTE before it transitions to the LTE network, when the WTRU 410 sends the first message on the random access channel (RACH), the LTE network may directly identify the WTRU 410 and send its response, thereby sending a temporary C-RNTI. When the WTRU 410 sends the RRC connection request, the WTRU 410 may then embed its tracking area update request and request for activation of the security procedure.
The embedding of an NAS level message within an RRC message may be performed in a conventional manner. A network, in its RRC connection setup, could activate the security procedure and complete the tracking area. The WTRU 410 may also embed the service request with the RRC connection request, but this could be decided based on size restrictions of the message.
Ongoing traffic (911) is shown as occurring between the non-3GPP access protocol stack of the WTRU 410 and the non-3GPP network 411. A measure LTE message (912) is sent from the non-3GPP network 411 to the non-3GPP access protocol stack of the WTRU 410, which sends the details of the measurement command (913) to the 3GPP access protocol stack of the WTRU 410.
The 3GPP access protocol stack then makes measurements (914) and forwards a measurement report (915) to the non-3GPP access protocol stack. A handover decision is then made starting with the measurement report signal (916) being forwarded by the non-3GPP entity to the non-3GPP network 411. The non-3GPP network 411 then sends a forward relocation request message (917) to the target MME 412. The relocation request message (917), or an equivalent message, the non-3GPP network may also provide the MME with information related to services involved in a handover. For example, Quality of Service (QoS) parameters and/or IP address information may be included in message 917. It may also be the case that the relocation request message (917) may be an indication of a handover in order to establish a tunnel and resources.
In step 918, a tunnel establishment occurs between the WTRU 410, the non-3GPP network 411 and the target MME 412. Tunnel establishment may be initiated by the target MME 412, the non-3GPP network 411 or the WTRU 410. For example, the tunnel establishment may be triggered by the non-3GPP network sending a message consistent with non-3GPP protocol to the non-3GPP access protocol stack in the WTRU 410 that commands the WTRU to handover to 3GPP LTE. This may be used as a trigger for tunnel establishment. Once the tunnel is established, additional steps and signals may be performed and sent that involve the WTRU 410, target eNB 420, non-3GPP network 411, target MME 412 and/or the HSS 421, as necessary. These steps may be performed by signaling over the tunnel or over parts of the tunnel. Radio bearer configurations and their mapping to EPS bearers and UL/DL traffic flow template (TFT) allocation may be sent over the non-3GPP network signaling. In addition, RRC signaling and information may be passed in the tunnel. It may be passed as NAS signaling, and may be passed transparently by the NAS layer in the WTRU 410 to the RRC layer.
In one example, the triggering of the tunnel establishment may be initiated by the WTRU 410 by defining an event dedicated to triggering a tunnel establishment. The actual handover command may be sent later using the forward relocation command and reported to the target eNB 420 or target MME 412 by the WTRU 410 through a different handover event.
Once the tunnel is established, an attach/service request message (919) is sent from the 3GPP access protocol stack of the WTRU 410 to the target MME 412. The target MME 412 replies with an identify request message (920), and the 3GPP access protocol stack responds to the request with an identify response message (921). Authentication and key agreement (step 922) then occurs between the 3GPP access protocol stack in the WTRU 410 and the target MME 912 and the target MME 912 and the HSS 421. At this point, the target MME 912 sends a relocation request message (923) to the HSS 421, which responds with a relocation request acknowledgment (ACK) signal (924).
Any of attach/service response, EPS bearer context activation, TA response, NAS/RRC/U-Plane security information, and handover commands are exchanged between the 3GPP access protocol stack and the target MME 412 (step 925) over the non-3GPP tunnel. The target MME 412 sends a forward relocation response message (926) to the non-3GPP network 411. The forward relocation response message may be modified such that it can trigger just a tunnel establishment or a message may be defined that is specific for tunnel establishment. The non-3GPP network 411 then may send a handover command (927) to the non-3GPP access protocol stack in the WTRU 410. Handover then occurs from the non-3GPP access protocol stack to the 3GPP access protocol stack in the WTRU 410 (step 928) and E-UTRAN access procedures occur between the 3GPP entity and the target eNB 420 (step 929).
The 3GPP access protocol stack sends a handover confirmation message (930) to the eNB 420, and the eNB 420 sends a relocation complete message (931) to the target MME 412. The target MME 412 forwards the relocation complete message (932) to the non-3GPP network 411, which subsequently releases resources (step 933).
Accordingly, the following steps may occur by signaling over the tunnel or any part of it:
In particular, the bearer establishment and associated steps, such as IP address allocation and UL/DL TFT filter allocation, could be initiated by the 3GPP stack in the WTRU 410 over the tunnel based on ongoing traffic over the non-3GPP RAT or could be initiated by the target MME 412 over the tunnel based on the QoS parameters it receives from the non-3GPP RAT.
Although features and elements are described above in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided herein may be implemented in a computer program, software, or firmware incorporated in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache 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).
Suitable processors include, by way of example, 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, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of 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 (UE), terminal, base station, radio network controller (RNC), 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 videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (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 wireless local area network (WLAN) or Ultra Wide Band (UWB) module.
This application claims the benefit of U.S. provisional application No. 60/952,472, filed Jul. 27, 2007, which is incorporated by reference as if fully set forth.
Number | Date | Country | |
---|---|---|---|
60952472 | Jul 2007 | US |