WO2025210182A1 - Procédé de gestion de transmission de données dans réseau de communication - Google Patents

Procédé de gestion de transmission de données dans réseau de communication

Info

Publication number
WO2025210182A1
WO2025210182A1 PCT/EP2025/059180 EP2025059180W WO2025210182A1 WO 2025210182 A1 WO2025210182 A1 WO 2025210182A1 EP 2025059180 W EP2025059180 W EP 2025059180W WO 2025210182 A1 WO2025210182 A1 WO 2025210182A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdu
receiver
retransmission
sdu
rlc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2025/059180
Other languages
English (en)
Inventor
Yacine El Kolli
Pierre Visa
Pascal Lagrange
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Europe Ltd
Canon Inc
Original Assignee
Canon Europe Ltd
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from GB2404850.6A external-priority patent/GB2640205A/en
Application filed by Canon Europe Ltd, Canon Inc filed Critical Canon Europe Ltd
Publication of WO2025210182A1 publication Critical patent/WO2025210182A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • 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/1607—Details of the supervisory signal
    • H04L1/1685—Details of the supervisory signal the supervisory signal being transmitted in response to a specific request, e.g. to a polling signal
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets

Definitions

  • the present disclosure relates to a method for managing data in a communication network (e.g., a mobile telecommunication network). More particularly, the method is directed towards managing data in a communication network configured to operate in a radio link control acknowledge mode (RLC AM).
  • a communication network e.g., a mobile telecommunication network
  • RLC AM radio link control acknowledge mode
  • a T_reassembly timer can be reduced (or even set to 0), which increases the responsiveness of the RLC receiver once the sequence number gap is detected. But reducing the t-reassembly timer increases the number of false missing detections, which can then increase the overheads across the network. Accordingly, there is a need to manage the retransmission of data during RLC AM operating conditions in order improve the operating efficiency of such communication networks.
  • the PDU having an unknown status may be selected for retransmission based on a sequence number of the PDU associated with the first PDU Set. For example, retransmission of the last PDU of a PDU Set may be prioritised. Alternatively, if the PDU is not the last in the sequence of the PDU Set, then retransmission of the PDU according to the present method may not proceed (e.g., the PDU retransmission may be delayed, or retransmitted using legacy data management methods).
  • the retransmitted PDU may be selected for retransmission based on the remaining time for transmission of the first PDU Set.
  • Retransmission may be determined (e.g., configured, or controlled) on the basis of the PDU having an unknown status being the last PDU in a transmission window, and at least one other PDU of the PDU Set is ready to be transmitted.
  • Retransmission may be determined on the basis of the PDU having an unknown status being the nth last PDU in a transmit window, and at least one other PDU of the PDU Set is ready to be sent.
  • Retransmission may be determined on the basis of a transmit window having not been updated for a predetermined amount of time.
  • the notification may be generated based on the detection of a gap in the sequence of the PDUs received by the receiver.
  • the notification may be generated based on a duplicate detection of a PDU being received by the receiver.
  • the notification may be generated at the end of a timer set by the receiver.
  • the method may comprise at least one of the following method steps: transmitting, to the receiver, one or more protocol data units; receiving, from the receiver, a first notification indicating a status of the one or more PDUs; determining (e.g., identifying, inferring, estimating, calculating or deciding), based on the first notification, at least one PDU of the one or more PDUs having an unknown status.
  • the one or more PDUs may be associated with the same PDU Set.
  • the method step of determining the status of the PDU may comprise transmitting a first PDU of a PDU Set; transmitting, after the first PDU, a second PDU of the PDU Set; and receiving a (first) notification indicating that the status of only one of the transmitted PDUs (e.g., the first PDU but not the second PDU).
  • the polling bit may be transmitted to the receiver in a header of a PDU sent by the transmitter.
  • FIGS. 10 and 11 are flow charts illustrating the second method implemented at the RLC transmitter
  • the processor 215 is configured to execute machine readable instructions. Execution of these machine-readable instructions causes the UE to perform various functions. These functions may relate to transmission and/or interaction with peripheral devices like for instance a keyboard, a screen, a mouse, etc. (not shown in Figure 2).
  • the processor may run an operating system, such as iOS, Windows, Android, etc.
  • the processor 215 may be a single processor or may comprise two or more processors carrying out the processing required for the operation of the UE 205.
  • the core network communication manager355 manages communications of the base station with the core network. It may provide a standardized NG interface, as defined by the 3GPP standard, to support these communications.
  • the transceiver 335 is configured to provide bi-directional wireless communication with other wireless devices. These devices may be UEs, or even other base stations.
  • the transceiver 335 provides the necessary modems and frequency shifters in order to connect to a large number of UEs simultaneously, using different frequency carriers, in Time Division Duplex (TDD) or in Frequency Division Duplex (FDD).
  • the transceiver 335 may include a PDCP transmitter and a PDCP receiver.
  • the PDCP transmitter and the PDCP receiver may be implemented by the processor 315.
  • the PDCP transmitter and the PDCP receiver may be a software only functions implemented by the processor 315.
  • the transceiver 335 is connected to the antenna set 345, which may be limited to one antenna, but preferably it contains several antennas, in order to provide beamforming capability.
  • FIG 4 is a block schematic diagram illustrating the data plane protocol stack of a 5G NR systems as represented in Figure 1 .
  • the data plane protocol stack is described in detail in 3GPP document TS 23.501.
  • an application server 103 connects to the user plane function (UPF) 161 through a data network 160 at the level of PDU layer 402.
  • the PDU layer corresponds to the PDUs carried between the UE and the data network (DN) over the PDU session.
  • the PDU session type is IPv4 or IPv6 or IPv4v6
  • the PDUs correspond to IPv4 packets, IPv6 packets, or both.
  • the PUDs correspond to Ethernet frames; etc.
  • the core network provides session QoS parameters to the UPF, gNB and UE.
  • the PDU session QoS parameters includes the XR PDU set QoS parameters (S2-2302696):
  • PSER PDU Set error rate
  • PDU Set integrated handling indication (PSIHI), which is also previously known as a PDU Set integrated indication.
  • a PDU refers to a packet which is handled (e.g., managed or processed) by the PDU layer 402.
  • the other types of PDU are handled by the other layers. Accordingly, the PDUs belonging to one of the other layers (i.e., other than the PDU layer 402) is referred to herein with the prefix corresponding to the respective layer name, e.g., a PDCP PDU, or MAC PDU.
  • the UPF When the PDUs arrive at the UPF PDU layer 402, the UPF performs an application packet inspection to determine the PDU Set boundaries.
  • 3GPP document S2-2302696 provides examples on how to identify PDU Sets when inspecting RTP/SRTP header, RTP header extension, H.264 RTP payload, H.265 RTP payload and H.266 RTP payload.
  • PDU Set identification information as described in 3GPP document S2-2303842 is determined by the UPF and sent to the NG-RAN in the GTP-U header.
  • the PDU Set identification Information comprises:
  • a PDU Set importance which identifies the relative importance of a PDU Set compared to other PDU Sets within a QoS flow.
  • the UPF detects the PDU Set identification information and obtains from the core network a set of mapping rules (e.g., filtering rules).
  • the filtering rules define how each PDU Set is mapped to a QoS flow.
  • The, or each, QoS flow is identified by an identifier, and the GTP-U PDUs are marked according to the determined QoS flow identifier.
  • the relay layer 406 extracts PDU Set identification information and the QoS flow identifier from the GTP-U PDUs and maps them into the SDAP QoS flow(s).
  • an XR session e.g., a single XR session
  • multiple PDU Sets can be mapped to the same QoS flow.
  • one or more PDU Sets may be mapped to different QoS flows.
  • each SDAP QoS flow can be mapped to a different PDCP Data Radio Bearer (DRB).
  • DRB PDCP Data Radio Bearer
  • all of the SDAP QoS flows from the same XR session can be mapped to a PDCP DRB (e.g., a single PDCP DRB).
  • the UE detects the PDU Set identification information at the PDU layer 402, and obtains from the core network a set of mapping rules (e.g., filtering rules).
  • the filtering rules define how each PDU Set is mapped to the QoS flow(s).
  • the UE maps the XR PDUs to associated SDAP QoS flows according to the filtering rules. Similar to during downlink, during uplink multiple PDU Sets can be mapped to the same, or different, QoS flow(s) in an XR session (e.g., a single XR session).
  • the application layer 103 During downlink, the application layer 103 generates at least one application flow toward at least one UE (e.g., a single UE), for example one or more video flows and one or more audio flows. Then at the PDU layer 402, the application flows are arranged in PDU Sets. Each application flow is divided into multiple PDU Sets of the same, or different, types. Then, within the GTP-U layer404, each PDU Set type is mapped onto the QoS flows, so multiple application flows can be multiplexed in a QoS flow (e.g., a single QOS flow). Alternatively, each application flow can be mapped to a different QoS flow. Further alternatively, it is also possible that an application flow is divided into multiple QoS flows.
  • a QoS flow e.g., a single QOS flow
  • the SDAP layer 407 maps the QoS flows into DRBs, each DRB being handled (e.g., managed or processed) by a dedicated PDCP entity.
  • each DRB being handled (e.g., managed or processed) by a dedicated PDCP entity.
  • multiple application flows can be multiplexed in a single DRB.
  • each application flow can be mapped to a different DRB.
  • an application flow e.g., a single application flow
  • the application layer 403 During uplink, the application layer 403, generates at least one application flow towards the application server 103, for example one or more video flows, one or more audio flows, one or more sensing flow. Then at the PDU layer 402, the application flows are arranged in PDU Sets. At least one, or each, application flow is divided in multiple PDU Sets of same or different types and each PDU Set type is mapped on QoS flows, so multiple application flows can be multiplexed in one QoS flow, or each application flows can be mapped to different QoS. It is also possible that an application flow is divided into multiple QoS flows. Then the SDAP layer 407 maps the QoS flows into DRBs.
  • At least one, or each, radio bearer is handled (e.g., managed or processed) by a dedicated PDCP entity.
  • a dedicated PDCP entity e.g., a dedicated PDCP entity.
  • multiple application flows can be multiplexed in one DRB (e.g., a single DRB), or each application flow can be mapped to separate DRBs. Further alternatively, it is possible that an application flow (e.g., a single application flow) is divided into multiple DRBs.
  • At least one, or each, DRB is mapped to at least one RLC channel which in turn is mapped to at least one MAC logical channel (LCH).
  • LCH MAC logical channel
  • some of the XR data may have a PDU Set Delay Budget (PSDB) which must not be overrun because it then becomes obsolete (e.g., useless to the decoder) after the delay period has elapsed.
  • PSDB PDU Set Delay Budget
  • some information may be available regarding the reception status of the PDUs and the elapsed time of the PSDB.
  • the gNB can detect whether a PDU transmission has failed (e.g., despite attempted retransmissions and error correction mechanisms).
  • the decoder can only handle (e.g., manage or process) a complete application data packet which is received on time (e.g., if the PSIHI is “true”), then any remaining PDUs of the PDU Set (i.e., the PDUs still pending transmission) after the delay period has elapsed are useless to the decoder.
  • the RLC protocol layer can operate in three modes: A transparent mode (TM) during which data is transmitted with no header or any protocol implementation; an unacknowledged mode (UM) which implements segmentation and duplication detection; and finally, an acknowledged mode (AM) which implements the same functions as the UM mode but with the addition of a retransmission mechanism (e.g., an automatic repeat request (ARQ)).
  • TM transparent mode
  • UM unacknowledged
  • AM acknowledged mode
  • ARQ automatic repeat request
  • RLC AM is used when the reliability provided by lower layers of the protocol stack (e.g., PHY and MAC) needs to be enhanced.
  • the retransmission procedure of RLC AM is parametrised and configured by the gNB.
  • One important parameter is the maximum number of allowed retransmissions for one RLC SDU (e.g., “maxRetxThreshold”).
  • the transmitter is configured to retransmit the missing SDU.
  • Several retransmissions of the missing SDU may occur (e.g., at scheduled intervals) until a certain condition is met. For example, the retransmissions may repeat until the transmitter determines that the SDU has been received.
  • RLC AM is configured to reset the current session and trigger a Radio Link Failure (RLF) when the maximum number of retransmissions of a single SDU has been reached (or exceeded).
  • RLC AM is configured to reset the current session and trigger a Radio Link Failure (RLF) when the maximum number of retransmissions of a single SDU has been reached (or exceeded).
  • RLC AM also relies on the RLC receiver which sends status reports indicating the status of received SDUs to the RLC transmitter, which in return will schedule retransmission of lost SDUs and update the transmit window.
  • Status reporting at the RLC receiver is triggered either on demand by the RLC transmitter (e.g., a polling bit) or by the detection by the RLC receiver of a lost SDU.
  • An SDU is detected as lost when both a sequence number gap is detected and a timer (e.g., t-reassembly) is elapsed (or expired).
  • the transmit window is defined between a lower and upper bound SDU sequence number. In this way, it defines the SDUs that are eligible to be transmitted.
  • the transmit window is updated by both incrementing the lower and upper bounds.
  • the transmit window is only updated when the reception status of the lower bound SDU is confirmed, otherwise it stays unchanged even if new SDUs are provided by upper layer (e.g., PDCP) for transmission.
  • PDCP upper layer
  • a second PDU Set transmission can be stalled because the reception status of one SDU of a first PDU Set is not confirmed and the second PDU Set SDUs sequence number are out of the transmit window. This phenomenon is also known as transmit window stalling. This problem will now be described in more detail with reference to Figure 5.
  • RLC SDU 1 is sent by the RLC transmitter 501 and correctly received by the RLC receiver 502.
  • the RLC receiver 502 does not send a status report because there is no valid trigger for it.
  • RLC SDU 2 is sent by the RLC transmitter 501 with a poll bit set in the header.
  • RLC SDU 2 is also correctly received by the RLC receiver 502. Due to the presence of the poll bit, the RLC receiver 502 sends a status report 505 back to the RLC transmitter 501.
  • the status report contains a positive acknowledgement (ACK) for RLC SDU 3, indicating that RLC SDU 3 is the next SDU expected at the RLC receiver 502.
  • ACK positive acknowledgement
  • the RLC transmitter 501 interprets the status report to mean that all SDUs with sequence numbers below 3 have been correctly received by the RLC receiver 502.
  • the RLC transmitter 501 then updates the transmit window taking into account that RLC SDUs 1 and 2 are correctly received.
  • the next (i.e., fourth) transmission 507 involves SDU 4 being sent by the RLC transmitter
  • the RLC receiver 502 When receiving SDU 4, the RLC receiver
  • SDU 3 is missing because of the sequence number gap (e.g., SDU 3 has an unknown status). At that point, SDU 3 is not considered lost. Nevertheless, the RLC receiver 502 starts a t-reassembly timer and waits for the correct reception of SDU 3. The goal of the network is to wait for low level retransmissions to fix the issue. If SDU 3 is not received when the t-reassembly timer elapses (or expires), then the RLC receiver 502 will consider SDU 3 as being lost (e.g., at this the status of SDU 3 is no longer unknown because the RLC receiver 502 has concluded that the previous transmissions of SDU 3 will not be received). So, at the reception of SDU 4 (i.e., during transmission 507), there are no status reports triggered at the RLC receiver 502.
  • a subsequent transmission 509 involves the RLC transmitter 501 sending SDU 5 with a poll bit, which is received by the RLC receiver 502 correctly.
  • the t-reassembly timer is still running and the RLC receiver 502 is still expecting SDU 3 as the next SDU to be received.
  • the RLC receiver 502 sends a status report 510 back to the RLC transmitter 501.
  • the status report contains a positive acknowledgement (ACK) for RLC SDU 3, meaning that RLC SDU 3 is the next SDU expected at the RLC receiver.
  • ACK positive acknowledgement
  • the RLC transmitter 501 interprets the status report to mean that RLC SDU 3 is missing but not lost (e.g., SDU3 has an unknown status), the status of SDU 4 is unknown, and the status of SDU 5 is probably correctly received because a status report was sent as a result of the poll bit which was included with SDU 5. With this information the RLC transmitter 501 cannot update the transmit window because SDU 3 is not yet received correctly by the RLC receiver 502. Another transmission 511 coincides with the expiry of the t-reassembly timer at the RLC receiver 502. At that time the RLC receiver 502 considers that the SDU 3 is lost.
  • the RLC transmitter 501 performs the first retransmission of the SDU 3 which similar to the first transmission attempt, does not reach the RLC receiver 501 .
  • the t-reassembly timer is still running at the RLC receiver and nothing happens.
  • the t-reassembly timer elapses at the RLC receiver 502, meaning that the retransmission of SDU 3 has failed.
  • the RLC transmitter 501 nothing changed between transmissions 512 and 513, no new data was received from the upper layers of the protocol stack (e.g., the PDCP layer) for transmission, and the status of SDU 3 remains unknown.
  • the RLC receiver 502 considers that the first retransmission of SDU 3 is lost. The RLC receiver 502 shall then restart the t-reassembly timer and send a status report to the RLC transmitter 501.
  • the status report contains both a negative acknowledgement (Nack) for SDU 3 and a positive acknowledgement (Ack) for SDU 6.
  • the RLC transmitter 501 interprets the status report to mean that the first retransmission of SDU 3 is lost and shall be retransmitted once more.
  • the RLC receiver 501 interprets that all SDUs below 6 and above 3 are correctly received by the RLC receiver 502. Therefore, SDU 3 shall be retransmitted again and the transmit window still cannot be updated.
  • the retransmission sequence 511 , 512, 513 shall be repeated until successful reception of SDU 3 is confirmed, or the threshold of maximum number of retransmissions of a single SDU (in this case SDU 3) is reached. Only the confirmation of a correct reception of SDU 3 would allow updating the transmission window by the RLC transmitter 501 . Reaching the threshold of maximum number of retransmissions triggers a radio link failure (RLF) procedure putting an end to the whole communication process.
  • RLF radio link failure
  • the transmit window is only updated when the reception status of the lower bound SDU is confirmed, otherwise it stays unchanged even if new SDUs are provided by upper layer (e.g., PDCP) for transmission.
  • a second PDU Set transmission can be stalled because the reception status of one SDU of a first PDU Set is not confirmed and the second PDU Set SDUs sequence number are out of the transmit window. This phenomenon is also known as transmit window stalling.
  • Figure 6 is a schematic diagram illustrating a method of managing data transmission between the RLC transmitter and RLC receiver, according to a first embodiment of the present disclosure. The method will also be described with reference to the flow charts shown in Figures 9a and 9b.
  • two PDU Sets 601 and 602 are shown as being available for transmission during a time period 603 in which the RLC transmitter will sends SDUs 3, 4, 5, 6 and 7.
  • the RLC transmitter checks whether there will be other SDUs ready to be sent after SDU 8 (e.g. method step 901).
  • SDUs 9 to 11 are not ready for transmission (e.g., because either they are outside of the transmit window or not yet provided by the DPCP layer).
  • the RLC transmitter will check (e.g. method step 902) if some of the previous SDUs (as shown by reference 603) have an unknown reception status (e.g., missing or pending, but not lost). Then select one of them for an anticipated retransmission (e.g. method step 904).
  • the present disclosure provides a means of retransmitting a PDU having an unknown status before receiving a notification (e.g., negative acknowledgment) from the receiver which indicates that the status of the PDU has been lost.
  • a notification e.g., negative acknowledgment
  • SDU 3 has already been retransmitted two times, but the status of the second retransmission is unknown, so SDU 3 is selected as having an unknown (or pending) reception status and having the smallest sequence number among the SDUs with unknown reception status. Consequently, SDU 3 is selected for retransmission before it is confirmed whether the SDU 3 has been lost. Then, SDU 8 is transmitted as planned (e.g. method step 905), and SDU 3 is sent at the next transmission opportunity (e.g.., 605, 906, 907). This results in the timeline 607, in which SDU 3 is interposed between the SDU 8 and SDU 9 of the SDU sequence.
  • SDU 3 is interposed between the SDU 8 and SDU 9 of the SDU sequence.
  • the method of Figure 9 advantageously limits anticipation of the SDU retransmission to situations where there is time available to perform the retransmission, and only for a subset of SDUs associated with a given PDU Set. Therefore, this method achieves better responsiveness with reduced overheads.
  • FIG 7 is a schematic diagram illustrating a method of managing data transmission between the RLC transmitter and RLC receiver, according to a second embodiment of the present disclosure. This method will also be described with reference to the flow charts shown in Figures 10 and 11.
  • the RLC transmitter checks whether it is the last SDU of a PDU Set (e.g. method step 1001).
  • SDU 8 is the last SDU of PDU Set one (e.g. reference 700)
  • SDUs 9 to 11 are part of PDU Set two (e.g. reference 701).
  • SDUs 9 to 11 are ready to be sent (i.e. , they are both provided by the PDCP layer and included in the transmit window).
  • the method of Figure 10 advantageously limits anticipation of the SDU retransmission to PDU Set boundaries, and only for a subset of SDUs associated with a given PDU Set. Therefore, this method achieves better responsiveness with reduced overheads.
  • a further check at method step 1102 is performed to make sure that the second PDU Set (e.g. reference 701 of Figure 7), is less important than the first PDU Set (e.g. reference 700).
  • the RLC transmitter will check if some of the previous SDUs (e.g. reference 703) have an unknown, or pending, reception status (i.e., missing not lost). Then the RLC transmitter selects one of them for an anticipated retransmission (e.g. method step 1104).
  • the method therefore reduces the chances of delaying high importance PDU Sets from reaching their intended destination.
  • SDU 3 has already been retransmitted two times, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and having the smallest sequence number among the SDUs with unknown reception status. Consequently, SDU 8 is sent as planned (e.g. method step 1005), and SDU 3 is sent at the next transmission opportunity (e.g., 1005, 1006, 1007), thus delaying SDUs 9 to 11 by one transmission opportunity, which results in the timeline 707.
  • all the SDUs of the first PDU Set 700 with an unknown, or pending, reception status will be considered for anticipated retransmission, delaying further the SDUs of the next PDU Set.
  • Figure 8 is a schematic diagram illustrating a method of managing data transmission between the RLC transmitter and RLC receiver, according to a third embodiment of the present disclosure. This method will also be described with reference to the flow charts shown in Figure 12.
  • two PDU Sets 801 and 802 will become available for transmission during a time period 803, during which the RLC transmitter is configurable to send SDUs 3, 4, and 5.
  • SDU 6 e.g., 804
  • the RLC transmitter detects a transmit window situation (e.g. method step 1201).
  • SDU 6 is the last SDU of the transmit window.
  • SDUs 7 to 11 are not ready to be sent (e.g., they are provided by PDCP layer but not included in the transmit window).
  • the RLC transmitter will check (e.g. method step 1202) if some of the previous SDUs (e.g. 803) have an unknown, or pending, reception status (e.g., missing not lost). Then the RLC transmitter selects one of them for an anticipated retransmission (e.g. method step 1204).
  • SDU 3 has already been retransmitted two times, but the status of the second retransmission is unknown. Therefore, SDU 3 is selected as having an unknown (or pending) reception status and having the smallest sequence number among the SDUs with unknown reception status
  • SDU 6 is sent as planned (e.g., method step 1205), and SDU 3 is sent at the next transmission opportunity (e.g., 1205, 1206, 1207).
  • this does not delay SDUs 9 to 11 by one transmission opportunity since the transmit window is stalled anyway.
  • the resulting timeline considering that the transmit window stall condition is resolved by the successful retransmission of SD3 is illustrated by reference 807.
  • the RLC transmitter is ready to send a new SDU (e.g., a first SDU) and is notified by the lower layer of the protocol stack (e.g., the MAC layer) that a transmission opportunity is available.
  • a new SDU is a SDU with a sequence number following the sequence number of the last sent SDU, that is part of the transmit window, and that has not been sent earlier.
  • the RLC transmitter checks whether there are any other SDUs ready to be transmitted, either as a first transmission or as retransmission.
  • the RLC transmitter proceeds with method step 903, and sends the first SDU according to RLC AM rules (e.g., as defined in TS 38.322). If the current SDU is the last one to be sent before a silent period, (i.e., ‘yes’ at method step
  • the RLC transmitter checks during method step 902 if there is an SDU with an unknown, or pending, reception status (meaning that the SDU is neither confirmed as being received nor confirmed as being lost and thus not considered as being ready for retransmission).
  • RLC transmitter proceeds with method step 903 and sends the first SDU according to RLC AM rules (e.g., as defined in TS 38.322).
  • the RLC transmitter selects at least one of these SDUs (e.g., second SDU) for an anticipated retransmission. Selecting the second SDU for anticipated retransmission means changing the status of this second SDU from unknown (or missing not lost) to lost and placing the second SDU in the retransmission buffer.
  • the selection of the second SDU among the SDUs with unknown, or pending, reception status is performed according to a configuration which includes the following three options:
  • the selected SDU is the SDU with the smallest sequence number among the SDUs with pending reception status.
  • the selected SDU is the SDU with the smallest sequence number among the SDUs with unknown, or pending, reception status and included in the PDU Set with the smallest remaining time.
  • the selected SDU is the SDU with the smallest sequence number among the SDUs with unknown, or pending, reception status and included in the most important PDU Set with the smallest remaining time.
  • the RLC transmitter proceeds with method step 905 and sends the first SDU according to RLC AM rules (e.g., as defined in TS 38.322).
  • RLC AM rules e.g., as defined in TS 38.322
  • the RLC transmitter waits for the next transmission opportunity from the lower layer of the protocol stack.
  • a further method step 907 involves the RLC transmitter sending the second SDU according to RLC AM rules (e.g., as defined in TS 38.322).
  • Figure 10 is a flow chart of the method according to the second embodiment of the present disclosure, as implemented by the RLC transmitter 501 .
  • the method steps of Figures 9 and 10 are identical except for method step 1001 in Figure 10, which different to method step 901 in Figure 9b.
  • the differential method step 1001 will be described in detail.
  • the RLC transmitter checks if the first SDU is the last SDU of a PDU Set, regardless of the availability of other SDUs to be transmitted after the first SDU (in contrast to the requirements of method step 901 in Figure 9b). In this way, the method in Figure 10 is able to systematically schedule an anticipated retransmission at the end of each PDU Set.
  • Figure 11 is a further flow chart of the method according to the second embodiment of the present disclosure, as implemented by the RLC transmitter 501.
  • the method steps of Figures 10 and 11 are identical except for the additional method step 1102 in Figure 11 , which is not present in Figure 10.
  • the RLC transmitter checks if the next SDU available for transmission after the first SDU is part of a more important PDU Set. If the next available SDU is part of a more important PDU Set, then the RLC transmitter proceeds with method step 1103. If the next available SDU is part of a less important PDU Set, or if there are no next SDU ready for transmission then the RLC transmitter proceeds with method step 1104. Accordingly, the method shown in Figure 11 is able to prevent scheduling an anticipated retransmission at the expense of a more important PDU Set.
  • the importance of the PDU Set can be determined by at least one of a PDU Set Importance (PSI) parameter, the associated delay budget, and the associated remaining time in the delay budget. For example, a combination of all three of these criteria is possible.
  • PSI PDU Set Importance
  • the first SDU is the last SDU in the transmit window, and at least one other SDU is ready to be transmitted;
  • the first SDU is the nth last SDU in the transmit window, and at least one other SDU is ready to be sent, wherein n is a configuration parameter
  • One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status.
  • the unknown status is indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the overheads when compared to systematic retransmission. In this way, a means is provided for anticipating retransmission of PDUs with unknown statuses.
  • a receiver (Rx) initiated approach and/or a transmitter (Tx) initiated approach may include configuring the transmitting side of AM RLC entity to notify the receiving RLC side about the obsolete SDUs.
  • the Tx side then stops retransmitting obsolete SDUs, and the Rx side updates the state variables according to the information from Tx side.
  • the Rx initiated approach may include configuring (e.g., enhancing) RLC AM with a way for the receiver to indicate abandoned SDUs to the transmitter (i.e. , to achieve proper advancing of the transmitting window).
  • the Tx side just processes the status report as in legacy schemes. Further considerations may relate to how the Rx side may determine that an SDU should be abandoned.
  • A. Autonomous retransmission One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status.
  • the unknown status is indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the overhead when compared to systematic retransmission.
  • Proposal 1 Consider autonomous retransmission of PDUs with unknown status. The overhead may be further reduced if the autonomous retransmission of PDUs with unknown status is not systematically triggered. For example, the autonomous retransmission of PDUs having an unknown status may occur following the transmission of all PDUs of a PDU Set.
  • Proposal 4 Further study the criteria for triggering autonomous retransmission of PDUs with unknown status.
  • Enhanced status report Speeding-up the transmission (e.g., by the receiving side) of status reports by the introduction of new triggers. For example, a timer-based trigger.
  • a status report timer elapses while the t-Reassembly timer is still running, there will be no nack information sent to the transmitter.
  • Observation 4 increasing the status report frequency is not useful when the t-Reassembly timer is still running.
  • a t-Reassembly timer can be reduced (or even set to 0), which increases the responsiveness of the RLC receiver once the sequence number gap is detected. But reducing the t-Reassembly timer increases the number of false missing detections, which can then increase the overhead across the network.
  • Observation 5 Enhanced status report costs extra resources in downlink.
  • Discarding the prohibit timer may insure timely transmission of the status report. But the prohibit timer is set by the network for reasons that are independent from the XR application itself. Therefore, the prohibit timer should not be ignored when set. Proposal 5: Do not alter the prohibit timer when set by the network. Proposal 6: Do not enhance the status report.
  • the maximum polling frequency can be configured as one polling bit every 4 packets. But polling frequency cannot match the PDU Sets boundaries because PDU Set boundaries are variable. For example, one option may involve reducing the t-PollRetransmit timer below 5 ms. Observation 6: Increasing the polling frequency can result in a large number of non-useful status reports being sent.
  • Another option may be to initiate polling by the transmitter based on remaining time information. However, if the polling bit triggers a status report based on PDB, but the t-Reassembly timer is still running, there will be no nack information sent back to the transmitter. Observation 7: Autonomous retransmission is necessary to overcome the delay induced by the t-Reassembly timer.
  • Unnecessary RLC AM retransmissions may be avoided (or reduced) by configuring the RLC AM by adopting enhancements to either the receiver (Rx) initiated approach, or the transmitter (Tx) initiated approach.
  • the transmitting side of the AM RLC entity may notify the receiving RLC side about the obsolete SDUs.
  • the Tx side stops retransmitting obsolete SDUs and the Rx side updates state variables according to the information from the Tx side.
  • RLC AM may be enhanced by providing a way for the receiver to indicate abandoned SDUs to the transmitter. Accordingly, the Tx side just processes the status report as in known methods. Such approaches do not consider how the Rx side should determine that an SDU should be abandoned.
  • the TX window may be updated once the discard decision is taken. In that case, the TX window is updated before the RX window is updated. Furthermore, the RX window will be updated based on the discard notification received from the transmitting entity. Consequently, the RX and TX windows will be out of sync for the time that it takes for the discard notification to arrive. In summary, for the TX initiated approach, the TX and RX windows may be out of sync for a negligible amount of time.
  • MMW Move Receiving Window
  • FIG. 13 is a schematic diagram illustrating an example signalling between two nodes of a wireless communication network.
  • An SDU can be discarded with explicit signalling when a predetermined threshold has been reached, for example, when a number of retransmissions (MaxDAT) is reached, or when the transmission time exceeds a predefined value (Timer_Discard) for an SDU in acknowledged mode RLC.
  • a “Move Receiving Window” (MRW) command can be sent to the receiver so that acknowledge mode data (AMD), e.g., a PDU carrying the SDU which is to be discarded by the receiver and/or the receiver window, is updated accordingly.
  • a method according to embodiments of the present disclosure is configured to merge the MRW command with the discard notification signalling, in order to limit signalling overhead.
  • the method may comprise the following steps for TX initiated approach:
  • the TX discards one or more SDUs based on a PDCP discard timer
  • the TX window is not updated but the one or more discarded SDUs are not sent;
  • the TX sends a discard notification to the RX;
  • the RX updates the RX window based on the discard notification
  • the RX sends a status report acknowledging a new window boundary
  • the TX advances the TX window based on the status report.
  • the RX side has no knowledge of PDU Sets at any layer of the protocol stack. This is because PDU Sets information, including PDU Set boundary and sequence numbers, are not included within inline communications. As a result, providing a means for the RX side to determine that an SDU is obsolete is therefore difficult.
  • a method for addressing this problem may involve the receiving entity (e.g., the RX) abandoning SDUs based on a timer, like is already achieved according to the PDCP. The timer may then be started upon the detection of a sequence number gap detection. The timer can then be set to a value related to some delay budget.
  • the time to detect a sequence number gap is unpredictable. In a worse case (e.g., when the last PDU of a PDU Set is lost) the sequence number gap will only be detected at the successful transmission of a PDU of a further (e.g., subsequent) PDU Set.
  • the time to detect a sequence number gap is unpredictable and can be as large as a PDU Set period.
  • the transmitting entity may continue to retransmit obsolete SDUs even after the PDU Set delay budget has elapsed. For these reasons, at least, it is considered that the RX initiated approach is less efficient than the TX initiated approach.
  • both the transmitting and receiving entities e.g., Tx and Rx
  • both the transmitting and receiving entities autonomously discard the one or more SDUs based on a predefined criterion, for example similar to those criteria used in the TX and RX initiated approaches (e.g., timers).
  • a predefined criterion for example similar to those criteria used in the TX and RX initiated approaches (e.g., timers).
  • timers e.g., timers.
  • each of the Tx and Rx sides will discard the same SDUs so there is no need for discard signalling or window signalling.
  • the TX and RX windows will not be exactly synced because of the difference between the RX side and the TX side timers. Consequently, there may be concerns about the time taken by the receiving side to detect a sequence number gap before initializing a timer.
  • the efficiency of the RX initiated approach is described in the above table as being “poor” because the time to detect a missing transmission (e.g., indicative of a sequence number gap) is wasted time. Accordingly, some unnecessary transmissions cannot be avoided.
  • the efficiency of the combined approach is described in the table as “No signalling but/poor” because the TX and RX will not discard at the same time. Hence, the window synchronisation is affected by the time to detect a missing transmission (e.g., indicative of a sequence number gap).
  • the method according to the TX initiated approach is adopted with window synchronization signalling, since this provides a favourable balance between signalling, efficiency, and window synchronisation requirements.
  • TX discards SDUs based on PDCP discard timer
  • RX updates RX window based on discard notification
  • RX sends a status report acknowledging new window boundary
  • TX advances TX window based on status report
  • both the transmitting and receiving entities autonomously discards SDUs based on similar criteria (timers). Eventually, each side will discard the same SDUs so there is no need for discard signalling or window signalling. However, the TX and RX windows will not be exactly synced because of the difference between the RX side and TX side timers. Of greater concern is the time taken by the receiving side to detect a sequence number gap before initializing a timer.
  • One way to reduce the retransmission delay is to anticipate the retransmission of PDUs with unknown status.
  • the unknown status may be indicative of the PDU having been transmitted to the receiver but not acknowledged as being received or detected lost by the receiver. This enables earlier and more efficient retransmission of some PDUs, which thereby minimizes the network overhead when compared to a systematic retransmission.
  • the overhead may be reduced further if the autonomous retransmission of PDUs with unknown status is not systematically triggered.
  • the autonomous retransmission of PDUs having an unknown status may occur following the first transmission of all SDUs of a PDU Set. Alternatively (or in addition) the autonomous retransmission of PDUs having an unknown status may occur when the transmit and retransmit buffers are empty.
  • the autonomous retransmission trigger can be further extended to a remaining time threshold applied to the transmit window. If the transmit window is stalled up to the remaining time threshold of a PDU Set, then autonomous retransmission may be triggered. Careful design of the autonomous retransmission trigger may allow drastic reduction of unnecessary SDU retransmission.
  • autonomous transmission may trigger some unnecessary SDU retransmission, whilst the enhanced polling can generate unnecessary signalling exchange.
  • the difference is not obvious to quantify, because there are numerous factors to take into account like the design of autonomous retransmission trigger, the size of the SDUs, or the frequency of the polling. Accordingly, the capacity impact of autonomous retransmission can be managed through careful design of triggering condition.
  • autonomous retransmission has an impact only on the TX side whereas the polling needs to be enhanced at the TX side for triggering, and at the RX side for timer management. In this way, autonomous retransmission may be less complex than polling enhancement. It is advantageous to adopt autonomous retransmission for PDUs with unknown status.
  • the words “comprising, “having,” “including,” or “containing” are inclusive or open-ended and do not exclude additional, unrecited elements or method steps.
  • the use of the term “a” or “an” in the claims and/or the specification may mean “one,” as well as “one or more,” “at least one,” and “one or more than one.”
  • the terms “a,” “an,” and “the,” as well as all singular terms include plural referents unless the context clearly indicates otherwise.
  • plural terms shall include the singular unless otherwise required by context.
  • the use of the term “or” in the present disclosure is used to mean an inclusive “and/or” unless explicitly indicated to refer to alternatives only or unless the alternatives are mutually exclusive.
  • the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over, as one or more instructions or code, a computer-readable medium and executed by a hardware-based processing unit.
  • Disk and disc includes compact disc (CD), laserdisc, optical disc, digital versatile disc (DVD), floppy disk and Blu-ray disc, where disks usually reproduce data magnetically, whilst discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Procédé de gestion de transmission de données dans un réseau de communication fonctionnant dans un mode d'accusé de réception de commande de liaison radio, le réseau de communication comprenant un émetteur et un récepteur, le procédé au niveau de l'émetteur consistant à : retransmettre une PDU ayant un état inconnu avant de recevoir une notification provenant du récepteur indiquant l'état de la PDU.
PCT/EP2025/059180 2024-04-04 2025-04-03 Procédé de gestion de transmission de données dans réseau de communication Pending WO2025210182A1 (fr)

Applications Claiming Priority (10)

Application Number Priority Date Filing Date Title
GB2404850.6A GB2640205A (en) 2024-04-04 2024-04-04 Method for managing data transmission in a communication network
GB2404850.6 2024-04-04
GB2406347.1 2024-05-07
GB2406347.1A GB2640324A (en) 2024-04-04 2024-05-07 Method for managing data transmission in a communication network
GB2411756.6 2024-08-09
GB2411756.6A GB2640342A (en) 2024-04-04 2024-08-09 Method for managing data transmission in a communication network
GB2414486.7A GB2640354A (en) 2024-04-04 2024-10-02 Method for managing data transmission in a communication network
GB2414486.7 2024-10-02
GB2416353.7 2024-11-06
GB2416353.7A GB2640361A (en) 2024-04-04 2024-11-06 Method for managing data transmission in a communication network

Publications (1)

Publication Number Publication Date
WO2025210182A1 true WO2025210182A1 (fr) 2025-10-09

Family

ID=95450244

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2025/059180 Pending WO2025210182A1 (fr) 2024-04-04 2025-04-03 Procédé de gestion de transmission de données dans réseau de communication

Country Status (1)

Country Link
WO (1) WO2025210182A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230224383A1 (en) * 2022-01-10 2023-07-13 Mediatek Singapore Pte. Ltd. Extended reality (xr) traffic handling
WO2024031248A1 (fr) * 2022-08-08 2024-02-15 Apple Inc. Retransmission de rlc basée sur un ensemble de pdu

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230224383A1 (en) * 2022-01-10 2023-07-13 Mediatek Singapore Pte. Ltd. Extended reality (xr) traffic handling
WO2024031248A1 (fr) * 2022-08-08 2024-02-15 Apple Inc. Retransmission de rlc basée sur un ensemble de pdu

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
LIFENG HAN ET AL: "Discussion on RLC enhancements for XR", vol. 3GPP RAN 2, no. Changsha, Hunan Province, CN; 20240415 - 20240419, 3 April 2024 (2024-04-03), XP052584324, Retrieved from the Internet <URL:https://www.3gpp.org/ftp/TSG_RAN/WG2_RL2/TSGR2_125bis/Docs/R2-2402354.zip R2-2402354.doc> [retrieved on 20240403] *
NOKIA ET AL: "XR Capacity Enhancements", vol. RAN WG2, no. Electronic; 20221010 - 20221019, 30 September 2022 (2022-09-30), XP052262888, Retrieved from the Internet <URL:https://ftp.3gpp.org/tsg_ran/WG2_RL2/TSGR2_119bis-e/Docs/R2-2209559.zip R2-2209559 XR Capacity Enhancements.docx> [retrieved on 20220930] *

Similar Documents

Publication Publication Date Title
CA2615915C (fr) Systeme d&#39;extraction efficace de donnees mises en memoire tampon sur un noeud b suite a une remise a zero de la couche mac
US10341059B2 (en) Method and arrangements in a telecommunication system for handling status information of data units
US10440614B2 (en) Interruptions in wireless communications
US9565007B2 (en) Method of receiving a point-to-multipoint service in a wireless communication system
WO2015018535A1 (fr) Retransmission d&#39;unité de données de protocole par un chemin de transmission alternatif pour réseau sans fil à double connectivité
CN110476445A (zh) 利用分离承载的分组数据汇聚协议窗口
US10785687B2 (en) Inter-node B handover in HSDPA or multi-flow HSPA including packet retransmission
CN101682916A (zh) 在移动通信系统中发送rlc pdu和分配无线资源的方法以及移动通信的rlc实体
GB2629871A (en) Methods for controlling a packet data convergence protocol communication network
WO2025210182A1 (fr) Procédé de gestion de transmission de données dans réseau de communication
GB2640361A (en) Method for managing data transmission in a communication network
WO2025210190A1 (fr) Procédé de gestion de transmission de données dans un réseau de communication
GB2640325A (en) Method for managing data transmission in a communication network
GB2642753A (en) Method for managing data transmission in a communication network
WO2026017753A1 (fr) Procédé de gestion de transmission de données dans un réseau de communication
WO2026093470A1 (fr) Procédé de gestion de transmission de données dans un réseau de communication
AU2009245823B2 (en) System for efficient recovery of node-b buffered data following Mac layer reset
WO2011134232A1 (fr) Procédé, dispositif et système pour le traitement du transfert intercellulaire d&#39;un équipement utilisateur dans un système d&#39;évolution à long terme (lte)
GB2629872A (en) Methods for controlling a PDCP transmitter
WO2024231490A1 (fr) Procédés de commande d&#39;un émetteur pdcp
EP3031282A1 (fr) Retransmission d&#39;unité de données de protocole par un chemin de transmission alternatif pour réseau sans fil à double connectivité

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 25719637

Country of ref document: EP

Kind code of ref document: A1