Patent Application
20150135024
The technology relates to radio communications, and in particular, to detecting, correcting, and if possible preventing ciphering errors between two radio nodes.
The technology in this application is described in an example UTRAN/Wideband Code Division Multiple Access (WCDMA) context. In particular, the technology is related to the WCDMA Radio Link Control (RLC) protocol, Unacknowledged Mode (UM) transmission and reception, ciphering, Medium Access Control (MAC) Hybrid ARQ (HARD) process, the air interface (Uu) and the interface between NodeB and Radio Network Controller (RNC) (Iub/Iur interface) in a UTRAN type of system such as the example illustrated in
Whenever the RLC layer is configured in unacknowledged mode (UM), ciphering is performed by RLC itself. See 3GPP TS25.322v10.1.0 “Radio Link Control (RLC) protocol specification,” incorporated herein by reference.
For RLC UM mode, a ciphering unit is the Unacknowledged Mode Protocol Data Unit (UMD PDU) excluding the first octet, i.e., excluding the UMD PDU header. See
The Sequence Number (SN), which is contained in the first octet of the UMD PDU, is not encrypted, whereas all the remaining octets (i.e., the Ciphering Unit) are encrypted when ciphering is activated. 3GPP TS33.102v10.0.0 “3G security; Security architecture,” incorporated herein by reference, defines parameters required by the RLC layer for ciphering. One of these parameters is the ciphering sequence number COUNT-C, which is 32 bits long. There is one COUNT-C value per up-link radio bearer and one COUNT-C value per down-link radio bearer using RLC Acknowledged Mode (AM) or RLC UM.
COUNT-C includes two parts: a short sequence number and a long sequence number. The short sequence number forms the least significant bits of COUNT-C while the long sequence number forms the most significant bits of COUNT-C. The update of COUNT-C depends on the transmission mode as described below.
For RLC UM mode, the short sequence number is the 7-bit RLC sequence number (RLC SN) and this is part of the RLC UM PDU header. The long sequence number is the 25-bit RLC UM Hyper Frame Number (HFN), which is incremented at each RLC SN cycle. Since the Sequence Number (SN) has a length of 7 bits, its range is 128 PDUs. If the transmission/reception starts from sequence number (SN) 0, then the HFN is incremented after the transmission/reception of 128 PDUs. But the transmitting UM RLC entity does not receive any feedback information regarding the correct or erroneous reception of UM PDUs by the receiver side.
Since the transmitting UM RLC entity is not aware of whether the UM RLC PDUs are actually received or not by the receiving RLC entity, it will continue transmitting UM RLC PDUs whenever there is data received from higher layers and resources from lower layers are available. In case more than 127 consecutive UM RLC PDUs are transmitted but not received, or not correctly received, this will cause a mismatch between the current HFN value calculated at the transmitting and receiving side. If further UM PDUs are transmitted and received correctly, the COUNT-C on the transmitting and receiving side will be misaligned since a wrap around of the RLC Sequence Number has occurred on the transmitting side which the receiving side is unaware of, leading to a ciphering problem. The result is that the data in the RLC UM PDU will be erroneously deciphered since the RLC entities involved in the transmission/reception will not be able to detect the error and will just forward the corrupted PDUs to higher layers.
For example, assume HFN=0 and SN=1 for the last successful PDU transmission/reception and that the following 128 PDUs are transmitted, but not received correctly. The transmitting side increments the HFN by one because a complete SN cycle has occurred. For the next transmission, the SN=2, but the HFN on the transmitting side is 1 and not 0. If the receiving side receives this PDU correctly, it reads SN=2 and assumes that the HFN is still equal to 0, since its HFN has not been incremented. As a result, the COUNT-C's at sender and at the receiver do not match, causing a ciphering error. The same result occurs if more than 128 PDUs are not received correctly.
This error may for instance occur, for the downlink, as follows. First, assuming the initial RF condition is satisfactory, the UM RLC PDUs are correctly transmitted over HS-DSCH ([3GPP TS25.321v11.0.0 “Medium Access Control (MAC) protocol specification,” incorporated by reference) by the network and received by the UE. Then, the RF quality deteriorates, but not so much as to cause de-synchronization at L1 or a Radio Link Failure (3GPP TS25.214v11.1.0 “Physical layer procedures (FDD),” incorporated by reference) procedure. Nevertheless, the UE can not successfully decode packets on the High Speed Physical Downlink Shared Channel (HS-PDSCH). This may happen if the quality of the downlink Dedicated Physical Control Channel (DPCCH)/Fractional—Dedicated Physical Channel (F-DPCH) is sufficient to keep the UE in-sync, but the quality of the Shared Control Channel for the High Speed Downlink Shared Channel (HS-DSCH) (HS-SCCH) and the HS-PDSCH is not sufficient to allow a correct data reception. It is notable that the physical channels DPCCH and F-DPCH are power-controlled, whereas in contrast, the power of the HS-SCCH and HS-PDSCH is not based on feedback from the UE. The condition is compounded if this condition persists for a period of time corresponding to the transmission of 128 UM RLC PDUs.
In the current 3GPP standard, the NodeB is aware, by way of the MAC Hybrid ARQ, of unsuccessful transmissions of MAC-hs/ehs PDUs, because these MAC PDUs (and their re-transmissions) are either (1) not acknowledged or (2) negatively acknowledged by the UE. But because the MAC Hybrid ARQ processing is performed by the NodeB and the RLC protocol is handled by the RNC, the RNC is not aware of HARQ failures. This is illustrated in the
But again, there is no mechanism that informs higher protocol layers (and in turn the network) of consecutive HARQ failures. This can be seen in
It would also be desirable that any technology capable of detecting the loss of consecutive RLC PDUs be configurable depending on the transfer mode of the RLC PDUs (i.e. UM, AM or TM) and the logical channel associated to the PDUs. Different transfer modes and different logical channel may need different and independent mechanisms to detect the PDU loss.
A transmitting node communicates with a receiving node using a multi-layer communications protocol having a lower media access control, MAC, layer and a higher radio link control, RLC, layer. An RLC controller operates in an RLC unacknowledged mode, RLC UM. A MAC controller operates using hybrid automatic repeat request, HARQ, for transmitted MAC protocol data units. The RLC controller in the RLC UM transmits RLC protocol data units via the MAC layer. The MAC controller monitors transmission errors at the MAC layer and informs the RLC controller when detecting a predetermined number of consecutive transmission errors or a predetermined number of transmission errors during a predetermined time period so that the RLC controller can perform one or more actions.
Typically, in the RLC UM, the RLC controller does not receive any feedback information regarding correct or erroneous reception of the transmitted RLC protocol data units by the receiving node. In example embodiments, the transmission errors are MAC protocol data unit, MAC PDU, transmission failures which occur when a maximum number of HARQ transmissions for a MAC PDU is reached without receiving a positive acknowledgement for that MAC PDU. In one example embodiment, the MAC controller uses a counter to account for each MAC PDU transmission failure, and the counter is reset if the transmission of a MAC PDU is successful. In another example embodiment, the MAC controller uses a counter to account for each MAC PDU transmission failure occurring during the predetermined time period.
The technology described above may be implemented for each of multiple data flows, each of multiple logical channels, or each of multiple priority queues.
In one example embodiment, the transmitting node is a user equipment, UE, that includes the RLC controller and the MAC controller, and the one or more actions includes taking action to permit synchronization of the UE and radio base station.
In another example embodiment, a radio network controller, RNC, includes the RLC controller, and a radio base station communicating with the RNC and a user equipment, UE, includes the MAC controller. The MAC controller in the radio base station sends an error message to the RLC controller in the RNC so that the RNC controller can perform the one or more actions.
A further example embodiment includes the RNC transmitting to the radio base station a message indicating one or more data flows and/or one or more logical radio channels to be monitored for errors. The radio base station, in response, configures one or more de-synchronization detecting counter(s) and/or timer(s) for each of the one or more specific data flows, one or more specific logical channels, or one or more multiple priority queues indicated in the message. The configured one or more de-synchronization detecting counter(s) and/or timer(s) detect an error, and the radio base station sends a de-synchronization message to the RNC indicating de-synchronization between the UE and the radio base station.
In one example application, the RLC controller performs ciphering of data units to be transmitted.
In another example application, the RLC controller and the MAC controller are configured to support voice over IP, VoIP, communications, and the one or more actions includes an indication that a lack of synchronization is affecting the transmitting and receiving nodes. In some embodiments an elapsed time is determined between two consecutively-received RLC protocol data units. A timing offset is determined using the elapsed time, and the timing offset is used to acquire synchronization. The elapsed time is divided by a VoIP transmission rate so that the timing offset is determined using the elapsed time divided by the VoIP transmission rate.
Other example embodiments are directed specifically to an RNC communicating with a UE via a radio base station over a radio interface using a multi-layer communications protocol having a MAC layer and an RLC layer, where an RLC controller in the RNC operates in RLC UM, and where a MAC controller in the base station operates using HARQ for transmitted MAC data units. The RNC determines one or more parameters associated with the communication between the UE and the RNC for the base station to monitor. The RNC configures the radio base station to detect when a predetermined number of consecutive transmission errors or a predetermined number of transmission errors during a predetermined time period occurs. The RNC receives from the radio base station a message indicating the occurrence of a predetermined number of consecutive transmission errors or a predetermined number of transmission errors during a predetermined time period and sends a correction message to the radio base station based on the received message.
An example correction message includes information to permit synchronization between the UE and the radio base station, and the information may include a time offset to a transmission frame number.
In an example application, the RNC configures the radio base station by sending a message to the radio base station to monitor each of multiple data flows, each of multiple logical channels, or each of multiple priority queues for the predetermined number of consecutive transmission errors or the predetermined number of transmission errors during a predetermined time period.
Various example embodiments are described for configuring or signaling the predetermined value and for sending an error detection indication. In one example implementation in a UTRAN-based system, (1) example uplink and downlink signaling between RNC and NodeB and (2) example message formats for sending the error detection configuration, e.g., for each data flow or logical channel, and for sending an error detection, e.g., for each data flow or logical channel, are described.
The following sets forth specific details, such as particular embodiments for purposes of explanation and not limitation. But it will be appreciated by one skilled in the art that other embodiments may be employed apart from these specific details. In some instances, detailed descriptions of well known methods, nodes, interfaces, circuits, and devices are omitted so as not obscure the description with unnecessary detail. Those skilled in the art will appreciate that the functions described may be implemented in one or more nodes using hardware circuitry and/or using software programs and data in conjunction with one or more digital microprocessors or general purpose computers. Nodes that communicate using the air interface also have suitable radio communications circuitry. Moreover, the technology can additionally be considered to be embodied entirely within any form of computer-readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
Individual function and flowchart blocks are shown in the figures. Those skilled in the art will appreciate that the functions of those blocks may be implemented using individual hardware circuits, using software programs and data in conjunction with a suitably programmed microprocessor or general purpose computer, using applications specific integrated circuitry (ASIC), using one or more digital signal processors (DSPs), and using field programmable gate array(s) (FPGAs).
The software program instructions and data may be stored on computer-readable storage medium and when the instructions are executed by a computer or other suitable processor control, the computer or processor performs the functions, and (where appropriate) state machines capable of performing such functions.
Although process steps, algorithms or the like may be described or claimed in a particular sequential order, such processes may be configured to work in different orders. In other words, any sequence or order of steps that may be explicitly described or claimed does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order possible. Further, some steps may be performed simultaneously despite being described or implied as occurring non-simultaneously (e.g., because one step is described after the other step). Moreover, the illustration of a process by its depiction in a drawing does not imply that the illustrated process is exclusive of other variations and modifications thereto, does not imply that the illustrated process or any of its steps are necessary to the invention(s), and does not imply that the illustrated process is preferred. A description of a process may be a description of an apparatus for performing the process. The apparatus that performs the process can include, e.g., a processor and those input devices and output devices that are appropriate to perform the process.
In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer, processor, and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term “processor” or “controller” also refers to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
Although the description is given for user equipment (UE), it should be understood by the skilled in the art that “UE” is a non-limiting term comprising any wireless device or node equipped with a radio interface allowing for at least one of: transmitting signals in UL and receiving and/or measuring signals in DL. Some examples of UE in its general sense are PDA, laptop, mobile, sensor, fixed relay, mobile relay, a radio network node (e.g., an LMU or a femto base station or a small base station using the terminal technology). A UE herein may comprise a UE (in its general sense) capable of operating or at least performing measurements in one or more frequencies, carrier frequencies, component carriers or frequency bands. It may be a “UE” operating in single- or multi-RAT or multi-standard mode.
A cell is associated with a base station, where a base station comprises in a general sense any node transmitting radio signals in the downlink (DL) and/or receiving radio signals in the uplink (UL). Some example base stations are eNodeB, eNB, Node B, macro/micro/pico radio base station, home eNodeB, relay, repeater, sensor, transmitting-only radio nodes or receiving-only radio nodes. A base station may operate or at least perform measurements in one or more frequencies, carrier frequencies or frequency bands and may be capable of carrier aggregation. It may also be a single-radio access technology (RAT), muti-RAT, or multi-standard node, e.g., using the same or different base band modules for different RATs.
The signaling described is either via direct links or logical links (e.g. via higher layer protocols and/or via one or more network nodes). For example, signaling from a coordinating node may pass another network node, e.g., a radio node.
The example embodiments are described in the non-limiting example context of a UTRAN type system. However, the technology is not limited to UTRAN, but may apply to any Radio Access Network (RAN), single-RAT or multi-RAT. Some other RAT examples are LTE-Advanced, UMTS, GSM, cdma2000, WiMAX, and WiFi. If applying the technology to LTE, for example, those skilled in the art will understand that the MAC entities in LTE have different names and functionalities.
The ciphering problem described in the background for UM RLC transmission/reception is preceded by the loss of a number of consecutive RLC PDUs (this number typically depends on the number of bits used to indicate the Sequence Number (SN). In the non-limiting example from the background, 7 bits are used, and thus, the number of lost consecutive data units might be 128 or more. But other smaller or larger numbers of lost consecutive PDUs may be used. The loss of consecutive PDUs can be detected by the MAC layer in case of transmission over HS-DSCH (for the downlink) and EUL (for the uplink). This mechanism may be implemented in the network side, in the UE side, or in both network and UE independently.
Consider the situation where the sequence number (SN) range is 128, i.e., from 0 to 127, and PDUs are transmitted and should be received in the same order. In other words, a PDU with a lower SN is transmitted and should be received before a PDU with a higher SN is received. But if the receiver receives a PDU with SN5 and thereafter receives a PDU with SN3, the technology provided by this application concludes that the 125 PDUs (127-5+3) have been lost (not received or correctly received) because the PDU with SN3 should not be received before the PDU with SN5. As a result, the HFN in the receiver may be incremented by one since the SN has “wrapped around.” But the number of lost PDUs need not necessarily be set to 128. Rather, it may for example be set to 20 in order to detect that something has or may have gone wrong to give the network and/or the UE an opportunity to action, if needed.
The network can detect the loss of consecutive UM RLC PDUs using one or more counters and/or timers in the MAC layer (e.g., in a MAC-hs controller or MAC-ehs controller). When the counters reach a specified value (e.g., hardcoded, defined during the set-up of the MAC and RLC entities, etc.), or at the expiration of one or more timers, an error detection notification is sent from the NodeB to the RNC for the downlink failures and for certain occurrences of uplink failure.
The UE may also detect the loss of consecutive UM RLC PDUs using one or more counters and/or timers in the MAC layer (e.g., in a MAC-e/es controller or MAC-i/is controller). When the counters reach a specified value (e.g., hardcoded, defined during the set-up of the MAC and RLC entities, etc.), or at the expiration of one or more timers, an error detection notification is sent from the UE to the RNC.
The network may use the notification received from the UE or the NodeB in order to correct an HFN de-sync error by re-aligning the frame numbers so that they are the same in both transmitting and receiving nodes.
Another aspect of the technology this application addresses the fact that a UE radio bearer may include multiple data flow and/or logical channels that may need to be treated differently, e.g., different data flows have different quality of service parameters. This is illustrated in
Loss of data on the HARQ level is not a problem for RLC AM because such a loss of data causes an RLC retransmission which means that the RNC will be able to indirectly identify the logical channel that lost the data based on this information. However, for RLC UM, no such indication will be transmitted or received, and as a result, the data loss must be deduced implicitly based on the fact that a NACK was received for a TTI in which data from the priority queue to which the RLC UM data is mapped was scheduled. It would be instead beneficial for the network and/or for the UE to know whether this loss of consecutive PDUs (MAC and RLC) has an impact on a particular RLC entity (because this may determine a ciphering error if the transfer mode is UM) or on a particular logical channel (because different logical channels may be associated to different services which in turn may be more or less sensitive to a loss of PDUs). In accordance with example embodiments, the configuration for error detection (e.g., de-synchronization between the Node B and the UE) preferably depends on the transfer mode of RLC PDUs (i.e., UM, AM, or TM) and the specific and individual data flow and/or logical channel associated to those PDUs. Different transfer modes and different data flows and/or logical channels may need independent mechanisms, e.g., MAC counters and timers, in order to detect PDU loss per flow/logical channel.
The description is now divided into three sections to allow focus on different example embodiments, applications, and variations. The technology in these sections may be used alone or in combination. The three sections include error detection, configuration and reporting of error detection, and correction of the error to maintain or reclaim synchronization between UE and the network.
Error Detection
The apparatus for error detection may be implemented in the UE and/or in one or more network nodes. If the error detection mechanism is configured in both the network node and the UE, then error detection mechanisms in the UE and the network node(s) may be different. Error detection in the UE is described in a first example context, and a second example context describes error detection in the network node.
For a first example implementation, error detection may be based on counter used by a MAC layer controller in the UE, if the UE is the transmitting node, and/or the network node if it is the transmitting node. MAC PDUs are communicated between MAC controllers in the UE and NodeB. RLC PDUs are communicated between RLC controllers in the UE and RNC. Error detection by a transmitting UE may be based on counter used by a MAC layer controller. When an RLC controller in the transmitting UE operates in Unacknowledged Mode, the MAC controller uses a counter to account for each transmission failure of a MAC PDU detected by the MAC controller in the transmitter. For the UE, when an RLC controller in the UE operates in Unacknowledged Mode, the MAC layer uses a counter to account for each transmission failure of a MAC PDU detected by the MAC controller. The counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. If the counter is initialized to zero, a maximum value for the counter is also configured. If that maximum count value is reached, then the MAC controller sends an indication to the RLC controller that an error event has occurred, e.g., a loss of synchronization or de-synchronization between the UE transmitter and receiver. The maximum count value corresponds to the predetermined number of consecutive errors. Similarly, the counter may be initialized to a configurable, non-zero value which also corresponds to the predetermined number of consecutive errors. In this case, each time there is a transmission failure of a MAC PDU, the counter is decremented by one.
In either counter approach, the counter is reset if the transmission of a MAC PDU is successful. To reset means that the counter is initialized to 0 or to the value configured by the network depending on whether the counter increases or decreases after a detected transmission failure.
If the counter value is configured by the network, then this value can be conveyed to the MAC controller in the UE via radio resource control (RRC) signaling. Alternatively, this counter value can be hardcoded in the UE MAC controller. This alternative approach does not require any signaling between the RNC and UE.
In this situation, the transmitter and the receiver each include configured HARQ controllers. The transmission of a MAC PDU is considered successful if the HARQ controller in the UE receives a positive acknowledgement from the network for that MAC PDU. If the transmission of a MAC PDU is not successful, then the UE re-transmits the MAC PDU if configured by the network to retransmit. A transmission failure occurs when the maximum number of HARQ transmissions (which includes the initial transmission and any retransmissions) for a MAC PDU is reached. The receiver, upon receiving a MAC PDU, sends a positive acknowledgement for that MAC PDU if it was successfully received or a negative acknowledgement for that MAC PDU if it was unsuccessfully received (not received or received in error). In this example context, a MAC PDU refers to a MAC-e/es or MAC-i/is PDU for the uplink.
An example implementation of the first embodiment with error detection by a transmitting network is now described. When a Radio Link Control controller in the RNC is configured in order to operate in Unacknowledged Mode, the MAC layer in the transmitting NodeB includes a counter that is used to account for each transmission failure of a MAC PDU detected by the MAC controller. The counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. If the counter is initialized to zero, a maximum value for the counter is also configured. If that maximum count value is reached, then the MAC controller sends an indication to the RLC controller that an error event has occurred, e.g., a loss of synchronization or de-synchronization between the transmitter and UE receiver. The maximum count value corresponds to the predetermined number of consecutive errors. Similarly, the counter may be initialized to a configurable, non-zero value which also corresponds to the predetermined number of consecutive errors. In this case, each time there is a transmission failure of a MAC PDU, the counter is decremented by one.
If the counter value is configured by the network, this value can be conveyed to the MAC controller in the NodeB via Node B Application Part (NBAP) signaling. Alternatively, this value can be a hardcoded parameter in the MAC controller of the NodeB. This alternative approach does not require any signaling between the RNC and UE.
The transmission of a MAC PDU is considered successful if the HARQ controller in the network receives a positive acknowledgement from the UE for that MAC PDU. If the transmission of a MAC PDU is not successful, then the network node may re-transmit the MAC PDU. A transmission failure is considered when the network decides to stop re-transmitting that MAC PDU. The previous assumptions are based on the fact that the transmitter and the receiver have configured HARQ entities. The receiver, upon receiving a MAC PDU, should then send a positive acknowledgement for that MAC PDU if it was successfully received or a negative acknowledgement for that MAC PDU if it was unsuccessfully received. In this example context, a MAC PDU refers to a MAC-hs or MAC-ehs PDU for the downlink.
The following example procedure may be implemented in either or both the UE and network node(s). When the incremented counter reaches its maximum value, the Medium Access Control controller sends an error indication to one or more higher layers, e.g., the RLC layer. Alternatively, if a decrementing counter is used, and it reaches its minimum value (i.e., 0), the MAC controller sends an error indication to one or more higher layers. This error indication may trigger one or more higher protocol layer procedures.
In a second example implementation, error detection is based on a counter and a timer.
Consider an example including error detection by a transmitting UE. The function of the counter is to account for each transmission failure of a MAC PDU. The function of the timer is to account for a maximum time frame under which the MAC PDU transmission failures are counted.
When an RLC controller operates in Unacknowledged Mode, the MAC layer uses a counter to account for each transmission failure of a MAC PDU detected by the MAC controller. The counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. If the counter is initialized to zero, a maximum value for the counter is also configured. If that maximum count value is reached, then the MAC controller sends an indication to the RLC controller that an error event has occurred, e.g., a de-synchronization between the transmitting UE and receiver. The maximum count value corresponds to the predetermined number of consecutive errors. Alternatively, the counter may be initialized to a configurable, non-zero value which also corresponds to the predetermined number of consecutive errors. In this case, each time there is a transmission failure of a MAC PDU, the counter is decremented by one.
The timer may for example be configured with a timer value by the network and signaled to the UE or the timer value may be hardcoded in the UE. The timer value indicates when the timer expires. The timer is started when there is a transmission failure of a MAC PDU. The timer is reset at its expiration and is not re-started due to subsequent failures. The counter is reset at the expiration of the timer. To reset means that the counter is initialized to 0 or to the value configured by the network depending on whether the counter increases or decreases after a failure.
If the counter value or maximum counter value is configured by the network, this value can be conveyed to the MAC controller in the UE via RRC signaling. Otherwise, this value can be hardcoded in the MAC controller of the UE. The latter approach does not require signaling between the RNC and UE.
In this situation, the UE transmitter and the NodeB receiver each include configured HARQ controllers. The transmission of a MAC PDU is considered successful if the HARQ controller in the UE receives a positive acknowledgement from the network for that MAC PDU. If the transmission of a MAC PDU is not successful, then the UE re-transmits the MAC PDU if configured by the network to retransmit. A transmission failure occurs when the maximum number of HARQ transmissions (which includes the initial transmission and any retransmissions) for a MAC PDU is reached. The NodeB receiver, upon receiving a MAC PDU, sends a positive acknowledgement for that MAC PDU if it was successfully received or a negative acknowledgement for that MAC PDU if it was unsuccessfully received (not received or received in error). In this example context, a MAC PDU refers to a MAC-e/es PDU or a MAC-i/is PDU for the uplink.
Consider an example including error detection by a transmitting network. When an RLC controller in the RNC is configured in order to operate in Unacknowledged Mode, the MAC controller in the NodeB is configured with a counter and a timer. The function of the counter is to account for each transmission failure of a MAC PDU. The function of the timer is to account for a maximum time frame under which the MAC PDU transmission failures are counted.
The counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. If the counter is initialized to zero, a maximum value for the counter is also configured. If that maximum count value is reached, then the MAC controller sends an indication to the RLC controller that an error event has occurred, e.g., a de-synchronization between the NodeB transmitter and UE receiver. The maximum count value corresponds to the predetermined number of consecutive errors. Similarly, the counter may be initialized to a configurable, non-zero value which also corresponds to the predetermined number of consecutive errors. In this case, each time there is a transmission failure of a MAC PDU, the counter is decremented by one.
The timer may for example be configured with a timer value by the network or the timer value may be hardcoded. The timer value indicates when the timer expires. The timer is started when there is a transmission failure of a MAC PDU. The timer is reset at its expiration and is not re-started due to subsequent failures. The counter is reset at the expiration of the timer. Again, to reset means that the counter is initialized to 0 or to the value configured by the network depending on whether the counter increases or decreases after a failure.
If the counter value is configured by the network, this value can be conveyed to the MAC controller in the NodeB via NBAP signaling or this value can be a hardcoded parameter in the MAC controller of the NodeB. The latter approach does not require signaling between RNC and NodeB. If the timer value is configured by the network, this value can be conveyed to the MAC controller in the Node-B via NBAP signaling. Alternatively, this value can be a hardcoded parameter in the MAC controller of the NodeB. The latter approach does not require signaling between RNC and NodeB.
In this situation, the transmitter and the receiver each include configured HARQ controllers. The transmission of a MAC PDU is considered successful if the HARQ controller in the transmitter receives a positive acknowledgement from the receiver for that MAC PDU. If the transmission of a MAC PDU is not successful, then the transmitter re-transmits the MAC PDU if configured by the network to retransmit. A transmission failure occurs when the maximum number of HARQ transmissions (which includes the initial transmission and any retransmissions) for a MAC PDU is reached. The receiver, upon receiving a MAC PDU, sends a positive acknowledgement for that MAC PDU if it was successfully received or a negative acknowledgement for that MAC PDU if it was unsuccessfully received (not received or received in error). In this example context, a MAC PDU refers to a MAC-hs PDU or a MAC-ehs PDU for the downlink.
The following example procedure may apply to one or both of the UE and network node(s). When the counter is incremented and reaches its maximum value, the MAC controller sends an error indication to one or more higher protocol layers, e.g., an RLC controller. Similarly, if the decrementing counter is used and reaches its minimum value (i.e., 0), the MAC controller sends an error indication to one or more higher layers.
A third example implementation performs error detection using two counters and a timer.
The first counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. If the counter is initialized to zero, then a maximum value for the counter may also be configured. Alternatively, the first counter may be initialized to a configurable non-zero value. Each time there is a transmission failure of a MAC PDU, the counter is decremented by one. The first counter is reset if the transmission of a MAC PDU is successful. If the first counter value is configured by the network, that value may be conveyed to the MAC controller in the UE via RRC signaling. Alternatively, this value can be hardcoded in the MAC controller of the UE which does not require signaling between an RNC and the UE.
The second counter may be initialized to zero and incremented by one every time there is a transmission failure of a MAC PDU up to a maximum value configured for the second counter. Alternatively, the second counter may be initialized to a configurable non-zero value. The timer is either configured by the network and then signaled to the UE, or hardcoded in the UE. The timer value indicates when the timer expires. The timer is started when there is a failure in the transmission of a MAC PDU. The timer is reset at expiration. The timer is not re-started due to subsequent failures. The second counter is reset at the expiration of the timer. If the second counter value is configured by the network, this value can be conveyed to the MAC controller in the UE via RRC signaling. Alternatively, the value can be hardcoded in the MAC controller of the UE which avoids the need for signaling between RNC and UE.
For error detection in this third embodiment by the network node when an RLC controller in the RNC is configured in order to operate in Unacknowledged Mode, the MAC controller in the NodeB is configured with two counters and a timer. The first counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. In this example context, MAC PDU refers to a MAC-hs PDU or a MAC-ehs PDU for the downlink. If the first counter is initialized to zero, a maximum value for the counter is also configured. Alternatively, the counter may be initialized to a configurable non-zero value, and each time there is a transmission failure of a MAC PDU, the counter is decremented by one. The first counter is reset if the transmission of a MAC PDU is successful. If the first counter value is configured by the network, this value can be conveyed to the MAC controller in the NodeB via NBAP signaling. Alternatively, this value can be a hardcoded parameter in the MAC controller of the NodeB which avoids the need for signaling between RNC and NodeB.
The second counter may be initialized to an initial value equal to zero and incremented by one every time there is a transmission failure of a MAC PDU. If the second counter is initialized to zero, a maximum value for the counter is also configured. Alternatively, the second counter may be initialized to a configurable non-zero value, and each time there is a transmission failure of a MAC PDU, the counter is decremented by one. The configured value for the timer indicates when the timer expires. The timer is started when there is a transmission failure of a MAC PDU. The timer is reset at its expiration and is not re-started due to subsequent failures. The second counter is reset at the expiration of the timer.
If the second counter value is configured by the network, this value can be conveyed to the MAC controller in the NodeB via NBAP signaling or this value can be a hardcoded parameter in the MAC controller of the NodeB which means that signaling between RNC and NodeB is not required. If the timer value is configured by the network, this value can be conveyed to the MAC controller in the NodeB via NBAP signaling or this value can be a hardcoded parameter in the MAC controller of the NodeB.
The procedures shown in
In a fourth example embodiment, error detection is based on a timer. In an example where error detection is done by the UE, with an RLC controller configured to operate in Unacknowledged Mode, the MAC controller includes a timer. The function of the timer is to account for a maximum time period under which the MAC PDU transmission failures occur without a successful transmission. The timer may for example be configured by the network via RRC signaling or hardcoded in the UE. The timer value indicates when the timer expires. Assuming that data is sent periodically (e.g. as for Voice over IP) or that there will be a least a predetermined number of MAC PDU transmissions, the timer is started when there is a transmission failure of a MAC PDU. The timer is reset when there is a successful transmission of a MAC PDU. The timer need not be re-started for subsequent failures. In this example context, a MAC PDU refers to a MAC-e/es PDU or a MAC-i/is PDU for the uplink.
In an example where error detection is done by a network node, the RLC controller in the RNC is configured to operate in Unacknowledged Mode, and the MAC controller in the NodeB includes a timer like that just described for the UE. If the timer value is configured by the network, this value can be conveyed to the MAC controller in the NodeB via NBAP signaling. Alternatively, this value can be a hardcoded parameter in the MAC controller of the NodeB which means that signaling between RNC and NodeB is not needed. In this example context, a MAC PDU refers to a MAC-hs PDU or aMAC-ehs PDU for the downlink.
Configuration and Reporting of Error Detection.
In example embodiments, the NodeB may execute independent instances of the error detection algorithm(s) described above to detect loss of DL MAC PDUs. Each instance of an error detection algorithm may be associated to a different MAC-d flows, priority queue, and/or logical channel identity. Each error detection instance may use different counters and/or timers depending on the implementation. The NodeB preferably signals the error detection associated to each instance independently to the RNC.
Thus, for example, a NodeB indicates loss of DL MAC PDUs for each priority queue in the NodeB. If there is a one to one mapping of logical channels to priority queues, then there is a direct identification to the RNC of which logical channel is affected, and consequently, loss of data for a particular logical channel can be determined as a certainty. Given priority considerations for typical data mapped to RLC UM like VoIP or real time video, RLC UM data in a typical implementation may be mapped to an exclusive priority queue, thereby permitting direct identification of PDU losses of RLC UM data. This reduces the risk of transmit sequence number (TSN) wrap around.
If more than one logical channel is mapped to a particular priority queue, then the behavior is implementation dependent, and the RNC may either choose to assume that RLC UM data has been lost or not. In this case, the RNC may choose not to act on the information received or more conservatively estimate that the data lost from the priority queue stems from the logical channel most susceptible to TSN wrap around, i.e., the logical channel conveying RLC UM data. Since the RNC knows the mapping logical channels to MAC-d flows and to Priority Queues for MAC-hs and Queue id for MAC-ehs, the RNC has sufficient information to determine if the functionality described above should be triggered or not for an individual data flow.
RNC Configuration.
In example embodiments, when configuring a Radio Bearer and the relevant RLC entities and MAC-d flows, MAC reordering queues, and Logical Channel IDs, information signaled from the RNC to both the NodeB and UE is used for the configuration detection. For example, the RNC may signal up to 8 RB multiplexing options (maxRBMuxOptions). For each multiplexing option, the RNC may provide Downlink RLC logical channel information. For each Downlink RLC logical channel, (e.g., up to 2 per RLC entity or radio bearer), the RNC provides either MAC-hs or MAC-ehs header type information. For MAC-hs, the DL HS-DSCH MAC-d flow identity (0 to 7) may be provided, and for MAC-ehs, a DL HS-DSCH MAC-ehs Queue Id (0 to 7) and optionally a logical channel identity (1 to 15) may be provided. The RNC may provide the HS-DSCH MAC-d flow identity (0 to 7).
One non-limiting example is provided below. Either priority queue ID, HS-DSCH MAC-d Flow ID, logical channel ID, or a subset of these parameters is selected. The RNC configures a de-sync counter and/or timer for each HS-DSCH MAC-d flow ID and/or priority queue and/or logical channel ID. This configuration information is provided to and used in the Node B.
The technology may for example be applied to the NBAP (TS 25.433)/RNSAP (25.423) control plane by adding into an existing message or by creating a new dedicated message. One example of a configuration IE is given in Table 1 below.
In the Table 2 example below, new Information Elements (IEs) for HFN de-synchronization (de-sync) configuration are added on NBAP by adding the new configuration IEs to the existing IE HS-DSCH MAC-d Flow Information. This IE may be included in dedicated Radio Link handling messages “RADIO LINK SETUP REQUEST/RADIO LINK ADDITION REQUEST/RADIO LINK RECONFIGURATION PREARE/RADIO LINK RECONFIGURATION REQUEST” in NBAP and RNSAP.
The HS-DSCH MAC-d Flows Information IE is used for the establishment of HS-DSCH MAC-d flows for a UE Context.
The IE HFN de-synchronization detection Configuration is defined as in below Table 3. The HFN de-synchronization detection Configuration IE provides information for a Node B or drift RNS (DRNS) to perform HFN de-synchronization detection.
Another example is an HFN de-synchronization detection Configuration IE that provides information for a Node B to perform HFN de-synchronization detection such as set forth in the Table 4 below.
The new information may also be applied to the Iub (TS 25.435)/Iur (TS 25.425) user plane frame protocol, by adding into the existing HS-DSCH data frame, the existing HS-DSCH control frame, or by creating a new HS-DSCH control frame.
Alternatively, the RNC may send an NBAP control plane or UP FP message containing a list with the following (or a subset of the following) information elements: MAC-d ID, logical channel ID, queue ID, De-sync Detect Counter, and/or De-sync Detect Timer.
Example Apparatus for Error Indication/Notification.
Once the error is detected, it is reported to one or more higher layers so that some type of corrective or preventive action may be taken. Example alternatives and embodiments are now described for configuring and reporting the error detection. Depending on how the error detection is configured, the error notification/indication may use the same or similar IEs as in the error detection configuration message sent by the RNC. Ultimately, the Node B may send the error indication/notification in various ways. It may also be specified that when the RNC does not configure the de-sync detection counter and/or timer, the Node B should not perform any de-sync detection. It may also be specified that when the RNC configures the de-sync detection counter and/or timer to certain values, the Node B should stop the de-sync detection. It may also be specified the Node B should perform de-sync detection with the configuration in Node B, not via RNC.
The Node B preferably provides an error indication/notification per Priority Queue, HS-DSCH MAC-d flow, and/or logical channel. As non-limiting examples, the error indication may be defined as an HARQ failure, a MAC-d failure, or HFN de-synchronization Indication, etc. The technology may be applied to the NBAP (TS 25.433)/RNSAP (25.423) control plane by adding into the existing message or by creating new dedicated message. One non-limiting example is given in the Table 5 below.
Another non-limiting example is given in the Table 6 below.
The new IEs for HFN de-sync indication/notification may, as a non-limiting example, be added on NBAP/RNSAP to an existing IE “HS-DSCH FDD Update Information.” This IE is included in the dedicated Radio Link message “RADIO LINK PARAMETER UPDATE INDICATION.” It can be added directly to the NBAP/RNSAP “RADIO LINK PARAMETER UPDATE INDICATION.” It can also be applied to Iub (TS 25.435)/Iur (TS 25.425) user plane frame protocol by adding into the existing HS-DSCH data frame, the existing HS-DSCH control frame, or by creating a new HS-DSCH control frame.
For the downlink (DL), the RNC configures one or more counters and/or timers per different instances of MAC-d flows/reorderings/queues/logical channel identities (one or more) that are signaled to the NodeB. When the error event is detected by the MAC controller in the transmitting NodeB, an indication of the error event may be sent from the NodeB to the RNC for each instance independently.
For the DL, one or more counters and/or timers are statically configured in the NodeB. When an error event is detected by the MAC controller in the transmitting NodeB, an indication of the error event may be sent from the NodeB to the RNC.
For the uplink (UL), the RNC configures one or more timers or counters that are signaled to the NodeB. When an error event is detected by the MAC controller in the transmitting NodeB, an indication of the error event may be sent from the NodeB to the RNC.
For the UL, one or more counters and/or timers are statically configured in the NodeB. When an error event is detected by the MAC controller in the transmitting NodeB, an indication of the error event may be sent from the NodeB to the RNC.
The indication of an error event is achieved by adding a new IE Indicator in the existing Control Plane message in Node B Application Part (NBAP) 3GPP TS25.433v11.0.0 and Radio Network Subsystem Application Part (RNSAP) 3GPP TS25.423v11.1.0, both of which are incorporated by reference, or adding a new indication message, so that the Node B can inform the RNC of the error detected at the MAC layer. For example, a new Information Element (IE) may be added to the in NBAP/RNSAP “RADIO LINK PARAMETER UPDATE INDICATION” message. A new IE, for example “MAC Failure Indication,” may be defined to indicate DL/UL MAC error detection or “failure indication.” More detailed failure information can also be defined.
The example Table 7 below is adapted from 3GPP NBAP TS 25.433 chapter 9.2.2.18Ea “HS-DSCH FDD Update Information,” which provides information for HS-DSCH to be updated using at least one IE.
The Indication of Error Detection from the NodeB to the RNC May be achieved by using the reserved/spare bits in 3GPP TS25.435v10.4.0 (Iub UP Prot) and 3GPP TS25.425v10.2.0 (Iur UP Prot), incorporated herein by reference, to send the indication from Node B to RNC in the control frame or data frames.
In 3GPP TS25.425v10.2.0, chapter 6.3.3.11 HS-DSCH CAPACITY ALLOCATION for example, the “6” and “7” in first octet in the CA frame may be used and these new interpretations may be assigned if either is set to “1”. This mapping may be implemented for both Capacity Allocation (CA) type 1 and/or type 2. Spare extensions in this frame can also be used as another alternative. If bit “7” is set to “0,” then the legacy interpretation is applied to the interpretation of the CA frame contents. But if this bit is set to “1,” then the CA frame is understood to indicate that HARQ failure has occurred on the DL. If bit “6” is set to “0,” then a legacy interpretation is applied to the interpretation of the CA frame contents. But if this bit is set to “1,” then the CA frame is understood to indicate that HARQ failure has occurred on the UL. This indication may then be sent either once per occurrence of HARQ failure within a specified time or each time a HARQ failure occurs, i.e., one CA frame with the above-mentioned alternative mapping is sent once for every TTI that HARQ failure occurs in the UL or DL.
Bits “6” and “7” in a first octet in a CA frame are used to indicate that the CA frame contains HARQ failure information for either the UL or the DL and that the “HS-DSCH Credits” field of the CA frame contains additional HARQ failure information. The “HS-DSCH Credits” field could thus contain such information as the number of TTI's for which HARQ failure has occurred and a measure of how many bits each failed TTI attempted to transmit. See the two Tables below. Both embodiment features provide the RNC with sufficient information to determine if the sequence number (SN) of the transmitting and receiving RLC entities are unaligned or out of sync, and consequently, whether the HFN should be offset.
CA type 1 in 3 GPP TS25.435v10.4.0, chapter 6.3.3.11:
CA type 2:
The counters and/or timers are signaled by the RNC to the NodeB. The new counter(s) and timer(s) can be included in the NBAP/RNSAP Control Plane signaling when RNC sets up the dedicated Radio Link, and/or when RNC reconfigures the existing Radio Link, for example in RADIO LINK SETUP REQUEST/RADIO LINK ADDITION REQUEST/RADIO LINK RECONFIGURATION PREARE/RADIO LINK RECONFIGURATION REQUEST messages described in TS25.433 and TS25.423. The new counter(s) and timer(s) can also be signaled from RNC to Node B/DRNC in the Iur/Iub user plane Frame protocols.
For the UL, the RNC configures one or more counters and/or timers that are signaled to the UE. When the failure is detected by the MAC controller in the UE, an indication may be sent from the UE to the RNC.
For the UL, one or more counters and/or timers are statically configured in the UE. When the failure is detected by the MAC controller in the UE, an indication may be sent from the UE to the RNC.
The counters and/or timers configured by the RNC and signaled to the UE, may be signaled in any of the following RRC messages (see TS25.331v11.1.0 “Radio Resource Control (RRC); Protocol specification”): RRC CONNECTION SETUP, RADIO BEARER SETUP, RADIO BEARER RECONFIGURATION, MEASUREMENT CONTROL.
The UL HARQ failure may be signaled by the UE to the RNC by means of any of the following RRC messages (see 3GPP TS25.331v11.1.0): CELL UPDATE, SIGNALLING CONNECTION RELEASE INDICATION, MEASUREMENT REPORT.
Error Correction.
RLC UM may be configured for applications such as Voice over IP (VoIP). VoIP applications transmit data periodically, for example, every 20 ms but other rates may be possible. For example and illustrative purposes, this periodicity is called T_Period. As explained above, the Hyper Frame Number (HFN) is increased by the transmitter after the last sequence number has been transmitted. The HFN is increased by the receiver after the last sequence number has been received. For example, if 7 bits are used to indicate the sequence number, after 128 received RLC PDUs, the receiver increases the HFN by one. In the time domain, after 128×T_Period, the receiver increases the HFN value by one. In this context, 128×T_Period is called HFN_Update_Period. The same applies for the transmitter.
After HFN de-sync detection, the detecting node (NodeB) calculates the elapsed time between A and B (see
The elapsed time is divided by the HFN_Update_Period. The quotient of the division (HFN_Offset) should be rounded to the lowest integer. The HFN_Offset is signaled from the NodeB to the RNC. The HFN at time B should be the HFN at time A plus the HFN_offset. Since the UE hasn't been able to increment its HFN by HFN_Offset, the RNC will decrement its HFN by HFN_Offset in order to match the HFN at the UE side.
Consider the following non-limiting example:
T_Period is equal to 20 ms.
HFN at time A is equal to 34.
Elapsed time between B and A is 7620 milliseconds.
HFN at time B=HFN at time A+3=37.
The RNC resets the HFN to the HFN at time A i.e. HFN at time B−3=37−3=34.
The RNC conveys T_Period to the NodeB via the Iub. The NodeB conveys the HFN_Offset to the RNC via the Iub.
HFN_Offset=round_down[(T(B)−T(A))/HFN_Update_Period].
The UE includes a radio transceiver 30 and one or more antennas and a MAC controller 20 including an HARQ controller 22. Depending on the example embodiment, the MAC controller 20 may also include one or more counters 24, 28 and/or a timer 26 to perform the functions described above. As indicated with an arrow, an error indication message is provided by the MAC controller 20 to an RLC controller 18, which may then take appropriate action to correct that error, such as re-synchronizing the UE radio transceiver timing with that of the NodeB. The RLC controller also communicates with one or more upper protocol layers 16.
The NodeB 12 includes multiple radio transceivers 40 and one or more antennas and a MAC controller 42 including an HARQ controller 44. Depending on the example embodiment, the MAC controller 42 may also include one or more counters 44, 46 and/or timers 48 to perform the functions described above. The MAC controller 42 receives an error detection configuration message from the RNC 14 for each of one or more individual data flows, logical channels, priority queues, etc. The RNC 14 includes a configuration controller 50 which selectively generates individual error detection configuration messages shown in the example in
The technology described here includes many advantages. For example, the technology allows detection of a loss of MAC PDUs which leads to a loss of synchronization between transmitter and receiver. In the non-limiting UTRAN example, the loss of synchronization may correspond to HFN misalignment, and as a result, a subsequent ciphering error in the case of RLC UM communications between a UE and the network. One or more configurable counters and/or a timer may be used to detect a loss of MAC PDUs which may lead to such HFN misalignment. The technology is flexible in that static or dynamic (network configurable) setting of error detection configuration(s) may be used. The error or failure reporting mechanism allows the UE and/or the network node to take corrective action, e.g., to recover the HFN alignment or reconfigure or release the RLC UM entity. As mentioned above, recovery from HFN de-synchronization may avoid or allows recovery from the ciphering error. The technology, as mentioned above, finds wide application. But one example application is Voice over IP (VoIP) services, which makes use of RLC UM. Other example advantages include the RNC configuring a Node B to detect the de-sync per HS-DSCH MAC-d flow, priority Queue, or logical channel. As a result, the RNC specify that de-sync error detection and/or notification only be performed by a Node B for specific HS-DSCH MAC-d flow(s), priority Queue(s), or logical channel(s) and not for others.
Although the description above contains many specifics, they should not be construed as limiting but as merely providing illustrations of some presently preferred embodiments. Embodiments described herein may be considered as independent embodiments or may be considered in any combination with each other to describe non-limiting examples. Although non-limiting, example embodiments of the technology were described in a UTRAN context, the principles of the technology described may also be applied to other radio access technologies. For example, in an LTE system, the NodeB and RNC in UTRAN correspond to a single node, the eNodeB, in LTE. Ciphering in LTE is similar to that in UTRAN, but it is performed at a Packet Data Convergence Protocol, PDCP, layer, and the sequence number range is not necessarily 7 bits but can be configured by upper layers (values: 5, 7, 12, 15). The input count is 32 bits and contains HFN and SN as in UTRAN. When the RLC is informed by MAC that a predetermined number of (consecutive) transmission errors has been detected, actions by RLC may include informing PDCP about the transmission errors. While the error detection and error correction mechanisms would be similar, the configuration and signaling would be different. For example, there is no need to signal between the RNC and the NodeB, and the RRC signaling between the RNC and UE would be handled by RRC signaling between the UE and eNodeB.
Indeed, the technology fully encompasses other embodiments which may become apparent to those skilled in the art. Reference to an element in the singular is not intended to mean “one and only one” unless explicitly so stated, but rather “one or more.” All structural and functional equivalents to the elements of the above-described embodiments that are known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be encompassed hereby. Moreover, it is not necessary for a device or method to address each and every problem sought to be solved by the described technology for it to be encompassed hereby.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SE2013/050480 | 4/30/2013 | WO | 00 |
| Number | Date | Country | |
|---|---|---|---|
| 61645762 | May 2012 | US | |
| 61754099 | Jan 2013 | US |
