Technique for configuring link layer entities for a handover

Technology for configuring link layer entities for handover

The present invention relates generally to the field of handover in mobile communication networks. In particular, the present invention relates to handovers between link layer entities that control retransmission mechanisms.

A retransmission mechanism, also known as an automatic repeat request (ARQ) technique, constitutes a method for addressing data loss on its path to its intended recipient. This data loss may be the result of undesirable physical conditions such as interference, noise, or multipath propagation.

ARQ technology indicates to the transmitter that an individual data unit has been successfully received (positive acknowledgment) or lost (negative acknowledgment) based on a status report sent from the receiver of the data. In general, the receiver generates an event-based, timer-based or poll-based status report according to the specifications of the respective ARQ protocol. The status report may be scheduled at a certain point, for example, on time or after receipt of a certain number of data units.

The transmitter evaluates the received status report and decides on retransmission of individual data units that were not received or were not correctly received at the receiver. Some ARQ techniques provide for automatic retransmission of a data unit in which no positive acknowledgment is received within a predetermined time interval after the first transmission of the data unit.

Regarding the open systems interconnection (OSI) layer model, ARQ technology is always implemented on the data link layer (Layer 2 or L2). The data link layer is located between the physical layer (Layer 1 or L1) and the network layer (Layer 3 or L3) as represented by the protocol stack 10 shown on the left side of FIG.

The physical layer (L1) defines the electronic and physical specifications for the network components involved in data transmission. The data link layer (L2) provides a mechanism for data transmission between individual network components and for detecting and possibly correcting errors that may occur in the physical layer (L1). The network layer (L3) performs network routing, flow control, segmentation/desegmentation, and error control functions. The best known example of the L3 protocol is the Internet Protocol (IP).

Always on top of the network layer (L3) there is one or more additional layers. In the example shown on the leftmost side of Fig. 1, these additional layers include a transport layer L4 configured according to TCP (transmission control protocol) and an application layer L7 configured according to FTP (file transfer protocol). Although not part of the formal OSI model, additional protocols may operate between the data link layer (L2) and the physical layer (L1). These protocols are often referred to as "layer 2.5" protocols.

In the exemplary configuration shown in Figure 1, the data link layer (L2) is divided into two sub-layers, a radio link control (RLC) layer and a medium access control (MAC) layer, respectively. The ARQ technique is now the best case implemented within the RLC sub-layer, which will be described in more detail with reference to the right side of FIG. 1 .

In the configuration shown in Fig. 1, the RLC sub-layer comprises a first buffer 12 interacting with the network layer L3 and a second buffer 14 interacting with the MAC sub-layer. The first buffer 12 is provided for storing incoming service data units (SDUs) such as IP packets generated in the network layer L3. The SDUs stored in the first buffer 12 are read by the segmentation engine 18 which segments the SDUs 16 into RLC protocol data units (PDUs) 20 . On the other hand, the PDUs 20 are sent to the MAC sub-layer for transmission to the intended recipient, otherwise they are stored in the second buffer 14 for possible retransmission under the ARQ protocol framework.

At some point on time, the receiver of the PDUs makes a handover from a first network component (with a link layer entity having an RLC configuration as shown in Figure 1) to a second network component (with a similar link layer entity). may need In the following, some possible handover scenarios will be representatively described with reference to a process occurring at the data link layer.

In principle, handover from the original serving link layer entity to the new link layer entity may occur without previous buffer tuning as shown in FIG. In this case, when a handover is performed between two link layer entities, the stream of SDUs is switched from the old service link layer entity to the new link layer entity, and the buffers 12 and 14 of the old service link layer entity are Content is simply discarded. The resulting loss of buffered content will slow the operation of higher layers and may result in a temporary drop in quality of service.

According to the alternative handover scenario shown in Fig. 3, the handover is such that before switching the SDU stream from the current serving link layer entity to the new link layer entity, the contents of the SDU buffer 12 of the current serving link layer entity are transferred to the new link layer. may be performed to be transmitted to the entity's SDU buffer 12'. This process is also often referred to as the so-called L3 context transfer. In this case, only the contents of the PDU buffer 14 of the old service link layer entity are discarded. US 2004/0146033 A1 describes a representative technique for such L3 context transmission.

One disadvantage of the handover scheme shown in FIG. 3 is the fact that data loss caused by discarding the contents of the PDU buffer 13 may lead to service degradation. In addition, data loss can trigger higher layer protocol interactions with, for example, TCP at the transport layer (L4). This higher layer protocol interaction is illustrated in FIG. 4 . As can be gathered from the TCP trace shown in Figure 4, several TCP segments are lost in the instantaneous handover (see dark vertical line). The lost TCP segment must be retransmitted by TCP after the handover has occurred, which leads to a slow transmission start after the handover.

Additionally, loss of a TCP segment in an instantaneous handover may result in a TCP timeout. Thus, frequent handovers can lead to situations where the TCP sender cannot achieve a sufficiently high transmission rate, leading to radio link underutilization. This underutilization scenario is illustrated by the trace of the TCP congestion window CNWD shown in FIG.

One solution to avoid the problems shown in Figures 4 and 5 would be to do a practically lossless handover. This allows all data currently transmitted (and stored in the link layer PDU buffer) to be reconstructed. Thereafter, SDUs reconstructed from the contents of the PDU buffer may be transmitted to a new link layer entity in addition to transmission of the SDU buffer contents as shown in FIG.

However, it is shown that this reconstruction method can lead to unintentional data duplication as shown in the TCP trace of FIG. This data duplication is a result of the fact that some reconstructed SDUs have already been successfully transmitted to the receiver, but the corresponding PDUs have not yet been deleted from the PDU buffers.

The replication shown in Figure 6 tends to interfere with higher layer protocols such as TCP. TCP rejects two duplicate data packets along with sending a TCP replication acknowledgment back to the TCP sender, which leads to TCP error recovery. Replication grants lead to aspects of the TCP congestion window CNWD as shown in FIG. This aspect indicates that the radio link is not fully used most of the time. Obviously, this underutilization constitutes a waste of available resources.

Therefore, there is a need for an improved handover technique on the link layer level that is more compatible with the ARQ protocol.

According to a first aspect there is provided a method of configuring a link layer entity for handover, the link layer entity receiving a service data unit from a higher functional layer, converting the service data unit into a protocol data unit, Buffer protocol data units for transmission to a recipient under the ARQ protocol P with a status report, wherein the status report indicates receipt of one or more protocol data units at the recipient. The method includes receiving an additional status report from a receiver of a protocol data unit for an existing ARQ connection in terms of an upcoming handover, a service data unit corresponding to a buffered protocol data unit taking information contained in the additional status report into account and sending the determined service data unit to a link layer entity that establishes a new ARQ connection to the receiver.

This method may be implemented with respect to any ARQ technique, including sliding window ARQ, go-back(n) ARQ, range-based ARQ, and stop-and-wait ARQ. The additional status report may be constituted by a positive acknowledgment, a negative acknowledgment or any other ARQ message containing information about the current status of the recipient regarding previously transmitted protocol data units.

The additional status report considers the ARQ tuning between the link layer sender and the link layer receiver just before handover is performed. In some cases, the additional status report may be considered as an unscheduled report, since it may be generated by the recipient in addition to the status report generated in a normal transmission scenario, i.e. in a transmission scenario excluding the handover procedure. am.

In some cases, the method may further comprise stopping the transmission of the service data unit and/or the protocol data unit. This suspension is preferably done in close temporary relationship with the receipt of a further status report. According to a first option, the transmission of the protocol data unit is stopped in response to receipt of a further status report. According to another option, the transmission of the protocol data unit is stopped just before the reception of the additional status report, for example in response to the reception of information about the handover that is about to take place.

The method may additionally include requesting an additional status request from the recipient. If this request step is performed by a link layer entity that requires an additional status report, then the transmission of the protocol data unit may be stopped (e.g., just before or after) in a temporary relationship close to that for which the additional status report is requested from the recipient. . In some scenarios, the step of requesting an additional status report is initiated upon receipt of a notification regarding an upcoming handover.

Additional status reports may be requested from the recipient in several ways. The request for additional status reports may be included, for example, in a dedicated link layer message sent to the recipient. Additionally or alternatively, additional status reports may be requested via one or more radio resource management (RRM) messages. Alternatively or additionally, the additional status report may be received via one or more RRM control messages.

According to one variation, requesting the additional status report comprises sending a request instructing the recipient to unconditionally generate and transmit the additional status report. If such a request is received by the recipient, the recipient MUST ignore any condition that potentially prevents or delays the generation of a status report, such as an active status protection timer.

Determining the service data unit preferably excludes the service data unit corresponding to the protocol data correctly received at the recipient (as indicated in the additional status report). Thereby, a successfully transmitted protocol data unit may be deleted from the PDU buffer before starting the reconfiguration. Therefore, reconfiguration to this day is possible due to additional status reports and the resulting enhanced ARQ tuning that immediately handles upcoming handovers.

According to a first option, the step of determining the service data unit comprises the reconfiguration service data unit from the buffered protocol data unit taking into account the information contained in the further status report. According to another option, determining the service data unit comprises selecting the buffered service data unit corresponding to the buffered protocol data unit taking into account the information included in the additional status report. The service data units may be selected from a conventional SDU buffer (filled with service data units received from a higher functional layer, such as the SDU buffer 12 shown in Figure 1), or may have already been segmented or to be segmented into protocol data units. It can be selected from a separate SDU buffer containing only service data units.

As described above, service data units received from higher functional layers may be buffered in a link layer buffer. In such a scenario, the data context may be created from all determined service data units (eg, service data units reconstructed from protocol data units), and may additionally be created from all conventional buffered service data units. The transmitted data context is therefore also determined taking into account the information contained in the reconstructed service data unit or otherwise contained in the additional status report. Therefore, the data context may then be sent to the link layer entity establishing (or already established) a new ARQ connection to the receiver.

The present invention may be implemented in the form of a software solution, by one or more hardware components or as a combined software/hardware method. According to a software aspect, a computer program product is provided. The computer program product includes portions of program code for performing processing steps when the computer program product operates one or more computing devices. The computer program product may be stored on a computer-readable recording medium.

Regarding the hardware aspect, there is provided an apparatus for configuring a link layer entity for handover, wherein the link layer entity receives service data from a higher functional layer, converts the service data unit into a protocol data unit, and a state Buffer protocol data units for transmission to a recipient under the ARQ protocol framework with a report status report, wherein the status report indicates receipt of one or more protocol data units at the recipient. The device has a first interface for receiving an additional status report from the receiver of the protocol data unit for an existing ARQ connection in terms of an upcoming handover, a service corresponding to the buffered protocol data unit taking into account the information contained in the additional status report a mechanism for determining a data unit, and a second interface for sending the determined service data unit to a link layer entity that establishes a new ARQ connection to a receiver.

The device may be part of a system that additionally includes a recipient with a reporting mechanism that allows it to generate additional status reports for existing ARQ connections. A device may be integrated with or otherwise communicate with one or more link layer entities. The link layer entity may then be incorporated into a new component that may include one or more additional functional layers.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS In the following, the present invention will be described with reference to exemplary embodiments shown in the drawings.

1 is a schematic diagram showing, on the left, a protocol stack with a data link layer, and on the right, various mechanisms performed in the data link layer;

Fig. 2 is a schematic diagram illustrating a first handover procedure between two link layer entities;

3 is a schematic diagram illustrating a second handover procedure between two link layer entities;

Fig. 4 is a diagram showing data loss resulting in the handover procedure shown in Fig. 3;

Fig. 5 is a diagram illustrating a time-over aspect resulting in the data loss shown in Fig. 5;

Figure 6 illustrates data duplication resulting in unnecessary reconstructed SDUs;

Fig. 7 illustrates a TCP aspect in response to a copy acknowledgment resulting in data duplication shown in Fig. 6;

Fig. 8 is a schematic diagram showing an embodiment of a constituent device according to an embodiment of the present invention;

Fig. 9 is a schematic diagram showing a handover procedure and a system embodiment under the control of the apparatus of Fig. 8;

Fig. 10 is a schematic flowchart showing a method embodiment of the present invention;

11 is a schematic diagram showing an additional embodiment of the present invention; and

12 illustrates an improved TCP aspect resulting in an implementation of the present invention;

In the following description, specific details are set forth, such as specific sequences of steps, individual ARQ scenarios, and specific system configurations, for a thorough understanding of the present invention, for purposes of explanation and not limitation. It will be apparent to those skilled in the art that the present invention may be practiced in other embodiments that depart from these specific details. In particular, while embodiments are described in the context of TCP/IP, with respect to a specific ARQ mechanism, and with respect to a data link layer having certain configurations, the present invention may also be implemented in terms of other protocols and configurations.

Furthermore, those of ordinary skill in the art may be implemented using software functions relating to the programmed microprocessors or general purpose computers described herein and/or using application specific integrated circuits (ASICs). Furthermore, while the invention has been described primarily in the form of methods and apparatus, the invention may also be embodied in computer program products as well as systems comprising a computer processor and memory associated with said processor, the memory being described herein. One or more programs capable of performing the specified functions are encoded.

8 shows an embodiment of an apparatus 80 for configuring a link layer entity for handover. The device 80 comprises a first interface 82 for receiving (in terms of an upcoming handover) a further status report from the recipient of the protocol data unit. Therefore, the additional status report leads to the handover procedure. The status report belongs to the existing ARQ connection stretching between the first link layer entity and the receiver. Additional status reports may be received via the first interface 82 in addition to the normal status reports generated by the recipient pertaining to the conventional ARQ protocol.

Apparatus 80 also includes a mechanism 84 for determining (eg, reconfiguring or selecting) a service data unit corresponding to a buffering protocol data unit based on information included in the additional status report. Such information may indicate successful and/or unsuccessful reception of one or more protocol data units at the recipient. The additional status report therefore takes into account the tuning between the receiver and the first link layer entity communicating with the receiver via the existing ARQ connection. This tuning helps avoid transmission of service data units corresponding to buffered protocol data units that have already been successfully received by the recipient but have not yet been acknowledged by way of a "normal" status report.

Additionally, the device 80 provides a second interface 86 for transmitting the service data unit determined by the mechanism 84 to a second link layer entity that establishes a new ARQ connection to the receiver in view of the handover. include

This handover will now be described in detail with reference to FIG.

9 shows a network system 90 comprising two link layer entities 92 and 94 , a (common) controller 88 for link layer entities 92 and 94 , and a receiver 96 . Each of the two link layer entities 92 and 94 and the receiver have a protocol stack with a data link layer that may be similar to that shown in FIG. In addition, each link layer entity 92, 94 includes an apparatus 80 as shown in Figure 8 which implements the required handover configuration.

In one exemplary implementation, link layer entities 92 and 94 are incorporated into base stations or Node Bs according to universal mobile telecommunications system (UMTS) standards. The controller 88 may be configured as a UMTS radio network controller (RNC). In a UMTS context, the recipient 96 may take the form of a user equipment (UE), such as a mobile phone. Alternatively, link layer entities 92 and 94 may be integrated with controller 88 in a single RNC component.

It should be noted that the apparatus 80 and link layer entities 92 and 94 may be implemented on a terminal side, such as a UE (uplink), or on a network side (downlink). In a terminal scenario, the two link layer entities 92 and 94 may constitute two different PCMCIA cards coupled to the same terminal as, for example, a portable computer. Alternatively, the two link layer entities 92 and 94 may be incorporated in a dual mode terminal operating according to at least two wireless communication standards, such as UMTS and Global System for Mobile Communications (GSM).

As shown in FIG. 9 , there is an ARQ connection 98 stretching between the first link layer entity 92 and the receiver 96 . ARQ connection 98 constitutes a data and/or control channel with ARQ functionality. Due to the possible mobility of the recipient 96 or other environment, a handover between the first link layer entity 92 and the second link layer entity 94 may be required at some point in time. In the process of handover, a new ARQ connection 100 will be established between the second link layer entity 94 and the receiver 96 . After the new ARQ connection 100 is established (or, in an alternative embodiment, before), the existing ARQ connection 96 between the first link layer entity 92 and the receiver 96 may be terminated. In the course of the handover procedure, the data context will be transferred between the first network entity 92 and the second link layer entity 94 , as indicated by arrow 102 . The data context may be transferred between link layer entities 92 and 94 immediately or via controller 88 .

In the following, communication between the four network components 88 , 92 , 94 , 96 shown in FIG. 9 will be described from the perspective of the first link layer component 92 with reference to the flowchart 1000 of FIG. 10 .

The first link layer entity 92 always receives service data units from a higher functional layer such as the network layer L3 arranged in the controller 88 or any other network component. Link layer entity 92 converts these service data units into protocol data units and buffers the protocol data units for transmission under the framework of the ARQ protocol to receiver 96 . The ARQ protocol defines a typical status report indicating the receipt of one or more protocol data at the receiver 96 .

Referring now to FIG. 10 , the first link layer entity 92 performs an upcoming handover of the recipient 96 from the first link layer entity 92 to the second link layer entity 94 in a first step 101 . An additional status report is received from the receiver 96 for the existing ARQ connection 98 in terms of .

In a second step 1020 , the first link layer entity 92 determines a service data unit corresponding to the buffered protocol data unit taking into account the status information included in the additional status report received from the recipient 96 (eg, , reconfigure or select).

In a further step 1030 , the first link layer entity sends to the second link layer entity 94 a data context comprising at least the service data unit determined in step 102 as indicated by arrow 102 . . Additionally, the controller 88 will switch the service data stream from the first link layer entity 92 to the second link layer entity 94 . The second link layer entity 94 will then start sending protocol data units over the new ARQ connection to the receiver 96 taking into account the data context received from the first link layer entity 92 .

Next, an additional embodiment of the present invention will be described with reference to the schematic diagram shown in FIG. The embodiment shown in Fig. 11 may be combined with any one of the embodiments described with reference to Figs.

The process schematically illustrated in Fig. 11 is when a receiver of a PDU stream detects that it needs handover from a current serving link layer entity (left side of Fig. 11) to a new link layer entity (right side of Fig. 11) (e.g., by the controller 88 shown in Fig. 9). In this case, the current serving link layer entity is immediately notified of an upcoming handover. This notification triggers state tuning between the current service link layer entity and the PDU receiver (not shown in FIG. 11). State tuning can be performed in several ways.

In one embodiment, the current serving link layer entity (eg, RLC sub-layer) sends a newly defined link layer message (referred to as a Super-Poll Request) to the PDU receiver. The PDU receiver responds to the super-pol request with the generation of additional status reports and the transmission of these status reports to the current service link layer entity. What makes a super-poll request different from a conventional link layer is the fact that a super-poll request instructs the recipient to generate and send a status report in any case (even if the local health protection timer is running).

To reduce overall messaging, a handover-related super-poll request is included as an additional configuration of the handover procedure (typically performed via RRM messages in the Radio Resource Control (RRC) protocol) as a "default request". )" can be substituted. In this case, an additional status report may be automatically generated and transmitted from the recipient notified of the upcoming handover within a dedicated or handover-related RRM message. Consequently, the status report for the link layer connection to be changed may be included in the RRM message instead of sending it as a separate link layer message (eg, as in the super-pol request scenario described above).

From the point of view of receiving the handover notification and/or generating and sending the additional status request, the current serving link layer entity may selectively stop sending the PDU to the receiver. In addition, or alternatively, the transmission of the SDU to the current serving link layer entity may be stopped.

In response to receiving the additional status report from the recipient, the current service link layer entity updates its transmission status. This update step may include deleting or discarding any PDUs in the PDU buffer 14 shown in FIG. 11 that are positively acknowledged in the additional status report.

In the next step, the current service link layer entity reconstructs the SDU from the updated PDU buffer 14 for context transmission. Reconstruction starts only after the content of the additional status report has been considered. In an alternative embodiment, the SDU is not reconstructed from the updated PDU buffer 14, but (if the SDU read from the SDU buffer 12 for segmentation is not deleted from the SDU buffer 12 and is properly marked) SDUs selected from the SDU buffer 12, or SDUs that have been read for segmentation, are selected from a dedicated SDU buffer (not shown) that is temporarily stored for generation of a handover-related data context. In the selection scenario, these SDUs approved in the additional status report will not be selected for data context generation.

In the reconfiguration scenario, the current service link layer entity creates a data context from all the SDUs stored in the SDU buffer 12 and additionally from the reconstructed from the updated PDU buffer 14 . The data text containing the buffered and reconstructed SDU is then passed to the new link layer entity as indicated by the two arrows in FIG. In the new link layer entity, the SDU contained in the data context is stored in the local SDU buffer 12'. Consequently, this SDU buffer 12' will also contain the SDU corresponding to the reconstructed PDU from the updated PDU 14 of the current/previous service link layer entity.

In the final step, the SDU stream is switched to a new link layer entity as shown in FIG. 11, and the new link layer entity starts to transmit PDUs to the original receiver through the newly established ARQ connection.

As will become apparent from the above description, the embodiment contemplates lossless handover without duplication of an SDU that has already been successfully transmitted. As a result, negative interactions with higher layer protocols such as TCP can be avoided as shown in the diagram of FIG. As can be obtained from Fig. 12, the congestion window CNWD is only adjusted by SDU buffer overflow, but interference with TCP due to unintentional data duplication in handover cannot be notified.

It should be noted that the present invention can be used in a wide range of handover scenarios. These scenarios include intra-system handover, inter-system handover between multiple radio technologies (eg, access switches), handover between multiple access gateways in the Long Term Evolution (LTE) project of the Third Generation Partnership Project (3GPP). , and handover between 3GPP LTE Release 7 and Pre-Release 7 3GPP access. Additionally, the serving radio network system (SRNS) relocation mechanism within the 3GPP network may be improved for inter-RNC handover.

It will be appreciated by those skilled in the art that the embodiments described above may be adapted or extended in many ways. Therefore, while the above description refers to preferred embodiments, the scope of the present invention is limited only by the following claims and the elements recited herein.