[go: up one dir, main page]

WO2018080565A1 - Procédures de transfert et de réception de données dans des communications de liaison latérale 5g/s - Google Patents

Procédures de transfert et de réception de données dans des communications de liaison latérale 5g/s Download PDF

Info

Publication number
WO2018080565A1
WO2018080565A1 PCT/US2016/068256 US2016068256W WO2018080565A1 WO 2018080565 A1 WO2018080565 A1 WO 2018080565A1 US 2016068256 W US2016068256 W US 2016068256W WO 2018080565 A1 WO2018080565 A1 WO 2018080565A1
Authority
WO
WIPO (PCT)
Prior art keywords
pdu
tsl
sdu
harq
data
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/US2016/068256
Other languages
English (en)
Inventor
Satish Chandra Jha
Yaser M. FOUAD
Qian Li
Guangjie Li
Xiaoyun May Wu
Geng Wu
JoonBeom Kim
Vesh Raj SHARMA BANJADE
Lu LU
Hassan GHOZLAN
Dawei YING
Song Noh
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.)
Intel Corp
Original Assignee
Intel Corp
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 Intel Corp filed Critical Intel Corp
Publication of WO2018080565A1 publication Critical patent/WO2018080565A1/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
    • 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/1825—Adaptation of specific ARQ protocol parameters according to transmission conditions
    • 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/1829—Arrangements specially adapted for the receiver end
    • H04L1/1835—Buffer management
    • 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/1829—Arrangements specially adapted for the receiver end
    • H04L1/1848—Time-out mechanisms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/321—Interlayer communication protocols or service data unit [SDU] definitions; Interfaces between layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/162—Implementing security features at a particular protocol layer at the data link layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/04—Wireless resource allocation
    • H04W72/044—Wireless resource allocation based on the type of the allocated resource
    • H04W72/0446—Resources in time domain, e.g. slots or frames

Definitions

  • Embodiments pertain to radio access networks. Some embodiments relate to wearable devices in various cellular and wireless local area network (WLAN) networks, including Third Generation Partnership Project Long Term Evolution (3GPP LTE) networks and LTE advanced (LTE-A) networks as well as 4 th generation (4G) networks and 5 th generation (5G) networks. Some embodiments relate to 5G wearable or other“things” devices and network interactions, in particular handling of user and control plane data in sidelink communications.
  • WLAN wireless local area network
  • 3GPP LTE Third Generation Partnership Project Long Term Evolution
  • LTE-A LTE advanced
  • 5G 5 th generation
  • 3GPP LTE systems including both LTE and LTE-A systems
  • UEs user equipment
  • network resources such as network resources
  • IoT Internet of Things
  • MTC machine type communication
  • M2M machine-to-machine
  • tUE user-based IoT devices developed recently whose popularity has exploded is“things” user equipment (tUE), such as wearable devices, in addition to one or more network UEs (nUE).
  • wearable devices include fitness trackers, smart watches, and smart glasses.
  • Wearable devices typically have lower processing capability, a small battery capacity, and a low internal memory capacity.
  • each user may carry multiple wearable devices, and may be located in a highly-dense populated situation with other people carrying one or more other wearable devices and nUEs.
  • tUEs may have a mobility similar to that of nUEs and limited functionality compared to the nUEs, independent of the type of tUE.
  • the sidelink communication in the 5G network between a tUE and nUE remains to be determined due at least in part to the vast changes in design of the 5G network.
  • FIG.1 is a block diagram of a system architecture for supporting things devices in accordance with some embodiments.
  • FIG.2 illustrates components of a communication device in accordance with some embodiments.
  • FIG.3 illustrates a block diagram of a communication device in accordance with some embodiments.
  • FIG.4 illustrates another block diagram of a communication device in accordance with some embodiments.
  • FIG.5 illustrates a protocol stack in accordance with some embodiments.
  • FIGS.6A and 6B illustrate downlink and uplink subframe structures in accordance with some embodiments.
  • FIG.7 illustrates a flowchart of a method of transferring data in accordance with some embodiments.
  • FIG.1 is a block diagram of a system architecture 100 for supporting things devices.
  • the system architecture 100 includes a network user equipment (nUE) 110, one or more things user equipment (tUEs) 120a, 120b, 120c, an evolved universal terrestrial radio access network (E- UTRAN) base station (BS, also referred to as an evolved NodeB (eNB)) or 5G base station 130, and an evolved packet core (EPC) or 5G core 140.
  • the nUE 110 and the tUEs 120 together form a personal area network (PAN) 150 or side link cell.
  • the EUTRAN thus may include eNBs 130 that provide user plane and control plane protocol terminations towards the nUE 110.
  • the eNBs 130 may be connected by means of the X2 interface.
  • the eNBs 130 may also be connected to a Mobility Management Entity (MME) the via a S1-MME and to a Serving Gateway (S-GW) via a S1-U.
  • MME Mobility Management Entity
  • S-GW Serving Gateway
  • the nUE 110 may be any user equipment capable of
  • the nUE 110 may be a mobile phone, a tablet computer, a wearable device such as a smart watch, etc.
  • the nUE may be a tUE that is capable of communicating with the base station 130 and has sufficient battery life (e.g., greater than 30%, 50%, 75%, 90% of the maximum amount of battery power etc.).
  • the nUE 110 may have a full infrastructure network access protocol and full control and user plane (C/U-dlane) functions. As shown, the nUE 110 may communicate with the base station 130 via a Xu-d (direct) air interface.
  • Each tUE 120 may include a wireless interface (Xu-d or Xu-s) for communicating within the PAN 150.
  • the tUE 120 may communicate with the nUE 110 or another tUE 120 through the Xu-s (sidelink) intra-PAN air interface.
  • the tUE 120 may include, for example, smart watches, smart glasses, smart headphones, fitness sensors, movement trackers, sleep sensors, etc.
  • the tUE 120 may also communicate directly with the base station 130 via a Xu-d air interface.
  • the tUE 120 may be unable to communicate directly with the base station 130.
  • the nUE 110 may act as a master UE in a sidelink cell formed by the nUE 110 and associated tUEs 120.
  • the tUE 120 may have a full sidelink protocol stack and may or may not have standalone direct link protocol stack.
  • the tUE 120 may act as a slave UE in the side link cell.
  • the base station 130 may be a base station of a cellular network.
  • the base station 130 is may be an eNB in a LTE cellular network or a 5G Radio Access Network (RAN) in a next generation (5G) network.
  • the 5G RAN may be a standalone base station or a booster cell anchored to an eNB.
  • the base station 130 may communicate with a core network 140 (EPC for LTE or 5G core for 5G) using an S1 interface.
  • EPC LTE or 5G core for 5G
  • Some aspects of the subject technology are directed to defining the air interface between the base station and the PAN of the nUE 110 and the tUEs 120, while other aspects are directed to defining the intra-PAN air interface for enabling low power operation with diverse traffic and application requirements.
  • aspects of the subject technology may be implemented in conjunction with a LTE network, and, in some cases, leverages device-to-device (D2D) and machine-type communications (MTC) technology.
  • D2D device-to-device
  • MTC machine-type communications
  • aspects of the subject technology address high-density scenarios.
  • LTE-D2D some aspects of the subject technology enable PAN-specific identity, unicast in intra-PAN communication, uplink and downlink features, and operation in unlicensed bands.
  • LTE-MTC some aspects of the subject technology provide support for diverse traffic, including high rate traffic and low latency traffic.
  • the base station 130 may be a macro base station or a smaller base station (micro, pico, nano) that may terminate the air interface protocol.
  • the base station 130 may fulfill various logical functions for the RAN including, but not limited to, RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.
  • RNC radio network controller functions
  • UEs 120 may be configured to communicate orthogonal frequency division multiplexed (OFDM) communication signals with the base station 130 over a multicarrier communication channel in accordance with an OFDMA communication technique.
  • the OFDM signals may comprise a plurality of orthogonal subcarriers.
  • non-OFDM signals may be used in addition or instead of OFDM signals.
  • the S1 interface may be the interface that separates the RAN 130 and the core network 140.
  • the S1 interface may be split into two parts: the S1- U, which may carry traffic data between base stations of the RAN 130 and other elements of the core network, such as a serving GW, and the S1-MME, which may be a signaling interface between the RAN 130 and an MME.
  • FIG.2 illustrates components of a communication device in accordance with some embodiments.
  • the communication device 200 may be a UE, eNB or other network component as described herein.
  • the communication device 200 may be a stationary, non-mobile device or may be a mobile device.
  • the UE 200 may include application circuitry 202, baseband circuitry 204, Radio Frequency (RF) circuitry 206, front-end module (FEM) circuitry 208 and one or more antennas 210, coupled together at least as shown.
  • RF Radio Frequency
  • FEM front-end module
  • At least some of the baseband circuitry 204, RF circuitry 206, and FEM circuitry 208 may form a transceiver.
  • other network elements, such as the MME may contain some or all of the components shown in FIG.2.
  • the application or processing circuitry 202 may include one or more application processors.
  • the application circuitry 202 may include circuitry such as, but not limited to, one or more single-core or multi- core processors.
  • the processor(s) may include any combination of general- purpose processors and dedicated processors (e.g., graphics processors, application processors, etc.).
  • the processors may be coupled with and/or may include memory/storage and may be configured to execute instructions stored in the memory/storage to enable various applications and/or operating systems to run on the system.
  • the baseband circuitry 204 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
  • the baseband circuitry 204 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 206 and to generate baseband signals for a transmit signal path of the RF circuitry 206.
  • Baseband processing circuity 204 may interface with the application circuitry 202 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 206.
  • the baseband circuitry 204 may include a second generation (2G) baseband processor 204a, third generation (3G) baseband processor 204b, fourth generation (4G) baseband processor 204c, and/or other baseband processor(s) 204d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 5G, etc.).
  • the baseband circuitry 204 e.g., one or more of baseband processors 204a-d
  • the radio control functions may include, but are not limited to, signal modulation/demodulation,
  • modulation/demodulation circuitry of the baseband circuitry 204 may include FFT, precoding, and/or constellation mapping/demapping functionality.
  • encoding/decoding circuitry of the baseband circuitry 204 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality.
  • LDPC Low Density Parity Check
  • the baseband circuitry 204 may include elements of a protocol stack such as, for example, elements of an Evolved UTRAN (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), radio resource control (RRC) elements, and/or Non-Access Stratum (NAS) elements.
  • EUTRAN Evolved UTRAN
  • a central processing unit (CPU) 204e of the baseband circuitry 204 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers, and/or NAS.
  • the protocol layers shown in FIG.5 may be implemented in the baseband circuitry 204 and run by the CPU 204e.
  • the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 204f.
  • the audio DSP(s) 204f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.
  • Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 204 and the application circuitry 202 may be
  • SOC system on a chip
  • the baseband circuitry 204 may provide for communication compatible with one or more radio technologies.
  • the baseband circuitry 204 may support communication with an EUTRAN and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN).
  • WMAN wireless metropolitan area networks
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • Embodiments in which the baseband circuitry 204 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.
  • the device can be configured to operate in accordance with communication standards or other protocols or standards, including Institute of Electrical and Electronic Engineers (IEEE) 802.16 wireless technology (WiMax), IEEE 802.11 wireless technology (WiFi) including IEEE 802.11 ad, which operates in the 60 GHz millimeter wave spectrum, various other wireless technologies such as global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE), GSM EDGE radio access network (GERAN), universal mobile telecommunications system (UMTS), UMTS terrestrial radio access network (UTRAN), or other 2G, 3G, 4G, 5G, etc. technologies either already developed or to be developed.
  • RF circuitry 206 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium.
  • the RF circuitry 206 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.
  • RF circuitry 206 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 208 and provide baseband signals to the baseband circuitry 204.
  • RF circuitry 206 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 204 and provide RF output signals to the FEM circuitry 208 for transmission.
  • the RF circuitry 206 may include a receive signal path and a transmit signal path.
  • the receive signal path of the RF circuitry 206 may include mixer circuitry 206a, amplifier circuitry 206b and filter circuitry 206c.
  • the transmit signal path of the RF circuitry 206 may include filter circuitry 206c and mixer circuitry 206a.
  • RF circuitry 206 may also include synthesizer circuitry 206d for synthesizing a frequency for use by the mixer circuitry 206a of the receive signal path and the transmit signal path.
  • the mixer circuitry 206a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 208 based on the synthesized frequency provided by synthesizer circuitry 206d.
  • the amplifier circuitry 206b may be configured to amplify the down-converted signals and the filter circuitry 206c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals.
  • LPF low-pass filter
  • BPF band-pass filter
  • Output baseband signals may be provided to the baseband circuitry 204 for further processing.
  • the output baseband signals may be zero-frequency baseband signals, although this is not a requirement.
  • mixer circuitry 206a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.
  • the mixer circuitry 206a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 206d to generate RF output signals for the FEM circuitry 208.
  • the baseband signals may be provided by the baseband circuitry 204 and may be filtered by filter circuitry 206c.
  • the filter circuitry 206c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.
  • the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively.
  • the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 206a of the receive signal path and the mixer circuitry 206a of the transmit signal path may be configured for super-heterodyne operation.
  • the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect.
  • the output baseband signals and the input baseband signals may be digital baseband signals.
  • the RF circuitry 206 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 204 may include a digital baseband interface to communicate with the RF circuitry 206.
  • ADC analog-to-digital converter
  • DAC digital-to-analog converter
  • a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.
  • the synthesizer circuitry 206d may be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable.
  • synthesizer circuitry 206d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.
  • the synthesizer circuitry 206d may be configured to synthesize an output frequency for use by the mixer circuitry 206a of the RF circuitry 206 based on a frequency input and a divider control input.
  • the synthesizer circuitry 206d may be a fractional N/N+1 synthesizer.
  • frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement.
  • VCO voltage controlled oscillator
  • Divider control input may be provided by either the baseband circuitry 204 or the applications processor 202 depending on the desired output frequency.
  • a divider control input (e.g., N) may be determined from a look- up table based on a channel indicated by the applications processor 202.
  • Synthesizer circuitry 206d of the RF circuitry 206 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator.
  • the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA).
  • the DMD may be configured to divide the input signal by either N or N+1 (e.g., based on a carry out) to provide a fractional division ratio.
  • the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop.
  • the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line.
  • Nd is the number of delay elements in the delay line.
  • synthesizer circuitry 206d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other.
  • the output frequency may be a LO frequency (fLO).
  • the RF circuitry 206 may include an IQ/polar converter.
  • FEM circuitry 208 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 210, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 206 for further processing.
  • FEM circuitry 208 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 206 for transmission by one or more of the one or more antennas 210.
  • the FEM circuitry 208 may include a TX/RX switch to switch between transmit mode and receive mode operation.
  • the FEM circuitry may include a receive signal path and a transmit signal path.
  • the receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 206).
  • LNA low-noise amplifier
  • the transmit signal path of the FEM circuitry 208 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 206), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 210.
  • PA power amplifier
  • the communication device 200 may include additional elements such as, for example, memory/storage, display, camera, sensor, and/or input/output (I/O) interface as described in more detail below.
  • the communication device 200 described herein may be part of a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless
  • PDA personal digital assistant
  • the communication device 200 may include one or more user interfaces designed to enable user interaction with the system and/or peripheral component interfaces designed to enable peripheral component interaction with the system.
  • the communication device 200 may include one or more of a keyboard, a keypad, a touchpad, a display, a sensor, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, a power supply interface, one or more antennas, a graphics processor, an application processor, a speaker, a microphone, and other I/O components.
  • the display may be an LCD or LED screen including a touch screen.
  • the sensor may include a gyro sensor, an accelerometer, a proximity sensor, an ambient light sensor, and a positioning unit.
  • the positioning unit may communicate with components of a positioning network, e.g., a global positioning system (GPS) satellite.
  • GPS global positioning system
  • the antennas 210 may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals.
  • the antennas 210 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.
  • the communication device 200 is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements.
  • processing elements including digital signal processors (DSPs), and/or other hardware elements.
  • some elements may comprise one or more microprocessors, DSPs, field-programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein.
  • the functional elements may refer to one or more processes operating on one or more processing elements.
  • Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein.
  • a computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer).
  • a computer-readable storage device may include read- only memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.
  • Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.
  • FIG.3 is a block diagram of a communication device in accordance with some embodiments.
  • the device may be a UE, for example, such as the UE shown in FIG.1.
  • the physical layer circuitry 302 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals.
  • the communication device 300 may also include medium access control layer (MAC) circuitry 304 for controlling access to the wireless medium.
  • the communication device 300 may also include processing circuitry 306, such as one or more single-core or multi-core processors, and memory 308 arranged to perform the operations described herein.
  • the physical layer circuitry 302, MAC circuitry 304 and processing circuitry 306 may handle various radio control functions that enable communication with one or more radio networks compatible with one or more radio technologies.
  • the radio control functions may include signal modulation, encoding, decoding, radio frequency shifting, etc.
  • communication may be enabled with one or more of a WMAN, a WLAN, and a WPAN.
  • the communication device 300 can be configured to operate in accordance with 3GPP standards or other protocols or standards, including WiMax, WiFi, WiGig, GSM, EDGE, GERAN, UMTS, UTRAN, or other 3G, 3G, 4G, 5G, etc. technologies either already developed or to be developed.
  • the communication device 300 may include transceiver circuitry 312 to enable communication with other external devices wirelessly and interfaces 314 to enable wired communication with other external devices.
  • the transceiver circuitry 312 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range.
  • RF Radio Frequency
  • the antennas 301 may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals.
  • the antennas 301 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.
  • the communication device 300 is illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including DSPs, and/or other hardware elements. For example, some elements may comprise one or more
  • the functional elements may refer to one or more processes operating on one or more processing elements.
  • Embodiments may be implemented in one or a combination of hardware, firmware and software. Embodiments may also be implemented as instructions stored on a computer- readable storage device, which may be read and executed by at least one processor to perform the operations described herein.
  • FIG.4 illustrates another block diagram of a communication device in accordance with some embodiments.
  • the communication device 400 may operate as a standalone device or may be connected (e.g., networked) to other communication devices.
  • the communication device 400 may operate in the capacity of a server communication device, a client communication device, or both in server- client network environments.
  • the communication device 400 may act as a peer communication device in peer-to-peer (P2P) (or other distributed) network environment.
  • P2P peer-to-peer
  • the communication device 400 may be a UE, eNB, PC, a tablet PC, a STB, a PDA, a mobile telephone, a smart phone, a web appliance, a network router, switch or bridge, or any communication device capable of executing instructions (sequential or otherwise) that specify actions to be taken by that communication device.
  • the term“communication device” shall also be taken to include any collection of communication devices that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.
  • Examples, as described herein, may include, or may operate on, logic or a number of components, modules, or mechanisms.
  • Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner.
  • circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module.
  • the whole or part of one or more computer systems (e.g., a standalone, client or server computer system) or one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations.
  • the software may reside on a communication device readable medium.
  • the software when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
  • module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.
  • modules are temporarily configured, each of the modules need not be instantiated at any one moment in time.
  • the modules comprise a general-purpose hardware processor configured using software
  • the general-purpose hardware processor may be configured as respective different modules at different times.
  • Software may accordingly configure a hardware processor, for example, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
  • Communication device 400 may include a hardware processor 402 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 404 and a static memory 406, some or all of which may communicate with each other via an interlink (e.g., bus) 408.
  • a hardware processor 402 e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof
  • main memory 404 e.g., main memory
  • static memory 406 e.g., static memory
  • the communication device 400 may further include a display unit 410, an alphanumeric input device 412 (e.g., a keyboard), and a user interface (UI) navigation device 414 (e.g., a mouse).
  • the display unit 410, input device 412 and UI navigation device 414 may be a touch screen display.
  • the communication device 400 may additionally include a storage device (e.g., drive unit) 416, a signal generation device 418 (e.g., a speaker), a network interface device 420, and one or more sensors 421, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
  • GPS global positioning system
  • the communication device 400 may include an output controller 428, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • a serial e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • USB universal serial bus
  • IR infrared
  • NFC near field communication
  • the storage device 416 may include a communication device readable medium 422 on which is stored one or more sets of data structures or instructions 424 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein.
  • the instructions 424 may also reside, completely or at least partially, within the main memory 404, within static memory 406, or within the hardware processor 402 during execution thereof by the communication device 400.
  • one or any combination of the hardware processor 402, the main memory 404, the static memory 406, or the storage device 416 may constitute communication device readable media.
  • the term "communication device readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 424.
  • the term“communication device readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the communication device 400 and that cause the communication device 400 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions.
  • Non-limiting communication device readable medium examples may include solid-state memories, and optical and magnetic media.
  • Specific examples of communication device readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks;
  • communication device readable media may include non-transitory communication device readable media.
  • communication device readable media may include communication device readable media that is not a transitory propagating signal.
  • the instructions 424 may further be transmitted or received over a communications network 426 using a transmission medium via the network interface device 420 utilizing any one of a number of transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.).
  • transfer protocols e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.
  • Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., IEEE 802.11 family of standards known as WiFi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, a LTE family of standards, a UMTS family of standards, peer-to-peer (P2P) networks, among others.
  • the network interface device 420 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 426.
  • the network interface device 420 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), MIMO, or multiple-input single-output (MISO) techniques.
  • SIMO single-input multiple-output
  • MISO multiple-input single-output
  • the network interface device 420 may wirelessly communicate using Multiple User MIMO techniques.
  • transmission medium shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the communication device 400, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
  • a tUE such as a wearable device or vehicle-embedded device may be temporarily or permanently constrained to communicate with the EUTRAN through a nUE.
  • Several tUEs may be associated with a particular nUE to form a PAN.
  • a large number of nUEs may be located in a particular geographical region served by a single EUTRAN.
  • Each nUE may be associated with a different PAN, which may create a high density network scenario.
  • the RAN may furthermore assign a common resource pool for wearable communication. This resource pool may be shared among all of the PANs in the geographical area and within each PAN on a contention-based resource access basis.
  • Each nUE may have two higher layer protocol stacks, one for the Xu-s interface with the tUE and one for the Xu-d interface with the EUTRAN.
  • the tUEs may have the same two higher layer protocol stacks or may have a single higher layer protocol stack for one for the Xu-s interface with the nUE.
  • FIG.5 illustrates a protocol stack in accordance with some embodiments.
  • the protocol stack may be provided in any of the nUEs or tUEs described in FIGS.1-4.
  • the higher layer protocol stack (tSL-HL) 504 may refer primarily to the protocol layers between the PHY (tSL-PHY) 506 and
  • the tSL-HL 504 may refer to one or more of the MAC, RLC and PDCP layers of legacy LTE protocol layers.
  • the tSL-HL 504 may comprise a transmission tSL-HL entity and a receiving tSL-HL entity.
  • packet processing may be used by the tSL- HL 504 to generate a tSL-HL packet data unit (PDU) for a given grant size for each of the UP and the CP data.
  • PDU packet data unit
  • the higher layer design may be reduced to a single layer to reduce packet processing time as well as packet header overhead.
  • the data transfer procedure for UP and CP data may include defined various variables, constant and timers for the tSL-HL transmit entity, methods to update various variables to handle and track the data transfer procedure, methods to assign and maintain a sequence number (SN) to tSL-HL service data units (SDUs), methods to buffer and monitor transfer status of each tSL-HL SDU as well as each tSL-HL PDU, a grant reception process, a mechanism to submit the tSL-HL PDU and grant information to a hybrid automatic repeat request (HARQ) process, and a HARQ process from a higher layer perspective.
  • SN sequence number
  • SDUs tSL-HL service data units
  • HARQ hybrid automatic repeat request
  • the data reception procedures for the UP and CP data may include a process to receive tSL-HL PDU from the lower layer; a process to place the tSL-HL PDU in a reception buffer; a definition of various variables, constant and timers for the tSL-HL receive entity, and methods to update various variables to handle and a track data reception procedure.
  • FIGS.6A and 6B illustrate downlink and uplink subframe structures in accordance with some embodiments.
  • the DL and UL subframe structures 610, 630 may be used by any of the nUEs or tUEs shown in FIGS.1- 5.
  • Each DL and UL subframe 610, 630 may be 1ms, although other numerologies such as subframe lengths of 0.25ms, 0.5ms, or 2ms can also be supported.
  • Each DL and UL subframe 610, 630 may be divided into multiple physical resource blocks (PRB) in the frequency domain in which each PRB may occupy 3 subcarriers over one subframe. For a subcarrier spacing of 60 kHz and subframe duration of 1ms, each PRB may occupy 180 kHz over 1 ms.
  • the PRBs may be grouped into subchannels in which each subchannel occupies 6 PRBs consecutive in the frequency domain. The minimum system bandwidth is of the size of a subchannel.
  • the channels may be transmitted on a PRA, which may be an aggregation of multiple continuous PRBs.
  • Each DL and UL subframe 610, 630 may be divided into a number of sections, each of which is addressed to the same tUE.
  • the first symbol in the subframe 610, 630 may be a common control channel 612 and may indicate whether the data channel 622 is an UL or DL data channel.
  • the common control channel 612 may be a DL common control channel independent of whether the data channel 622 in the subframe 610, 630 is UL or DL.
  • the common control channel 612 may have a 10 bit payload in which the UL/DL indication is a single bit.
  • the DL common control channel 612 may be followed by a Transmitter resource Acquisition and Sounding (TAS) channel 616.
  • TAS Transmitter resource Acquisition and Sounding
  • the TAS channel 616 may be a DL channel in the DL subframe 610 and an UL channel in the UL subframe 630.
  • the TAS channel 616 may be used by the transmitter to transmit a reference signal for measurement by the receiver. For example, in the DL subframe 610, the nUE may transmit the reference signal and the tUE may measure the reference signal.
  • the TAS channel 616 may have a 6 bit payload in which the new data indicator (NDI) is a single bit with a 2 bit repetition and 3 bit CRC.
  • NDI new data indicator
  • a Receiver resource Acknowledgement and Sounding (RAS) channel 618 may be provided subsequent to the TAS channel 616.
  • the receiver e.g., the tUE in the RAS channel 618 in the DL subframe 610, may transmit the measurement to the transmitter (nUE in the DL subframe 610).
  • the RAS channel 618 may provide a CSI and power head room (PHR) report.
  • the RAS channel 618 may have a 10 bit payload in which the modulation and coding scheme (MCS) is 4 bits with a 2 bit PHR and 4 bit CRC.
  • MCS modulation and coding scheme
  • the TAS and RAS channels 616, 618 may be followed by a DL data channel 622 in a DL subframe 610, or UL data channel in an UL subframe 630.
  • the data channel 622 may contain data provided from the transmitter to the receiver. This data may include ID and security information or user data.
  • the data channel 622 may be followed by an ACK/NACK channel 624.
  • the ACK/NACK channel 624 may contain a response to transmission of the data in the data channel 622 and be used by the transmitter to determine whether retransmission of the data in the data channel 622 is to occur.
  • the ACK/NACK channel 624 may have a 10 bit payload in which the
  • ACK/NACK is 2 bits with a 4 bit buffer status report (BSR) in a DL subframe 610 indicating whether data is present for transmission and 4 bit CRC.
  • BSR buffer status report
  • guard periods 614 may be used to reduce inter-symbol interference or permit the tUE to switch between the transmitter and receiver chains. At least some of the guard periods 614 may have different lengths. For example, the guard periods between the DL common control channel 612 and the TAS channel 616, between the TAS channel 616 and the RAS channel 618 and after the ACK/NACK channel 624 may occupy 1 symbol (17.7Ps total), the guard period 614 between the RAS channel 618 and the data channel 622 may occupy 1 symbol + 8.33Ps (26.03Ps total) and the guard period 614 between the data channel 622 and the ACK/NACK channel 624 may occupy 2 symbols.
  • a majority of the subchannels in the system may be used to provide data between UEs. However, one or more of the subchannels may be reserved for control signaling.
  • 1-2 resource elements (REs) of one of the central 6 PRBs in the first DL subframe of each frame may provide broadcast channel information, as well as paging and discovery information.
  • 1 RE may be defined as 1 subcarrier over 1 symbol
  • 1 resource unit (RU) may be defined as 3 subcarriers over 4 consecutive symbols (in total 12 REs).
  • the DL common control channel, the TAS channel, the RAS channel and the ACK channel may each occupy one RU, while the data channel may occupy the 3 subcarriers over 34 symbols.
  • the total subframe in this embodiment may thus extend over 56 symbols (including the above guard periods).
  • the nUE may transmit scheduling decisions in the common control channel of an UL subframe and in the TAS channel in a DL subframe. It is desirable for the number of PRAs for UL transmission for a tUE to be based on the buffer size of the tUE, that is, the amount of data that the tUE has to transmit to the nUE.
  • the amount of data to be carried on each PRA in the data channel may be unknown in the scheduling phase
  • the amount of data on each PRA (and thus number of PRAs to transmit the data) may instead be determined by the nUE after the RAS channel as the MCS is contained in the RAS channel. This leads to the nUE using an estimate of the MCS efficiency when determining the scheduling for the tUE.
  • FIG.7 illustrates a flowchart of a method of transferring data in accordance with some embodiments.
  • the method may be performed by any tUE shown in FIGS.1-4.
  • the order of the operations may be different from that shown in FIG.7.
  • one or more of the operations shown may not be present or may be combined with other operations, and other, unshown operations may be used in addition to those illustrated.
  • the tSL-HL 504 may receive user plane data (such as IP data or application data) from an upper layer IP/Application 502 for uplink (UL) data transmission.
  • the tSL-HL 504 may receive CP data from the tSL-RRC 508 for UL data transmission.
  • the data packets received from the IP/Application 502 may be transformed into a tSL-HL SDU for the tSL-HL 504.
  • the tSL-HL SDU may be stored in a buffer (e.g., a memory as shown in FIGS.2- 4) until a transmission opportunity over the Xu-s becomes available, after which the tSL-HL 504 may perform various operations for the transfer of the tSL-HL SDU.
  • the transmission opportunity may become available, for example, when an UL grant reception is indicated by a lower layer such as the tSL-PHY 506.
  • the data packet prepared by the tSL-HL 504 to pass to the tSL-PHY 506 is referred to herein as the tSL-HL PDU.
  • the user plane data transfer procedure may be initiated at reception of a user plane tSL-HL SDU from an upper layer such as an IP or application layer 502.
  • the user plane data may be uplink data for transmission over the Xu-S.
  • the tUE may start a user plane timer
  • the user plane timer may be configured by the tSL-RRC 508.
  • the tSL-HL 504 may then associate the user plane tSL-HL SN corresponding to a user plane register (Next_tSL- HL_TX_SN_UP) to the tSL-HL SDU.
  • the tUE may subsequently perform header compression of the user plane tSL-HL SDU.
  • the manner in which header compression is performed may also be configured by the tSL-RRC 508.
  • the tUE may then perform ciphering on the compressed user plane tSL-HL SDU. In some embodiments, the tUE may also perform integrity protection on the compressed control plane tSL-HL SDU.
  • a user plane register Next_tSL-HL_TX_SN_UP may then be adjusted at operation 710.
  • the user plane register may be incremented by 1.
  • the user plane register may be decremented.
  • the user plane register may be adjusted by a value other than 1.
  • the tUE may determine whether the user plane register has exceeded a predetermined boundary at operation 710. For example, the tUE may determine whether the Next_tSL-HL_TX_SN_UP >
  • the register may be reset to a predetermined state at operation 712.
  • the Next_tSL-HL_TX_SN_UP may be set to 0, although in other embodiments a different value may be used.
  • the resulting user plane tSL-HL data SDU may be buffered to a user plane transmission buffer at operation 714.
  • the buffer may be part of the memory shown in any of FIGS.2-4.
  • the tUE may receive a grant from the nUE for a transmission of a particular size at operation 716.
  • the grant may be part of a larger grant that originates from the eNB and, for the tUE, may be indicated by the nUE for transmission to the nUE.
  • the grant may be for one or more physical resource blocks (PRBs) or other data blocks (such as narrowband PRBs of 1.4MHz, for example) as scheduled by the eNB.
  • PRBs physical resource blocks
  • other data blocks such as narrowband PRBs of 1.4MHz, for example
  • the transmission opportunity for the user plane tSL-HL data SDU indicated by the grant may be provided on a non-control (e.g., user plane) PRB.
  • the grant size may be the same as the size of the user plane tSL-HL Data SDU or may be different from the SDU size.
  • the tUE may, in response to the grant, generate a user plane tSL- HL PDU at operation 718.
  • the user plane tSL-HL SDU may be of a size equal to the grant size.
  • the user plane tSL-HL SDU may be of a size different than the grant size– for example, the grant may be larger than the user plane tSL-HL SDU (the user plane tSL-HL SDU may be smaller than the minimum PRB) or the grant may be smaller than the user plane tSL-HL SDU (the user plane tSL-HL SDU may be sufficiently large as to use multiple grants).
  • the tSL-HL PDU may be generated after getting grant and may always be made equal to the grant size.
  • the tSL-HL PDU may be generated to be equal to the grant size in a number of ways when the tSL-HL SDU is not equal to the grant size: using a SDU/SDU segment, through addition of a previous PDU/PDU segment or through the use of padding.
  • new PDUs may be created from previous/original PDUs in a retransmission buffer.
  • a PDU may have more than one complete SDU; a PDU, for example, may have 0 or more SDUs and 0 to 2 SDU segments.
  • a PDU may have two SDU segments (the last segment of a last SDU in the beginning of the current PDU and a first segment of a current SDU in the end of the current PDU) or may have 0 or more complete SDUs in between.
  • the UL grant for HARQ retransmission may be larger than the data contained within the HARQ buffer.
  • the HARQ process may ask for new UL data and the transmission may no longer be a HARQ retransmission.
  • the HARQ buffer may be flushed, which means that the HARQ for that specific PHY TB/PDU is terminated.
  • the new UL data may be a new transmission, which can be from new SDUs or a previous PDU for ARQ retransmission.
  • the resulting user plane tSL-HL PDU may be submitted to the tSL-PHY through a HARQ entity.
  • the tSL-HL PDU may then be transmitted at operation 720.
  • the control plane data transfer procedure may similarly be initiated at reception of a control plane tSL-HL SDU from an upper layer.
  • the tUE may start a control plane timer (discardTimer-CP) associated with the control plane tSL-HL SDU.
  • the control plane timer may be configured by the tSL-RRC 508.
  • the tUE/nUE may then associate the control plane tSL-HL SN corresponding to a control plane register (Next_tSL-HL_TX_SN_CP) to the control plane tSL-HL SDU. If applicable the tUE may then perform either or both integrity protection and ciphering on the compressed.
  • the control plane register Next_tSL-HL_TX_SN_CP may then be incremented similar to the user plane register. After adjustment, the tUE may determine whether the register has exceeded a predetermined boundary. For example, the tUE may determine whether the Next_tSL-HL_TX_SN_CP > Maximum_tSL-HL_SN_CP. If the register has exceeded the boundary, the register may be reset to a predetermined state. For example, the Next_tSL- HL_TX_SN_CP may be set to 0. The resulting control plane tSL-HL Data SDU may be buffered to a control plane transmission buffer.
  • the tUE may receive a grant for a transmission of a particular size.
  • the transmission opportunity of the grant may be provided on a control PRB.
  • the grant size may be the same as the size of the control plane tSL-HL data SDU or may be different from the SDU size.
  • the device may in response to the grant generate a control plane tSL-HL PDU of size equal to the grant size.
  • the resulting control plane tSL-HL PDU may then be submitted to the tSL-PHY through a HARQ entity.
  • a valid grant may be used for an uplink transmission from the tUE to the nUE.
  • a valid grant may include the assignment of one or more PRBs from the nUE for a given transmission time interval (TTI).
  • TTI transmission time interval
  • a HARQ retransmission may be non-adaptive process in which HARQ retransmission is performed on pre-deterministic resources and in a predetermined TTI. The resources and TTI can be determined from the original transmission’s resources and TTI value.
  • the nUE may send a UL grant addressed to the tUE Temporary (or short) ID.
  • a new data indicator (NDI) may be set (or toggled) for a new transmission.
  • the UL grant may be computed by the tSL-HL 504 from the resources of the original transmission and TTI value based on pre-specified rules for HARQ retransmission.
  • a new data indicator may not be used for the HARQ retransmission.
  • an adaptive HARQ retransmission process may be performed.
  • the nUE may explicitly indicate an uplink grant on a PRB or a group of PRBs where a HARQ retransmission by an associated HARQ process is expected. As above, a new data indicator may not be used for the HARQ retransmission.
  • the tSL-HL 504 may determine the HARQ Process ID based on the PRB(s) received in the grant.
  • the PRB number can be used to define the HARQ Process ID.
  • the PRB number of the first PRB of the group can be used to define the HARQ Process ID.
  • the tSL-HL 504 may determine, upon UL grant reception, whether UL grant is on a control PRB(s) or on a non-control PRB(s).
  • the tSL-RRC 508 may preconfigure the tUE with the control and non-control PRBs configuration.
  • the tUE may store the uplink grant and the associated HARQ information as a configured uplink grant.
  • the configured uplink grant may be initialized to start in the appropriate TTI and to potentially recur according to retransmission rules in case of NACK HARQ feedback.
  • the HARQ ACK/NACK may be received within the transmission TTI/Subframe. This means that the predefined HARQ retransmission may be configured in the next uplink TTI/subframe.
  • the configured uplink grant and the associated HARQ information may be delivered to the HARQ entity for the TTI for each PRB (or for each HARQ PRB groups).
  • the HARQ process itself may include a HARQ entity that follows the HARQ process.
  • a HARQ entity may be present at the tSL-HL transmitting side entity.
  • the HARQ entity may maintain a number of parallel HARQ processes allowing transmissions to take place continuously while waiting for the HARQ feedback on the successful or unsuccessful reception of previous transmissions.
  • the number of parallel HARQ processes per HARQ entity may be configured by the tSL-RRC 508.
  • One HARQ process may be associated with a given PRB (or a given PRBs group).
  • the HARQ process associated with a control PRB may be a control plane HARQ process, while the HARQ process associated with a non-control PRB may be a user plane HARQ process.
  • the HARQ entity may identify the HARQ process(es) for which a transmission should take place.
  • the HARQ entity may also route the received HARQ feedback (ACK/NACK information), modulation and coding scheme (MCS) and resource, relayed by the physical layer, to the appropriate HARQ process(es).
  • MCS modulation and coding scheme
  • the HARQ entity may perform a number of procedures.
  • the HARQ entity may, for example, identify the HARQ process(es) associated with this PRB (or a given PRBs group), and undertake functions for each identified HARQ process.
  • a first function occurs if a New Data Indicator (NDI) provided in the associated HARQ information has been toggled compared to the value in the previous transmission of the HARQ process or if the HARQ buffer of the HARQ process is empty, the HARQ entity may generate a new tSL-HL data PDU.
  • the new PDU may be a control plane PDU if the PRB is a control PRB, and otherwise a user plane data PDU.
  • the HARQ entity may also deliver the tSL- HL PDU, the uplink grant and the HARQ information to the identified HARQ process.
  • the HARQ entity may also instruct the identified HARQ process to trigger a new transmission.
  • the HARQ entity may perform different functions depending on whether the grant size is equal to the PDU in the HARQ buffer. If so, the HARQ entity may instruct the identified HARQ process to generate a non-adaptive retransmission.
  • the HARQ entity may flush the HARQ buffer of the HARQ process, and then follow the same functions as above; that is generate a new tSL- HL data PDU (control plane PDU if the PRB is a control PRB, otherwise user plane data PDU), deliver the tSL-HL PDU, the uplink grant and the HARQ information to the identified HARQ process, and instruct the identified HARQ process to trigger a new transmission.
  • tSL- HL data PDU control plane PDU if the PRB is a control PRB, otherwise user plane data PDU
  • Each HARQ process may maintain multiple state variables.
  • a first state variable CURRENT_TX_NB may indicate the number of
  • a second state variable HARQ_FEEDBACK may indicate the HARQ feedback for the tSL-HL PDU currently in the buffer.
  • the first state variable CURRENT_TX_NB may be initialized to a predetermined value, such as 0.
  • New transmissions may then be performed on the resource and with the MCS indicated in a Receiver resource Acknowledgement and Sounding (RAS) message.
  • RAS Receiver resource Acknowledgement and Sounding
  • Non-adaptive retransmission may be performed on the same resource, or on a resource determined based on an earlier transmission resource, and with the same MCS as was used for the last transmission attempt made.
  • the tSL-HL entity 504 may be configured with a maximum number of HARQ transmissions configured by the tSL-RRC 508: maxHARQ-Tx. For transmissions on all HARQ processes, the maximum number of
  • transmissions may be set to maxHARQ-Tx.
  • the tSL-RRC 508 may configure different maximum number of HARQ transmissions limits for user plane HARQ processes (maxHARQ-Tx-UP) and control plane HARQ processes (maxHARQ-Tx-CP).
  • the HARQ process may set the second state variable HARQ_FEEDBACK to the received value. If the received
  • the HARQ buffer may be flushed. If the HARQ entity requests a new transmission, the HARQ process may set the first state variable CURRENT_TX_NB to a predetermined value such as 0, store the tSL-HL PDU in the associated HARQ buffer, store the uplink grant received from the HARQ entity, set the second state variable HARQ_FEEDBACK to NACK, and generate a HARQ transmission.
  • the HARQ process may increment/decrement the first state variable CURRENT_TX_NB by 1 (or some other value), set the second state variable HARQ_FEEDBACK to NACK and generate a HARQ transmission.
  • the HARQ transmission may be generated in situations in which the HARQ entity requests a new transmission or the HARQ entity requests a retransmission. In either case, to generate a transmission, the HARQ process may instruct the tSL-PHY 506 to generate a transmission according to the stored uplink grant with the stored HARQ Information.
  • the HARQ process may then determine whether or not to flush the HARQ buffer and take the appropriate action. This determination may be dependent on the value of the first state variable CURRENT_TX_NB. In particular, if the first state variable
  • CURRENT_TX_NB maximum number of transmissions– 1 (the value of one increment or decrement), then the HARQ buffer may be flushed.
  • a first retransmission may occur at the PHY/Lower MAC/Lower tSL-HL layer and handled by the HARQ process.
  • the first retransmission may be performed for each PHY transport block (PDU bit string).
  • the PHY TB/PDU may be stored in the HARQ buffer for the first retransmission and thus may have a reduced latency.
  • An ACK/NACK may be sent by the receiving side PHY/Lower MAC layer immediately after checking the CRC.
  • the PHY/Lower MAC layer may not decode the PDU, and thus the PDU_ID or other parameters may remain unknown.
  • the PHY/Lower MAC layer may instead merely know the HARQ process ID and ACK or NACK for that PHY transport block/PDU bit string.
  • the second retransmission may be at the tSL-HL level for each tSL-HL PDU (ARQ) which is performed later if multiple tries by the HARQ process fail.
  • the second retransmission thus has higher latency than the first retransmission.
  • the tSL-HL receive side may decode the tSL-PDUs, keep track of missing PDUs and after a predetermined amount of time transmit an ARQ ACK/NACK Status PDU/report for several PDUs requesting ARQ retransmission for missing PDUs.
  • the tSL-HL transmit side after receiving the Status Report, may in response retransmit the missing PDU.
  • the data reception procedures for user plane and control plane data may follow similar processes.
  • a separate set of all parameters (variables, constants and timers) may be defined by the tSL-RRC 508 for the user plane and the control plane - although a data reception procedure is discussed herein using a common set of parameters as an example.
  • the VR (R) parameter should be understood to be VR-UP(R) for user plane data reception procedure and VR- CP(R) for the control plane data reception procedure.
  • VR(ACK_PDU_ID), VR(H), VR(Reorder) and t-Reordering should be understood to be VR-UP(ACK_PDU_ID), VR-UP(H), VR- UP(Reorder) and t-Reordering-UP for the user plane data reception procedure and VR-CP(ACK_PDU_ID), VR-CP(H), VR-CP(Reorder) and t-Reordering-CP for the control plane data reception procedure.
  • the PDU_ID may be defined in some circumstances to be the SDU SN of the first SDU in the PDU, if first data field element of the tSL-HL PDU is an SDU. If first data field element of the tSL-HL PDU is an SDU Segment, that is, the SDU is larger than the length of the transmission opportunity and is thus split into multiple PDUs, the PDU_ID may be the SDU SN of first SDU segment in the PDU. If the retransmission PDU is a segment of an original PDU during retransmission, the PDU_ID may be the re-segmentation SN, Start byte offset (SO) and End byte offset (EO). Once all segments of an original PDU (for a given Re-segmentation SN) are received and assembled to obtain the original PDU, the PDU_ID of the original packet is given as above.
  • the receiving side of the tSL-HL entity may keep track of the PDU_ID of the PDU following the last in-sequence completely received tSL-HL PDU as a state variable VR(R).
  • V(R) may serve as the lower end of the receiving window. There may be no explicit upper end of the receiving window. However, since the maximum number of PDUs (which are yet to be
  • TX_Window_Size an indirect limit may instead exist on the receiving window size in terms of number of PDUs.
  • the limit on the receiving window size may be TX_Window_Size multiplied by the maximum number of segments per PDU. Using this, a PDU_ID falls within the receiving window if PDU_ID ⁇ VR(R) and otherwise falls outside of the receiving window.
  • the receiving side of a tSL-HL entity may either discard the received tSL-HL data PDU or place the received tSL-HL data PDU in the reception buffer. If the received tSL-HL data PDU is placed in the reception buffer, the state variables may be updated, the tSL-HL SDUs reassembled and delivered to the upper layer and t-Reordering started/stopped as desired. When t-Reordering expires, the receiving side of a tSL-HL entity may update state variables and start t- Reordering as desired.
  • All the segments belonging to the same PDU may carry the same Re-segmentation SN.
  • the Re-segmentation SN, Start Byte Offset and End Byte Offset may serve as the PDU segment ID during retransmission.
  • the actions taken by the receiving side of a tSL-HL entity may depend on whether the byte segment numbers have been previously received.
  • the received tSL-HL data PDU may be discarded; otherwise, the received tSL-HL data PDU may be placed the reception buffer and further actions performed in response to a tSL-HL data PDU being placed in the buffer. If some byte segments of the tSL-HL PDU contained in the tSL-HL data PDU have been received before, the duplicate byte segments may be discarded.
  • the actions taken by the receiving side of a tSL-HL entity may depend on whether or not the PDU_ID falls within the receiving window. In other words, the actions may depend on whether x ⁇ VR(R). If so, the tSL-HL data PDU may be placed in the reception buffer and further actions performed in response to a tSL-HL data PDU being placed in the buffer. If not (the PDU_ID falls outside of the receiving window), the received tSL-HL data PDU may be discarded.
  • the actions performed in response to a tSL-HL data PDU being placed in the buffer may depend on whether the PDU is a PDU segment or a PDU.
  • VR(ACK_PDU_ID) have been received, VR(ACK_PDU_ID) may be updated to the PDU_ID of the first tSL-HL PDU with PDU_ID > current
  • the receiving side of a tSL-HL entity may update VR(ACK_PDU_ID) to the PDU_ID of the first tSL-HL PDU with PDU_ID ⁇ VR(Reorder) for which not all byte segments have been received. If VR (H) > VR(ACK_PDU_ID), the receiving side of a tSL-HL entity may start t- Reordering and set VR(Reorder) to VR(H).
  • the state variables described herein may be used in tSL-HL entities in order to specify the tSL-HL protocol.
  • the state variables may be normative.
  • all state variables and all counters may be non-negative integers.
  • a tSL-HL PDU may be identified by a PDU_ID that includes an SDU PDU_ID of a first SDU in the PDU, if the first data field (SDU/SDU segment field) of the tSL-HL PDU is an SDU.
  • the PDU_ID may include the (SDU SN, Segment Number) of first SDU segment in the PDU if the first data field (SDU/SDU segment field) of the tSL-HL PDU is an SDU Segment.
  • PDU_ID (SDU_SN, Seg_N).
  • a PDU may have multiple data fields.
  • the next PDU_ID will be next SDU SN and/or SDU Seg_N (as applied above) with respect to SDU SN and SDU Seg_N of the last data field of the current PDU.
  • All state variables related to PDU_ID may perform one or more arithmetic operations on the SDU_SN and Seg_N of the PDU_ID.
  • a modulus base may be used.
  • VR(R)(SDU_SN) ⁇ SDU_SN ⁇ VR(ACK_PDU_ID) (SDU_SN) may be evaluated as [VR(R) (SDU_SN)– BASE_RECEIVE] modulo MaxSN ⁇ [SDU_SN–
  • Each of the state variables may be maintained for user plane as well as control plane if not otherwise specified. That is, two instances of each state variable per tSL-HL entity (one for user plane and one for control plane) may be maintained, unless otherwise specified.
  • VR(R) parameter should be maintained as VR-UP(R) for the user plane data reception process and VR-CP(R) for the control plane data reception process.
  • the transmitting side of each tSL-HL entity may maintain the state variables VT(ACK)–
  • This state variable may hold the value of the PDU_ID of the next tSL-HL PDU for which a positive acknowledgment is to be received in-sequence and the state variable may serve as the lower edge of the transmitting window.
  • the transmitting side of tSL-HL entity may maintain multiple different counters.
  • the RETX_COUNT counter counts the number of retransmissions of a tSL-HL PDU. There may be one RETX_COUNT counter per PDU to be retransmitted.
  • the TX_PDU_COUNT counter may count the number of tSL-HL PDUs that have been transmitted and have not been acknowledged so far from the receiving tSL-HL entity.
  • the TX_PDU_COUNT counter may enable the receiving tSL-HL entity to maintain a transmission window in terms of number of PDUs.
  • each tSL-HL entity may also maintain multiple different state variables.
  • the VR(R)– Receive state variable may hold the value of the PDU_ID following the last in-sequence completely received tSL-HL PDU and serve as the reference to discard duplicate PDU. Any tSL-HL PDU with a PDU_ID less than VR(R) may be determined to be a duplicate reception and subsequently discard the duplicate PDU.
  • Another variable that may be maintained by the receiving side of each tSL-HL entity is VR(Reorder)– t-Reordering state variable.
  • VR(Reorder)– t-Reordering state variable may hold the value of the PDU_ID following the PDU_ID of the tSL-HL data PDU that triggered t-Reordering.
  • each tSL-HL entity may also maintain the VR(ACK_PDU_ID)– Acknowledge PDU_ID for status transmission - state variable.
  • the VR(ACK_PDU_ID)– Acknowledge PDU_ID for status transmission state variable may hold the highest possible value of the PDU_ID that can be indicated by“ACK_PDU_ID” when a STATUS PDU is to be constructed.
  • the VR(ACK_PDU_ID)– Acknowledge PDU_ID for status transmission state variable may be initially set to a predetermined value such as 0.
  • each tSL-HL entity may also maintain the VR(H)– Highest received state variable.
  • the VR(H)– Highest received state variable may hold the value of the PDU_ID following the PDU_ID of the tSL- HL data PDU with the highest PDU_ID among received tSL-HL data PDUs.
  • the VR(H)– Highest received state variable may be initially set to a predetermined value such as 0.
  • the Tx_Window_Size constant may be used mainly by the transmitting side of the tSL-HL entity.
  • the Tx_Window_Size constant may provide value for a maximum number of PDUs that can be transmitted without getting ACK from the receiving tSL-HL entity. The same constant may be used by the receiving side to estimate the reception buffer requirement.
  • the TX_Window_Size 512 for user plane data transfer and 64 for control plane data transfer.
  • a number of timers may be configured by the tSL-RRC to control various operations of the tSL-HL protocol layer.
  • One such timer is the t- Reordering timer.
  • the t-Reordering timer may be used by the receiving side of an tSL-HL entity in order to detect loss of tSL-HL PDUs at lower layer. If t- Reordering for the user (control) plane is running, t-Reordering may not be started additionally for the user (control) plane. Thus, only two t-Reordering per tSL-HL entity (one for user plane and one for control plane) may be running at a given time.
  • Another such timer is the maxWaitForStatusPDUTimer. The maxWaitForStatusPDUTimer may be used to resolve deadlock cases of infinitely waiting for an ARQ ACK/NACK STATUS PDU. If the
  • maxWaitForStatusPDUTimer is not running, it may be started upon
  • the maxWaitForStatusPDUTimer may be restarted upon reception of an ARQ ACK/NACK STATUS PDU if any data (including PDUs NACKed in the current STATUS PDU) is still available for transmission or retransmission.
  • the maxWaitForStatusPDUTimer may be stopped upon reception of an ARQ ACK/NACK STATUS PDU if no more data is available for transmission or retransmission. If the
  • maxWaitForStatusPDUTimer for user (control) plane is running, the maxWaitForStatusPDUTimer may not be started additionally for user (control) plane. Thus, only two maxWaitForStatusPDUTimer per tSL-HL entity (one for user plane and one for control plane) may be running at a given time.
  • Configurable parameters provided by tSL-RRC may be maintained for the user plane as well as the control plane if not otherwise specified. That is, two instances of each parameter per tSL-HL entity (one for user plane and one for control plane) may be maintained, unless otherwise specified.
  • Various parameters that may be configured by tSL-RRC include the maxRetxThreshold and maxHARQ-Tx.
  • the maxRetxThreshold parameter may be used by the transmitting side of the tSL-HL entity to limit the number of ARQ retransmissions of a tSL-HL PDU.
  • the maxHARQ-Tx parameter may be used by the HARQ process at the transmitting side of the tSL-HL entity to limit the number of HARQ retransmissions of a tSL-HL PDU.
  • Example 1 is an apparatus of user equipment (UE), the apparatus comprising: a memory; and processing circuitry in communication with the memory and arranged to: encode a service data unit (SDU) for transmission to a scheduler UE (nUE) through a sidelink (tSL) interface, the SDU comprising at least one of user plane (UP) SDU or control plane (CP) SDU, the UP SDU generated at one of an internet protocol (IP) or application layer, the CP SDU generated at a sidelink radio resource control (tSL-RRC) layer; transfer the SDU to a sidelink higher layer protocol stack (tSL-HL); generate a packet data unit (PDU) from the SDU in response to reception of an uplink (UL) grant from the nUE through the tSL interface; and transfer the PDU from the tSL-HL to a physical layer (tSL-PHY) for transmission to the nUE through the tSL interface during a transmission time interval (TTI) indicated in the UL grant.
  • SDU service data unit
  • Example 2 the subject matter of Example 1 optionally includes, wherein the PDU is encoded to include a PDU identity (ID), and the PDU ID comprises: a SDU sequence number (SN) of a first SDU in the PDU when the first data field in the PDU is a complete SDU, the SDU SN and segment number (Seg_N) of the first SDU segment in the PDU when the first data field in the PDU is a SDU segment, or a resegmentation SDU SN, start offset and end offset, if a retransmission PDU is a segment of a larger PDU during retransmission.
  • ID PDU identity
  • the PDU ID comprises: a SDU sequence number (SN) of a first SDU in the PDU when the first data field in the PDU is a complete SDU, the SDU SN and segment number (Seg_N) of the first SDU segment in the PDU when the first data field in the PDU is a SDU segment, or a
  • Example 3 the subject matter of Example 2 optionally includes, wherein: the PDU ID is a duple, independent of a type of the PDU, the duple comprising the SDU SN and Seg_N, the SDU Seg_N equal to 0 when the first data field in PDU is the complete SDU, a next PDU ID after a current PDU ID, when each PDU comprises n data fields, where n is an integer of at least 1, is a duple of one of: a next SDU SN and SDU Seg_N equal to 0 when a first data field of the next PDU is a next complete SDU and a nth data field of the current PDU is one of: a current complete SDU or a last segment of a current SDU segment, the next SDU SN and SDU Seg_N equal to 1 when the first data field of the next PDU is a next SDU segment and the nth data field of the current PDU is one of: the current SDU or the last segment of the current SDU segment
  • Example 4 the subject matter of any one or more of Examples 1–3 optionally include, wherein: the tSL-HL comprises an automatic repeat request (ARQ) entity configured to maintain a plurality of state variables and counters, the plurality of state variables and counters comprising at least one of: an acknowledgement (ACK) state variable configured to retain a value of the PDU ID of a next PDU for which a positive acknowledgment is to be received in-sequence and serve as a lower edge of a transmitting window, the ACK state variable is initially set to 0 and is updated when the tSL-HL entity receives a positive acknowledgment for a PDU associated with the ACK state variable, the transmitting window configured to indicate a maximum number of PDUs that can be transmitted without reception of an ACK, the transmitting window for UP PDUs larger than the transmitting window for CP PDUs, and a retransmission counter configured to count a number of retransmissions of a particular PDU, the retransmission counter is initially
  • Example 5 the subject matter of any one or more of Examples 1–4 optionally include, wherein: the tSL-HL comprises an automatic repeat request (ARQ) entity configured to maintain a plurality of state variables, the plurality of state variables comprising at least one of: a receive state variable configured to retain a value of a PDU ID following a last in-sequence completely received PDU and serve as a reference to discard duplicate PDUs, the tSL-HL entity configured to discard PDUs with PDU IDs less than the receive state variable as being a duplicate reception, the receive state variable is initially set to 0 and is updated when the tSL-HL entity receives a particular PDU that has a PDU ID equal to the receive state variable, a reorder state variable configured to retain a value of a next PDU ID following a PDU ID that triggered reordering stored in the memory, a transmission acknowledge state variable configured to retain a highest possible value of an indicatable PDU ID in response to a request for an acknowledgment/negative
  • ARQ
  • Example 6 the subject matter of any one or more of Examples 1–5 optionally include, wherein: the tSL-HL comprises an automatic repeat request (ARQ) entity configured to maintain a plurality of timers, the plurality of timers comprising at least one of: a reorder timer configured to detect loss of PDUs at the tSL-PHY, and a deadlock timer configured to limit wait time for an acknowledgement/negative acknowledgment (ACK/NACK) in response to a particular PDU, the deadlock timer started in response to PDU transmission and restarted in response to ACK/NACK reception when at least one other PDU remains for transmission or stopped in response to ACK/NACK reception after transmission of a final PDU.
  • ARQ automatic repeat request
  • Example 7 the subject matter of any one or more of Examples 1–6 optionally include, wherein: the processing circuitry is further configured to, at reception of the SDU at the tSL-HL: when configured by the tSL-RRC layer, start a discard timer associated with the SDU, associate an SDU sequence number (SN) with the SDU, the SDU SN being a next available SDU SN, and increment the next available SDU SN, when configured by the tSL-RRC layer, perform at least one of header compression, integrity protection or ciphering of the SDU, and when the next available SN is the maximum SDU SN, reset the SDU SN, and store the SDU in a transmission buffer to form a buffered SDU, generation of the PDU comprises generation of the PDU from the buffered SDU in response to reception of the UL grant, the PDU having a size of the UL grant, the processing circuitry further comprises a hybrid automatic repeat request (HARQ) entity is configured to receive the PDU from the HARQ) entity
  • Example 8 the subject matter of any one or more of Examples 1–7 optionally include, wherein: the UL grant comprises at least one of a new grant for transmission of new UL data or a retransmission grant for a hybrid automatic repeat request (HARQ) retransmission of UL data in a HARQ buffer, the retransmission grant being one of an adaptive or non-adaptive retransmission grant, the UL grant associated with a physical resource block (PRB) for the UE to transmit the PDU to the nUE, in response to reception of the UL grant, the processing circuitry is further configured to: in response to reception of the new grant, set a new data indicator (NDI), the new grant addressed to a short identification (ID) of the UE, and in response to reception of the adaptive retransmission grant, determine the PRB, the PRB indicated by the adaptive retransmission grant, and for the non-adaptive retransmission grant, the processing circuitry is further configured to determine the PRB based on HARQ rules and resources
  • Example 9 the subject matter of Example 8 optionally includes, wherein the processing circuitry is further configured to: determine a HARQ process identification (ID) based on the PRB, store the UL grant and associated HARQ information in the memory as a configured grant, initialize the configured uplink grant to start in a current TTI and to recur in a next TTI in response to reception of a HARQ negative acknowledgment (NACK) in response to a transmission on the UL grant, and deliver the configured grant to a HARQ entity for the current TTI for the PRB.
  • ID HARQ process identification
  • NACK HARQ negative acknowledgment
  • Example 10 the subject matter of any one or more of Examples 1–9 optionally include, wherein: the PDU comprises one of new data and retransmission of the new data, the tSL-HL comprises a hybrid automatic repeat request (HARQ) entity configured to determine whether to retransmit the new data, maintain parallel HARQ processes and permit transmissions of other data to occur while HARQ feedback on reception of previous transmissions is pending, a number of parallel HARQ processes is configured by the tSL-RRC layer, each HARQ process is associated with a different physical resource block (PRB), a HARQ process associated with a control PRB is CP HARQ process and a HARQ process associated with a non-control PRB is UP HARQ process, and at the TTI, when a particular UL grant is indicated for a particular PRB, the HARQ entity is configured to identify an associated HARQ process associated with the particular PRB and route HARQ feedback, a modulation and coding scheme (MCS) and a resource
  • MCS
  • Example 11 the subject matter of Example 10 optionally includes, wherein the HARQ entity is configured to: in response to a new data indicator (NDI) in the associated HARQ process being changed compared to a value in a previous transmission of the associated HARQ process or a HARQ buffer of the associated HARQ process being empty: generate a new data PDU from the new data, deliver the new data PDU, UL grant and HARQ information to the associated HARQ process, and instruct the associated HARQ process to trigger a new transmission of the new data PDU to the nUE, in response to the HARQ buffer of the associated HARQ process being occupied and a grant size of the UL grant being equal to a size of a PDU of the associated HARQ process in the HARQ buffer, instruct the associated HARQ process to generate a non- adaptive retransmission of the PDU of the associated HARQ process in the HARQ buffer, and in response to the HARQ buffer of the associated HARQ process being occupied and the
  • Example 12 the subject matter of any one or more of Examples 10–11 optionally include, wherein the HARQ entity is configured to: maintain a first state variable that indicates a number of HARQ transmissions of a HARQ PDU in a HARQ buffer, and a second state variable that indicates the HARQ feedback for the HARQ PDU, the first state variable initialized when the associated HARQ process is established, the HARQ transmission being a HARQ UP transmission or a HARQ CP transmission, a maximum number of HARQ transmissions configured by the tSL-RRC layer, a maximum number of HARQ UP transmissions independent of a maximum number of HARQ CP transmissions, and perform a new HARQ transmission to the nUE on the resource with the MCS, the MCS indicated in a Receiver resource Acknowledgement and Sounding (RAS), and perform a non-adaptive HARQ retransmission on the resource and with the MCS.
  • the HARQ entity is configured to: maintain a first
  • Example 13 the subject matter of Example 12 optionally includes, wherein the associated HARQ process is configured to: in response to reception of the HARQ feedback, set the second state variable to the HARQ feedback received, and flush the HARQ buffer when the HARQ feedback is an acknowledgment (ACK), in response to a request from the HARQ entity for a new transmission of the HARQ PDU: initialize the first state variable, store the HARQ PDU in the HARQ buffer, store the UL grant received from the HARQ entity in the HARQ buffer, set the second state variable to negative
  • ACK acknowledgment
  • NACK acknowledgment
  • NACK acknowledgment
  • NACK HARQ transmission
  • increment the first state variable set the second state variable to NACK
  • generate the HARQ transmission instruct the tSL-PHY to generate a transmission to the nUE according to the UL grant and HARQ information stored in the HARQ buffer to generate the HARQ transmission
  • flush the HARQ buffer when the first state variable is equal to one fewer than the maximum number of HARQ transmissions.
  • Example 14 the subject matter of any one or more of Examples 10–13 optionally include, wherein a tSL-HL entity comprising the tSL-HL is configured to: retain, in a reception buffer, a PDU state variable to keep track of a PDU ID of a tSL-HL PDU received from the tSL-PHY following a last in-sequence completely received tSL-HL PDU, the PDU state variable configured to serve as a lower end of a receiving window, a limit on the receiving window size being a maximum number of PDUs multiplied by the maximum number of segments per PDU, a particular PDU ID in the receiving window if the particular PDU ID is at least the PDU state variable, in response to reception of the tSL-HL PDU from the tSL-PHY: one of discard the tSL-HL data PDU or store the tSL-HL data PDU in the reception buffer, when the received tSL-HL data PDU is stored in the reception buffer, update the PDU
  • Example 15 the subject matter of Example 14 optionally includes, wherein: the PDU comprises a plurality of segments, each segment configured to carry a same resegmentation sequence number (SN) and a different start and end offset, a last segment comprising a header with a flag, the flag configured to indicate the last segment, the tSL-HL comprises an automatic repeat request (ARQ) entity configured to at least one of: when a received tSL- HL data PDU is a PDU segment: discard one of a received tSL-HL data PDU when the tSL-HL PDU having the same resegmentation SN and start and end offsets has been previously received before or duplicate byte segments of the tSL-HL PDU, or store the received tSL-HL data PDU in a reception buffer, or when the received tSL-HL data PDU is a complete PDU: store the received tSL- HL data PDU in the reception buffer when the received tSL-HL data PDU falls within a
  • Example 16 the subject matter of Example 15 optionally includes, wherein the ARQ entity is further configured to: when the received tSL-HL data PDU is stored in reception buffer and the received tSL-HL data PDU is the PDU segment: wait for missing PDU segments when all bytes of the PDU with the resegmentation SN have not been received, and in response to a complete set of the bytes of the PDU with the resegmentation SN being received: reassemble the PDU from the PDU segments, decode the PDU and obtain a PDU ID, update a tSL-HL receive side state variable, and reassemble a tSL-HL SDU from byte segments of tSL-HL PDUs with a PDU ID that falls outside of the receiving window and in-sequence byte segments of the tSL-HL PDU with the PDU ID of a PDU with a complete set of the bytes, remove tSL- HL headers during the reassembly and
  • Example 17 the subject matter of any one or more of Examples 15–16 optionally include, wherein the ARQ entity is further configured to: when the received tSL-HL data PDU is stored in reception buffer and the received tSL-HL data PDU is the PDU: decode the PDU, update a tSL- HL receive side state variable, and reassemble a tSL-HL SDU from byte segments of tSL-HL PDUs with a PDU ID that falls outside of the receiving window and in-sequence byte segments of the tSL-HL PDU with the PDU ID of a PDU with a complete set of the bytes, remove tSL-HL headers during the reassembly and deliver the reassembled tSL-HL SDU to the at least one of the IP or application layer.
  • Example 18 the subject matter of any one or more of
  • Examples 1–17 optionally include, wherein: the processing circuitry comprises a baseband processor, and the apparatus further comprises a transceiver configured to communicate with the nUE.
  • Example 19 is an apparatus of user equipment (UE), the apparatus comprising: a memory; and processing circuitry in communication with the memory and arranged to: receive a packet data unit (PDU) from another UE (tUE) through a sidelink (tSL) interface, the PDU received at a sidelink physical layer (tSL-PHY) during a transmission time interval (TTI) allocated for the other UE by the UE; transfer the PDU to a sidelink higher layer protocol stack (tSL-HL) entity, at the tSL-HL entity, determine a PDU type of the PDU from a PDU identity (ID) of the PDU, the PDU type comprising one of a complete service data unit (SDU) or a SDU segment for one of new data or retransmission data, the SDU comprising at least one of user plane (UP) SDU or control plane (CP) SDU; at a hybrid automatic repeat request (HARQ) entity generate, for transmission to the other UE, an acknowledgement (ACK) or negative acknowledgment (N).
  • Example 20 the subject matter of Example 19 optionally includes, wherein: the PDU ID is a duple, independent of a type of the PDU, the duple comprising a SDU sequence number (SN) and a segment number (Seg_N), the SDU Seg_N equal to 0 when the PDU is the complete SDU, a next PDU ID after a current PDU ID, when each PDU comprises n data fields, where n is an integer of at least 1, is a duple of one of: a next SDU SN and SDU Seg_N equal to 0 when a first data field of the next PDU is a next complete SDU and a nth data field of the current PDU is one of: a current complete SDU or a last segment of a current SDU segment, the next SDU SN and SDU Seg_N equal to 1 when the first data field of the next PDU is a next SDU segment and the nth data field of the current PDU is one of: the current SDU or the last
  • Example 21 the subject matter of any one or more of
  • Examples 19–20 optionally include, wherein: the HARQ entity is configured to maintain a plurality of state variables, the plurality of state variables comprising at least one of: a receive state variable configured to retain a value of the PDU ID following a last in-sequence completely received PDU and serve as a reference to discard duplicate PDUs, the tSL-HL entity configured to discard PDUs with PDU IDs less than the receive state variable as being a duplicate reception, the receive state variable updated when the tSL-HL entity receives a particular PDU that has a PDU ID equal to the receive state variable, a reorder state variable configured to retain a value of a next PDU ID following a PDU ID that triggered reordering of PDUs stored in the memory, a transmission acknowledge state variable configured to retain a highest possible value of an indicatable PDU ID in response to a request for a status of a stored PDU, and a highest receive state variable configured to retain a value of a next PDU ID following a highest P
  • Example 22 the subject matter of any one or more of
  • Examples 19–21 optionally include, wherein the processing circuitry is configured to: grant to the tUE a different physical resource block (PRB) associated with each of a plurality of PDUs and associated parallel HARQ processes, a HARQ process associated with a control PRB is CP HARQ process and a HARQ process associated with a non-control PRB is UP HARQ process, and at the TTI, receive from the tUE a modulation and coding scheme (MCS) for each of the plurality of PRBs and route HARQ feedback to the tUE for each of the plurality of PRBs.
  • MCS modulation and coding scheme
  • Example 23 the subject matter of any one or more of
  • Examples 19–22 optionally include, wherein the ARQ entity is configured to: retain, in a reception buffer, a PDU state variable to keep track of the PDU ID of a tSL-HL PDU received, from the tUE through a sidelink physical layer (tSL- PHY) of the UE, following a last in-sequence completely received tSL-HL PDU, the PDU state variable configured to serve as a lower end of a receiving window, a limit on the receiving window size being a maximum number of PDUs multiplied by a maximum number of segments per PDU, a particular PDU ID determined to be in the receiving window when the particular PDU ID is at least the PDU state variable, in response to reception of the tSL-HL PDU from the tSL-PHY: one of discard the tSL-HL data PDU or store the tSL-HL data PDU in the reception buffer, when the received tSL-HL data PDU is stored in the reception buffer, update the PDU state variable, reassemble and deliver
  • Example 24 the subject matter of Example 23 optionally includes, wherein: the PDU comprises a plurality of segments, each segment configured to carry a same resegmentation SN and a different start and end offset, a last segment comprising a header with a flag, the flag configured to indicate the last segment, and the tSL-HL entity is further configured to at least one of: when a received tSL-HL data PDU is the PDU segment: discard one of a received tSL-HL data PDU when the tSL-HL PDU having the same
  • resegmentation SN and start and end offsets has been previously received before or duplicate byte segments of the tSL-HL PDU, or store the received tSL-HL data PDU in a reception buffer, or when the received tSL-HL data PDU is the complete PDU: store the received tSL-HL data PDU in the reception buffer when the received tSL-HL data PDU falls within a receiving window, or discard the received tSL-HL data PDU when the received tSL-HL data PDU falls outside the receiving window.
  • Example 25 the subject matter of Example 24 optionally includes, wherein the ARQ entity is further configured to: when the received tSL-HL data PDU is stored in reception buffer and the received tSL-HL data PDU is the PDU segment: wait for missing PDU segments when all bytes of the PDU with the resegmentation SN have not been received, and in response to a complete set of the bytes of the PDU with the resegmentation SN being received: reassemble the PDU from the PDU segments and decode the PDU, update a tSL-HL receive side state variable, and reassemble a tSL-HL SDU from byte segments of tSL-HL PDUs with a PDU ID that falls outside of the receiving window and in-sequence byte segments of the tSL-HL PDU with the PDU ID of a PDU with a complete set of the bytes, remove tSL-HL headers during the reassembly and deliver the reassembled t
  • Example 26 the subject matter of any one or more of
  • Examples 24–25 optionally include, wherein the ARQ entity is further configured to: when the received tSL-HL data PDU is stored in reception buffer and the received tSL-HL data PDU is the PDU: decode the PDU, update a tSL- HL receive side state variable, increment the PDU ID to a PDU ID for which the HARQ entity remains free from at least one byte segment, and reassemble a tSL- HL SDU from byte segments of tSL-HL PDUs with a PDU ID that falls outside of the receiving window and in-sequence byte segments of the tSL-HL PDU with the PDU ID of a PDU with a complete set of the bytes, remove tSL-HL headers during the reassembly and deliver the reassembled tSL-HL SDU to the at least one of the IP or application layer.
  • Example 27 the subject matter of Example undefined optionally includesA computer-readable storage medium that stores instructions for execution by one or more processors of a user equipment (UE), the one or more processors to: generate one of a user plane (UP) or control plane (CP) service data unit (SDU) for transmission to another UE (nUE) through a sidelink (tSL) interface; generate a packet data unit (PDU) from the SDU, the PDU comprising one of the SDU or a SDU segment of the SDU, a PDU identity (ID) comprising a duple that comprises a SDU sequence number (SN) and a SDU segment number (Seg_N), the Seg_N equal to 0 when the PDU is the SDU, the PDU comprising one of new or retransmission data; receive, from the nUE through the tSL interface, the UL grant for transmission of the PDU; and transmit to the nUE through the tSL interface the PDU as indicated by the UL grant.
  • UP user plane
  • Example 28 the subject matter of Example 27 optionally includes, wherein the instructions further configure the one or more processors to: start a discard timer associated with the SDU after the SDU is generated, perform at least one of header compression, integrity protection or ciphering of the SDU when configured by a tSL-RRC layer, and when the next available SN is the maximum SDU SN, reset the SDU SN, and store the SDU in a transmission buffer to form a buffered SDU, wherein the discard timer, maximum SDU SN and buffer size of the transmission buffer are different for the UP and CP SDU.
  • Example 29 the subject matter of any one or more of Examples 27–28 optionally include, wherein: the UL grant comprises at least one of a new grant for transmission of new UL data or a retransmission grant for a hybrid automatic repeat request (HARQ) retransmission, the retransmission grant being one of an adaptive or non-adaptive retransmission grant, the UL grant associated with a physical resource block (PRB) for the UE to transmit the PDU to the other UE, and the instructions further configure the one or more processors to: in response to reception of the UL grant: in response to reception of the new grant, set a new data indicator (NDI), the new grant addressed to a short identification (ID) of the UE, and in response to reception of the adaptive retransmission grant, determine the PRB, the PRB indicated by the adaptive retransmission grant, and for the non-adaptive retransmission grant, determine the PRB based on HARQ rules and resources for, and a TTI value of, the new grant,
  • HARQ
  • Example 30 the subject matter of Example undefined optionally includesAn apparatus of a user equipment (UE), the apparatus comprising: means for generating one of a user plane (UP) or control plane (CP) service data unit (SDU) for transmission to another UE (nUE) through a sidelink (tSL) interface; means for generating a packet data unit (PDU) from the SDU, the PDU comprising one of the SDU or a SDU segment of the SDU, a PDU identity (ID) comprising a duple that comprises a SDU sequence number (SN) and a SDU segment number (Seg_N), the Seg_N equal to 0 when the PDU is the SDU, the PDU comprising one of new or retransmission data; means for receiving, from the nUE through the tSL interface, the UL grant for transmission of the PDU; and means for transmitting to the nUE through the tSL interface the PDU as indicated by the UL grant.
  • UP user plane
  • CP control plane
  • Example 31 the subject matter of Example 30 optionally includes, further comprising: means for starting a discard timer associated with the SDU after the SDU is generated, means for performing at least one of header compression, integrity protection or ciphering of the SDU when configured by a tSL-RRC layer, and means for resetting, when the next available SN is the maximum SDU SN, the SDU SN, and store the SDU in a transmission buffer to form a buffered SDU, wherein the discard timer, maximum SDU SN and buffer size of the transmission buffer are different for the UP and CP SDU.
  • Example 33 the subject matter of Example undefined optionally includesA method of providing communications between user equipments (UEs), the method comprising: generating one of a user plane (UP) or control plane (CP) service data unit (SDU) for transmission from one UE to another UE (nUE) through a sidelink (tSL) interface; generating a packet data unit (PDU) from the SDU, the PDU comprising one of the SDU or a SDU segment of the SDU, a PDU identity (ID) comprising a duple that comprises a SDU sequence number (SN) and a SDU segment number (Seg_N), the Seg_N equal to 0 when the PDU is the SDU, the PDU comprising one of new or retransmission data; receiving, from the nUE through the tSL interface, the UL grant for transmission of the PDU; and transmitting to the nUE through the tSL interface the PDU as indicated by the UL grant.
  • UP user plane
  • CP control plane
  • SDU service
  • Example 34 the subject matter of Example 33 optionally includes, further comprising: starting a discard timer associated with the SDU after the SDU is generated, performing at least one of header compression, integrity protection or ciphering of the SDU when configured by a tSL-RRC layer, and resetting, when the next available SN is the maximum SDU SN, the SDU SN, and store the SDU in a transmission buffer to form a buffered SDU, wherein the discard timer, maximum SDU SN and buffer size of the transmission buffer are different for the UP and CP SDU.
  • Example 35 the subject matter of any one or more of
  • Examples 33–34 optionally include, wherein: the UL grant comprises at least one of a new grant for transmission of new UL data or a retransmission grant for a hybrid automatic repeat request (HARQ) retransmission, the retransmission grant being one of an adaptive or non-adaptive retransmission grant, the UL grant associated with a physical resource block (PRB) for the UE to transmit the PDU to the other UE, and the method further comprises: in response to reception of the UL grant: setting, in response to reception of the new grant, a new data indicator (NDI), the new grant addressed to a short identification (ID) of the UE, and determining, in response to reception of the adaptive retransmission grant, the PRB, the PRB indicated by the adaptive retransmission grant, and determining, for the non-adaptive retransmission grant, the PRB based on HARQ rules and resources for, and a TTI value of, the new grant, a
  • NDI new data indicator
  • ID short identification

Landscapes

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

Abstract

L'invention concerne en général des systèmes et des procédés de gestion de transfert et de réception de données de plan utilisateur et de plan de commande directement entre des UE. L'invention concerne une procédure de transfert de données qui comprend des variables, des constantes et des minuteries destinées à une entité de transmission tSL-HL et la mise à jour des variables pour gérer et suivre le transfert de données. La procédure comprend l'attribution et la maintenance des SN SDU pendant la transmission et la retransmission, ainsi que la mise en mémoire tampon et la surveillance de l'état de transfert de chaque SDU et PDU et d'un processus HARQ associé. Des procédures de réception de données décrites pour les données de plan d'utilisateur et de plan de commande comprennent la réception de la PDU à partir d'une couche inférieure, le stockage de la PDU et la combinaison des PDU dans une mémoire tampon.
PCT/US2016/068256 2016-10-31 2016-12-22 Procédures de transfert et de réception de données dans des communications de liaison latérale 5g/s Ceased WO2018080565A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662415092P 2016-10-31 2016-10-31
US62/415,092 2016-10-31

Publications (1)

Publication Number Publication Date
WO2018080565A1 true WO2018080565A1 (fr) 2018-05-03

Family

ID=62025309

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/068256 Ceased WO2018080565A1 (fr) 2016-10-31 2016-12-22 Procédures de transfert et de réception de données dans des communications de liaison latérale 5g/s

Country Status (1)

Country Link
WO (1) WO2018080565A1 (fr)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020056068A1 (fr) * 2018-09-13 2020-03-19 Intel Corporation Rétroaction de demande de répétition automatique hybride pour communication sans fil
WO2020143755A1 (fr) * 2019-01-11 2020-07-16 中国移动通信有限公司研究院 Procédé d'envoi et procédé de réception d'informations de commande, terminal et dispositif côté réseau
WO2021087880A1 (fr) * 2019-11-07 2021-05-14 Zte Corporation Système et procédé de conception et de configuration de signalisation de référence
CN114375553A (zh) * 2019-09-23 2022-04-19 联想（新加坡）私人有限公司 确定数据传输抢占
WO2022103139A1 (fr) * 2020-11-10 2022-05-19 Samsung Electronics Co., Ltd. Procédé et appareil d'accélération de traitement de données dans un système de communication sans fil de prochaine génération
CN115152265A (zh) * 2020-02-13 2022-10-04 Lg电子株式会社 在无线通信系统中基于配置许可刷新harq缓冲器的方法和设备
WO2024007305A1 (fr) * 2022-07-08 2024-01-11 Apple Inc. Rejet proactif de paquets de liaison montante pour systèmes nouvelle radio 5g
KR20240031372A (ko) * 2021-09-08 2024-03-07 엘지전자 주식회사 무선 통신 시스템에서 ue가 프레임 레벨 폐기 동작을 수행하기 위한 방법 및 장치
US20240171317A1 (en) * 2021-05-26 2024-05-23 Lg Electronics Inc. Method and apparatus for managing configured grant timer in wireless communication system
EP4445679A4 (fr) * 2022-02-11 2025-10-29 Zte Corp Procédé et système de traitement de rapport d'état de commande de liaison radio incohérent

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015163593A1 (fr) * 2014-04-22 2015-10-29 Lg Electronics Inc. Procédé pour traiter des pdu de pdcp reçues pour un système de communication d2d et dispositif correspondant
US20160128094A1 (en) * 2014-11-05 2016-05-05 Lg Electronics Inc. Method for canceling scheduling requests triggered by a sidelink buffer status report in a d2d communication system and device therefor

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015163593A1 (fr) * 2014-04-22 2015-10-29 Lg Electronics Inc. Procédé pour traiter des pdu de pdcp reçues pour un système de communication d2d et dispositif correspondant
US20160128094A1 (en) * 2014-11-05 2016-05-05 Lg Electronics Inc. Method for canceling scheduling requests triggered by a sidelink buffer status report in a d2d communication system and device therefor

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"NR user plane architecture to ease Tx processing", R2-166884, 3GPP TSG-RAN WG2 MEETING #95BIS, 1 October 2016 (2016-10-01), Kaohsiung, XP051162295 *
CATT: "NR U-plane multiconnectivity configurations", R2-166112, 3GPP TSG-RAN WG2 MEETING #95BIS, 30 September 2016 (2016-09-30), Kaohsiung, XP051161575 *
HUAWEI, HISILICON: "Analysis of L2 Segmentation and Concatenation in NR", R2-166196, 3GPP TSG-RAN WG2 MEETING #95BIS, 1 October 2016 (2016-10-01), Kaohsiung, XP051162067 *

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112655166B (zh) * 2018-09-13 2024-04-16 苹果公司 用于无线通信的混合自动重传请求反馈
CN112655166A (zh) * 2018-09-13 2021-04-13 苹果公司 用于无线通信的混合自动重传请求反馈
US12119945B2 (en) 2018-09-13 2024-10-15 Apple Inc. Hybrid automatic repeat request feedback for wireless communication
WO2020056068A1 (fr) * 2018-09-13 2020-03-19 Intel Corporation Rétroaction de demande de répétition automatique hybride pour communication sans fil
WO2020143755A1 (fr) * 2019-01-11 2020-07-16 中国移动通信有限公司研究院 Procédé d'envoi et procédé de réception d'informations de commande, terminal et dispositif côté réseau
US12035300B2 (en) 2019-01-11 2024-07-09 China Mobile Communication Co., Ltd Research Institute Control information sending method and receiving method, terminal, and network side device
CN114375553A (zh) * 2019-09-23 2022-04-19 联想（新加坡）私人有限公司 确定数据传输抢占
WO2021087880A1 (fr) * 2019-11-07 2021-05-14 Zte Corporation Système et procédé de conception et de configuration de signalisation de référence
US12369182B2 (en) 2019-11-07 2025-07-22 Zte Corporation System and method for reference signaling design and configuration
CN115152265A (zh) * 2020-02-13 2022-10-04 Lg电子株式会社 在无线通信系统中基于配置许可刷新harq缓冲器的方法和设备
US12143226B2 (en) 2020-02-13 2024-11-12 Lg Electronics Inc. Method and apparatus for flushing HARQ buffer based on configured grant in wireless communication system
WO2022103139A1 (fr) * 2020-11-10 2022-05-19 Samsung Electronics Co., Ltd. Procédé et appareil d'accélération de traitement de données dans un système de communication sans fil de prochaine génération
US20240171317A1 (en) * 2021-05-26 2024-05-23 Lg Electronics Inc. Method and apparatus for managing configured grant timer in wireless communication system
KR20240031372A (ko) * 2021-09-08 2024-03-07 엘지전자 주식회사 무선 통신 시스템에서 ue가 프레임 레벨 폐기 동작을 수행하기 위한 방법 및 장치
KR102876068B1 (ko) * 2021-09-08 2025-10-27 엘지전자 주식회사 무선 통신 시스템에서 ue가 프레임 레벨 폐기 동작을 수행하기 위한 방법 및 장치
EP4445679A4 (fr) * 2022-02-11 2025-10-29 Zte Corp Procédé et système de traitement de rapport d'état de commande de liaison radio incohérent
WO2024007305A1 (fr) * 2022-07-08 2024-01-11 Apple Inc. Rejet proactif de paquets de liaison montante pour systèmes nouvelle radio 5g

Similar Documents

Publication Publication Date Title
US11737171B2 (en) 5G FDD low latency transmission subframe structure system and method of use
US11245480B2 (en) Devices and methods for robust measurement and data receiving
US11013063B2 (en) User equipment (UE), evolved node-b (eNB) and methods for dynamic hybrid automatic repeat request (HARQ)
US10390236B2 (en) Systems, methods and devices for uplink transmissions with reduced signaling overhead
EP3420659B1 (fr) Informations de commande de liaison descendante destinées à des transmissions de liaison montante non programmées
US10560174B2 (en) Latency reduction for wireless data transmission
WO2018080565A1 (fr) Procédures de transfert et de réception de données dans des communications de liaison latérale 5g/s
WO2018080561A1 (fr) Rapport d'état de tampon dans des communications de liaison latérale de l'internet des objets nr 5g
WO2017099860A1 (fr) Dispositif pour une émission en liaison montante non planifiée dans le spectre non autorisé
CN115459894A (zh) 用于新空口物理上行链路控制信道的序列设计和资源分配
US11122643B2 (en) LWIP enhancements for reliable DRB switching
WO2017127126A1 (fr) Dispositifs et procédés pour fournir une requête de liaison montante 5g
US10694453B2 (en) Discovery and network access procedures for 5G things communication system
US20190090220A1 (en) User equipment (ue) and method of sidelink data communication in fifth generation (5g) new radio (nr) things networks
CN110168999A (zh) Nr urllc中可靠的免授权上行链路传输
WO2018080566A1 (fr) Structure de sous-trame et procédure de communication pour une communication véhicule à véhicule d'objets nr 5g
WO2018084880A1 (fr) Planification d'ue réseau assistée par nœud b évolué dans une liaison latérale d'objets de nouvelle radio 5g
WO2018071051A1 (fr) Procédures et signalisation de planification et attribution de ressources dans un système de communication de liaison latérale d'objets de nouvelle radio 5g
CN114448592B (zh) 5g系统中的自包含tdd帧结构和dl-ul配置
EP3437381A1 (fr) Échelonnement d'un trafic sans surveillance dans un système d'évolution à long terme (lte) après une interdiction
HK1255081B (zh) 针对无线数据传输的延迟减少

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

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

Country of ref document: EP

Kind code of ref document: A1