[go: up one dir, main page]

WO2017052449A1 - Procédés et nœuds pour utilisation dans un réseau de communication - Google Patents

Procédés et nœuds pour utilisation dans un réseau de communication Download PDF

Info

Publication number
WO2017052449A1
WO2017052449A1 PCT/SE2016/050871 SE2016050871W WO2017052449A1 WO 2017052449 A1 WO2017052449 A1 WO 2017052449A1 SE 2016050871 W SE2016050871 W SE 2016050871W WO 2017052449 A1 WO2017052449 A1 WO 2017052449A1
Authority
WO
WIPO (PCT)
Prior art keywords
delivery information
radio access
data unit
node
access node
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/SE2016/050871
Other languages
English (en)
Inventor
Nianshan SHI
Waikwok Kwong
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.)
Telefonaktiebolaget LM Ericsson AB
Original Assignee
Telefonaktiebolaget LM Ericsson AB
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 Telefonaktiebolaget LM Ericsson AB filed Critical Telefonaktiebolaget LM Ericsson AB
Publication of WO2017052449A1 publication Critical patent/WO2017052449A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • 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/1812—Hybrid protocols; Hybrid automatic repeat request [HARQ]
    • 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

Definitions

  • the disclosure relates in general to methods and nodes for use in a communication network and in particular to methods in a control node and methods in a radio access node in a communication network and control nodes and radio access nodes in a communication network.
  • Figure 1 illustrates generic layered peer-to-peer communication between a terminal device and a mobile network.
  • the protocol stack can be divided roughly into L1 - Layer 1 (the physical, PHY, layer), L2 - Layer 2 (the data link layer(s)), and L3 - Layer 3 (the network layer(s); although only the control-plane Radio Resource Control, RRC, protocol is shown in Figure 1).
  • Layer 2 is often divided further into the Radio Link Control, RLC, and the Medium Access Control, MAC, layer for the control plane and also the Packet Data Convergence Protocol, PDCP, layer (not shown in Figure 1) for the user plane.
  • RLC Radio Link Control
  • MAC Medium Access Control
  • PDCP Packet Data Convergence Protocol
  • Radio Resource Control (RRC) procedures often end with an acknowledgement in the form of a "Complete” or “Confirm” message. For example, “Cell Update” is acknowledged by "Cell Update Confirm”.
  • RLC Radio-Link Control protocol
  • AM Acknowledged mode
  • UM Unacknowledged mode
  • TM Transparent mode
  • RLC AM acknowledgement is requested by setting a poll bit in a RLC header of a transmission.
  • the RLC entity on the opposite side then responds with an RLC control protocol data unit (PDU) acknowledging the correctly received RLC PDUs.
  • PDU RLC control protocol data unit
  • HSDPA High Speed Downlink Packet Access
  • EUL Enhanced Uplink
  • 3GPP Third Generation Partnership Project
  • HS-DPCCH High Speed-Dedicated Physical Control Channel
  • E-DSCH High Speed- Downlink Shared Channel
  • ARQ Enhanced Dedicated Channel
  • E-HICH Hybrid Automatic Repeat Request Indicator Channel
  • Both HSDPA and EUL are equipped with multiple hybrid ARQ (HARQ) processes, which perform automatic retransmission of any transmission that is not positively acknowledged.
  • L1 transmissions are not acknowledged.
  • the round-trip time i.e., the time it takes for the acknowledgement to come back after a transmission, differs significantly between the different layers. It typically ranges from a few milliseconds (ms) to up to 40 ms for L1 (depending on the Transmission Time Interval (TTI) length and the number of HARQ processes), to 100-200 ms for L2, and to 0.5 to 1 seconds (s) or even more for L3.
  • TTI Transmission Time Interval
  • the network side is made up of two types of nodes: Radio Network Controllers (RNCs) and radio base stations (RBSs) called Node Bs, with one RNC controlling a, usually large, number of RBSs.
  • RNCs Radio Network Controllers
  • RBSs radio base stations
  • the RRC and RLC protocols originate and terminate in the RNC while the HARQ protocol originates and terminates in the RBS.
  • RRC Radio Resource Control
  • UE User Equipment
  • RBS Radio Service Set
  • the RBS is responsible for the delivery the messages in a generic way (e.g. via the physical layer) and is unaware of the identity of the messages.
  • Figure 2 shows the protocol stacks for UTRAN 2 including the split of the radio access network (RAN) into the RNC 4 and the Node B 6.
  • the MAC protocol is split into multiple layers, MAC-d, MAC-c and MAC-is which operate in the RNC 4 and UE 8, and MAC-i and MAC-ehs which operate in the Node B 6 and UE 8.
  • the layers that are directly supervising the physical transmissions, MAC-ehs (on the downlink, DL) and MAC-i (on the uplink, UL) implement the HARQ protocol, which makes use of fast retransmissions.
  • UL and DL data are carried over the lub interface (the interface between the RNC 4 and Node B 6 provided by a Transport Network Layer, TNL) using different lub frame protocols (HS-DSCH frame protocol, FP, and e-DCH FP).
  • Figure 3 shows the protocol stacks for UTRAN 2 in the situation where the UE 8 is connected via a drift RNC (DRNC) to a serving RNC (SRNC) using a lur interface.
  • DRNC drift RNC
  • SRNC serving RNC
  • a UE can be in one of five states: IDLE, URA_PCH, CELL_PCH, CELL_FACH, and CELL_DCH.
  • the IDLE state is also called the idle mode and the rest are collectively referred to as the connected mode.
  • Data transmission and reception are not possible in IDLE, URA_PCH, and CELL_PCH. To do so, the UE needs to transition to the CELL_FACH state, and for the UE to know that it has data to receive, it must be notified via paging.
  • a data unit When a data unit is passed to an RLC entity in Layer 2, it may be segmented if it cannot fit into a single RLC PDU. It may also be concatenated with an earlier or later data unit if it does not fill up a whole RLC PDU. Various headers are added depending on whether the data unit is to be transmitted in Acknowledged Mode (AM), Unacknowledged Mode (UM), or Transparent Mode (TM). The results are then passed down to the MAC-d layer, which may or may not add an additional header.
  • AM Acknowledged Mode
  • UM Unacknowledged Mode
  • TM Transparent Mode
  • the MAC-d PDUs are transmitted from the RNC 4 to the RBS 6 over the lub interface. They are then assembled into Transport Blocks (TBs) by adding appropriate headers and any necessary padding.
  • Transport Blocks For transmissions over HS-DSCH, two types of high speed (HS) transport protocols are used: MAC-hs and MAC-ehs.
  • MAC-ehs is an enhanced version of the MAC-hs protocol. It accepts variable MAC-d PDU size and is capable of segmenting and reassembling MAC-d PDUs to minimise the need for padding and to reduce the amount of protocol overhead. This handling is shown in Figure 4 for the MAC-hs case.
  • the higher layer PDU may be an RRC message or a user data unit in the form of a PDCP PDU.
  • Various headers are attached to the data by the different L2 protocols. Note that a MAC-d header is needed only if different logical channels are multiplexed on the same MAC-d flow.
  • the MAC-d PDUs are transmitted over the lub interface inside an lub data frame (not shown).
  • the operations covered by bracket 20 represent segmentation and concatenation of service data units (SDUs) or reassembly of SDUs (depending on whether the data is flowing up or down the protocol stack).
  • SDUs service data units
  • CRC Cyclic Redundancy Check
  • the MAC-d PDUs When transmitted over the lub interface, the MAC-d PDUs are carried inside an lub data frame.
  • Two types of HS-DSCH data frames can be used, one for fixed MAC-d PDU size and one for flexible MAC-d PDU size.
  • the structure of the two types of data frames are shown in Figures 5 and 6 respectively.
  • the bits in the data frame 22 are transmitted from left to right (i.e., bit 7 first) and then from top to bottom.
  • the data frames 22 are divided into a header part 24 and a payload part 26.
  • the header 24 provides some control information concerning the payload 26. Additional control information can also be carried in the payload 26 of the data frame 22.
  • the data frame 22 in Figure 5 is used for carrying data with fixed MAC-d PDU size.
  • the common PDU size and the number of PDUs in the data frame 22 are given in the "MAC-d PDU Length" and the "Num Of PDUs" fields in the header 24.
  • the data frame 22 in Figure 6 is used for carrying data with flexible MAC-d PDU size.
  • Consecutive MAC-d PDUs 28 from the same logical channel and having the same size are grouped into PDU blocks 30.
  • Each PDU block 30 (which may contain one or more PDUs) are indicated in the header 24 by an Information Element (IE) group 36 "MAC-d PDU Length in block n", "#PDUs in block n", and "Logical CH ID block n" for the PDU size, number of PDUs, and the logical channel of the block respectively.
  • IE Information Element
  • NEFs New Information Element Flags
  • Bits 0-6 of each octet are Boolean flags that indicate if specific control information will follow.
  • Bit 7 is used as an extension flag, which indicates that the current octet is followed by another "New IE Flags" octet.
  • spare bits 32 are found in each MAC-d PDU 28.
  • multiple sets of spare bits 34 are found in the header 24, for example in each IE group 36.
  • ACKs acknowledgements
  • the UE is ordered to transition from CELL_DCH or CELL_FACH to one of the paging states, e.g., URA_PCH.
  • the RNC sends a Radio Bearer Reconfigure message to the UE and the UE responds with a Radio Bearer Reconfigure Complete message before making the transition. Both messages are sent using RLC AM which means that the procedure should be quite robust.
  • the RNC therefore, waits to see if the L3 message is received again. If it doesn't receive the message again, the RNC can conclude that the UE has most likely received the ACK correctly. However, to account for possible loss of the message over the air, this waiting must be long enough to allow for several RLC retransmissions. The result is the RNC waiting on the order of 1 second. This long waiting leads to reachability problems and the tying up of system resources. This is an unfortunate situation since in the majority of the cases, the UE would have received the ACK correctly and the RNC is just waiting for a retransmission that will never come.
  • HSPA High Speed Packet Access
  • L1 acknowledgements are made possible by the use of HARQ processes and new physical control channels. These acknowledgements constitute a large amount of information that is currently used for RBS-internal purposes only since it is neither practical nor necessary to transfer all of this information up to the RNC.
  • a method is provided for an RNC (or more generally a control node) to request L1 delivery confirmation for specific data units from the RBS (or more generally a radio access node).
  • the RBS On reception of these data units, the RBS notifies the RNC when it has received a positive acknowledgement from the UE for the over-the-air transmission or when the over-the-air transmission has failed after a certain number of HARQ retransmissions.
  • This technique therefore can provide better latency to the end user and improve the utilization of system resources. For example, when the L1 delivery result shows that the terminal device has received the data in question, system resources used for the old configuration can be released immediately, and any new data can be sent to the terminal device in the new configuration earlier. If the L1 delivery result shows that the transmission has failed, the data can be retransmitted immediately without having to wait for L2 or L3 timeouts.
  • a method of operating a control node in a communication network comprising sending a data unit for a terminal device to a radio access node in the communication network; sending a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receiving delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a control node for use in a communication network, the control node being adapted to send a data unit for a terminal device to a radio access node in the communication network; send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a method of operating a radio access node in a communication network comprising receiving a data unit for a terminal device from a control node in the communication network; receiving a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmitting the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; receiving an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and sending delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a radio access node for use in a communication network, the radio access node being adapted to receive a data unit for a terminal device from a control node in the communication network; receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of the aspects described above.
  • a control node for use in a communication network, with the control node comprising a processor and a memory.
  • the memory contains instructions executable by the processor whereby the control node is operative to send a data unit for a terminal device to a radio access node in the communication network; send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a radio access node for use in a communication network, with the radio access node comprising a processor and a memory.
  • the memory contains instructions executable by the processor whereby the radio access node is operative to receive a data unit for a terminal device from a control node in the communication network; receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a control node for use in a communication network.
  • the control node comprises a first sending module configured to send a data unit for a terminal device to a radio access node in the communication network; a second sending module configured to send a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and a first receiving module configured to receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • a radio access node for use in a communication network.
  • the radio access node comprises a first receiving module configured to receive a data unit for a terminal device from a control node in the communication network; a second receiving module configured to receive a delivery information request for the data unit from the control node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; a first transmitting module configured to transmit the data unit to the terminal device over the air interface using a hybrid automatic repeat request, HARQ, protocol; a third receiving module configured to receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and a first sending module configured to send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • Figure 1 illustrates generic layered peer-to-peer communication between a terminal device and a mobile network
  • Figure 2 shows the protocol stacks for UTRAN
  • Figure 3 shows the protocol stacks for UTRAN when a drift RNC is used;
  • Figure 4 shows the data flow for transmission on HS-DSCH using MAC-hs;
  • Figure 5 shows a HS-DSCH data frame type 1 ;
  • Figure 6 shows a HS-DSCH data frame type 2;
  • Figure 7 is a block diagram of a radio access node according to an exemplary embodiment
  • Figure 8 is a block diagram of a control node according to an exemplary embodiment
  • Figure 9 is a flow chart illustrating a method in a communication network according to an exemplary embodiment of the techniques described herein;
  • Figure 10 shows an exemplary lub control frame for reporting delivery information
  • Figure 11 shows HS-DSCH data frame types 1 and 2 that include a Request ID according to an exemplary embodiment
  • Figure 12 shows another exemplary mechanism for requesting delivery information
  • Figure 13 is a flow chart illustrating an exemplary method of operating a control node
  • Figure 14 is a flow chart illustrating an exemplary method of operating a radio access node
  • Figure 15 is a block diagram of a control node according to another exemplary embodiment
  • Figure 16 is a block diagram of a radio access node according to another exemplary embodiment
  • Figure 17 is a block diagram of a control node according to yet another exemplary embodiment.
  • FIG. 18 is a block diagram of a radio access node according to yet another exemplary embodiment. Detailed Description
  • the technology can additionally be considered to be embodied entirely within any form of computer- readable memory, such as solid-state memory, magnetic disk, or optical disk containing an appropriate set of computer instructions that would cause a processor to carry out the techniques described herein.
  • Hardware implementation may include or encompass, without limitation, digital signal processor (DSP) hardware, a reduced instruction set processor, hardware (e.g., digital or analog) circuitry including but not limited to application specific integrated circuit(s) (ASIC) and/or field programmable gate array(s) (FPGA(s)), and (where appropriate) state machines capable of performing such functions.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a computer is generally understood to comprise one or more processors, one or more processing units, one or more processing modules or one or more controllers, and the terms computer, processor, processing unit, processing module and controller may be employed interchangeably.
  • the functions may be provided by a single dedicated computer, processor, processing unit, processing module or controller, by a single shared computer, processor, processing unit, processing module or controller, or by a plurality of individual computers, processors, processing units, processing modules or controllers, some of which may be shared or distributed.
  • these terms also refer to other hardware capable of performing such functions and/or executing software, such as the example hardware recited above.
  • UE user equipment
  • UE user equipment
  • UE is a non-limiting term comprising any mobile or wireless device or node equipped with a radio interface allowing for at least one of: transmitting signals in uplink (UL) and receiving and/or measuring signals in downlink (DL).
  • a UE herein may comprise a UE (in its general sense) capable of operating or at least performing measurements in one or more frequencies, carrier frequencies, component carriers or frequency bands. It may be a "UE” operating in single- or multi-radio access technology (RAT) or multi-standard mode.
  • RAT multi-radio access technology
  • the terms “mobile device” and “terminal device” may be used interchangeably in the following description, and it will be appreciated that such a device does not necessarily have to be 'mobile' in the sense that it is carried by a user. Instead, the terms “mobile device” and “terminal device” encompass any device that is capable of communicating with communication networks that operate according to one or more mobile communication standards, such as the Global System for Mobile communications, GSM, UMTS, Long-Term Evolution, LTE, etc.
  • a cell is associated with a base station or radio base station (RBS), where a base station comprises in a general sense any network node transmitting radio signals in the downlink and/or receiving radio signals in the uplink.
  • RBS radio base station
  • Some example base stations are eNodeB, eNB, Node B, macro/micro/pico/femto radio base station, home eNodeB (also known as femto base station), relay, repeater, sensor, transmitting-only radio nodes or receiving-only radio nodes.
  • a base station may operate or at least perform measurements in one or more frequencies, carrier frequencies or frequency bands and may be capable of carrier aggregation. It may also be a single-radio access technology (RAT), multi-RAT, or multi-standard node, e.g., using the same or different base band modules for different RATs.
  • RAT single-radio access technology
  • multi-RAT multi-RAT
  • multi-standard node e.g., using the same or different base band modules for different RATs.
  • radio access node refers to a network node, e.g. a base station, Node B or eNodeB, that communicates with a terminal device over an air interface
  • control node can refer to a node in the radio access network (RAN) part of the communication network (e.g. in the case of an RNC in UTRAN) or a node in a core network part of the communication network (e.g. a mobility management entity, MME, or serving gateway, SGW in an LTE communication network).
  • RAN radio access network
  • MME mobility management entity
  • SGW serving gateway
  • the signalling described is either via direct links or logical links (e.g. via higher layer protocols and/or via one or more network nodes).
  • FIG. 7 shows exemplary components of a radio access node 40 (e.g. a Node B in UMTS) that can be used in one or more of the embodiments described below.
  • the radio access node 40 comprises a processing unit 42 that controls the operation of the radio access node 40.
  • the processing unit 42 is connected to transceiver circuitry 44 with one or more associated antenna(s) 46 which are used to transmit signals to, and receive signals from, terminal devices in the network over the air (i.e. over an air interface).
  • the radio access node 40 also comprises a memory unit 48 that is connected to the processing unit 42 and that stores information and data required for the operation of the radio access node 40.
  • the radio access node 40 also includes components and/or circuitry 50 for allowing the radio access node 40 to exchange information with a control node (e.g. an RNC, typically via the lub interface).
  • Figure 8 shows exemplary components of a control node 60 (e.g. an RNC in UMTS) that can be used in one or more of the embodiments described below.
  • the control node 60 comprises a processing unit 62 that controls the operation of the control node 60.
  • the processing unit 62 is connected to components and/or circuitry 64 for allowing the control node 60 to exchange information with the radio access node(s) 40 with which it is associated (which is typically via the lub interface), and components or circuitry 66 for allowing the control node 60 to exchange information with the core network.
  • the control node 60 also comprises a memory module 46 that is connected to the processing module 40 and that stores information and data required for the operation of the control node 60.
  • UTRAN i.e. Node Bs and RNCs
  • UE user equipments
  • UTRAN and the other UTRAN-specific terminology used herein
  • E-UTRAN evolved UTRAN
  • a control node e.g. RNC
  • RBS radio access node
  • Node B a radio access node
  • the control node can mark the data units when they are sent to the radio access node.
  • These specific data units may include downlink user plane data, L2 and/or L3 control plane data, including (but not limited to) RLC control data and acknowledgements for uplink user plane and control plane data.
  • the radio access node can then keep track of these specific data units and when the delivery of the data units are acknowledged by the terminal device at L1 , the radio access node informs the control node about the delivery results, so that the control node can skip or avoid waiting for a higher layer retransmission and/or higher layer acknowledgment from the terminal device.
  • This overall procedure in the context of an RNS and Node B is illustrated by the flow chart in Figure 9.
  • step 901 the RNC 60 indicates in the lub frame protocol that a L1 delivery result is required for one or more specific data units.
  • the Node B 40 then keeps track of the L1 delivery status of the one or more data units (step 903). Once the delivery status is known (e.g. delivered or undelivered), the Node B 40 sends the delivery result to the RNC 60 (step 905), and the RNC 60 acts according to the delivery result (step 907).
  • an RNC (or more generally a control node) can mark specific user-plane and/or control-plane data sent to a Node B (or more generally a radio access node) over the lub interface for the purpose of requesting an explicit L1 delivery report. It will be appreciated that if the Node B is connected to the SRNC via a DRNC, the described solutions can also be applied to communications over the lur interface.
  • the following description also indicates techniques by which a radio access node can provide L1 feedback of the delivery results to a control node.
  • the RBS sends the data unit to the UE over a transport channel, which has its own protocols. This is done in the MAC layer which is part of Layer 2.
  • the protocol(s) add headers and possibly other information such as CRC before it is handed down to the physical layer for transmission over the air.
  • the physical layer also adds other processing (coding, modulation, etc.) before transmission.
  • the HARQ protocol enables fast retransmission in the MAC layer (rather than the RLC layer), and it requires that the peer entity (i.e. the reception side of the transport channel) in the MAC layer of the UE transmits an ACK when it receives the data.
  • the ACK is sent on a physical control channel (the HS-DPCCH) dedicated for the purpose. If no ACK is received, the MAC layer would retransmit the data again for a certain number of times before it gives up. Thus, the MAC layer knows if the delivery over the air is successful (an ACK is received) or failed (it has given up without receiving an ACK).
  • the techniques described herein provide that the RBS provides information to the RNC on whether the data unit has been delivered over the air based on delivery information obtained from the HARQ protocol.
  • the marking of a data unit by the RNC for the purpose of requesting L1 delivery feedback can be done in different ways.
  • the MAC-d PDUs which contain the data units, are transferred over the lub on an lub data frame from the RNC to the Node B.
  • marking at the data-frame level and marking at the MAC-d PDU level. The details depends to a certain extent on whether the HS-DSCH Data Frame Type 1 or the HS-DSCH Data Frame Type 2 is being used. The two approaches set out below can also be combined and used together.
  • Solution 1 Marking at the lub data-frame level - This solution is most appropriate when the data unit that delivery information is being requested for is contained in a single lub data frame that contains no other data. It can be accomplished by introducing a flag in the lub data frame that, when set, indicates to the RBS that a L1 delivery report is to be provided. There are at least two ways of achieving this. The first is to make use of the spare bits 32 in the header 24 or in the payload 26 of the data frame 22. The second is to introduce such an indication in the spare extension.
  • the marking of a data frame using spare bits can be achieved, e.g., by using one of the four spare bits 32 in the beginning of the payload 26, i.e., before the first MAC-d PDU 28.
  • the marking of a data frame using spare bits can be achieved using one of the spare bits 34 at bit 0-2 on the 4th octet in the header 24.
  • the next unused "New IE Flag" 36 from either of the Type 1 or Type 2 data frame can be selected and a new Indication can be defined.
  • Solution 2 Marking at the MAC-d PDU level - This solution is most appropriate when the data unit that delivery information is being requested for is contained in a data frame together with other data units. It can however, also be used when the data frame only contains the data unit that delivery information is being requested for. Like solution 1 , this marking can also be done by making use of the spare bits or by introducing a new IE by means of a new "New IE Flag" in the spare extension. For HS-DSCH Data Frame Type 1 the marking of a MAC-d PDU using spare bits can be achieved by using one of the four spare bits 32 before each of the MAC-d PDUs.
  • the bit used can be the same bit as the one used for Solution 1 , or it can be a different bit, for example if the two solutions are to be used together or not.
  • the marking of a MAC-d PDU using spare bits can be achieved by using the single spare bit after the "MAC-d PDU length in block n" IE in the header 24.
  • an overall flag like the one in Solution 1 , can also be used to indicate at the data-frame level that a L1 delivery report is required for some of the PDUs in the data frame.
  • the next unused "New IE Flag" from either of the Type 1 or Type 2 data frame can be selected.
  • a new IE is needed to indicate the individual MAC-d PDUs that delivery information is required.
  • the MAC-d PDUs in the data frame can be numbered from 0 to N, and a bitmap may be defined with each bit indicating one MAC-d PDU in the data frame.
  • the data unit that delivery information is being requested for may be split into many MAC-d PDUs that are put into multiple lub data frames.
  • Solution 1 For data frames that contain only PDUs from the required data unit, Solution 1 can be used.
  • Solution 2 For the last (or first) data frame that may contain PDUs from other data units, Solution 2 can be used.
  • the RNC needs to identify which frame is the last data frame. This can be done, for example, using a 1-bit more-to-come flag, although those skilled in the art will appreciate that other solutions are possible.
  • a spare bit from the first octet in the payload 26 of the Type 1 data frame or the 4th octet in the header 24 of the Type 2 data frame can be used for this purpose.
  • this information can also be carried in a new IE introduced by a new "New IE Flag" in the spare extension.
  • the Node B After receiving a data frame and an indication that L1 delivery feedback is required, the Node B monitors the delivery of the MAC-d PDUs from the data frame over the air interface (i.e. the Node B monitors the HARQ protocol associated with the MAC-d PDUs). The result could be a successful or unsuccessful delivery over the air interface. The Node B then needs to return this delivery information to the RNC. In order to do this in an unambiguous way (i.e. in such a way that ensures the RNC knows exactly which PDUs have been successfully received (or not), an identification is needed for each request of a L1 delivery report.
  • a 3-bit number may be used as a Request ID (i.e. an identifier of the request).
  • a Request ID i.e. an identifier of the request.
  • the Request ID can also used as the marking flag (i.e. the flag to indicate that delivery information is required).
  • the Request ID can be introduced as a new IE using a new "New IE Flag" in the spare extension for both the Type 1 and Type 2 data frames.
  • the delivery report can indicate the overall result, with the delivery being indicated as successful only if all of the marked PDUs are delivered successfully. 2. Alternatively the delivery report can indicate the results per-PDU.
  • per- PDU reporting can be used with marking at the data-frame level.
  • the L1 delivery report may be implemented in the lub interface user-plane protocol by either using a new control frame, or modifying an existing control or data frame sent from the Node B to the RNC.
  • Figure 10 shows an example of a new lub control frame that could be used for this purpose. It defines a new Control Frame Type in the header 80 and carries the Request ID followed by an optional HS-DSCH Radio Network Temporary Identity (H-RNTI) in the payload 82 in case the report is sent on a common channel.
  • the payload 82 also includes a HI (H-RNTI Indication) field that indicates whether a 16-bit H-RNTI follows the Request ID.
  • One or more delivery results (Rx) then follow.
  • the bit labelled "Ex” is an extension bit indicating if another octet of results follows.
  • lub control plane Node B Application Part, NBAP
  • Those skilled in the art will be aware of alternative ways in which the delivery information can be sent from the Node B to the RNC.
  • a minimal scheme can be created by restricting the data unit (whose delivery report is required) to be included in a single data frame by itself, i.e., without including data from any other data units. The marking can then be done on the data-frame level with no ambiguity.
  • Figures 1 1 (a) and 1 1 (b) show implementations for the Type 1 and Type 2 HS-DSCH data frames respectively for this minimal scheme that use the existing spare bits.
  • Figure 1 1 (a) three of the four spare bits at the start of the first MAC-d PDU 28 in the payload 26 are used for the Request ID 84.
  • Figure 1 1 (b) the three spare bits in the header 24 are used for the Request ID 86.
  • Figure 12 shows the minimal implementation of a L1 delivery feedback request using a new IE indicated by a new "New IE Flag" in the spare extension. This implementation is common to both types of data frames, differing only in the position of the next available "New IE Flag" field.
  • FIG. 12 The example shown in Figure 12 is for the HS-DSCH Data Frame Type 1 , where the next available New IE Flag is used as a "Request ID Flag" which, when set, indicates that there is a "Request ID” IE in one of the following octets.
  • the Request ID in the HS-DSCH data frame is used also for marking the data-frame that the RNC is requesting the L1 delivery report for.
  • the delivery report remains the same as that shown in Figure 10, but will contain only one reported result (R1).
  • FIG. 13 is a flow chart illustrating an exemplary method of operating a control node 60 in a communication network according to the techniques presented herein.
  • the control node 60 sends a data unit for a terminal device 8 to a radio access node 40 in the communication network.
  • the data unit can comprise user plane data and/or control plane data.
  • the user plane data and/or control plane data can originate in a Layer 2 or Layer 3 protocol.
  • control node is an RNC
  • the radio access node is a Node B
  • the communication network is a UTRAN.
  • control node is a node in an Evolved Packet Core, EPC
  • the radio access node is an eNodeB in a E-UTRAN.
  • step 1303 the control node 60 sends a delivery information request for the data unit to the radio access node 40.
  • the delivery information request requests the radio access node provide delivery information for the data unit that indicates whether the data unit was successfully received by the terminal device over an air interface.
  • the steps of sending a data unit (step 1301) and/or sending a delivery information request (step 1303) are performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol).
  • the delivery information request can be indicated in an lub frame protocol, e.g. in an lub data frame.
  • the data unit can be carried inside a payload of a data frame that comprises a payload and a header.
  • the delivery information can be indicated in the payload or the header of the data frame.
  • the delivery information request can be indicated in a MAC PDU.
  • the delivery information request is included in a HS-DSCH Data Frame Type 1 or HS-DSCH Data Frame Type 2.
  • step 1305 the control node 60 receives delivery information for the data unit from the radio access node 40.
  • the delivery information is based on a HARQ protocol that is used by the radio access node 40 to transmit the data unit to the terminal device over the air interface.
  • step 1305 is performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol).
  • the delivery information is received in an lub frame protocol, e.g. an lub control frame.
  • step 1301 can comprise sending a plurality of data units, and step 1305 can comprise receiving delivery information for each of the plurality of data units.
  • step 1301 can comprise sending a plurality of data units, and step 1305 can comprise receiving a piece of single delivery information covering all of the data units.
  • an indication that the transmission is successful may only be provided if all of the plurality of data units have been successfully transmitted.
  • step 1301 can comprise sending a plurality of data units, and the delivery information request can request the radio access node provide delivery information in respect of a specific one or more (i.e. not all) of the plurality of data units.
  • the delivery information request comprises an identifier for the data unit that is the subject of the request
  • the received delivery information comprises an identifier for the data unit that is the subject of the delivery information.
  • the method further comprises the step of using the received delivery information for the data unit to determine an action to perform in respect of a higher layer communication protocol in the control node.
  • the step of using the received delivery information can comprise initiating a retransmission of the data unit according to the higher layer communication protocol.
  • the higher layer communication protocol can be a Layer 2 communication protocol or a Layer 3 communication protocol.
  • FIG 14 is a flow chart illustrating an exemplary method of operating a radio access node 40.
  • the radio access node 40 receives a data unit for a terminal device from a control node 60 in the communication network.
  • the data unit can comprise user plane data and/or control plane data.
  • the user plane data and/or control plane data can originate in a Layer 2 or Layer 3 protocol.
  • control node is an RNC
  • the radio access node is a Node B
  • the communication network is a UTRAN.
  • control node is a node in an Evolved Packet Core, EPC
  • the radio access node is an eNodeB in a E-UTRAN.
  • the radio access node 40 receives a delivery information request for the data unit from the control node.
  • the delivery information request requests the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface.
  • the step of receiving a data unit (step 1401) and/or receiving a delivery information request (step 1403) are performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol).
  • the delivery information request can be indicated in an lub frame protocol, e.g. in an lub data frame.
  • the data unit can be carried inside a payload of a data frame that comprises a payload and a header.
  • the delivery information request is indicated in the payload or the header of the data frame.
  • the delivery information request can be indicated in a MAC PDU.
  • the delivery information request is included in a HS-DSCH Data Frame Type 1 or a HS-DSCH Data Frame Type 2.
  • step 1405 the radio access node 40 transmits the data unit to the terminal device over the air interface using a HARQ protocol.
  • the radio access node 40 then receives an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface (step 1407).
  • This indication can be an acknowledgement (ACK) message or a negative acknowledgement (NACK) message.
  • the radio access node 40 then sends delivery information for the data unit to the control node 60.
  • the delivery information is based on the indication according to the HARQ protocol and indicates whether the data unit was successfully received by the terminal device over the air interface.
  • step 1409 is performed using a transport layer communication protocol (e.g. the Transport Network Layer protocol).
  • the delivery information is sent in an lub frame protocol, e.g. in an lub control frame.
  • step 1401 can comprise receiving a plurality of data units
  • step 1409 can comprise sending delivery information for each of the plurality of data units.
  • step 1401 can comprise receiving a plurality of data units, and step 1409 can comprise sending a piece of single delivery information covering all of the data units.
  • an indication that the transmission is successful may only be provided if all of the plurality of data units have been successfully transmitted.
  • step 1401 can comprise receiving a plurality of data units, and the delivery information request can request the radio access node provide delivery information in respect of a specific one or more (i.e. not all) of the plurality of data units.
  • the delivery information request comprises an identifier for the data unit that is the subject of the request, and the sent delivery information comprises an identifier for the data unit that is the subject of the delivery information.
  • FIG. 15 is a block diagram of a control node 60 according to another exemplary embodiment.
  • a control node 60 is for use in a communication network and comprises a processor 1501 and a memory 1502.
  • the memory 1502 contains instructions executable by the processor 1501 , whereby said control node 60 is operative to send a data unit for a terminal device to a radio access node 40 in the communication network, send a delivery information request for the data unit to the radio access node 40, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface, and receive delivery information for the data unit from the radio access node 40, the delivery information being based on a HARQ protocol used by the radio access node 40 to transmit the data unit to the terminal device over the air interface.
  • FIG 16 is a block diagram of a radio access node 40 according to another exemplary embodiment.
  • the radio access node 40 is for use in a communication network and comprises a processor 1601 and a memory 1602.
  • the memory 1602 contains instructions executable by the processor 1601 , whereby the radio access node 40 is operative to receive a data unit for a terminal device from a control node 60 in the communication network; receive a delivery information request for the data unit from the control node 60, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; transmit the data unit to the terminal device over the air interface using a HARQ protocol; receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface; and send delivery information for the data unit to the control node 60, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • FIG 17 is a block diagram of a control node 60 according to yet another exemplary embodiment.
  • the control node 60 is for use in a communication network and comprises a first sending module 1701 , a second sending module 1702 and a first receiving module 1703.
  • the first sending module 1701 is configured to send a data unit for a terminal device to a radio access node 40 in the communication network.
  • the second sending module 1702 is configured to send a delivery information request for the data unit to the radio access node 40, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface.
  • the first receiving module 1703 is configured to receive delivery information for the data unit from the radio access node 40, the delivery information being based on a HARQ protocol used by the radio access node 40 to transmit the data unit to the terminal device over the air interface.
  • FIG. 18 is a block diagram of a radio access node 40 according to yet another exemplary embodiment.
  • the radio access node 40 is for use in a communication network and comprises a first receiving module 1801 , a second receiving module 1802, a first transmitting module 1803, a third receiving module 1804 and a first sending module 1805.
  • the first receiving module 1801 is configured to receive a data unit for a terminal device from a control node 60 in the communication network.
  • the second receiving module 1802 is configured to receive a delivery information request for the data unit from the control node 60, the delivery information request requesting the radio access node 40 provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface.
  • the first transmitting module 1803 is configured to transmit the data unit to the terminal device over the air interface using a HARQ protocol.
  • the third receiving module 1804 is configured to receive an indication according to the HARQ protocol of whether the data unit was successfully received by the terminal device over the air interface.
  • the first sending module 1805 is configured to send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • a method of operating a control node in a communication network comprising:
  • the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface
  • the radio access node receiving delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • step of sending a data unit comprises sending a plurality of data units
  • step of receiving delivery information for the data unit comprises receiving respective delivery information for each of the plurality of data units.
  • a method as defined in statement 1 or 2 wherein the step of sending a data unit comprises sending a plurality of data units, and wherein the step of receiving delivery information for the data unit comprises receiving a single delivery information in respect of the plurality of data units. 5. A method as defined in any of statements 1-4, wherein the step of sending a data unit comprises sending a plurality of data units, and wherein the delivery information request requests the radio access node provide delivery information in respect of a specific one or more of the plurality of data units.
  • the delivery information request comprises an identifier for the data unit that is the subject of the request
  • the received delivery information comprises an identifier for the data unit that is the subject of the delivery information
  • the step of using the received delivery information comprises initiating a retransmission of the data unit according to the higher layer communication protocol.
  • control node is a Radio Network Controller, RNC
  • radio access node is a Node B
  • communication network is a Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, UTRAN.
  • control node is a node in an Evolved Packet Core
  • EPC of the communication network and the radio access node is an eNodeB is in an Evolved-Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, E-UTRAN.
  • a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of statements 1-18.
  • a control node for use in a communication network the control node being adapted to:
  • the radio access node sends a delivery information request for the data unit to the radio access node, the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface; and receive delivery information for the data unit from the radio access node, the delivery information being based on a hybrid automatic repeat request, HARQ, protocol used by the radio access node to transmit the data unit to the terminal device over the air interface.
  • HARQ hybrid automatic repeat request
  • control node is further adapted to perform the method steps set out in any of statements 2-18. 21.
  • a method of operating a radio access node in a communication network comprising:
  • the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface
  • the control node sending delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • step of receiving a data unit comprises receiving a plurality of data units, and wherein the delivery information request requests the radio access node provide delivery information in respect of a specific one or more of the plurality of data units.
  • control node is a Radio Network Controller, RNC
  • radio access node is a Node B
  • communication network is a Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, UTRAN.
  • control node is a node in an Evolved Packet Core
  • EPC of the communication network and the radio access node is an eNodeB is in an Evolved-Universal Mobile Telecommunications System, UMTS, Terrestrial Radio Access Network, E-UTRAN.
  • a computer program product comprising a computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform the method of any of statements 21-36.
  • a radio access node for use in a communication network the radio access node being adapted to:
  • the delivery information request requesting the radio access node provide delivery information that indicates whether the data unit was successfully received by the terminal device over an air interface
  • radio access node send delivery information for the data unit to the control node, the delivery information being based on the HARQ protocol and indicating whether the data unit was successfully received by the terminal device over the air interface.
  • the radio access node is further adapted to perform the method steps set out in any of statements 22-36.
  • a method for a first node in a mobile communication network with a multi-layer communication protocol to obtain lower-layer transmission information of specific data units from a second network node that is responsible for the delivery of the data units to a communication device can comprise a requesting mechanism for the first network node to indicate to the second network node the specific data unit for which information on delivery results are wanted, and a reporting mechanism for the second network node to provide the wanted delivery information to the first network node.
  • E. A method as defined in D, wherein some or all of the following request information is provided in each data frame that contains data whose delivery information is wanted: (i) an identifier for the request; (ii) the part of the payload in the data frame where delivery information is wanted; (iii) whether a single delivery result should be provided for the entire request or separately for each indicated part in the request; and (iv) whether the request includes data from a following data frame.
  • a method as defined in D wherein the data unit whose delivery information is wanted is always contained in a single data frame that contains no other data units and reporting is to be provided always on a per-request basis.
  • G A method as defined in E or F, wherein the information on the request is provided using spare bits in the data frame.
  • J. A method as defined in any of A-l, wherein the reporting mechanism is realised using a new or modified control frame of the lub user-plane protocols, with the control frame containing (i) the identifier for the original request; and/or (ii) whether the delivery of each separately-indicated part is successful or not.

Landscapes

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

Abstract

L'invention concerne des procédés et des nœuds destinés à être utilisés dans un réseau de communication. Selon un aspect, un procédé permettant de faire fonctionner un nœud de commande dans un réseau de communication comprend les étapes suivantes : envoi à un nœud d'accès radio du réseau de communication d'une unité de données destinée à un terminal; envoi au nœud d'accès radio d'une demande d'informations de livraison de l'unité de données, la demande d'informations de livraison demandant au nœud d'accès radio de fournir des informations indiquant si l'unité de données a été correctement reçue par le terminal sur une interface radio; et réception des informations de livraison de l'unité de données provenant du nœud d'accès radio, les informations de livraison étant basées sur un protocole de demande de répétition automatique hybride (HARQ) utilisé par le nœud d'accès radio pour transmettre l'unité de données au dispositif sur l'interface radio.
PCT/SE2016/050871 2015-09-25 2016-09-16 Procédés et nœuds pour utilisation dans un réseau de communication Ceased WO2017052449A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201562232701P 2015-09-25 2015-09-25
US62/232,701 2015-09-25

Publications (1)

Publication Number Publication Date
WO2017052449A1 true WO2017052449A1 (fr) 2017-03-30

Family

ID=58386716

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SE2016/050871 Ceased WO2017052449A1 (fr) 2015-09-25 2016-09-16 Procédés et nœuds pour utilisation dans un réseau de communication

Country Status (1)

Country Link
WO (1) WO2017052449A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009115261A1 (fr) * 2008-03-17 2009-09-24 Panasonic Corporation Gestion de processus harq améliorée
WO2013104413A1 (fr) * 2012-01-10 2013-07-18 Nokia Siemens Networks Oy Fourniture d'un support radio sur une pluralité de porteuses composantes
WO2013137802A2 (fr) * 2012-03-14 2013-09-19 Telefonaktiebolaget L M Ericsson (Publ) Procédés et dispositifs pour un reporting dans un réseau radio mobile cellulaire
WO2015017373A1 (fr) * 2013-07-30 2015-02-05 Qualcomm Incorporated Transmission d'informations de commande en liaison montante (uci) avec considérations de groupage
WO2015048248A1 (fr) * 2013-09-26 2015-04-02 Qualcomm Incorporated Mécanisme pour échanger des messages de signalisation de propriétaire entre un équipement utilisateur (ue) et un réseau

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009115261A1 (fr) * 2008-03-17 2009-09-24 Panasonic Corporation Gestion de processus harq améliorée
WO2013104413A1 (fr) * 2012-01-10 2013-07-18 Nokia Siemens Networks Oy Fourniture d'un support radio sur une pluralité de porteuses composantes
WO2013137802A2 (fr) * 2012-03-14 2013-09-19 Telefonaktiebolaget L M Ericsson (Publ) Procédés et dispositifs pour un reporting dans un réseau radio mobile cellulaire
WO2015017373A1 (fr) * 2013-07-30 2015-02-05 Qualcomm Incorporated Transmission d'informations de commande en liaison montante (uci) avec considérations de groupage
WO2015048248A1 (fr) * 2013-09-26 2015-04-02 Qualcomm Incorporated Mécanisme pour échanger des messages de signalisation de propriétaire entre un équipement utilisateur (ue) et un réseau

Similar Documents

Publication Publication Date Title
US12224869B2 (en) Duplication and RLC operation in new radio access technology
US12047807B2 (en) Method for processing data in consideration of TCP/IP
ES2604981T3 (es) Procedimiento para desplazar una ventana de recepción en una red de acceso de radio
US8413002B2 (en) Method of performing ARQ procedure for transmitting high rate data
US11129047B2 (en) Radio link control status reporting
KR101591824B1 (ko) 무선 통신 시스템에서의 폴링 과정 수행 방법
EP1871055A2 (fr) Procédé et appareil pour manipuler des données de liaison ascendante lors du transfert dans un système de communication sans fil
KR20180037960A (ko) 인핸스드 컴포넌트 캐리어들로의 패킷 데이터 수렴 프로토콜 (pdcp) 재순서화를 위한 방법, 장치들 및 컴퓨터 판독가능 매체
US20100067481A1 (en) Data retransmission method, network controller, mobile station and base station
WO2016077730A1 (fr) Signalisation de schéma de compression de données évolué
WO2017023438A1 (fr) Procédés et appareils de segmentation de commande d'accès au support (mac) et accusé de réception (ack) de protocole de convergence de données en mode paquet (pdcp) avec des porteuses composante améliorées (ecc)
EP2086272A1 (fr) Système de communication mobile et procédé de transmission de rapport d'état PDCP associé
EP3703416B1 (fr) Procédé et dispositif de transmission de données en cas de changement de version pdcp dans un système de communication sans fil
US20170012745A1 (en) Method and apparatus for triggering acknowledgement status report in wireless communications system
US20150135024A1 (en) Methods and apparatus for detecting frame number discontinuities between radio nodes
EP1868311B1 (fr) Évitement des demandes de retransmission dans un schéma de retransmission de paquets
US20140313981A1 (en) Handling Redundant Data in a Communication System
US10785687B2 (en) Inter-node B handover in HSDPA or multi-flow HSPA including packet retransmission
US20140029564A1 (en) Communication system, communication apparatus and radio resource allocating method
WO2017122268A1 (fr) Dispositif de communication sans fil, système de communication sans fil et procédé de communication sans fil
WO2017122267A1 (fr) Dispositif de communication sans fil, système de communication sans fil, et procédé de communication sans fil
US12531669B2 (en) Data indicator handling for HARQ transmissions during C-DRX mode
KR101617044B1 (ko) 피어 엔티티의 전송 상태 정보를 이용한 데이터 유닛 재전송 방법
WO2017052449A1 (fr) Procédés et nœuds pour utilisation dans un réseau de communication
WO2025210190A1 (fr) Procédé de gestion de transmission de données dans un réseau de communication

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

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16849105

Country of ref document: EP

Kind code of ref document: A1