RU2448437C2 - Method and apparatus for controlling handover between utra r6 cells and r7 cells - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: method and apparatus for controlling an optimisation of handover procedures between universal terrestrial radio access (UTRA) release 6 (R6) cells and UTRA release 7 (R7) cells are disclosed. When a wireless transmit/receive unit (WTRU) is moving between an R6 cell and an R7 cell, or between R7 cells, handover is initiated from a source Node B to a target Node B. In the R7 cell, the enhanced medium access control (MAC) functionality including flexible radio link control (RLC) protocol data unit (PDU) size and high speed MAC (MAC-hs) segmentation and multiplexing of different priority queues are supported. After the handover, a MAC layer and/or an RLC layer are reconfigured or reset based on functionality supported by the target Node B.

EFFECT: reduced loss of quality and data during handover.

7 cl, 3 dwg

Description

FIELD OF THE INVENTION

This application relates to wireless communications.

State of the art

Some of the main goals of developing the High Speed Packet Access Standard (HSPA) include increasing data rates, increasing system bandwidth and coverage, improving support for packet services, reducing latency, reducing operator costs and backward compatibility. Meeting these goals requires the development of a radio interface protocol and network architecture. More specifically, meeting these goals has the required set of improvements and architectural changes to Layer 2 (L2) functionality (i.e., Radio Link Control (RLC) and Media Access Control (MAC)).

Some of the L2 enhancements include flexible RLC protocol data unit (PDU) size, segmentation / concatenation, and high-speed MAC multiplexing (MAC-hs). In Universal Terrestrial Radio Access Standard (UTRA) version 6 (R6), RLC entities in the acknowledgment (AM) mode may only use a fixed RLC PDU size. In addition, the MAC-hs sublayer in Node B can only support MAC-d PDU concatenation. Improvements to L2 in UTRA version 7 (R7) lead to significant RLC / MAC changes for R6 features.

The architecture changes of the Advanced MAC-hs (MAC-ehs) on the UTRAN side include the addition of a multiplexing entity (MUX) by a logical channel identifier (LCH-ID). The LCH-ID MUX object multiplexes the logical channels into a priority queue. The MAC-ehs architecture further includes priority queue segmentation functionality and multiplexing of MAC-ehs payload blocks from various priority queues in the MAC-ehs PDU.

Changes to the MAC-ehs architecture on the wireless receive / transmit module (WTRU) side include parsing MAC-ehs payload blocks from the MAC-ehs PDUs. Additionally, after reordering, the MAC-ehs payload blocks are redirected to the LCH-ID demultiplexing entity. This LCH-ID demultiplexing object routes the MAC-ehs payload blocks to the correct reassembly object based on the logical channel identifier. The MAC-ehs architecture in the WTRU also includes a reassembly entity that reassembles the MAC-ehs segmented service data units (SDUs) and redirects the full MAC-ehs SDUs to higher layers.

Currently, when unidirectional radio channels are set up or reconfigured via Radio Resource Control (RRC) service signals, an information element (IE) "Display Information for Unidirectional Radio Channel (RB)" is present. "Display information for RB" contains information about an RLC instance and transport channels corresponding to a unidirectional radio channel (RB).

In the "Display Information for RB" IE, new information elements (IEs) can be added that indicate whether the RLC instance logical channel supports flexible RLC PDUs or whether MAC sublevels MAC-hs or MAC-ehs. For the purpose of the present invention, these IEs will be referred to as “Downlink RLC (DL) Configuration” and “MAC-hs DL Configuration”. The MAC-hs configuration must be the same for all RBs mapped to the high speed downlink shared channel (HS-DSCH), otherwise an invalid configuration occurs.

In HSPA, high speed shared channels are monitored by WTRUs in one cell (i.e., in a serving cell of a high speed downlink shared channel (HS-DSCH)). Due to mobility, when a WTRU moves from one cell to another, the WTRU must change the serving cell by switching to the new serving HS-DSCH cell and terminating communication with the old serving HS-DSCH cell. In the procedure for redistributing nodes B, a handover between nodes B is carried out from the old node B (i.e., the source node B) to the new node B (i.e. the target node B).

During the change of the serving node B, the target node B should begin to transmit data according to the new configuration. Handover may occur at HSPA Enhanced Bs that support L2 enhancements, or to / from cells with or without L2 enhancements. In both cases, the WTRU should be able to perform handoff, tune in to new configurations, and minimize data loss.

In a conventional system (i.e., R6 system), when a handover is in progress, a Radio Resource Control (RRC) message may carry a MAC level reset indicator. In particular, when a handover between nodes B or within node B takes place, the data in the MAC-hs in the source node B is deleted and the MAC-hs in the WTRU must be reset. When receiving a reset indicator, the WTRU should perform the following sequence of functions:

1) clear the hybrid automatic retransmission request (HARQ) software buffer for all configured HARQ processes;

2) stop all active reordering disable timers (T1) and set all timers T1 to their initial value;

3) start the transmission sequence number (TSN) with the value 0 for the next transmission for each configured HARQ process;

4) initialize the variables RcvWindow_UpperEdge and next_expected_TSN with their initial values;

5) parse all MAC-hs PDUs in the reordering buffer and deliver all MAC-d PDUs to the MAC-d object; and

6) clear the reordering buffer.

With the advent of new L2 enhancements, new procedures must be defined in order to optimize and minimize data loss during handover between R7 cells or between R7 cell and R6 cell. In particular, procedures that aim to reset the MAC-hs object must be modified to take into account new L2 improvements.

In addition, it is impossible to assume that all nodes B R6 will be upgraded simultaneously to nodes B R7. Consequently, handoffs between cells R6 and R7 can occur frequently. Due to functional changes in the RLC and MAC, methods must be defined in order to perform handoffs with minimal loss of quality and data between these cells. In particular, on the WTRU side, MAC-hs and RLC must perform functional changes during handovers.

SUMMARY OF THE INVENTION

A method and apparatus for controlling optimization of handover procedures between a UTRA R6 cell (i.e., a lower layer) and a UTRA R7 cell (i.e. a upper layer) are disclosed. When a WTRU moves between an R6 cell and an R7 cell or between R7 cells, a handover is initiated from the source node B to the target node B. In the R7 cell, enhanced MAC functionality is supported, including flexible RLC PDU size and MAC-hs segmentation and multiplexing of various priority queues in the WTRU. The changes that are being made to the WRTU are due to the fact that the WRTU moves between R6 and R7. When the WRTU moves between these cells, the network must reconfigure the WRTU with the new configurations. After a handover, the MAC layer and / or RLC layer are reconfigured or reset based on the functionality supported by target node B.

Brief Description of the Drawings

A more detailed understanding of the invention can be obtained from the following description together with the accompanying drawings, in which:

FIG. 1A is an exemplary flow chart of a WTRU that moves between R6 and R7 and is configured to work with new RLC and MAC-hs sub-layers when a handover message is received during a serving cell change procedure;

FIG. 1B is a detailed diagram of a MAC module in the WTRU of FIG. 1A; and

FIG. 2 is a flowchart of a WTRU handover procedure implemented in the WTRU of FIG. 1A.

DETAILED DESCRIPTION OF THE INVENTION

When mentioned below, the term "wireless transmit / receive module (WTRU)" includes, but is not limited to, user equipment (UE), a mobile station, a fixed or mobile subscriber module, a pager, a cell phone, a personal digital device (PDA), a computer or any other type of user device capable of operating in a wireless environment. When referred to below, the term “Node B” includes, but is not limited to, a base station, a node controller, an access point (AP), or any other type of interface device capable of operating in a wireless environment.

When mentioned below, cell R7 includes nodes B and RNC, which have advanced features L2. Throughout this invention, the R7 cell may refer to older versions that support advanced L2. When mentioned below, the R6 cell includes a Node B and an RNC that do not support the advanced features of L2. This may include B R7 nodes without L2 features and any of the previous versions of the third generation partnership project standard (3GPP). R7 MAC-hs in this invention is referred to as enhanced MAC-hs (i.e., MAC-ehs).

The term “RLC reset” is also referred to as re-establishment of an RLC. These terms are used interchangeably.

The following terms are used throughout the description and are given briefly. The MAC-ehs payload block is the MAC-ehs SDU or MAC-ehs SDU segment contained in the MAC-ehs PDU. MAC-ehs reordering PDUs are a set of MAC-ehs payload blocks in MAC-ehs PDUs that belong to a single priority queue. An advanced cell is a cell that supports L2 enhancements. An unimproved cell is a cell that does not support L2 enhancements.

Disclosed are changes to a MAC-hs or MAC-ehs reset procedure, a MAC-hs or MAC-ehs reconfiguration procedure, and an RLC re-establishment evaluation procedure.

A method and apparatus are disclosed herein that optimize handover scenarios, reset procedures for MAC-hs objects and RLC objects to support handoff between R7 cells and between R6 and R7 cells. It should be understood that references to R6 cells or R6 nodes B are directed to cells and B nodes that do not support advanced L2 features, such as MAC segmentation and flexible RLC PDU size. The disclosed method and apparatus is applicable to both uplink (UL) and downlink (DL), as well as other wireless technologies, such as long-term development standard (LTE) and other systems with a flat architecture, such as broadband multiple code division access (WCDMA) R8.

FIG. 1A is an exemplary flow chart of a WTRU 100 that moves between R6 and R7 and is configured to operate with new RLC and MAC-hs sublayer when a handover message is received during a serving cell change procedure. As shown in FIG. 1A, the WTRU 100 includes an RRC module 105, an RLC module 110, a MAC module 115, and a physical layer 1 (PHY) module 120. The change of the serving cell can be carried out through the RRC message reconfiguration of the unidirectional radio channel, the RRC message reconfiguration of the transport channel or the RRC message reconfiguration of the physical channel.

The WTRU 100 operates in a wireless communication system including a target node B, a source node B, an RNC control (CRNC), and a source RNC (SRNC) (not shown). An SRNC may include an RLC module and an RRC module (not shown).

Handover within an R7 Cell

In the R7 architecture, MAC-hs contains new functionalities that include MAC-hs segmentation and multiplexing of different priority queues at node B. The RLC functionality remains in the radio network controller (RNC) and supports flexible PDU sizes. The R7 MAC-hs header is significantly different from the R6 MAC-hs header. In LTE and other WCDMA flat architecture systems, the RLC functionality is located in the Node B. In UL, the RLC functionality is in the WTRU.

When a handover is in progress, the MAC-hs object in the source node B is deleted and the new MAC-hs object is set in the target node B. When the new configuration is performed, the maximum RLC PDU size can be adjusted for the target node B. This is done by one or a combination of the following methods: 1) assign a default value for the initial size of the RLC PDU; 2) maintain the existing size of the RLC PDU; or 3) set a new RLC PDU size based on the channel characteristics of the target node B. This is applicable when node B reports the maximum size of the RLC PDU to the RLC object in the RNC. Messages with a channel quality indicator (CQI) that are sent to the target node B during a handover may offer a good estimate of the channel characteristics. In turn, the target node B may provide feedback to the RLC entity in the RNC to set the updated RLC PDU size before initiating transmission on the new cell. Any conventional methods may be used to provide feedback information to the target node B during the change of the serving HS-DSCH cell.

When the new MAC-hs is set at the target node B, the MAC-hs on the WTRU side is preferably synchronized with the target node B. Therefore, the WTRU preferably also resets the MAC-hs object in the WTRU.

Due to changes in the functionality of the MAC-hs sublayer, the R6 reset procedure is modified to take into account the fact that after HARQ reception, the MAC-hs PDU disassembly function is used before reordering. After reordering, the reassembly function is added to the existing disassembly function.

The traditional R6 MAC-hs reset procedure is changed by disassembling all MAC-hs PDUs in the reordering buffer, reassembling the segmented packets that can be successfully reassembled in MAC-hs service data units (SDUs), and delivering all the ready MAC-hs SDUs to the upper levels and discards of partially received MAC-hs SDUs.

More specifically, due to changes in architecture, it is proposed to update the MAC-ehs reset procedure. At this time of activation or during indication, the WTRU should process the reordering PDUs of MAC-ehs that are waiting in the reordering buffer. All MAC-ehs reordering PDUs must be parsed or demultiplexed into MAC-ehs payload blocks. MAC-ehs payload blocks are then passed to the reassembly module. After the reassembly entity processes all of the MAC-ehs payload blocks and reassembles the segmented MAC-ehs payload blocks in the MAC-ehs SDUs that can be reassembled, the reassembly must ensure that any remaining saved segment ( s) The MAC-hs SDU is removed from the reassembly entity. Finally, off-the-shelf PDUs are delivered to higher layers in the corresponding logical channels or MAC-d / c flows.

For example, the MAC-ehs reset procedure may take the following form for the MAC-ehs architecture, if the reset of the MAC module 115 is requested by the upper layers, then the WTRU 100 during activation indicated by the upper layers should:

a) flush HARQ program buffers for all configured HARQ processes;

b) stop all active reordering disable timers (T1) and set all timers T1 to their initial value;

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

d) initialize the variables RcvWindow_UpperEdge and next_expected_TSN with their initial values;

e) deliver all reordering PDUs in the reordering queue to LCH-ID demultiplexing modules and / or demultiplexing MAC-ehs payload blocks and routing them to the correct reassembly module based on the logical channel identifier;

f) reassemble the segmented MAC-ehs SDUs and deliver the finished MAC-ehs SDUs (MAC PDUs) to the upper layers;

g) discard all stored reordering PDUs (or MAC-hs SDU segments) from the reassembly modules;

h) clear reordering queues; and

i) it is not necessary to indicate all RLC objects of the acknowledgment (AM) mode displayed on the HS-DSCH in order to generate a status report if the MAC-hs reset is triggered due to the receipt of the MAC-hs Reset Indicator IE by upper layers.

A different MAC-ehs architecture may exist if the reordering functionality is followed by the SDU disassembly function, the reassembly object, and finally the LCH-ID demultiplexing object. A disassembly function can be part of a reassembly object, with only the reassembly object to exist in the MAC-ehs architecture. For example, the MAC-ehs reset procedure may take the following form for this MAC-ehs architecture.

FIG. 1B is a detailed diagram of a MAC module 115 in the WTRU 100 of FIG. 1A. As shown in FIG. 1B, the MAC module 115 includes a plurality of LCH-ID demultiplexing modules 130A and 130B, reassembly modules 135A and 135B, reordering queues 140A and 140B, reordering queue distribution module 145, disassembly module 150, and a HARQ module 155. Reordering queues 140A and 140B are used to reorder the received MAC PDUs, so reassembly can be performed and data can be delivered in order to the upper layers. HARQ module 155 includes at least one HARQ software buffer (not shown).

Referring to FIG. 1B, if a MAC-ehs object reset is requested by upper layers, the WTRU 100 during activation indicated by upper layers should:

a) clear the HARQ program buffer in HARQ module 155 for all configured HARQ processes;

b) stop all active reordering disable timers (T1) and set all timers T1 to their initial value;

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

d) initialize the variables RcvWindow_UpperEdge and next_expected_TSN with their initial values;

e) all reordering PDUs in reordering queues 140A and 140B are delivered to disassembly module 150; and / or

f) the disassembly unit 150 parses all reordering PDUs into MAC-hs SDUs or MAC-hs SDU segments and delivers them to the reassembly units 135A and 135B; or

g) if there is only reassembly module 135, data from reordering queues is delivered to reassembly module 135. Reassembly modules 135A and 135B reassemble the segmented MAC-ehs SDUs and deliver the finished MAC-ehs SDUs to the LCH-ID demultiplexing modules 130A and 130B, each of which delivers the finished SDUs to the correct logical channel or MAC-d / c stream;

g) discard all stored reordering PDUs (or MAC-hs SDU segments) from the reassembly units 135A and 135B; and

h) flush reordering queues 140A and 140B.

Optionally, in the case of a handover within node B (i.e., handoff between sectors of one node B), the MAC-hs reset procedure described above probably will not have to be performed. In this case, the handover is performed as described in the conventional R6 system.

Handover between R6 and R7 cells

L2 enhanced cells (i.e., R7 cells) support a flexible RLC PDU size, while unimproved cells (i.e., R6 cells) have a fixed RLC PDU size. This implies that when a handover to and from R7 cells takes place, the affected RLC objects in the RNC and WTRU must be reconfigured to old RLC objects. In addition, MAC-hs sublevels must be reconfigured to decode the correct header formats and support new or old functionality.

If re-establishment of an RLC entity is required, significant data loss may occur. Thus, it is desirable to minimize this data loss.

Event Sequence for Handover Procedure

FIG. 2 is a flowchart of a WTRU handover procedure 200 implemented in the WTRU 100 of FIG. 1. At step 205, the RRC module 105 in the WTRU 100 receives an RRC handover command to initiate a handover procedure. At step 210, the physical layer (PHY) module 120 (L1) 120 is instructed by the RRC module 105 to establish new radio links indicated in the RRC handover command. This sequence of events is similar to the traditional procedure prior to the MAC-hs reset stage.

At step 215, the RRC module 105 sends a request to reset the MAC-hs and / or reconfigure the MAC-hs to the MAC module 115 in the WTRU 100, as necessary. If reconfiguration of MAC-hs is required, then reconfiguration of MAC-hs is performed as explained in detail below. The MAC-hs reset indicator parameter of the RRC module 105 to the MAC primitive may optionally be supplemented to indicate MAC-hs reconfiguration.

Once MAC module 115 performs MAC-hs reset and / or MAC-hs reconfiguration (step 220), and reordering queues 140A and 140B in MAC module 115 are cleared (step 225), an RLC status request message can be sent to the RLC module 110 from the MAC module 115 (step 230). At step 235, the RLC module 110 then generates a status report for all RLC instances in the acknowledgment (AM) mode displayed on the HS-DSCH after each of the RLC PDUs is processed by the RLC module 110. Optionally, a request message RLC status is not sent to RLC module 110.

If an RLC reset is required, the RRC module 105 sends a re-establishment request message (i.e., an RLC reset message) to the RLC module 110 (step 240). A partial or full RLC reset is then performed as a result of this request, as described in detail below. The following options may be available for the RLC reset indicator:

1) the RLC indicator is not sent to the RLC module 110;

2) a complete reset indicator is sent to the RLC module 110; or

3) a partial reset indicator is sent to the RLC module 110.

The RLC reset / reconfiguration indicator may be signaled via the RLC (CRLC) -Config-Req control primitive, or may be explicitly signaled by MAC-hs with the last redirected MAC SDU. Alternatively, the RLC reset / reconfiguration indicator can be reported via MAC-hs using STATUS-Report-Req. The RLC processing of all cleared SDUs is preferably performed before an RLC reset or status report.

If an unsynchronized handover is performed, steps 220-230 are performed as soon as the RRC message is received. If the synchronized handover is performed, steps 220-230 are performed at the current activation time.

Overhead transmission method in WTRU

After the RRC at the RNC has decided to change the serving Node B, the RNC should notify the WTRU that a reset / reconfiguration is required for the MAC-hs sublayer or RLC receiving 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:

1a) reset or reconfigure MAC-hs. An additional bit (i.e., the MAC-hs reconfiguration indicator) is added to the RRC message indicating operation R6 or R7 of the MAC-hs after handover;

1b) RLC reset indicator to indicate partial or complete reset;

1c) two bits to indicate one of the following:

i) MAC-hs reset;

ii) reconfiguration of MAC-hs;

iii) RLC reset or

iv) no action required;

1d) an additional field indicating that a cell change from R6 to R7 or vice versa has occurred; or

1e) additional information is not added to the RRC handover message other than the traditional MAC-hs reset indicator.

The WTRU preferably determines what action it should take based on one or a combination of the following options:

2a) if the reconfiguration of the MAC-hs or the reset of the RLC is reported explicitly (i.e., through the service signals 1a, 1b or 1c above), the WTRU performs these tasks in the manner described above;

2b) if only the MAC-hs reset is set to TRUE and additional information bits are not added to the RRC handover message (i.e., service signals 1e), then the WTRU bases its decision on system information from the source and target cells from the RRC messages . In particular, the WTRU implicitly reads / receives information about the support signs of the source and target cells;

i) if the WTRU detects that a change from R6 to R7 or from R7 to R6 is occurring, the WTRU concludes that MAC-hs reconfiguration is necessary. In addition, the WTRU may also conclude whether a reset or re-establishment of the RLC is required. The WRTU may conclude that a change has occurred from R6 to R7, or vice versa, through the information provided in the IE "Display Information for RB" in the RRC handover message, i.e. whether MAC-ehs or MAC-hs is configured and whether the new RLC entity supports flexible or fixed RLC PDUs. WRTU compares the new configuration with the existing one and concludes that the change has occurred;

ii) RLC reset may not be required when a change from R6 to R7 occurs. This information can be configured through higher layers. The upper levels may indicate that no RLC reset is required or a full / partial RLC reset between specific versions is required;

2c) if only the MAC-hs reconfiguration indicator is added to the RRC message (i.e., overhead signals 1a above), the WTRU may conclude that an RLC reset is also required;

2d) alternatively, if only the RLC reset indicator is added to the RRC message (i.e., overhead signals 1b above), the WTRU concludes that MAC-hs reconfiguration is required;

2e) if the MAC-hs reset indicator is set to TRUE, and an additional field in the RRC message indicates that the source and target cells support different versions (i.e., service signals 1d above), then the WTRU determines whether reconfiguration of MAC-hs is required and / or a partial or full RLC reset is required.

Ways to Perform MAC-hs Reconfiguration

Reconfiguring MAC-hs performs a change in MAC-hs functionality from the old MAC-hs to the new MAC-hs. In particular, if the WTRU moves between cells R6 and R7, the header format and the functionality of the MAC-hs are changed. Therefore, a method is required in order to carry out this change.

Initially, the MAC-hs reset procedure is performed. Once the buffers are cleared, the variables are flushed, and the successful MAC-hs SDUs are delivered to the upper layers, the MAC layer will reconfigure its functionality.

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

1) MAC-hs reset;

2) after resetting the HARQ processes, the MAC layer is configured to support the MAC-ehs header format;

3) the priority demultiplexing functionality is added before reordering queues. Optionally, demultiplexing functionality can always be present when MAC-hs is installed (assuming that the WTRU supports R7), since in R6 cells only one reordering queue is present in each MAC-hs PDU;

4) the functionality of reassembly (and demultiplexing of logical channels) is added to the existing disassembly function block in each reordering queue. Optionally, reassembly functionality can always be present when MAC-hs is installed (assuming that the WTRU supports R7), since there are no reordering queue entries in segment R6 that have segmentation identifiers.

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

1) MAC-ehs is reset, as specified for UTRA R7 cells;

2) after resetting the HARQ processes, MAC-hs is configured to support the R6 header format;

3) the priority demultiplexing functionality is deleted. Optionally, demultiplexing functionality is stored in MAC-hs, since in R6 cells only one reordering queue should be present in each MAC-hs PDU;

4) the reassembly functionality is removed. Optionally, reassembly remains inactive in MAC-hs, as there are no reordering queue entries in segment R6 with segmentation identifiers.

MAC-hs reconfiguration procedure

One instance of MAC-ehs or MAC-hs in the WTRU must be configured for all unidirectional radio channels. Therefore, MAC-hs is configured to support an advanced configuration in a cell supporting version 7 and higher, and a conventional configuration in a cell supporting version 6 and lower.

The WTRU can change its MAC-hs configuration from an advanced configuration to a regular configuration, or vice versa, if commanded through higher layers. This may occur, for example, during a handover scenario. The procedure for 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 RRC messages that contain IEs for MAC-hs or MAC-ehs configurations or their equivalent IEs included in the IE "Display Information for RB" and IE is available when RB is installed or reconfigured .

The reconfiguration procedure can be carried out with: a description of the universal actions when receiving IE "Display information for RB"; a new definition that seeks to obtain the “MAC-hs-DL configuration" IE or equivalent IE; or other intended action that is directed to a different MAC configuration.

The procedure corresponding to the reception of this IE can be defined as follows:

a) if the "MAC-hs-DL configuration" is set to "advanced", and the previously stored value is "normal" (that is, if the configuration is changed from normal to advanced):

1) reset the MAC-hs object and

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

b) otherwise, if the "MAC-hs-DL configuration" is set to "normal", and the previously stored value is equal to "advanced" (that is, if the configuration is changed from advanced to normal):

1) reset the MAC-ehs object and

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

In an optional embodiment, if reconfiguration of the MAC-hs is performed during a handover, the existing MAC-hs reset indicator may be used at the same time as the configuration change. However, the procedure must ensure that the MAC-hs reset indicator is read and executed before reconfiguring the MAC-hs. In this embodiment, an optional check may be performed. If reconfiguration of the MAC-hs is performed and the MAC-hs reset indicator is not set, then the WTRU operation mode may be undefined, or the MAC independently performs a reset.

Optionally, reconfiguring the MAC from normal to advanced and vice versa can be specified in MAC specifications (3GPP 25.321). Stages can be specified as part of an existing MAC-hs or MAC-ehs procedure. More specifically, when a reset of MAC-hs or MAC-ehs is requested by upper layers due to reconfiguration from normal to enhanced MAC-hs or vice versa, the following can be clarified in the reset procedure of MAC-ehs and / or MAC-hs. If reconfiguration has occurred (or it may not necessarily apply to all cases), all cleared reordering PDUs or MAC-hs PDUs must be processed using the old configuration that existed before the reset indicator.

Alternatively, the reconfiguration procedure may be specified in the new MAC specification section (3GPP 25.321) or as part of the reconfiguration of MAC-hs / MAC-ehs parameters. The method is directed, in particular, to reconfigure MAC-hs to MAC-ehs or vice versa, ordered by upper layers. More specifically, the following may be defined and indicated:

The MAC-hs / ehs-object can be reconfigured (modified) by the upper levels from the usual to the advanced or vice versa.

When the MAC-hs / ehs object is reconfigured through the upper layers, the WTRU must discard the MAC-hs / ehs object (all packets in the reordering queues must be processed using the old configuration before reconfiguration).

Alternatively, for the purpose of this procedure, the reset can be replaced by removing all reordering PDUs or MAC-hs PDUs from the reordering queue and delivering them to the output object, where the output object is the object above the reordering object (for example, for MAC-hs this can be a disassembly object , and for MAC-ehs it can be an LCH-ID demultiplexing object or a reassembly object). Note that the reset procedure may still be performed after reconfiguration due to the explicit MAC-hs reset indicator in the handover command. Then, the use of the configuration of the new MAC-hs or MAC-ehs begins during activation, indicated by the upper layers.

Ways to Perform RLC Reset During Handoffs

a) Switching from R6 cells to R7 cells without a complete RLC reset.

When switching from R6 cells to R7 cells, a full reset may not be performed due to the new RLC being configured to support flexible PDU sizes. This is called a partial reset. If the RLC headers do not have any significant changes, the existing fixed RLC PDUs are preferably treated as flexible PDUs in the new RLC. Therefore, the RLC entity preferably stores existing sequence numbers and corresponding RLC PDUs. However, some variables are preferably reinitialized or modified to support new RLC objects. These variables preferably include, but are not limited to, one or a combination of timers, variables that aim to support the receive and transmit window, criteria for reporting a status, and other state variables applicable to R7.

If a reset is required, a method similar to the one below can be performed.

b) Switching from R7 cells to R6 cells when an RLC reset is required.

Changing a serving cell from an R7 cell to an R6 cell may require an RLC reset because the R6 RLC is not configured to handle flexible RLC PDU sizes. Therefore, the RLC PDUs in the RLC entity are preferably deleted at the transmitting side and processed at the receiving side before the reset is applied. To optimize the reset procedure and minimize data loss, one of the following two options is preferably performed. Additionally, in other systems where RLC functionality is included in Node B, such as LTE or R8 WCDMA with a flat architecture, when a handover occurs between Nodes B, the RLC in the WRTU should probably be reset or reinstalled, and data loss should be minimized. The options described below also apply to such systems.

Option 1

The sending side resets the state variables specified for the sender. The transmitting side sets configurable parameters applicable to the transmitting side of the new RLC entity. The transmitting side resets the hyperframe number (HFN). The transmitting side discards SDUs that are successfully transmitted to the receiver for each AM RLC entity (i.e., all RLC PDUs corresponding to SDUs that are positively acknowledged and alternatively notify the upper layers that these SDUs have been successfully transmitted).

Alternatively, the transmitting side may discard all SDUs that are successfully transmitted until the first unsuccessful SDU. All SDUs that have one or more RLC PDUs without acknowledgment are stored in the transmission buffer, the transmission buffer being located in the RLC entity or at higher layers, such as packet data convergence protocol (PDCP). The transmitting side discards all RLC PDUs and all control PDUs on the transmitting side. Once the reset procedure is completed, RLC SDUs that are not discarded can be transmitted through target node B according to the new RLC configuration in target node B.

This method minimizes data loss, and failed SDUs are retransmitted. Since the transmitting side did not receive the final PDU state from the receiving side, the transmitting side does not have up-to-date status information. This may result in duplicate transmission of the RLC SDU. Therefore, duplication detection functionality can be added at the receiving side.

Optionally, the method may be implemented in order to obtain end state information from the receiving side prior to the reset of the RLC. The receiving side, after resetting and / or reconfiguring the MAC-hs, initiates a status report for all AM RLC entities mapped to the HS-DSCH. Status reports are based on RLC PDUs. However, the transmitting side must wait to accept the status of the RLC PDU before the RLC is reset. This may delay the handover procedure.

Alternatively, the receiving side may transmit the RLC SDU state to the transmitting side. The transmitting side can then discard all other RLC SDUs that are successfully received. This can minimize duplicate transmission. However, a method is required in order to identify the RLC SDU (RLC SDU numbering). Optionally, this function may be performed by a packet data convergence protocol (PDCP) layer instead of an RLC layer. If the data recovery process is processed by PDCP, the equivalent of the RLC SDU is PDCP SDU. As mentioned above, the transmitter side must use a status report in order to retransmit SDUs that are not received successfully and discard SDUs that are indicated as successfully received according to the status report, at the RLC level or at the PDCP level .

At the receiving side, after the MAC is discarded and all successfully received packets, including all packets in the reordering queue, are delivered to the RLC, the following steps can be performed. The receiver handles all RLC PDUs. Optionally, the receiving end generates RLC status reports for each AM RLC instance, if used in order to minimize data loss. The receiving side sends the RLC PDUs, which can be successfully assembled in the RLC SDU, to the upper layers. The receiving side discards the RLC PDUs that cannot be assembled in the RLC SDU. Optionally, if sequential delivery is supported, RLC SDUs that are not serial can be stored on the receiving side, since missing SDUs must be retransmitted from destination node B. Optionally, this can be done at the PDCP level. More specifically, if this functionality is performed in a PDCP, the procedure described immediately above should be replaced with a PDCP SDU. More specifically, the PDCP must store PDCP SDUs that are not consecutive until the missing SDUs are retransmitted from the target node B. The RLC layer can then be reconfigured to a new RLC configuration while simultaneously resetting the state variables and setting configurable parameters applicable to the receiving side, equal to the default values. Duplicate detection functionality can be added. Duplicated RLC SDUs can be deleted and not transferred to the upper layers. This step may optionally be performed by upper layers.

Option 2

In accordance with option 2, you can prevent the reset of the RLC.

In particular, if the RLC PDU size of the R7 cell is larger than the fixed RLC PDU size of the R6 cell, and the WTRU moves from the R6 cell to the R7 cell, the smaller PLC PDU is preferably transmitted and activated in the R7 cell. If the RLC PDU size of the R7 cell is larger than the fixed RLC PDU size of the R6 cell, and the WTRU moves from the R7 cell to the R6 cell, all RLC PDUs from the R7 cell are preferably re-segmented into a fixed RLC PDU size. This requires RLC re-segmentation functionality. All other variables and parameters applicable to the receiving and transmitting sides of the new RLC objects are preferably set to support R6 RLC.

OPTIONS FOR CARRYING OUT

1. A method of resetting a medium access control (MAC) module, the method comprising the steps of:

- receive the advanced high speed MAC (MAC-ehs) reset message from the radio resource control module (RRC);

- flush the software buffer of hybrid automatic retransmission requests (HARQ) in the MAC module for all configured HARQ processes;

- stop the reordering disable timer and the MAC-ehs reordering timer in the reordering queue of the MAC module, while the reordering queue reorders the received MAC-ehs protocol data units (PDUs) using at least one variable;

- set timers and a variable to their initial values;

- deliver all reordering PDUs in the reordering queue to the reassembly module located in the MAC module;

- using the reassembly module, reassemble the MAC-ehs segmented Service Data Units (SDUs) and successfully reassemble the MAC-ehs SDUs into the demultiplexing module by the logical channel identifier (LCH-ID) located in the MAC module;

- through the LCH-ID demultiplexing module, the finished MAC SDUs are delivered to the correct logical channel or MAC stream;

- discard the stored MAC-ehs SDU segments from the reassembly module; and

- clear the reordering queue.

2. A wireless transmit / receive module (WTRU), comprising:

- a radio resource control (RRC) module configured to receive an RRC handover message indicating that reconfiguration between fixed and flexible sizes of radio link control protocol (RLC) protocol data units (PDUs) has occurred; and

a radio link control module (RLC), wherein the RRC module determines whether or not to send an RLC re-establishment message to the RLC module.

3. The WTRU of embodiment 2, wherein the RRC determines whether RLC re-establishment is required if the RRC handover message indicates that the RLC configuration has changed from a flexible RLC PDU size to a fixed RLC PDU size.

4. A method for reconfiguring high-speed media access control (MAC-hs) or advanced MAC-hs (MAC-ehs) in a wireless transmit / receive module (WTRU), the method comprising the steps of:

- receive a handover message according to Radio Resource Management (RRC) indicating a new MAC-hs or MAC-ehs configuration in a downlink (DL).

5. The method of embodiment 4, wherein the WTRU determines from the RRC message that the MAC reconfiguration 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 embodiments 4 and 5, wherein the MAC-hs / ehs reset indicator is set in the RRC handover message.

7. The method of embodiment 6, wherein the WTRU performs a MAC-hs or MAC-ehs reset before reconfiguring MAC-hs / ehs if a MAC-ehs or MAC-hs reset indicator is present.

8. The method of embodiment 6, wherein an undefined WTRU mode of operation occurs if a MAC-hs or MAC-ehs reset is not specified in the RRC handover message, and reconfiguration of the MAC-hs / ehs is completed.

9. A method of minimizing data loss during a handover procedure, the method comprising the steps of:

- discard service data units (SDUs) that have been successfully transmitted, the SDUs corresponding to the Radio Link Control (RLC) SDUs; and

- Store SDUs that are not discarded in the RLC transfer buffer.

10. The method of embodiment 9, further comprising the step of:

- discard all RLC PDUs in the retransmission buffer.

11. The method of embodiment 10, further comprising the steps of:

- reset the state variables associated with the transmitting side of the RLC;

- reset the hyperframe number (HFN) and

- Install a new RLC configuration.

12. A method of minimizing data loss during a handover procedure, the method comprising the steps of:

- discard service data units (SDUs) that have been successfully transmitted, the SDUs corresponding to SDUs using packet data convergence protocol (PDCP); and

- Store SDUs that are not discarded in the PDCP transmit buffer.

13. The method of embodiment 12, further comprising the step of:

- discard all radio data control unit (RLC) protocol data units (PDUs) in the retransmission buffer.

14. The method of embodiment 13, further comprising the steps of:

- reset the state variables associated with the transmitting side of the RLC;

- reset the hyperframe number (HFN) and

- Install a new RLC configuration.

15. A method of minimizing data loss during a handover procedure, the method comprising the steps of:

- discard service data units (SDUs) that are successfully transmitted until the first unsuccessfully transmitted SDU; and

- save SDUs that are not discarded in the radio link control transmission buffer (RLC), the SDUs corresponding to the RLC SDUs.

16. The method of embodiment 15, further comprising the step of:

- discard all RLC PDUs in the retransmission buffer.

17. The method of embodiment 16, further comprising the steps of:

- reset the state variables associated with the transmitting side of the RLC;

- reset the hyperframe number (HFN) and

- Install a new RLC configuration.

18. A method of minimizing data loss during a handover procedure, the method comprising the steps of:

- discard service data units (SDUs) that are successfully transmitted until the first unsuccessfully transmitted SDU; and

- save SDUs that are not discarded in the packet data convergence protocol (PDCP) transmission buffer, the SDUs corresponding to PDCP SDUs.

19. The method of embodiment 18, further comprising the step of:

- discard all RLC PDUs in the retransmission buffer.

20. The method of embodiment 19, further comprising the steps of:

- reset the state variables associated with the transmitting side of the RLC;

- reset the hyperframe number (HFN) and

- Install a new RLC configuration.

21. The method of sending a report on the status of the service data unit (SDU) when a handover is completed, the method comprising the steps of:

- confirm acceptance of successfully received SDUs and

- negatively confirm the reception of unsuccessfully received SDUs, while the SDU status report corresponds to the status report of the Radio Link Management (RLC) SDU.

22. The method of embodiment 21, further comprising the step of:

- discard SDUs, the receipt of which is confirmed in the received RLC SDU status report during the handover.

23. The method of sending a report on the state of the service data unit (SDU) when a handover is completed, the method comprising the steps of:

- confirm acceptance of successfully received SDUs and

- negatively confirm the reception of unsuccessfully received SDUs, while the SDU status report corresponds to the SDU status report using the packet data convergence protocol (PDCP).

24. The method of embodiment 23, further comprising the step of:

- discard SDUs, the receipt of which is confirmed in the received PDCP SDU status report during handover.

25. A method for retransmission of service data units (SDUs) after a handover is completed, the method comprising the step of:

- retransmit the SDUs on the new cell, wherein the SDUs correspond to the Radio Link Control (RLC) SDUs.

26. The method of embodiment 25, further comprising the step of:

- retransmit all SDUs whose receipt is not acknowledged.

27. The method of embodiment 25, further comprising the step of:

- retransmit all SDUs from the first unsuccessfully transmitted SDUs.

28. The method of embodiment 25, further comprising the step of:

- retransmit only SDUs that received a negative acknowledgment of receipt after the SDU status report has been received due to a handover.

29. The method of embodiment 25, further comprising the step of:

- retransmit SDUs that are stored in the RLC SDU transmission buffer.

30. A method for retransmission of service data units (SDUs) after a handover is completed, the method comprising the step of:

- retransmit the SDUs over the new cell, while the SDUs correspond to SDUs using the packet data convergence protocol (PDCP).

31. The method of embodiment 30, further comprising the step of:

- retransmit all SDUs whose receipt is not acknowledged.

32. The method of embodiment 30, further comprising the step of:

- retransmit all SDUs from the first unsuccessfully transmitted SDUs.

33. The method of embodiment 30, further comprising the step of:

- retransmit only SDUs that received a negative acknowledgment of receipt after the SDU status report has been received due to a handover.

34. The method of embodiment 30, further comprising the step of:

- retransmit SDUs that are stored in the PDCP SDU transmission buffer.

35. A method for processing service data units (SDUs) when a handover is complete, the method comprising the steps of:

- process all the radio data management unit (RLC) protocol data units (PDUs) that can be collected in the RLC SDU;

- send all successfully assembled RLC SDUs to the upper levels;

- discard all RLC PDUs that cannot be collected in the RLC SDU; and

- save all the extraordinary SDUs in the RLC SDU receive buffer.

36. The method of embodiment 35, further comprising the steps of:

- reset the receiver variables and hyperframe number (HFN);

- establish a new configuration of medium access control (MAC) and

- Install a new RLC configuration.

37. The method of embodiment 36, further comprising the step of:

- collect a status report of the SDU indicating successfully and unsuccessfully received SDUs, wherein the status report of the SDU corresponds to the status report of the RLC SDU.

38. A method for processing service data units (SDUs) when a handover is complete, the method comprising the steps of:

- process all the radio data management unit (RLC) protocol data units (PDUs) that can be collected in the RLC SDU;

- send all successfully assembled RLC SDUs to the upper levels;

- discard all RLC PDUs that cannot be collected in the RLC SDU; and

- Store all the extraordinary SDUs in the SDU receive buffer over the packet data convergence protocol (PDCP).

39. The method of embodiment 38, further comprising the steps of:

- reset the receiver variables and hyperframe number (HFN);

- establish a new configuration of medium access control (MAC) and

- Install a new RLC configuration.

40. The method of embodiment 39, further comprising the step of:

- collect an SDU status report indicating successfully and unsuccessfully received SDUs, wherein the SDU status report corresponds to the PDCP SDU status report.

Although features and elements are described in specific combinations, each feature or element can be used autonomously without other features and elements, or in various combinations with or without other features and elements. The provided methods or flowcharts of the method may be implemented in a computer program, software, or firmware material implemented on a computer-readable storage medium for execution by a general purpose computer or processor. Examples of computer-readable storage media include read-only memory (ROM), random access memory (RAM), a register, cache memory, semiconductor storage devices, magnetic media such as internal hard drives and removable drives, magneto-optical media and optical media such like CD-ROMs and digital versatile discs (DVDs).

Suitable processors include, for 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, and specialized integrated circuits (ASICs) ), user programmable gate array (FPGA) circuits, any other type of integrated circuit (IC) and / or state machine.

A processor associated with the software may be used to implement a radio frequency transceiver for use in a wireless transceiver module (WTRU), subscriber unit (UE), terminal, base station, radio network controller (RNC), or any host computer. The WTRU can be used together with modules implemented in hardware and / or software, such as a camera, camcorder module, videophone, speakerphone, vibration device, speaker, microphone, television transceiver, handsfree headset, keyboard, Bluetooth® module , frequency modulated (FM) radio module, liquid crystal display (LCD), organic light emitting diode (OLED) display, digital music player, multimedia player, video game device module, Intern t-browser, and / or any wireless local area network (WLAN).

Claims (7)

1. A method of resetting a medium access control (MAC) module, the method comprising the steps of:
receiving an advanced high speed MAC (MAC-ehs) reset message from a radio resource control module (RRC);
clear the hybrid automatic retransmission request (HARQ) software buffer in the MAC module for all configured HARQ processes;
stopping the reordering disable timer and the MAC-ehs reordering timer in the reordering queue of the MAC module, the reordering queue reordering the received MAC-ehs protocol data units (PDUs) using at least one variable;
set timers and a variable to their initial values;
deliver all reordering PDUs in the reordering queue to the reassembly module located in the MAC module;
using the reassembly module, reassemble the MAC-ehs segmented Service Data Units (SDUs) and deliver the successfully reassembled MAC-ehs SDUs to the logical channel identifier (LCH-ID) demultiplexing module located in the MAC module;
through the LCH-ID demultiplexing module, the finished MAC SDUs are delivered to the correct logical channel or MAC stream;
discard the stored MAC-ehs SDU segments from the reassembly module; and clear the reordering queue. 2. A wireless transmit / receive module (WTRU), comprising:
radio resource management module (RRC); and
a medium access control (MAC) module, comprising:
Hybrid Automatic Repeat reQuestion (HARQ) software buffer
reordering queue, including reordering disable timer and advanced high-speed MAC (MAC-ehs) reordering timer; reassembly module; and
the logical channel identifier demultiplexing module (LCH-ID), while the MAC module is configured to:
receive a MAC-ehs reset message from an RRC module;
Flush the HARQ software buffer for all configured HARQ processes
stop the reordering disable timer and the MAC-ehs reordering timer, wherein the reordering queue reorders the received MAC-ehs protocol data units (PDUs) using at least one variable;
set timers and a variable to their initial values;
deliver all reordering PDUs in the reordering queue to the reassembly module, while the reassembly module reassembles the MAC-ehs segmented service data units (SDUs), delivers the successfully reassembled MAC-ehs SDUs to the LCH-ID demultiplexer, which delivers the finished MAC SDU to the correct logical channel or MAC stream, discards the stored MAC-ehs SDU segments from the reassembly module; and
clear the reordering queue. 3. A method of performing reconfiguration of high-speed medium access control (MAC-hs) or advanced MAC-hs (MAC-ehs) in a wireless transmit / receive module (WTRU),
wherein the method comprises the steps in which:
receive a handover message according to Radio Resource Management (RRC) indicating a new downlink (DL) MAC-hs or MAC-ehs configuration value. 4. The method according to claim 3, in which the WTRU determines from the RRC message that the reconfiguration of the MAC occurred when the MAC changes from MAC-hs to MAC-ehs or from MAC-ehs to MAC-hs. 5. The method of claim 4, wherein the MAC-hs / ehs reset indicator is set in the RRC handover message. 6. The method of claim 5, wherein the WTRU resets the MAC-hs or MAC-ehs before reconfiguring the MAC-hs / ehs if a reset indicator of MAC-ehs or MAC-hs is present. 7. The method of claim 5, wherein the WTRU is in an undefined mode of operation if the MAC-hs or MAC-ehs are not set in the RRC handover message and the MAC-hs / ehs reconfiguration has occurred.

Images