Method and apparatus for controlling a handover between utra r6 cells and r7 cells

(54) Title: METHOD AND DEVICE FOR THE CONTROL OF A HANDOVER BETWEEN R6 AND R7 UTRA CELLS (30) Unionist Priority: 02/02/2007 us 60 / 887,896, 03/16/2007 US 60 / 895,338, 03/26 / 2007 US 60 / 908,076, 26/04/2008 US 60 / 914,189 (73) Holder (s): interdigital Technology Corporation (72) Inventor (s): christopher r. cave, diana pani, Paul Marinier, STEPHEN E. TERRY (74) Attorney (s): Advocacia Pietro Ariboni S / C (86) International Request: pct us2008001398 of 02/01/2008 (57) Summary: method and device for controlling a HADOVER BETWEEN R6 AND R7 UTRA CELLS. A method and a device for controlling an optimization of a handover process between review cells 6 (R6) for access to universal terrestrial radio (UTRA) and review cells 7 (R7) of UTRA are described. When a wireless transmit / receive unit (WTRU) moves between an R6 cell and an R7 cell, or between R7 cells, a handover from the source Node B to the target Node B is initiated. In cell R7, enhanced media access control (MAC) features are supported including a flexible size of the radio link control protocol (PDU) data unit and high-speed MAC segmentation (MAC- hs) and the multiplexing of different priority queues. After handover, a MAC layer and / or an RLC layer are reconfigured or readjusted based on the functionality supported by the target Node B.

(87) International Publication: wo 2008 / 097486of 14/08/2008 • 20

VJ

1/22

<img file="BRPI0806351A2_D0001.tif" />

P 0806351-6

Method and device for controlling a handover eniic uouicia ru&gt; e nr ui ka.

FIELD OF THE INVENTION

This invention is related to the field of wireless communications.

FUNDAMENTALS

Some of the major goals for the evolution of high speed packet access (HSPA) include higher data transfer rates, increased system capacity and coverage, improved support for package services, waiting reduced, reduced operator costs and return capacity. Meeting these objectives requires an evolution in the radio interface protocol and network architecture. More specifically, the satisfaction of these objectives has required a set of improvements and architectural changes to the layer 2 (L2) functionalities (that is, radio link control (RLC) and access control (MAC)) .

Some of the L2 improvements include flexible sizes for the RLC protocol data units (PDU), segmentation / concatenation and MAC multiplexing (MAC-hs) at high speed. When accessing universal terrestrial radio (UTRA) update 6 (R6), RCL entities in the receive conformation mode (AM) can only use a fixed RCL PDU size. In addition, the MAC-hs sublayer on node B can only support concentrations of MAC-d PDUs. Improvements in L2 from UTRA update 7 (R7) result in significant changes to the RLC / MAC in relation to the characteristics of R6.

Changes to the improved MAC-hs architecture on the UTRA side include the addition of a multiplexing entity (MUX) for the logical channel identifier (LCH-ID). The LUX-ID MUX entity performs the logical multiplexing of channels in a priority queue. The MAC-ehs architecture also includes the priority queue segmentation functionality and the multiplexing of MAC-ehs load units from different priority queues on a MAC-ehs PDU.

Changes in the MAC-ehs architecture on the side of the wireless receiving / transmitting units (WTRU) include the disassembly of the MAC-ehs load units from the MAC-ehs PDU. In addition, and after re-ordering, the MAC-ehs load units are sent to an LCH-ID demultiplexing entity. This LCH-ID demultiplexing entity routes the MACehs load units to the correct reassembly entity based on the logical channel identifier. The MAC-ehs Architecture in the WTRU also includes a reassembly entity which reassembles the MAC-ehs service data units (SDUs) and sends all MAC-ehs SDUs to the highest layers.

Currently, when radio bearers are

2/22 adjusted or reconfigured by means of a signal from a radio source control (RRC), the information element (IE) of the “radio carrier mapping information (RB)” is present. The “RB mapping information” contains information about the RLC instance and the transport channels corresponding to the radio carrier (RB).

New information elements (IE) s can be added to the “IE RB mapping information, which indicates whether the logical channel of the RLC instance supports flexible RLC PDUs, or whether the MAC sublayers support MAC-hs or MAC-ehs . For the purposes of this invention, these LEs will hereinafter be called "RLC configuration of the downlink (DL)" and "DL configuration of the MAC-hs". The configuration of MAC-hs must be the same for all RBs mapped to a shared high-speed downlink channel (HS-DSCH), or an invalid configuration will result.

In HSPA, shared high-speed channels are monitored by a WTRU in a single cell (that is, the cell of the shared high-speed downlink channel in service (HS-DSCH)). Due to mobility, when the WTRU is moving from one cell to another, the WTRU needs to change the service cell by switching to a new HS-DSCH service cell and terminating communication with the old HSDSCH service cell. In a node B relocation procedure, inter-node B handover occurs from an old node B (that is, the source node B) to a new node B (that is, the target node B).

When changing a B node in service, the target B node needs to start transmitting the data through the new configuration. Handover can occur within the B HSPA nodes involved, which support the L2 improvements, or from / to the cells with or without the L2 improvements. In any case, the WTRU must be able to perform the handover, adjust the new settings and minimize data loss.

In a conventional system (that is, in an R6 system), when the handover occurs, a radio source control (RRC) message can carry a MAC layer reset indicator. Specifically, when an interover B or intra-B node handover occurs, the data on the MAC-hs on the source node B is erased and the MAC-hs on the WTRU must be reset. Upon receipt of the reset indicator, the WTRU will perform the following sequence of functions:

1) unload the soft buffer of the hybrid automatic repetition request (HARQ) for all configured processes (HARQ);

2) stop all active reordering release timers (T1) and set all T1 timers to their initial values;

3) start the transmission sequential number (TSN) with a value of 0 for the

3/22 next transmission in each configured HARQ process;

4) start the variables RcvWindow_UpperEdge and next_expected_TSN from their initial values;

5) disassemble all the MAC-hs PDUs in the reordering buffer and send all MAC-d PDUs to the MAC-d entity; and

6) unload the reordering buffer.

From the introduction of new improvements in L2, new procedures need to be defined in order to optimize and minimize data loss during a handover between R7 cells, or between an R7 cell and an R6 cell. Specifically, the procedures that deal with the readjustment of MAC-hs entities need to be modified in order to take into account the new improvements / evolutions of L2.

Furthermore, it cannot be assumed that all B R6 nodes will be updated at the same time for B R7 nodes. Therefore, handover between cells R6 and R7 may occur frequently. Due to the functional changes of RLC and MAC, methods must be defined to carry out the handovers with a minimum loss of quality and data between these cells. Specifically, on the WTRU side, MAC-hs and RLC must make functional changes during handovers.

SYNTHESIS

A method and device for controlling an optimization of a handover process between R6 UTRA (i.e., lower layer) and R7 UTRA (that is, upper layer) cells is described. When a WTRU moves between an R6 cell and an R7 cell, or between R7 cells, a handover from the source Node B to the target Node B is initiated. In cell R7, enhanced MAC functionality including flexible RLC PDU size and MAC-hs segmentation and multiplexing of different priority queues in the WTRU are supported. The changes that occur in WRTU are due to the fact that WRTU is moving between R6 and R7 cells. When the WRTU moves between such cells, the network must reconfigure the WRTU with new configurations. After handover, a MAC layer and / or an RLC layer are reconfigured or readjusted based on the functionality supported by the target Node B. BRIEF DESCRIPTION OF THE DRAWINGS

A better understanding of the invention can be obtained from the description that follows, together with the accompanying drawings, in which:

- Figure 1A is an example block diagram of a WTRU which moves between cells R6 and R7, and is configured to operate with the new sublayers RLC and MAC-hs when a handover message is received during a drawing procedure. the cell;

4/22

Figure 1B is a detailed diagram of a MAC unit in the WTRU of figure 1 A; and Figure 2 is a flow diagram of a WTRU handover procedure implemented in the WTRU of figure 1A.

DETAILED DESCRIPTION

Where referred to hereafter, the wireless reception / transmission unit (WTRU) terminology includes, but is not limited to, user equipment (UE), a mobile station, a fixed or mobile subscription unit, a pager, a cell phone , 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, Node B terminology includes, but is not limited to, a base station, a local controller, an access point (AP) or any other type of interface device capable of operating in a wireless environment.

When referred to hereafter, an R7 cell includes Nodes B and RNCs which have improved L2 characteristics. Throughout this invention, an R7 cell can refer to higher revisions which support the L2 improvements. When referred to hereafter, an R6 cell includes Node B and RNC which do not support the improved L2 characteristics. This may include Nodes B R7 without L2 characteristics and any revisions to the preliminary third generation partnership projects (3GPP). MAC-hs R7 in this invention refers to the improved MAC-hs (i.e., MAC-ehs).

The RLC readjustment terminology also refers to a re-establishment of the RLC.

These terms are used interchangeably.

The following terms are used throughout the description and are briefly defined. A MAC-ehs load unit is a MAC-ehs SDU or a segment of a MAC-ehs SDU contained in a MAC-ehs DPU. A MAC-ehs reordering PDU is a set of MAC-ehs load units in a MAC-ehs PDU which belongs to the same priority queue. An improved cell is a cell that supports L2 improvements. An unimproved cell is a cell that does not support L2 improvements.

The change procedures for the MAC-hs or MAC-ehs readjustment procedures, a MAC-hs or MAC-ehs reset procedure and the RLC re-establishment re-evaluation procedures are described.

A method and device are described here, which deal with the optimization of the handover scenarios, the readjustment procedures of the MAC-hs and RLC entities to support the handovers between R7 cells, and between R6 and R7 cells. It should be understood that references to cells R6 or to Nodes B R6 are directed to cells and Nodes B that do not support the improved characteristics L2,

5/22 such as MAC segmentation and flexible RLC PDU size. The described method and device are applicable for both uplink (UL) and downlink (DL), as well as for other wireless technologies such as long-term evolution (LTE) and other flat architecture systems such as multiple access with division of the broadband code R8 (WCDMA) (R8 wideband code division multiple access).

Figure 1A is an example block diagram of a WTRU 100 which moves between cells R6 and R7, and is configured to operate with the new RLC and MAC-hs sublayers when a handover message is received during a change procedure service cell. As shown in figure 1A, the WTRU 100 includes an RRC unit 105, an RLC unit 10, a MAC unit 115 and a physical layer unit 1 (PHY). The change in the service cell can take place via a radio carrier reconfiguration RRC message, a transport channel reconfiguration RRC message or a physical channel reconfiguration RRC message.

The WTRU 100 operates on a wireless communication system including a target Node B, a source Node B, a control RNC (CRNC) and a source RNC (SRNC) (not shown). The SRNC can include an RLC unit and an RRC unit (not shown).

Handover \ ntra cell R7

In the R7 architecture, MAC-hs includes new features which include the segmentation and multiplexing of MAC-hs for different priority queues in Node Β. The RLC functionality remains on a radio network controller (RNC) and supports flexible PDU sizes. The MAC-hs R7 reader is significantly different from the MAC-hs R6 reader. In LTE and other WCDMA flat architecture systems, the RLC functionality is found in Node B. In UL, the RLC functionality is located in the WTRU.

When a handover occurs, the MAC-hs entity on a source Node B is deleted and a new MAC-hs entity is set on the target Node B. When the new configuration occurs, the maximum size of the RLC PDU can be adjusted for the target Node B. This is done through one or a combination of the following methods: 1) giving a default value for the RLC PDU size; 2) maintain the existing RLC PDU sizes; or 3) adjust a new RLC PDU size based on the conditions of the target Node B channel. This is applicable in the case where Node B signals the maximum PDU size of the RLC to the RLC entity in the RNC. The channel quality indicator (CQI) information that is sent to the target Node B during the handover can provide a good estimate of the channel conditions. In turn, the target Node B can provide a return to the RLC entity at the RNC to adjust an updated size of the RLC PDU before starting transmission via the new

6/22 cell. Any conventional methods can be used to provide feedback information to the target Node B when changing the cell to HS-DSCH service.

When a new MAC-hs is set on the target Node B, the MAChs on the side of the WTRU is preferably synchronized with the target Node B. Therefore, the

WTRU preferably also resets the MAC-entity in the WTRU.

Due to the change of functionality of the MAChs sublayer, the R6 readjustment procedure is modified in order to take into account the fact that after receiving the HARQ, a disassembly function of the MAC-hs PDU is used before reordering. After reordering, a reassembly function is added to the existing disassembly function.

The conventional MAC-hs R6 readjustment procedure is changed by dismantling all MAC-hs PDUs in the reordering buffer, reassembling the segmented packages that can be successively reassembled in the MAC-hs service data units (SDUs) , sending all

Full MAC-hs SDUs for the upper layers, and unloading the partially received MAC-hs SDUs.

More specifically, and due to changes in architecture, it is proposed to update the MAC-ehs readjustment procedure. At a given activation time or at the time of indication, the WTRU must process the MAC-ehs reordering PDUs that are waiting in the reordering buffer. All MAC-ehs reordering PDUs must be disassembled or demultiplexed in the MAC-ehs load units. The MAC-ehs cargo units are then passed to a reassembly unit. After the reassembly unit processes all MAC-ehs load units and reassembles the MAC-ehs load units segmented into MAC-ehs SDUs that can be reassembled, the reassembly entity must ensure that any remaining segment (s) ( s) MAC-hs SDU are deleted from the reassembly entity. Finally, the complete PDUs are sent to the upper layers in the corresponding logical channels or MAC-d / c flows.

For example, the MAC-ehs readjustment procedure can take the following form for the MAC-ehs architecture, if the readjustment of the MAC 115 unit is requested by the upper layers, the WTRU 100 must at the activation time indicated by the upper layers:

a) unload the HARQ soft buffers for all configured HARQ processes;

b) stop all reordering release timers (T1) and adjust all T1 timers to their initial values;

c) start the TSN with the value 0 for the next transmission in each configured HARQ process (and each priority queue);

d) start the variables RcvWindowJJpperEdge and next_expected_TSN with their

7/22 initial values;

e) send all the reordering PDUs, in the reordering queue, to the LCH-ID demultiplexing units and / or demultiplexed MAC-ehs load units and route them to the correct reassembly unit based on the logical channel identifier;

f) reassemble the segmented SUDs of MAC-ehs and send the complete MAC-ehs SDUs (MAC PDUs) to the highest layers;

g) unload any stored reordering PDUs (or SDU segments of MAC-hs) from the reassembly units;

h) unload the reordering queues; and

i) optionally indicate for all RLC entities in recognition mode (AM) mapped from the HS-DSCH to generate a situation report if the MAC-hs readjustment was initiated due to a receipt of the MAC-hs readjustment indicator from the IE through the upper layers.

There may be a different MAC-ehs architecture in which the reordering functionality is followed by an SDU disassembly function, a reassembly entity and finally an LCH-ID demultiplexing entity. The disassembly function can be part of the reassembly entity, in which case only one reassembly entity will exist in the MAC-ehs architecture. For example, the MAC-ehs readjustment procedure can take the following form for this MAC-ehs architecture.

Figure 1B is a detailed diagram of the MAC 115 unit on the WTRU 100 of figure 1A. As shown in Figure 1B, the MAC 115 unit includes a plurality of demultiplexing units LCH-130A and 130B, disassembly units 135A and 135B, reordering rows 140A and 140B, a distribution unit 145 of the reordering rows, a unit disassembly 150 and an HARQ 155 unit. Reordering queues 140A and 140B are used to reorder the received MAC PDUs, in such a way that such reassembly can be performed and data can be sent in order to the highest layers. HARQ 155 units include at least one HARQ soft buffer (not shown).

With reference to figure 1B, if the readjustment of the MAC-ehs entity is requested by the upper layers, the WTRU 100 must, at the moment of activation indicated by the upper layers:

a) unload the HARQ soft buffer in the HARQ 155 unit for all configured HARQ processes;

b) stop all active reordering release timers (T1) and set all T1 timers to their initial values;

c) start the TSN with the value 0 for the next transmission in each HARQ process

8/22 configured (and each priority queue);

d) start the variables RcvWindowJJpperEdge and next_expected_TSN with their initial values;

e) all reordering PDUs in reordering queues 140A and 140B are sent to disassembly unit 150, and / or;

f) disassembly unit 150 disassembles all reordering PDUs in MAC-hs SDUs or segments of MAC-hs SDUs and sends them to the 135A and 135B reassembly units or;

g) if there is only one reassembly unit 135, the reordering queue data is sent to the reassembly unit 135. The reassembly units 135A 135B reassemble the MAC-ehs SDU segments and send the MAC-ehs SUDs complete for LCH-ID 130A and 130B demultiplexing units, each of which sends the complete SDUs to the correct logical channel or MAC-d / c stream;

h) unload any stored reordering PDUs (or SDU segments of the MAC-hs) from the reassembly units 135A and 135B; and

i) unload reordering queues 140A and 140B.

Optionally, and in the case of an intra handover to Node B, (that is, a handover between sectors of the same Node B), the MAC-hs readjustment procedure described above may not have to be performed). In this case, the handover is performed as described for a conventional R6 system.

Handovers between R6 and R7 cells

Enhanced L2 cells, (ie, R7 cells), support flexible sizes of the RLC PDU while unimproved cells (i.e., R6 cells) have a fixed size for the RLC PDU. This implies that when a handover to and from R7 cells occurs, the affected RLC entities in the RNC and WTRU must be reconfigured for the old RLC entities. Furthermore, MAC-hs sublayers need to be reconfigured in order to decode the correct header formats and to support new and old formalities.

If it is necessary to re-establish an RLC entity, significant data loss may occur. Thus, it would be desirable to minimize this data loss.

Sequence of events for the handover procedure

Figure 2 is a diagram of a WTRU handover procedure 200, implemented in WTRU 100 of figure 1. In step 205, the RRC unit 105 in WTRU 100 receives an RRC handover command to initiate the handover procedure. In step 210, units 120 of the physical layer (PHY) 1 (LI) are instructed by the RRC unit 105 to initiate new radio links indicated in the

9/22 handover. This sequence of events is similar to the conventional procedure up to the MAC-hs adjustment step.

In step 215, the RRC 105 unit sends a MAC-hs reset and / or MAC-hs reset request to the MAC 115 unit on the WTRU 100, as requested. If MAC-hs reconfiguration is required, then MAC-reconfiguration is performed as explained in detail below. The parameter indicating the readjustment of the MAC-hs of the RRC 105 unit to the primitive MAC can optionally be extended to indicate the reconfiguration of the MAC-hs.

Once the MAC 115 unit resets the MAC-hs and / or reconfigures the MAC-hs (step 220), and the reordering queues 140A and 140B on the MAC 115 unit are offloaded (step 225), a message of RLC status request can be sent to the RLC 110 unit from the MAC 115 unit (step 230). In step 235, the RLC 110 unit then generates a status report for all RLC instances in recognition mode (AM) mapped to the HS-DSCH after each of the RLC PDUs has been processed by the RLC 110 unit. Optionally, the RLC status request message is sent to the RLC 110 unit.

If an RLC reset is required, the RRC 105 unit sends a reset message (that is, an RLC reset message) to the RLC 110 unit (step 240). A partial or total adjustment is then carried out as a result of this request, as described in detail below. The following options may be available for an RLC readjustment indication:

1) no RLC indication is sent to the RLC 110 unit;

2) a full reset indication is sent to the RLC 110 unit; or

3) a partial reset indication is sent to the RLC 110 unit.

The RLC readjustment / reconfiguration indication can be signaled by the primitive RLC control (CRLC) -Config-Req, or it can be explicitly signaled by MAC-hs with the last SDU MAC SDU sent. Alternatively, the RLC readjustment / reconfiguration indication can be signaled by MAC-hs through STATUS-Report-Req. The RLC processing of all downloaded SDUs is preferably carried out before the status report or the RLC readjustment.

If an unsynchronized handover is performed, steps 220-230 are performed as soon as the RRC message is received. In case of a synchronized handover, steps 220-230 are performed at a given moment of activation.

Signaling method for WTRU

Once the RRC at RNC has made the decision to make a change from Node B in service, the RNC must notify the WTRU that it is

10/22 readjustment / reconfiguration is required for the MAC-hs sublayer or for the receiving RLC entity, if applicable. One or a combination of the following options is preferably performed:

The RNC sends an RRC handover message explicitly indicating one or a combination of the following information:

la) readjustment or reconfiguration of MAC-hs. An extra bit (ie, a MAC-hs reset indicator) is added to the RRC message indicating either the MAC-hs R6 or R7 operation from the handover.

lb) RLC readjustment indicator to specify both a partial and a full readjustment.

lc) two bits to indicate one of:

i) readjustment of MAC-hs;

ii) reconfiguration of MAC-hs;

iii) readjustment of the RLC; or iv) activation is not required.

ld) an extra field indicating that a cell change, from R6 to R7, or vice versa, has occurred; or le) no extra information is added to the RRC handover message except for the conventional MAC-hs reset indicator.

The WTRU preferably decides which action to take based on one or a combination of the following options:

2a) if a MAC-hs reconfiguration or an RLC readjustment is explicitly signaled, (ie, signaling 1a, 1b or 1c above), WTRU performs the tasks indicated in the orders described above.

2b) if only the MAC-hs reset is indicated as TRUE and no external bit of information is added to the RRC handover message (that is, signaling 1e), then the WTRU bases its decision on the system information from the source and target cells of RRC messages. Specifically, the WTRU implicitly reads / obtains information on the supporting characteristics of the source and target cells.

i) if the WTRU detects a change from R6 to R7 or from R7 to R6, the WTRU deduces that a MAC-hs reconfiguration is necessary. In addition, the WTRU can also deduct whether an adjustment or re-establishment of the RLC is required. The WRTU can deduce that a change from R6 to R7, or vice versa, occurred through the information provided in the IE RB mapping information of the RRC handover message, that is, whether MAC-ehs or MAC-hs is being configured and whether the new RLC entity supports the RLC PDU

11/22 fixed or flexible. WRTU compares the new configuration with the existing one and deduces that a change has occurred.

ii) RLC readjustment may not be necessary when one changes from R6 to R7. This information can be configured by the highest layers. The higher layers may indicate that it is not necessary to readjust the total and / or partial between certain revisions.

2c) if only a MAC-hs reconfiguration indicator is added to the RRC message, (ie, the signaling 1a above), the WTRU can deduce that a readjustment of the RLC is also necessary.

2d) alternatively, if only one RLC indicator is added to the RRC message (ie, signaling 1b above), the WTRU deduces that a reconfiguration of the MAC-hs is necessary.

2e) if the MAC-hs readjustment indicator is marked as true and the extra RRC message field indicates that the source and white cells support different versions, (ie, the 1d signaling above), then the WTRU decides whether it is necessary the reconfiguration of the MAC-hs reconfiguration and / or a partial or total readjustment of the RLC.

Methods for performing a MAC-hs reset

Reconfiguring MAC-hs makes a change in MAC-hs functionality from the old MAC-hs to the new MAC-hs. Specifically, if the WTRU is moved between cells R6 and R7, the header format and the functionality of MAC-hs is changed. Therefore, a method is needed to make this change.

Initially, the MAC-hs readjustment procedure is performed. Once the buffers are cleared, the variables are readjusted and the satisfactory MAC-hs SDUs are sent to the highest layers, the MAC layer reconfigures its functionality.

In the event of a change from R6 to R7, the following sequence of events may take place:

1) MAC-hs are readjusted.

2) after the readjustment of the HARQ processes, the MAC layer is configured to support the MAC-ehs header format.

) is added the demultiplexing of the functionality of the priority queues before the re-ordering queues. Optionally, the demultiplexing functionality can always be present when MAC-hs is adjusted, (since the WTRU supports R7), since in R6 cells only one reordering queue is present in each MAC-hs PDU.

4) the reassembly functionality (and demultiplexing of the logical channels) is

12/22 added to the existing disassembly functional block in each reordering queue. Optionally, the reassembly functionality can always be present when the MAC-hs is adjusted (since the WTRU supports R7), since in R6 cells none of the entries in the reordering queue will present segmentation identifiers.

If a change occurs from R7 to R6, the following sequence of events may occur:

1) MAC-ehs is readjusted as defined for R7 UTRA R7 cells.

2) from the readjustment of the HARQ processes, the MAC-hs is configured to support the R6 header format.

3) the priority queue demultiplexing functionality is removed. Optionally, the demultiplexing functionality is maintained in MAC-hs since in R6 cells only one reordering queue can be present for each MAC-hs PDU.

4) the reassembly functionality is removed. Optionally, reassembly remains inactive at MAC-hs since none of the R6 cell entries in the reordering queue have segmentation identifiers.

Reconfiguration of the MAC-hs procedure

A single MAC-ehs or MAC-hs per WTRU instance must be configured for all radio carriers. Therefore, MAC-hs is configured to support an improved configuration in version 7 of the support cell, or higher, and a normal configuration in summer 6 of the support cell, or lower.

A WTRU can change its MAC-hs configuration from an improved configuration to a normal configuration, or vice versa, if this is ordered by the highest layers. This can happen, for example, during a handover scenario. A procedure that deals with reconfiguring MAC-hs between MAC-hs and MAC-ehs is described below.

The reconfiguration procedure is based on the information provided to the WTRU via the RRC messages containing the lEs in the MAC-hs or MAC-ehs configurations, or in its equivalent IE included in the RB mapping information IE and the IE present when a RB is adjusted or reconfigured.

The reconfiguration procedure can occur: in the description of the generic actions upon receipt of the IE of the “RB mapping information”; a nine definition which deals with the actions with the receipt of the MAC-hs DL configuration IE or its equivalent IE; or another existing action that deals with another MAC configuration.

The corresponding procedure for receiving this IE

13/22 can be defined as follows:

a) if the “DL configuration of the MAC-hs is set to the“ improved ”value and the previously stored value was set to normal (that is, if the setting is changing from normal to improved):

1) readjust the MAC-hs entry; and

2) configure MAC-hs or MAC-ehs according to the MAC-hs DL configuration IE.

b) in addition, if the “DL configuration of MAC-hs” is set to the normal value and the previously stored value is set to improved (that is, if the configuration is changing from improved to normal):

1) readjust the MAC-ehs entity; and

2) configure MAC-hs or MAC-ehs according to the MAC-hs DL configuration IE.

In an optional embodiment, if the reconfiguration of the MAC-hs is performed at the time of the handover, the indication of adjustment of the existing MAC-hs could be used simultaneously with a configuration change. However, the procedure must ensure that the MAC-hs reset indicator is read and performed before the MAC-hs is reset. In this embodiment, an optional check can be performed. If the MAC-hs reconfiguration occurs, and the MAC-hs reset indicator is not checked, then the WTRU's behavior may be unspecified or the MAC can perform an independent reset.

Optionally, reconfiguring the MAC dew from normal to improved, or vice versa, can be specified in the MAC specifications (3GPP 25.321). The steps can be specified as part of the existing MAC-hs or MAC-ehs procedures. More specifically, when a readjustment of a MAChs or a MAC-ehs is requested by the upper layers, due to the reconfiguration of the MAC-hs from normal to improved, or vice versa, what follows must be clarified in the MAC-hs readjustment procedure. and / or MAC-ehs. In case the configuration has occurred (or optionally this can be applied to all cases), all the PDUs or PDUs of reordering MAC-hs discharged must be processed using the previously existing configuration before the readjustment indication.

Alternatively, the reset procedure can be specified in a new section in the MAC specification (3GPP 25.321) or as a part of the reset procedure for the MAC-hs / MAC-ehs parameters. The method deals specifically with reconfiguring MACs^:hs for MAC-ehs, or vice versa, ordered by the highest layers ,. More specifically, the following can be specified and indicated:

14/22

The MAC-hs / ehs entity can be reconfigured (modified) by the upper layers from normal to improved, or vice versa.

When the MAC-hs / ehs entity is reconfigured by the upper layers, the WTRU must readjust the MAC-hs / ehs entity (all packets in the reordering queues must be processed using the configuration prior to the reconfiguration).

Alternatively for the purpose of this procedure, the readjustment can be overridden by removing all reordering PDUs or MAC-hs PDUs from the reordering queue and sending them to the outgoing entity, with the outgoing entity being the above entity of the reordering entity (for example, for MAC-hs this can be the disassembly entity and for MAC-ehs this can be the demultiplexing entity LCH-ID, or the reassembly entity). Note that the reset procedure can still be performed after reconfiguration due to the MAC-hs reset indicator explicit in the handover command. The use of the new MAC-hs or MAC-ehs settings starts at the moment of activation indicated by the highest layers.

Methods to perform the RLC readjustment during handovers

a) Switching the cells from R6 to R7 without a total readjustment of the RLC.

When switching cells R6 to R7, a total readjustment does not need to be performed due to the fact that the new RLC can be configured to support flexible PDU sizes. This is called a partial readjustment. If the RLC readers do not show any significant changes, the PDU of the existing fixed RLCs are preferably treated as flexible PDUs in the new RLC. Therefore, the RLC entity preferably maintains the existing sequence of RLC numbers and corresponding PDUs. However, some variables are preferably re-started or changed to support the new RLC entities. These variables preferably include, but are not limited to, one or a combination of timers, variables that deal with the maintenance of the transmission and reception windows, criteria for situation reports, and other situation variables applicable to R7.

If readjustment is necessary, a method similar to the one below can be used.

b) Switching cells R7 to R6 when RLC readjustment is necessary.

A change in the service cell from an R7 cell to an R6 cell may require a readjustment of the RLC due to the fact that the R6 RLC is not configured to handle flexible RLC PDU sizes. Therefore, the RLC PDUs in the RLC entity are preferably erased on the transmission side and

15/22 processed on the receiving side before the adjustment is applied. In order to optimize the readjustment procedure and to minimize data loss, one of the two options is preferably performed. In addition, in other systems in which RLC functionality is included in Node B, such as in RCD LTE or flat WCDMA architectures, when an inter-Node B handover occurs, the RLC entity in WRTU must be readjusted or re-established and data loss must be minimized. The options described below are also applicable for such systems.

Option 1

The transmission side resets the state variables specified for the sender. The transmission side adjusts the configurable parameters applicable to the transmission side of the RLC entity. The transmission link resets the hyper frame number (HFN). The transmission side discards the SDUs that have been successfully transmitted to the receiver for each RLC AM entity (ie, all RLC PDUs corresponding to the SDUs that have been positively confirmed as received and alternatively notify the upper layers that these SDUs were transmitted from satisfactorily).

Alternatively, the transmission side can discard all SDUs that have been successfully transmitted until the first SDU is not successfully transmitted. All SDUs that have one or more non-acknowledgment receipts from the RLC PDUs are saved in the transmission buffer, and the transmission buffer can be located in the RLC entity or in higher layers, such as in the data convergence protocol of the package (PDCP). The transmission side discards all RLC PDUs and all PDUs on the transmission side. Once the readjustment procedure is completed, RLC SDUs that have not been discarded can be transmitted through the target Node B through the new RLC configuration on the target Node B.

This method minimizes data loss and unsatisfactory SDUs are retransmitted. Since the transmission side does not receive a final status PDU from the receiving side, the transmission side does not have updated status information. This can result in a duplicate transmission of the RLC SDUs. Therefore, a duplication detection feature can be added on the receiving side.

Optionally, a method can be implemented to have a final information on the situation on the receiving side before readjusting the RLC. The receiving side, after readjusting and / or reconfiguring MAC-hs, triggers a status report for all RLC AM entities mapped to HS-DSCH. The status reports are based on the RLC PDU. However, the transmission side must wait to receive the RLC PDU report before readjusting the RLC. This can delay the handover process.

16/22

Alternatively, the receiving side can transmit the status of the RLC's SDU to the transmission side. The transmission side can then discard any other RLC SDUs that have been successfully received. This can minimize duplication of transmissions. However, a method for identifying

RLC SDUs (RLC SDU numbering) is required. Optionally, this function can be performed by the packet data convergence protocol layer (PDCP) instead of the RLC layer. If the data recovery process is handled by the PDCP, the SDU equivalent of RLC is the PDD SUD. As mentioned above, the transmission side will use the status report to relay the

SDUs that were not satisfactorily received and download the SDUs that are indicated as satisfactorily received by the status report, both at the RLC level and at the PDCP level.

On the receiving side, after the MAC has been reset and all packets satisfactorily received, including all packets in the reordering queues, are sent to RLC, the following steps can be performed. The receiving side processes all RLC PDUs. Optionally, the receiving side generates RLC status reports for each RLC AM instance if used to minimize data loss. The receiving side sends the RLC PDUs that can be satisfactorily mounted on RLC SDUs to the higher layers. The receiving side discards RLC PDUs that cannot be mounted on RLC SDUs. Optionally, and if supported and sent in sequence, RLC SDUs that are not in sequence can be preserved on the receiving side, since the missing SDUs will be retransmitted from the target Node B. Optionally, this could be done at the PDCP layer. More specifically, if this functionality is performed in the PDCP, the procedure just described above should be replaced by the PDCP SDU. More specifically, the PDCP should store the PDCP SDUs that are not in sequence until the missing SDUs are retransmitted from the target Node B. The RLC layer can then be reconfigured to the new RLC configuration while resetting the status variables and configurable adjustment parameters applicable on the receiving side to the default values. Duplicate detection functionality can be added. Duplicate RLC SDUs can be deleted and not transmitted to the highest layers. This step can be optionally performed by the highest layers.

Option 2

According to option 2, adjustment of the

RLC. Specifically, if the RLC PDU size of an R7 cell is larger than the fixed size of the RLC PDU of an R6 cell and if a WTRU is moving from an R6 cell to an R7 cell, a smaller PLC PDU is

17/22 preferably transmitted and left in cell R7. If the RLC PDU size of an R7 cell is larger than the fixed size of the RLC PDU of an R6 cell and a WTRU is moving from an R7 cell to an R6 cell, all RLC PDUs of the R7 cell are preferably re-segmented into the fixed size of the RLC PDU. This requires RLC re-segmentation functionality. All other variables and parameters applicable to the transmission and reception sides of the new RLC entities are preferably adjusted to support the R6 RLC.

Forms of realization

1. A method for resetting the media access control unit (MAC), the method comprising:

receiving a high-speed MAC reset message (MAC-ehs) from a radio source control unit (RRC);

unload the hybrid automatic repeat request (HARQ) soft buffer on the MAC unit for all configured HARQ processes;

stop reordering release timer and MAC-ehs release timer located in the MAC unit reordering queue, the reordering queue reordering the protocol data units (PDUs) of the MAC-ehs received using at least a variable;

adjust timers and variable to their initial values;

- send all the reordering PDUs in the reordering queue to a reassembly unit located on the MAC unit;

- the reassembly unit performing the reassembly of the segmented MAC-ehs service data units (SDUs) and sending the MAC-ehs SUDs satisfactorily reassembled to a logical channel identifier (LCH-ID) demultiplexing unit located in the unit MAC;

- the LCH-ID demultiplexing unit sending the complete MAC SDUs to the correct logical channel or MAC stream;

discard the MAC-ehs SDU segments of the reassembly unit; and

- unload the reordering queue.

2. A wireless receiving / transmitting unit (WTRU), comprising:

- a radio source control unit (RRC) configured to receive an RRC handover message indicating that there has been a reconfiguration between the fixed and variable sizes of the radio link control protocol (PDU) data unit (RLC); and

- a radio link control unit (RLC), the unit determining whether or not to send an RLC reset message to the RLC unit.

3. The WTRU of embodiment 2, in which the RRC determines whether it is necessary to reestablish the RLC if the RRC handover message indicates that the

18/22 RLC configuration has changed from a flexible RLC PDU size to a fixed RLC PDU size.

4. A method for performing reconfiguration of high-speed media access control (MAC-hs) or enhanced MAC-hs (MAC-ehs) in a wireless transmission / reception unit (WTRU), the method comprising:

receive a radio source control (RRC) handover message indicating a new MAC-hs or MAC-ehs downlink (DL) configuration value.

5. The method, according to embodiment 4, in which the WTRU determines from the RRC message that a reconfiguration of the MAC occurred when the MAC changes from MAC-hs to MAC-ehs or from MAC-ehs to MAC-hs.

6. The method, according to any one of the embodiments 4 and 5, in which the MAC-hs / ehs readjustment indicator is adjusted in the RRC handover message.

7. The method, according to embodiment 6, in which the WTRU performs the adjustment of the MAC-hs or MAC-ehs before reconfiguring the MAC-hs / ehs if the MAC-ehs or MAC-hs.

8. The method, according to embodiment 6, in which an unspecified behavior of the WTRU occurs if the MAC-hs or MAC-ehs readjustment is not adjusted in the RRC handover message and the MAC-hs reconfiguration has occurred / ehs.

9. A method to minimize data loss during a handover procedure, the method comprising:

- unload the service data units (SDUs) that have been successfully transmitted, the SDUs corresponding to the SDUs of the radio link control; and

- store SDUs that have not been unloaded in an RLC transmission buffer.

10. The method, according to embodiment 9, further comprising:

- unload all PDUs from the RLC into a retransmission buffer.

11.0 method, according to embodiment 10, further comprising:

- readjust the state variables associated with the transmission side of the RLC;

- readjust the number of hyperframes (HFN); and

- adjust the new RLC configuration.

12. A method to minimize data loss during a handover procedure, the method comprising:

- unload the service data units (SDUs) that have been successfully transmitted, the SDUs corresponding to the SDUs of the packet data convergence protocol (PDCP); and store SDUs that have not been unloaded in a PDCP transmission buffer.

19/22

13. The method, according to embodiment 12, further comprising:

- unload all protocol data units (PDUs) from radio link control (RLC) into a retransmission buffer.

14. The method, according to embodiment 13, still comprising: readjusting the state variables associated with the transmission side of the RLC; readjust the number of hyper frames (HFN); and adjust the new RLC configuration.

15. A method to minimize data loss during a handover procedure, the method comprising:

- unload the service data units (SDUs) that have been successfully transmitted, up to a first SDU not successfully transmitted; and

- store SDUs that have not been unloaded in a radio link control (RLC) transmission buffer, the SDUs corresponding to the RLC SDUs.

16. The method, according to embodiment 15, further comprising:

- unload all PDUs from the RLC into a retransmission buffer.

17. The method, according to embodiment 16, further comprising:

- readjust the state variables associated with the transmission side of the RLC; readjust the number of hyperframes (HFN); and adjust the new RLC configuration.

18. A method to minimize data loss during a handover procedure, the method comprising:

- unload the service data units (SDUs) that have been successfully transmitted, up to a first SDU not successfully transmitted; and

- store SDUs that have not been unloaded in a transmission buffer of the packet data convergence protocol (PDCP), with the SDUs corresponding to the PDCP SUDs.

19. The method, according to embodiment 18, further comprising: unloading all PDUs from the RLC into a retransmission buffer.

20. The method, according to embodiment 19, still comprising: readjusting the state variables associated with the transmission side of the RLC; readjust the number of hyperframes (HFN); and

- adjust the new RLC configuration.

21. A method for sending a service data unit (SDU) status report when a handover occurs, the method comprising:

- confirm receipt of SDUs satisfactorily received; and not confirming receipt of SDUs not satisfactorily received, with an SDU status report corresponding to a radio link control (RLC) SDU status report.

20/22

22. The method, according to embodiment 21, still comprising: unloading the SDUs that have been confirmed in a situation report of the SDU of the RLC received during the handover.

23. A method for sending a service data unit (SDU) status report when a handover occurs, the method comprising:

- confirm receipt of SDUs satisfactorily received: and do not confirm receipt of SDUs not satisfactorily received, with an SDU status report corresponding to an SDU status report for the packet data convergence protocol (PDCP).

24. The method, according to embodiment 23, further comprising:

- unload the SDUs that have been confirmed in a PDU SDU status report received during the handover.

25. A method for relaying service data units (SDUs) after a handover has occurred, the method comprising:

- retransmit the SDUs through a new cell, the SDUs corresponding to the SDUs of the radio link control (RLC).

26. The method, according to embodiment 25, further comprising:

- retransmit all SDUs that have not been acknowledged.

27. The method, according to embodiment 25, further comprising:

- retransmit all SDUs from a first SDU not satisfactorily transmitted.

28. The method, according to embodiment 25, further comprising:

- retransmit only those SDUs that have not been acknowledged after an SDU status report has been received due to a handover.

29. The method, according to embodiment 25, further comprising:

- retransmit the SDUs that have been stored in a transmission buffer of the RLC SDU.

30. A method for relaying service data units (SDUs) after a handover has occurred, the method comprising:

retransmit the SDUs through a new cell, the SDUs corresponding to the SDUs of the packet data convergence protocol (PDCP).

31. The method, according to embodiment 30, further comprising:

- retransmit all SDUs that have not been acknowledged.

32. The method, according to embodiment 30, further comprising:

- retransmit all SDUs from a first SDU not satisfactorily transmitted.

33. The method, according to embodiment 30, still comprising: retransmit only those SDUs that have not been acknowledged after a

21/22 SDU status report has been received due to a handover.

34. The method, according to embodiment 30, further comprising: retransmitting the SDUs that have been stored in a transmission buffer of the PDCP's SDU.

35. A method of processing service data units (SDUs) when a handover occurs, the method comprising:

process all radio link control (RLC) protocol data units (PDUs) that can be mounted on RLC SDUs;

- send all RLC SDUs satisfactorily assembled to the upper layers;

unload all RLC PDUs that cannot be mounted on RLC SDUs; and

- store the SDUs out of order in an RLC SDU reception buffer.

36. The method, according to embodiment 35, still comprising: readjusting the variables received and the number of hyperframes (HFN);

- adjust the new configuration of the media access control (MAC); and

- adjust the configuration of the new RLC.

37. The method, according to embodiment 36, still comprising: assembling an SDU status report indicating the SDUs satisfactorily and not satisfactorily received, with an SDU status report corresponding to an SDLC status report from the RLC.

38. A method of processing service data units (SDUs) when a handover occurs, the method comprising:

- process all radio link control (RLC) protocol data units (PDUs) that can be mounted on RLC SDUs;

- send all RLC SDUs satisfactorily assembled to the upper layers;

- unload all RLC PDUs that cannot be mounted on RLC SDUs; and

- store the SDUs out of order in an SDU reception buffer of the packet data convergence protocol (PDCP).

39. The method, according to embodiment 38, further comprising:

- readjust the received variables and the number of hyperframes (HFN);

- adjust the new configuration of the media access control (MAC); and

- adjust the configuration of the new RLC.

40. The method, according to embodiment 38, still comprising: assembling an SDU status report indicating the SDUs satisfactorily and not satisfactorily received, with an SDU status report corresponding

22/22 to a PDCP SDU status report.

Although all features and elements have been described in particular combinations, each feature or element can be used alone, without the other features and elements, or in different combinations, with or without other features and elements. The methods or flow charts provided may be implemented by means of a computer program, software, or firmware that are tangibly incorporated into a storage medium that can be read by a computer, for execution through of a general purpose computer or processor. Examples of storage media capable of being read by a computer include read-only memories (ROM), random access memories (RAM), a register, a cache memory, a semiconductor memory device, magnetic media such as a disk internal hard drive, a removable disk, optical-magnetic media and optical media such as CD-ROM discs, and digital versatile discs (DVDs).

Suitable processors may include, for example, a general purpose processor, a specific purpose processor, a conventional processor, a digital signal processor (DSP), a variety of processors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, an integrated circuit for specific applications (ASIC), a field programmable Gate Array circuit (FPGA), or any other type of integrated circuit (Cl), and / or state machine.

A processor in association with software can be used to implement radio frequency transceivers for use in a wireless transmission and reception unit (WTRU), user equipment (EU), terminal, base station, a radio network controller (RNC), or any host computer. The WTRU can be used in conjunction with modules implemented by means of hardware and / or software, such as a camera, a video camera module, a videophone, a talking phone, a vibrating device, a speaker, a microphone, a television transceiver, a handsfree headset, a keyboard, a Bluetooth® module, a radio frequency modulated (FM) unit, a liquid crystal display (LCD) unit, a LED display unit organic (OLED), a digital music player, a media player, a video game module, an Internet browser, and / or any wireless local area network (WLAN) module.

1/4