WO2010034357A1

WO2010034357A1 - Method and device for data processing, providing or supporting a handoff functionality in a wimax network, and communication system comprising such device

Info

Publication number: WO2010034357A1
Application number: PCT/EP2008/063041
Authority: WO
Inventors: Achim Von Brandt; Shun Liang Zhang; Yi Zhang; Wei Hua Zhou
Original assignee: Nokia Siemens Networks Oy
Priority date: 2008-09-29
Filing date: 2008-09-29
Publication date: 2010-04-01

Abstract

A method and a device are suggested for data processing, providing or supporting a handoff functionality in a WiMAX network, comprising the step: A serving component informs a target component about a mobile station's capability to support handoff. Furthermore, a communication system is suggested comprising said device.

Description

Method and device for data processing, providing or supporting a handoff functionality in a WiMAX network, and communi- cation system comprising such device

The invention relates to a method and to a device for data processing, providing or supporting a handoff functionality in a WiMAX network, and to a communication system comprising such device.

WiMAX, the Worldwide Interoperability for Microwave Access, is a telecommunications technology that provides for wireless transmission of data in a variety of ways, ranging from point-to-point links to full mobile cellular-type access. The technology provides broadband speed without the requirement of cables. The technology is based on the IEEE 802.16 standard (also called WirelessMAN) .

To further reduce a service interruption time, a seamless handoff (HO) concept is proposed in IEEE 802.16 Rev2/D5.

Thus, a capability of seamless HO is negotiated by REG- REQ/RSP messages. Seamless HO can only be performed if sup- ported by a serving base station (BS) , at least one target base station and the mobile station (MS) . Furthermore, during seamless HO, the serving BS includes a pre-allocated basic CID in "MOB_BSHO-REQ/RSP"-messages. A specific action time may be included in such "MOB_BSHO-REQ/RSP"-messages to indi- cate a valid time of pre-allocated CIDs for the at least one target BS. A seamless HO mode flag is transmitted in the "MOB_BSHO-REQ/RSP"-messages. The MS initiates a "RNG- REQ/RSP"-message before the deadline specified by a "Seamless HO Ranging Initiation Deadline" .

Disadvantageously, the existing HO proposal does not provide proper support from the WiMAX backhaul. For example, the components (target BS, serving BS and MS) do not have adequate information to efficiently and quickly support seamless HO in the WiMAX environment. Hence, the MS is not yet able to support any seamless HO, e.g., as it cannot ensure that the ranging request/response messages are provided prior to the HO ranging initiation deadline is reached. Also the MS is not aware of any such deadline.

The problem to be solved is to overcome the disadvantages stated above and in particular to provide an efficient mecha- nism supporting seamless HO in a WiMAX environment, especially with support from a WiMAX backhaul.

This problem is solved according to the features of the independent claims. Further embodiments result from the depending claims.

In order to overcome this problem, a method is suggested for data processing, providing or supporting a handoff functionality in a WiMAX network, comprising the step: - a serving component informs a target component about a mobile station's capability to support handoff.

Hence, said target component becomes aware of the mobile station's handoff capability. Said handoff capability comprises in particular a handoff and/or handover functionality supported by the mobile station.

The mobile station, the target and serving components may in particular be components of a WiMAX network or of a WiMAX en- vironment.

Said handoff (functionality) may comprise in particular a seamless handoff and it may be part of a handover procedure.

In an embodiment, the serving component informs the target component about the mobile station's capability to support handoff via a HO REQ message. In another embodiment, the serving component is a serving base station and/or associated with a serving access service network.

The serving component may also be a or be associated with a serving ASN gateway.

In a further embodiment, the target component comprises at least one target base station and/or is associated with at least one target access service network.

The target component may also be a or be associated with at least one target ASN gateway.

In a next embodiment, the method comprises the step:

- if the target component supports handoff, it provides an according response to the serving component.

This can be done, e.g., via a "HO_RSP" message.

It is also an embodiment that said response comprises at least one of the following information:

- a handoff capability of the target component;

- a CID; - a registration deadline or a registration time restriction;

- a CID valid time.

Pursuant to another embodiment, the method comprises the step:

- conveying an information based on the response provided by the target component from the serving component to the mobile station.

According to an embodiment, the serving component may in particular negotiate with the target component and determine a time limit for the mobile station to initiate a REG-REQ mes- sage to be conveyed to the target component and the serving component conveys the time limit to the mobile station.

For example, the target component may recommend one time limit to the serving component via the HO RSP message, and the serving component may determine (based on the recommended one time limit as well as based on other factors) the final time limit. Then, the serving component conveys the determined final time limit to the target component via an HO ACK message.

According to another embodiment, the serving component informs the target component about the time limit, in particular via an acknowledgment message.

In yet another embodiment, the mobile station notifies the handoff to the target component in particular by providing a "MOB_HO-IND" message towards the serving component.

According to a next embodiment, the target component upon receiving the mobile station's handoff notification selects the target component for the handoff and/or handover.

The problem stated above is also solved by a device compris- ing a and/or being associated with a processor unit and/or a hard-wired circuit and/or a logic device that is arranged such that the method as described herein is executable thereon .

According to an embodiment, the device is a communication device, in particular a or being associated with a mobile station .

According to yet another embodiment, said device is a commu- nication device, in particular a or being associated with an access service network or with a gateway of an access service network, in particular with at least one target base station and/or with a serving base station. The problem stated supra is further solved by a communication system comprising the device as described herein.

Embodiments of the invention are shown and illustrated in the following figure:

Fig.l shows a message chart between a MS, a serving access service network (ASN), e.g. a serving BS, at least one target ASNs (target BSs) and an anchoring ASN used also for authentication purposes.

This approach in particular provides an efficient mechanism supporting seamless HO in a WiMAX environment, especially with support from a WiMAX backhaul.

Thus, in particular a backhaul signaling support is suggested comprising at least one of the following approaches:

(1) A type length value (TLV) is supplied to a HO_REQ message to indicate the seamless HO support capability of the MS and the serving BS to the target BS.

The TLV may be added or an existing TLV on air interface may be used. The serving BS may set this TLV according to a seamless HO capability negotiated during REG- REQ/RSP transactions with the MS by a "Handover Supported Field" TLV.

(2) A TLV is supplied to a HO_RSP message to indicate the seamless HO support capability of the target BS.

The TLV may be added or an existing TLV on air interface may be used. The serving BS may set a "Seamless HO mode flag" TLV of the MOB_BSHO-REQ/RSP messages according to this TLV of the HO RSP message. (3) A TLV is supplied to the HO RSP message to inform the serving BS about a CID pre-allocated by the target BS for the MS.

The TLV may be added or an existing TLV on air interface may be used. The serving BS may set a "Pre-allocated Basic CID" TLV of the MOB_BSHO-REQ/RSP messages according to this TLV of the HO_RSP message.

(4) A TLV is supplied to the HO_RSP message to indicate a valid time associated with the pre-allocated CID determined by the target BS .

The TLV may be added or an existing TLV on air interface may be used. The serving BS may set an "Action time" TLV in the MOB_BSHO-REQ/RSP messages according to this TLV.

(5) A TLV is supplied to the HO_RSP message to inform the MS about a deadline recommended by the target BS to initi- ate a RNG-REQ to the target BS.

The TLV may be added or an existing TLV on air interface may be used.

(6) The serving BS determines a final deadline for the MS to initiate the RNG_REQ message to the target BS according to the recommended deadline set by the target BS (optionally including further parameters) . Then, the determined deadline is conveyed to the MS via a "HO Ranging Initiation Deadline" TLV in the MOB_BSHO-REQ/RSP messages .

(7) A TLV is supplied to a HO_ACK message for the serving BS to inform the target BS about the final deadline deter- mined for the MS to initiate the REG-REQ message to the target BS . (8) The target BS can provide a dedicated opportunity to the MS by uplink (UL) grant or via an information element (e.g., a Fast_Ranging_IE) in an UL-MAP message to allow the MS initiating the RNG-REQ message towards the target BS before the deadline is reached.

Fig.l shows a message chart between a MS, a serving access service network (ASN), e.g. a serving BS, at least one target ASN (target BSs) and an anchoring ASN used also for authenti- cation purposes. Fig.l in particular visualizes an enhancement to backhaul signaling during a HO preparation phase.

Hereinafter, the steps 1 to 13 shown in Fig.l are explained.

STEP Ia

The MS initiates entering a network by sending a REG-REQ message. The MS may set bit 5 of a "Handover Supported Field" TLV in the REG-REQ message to indicate its capability for seamless HO support.

STEP Ib

The (serving) BS in the serving ASN provides a REQ-REG with a REQ-RSP message indicating its seamless HO support capability via the "Handover Supported Field" TLV.

Seamless HO capability is negotiated during the REG-REQ/RSP transaction, and the serving BS may store negotiation results for later use.

STEP 2

The MS initiates the HO process by sending a MOB_MSHO-REQ message to the BS of the serving ASN. STEP 3

The BS in the serving ASN sends an R4 HO_REQ message to one or more target ASNs thereby controlling potential target BS' s selected for handover.

The HO_REQ message comprises a TLV, e.g., "Seamless HO capability", indicating whether seamless HO is supported. This TLV is set according to the seamless HO support status deter- mined during the REG-REQ/RSP transaction.

STEPs 4-5

STEP 4 and STEP 5 correspond to the known specification as provided by the Network Working Group (NWG) .

STEP 6

Upon receiving the HO_REQ message (STEP 3), the target BS knows the seamless HO support capability of the MS and of the serving BS by checking the additional "Seamless HO capability" TLV. If seamless HO is not supported by either the MS and/or the serving BS, known processing may apply, e.g., as set forth in existing specifications (see NWG, stage 3, Re- lease 1.2.3) .

If seamless HO is supported by the MS and by the serving BS and not supported by the target BS, the target BS may indicate its "seamless HO capability" via an additional "Seamless HO capability" TLV in the HO_RSP.

If seamless HO is supported by all (i.e., the MS, the serving BS and the target BS) , the target BS may indicate its seamless HO support capability via the "Seamless HO capability" TLV in the HO_RSP. Also, the target BS may allocate a basic CID and convey this pre-allocated CID to the MS (via the serving ASN) by setting an additional TLV "Basic CID" in the HO RSP message. The target BS may further indicate a valid time associated with the pre-allocated CID by (adding and) setting a TLV "Basic CID valid time" in the HO_RSP message. In addition, the target BS may indicate a recommended deadline for the MS to initiate REG-REQ by setting a "REG dead- line" TLV in the HO_RSP. Finally, the target BS sends the HO_RSP message as the response to HO_REQ message.

STEP 7

The serving BS sends the MOB_BSHO_RSP message to the MS as a response to the MOB_BSHO_REQ message provided by the MS in STEP 2.

The serving BS may set a "Seamless HO mode flag" TLV accord- ing to the "Seamless HO capability" TLV provided by the

HO_RSP from the target BS (STEP 6) and the serving BS may further set a "Pre-allocated Basic CID" TLV according to the "Basic CID" TLV as received in the HO_RSP message. Also, the serving BS may set a specific "action time" according to the value "Basic CID valid time" TLV provided by the HO_RSP message .

The serving BS determines a final deadline for the MS to initiate the REG-REQ towards the target BS according to the rec- ommended deadline indicated by the "REG deadline" TLV in the HO RSP message, and it may set a "HO Ranging Initiation Deadline" TLV in the MOB_BSHO-RSP message according to the final deadline determined.

STEP 8

The serving BS of this serving ASN acknowledges the HO_RSP with a HO_ACK message conveying a "REG deadline" TLV with this HO ACK message comprising the final deadline determined in STEP 7 in order to inform the target BS about the deadline for seamless HO. Upon receiving the HO ACK message, the target ASN may calculate a start of the deadline for the MS to initiate RNG- REQ/RSP transaction according to a "Time Stamp" TLV provided in said HO_ACK message by the serving BS.

STEP 9

The MS sends a MOB_HO-IND message to the serving ASN to notify a handover to one of the target BSs.

STEP 10

Upon receiving of the MOB HO-IND message, the serving ASN sends an R4 HO_CNF message to the selected Target ASN.

STEPs 11-13

The target BS of the target ASN may provide a dedicated opportunity for the MS (e.g., via a Fast Ranging IE in a UL-MAP or a UL Grant) to initiate a RNG-REQ/RSP transaction before the "Seamless HO Ranging Initiation Deadline" is reached. These steps are processed according to IEEE 802.16 specification .

Hence, advantageously, the approach provided supports seamless handover in a WiMAX environment in particular comprising the steps :

(1) Informing the target ASN (e.g., an ASN gateway) about the MS ' s capability to support seamless HO.

The serving BS (or the ASN gateway) informs the target ASN gateway or the target base station about the MS ' s capability to support seamless HO. The serving BS or the ASN gateway obtain the information regarding the support of seamless HO during REG-REQ/RSP in particular during an initial attachment of the MS. (2) The HO REQ message may be used to forward this information of "Seamless HO capability" from the serving ASN

(gateway) to the target ASN (gateway) (or from the serving BS to the target BS) .

(3) If the target ASN (the target BS) supports seamless HO, it responds accordingly, supplying further information such as, e.g., the CID, the basic CID valid time, etc.

(4) If the target BS supports seamless HO, it may indicate such capability via said HO_RSP message to the serving BS, which may further inform the MS via the air interface. The serving BS may further provide information gathered by the HO_RSP message received from the target BS towards the MS, e.g., the pre-allocated CID, the basic CID value time, etc.

(5) The serving ASN (gateway) may control the seamless HO by triggering the HO to the UE and to the target ASN side and by coordinating the time stamps.

(6) The serving BS may convey the deadline for the MS to initiate REG-REQ to the target BS as required by seamless HO.

Preferably, the target BS may become aware of the final deadline determined, the start of the deadline can be derived from the time stamp.

(7) Regarding the negotiation process between the serving BS and the target BS to determine the deadline, the serving BS may coordinate the process and inform the MS and the target BS about the final deadline determined.

It is noted that in non-seamless HO, such seamless HO related information transfer may not be required. Furthermore, in non-seamless HO, there is no need for a negotiation process about such deadline. It is also noted that MS may refer to any kind of user terminal or device, in particular comprising an air interface. Hence, MS may be a user equipment (UE) , a mobile terminal, a mobile phone, a personal digital assistant, a computer (laptop, personal computer) or any device with a mobile interface .

Thus, advantageously, this approach provided enables seamless HO over an air interface with support from a WiMAX backhaul. The target BS quickly becomes aware of the MS ' s seamless HO capability, the serving BS becomes aware of the CID allocated by the target BS and in particular the MS is becomes aware of the valid time for such pre-allocated CID.

List of Abbreviations :

ASN Access Service Network

BS Base Station CID Connection Identifier

CNF Confirmation

HO Handoff

MOB mobility

MS Mobile Station NWG Network Working Group

REG Register or Registration

REQ Request

RNG ranging

RSP Response TLV Type Length Value

UE User Equipment

UL uplink

WiMAX Worldwide Interoperability for Microwave Access

Claims

Claims :

1. A method data processing, providing or supporting a handoff functionality in a WiMAX network, comprising the step:

- a serving component informs a target component about a mobile station's capability to support handoff.

2. The method according to claim 1, wherein the serving component informs the target component about the mobile station's capability to support handoff via a HO_REQ message .

3. The method according to any of the preceding claims, wherein the serving component is a serving base station and/or associated with a serving access service network.

4. The method according to any of the preceding claims, wherein the target component comprises at least one tar- get base station and/or is associated with at least one target access service network.

5. The method according to any of the preceding claims, comprising the step: - if the target component supports handoff, it provides an according response to the serving component.

6. The method according to claim 5, wherein said response comprises at least one of the following information: - a handoff capability of the target component;

- a CID;

- a registration deadline or a registration time restriction;

- a CID valid time.

7. The method according to any of claims 5 or 6, comprising the step: - conveying an information based on the response provided by the target component from the serving component to the mobile station.

8. The method according to any of claims 5 to 7, wherein

- the serving component determines a time limit for the mobile station to initiate a REG-REQ message to be conveyed to the target component;

- the serving component conveys the time limit to the mobile station.

9. The method according to claim 8, wherein the serving component informs the target component about the time limit, in particular via an acknowledgment message.

10. The method according to any of the preceding claims, wherein the mobile station notifies the handoff to the target component in particular by providing a "MOB_HO- IND" message towards the serving component.

11. The method according to claim 10, wherein the target component upon receiving the mobile station's handoff notification selects the target component for the hand- off and/or handover.

12. A device comprising a and/or being associated with a processor unit and/or a hard-wired circuit and/or a logic device that is arranged such that the method according to any of the preceding claims is executable thereon.

13. The device according to claim 12, wherein said device is a communication device, in particular a or being associated with a mobile station.

14. The device according to claim 12, wherein said device is a communication device, in particular a or being associated with an access service network or with a gateway of an access service network, in particular with at least one target base station and/or with a serving base station .

15. Communication system comprising the device according to any of claims 12 to 14.