IL195146A - Bi-directional rlc non-persistent mode for low delay services - Google Patents
Bi-directional rlc non-persistent mode for low delay servicesInfo
- Publication number
- IL195146A IL195146A IL195146A IL19514608A IL195146A IL 195146 A IL195146 A IL 195146A IL 195146 A IL195146 A IL 195146A IL 19514608 A IL19514608 A IL 19514608A IL 195146 A IL195146 A IL 195146A
- Authority
- IL
- Israel
- Prior art keywords
- timer
- rlc data
- rlc
- data block
- missing
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/10—Flow control between communication endpoints
- H04W28/14—Flow control between communication endpoints using intermediate storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1835—Buffer management
- H04L1/1838—Buffer management for semi-reliable protocols, e.g. for less sensitive applications such as streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1829—Arrangements specially adapted for the receiver end
- H04L1/1848—Time-out mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/1874—Buffer management
- H04L1/1877—Buffer management for semi-reliable protocols, e.g. for less sensitive applications like streaming video
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/12—Arrangements for detecting or preventing errors in the information received by using return channel
- H04L1/16—Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
- H04L1/18—Automatic repetition systems, e.g. Van Duuren systems
- H04L1/1867—Arrangements specially adapted for the transmitter end
- H04L1/188—Time-out mechanisms
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
BI-DIRECTIONAL RLC NON-PERSISTENT MODE FOR LOW DELAY SERVICES Bi-directional RLC non-persistent mode for low delay services FIELD OF THE INVENTION The present invention generally relates to radio access networks, and particularly relates to maintaining Quality-of-Service (QoS) for delay-sensitive applications such as Voice-over IP (VoIP) serviced by radio access networks.
BACKGROUND OF THE INVENTION Some radio access networks route data in packets. For example, a packet switched radio service such as the General Packet Radio Service (GPRS) is added onto an existing circuit-switched network such as the Global System for Mobile Communications (GSM) network to provide both circuit and packet switched communication services. Enhanced Data rates for GSM Evolution (EDGE) or Enhanced GPRS (EGPRS) is a digital mobile phone technology that allows for increased data transmission rates and improved data transmission reliability in GPRS/GSM networks. EDGE employs an 8-PSK modulation scheme which carries three times more information through an extended signal constellation.
GPRS/EDGE radio networks (GERANs) include a gateway GPRS support node (GGSN) and a serving GPRS support node (SGSN) for supporting packet switched communication. The GGSN provides a gateway between the radio network and the public switched packet data network and/or other GPRS networks. The GGSN implements authentication and location management functions. The SGSN controls connections between the radio network and mobile stations. The SGSN performs session management and GPRS mobility management such as handovers and paging. The Base Station Subsystem (BSS) component of a circuit-switched GSM network is updated to support packet switched data communication. For example, a Packet Control Unit (PCU) is provided for converting packet data into a format that can be transferred over the air interface to mobile stations.
Packet data is carried across several interfaces in a GERAN. At each interface, data is packetized according to a particular protocol. For example, application data is sent to a GERAN over the Internet as an IP datagram. The IP datagram is received at the GGSN as a Network Data Packet Unit (N-PDU) which is addressed to a particular IP address. The GGSN encapsulates the N-PDU using the GPRS tunneling protocol (GTP) by adding a GTP header that enables the possibility to tunnel the N-PDUs across GPRS core network. The GTP-PDU is passed to the UDP layer. The UDP layer adds an UDP header to the PDU. The header indicates source and destination port addresses. The UDP-PDU is then forwarded to an IP layer. The IP layer adds SGSN source and destination addresses. The IP layer segments the PDU into smaller units if the PDU is too long.
The IP-PDU is transferred to the SGSN where it is treated as an N-PDU. The SGSN removes the various headers added by the GGSN and provides the N-PDU to a Sub Network Dependent Convergence Protocol (SNDCP) layer. The SNDCP layer converts the N-PDU into a format compatible with the underlying GPRS network architecture. Upon completion, the SNDCP-PDU is passed to a Logical Link Control (LLC) layer. The LLC layer provides a logical connection between the SGSN and mobile stations served by the GERAN. The LLC layer encapsulates the SNDCP-PDU with an LLC header. A Base Station System GPRS Protocol (BSSGP) layer is located directly below the LLC layer and provides routing information so that the LLC-DPU is properly routed to the BSS (e.g. over a frame relay physical layer). The BSSGP operates between the SGSN and the BSS, i.e., the BSSGP does not extend over the air interface.
At the BSS, the LLC-PDU is provided to the Radio Link Control (RLC) layer. The RLC layer establishes a reliable link (e.g. if required by the QoS of the corresponding packet switched service) between the BSS and mobile station. The RLC layer performs segmentation and reassembly of upper-layer PDUs (LLC PDUs in this example) into RLC data blocks. As used herein, the term "upper-layer" means protocol layers above the RLC layer. RLC data blocks consist of an RLC header, an RLC data unit, and spare bits. The RLC data blocks are then passed to a Medium Access Control (MAC) layer which encapsulates the blocks with MAC headers. The MAC layer controls access signaling across the air interface, including the assignment of uplink and downlink radio blocks which are used to carry the RLC data blocks. The data is then transmitted to a mobile station over the air interface via the physical layer. To this end, a Temporary Block Flow (TBF) is established between the BSS and mobile station. The TBF is a logical connection between the BSS and mobile station over which the data is transferred. One or more dynamic (shared) or fixed (dedicated) packet data channels (timeslots) may be assigned when a TBF is established. At the mobile station, the data is received at the physical layer and encapsulation headers are removed from the received data as it moves up the mobile station protocol stack. Eventually, the original application data is received at the application layer.
However, the mobile station may not receive all RLC data blocks after initial transmission by the BSS, e.g., due to poor radio conditions, transmission errors, etc. Similarly, the BSS may not receive the initial transmission of any given RLC data block sent by a mobile station. An RLC data block is considered received when it is received in a layer 1 frame with consistent parity bits as defined in Release 7 of the 3rd Generation Partnership Project RLC/MAC Protocol (3GPP TS 44.060 V7.7.0). RLC data blocks may also be received out-of- order. Each transmitted RLC data block has a sequence number indicating the position of that RLC data block within a sequence of RLC data blocks.
Release 7 of the 3GPP RLC/MAC Protocol enables an RLC receiver endpoint to handle missing RLC data blocks in one of three ways. Case 1 : When operating in RLC acknowledged mode, the RLC receiver endpoint sends a packet acknowledged/ not acknowledged (ACK/NACK) message to the RLC transmitter endpoint indicating which RLC data blocks are missing. The RLC transmitter endpoint then re-transmits the missing RLC data blocks. Missing RLC data blocks are retransmitted indefinitely in RLC acknowledged mode though the RLC protocol may experience stalling should the number of outstanding (unacknowledged) RLC data blocks grow too large at the RLC transmitting endpoint. Case 2: The RLC transmitter endpoint does not re-transmit any RLC data blocks when operating in RLC unacknowledged mode. Accordingly, in RLC unacknowledged mode missing RLC data blocks are ignored at the RLC receiver endpoint. Case 3: In RLC non-persistent mode, a limited number of RLC data block retransmissions are possible. However, it is not required that all RLC data blocks be correctly received at the RLC receiver endpoint.
For RLC acknowledged mode, the RLC endpoints maintain a sliding window of RLC data blocks based on block sequence numbers (BSN). The sliding window has a predefined width (e.g., 64 blocks for GPRS and 64 to 1024 blocks for EDGE). The RLC receiver endpoint continues to request retransmission of all missing RLC data blocks within the sliding window via a packet ACK/NACK message. This conventional sliding window based approach associated with RLC acknowledged mode is also used for RLC non-persistent mode. The conventional sliding window based approach is used for determining which RLC data block should be negatively acknowledged (NACK) by the receiving RLC endpoint or re-transmitted by the transmitting RLC endpoint. However, it creates QoS issues for delay-sensitive applications such as VoIP given the relatively long round-trip signal propagation times associated with the receiving RLC endpoint sending a NACK to transmitting RLC endpoint and the subsequent retransmission of missing RLC data blocks. Delay-sensitive applications such as VoIP have maximum packet data transfer delay constraints that must be met to assure sufficient QoS from a user perspective. For example, maximum mouth-to-ear speech frame propagation for VoIP is typically 300 ms or less. Missing speech frames received after a 300 ms delay may result in user perception of degraded speech call quality.
For example, based on current radio conditions, a low-throughput Modulation and Coding Scheme (e.g., MCS-1) is selected as the coding scheme for a bi-directional TBF established to support a VoIP service. A particular form of header compression (e.g. robust header compression or ROHC) is also negotiated when the TBF is established (e.g. by the SNDCP layer). Accordingly, one or more RLC data blocks are transmitted over the air interface for each RTP/UDP/IP PDU with header compression being applied by SNDCP (i.e. for VoIP, the full protocol stack involves RTP/UDP/IP/SNDCP/LLC PDUs being carried by one or more RLC data blocks). Further, for packet services having a low transfer delay attribute (such as VoIP), RLC non-persistent mode is selected instead of RLC acknowledged in order to avoid issues resulting from considering all RLC data blocks covered by the sliding RLC window as inherently valid and always subject to re-transmission. This way, a limited number of retransmissions can be made (if necessary) for each RLC data block in an effort to achieve an acceptably low frame error rate without exceeding a maximum overall transfer delay as allowed by the VoIP application when conveying speech frames over the air interface. In other words, RLC non- persistent mode establishes the validity of RLC data based on considering a transfer delay threshold established at TBF set up time (applicable to both the receiving and transmitting RLC endpoints) while still maintaining the use of the sliding RLC window concept (but not using it to determine the validity of RLC data blocks).
An RLC window size is established by explicit control plane signaling and is configured for both RLC acknowledged mode and RLC non-persistent mode. Though still configured for RLC non-persistent mode, the RLC window size in this case is not used to determine whether or not a missing RLC data block having a sequence number within the sliding RLC window is considered as valid (i.e. still considered as expected by the receiving RLC endpoint and still considered as being subject to re-transmission by the transmitting RLC endpoint). To demonstrate how relying on a fixed RLC window size is not sufficient to determine the validity of missing RLC data blocks for delay sensitive applications (such as VoIP), the following example is presented.
A nominal fixed RLC window size can be established (at initial TBF establishment) based on the ratio X of RLC data blocks required to carry RTP/UDP/IP PDUs required for a given modulation and coding scheme (MCS). Assuming MCS-1 , 20 ms of speech per speech (RTP) frame and X = 2, the window size could, for example, be set to 8X, meaning 16 RLC data blocks carrying 8 RTP frames (RTP/UDP/IP PDUs) and therefore speech payload as old as 160 ms would be considered valid. As time progresses, radio conditions may improve so that the payload-bearing capacity of each RLC data block doubles (e.g., to MCS-4). At this point, the number of RLC data blocks required to transmit a RTP/UDP/IP PDU is cut in half (i.e. X reduces to 1 ). Thus, with up to 16 RLC data blocks permitted by the RLC window size, RTP frames as old as 320 ms would effectively be considered as valid based on the initially established window size. Such variations in the amount of time allowed for conveying RTP frames across the air interface can result in exceeding the QoS delay attribute for the VoIP application. Of course, radio conditions may improve beyond MCS-4 as considered here such that buffered RLC data blocks even older than 320 ms would then be considered as valid. This fixed RLC window size approach causes a similar issue at the RLC receiver endpoint where missing RLC data blocks are still expected even though they have been missing for a period of time that exceeds the QoS delay attribute for the VoIP application. It should also be noted that any attempt to dynamically re-negotiate the RLC window size as radio conditions change will in practice be too cumbersome (i.e., control plane signaling intensive) and may actually result in generating service interruptions that would be perceived as a reduced QoS experience.
The nominal fixed RLC window size approach can also cause RTP speech frames to be prematurely considered as no longer valid as shown in the following example. When the MCS coding scheme selected during initial TBF establishment is somewhat higher (e.g. MCS-4), an average of Y RLC data blocks are required to carry each RTP frame (RTP/UDP/IP PDU) transmitted over the air interface. Assuming MCS-4, 20 ms of speech per speech (RTP) frame and Y = 1 , the window size could, for example, be set to 8Y, meaning 8 RLC data blocks carrying 8 RTP frames (RTP/UDP/IP PDUs) and therefore speech payload as old as 160 ms would be considered valid. As time progresses, radio conditions may deteriorate so that the payload bearing capacity of each RLC data block is cut in half (e.g. to MCS-1 ). When this occurs, the number of RLC data blocks transmitted for each RTP/UDP/IP PDU doubles (i.e. Y increases to 2). Accordingly, the previously established window size now allows RLC data blocks containing speech payload no older than 80 ms to be considered as valid. Thus, when radio conditions deteriorate, the amount of time for which buffered RLC data blocks (at the transmitting RLC endpoint) or missing RLC data blocks (at the receiving RLC endpoint) are considered valid may be excessively small, resulting in an unnecessarily high speech frame error rate.
In another example, the MCS scheme, number of RLC data blocks per RTP/UDP/IP PDU, header compression, size of a speech sample carried by a single RTP frame and window size are the same as in the first two examples. However, we now consider a temporary stoppage in the flow of speech payload (e.g. when a user stops speaking). The fixed RLC window size approach will once again result in less than optimal performance as follows. When a user stops speaking, the RLC transmitter endpoint may still generate supervisory frames or 'keep alive' frames (i.e. Silence Descriptor frames also known as SID frames). Since SID frames contain less payload than RTP frames and are sent less often than RTP frames (e.g. the equivalent of every 8th RTP frame), the overall rate at which RLC data blocks are transmitted is significantly reduced for the period of time where there are no actual speech frames requiring transmission. However, this may result in a reduced buffering demand which may in turn result in the RLC data blocks containing speech frame payload buffered before the silent period was entered as being considered as valid for an excessively long period of time because the RLC window size is fixed and it takes longer for the window edges to be reached (i.e. due to a reduced RLC data block throughput rate experienced during the silent period). Lengthening the time for which RLC data blocks (containing speech frame payload) are considered valid can therefore result in exceeding the QoS delay attribute for the VoIP application as described earlier. Once again, this same scenario can produce a similar issue at the RLC receiver endpoint where missing RLC data blocks are considered valid (i.e. still expected) for longer periods of time than they should be.
In yet another example, the MCS scheme, number of RLC data blocks per RTP/UDP/IP PDU, header compression, size of a speech sample carried by a single RTP frame and window size are the same as in the first two examples. However we now consider low header compression efficiency during TBF establishment typically followed by a subsequent increase (i.e. improvement) in compression efficiency as time goes by. Changes in compression efficiency may then also occur (e.g. due to cell change accomplished using handover) well after the VoIP session has been initially established and a good level of compression efficiency has been established. During periods of low compression efficiency, the number of RLC data blocks required to transmit each RTP/UDP/IP PDU is high (i.e. since RTP/UDP/IP PDUs are larger during periods of low compression efficiency). Further, the fixed RLC window size that is established at initial TBF establishment typically assumes relatively high compression efficiency as would be applicable during steady state conditions. Accordingly, during periods of low compression efficiency, RLC data blocks may quickly become considered as falling outside the fixed (but sliding) RLC window, and thus become treated as invalid (by both the transmitting and receiving RLC endpoints) when in reality they may be well within the transfer delay time allowed for by the delay QoS attribute of the corresponding VoIP application.
SUMMARY OF THE INVENTION According to the methods and apparatus taught herein, the transfer delay QoS for delay-sensitive packet services (such a VoIP) can be satisfied in radio access networks by determining the validity of packet data payload at both the receiving and transmitting RLC endpoints based on a maximum data transfer delay constraint instead of a sliding RLC window size approach. On the transmitter side, a timer-based packet buffering approach is employed when transmitting delay-sensitive packet data such as VoIP data packets. Transmitted packet data is buffered for a period of time determined by the transfer delay timer value established at initial TBF establishment (i.e. where the allocated transfer delay value is a reflection of the transfer delay QoS attribute for the packet data application supported by the allocated TBF). Buffered RLC data blocks are deleted after the corresponding transfer delay timer expires, thus preventing subsequent retransmission of the deleted (and no longer valid) RLC data blocks.
On the receiver side, a timer-based packet retransmission request approach is similarly employed when an RLC data block is detected as missing. An RLC data block detected as missing at the receiver is expected to be received until the corresponding transfer delay timer expires. The missing RLC data block is no longer expected to be received when its corresponding transfer delay timer expires. The corresponding application layer may then be provided with a partially completed version (i.e. an erroneous version) of the RTP/UDP/IP PDU for which one or more missing RLC data blocks are no longer expected.
The maximum data transfer delay constraint preferably depends on the application type. The data transfer delay over the air interface is approximately 100 ms for VoIP data packets. As such, transmitted RLC data blocks that remain buffered for about 100 ms after initial transmission are deleted from memory at the RLC transmitter endpoint. Similarly, RLC data blocks at the RLC receiver endpoint continue to be expected for approximately 100 ms after first being detected as missing after which they will be invalidated. In another embodiment, the value of the packet data transfer delay attribute is approximately three seconds or less for Multimedia Broadcast Multicast Service (MBMS) based applications.
According to one embodiment, upper-layer packet data units (PDUs) associated with an application having a maximum data transfer delay constraint are transferred by starting a timer responsive to initial transmission of an RLC data block associated with one or more upper-layer PDUs (e.g., LLC PDUs). The timer is initialized to a timer value that is based on the maximum data transfer delay constraint. So long as the timer has not expired, the RLC data block is retransmitted responsive to a received message indicating its reception is unacknowledged. The RLC data block is deleted from memory responsive to the timer expiring or a received message indicating its reception is acknowledged. The value of the timer may be determined upon initial TBF establishment (e.g. based on the transfer delay QoS attribute of the corresponding packet service).
According to another embodiment, the receiving RLC endpoint detects a missing RLC data block in the sequence of one or more transmitted RLC data blocks associated with the one or more upper-layer PDUs. A timer is started responsive to detecting the missing RLC data block. The timer is initialized to a timer value that is based on the maximum data transfer delay constraint. The missing RLC data block is expected to be received until the timer expires. The missing RLC data block may be deleted from memory at the point the timer expires.
Of course, the present invention is not limited to the above features and advantages. Those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS In order to understand the invention and to see how it may be carried out in practice, embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which: Figure 1 is a block diagram of one embodiment of a radio access network.
Figure 2 illustrates an embodiment of processing logic for buffering transmitted data packets at a transmitter based on a maximum data transfer delay constraint.
Figure 3 illustrates an embodiment of processing logic for processing missing data packets at a receiver based on a maximum data transfer delay constraint.
DETAILED DESCRIPTION OF EMBODIMENTS Figure 1 illustrates an embodiment of a GPRS/EDGE Radio Access Network (GERAN) 100. The GERAN 100 supports both circuit switched and packet switched communication. The GERAN 100 transmits data packets to a mobile device 102 such as a mobile phone over a downlink communication channel 104 also known as a downlink TBF. Of course, the GERAN 100 may transmit the same data packets to multiple devices (not shown) using a point-to- multipoint transmission approach such as Multimedia Broadcast Multicast Service (MBMS). For ease of explanation only, operation of the GERAN 100 is described herein with reference to a point-to-point communication link between the GERAN 100 and the single mobile device 102. However, those skilled in the art will readily recognize the techniques disclosed herein apply equally to point-to-multipoint transmission schemes.
The GERAN 100 implements a timer-based packet buffering approach when transmitting delay-sensitive data packets such as VoIP data packets. The timer-based packet buffering approach does not determine the ongoing validity of packet data based on whether or not the corresponding RLC data blocks remain within a sliding RLC window. Instead, transmitted data packets are buffered by the GERAN 100 for an amount of time determined by the transfer delay QoS attribute corresponding to the application being serviced. The transmission time constraint indicated by the application being serviced is referred to herein as maximum data transfer delay. Maximum data transfer delay corresponds to the maximum amount of time allowed for the transmission and reception of a data packet beyond which the packet is considered invalid and is determined by the transfer delay QoS attribute of the delay-sensitive application being serviced. At the transmitting RLC endpoint, located within either BSS 122 or mobile device 102, each transmitted upper layer PDU (i.e. an LLC PDU) is buffered (using one or more RLC data blocks) for an amount of time corresponding to the data transfer delay indicated by the application being serviced. A buffered RLC data block is deleted when stored longer than the allowed data transfer delay, thus ensuring adherence to the transfer delay QoS attribute of delay-sensitive applications as will be described in more detail later.
In the BSS 122, buffered RLC data blocks are available for retransmission upon request from the mobile device 102, e.g., in response to a packet being negatively acknowledged (i.e., responsive to a packet NACK message received from the mobile device 102 in RLC non-persistent mode). A packet NACK message indicates which RLC data blocks have not been received by the mobile device 102, e.g., because RLC data blocks have been received out-of-order at the mobile device 102. This way, the BSS 122 retransmits missing RLC data blocks to the mobile device 102 so long as the corresponding data transfer delay has not been exceeded. In addition, upon identifying an out-of-sequence RLC data block, the mobile device 102 starts a corresponding timer 132 used to determine the period of time for which it will continue to expect that missing RLC data block. When the timer 132 expires, the mobile device 102 no longer expects the missing RLC data block or any other additional RLC data blocks corresponding to the same upper layer PDU and may therefore generate an incomplete (i.e. erroneous) upper layer PDU. Generating an incomplete upper layer PDU may prove more beneficial than producing no upper layer PDU at all in this case. In one embodiment, the air interface data transfer delay is approximately 100 ms for VoIP data packets. Buffered VoIP data packets (i.e. all buffered RLC data blocks used to transmit a given VoIP data packet) are deleted if stored longer than 100 ms before a corresponding packet acknowledged (packet ACK) message is received from the mobile device 102, thus enforcing the QoS for the VoIP application.
The mobile device 102 implements a similar timer-based packet retransmission request approach for uplink communication. During uplink communication, the BSS 122 receives RLC data blocks from the mobile device 102 over an uplink communication channel 106 also known as an uplink TBF. According to this embodiment, the BSS 122 requests retransmission of missing RLC data blocks, e.g., by sending a packet NACK message to the mobile device 102. The BSS 122 expects to receive a missing RLC data block until the data transfer delay required by the application has been exceeded in a similar manner as previously described for packet data sent over the downlink communication channel 104. When this occurs, the BSS 122 no longer expects to receive the missing RLC data block or any other additional RLC data blocks corresponding to that same upper layer PDU and may therefore immediately generate an incomplete (i.e. erroneous) upper layer PDU.
The mobile device 102 implements the similar timer-based packet data buffering and retransmission request approaches used by the BSS 122 when servicing a delay-sensitive application. That is, the mobile device 102 stores RLC data blocks it transmits over the uplink communication channel 106 until the RLC data blocks are buffered longer than allowed by the maximum data transfer delay required by the application being serviced. RLC data blocks buffered longer than allowed as indicated by the data transfer delay are deleted. In a downlink configuration, the mobile device 102 expects to receive missing RLC data blocks over the downlink communication channel 104 until the maximum data transfer delay constraint is exceeded. RLC data blocks missing longer than indicated by the corresponding packet data transfer delay QoS attribute are no longer expected by the mobile device 102. This way, the transfer delay QoS attribute is enforced for the delay-sensitive application being serviced.
For example, a low-throughput Modulation and Coding Scheme such as MCS-1 may be used when radio conditions are poor. Each upper-layer Packet Data Unit (PDU) used to convey VoIP data such as an RTP/UDP/IP PDU may include 20 ms of speech data when encoded using MCS-1. The coding scheme may be upgraded when radio conditions improve, e.g., to MCS-4. The number of RLC data blocks needed to transmit upper-layer VoIP PDUs is cut in half when the coding scheming is upgraded from MCS-1 to MCS-4. The maximum data transfer delay constraint specified by the VoIP application therefore remains constant regardless of how radio conditions may change during the course of a delay-sensitive application.
In more detail, the GERAN 100 includes a GSM Gateway Mobile Switching Center (GMSC) 108 for providing a gateway between the GERAN 100 and the Public-Switched Telephone Network (PSTN) 1 10. The GERAN 100 also includes a Mobile services Switching Center (MSC) and a Visitor Location Register (VLR) 1 12 for supporting circuit-switched communication. The MSC/VLR 1 12 performs circuit switching functions, provides connections to other circuit-switched networks (not shown), and contains subscriber information necessary for providing circuit switched services. A central database 114 maintains the Home Location Register (HLR) which contains information associated with each mobile phone subscriber authorized to use the GERAN 100.
The GERAN 100 further includes complementary components for supporting packet switched communication. A Gateway GPRS Support Node (GGSN) 116 provides a gateway between the GERAN 100 and the public switched packet data network 1 18 and/or other GPRS networks (not shown). The GGSN 116 implements authentication and location management functions. The GERAN 100 also includes a serving GPRS support node (SGSN) 120 that controls connections between the GERAN 100 and the mobile device 102. The SGSN 120 performs session management and GPRS mobility management such as handovers and paging. The SGSN 120 has access to a GPRS register maintained by the central database 1 14 which stores SGSN addresses and maintains GPRS subscriber data and routing information. The GERAN 100 further includes a Base Station Subsystem (BSS) 122 for handling traffic and signaling between the mobile device 102 and the GERAN 100. The BSS 122 transcodes speech channels, allocates radio channels, performs paging, manages quality of transmission and reception over the air interface and many other tasks related to the GERAN 100 as is well known in the art.
For ease of explanation only, operation of the BSS 122 and mobile device 102 is described next with reference to a downlink data packet transfer from the BSS 122 to mobile device 102. As such, the BSS 122 implements the timer-based packet buffering approach when transmitting data packets (carried using one or more RLC data blocks) to the mobile device 102. The mobile device 102 implements the timer-based retransmission request approach when receiving data packets from the BSS 122. However, in an uplink configuration, the timer-based packet data buffering approach is implemented by the mobile device 102 when the mobile device transmits data packets to the BSS 122. Correspondingly, in the uplink case, the BSS 122 implements the timer-based retransmission request approach when receiving data packets from the mobile device 102 over the uplink communication channel 106. With this understanding, the term "wireless receiver" as used herein shall mean the device receiving data packets (carried using one or more RLC data blocks) and the term "wireless transmitter" as used herein shall mean the device transmitting the data packets.
Turning now to the BSS 122, a processor 124 included in the BSS 122 manages data packet operations including protocol stack management. The BSS processor 124 may be fully implemented in hardware, partially in hardware and partially in software, or completely in software. Regardless, the BSS processor 124 enables coherent communication between the mobile device 102 and the SGSN 120. For example, the SGSN 120 communicates with the BSS 122 using an upper-layer protocol layer such as the Logical Link Control (LLC) protocol layer. The mobile station 102 communicates with the BSS 122 at a lower protocol layer such as the Medium Access Control (MAC) and RLC protocol layers. The BSS processor 124 converts upper-layer LLC PDUs to RLC and MAC blocks and vice versa.
The BSS processor 124 also manages packet buffering when transmitting data packets (carried within one or more RLC data blocks) to the mobile device 102 over a fixed or dynamic downlink communication channel 104 such as a GPRS/EDGE packet data traffic channel (PDTCH). The BSS processor 124 generates RLC data blocks from application data such as VoIP packet data. Downlink VoIP packet data arrives at the GERAN 100 as an IP datagram. The GGSN 1 16 and SGSN 120 process the VoIP data which arrives at the BSS 122 as a group of LLC PDUs. The BSS processor 124 converts the LLC PDUs to RLC data blocks based on the BSS protocol stack. The BSS processor 124 then generates a Temporary Block Flow (TBF) establishment message, e.g., a packet downlink assignment message. The TBF establishment message is transmitted to the mobile device 102. In response, a TBF is established between the BSS 122 and mobile device 102 where the TBF is a dynamic physical connection over which the RLC data blocks are transferred.
Each RLC data block is stored in a buffer 126 included in the BSS 122 before it is transmitted, e.g., as illustrated by Step 200 of Figure 2. The RLC data blocks are then transmitted over the downlink communication channel 104, e.g., as illustrated by Step 202 of Figure 2. The BSS processor 124 starts a timer 128 included in or associated with the processor 124 each time an RLC data block is transmitted. The timer 128 is initialized to a value that is based on the maximum data transfer delay constraint for the corresponding VoIP application. The data transfer delay constraint may be derived from the transfer delay QoS attribute established as part of Packet Data Protocol (PDP) context data structure present at both the SGSN 120 and GGSN 1 16 which contains the subscriber's session QoS attributes applicable for each PDP Context activated. In one embodiment, the application is VoIP based and the data transfer delay is approximately 100 ms. Accordingly, the timer 128 is initialized to a value of approximately 100 ms. In another embodiment, the application is MBMS-based. According to this embodiment, the timer 128 is initialized to a data transfer delay value of approximately three seconds or less.
The timer 128 begins to countdown from its initialized state when the corresponding RLC data block is initially transmitted by the BSS 122, e.g., as illustrated by Step 204 of Figure 2. The BSS processor 124 periodically monitors the current timer value for each transmitted RLC data block to determine whether one or more of the timers 128 have expired, e.g., as illustrated by Step 206 of Figure 2. If an instance of timer 128 has expired, the BSS processor 124 deletes the corresponding RLC data block from the buffer 126, e.g., as illustrated by Step 208 of Figure 2. This way, the RLC data block will not be retransmitted responsive to a subsequent packet NACK message received from the mobile device 102. The BSS processor 124 may start only one instance of timer 128 when the first of potentially multiple RLC data blocks required to transmit a given upper layer PDU is buffered since all of the RLC data blocks must be successfully transmitted to the RLC receiving endpoint before timer 128 expires (i.e. it may not be necessary to start an instance of timer 128 for each of these RLC data blocks).
The BSS processor 124 also removes an RLC data block from the transmit buffer 126 even before its timer 128 expires when a packet ACK message is received from the mobile device 102 indicating the RLC data block was received, e.g., as illustrated by Steps 210 and 208 of Figure 2. A buffered RLC data block is retransmitted responsive to a packet NACK message if the message is received before the instance of timer 128 associated with the RLC data block expires, e.g., as illustrated by Steps 212 and 214 of Figure 2. This way, an RLC data block identified as missing by the mobile device 102 may be retransmitted so long as the block's timer 128 has riot expired.
The timer value used by the BSS processor 124 may either be explicitly transmitted to the mobile device 102 or derived from the transfer delay QoS attribute established at PDP Context activation time so the mobile device 102 can use it when processing the RLC data blocks transmitted by the BSS 122. The mobile device 102 may use the timer value to determine when to no longer expect a missing RLC data block. The mobile device 102 may also use the timer value to determine when the mobile device 102 should stop re-transmitting an RLC data block to the BSS 122 for which the BSS 122 has not yet acknowledged the corresponding reception. In one embodiment, the maximum data transfer delay constraint is provided to the mobile device 102, e.g., as part of the PDP context activation procedure used to determine the QoS attributes (including transfer delay) applicable to the TBFs (used in support of that PDP Context) over which the RLC data blocks are transmitted. In another embodiment, the timer value used by the BSS timer 128 is provided to the mobile device 102, e.g., as an IE portion of a message.
Regardless, the mobile device 102 is also instructed when to establish the ongoing validity of missing downlink RLC data blocks based on the maximum data transfer delay constraint. In one embodiment, the BSS processor 124 programs an IE in the TBF establishment message used to establish the downlink TBF over which the RLC data blocks are transmitted by the BSS 122. For example, one or more unused bits in the window size IE of an EDGE TBF establishment message may be programmed by the BSS processor 124 to indicate the mobile device 102 is to establish the ongoing validity of missing downlink RLC data blocks based on the maximum data transfer delay constraint. A processor 130 included in the mobile device 102 inspects the appropriate IE in the TBF establishment message to determine whether the mobile device 102 is to establish the ongoing validity of missing downlink RLC data blocks based on the maximum data transfer delay constraint. Otherwise, the mobile device 102 establishes the ongoing validity of missing downlink RLC data blocks based on the conventional sliding RLC window approach.
A timer 132 included in or associated with the mobile device processor 130 supports the timer-based packet retransmission request approach at the mobile device 102 when instructed to do so by the BSS processor 124. The mobile device timer 132 tracks the age of missing downlink RLC data blocks, i.e., RLC data blocks expected, but not yet received by the mobile device 102. A new timer is started each time an RLC data block is initially detected as missing, e.g., as illustrated by Step 300 of Figure 3. An RLC data block is detected as missing when one or more RLC data blocks are received out-of-order as indicated by the sequence number included as part of each transmitted RLC data block. The mobile device timer 132 is initialized to a value based on the maximum data transfer delay constraint previously received by the mobile device 102. The raw data transfer delay itself may be used as the timer value or the mobile device 102 may take into account typical air interface transmission time intervals to account for time that may already have elapsed (since initial transmission by the BSS) when it detects an RLC data block to be missing.
The mobile device processor 130 periodically determines whether the mobile device timer 132 has expired for each detected missing RLC data block, e.g., as illustrated by Step 302 of Figure 3. If a timer expires before the corresponding RLC data block is received, the missing RLC data block is invalidated by the mobile device processor 130, e.g., as illustrated by Step 304 of Figure 3. The mobile device 102 no longer expects to receive invalidated RLC data blocks. Instead, the mobile device processor 130 may then generate an incomplete (i.e. erroneous) upper layer PDU instead of sending no upper layer PDU at all.
The mobile device processor 130 continues to expect missing RLC data blocks whose respective timers 132 have not yet expired. If a timer 132 has not expired and the corresponding RLC data block has not yet been received, the mobile device processor 130 requests retransmission of the missing RLC data block, e.g., as illustrated by Steps 306 and 308 of Figure 3. A missing RLC data block received before its timer 132 expires is considered valid by the mobile device processor 130. A valid RLC data block is processed by removing encapsulation headers as the data packet is processed up the mobile device protocol stack by the mobile device processor 130, e.g., as illustrated by Step 310 of Figure 3. When transmitting uplink RLC data blocks to the BSS 122, the mobile device 102 also maintains a timer that has the same function as described above for timer 128 in BSS 122. In a similar fashion when receiving uplink RLC data blocks from the mobile device 102, the BSS 122 maintains a timer that has the same function as described above for timer 132 in the mobile device 102.
With the above range of variations and applications in mind, it should be understood that the present invention is not limited by the foregoing description, nor is it limited by the accompanying drawings. Instead, the present invention is limited only by the following claims, and their legal equivalents.
It will also be understood that the invention contemplates a machine-readable program being readable by a CPU for executing the method of the invention. The invention further contemplates a machine-readable memory tangibly embodying a program of instructions executable by the machine for executing the method of the invention.
Claims (19)
1. A method of transferring upper-layer packet data units (PDUs) associated with an application having a maximum data transfer delay constraint, comprising: starting a timer responsive to initial transmission of a radio link control (RLC) data block associated with one or more of the upper-layer PDUs, the timer initialized to a timer value that is based on the maximum data transfer delay constraint; re-transmitting the RLC data block responsive to a received message indicating reception of the RLC data block is unacknowledged so long as the timer has not expired; transmitting the timer value to one or more wireless receivers configured to receive the upper-layer PDUs; instructing- the one or more wireless receivers to use the timer value when processing received RLC data blocks, wherein instructing the one or more wireless receivers to use the timer value when processing received RLC data blocks comprises programming an information element in a temporary block flow (TBF) establishment message, the information element configured to instruct the one or more wireless receivers to use the timer value when processing missing RLC data blocks by generating an incomplete upper-layer PDU; and deleting the RLC data block from memory responsive to the timer expiring or a received message indicating reception of the RLC data block is acknowledged.
2. The method of claim 1 , further comprising initializing the timer to approximately one hundred milliseconds when the application is voice-over internet protocol based.
3. The method of claim 1 , further comprising initializing the timer to approximately three seconds or less when the application is multimedia broadcast multicast service based.
4. The method of claim 1 , wherein transmitting the timer value comprises including the timer value as an information element in a message transmitted to the one or more wireless receivers.
5. A wireless transmitter for transferring upper-layer packet data units (PDUs) associated with an application having a maximum data transfer delay constraint, the wireless transmitter comprising: - 18 - 195146/2 a timer configured to begin counting responsive to initial transmission of a radio link control (RLC) data block associated with one or more of the upper-layer PDUs, the timer initialized to a timer value that is based on the maximum data transfer delay constraint; a buffer configured to delete the RLC data block from the buffer responsive to the timer expiring or a received message indicating reception of the RLC data block is acknowledged; and a processor configured to re-transmit the RLC data block responsive to a received message indicating reception of the RLC data block is unacknowledged so long as the timer has not expired, transmit the timer value to one or more wireless receivers configured to receive the upper-layer PDUs, instruct the one or more wireless receivers to use the timer value when processing received RLC data blocks, and program an information element in a temporary block flow (TBF) establishment message, the information element configured to instruct the one or more wireless receivers to use the timer value when processing missing RLC data blocks by generating an incomplete upper-layer PDU.
6. The wireless transmitter of claim 5, wherein the processor is further configured to initialize the timer to approximately one hundred milliseconds when the application is voice-over internet protocol based.
7. The wireless transmitter of claim 5, wherein the processor is further configured to initialize the timer to approximately three seconds or less when the application is multimedia broadcast multicast service based.
8. The wireless transmitter of claim 5, wherein the processor is configured to include the timer value as an information element in a message transmitted to the one or more wireless receivers.
9. A method of receiving one or more upper-layer packet data units (PDUs) associated with an application having a maximum data transfer delay constraint, comprising: detecting a missing radio link control (RLC) data block in a sequence of one or more transmitted RLC data blocks associated with the one or more upper-layer PDUs; starting a timer instance responsive to detecting the missing RLC data block, the timer initialized to a timer value that is based on the maximum data transfer delay constraint; - 19 - 195146/2 indicating missing RLC data blocks are processed based on the timer value, wherein indicating missing RLC data blocks are processed based on the timer value comprises generating a message responsive to a received temporary block flow (TBF) establishment message, the TBF establishment message including an information element configured to instruct the use of the timer value when processing missing RLC data blocks by generating an incomplete upper-layer PDU; and expecting to receive the missing RLC data block until the timer expires.
10. The method of claim 9, further comprising initializing the timer to approximately one hundred milliseconds when the application is voice-over internet protocol based.
11. The method of claim 9, further comprising initializing the timer to approximately three seconds or less when the application is multimedia broadcast multicast service based.
12. The method of claim 9, further comprising retrieving the timer value from an information element included in a received message.
13. The method of claim 9, further comprising deleting the missing RLC data block from memory responsive to the timer expiring before the missing RLC data block is received.
14. A wireless receiver for receiving one or more upper-layer packet data units (PDUs) associated with an application having a maximum data transfer delay constraint, the wireless receiver comprising a processor configured to: detect a missing radio link control (RLC) data block in a sequence of one or more transmitted RLC data blocks associated with the one or more upper-layer PDUs; start a timer instance responsive to detecting the missing RLC data block, the timer initialized to a timer value that is based on the maximum data transfer delay constraint; indicate missing RLC data blocks are processed based on the timer value; generate a message responsive to a received temporary block flow (TBF) establishment message, the TBF establishment message including an information element configured to instruct the use of the timer value when processing missing RLC data blocks by generating an incomplete upper-layer PDU; and expect to receive the missing RLC data block until the timer expires. - 20 - 195146/2
15. The wireless receiver of claim 14, wherein the processor is further configured to initialize the timer to approximately one hundred milliseconds when the application is voice over internet protocol based.
16. The wireless receiver of claim 14, wherein the processor is further configured to initialize the timer to approximately three seconds or less when the application is multimedia broadcast multicast service based.
17. The wireless receiver of claim 14, wherein the processor is further configured to retrieve the timer value from an information element included in a received message.
18. The wireless receiver of claim 14, wherein the processor is further configured to delete the missing RLC data block from memory responsive to the timer expiring before the missing RLC data block is received.
19. A machine-readable memory bearing program code means for performing the method according to any one of claims 1 to 4 or 9 to 13 when said program is run on a CPU. For the Applicants, WOLFF, BREGMAN AND GOLLER By: _ , .
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US80076006P | 2006-05-16 | 2006-05-16 | |
US11/684,020 US7848287B2 (en) | 2006-05-16 | 2007-03-09 | Bi-directional RLC non-persistent mode for low delay services |
PCT/EP2007/054273 WO2007131880A1 (en) | 2006-05-16 | 2007-05-03 | Bi-directional rlc non-persistent mode for low delay services |
Publications (2)
Publication Number | Publication Date |
---|---|
IL195146A0 IL195146A0 (en) | 2009-09-22 |
IL195146A true IL195146A (en) | 2012-08-30 |
Family
ID=38283901
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
IL195146A IL195146A (en) | 2006-05-16 | 2008-11-06 | Bi-directional rlc non-persistent mode for low delay services |
Country Status (12)
Country | Link |
---|---|
US (1) | US7848287B2 (en) |
EP (1) | EP2018731B1 (en) |
JP (1) | JP5009978B2 (en) |
KR (1) | KR20090009250A (en) |
CN (1) | CN101444033B (en) |
DK (1) | DK2018731T3 (en) |
ES (1) | ES2388750T3 (en) |
HK (1) | HK1132857A1 (en) |
IL (1) | IL195146A (en) |
MY (1) | MY147694A (en) |
TW (1) | TWI415433B (en) |
WO (1) | WO2007131880A1 (en) |
Families Citing this family (55)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8839065B2 (en) * | 2011-07-29 | 2014-09-16 | Blackfire Research Corporation | Packet loss anticipation and pre emptive retransmission for low latency media applications |
US8098601B2 (en) * | 2007-03-23 | 2012-01-17 | Research In Motion Limited | Slow adaptation of modulation and coding for packet transmission |
CA2690430A1 (en) * | 2007-06-15 | 2008-12-18 | Research In Motion Limited | System and method for link adaptation overhead reduction |
KR101116095B1 (en) * | 2007-06-15 | 2012-02-13 | 리서치 인 모션 리미티드 | System and method for semi-persistent and dynamic scheduling and discontinuous reception control |
KR101486352B1 (en) | 2007-06-18 | 2015-01-26 | 엘지전자 주식회사 | Method of controlling uplink synchronization state at a user equipment in a mobile communication system |
KR101470637B1 (en) * | 2007-06-18 | 2014-12-08 | 엘지전자 주식회사 | Method for enhancing radio resource and informing status report in mobile telecommunications system and receiver of mobile telecommunications |
KR101341515B1 (en) | 2007-06-18 | 2013-12-16 | 엘지전자 주식회사 | Method of updating repeatedly-transmitted information in wireless communicaiton system |
WO2008156314A2 (en) | 2007-06-20 | 2008-12-24 | Lg Electronics Inc. | Effective system information reception method |
US8149768B2 (en) | 2007-06-20 | 2012-04-03 | Lg Electronics Inc. | Method of transmitting data in mobile communication system |
EP2176969B1 (en) * | 2007-08-10 | 2012-11-28 | LG Electronics Inc. | Methods of setting up channel in wireless communication system |
KR101467789B1 (en) | 2007-08-10 | 2014-12-03 | 엘지전자 주식회사 | A control method for uplink connection of idle terminal |
KR101392697B1 (en) | 2007-08-10 | 2014-05-19 | 엘지전자 주식회사 | Method for detecting security error in mobile telecommunications system and device of mobile telecommunications |
GB2464427B (en) * | 2007-08-10 | 2012-04-04 | Lg Electronics Inc | Method of reporting measurement result in wireless communication system |
KR101495913B1 (en) * | 2007-08-10 | 2015-02-25 | 엘지전자 주식회사 | Method for transmitting and receiving control data in mobile telecommunications system and transmitter and receiver of mobile telecommunications |
WO2009022836A2 (en) | 2007-08-10 | 2009-02-19 | Lg Electronics Inc. | A random access method for multimedia broadcast multicast service(mbms) |
KR20090016431A (en) * | 2007-08-10 | 2009-02-13 | 엘지전자 주식회사 | A method of performing channel quality report in a wireless communication system |
KR101490253B1 (en) | 2007-08-10 | 2015-02-05 | 엘지전자 주식회사 | Method of transmitting and receiving control information in a wireless communication system |
KR20090016412A (en) * | 2007-08-10 | 2009-02-13 | 엘지전자 주식회사 | Method of data communication in a wireless communication system |
KR101461965B1 (en) | 2007-08-14 | 2014-11-14 | 엘지전자 주식회사 | A method of transmitting and processing data block of specific protocol layer in wireless communication system |
US20090046639A1 (en) * | 2007-08-14 | 2009-02-19 | Zhijun Cai | System and Method for Handling Large IP Packets During VoIP Session |
CN103327536B (en) * | 2007-09-13 | 2016-07-06 | Lg电子株式会社 | The method of transmission buffer state report in a wireless communication system |
KR101461970B1 (en) | 2007-09-13 | 2014-11-14 | 엘지전자 주식회사 | Method of performing polling procedure in a wireless communication system |
KR100937432B1 (en) | 2007-09-13 | 2010-01-18 | 엘지전자 주식회사 | Method of allocating radio resources in a wireless communication system |
ES2378267T3 (en) | 2007-09-14 | 2012-04-10 | Research In Motion Limited | System and method for the start time of discontinuous reception control |
KR101513033B1 (en) * | 2007-09-18 | 2015-04-17 | 엘지전자 주식회사 | A method for qos guarantees in a multilayer structure |
KR101591824B1 (en) | 2007-09-18 | 2016-02-04 | 엘지전자 주식회사 | Method of performing polling procedure in a wireless communication system |
KR101435844B1 (en) | 2007-09-18 | 2014-08-29 | 엘지전자 주식회사 | Method of transmitting a data block in a wireless communication system |
WO2009038377A2 (en) | 2007-09-20 | 2009-03-26 | Lg Electronics Inc. | Method of effectively transmitting radio resource allocation request in mobile communication system |
US8432841B2 (en) * | 2007-10-25 | 2013-04-30 | Unwired Planet, Llc | Methods and arrangements in a radio communications system |
WO2009057941A2 (en) * | 2007-10-29 | 2009-05-07 | Lg Electronics Inc. | A method for repairing an error depending on a radion bearer type |
WO2009096731A2 (en) * | 2008-01-31 | 2009-08-06 | Lg Electronics Inc. | Method for signaling back-off information in random access |
KR101594359B1 (en) | 2008-01-31 | 2016-02-16 | 엘지전자 주식회사 | Method of signaling back-off information in random access |
EP3410623B1 (en) | 2008-01-31 | 2021-07-28 | LG Electronics Inc. | Method for sending status information in mobile telecommunications system and receiver of mobile telecommunications |
KR101163275B1 (en) | 2008-03-17 | 2012-07-05 | 엘지전자 주식회사 | Method for transmitting pdcp status report |
US8151155B2 (en) * | 2008-06-06 | 2012-04-03 | Redpine Signals, Inc. | Packet Re-transmission controller for block acknowledgement in a communications system |
EP2347619B1 (en) * | 2008-10-16 | 2013-04-03 | Telefonaktiebolaget L M Ericsson (PUBL) | Apparatus and method of controlling sporadic transmissions of silence insertion descriptor (sid) |
US20100260098A1 (en) | 2009-04-10 | 2010-10-14 | Qualcomm Incorporated | Header compression for ip relay nodes |
CN102292940B (en) * | 2009-04-20 | 2014-04-02 | 华为技术有限公司 | Communication method and apparatus for header compression adopting ARQ mechanism |
US9729350B1 (en) * | 2010-05-07 | 2017-08-08 | Amazon Technologies, Inc. | Maintaining packet order in network flows over an autonomous network |
CN102348231B (en) * | 2010-07-28 | 2016-07-20 | 中兴通讯股份有限公司 | A kind of subscriber equipment and the method reporting RLF correlation measurement information thereof |
US9055464B2 (en) * | 2011-07-07 | 2015-06-09 | Optis Cellular Technology, Llc | RLC Data transmission control based on UE memory capacity |
US20130070581A1 (en) * | 2011-09-20 | 2013-03-21 | Cambridge Silicon Radio Limited | Controlling Data Transmission |
US9298560B2 (en) | 2013-05-16 | 2016-03-29 | Tektronix Texas, Inc. | System and method for GTP session persistence and recovery |
US9942846B2 (en) * | 2013-12-05 | 2018-04-10 | Qualcomm Incorporated | Delaying radio link control retransmissions |
KR102265454B1 (en) * | 2014-04-11 | 2021-06-15 | 삼성전자 주식회사 | Apparatus and method for improving communication quality in mobile communication network |
WO2016073263A1 (en) * | 2014-11-06 | 2016-05-12 | Commscope Technologies Llc | High-speed capture and analysis of downlink data in a telecommunications system |
US10420012B2 (en) * | 2015-09-14 | 2019-09-17 | Prodatakey, Inc. | Adaptive unicast timeout for a wireless network having optimized routing |
KR102410581B1 (en) * | 2015-10-30 | 2022-06-17 | 삼성전자주식회사 | Method and apparatus for controlling uplink data transmission in wireless communication system |
SG11201903123XA (en) | 2016-10-11 | 2019-05-30 | Lg Electronics Inc | Method for applying reflective quality of service in wireless communication system, and device therefor |
CN108365924B (en) | 2017-01-26 | 2021-02-12 | 华为技术有限公司 | Data retransmission method and communication device |
MX2019009533A (en) | 2017-02-13 | 2019-09-16 | Ericsson Telefon Ab L M | Technique for monitoring a radio communication. |
CN106911434B (en) * | 2017-02-23 | 2020-10-27 | 广州林邦信息科技有限公司 | Data retransmission prevention method and system |
US10750520B2 (en) * | 2017-04-27 | 2020-08-18 | Qualcomm Incorporated | Radio link control/packet data convergence protocol window advance with holes |
CN111082899A (en) * | 2018-10-19 | 2020-04-28 | 中兴通讯股份有限公司 | Transmission method, device and system |
TWI784120B (en) * | 2019-01-17 | 2022-11-21 | 韓商愛思開海力士有限公司 | Memory controller for stoarge device, stoarge device, control method for storage device, and recording medium |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3101475B2 (en) * | 1993-11-16 | 2000-10-23 | キヤノン株式会社 | Wireless communication device |
FI114768B (en) * | 1999-03-11 | 2004-12-15 | Nokia Corp | An improved method and arrangement for transmitting information in a packet radio service |
US6519223B1 (en) * | 1999-04-06 | 2003-02-11 | Telefonaktiebolaget L M Ericsson (Publ) | System and method for implementing a semi reliable retransmission protocol |
EP1198107B1 (en) * | 2000-10-07 | 2012-11-28 | LG Electronics Inc. | Method for transmitting data from an RLC layer in a radio communication system |
FR2840758B1 (en) * | 2002-06-11 | 2004-11-26 | Evolium Sas | METHOD FOR SUPPORTING REAL-TIME TRAFFIC IN A MOBILE RADIO COMMUNICATION SYSTEM |
US6999447B2 (en) * | 2002-06-26 | 2006-02-14 | Motorola, Inc. | VOIP transmitter and receiver devices and methods therefor |
US6937564B2 (en) * | 2003-05-30 | 2005-08-30 | Nokia Corporation | Management of downlink TBF in an EGPRS and in a GPRS mobile station using final block indicator and relative reserved block period field |
JP4668207B2 (en) | 2003-12-29 | 2011-04-13 | エレクトロニクス アンド テレコミュニケーションズ リサーチ インスチチュート | Packet retransmission method in mobile communication system and computer-readable recording medium on which program is recorded |
US20060146745A1 (en) * | 2005-01-05 | 2006-07-06 | Zhijun Cai | Method and apparatus for scheduling and synchronizing a multimedia broadcast/multicast service |
-
2007
- 2007-03-09 US US11/684,020 patent/US7848287B2/en active Active
- 2007-05-03 CN CN2007800174779A patent/CN101444033B/en not_active Expired - Fee Related
- 2007-05-03 WO PCT/EP2007/054273 patent/WO2007131880A1/en active Application Filing
- 2007-05-03 ES ES07728726T patent/ES2388750T3/en active Active
- 2007-05-03 EP EP07728726A patent/EP2018731B1/en not_active Not-in-force
- 2007-05-03 JP JP2009510397A patent/JP5009978B2/en not_active Expired - Fee Related
- 2007-05-03 DK DK07728726.6T patent/DK2018731T3/en active
- 2007-05-03 KR KR1020087028118A patent/KR20090009250A/en not_active Application Discontinuation
- 2007-05-15 TW TW096117242A patent/TWI415433B/en not_active IP Right Cessation
-
2008
- 2008-11-06 IL IL195146A patent/IL195146A/en active IP Right Grant
- 2008-11-14 MY MYPI20084606A patent/MY147694A/en unknown
-
2009
- 2009-11-09 HK HK09110399.7A patent/HK1132857A1/en not_active IP Right Cessation
Also Published As
Publication number | Publication date |
---|---|
US7848287B2 (en) | 2010-12-07 |
CN101444033B (en) | 2012-07-18 |
TW200807992A (en) | 2008-02-01 |
TWI415433B (en) | 2013-11-11 |
DK2018731T3 (en) | 2012-07-23 |
WO2007131880A1 (en) | 2007-11-22 |
EP2018731B1 (en) | 2012-06-13 |
JP5009978B2 (en) | 2012-08-29 |
EP2018731A1 (en) | 2009-01-28 |
ES2388750T3 (en) | 2012-10-18 |
HK1132857A1 (en) | 2010-03-05 |
US20070268861A1 (en) | 2007-11-22 |
CN101444033A (en) | 2009-05-27 |
JP2009538011A (en) | 2009-10-29 |
MY147694A (en) | 2012-12-31 |
KR20090009250A (en) | 2009-01-22 |
IL195146A0 (en) | 2009-09-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
EP2018731B1 (en) | Bi-directional rlc non-persistent mode for low delay services | |
AU2003276747B2 (en) | Method for moving a receive window in a radio access network | |
US9674832B2 (en) | Method and apparatus for layer 2 ARQ for packets | |
US7181667B2 (en) | Method and apparatus for modulating radio link control (RLC) ACK/NAK persistence to improve performance of data traffic | |
EP1695462B1 (en) | Transmitting and receiving control protocol data unit having processing time information | |
US7940771B2 (en) | Apparatus and method for requesting packet retransmission in a wireless communication system | |
US20120140704A1 (en) | Method and apparatus for controlling downlink data transmission in a multi-hop relay communication system | |
US20080101290A1 (en) | Apparatus for Arq Controlling in Wireless Portable Internet System and Method Thereof | |
KR20070077798A (en) | Method for requesting and transmitting status report of a mobile communication system and therefor apparatus | |
KR20070102167A (en) | Method and apparatus for performing automatic retransmission request in mobile telecommunication system | |
KR101197887B1 (en) | Method and apparatus for transmitting and receiving status report of automatic repeat request in mobile telecommunication system | |
KR101201046B1 (en) | Method and Apparatus for retransmitting a control message in a mobile communication system | |
KR101298580B1 (en) | Method and apparatus for transmitting/receiving for packet decoding information of packet service in mobile telecommunication system |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FF | Patent granted | ||
KB | Patent renewed | ||
KB | Patent renewed | ||
KB | Patent renewed | ||
KB | Patent renewed |