Adjustable RLC Window for GSM/EDGE Latency Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In GSM/EDGE networks, the 'in sequence RLC delivery property' causes RLC blocks received within the receive window to be delayed at the upper layers, even if all corresponding LLC frames are completely received, leading to additional latency, which is detrimental for delay-sensitive services like VoIP, due to persistent retransmissions and minimum window size causing intrinsic latency.
Innovation Solution
The method involves setting a smaller transmit/receive window size for RLC/MAC radio blocks, with a notification message broadcast to adjust the window size to values lower than 64 blocks, allowing non-persistent mode retransmissions and in-sequence delivery of correctly received blocks, while discarding blocks outside the receive window, thereby reducing latency.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the minimum window size of 64 RLC/MAC blocks is used to ensure reliable retransmissions, then retransmission reliability is improved, but latency increases to 1,280 ms
Solution Approach 1:
The patent applies dynamics by making the RLC/MAC window size adjustable rather than fixed. The network can dynamically configure different window sizes (e.g., 16, 32, or 64 blocks) based on service requirements. For delay-sensitive services like VoIP, a smaller window size (16 blocks) is configured to reduce latency, while for reliability-critical services, a larger window size (64 blocks) is used. This dynamic adaptation resolves the contradiction between reliability and latency.
Solution Approach 2:
The patent changes the parameter of window size from a fixed minimum of 64 blocks to a configurable parameter that can be set to 16, 32, or 64 blocks. This parameter change allows the system to optimize for different service types: smaller values reduce latency for real-time services, while larger values maintain reliability for error-sensitive applications. The configuration is communicated through signaling messages between the network and mobile station.
2Reliability
If persistent retransmissions are used to ensure complete data delivery, then data completeness is improved, but latency increases for delay-sensitive services
Solution Approach 1:
The patent introduces dynamic retransmission modes: persistent mode for traditional data services and non-persistent mode for delay-sensitive services. In non-persistent mode, the transmitter does not continuously retransmit blocked data, allowing the receiver to proceed with in-sequence delivery after a certain number of attempts. This dynamic selection resolves the contradiction by matching the retransmission behavior to service requirements.
Solution Approach 2:
The patent changes the retransmission parameter from persistent (continuous) to non-persistent (limited attempts) based on service type. For delay-sensitive services, the system configures non-persistent retransmissions with a limited number of attempts, preventing indefinite retransmission delays. For reliability-critical services, persistent retransmissions continue until successful delivery. This parameter change enables the system to balance data completeness and latency.
3Stability of the object's composition
If in-sequence RLC delivery is enforced to maintain data order, then data ordering is improved, but latency increases as received blocks are delayed at upper layers
Solution Approach 1:
The patent applies dynamics by making the in-sequence delivery requirement configurable. For delay-sensitive services, the system can disable strict in-sequence delivery at the RLC layer, allowing out-of-sequence blocks to be delivered to the upper layers. The application layer can then handle reordering if needed. This dynamic approach resolves the contradiction by trading some ordering guarantee for reduced latency in real-time services.
Solution Approach 2:
The patent changes the delivery mode parameter from strict in-sequence to configurable delivery. The network can signal whether in-sequence delivery is required or if out-of-sequence delivery is acceptable. For VoIP and other real-time services, out-of-sequence delivery is permitted to minimize latency, while for file transfer and other data services, in-sequence delivery is maintained. This parameter change enables flexible trade-off between ordering and latency.
4Adaptability or versatility
If a larger receive window is used to buffer RLC blocks, then retransmission flexibility is improved, but intrinsic latency increases
Solution Approach 1:
The patent applies dynamics by making the receive window size configurable rather than fixed at a large default value. The network can set the receive window size (e.g., 16, 32, or 64 blocks) based on service requirements. For delay-sensitive services, a smaller window size is configured to reduce the buffering delay, while for services requiring high retransmission flexibility, a larger window size is used. This dynamic configuration resolves the contradiction between flexibility and latency.
Solution Approach 2:
The patent changes the receive window size parameter from a large fixed value to a configurable parameter. The system can select appropriate window sizes (16, 32, or 64 blocks) to match service requirements. Smaller window sizes reduce intrinsic latency for real-time services, while larger window sizes provide more flexibility for retransmissions in data services. This parameter change enables the system to optimize the trade-off between flexibility and latency.
Data Source
AI summary
Real-time media or multimedia services in 3GPP GSM/EDGE-compliant mobile radio networks call for reducing the actual latency of transmissions. Resources are assigned by the network to set up or reconfigure a TBF associated to the uplink/downlink transmission of radio blocks from/to an MS. A 5-bit "Coding" field is configured in the header of the involved RLC/MAC messages to select the transmitting/receiving window size. An additional signalling bit, also called scaling bit, is asserted/negated according to two opportunities offered by the new MAC protocol to properly select the window size. Thanks to the introduction of the scaling bit a subdivision of the time windows for type of services is made possible. Non real-time services, e.g. file transfer, avail of standard window sizes for MSs with multislot capability, as reported in 3GPP TS 44.060, V7.3.0 (2006-01), Release 7, subclause 9.1.9, for EGPRS TBFs. Delay-sensitive services, e.g. media or multimedia real-time transmissions, avail of new window sizes with scaled down values remapped to start from 1 to (maximum) 64 RLC/MAC blocks. The scaling bit is asserted or negated by BSC accordingly. Both peer entities comprised in a TBF are receiving the RLC/MAC messages with the proper setting of the scaling bit and the 5-bit coding IF; these entities decode the scaling bit and behave accordingly. The behaviour consists of either assuming the standard window size or scaled window size addressed by the same predetermined 5-bit "coding" information element (fig.3).