WO2018026393A1 - Équipement utilisateur (ue), nœud b évolué (enb) et procédés de communication voix sur lte (volte) selon une compression robuste des en-têtes (rohc) - Google Patents

Équipement utilisateur (ue), nœud b évolué (enb) et procédés de communication voix sur lte (volte) selon une compression robuste des en-têtes (rohc) Download PDF

Info

Publication number
WO2018026393A1
WO2018026393A1 PCT/US2017/016180 US2017016180W WO2018026393A1 WO 2018026393 A1 WO2018026393 A1 WO 2018026393A1 US 2017016180 W US2017016180 W US 2017016180W WO 2018026393 A1 WO2018026393 A1 WO 2018026393A1
Authority
WO
WIPO (PCT)
Prior art keywords
rohc
pdcp
packets
network protocol
packet
Prior art date
Application number
PCT/US2017/016180
Other languages
English (en)
Inventor
Jerome Parron
Stefania Sesia
Christian Drewes
Original Assignee
Intel IP Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel IP Corporation filed Critical Intel IP Corporation
Publication of WO2018026393A1 publication Critical patent/WO2018026393A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/04—Protocols for data compression, e.g. ROHC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • Embodiments pertain to wireless communications. Some embodiments relate to wireless networks including 3GPP (Third Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, and 3 GPP LTE- A (LTE Advanced) networks, although the scope of the 3GPP (Third Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, and 3 GPP LTE- A (LTE Advanced) networks, although the scope of the 3GPP (Third Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, and 3 GPP LTE- A (LTE Advanced) networks, although the scope of the 3GPP (Third Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, and 3 GPP LTE- A (LTE Advanced) networks, although the scope of the 3GPP (Third Generation Partnership Project) networks, 3GPP LTE (Long Term Evolution) networks, and 3 GPP LTE- A (LTE Advanced) networks, although the scope of the 3GP
  • embodiments is not limited in this respect. Some embodiments relate to internet-of-things (loT) operation, including narrowband loT (NB loT) operation. Some embodiments relate to voice communication, including voice over LTE (VoLTE) communication.
  • LoT internet-of-things
  • NB loT narrowband loT
  • VoIP voice over LTE
  • Base stations and mobile devices operating in a cellular network may exchange data and related control messages.
  • the network may support operation according to Internet of Things (loT) protocols or techniques.
  • mobile devices that support IoT operation may operate in accordance with reduced processing power, memory, size, complexity and/or other factors.
  • Some operations may be challenging, including synchronization, exchanging of voice, exchanging of data, usage of headers and/or other operations. Accordingly, there is a general need for methods and systems for performing these and other operations as part of loT techniques and/or other techniques.
  • FIG. 1 is a functional diagram of a 3GPP network in accordance with some embodiments
  • FIG. 2 illustrates a block diagram of an example machine in accordance with some embodiments:
  • FIG. 3 is a block diagram of an E volved Node-B (eNB) in accordance with some embodiments
  • FIG. 4 is a block diagram of a User Equipment (UE) in accordance with some embodiments.
  • UE User Equipment
  • FIG. 5 illustrates the operation of a method of communication in accordance with some embodiments
  • FIG. 6 illustrates examples layers, example protocols and example operations in accordance with some embodiments
  • FIG. 7 illustrates example operations in accordance with some embodiments
  • FIG. 8 illustrates additional examples layers, example protocols and example operations in accordance with some embodiments.
  • FIG. 9 illustrates the operation of another method of communication in accordance with some embodiments.
  • FIG. I is a functional diagram of a 3GPP network in accordance with some embodiments. It should be noted that embodiments are not limited to the example 3GPP network shown in FIG. 1, as other networks may be used in some embodiments. As an example, a Fifth Generation (5G) network may be used in some cases. As another example, a wireless local area network (WLAN) may be used in some cases. Embodiments are not limited to these example networks, however, as other networks may be used in some embodiments. In some embodiments, a network may include one or more components shown in FIG. 1. Some embodiments may not necessarily include all components shown in FIG. 1 , and some embodiments may include additional components not shown in FIG. 1.
  • 5G Fifth Generation
  • WLAN wireless local area network
  • the network 100 may comprise a radio access network (RAN)
  • RAN radio access network
  • the E-UTRAN or evolved universal terrestrial radio access network 101 and the core network 120 (e.g., shown as an evolved packet core (EPC)) coupled together through an SI interface 115.
  • EPC evolved packet core
  • SI interface 115 For convenience and brevity sake, only a portion of the core network 120, as well as the RAN 100, is shown.
  • the core network 120 includes a mobility management entity
  • the RAN 100 includes Evolved Node-B's (eNBs) 104 (which may operate as base stations) for communicating with User Equipment (UE) 102.
  • eNBs Evolved Node-B's
  • the eNBs 104 may include macro eNBs and low power (LP) eNBs. [ ⁇ 17] In some embodiments, one or more of the UEs 102 and/or eNBs
  • references herein to a UE, IoT UE and/or NB loT UE as pail of descriptions herein are not limiting. For instance, references to one of the UE, IoT UE or NB IoT UE as part of descriptions of various operations and/or techniques may be applicable to the others in some embodiments.
  • the eNB 104 may be configured to operate in accordance with an internet-of-things (IoT) protocol and/or IoT techniques
  • IoT internet-of-things
  • MTC machine type communication
  • the UE 102 may transmit signals (data, control and/or other) to the eNB 104, and may receive signals (data, control and/or other) from the eNB 104. These embodiments will be described in more detail below.
  • the MME 122 is similar in function to the control plane of legacy Serving GPRS Support Nodes (SGSN).
  • the MME 122 manages mobility aspects in access such as gateway selection and tracking area list management.
  • the serving GW 124 terminates the interface toward the RAN 100, and routes data packets between the RAN 100 and the core network 120. In addition, it may be a local mobility anchor point for inter-eNB handovers and also may provide an anchor for inter-3GPP mobility. Other responsibilities may include lawful intercept, charging, and some policy enforcement.
  • the serving GW 124 and the MME 122 may be implemented in one physical node or separate physical nodes.
  • the PDN GW 126 terminates an SGi interface toward the packet data network (PDN).
  • PDN packet data network
  • the PDN GW 126 routes data packets between the EPC 120 and the external PDN, and may be a key node for policy enforcement and charging data collection. It may also provide an anchor point for mobility with non-LTE accesses.
  • the external PDN can be any kind of IP network, as well as an IP Multimedia Subsystem (IMS) domain.
  • IMS IP Multimedia Subsystem
  • the PDN GW 126 and the serving GW 124 may be implemented in one physical node or separated physical nodes.
  • the eNBs 104 terminate the air interface protocol and may be the first point of contact for a UE 102. In some
  • an eNB 104 may fulfill various logical functions for the RAN 100 including but not limited to RNC (radio network controller functions) such as radio bearer management, uplink and downlink dynamic radio resource management and data packet scheduling, and mobility management.
  • RNC radio network controller functions
  • UEs 102 may be configured to communicate Orthogonal Frequency Division Multiplexing (OFDM) communication signals with an eNB 104 over a multi carrier communication channel in accordance with an Orthogonal Frequency Division Multiple Access (OFDMA) communication technique.
  • Hie OFDM signals may comprise a plurality of orthogonal subcarriers.
  • the SI interface 115 is the interface that separates the RAN 100 and the EPC 120. It is split into two pails: the Sl-U, which carries traffic data between the eNBs 104 and the serving GW 124, and the SI -MME, which is a signaling interface between the eNBs 104 and the MME 122.
  • the X2 interface is the interface between eNBs 104.
  • the X2 interface comprises two parts, the X2-C and X2-U.
  • the X2-C is the control plane interface between the eNBs 104
  • the X2-U is the user plane interface between the eNBs 104.
  • LP cells are typically used to extend coverage to indoor areas where outdoor signals do not reach well, or to add network capacity in areas with very dense phone usage, such as train stations.
  • the term low power (LP) eNB refers to any suitable relatively low power eNB for implementing a narrower cell (narrower than a macro cell) such as a ferntocell, a picocell, or a micro cell.
  • Ferntocell eNBs are typicaliy provided by a mobile network operator to its residential or enterprise customers.
  • a ferntocell is typically the size of a residential gateway or smaller and generally connects to the user's broadband line.
  • a LP eNB might be a ferntocell eNB since it is coupled through the PDN GW 126.
  • a picocell is a wireless communication system typically covering a small area, such as in-building (offices, shopping malls, train stations, etc.), or more recently m-aircraft.
  • a picocell eNB can generally connect through the X2 link to another eNB such as a macro eNB through its base station controller (BSC)
  • BSC base station controller
  • LP eNB may be implemented with a picocell eNB since it is coupled to a macro eNB via an X2 interface.
  • Picocell eNBs or other LP eNBs may incorporate some or all functionality of a macro eNB. In some cases, this may be referred to as an access point base station or enterprise ferntocell.
  • a downlink resource grid may be used for downlink transmissions from an eNB 104 to a UE 102, while uplink
  • the gnd may be a time-frequency grid, called a resource grid or time-frequency resource grid, which is the physical resource in the downlink in each slot.
  • a time-frequency plane representation is a common practice for OFDM systems, which makes it intuitive for radio resource allocation.
  • Each column and each row of the resource grid correspond to one OFDM symbol and one OFDM subcarrier, respectively.
  • the duration of the resource grid in the time domain corresponds to one slot in a radio frame.
  • the smallest time-frequency unit in a resource grid is denoted as a resource element (RE).
  • RE resource element
  • circuitry may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality.
  • ASIC Application Specific Integrated Circuit
  • the circuitry may be implemented in, or functions associated with the circuitry may be implemented by, one or more software or firmware modules.
  • circuitry may include logic, at least partially operable in hardware. Embodiments described herein may be implemented into a system using any suitably configured hardware and/or software.
  • FIG. 2 illustrates a block diagram of an example machine in accordance with some embodiments.
  • the machine 200 is an example machine upon which any one or more of the techniques and/or methodologies discussed herein may be performed.
  • the machine 200 may operate as a standalone device or may be connected (e.g., networked) to other machines.
  • the machine 200 may operate in the capacity of a serv er machine, a client machine, or both in server-client network environments.
  • the machine 200 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment.
  • P2P peer-to-peer
  • the machine 200 may be a UE 102, eNB 104, access point (AP), station (STA), mobile device, base station, personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a smart, phone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine.
  • the term "machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.
  • Examples as described herein may include, or may operate on, logic or a number of components, modules, or mechanisms.
  • Modules are tangible entities (e.g., hardware) capable of performing specified operations and may be configured or arranged in a certain manner.
  • circuits may be arranged (e.g., internally or with respect to external entities such as other circuits) in a specified manner as a module.
  • the whole or part of one or more computer systems e.g., a standalone, client or server computer system
  • one or more hardware processors may be configured by firmware or software (e.g., instructions, an application portion, or an application) as a module that operates to perform specified operations.
  • the software may reside on a machine readable medium.
  • the software when executed by the underlying hardware of the module, causes the hardware to perform the specified operations.
  • module is understood to encompass a tangible entity, be that an entity that is physically constructed, specifically configured (e.g., hardwired), or temporarily (e.g., transitorily) configured (e.g., programmed) to operate in a specified manner or to perform part or all of any operation described herein.
  • each of the modules need not be instantiated at any one moment in time.
  • the modules comprise a general-purpose hardware processor configured using software
  • the general-purpose hardware processor may be configured as respective different modules at different times.
  • Software may accordingly configure a hardware processor, for exampie, to constitute a particular module at one instance of time and to constitute a different module at a different instance of time.
  • the machine 200 may include a hardware processor 202 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a mam memory 204 and a static memory 206, some or all of which may communicate with each other via an interlink (e.g., bus) 208.
  • the machine 200 may further include a display unit 210, an alphanumeric input device 212 (e.g., a keyboard), and a user interface (UI) navigation device 214 (e.g., a mouse).
  • the display unit 210, input device 212 and UI navigation device 214 may be a touch screen display.
  • the machine 200 may additionally include a storage device (e.g., drive unit) 216, a signal generation device 218 (e.g., a speaker), a network interface device 220, and one or more sensors 221, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor.
  • the machine 200 may include an output controller 228, such as a serial (e.g., universal serial bus (USB), parallel , or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • a serial e.g., universal serial bus (USB), parallel , or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
  • USB universal serial bus
  • parallel or other wire
  • the storage device 216 may include a machine readable medium 222 on which is stored one or more sets of data structures or instructions 224 (e.g. , software) embodying or utilized by any one or more of the techniques or functions described herein.
  • the instructions 224 may also reside, completely or at least partially, within the main memory 204, within static memory 206, or within the hardware processor 202 during execution thereof by the machine 200.
  • one or any combination of the hardware processor 202, the main memory 204, the static memory 206, or the storage device 216 may constitute machine readable media.
  • the machine readable medium may be or may include a non -transitory computer-readable storage medium.
  • machine readable medium 222 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 224.
  • the term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 200 and that cause the machine 200 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions.
  • Non-limiting machine readable medium examples may include solid-state memories, and optical and magnetic media.
  • Specific examples of machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable
  • machine readable media may include non-transitory machine readable media.
  • machine readable media may include machine readable media that is not a transitory propagating signal.
  • the instructions 224 may further be transmitted or received over a communications network 226 using a transmission medium via the network interface device 220 utilizing any one of a number of transfer protocols (e.g., frame relay , internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.).
  • transfer protocols e.g., frame relay , internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.
  • Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, a Long Term Evolution (LTE) family of standards, a Universal Mobile Telecommunications System (UMTS) family of standards, peer-to-peer (P2P) networks, among others.
  • LAN local area network
  • WAN wide area network
  • POTS Plain Old Telephone
  • wireless data networks e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®
  • IEEE 802.15.4 family of standards e.g., Institute of Electrical and Electronics Engineers (IEEE
  • the network interface device 220 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 226.
  • the network interface device 220 may include a plurality of antennas to wirelessiy communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques.
  • SIMO single-input multiple-output
  • MIMO multiple-input multiple-output
  • MISO multiple-input single-output
  • the network interface device 220 may wireiessly communicate using Multiple User MIMO techniques.
  • the term "transmission medium * ' shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 200, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.
  • FIG. 3 is a block diagram of an Evolved Node-B (e ' NB) in accordance with some embodiments. It should be noted that in some
  • the eNB 300 may be a stationary non-mobile device.
  • the eNB 300 may be suitable for use as an eNB 104 as depicted in FIG. 1.
  • the eNB 300 may include physical layer circuitry 302 and a transceiver 305, one or both of which may enable transmission and reception of signals to and from the UE 200, other eNBs, other UEs or other devices using one or more antennas 301.
  • the physical layer circuitry 302 may perform various encoding and decoding functions that may include formation of baseband signals for transmission and decoding of received signals.
  • the transceiver 305 may perform various transmission and reception functions such as conversion of signals between a baseband range and a Radio Frequency (RF) range.
  • RF Radio Frequency
  • the physical layer circuitry 302 and the transceiver 305 may be separate components or may be part of a combined component.
  • some of the described functionality related to transmission and reception of signals may be performed by a combination that may include one, any or all of the physical layer circuitry 302, the transceiver 305, and other components or layers.
  • the eNB 300 may also include medium access control layer (MAC) circuitry 304 for controlling access to the wireless medium.
  • the eNB 300 may also include processing circuitry 306 and memory 308 arranged to perform the operations described herein.
  • the eNB 300 may also include one or more interfaces 310, which may enable communication with other components, including other eNBs 104 (FIG. 1), components in the EPC 120 (FIG. 1) or other network components.
  • the interfaces 310 may enable communication with other components that may not be shown in FIG. 1, including components external to the network.
  • the interfaces 310 may be wired or wireless or a combination thereof.
  • an eNB or other base station may include some or all of the components shown in either FIG. 2 or FIG. 3 or both.
  • FIG. 4 is a block diagram of a User Equipment (UE) in accordance with some embodiments.
  • the UE 400 may be suitable for use as a UE 102 as depicted in FIG. 1 .
  • the UE 400 may include application circuitry 402, baseband circuitry 404, Radio Frequency (RF) circuit! ⁇ ' 406, front-end module (FEM) circuitry 408 and one or more antennas 410, coupled together at least as shown.
  • other circuitry or arrangements may include one or more elements and/or components of the application circuitry 402, the baseband circuitry 404, the RF ' circuitry 406 and/or the FEM circuitry 408, and may also include other elements and/or components in some cases.
  • '"processing circuitry may include one or more elements and/or components, some or all of which may be included in the application circuitry 402 and/or the baseband circuitry 404.
  • a '"transceiver” and/or '"transceiver circuitry may include one or more elements and/or components, some or all of which may be included in the RF circuitry 406 and/or the FEM circuitry 408.
  • the processing circuitry, transceiver and/or the transceiver circuitry may also include other elements and/or components in some cases.
  • a UE or other mobile device may include some or all of the components shown in either FIG. 2 or FIG. 4 or both.
  • the application circuitry 402 may include one or more application processors.
  • the application circuitry 402 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
  • the processor(s) may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors,
  • the processors may be coupled with and/or may include memory /storage and may be configured to execute instructions stored in the memory /storage to enable various applications and/or operating systems to run on the system.
  • the baseband circuitry 404 may include circuitry such as, but not limited to, one or more single-core or multi-core processors.
  • the baseband circuitry 404 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 406 and to generate baseband signals for a transmit signal path of the RF circuitry 406.
  • Baseband processing circuitry 404 may interface with the application circuitry 402 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 406.
  • the baseband circuitry 404 may include a second generation (2G) baseband processor 404a, third generation (3G) baseband processor 404b, fourth generation (4G) baseband processor 404c, and/or other baseband processor(s) 404d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.).
  • the baseband circuitry 404 e.g., one or more of baseband processors 404a-d
  • the radio control functions may include, but are not limited to, signal modulation/demodulation,
  • modulation/demodulation circuitry of the baseband circuitry 404 may include Fast-Fourier Transform (FFT), preeodmg, and/or constellation
  • encoding/decoding circuitry of the baseband circuitry 404 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality.
  • LDPC Low Density Parity Check
  • the baseband circuitry 404 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or radio resource control (RRC) elements.
  • EUTRAN evolved universal terrestrial radio access network
  • MAC media access control
  • RLC radio link control
  • PDCP packet data convergence protocol
  • RRC radio resource control
  • CPU central processing unit
  • 404 may be configured to run elements of the protocol stack for signaling of the
  • the baseband circuitry may include one or more audio digital signal processor(s) (DSP) 404f.
  • the audio DSP(s) 404f may be include elements for
  • compression/decompression and echo cancellation may include other suitable processing elements in other embodiments.
  • Components of the baseband circuitry may be suitably combined in a single chip, a single chipset, or disposed on a same circuit board in some embodiments.
  • some or all of the constituent components of the baseband circuitr ' 404 and the application circuitry 402 may be implemented together such as, for example, on a system on a chip (SOC).
  • SOC system on a chip
  • the baseband circuitry 404 may provide for communication compatible with one or more radio technologies.
  • the baseband circuitry 404 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN).
  • EUTRAN evolved universal terrestrial radio access network
  • WMAN wireless metropolitan area networks
  • WLAN wireless local area network
  • WPAN wireless personal area network
  • multi-mode baseband circuitry Embodiments in which the baseband circuitry 404 is configured to support radio communications of more than one wireless protocol.
  • RF circuitry 406 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium.
  • the RF circuitry 406 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network.
  • RF circuitry 406 may include a receive signal path which may include circuitry to down-convert RF signals received from the FEM circuitry 408 and provide baseband signals to the baseband circuitry 404.
  • RF circuitry 406 may also include a transmit signal path which may include circuitry to up-convert baseband signals provided by the baseband circuitry 404 and provide RF output signals to the FEM circuitry' 408 for transmission.
  • the RF circuitry 406 may include a receive signal path and a transmit signal path.
  • the receive signal path of the RF circuitry 406 may include mixer circuitry 406a, amplifier circuitry 406b and filter circuitry 406c.
  • the transmit signal path of the RF circuitry 406 may include filter circuitry 406c and mixer circuitry 406a.
  • RF circuitry 406 may also include synthesizer circuitry 4()6d for synthesizing a frequency for use by the mixer circuit! ⁇ ' 406a of the receive signal path and the transmit signal path.
  • the mixer circuitiy 406a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitiy 408 based on the synthesized frequency provided by synthesizer circuitiy 406d.
  • the amplifier circuitiy 406b may be configured to amplify the down-converted signals and the filter circuitry 406c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals.
  • LPF low-pass filter
  • BPF band-pass filter
  • Output baseband signals may be provided to the baseband circuitiy 404 for further processing.
  • the output baseband signals may be zero-frequency baseband signals, although this is not a requirement.
  • mixer circuitiy 406a of the receive signal path may comprise passi v e mixers, although the scope of the embodiments is not limited in this respect.
  • the mixer circuitry 406a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 406d to generate RF output signals for the FEM circuitry 408.
  • the baseband signals may be provided by the baseband circuitry 404 and may be filtered by filter circuitry 406c.
  • the filter circuitry 406c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.
  • LPF low-pass filter
  • the mixer circuitiy 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively.
  • the mixer circuitiy 406a of the receive signal path and the mixer circuitry 406a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection).
  • the mixer circuitr ' 406a of the receive signal path and the mixer circuitry 406a may be arranged for direct downconversion and/or direct upconversion, respectively.
  • the mixer circuitry 406a of the receive signal path and the mixer circuitiy 406a of the transmit signal path may be configured for super-heterodyne operation.
  • the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect.
  • the output baseband signals and the input baseband signals may be digital baseband signals.
  • the RF circuitry 406 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitiy and the baseband circuitiy 404 may include a digital baseband interface to communicate with the RF circuitiy 406.
  • ADC analog-to-digital converter
  • DAC digital-to-analog converter
  • a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.
  • the synthesizer circuitry 406d may be a fractional-N synthesizer or a fractional N/N+1 synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable.
  • synthesizer circuitry 406d may be a delta-si gma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.
  • the synthesizer circuitiy 406d may be configured to synthesize an output frequency for use by the mixer circuitry 406a of the RF circuitr ' 406 based on a frequency input and a divider control input.
  • the synthesizer circuitiy 406d may be a fractional N/N+1 synthesizer.
  • frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement.
  • VCO voltage controlled oscillator
  • Di vider control input may be provided by either the baseband circuitiy 404 or the applications processor 402 depending on the desired output frequency.
  • a divider control input (e.g., N) may be determined from a lookup table based on a channel indicated by the applications processor 402.
  • Synthesizer circuitry 406d of the RF circuitry 406 may include a divider, a delay-locked loop (DLL), a multiplexer and a phase accumulator.
  • the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DP A).
  • the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio.
  • the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop.
  • the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line.
  • Nd is the number of delay elements in the delay line.
  • synthesizer circuitry 406d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g. , twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other.
  • the output frequency may be a LO frequency (fLo).
  • the RF circuitry 406 may include an IQ/polar converter.
  • FEM circuitry 408 may include a receive signal path which may include circuitry configured to operate on RF signals received from one or more antennas 410, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 406 for further processing.
  • FEM circuitry 408 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 406 for transmission by one or more of the one or more antennas 410.
  • the FEM circuitry 408 may include a TX/RX switch to switch between transmit mode and receive mode operation.
  • the FEM circuitry may include a receive signal path and a transmit signal path.
  • the receive signal path of the FEM circuitry may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 406).
  • LNA low-noise amplifier
  • the transmit signal path of the FEM circuitry 408 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 406), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 410.
  • PA power amplifier
  • the LIE 400 may include additional elements such as, for example, memory /storage, display, camera, sensor, and/or input/output (I/O) interface.
  • the antennas 230, 301, 410 may comprise one or more directional or omnidirectional antennas, including, for example, dipole antennas, monopole antennas, patch antennas, loop antennas, microstrip antennas or other types of antennas suitable for transmission of RF signals.
  • MIMO multiple-input multiple-output
  • the antennas 230, 301 , 410 may be effectively separated to take advantage of spatial diversity and the different channel characteristics that may result.
  • the UE 400 and/or the eNB 300 may be a mobile device and may be a portable wireless communication device, such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a wearable device such as a medical device (e.g. , a heart rate monitor, a blood pressure monitor, etc.), or other device that may receive and/or transmit information wirelessly.
  • PDA personal digital assistant
  • a laptop or portable computer with wireless communication capability such as a personal digital assistant (PDA), a laptop or portable computer with wireless communication capability, a web tablet, a wireless telephone, a smartphone, a wireless headset, a pager, an instant messaging device, a digital camera, an access point, a television, a wearable device such as a medical device (e.g. , a heart rate monitor, a blood pressure monitor, etc.
  • Mobile devices or other devices in some embodiments may be configured to operate according to other protocols or standards, including IEEE 802.1 1 or other IEEE standards.
  • the UE 400, eNB 300 or other device may include one or more of a keyboard, a display, a non-volatile memory port, multiple antennas, a graphics processor, an application processor, speakers, and other mobile device elements.
  • the display may be an LCD screen including a touch screen.
  • the UE 400 and the eNB 300 are each illustrated as having several separate functional elements, one or more of the functional elements may be combined and may be implemented by combinations of software-configured elements, such as processing elements including digital signal processors (DSPs), and/or other hardware elements.
  • DSPs digital signal processors
  • some elements may comprise one or more microprocessors, DSPs, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), radio-frequency integrated circuits (RFICs) and combinations of various hardware and logic circuitry for performing at least the functions described herein.
  • the functional elements may refer to one or more processes operating on one or more processing elements.
  • Embodiments may be implemented in one or a combination of hardware, firmware and software.
  • Embodiments may also be implemented as instructions stored on a computer-readable storage device, which may be read and executed by at least one processor to perform the operations described herein.
  • a computer-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer).
  • a computer-readable storage device may include readonly memory (ROM), random-access memory (RAM), magnetic disk storage media, optical storage media, flash-memor ' devices, and other storage devices and media.
  • Some embodiments may include one or more processors and may be configured with instructions stored on a computer-readable storage device.
  • an apparatus used by the UE 400 and/or eNB 300 and/or machine 200 may include various components of the UE 400 and/or the eNB 300 and/or the machine 200 as shown in FIGs. 2-4. Accordingly, techniques and operations described herein that refer to the UE 400 (or 102) may be applicable to an apparatus for a UE. In addition, techniques and operations described herein that refer to the eNB 300 (or 104) may be applicable to an apparatus for an eNB.
  • the UE 102 may compress network protocol headers as part of a robust header compression (RoHC), the network protocol headers corresponding to a sequence of voice packets.
  • the UE 102 may transmit a sequence of packet data convergence protocol (PDCP) packets that include the voice packets and the corresponding compressed network protocol headers.
  • PDCP packet data convergence protocol
  • the UE 102 may determine that the RoHC is to be resynchronized between first and second PDCP packets that are consecutive within the sequence of PDCP packets.
  • the UE 102 may transmit, between the first and second PDCP packets, a resvnchronization PDCP packet to resynchronize the RoHC.
  • the first PDCP packet may be based on a first voice packet of the sequence of voice packets and a corresponding first network protocol header compressed as part of the RoHC.
  • the resvnchronization PDCP packet may be based on the first network protocol header without the compression of the RoHC.
  • a UE 102 may perform one or more operations of the method 500, but embodiments are not limited to performance of the method 500 and/or operations of it by the UE 102.
  • the eNB 104 may perform one or more operations of the method 500 (and/or similar operations). Accordingly, although references may be made to performance of one or more operations of the method 500 by the UE 102 in descriptions herein, it is understood that the eNB 104 may perform the same operation(s), similar operation(s) and/or reciprocal operation(s), in some embodiments.
  • the method 500 and other methods described herein may refer to eNBs 104 or UEs 102 operating in accordance with 3GPP standards, 5G standards and/or other standards, embodiments of those methods are not limited to just those eNBs 104 or UEs 102 and may also be practiced on other devices, such as a Wi-Fi access point (AP) or user station (STA).
  • AP Wi-Fi access point
  • STA user station
  • the method 500 and other methods described herein may be practiced by wireless devices configured to operate in other suitable types of wireless communication systems, including systems configured to operate according to various IEEE standards such as IEEE 802.11.
  • the method 500 may also refer to an apparatus for a UE 102 and/or eNB 104 and/or other device described above.
  • embodiments are not limited by- refer ences herein (such as in descriptions of the methods 500 and 900 and/or other descriptions herein) to transmission, reception and/or exchanging of elements such as frames, messages, requests, indicators, signals or other elements.
  • an element may be generated, encoded or otherwise processed by processing circuitry (such as by a baseband processor included in the processing circuit! ⁇ ') for transmission.
  • the transmission may be performed by a transceiver or other component, in some cases.
  • such an element may be decoded, detected or otherwise processed by the processing circuitry (such as by the baseband processor).
  • the element may be received by a transceiver or other component, in some cases.
  • the processing circuitry and the transceiver may be included in a same apparatus. The scope of embodiments is not limited in this respect, however, as the transceiver may be separate from the apparatus that comprises the processing circuitry, in some embodiments.
  • the UE 102 may exchange one or more control messages with the eNB 104. Accordingly, the UE 102 may transmit one or more control messages to the eNB 104 and/or receive one or more control messages from the eNB 1 04.
  • the control message(s) may include any suitable information related to communication between the UE 102 and the eNB, including but not limited to an establishment of connectivity between the UE 102 and the eNB 104, voice codec information, header compression information and/or other.
  • the UE 102 may compress network protocol headers in accordance with a robust header compression (RoHC).
  • the UE 1 02 may generate a sequence of PDCP packets.
  • the PDCP packets may include the voice packets and may further include the corresponding compressed network protocol headers (the corresponding network protocol headers after compression of the RoHC is applied).
  • the PDCP packets may be based on the voice packets and may be further based on the corresponding compressed network protocol headers (the corresponding network protocol headers after the RoHC is applied).
  • the UE 102 may transmit the sequence of PDCP packets.
  • the transmission of the PDCP packets may include operations such as repetition, forward error correction (FEC), bit-to- symbol mapping, assignment of the symbols to resource units ( M l s) of one or more PRBs, interleaving and/or other operations.
  • FEC forward error correction
  • M l s resource units
  • the PDCP packets may not necessarily be transmitted, in some embodiments.
  • a signal (OFDM or other) based on the PDCP packets may be transmitted.
  • a group of symbols based on the PDCP packets may be mapped to RUs and/or PRBs for transmission.
  • voice over Long Term Evolution (VoLTE) techniques may be used, alihough the scope of embodiments is not limited in this respect.
  • the UE 102 may be arranged to operate in accordance with a Third Generation Partnership Project (3 GPP) Long Term Evolution (LTE) protocol.
  • 3 GPP Third Generation Partnership Project
  • LTE Long Term Evolution
  • the PDCP packets may be generated for
  • the sequence of voice packets (and/or the sequence of PDCP packets) may be sent as part of a category Ml (Cat-Ml) internet-of-things (IoT) communication.
  • the predetermined redundancy rate may be based on a maximum transport block size (TBS) of the Cat-Mi IoT communication and a voice packet size, in some cases.
  • TBS transport block size
  • the predetermined redundancy rate may be based on a target performance level of the Cat-Ml IoT operation, in some cases.
  • the sequence of PDCP packets may be generated for transmission in one or more physical resource blocks (PRBs) reserved for Cat- Ml IoT communication.
  • PRBs physical resource blocks
  • the TBS of the Cat-Ml IoT communication may be based at least partly on a number of PRBs reserved for the Cat-Ml IoT operation.
  • 6 PRBs which may be 12 resource units (RUs) by 7 OFDM symbol periods
  • Embodiments are not limited to these examples and are not limited to usage of Cat-Ml IoT communication, as other suitable types of communication (IoT or otherwise) may be used.
  • category NB-1 (Cat NB-l) communication may be used, in some cases.
  • the Cat NB-1 communication may be performed in one PRB, in some cases, alihough the scope of embodiments are not limited in this respect.
  • Cat-Ml communication and/or Cat NB-l communication such references are not limiting, as other categories and/or types of communication may be used, in some embodiments.
  • a category and/or type of communication may ⁇ be defined to satisfy Internet of Things use cases such as Category Ml, Category NB1 or any other category.
  • Such categories may be defined in the context of FeMTC and/or eNB-IOT, in some cases, although the scope of embodiments is not limited in this respect. It should be noted that one or more such categories may be defined and/or specified at a future time, in some cases.
  • the UE 102 may select a voice packet size based on a maximum transport block size (TBS) according to the category, in some embodiments.
  • TBS maximum transport block size
  • a network protocol header without the compression of the RoHC may be 60 bytes (480 bits) or other suitable number of bytes/bits, and a compressed network protocol header may be 3 bytes (24 bits) or other suitable number of bytes/bits.
  • the RoHC may be performed on network protocol headers that correspond to voice packets.
  • the network protocol headers may encapsulate the voice packets.
  • the network protocol headers may be based on one or more of an internet protocol (IP), universal datagram protocol (UDP), and real -time transport protocol (RTP).
  • IP internet protocol
  • UDP universal datagram protocol
  • RTP real -time transport protocol
  • the network protocol header may be an IP/UDP/RTP header.
  • the network protocol header may be based on any suitable protocol(s) and/or iayer(s).
  • the compression of a particular network protocol header of a sequence of network protocol headers may be based on one or more previous network protocol headers of the sequence of network protocol headers. For instance, one or more fields of the particular network protocol header may have a same value as one or more previous network protocol headers. In some cases, a value of a particular field may vary in a known manner (such as a count and/or index) between consecutive network protocol headers, which may be used as part of the compression. In some cases, a comparison between consecutive network protocol headers may be used as part of the compression.
  • the voice packets may be generated by a voice codec.
  • the voice codec may be implemented by the processing circuitry of the UE 102, in which case the processing circuitry and/or UE 102 may generate the voice packets.
  • the voice codec may be
  • the voice codec may be implemented separately from the UE 102 (such as by external components)), in which case the UE 102 may receive the voice packets from an external component.
  • a network protocol header may correspond to a voice packet.
  • each voice packet may correspond to a network protocol header, in some cases.
  • groups of voice packets may be combined (such as multiple consecutive voice packets) and each group may correspond to one of the network protocol headers.
  • the voice packets may be part of a sequence of voice packets.
  • the network protocol headers may be part of a sequence of network protocol headers.
  • the UE 102 may generate the sequence of PDCP packets based on an encoding of the voice packets and the corresponding compressed network protocol headers in accordance with a predetermined redundancy rate per PDCP packet. For instance, the UE 102 may encode a combination of a particular voice packet and the corresponding compressed network protocol header to generate a particular PDCP packet. The UE 102 may perform the same (or similar) operations on some or all of the voice packets (and corresponding compressed network protocol headers) to generate the sequence of PDCP packets.
  • memory of the UE 102 and/or apparatus of the UE 102 may be configurable to store the predetermined redundancy rate for usage in the generation of the PDCP packets, although the scope of embodiments is not limited in this respect.
  • the PDCP packets may include voice packets and corresponding network protocol headers and may exclude the network protocol headers without the compression of the RoHC.
  • the encode operation may be performed (to generate the PDCP packets) based on input(s) that include the voice packets and the compressed network protocol headers, but exclude (or do not include) the network protocol headers without the compression of the RoHC.
  • the PDCP packets may support a limited block size of encoded bits and/or symbols (such as a transport block size (TBS) or other).
  • TBS transport block size
  • the TBS may be or may define a boundary of a maximum possible size of a PDCP packet. If a PDCP packet is larger than the TBS, the PDCP packet may be segmented.
  • segmentation of PDCP packets larger than the TBS may be a rule, guideline and/or restriction.
  • a rule, guideline and/or restriction may be included in a 3GPP standard and/or other standard, in some embodiments, although the scope of embodiments is not limited in this respect.
  • the network protocol headers with and without the compression of the RoHC may vary in size by a large amount, in some cases. Therefore, usage of the compressed network protocol headers in the encode operation may enable a larger amount of redundancy in comparison to a redundancy when the network protocol headers (without the compression of the RoHC) are used. In some cases, usage of the RoHC may enable, for a particular TBS, an increase in a voice codec rate for the voice packets in comparison to a maximum voice codec rate when the RoHC is not used.
  • a resulting size of the voice packet plus a size of the network protocol header without the compression of the RoHC may exceed a particular TBS. Accordingly, the second voice codec rate may be unsupported by the particular TBS although the first voice code rate may be supported. In addition, more redundancy may be used for the first voice codec rate than for the second voice codec rate, and therefore the first voice codec rate may be supported at a higher range (such as a distance between the eNB 104 and the UE 102), in some cases.
  • a redundancy may be applied to the PDCP packets.
  • the redundancy may be based on a number of di versity repetitions, a forward error correction (FEC) coding rate or a combination thereof.
  • FEC forward error correction
  • the diversity repetitions and/or FEC may be applied to the PDCP packets.
  • the PDP packets may be sequences of bits, which may be repeated and/or FEC encoded.
  • the bits of the PDCP packets and/or FEC encoded bits based on the PDCP packets may be repeated.
  • modulation symbols based on the PDCP packets (uncoded bits and/or FEC encoded bits) may be repeated.
  • the diversity repetitions may be applied to coded or uncoded bits of the voice packets and/or compressed network protocol headers.
  • the diversity repetitions may be applied to modulation symbols before or after coding of the bits of the voice packets and/or compressed network protocol headers.
  • a higher amount of redundancy may be applied by selection of the FEC coding rate, in which a lower FEC coding rate corresponds to a higher amount of redundancy. For instance, a rate 1/2 FEC coding rate provides less redundancy than a rate 1/4 FEC coding rate.
  • the UE 102 may determine whether the RoHC is to be resynchronized. It should be noted that embodiments are not limited by- references herein to resynchronization or synchronization of the RoHC. In some embodiments, the network headers may be resynchronized and/or synchronized using operations and/or techniques described herein.
  • the UE 102 may generate a resynchronization PDCP packet. For instance, the UE 102 may generate a packet for resynchronization of RoHC context.
  • the UE 102 may transmit the resynchronization PDCP packet.
  • the UE 102 may determine and/or detect one or more silence periods.
  • the UE 102 may restrict transmission of the resynchronization PDCP packet to one of the silence periods. It should be noted that embodiments are not limited to the chronological order shown in FIG. 5. For instance, the ordering of operations may be different for different use cases.
  • embodiments may not necessarily include all operations shown in FIG. 5. For instance, the determination and/or detection of the silence period(s) and restriction of the resynchronization PDCP packet to the silence period(s) may not necessarily be performed in some embodiments.
  • the UE 102 may transmit a PDCP packet
  • the synchronization PDCP packet may be transmitted to synchronize the RoHC.
  • the RoHC may be synchronized as part of an initialization (such as an initialization of the RoHC or other initialization), although the scope of embodiments is not limited in this respect.
  • the synchronization PDCP packet may be transmitted before resynchronization PDCP packets (to be described below).
  • the synchronization PDCP packet may also be transmitted before PDCP packets that include the voice packets and/or
  • the UE 102 may determine that the RoHC is to be resynchronized between first and second PDCP packets that are consecutive within the sequence of PDCP packets.
  • the UE 102 may determine that the RoHC is to be resynchronized between the first and second PDCP packets based on a predetermined resynchronization interval of the RoHC during which at least one network protocol header without the compression of the RoHC is to be transmitted to resynchronize the RoHC. For instance, based on a schedule (which may be predetermined), periodicity and/or other factors, the UE 102 may determine that the RoHC is to be resynchronized.
  • the resynchronization may be
  • the resynchronization may be scheduled/determined after a particular number of PDCP packets, such as after every Nth PDCP packet, for some value of the parameter N.
  • the resynchronization may be scheduled/determined after a particular amount of time has elapsed.
  • the UE 102 may determine whether a silence period of the sequence of voice packets occurs based at least partly on one or more silence indicators of the voice packets. The UE 102 may determine whether the RoHC is to be resynchronized based at least partly on whether the silence period occurs.
  • the UE 102 may determine and/or detect one or more silence periods of the sequence of voice packets based at least partly on one or more silence indicators of the voice packets.
  • the UE 102 may restrict transmission of the resynchronization PDCP packet to one of the silence periods.
  • the UE 102 may restrict the network protocol headers without the compression of the RoHC to the PDCP packets that are generated for transmission during the silence period.
  • the resynchronization PDCP packet may be based on one of the network protocol headers without the compression of the RoHC.
  • the resynchronization PDCP packet may exclude the voice packets, in some cases.
  • the usage of the network protocol headers without the compression of the RoHC may be restricted to resynchronization packets (and therefore not performed for the sequence of PDCP packets that are based on and/or include the voice packets).
  • the resynchronization PDCP packet may not be based on and/or include voice packets. Accordingly, transmission of the network protocol headers without the compression of the RoHC may be separate from transmission of the voice packets and compressed network protocol headers, in some cases.
  • one or more PDCP packets may further include indicators of whether the PDCP packets include one of the network protocol header without the compression of the RoHC.
  • each PDCP packet may further include an indicator of whether the PDCP packet includes one of the network protocol header without the compression of the RoHC.
  • the indicator of a particular PDCP packet may indicate whether the PDCP packet includes a network protocol header without the compression of the RoHC or a network protocol header compressed as part of the RoHC.
  • the indicator may take one of two values to indicate whether the particular PDCP packet includes a network protocol header compressed as part of the RoHC or a network protocol header without the compression of the RoHC.
  • Such indicator(s) may be included in PDCP headers, in some embodiments, although the scope of embodiments is not limited in this respect.
  • some or ail of the PDCP packets may include other indicator(s), in addition to or instead of those described above.
  • one or more indicators may be included to indicate whether an uncompressed network protocol header (without the compression of the RoHC) is to be dropped or concatenated with a pay ioad (voice packet) of a next PDCP packet in a sequence of PDCP packets.
  • the particular PDCP packet may further include an indicator of whether the particular network protocol header without the compression of the RoHC is to be dropped or concatenated with a voice packet included in a next PDCP packet.
  • the indicator may indicate that the uncompressed header is to be used by the receiving entity for resvnchronization of the RoHC only, although the scope of embodiments is not limited in this respect,
  • the UE 102 may determine that the
  • RoHC is to be resynchronized between first and second PDCP packets that are consecutive within the sequence of PDCP packets.
  • the UE 102 may generate, for transmission between the first and second PDCP packets, a resynchronization PDCP packet to resynchronize the RoHC.
  • the first PDCP packet may be based on a first voice packet of the sequence of voice packets and a corresponding first network protocol header compressed in accordance with the RoHC.
  • the resynchronization PDCP packet may be based on the first network protocol header without the compression of the RoHC. In some cases, the
  • the resynchronization PDCP packet may include the first network protocol header without the compression of the RoHC and may exclude the first voice packet.
  • the UE 102 may determine that the RoHC is to be resynchronized between first and second PDCP packets that are consecutive within the sequence of PDCP packets.
  • the UE 102 may generate, for transmission between the first and second PDCP packets, a resynchronization PDCP packet to resynchronize the RoHC.
  • the second PDCP packet may be based on a second voice packet of the sequence of voice packets and a corresponding second network protocol header compressed in accordance with the RoHC.
  • the resynchronization PDCP packet may be based on the second network protocol header without the compression of the RoHC.
  • the resynchronization PDCP packet may include the second network protocol header without the compression of the RoHC and may exclude the second voice packet.
  • the UE 102 may detect one or more silence periods based on silence indicators of a sequence of voice packets.
  • the voice packets and corresponding network protocol headers may be transmitted as part of a voice communication.
  • the UE 102 may compress at least some of the network protocol headers in accordance with a robust header compression (RoHC).
  • the UE 102 may generate, for transmission, a sequence of PDCP packets.
  • Each PDCP packet may include one of the voice packets and may further include the corresponding compressed network protocol header or the corresponding network protocol header without the compression of the RoHC.
  • the inclusion of the network protocol headers without the compression of the RoHC may be restricted to the PDCP packets of the silence periods.
  • the UE 102 may select one or more of the PDCP packets of the silence period that are to include the network protocol headers without the compression of the RoHC.
  • the UE 102 may include the network protocol headers without the compression of the RoHC in one or more of those selected PDCP packets.
  • the sequence of PDCP packets may be transmitted as part of a category Ml (Cat-Mi) intemet-of-things (IoT) communication.
  • the PDCP packets may be based on a repetition diversity for the voice packets in accordance with a predetermined number of repetitions.
  • the predetermined number of repetitions may be based on a maximum transport block size (TBS) of the Cat-M i IoT communication and a voice packet size.
  • TBS transport block size
  • the predetermined number of repetitions may be further based on a target performance level of the Cat-Mi IoT operation.
  • the UE 102 may determine whether an
  • RoHC context refresh timer is active at a beginning of a particular silence period. If the RoHC context refresh timer is acti v e at the beginning of the particular silence peri od, the UE 102 may select one of the PDCP packets of the particular silence period to include one of the network protocol headers without the compression of the RoHC. The UE 102 may include the network protocol header without the compression of the RoHC in the selected PDCP packet.
  • the UE 102 may receive a signal to noise ratio
  • SNR SNR measurement from an Evolved Node-B (eNB) based on the sequence of PDCP packets.
  • eNB Evolved Node-B
  • Embodiments are not limited to SNR measurements, however, as other suitable performance metrics may be used.
  • the UE 102 may adapt a voice codec rate from a first value to a second value.
  • the UE 102 may use the second value for encoding of subsequent voice packets in some embodiments, such as when the UE 102 implements the voice codec.
  • the UE 102 may communicate the second value to another component (such as a voice codec that is separate from the processing circuitry used for other operations of the method 500), in some embodiments.
  • another component such as a voice codec that is separate from the processing circuitry used for other operations of the method 500.
  • embodiments may not necessarily include all operations shown in FIG. 5. For instance, the reception of the SNR measurement and/or the adaption of the voice codec rate may not necessarily be performed in some embodiments.
  • the UE 102 may generate, for transmission in accordance with a number of diversity repetitions, a sequence of packet data convergence protocol (PDCP) packets based on a first sequence of voice packets and corresponding network protocol headers compressed in accordance with a robust header compression (RoHC).
  • the first sequence of voice packets may be formatted in accordance with a first value of a voice codec rate.
  • the sequence of PDCP packets is to be sent as part of a category Ml (Cat-Mi) intemet-of-things (loT) communication.
  • the UE 102 may receive a signal to noise ratio (SNR) measurement from an Evolved Node-B (eNB) based on the sequence of PDCP packets.
  • SNR signal to noise ratio
  • the UE 102 may adapt the voice codec rate from the first value to a second value to be used, by a voice codec entity, for a second sequence of voice packets.
  • the voice codec rate may be adapted based at least partly on a target SNR for the Cat-Mi loT communication and a maximum transport block size (TBS) of the Cat-Mi IoT communication.
  • TBS transport block size
  • a redundancy rate and/or redundancy level may be changed accordingly. For instance, with a different voice packet pay load size, a different amount of FEC and/or repetitions may be used for a particular TBS.
  • the number of diversity repetitions described above may be referred to below as a first number of diversity repetitions; the sequence of PDCP packets described above may be referred to below as a first sequence of PDCP packets.
  • the UE 102 may generate, for transmission in accordance with a second number of diversity repetitions, a second sequence of PDCP packets based on the second sequence of voice packets and corresponding network protocol headers compressed in accordance with the RoHC.
  • the UE 102 may determine that the
  • the UE 102 may generate, for transmission between first and second PDCP packets of the sequence of PDCP packets, a resynchronization PDCP packet to resynchronize the RoHC,
  • resynchronization PDCP packet may be based on the network protocol header of the first PDCP packet without the compression of the RoHC, in some cases.
  • the UE 102 may determine that the RoHC is to be resynchronized based on a predetermined resynchronization interval of the RoHC during which at least one network protocol header without the compression of the RoHC is to be transmitted to resynchronize the RoHC.
  • the UE 102 may determine whether a silence period of the sequence of voice packets occurs based at least partly on one or more silence indicators of the voice packets The UE 102 may determine that the RoHC is to be resynchronized based at least partly on whether the silence period occurs.
  • FIG. 6 illustrates examples layers, example protocols and example operations in accordance with some embodiments.
  • FIG. 7 illustrates example operations in accordance with some embodiments.
  • FIG. 8 illustrates additional examples layers, example protocols and example operations in accordance with some embodiments.
  • the examples shown in FIGs. 6-8 may illustrate some or all of the concepts and techniques described herein in some cases, but embodiments are not limited by the examples. For instance, embodiments are not limited by the name, number, type, size, ordering, arrangement and/or other aspects of the operations, layers, subsystems, voice packets, network protocol headers, PDCP packets and other elements as shown in FIGs. 6-8. Although some of the elements shown in the examples of FIGs. 6-8 may be included in a 3GPP LTE standard and/or other standard, embodiments are not limited to usage of such elements that are included in standards.
  • Audio encoder operation(s) may be performed at operation 610. These operations may be performed by the UE 102, an apparatus of the UE 102 or by external component(s). Protocols and/or protocol layers such as RTP 615, UDP 620, IP 625, PDCP 630, RLC 640, MAC 645, PHY (Layer 1 ) 650 and/or others may be performed. In addition, RoHC 635 may be performed. In some embodiments, the RoHC 635 may be part of the PDCP layer,
  • a device (UE 102, eNB 104 or other) 655 may include subsystem(s) that may perform related operations.
  • the audio subsystem 665 may include a voice codec (vocoder, speech encoder and/or other) 665.
  • the RTP stack 670 and the UDP/IP stack 675 may be used in a data plane 690 for the audio payload.
  • the cellular protocol stack 680 may perform one or more operations such as 682, 684, 686, 688, 690 and/or other(s).
  • the audio speech/silence message 692 may be used to communicate information (silence indicators and/or other), in some cases.
  • a VoLTE call may be ongoing at the UE 102, m some cases.
  • the UE 102 may transmit a PDCP packet with sequence number (SN) of "X" which may correspond to an audio speech packet (voice packet) with SN of "N" at 710.
  • a compressed header may also be sent.
  • the UE 102 may locally save an RTP/UDP/IP header (network protocol header) of the audio packet sent at 710, For instance, a version of the network protocol header without RoHC may be saved.
  • the UE 102 may determine that the network protocol header without RoHC may be sent.
  • Reasons may include RoHC feedback, periodic refresh and/or other. It should be noted that the header without the compression of the RoHC may be referred to, for convenience, as an
  • the network protocol header without RoHC may be sent at 730 in a PDCP packet that does not include and/or is not based on an audio speech packet.
  • a next audio speech packet (with SN of "N+l ”) may be sent.
  • audio silence may begin.
  • the UE 102 may send an audio speech packet.
  • the eNB 104 may respond with RoHC feedback.
  • the UE 102 may determine that a PDCP packet with a network protocol header without the compression of the RoHC is to be sent. In some cases, a separate PDCP packet may not be sent. For instance, during silence periods, an audio payload may be small, and a network protocol header without the compression of the RoHC may fit within a block size.
  • an audio speech packet (of a silence period) and the network protocol header without the compression of the RoHC may be sent.
  • the device may include an audio sub-system 820, which may perform one or more operations such as determination of a codec rate/type 825.
  • a data plane (indicated by 810) may be used to communicate audio payloads between the audio sub-system 820 and the cellular protocol stack 850, in some cases. The determination may be performed according to the radio bandwidth and protocol header compression activation status and/or other factor(s). Radio bandwidth indication 812, RoHC status 814 and/or other information may be determined by the cellular protocol stack 850 at 855, and may be sent to the audio sub-system 820.
  • An RTP stack 830 and UDP/IP stack 840 may also perform one or more operations.
  • FIG. 9 illustrates the operation of another method of
  • embodiments of the method 900 may include additional or even fewer operations or processes in comparison to what is illustrated in FIG. 9 and embodiments of the method 900 are not necessarily limited to the chronological order that is shown in FIG. 9.
  • embodiments of the method 900 may be applicable to UEs 102, eNBs 104, APs, STAs and/or other wireless or mobile devices.
  • the method 900 may also be applicable to an apparatus for a UE 102, eNB 104 and/or other device described above.
  • an eNB 104 may perform one or more operations of the method 900, but embodiments are not limited to performance of the method 900 and/or operations of it by the eNB 104. In some embodiments,
  • the UE 102 may perform one or more operations of the method 900 (and/or similar operations). Accordingly, although references may be made to performance of one or more operations of the method 900 by the eNB 104 in descriptions herein, it is understood that the UE 102 may perform the same operation(s), similar operation(s) and/or reciprocal operation(s), in some embodiments.
  • the method 900 may be practiced by an eNB 104 and may mciude exchanging of elements, such as frames, signals, messages and/or other elements, with a UE 102.
  • the method 500 may be practiced by a UE 102 and may include exchanging of such elements with an eNB 104.
  • operations and techniques described as part of the method 500 may be relevant to the method 900.
  • embodiments of the method 900 may include one or more operations performed by the eNB 104 that may be the same as, similar to or reciprocal to one or more operations described herein performed by the UE 102 (including but not limited to operations of the method 500).
  • an operation of the method 900 may be the same as or similar to an operation of the method 500.
  • an operation of the method 900 may include a downlink transmission by the eNB that is similar to an uplink transmission by the UE 102 included in the method 500,
  • the eNB 104 may exchange one or more control messages with the UE 102. Accordingly, the eNB 104 may transmit one or more control messages to the UE 102 and/or receive one or more control messages from the UE 102.
  • the control niessage(s) may include any suitable information related to communication between the UE 102 and the eNB, including but not limited to an establishment of connectivity between the UE 102 and the eNB 104, voice codec information, header compression information and/or other.
  • the eNB 104 may compress network protocol headers in accordance with a robust header compression (RoHC).
  • RoHC robust header compression
  • the eNB 104 may generate a sequence of PDCP packets.
  • the eNB 104 may transmit the sequence of PDCP packets.
  • determine whether the RoHC is to be resynchronized determine whether the RoHC is to be resynchronized.
  • the eNB 104 may determine and/or detect one or more silence periods.
  • the eNB 104 may restrict transmission of the resynchronization PDCP packet to one of the silence periods. It should be noted that embodiments may not necessarily include all operations shown in FIG. 5. For instance, the determination and/or detection of the silence period(s) and restriction of the resynchronization PDCP packet to the silence period(s) may not necessarily be performed in some embodiments.
  • the eNB 104 may receive an SNR
  • the eNB 104 may adapt a voice codec rate. It should be noted that embodiments may not necessarily include all operations shown in FIG. 9. For instance, the reception of the SNR measurement and/or the adaption of the voice codec rate may not necessarily be performed in some embodiments.
  • a 3GPP protocol may use one or more techniques that may enable cellular Internet of Things. Examples of such techniques may include Cat Ml, Cat NB1 and/or other.
  • voice communication in accordance with Cat NBl or Cat Ml may be challenging. For instance, a packet size of the voice communication may be larger than a maximum number of bits and/or allocated number of bits.
  • TBS Transport Block Size
  • RoHC robust header compression
  • a full header (and/or non-compressed header) may be sent (i.e., transmission without RoHC).
  • the header compressor at the transmit side may send the full header information as part of the "Refresh and re-initialization" of session context (i.e., transmission without RoHC).
  • a periodic refresh of the RoHC context (for instance, when RoHC mode is uni-directional) may be performed.
  • a target signal-to-noise ratio (SNR) of 0 dB may be used for a same coverage level that is achievable by Uplink Cat 1 (such as approximately 140 dB of Maximum Coupling Loss (MEL)).
  • MEL Maximum Coupling Loss
  • a number of repetitions may be used to achieve a performance level. Note that repetitions may correspond to packets being repeated multiple times in subsequent subframes in order to improve an SNR and a probability of successful decoding. If after a certain amount of physical layer repetitions, the packet cannot be decoded successfully, additional transmissions may be possible through the use of techniques such as hybrid automatic repeat request (HARQ) and/or other.
  • HARQ hybrid automatic repeat request
  • a codec (audio, video and/or other) may not be supported, such as when the TBS for the codec may be too large.
  • uncompressed headers may correspond to 60 bytes while compressed headers may correspond to 3 bytes.
  • the header can be compressed, there may be a saving of 456 bits (for a basic case of 20ms pavload aggregation).
  • the compression may reduce an amount of repetitions used for some codecs and may also enable support of some codecs that otherwise may not necessarily be supported.
  • IoT techniques may be used with aim to reduce cost and complexity by trading off data rate, latency, bandwidth and/or other factor(s).
  • IoT techniques may be used in accordance with a
  • 3GPP protocol including but not limited to Rel-13.
  • Non-limiting examples include Cat Ml and Cat NBl.
  • a Cat Ml technique may be able to support VoLTE, for instance with limited coverage if a normal call quality should be maintained (approx. 4-10 dB coverage limitation for WB-AMR codecs depending on the hannel conditions wit legacy Cat 1 devices (POLQA ⁇ 4 and latency ⁇ 50ms) and with limited voice quality due to low codec rate.
  • NB-IoT may not efficiently support near real time services such as VoLTE with reasonable coverage level and reasonable performance.
  • One reason may be a limitation in terms of data rate which would require high latency in order to support voice with reasonable coverage.
  • a feature of Cat Ml and Cat NB1 is the possibility to extend coverage to a certain extent. This may be achieved via the use of repetitions at the physical layer, in which a packet may be repeated in subsequent sub-frames in order to increase the SNR. Repetitions can be used to compensate for the coverage loss due to one or more factors, such as the use of a single receive antenna, a reduced transmit power (in comparison to other arrangements, categories and/or protocols, including but not limited to legacy Cat 1 devices) and/or other factor(s).
  • the repetitions can be used in order to achieve higher coverage compared to what may be achieved in other arrangements, categories and/or protocols, including but not limited to legacy Cat 1 devices.
  • the use of repetitions may be challenging and/or problematic when near real time services such as voice are to be supported.
  • codec rates that can be supported may depend on a target coverage level.
  • a 20 millisecond speech packet length may be supported with possibly some quality degradation while at least AMR-WB 6.6 and 8.85 kbps codec rates with 40 millisecond codec frame bundling (aggregation level at RTP layer) may be supported.
  • codec rates may be possible in some cases.
  • a number of repetitions may be too large compared to an inter transmission time (this is a function of the code rate and hence the TBS and the SNR target).
  • a number of bits to be transmitted may be higher than a parameter, such as a maximum TBS size of 1000 bits, other maximum TBS size and/or other number. It may be beneficial if a packet size is reduced as much as possible.
  • One contributor to the packet size is the header. When RoHC is used, the header may be reduced from 60 bytes to 3 bytes, with more than 450 bits saved in some cases.
  • RoHC robust header compression
  • usage of robust header compression may not necessarily be used in some cases, including cases in which a radio bearer is established and the PDCP configuration is also provided.
  • usage of RoHC may not be configured and when the UE 102 is in a bandwidth reduced mode (such as Cat Ml) only limited codec types may be possible with coverage level similar to legacy systems as explained above.
  • the protocol headers may not necessarily be compressed for every packet.
  • An uncompressed header may be sent in some cases, including but not limited to the example cases that follow.
  • a full header may be sent (i.e., transmission without protocol header compression).
  • feedback sent by the receiver may indicate a
  • RoHC header decompression issue may occur due to packet loss, such as in a case of VoLTE packet failures at the PHY layer (such as after HARQ with no ARQ at RLC or application layer for VoLTE).
  • a periodic refresh of the RoHC context may be performed, including but not limited to cases in which a RoHC mode is uni-directional.
  • the protocol headers may ⁇ be sent in packets that are separate from packets used to send voice payloads. This may be called a "split header method" or similar, although the scope of embodiments is not limited in this respect.
  • Such techniques may be enabled upon request or when there is, for example, a limitation in terms of bandwidth as explained in some scenarios herein. Such techniques may maximize and/or increase a number of cases in which a PDCP packet fits in the resource blocks allocated in one transmission opportunity even in cases in which a PDCP packet is to be sent with uncompressed protocol header.
  • an uncompressed header may be sent. For instance, for initial RoHC context initialization or due to periodic RoHC context update or due to RoHC context recover ⁇ ' following RoHC feedback or other.
  • the uncompressed header may be sent in a separate PDCP packet without a user payload.
  • a next PDCP packet may include the user payload with a compressed header, in some cases, the uncompressed header may be restricted to PDCP packets separate from PDCP packets that include a payload. Accordingly, a maximum transport block size (such as 1000 bits or other) may not necessarily be reached.
  • operations such as RLC segmentation and/or other may be avoided.
  • a potential benefit for V oLTE communication may be a capability to use additional audio rates, which may enhance user experience (through better voice quality) in some cases.
  • an uncompressed header may be sent in a separate PDCP packet without user payload.
  • the next PDCP packet may contain the user payload with a compressed header.
  • a maximum transport block size such as 1000 bits or other
  • RLC segmentation may be avoided in some cases.
  • a potential benefit (such as for VoLTE or other) may be a capability to use additional audio rates, which may enhance user experience (better voice quality) in some cases.
  • a device may perform one or more of the operations that follow.
  • the PDCP/RoHC entity may save a copy of the protocol headers of the latest transmitted packet.
  • the protocol header(s) to be saved may depend on the RoHC profile used. In a non-limiting example, for V oLTE, profile 0x001
  • the PDCP/RoHC entity may transmit a PDCP packet that includes the uncompressed saved protocol header of the latest transmitted audio packet, but excludes a voice payload.
  • a next audio packet may then be sent that may include a compressed header and may also include a voice payload.
  • the resynchronization may be triggered immediately (such as when a current audio packet is to be sent).
  • the PDCP may generate a PDCP packet with an uncompressed header (such as without compression of the RoHC) using the last (previous) transmitted audio packet. In such a case, no IP packet may be received from upper layer(s).
  • the PDCP may have decided (on its own) to build and send a resynchronization packet.
  • the header may be a network protocol header or other.
  • the resynchronization may be triggered when a next audio packet is to be sent.
  • the resynchronization packet may be sent when an IP packet that includes an audio packet is to be sent.
  • the PDCP may send a first PDCP packet that includes the uncompressed header (such as a network protocol header without the compression of the RoHC) of the IP packet.
  • the PDCP may send another PDCP packet that includes the audio packet (IP payload) with or without a compressed protocol header.
  • the RoHC decompressor upon reception of a PDCP packet that includes containing the uncompressed headers, the RoHC decompressor resynchronize the RoHC context.
  • the data can be dropped once the RoHC context resynchronization is complete. This can be done by the respective protocol layer considering there is no payload.
  • a flag can be set in the PDCP header to indicate the PDCP entity on receiver side to drop the data on the RoHC context is synchronized.
  • the uncompressed header may be sent in a PDCP packet.
  • the next PDCP packet may include the user payload with the compresses proiocol header. This method may simplify one or more operations of the receiver, which may use the uncompressed header to synchronize the RoHC context and may send one or more subsequent PDCP packets with compressed headers.
  • the uncompressed packet may be sent at any suitable time.
  • the packet following the PDCP packet with the uncompressed header, the next PDCP packet may include the payload with compressed protocol header.
  • the receiver may reconstruct the IP packet by concatenating the uncompressed header received in one PDCP packet and the user payload received in the next PDCP packet.
  • an indicator may be required in the PDCP header to indicate that this PDCP packet shall be concatenated with the next one.
  • a potential benefit of this method may be to avoid to transmit two times the same protocol headers: one time uncompressed and one time compressed.
  • the split of uncompressed header and user payioad during audio silence phases may be avoided.
  • a first PDCP packet may include an uncompressed network protocol header (such as a network protocol header without the compression of the RoHC).
  • a next P DCP packet may include payioad without a header.
  • an IP packet that includes an audio packet may be received in a PDCP entity.
  • the PDCP entity may build and send a first PDCP packet that includes the uncompressed protocol header only (for instance, IP/UDP/RTP header) of the IP packet.
  • a next PDCP packet may include the audio packet only (without the protocol header).
  • the receiver PDCP may concatenate protocol header and audio packet before sending the IP packet to the IP stack.
  • one or more indicators may be used (such as one or more bits included in a PDCP header of a PDCP packet) to indicate to a receiving entity that the PDCP packet contains an uncompressed network protocol header (such as a network protocol header without the compression of the RoHC). Accordingly, the PDCP payioad may be used (by the receiving entity) for RoHC context resynchronization and may be dropped after the resynchronization.
  • the PDCP of a sender may include an indicator (such as in the PDCP header) that indicates that the PDCP of a receiver (receiving entity) is to concatenate a payioad with a next PDCP packet.
  • a first PDCP packet (PDCP[ SN
  • the sender may set a bit in the PDCP header of PDCP [SN] to indicate that the payioad is to be concatenated with a payioad of a second PDCP packet (PDCP[SN+1]).
  • the second PDCP packet may be a next PDCP packet after the first PDCP packet in a sequence of PDCP packets.
  • the second PDCP packet may include an audio packet as payioad.
  • the receiver may concatenate the uncompressed header and the audio packet before delivering to one or more upper layers.
  • the uncompressed header may be based on one or more of IP, RTP, UDP and/or other.
  • the PDCP header may be re-synced (re- synchronized) during an audio silence phase. In case of audio silence, as the size of the audio packet is much smaller, there is no need to send an extra PDCP packet with uncompressed RTP/UDP/IP header only.
  • a usual PDCP packet containing the uncompressed header and user pay load can be sent.
  • the audio silence detection may be done by packet inspection for instance in the PDCP layer or upon direct notification from the audio sub-system to the PDCP.
  • audio silence phases may be used for periodic re-synchronization of the header.
  • audio silence phase may be used for re- synchronization of the headers to reduce the probability of requiring the uncompressed header transmission during speech phases.
  • the RoHC context refresh may be aligned (or at least aligned as much as possible) to the silence period. This may be beneficial when RoHC is configured in unidirectional mode. For instance, if the start of an audio silence sequence is detected and the periodic RoHC context refresh timer is running whose expir ' would lead to enter the RoHC compressor IR (initialization and Refresh) State, then an uncompressed header may be sent and the timer RoHC context refresh may be restarted. This may also be beneficial for optimistic and reliable RoHC mode, such as in case of bad radio conditions. When bad radio condition is faced, uncompressed header may be sent periodically during audio silence even if no feedback is received. This may help to anticipate potential RoHC decompression issues due to packet loss at receiver side.
  • a method for codec rate adaptation to radio parameters and RoHC usage via the communication between audio subsystem and cellular protocol stack may be performed.
  • a direct communication may be established between the audio subsystem and the radio access technology in order to optimize the audio configuration, for instance the audio codec rate according to the radio link configuration.
  • Example parameters which could be exchanged may include, but are not limited to:
  • the audio subsystem may use this information in order to perform operation(s) such as adaptation of the codec rate to the available system bandwidth.
  • the Cellular protocol stack could trigger the use of other methods described herein, in some cases.
  • the audio subsystem may trigger the use of one or more of the methods described herein (instead of this being performed by the cellular protocol stack). In some embodiments, any combination of the above may be used.
  • techniques, methods and/or operations described herein may be performed not only in normal VoLTE communication when the codec is assumed to be fixed but also in a case when the codec can be dynamically changed during speech communication.
  • the communication may start with a low codec rate to make sure that when the communication starts the use of uncompressed headers does not break a TBS limitation (1000 bits or other suitable value).
  • the codec rate can be changed during the call to adapt the channel conditions, available bandwidth, use of RoHC and/or other factor(s).
  • the communication between the audio subsystem and the cellular protocol stack may trigger the use of the split header method as described in one or more methods herein. This may enable optimization of the codec type based on the maximal use of the radio resources, in some cases.
  • the beginning of the communication may start with a low codec rate (such as 4.75 kbps AMR-NB codec) and with usage of an uncompressed header (without the compression of the RoHC) together with voice payload.
  • a low codec rate such as 4.75 kbps AMR-NB codec
  • the protocol header may be compressed and the codec rate may be increased.
  • a link between the audio subsystem and the cellular protocol stack may be used for exchanging of information.
  • a method in the eNB 104, UE 102 or other device may enable decoupling the transmission of the uncompressed headers (without compression of the RoHC) and the payload (voice packets and/ or other). For instance, the uncompressed header (without compression of the RoHC) may be sent in a separate PDCP packet without the payload.
  • a PDCP/RoHC entity may and/or shall: when sending an IP packet, PDCP/RoHC entity may and/or shall save a copy of the protocol headers of the latest transmitted packet. The protocol headers to save may depend on the RoHC profile used.
  • the PDCP/RoHC entity may transmit a PDCP packet containing the uncompressed saved protocol header of the latest transmitted audio packet. In some cases, no payload may be sent (PDCP/RoHC may refrain from inclusion of payload). The next audio packet may then be sent normally with compressed header.
  • the RoHC decompressor may resynchronize the RoHC context. In some cases, a flag may be set m the PDCP header to indicate to the PDCP entity on receiver side whether to drop the data, which may be based on whether the RoHC context is synchronized. For instance, the flag may be represented by a bit that indicates if the packet is a "header only" packet (such as a packet without the voice payload).
  • the header may be decoupled with respect to the payload since the start of the communication. In some embodiments, the header may be decoupled with respect to the payload only when the call has been established after an initial transitory.
  • the codec may be dynamically changed during speech communication. For instance, the communication may start with a low codec to make sure that when the communication starts the use of uncompressed headers does not break a TBS size (limitation). For instance, a value of 1000 bits may be used. The codec rate may be changed during the call to adapt the conditions.
  • conditions that may trigger changes in the codec rate may include, but are not limited to: the bandwidth, the PDCP configuration, (ROHC enabled or not), support of coverage extension, number of repetitions, whether single or multiple HARQ transmissions are used/possible, TBS size/limitation and/or other.
  • a communication may be established between the audio subsystem and the cellular protocol stack.
  • information that may be exchanged may include bandwidth, the PDCP configuration, (ROHC enabled or not), support of coverage extension, number of repetitions, whether single or multiple HARQ transmissions are used/possible, TBS size/limitation and/or other.
  • the PDCP packet containing the user payioad follows the PDCP packet containing the uncompressed protocol header only and contains the compressed protocoi header. In some embodiments, the PDCP packet containing the user payioad follows the PDCP packet containing the uncompressed protocol header only, and does not contain the compressed proiocol header. In some embodiments, the uncompressed header without user payioad may be sent during speech sequence only. In some embodiments, the device (UE 102, e ' NB 104 or other) may be informed via signaling/flag whether a packet contains uncompressed header only without payioad.
  • the device may be informed via signaling/flag whether a packet contains payioad only without any header.
  • any combination of IP, UDP and RTP headers may be used.
  • the device may align the uncompressed header sending to the audio speech silence period.
  • an uncompressed header may be sent upon start of audio silence sequence.
  • the audio silence detection may be done by packet inspection in the sender or upon notification from upper iayer(s).
  • an apparatus of a User Equipment may comprise memory.
  • the apparatus may further comprise processing circuitry.
  • the processing circuitry may be configured to compress, as part of a robust header compression (RoHC), network protocol headers corresponding to a sequence of voice packets.
  • the processing circuitry may be further configured to generate, for transmission, a sequence of packet data convergence protocol (PDCP) packets that include the voice packets and the corresponding network protocol headers compressed as part of the RoHC.
  • the processing circuitry may be further configured to determine that the RoHC is to be resynchronized between first and second PDCP packets that are consecutive within the sequence of PDCP packets.
  • RoHC robust header compression
  • PDCP packet data convergence protocol
  • the processing circuitry may be further configured to generate, for transmission between the first and second PDCP packets, a ⁇ synchronization PDCP packet to resynchronize the RoHC.
  • the first PDCP packet may include a first voice packet of the sequence of voice packets and a corresponding first network protocol header compressed as part of the RoHC.
  • the resynchronization PDCP packet may include the first network protocol header and excludes the first voice packet.
  • Example 2 the subject matter of Example 1, wherein the resynchronization PDCP packet raay include the first network protocol header without the compression of the RoHC.
  • the PDCP packets of the sequence of PDCP packets may include the network protocol headers compressed as part of the RoHC, may include the voice packets, and may exclude the network protocol headers without the compression of the RoHC.
  • Example 3 the subject matter of one or any combination of
  • Examples 1 -2 wherein the sequence of voice packets may be sent as part of an intemet-of-things (loT) communication.
  • the processing circuitry may be further configured to select a voice packet size based on a maximum transport block size (TBS) of the IoT communication.
  • TBS transport block size
  • Example 4 the subject matter of one or any combination of Examples 1-3, wherein a category of the IoT communication may be one of category Ml (Cat Ml) or category NB1 (Cat NB1).
  • the maximum TBS may be based at least partly on the IoT category of the IoT communication.
  • Example 5 the subject matter of one or any combination of Examples 1 -4, wherein the processing circuitry may be further configured to select the voice packet size as a value for which a summation is less than or equal to the maximum TBS.
  • the summation may include at least the voice packet size and a compressed network protocol header size.
  • Example 6 the subject matter of one or any combination of Examples 1 -5, wherein the sequence of PDCP packets may be generated for transmission in one or more physical resource blocks (PRBs) reserved for IoT communication.
  • PRBs physical resource blocks
  • the TBS of the IoT communication may be based at least partly on a number of PRBs reserved for the IoT communication.
  • Example 7 the subject matter of one or any combination of Examples 1-6, wherein the processing circuitry may be further configured to determine that the RoHC is to be resynchronized between the first and second PDCP packets based on a predetermined resynchronization interval of the RoHC during which at least one network protocol header without the compression of the RoHC is to be transmitted to resynchronize the RoHC.
  • Example 8 the subject matter of one or any combination of Examples 1-7, wherein the processing circuitry may be further configured to determine whether a silence period of the sequence of voice packets occurs based at least partly on one or more silence indicators of the voice packets. The processing circuitry may be further configured to determine whether the RoHC is to be resynchronized based at least partly on whether the silence period occurs.
  • Example 9 the subject matter of one or any combination of
  • processing circuitry may be further configured to determine one or more silence periods of the sequence of voice packets based at least partly on one or more silence indicators of the voice packets.
  • the processing circuitry may be further configured to restrict transmission of the resynchronization PDCP packet to one of the silence periods.
  • Example .10 the subject matter of one or any combination of Examples 1-9, wherein the processing circuitry may be further configured to restrict the network protocol headers without the compression of the RoHC to the PDCP packets that are generated for transmission during the silence periods.
  • Example 11 the subject matter of one or any combination of Examples 1 -10, wherein the processing circuitry may be further configured to generate, for transmission, transport blocks based on repetition of the PDCP packets of the sequence of PDCP packets or forward error correction (FEC) applied to the PDCP packets of the sequence of PDCP packets.
  • FEC forward error correction
  • the subject matter of one or any combination of Examples 1 -1 1, w herein the second PDCP packet may include a second voice packet of the sequence of voice packets and a corresponding second network protocol header compressed as part of the RoHC.
  • the processing circuitry may ⁇ be further configured to compress, as part of the RoHC, the second network protocol header based at least partly on a comparison with the first network protocol header.
  • Example 13 the subject matter of one or any combination of
  • the UE may be arranged to operate in accordance with a Third Generation Partnership Project (3GPP) Long Term Evolution (LTE) protocol.
  • 3GPP Third Generation Partnership Project
  • LTE Long Term Evolution
  • the PDCP packets may be generated for transmission as part of a voice over Long Term Evolution (VoLTE) communication.
  • the network protocol headers may be based on one or more of an internet protocol (IP), universal datagram protocol (UDP), and real-time transport protocol (RTP).
  • IP internet protocol
  • UDP universal datagram protocol
  • RTP real-time transport protocol
  • Example 14 the subject matter of one or any combination of
  • Examples 1 -13 wherein the processing circuitry may be further configured to generate, for transmission as part of an initialization of the RoHC, a
  • the synchronization PDCP packet may include a network protocol header without the compression of the RoHC.
  • the synchronization PDCP packet may exclude the voice packets of the sequence.
  • Example 15 the subject matter of one or any combination of Examples 1 -14, wherein the memory may be configurable to store the first network protocol header for usage in the generation of the resynchronization PDCP packet.
  • Example 16 the subject matter of one or any combination of Examples 1-15, wherein the apparatus may further include a transceiver to transmit the sequence of PDCP packets.
  • Example 17 the subject matter of one or any combination of Examples 1 -16, wherein the processing circuitry may include a baseband processor to compress the network protocol headers and to determine that the RoHC is to be resynchronized.
  • a non-transitory computer-readable storage medium may store instructions for execution by one or more processors to perform operations for communication by an Evolved Node-B (eNB).
  • the operations may configure the one or more processors to detect one or more silence periods based on sil ence indicators of a sequence of voice packets, wherein the voice packets and corresponding network protocol headers are to be transmitted as part of a voice communication.
  • the operations may further configure the one or more processors to compress at l east some of the network protocol headers in accordance with a robust header compression (RoHC).
  • RoHC robust header compression
  • the operations may further configure the one or more processors to generate, for transmission, a sequence of packet data convergence protocol (PDCP) packets.
  • PDCP packet data convergence protocol
  • Each PDCP packet may include one of the voice packets and the corresponding compressed network protocol header or may include the corresponding network protocol header without the compression of the RoHC.
  • the network protocol headers without the compression of the RoHC may be restricted to the PDCP packets of the silence periods.
  • the operations may further configure the one or more processors to sel ect one or more of the PDCP packets of the silence period that are to include the network protocol headers without the compression of the RoHC.
  • Example 19 the subject matter of Example 18, wherein the sequence of PDCP packets may be transmitted as part of an internet-of-things (IoT) communication.
  • the operations may further configure the one or more processors to repeat the PDCP packets in accordance with a predetermined number of repetitions or to apply forward error correction (FEC) to the PDCP packets in accordance with a predetermined FEC coding rate.
  • FEC forward error correction
  • predetermined number of repetitions and the predetermined FEC coding rate may be based on a target performance level of the IoT communication.
  • Example 20 the subject matter of one or any combination of Examples 18-19, wherein the operations may further configure the one or more processors to determine whether an RoHC context refresh timer is active at a beginning of a particular silence period. The operations may further configure the one or more processors to, if the RoHC context refresh timer is active at the beginning of the particular silence period, select one of the PDCP packets of the particular silence peri od to include one of the network protocol headers without the compression of the RoHC.
  • each PDCP packet may further include an indicator of whether the PDCP packet includes one of the network protocol headers without the compression of the RoHC.
  • Example 22 the subject matter of one or any combination of Examples 18-21, wherein for at least a particular PDCP packet that includes a particular network protocol header without the compression of the RoHC, the particular PDCP packet may further include an indicator of whether the particular network protocol header without the compression of the RoHC is to be dropped or concatenated with a voice packet included in a next PDCP packet.
  • an apparatus of a User Equipment may comprise memory.
  • the apparatus may further comprise processing circuitry.
  • the processing circuitry may be configured to generate, for transmission, a sequence of packet data convergence protocol (PDCP) packets based on a first sequence of voice packets and corresponding network protocol headers compressed in accordance with a robust header compression (RoHC).
  • the first sequence of voice packets may be formatted in accordance with a first value of a voice codec rate.
  • the sequence of PDCP packets may be sent as part of an internet-of-things (IoT) communication.
  • IoT internet-of-things
  • the processing circuitry may be further configured to decode a signal to noise ratio (SNR) measurement from an Evolved Node-B (eNB) based on the sequence of PDCP packets.
  • the processing circuitry may be further configured to adapt the voice codec rate from the first value to a second value to be used, by a voice codec entity, for a second sequence of voice packets, the voice codec rate adapted based at least partly on a target SNR for the IoT communication and a maximum transport block size (TBS) of the IoT communication.
  • SNR signal to noise ratio
  • eNB Evolved Node-B
  • Example 24 the subject matter of Example 23, wherein the processing circuitry may be further configured to determine that the RoHC is to be resynchronized.
  • the processing circuitry may be further configured to generate, for transmission between first and second PDCP packets of the sequence of PDCP packets, a resynchronization PDCP packet to resynchronize the RoHC.
  • the resynchronization PDCP packet may be based o the network protocol header of the first PDCP packet without the compression of the RoHC.
  • Example 25 the subject matter of one or any combination of Examples 23-24, wherein the processing circuitry may be further configured to determine that the RoHC is to be resynchronized based on a predetermined resynchronization interval of the RoHC during which at least one network protocol header without the compression of the RoHC is to be transmitted to resynchronize the RoHC.
  • Example 26 the subject matter of one or any combination of Examples 23-25, wherein the processing circuitry may be further configured to determine whether a silence period of the sequence of voice packets occurs based at least partly on one or more silence indicators of the voice packets. The processing circuitry may be further configured to determine that the RoHC is to be resynchronized based at least partly on whether the silence penod occurs.
  • an apparatus of an Evolved Node-B may comprise means for detecting one or more silence periods based on silence indicators of a sequence of voice packets, wherein the voice packets and corresponding network protocol headers are to be transmitted as part of a voice communication.
  • the apparatus may further comprise means for compressing at least some of the network protocol headers in accordance with a robust header compression (RoHC).
  • the apparatus may further comprise means for generating, for transmission, a sequence of packet data convergence protocol (PDCP) packets.
  • PDCP packet data convergence protocol
  • Each PDCP packet may include one of the voice packets and the corresponding compressed network protocol header or may include the corresponding network protocol header without the compression of the RoHC.
  • the network protocol headers without the compression of the RoHC may be restricted to the PDCP packets of the silence periods.
  • the apparatus may further comprise means for selecting one or more of the PDCP packets of the silence period that are to include the network protocol headers without the compression of the RoHC,
  • Example 28 the subject matter of Example 27, wherein the sequence of PDCP packets may be transmitted as part of an internet-of-things (loT) communication.
  • the apparatus may further comprise means for repeating the PDCP packets in accordance with a predetermined number of repetitions or for applying forward error correction (FEC) to the PDCP packets in accordance with a predetermined FEC coding rate.
  • FEC forward error correction
  • the predetermined number of repetitions and the predetermined FEC coding rate may be based on a target performance level of the IoT communication.
  • Example 29 the subject matter of one or any combination of Examples 27-28, the apparatus further comprising means for determining whether an RoHC context refresh timer is active at a beginning of a particular silence period.
  • the apparatus may further comprise means for selecting, if the RoHC context refresh timer is acti v e at the beginning of the particular silence penod, one of the PDCP packets of the particular silence period to include one of the network protocol headers without the compression of the RoHC.
  • each PDCP packet may further include an indicator of whether the PDCP packet includes one of the network protocol headers without the compression of the RoHC.
  • Example 31 the subject matter of one or any combination of Examples 27-30, wherein for at least a particular PDCP packet that includes a particular network protocol header without the compression of the RoHC, the particular PDCP packet may further include an indicator of whether the particular network protocol header without the compression of the RoHC is to be dropped or concatenated with a voice packet included in a next PDCP packet.

Abstract

La présente invention concerne un équipement utilisateur (EU), un nœud B évolué (eNB) et des procédés de communication. L'UE peut compresser des en-têtes de protocole de réseau selon une compression robuste des en-têtes (RoHC), les en-têtes de protocole de réseau correspondant à une séquence de paquets vocaux. L'UE peut transmettre une séquence de paquets du protocole de convergence de données par paquets (PDCP), lesquels sont basés sur un codage des paquets vocaux et des en-têtes de protocole de réseau compressés correspondants, selon un taux de redondance prédéterminé par paquet PDCP. L'UE peut déterminer si la RoHC doit être resynchronisée et peut transmettre un paquet du protocole PDCP de resynchronisation pour resynchroniser la RoHC. Le paquet du protocole PDCP de resynchronisation peut être basé sur un en-tête de protocole de réseau sans compression du RoHC.
PCT/US2017/016180 2016-08-02 2017-02-02 Équipement utilisateur (ue), nœud b évolué (enb) et procédés de communication voix sur lte (volte) selon une compression robuste des en-têtes (rohc) WO2018026393A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662369854P 2016-08-02 2016-08-02
US62/369,854 2016-08-02

Publications (1)

Publication Number Publication Date
WO2018026393A1 true WO2018026393A1 (fr) 2018-02-08

Family

ID=61073053

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2017/016180 WO2018026393A1 (fr) 2016-08-02 2017-02-02 Équipement utilisateur (ue), nœud b évolué (enb) et procédés de communication voix sur lte (volte) selon une compression robuste des en-têtes (rohc)

Country Status (1)

Country Link
WO (1) WO2018026393A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110875916A (zh) * 2018-09-04 2020-03-10 大唐移动通信设备有限公司 一种语音数据的传输方法和网络设备
CN110945909A (zh) * 2018-05-18 2020-03-31 苹果公司 边缘无线覆盖范围中的压缩器状态和解压器状态的快速同步

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090052453A1 (en) * 2007-08-22 2009-02-26 Minkyu Lee Method and apparatus for improving the performance of voice over IP (VoIP) speech communications systems which use robust header compression (RoHC) techniques
US20090311996A1 (en) * 2008-06-13 2009-12-17 Fujitsu Limited Content distributing system, content distributing apparatus, terminal device and content distributing method
US20110306309A1 (en) * 2009-03-19 2011-12-15 Fujitsu Limited Receiving apparatus, transmitting apparatus, receiving method, transmitting method, communications system, and communication method
US20150016320A1 (en) * 2005-06-21 2015-01-15 Ootis Wireless Technology, LLC Dynamic robust header compression

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150016320A1 (en) * 2005-06-21 2015-01-15 Ootis Wireless Technology, LLC Dynamic robust header compression
US20090052453A1 (en) * 2007-08-22 2009-02-26 Minkyu Lee Method and apparatus for improving the performance of voice over IP (VoIP) speech communications systems which use robust header compression (RoHC) techniques
US20090311996A1 (en) * 2008-06-13 2009-12-17 Fujitsu Limited Content distributing system, content distributing apparatus, terminal device and content distributing method
US20110306309A1 (en) * 2009-03-19 2011-12-15 Fujitsu Limited Receiving apparatus, transmitting apparatus, receiving method, transmitting method, communications system, and communication method

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MATE TOMOSKOZI ET AL.: "Performance Evaluation of Network Header Compression Schemes for UDP, RTP and TCP", PERIODICA POLYTECHNICA ELECTRICAL ENGINEERING AND COMPUTER SCIENCE, vol. 60, no. 3, 20 April 2016 (2016-04-20), pages 151 - 162, XP055461438, Retrieved from the Internet <URL:https://pp.bme.hu/eecs/article/view/8958> *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110945909A (zh) * 2018-05-18 2020-03-31 苹果公司 边缘无线覆盖范围中的压缩器状态和解压器状态的快速同步
CN110945909B (zh) * 2018-05-18 2022-05-03 苹果公司 边缘无线覆盖范围中的压缩器状态和解压器状态的快速同步
CN110875916A (zh) * 2018-09-04 2020-03-10 大唐移动通信设备有限公司 一种语音数据的传输方法和网络设备

Similar Documents

Publication Publication Date Title
US11245480B2 (en) Devices and methods for robust measurement and data receiving
US11013063B2 (en) User equipment (UE), evolved node-b (eNB) and methods for dynamic hybrid automatic repeat request (HARQ)
US11737171B2 (en) 5G FDD low latency transmission subframe structure system and method of use
US11122580B2 (en) Evolved node-b (ENB), user equipment (UE) and methods for flexible duplex communication
US10516461B2 (en) Beam management for dual transmission point hybrid beamforming systems in 5G
US10560174B2 (en) Latency reduction for wireless data transmission
WO2017127126A1 (fr) Dispositifs et procédés pour fournir une requête de liaison montante 5g
US11122643B2 (en) LWIP enhancements for reliable DRB switching
US11082950B2 (en) User equipment (UE) and method of sidelink data communication in fifth generation (5G) new radio (NR) things networks
WO2018063436A1 (fr) Rapport de mesure comportant un nombre de faisceaux disponibles
EP3453131B1 (fr) Équipement d&#39;utilisateur (ue) et procédés de réception de paquets sur un support radio divisé
WO2017083025A1 (fr) Espace de découverte de dispositif à dispositif amélioré
WO2017058281A1 (fr) Équipement d&#39;utilisateur (ue) et procédés d&#39;enregistrement de services à commutation de circuit (cs) dans un fonctionnement multimode
WO2018026393A1 (fr) Équipement utilisateur (ue), nœud b évolué (enb) et procédés de communication voix sur lte (volte) selon une compression robuste des en-têtes (rohc)
WO2017131808A1 (fr) Nœud b évolué (enb), équipement d&#39;utilisateur (ue) et procédés de notification de trafic sur des connexions de réseau de données par paquets (pdn) délestées
WO2017171904A1 (fr) Dispositif et procédé pour une gestion de cycle de vie de nfv à l&#39;aide de fonctions de gestion de configuration
WO2017171898A1 (fr) Équipement utilisateur (ue), nœud b évolué (enb) et procédés de suspension et de reprise de liaisons de communication d&#39;un support radio
US11711448B2 (en) Compression schemes for relaying prior to decoding
CN115552820A (zh) 用于在解码前进行中继的信令

Legal Events

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

Ref document number: 17837336

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 17837336

Country of ref document: EP

Kind code of ref document: A1