HK1140893B - Method and apparatus for controlling a handover between utra r6 cells and r7 cells - Google Patents
Method and apparatus for controlling a handover between utra r6 cells and r7 cells Download PDFInfo
- Publication number
- HK1140893B HK1140893B HK10106995.0A HK10106995A HK1140893B HK 1140893 B HK1140893 B HK 1140893B HK 10106995 A HK10106995 A HK 10106995A HK 1140893 B HK1140893 B HK 1140893B
- Authority
- HK
- Hong Kong
- Prior art keywords
- mac
- unit
- ehs
- rlc
- reordering
- Prior art date
Links
Description
Technical Field
The present application relates to wireless communications.
Background
Some of the goals of High Speed Packet Access (HSPA) evolution include higher data rates, higher system capacity and coverage, enhanced support for packet traffic, reduced latency, reduced operational costs, and backward compatibility. Achieving these goals requires the evolution of radio interface protocols and network architectures. More specifically, achieving these goals requires a set of enhancements and structural changes to the layer 2(L2), i.e., Radio Link Control (RLC) and Medium Access Control (MAC), functionality.
Some enhancements of L2 include variable (flexible) RLC Protocol Data Unit (PDU) size, high speed MAC (MAC-hs) segmentation/concatenation, and multiplexing. In Universal Terrestrial Radio Access (UTRA) release 6(R6), the Acknowledged Mode (AM) RLC entity can only use a fixed RLC PDU size. In addition, the MAC-hs sublayer in the node B can only support concatenation of MAC-d PDUs. The L2 enhancement of UTRA release 7(R7) causes a large RLC/MAC change to R6 characteristics.
Changes to the enhanced MAC-hs (MAC-ehs) structure at the UTRAN side include the addition of logical channel identifier (LCH-ID) Multiplexing (MUX) entities. The LCH-ID MUX entity multiplexes logical channels into priority queues. The MAC-ehs structure further includes a priority queue segmentation function and multiplexes MAC-ehs payload units from different priority queues into MAC-ehs PDUs.
Changes to the MAC-ehs structure at the wireless transmit/receive unit (WTRU) side include decomposition of MAC-ehs payload units from MAC-ehs PDUs. Further, after reordering, the MAC-ehs payload unit is forwarded to the LCH-ID demultiplexing entity. The LCH-ID demultiplexing entity routes the MAC-ehs payload units to the correct reassembly entity based on the logical channel identifier. The MAC-ehs structure at the WTRU further includes a reassembly entity that reassembles segmented MAC-ehs Service Data Units (SDUs) and forwards all MAC-ehs SDUs to higher layers.
Currently, when a radio bearer is established or reconfigured via Radio Resource Control (RRC) signaling, there is an Information Element (IE) "Radio Bearer (RB) mapping information". The "RB mapping information" contains information on RLC instances and transport channels corresponding to Radio Bearers (RBs).
A new Information Element (IE) may be added to the IE "RB mapping information" indicating whether the logical channel of the RLC instance supports flexible RLC PDUs or whether the MAC sublayer supports MAC-hs or MAC-ehs. For the purposes of the present invention, we refer to these IEs as "Downlink (DL) RLC configuration" and "DL MAC-hs configuration". The MAC-HS configuration on all RBs mapped to the high speed downlink shared channel (HS-DSCH) needs to be the same or else results in an invalid configuration.
In HSPA, the high speed shared channel is monitored by the WTRU in an individual cell, i.e., the serving high speed downlink shared channel (HS-DSCH) cell. Due to mobility, when a WTRU moves from one cell to another, the WTRU needs to perform a serving cell change by switching to a new serving HS-DSCH cell and terminating communication with the old serving HS-DSCH cell. During node B relocation, an inter-node B handover occurs from an old node B (i.e., a source node B) to a new node B (i.e., a destination node B).
When the serving node B changes, the target node B needs to start sending data on the new configuration. The handover may occur within an evolved HSPA node B supporting L2 enhancements or to/from a cell with or without L2 enhancements. For both cases, the WTRU must be able to perform a handover in accordance with the new configuration and minimize data loss.
In conventional systems (i.e., R6 systems), a Radio Resource Control (RRC) message may carry a MAC layer reset indicator when a handover occurs. In particular, when inter-node-B or intra-node-B handover occurs, data in the MAC-hs in the source node-B is deleted and the MAC-hs in the WTRU needs to be reset. Upon receiving the reset indicator, the WTRU performs a series of functions including:
1) clearing a hybrid automatic repeat request (HARQ) soft buffer for all configured HARQ processes;
2) stop all active reorder release timers (T1) and set all timers T1 to their initial values;
3) starting a Transmission Sequence Number (TSN) with a value of 0 for a next transmission of each configured HARQ process;
4) initializing variables RcvWindow _ UpperEdge and next _ expected _ TSN to their initial values;
5) decomposing all MAC-hs PDUs in the reordering buffer and delivering all MAC-d PDUs to the MAC-d entity; and
6) the reorder buffer is emptied.
When a new L2 enhancement is introduced, new procedures need to be defined to optimize and minimize data loss during handovers between R7 cells, or between R7 and R6 cells. In particular, the process of handling the reset MAC-hs entity needs to be modified to support the new L2 enhancements.
Additionally, it cannot be assumed that all R6 node Bs will be upgraded at the same time as the R7 node Bs. Therefore, handovers between R6 and R7 cells may occur frequently. Due to the changed functionality of RLC and MAC, a method must be defined to perform handover between these cells with minimal loss of quality and data. In particular, on the WTRU side, the MAC-hs and RLC must perform a functionality change during handover.
Disclosure of Invention
A method and apparatus for controlling handover procedure optimization between UTRA R6 (i.e., lower layer) cells and UTRA R7 (i.e., higher layer) cells is disclosed. When a WTRU moves between an R6 cell and an R7 cell, or between R7 cells, a handover is initiated from a source node-B to a destination node-B. In the R7 cell, enhanced MAC functions include flexible RLC PDU sizes and MAC-hs segmentation, and multiplexing of different priority queues in the WTRU is supported. The changes that occur in a WTRU result from the fact that the WTRU moves between R6 and R7 cells. When a WTRU moves between such cells, the network must reconfigure the WTRU with the new configuration. After handover, the MAC layer and/or RLC layer are reconfigured or reset based on the functions supported by the target node B.
Drawings
The invention may be understood in more detail from the following description taken in conjunction with the accompanying drawings, in which:
figure 1A is an example block diagram of a WTRU moving between R6 and R7 cells configured to operate with new RLC and MAC-hs sublayers when a handover message is received during a serving cell change procedure;
figure 1B is a detailed diagram of a MAC unit in the WTRU of figure 1A; and
fig. 2 is a flow diagram of a WTRU handover procedure implemented in the WTRU of fig. 1A.
Detailed Description
The term wireless transmit/receive unit (WTRU) as referred to below includes, but is not limited to, a User Equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cell phone, a Personal Digital Assistant (PDA), a computer, or any other type of user equipment capable of operating in a wireless environment. The term "node B" as referred to below includes, but is not limited to, a base station, a site controller, an Access Point (AP), or any other type of interfacing device capable of operating in a wireless environment.
Hereinafter, the R7 cell includes a node B and an RNC having improved L2 characteristics. Throughout this disclosure, the R7 cell may refer to a higher version of the improved L2. Hereinafter, the R6 cell includes a node B and an RNC that do not support the improved L2 characteristic. This may include R7 node B without L2 characteristics and any previous third generation partnership project (3GPP) releases. R7MAC-hs in the present invention refers to enhanced MAC-hs (i.e., MAC-ehs).
The term RLC reset also refers to RLC re-establishment. These terms may be used interchangeably.
The following terms are used throughout the specification and are simply defined. The MAC-ehs payload unit is a MAC-ehs SDU or a MAC-ehs SDU segment contained in a MAC-ehs PDU. A MAC-ehs reordering PDU is a set of MAC-ehs payload units in MAC-ehs PDUs belonging to the same priority queue. The enhanced cell is a cell supporting L2 enhancement. A non-enhanced cell is a cell that does not support L2 enhancement.
Changes to the MAC-hs or MAC-ehs reset procedure, the MAC-hs or MAC-ehs reconfiguration procedure and the RLC re-establishment evaluation procedure are disclosed.
Disclosed herein are a method and apparatus for optimization of a handover scenario, a reset procedure of MAC-hs and RLC entities for supporting handover between R7 cells, and between R6 and R7 cells. It should be understood that the R6 cell or R6 node B refers to cells and node bs that do not support improved L2 characteristics, such as MAC segmentation and flexible RLC PDU size. The disclosed methods and apparatus are applicable to Uplink (UL) and Downlink (DL) links, as well as other wireless technologies such as Long Term Evolution (LTE) and other flat-architecture systems such as R8 Wideband Code Division Multiple Access (WCDMA).
Fig. 1A is an example block diagram of a WTRU 100 that moves between R6 and R7 cells and is configured to operate with new RLC and MAC-hs sublayers when a handover message is received during a serving cell change procedure. As shown in fig. 1A, the WTRU 100 includes an RRC unit 105, an RLC unit 10, a MAC unit 115, and a Physical (PHY) layer 1 unit 120. The serving cell change may occur via a radio bearer reconfiguration RRC message, a transport channel reconfiguration RRC message, or a physical channel reconfiguration RRC message.
The WTRU 100 operates in a wireless communication system that includes a destination node B, a source node B, a controlling rnc (crnc), and a source rnc (srnc) (not shown). The SRNC may include an RLC unit and an RRC unit (not shown).
intra-R7 cell handover
In the R7 structure, the MAC-hs includes new functionality including MAC-hs segmentation and multiplexing of different priority queues in the node B. The RLC functions are retained in the Radio Network Controller (RNC) and support variable PDU sizes. The R7MAC-hs header is significantly different from the R6MAC-hs header. In LTE and other WCDMA flat architecture systems, the RLC functions are in the node B. In the UL, the RLC functions are located in the WTRU.
When a handover occurs, the MAC-hs entity in the source node-B is deleted and a new MAC-hs entity is set up in the target node-B. The maximum rlc pdu size may be adjusted for the target node B when a new configuration occurs. This is accomplished by one or a combination of the following methods: 1) allocating a default value for the initial RLC PDU size; 2) keeping the existing RLC PDU size; or 3) setting a new RLC PDU size based on the channel condition of the target node B. This applies to the case where the node B signals the maximum RLC PDU size to the RLC entity in the RNC. The Channel Quality Indicator (CQI) sent to the target node B during handover may provide a good estimate of the channel conditions. The target node B may in turn 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 method may be used to provide feedback information to the target node B during the serving HS-DSCH cell change.
When a new MAC-hs is established in the target node-B, the WTRU-side MAC-hs is preferably synchronized with the target MAC-hs. Therefore, the WTRU preferably also resets the MAC-hs entity in the WTRU.
Due to the functional change of the MAC-hs sublayer, the R6 reset procedure is modified to support the fact that after receiving HARQ, the MAC-hs PDU disassembly function is used before reordering. After reordering, a reassembly function is added to the existing disassembly function.
The conventional R6MAC-hs reset procedure is modified by disassembling all MAC-hs PDUs in the reordering buffer, reassembling segmented packets that can be successfully reassembled into MAC-hs Service Data Units (SDUs), passing all complete MAC-hs SDUs to higher layers, and discarding part of the received MAC-hs SDUs.
In particular, due to the change of the structure, it is proposed to update the MAC-ehs reset procedure. At a given activation time or at an indicated time, the WTRU must process MAC-ehs reordering PDUs waiting in a reordering buffer. All MAC-ehs reordering PDUs must be decomposed or demultiplexed into MAC-ehs payload units. The MAC-ehs payload unit is then passed to the reassembly unit. After the reassembly unit processes all MAC-ehs payload units and reassembles the segmented MAC-ehs payload units into MAC-ehs SDUs that can be reassembled, the reassembly unit must ensure that all stored remaining MAC-hs SDU segments are deleted from the reassembly unit. Finally, the complete PDU is passed to higher layers in the corresponding logical channel or MAC-d/c flow.
For example, the MAC-ehs reset procedure may take the form of a MAC-ehs structure as follows. If the upper layer requests a reset of the MAC unit 115, at the activation time indicated by the higher layer, the WTRU 100 will:
a) for all configured HARQ processes, emptying the HARQ soft buffer;
b) stopping all active reorder release timers (T1) and setting all timers T1 to their initial values;
c) for the next transmission on each configured HARQ process (and each priority queue), the TSN starts with a value of 0;
d) initializing variables RcvWindow _ UpperEdge and next _ expected _ TSN to their initial values;
e) passing all reordering PDUs in the reordering queue to the LCH-ID demultiplexing unit and/or demultiplexing MAC-ehs payload unit and routing them to the correct reassembly unit based on the logical channel identifier;
f) performing reassembly of the segmented MAC-ehs SDUs and delivering complete MAC-ehs SDUs (MAC PDUs) to higher layers;
g) discarding all stored reordering PDUs (or MAC-hs SDU segments) from the reassembly unit;
h) emptying the reordering queue; and
i) if a MAC-HS reset is initiated due to the receipt of the IE "MAC-HS reset indicator" by the upper layer, optionally all Acknowledged Mode (AM) RLC entities mapped on the HS-DSCH are instructed to generate a status report.
Different MAC-ehs structures may exist where the reordering function is followed by an SDU disassembly function, a reassembly entity, and finally an LCH-ID demultiplexing entity. The disassembly function may be part of the reassembly entity, in which case only the reassembly entity is present in the MAC-ehs structure. For example, the MAC-ehs reset procedure may take the following form for such a MAC-ehs structure.
Fig. 1B is a detailed diagram of the MAC unit 115 in the WTRU 100 of fig. 1A. As shown in fig. 1B, the MAC unit 115 includes a plurality of LCH-ID demultiplexing units 130A and 130B, reassembly units 135A and 135B, reordering queues 140A and 140B, a reordering queue allocation unit 145, a disassembly unit 150, and an HARQ unit 155. The reordering queues 140A and 140B are used to perform reordering of received MAC-ehs PDUs so that reassembly can be performed and data can be delivered to higher layers in order. The HARQ unit 155 includes at least one HARQ soft buffer (not shown).
Referring to fig. 1B, if the upper layer requests the MAC-ehs entity to be reset, at the activation time indicated by the higher layer, the WTRU 100 will:
a) for all configured HARQ processes, emptying the HARQ soft buffer in the HARQ unit 155;
b) stopping all active reorder release timers (T1) and setting all timers T1 to their initial values;
c) for the next transmission on each configured HARQ process (and each priority queue), the TSN starts with a value of 0;
d) initializing variables RcvWindow _ UpperEdge and next _ expected _ TSN to their initial values;
e) all reordering PDUs in the reordering queues 140A and 140B are passed to the parsing unit 150, and/or;
f) the decomposition unit 150 decomposes all reordering PDUs into MAC-hs SDUs or MAC-hs SDU segments and passes them to the reassembly units 135A and 135B, or;
g) if only reassembly unit 135 is present, data from the reorder queue is passed to reassembly unit 135. Reassembly units 135A and 135B perform reassembly of the fragmented MAC-ehs SDUs and deliver the complete MAC-ehs SDUs to LCH-ID demultiplexing units 130A and 130B, each demultiplexing unit delivering the complete SDUs to the correct logical channel or MAC-d/c stream;
h) discarding all stored reordering PDUs (or MAC-hs SDU segments) from reassembly units 135A and 135B; and
i) the reordered pairs 140A and 140B are cleared.
Alternatively, in the case of intra-node B handover, (i.e., handover between zones of the same node B), the MAC-hs reset procedure described above may 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
The L2 enhanced cell (i.e., R7 cell) supports flexible RLC PDU sizes, while the non-enhanced cell (i.e., R6 cell) has a fixed RLC PDU size. This means that when a handover to and from an R7 cell occurs, the affected RLC entities in the RNC and WTRU need to be reconfigured to the old RLC entity. In addition, the MAC-hs sublayer needs to be reconfigured to decode the correct header format and support new or old functions.
If the RLC entity needs to be re-established, a significant data loss can occur. It is therefore desirable to minimize such data loss.
Event sequence for switching programs
Fig. 2 is a flow diagram of a WTRU handover procedure 200 implemented in the WTRU 100 of fig. 1. In step 205, the RRC unit 105 in the WTRU 100 receives an RRC handover command to initiate a handover procedure. In step 210, the RRC unit 105 instructs the Physical (PHY) layer 1(L1) unit 120 to set up a new radio link indicated in the RRC handover command. This sequence of events up to the MAC-hs reset step is similar to a conventional procedure.
In step 215, the RRC unit 105 sends a MAC-hs reset and/or MAC-hs reconfiguration request to the MAC unit 115 in the WTRU 100 as needed. If a MAC-hs reconfiguration is requested, the MAC-hs reconfiguration is performed as explained in detail below. The MAC-hs reset indicator parameter of the RRC unit 105 for the MAC primitive (private) may optionally be extended to indicate MAC-hs reconfiguration.
Once MAC unit 115 performs a MAC-hs reset and/or MAC-hs reconfiguration (step 220) and reordering queues 140A and 140B in MAC unit 115 are emptied (step 225), an RLC status request message may be sent from MAC unit 115 to RLC unit 110 (step 230). In step 235, after each RLC PDU has been processed by the RLC unit 110, the RLC unit 110 then generates a status report for all Acknowledged Mode (AM) RLC instances mapped to the HS-DSCH. Optionally, no RLC status request message is sent to the RLC unit 110.
If RLC reset is requested, the RRC unit 105 transmits a re-establishment request message (i.e., an RLC reset message) to the RLC unit 110 (step 240). Then, as a result of this request, a partial or full RLC reset is performed as described in detail below. For the RLC reset indication, the following options are possible:
1) no RLC indication is sent to the RLC unit 110;
2) an all reset indication is sent to the RLC unit 110; or
3) A partial reset indication is sent to the RLC unit 110.
The RLC reset/reconfiguration indication may be signaled by the control RLC (crlc) -Config-Req primitive or explicitly signaled by MAC-hs with the last forwarded MAC SDU. Alternatively, the RLC reset/reconfiguration indication may be signaled by the MAC-hs in STATUS-Report-Req. RLC processing of all emptied SDUs is preferably performed prior to status reporting or RLC reset.
If a non-synchronous handover is performed, step 220 and step 230 are performed upon receiving the RRC message. If a synchronous handover is performed, step 220 is performed at a given activation time, step 230.
Method for transmitting signal to WTRU
Once the RRC in the RNC decides to perform a serving node B change, the RNC must inform the WTRU that a reset/reconfiguration to the MAC-hs sub-layer or the receiving RLC entity is required, if applicable. Preferably, one or a combination of the following options is performed:
the RNC sends an RRC handover message that explicitly indicates one or a combination of the following information:
1a) MAC-hs resets or reconfigures. Additional bits (i.e., MAC-hs reconfiguration indicator) are added to the RRC message indicating R6 or R7MAC-hs operation after handover.
1b) An RLC reset indicator to specify a partial or full reset.
1c) Two bits to indicate one of:
i) MAC-hs resetting;
ii) a MAC-hs reconfiguration;
iii) RLC reset; or
iv) no action is required.
1d) An additional field indicating that a cell change from R6 to R7 or vice versa occurs; or
1e) No additional information is added to the RRC handover message except for the conventional MAC-hs reset indicator.
Preferably, the WTRU decides what action must be taken based on one or a combination of the following options:
2a) if the MAC-hs reconfiguration or RLC reset is explicitly signaled, (i.e., signaling 1a, 1b, or 1c above), the WTRU performs the indicated tasks in the order described above.
2b) If only the MAC-hs reset is set to TRUE and no additional information bits are added to the RRC handover message, (i.e., 1e is signaled), the WTRU makes a decision based on the system information from the source and the target cell from the RRC message. In particular, the WTRU implicitly reads/acquires information about the supported characteristics of the source and destination cells.
i) If the WTRU detects that a change from R6 to R7 or from R7 to R6 has occurred, the WTRU concludes that a MAC-hs reconfiguration must be performed. Additionally, the WTRU may also infer whether an RLC reset or re-establishment is required. The WTRU may infer the occurrence of a change from R6 to R7 or vice versa, i.e., whether MAC-ehs or MAC-hs is configured, and whether the new RLC entity supports a flexible or fixed RLC pdu, via information provided in the IE "RB mapping information" in the RRC handover message. The WTRU compares the new configuration with the existing configuration and infers whether a change has occurred.
ii) when a change from R6 to R7 occurs, an RLC reset is not necessary. This information may be configured by higher layers. Higher layers may indicate that no RLC reset or full/partial RLC reset is needed between certain releases.
2c) If only the MAC-hs reconfiguration indicator is added to the RRC message, (i.e., signaling 1a above), the WTRU may conclude that an RLC reset is also needed.
2d) Alternatively, if only an RLC reset indicator is added to the RRC message, (i.e., signaling 1b above), the WTRU concludes that a 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 releases, (i.e., 1d above is signaled), the WTRU determines whether a MAC-hs reconfiguration is required and/or whether a partial or full RLC reset is required.
Method for performing MAC-hs reconfiguration
The MAC-hs reconfiguration performs a MAC-hs function change from the old MAC-hs to the new MAC-hs. In particular, if the WTRU moves between R6 and R7 cells, the header format and function of the MAC-hs is changed. Therefore, a method of performing the change is needed.
Initially, a MAC-hs reset procedure is performed. Once the buffer is emptied, the variable is reset, and a successful MAC-hs SDU is delivered to higher layers, the MAC layer reconfigures its functionality.
If a change from R6 to R7 occurs, the following sequence of events occurs:
1) a MAC-hs reset is performed.
2) Following the HARQ reset procedure, the MAC layer is configured to support the MAC-ehs header format.
3) The demultiplexing function of the priority queue is added before the reordering queue. Alternatively, since there is only one reordering queue per MAC-hs PDU in the R6 cell, the de-multiplexing function may be present all the time when MAC-hs is set up (assuming that the WTRU supports R7).
4) Reassembly (and demultiplexing of logical channels) functionality is added to the existing disassembly functional blocks in each reordering queue. Alternatively, since no entry in the reordering queue will have a segment identifier in the R6 cell, the reassembly function may always exist when the MAC-hs is set up (assuming the WTRU supports R7).
If a change from R7 to R6 occurs, the following sequence of events occurs:
1) a MAC-ehs reset is performed as defined for UTRAR7 cell.
2) Following the HARQ reset procedure, the MAC-hs is configured to support the R6 header format.
3) The demultiplexing function of the priority queue is removed. Alternatively, since there is only one reordering queue per MAC-hs PDU in the R6 cell, the de-multiplexing function is maintained in the MAC-hs.
4) The recombination function is removed. Alternatively, since no entry in the reordering queue would have a segment identifier in cell R6, the reassembly remains inactive in MAC-hs.
MAC-hs reconfiguration procedure
For all radio bearers, a separate MAC-ehs or MAC-hs instance for each WTRU should be configured. Thus, the MAC-hs is configured to support enhanced configurations in cells supporting release 7 or higher, and normal configurations in cells supporting release 6 or lower.
The WTRU may change its MAC-hs configuration from an enhanced configuration to a normal configuration, or vice versa, if commanded by higher layers. This may occur, for example, during a handover scenario. The following describes procedures involving MAC-hs reconfiguration between MAC-hs and MAC-ehs.
The reconfiguration procedure relies on information provided to the WTRU via an RRC message that contains an IE for MAC-hs or MAC-ehs, or its equivalent IE included in the "RB mapping information" IE, and that is present when an RB is set up or reconfigured.
The reconfiguration procedure may take place: in the description of the normal action after receiving the "RB mapping information" IE; in a new definition of actions involving the reception of the "DL MAC-hs configuration" IE or its equivalent; or another existing action involving another configuration of the MAC.
The procedure corresponding to the reception of this IE may be defined as follows:
a) if the "DL MAC-hs configuration" is set to the "enhanced" value and the previously stored value is set to the "normal" (i.e., if the configuration is changed from normal to enhanced);
1) resetting the MAC-hs entity; and
2) MAC-hs or MAC-ehs is configured according to the IE "DL MAC-hs configuration".
b) Otherwise, if the "DL MAC-hs configuration" is set to the "normal" value and the previously stored value is set to "enhanced" (i.e., if the configuration is changed from enhanced to normal);
1) resetting the MAC-ehs entity; and
2) MAC-hs or MAC-ehs is configured according to the IE "DL MAC-hs configuration".
In an alternative embodiment, if the MAC-hs reconfiguration is performed at handover, the existing MAC-hs reset indication may be used simultaneously to change the configuration. However, this 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 a MAC-hs reconfiguration occurs and the MAC-hs reset indicator is not set, the WTRU behavior may be unspecified or the MAC performs the reset independently.
Alternatively, MAC reconfiguration from normal to enhanced or vice versa may be specified in the MAC (3GPP 25.321) specification. The steps may be specified as part of an existing MAC-hs or MAC-ehs procedure. In particular, when a MAC-hs or MAC-ehs reset is requested by an upper layer due to reconfiguration from normal to enhanced MAC-hs or vice versa, the following will/can be clarified in the MAC-hs and/or MAC-ehs reset procedure. If a reconfiguration occurs, (or alternatively it can apply to all cases), all emptied reordering PDUs or MAC-hs PDUs have to be processed using the old configuration that existed before the reset indication.
Alternatively, the reconfiguration procedure may be described in a new section of the MAC specification (3GPP 25.321) or as part of the MAC-hs/MAC-ehs parameter reconfiguration procedure. This method is particularly relevant for reconfiguration from MAC-hs to MAC-ehs or vice versa, ordered by higher layers. In particular, the following cases can be explained and specified:
the MAC-hs/ehs entity can be reconfigured (modified) by upper layers from normal to enhanced or vice versa.
When the MAC-hs/ehs entity is reconfigured by the upper layers, the WTRU will reset the MAC-hs/ehs entity (all packets in the reordering queue must be processed using the old configuration before reconfiguration).
To replace this procedure, the reset may be replaced by removing all reordering PDUs or MAC-hs PDUs from the reordering queue and passing them to the output entity, which is an entity above the reordering entity (e.g. for MAC-hs it may be a decomposition entity and for MAC-ehs it may be an LCH-ID demultiplexing entity or a reassembly entity). Note that due to the explicit MAC-hs reset indicator in the handover command, a reset procedure may also be performed after reconfiguration. Then, at the activation time indicated by the higher layers, the use of a new MAC-hs or MAC-ehs configuration is started.
Method of performing RLC reset during handover
a) Handover from R6 cell to R7 without full RLC reset
When switching from the R6 cell to R7, a full reset may not be performed since the new RLC will be configured to support a variable PDU size. This is called a partial reset. If the RLC header does not have any significant changes, it is preferable to consider the existing fixed RLC PDU as a flexible PDU in the new RLC. Therefore, preferably, the RLC entity maintains the existing sequence number and the corresponding RLC PDU. Preferably, however, certain variables are reinitialized or changed to support the new RLC entity. Preferably, these variables include, but are not limited to, a timer or combination of timers, variables relating to maintenance of receive and transmit windows, criteria for status reporting, and other status variables that may be used for R7.
If a reset is required, a method similar to the following can be performed.
b) When RLC reset is required, handover is made from the R7 cell to R6.
The serving cell change from the R7 cell to the R6 cell may require an RLC reset because the R6 RLC is not configured in relation to the flexible RLC PDU size. 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 implemented. In addition, in other systems that include RLC functionality in the node B, such as in LTE or in planar R8 WCDMA, the RLC entity in the WTRU needs to be reset or re-established when an inter-node B handover occurs, and data loss needs to be minimized. The options described below are also applicable to such systems.
Option 1
The transmitting side resets the state variables designated for the sender. The transmitting side sets configurable parameters of the transmitting side that can be used for the new RLC entity. The transmitting side resets the Hyper Frame Number (HFN). The transmitting side discards SDUs that have been successfully transmitted to the receiver of each AM RLC entity (i.e., all RLC pdus corresponding to SDUs that have been acknowledged and, alternatively, notified to higher layers that these SDUs have been successfully transmitted).
Alternatively, the transmitting side may discard all SDUs that have been successfully transmitted until the first unsuccessful SDU. All SDUs with one or more unacknowledged RLC PDUs are stored in a transmit buffer, which may be located in the RLC entity or in higher layers, such as in the Packet Data Convergence Protocol (PDCP). The transmitting side discards all RLC PDUs and all control PDUs in the transmitting side. Once the reset procedure is completed, the RLC SDUs that are not discarded may be sent via the target node B with the new RLC configuration in the target node B.
This approach minimizes data loss and unsuccessful SDUs are retransmitted. Since the transmitting side does not receive the final status PDU from the receiving side, the transmitting side does not have status information updated at any time. This may result in repeated transmission of rlc sdus. Therefore, a duplicate detection function may be added on the receiving side.
Alternatively, a method may be performed to obtain final state information from the receiving side before resetting the RLC. After resetting and/or reconfiguring the MAC-HS, the receiving side triggers a status report for all AM RLC mapped to the HS-DSCH. The status report is based on RLC PDUs. However, the transmitting side must wait to receive the RLC PDU status before resetting the RLC. This delays the handover procedure.
Alternatively, the receiving side may transmit the RLC SDU status to the transmitting side. The transmitting side then discards all other RLC SDUs that have been successfully received. This may minimize duplicate transmissions. However, a method of identifying RLC SDUs (counting of RLC SDUs) is required. Alternatively, the RLC layer may be replaced by a Packet Data Convergence Protocol (PDCP) layer to perform this function. If the PDCP handles the data recovery procedure, the equivalent of the RLC SDU is the PDCP SDU. As described above, the transmitting side will retransmit SDUs that are not successfully received using a status report, which may be at either the RLC or PDCP level, and discard SDUs that are successfully received as indicated by the status report.
On the receiving side, after the MAC has been reset and all successfully received packets including all packets in the reordering queue are delivered to the RLC, the following steps may be performed. The receiving side processes all RLC PDUs. Alternatively, if RLC status reporting is used to minimize data loss, the receiving side generates an RLC status report for each RLC AM instance. The receiving side transmits RLC PDUs, which can be successfully combined into RLC SDUs, to a higher layer. The receiving side discards RLC PDUs which cannot be combined into RLC sdus. Alternatively, if in-order delivery is supported, the RLC SDUs that are not in-order are saved at the receiving side, since the missing SDUs will be retransmitted from the target node B. Optionally, this function may be performed at the PDCP layer. In particular, if the function is performed in the PDCP, the procedure described above may be replaced by the PDCP sdus. More particularly, the PDCP may store PDCP SDUs that are not in sequence until the missing SDUs are retransmitted from the target node B. The RLC layer may then be reconfigured to a new RLC configuration while resetting the state variables and setting the configurable parameters available to the receiving side to default values. Duplicate detection functionality may be added. Duplicate RLC SDUs may be deleted and not sent to higher layers. This step may optionally be performed by a higher layer.
Option 2
According to option 2, RLC reset may be avoided. In particular, if the RLC PDU size from 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, RLC PDUs with a smaller size are preferably transmitted and allowed in the R7 cell. If the RLC PDU size from 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, preferably, all RLC PDUs from the R7 cell are re-segmented into fixed size RLC PDUs. This requires RLC re-segmentation functionality. Preferably, all other variables and parameters available to the receiving and transmitting sides of the new RLC entity are set to support R6 RLC.
Examples
1. A method of resetting a Medium Access Control (MAC) unit, the method comprising:
receiving an enhanced high speed MAC (MAC-ehs) reset message from a Radio Resource Control (RRC) unit;
flushing a hybrid automatic repeat request (HARQ) soft buffer for all configured HARQ processes in the MAC unit;
stopping a reordering release timer and a MAC-ehs reordering timer located in a reordering queue of the MAC unit, wherein the reordering queue uses at least one variable to perform reordering of received MAC-ehs Protocol Data Units (PDUs);
setting the timer and the variable to their respective initial values;
passing all reordering PDUs in the reordering queue to a reassembly unit located in the MAC unit;
the reassembly unit performs reassembly of segmented MAC-ehs Service Data Units (SDUs) and delivers successfully reassembled MAC-ehs SDUs to a logical channel identifier (LCH-ID) demultiplexing unit located in the MAC unit;
the LCH-ID demultiplexing unit transmits the complete MAC SDU to a correct logic channel or MAC stream;
discarding stored MAC-ehs SDU segments from the reassembly unit; and
emptying the reordering queue.
2. A wireless transmit/receive unit (WTRU), comprising:
a Radio Resource Control (RRC) unit configured to receive an RRC handover message indicating that a reconfiguration has occurred between fixed and variable Radio Link Control (RLC) Protocol Data Unit (PDU) sizes; and
a Radio Link Control (RLC) unit, wherein the RRC unit determines whether to send an RLC re-establishment message to the RLC unit.
3. The WTRU of embodiment 2 wherein if the RRC handover message indicates that the RLC configuration is changed from a flexible RLC PDU size to a fixed RLC PDU size, the RRC determines whether an RLC re-establishment is required.
4. A method of performing high speed medium access control (MAC-hs) or enhanced MAC-hs (MAC-ehs) reconfiguration in a wireless transmit/receive unit (WTRU), the method comprising:
a Radio Resource Control (RRC) handover message indicating a new Downlink (DL) MAC-hs or MAC-ehs configuration value is received.
5. The method of embodiment 4 wherein the WTRU determines from the RRC message that a MAC reconfiguration occurred when the MAC changes from MAC-hs to MAC-ehs or from MAC-ehs to MAC-hs.
6. The method of any of embodiments 4 and 5 wherein a 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 prior to the MAC-hs/ehs reconfiguration if the MAC-ehs or MAC-hs reset indicator is present.
8. The method of embodiment 6 wherein unspecified behavior of the WTRU occurs if the MAC-hs or MAC-ehs reset is not set in the RRC handover message and a MAC-hs/ehs reconfiguration occurs.
9. A method of minimizing data loss during a handover procedure, the method comprising:
discarding a Service Data Unit (SDU) that has been successfully transmitted, wherein the SDU corresponds to a Radio Link Control (RLC) SDU; and
the SDUs that are not discarded are stored in the RLC transmission buffer.
10. The method of embodiment 9, further comprising:
all RLC PDUs in the retransmission buffer are discarded.
11. The method of embodiment 10, further comprising:
resetting a state variable related to a transmitting RLC side;
resetting a Hyper Frame Number (HFN); and
a new RLC configuration is set.
12. A method of minimizing data loss during a handover procedure, the method comprising:
discarding Service Data Units (SDUs) that have been successfully transferred, wherein the SDUs correspond to Packet Data Convergence Protocol (PDCP) SDUs; and
the SDUs that are not discarded are stored in the PDCP transport buffer.
13. The method of embodiment 12, further comprising:
all Radio Link Control (RLC) Protocol Data Units (PDUs) in the retransmission buffer are discarded.
14. The method of embodiment 13, further comprising:
resetting a state variable related to a transmitting RLC side;
resetting a Hyper Frame Number (HFN); and
a new RLC configuration is set.
15. A method of minimizing data loss during a handover procedure, the method comprising:
discarding Service Data Units (SDUs) that have been successfully transmitted until a first unsuccessfully transmitted SDU; and
storing the non-discarded SDUs in a Radio Link Control (RLC) transmission buffer, wherein the SDUs correspond to RLC SDUs.
16. The method of embodiment 15, further comprising:
all RLC PDUs in the retransmission buffer are discarded.
17. The method of embodiment 16, further comprising:
resetting a state variable related to a transmitting RLC side;
resetting a Hyper Frame Number (HFN); and
a new RLC configuration is set.
18. A method of minimizing data loss during a handover procedure, the method comprising:
discarding Service Data Units (SDUs) that have been successfully transmitted until a first unsuccessfully transmitted SDU; and
storing the non-discarded SDUs in a Packet Data Convergence Protocol (PDCP) transmit buffer, wherein the SDUs correspond to PDCP SDUs.
19. The method of embodiment 18, further comprising:
all RLC PDUs in the retransmission buffer are discarded.
20. The method of embodiment 19, further comprising:
resetting a state variable related to a transmitting RLC side;
resetting a Hyper Frame Number (HFN); and
a new RLC configuration is set.
21. A method of transmitting a Service Data Unit (SDU) status report when a handover occurs, the method comprising:
responding to the successfully received SDU; and
negative acknowledgement for the unsuccessfully received SDU, wherein the SDU status report corresponds to a Radio Link Control (RLC) SDU status report.
22. The method of embodiment 21, further comprising:
SDUs acknowledged in the received RLC SDU status report are discarded during handover.
23. A method of transmitting a Service Data Unit (SDU) status report when a handover occurs, the method comprising:
responding to the successfully received SDU; and
negatively acknowledging unsuccessfully received SDUs, wherein the SDU status report corresponds to a Packet Data Convergence Protocol (PDCP) SDU status report.
24. The method of embodiment 23, further comprising:
the SDUs acknowledged in the received PDCP SDU status report are discarded during handover.
25. A method of retransmitting a Service Data Unit (SDU) after a handover occurs, the method comprising:
retransmitting SDUs on the new cell, wherein the SDUs correspond to Radio Link Control (RLC) SDUs.
26. The method of embodiment 25, further comprising:
all SDUs not acknowledged are retransmitted.
27. The method of embodiment 25, further comprising:
all SDUs are retransmitted starting from the first unsuccessfully transmitted SDU.
28. The method of embodiment 25, further comprising:
only SDUs that have been negatively acknowledged after receiving an SDU status report due to handover are retransmitted.
29. The method of embodiment 25, further comprising:
the SDUs that have been stored in the RLC SDU transmission buffer are retransmitted.
30. A method of retransmitting a Service Data Unit (SDU) after a handover occurs, the method comprising:
retransmitting SDUs on the new cell, wherein the SDUs correspond to Packet Data Convergence Protocol (PDCP) SDUs.
31. The method of embodiment 30, further comprising:
all SDUs not acknowledged are retransmitted.
32. The method of embodiment 30, comprising:
all SDUs are retransmitted starting from the first unsuccessfully transmitted SDU.
33. The method of embodiment 30, comprising:
only SDUs that have been negatively acknowledged after receiving an SDU status report due to handover are retransmitted.
34. The method of embodiment 30, further comprising:
the SDUs that have been stored in the PDCP SDU transfer buffer are retransmitted.
35. A method of processing Service Data Units (SDUs) when a handover occurs, the method comprising:
processing all Radio Link Control (RLC) Protocol Data Units (PDUs) that can be combined into an RLC SDU;
sending all successfully combined RLC SDUs to an upper layer;
discarding all RLC PDUs that cannot be combined into RLC SDUs; and
all out-of-order SDUs are stored in the RLC SDU reception buffer.
36. The method of embodiment 35, further comprising:
resetting receiver variables and Hyper Frame Numbers (HFNs);
setting a new Media Access Control (MAC) configuration; and
a new RLC configuration is set.
37. The method of embodiment 36, comprising:
SDU status reports indicating SDUs that were successfully received and not successfully received are combined, wherein the SDU status reports correspond to RLC SDU status reports.
38. A method of processing Service Data Units (SDUs) when a handover occurs, the method comprising:
processing all Radio Link Control (RLC) Protocol Data Units (PDUs) that can be combined into an RLC SDU;
sending all successfully combined RLC SDUs to an upper layer;
discarding all RLC PDUs that cannot be combined into RLC SDUs;
and
all out-of-order SDUs are stored in a Packet Data Convergence Protocol (PDCP) SDU receive buffer.
39. The method of embodiment 38, further comprising:
resetting receiver variables and Hyper Frame Numbers (HFNs);
setting a new Media Access Control (MAC) configuration; and
a new RLC configuration is set.
40. The method of embodiment 39, further comprising:
SDU status reports indicating successfully received and unsuccessfully received SDUs are combined, wherein the SDU status report corresponds to a PDCP SDU status report.
Although features and elements are described in particular combinations, each feature or element can be used alone without the other features and elements or in various combinations with or without other features and elements. The methods or flow charts provided may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor, examples of which include Read Only Memory (ROM), Random Access Memory (RAM), registers, buffers, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks and Digital Versatile Disks (DVDs).
For example, suitable processors include: 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, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) circuit, any other type of Integrated Circuit (IC), and/or a state machine.
A processor in association with software may be used to implement a radio frequency transceiver for use in a Wireless Transmit Receive Unit (WTRU), User Equipment (UE), terminal, base station, Radio Network Controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a camcorder module, a video phone,Speakerphone, vibration device, speaker, microphone, television transceiver, hands free headset, keyboard, bluetoothA module, a Frequency Modulation (FM) radio unit, a Liquid Crystal Display (LCD) display unit, an Organic Light Emitting Diode (OLED) display unit, a digital music player, a media player, a video game player module, an internet browser, and/or any Wireless Local Area Network (WLAN) module.
Claims (2)
1. A method of resetting a medium access control, MAC, element, the method comprising:
receiving an enhanced high speed MAC-ehs reset message from a radio resource control, RRC, unit;
emptying the HARQ soft buffer for all configured hybrid automatic repeat request HARQ processes in the MAC unit;
stopping a reordering release timer and a MAC-ehs reordering timer located in a reordering queue of the MAC unit, wherein the reordering queue uses at least one variable to perform reordering of received MAC-ehs Protocol Data Units (PDUs);
setting the timer and the variable to their respective initial values;
passing all reordering PDUs in the reordering queue to a reassembly unit located in the MAC unit;
the reassembly unit performs reassembly of the segmented MAC-ehs service data units SDU and delivers successfully reassembled MAC-ehs SDU to a logical channel identifier (LCH-ID) demultiplexing unit located in the MAC unit;
the LCH-ID demultiplexing unit transmits the complete MAC SDU to a correct logic channel or MAC stream;
discarding stored MAC-ehs SDU segments from the reassembly unit; and
emptying the reordering queue.
2. A wireless transmit/receive unit, WTRU, comprising:
a radio resource control, RRC, unit; and
a medium access control, MAC, unit, the MAC unit comprising:
a reordering queue comprising a reordering release timer and an enhanced high speed MAC-ehs reordering timer;
a recombination unit; and
a logic channel identifier LCH-ID demultiplexing unit; the MAC unit is configured to:
receiving a MAC-ehs reset message from the RRC unit;
emptying the HARQ soft buffer for all configured hybrid automatic repeat request HARQ processes;
stopping the reordering release timer and the MAC-ehs reordering timer, wherein the reordering queue uses at least one variable to perform reordering of received MAC-ehs Protocol Data Units (PDUs);
setting the timer and the variable to their respective initial values;
delivering all reordering PDUs in the reordering queue to the reassembly unit, wherein the reassembly unit performs reassembly of segmented MAC-ehs service data units SDUs, delivers successfully reassembled MAC-ehs SDUs to the logical channel identifier LCH-ID demultiplexing unit, which delivers complete MAC SDUs to the correct logical channel or MAC stream, discards stored MAC-ehs SDU segments from the reassembly unit; and
emptying the reordering queue.
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US60/887,896 | 2007-02-02 | ||
| US60/895,338 | 2007-03-16 | ||
| US60/908,076 | 2007-03-26 | ||
| US60/914,189 | 2007-04-26 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| HK13110648.0A Division HK1183396A (en) | 2007-02-02 | 2010-07-19 | A wtru and a method implemented in the wtru |
Related Child Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| HK13110648.0A Addition HK1183396A (en) | 2007-02-02 | 2010-07-19 | A wtru and a method implemented in the wtru |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| HK1140893A HK1140893A (en) | 2010-10-22 |
| HK1140893B true HK1140893B (en) | 2014-02-28 |
Family
ID=
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| TWI467994B (en) | UTRA R6 cell and R7 cell control handover method and device | |
| JP5714146B2 (en) | Method and apparatus for supporting uplink protocol changes | |
| CN101641914B (en) | Wireless communication method and device for supporting reconfiguration of radio link control parameters | |
| RU2448437C2 (en) | Method and apparatus for controlling handover between utra r6 cells and r7 cells | |
| HK1140893B (en) | Method and apparatus for controlling a handover between utra r6 cells and r7 cells | |
| HK1140893A (en) | Method and apparatus for controlling a handover between utra r6 cells and r7 cells | |
| HK1183396A (en) | A wtru and a method implemented in the wtru | |
| HK1139258B (en) | Wireless communication method and apparatus for supporting reconfiguration of radio link control parameters |