RLC Data Unit Management for Transmission Stalling Prevention

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current RLC protocol in mobile communications fails to adequately detect lost or corrupted status reports, particularly those containing NACKs, leading to potential stalling of data transmission when the last block is sent, as it relies on receiving fresh data units rather than retransmitted units.

Innovation Solution

A data unit management apparatus with a retransmission request sender and a retransmitted data unit monitor that uses a timer to check for receipt of retransmitted data units within a predetermined period, avoiding the issue of stalling by focusing on retransmitted units which are within the current transmission window, and allowing action even if no data units are received.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Device complexity

If the RLC protocol relies on receiving fresh data units to detect lost status reports, then the detection mechanism is simple, but data transmission stalls when the last block is sent and no fresh data units are received

Engineering Contradiction:
Improvedetection mechanism complexityVSAvoiddata transmission continuity
Core Design Contradiction:
Device complexityVSProductivity

Solution Approach 1:

The system uses retransmitted data units themselves as the trigger for detection, rather than requiring external fresh data units. The retransmission request sender monitors for retransmitted units and uses their arrival to infer successful status report delivery, making the system self-sufficient even when no new data is being transmitted

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The system establishes a feedback loop where the arrival of retransmitted data units provides information about the successful delivery of status reports. This feedback mechanism allows the system to detect lost status reports by the absence of expected retransmitted units, maintaining transmission continuity through proactive monitoring

Inventive Principle:
Principle #23Feedback

2Reliability

If the system monitors for retransmitted data units within a predetermined period, then lost status reports are detected reliably, but the system requires additional timing and monitoring mechanisms

Engineering Contradiction:
Improvelost status report detection reliabilityVSAvoidtiming and monitoring mechanism complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system pre-configures a predetermined period for monitoring retransmitted data units before actually needing to detect a lost status report. This preliminary setup of the timer and monitoring window allows the system to reliably detect losses without complex real-time decision-making, as the detection criteria are established in advance

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system uses a predetermined time period parameter to transform the detection problem from a continuous monitoring task into a discrete time-window evaluation. By changing the monitoring approach to be time-bound rather than continuous, the system achieves reliable detection with simpler mechanisms

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS7525908B2Data unit management in communications
Publication Date: 2009.04.28 MALIKIE INNOVATIONS LTD
  • US7525908B2 patent drawing
  • US7525908B2 patent drawing
  • US7525908B2 patent drawing

AI summary

In Radio Link control (REC) apparatus, a mechanism is provided for detecting missing or corrupted data units at the receiving end of a transmission link, requesting retransmission and then monitoring the response to the retransmission request. Distinctively, a receiving communications entity 300 is equipped to act on a nil response. If no data unit is retransmitted, the receiving entity triggers at least one repeat retransmission request. This is the case even if no further data unit is received after the retransmission request is triggered. Retransmission requests are repeated up to a preset number, whereafter a different recovery mechanism is triggered.