WO2019179792A1 - Notifications d'application provenant d'un réseau pour une adaptation de débit et de commande de flux - Google Patents

Notifications d'application provenant d'un réseau pour une adaptation de débit et de commande de flux Download PDF

Info

Publication number
WO2019179792A1
WO2019179792A1 PCT/EP2019/055890 EP2019055890W WO2019179792A1 WO 2019179792 A1 WO2019179792 A1 WO 2019179792A1 EP 2019055890 W EP2019055890 W EP 2019055890W WO 2019179792 A1 WO2019179792 A1 WO 2019179792A1
Authority
WO
WIPO (PCT)
Prior art keywords
link layer
data
data stream
response message
transmission
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.)
Ceased
Application number
PCT/EP2019/055890
Other languages
English (en)
Inventor
Jonathan Ling
Bongho Kim
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.)
Nokia Technologies Oy
Original Assignee
Nokia Technologies Oy
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
Application filed by Nokia Technologies Oy filed Critical Nokia Technologies Oy
Priority to EP19709933.6A priority Critical patent/EP3769558A1/fr
Priority to US16/982,129 priority patent/US20210127301A1/en
Publication of WO2019179792A1 publication Critical patent/WO2019179792A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/02—Arrangements for optimising operational condition
    • 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
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • 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/0226—Traffic management, e.g. flow control or congestion control based on location or mobility
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L5/00—Arrangements affording multiple use of the transmission path
    • H04L5/003—Arrangements for allocating sub-channels of the transmission path
    • H04L5/0053—Allocation of signalling, i.e. of overhead other than pilot signals
    • H04L5/0055—Physical resource allocation for ACK/NACK

Definitions

  • Various example embodiments relate generally to wireless networks and, more specifically, relate to throughput and flow control adaptation in wireless networks.
  • Wireless networks must be designed to meet the growing demands of applications. Future wireless networks will need to support applications having specific QoS requirements, such as high-bit rates and low latencies for example, thus presenting the wireless networks with multiple QoS flows. For example, applications may present the network with multiple audio/video streams and real-time information from tactical sensors, for example.
  • QoS requirements are difficult to achieve due to a number of reasons, including radio impairments, fading, multipath, shadowing, interference, measurement gaps, varying load, thermal conditions, processing power, and proportional sharing.
  • a method including: inserting at least one link layer request message into a data stream to be transmitted by the apparatus, wherein the data stream corresponds to an application and comprises a plurality of data parts, and wherein the at least one link layer request message requests a status of a transmission of a first data part of the plurality of data parts from a first communication protocol of an apparatus; receiving a link layer response message indicative of the status of the transmission of the first data part from the first communication protocol; and controlling a flow of the data stream based on the link layer response message.
  • an apparatus comprising means for performing: inserting at least one link layer request message into a data stream to be transmitted by the apparatus, wherein the data stream corresponds to an application and comprises a plurality of data parts, and wherein the at least one link layer request message requests a status of a transmission of a first data part of the plurality of data parts from a first communication protocol of the apparatus; receiving a link layer response message indicative of the status of the transmission of the first data part from the first communication protocol; and controlling a flow of the data stream based on the link layer response message.
  • a computer readable medium comprising program instructions.
  • the program instructions may cause the apparatus to perform at least the following: inserting at least one link layer request message into a data stream to be transmitted by an apparatus, wherein the data stream corresponds to an application and comprises a plurality of data parts, and wherein the at least one link layer request message requests a status of a transmission of a first data part of the plurality of data parts from a first communication protocol of the apparatus; receiving a link layer response message indicative of the status of the transmission of the first data part from the first communication protocol; and controlling a flow of the data stream based on the link layer response message.
  • FIG. 1 is a block diagram of one possible and non-limiting exemplary system in which exemplary embodiments may be practiced
  • FIG. 2 shows an example embodiment of the subject matter described herein
  • FIG. 3 is a simplified block diagram showing the data flow between different protocol layers
  • FIGS. 4A and 4B shows PDCP and RLC protocol layers with enhanced messaging in accordance with an example embodiment of the subject matter described herein;
  • FIG. 5 is a control message in accordance with an example embodiment of the subject matter described herein;
  • FIG. 6 shows a simulated video transmission network in accordance with an example embodiment of the subject matter described herein;
  • FIG. 7 shows results for observed video frame transmission rate and actual receive rates from the simulation from a simulation in accordance with an example embodiment of the subject matter described herein;
  • FIG. 8 is a logic flow diagram for application notifications from a network for throughput and flow control adaptation, and illustrates the operation of exemplary methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments.
  • the exemplary embodiments herein describe techniques for application notifications from network for throughput and flow control adaptation. Additional description of these techniques is presented after a system into which the exemplary embodiments may be used is described.
  • LTE Long Term Evolution
  • gNB 5G wireless networks
  • FIG. 1 shows a block diagram of one possible and non-limiting exemplary system in which the exemplary embodiments may be practiced.
  • a user equipment (UE) 1 10 is in wireless communication with a wireless network 100.
  • a UE is a wireless, typically mobile device that can access a wireless network.
  • the UE 1 10 includes one or more processors 120, one or more memories 125, and one or more transceivers 130 interconnected through one or more buses 127.
  • Each of the one or more transceivers 130 includes a receiver, Rx, 132 and a transmitter, Tx, 133.
  • the one or more buses 127 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, and the like.
  • the one or more transceivers 130 are connected to one or more antennas 128.
  • the one or more memories 125 include computer program code 123.
  • the UE 1 10 includes a UE protocol stack module, comprising one of or both parts 140-1 and/or 140-2, which may be implemented in a number of ways.
  • the UE protocol stack module may be implemented in hardware as UE protocol stack module 140-1 , such as being implemented as part of the one or more processors 120.
  • the UE protocol stack module 140-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array.
  • the UE protocol stack module 140 may be implemented as UE protocol stack module 140-2, which is implemented as computer program code 123 and is executed by the one or more processors 120.
  • the one or more memories 125 and the computer program code 123 may be configured to, with the one or more processors 120, cause the user equipment 1 10 to perform one or more of the operations as described herein.
  • the UE 110 communicates with eNB 170 via a wireless link 1 1 1.
  • the eNB (evolved NodeB) 170 is a base station (e.g., for LTE, long term evolution) that provides access by wireless devices such as the UE 1 10 to the wireless network 100.
  • the eNB 170 includes one or more processors 152, one or more memories 155, one or more network interfaces (N/W l/F(s)) 161 , and one or more transceivers 160 interconnected through one or more buses 157.
  • Each of the one or more transceivers 160 includes a receiver, Rx, 162 and a transmitter, Tx, 163.
  • the one or more transceivers 160 are connected to one or more antennas 158.
  • the one or more memories 155 include computer program code 153.
  • the eNB 170 includes a protocol stack module, comprising one of or both parts 150-1 and/or 150-2, which may be implemented in a number of ways.
  • the protocol stack module may be implemented in hardware as protocol stack module 150-1 , such as being implemented as part of the one or more processors 152.
  • the protocol stack module 150-1 may be implemented also as an integrated circuit or through other hardware such as a programmable gate array.
  • the protocol stack module may be implemented as protocol stack module 150-2, which is implemented as computer program code 153 and is executed by the one or more processors 152.
  • the one or more memories 155 and the computer program code 153 are configured to, with the one or more processors 152, cause the eNB 170 to perform one or more of the operations as described herein.
  • the one or more network interfaces 161 communicate over a network such as via the links 176 and 131.
  • Two or more eNBs 170 communicate using, e.g., link 176.
  • the link 176 may be wired or wireless or both and may implement, e.g., an X2 interface.
  • the one or more buses 157 may be address, data, or control buses, and may include any interconnection mechanism, such as a series of lines on a motherboard or integrated circuit, fiber optics or other optical communication equipment, wireless channels, and the like.
  • the one or more transceivers 160 may be implemented as a remote radio head (RRH) 195, with the other elements of the eNB 170 being physically in a different location from the RRH, and the one or more buses 157 could be implemented in part as fiber optic cable to connect the other elements of the eNB 170 to the RRH 195.
  • RRH remote radio head
  • the cell makes up part of an eNB. That is, there can be multiple cells per eNB.
  • the term“cell” may refer to the coverage area of a given set of transceivers associated with a eNB, or may refer to the logical part of the eNB that performs functions related to the transmission/reception within that coverage area. For instance, there could be three cells for a single eNB carrier frequency and associated bandwidth, each cell covering one-third of a 360 degree area so that the single eNB’s coverage area covers an approximate oval or circle.
  • each cell can correspond to a single carrier and an eNB may use multiple carriers. So if there are three 120 degree cells per carrier and two carriers, then the eNB has a total of 6 cells.
  • the wireless network 100 may include one or more network control elements (NCE) 190 that may include MME (Mobility Management Entity) and/or SGW (Serving Gateway) functionality, and which provides connectivity with a further network, such as a telephone network and/or a data communications network (e.g., the Internet).
  • the eNB 170 is coupled via a link 131 to the NCE 190.
  • the link 131 may be implemented as, e.g., an S1 interface.
  • the NCE 190 includes one or more processors 175, one or more memories 171 , and one or more network interfaces (N/W l/F(s)) 180, interconnected through one or more buses 185.
  • the one or more memories 171 include computer program code 173.
  • the one or more memories 171 and the computer program code 173 are configured to, with the one or more processors 175, cause the NCE 190 to perform one or more operations.
  • the wireless network 100 may implement network virtualization, which is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network.
  • Network virtualization involves platform virtualization, often combined with resource virtualization.
  • Network virtualization is categorized as either external, combining many networks, or parts of networks, into a virtual unit, or internal, providing network-like functionality to software containers on a single system. Note that the virtualized entities that result from the network virtualization are still implemented, at some level, using hardware such as processors 152 or 175 and memories 155 and 171 , and also such virtualized entities create technical effects.
  • the computer readable memories 125, 155, and 171 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory.
  • the computer readable memories 125, 155, and 171 may be means for performing storage functions.
  • the processors 120, 152, and 175 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples.
  • the processors 120, 152, and 175 may be means for performing functions, such as controlling the UE 110, eNB 170, and other functions as described herein.
  • the various embodiments of the user equipment 1 10 can include, but are not limited to, cellular telephones such as smart phones, tablets, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.
  • PDAs personal digital assistants
  • portable computers having wireless communication capabilities
  • image capture devices such as digital cameras having wireless communication capabilities
  • gaming devices having wireless communication capabilities
  • music storage and playback appliances having wireless communication capabilities
  • Internet appliances permitting wireless Internet access and browsing, tablets with wireless communication capabilities, as well as portable units or terminals that incorporate combinations of such functions.
  • RTT round-trip-time
  • a video receiver may send back an estimate of the achievable rate end to end.
  • the video receiver may send back a notification so that the sender will transmit dummy frames until the congestion event is over. For example, if the channel rate drops, the transmitter will not find this out until at least one RTT.
  • the transmitter Before receiving feedback (i.e. before one RTT), the transmitter may continue to send at a higher rate. If the radio link is the bottleneck, then packets will be buffered at the sender, and be transmitted at the link rate which is lower than the traffic input rate, and delivered late.
  • the approximate outage period of, for example in real-time video may be calculated as follows:
  • a receiver obtains delayed frame at RTT/2+TX_delay (i.e. the wired + wireless delay) and deduces a new rate send the new rate back to the sender;
  • the outage period for the above is approximately equal to: — ( RTT + T f — ). This can
  • Some attempts to address these problems include using multiple radio bearer support and using intra-flow priority queue.
  • each one of these attempts suffers from one or more of the following disadvantages: the network operator is required to allocate more resources, for example an additional GBR bearer, which reduces the resources of other users in the case multiple radio bearer support; intra-flow priority queues are overly complex, require classification and identification of traffic, and/or require a dynamic application-network interface.
  • a modem such as an LTE modem for example
  • this flow-control mechanism relates to how communications are transmitted to the MAC layer, and up, to provide the application with a local throughput and congestion event notification.
  • FIG. 2 this figure is a simplified diagram showing messages exchanged between two applications in accordance with an example embodiment.
  • FIG. 2 includes an Application A that sends messages to Application B over a radio link and requests link layer acknowledgments, and vice versa.
  • a transport layer protocol or the application itself, may insert Link Layer (LL) Ack-Req messages within its user datagram protocol (UDP) packet stream.
  • the request and response messages may be IP packets, which are trapped at the PDCP layer, and not sent over-the-air. For example, before and after every video frame, an LL-Ack-Req may be sent, and a link layer response is generated indicating transmission by the modem, and delivered to the application, which keeps track of the responses.
  • the link layer response may be generated based on at least one of the following three events:
  • the timestamp ignores the over-the-air transmission delay, but is relatively easy to implement.
  • additional communications between layers is required to obtain the HARQ process feedback, but this option also provides better indication of delivery as well as delay.
  • Option (iii) provides the most accurate indication of delivery, but there is delay in receiving the RLC Status PDU, as the ACK/NACKs are aggregated and then delivered over- the-air.
  • FIG. 3 is a simplified block diagram a simplified block diagram showing the data flow between different protocol layers of a transmitting entity.
  • packets e.g. IP packets
  • the PDCP layer generates PDCP PDUs from the PDCP SDUs and adds a PDCP header. These packets are then sent to the RLC layer.
  • the RLC layer receives the packets (RLC SDUs) from the PDCP layer.
  • the RLC layer processes the packets to form RLC PDUs which are then passed down the protocol stack and eventually transmitted by the transmitting entity.
  • the RLC layer concatenates the RLC SDU 1 and RLC SDU 2 and segments RLC SDU 3.
  • RLC PDU 1 is associated with RLC SDU 1 , RLC SDL ) 2, and part of RLC SDL ) 3.
  • RLC PDU 3 is associated with the remaining part of RLC SDU 3.
  • FIGS. 4A and 4B are block diagrams showing enhanced cross protocol messaging scheme implemented in the PDCP and RLC layers, respectively, in accordance with some example embodiments.
  • the network may initially configure a UE to support cross protocol layer communication (such as for ‘application layer acknowledgements’ for example).
  • the configuration may include a request message type and a valid source IP address of such requests.
  • the enhanced messaging scheme is shown in the darker shaded blocks while other functionalities of the PDCP and RLC layers are shown in the remaining blocks.
  • the enhanced messaging procedure shown in FIGS. 4A and 4B includes the following:
  • An application or an agent may send a control message requesting a link layer acknowledgement after a certain amount of data is sent from the application or agent.
  • This request for the link layer acknowledgement i.e. LL- Ack-Req
  • the request may also be accomplished such as by sending an IP packet with a specific option field or by using a new ICMP packet to request a link layer acknowledgment for example. It is noted that these request and response packets are referred to generically herein using the terms LL-Ack-Req and LL-Ack-Resp.
  • the LL-ACK-Req is intercepted by the PDCP layer.
  • the PDCP layer records a source address (Ack-Req-SA), a request sequence number (Ack-Req-SN), a PDCP sequence number (Ack-Req-PDCP-SN) of the previous data packet, and the current time.
  • the LL-Ack-Req packet is then discarded by the PDCP layer of the transmitting entity 402.
  • the transmitting PDCP entity 402 generates sends down to the RLC layer 340, a data delivery status (DDS) request (PDCP-DDS-Req) message that has the PDCP- DDS-SN equal to the Ack-Req-PDCP-SN as indicated by 410.
  • DDS data delivery status
  • the RLC layer 440 intercepts the PDCP-DDS-Req. In both unacknowledged mode (UM) and acknowledged mode (AM), after the transmission opportunity and after the RLC segments the RLC SDUs, if Ack-Req-PDCP-SN is in the range of transmitted SDUs then a“DDS-Resp” is generated with the data/control (D/C) bit set to control as indicated by 416.
  • the RLC-DDS-Resp includes the SN of the PDCP-DDS-Req. For example, a list may be implemented in the RLC layer that includes the sequence numbers for which delivery notifications have been requested.
  • the last SDU SN that is put into the transmission opportunity (which could be either a segment or a whole packet) is obtained and compared to the sequence numbers in the list. If so, then the DDS-Resp is generated as described above.
  • the egress PDCP entity 404 receives the DDS-Resp message at block 418, and generates an LL-Ack-Resp packet.
  • the LL-ACK-Resp packet comprises: a destination address equal to the Ack-Req-SA, the Ack-Req-SN, a status, a timestamp in, and a timestamp out.
  • This LL-ACK-Resp packet is then sent up the protocol stack to the application as shown in block 420.
  • the status in the LL-ACK-Resp is set to one of ACK, NACK, or NULL, where NULL is used to indicate that the UE lost track of the request and cannot give a response.
  • LL-ACK-Resp may be set to NULL when an error occurs, when the internal state is flushed and/or when the internal state is confused (such as when the UE temporarily loses connection with the network for example).
  • the error In downlink the error may be, for example, when there is a handoff and the base station is being changed, and in uplink the error may be, for example when too many LL-ACK-Reqs are requested. Accordingly, if a DDS-Resp is not eventually obtained, there will be a timeout, the DDR-Req will be flushed, and the LL-Ack-Resp NULL generated.
  • the application may use the LL-Ack-Resp message from the PDCP layer to control the flow of the data, namely, the application may send a next data frame if a response is received or skip the next data frame if a response is not received.
  • the large initial delay from the SR and BSR can be eliminated when estimating transmission delay by using the time difference between the LL-Ack-Resp from the start of the data frame and the LL-Ack-Resp from the end of the data frame.
  • the estimated throughput may correspond to the number of bytes per travel time which can be lowered by the sender if the estimated delay is too high.
  • the control message format 500 includes a data/control field 502, a PDU type field 504, and a PDCP sequence number field 506.
  • the PDCP SN field 506 is 12-bits long and the PDU type field 504 is 3-bits long.
  • the PDU type field 504 may be configured with a value to indicate that the control message corresponds to a DDS request and/or response.
  • the value indicated in the control message may be defined by a wireless standard, and may correspond to the following table for example (where A, B, C, etc. are different 3-bit values):
  • control message format 500 and the corresponding values are merely example, and other formats and/or values are also possible, such as control format messages with different lengths, different size fields, different values, and/or the like.
  • an initial setup and/or configuration is performed so that the application knows certain information, such as an IP address and a UDP port of where to send the requests (e.g. LL-Ack-Req).
  • information such as an IP address and a UDP port of where to send the requests (e.g. LL-Ack-Req).
  • information could be preconfigured in a user equipment and/or the information could be accessed on the internet if the application knows which cellular operator the user equipment is using.
  • Another possibility is using a discovery protocol to discover such information.
  • user equipments may be configured by the network (such as an MME for example) on a per user basis from the MME, in which case the UE and/or eNB would be configured to accept requests as described above (e.g. LL-Ack-Req), and the rate of such requests.
  • a dynamic service is also possible where a wireless network (such as a 5G wireless network) may use an exposure function (NEF) to interface to the application, so that application can request
  • the requests e.g. LL-Ack-Req
  • the responses e.g. LL-ACK-Resp
  • the process is completely network driven and the responses may be trapped at either the PDCP layer or IP layer at a network node (e.g. an eNB or PGW). It is noted in these network-driven examples, the LL-Ack- Resp would be sent over the air (downlink).
  • FIG. 6 shows an example of a video transmission network 600 that was used to simulate an enhanced messaging scheme in accordance with an example embodiment.
  • the network 600 was simulated such that the enhanced messaging functionality was implemented at the PDCP and RLC layers in the LTE stack using a video sender application 602 for a user equipment 608, and a video receiver application 604 were designed to use and test the effectiveness using throughput and congestion event notifications in accordance with some example embodiments.
  • the data was packetized (UDP) with RTP headers using the fed back rate 612 from the receiver frames (dummy data).
  • uplink video traffic transmission was used comprising video frames 610.
  • a timestamp was added at the eNB 606 to allow the receiver to determine the transmission rate using the timestamp on the first and last packet of the frame.
  • Throughput estimation Delay measurement of first packet and last packet of a frame using IP timestamping at eNB.
  • Congestion Detection Two sequential late frames triggers congestion notification (CN) flag in frame rate response. If CN is received then sender generates dummy video frames until CN flag is cleared.
  • CN congestion notification
  • this figure shows the observed video frame transmission rate and actual receive rates according to a simulation for network 600 for both end-to-end feedback and link-layer feedback.
  • the frame rate for the simulation is 50 frames per second.
  • the frame rate is set to zero at the transmitter if congestion control is active in skipping or transmitting dummy frames.
  • the rate is set to zero at the receiver if a frame misses its playback time.
  • both the link layer acknowledgments method and the end-to-end technique experience a ramp-up period.
  • the channel bandwidth dips from 7 to 4.1 Mbps momentarily (for example due to congestion) which occurs at approximately 0.5-0.8s.
  • congestion control causes frames to be skipped as represented by 706 and 708 for the LL-Acknowledgments method and the end-to-end method, respectively.
  • the average sending rate was 5.1 Mbps during the example simulation, with 2 frames (4%) skipped, and no frames were dropped.
  • the average sending rate was 4.7 Mbps, with 7 frames (13%) skipped by the transmitter, and 15 frames (30%) dropped at the receiver as shown at 710 in FIG. 7.
  • the outage with the end-to-end feedback method was 250ms.
  • the receiver side frame receive rate diagram clearly indicates that the end-to-end mechanism without LL- Acknowledgments experienced longer frame loss. In contrast, using LL-Acknowledgments no frame loss was experienced except the reduced receiving frame rate caused by the reduced air link rate (as shown in the‘channel’ line of FIG. 7).
  • FIG. 8 is a logic flow diagram for application notifications from network for throughput and flow control adaptation. This figure further illustrates the operation of an exemplary method or methods, a result of execution of computer program instructions embodied on a computer readable memory, functions performed by logic implemented in hardware, and/or interconnected means for performing functions in accordance with exemplary embodiments.
  • the UE protocol stack module 140-1 and/or 140-2 or the protocol stack module 150-1 and/or 150-2 may include multiples ones of the blocks in FIG. 8, where each included block is an interconnected means for performing the function in the block.
  • a transmitting entity such as the UE 1 10, e.g., under control of the UE protocol stack module 140-1 and/or 140-2 at least in part, or the eNB 170, e.g., under the control of the protocol stack module 150-1 and/or 150-2 at least in part).
  • a method including: inserting at least one link layer request message into a data stream to be transmitted by an apparatus, wherein the data stream corresponds to an application and comprises a plurality of data parts, and wherein the at least one link layer request message requests a status of a transmission of a first data part of the plurality of data parts from a first communication protocol of the apparatus as indicated by block 800; receiving a link layer response message indicative of the status of the transmission of the first data part from the first communication protocol as indicated by block 802; and controlling a flow of the data stream based on the link layer response message as indicated by block 804.
  • the layer response message may include one of: a first value acknowledging the first data part has been transmitted by a modem of the apparatus; and a second value indicating the first data part was not transmitted and/or that the status of the transmission cannot be provided.
  • Controlling the flow of the data stream may include: causing a next data part of the data stream be transmitted when the link layer response message acknowledges the transmission of the first data part, and causing the next part of the data stream to be skipped when the link layer response message fails to acknowledge transmission of the first data part of the application.
  • the method may include: estimating a transmission delay of the data stream based on a first time value associated with the link layer response message wherein the link layer response message indicates that the first data part has been transmitted, and a second time value associated with a further link layer response message wherein the further link layer response message indicates that a next part of the data stream has been transmitted.
  • the method may include: adjusting a transmission rate of the data stream based at least on the estimated transmission delay.
  • the received link layer response message may be generated in response to determining by a second communication protocol of the apparatus a transmission opportunity for the first data part.
  • the first communication protocol may be a packet data convergence protocol
  • the second communication protocol may be a radio link control protocol.
  • the at least one link layer request message and the received link layer response message may not be transmitted by the modem of the apparatus.
  • the data stream may include a video stream such that each of the plurality of data parts of the data stream comprises a video frame.
  • an apparatus comprising means for performing: inserting at least one link layer request message into a data stream to be transmitted by the apparatus, wherein the data stream corresponds to an application and comprises a plurality of data parts, and wherein the at least one link layer request message requests a status of a transmission of a first data part of the plurality of data parts from a first communication protocol of the apparatus; receiving a link layer response message indicative of the status of the transmission of the first data part from the first communication protocol; and controlling a flow of the data stream based on the link layer response message.
  • the layer response message may include one of: a first value acknowledging the first data part has been transmitted by a modem of the apparatus; and a second value indicating the first data part was not transmitted and/or that the status of the transmission cannot be provided.
  • Controlling the flow of the data stream may include: causing a next data part of the data stream be transmitted when the link layer response message acknowledges the transmission of the first data part, and causing the next part of the data stream to be skipped when the link layer response message fails to acknowledge transmission of the first data part of the application.
  • the means may be further configured to perform: estimating a transmission delay of the data stream based on a first time value associated with the link layer response message wherein the link layer response message indicates that the first data part has been transmitted, and a second time value associated with a further link layer response message wherein the further link layer response message indicates that a next part of the data stream has been transmitted.
  • the means may be further configured to perform: adjusting a transmission rate of the data stream based at least on the estimated transmission delay.
  • the received link layer response message may be generated in response to determining by a second communication protocol of the apparatus a transmission opportunity for the first data part.
  • the first communication protocol may be a packet data convergence protocol
  • the second communication protocol may be a radio link control protocol.
  • the at least one link layer request message and the received link layer response message may not be transmitted by the modem of the apparatus.
  • the data stream may include a video stream such that each of the plurality of data parts of the data stream comprises a video frame.
  • the video stream may be a real-time video stream.
  • Inserting the at least one link layer request message may include: inserting a first link layer request message prior to each video frame in the data stream and a second link layer request message after each video frame in the data stream.
  • the means may include: at least one processor; and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.
  • a computer readable medium may include program instructions for causing an apparatus to perform at least the following: inserting at least one link layer request message into a data stream to be transmitted by an apparatus, wherein the data stream corresponds to an application and comprises a plurality of data parts, and wherein the at least one link layer request message requests a status of a transmission of a first data part of the plurality of data parts from a first communication protocol of the apparatus; receiving a link layer response message indicative of the status of the transmission of the first data part from the first communication protocol; and controlling a flow of the data stream based on the link layer response message.
  • the layer response message may include one of: a first value acknowledging the first data part has been transmitted by a modem of the apparatus; and a second value indicating the first data part was not transmitted and/or that the status of the transmission cannot be provided.
  • Controlling the flow of the data stream may include: causing a next data part of the data stream be transmitted when the link layer response message acknowledges the transmission of the first data part, and causing the next part of the data stream to be skipped when the link layer response message fails to acknowledge transmission of the first data part of the application.
  • the program instructions may include: estimating a transmission delay of the data stream based on a first time value associated with the link layer response message wherein the link layer response message indicates that the first data part has been transmitted, and a second time value associated with a further link layer response message wherein the further link layer response message indicates that a next part of the data stream has been transmitted.
  • the program instructions may include: adjusting a transmission rate of the data stream based at least on the estimated transmission delay.
  • the received link layer response message may be generated in response to determining by a second communication protocol of the apparatus a transmission opportunity for the first data part.
  • the first communication protocol may be a packet data convergence protocol
  • the second communication protocol may be a radio link control protocol.
  • the at least one link layer request message and the received link layer response message may not be transmitted by the modem of the apparatus.
  • the data stream may include a video stream such that each of the plurality of data parts of the data stream comprises a video frame.
  • a technical effect of one or more of the example embodiments disclosed herein is improving adaptation, namely, recovery from rate drop, on a non-GBR bearer. Another technical effect of one or more of the example embodiments disclosed herein is that it does not require classification/identification and thus there is no requirement to have a dynamic application-network interface. Another technical effect of one or more of the example embodiments disclosed herein is allowing a codec to tailor its adaptation strategy with knowledge of exactly which frame was transmitted.
  • Embodiments herein may be implemented in software (executed by one or more processors), hardware (e.g., an application specific integrated circuit), or a combination of software and hardware.
  • the software e.g., application logic, an instruction set
  • a“computer-readable medium” may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer, with one example of a computer described and depicted, e.g., in FIG. 1.
  • a computer-readable medium may comprise a computer-readable storage medium (e.g., memories 125, 155, 171 or other device) that may be any media or means that can contain, store, and/or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.
  • a computer-readable storage medium does not comprise propagating signals.
  • the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above- described functions may be optional or may be combined.
  • eNB or eNodeB evolved Node B (e.g., an LTE base station)
  • UDP user datagram protocol UE user equipment e.g. , a wireless, typically mobile device

Landscapes

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

Abstract

L'invention concerne un procédé consistant à : insérer au moins un message de demande de couche de liaison dans un flux de données à transmettre par l'appareil, le flux de données correspondant à une application et comprenant une pluralité de parties de données, et le ou les messages de demande de couche de liaison demandant un état d'une transmission d'une première partie de données de la pluralité de parties de données provenant d'un premier protocole de communication de l'appareil; recevoir un message de réponse de couche de liaison indiquant l'état de la transmission de la première partie de données à partir du premier protocole de communication; et commander un flux du flux de données sur la base du message de réponse de couche de liaison.
PCT/EP2019/055890 2018-03-20 2019-03-08 Notifications d'application provenant d'un réseau pour une adaptation de débit et de commande de flux Ceased WO2019179792A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP19709933.6A EP3769558A1 (fr) 2018-03-20 2019-03-08 Notifications d'application provenant d'un réseau pour une adaptation de débit et de commande de flux
US16/982,129 US20210127301A1 (en) 2018-03-20 2019-03-08 Application Notifications from Network for Throughput and Flow Control Adaptation

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/926,273 US20190297532A1 (en) 2018-03-20 2018-03-20 Application Notifications From Network For Throughput And Flow Control Adaptation
US15/926,273 2018-03-20

Publications (1)

Publication Number Publication Date
WO2019179792A1 true WO2019179792A1 (fr) 2019-09-26

Family

ID=65724426

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/055890 Ceased WO2019179792A1 (fr) 2018-03-20 2019-03-08 Notifications d'application provenant d'un réseau pour une adaptation de débit et de commande de flux

Country Status (3)

Country Link
US (2) US20190297532A1 (fr)
EP (1) EP3769558A1 (fr)
WO (1) WO2019179792A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11997133B2 (en) * 2021-11-22 2024-05-28 Arbor Networks, Inc. Algorithmically detecting malicious packets in DDoS attacks

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006104344A2 (fr) * 2005-03-29 2006-10-05 Lg Electronics Inc. Procede destine a generer un bloc de donnees de couche inferieure dans un systeme de communication mobile
WO2008136598A1 (fr) * 2007-05-03 2008-11-13 Lg Electronics Inc. Méthode de traitement de données dans un système de communications sans fil
EP2538618A1 (fr) * 2011-06-22 2012-12-26 Siemens Aktiengesellschaft Procédé destiné à la transmission de paquets de données
WO2013167647A1 (fr) * 2012-05-11 2013-11-14 Nokia Siemens Networks Oy Mécanisme de contrôle des paramètres de tampon dans un contrôle de flux
US20170127318A1 (en) * 2015-10-29 2017-05-04 Altiostar Networks, Inc. Video pacing based on radio conditions

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE60017356T2 (de) * 2000-03-02 2005-06-02 Matsushita Electric Industrial Co., Ltd., Kadoma Datenübertragung über ein unzuverlässiges Netz
US20020089959A1 (en) * 2001-01-11 2002-07-11 Fischer Michael A. System and method for providing a selectable retry strategy for frame-based communications
KR20060100512A (ko) * 2005-03-17 2006-09-21 삼성전자주식회사 전송제어 프로토콜 기반의 네트워크에서 평균 대역폭 추정방법 및 시스템
US8169938B2 (en) * 2005-06-05 2012-05-01 Starkey Laboratories, Inc. Communication system for wireless audio devices
US8369257B2 (en) * 2008-12-31 2013-02-05 Stmicroelectronics, Inc. Reliable and deterministic communication protocol
JP5175773B2 (ja) * 2009-02-27 2013-04-03 株式会社東芝 通信装置、方法及びプログラム
US20130010641A1 (en) * 2011-07-05 2013-01-10 Esmael Dinan Carrier Activation Employing RRC messages
US10716157B2 (en) * 2017-02-09 2020-07-14 Apple Inc. 5G/LTE dual connectivity

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2006104344A2 (fr) * 2005-03-29 2006-10-05 Lg Electronics Inc. Procede destine a generer un bloc de donnees de couche inferieure dans un systeme de communication mobile
WO2008136598A1 (fr) * 2007-05-03 2008-11-13 Lg Electronics Inc. Méthode de traitement de données dans un système de communications sans fil
EP2538618A1 (fr) * 2011-06-22 2012-12-26 Siemens Aktiengesellschaft Procédé destiné à la transmission de paquets de données
WO2013167647A1 (fr) * 2012-05-11 2013-11-14 Nokia Siemens Networks Oy Mécanisme de contrôle des paramètres de tampon dans un contrôle de flux
US20170127318A1 (en) * 2015-10-29 2017-05-04 Altiostar Networks, Inc. Video pacing based on radio conditions

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
INTEL CORPORATION: "TP for X2-UP on Flow control enhancements", vol. RAN WG3, no. Qingdao, China; 20170627 - 20170629, 26 June 2017 (2017-06-26), XP051302244, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/Meetings_3GPP_SYNC/RAN3/Docs/> [retrieved on 20170626] *

Also Published As

Publication number Publication date
US20190297532A1 (en) 2019-09-26
US20210127301A1 (en) 2021-04-29
EP3769558A1 (fr) 2021-01-27

Similar Documents

Publication Publication Date Title
US10602400B2 (en) Enhancement of PDCP status report
US8761011B2 (en) Efficient flow control in a radio network controller (RNC)
US10440614B2 (en) Interruptions in wireless communications
US8339962B2 (en) Limiting RLC window size in the HSDPA flow control
US10342060B2 (en) Inter-eNB Carrier Aggregation
US12574791B2 (en) Method and apparatus to synchronize radio bearers
EP2204016B1 (fr) Contrôle de flux efficace dans un contrôleur de réseau radio (rnc)
WO2018225988A1 (fr) Appareil et procédé de régulation de la congestion dans un système de communication sans fil
JP2018521585A (ja) 第１の基地局又は第２の基地局を選択してユーザ装置（ｕｅ）にパケットデータユニット（ｐｄｕ）を送信する方法及び装置
Paul et al. An AQM based congestion control for eNB RLC in 4G/LTE network
TWI825132B (zh) 用於多連接的方法
US9974059B2 (en) Method and apparatus for control information transmission
WO2023125310A1 (fr) Procédé de communication et appareil de communication
US20250071615A1 (en) Data transmission method and apparatus and communication device
JP2013085135A (ja) ネットワーク端末装置およびデータ伝送方法
US20210127301A1 (en) Application Notifications from Network for Throughput and Flow Control Adaptation
EP2890179B1 (fr) Procédé, appareil et programme informatique pour le transfert de données
WO2024058550A1 (fr) Procédé et dispositif de modification dynamique de configuration de réseau d&#39;accès radio (ran)
US20090109951A1 (en) Method and Apparatus for Counting Transmission Times of a PDU
Kumar et al. Device‐centric data reordering and buffer management for mobile Internet using Multipath Transmission Control Protocol
US20230397038A1 (en) Traffic engineering for real-time applications
WO2022240064A1 (fr) Procédé et système de transport assisté par la qualité du canal dans un réseau sans fil
JP6973511B2 (ja) 通信装置、通信システム、通信方法及びプログラム
WO2025233000A1 (fr) Rapport d&#39;état rlc et retransmission
WO2025232999A1 (fr) Rapport d&#39;état rlc et retransmission

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: 19709933

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2019709933

Country of ref document: EP

Effective date: 20201020