CN109076568B - High layer design for control plane packet processing in fifth generation (5G) wearable communications - Google Patents

Abstract

Discusses techniques for implementing wearable high layers (w‑HL) for communications including wearable user equipment (wUE). An example includes: assigning a different sequence number to each of the one or more control plane (CP) packets from the wearable radio resource control (w-RRC) layer; buffering the one or more CP packets to the CP transmit buffer; determine physical resource allocation (PRA) and allocation size for wearable high layer (w‑HL) control protocol data units (C‑PDUs); based at least in part on one or more buffered to CP transmit buffers CP packet, PRA, and allocation size generate w-HL C-PDU; add packet header to w-HL C-PDU; and provide w-HL C-PDU to physical layer based on PRA.

Description

High-level design for control-plane packet processing in fifth-generation (5G) wearable communications

CROSS-REFERENCE TO RELATED APPLICATIONS

THIS APPLICATION REQUESTS A U.S. PROVISIONAL DESIGN FOR CONTROLPLANE PACKET PROCESSING IN 5G-WEARABLE COMMUNICATION, filed on May 19, 2016 The benefit of Application No. 62/338,917, the contents of which are hereby incorporated by reference in their entirety.

technical field

The present disclosure relates to wireless technologies, and more particularly to high-level designs for communication between wearable user equipment (wUE) and network UEs (nUE).

Background technique

Conventional LTE (Long Term Evolution) systems employ a higher layer protocol stack that includes a PHY (Physical Layer) and an RRC (Radio Resource Control) layer for control plane traffic or IP (Internet Protocol) or IP (Internet Protocol) for user plane traffic. A protocol layer between application layers. In conventional LTE, these higher layer protocol layers are the MAC (Medium Access Control) layer, the RLC (Radio Link Control) layer, and the PDCP (Packet Data Convergence Protocol) layer.

SUMMARY OF THE INVENTION

Embodiments of the present disclosure relate to an apparatus configured for use in a user equipment UE.

According to a first aspect of the present disclosure, there is provided an apparatus configured for use in a user equipment UE. The apparatus includes: a memory; and one or more processors configured to: provide one or more control plane CP packets from the wearable radio resource control w-RRC layer to the wearable high layer w-HL; assigning a different sequence number to each of the multiple CP packets; buffering the one or more CP packets into the CP transmission buffer; determining the physical resource configuration PRA for the w-HL control protocol data unit C-PDU and an allocation size; generating the w-HL C-PDU based at least in part on the one or more CP packets buffered to the CP transmit buffer, the PRA, and the allocation size; sending the w-HL C-PDU to the w- The HLC-PDU adds a packet header; and the w-HL C-PDU is provided from the w-HL to the physical layer based on the PRA.

According to a second aspect of the present disclosure, there is provided an apparatus configured for use in a user equipment UE. The apparatus includes: a memory; and one or more processors configured to: provide one or more wearable higher layer w-HL control protocol data units C-PDUs from one or more physical layer transport blocks TB to w -HL; generate a plurality of w-HL control service data units C-SDUs from the one or more w-HL C-PDUs; The associated different sequence numbers SN determine an ordering of the plurality of w-HL SDUs; and providing the plurality of w-HL C- SDU.

According to a third aspect of the present disclosure, there is provided an apparatus configured for use in a user equipment UE. The apparatus includes: means for storing configured to store instructions; and means for processing configured to execute the instructions to: provide from the wearable radio resource control w-RRC layer to the wearable high layer w-HL one or more w-HL control service data units C-SDUs; assign a unique sequence number SN to each of the one or more w-HL C-SDUs; assign the one or more storing a plurality of w-HL C-SDUs in an uplink UL control plane CP transmit buffer; receiving a UL grant indicating a physical resource configuration PRA and a grant size; generating w-HL control protocol data based at least in part on the UL grant Element C-PDU, wherein the w-HL C-PDU includes a buffer status report BSR, a power headroom report PHR, a UL CP transmission buffer, a UL CP retransmission buffer, a UL user plane CP transmission buffer, or one or more of a UL UP retransmission buffer; and passing the w-HL C-PDU from the w-HL to the physical layer.

Description of drawings

1 is a block diagram illustrating an example user equipment (UE) that may be used in conjunction with various aspects described herein.

2 is an example diagram of a communication system that can facilitate fifth generation (5G) wearable (5G wearable or 5G-W) communications in accordance with aspects described herein.

3 is a diagram illustrating a protocol stack for a wUE (wearable UE)-nUE (network UE) interface in accordance with aspects described herein.

4 is a flowchart illustrating an example of processing details that control plane (CP) data may undergo at a w-HL (wearable high layer) layer in accordance with aspects described herein.

5 is a block diagram illustrating a system that facilitates a high layer (w-HL) for wearable communications at a UE in accordance with aspects described herein.

6 is a flowchart illustrating a method of generating w-HL C-PDUs (Control Plane Protocol Data Units) from one or more w-RRC (Wearable Radio Resource Control) CP packets with the aid of various aspects described herein .

7 is a flowchart illustrating a method of generating one or more w-RRC CP packets from one or more received TBs (transport blocks) and delivering the packets in sequence with the aid of various aspects described herein.

FIG. 8A is a diagram illustrating that when the remaining grant has only one byte, which may be added at the beginning of the w-HL C-PDU header to exactly match the w-HL C-PDU size to the grant size, in accordance with aspects described herein Illustration of an example of padding subheaders.

8B is a diagram illustrating that when the remaining grant has only two bytes, it may be added at the beginning of the w-HL C-PDU header to exactly match the w-HL C-PDU size to the grant size in accordance with aspects described herein A diagram of an example of a padding subheader.

8C is a diagram illustrating that 0 or more bytes may be added at the end of the w-HL C-PDU header to enable insertion of 0 or more bytes at the end of the w-HL-PDU (data field) in accordance with aspects described herein Illustration of an example of a padding subheader that pads the data field so that the w-HL C-PDU size can be exactly matched to the grant size.

9A is a diagram showing an example of a C-PDU including only CP SDUs (Service Data Units) from the UL (Uplink) CP Transmission Buffer.

9B is a diagram showing an example of a C-PDU including a BSR (Buffer Status Report) and a CP SDU from a UL CP transmission buffer.

10A is a diagram illustrating an example of a C-PDU including a PHR (Power Headroom Report) and a CP SDU from a UL CP transmit buffer.

10B is a diagram illustrating an example of a C-PDU including a BSR, a PHR, and a CP SDU from a UL CP transmit buffer.

FIG. 11 is a diagram showing an example of a C-PDU similar to FIG. 10B with a padding subheader of one byte at the beginning.

FIG. 12 is a diagram showing an example of a C-PDU similar to FIG. 10B with a padding subheader of two bytes at the beginning.

FIG. 13 shows a diagram of an example of a C-PDU similar to that of FIG. 10B with a padding subheader of multiple bytes at the end.

Figure 14 is a diagram showing an example w-HL C-PDU with BSR, PHR, and CP-SDU segment from UL CP Tx (transmission) buffer (the segment is not the last segment of the SDU).

15 is a diagram showing an example of a w-HL C-PDU with BSR, PHR, and CP-SDU from the UL CP TX buffer (the segment is the last segment of the SDU).

16A is a diagram showing an example of a w-HL C-PDU with BSR, PHR, and UP-SDU (User Plane SDU) from the UL User Plane Tx Buffer.

16B is a diagram showing an example of a w-HL C-PDU with BSR, PHR, and a UP-SDU segment from the UL user plane TX buffer (not the last segment of the SDU).

17A is a diagram showing an example of a w-HL C-PDU with BSR, PHR, and UP-SDU segment from the UL user plane TX buffer (last segment of the SDU).

17B is a diagram showing an example of ARQ retransmission of w-HL C-PDUs with BSR, PHR, and C-PDUs (not re-segmented) from the UL ARQ control plane retransmission buffer.

Figure 18A is an ARQ showing a w-HL C-PDU with BSR, PHR, and a C-PDU segment from the UL ARQ control plane retransmission buffer (not the last segment of the re-segmented C-PDU) Illustration of an example of retransmission.

Figure 18B is a diagram showing a w-HL C-PDU segment with BSR, PHR, and C-PDU segment from the UL ARQ control plane retransmission buffer (last segment of the re-segmented C-PDU) Illustration of an example of ARQ retransmission.

19 is a diagram showing an example of a w-HL C-PDU with BSR, PHR, CP-SDU from UL control plane TX buffer, and UP-SDU from UL user plane TX buffer.

Figure 20 is a w-HL showing a BSR, PHR, CP-SDU from UL control plane TX buffer, and UP-SDU segment from UL user plane TX buffer (not the last segment of UP-SDU) Illustration of an example of a CP PDU.

Figure 21 is a w-HL CP PDU showing with BSR, PHR, CP-SDU segment from UL control plane TX buffer (last segment of the SDU), and UP-SDU from UL user plane TX buffer A diagram of an example.

Figure 22 is a diagram showing a segment with BSR, PHR, CP-SDU from UL control plane TX buffer (last segment of the SDU), and UP-SDU segment from UL user plane TX buffer (not SDU's) A diagram of an example of a w-HL CP PDU of the last segment).

Figure 23 is a diagram showing a w-HL C-PDU with BSR, PHR, C-PDU from UL control plane retransmission buffer (not re-segmented), and UP-SDU from UL user plane TX buffer Illustration of an example.

Figure 24 is a diagram showing a C-PDU with BSR, PHR, C-PDU from UL control plane retransmission buffer (not re-segmented), and UP-SDU segment from UL user plane TX buffer (not the last segment) A diagram of an example of a w-HL C-PDU.

Figure 25 is a diagram showing a C-PDU with BSR, PHR, C-PDU from UL control plane retransmission buffer (not re-segmented), CP SDU from UL control plane transmission buffer, and from UL user plane TX buffer Illustration of an example of a w-HL C-PDU of a UP-SDU (not fragmented).

Figure 26 is a diagram showing a C-PDU segment with BSR, PHR, C-PDU from UL control plane retransmission buffer (last segment of the re-segmented C-PDU), and CP-PDU from UL control plane TX buffer Illustration of an example of a w-HL C-PDU of an SDU.

Figure 27 is a diagram showing a C-PDU segment with BSR, PHR, C-PDU from UL control plane retransmission buffer (last segment of the re-segmented C-PDU), and CP SDU from UL control plane TX buffer Illustration of an example of a fragmented (not the last fragmented) w-HLC-PDU.

Detailed ways

The present disclosure will now be described with reference to the drawings, wherein like reference numerals are used throughout to refer to like elements and the illustrated structures and devices are not necessarily drawn to scale. As used herein, the terms "component," "system," "interface," etc. are used to refer to computer-related entities, hardware, software (eg, software in execution), and/or firmware. For example, a component may be a processor (eg, a microprocessor, controller, or other processing device), processes running on the processor, controllers, objects, executable instructions, programs, storage devices, computers, tablet PCs, and /or user equipment with processing equipment (eg, mobile phone, etc.). For example, applications running on servers and servers can also be components. One or more components can reside in a process, and a component can be localized on one computer and/or distributed between more than two computers. A group of elements or a group of other components may be described herein, wherein the term "group" may be understood to mean "one or more."

In addition, these components can execute data structures from various computer-readable storage media having various data structures (eg, modules) stored thereon. For example, these components may be based on having one or more data packets (eg, from a local system, a distributed system, and/or across a network (eg, the Internet, a local area network, a wide area network, or a similar network with other systems) via signals) The data of one component that interacts with another component in another component) is communicated via local and/or remote processes.

As another example, a component may be a device having a specific function provided by mechanical components operated by electrical or electronic circuits that may be operated by a software application or a firmware application executed by one or more processors. The one or more processors may be internal or external to the device and may execute at least a portion of a software or firmware application. As yet another example, a component may be a device that provides a specific function through an electronic component without mechanical components; the electronic component may include one or more processors in which software and/or firmware executes software and/or firmware that at least partially imparts the functionality of the electronic component.

The word "exemplary" is used to refer to a specific concept. The term "or" is used in this application to mean an inclusive "or" rather than an exclusive "or." That is, unless indicated to the contrary or clear from context, "X employs A or B" means any natural inclusive permutation. That is, if X employs A, X employs B, or X employs A and B, then any of the foregoing instances satisfy "X employs A or B." In addition, the terms "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless indicated to the contrary or clear from the context to be directed to a singular form . In addition, the terms "comprising", "including", "having", "containing", "having", or variations thereof are used in the detailed description and claims, and these terms are used to mean inclusiveness similar to the term "comprising" meaning.

The term "circuitry" as used herein may refer to or include an application specific integrated circuit (ASIC), electronic circuit, processor (shared, dedicated, or group), and/or memory (shared) executing one or more software or firmware programs , dedicated, or group), combinational logic, and/or other suitable hardware components that provide the described functionality, or may be part of such hardware components. In some embodiments, a circuit may be implemented in one or more software or firmware modules, or functionality associated with a circuit may be implemented by one or more software or firmware modules. In some embodiments, a circuit may include logic operable, at least in part, in hardware.

The embodiments described herein may be implemented as a system using any suitably configured hardware and/or software. Figure 1 illustrates example components of a user equipment (UE) device 100 in accordance with some embodiments. In some embodiments, UE device 100 may include application circuitry 102 , baseband circuitry 104 , radio frequency (RF) circuitry 106 , front-end module (FEM) circuitry 108 , and one or more antennas 110 coupled together as shown .

Application circuitry 102 may include one or more application processors. For example, application circuitry 102 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The one or more processors may include any combination of general-purpose processors and special-purpose processors (eg, graphics processors, application processors, etc.). The processor may be coupled to or include a memory/storage device and may be configured to execute instructions stored in the memory/storage device to enable various applications and/or operating systems to run on the system.

Baseband circuitry 104 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. Baseband circuitry 104 may include one or more baseband processors and/or control logic to process baseband signals received from the receive signal path of RF circuitry 106 and generate baseband signals for the transmit signal path of RF circuitry 106 . Baseband processing circuitry 104 may interface with application circuitry 102 for generating and processing baseband signals and for controlling the operation of RF circuitry 106 . For example, in some embodiments, baseband circuitry 104 may include second generation (2G) baseband processor 104a, third generation (3G) baseband processor 104b, fourth generation (4G) baseband processor 104c, and/or use One or more other baseband processors 104d in other existing generations, in development generations, or in future generations (eg, fifth generation (5G), 6G, etc.). Baseband circuitry 104 (eg, one or more baseband processors 104a - d ) may handle various radio control functions that enable communication with one or more radio networks via RF circuitry 106 . Radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency offset, and the like. In some embodiments, the modulation/demodulation circuitry of baseband circuitry 104 may include Fast Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functions. In some embodiments, the encoding/decoding circuitry of baseband circuitry 104 may include convolution, tail-biting convolution, turbo, Viterbi, and/or low density parity check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functions are not limited to these examples, and other suitable functions may be included in other embodiments.

In some embodiments, baseband circuitry 104 may include elements of a protocol stack, eg, elements of the Evolved Universal Terrestrial Radio Access Network (EUTRAN) protocol (eg, Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), Packet Data Convergence Protocol (PDCP), and/or Radio Resource Control (RRC) elements). The central processing unit (CPU) 104e of the baseband circuit 104 may be configured as an element of a protocol stack running for signaling of the PHY, MAC, RLC, PDCP, and/or RRC layers. In some embodiments, the baseband circuitry may include one or more audio digital signal processors (DSPs) 104f. Audio DSP 104f may include elements for compression/decompression and echo cancellation, and may include other suitable processing elements in other embodiments. In some embodiments, the components of the baseband circuitry may be suitably combined on a single chip or set of chips, or arranged on the same circuit board. In some embodiments, some or all of the constituent components of the baseband circuit 104 and the application circuit 102 may be implemented together, eg, on a system-on-chip (SOC).

In some embodiments, baseband circuitry 104 may provide communications compatible with one or more radio technologies. For example, in some embodiments, baseband circuitry 104 may support communication with Evolved Universal Terrestrial Radio Access Network (EUTRAN) and/or other Wireless Metropolitan Area Network (WMAN), Wireless Local Area Network (WLAN), Wireless Personal Area Network (WPAN) communication. Embodiments in which baseband circuitry 104 may be configured to support radio communications of more than one wireless protocol are referred to as multi-mode baseband circuitry.

RF circuitry 106 may use modulated electromagnetic radiation through a non-solid medium to enable communication with a wireless network. In various embodiments, RF circuitry 106 may include switches, filters, amplifiers, etc. to facilitate communication with the wireless network. RF circuitry 106 may include a receive signal path that may include circuitry that downconverts RF signals received from FEM circuitry 108 and provides baseband signals to baseband circuitry 104 . RF circuitry 106 may also include a transmit signal path, which may include circuitry that upconverts the baseband signal provided by baseband circuitry 104 and provides an RF output signal to FEM circuitry 108 for transmission.

In some embodiments, RF circuitry 106 may include a receive signal path and a transmit signal path. The receive signal path of RF circuit 106 may include mixer circuit 106a, amplifier circuit 106b, and filter circuit 106c. The transmit signal path of RF circuit 106 may include filter circuit 106c and mixer circuit 106a. The RF circuit 106 may also include a combiner circuit 106d for combining frequencies for use by the mixer circuit 106a of the receive and transmit signal paths. In some embodiments, the mixer circuit 106a of the receive signal path may be configured to downconvert the RF signal received from the FEM circuit 108 based on the synthesized frequency provided by the synthesizer circuit 106d. Amplifier circuit 106b may be configured to amplify the down-converted signal, and filter circuit 106c may be a low-pass filter (LPF) configured to remove unwanted signals from the down-converted signal to generate an output baseband signal. ) or Band Pass Filter (BPF). The output baseband signal may be provided to baseband circuitry 104 for further processing. In some embodiments, the output baseband signal may be a zero frequency baseband signal, although this is not required. In some embodiments, the mixer circuit 106a of the receive signal path may comprise a passive mixer, although the scope of the embodiments is not limited in this regard.

In some embodiments, the mixer circuit 106a of the transmit signal path may be configured to upconvert the input baseband signal based on the synthesized frequency provided by the synthesizer circuit 106d to generate the RF output signal for the FEM circuit 108 . The baseband signal may be provided by baseband circuit 104 and filtered by filter circuit 106c. The filter circuit 106c may comprise a low pass filter (LPF), although the scope of the embodiment is not limited in this regard.

In some embodiments, the mixer circuit 106a of the receive signal path and the mixer circuit 106a of the transmit signal path may comprise more than two mixers and may be arranged for quadrature downconversion and/or upconversion, respectively . In some embodiments, the mixer circuit 106a of the receive signal path and the mixer circuit 106a of the transmit signal path may include more than two mixers, and may be arranged for image rejection (eg, Hartley image rejection ). In some embodiments, the mixer circuit 106a of the receive signal path and the mixer circuit 106a of the transmit signal path may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuit 106a of the receive signal path and the mixer circuit 106a of the transmit signal path may be configured for superheterodyne operation.

In some embodiments, the output baseband signal and the input baseband signal may be analog baseband signals, although the scope of the embodiments is not limited in this regard. In some alternative embodiments, the output baseband signal and the input baseband signal may be digital baseband signals. In these alternative embodiments, RF circuitry 106 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuits, and baseband circuitry 104 may include a digital baseband interface in communication with RF circuitry 106 .

In some dual-mode embodiments, separate radio IC circuits may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this regard.

In some embodiments, the synthesizer circuit 106d may be a fractional N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiment is not limited in this regard (as other types of frequency synthesizers are also suitable). For example, the synthesizer circuit 106d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer including a phase locked loop with a frequency divider.

The synthesizer circuit 106d may be configured to synthesize the output frequency for use by the mixer circuit 106a of the RF circuit 106 based on the frequency input and the divider control input. In some embodiments, the combiner circuit 106d may be a fractional N/N+1 combiner.

In some embodiments, the frequency input may be provided by a voltage controlled oscillator (VCO), although this is not required. The divider control input may be provided by the baseband circuit 104 or the application processor 102 based on the desired output frequency. In some embodiments, the divider control input (eg, N) may be determined from a lookup table based on the channel indicated by the application processor 102 .

The combiner circuit 106d of the RF circuit 106 may include frequency dividers, delay locked loops (DLLs), multiplexers, and phase accumulators. In some embodiments, the frequency divider may be a dual modulo frequency divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by N or N+1 (eg, based on carry) to provide a fractional divide ratio. In some example embodiments, the DLL may include a cascaded set of tunable delay elements, phase detectors, charge pumps, and D-type flip-flops. In these embodiments, the delay elements may be configured to divide the VCO period into Nd equal phase groupings, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, the synthesizer circuit 106d may be configured to generate the carrier frequency as the output frequency, while in other embodiments the output frequency may be a multiple of the carrier frequency (eg, twice the carrier frequency, four times), and is used in conjunction with an integrating generator and a frequency divider circuit to generate multiple signals at the carrier frequency that are out of phase with each other. In some embodiments, the output frequency may be the LO frequency (fLO). In some embodiments, the RF circuit 106 may include an IQ/polarity converter.

FEM circuitry 108 may include a receive signal path that may include a receive signal path configured to operate on RF signals received from one or more antennas 110, amplify the received signals, and provide an amplified version of the received signals to RF circuitry 106 for processing circuit for further processing. The FEM circuit 108 may also include a transmit signal path, which may include circuitry configured to amplify the transmission signal provided by the RF circuit 106 for transmission by one or more of the one or more antennas 110 .

In some embodiments, the FEM circuit 108 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuit may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuit may include a low noise amplifier (LNA) that amplifies the received RF signal and provides the amplified receive RF signal as an output (eg, to RF circuit 106). The transmit signal path of the FEM circuit 108 may include a power amplifier (PA) that amplifies the input RF signal (eg, provided by the RF circuit 106 ), and generates a power amplifier (PA) for (eg, one or more of the one or more antennas 110 ) antenna) one or more filters for subsequent transmitted RF signals.

In some embodiments, UE device 100 may include additional elements such as memory/storage devices, displays, cameras, sensors, and/or input/output (I/O) interfaces.

Additionally, although the above example discussion of device 100 is made in the context of a UE device (eg, a wearable UE (wUE) or a network UE (nUE)), in various aspects similar devices may be incorporated such as an evolved node Used by a base station (BS) such as B (eNB).

In various aspects, the techniques disclosed herein may employ simplified high-level designs for communication between wUEs and nUEs including a w-RRC (wearable radio resource control) layer and a PHY (physical layer) for the control plane ) or a single layer between the IP/application layer and the PHY layer for the user plane (referred to here as Wearable High Layer (w-HL)).

Referring to FIG. 2, there is shown an example diagram of a communication system 200 that can facilitate fifth generation (5G) wearable (5G wearable or 5G-W) communications in accordance with aspects described herein. The communication system of Figure 2 shows the following network nodes and interfaces: (1) nUE (Network UE) with full infrastructure network (NW) access protocol stack (eg, full C/U (Control/User) plane functionality); (2) Three wUEs (wearable UEs), wherein one wUE has direct NW connection and two wUEs access NW (eg, E-UTRAN (Evolved Universal Terrestrial Radio Access Network) and EPC (Performance Technology) only via the help of nUEs (3) PAN (Personal Area Network) including nUE and wUE, nUE and wUE can use mutual authentication to form PAN; (4) NW and nUE (5) air interface between NW and wUE, Uu-w interface; (6) intra-PAN air interface between nUE and wUE, Xu-a interface; and (7) Intra-PAN air interface between wUEs, Xu-b interface.

The various embodiments discussed herein relate to the Xu-a interface shown in FIG. 2 . In various cases, the wUE may communicate with the E-UTRAN via the nUE. Each nUE may have several wUEs associated with it that together form a PAN (eg, the nUW and three wUEs shown in Figure 2). Typically, there are a large number of nUEs in a geographic area, and each nUE can have its own PAN, which can create high-density network scenarios. E-UTRAN can allocate a common resource pool for wearable communication. The resource pool may be shared on a contention-based resource access basis among multiple PANs in a relatively small geographic area, and potentially among multiple wUEs in each PAN. Each nUE can have two upper layer protocol stacks: one higher layer protocol stack for the interface between the wUE and nUE (Xu-a air interface), and one higher layer protocol stack for the interface between nUE and E-UTRAN (Uu-a p air interface). The higher layer protocol stack for the interface nUE-UTRAN may be the LTE Uu stack or may be the LTE Evolved 5G protocol stack. A higher layer protocol stack may primarily refer to one or more protocol layers between the PHY and the Radio Resource Control layer for control plane traffic and between the PHY and the IP/application layer for user plane traffic. As a specific example, the high layer refers to the MAC, RLC, and PDCP layers in the conventional LTE system.

Due to the competitive environment for communication on the Xu-a interface, each packet transmission (eg, PHY transport block (TB) size) in wearable communication can be shorter to reduce the impact of collisions on system performance. In one example, the TB size may be a relatively small number of bytes, eg, less than 75 bytes. In this use case, reducing the size of packet headers added at higher layers ensures that the ratio of data to packet headers remains reasonable. The high layer protocol design and packet processing procedure design for the high layers discussed here can minimize the overhead of the high layer protocol headers transmitted per packet, thereby increasing throughput. In various embodiments, a single wearable high layer (w-HL) can be used for the control plane, which can provide some or all of the following features: (1) simplified high layer protocol design; (2) customization Functionality of higher layer protocols for wearable communications; (3) reduced number of protocol layer specific header fields (eg, avoids adding multi-level packet IDs (eg, sequence numbers)); (4) increased lengths of various packet header fields short; (5) packet segmentation and combining with lower packet header overhead; (6) multiplexing of buffer status reports (BSR), power headroom reports (PHR), control plane data, and user plane data; and (7) Packet retransmission has lower packet header overhead.

In various aspects discussed herein, all higher layer functions for control plane data processing (eg, legacy LTE MAC/RLC/PDCP functions) may be incorporated into a single layer referred to herein as the Wearable High Layer (w-HL) , which can reduce packet headers during transmission on the air interface. Each PHY-SDU (PHY Service Data Unit, eg, PHY TB) on the control PRA (Physical Resource Configuration) can have a very small size for 5G-w compared to legacy LTE (eg 180-600 bits or 22.5- 75 bytes), the packet header reduction can provide significant advantages in throughput.

3, a protocol stack for a wUE-nUE interface (eg, the Xu-a interface discussed herein) is shown in accordance with aspects described herein. For UL (Uplink) transmission, the CP/UP (Control Plane/User Plane) data packets to be sent on the air interface can be sent as data packets from the wearable RRC (Control Plane Data) layer and/or IP/Host (User Plane Data) ) layer w-HL Service Data Unit (w-HL SDU) is received. The w-RRC layer can manipulate the configuration of w-HL. The w-HL may store the CP data in the UL CP transmit buffer until the PHY indicates a UL grant on the control PRA. The w-HL may store the UP data in the UL UP transmission buffer. Various aspects discussed herein relate to techniques associated with CP data processing. The w-HL may form a CP w-HL Protocol Data Unit (CP w-HL PDU), which may be based on the TB size indicated by the PHY. The w-HL may then pass the w-HL CP PDU to the PHY for transmission. A CP data packet w-HL SDU may undergo a number of operations discussed herein at the w-HL protocol layer during its lifetime.

Referring to FIG. 4, an example flow diagram illustrating details of processing that control plane (CP) data may undergo at the w-HL layer in accordance with aspects described herein is shown. Figure 4 also shows the generation of PDUs to be sent on control PRAs/resources (such PDUs are referred to herein as control PDUs or C-PDUs). Some functions of w-HL for control plane data include: (1) maintain w-HL SN (serial number); (2) optionally, (eg, configured by w-RRC) completeness of control plane data flow (3) optional, encryption and decryption of control plane data (e.g., configured by w-RRC); (4) in-order delivery of upper layer data; (5) discarding of repeated w-HL CP SDUs and Duplicate detection; (6) w-HL CP SDU drop (eg, timer based); (7) concatenation, segmentation, and assembly of SDUs; (8) multiplex buffer status reporting, power headroom reporting, control plane data, and/or user plane data; (9) re-segmentation of w-HL C-PDUs; and (10) protocol error detection and recovery through retransmission at two levels: (a) first terabyte level HARQ (Hybrid ARQ (Automatic Repeat Request)) and (b) ARQ (Automatic Repeat Request) at the w-HL C-PDU level.

In various embodiments discussed herein, w-HL may be employed based on the following design choices for directing w-HL's CP data processing. First, a separate PRA/resource (referred to herein as a control PRA) that is known explicitly/implicitly may be employed for the transmission of control plane data. In various aspects, control plane data is sent only on the control PRA, other PRAs may be used for user plane data transmission. PRA (Physical Resource Allocation) is a basic unit of physical resource allocation of resource blocks. Second, Power Headroom Report (PHR) and Buffer Status Report (BSR) can be loaded in w-HL PDUs sent on the Controlling PRA. Third, if there are grant resources remaining after placing BSR, PHR, and/or CP data, user plane data (eg, UP data waiting to be transmitted in the UL UPTx (transmission) buffer or UL UP retransmission buffer) Can be included in the w-HL C-PDU for controlling the PRA. Thus, multiplexing and assembly operations for w-HL PDUs used to control the PRA may be employed in various embodiments.

Referring to FIG. 5, there is shown a system 500 of a high layer (w-HL) system 500 that facilitates wearable communications for UEs (eg, network UEs (nUEs) or wearable UEs (wUEs)) in accordance with aspects described herein block diagram. System 500 may include one or more processors 510 (eg, one or more baseband processors such as the one or more baseband processors discussed in connection with FIG. 1 ), transceiver circuitry 520 (eg, including transmitter circuits or receivers) one or more of the transmitter circuits, which may employ common circuit elements, different circuit elements, or a combination thereof), and memory 530 (which may include any of a variety of storage media) storage medium and may store instructions and/or data associated with one or more of the processor(s) 510 or the transceiver circuit(s) 520). In various aspects, system 500 may be included in a user equipment (UE), either a wearable UE (wUE) or a network UE (nUE). As described in more detail below, system 500 may provide high-level functionality for control messaging between one or more wearable UEs (wUEs) and network UEs (nUEs) in a personal area network (PAN).

One or more processors 510 may implement a wearable high layer (w-HL), which may perform higher layer functions associated with control messages exchanged between the wUE and the nUE. In the embodiments discussed herein, in contrast to conventional LTE systems that employ three layers (MAC, RLC, and PDCP), such higher layer functions (eg, w-RRC (wearable radio resource control) layer and PHY (physical layer) The functionality of the layer(s) in between) may be implemented by one or more processors 510 via a single layer referred to herein as a w-HL (Wearable High Layer). In various aspects, one or more processors 510 may implement functionality associated with a w-HL transmit (Tx) entity and/or functionality associated with a w-HL receive (Rx) entity.

In terms of w-HL Tx, one or more processors 510 may implement one or more functions associated with a w-HL Tx entity, eg, any of the actions shown or described in connection with FIG. 4 . For example, one or more processors 510 may receive one or more w-RRC (Radio Resource Control) CP (Control Plane) packets as w-HL SDU (Service Data Unit) packets. One or more processors 510 may assign different sequence numbers (SNs) to w-HL SDUs. Optionally, one or more processors 510 may apply integrity protection and/or encryption (cryptographic computations) to the w-HL SDU. One or more processors 510 may add w-HL SDUs (eg, w-RRC CP packets) to CP transmit buffers (eg, uplink (UL) CPTx buffer at wUE, downlink at nUE (DL)CP Tx Buffer).

The one or more processors 510 may determine a physical resource allocation (PRA) and corresponding allocation size for the transceiver circuit 520 to transmit w-HLPDUs (protocol data units) via the PHY (physical layer). On the wUE side, the PRA may be indicated via a UL grant (eg, from the nUE).

Based on the PRA and allocation size, the one or more processors 510 may generate a w-HL PDU, which may include a Buffer Status Report (BSR) (eg, when the one or more processors 510 determine to include a BSR) , a power headroom report (PHR) (eg, when one or more processors 510 determine to include a PHR), one or more w-HL SDUs from the CP Tx buffer or a segment thereof (eg, one or more The processor 510 may perform appropriate segmentation based on the allocation size), one or more w-HL PDUs from the CP retransmission buffer or segmentation thereof (eg, one or more processors 510 may perform appropriate segmentation based on the allocation size). re-segmentation), and/or one or more of user plane (UP) data from the UP Tx buffer and/or the UP retransmission buffer. Each of the BSR, PHR, CP Retransmission Buffer, CP Tx Buffer, UP Retransmission Buffer, and UP Tx Buffer may have an associated priority that, in some aspects, may follow (BSR, PHR, CP The order of retransmission buffers, CP Tx buffers, etc.) gives them priority. The one or more processors 510 may include the BSR and/or the PHR based on the one or more processors 510 determining that the BSR/PHR is included (eg, based on the current BSR/PHR status, receiving a trigger/request to provide the BSR/PHT, etc.) ). For an allocation size sufficient to multiplex multiple items in a w-HL C-PDU, one or more processors 510 may perform such multiplexing based on relative priorities. In some aspects, one or more processors 510 may add padding to the w-HL C-PDU to match the size of the w-HL C-PDU to the allocation size.

One or more processors 510 may add a w-HL packet header to a w-HL C-PDU generated as described herein, which may include an indication w, depending on the data content of the w-HL C-PDU. - One or more subheaders for the content of the HL C-PDU.

The one or more processors 510 may pass the w-HL C-PDU with the header to the PHY for transmission by the transceiver circuit 520 via the PRA.

One or more processors 510 may employ a two-level retransmission mechanism associated with w-HL C-PDUs.

The one or more processors 510 may employ a HARQ (Hybrid Automatic Repeat Request) mechanism at the physical layer TB level, which may include the one or more processors 510 processing responses to the W-HL C-PDUs transmitted via the PHYs. HARQ ACK feedback (eg, ACK (acknowledgement) or NACK (negative acknowledgement)) received via the transceiver circuit 520 instead of the TB. In response to the NACK, the one or more processors 510 may resend the TB one or more times unless the HARQ retransmission limit is reached.

The one or more processors 510 may also employ an ARQ (Automatic Repeat Request) mechanism at the w-HL C-PDU level, which may include the one or more processors 510 processing responses to w-HL C-PDUs via the PHY Instead, ARQ ACK feedback (eg, ACK (acknowledgement) or NACK (negative acknowledgement)) is received via transceiver 520 . In response to the NACK, the one or more processors 510 may pass the w-HL C-PDU to the PHY for retransmission one or more times (eg, which may include resegmentation, etc.) unless the ARQ retransmission limit has been reached. The one or more processors 510 may re-determine the PRA and allocation size for the w-HL C-PDU (eg, based on a new UL grant, etc.) upon reprocessing the w-HL C-PDU to be delivered to the PHY. Depending on the allocation size for the w-HL C-PDU, this may include one or more processors 510 combining the CP data of the w-HL C-PDU with other data (eg, BSR, PHR, other CP data, or fragments thereof) , UP data, etc.) multiplexing and/or one or more processors 510 re-segment the w-HL C-PDU.

In terms of w-HL Rx, one or more processors 510 may implement one or more functions associated with a w-HL Rx entity (eg, at the nUE or wUE). For example, one or more processors 510 may generate HARQACK feedback (eg, ACK) that may be sent by transceiver 520 in response to TBs related to one or more w-HLC-PDUs being successfully or unsuccessfully received by transceiver 520 /NACK, etc.). One or more processors 510 may generate w-HL C-PDUs based on the TBs received by transceiver 520 . The one or more processors 510 may also generate ARQ ACK feedback (eg, ACK/NACK) that may be sent by the transceiver circuit 520 in response to the w-HL C-PDU being successfully or unsuccessfully reconstructed by the one or more processors 510. Wait). On the nUE side, the one or more processors 510 may generate (and the transceiver circuitry 520 may transmit) an UL grant indicating the PRA and allocation size via which the w-HLC-PDU is received.

The one or more processors 510 may provide the generated w-HL C-PDUs from the PHY to the w-HL for higher layer processing by the one or more processors 510. As discussed herein, each w-HL C-PDU may include one or more of a BSR, a PHR, one or more CP packets and/or fragments thereof, or one or more UP packets and/or fragments thereof, or many. For a multiplexed w-HL C-PDU including two or more kinds of data, the header of the w-HL C-PDU may include two or more subheaders, which may indicate Information associated with the data.

From the w-HL C-PDU, one or more processors 510 may generate one or more w-HL C-SDUs (eg, w-RRC CP packets). Based on the header of the w-HL C-PDU and the SN indicated therein, the one or more processors 510 may determine the ordering of the C-SDUs (RRC CP packets) and deliver the C-SDUs (w-RRC CP packets) in order to w-RRC layer.

Referring to FIG. 6, a flowchart of a method 600 of generating a w-HL C-PDU from one or more w-RRC CP packets in accordance with the aid of various aspects described herein is shown. In some aspects, method 600 may be performed at a UE. In other aspects, a machine-readable medium can store instructions associated with method 600 that, when executed, can cause a UE (eg, nUE or wUE) to perform the actions of method 600 .

At 610, one or more w-HL C-SDUs may be received from the w-RRC layer.

At 620, a unique SN can be assigned to each w-HL C-SDU of the one or more w-HL C-SDUs.

At 630, one or more w-HL C-SDUs may be stored in a UL CP Tx buffer.

At 640, one or more PRAs and allocation sizes for transmitting one or more w-HL C-PDUs can be determined.

At 650, one or more w-HL C-PDUs can be generated based at least in part on the PRA and the allocation size. The w-HL C-PDU may include one or more of BSR, PHR, UL CP Tx buffer, UL CP retransmission buffer, UL UP Tx buffer, or UL UP retransmission buffer.

At 660, the w-HL C-PDU can be delivered to the PHY.

At 670, the w-HL C-PDU may be sent via one or more TBs.

Additionally or alternatively, method 600 may include one or more other actions performed by the w-HL Tx entity described above in connection with system 500 .

Referring to FIG. 7, a flowchart is shown of a method 700 for generating one or more w-RRC CP packets from one or more received TBs and delivering the packets in sequence with the aid of various aspects described herein. In some aspects, method 700 can be performed at a UE. In other aspects, a machine-readable medium can store instructions associated with method 700 that, when executed, can cause a UE (eg, nUE or wUE) to perform the actions of method 700 .

At 710, one or more TBs carrying w-RRC CP packet data can be received.

At 720, one or more w-HL C-PDUs can be generated from the one or more TBs.

At 730, one or more w-HL C-PDUs may be passed to w-HL for further processing.

At 740, one or more w-HL C-SDUs (eg, w-RRCCP packets) can be generated from one or more w-HL C-PDUs.

At 750, based on the SN of the header of each of the one or more w-HL C-PDUs, an ordering of the one or more w-HL C-SDUs may be determined.

At 760, one or more w-HL C-SDUs may be delivered to the w-RRC layer in sequence.

Additionally or alternatively, method 700 may include one or more other actions performed by the w-HL Rx entity described above in connection with system 500 .

Control plane packet processing at w-HL

The following details may be used for packet processing and header addition of control plane data with respect to w-HL as described herein.

When w-HL receives a packet from a higher layer (w-RRC), the packet becomes a CP w-HL SDU (Service Data Unit) for the w-HL protocol layer.

A sequence number (SN) can be added to each w-HL CP SDU (to save header overhead, which can omit the SN of each w-HLC-PDU). Each CP SDU can be encrypted (encrypted/decrypted) and/or integrity protected, and the SDU SN can be used for these operations, so a Sequence Number (SN) can be added to each w-HL SDU.

The CP SDU may be stored in a different buffer than the UP SDU. Therefore, the sequence number assignments for CP and UP can be independent of each other. That is, the SN need not be unique between the CP SDU and the UP SDU. However, the CP SDU SN may be unique among the SNs assigned to the CPSDU to avoid errors. In addition, the SN of the CP SDU does not need to be the same length as the SN of the UP SDU.

If the w-RRC enables integrity protection, the w-HL may perform integrity protection operations on the CP SDU. In addition, the w-HL CP SDU can skip the integrity protection operation. The integrity protection operation increases the size of the w-HL SDU by adding some integrity check bytes.

If encryption is enabled, the w-HL CP SDU may undergo encryption operations that add security to air interface transmissions. Encryption does not change the size of the w-HL CP SDU.

A w-HL CP SDU (possibly a modified CPSDU if integrity protection and/or ciphering operations are performed) may be placed in the UL CP transmit buffer with its assigned SN. Note that the w-HL header may be added when the w-HL C-PDU is generated in response to a request from the PHY layer. In the aspect employed at the wUE, the PHY may request a w-HL PDU if there is a UL grant received on the controlling PRA.

In the aspect employed at the wUE, the buffering of the w-HL SDUs in the UL CP transmit buffer may trigger the sending of a scheduling request to the nUE to request a UL grant on the controlling PRA.

Once the UL grant for transmission on the control PRA is received at the PHY, the PHY may pass the UL grant to the w-HL requesting a w-HL C-PDU for transmission on the control PRA. A w-HL C-PDU of size equal to the PHY transport block (TB) size (eg, the size of the received UL grant) may then be generated.

w-HL may generate w-HL C-PDUs, which may include multiplexing BSRs, PHRs, w-HL CP SDUs buffered in UL CP Tx buffers (and/or UL CP ARQ retransmission buffers), and w-HL UP SDUs buffered in the UL UP Tx buffer (and/or the UL UPARQ retransmission buffer). Based on the grant size, w-HL may do one or more of the following: segment SDUs from UL CP/UP Tx buffers; UP PDU is re-segmented; combined with one or more SDU segments; combined with one or more SDUs; and/or combined with 0 or 1 BSR, 0 or 1 PHR, or 0 or more re-drops , 0 or more CP/UP segments, and 0 or more CP/UP SDUs.

The w-HL can then add packet headers to create the w-HL C-PDU for controlling the PRA. As used herein, a w-HL PDU for controlling a PRA may also be referred to as a w-HL C-PDU or w-HL CP PDU. Examples of packet header additions and their details are discussed in more detail below. The w-HL may store a copy of the w-HL C-PDU in the UL CP ARQ retransmission buffer. The w-HL may pass the w-HL C-PDU to the PHY for transmission on the controlling PRA.

The PHY may send the w-HL C-PDU one or more times until (a) the w-HL C-PDU is successfully received at the nUE/wUE or (b) the maximum HARQ retransmission limit is reached.

If the intended receiver (nUE/wUE) cannot successfully receive the w-HLC-PDU in the maximum number of HARQ retransmission attempts, the w-HL may invoke the ARQ retransmission procedure.

During ARQ retransmission, the original w-HL C-PDU can be re-segmented if the grant size is smaller, or the original w-HL C-PDU can be re-segmented with other segments/SDUs if the grant size is larger combine.

For each ARQ retransmission, the PHY may attempt up to the maximum number of ARQ retransmissions to deliver the C-PDU.

After the maximum number of ARQ retransmission attempts, if the C-PDU is not successfully received at the nUE/wUE, the w-HL may discard the relevant SDU and may notify higher layers (protocol layers above the w-HL of this) , for example, w-RRC).

Below are details of packet header additions that can be employed at the w-HL layer when creating a w-HL PDU.

High Layer (w-HL) Packet Header Design and Optimization for Control Plane Data

Packet header design features for control plane at w-HL

For w-HL UP data, a 10-bit sequence number (SN) may be assigned to each w-HL SDU of UP data such as IP data. The 10-bit SN can accommodate 1024 UP SDUs in the UL UP Tx buffer.

CP SDU is generated by w-RRC. It is unlikely that there will be more than 128 w-RRC messages or control plane messages (ie, w-HL CP SDUs) waiting to be transmitted in the UL CP Tx buffer at any one time. Therefore, in order to reduce the packet header size, a 7-bit Control Plane Sequence Number (C-SN) can be assigned to the CP SDU. In addition, adding an SN to each w-HL C-PDU can also be omitted to reduce packet header overhead. Typically, ciphering and/or integrity protection (when performed) is performed for each CP SDU and the CP SDU SN is used for this operation, so a Control Sequence Number (C-SN) may be added to each w-HL CP SDU.

If retransmission at the w-HL level is employed (eg, if w-HL ARQ is enabled), then each w-HL C-PDU may be retransmitted. In the absence of an SN for each w-HL PDU, the tag (unique ID) described here can be used to identify each C-PDU, so that the w-HL Rx (receiving) entity can During retransmission, the C-PDU identification tag (unique ID) is sent to the w-HL Tx (transmitting) entity. For each case of w-HL C-PDUs discussed below, a flag can be provided that can be used to identify each C-PDU. In general, SDU C-SN (or SN) or SDU C-SN (or SN) plus segment ID can be used as a tag/ID to uniquely identify any w-HL C-PDU as described below.

As mentioned earlier, the L1/PHY transport block can be limited to tens of bytes (less than 75 bytes) due to the contention-based transport environment on the Xu-a interface. A smaller L1 TB size can help reduce the performance impact from potential conflicts. Table 1 below shows example L1/PHY TB size ranges. In the example of Table 1, the maximum C-PDU (or UP PDU) size is approximately 600 bits (75 bytes) and the minimum C-PDU (or UP PDU) size is 176 bits (22 bytes). The example of Table 1 is used in the following discussion, although other sizes and corresponding changes in various details may be employed.

Table 1: Examples showing TB size ranges for 5G-W

TB size (bits) TB size (bytes) minimum 176 twenty two maximum 600 75

Length Indicator (L1): Indicates the length (in bytes) of up to 75 bytes, the length indicator (L1) = 7 bits can be used. 7 bits are sufficient to specify a length of up to 127 (2 ⁷ -1) bytes.

Number of bits representing the segment of the SDU: The number of bits representing the segment of the CP SDU depends on the maximum size of the SDU that can be received at the w-HL. Maximum PDCP SDU size supported by legacy LTE = 8188 bytes. However, in wearable communications, most control message packet sizes are much smaller than 8188 bytes. Typically, the control plane message size will be less than or equal to 1500 bytes. Based on these two possible maximum SDU sizes, the segment ID can be designed. For the user plane data size, it can be considered that there are two maximum packet size options of 8188 bytes and 1500 bytes.

There are two ways to represent a segment: (i) Specify the start/end bytes of the segment in the SDU, either via 13 bits (for maximum SDU size = 8188 bytes) or 11 bits (for maximum SDU size = 1500 words) section); and/or (ii) specify the segment number, which can be specified via 9 bits (for maximum segment #=8188/22=373) or 7 bits (for maximum segment #=1500/22=69) specified. Therefore, specifying the segment number as the segment ID is more efficient because the segment number uses a smaller number of bits. However, this adds some processing complexity to the sender/entity's w-HL layer. The w-HL layer sender/entity may locally record the segment start/end bytes for each segment.

Higher priority for retransmissions: Retransmissions can have higher priority than new transmissions. Therefore, the re-segmented data may be the first data segment/field if the UL grant is available in the TTI (transmission time interval) where HARQ/ARQ retransmission is expected.

Separation of PRAs for Control Data: As discussed herein, one or more PRAs may be explicitly or implicitly designated as control PRAs. In some aspects, control data may be sent only on these PRAs. If PHR/BSR transmission is triggered and/or should be sent based on these values, the PHR and BSR may be loaded in the wHL-PDU on the control PRA. In addition, if there are resources remaining after completing the CP data, the user plane data may be included in the wHL-PDU for controlling the PRA. A 1-bit flag (eg, PDU type) may identify a wHL PDU for control PRA or a wHL PDU for UP PRA.

Multiplexing of BSR, PHR, CP data, and UP data in C-PDUs: Since BSR, PHR, CP data, and/or UP data can be multiplexed for C-PDUs, handling multiplexing can be included in the header field (for example, field type).

Packet header optimization in case of re-segmentation of w-HL C-PDU during ARQ retransmission

During ARQ retransmission, if the base station provides a grant equal to the wHL C-PDU (previous TB size) on the control PRA, no resegmentation is required. However, the grant may have a smaller size, in which case the C-PDU (original C-PDU) in the retransmission buffer may be re-segmented. When the original C-PDU is re-segmented, an ID can be assigned to each of its re-segmented segments to help the w-HL RX entity recreate the original C-PDU and request the missing one or more re-segmented Fragmented retransmission. If some of the re-dropped segments of the original C-PDU are lost, only the lost re-dropped segments may be resent. During retransmission of a re-split segment, it may potentially be segmented again to be eligible for retransmission grants (which may be referred to herein as second-level re-segmentation). In some of these aspects, there may be multiple levels of resegmentation. For w-HL Tx and Rx entities, potential difficulties arise in managing multi-level re-segmented IDs and caching multi-level re-segmented data.

To simplify processing (at the w-HL Rx/Tx entity) and save buffering for ARQ retransmissions, in various aspects, only the original w-HL C-PDUs may be stored/buffered in the CP retransmission buffer. If re-segmentation of the original C-PDU (in the CP retransmission buffer) is performed due to a smaller grant size, the retransmission packet header can be added in such a way that each segment (of the re-segmentation) can be Uniquely identified and can be reconstructed from the original w-HL C-PDU (if the (re-segmented) segment is to be retransmitted).

In our design, w-HL C-PDUs (as well as UP PDUs) have a maximum size of up to 75 bytes. For re-segmentation of w-HL C-PDUs during ARQ retransmission, it is sufficient to specify the start offset in bytes of the re-segmented segment since it only requires 7 bits. Thus, a (re-segmented) segment can be identified via the ID used to identify the original C-PDU and the starting offset in bytes in the original C-PDU, as described below. To make decoding at the w-HL Rx entity simpler, a flag indicating whether it is the last segment may also be included.

C-Rseg-SO (7 bits): The resegmentation start offset may specify the original C-PDU (original header (eg, excluding leading padding, BSR, and PHR subheaders) + original data field) for this re-segmentation The start byte of the dropped segment, which may be the start byte number in the original C-PDU carried in the re-dropped segment when resegmentation is performed during ARQ retransmission of the C-PDU. For retransmission, the entire C-PDU (eg, original header + original data fields except the beginning padding, BSR, and PHR subheaders) excluding the leading padding, BSR, and PHR subheaders can be considered as a designated resection The data of the starting offset of the outgoing segment. For an example maximum C-PDU size of 600 bits (75 bytes), 7 bits (covering a length of up to 128 bytes) are sufficient to represent the start offset in the original C-PDU.

C-Rseg-SN (10 bits): During retransmission, each original C-PDU can be identified so that a C-PDU identification tag (PDU-ID) can be used when it is re-segmented. The C-PDU identification tag (PDU ID) is discussed in the various use cases below. In various scenarios, the C-PDU identification (PDU ID) can be based only on the SDU C-SN (or UP SDU SN) (7 bits or 10 bits), or based on the SDU C-SN (or UP SDU SN) and from the original Segment number (14 or 19 bits) of the C-PDU. If resegmentation is employed, the Reseg C-PDU tag ID may be defined as the control plane resegmentation sequence number (C-Rseg-SN) to be sent in the header during ARQ retransmission of the C-PDU (eg, 3 bits). The w-HL Tx entity may maintain, at least temporarily, a mapping table of C-Rseg-SNs to original C-PDU identification labels (PDU IDs), so that the w-HL Tx entity may create the remaining re-divided segments for later use license. Note that the w-HL Tx does not need to exchange this mapping table information with the w-HL Rx party. After collecting all the re-divided segments of the C-Rseg-SN, the Rx side can extract the original packet, so the mapping table information is not necessary. The original packet may have original header (excluding leading padding, BSR, and PHR subheaders) and original data fields. Therefore, the Rx side can obtain the SN or SN plus Seg-N from the original header.

A 1-bit C-Rseg-SN can be employed for controlling PRA ARQ retransmissions since each wUE has only one TB per TTI and retransmissions have higher priority. However, a 3-bit C-Rseg-SN can be defined so that the w-HL receiving entity can avoid sending ARQ ACK for each C-PDU. Therefore, the w-HL receiving entity may have the flexibility to receive 8 C-PDUs (due to the 3-bit C-RSeg-SN) and may send cumulative ACKs to reduce ARQ ACK overhead. Alternatively, the w-HL sending entity may send up to 8 C-PDUs without getting an ARQ ACK. Instead of C-RSeg-SN, C-PDU-SN (SN per PDU) can be used. However, by using only the C-RSeg-SN for retransmission, 3 bits can be saved in the first transmission of each C-PDU.

In the following, the packet header design of the CP data for each case and the C-PDU identification tag (C-PDU ID) that can be used for each case are discussed.

Control plane packet header design for w-HL data processing:

Various fields of the packet header

In various aspects, the following fields may be included in the packet header design of the w-HL PDU that may effectively allow for the fragmentation and cascade. User plane data transmissions related to packet headers may differ from the data transmissions discussed below. Table 2 below provides a brief description of several packet header fields that may be included in various aspects:

Table 2: Brief description of the main packet header fields proposed for w-HL C-PDUs and their descriptions.

Length Indicator: Whenever there is more than one SDU/SDU segment/C-PDU re-divided segment in the w-HL field, the corresponding subheader fields for all data fields except the last data field may have a length indicator field. When the last data field can also have a length field, there is a case (called tail padding) as described below.

The process of resizing a w-HL C-PDU to match the size of the assigned license

When PHY/L1 instructs to provide a C-PDU with a certain size, w-HL can ensure that it provides L1 with a w-HL C-PDU of exactly the same size as that indicated by L1. It can be assumed that the L1 transport block size (ie, the grant size indicated by L1 for w-HL C-PDU generation) is byte aligned. As described below, padding can be used to match the size of the w-HL to the license size.

Padding: In some cases, when preparing a w-HL C-PDU, after including more than 0 SDU/SDU segments/C-PDU repartitioned segments, some bytes (eg, 0, 1) of the grant , 2, 3, or 4 bytes, etc.) may remain. The remaining permissions may not be sufficient to include the new subheader and corresponding data field of at least one byte. In another case, there is not enough data to fill the license, and a relatively large padding (several bytes, eg, more than 4 bytes) can be used to fill the license. In these cases, padding may be added as described in the example octets shown in Figures 8A, 8B, and 8C and in the following cases.

In the first case, referring to Figure 8A, it is shown that when the remaining grant has only one byte, it may be added at the beginning of the w-HL C-PDU header to include the w-HL C - Example of a padding subheader where the PDU size exactly matches the grant size. In the first case, only one byte of UL grant remains, and a 1-byte padding subheader can be added at the beginning as shown in the example of Figure 8A. In the first case, the L1 field may be omitted for the subheader of the last SDU/SDU segment/C-PDU re-divided segment since it is still the last data field. Padding headers may be identified by different field types (eg, field type=111, etc.). When the receiver (w-HL Rx entity) finds the padding subheader at the beginning of the C-PDU header during decoding, it can simply ignore the padding subheader as if the bytes of the padding subheader were not present.

In the second case, referring to FIG. 8B, it is shown that when the remaining grant has only two bytes, it can be added at the beginning of the w-HL C-PDU header to convert the w-HL Example of a padding subheader with a C-PDU size that exactly matches the grant size. In the second case, only two bytes of permission remain, and two one-byte padding subheaders may be added to the two bytes at the beginning, see Figure 8B. In the second case, the L1 field may be omitted for the subheader of the last SDU/SDU segment/C-PDU re-divided segment since it is still the last data field. Padding headers may be identified by different field types (eg, field type=111). The receiver (w-HL Rx entity) can simply ignore the padding subheader at the beginning of the C-PDU header during decoding as if these two bytes were not present.

In a third case, referring to FIG. 8C, it is shown that a 0 may be added at the end of the w-HL C-PDU header such that a 0 is inserted at the end of the w-HL-PDU (data field) in accordance with aspects described herein more than 10 bytes of padding data field, thereby allowing the w-HL C-PDU size to be exactly matched to an example of a permitted-sized padding subheader. In the third case, a license of three or more bytes may remain. In the third case, there are enough grants in the subheader of the last SDU/SDU fragment/C-PDU re-divided fragment (as in the subheader of the w-HL C-PDU constructed before padding) Add L1 field and add padding subheader at the end. The padding subheader at the end (as shown in Figure 8C) may indicate that after the last SDU/SDU fragment/C-PDU re-divided segment data field (for which there is an L1), the remaining grants may be filled with padding . The padding data field in this case may include 0 or more bytes. The receiver (W-HL Rx entity) can simply ignore the remainder (eg padding) after the last SDU/SDU segment/C-PDU re-split segment when decoding.

Priority manipulation during multiplexing for creating C-PDUs for transmission on the control PRA

An example set of priorities for creating a w-HL C-PDU is as follows. The BSR and PHR may have the highest priority, and the BSR and PHR may be followed by C-PDUs in the CP retransmission buffer. The CP data in the CP Tx buffer may have the next highest priority. CP data may have higher priority than UP data when creating C-PDUs to be sent on the controlling PRA. UP data may be included in the C-PDU only if there is no more CP data to be sent. Grants remaining after placing the BSR and PHR (when included) can be used for ARQ retransmission of C-PDUs in the CP retransmission buffer. If there is a license remaining, the license can then be populated with CP data. If there is still a license remaining after placing the CP data, the UP data may be placed in the C-PDU.

According to this example, the priorities of various data in descending order may be as follows: (1) the BSR field may have the first (highest) priority included in the C-PDU; (2) the PHR field may have the second priority (3) C-PDUs waiting for retransmission in the ARQ retransmission buffer may have a third priority; (4) CP data may have a fourth priority; (5) UP data may have a fifth (lowest) priority .

Buffer Status Report (BSR) and Power Headroom Report (PHR)

The BSR can provide the nUE with an estimate of the UL data in the wUE's buffer so that the nUE can allocate a reasonable UL grant to the wUE. In one example, 5 bits (providing 32 possible BSR indices) may be used to specify the buffer size range. Table 3 below shows an example of the mapping of BSR index to buffer size (in bytes). In Table 3, the buffer size represents the total data in the buffers (eg, user plane transmit buffer and control plane transmit buffer) at the wUE.

Table 3: Buffer size classes for BSR

The PHR may be sent by the wUE to inform the nUE whether the wUE can transmit with a higher transmission power than the current transmission uses. PHR can be positive or negative. A positive PHR indicates that the wUE is not transmitting at the maximum allowed transmit power, so it can still transmit at higher Tx power or it can still transmit at higher throughput. If the PHR is negative, the wUE is already transmitting at the maximum allowed Tx power. The PHR information can be used by the nUE to determine whether to allocate more or less UL grants to the wUE. For example, in the case of positive PHR, the nUE may allocate more PRA/resources to the wUE.

In one example, 5 bits (equivalent to 32 PH indices) are used to specify the power headroom (PH). These 32 pH levels/indexes can be mapped to measured pH values. Table 4 below presents an example of the PH level and its mapping to the measured magnitude assuming that the maximum transmit power of the wUE is 20 dBm. The range of measured magnitudes represented by each power headroom index may vary according to the allowable PRA (Physical Resource Allocation) granularity.

Table 4: Example of mapping showing power headroom levels and power headroom reports

PH Power headroom level/reported value Quantitative value measured 0 PH_0 -23<=PH<-21 1 PH_1 -21<=PH<-19 2 PH_2 -19<=PH<-17 3 PH_3 -17<=PH<-15 ... ... ... 28 PH_28 33<=PH<35 29 PH_29 35<=PH<37 30 PH_30 37<=PH<39 31 PH_31 PH>=39

Various example cases for w-HL header generation

Show padding, BSR, PHR, and CP from uplink control plane transmit buffer w-HL C- of SDU Examples of various cases of PDU headers

Referring to Figure 9A, an example of a C-PDU including only CP SDUs from the UL CP transmit buffer is shown. It does not have a BSR or PHR, which can be indicated via the field type (eg, field type=011). PDU Type may here be 1 to indicate that the PDU is a C-PDU to be sent on the Controlling PRA. Content-Type=0011 may indicate that this field has a CP SDU. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in FIG. 9A can be uniquely identified by the C-SN field.

Referring to Figure 9B, an example of a C-PDU including a BSR and a CP SDU from the UL CP transmit buffer is shown. Field Type=000 may indicate that the PDU has a BSR field. The w-HL receiving (Rx) entity may know that the BSR has a fixed size (eg, 5 bits), and after the BSR, the data field starts as indicated by E=1. E=1 may indicate the presence of the next field. The type of the data field (the CP-SDU is not fragmented) can be identified by the content-type field=0011. C-PDU ID for retransmission (C-PDU identification tag): The C-PDU in FIG. 9B can be uniquely identified by the C-SN field.

Referring to FIG. 10A, an example of a C-PDU including a PHR and a CP SDU from a UL CP transmit buffer is shown. Field Type=001 may indicate that the PDU has a PHR field. The w-HL receiving entity may know that the PHR has a fixed size of 5 bits and the data field starts as indicated by E=1 after the PHR. E=1 may indicate the presence of the next field. The type of the data field (the CP-SDU is not fragmented) can be identified by the content-type field=0011. C-PDU ID for retransmission (C-PDU identification tag): The C-PDU in FIG. 10A can be uniquely identified by the C-SN field.

Referring to Figure 10B, an example of a C-PDU including BSR, PHR, and CP SDU from the UL CP transmit buffer is shown. Field Type=010 may indicate that the PDU has a BSR followed by a PHR field. The w-HL receiving entity may know that the 5-bit BSR field is followed by the 5-bit PHR field. After the BSR and PHR fields, the data field may begin as indicated by E=1. E=1 may indicate the presence of the next field. The type of data field (CP SDU - not fragmented) can be identified by the content type field 0011. C-PDU ID for retransmission (C-PDU identification tag): The C-PDU in FIG. 10B can be uniquely identified by the C-SN field.

Referring to FIG. 11, an example of a C-PDU similar to that of FIG. 10B is shown. However, a 1-byte padding subheader may be added to the beginning of the PDU to pad the grant. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in FIG. 11 can be uniquely identified by the C-SN field.

Referring to Figure 12, an example of a C-PDU similar to that of Figure 10B is shown. However, grants may be padded with two one-byte padding subheaders at the beginning of the PDU. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in Figure 12 can be uniquely identified by the C-SN field.

Referring to Figure 13, an example of a C-PDU similar to Figure 10B is shown. However, it has a padding subheader at the end that fills the remaining licenses. A length indicator field can be added to specify the length of the CP-SDU field so that the w-HL receiving entity can ignore all remaining bytes after obtaining the CP-SDU. C-PDU ID (C-PDU Identification Tag): The C-PDU in Figure 13 can be uniquely identified by the C-SN field.

Example showing BSR, PHR, and w-HL C-PDU header from CP SDU segment for UL CP transmission

When a CP SDU is segmented, each segment may have a segment number (C-Seg-N) and the SN of the SDU. Referring to Figure 14, an example of a w-HL C-PDU with BSR, PHR, and CP-SDU segment from the UL CP Tx buffer (which is not the last segment of the SDU) is shown. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in Figure 14 can be uniquely identified by the C-SN and C-Seg-N fields.

Referring to Figure 15, an example of a w-HL C-PDU with BSR, PHR, and CP-SDU segment from the UL CP TX buffer (which is the last segment of the SDU) is shown. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in Figure 15 can be uniquely identified by the C-SN and C-Seg-N fields.

Diagram showing BSR, PHR, UP SDU from UL UP transmission and/or w-HL C-PDU header of UP SDU segment example

As discussed above, CP data may have higher priority than UP data when creating C-PDUs to be sent. In such an aspect, UP data may be included in a C-PDU only if there is no more CP data to send. Therefore, the grants remaining after placing the BSR and PHR can be used for ARQ retransmission of C-PDUs in the retransmission buffer. If licenses remain, the licenses can then be filled with CP data. If there is still a license remaining after placing the CP data, the UP data may be placed in the C-PDU.

The following example represents the situation when there is no data in the CP transmit buffer or CP ARQ retransmission buffer.

Referring to Figure 16A, an example of a w-HLC-PDU with BSR, PHR, and UP-SDU from the UL user plane Tx buffer is shown. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in FIG. 16A can be uniquely identified by the SN field.

Referring to Figure 16B, an example of a w-HL C-PDU with BSR, PHR, and UP-SDU segment from the UL user plane TX buffer (which is not the last segment of the SDU) is shown. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in FIG. 16B can be uniquely identified by the SN and Seg-N fields.

Referring to Figure 17A, an example of a w-HL C-PDU with BSR, PHR, and UP-SDU segment (last segment of the SDU) from the UL user plane TX buffer is shown. C-PDU ID (C-PDU Identification Flag) for retransmission: The C-PDU in FIG. 17A can be uniquely identified by the SN and Seg-N fields.

Illustration showing BSR, PHR, C-PDU from UL CP retransmission buffer or w-HL C-PDU header of C-PDU segment example

As discussed above, if there is control plane data in the retransmission buffer waiting to be retransmitted, these data may have higher priority than CP data and UP data in the transmit buffer. Since the grant may be smaller than the w-HL C-PDU, the w-HL C-PDU may be re-segmented during retransmission. In some aspects, the w-HL C-PDU is not segmented during retransmissions when it is possible to include the entire w-HL C-PDU in the grant.

Referring to Figure 17B, an example of ARQ retransmission of w-HL C-PDUs with BSR, PHR, and C-PDUs (not re-segmented) from the UL ARQ control plane retransmission buffer is shown.

Referring to Figure 18A, a w-HL C-PDU with BSR, PHR, and C-PDU segment from the UL ARQ control plane retransmission buffer (not the last segment of the re-segmented C-PDU) is shown An example of ARQ retransmission. Resegmentation of w-HL C-PDUs in the retransmission buffer may be performed due to smaller grants.

Referring to Figure 18B, a w-HL C-PDU segment with BSR, PHR, and C-PDU segment from the UL ARQ control plane retransmission buffer (last segment of the re-segmented C-PDU) is shown Example of ARQ retransmission of segments. Resegmentation of w-HL C-PDUs in the retransmission buffer may be performed due to smaller grants. Here, the segment is the last segment, but the license is not enough to hold any other data fields.

w-HL C-PDU header showing BSR, PHR, UP SDU, CP SDU, CP SDU fragment, and/or UP SDU fragment example of

Referring to Figure 19, an example of w-HL C-PDU with BSR, PHR, CP-SDU from UL control plane TX buffer, and UP-SDU from UL user plane TX buffer is shown.

Referring to Figure 20, there is shown a UP-SDU segment (not the last segment of the UP-SDU) with BSR, PHR, CP-SDU from UL control plane TX buffer, and UP-SDU from UL user plane TX buffer Example of w-HL CP PDU.

Referring to Figure 21, a w-HL with BSR, PHR, CP-SDU segment from UL control plane TX buffer (last segment of the SDU), and UP-SDU from UL user plane TX buffer is shown Example of CP PDU.

Referring to Figure 22, shown with BSR, PHR, CP-SDU segment from UL control plane TX buffer (last segment of the SDU), and UP-SDU segment from UL user plane Tx buffer (not An example of a w-HLCP PDU for the last segment of the SDU).

Show BSR, PHR, C-PDU, C-PDU segment, CP/UP SDU, and/or CP/UP w-HL C-PDU for SDU fragmentation Example of a header

Referring to Figure 23, a w-HL C-PDU with BSR, PHR, C-PDU from UL control plane retransmission buffer (not re-segmented), and UP-SDU from UL user plane TX buffer is shown Example of a PDU. In this example, there is only one C-PDU in the control plane retransmission buffer and no data in the control plane transmission buffer.

Referring to Figure 24, shown with BSR, PHR, C-PDU from UL control plane retransmission buffer (not re-segmented), and UP-SDU fragment from UL user plane TX buffer (not the last fragment) segment) of the w-HL C-PDU. In this example, there is only one C-PDU in the control plane retransmission buffer and no data in the control plane transmission buffer.

Referring to Figure 25, shown with BSR, PHR, C-PDU from UL control plane retransmission buffer (not re-segmented), CP SDU from UL control plane transmission buffer, and TX buffer from UL user plane Example of a w-HL C-PDU for a UP-SDU (not fragmented) of a server. In this example, there is only one C-PDU in the control plane retransmission buffer and only one CP SDU in the control plane transmission buffer.

Referring to Figure 26, shown with BSR, PHR, C-PDU segment from UL control plane retransmission buffer (last segment of the re-segmented C-PDU), and from UL control plane TX buffer Example of w-HL C-PDU for CP-SDU. In this example, there is only one C-PDU in the control plane retransmission buffer.

Referring to Figure 27, shown with BSR, PHR, C-PDU segment from UL control plane retransmission buffer (last segment of the re-segmented C-PDU), and from UL control plane TX buffer Example of a w-HL C-PDU of a CP-SDU segment (not the last segment). In this example, there is only one C-PDU in the control plane retransmission buffer.

Examples herein may include subject matter such as a method, an apparatus for performing the acts or blocks of a method, included in a supported machine (eg, a processor with memory, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) etc.) at least one machine-readable medium of executable instructions, when executed, cause the machine to perform the actions of the above-described methods or for the actions of an apparatus or system that communicates simultaneously using multiple communication technologies according to the embodiments and examples described herein.

Example 1 is an apparatus configured for use in a user equipment (UE), comprising: a memory; and one or more processors configured to: report to one from a wearable radio resource control (w-RRC) layer Assign a different sequence number to each CP packet in or multiple Control Plane (CP) packets; buffer one or more CP packets into the CP transmit buffer; determine use for Wearable High Layer (w-HL) Control Protocol Data Units (C-PDU) physical resource allocation (PRA) and allocation size; generate w-HL C-PDU based at least in part on one or more CP packets buffered to CP transmit buffer, PRA, and allocation size; HL C-PDU adds packet header; and provides w-HL C-PDU to physical layer based on PRA.

Example 2 includes the subject matter of any variation of Example 1, wherein the one or more processors are further configured to be based at least in part on a buffer status report (BSR), a power headroom report (PHR), a CP retransmission buffer, a user One or more of the plane (UP) transport buffers, or the UP transport buffers, generate the w-HL C-PDUs.

Example 3 includes the subject matter of any variation of Example 2, wherein the one or more processors are further configured to determine a CP transmit buffer, CP retransmission buffer, BSR, PHR, UP transmit buffer, and UP retransmission buffer A different priority for each of the .

Example 4 includes the subject matter of any variation of Example 3, wherein the one or more processors are further configured to: based at least in part on multiplexing a CP retransmission buffer, BSR, PHR, UP transmission buffer, or UP retransmission buffer and CP transmit buffer to generate w-HL C-PDUs, wherein the multiplexing is based at least in part on transmissions for CP transmit buffer, CP retransmission buffer, BSR, PHR, UP Different priorities determined by each of the buffers, and the UP retransmission buffers.

Example 5 includes the subject matter of any variation of any of Examples 2-4, wherein the one or more processors are further configured to: by segmenting the one or more CP packets buffered into the CP transmit buffer, segmenting one or more prior w-HL C-PDUs buffered to the CP retransmission buffer, or re-segmenting one or more previously generated segments to generate one or more segments, wherein, The w-HL C-PDU is generated based at least in part on the one or more segments described above.

Example 6 includes the subject matter of any variation of any of Examples 2-4, wherein the one or more processors are further configured to generate a w-HL based at least in part on combining two or more of the following C-PDU: One or more CP packets buffered to the CP transmit buffer, one or more previous w-HL C-PDUs buffered to the CP retransmission buffer, and one or more segments.

Example 7 includes the subject matter of any variation of any of Examples 2-4, wherein the one or more processors are further configured to make a determination as to whether at least one of a BSR or a PHR is indicated via the w-HL C-PDU , and wherein the w-HL C-PDU includes at least one of BSR or PHR when the above determination is a positive determination.

Example 8 includes the subject matter of any variation of examples 1-4, wherein the packet header includes two or more subheaders.

Example 9 includes the subject matter of any variation of any of Examples 1-4, wherein the one or more processors are further configured to resize the w-HL C-PDU via padding to match the allocation size.

Example 10 includes the subject matter of any variation of any of Examples 1-4, wherein the one or more processors are further configured to process at least one Hybrid Automatic Repeat Request (HARQ) ACK related to the w-HL C-PDU /NACK (Acknowledge/Nack) response, wherein the one or more processors are configured to employ a physical layer transport block (TB) level retransmission mechanism in response to at least one HARQ ACK/NACK response including a HARQ NACK.

Example 11 includes the subject matter of any variation of any of Examples 1-4, wherein the one or more processors are further configured to process at least one automatic repeat request (ARQ) ACK/ NACK (Acknowledgement/Nacknowledgment) responses, wherein the one or more processors are further configured to employ a w-HL C-PDU level retransmission mechanism in response to at least one ARQ ACK/NACK response including an ARQNACK.

Example 12 includes the subject matter of any variation of Example 11, wherein, in response to the at least one ARQ ACK/NACK response including an ARQ NACK, the one or more processors are further configured to: determine a new PRA for the w-HL C-PDU and a new allocation size; and based on the new allocation length, performing at least one of: re-segmenting the w-HL C-PDU, or combining the w-HL C-PDU with one or more buffers buffered in the CP transmit buffer At least one of the CP packets, one or more prior w-HL C-PDUs buffered to the CP retransmission buffer, or one or more segments in combination.

Example 13 includes the subject matter in any variation of any of Examples 1-4, wherein the UE is a wearable UE (w-UE), and wherein the one or more processors are configured based on an uplink (UL) grant Determine the PRA and allocation size.

Example 14 includes the subject matter of any variation of examples 1-4, wherein the UE is a network UE (n-UE).

Example 15 includes the subject matter of any variation of any of Examples 2-4, wherein the one or more processors are further configured to generate the one or more segments by processing one or more segments buffered to the CP transmit buffer or fragmentation of multiple CP packets, fragmentation of one or more previous w-HL C-PDUs buffered to the CP retransmission buffer, or re-segmentation of one or more previously generated fragments, where , the w-HL C-PDU is generated based at least in part on one or more segments.

Example 16 includes the subject matter of any variation of any of Examples 2 to 4 or 15, wherein the one or more processors are further configured to generate w- based at least in part on combining two or more of the following HL C-PDU: One or more CP packets buffered to the CP transmit buffer, one or more previous w-HL C-PDUs buffered to the CP retransmission buffer, or one or more segments.

Example 17 includes the subject matter in any variation of any of Examples 2-4 or 15-16, wherein the one or more processors are configured to make whether to indicate via the w-HL C-PDU at least one of a BSR or a PHR and wherein the w-HL C-PDU includes at least one of the BSR or the PHR when the above-mentioned determination is a positive determination.

Example 18 includes the subject matter of any variation of examples 1-4 or 15-16, wherein the packet header includes two or more subheaders.

Example 19 includes the subject matter in any variation of any of Examples 1-4 or 15-18, wherein the one or more processors are further configured to resize the w-HL C-PDU via padding to match the allocation size.

Example 20 includes any variation of any of examples 1-4 or 15-19, wherein the one or more processors are further configured to process at least one Hybrid Automatic Repeat Request (HARQ) related to the w-HL C-PDU ) ACK/NACK (acknowledge/negative) response, wherein the one or more processors are configured to employ a physical layer transport block (TB) level retransmission mechanism in response to at least one HARQ ACK/NACK response including a HARQ NACK.

Example 21 includes the subject matter of any variation of any of Examples 1-4 or 15-20, wherein the one or more processors are further configured to process at least one automatic repeat request ( ARQ) ACK/NACK (Acknowledge/Nack) response, wherein the one or more processors are further configured to employ a w-HL C-PDU level retransmission mechanism in response to at least one ARQ ACK/NACK response including an ARQ NACK.

Example 22 includes the subject matter of any variation of Example 21, wherein, in response to the at least one ARQ ACK/NACK response including an ARQ NACK, the one or more processors are further configured to: determine a new PRA for the w-HL C-PDU and the new allocation size; and based on the new allocation size, perform at least one of: re-segmenting the w-HL C-PDU, or in conjunction with one or more CP packets buffered to the CP transmit buffer, buffering to One or more preceding w-HL C-PDUs, or at least one of one or more segments, and w-HL C-PDUs of the CP retransmission buffer.

Example 23 is an apparatus configured for use in a user equipment (UE), comprising: a memory; and one or more processors configured to generate one or more physical layer transport blocks (TBs) from one or more physical layer transport blocks (TBs). Multiple Wearable High Layer (w-HL) Control Protocol Data Units (C-PDUs); provide one or more w-HL C-PDUs to w-HL; generate multiple w-HL C-PDUs from one or more w-HL C-PDUs w-HL Control Service Data Units (C-SDUs); determining an ordering of the plurality of w-HL SDUs based on a different sequence number (SN) associated with each w-HL SDU of the plurality of w-HL SDUs; and Multiple w-HL C-SDUs are delivered to the Wearable Radio Resource Control (w-RRC) layer based on the above ordering.

Example 24 includes the subject matter in any variation of Example 23, wherein the one or more processors are further configured to generate one or more Hybrid Automatic Repeat Request (HARQ) ACK/NACK ( acknowledge/deny) response.

Example 25 includes the subject matter of any variation of Example 23, wherein the one or more processors are further configured to generate one or more automatic repeat request (ARQ) ACK/ NACK (Acknowledgement/Negative) response.

Example 26 includes the subject matter of any variation of Example 23, wherein a first w-HL C-PDU of the one or more w-HL C-PDUs includes a first w-HL C of a plurality of w-HL C-SDUs - Fragmentation of SDU, second w-HLC-SDU of multiple w-HL C-SDUs, Buffer Status Report (BSR), Power Headroom Report (PHR), Fragmentation of first User Plane (UP) packet Multiplexing of two or more of the segments, or the second UP packet.

Example 27 includes the subject matter of any variation of Example 23, wherein a first w-HL C-PDU of the one or more w-HL C-PDUs includes a header that includes a plurality of subheaders.

Example 28 includes the subject matter of any variation of any of examples 23-27, wherein the UE is a wearable UE (w-UE).

Example 29 includes the subject matter of any variation of any of examples 23 to 27, wherein the UE is a network UE (n-UE), and wherein the one or more processors are configured to generate a configuration indicative of one or more physical resources One or more uplink (UL) grants (PRAs), where one or more physical layer TBs correspond to one or more PRAs.

Example 30 includes the subject matter in any variation of Example 29, wherein the one or more UL grants indicate a grant size corresponding to the size of the one or more w-HL C-PDUs.

Example 31 includes the subject matter of any variation of any of examples 23-24, wherein the one or more processors are further configured to generate one or more automatic retransmissions related to the one or more w-HL C-PDUs Request (ARQ) ACK/NACK (Acknowledgement/Negative) response.

Example 32 is a machine-readable medium comprising instructions that, when executed, cause a wearable user equipment (w-UE) to perform the process of: receiving one or more wearables from a wearable radio resource control (w-RRC) layer Higher Layer (w-HL) Control Service Data Unit (C-SDU); assigns a unique sequence number (SN) to each of one or more w-HL C-SDUs; assigns one or more w-HL C-SDUs SDUs are stored in an uplink (UL) control plane (CP) transmit buffer; receive a UL grant indicating a physical resource configuration (PRA) and grant size; generate a w-HL control protocol data unit (C) based at least in part on the UL grant -PDU), where w-HL C-PDU includes Buffer Status Report (BSR), Power Headroom Report (PHR), UL CP Transmission Buffer, UL CP Retransmission Buffer, UL User Plane (UP) Transmission Buffer one or more of the UL UP retransmission buffer; and passing the w-HL C-PDU to the physical layer.

Example 33 includes the subject matter of any variation of Example 32, wherein the w-HL C-PDU includes a BSR, PHR, UL CP based transmit buffer, UL CP retransmission buffer, UL UP transmit buffer, or UL UP retransmission buffer Multiplexing of two or more items in the device.

Example 34 includes the subject matter of any variation of any of Examples 32-33, wherein the instructions, when executed, further cause the UE to employ w-HL C-PDU level automatic repeat request (ARQ) ACK/NACK (acknowledgement) /Nack) retransmission mechanism and physical layer transport block (TB) level Hybrid ARQ (HARQ) ACK/NACK retransmission mechanism.

Example 35 includes the subject matter of any variation of any of Examples 32-33, wherein the w-HL C-PDU header includes a plurality of subheaders.

Example 36 is an apparatus configured for use in a user equipment, comprising: storage configured to store instructions; and processing configured to execute the instructions to perform processing from wearable radio resource control (w- RRC) layer receives one or more Wearable High Layer (w-HL) Control Service Data Units (C-SDUs); assigns a different sequence to each of the one or more w-HLC-SDUs number (SN); store one or more w-HL C-SDUs in an uplink (UL) control plane (CP) transmit buffer; receive a UL grant indicating physical resource allocation (PRA) and grant size; at least A w-HL Control Protocol Data Unit (C-PDU) is generated based in part on the UL grant, wherein the w-HL C-PDU includes a Buffer Status Report (BSR), a Power Headroom Report (PHR), a UL CP transmit buffer, one or more of a UL CP retransmission buffer, a UL user plane (UP) transmission buffer, or a UL UP retransmission buffer; and passing the w-HL C-PDU to the physical layer.

Example 37 includes the subject matter of any variation of Example 36, wherein the w-HL C-PDU includes a BSR, PHR, UL CP based transmit buffer, UL CP retransmission buffer, UL UP transmit buffer, or UL UP retransmission buffer Multiplexing of two or more items in the device.

Example 38 includes the subject matter of any variation of any of examples 36-37, wherein the processing component is further configured to execute instructions to employ automatic repeat request (ARQ) ACK/NACK (acknowledgement/ ACK) retransmission mechanism and physical layer transport block (TB) level Hybrid ARQ (HARQ) ACK/NACK retransmission mechanism.

Example 39 includes the subject matter of any variation of any of Examples 36-37, wherein the w-HL C-PDU header includes a plurality of subheaders.

The above description of illustrative embodiments of the subject disclosure, including the description in the Abstract, is not intended to limit the disclosed embodiments exclusively to the precise forms disclosed. Although specific embodiments and examples are described herein for illustrative purposes, various modifications are contemplated that are within the scope of these embodiments and examples, as those skilled in the relevant art will recognize.

While the disclosed subject matter has been described herein in conjunction with various embodiments and corresponding drawings, it is to be understood that other similar embodiments may be used or the described Embodiments make modifications and additions for performing the same, similar, alternative, or alternative functions. Therefore, the disclosed subject matter should not be limited to any single embodiment described herein, but rather should be construed in breadth and scope in accordance with the appended claims.

Particularly with respect to the various functions performed by the above-described components or structures (assemblies, devices, circuits, systems, etc.), the terms used to describe these components (including references to "components") are used to correspond to the performance of the specified functions of the described components. Any components or structures (ie, functionally equivalent), even if not structurally equivalent to the disclosed structures that perform the functions of the example embodiments shown herein. Additionally, although a particular feature is disclosed for only one of various embodiments, such feature may be combined with one or more other features of other embodiments as desired and advantageous for any given or particular application.

Claims (26)

1. An apparatus configured for use in user equipment UE, comprising: memory; and One or more processors, configured as: provide one or more control plane CP packets from the wearable radio resource control w-RRC layer to the wearable high layer w-HL; assigning a different sequence number to each of the one or more CP packets; buffering the one or more CP packets into a CP transmit buffer; determining the physical resource configuration PRA and allocation size for the w-HL control protocol data unit C-PDU; generating the w-HL C-PDU based at least in part on the one or more CP packets buffered to the CP transmit buffer, the PRA, and the allocation size; adding a packet header to the w-HL C-PDU; and The w-HL C-PDU is provided from the w-HL to the physical layer based on the PRA. 2. The apparatus of claim 1, wherein the one or more processors are further configured to be based at least in part on a buffer status report BSR, a power headroom report PHR, a CP retransmission buffer, a user plane UP One or more of the transmit buffer, or the UP retransmission buffer, generates the w-HL C-PDU. 3. The apparatus of claim 2, wherein the one or more processors are further configured to determine the CP transmission buffer, the CP retransmission buffer, the BSR, the PHR, the Different priorities for each of the UP transmission buffer, and the UP retransmission buffer. 4. The apparatus of claim 3, wherein the one or more processors are further configured to: based at least in part on multiplexing one or more of the CP retransmission buffer, the BSR, the PHR, the UP transmission buffer, or the UP retransmission buffer and the CP transmission buffer generator to generate the w-HL C-PDU, wherein the multiplexing is based, at least in part, on the transmission buffer for the CP, the CP retransmission buffer, the BSR, the PHR, the UP transmission buffer, and the UP retransmission buffer. Different priorities determined by each of the . 5. The apparatus of any one of claims 2 to 4, wherein the one or more processors are further configured to: By segmenting one or more CP packets buffered to the CP transmit buffer, segmenting one or more prior w-HL C-PDUs buffered to the CP retransmission buffer, or one or more previously generated segments are re-segmented to generate one or more segments, wherein the w-HL C-PDU is generated based at least in part on the one or more segments. 6. The apparatus of any one of claims 2 to 4, wherein the one or more processors are further configured to generate the result based at least in part on combining two or more of the following: The w-HL C-PDU: one or more CP packets buffered to the CP transmission buffer, one or more previous w-HL C-PDUs buffered to the CP retransmission buffer, and one or more multiple segments. 7. The apparatus of any one of claims 2 to 4, wherein the one or more processors are further configured to make whether to indicate via the w-HL C-PDU the BSR or the A determination of at least one of the PHRs, and wherein the w-HL C-PDU includes at least one of the BSR or the PHR when the determination is a positive determination. 8. The apparatus of any of claims 1 to 4, wherein the packet header includes two or more subheaders. 9. The apparatus of any one of claims 1 to 4, wherein the one or more processors are further configured to resize the w-HL C-PDU via padding to match the allocation size . 10. The apparatus of any one of claims 1 to 4, wherein the one or more processors are further configured to process at least one hybrid automatic repeat request related to the w-HL C-PDU HARQ ACK/NACK Acknowledgement/Nack response, wherein the one or more processors are configured to employ a physical layer transport block TB-level retransmission mechanism in response to the at least one HARQ ACK/NACK response including a HARQ NACK. 11. The apparatus of any one of claims 2 to 4, wherein the one or more processors are further configured to process at least one automatic repeat request ARQ related to the w-HL C-PDU ACK/NACK acknowledgement/negative response, wherein the one or more processors are further configured to employ a w-HL C-PDU level retransmission mechanism in response to the at least one ARQ ACK/NACK response including an ARQ NACK. 12. The apparatus of any one of claims 1 to 4, wherein the one or more processors are further configured to process at least one automatic repeat request ARQ related to the w-HL C-PDU ACK/NACK acknowledgement/negative response, wherein the one or more processors are further configured to employ a retransmission mechanism at the w-HL C-PDU level in response to the at least one ARQ ACK/NACK response including an ARQ NACK; as well as Wherein, in response to the at least one ARQ ACK/NACK response including an ARQ NACK, the one or more processors are further configured to: determining a new PRA and a new allocation size for the w-HL C-PDU; and Based on the new allocation size, perform at least one of: re-segmenting the w-HL C-PDU, or re-segmenting the w-HL C-PDU with a buffer cached in the CP transmit buffer A combination of at least one of one or more CP packets, one or more prior w-HL C-PDUs buffered to the CP retransmission buffer, or one or more segments. 13. The apparatus of any one of claims 1 to 4, wherein the UE is a wearable UE w-UE accessing the network NW via the assistance of other UEs, and wherein the one or more processors is configured to determine the PRA and the allocation size based on an uplink UL grant. 14. The apparatus of any of claims 1 to 4, wherein the UE is a network UE n-UE with a full infrastructure network NW access protocol stack. 15. An apparatus configured for use in user equipment UE, comprising: memory; and One or more processors, configured as: providing one or more wearable higher layer w-HL control protocol data units C-PDUs from one or more physical layer transport blocks TB to the w-HL; generating a plurality of w-HL control service data units C-SDUs from the one or more w-HL C-PDUs; determining an ordering of the plurality of w-HL SDUs based on a different sequence number SN associated with each w-HL C-SDU of the plurality of w-HL SDUs; and The plurality of w-HL C-SDUs are provided from the w-HL to the Wearable Radio Resource Control w-RRC layer based on the ordering. 16. The apparatus of claim 15, wherein the one or more processors are further configured to generate one or more Hybrid Automatic Repeat Request (HARQ ACK/ACK) related to the one or more physical layer TBs NACK acknowledgement/denial response. 17. The apparatus of claim 15, wherein the one or more processors are further configured to generate one or more automatic repeat request ARQs related to the one or more w-HL C-PDUs ACK/NACK acknowledgement/denial response. 18. The apparatus of claim 15, wherein a first w-HL C-PDU of the one or more w-HL C-PDUs comprises a first w-HL C-SDU of the plurality of w-HL C-SDUs Fragmentation of w-HL C-SDU, second w-HLC-SDU of the plurality of w-HL C-SDUs, buffer status report BSR, power headroom report PHR, fragmentation of first user plane UP packet Multiplexing of two or more of the segments, or the second UP packet. 19. The apparatus of claim 15, wherein a first w-HL C-PDU of the one or more w-HL C-PDUs includes a header including a plurality of subheaders. 20. The apparatus of any of claims 15 to 19, wherein the UE is a wearable UE w-UE accessing the network NW via the assistance of other UEs. 21. The apparatus of any one of claims 15 to 19, wherein the UE is a network UE n-UE with a full infrastructure network NW access protocol stack, and wherein the one or more processors is configured to generate one or more uplink UL grants indicating one or more physical resource configuration PRAs, wherein the one or more physical layer TBs correspond to the one or more PRAs. 22. The apparatus of claim 21, wherein the one or more UL grants indicate a grant size corresponding to a size of the one or more w-HL C-PDUs. 23. An apparatus configured for use in user equipment UE, comprising: means for storing, configured to store the instructions; and Means for processing, configured to execute the instructions to: provide one or more w-HL control service data units C-SDU from the wearable radio resource control w-RRC layer to the wearable higher layer w-HL; assigning a unique sequence number SN to each of the one or more w-HL C-SDUs; storing the one or more w-HL C-SDUs in an uplink UL control plane CP transmit buffer; receiving a UL grant indicating a physical resource configuration PRA and a grant size; generating a w-HL control protocol data unit C-PDU based at least in part on the UL grant, wherein the w-HL C-PDU includes a buffer status report BSR, a power headroom report PHR, a UL CP transmit buffer, a UL one or more of a CP retransmission buffer, a UL user plane CP transmission buffer, or a UL UP retransmission buffer; and The w-HL C-PDU is passed from the w-HL to the physical layer. 24. The apparatus of claim 23, wherein the w-HL C-PDU comprises a buffer based on the BSR, the PHR, the UL CP transmission buffer, the UL CP retransmission buffer, the Multiplexing of two or more of the UL UP transmission buffers, or the UL UP retransmission buffers. 25. The apparatus of any one of claims 23 to 24, wherein the means for processing is further configured to execute the instructions to: employ automatic repeat request ARQ at the w-HL C-PDU level ACK/NACK ACK/NACK retransmission mechanism and physical layer transport block TB-level hybrid ARQ HARQ ACK/NACK retransmission mechanism. 26. The apparatus of any of claims 23 to 24, wherein the w-HL C-PDU header includes a plurality of subheaders.

Images