Design of XR traffic information indication

Abstract

The present disclosure relates to the design of XR traffic information indication. Methods, apparatuses, and systems are disclosed for providing traffic information related to data traffic groups, e.g., for 3GPP XR communications. A UE can transmit a traffic flow that includes a particular type of data (e.g., video, audio, control / pose) generated by an application implemented on the UE, such as an augmented reality application. The traffic flow can include bursts of data traffic groups, where each group includes a plurality of data packets containing a functional set of data, such as data for encoding a single video frame. The UE can generate and transmit traffic information to a base station regarding the nature, status, performance, and / or constraints of the data traffic groups. The base station can use the traffic information to make intelligent scheduling decisions regarding the data traffic groups.

Description

[0001] Priority information

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 303,455, filed January 26, 2022, entitled “Design for XR Traffic Information Indication,” which is incorporated herein by reference in its entirety as fully and completely set forth herein. Technical Field

[0003] This application relates to wireless communications, and more specifically to systems, apparatus, and methods for providing information in cellular communications to support data traffic groups.

[0004] Related technical descriptions

[0005] The use of wireless communication systems is growing rapidly. In recent years, wireless devices such as smartphones and tablets have become increasingly sophisticated. Beyond supporting phone calls, many mobile devices (i.e., user equipment or UE) now offer access to the internet, email, text messaging, virtual reality, augmented reality, cloud gaming, and navigation using the Global Positioning System (GPS), and are capable of operating complex applications that utilize these and other features. Furthermore, many different wireless communication technologies and standards exist. Some examples of wireless communication standards include GSM, UMTS (e.g., associated with WCDMA or TD-SCDMA air interfaces), LTE, LTE-A (LTE-Advanced), NR, HSPA, 3GPP 2CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), IEEE 802.11 (WLAN or Wi-Fi), and BLUETOOTH. TM (BT), etc.

[0006] The increasing number of features and functionalities introduced into wireless communication devices has created a continuous demand for improvements in both wireless communication and the devices themselves. In particular, as UE devices improve to support specialized communication-intensive application capabilities, such as virtual reality and augmented reality capabilities, UEs and networks may require new processes to manage specialized data flows within the network. Therefore, improvements are expected in this area. Summary of the Invention

[0007] This paper presents implementation schemes for apparatus, systems, and methods for providing base stations with traffic information related to data traffic groups of traffic flows.

[0008] For example, a UE can transmit traffic streams including specific types of data (e.g., video, audio, control / gesture) generated by applications implemented on the UE (such as augmented reality applications). Traffic streams can include bursts of data traffic groups, where each group comprises multiple data packets containing a set of functions containing data (such as data used to encode individual video frames). The UE can generate traffic information about the nature, status, performance, and / or constraints of the data traffic groups and transmit it to the base station. The base station can use the traffic information to make intelligent scheduling decisions regarding the data traffic groups.

[0009] A method that can be performed by a user equipment (UE) is disclosed. The UE can generate traffic information related to a data traffic group, which includes data from an application running on the UE; and transmit the traffic information to a base station.

[0010] In some scenarios, a UE can transmit a group of data traffic consisting of multiple packets, which include at least the minimum amount of data required for an application to perform a single function.

[0011] In some scenarios, the minimum amount of data required to form the discrete portion of an application-encoded video frame is the minimum amount of video data.

[0012] In some scenarios, transmission traffic information may include the traffic information within a Media Access Control (MAC) control element (CE) within the Physical Uplink Shared Channel (PUSCH).

[0013] In some scenarios, traffic information may include delay information to be measured from a reference time, where the reference time used is the start of a symbol in which the physical uplink shared channel (PUSCH) in which traffic information is transmitted begins.

[0014] In some scenarios, generating traffic information may include generating at least one uplink control information (UCI) that includes the traffic information.

[0015] In some such scenarios, transmitting traffic information may include including a UCI containing the traffic information within the Physical Uplink Control Channel (PUCCH). The PUCCH may also include at least one additional UCI.

[0016] In some such scenarios, at least one additional UCI may include traffic information related to a second data traffic group, which includes different categories of data from the application. In some scenarios, because the resources within the PUCCH are insufficient to include all available UCIs, a portion of the traffic information may be omitted from the UCI and at least one additional UCI.

[0017] In some scenarios, since the resources within the PUCCH are insufficient to include all available UCIs, at least one additional UCI can be omitted from the PUCCH.

[0018] In some scenarios, at least one additional UCI can be selected for omission based on the priority index included in the traffic information. In other scenarios, the omitted UCI can be selected based on the relative priority level of the UCI type.

[0019] In some scenarios, traffic information may include delay information to be measured from a reference time, where the reference time used is the start of a symbol in which the physical uplink control channel (PUCCH) in which traffic information is transmitted begins.

[0020] In some scenarios, traffic information may include delay information to be measured from a reference time, where the reference time is the start of the time slot in which the traffic information is transmitted.

[0021] In some scenarios, traffic information may include at least one of the following: the reliability requirements of the data traffic group; the priority level of the data traffic group; the maximum group error rate of the data traffic group; the number of remaining packets in the data traffic group; the group size of one or more packets in the data traffic group; or the group size of the remaining packets in the data traffic group.

[0022] In some scenarios, the UE can receive from the base station an indication that provides traffic information about a specific traffic flow, wherein a data traffic group is included in the specific traffic flow, and wherein traffic information is generated in response to receiving the indication.

[0023] In some such scenarios, the instruction can further indicate periodic resources that provide the UE with traffic information about a specific traffic flow.

[0024] It should be noted that the technologies described herein can be implemented in and / or used in several different types of devices, including but not limited to base stations, access points, mobile phones, portable media players, tablets, wearable devices, unmanned aerial vehicles, unmanned flight controllers, automobiles and / or motor vehicles, and various other computing devices.

[0025] The present invention is intended to provide a brief overview of some of the subjects described in this document. Therefore, it should be understood that the above features are merely illustrative and should not be construed as narrowing the scope or substance of the subjects described herein in any way. Other features, aspects, and advantages of the subjects described herein will become apparent from the following detailed description, drawings, and claims. Attached Figure Description

[0026] A better understanding of the subject matter can be obtained by considering the following detailed description of the various embodiments in conjunction with the accompanying drawings, in which:

[0027] Figure 1 Exemplary (and simplified) wireless communication systems according to some implementation schemes are shown;

[0028] Figure 2 An exemplary base station communicating with an exemplary wireless user equipment (UE) device according to some embodiments is shown;

[0029] Figure 3 An exemplary block diagram of a UE according to some implementation schemes is shown;

[0030] Figure 4 An exemplary block diagram of a base station according to some implementation schemes is shown;

[0031] Figure 5 An example of communication traffic comprising multiple bursts is shown according to some implementation schemes, each burst comprising one or more groups of data traffic;

[0032] Figure 6 An example of two PUSCH transmissions occurring at different locations within two corresponding time slots, according to some implementation schemes, is shown;

[0033] Figure 7 An example of two PUCCH transmissions occurring at different locations within two corresponding time slots, according to some implementation schemes, is shown;

[0034] Figure 8 A block diagram representing the reuse of multiple UCIs according to some implementation schemes is shown;

[0035] Figure 9 An example of multiplexing the UCI of traffic information with the UCI of HARQ-ACK within the PUCCH is shown according to some implementation schemes;

[0036] Figure 10 An example of multiplexing the UCI of traffic information with the UCI of HARQ-ACK within the PUSCH is shown according to some implementation schemes;

[0037] Figures 11 to 14 show block diagrams representing various configurations according to some implementations, in which a UCI carrying traffic information related to one or more data groups can be multiplexed with one or more other UCIs for transmission on the PUCCH.

[0038] Figures 15 to 18 show block diagrams representing various configurations according to some implementation schemes, through which a UCI carrying traffic information related to one or more data groups can be multiplexed with one or more other UCIs for transmission on the PUSCH; and

[0039] Figure 19 This is a flowchart illustrating a method for providing traffic information related to data traffic groups according to some implementation schemes.

[0040] While the features described herein are susceptible to various modifications and alternatives, specific embodiments thereof are illustrated by way of example in the accompanying drawings and described in detail herein. However, it should be understood that the drawings and their detailed description are not intended to limit this document to the specific forms disclosed, but rather are intended to cover all modifications, equivalents, and alternatives falling within the substance and scope of the subject matter as defined by the appended claims. Detailed Implementation

[0041] acronym

[0042] Various acronyms are used throughout this disclosure. The definitions of the most prominent acronyms that may appear throughout this disclosure are as follows:

[0043] • ADU: Application Data Unit

[0044] CSI: Channel State Information

[0045] DCI: Downlink Control Information

[0046] EUTRA: Evolved UMTS Terrestrial Radio Access

[0047] GSM: Global System for Mobile Communications

[0048] LTE: Long Term Evolution

[0049] MAC: Media Access Control

[0050] MAC CE: MAC control element

[0051] NR: New Radio

[0052] PDCCH: Physical Downlink Control Channel

[0053] PDSCH: Physical Downlink Shared Channel

[0054] PUCCH: Physical Uplink Control Channel

[0055] PUSCH: Physical Uplink Shared Channel

[0056] RAT: Radio Access Technology

[0057] RF: Radio Frequency

[0058] RSRP: Reference Signal Received Power

[0059] RSRQ: Reference Signal Received Quality

[0060] RX: Reception / Receive

[0061] SP: Semi-permanent

[0062] TX: Transmission / Transmit

[0063] UCI: Uplink Control Information

[0064] UE: User Equipment

[0065] UMTS: Universal Mobile Telecommunications System

[0066] XR: Extended Reality

[0067] the term

[0068] The following is a glossary of terms that will appear in this disclosure:

[0069] memory media —Any device of any type of nontransitory memory device or storage device. The term “memory medium” is intended to include mounting media such as CD-ROMs, floppy disks, or magnetic tape devices; computer system memory or random access memory such as DRAM, DDR RAM, SRAM, EDO RAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media, such as hard disk drives or optical storage devices; registers or other similar types of memory elements, etc. Memory media may also include other types of nontransitory memory or combinations thereof. Furthermore, memory media may reside in a first computer system executing a program, or may reside in a different second computer system connected to the first computer system via a network such as the Internet. In a later example, the second computer system may provide program instructions to the first computer system for execution. The term “memory medium” may include two or more memory media that may reside in different locations on different computer systems connected via a network, for example. Memory media may store program instructions (e.g., representing a computer program) that can be executed by one or more processors.

[0070] carrier medium—The memory medium as described above, and the physical transmission medium, such as a bus, network and / or other physical transmission medium for transmitting signals (such as electrical signals, electromagnetic signals or digital signals).

[0071] Computer system (or computer) —Any type of computing or processing system, including personal computer systems (PCs), mainframe computer systems, workstations, network appliances, internet-connected appliances, personal digital assistants (PDAs), television systems, grid computing systems, or other devices or combinations thereof. Generally, the term "computer system" can be broadly defined as any device (or combination of devices) that includes at least one processor that executes instructions from a memory medium.

[0072] User Equipment (UE) (or "UE device") —Any of various types of computer systems or devices that are mobile or portable and perform wireless communication. Examples of UE devices include mobile phones or smartphones (e.g., iPhone). TM Based on Android TM Telephones), tablet computers (e.g., iPads) TM Samsung Galaxy TM ), portable gaming devices (e.g., Nintendo DS) TM PlayStation Portable TM Gameboy Advance TM iPhone TM Wearable devices (e.g., smartwatches, smart glasses), laptops, PDAs, portable internet devices, music players, data storage devices, other handheld devices, automobiles and / or motor vehicles, unmanned aerial vehicles (UAVs) (e.g., drones), UAV controllers (UACs), virtual / augmented reality devices, etc. Generally speaking, the term "UE" or "UE device" can be broadly defined to encompass any electronic device, computing device, and / or telecommunications device (or a combination of these devices) that is easily transportable by the user and capable of wireless communication.

[0073] wireless devices —Any of various types of computer systems or devices that perform wireless communication. Wireless devices can be portable (or mobile), or they can be stationary or fixed in a location. UE is an example of a wireless device.

[0074] Communication equipment—Any of various types of computer systems or devices that perform communication, which may be wired or wireless. Communication devices may be portable (or mobile), or they may be stationary or fixed in one location. A wireless device is one example of a communication device. A UE is another example of a communication device.

[0075] Base station (BS) – The term “base station” has the full range of its usual meaning and includes at least a wireless communication station that is installed in a fixed location and used for communication as part of a wireless telephone system or radio system.

[0076] Processing element (or processor) – refers to various elements or combinations of elements capable of performing the functions in a device (such as user equipment or cellular network equipment). Processing elements may include, for example: processors and associated memory, portions or circuitry of individual processor cores, entire processor cores, processor arrays, circuitry such as ASICs (Application-Specific Integrated Circuits), programmable hardware elements such as Field-Programmable Gate Arrays (FPGAs), and any combination thereof.

[0077] Wi-Fi The term "Wi-Fi" encompasses the full range of its common meaning and includes at least wireless communication networks, or RATs, which are provided by and through wireless LAN (WLAN) access points to provide connectivity to the Internet. Most modern Wi-Fi networks (or WLAN networks) are based on the IEEE 802.11 standard and marketed under the name "Wi-Fi." Wi-Fi (WLAN) networks are distinct from cellular networks.

[0078] automaticAutomatic means that an action or operation is performed automatically by a computer system (e.g., software executed by the computer system) or device (e.g., circuits, programmable hardware elements, ASICs, etc.) without requiring direct specification or execution of the action or operation through user input. Therefore, the term "automatically" is the opposite of an operation performed or specified manually by a user, where the user provides input to directly perform the operation. An automatic process can be initiated by user-provided input, but the subsequent actions performed "automatically" are not specified by the user; that is, they are not performed "manually," where the user specifies each action to be performed. For example, a user filling out a form by selecting each field and providing input specifying information (e.g., by typing information, selecting a checkbox, radio selection, etc.) is considered manually filling out the form, even though the computer system must update the form in response to the user's actions. The form can be automatically filled out by a computer system (e.g., software executed on the computer system) which analyzes the fields of the form and fills it out without any user input specifying answers for the fields. As indicated above, the user can invoke the automatic filling of the form but does not participate in the actual filling of the form (e.g., the user does not manually specify answers for the fields, but they are completed automatically). This manual provides various examples of operations that are automatically performed in response to actions taken by the user.

[0079] Configured as Various components can be described as being "configured" to perform one or more tasks. In such contexts, "configured" is a broad expression generally meaning "having" a "structure" that performs one or more tasks during operation. Thus, a component can be configured to perform a task even when it is not currently performing one (e.g., a set of electrical conductors can be configured to electrically connect one module to another, even when the two modules are not connected). In some contexts, "configured" can also be a broad expression generally meaning a structure that "has" a "circuit" that performs one or more tasks during operation. Thus, a component can be configured to perform a task even when it is not currently switched on. Typically, the circuit forming the structure corresponding to "configured" can include hardware circuitry.

[0080] For ease of description, various components may be described as performing one or more tasks. Such descriptions shall be interpreted as including the phrase “configured to”. The statement that a component is configured to perform one or more tasks is expressly intended not to invoke the interpretation of paragraph 6 of section 112 of title 35 of the United States Code.

[0081] Figure 1 and Figure 2 -Exemplary communication system

[0082] Figure 1 Exemplary (and simplified) wireless communication systems that can implement various aspects of this disclosure according to some embodiments are shown. It should be noted that... Figure 1The system described is merely one example of a possible system, and this implementation can be carried out in any of a variety of systems as needed.

[0083] As shown in the figure, this exemplary wireless communication system includes a base station 102 that communicates with one or more (e.g., any number) user equipments 106A, 106B, etc., up to 106N, via a transmission medium. Each user equipment may be referred to herein as a "user equipment" (UE) or UE device. Therefore, user equipment 106 is referred to as a UE or UE device.

[0084] Base station 102 may be a transceiver base station (BTS) or a cell site, and may include hardware and / or software for implementing wireless communication with UEs 106A to 106N. If base station 102 is implemented in the context of LTE, it may be referred to as an "eNodeB" or "eNB". If base station 102 is implemented in the context of 5G NR, it may alternatively be referred to as a "gNodeB" or "gNB". Base station 102 may also be equipped to communicate with network 100 (e.g., the core network of a cellular service provider, telecommunications networks such as the Public Switched Telephone Network (PSTN), and / or the Internet, and various other possible networks). Therefore, base station 102 facilitates communication between user equipments and / or between user equipments and network 100. The communication area (or coverage area) of a base station may be referred to as a "cell". Also as used herein, in relation to a UE, a base station may sometimes be considered to represent the network, taking into account both uplink and downlink communication of the UE. Therefore, a UE communicating with one or more base stations in the network may also be understood as a UE communicating with the network.

[0085] Base station 102 and user equipment can be configured to communicate via a transmission medium using any of a variety of radio access technologies (RATs), also known as wireless communication technologies or telecommunications standards, such as GSM, UMTS (WCDMA), LTE, LTE-A Advanced, LAA / LTE-U, 5G NR, 3GPP2, CDMA2000 (e.g., 1xRTT, 1xEV-DO, HRPD, eHRPD), Wi-Fi, etc.

[0086] Base station 102 and other similar base stations operating according to the same or different cellular communication standards may thus provide, as one or more cell networks, continuous or near-continuous overlapping services to UE 106 and similar devices over a geographic area via one or more cellular communication standards.

[0087] It should be noted that UE 106 can communicate using multiple wireless communication standards. For example, UE 106 can be configured to communicate using either or both of the 3GPP cellular communication standards or the 3GPP2 cellular communication standards. In some implementations, UE 106 can be configured to provide and / or utilize information to support data traffic groups, such as through the various methods described herein. UE 106 can also be configured, or alternatively configured, to use WLAN, BLUETOOTH, etc. TM It can communicate with one or more Global Navigation Satellite Systems (GNSS, such as GPS or GLONASS), one and / or more mobile television broadcasting standards (e.g., ATSC-M / H), etc. Other combinations of wireless communication standards (including more than two wireless communication standards) are also possible.

[0088] Figure 2 An exemplary user equipment 106 (e.g., one of devices 106A to 106N) communicating with base station 102 according to some embodiments is illustrated. UE 106 can be a device with wireless network connectivity, such as a mobile phone, handheld device, wearable device, computer or tablet, unmanned aerial vehicle (UAV), unmanned flight controller (UAC), automobile, virtual / augmented reality device, or virtually any type of wireless device. UE 106 may include a processor (processing element) configured to execute program instructions stored in memory. UE 106 can perform any of the method embodiments of the present invention by executing such stored instructions. Alternatively or additionally, UE 106 may include programmable hardware elements, such as any of an FPGA (Field Programmable Gate Array), integrated circuit, and / or various other possible hardware components configured to perform (e.g., individually or in combination) any of or any portion of any of the method embodiments described herein. UE 106 may be configured to communicate using any of a plurality of wireless communication protocols. For example, UE 106 can be configured to communicate using two or more of CDMA2000, LTE, LTE-A, 5G NR, WLAN, or GNSS. Other combinations of wireless communication standards are also possible.

[0089] UE 106 may include one or more antennas communicating using one or more wireless communication protocols according to one or more RAT standards. In some embodiments, UE 106 may share one or more portions of the receive chain and / or transmit chain among multiple wireless communication standards. The shared radio components may include a single antenna, or may include multiple antennas for performing wireless communication (e.g., for MIMO). Typically, the radio components may include any combination of baseband processors, analog radio frequency (RF) signal processing circuitry (e.g., including filters, mixers, oscillators, amplifiers, etc.), or digital processing circuitry (e.g., for digital modulation and other digital processing). Similarly, the radio components may use the aforementioned hardware to implement one or more receive chains and transmit chains.

[0090] In some implementations, UE 106 may include separate transmit and / or receive chains (e.g., including separate antennas and other radio components) for each wireless communication protocol configured to communicate therewith. As another possibility, UE 106 may include one or more radio components shared among multiple wireless communication protocols, as well as one or more radio components uniquely used by a single wireless communication protocol. For example, UE 106 may include shared radio components for communication using either LTE or CDMA2000 1xRTT (or LTE or NR, or LTE or GSM), and for communication using Wi-Fi and BLUETOOTH. TM Each component communicates independently. Other configurations are also possible.

[0091] Figure 3 - Block diagram of an exemplary UE device

[0092] Figure 3A block diagram of an exemplary UE 106 according to some embodiments is shown. As shown, UE 106 may include a System-on-Chip (SOC) 300, which may include parts for various purposes. For example, as shown, SOC 300 may include a processor 302 capable of executing program instructions for UE 106, and display circuitry 304 capable of performing graphics processing and providing display signals to a display 360. In some specific embodiments, display 360 may include a touchscreen capable of detecting user input, such as a touch event. SOC 300 may also include sensor circuitry 370, which may include components for sensing or measuring any of a variety of possible characteristics or parameters of UE 106. For example, sensor circuitry 370 may include motion sensing circuitry configured to detect motion of UE 106, for example, using a gyroscope, accelerometer, and / or any of various other motion sensing components. As another possibility, sensor circuitry 370 may include one or more temperature sensing components, for example, for measuring the temperature of each of one or more antenna panels and / or other components of UE 106. As needed, any of various other possible types of sensor circuitry may also be included in UE 106, or alternatively. Processor 302 may also be coupled to memory management unit (MMU) 340, which may be configured to receive addresses from processor 302 and translate those addresses into locations in memory (e.g., memory 306, read-only memory (ROM) 350, NAND flash memory 310) and / or other circuitry or devices, such as display circuitry 304, radio components 330, connector interface (I / F) 320, and / or display 360. MMU 340 may be configured to perform memory protection and page table translation or setup. In some embodiments, MMU 340 may be included as part of processor 302.

[0093] As shown in the figure, the SOC 300 can be coupled to various other circuits of the UE 106. For example, the UE 106 may include various types of memory (e.g., including NAND flash memory 310), connector interface 320 (e.g., for coupling to computer systems, docking stations, charging stations, etc.), display 360, and wireless communication circuitry 330 (e.g., for LTE, LTE-A, NR, CDMA2000, BLUETOOTH). TM(e.g., Wi-Fi, GPS, etc.). UE device 106 may include at least one antenna (e.g., 335a) and may include multiple antennas (e.g., shown by antennas 335a and 335b) for performing wireless communication with base stations and / or other devices. Antennas 335a and 335b are shown by way of example, and UE device 106 may include fewer or more antennas. Generally, one or more antennas are collectively referred to as antenna 335. For example, UE device 106 may use antenna 335 to perform wireless communication via radio circuitry 330. As described above, in some embodiments, the UE may be configured to use multiple wireless communication standards for wireless communication.

[0094] UE 106 may include hardware and software components for implementing methods by which UE 106 provides and / or utilizes information to support data traffic groups, as described further herein. The processor 302 of UE device 106 may be configured to implement some or all of the methods described herein, for example by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). In other embodiments, processor 302 may be configured as a programmable hardware element, such as an FPGA (Field-Programmable Gate Array) or as an ASIC (Application-Specific Integrated Circuit). Furthermore, processor 302 may be coupled to, for example, Figure 3 Other components shown and / or interoperable with these other components can provide and / or utilize information to support data traffic groups according to various embodiments disclosed herein. Processor 302 can also implement various other applications and / or end-user applications running on UE 106.

[0095] In some implementations, radio component 330 may include a separate controller dedicated to controlling communications for various corresponding RAT standards. For example, such as Figure 3 As shown, the radio component 330 may include a Wi-Fi controller 352, a cellular controller (e.g., an LTE, LTE-A, and / or NR controller) 354, and a BLUETOOTH controller. TM Controller 356, and in at least some embodiments, one or more of these controllers may be implemented as corresponding integrated circuits (referred to as ICs or chips), which communicate with each other and with the SOC 300 (more specifically with the processor 302). For example, Wi-Fi controller 352 may communicate with cellular controller 354 via a cell-ISM link or WCI interface, and / or BLUETOOTH TMController 356 can communicate with cellular controller 354 via a cell-ISM link or the like. Although three separate controllers are shown within radio component 330, other implementations with fewer or more similar controllers for various different RATs can be implemented in UE device 106.

[0096] Furthermore, implementation schemes in which the controller can perform functions associated with various radio access technologies are envisioned. For example, according to some implementation schemes, in addition to hardware and / or software components for performing cellular communications, the cellular controller 354 may also include hardware and / or software components for performing one or more activities associated with Wi-Fi, such as Wi-Fi preamble detection, and / or the generation and transmission of Wi-Fi physical layer preamble signals.

[0097] Figure 4 - Block diagram of an exemplary base station

[0098] Figure 4 A block diagram of an exemplary base station 102 according to some implementation schemes is shown. It should be noted that... Figure 4 The base station shown is merely one example of a possible base station. As illustrated, base station 102 may include a processor 404 capable of executing program instructions specific to base station 102. Processor 404 may also be coupled to a memory management unit (MMU) 440 or other circuitry or device, which may be configured to receive addresses from processor 404 and translate those addresses into locations in memory (e.g., memory 460 and read-only memory (ROM) 450).

[0099] Base station 102 may include at least one network port 470. Network port 470 may be configured to be coupled to a telephone network and provide access rights as described above. Figure 1 and Figure 2 The telephone network described herein includes multiple devices such as UE device 106. Network port 470 (or an additional network port) may also be configured, or alternatively configured, to be coupled to a cellular network, such as the core network of a cellular service provider. The core network may provide mobility-related services and / or other services to multiple devices such as UE device 106. In some cases, network port 470 may be coupled to the telephone network via the core network, and / or the core network may provide the telephone network (e.g., in other UE devices served by the cellular service provider).

[0100] Base station 102 may include at least one antenna 434 and possibly multiple antennas. Antenna 434 may be configured to operate as a wireless transceiver and may also be configured to communicate with UE device 106 via radio component 430. Antenna 434 communicates with radio component 430 via communication link 432. Communication link 432 may be a receive link, a transmit link, or both. Radio component 430 may be designed to communicate via various wireless telecommunication standards, including but not limited to NR, LTE, LTE-A WCDMA, CDMA2000, etc. Processor 404 of base station 102 may be configured to implement and / or support implementation of some or all of the methods described herein, for example by executing program instructions stored on a memory medium (e.g., a non-transitory computer-readable memory medium). Alternatively, processor 404 may be configured as a programmable hardware element such as a FPGA (Field-Programmable Gate Array), or as an ASIC (Application-Specific Integrated Circuit), or a combination thereof. In the case of certain RATs (e.g., Wi-Fi), base station 102 can be designed as an access point (AP), in which case network port 470 can be implemented to provide access to a wide area network and / or one or more local area networks, for example it may include at least one Ethernet port, and radio component 430 can be designed to communicate according to the Wi-Fi standard.

[0101] Figure 5 –XR traffic data traffic group

[0102] Virtual reality (VR) and similar augmented reality (AR) and / or mixed reality (MR) applications can be processor-intensive because they can involve real-time video processing, audio processing, location / position processing, environmental processing, haptic feedback processing, and so on. Such intensive processing can exceed the processing and / or battery power capabilities of many mobile user devices. The extended reality (XR) support currently being considered by 3GPP represents an attempt to mitigate these challenges by offloading critical processing functions to one or more network devices (such as XR servers) in the NR network, while providing time-critical communication to exchange relevant data between the network and the UE providing the user interface. Cloud gaming applications could work similarly.

[0103] For example, in some scenarios, uplink and / or downlink XR application traffic may include video information and / or scene information. While such data can be formatted as IP packets for wireless transmission (e.g., according to 5G / IETF / Industry Forum communication protocols), a single IP packet may not be sufficient to carry the amount of data required for functionality; for example, the minimum amount of data required for functionality. For instance, several packets may be needed to provide a complete video frame or a quantum subdivision of a video frame. A video encoder receiving IP packets may consume data from several packets together to perform a single function, such as encoding a complete video frame or discrete portions thereof, such as a subdivision of a video frame. Therefore, several packets carrying data for a single function, application process, etc., can be grouped into a single-function data traffic group, such as an Application Data Unit (ADU). Such a data traffic group may include multiple packets sufficient to provide the amount of data required for functionality (e.g., the minimum amount of data required to perform a single function, application process, etc.).

[0104] In some scenarios, multiple data streams can be transmitted, for example, to transmit various data types. For instance, a first data stream may include a data stream containing video data, a second data stream may include a data stream containing audio data, and a third data stream may include a data stream containing location / position data. As another example, data streams may be associated with data streams that include heterogeneous data such as audio data, video data, etc.

[0105] XR traffic can include bursts of traffic carrying one or more data traffic groups. Figure 5 An example of communication traffic comprising multiple bursts, each burst consisting of one or more groups of data traffic, is shown according to some implementation schemes. As illustrated in the figure, Figure 5 The communication traffic consists of three traffic bursts. In some scenarios, each burst can represent a capture of the virtual world and can include any appropriate data, such as audio, video, environmental data, location / position data, sensor data, haptic feedback data, etc.

[0106] As shown in the figure, Burst 1 comprises two data traffic groups: Group 1 and Group 2. Each of Group 1 and Group 2 comprises three IP packets. As an example, Burst 1 may include IP packets for encoding video frames, where Group 1 may include three IP packets carrying data for encoding a first renderable segment (e.g., the top region of the frame) of the video frame, and Group 2 may include three IP packets carrying data for encoding a second renderable segment (e.g., the bottom region of the frame) of the video frame. In this example, the receiving video encoder may be able to render the top region of the frame after successfully receiving Group 1, and may be able to render the bottom region of the frame after successfully receiving Group 2.

[0107] As shown in the diagram, Burst 2 comprises three data traffic groups. Groups 3 and 4 each contain four IP packets, which can carry data of a different type than that carried in Groups 1 and 2. For example, Groups 3 and / or 4 can carry audio data, environmental data, location / location data, etc. Group 5 comprises three IP packets, which can be of the same type as Groups 1 and 2, or they can be of a different type.

[0108] As shown in the figure, Burst 3 only includes Group 6, which consists of 4 IP packets. Group 6 can be of the same type as Groups 3 and 4, or it can be of a different type.

[0109] In some scenarios, various performance parameters, such as error rate, latency information, and relative packet type importance, can be specified at the data traffic group level rather than the packet level (or other than the packet level) to better capture application requirements. As a first example, an application may have a certain Group Error Rate (GER) requirement. GER can be expressed as the percentage of data traffic groups that err within a specific measurement window. For example, in some scenarios where a data traffic group comprises a minimum amount of data that can be meaningfully consumed by the receiving device, the failure of any single packet within a data traffic group can lead to the failure of the entire data traffic group. Therefore, even if the Packet Error Rate (PER) requirement specified by the network is met, communication may fail to meet the specified GER requirement.

[0110] As a second example, an application may have certain delay requirements for a data traffic group. Such delay requirements can specify the maximum time allowed to receive all packets in the data traffic group, measured from the time the first packet is transmitted. For example, in a scenario where the receiving device cannot utilize the received data if it has not received all packets in the data traffic group, if the base station determines that the remaining time is insufficient to meet the data traffic group delay requirements, the base station may abandon transmitting the remaining packets of the data traffic group in the downlink (or may abandon allocating resources to the UE to transmit the remaining packets in the uplink), because if no packets of the data traffic group are received, the receiving device may not be able to utilize the data in the data traffic group.

[0111] As a third example, one or more groups of a data traffic group can be designated as more or less important than other groups. For instance, if the data generation application implements application-level error correction, the application client can consume only a portion of the bits in the data traffic group and omit the remaining bits to increase capacity. If the application implements error hiding techniques, it can tolerate a certain percentage of the bits in the data traffic group that are erroneous. Some video encoders are configured to consume all bits in the data traffic group up to the first bit in the error, and all subsequent bits after the first bit in the error can be discarded because they cannot be consumed by the corresponding decoder.

[0112] Alternatively, packets within a data traffic group may include different types of data. For example, a first packet in a video data traffic group may include data for encoding an I-slice (intra-coded slice) of a first frame, which may be independently coded / decoded, while a second packet in the data traffic group may include data for encoding a P-slice (predictive slice) of a second frame, which may be encoded as a function of the difference relative to the previous I-slice. In such a scenario, the receiving device may be able to implement an error handling process to recover from lost P-slices. However, the loss of an I-slice can render subsequent P-slices unavailable. Therefore, packets containing I-slices can be designated as having higher importance than packets containing P-slices. If the base station determines that a packet containing an I-slice has not been successfully received, the base station may abandon the transmission of the remaining packets of the data traffic group in the downlink (or may abandon the allocation of resources for the UE to transmit the remaining packets in the uplink).

[0113] In some scenarios, the performance parameters for these various data traffic groups can differ for different data types. For example, a first latency requirement and / or GER can be set for a data traffic group containing video data, and a second latency requirement and / or GER can be set for a data traffic group containing audio data.

[0114] Figures 6 to 7 -Data group traffic information

[0115] From the base station's perspective, data traffic group processing occurs at the MAC and PHY layers. Therefore, the base station may be unaware of various higher-level considerations that could affect data traffic group performance, such as those discussed above. Consequently, the UE can provide feedback to the base station indicating various information related to data traffic groups and performance parameters. For example, the UE can provide information such as GER, latency information, packet importance, data traffic group composition, number of remaining packets, and packet size. This information allows the base station to make intelligent decisions regarding data traffic group processing, such as those outlined above. For instance, the UE can request additional transmission resources from the base station based on the traffic in its transmission buffer, but it can also provide intelligent information such as latency requirements and the number of remaining packets. In response, the base station can determine that there is insufficient time remaining within the latency budget to accommodate the transmission of all remaining packets in the data traffic group. Therefore, based on the received information, the base station can either forgo allocating the requested additional transmission resources to the UE or perform other intelligent actions.

[0116] In some scenarios, the UE can provide various traffic information to the base station in the MAC control element (CE) of the Physical Uplink Shared Channel (PUSCH). Traffic information may belong to an associated data traffic group. For example, the MAC CE may include identifiers of the data traffic group and / or one or more packets included in the data traffic group. Figure 6 An example of two PUSCH transmissions proceeding from left to right over time is shown. PUSCH-1 is transmitted in time slot n and includes a first MAC CE containing traffic information. PUSCH-2 is transmitted in the subsequent time slot m and includes a second MAC CE containing traffic information.

[0117] According to current standards, each PUSCH can be scheduled at a different location within its corresponding time slot, independent of its relative position in other time slots. For example, in Figure 6 In the scenario shown, PUSCH-2 is transmitted at the beginning of time slot m (e.g., in the first symbol of time slot m), while PUSCH-1 is transmitted at a time other than the beginning of time slot n (e.g., in a symbol later than the first symbol of time slot n). Assuming an SCS of 15 kHz, this can result in variations in start time across various time slots, up to approximately 12 / 14 × 1 ms = 0.85 ms. The location of the PUSCH can be determined by the base station at the PHY layer and can depend on various factors, such as whether other UL communications (e.g., from another UE) are given priority in earlier symbols within the time slot.

[0118] Traffic information, such as delay information, may include and / or depend on certain timing information. For example, traffic information included in the MAC CE may include the amount of time required for the delay of the associated data traffic group and / or the amount of time remaining until the end of the delay period. The amount of time can be measured from a reference time known to both the UE and the base station. In some implementations, the reference time may be the start time of the PUSCH containing the MAC CE, including the delay information. However, in some scenarios, this can lead to increased complexity because the MAC CE is written at the MAC level, while the PUSCH position is subsequently determined at the PHY level. For example, if the expected position of the PUSCH changes after the MAC CE is written, the UE may need to return data to the MAC level to modify the MAC CE with updated timing information based on the start time of the PUSCH change. To avoid this, in some implementations, the reference time may be the start time of the slot containing the PUSCH, rather than the start of the PUSCH itself.

[0119] In some scenarios, with similar timing considerations, similar traffic information can be carried in the MACCE of the PDSCH.

[0120] In some scenarios, with similar timing considerations, similar traffic information can be carried in the MAC CE of downlink traffic.

[0121] In some scenarios, the UE can provide various traffic information to the base station as uplink control information (UCI) within the Physical Uplink Control Channel (PUCCH). The traffic information may belong to an associated data traffic group and may include identifiers of the data traffic group and / or one or more packets included in the data traffic group. Figure 7 An example of two PUCCH transmissions proceeding from left to right over time is shown. PUCCH-1 is transmitted in time slot n and includes a first UCI containing traffic information. PUCCH-2 is transmitted in the subsequent time slot m and includes a second UCI containing traffic information.

[0122] Similar to PUSCH, each PUCCH can be scheduled at a different location within its corresponding time slot, independent of its relative position in other time slots. For example, in Figure 7 In the scenario shown, PUCCH-2 is transmitted at the beginning of time slot m (e.g., at the first symbol of time slot m), while PUCCH-1 is transmitted at a time other than the beginning of time slot n (e.g., at a symbol later than the first symbol of time slot n).

[0123] As previously discussed, some traffic information, such as delay information, may include and / or depend on certain timing information. For example, traffic information included in the UCI may include the amount of time required for the delay of the associated data traffic group and / or the amount of time remaining until the end of the delay period. The amount of time can be measured from a reference time known to both the UE and the base station. In some implementations, the reference time may be the start time of the PUCCH containing the UCI including delay information, or it may be the start time of the slot containing the PUCCH. Because the UCI is written by the PHY layer, using the start of the PUCCH as the reference time does not cause the same problems as using the start of the PUSCH. On the other hand, resources in the PUCCH are more limited than those in the PUSCH, which may lead to the desire to minimize the size of the UCI data provided for traffic information. It can be observed that reporting the amount of time relative to the start of the PUCCH may require a smaller field than reporting a longer amount of time relative to the start of the slot. Therefore, in some scenarios, using the start of the PUCCH as the reference time may be preferred.

[0124] In some implementations, the reference time can be the start time of the sub-slot in which the PUCCH begins. If the PUCCH includes repetitions, the first repetition (e.g., the start time of the sub-slot in which the first repetition of the PUCCH begins) can be used as the reference time.

[0125] In some scenarios, with similar timing considerations, similar traffic information can be carried in the DCI of the PDCCH.

[0126] Figures 8 to 10 -Reuse data group traffic information

[0127] In some scenarios, a UCI carrying traffic information belonging to one or more data groups can be scheduled to be transmitted at a time that overlaps with a UCI carrying one or more other UCIs such as HARQ-ACK, scheduling request (SR), or channel state information (CSI) (e.g., within the same time slot or sub-time slot). Figure 8 A block diagram representing the processing of UCI in such a scenario is shown according to some implementation schemes.

[0128] like Figure 8 As shown, overlapping UCIs can be multiplexed on a single PUCCH. Depending on some specific implementations, for example, if the PUCCH resources are insufficient to include all overlapping UCIs, one or more lower priority UCIs can be discarded (e.g., omitted from the resulting PUCCH).

[0129] In some scenarios, the resulting PUCCH can be scheduled for transmission at a time overlapping with the PUSCH. In response, the UCI can be further multiplexed to be carried on the PUSCH. In some such scenarios, the SR UCI (if present) will be discarded because SR is currently not supported in the PUSCH.

[0130] Figure 9 An example of a UCI for traffic information that overlaps temporally with the UCI of HARQ-ACK within time slot m, according to some implementation schemes, is shown. In response, the UE can multiplex these two UCIs for transmission on PUSCH-1. PUSCH-1 is transmitted in time slot m and includes the multiplexed traffic information and HARQ-ACK information.

[0131] In some such scenarios, traffic information may include and / or depend on certain timing information, which can be measured from a reference time known to both the UE and the base station, for example, as discussed above. In some implementations, the reference time may be the start of time slot m. In other implementations, the reference time may be the start of the PUCCH. In still other implementations, the reference time may be the time at which the UCI carrying traffic information is scheduled for transmission before multiplexing. In some scenarios, due to the combination... Figure 7 The reason for the discussion is that the latter option may be the preferred choice.

[0132] In some scenarios, with similar timing considerations, similar traffic information related to data traffic groups can be carried in the DCI, for example, carried in one or more DCI fields or mapped to one or more code states in the DCI and carried in the PDCCH.

[0133] Figure 10 An example of a UCI for traffic information that overlaps temporally with the UCI of HARQ-ACK within time slot m, according to some implementation schemes, is shown. In this example, two UCIs can be multiplexed to form PUCCH-1, for example, as... Figure 9 As shown. However, in Figure 10 In the example, PUCCH-1 overlaps with PUSCH in time. Therefore, the UE can further multiplex the UCI to be carried on the PUSCH in time slot m. The PUSCH is transmitted in time slot m and includes multiplexed traffic information and HARQ-ACK information.

[0134] In some scenarios, traffic information may include and / or depend on certain timing information, which can be measured from a reference time known to both the UE and the base station. In some implementations, the reference time may be the start of time slot m. In other implementations, the reference time may be the start of PUSCH. In still other implementations, the reference time may be the time at which the UCI carrying traffic information is scheduled for transmission before multiplexing. In some scenarios, due to the combination... Figure 7 The reason for the discussion is that the latter option may be the preferred choice.

[0135] In some scenarios, with similar timing considerations, similar traffic information can be carried in the DCI, which can be multiplexed with HARQ-ACK information and carried in the PDSCH.

[0136] UCI format for traffic information

[0137] In implementations where traffic information related to data traffic groups is carried in the PUCCH, the traffic information can represent a new UCI type. In some such implementations, a single PUCCH configuration can be defined to carry traffic information related to one or more traffic streams. In other implementations, multiple PUCCH configurations can be defined for a given traffic stream. For example, a first PUCCH configuration can be defined for a video traffic stream, a second PUCCH configuration for an audio traffic stream, a third PUCCH configuration for a gesture / control information traffic stream, and so on.

[0138] Traffic information PUCCH configurations can include reporting of traffic information such as latency, packet type importance, data traffic group composition, precise packet size, number of remaining packets, and reliability targets (such as GER). As an example, a first PUCCH configuration can be defined for traffic information related to a first (e.g., video) traffic stream. The first PUCCH configuration can include latency information, reliability requirements, and a PUCCH priority level. A second PUCCH configuration can be defined for traffic information related to a second (e.g., audio) traffic stream. The second PUCCH configuration can include latency information and a PUCCH priority level, but the reliability requirements can be omitted. It can be assumed that the second traffic stream utilizes the default reliability requirements. Many other configurations are also possible.

[0139] If multiple PUCCH configurations are defined for a given traffic flow, PUCCH conflicts may sometimes occur, where PUCCHs for multiple traffic flows can be prepared for transmission at the same or overlapping times. In some scenarios, the available PUCCH resources may not be sufficient to accommodate all prepared PUCCHs. In such scenarios, the UE can prioritize some traffic information over others. Prioritized traffic information can be reused and transmitted on available PUCCH resources, while lower-priority traffic information can be omitted, for example, dropped.

[0140] As an example, the PUCCH associated with each traffic flow may include a priority index, which indicates the relative priority of the traffic information included in that PUCCH. For example, a first PUCCH may be associated with a first traffic flow that may be considered to have particularly high importance and / or be expected to deviate from the default traffic information value most frequently. Therefore, the first PUCCH may be assigned the highest priority, such as priority index 0. A second PUCCH may be associated with a second traffic flow that may be considered to have lower importance and / or be expected to deviate from the default traffic information value less frequently. Therefore, the second PUCCH may be assigned a lower priority, such as priority index 1. In some implementations, additional lower priority values ​​may be specified to allow for larger differences in relative priority values. In some implementations, indexes or other identifiers of the PUCCH resource configuration for traffic information may be used in prioritization. For example, a lower-indexed PUCCH resource configuration for traffic information may have a higher priority than a higher-indexed PUCCH resource configuration for traffic information, or vice versa.

[0141] If a PUCCH conflict occurs in a scenario utilizing such a priority index, the UE can prioritize which information to transmit in the available PUCCH resources based on the corresponding priority index of the prepared PUCCHs. For example, based on the included priority index 0, the first PUCCH can be included first. If the PUCCH resources are still available after the first PUCCH is included, some or all of the second PUCCHs can be included, for example, until all available PUCCH resources have been utilized, or until all prepared PUCCHs have been included. Any prepared PUCCHs or portions thereof not included in the available PUCCH resources can be omitted, for example, discarded.

[0142] As a second example, instead of assigning a corresponding priority index to each prepared PUCCH, the UE can prioritize traffic information based on information type. For example, in some implementations, the UE can prioritize delay information most highly and reliability requirements less highly. Therefore, the UE can first include delay information from all prepared PUCCHs and then utilize any remaining PUCCH resources to include reliability requirements from some or all prepared PUCCHs. If PUCCH resources remain after including reliability requirements from all prepared PUCCHs, the UE can use the remaining PUCCH resources to include some or all additional, lower-priority traffic information. Any traffic information not included in the available PUCCH resources can be omitted, for example, discarded.

[0143] Periodicity of traffic information reports

[0144] In some implementations, the base station can configure the UE to periodically report traffic information, for example, according to any of the methods described above. For instance, the base station can configure periodic PUCCH resources for the UE to report traffic information related to data traffic groups. The periodic resources can be associated with the period and offset of a given XR traffic flow. In some implementations, the base station can configure different periodic PUCCH resources for different traffic flows.

[0145] If downlink traffic reaching the base station is encrypted, the base station may be unable to examine the downlink traffic to determine the number of periodic configurations to be configured at the UE. Therefore, the base station can utilize auxiliary information from the UE or from the core network to facilitate the base station's selection of configurations at the UE.

[0146] If uplink traffic reaching the base station is encrypted, the base station may be unable to examine the uplink traffic to determine the amount of periodic configuration to be configured at the UE. It can be observed that the UE retains more information about the uplink traffic than the base station. Therefore, the base station can then utilize auxiliary information from the UE or from the core network to facilitate the base station's selection of configurations at the UE.

[0147] As an example, downlink XR traffic can include video streams, audio streams, and data streams, which arrive at different periods and are offset individually according to the periodicity of the respective streams. The UE can report the quantity and characteristics of the XR traffic streams to the base station from its dialogue with the application server and / or the core network. Alternatively or additionally, the base station can obtain such information from the core network's Session Management Function (SMF). Using the information obtained through any one or both means, the base station can configure periodic PUCCH resources for each DL traffic stream to facilitate UE reporting of XR traffic information.

[0148] In some implementations, the base station can be configured by the UE to send semi-persistent (SP) reports, where the base station can provide indications for activating / deactivating periodic reports. SP reports carrying traffic information can be sent on the PUCCH or PUSCH, and the traffic information may include downlink traffic information and / or uplink traffic information. In some scenarios, the network can utilize both PUCCH and PUSCH to configure SP reports with traffic information. As mentioned above, traffic information for one or more traffic flows can be sent in a single SP report configuration or multiple SP report configurations.

[0149] As a first example, a new MAC CE can be introduced to trigger the UE to report traffic information about PUCCH resources using SP reports. The trigger can be linked to periodicity and offset, as well as PUCCH resources associated with the root report.

[0150] As a second example, a new trigger status field can be introduced into the downlink control information (DCI) transmission to trigger the UE to report traffic information about PUSCH resources using SP reports. The trigger can be linked to periodicity and offset, as well as PUSCH resources associated with the root report.

[0151] In some implementations, a semi-persistent configuration of the PUSCH can also be used for CSI reporting. If SP CSI reports and SP traffic information reports occur on different PUSCHes, their transmission times can be long. Therefore, power efficiency can be improved by supporting reporting SP CSI reports and SP traffic information reports on the same PUSCH. For example, existing mechanisms for SP CSI triggering can be extended to support both CSI and traffic information. As another example, SP traffic information carried on a PUSCH can be triggered separately and multiplexed with SP CSI reports. This allows the network greater flexibility in choosing different periodicities and offsets for SP CSI and SP traffic information. For example, if there is overlap between a first PUSCH carrying SP CSI and a second PUSCH carrying SP traffic information on the same component carrier, both SP CSI and SP traffic information can be carried on the first PUSCH. Alternatively, both SP CSI and SP traffic information can be carried on the second PUSCH. If the PUSCH selected to carry both SP CSI and SP traffic information has insufficient resources to accommodate both sets of information, lower-priority data can be omitted, for example, discarded. For example, if SP CSI or SP traffic information is considered a lower priority, some or all of that dataset can be omitted. Alternatively, lower priority data from both datasets can be omitted.

[0152] In some implementations, the base station can configure resources and trigger non-periodic reporting by the UE. For example, the base station can first configure a trigger state and associated traffic information for one or more traffic flows that have been triggered, for example, using RRC signaling and / or MAC CE. MAC CE can be used to narrow down the addressable traffic information request between configurations via RRC signaling. Subsequently, the network can provide the UE with an indication, for example, in downlink control information (DCI) transmission to report traffic information, for example, in PUCCH or PUSCH. In some implementations, this indication can specify one or more traffic flows for which the UE should provide traffic information. For example, the base station can transmit a DCI including a 4-bit traffic information trigger state field, which can indicate any of up to 16 different configurations of the UE traffic flows for which traffic information should be reported. Other formats for triggering non-periodic reporting of traffic information are also possible.

[0153] Figures 11 to 14 – Exemplary PUCCH multiplexing configurations

[0154] Figures 11 to 14 illustrate block diagrams representing various configurations according to some implementations, through which a UCI carrying traffic information associated with one or more data groups can be multiplexed with one or more other UCIs for transmission on the PUCCH. In some implementations, one or more UCI types may include priority levels, while in other implementations, no priority distinction is made. In some implementations, the traffic information UCI may be a single-part UCI, while in other implementations, the traffic information UCI may be a two-part UCI.

[0155] Figures 11A to 11D Block diagrams are shown representing four different exemplary reuse configurations according to some implementations, wherein the traffic information UCI is a single-part UCI and no priority distinction is made within any UCI type.

[0156] Figure 11A Each of the five UCI types is shown: Traffic Information, HARQ-ACK, SR, CSI Part I, and CSI Part II. Two or more of these UCIs can be reused in a PUCCH, for example, by combining... Figure 8 As discussed, the PUCCH can include PUCCH Part I and PUCCH Part II, as known in the art, for example. For instance, existing 3GPP standards allow HARQ-ACK, SR, and / or CSI Part I to be carried in PUCCH Part I, while CSI Part II (if present) can be carried within PUCCH Part II. If more than one UCI is to be carried in PUCCH Part I, the payloads of such UCIs can be concatenated and encoded by a first encoder. CSI Part II can be encoded by a second encoder. Figure 11A In the example shown, traffic information can also be concatenated with other UCIs in PUCCH Part I and encoded by the first encoder. In various specific implementations, traffic information can be concatenated at various points relative to other UCIs. For example, traffic information can be concatenated between HARQ-ACK-ACK and SR, or between SR and CSI Part I, or after CSI Part I. It should be understood that fewer than all of the shown UCIs may exist in any given scenario. Fewer than all of the shown UCIs may exist in applicable specifications to simplify support for traffic information reporting. Figure 11A It shows how each UCI type can be handled if it exists.

[0157] Figure 11BA similar example is shown, the difference being that traffic information can be carried in PUCCH Part II. For example, traffic information can be concatenated with CSI Part II and encoded by a second encoder. The ordering of UCIs within the PUCCH part can be based on their importance / priority. For example, CSI Part II can be appended to... Figure 11B Traffic information is considered more important because it can be regarded as more important. Similar considerations for the ranking of UCI can be applied to other scenarios, such as those shown in any of Figures 11 to 15.

[0158] Figure 11C An example is shown where CSI Part I and CSI Part II are discarded (e.g., omitted) when traffic information is present. For example, in some implementations, traffic information may be considered more important than CSI, such that CSI can be discarded to ensure sufficient resource availability in the PUCCH to include traffic information. The traffic information may be encoded by a second encoder and carried in PUCCH Part II.

[0159] Figure 11D An example is shown where traffic information is considered an extension of SR. It can be observed that the traffic information UCI can reflect many similarities to the SR UCI, making it logical to process traffic information and SR together during UCI multiplexing. Figure 11D In the examples, if the SR UCI does not exist, the traffic information can assume the location of the SR, or if the SR exists, the traffic information can be pre-added / attached / concatenated to the SR. In some implementations, the traffic information can provide more granular information about applicable data traffic than the SR, so if the SR exists, the traffic information can take precedence over the SR. For example, if both the SR and the traffic information exist, the SR can be discarded. In some implementations, the SR can only be discarded if the existing traffic information is used for the uplink.

[0160] Figures 12A to 12B Block diagrams are shown representing two different exemplary reuse configurations according to some implementations, wherein the traffic information UCI is a two-part UCI and no priority distinction is made within either UCI type.

[0161] Figure 12A It shows something similar to Figure 11AThe example differs in that the traffic information UCI is shown as two parts: traffic information part I and traffic information part II. In some specific implementations, traffic information part II may carry a traffic information payload, while traffic information part I may indicate the size of traffic information part II, for example, in bits. As shown, traffic information part I may be carried in PUCCH part I (e.g., concatenated with HARQ-ACK, SR, and / or CSI part I (if present) and encoded by a first encoder), while traffic information part II may be carried in PUCCH part II (e.g., concatenated with CSI part II (if present) and encoded by a second encoder).

[0162] Figure 12B A similar example is shown, except that CSI Part I and CSI Part II are discarded when traffic information is present, similar to... Figure 11C Examples.

[0163] Figures 13A to 13E Block diagrams representing five different exemplary multiplexing configurations according to some implementations are shown, where the traffic information UCI is a single-part UCI and is prioritized within some UCI types. Specifically, as shown, the HARQ-ACK UCI can be either high-priority (HP) HARQ-ACK or low-priority (LP) HARQ-ACK. Similarly, the SR UCI can be either HP SR or LP SR. Existing 3GPP standards allow LP HARQ-ACK and / or LP SR to be carried in PUCCH Part II (e.g., concatenated with CSI Part II, if present, and encoded by a second encoder).

[0164] Figure 13A An example is shown in which traffic information is added to such a configuration and can be carried in PUCCH section I.

[0165] Figure 13B A similar example is shown, where traffic information can be carried in PUCCH Part II.

[0166] Figure 13C It shows the relationship with Figure 13A The example is similar to the one mentioned above, except that CSI Part I and CSI Part II are discarded when traffic information is available.

[0167] Figure 13D It shows the relationship with Figure 13B Similar examples exist, except that CSI Part I and CSI Part II are discarded when traffic information is available.

[0168] and Figure 11D Similar examples exist. Figure 13EAn example is shown where traffic information is treated as an extension of SR.

[0169] Figures 14A to 14B Block diagrams are shown representing two different exemplary reuse configurations according to some implementations, wherein the traffic information UCI is a two-part UCI and is prioritized within some UCI types.

[0170] Figure 14A It shows something similar to Figure 13A The example differs in that the traffic information UCI is shown as two parts. As shown in the figure, traffic information part I can be carried in PUCCH part I, while traffic information part II can be carried in PUCCH part II.

[0171] Figure 14B A similar example is shown, except that CSI Part I and CSI Part II are discarded when traffic information is available.

[0172] Any of the foregoing configurations or similar configurations can be used in various specific implementations to reuse UCI for transmissions within the PUCCH. For example, a UE (such as UE 106) or a component thereof (such as radio component 330 or cellular controller 354) can perform UCI encoding according to any of the foregoing configurations. A base station (such as base station 102) or a component thereof (such as radio component 430) can decode the PUCCH configured according to any of the foregoing configurations.

[0173] Figures 15 to 18 – Exemplary PUSCH multiplexing configurations

[0174] Figures 15 through 18 illustrate block diagrams representing various configurations according to some implementations, through which a UCI carrying traffic information associated with one or more data groups can be multiplexed with one or more other UCIs for transmission on the PUSCH. In some implementations, one or more UCI types may include priority levels, while in other implementations, no priority distinction is made. In some implementations, the traffic information UCI may be a single-part UCI, while in other implementations, the traffic information UCI may be a two-part UCI.

[0175] Figures 15A to 15D Block diagrams are shown representing four different exemplary reuse configurations according to some implementations, wherein the traffic information UCI is a single-part UCI and no priority distinction is made within any UCI type.

[0176] Figure 15AEach of the four UCI types is shown: Traffic Information, HARQ-ACK, CSI Part I, and CSI Part II. Two or more of these UCIs can be reused in a PUSCH, for example, as a combination. Figure 8 As discussed, a PUSCH can include PUSCH Part 0, PUSCH Part 1, and PUSCH Part 2, as known in the art, for example. For instance, existing 3GPP standards allow HARQ-ACK to be carried in PUSCH Part 0 and encoded by a first encoder. CSI Part 1 can be carried in PUSCH Part 1 and encoded by a second encoder. CSI Part 2 can be carried in PUSCH Part 2 and encoded by a third encoder. Figure 15A In the example shown, traffic information can also be included in PUSCH section 0. If HARQ-ACK is also present, the traffic information can be concatenated therewith and encoded by the first encoder. It should be understood that fewer than all of the shown UCIs may exist in any given scenario. Fewer than all of the shown UCIs may exist in applicable specifications to simplify the reporting of traffic information. Figure 15A It shows how each UCI type can be handled if it exists.

[0177] Figure 15B A similar example is shown, the difference being that traffic information can be carried in PUSCH section I. For example, traffic information can be concatenated with CSI section I and encoded by a second encoder.

[0178] Figure 15C A similar example is shown, the difference being that traffic information can be carried in PUSCH Part II. For example, traffic information can be concatenated with CSI Part II and encoded by a third encoder.

[0179] Figure 15D It shows something similar to Figure 15B For example, traffic information can be carried in PUSCH section I, the difference being in Figure 15D In this process, CSI Part I can be moved to be carried over to PUSCH Part II, for example, to ensure sufficient resource availability for traffic information in PUSCH Part I. CSI Part II can be discarded.

[0180] Figures 16A to 16E Block diagrams are shown representing five different exemplary reuse configurations according to some implementation schemes, wherein the traffic information UCI is a two-part UCI and no priority distinction is made within any UCI type.

[0181] Figure 16A It shows something similar to Figure 15AThe example differs in that the traffic information UCI is shown as two parts: traffic information part I and traffic information part II. In some specific implementations, traffic information part II may carry the traffic information payload, while traffic information part I may indicate the size of traffic information part II, for example, in bits. As shown, traffic information part I may be carried in PUSCH part I (e.g., concatenated with CSI part I (if present) and encoded by a second encoder), while traffic information part II may be carried in PUSCH part II (e.g., concatenated with CSI part II (if present) and encoded by a third encoder).

[0182] Figure 16B A similar example is shown, except that the flow information part I can be carried in the PUSCH part 0 (e.g., concatenated with HARQ-ACK (if present) and encoded by the first encoder).

[0183] Figure 16C It shows something similar to Figure 16B The difference is that the flow information section II can be carried in the PUSCH section I (e.g., concatenated with the CSI section I (if present) and encoded by a second encoder).

[0184] Figure 16D It shows the relationship with Figure 16A A similar example, except that CSI Part I and CSI Part II can be discarded when traffic information is available.

[0185] Figure 16E It shows the relationship with Figure 16A A similar example, except that CSI part I can be moved so that it can be carried in PUSCH part II, and CSI part II can be discarded.

[0186] Figures 17A to 17F Block diagrams representing six different exemplary multiplexing configurations according to some implementations are shown, where the traffic information UCI is a single-part UCI and is prioritized within some UCI types. Specifically, as shown, the HARQ-ACK UCI can be either a high-priority (HP) HARQ-ACK or a low-priority (LP) HARQ-ACK. Existing 3GPP standards allow LP HARQ-ACK to be carried in PUSCH Part I (e.g., concatenated with CSI Part I (if present) and encoded by a second encoder).

[0187] Figure 17A An example is shown where traffic information is added to such a configuration and can be carried in PUSCH section 0.

[0188] Figure 17BA similar example is shown, where traffic information can be carried in PUSCH section I.

[0189] Figure 17C A similar example is shown, where traffic information can be carried in PUSCH Part II.

[0190] Figure 17D A similar example is shown, the difference being that CSI Part I and CSI Part II can be discarded when traffic information is present. Traffic information can be carried in PUSCH Part I, and LP HARQ-ACK can be carried in PUSCH Part II.

[0191] Figure 17E It shows the relationship with Figure 17D A similar example, except that traffic information can be carried in PUSCH Part II, while LP HARQ-ACK is retained in PUSCH Part I.

[0192] Figure 17F It shows the relationship with Figure 17A A similar example, the difference being that CSI Part II is discarded if traffic information is present. CSI Part I and / or traffic information can be carried in PUSCH Part II, while LP HARQ-ACK is retained in PUSCH Part I.

[0193] Figures 18A to 18E Block diagrams are shown representing five different exemplary reuse configurations according to some implementation schemes, where the traffic information UCI is a two-part UCI and is prioritized within some UCI types.

[0194] Figure 18A It shows something similar to Figure 17A The example differs in that the traffic information UCI is shown as two parts. Traffic information part I can be carried in PUSCH part I, and traffic information part II can be carried in PUSCH part II.

[0195] Figure 18B A similar example is shown, except that the flow information section I can be carried in the PUSCH section 0.

[0196] Figure 18C A similar example is shown, except that traffic information section I can be carried in PUSCH section 0, and traffic information section II can be carried in PUSCH section I.

[0197] Figure 18D It shows the relationship with Figure 18AA similar example, except that CSI Part I and CSI Part II are discarded when traffic information is available.

[0198] Figure 18E It shows the relationship with Figure 18A A similar example, except that CSI Part II is discarded when traffic information is available, and CSI Part I can be carried in PUSCH Part II.

[0199] Any of the foregoing configurations or similar configurations can be used in various specific implementations to reuse UCI for transmissions within the PUSCH. For example, a UE (such as UE 106) or a component thereof (such as radio component 330 or cellular controller 354) can perform UCI encoding according to any of the foregoing configurations. A base station (such as base station 102) or a component thereof (such as radio component 430) can decode the PUSCH configured according to any of the foregoing configurations.

[0200] Figure 19 –Exemplary Method

[0201] Figure 19 This is a flowchart illustrating a method for providing traffic information related to data traffic groups according to some implementation schemes. Figure 19 The method can be performed by the UE (such as UE 106) or by one of its components (such as by radio component 330 and / or cellular controller 354). As shown in the figure, Figure 19 The method can be operated as follows.

[0202] At 1902, UE 106 can receive from the base station an indication to provide traffic information about a specific traffic flow. For example, a traffic flow may include data from a specific application being executed on UE 106, such as data related to a specific category or type of data. As a specific example, a data flow may include video traffic from an application. As another example, a data flow may include audio traffic or control traffic, etc.

[0203] In some scenarios, traffic flow may include uplink traffic generated by the UE for an application (and / or through an application). In other scenarios, traffic flow may include downlink traffic known to the UE but generated by a remote device (such as another UE or a network XR server).

[0204] In some scenarios, the indication may include a trigger for reporting aperiodic traffic information for one or more traffic flows. In some scenarios, the indication may include instructions and / or configuration information for performing periodic reporting of traffic information for one or more traffic flows. For example, the indication may specify a periodic resource for reporting traffic information and / or may specify one or more parameters, such as the reporting period and / or time offset value. In some scenarios, the indication may include instructions for performing semi-persistent reporting. For example, the indication may include instructions for temporarily activating periodic reporting.

[0205] In some scenarios, the indication to provide traffic information can represent a general indication that the UE is providing traffic information, such as not identifying a specific traffic flow. In such scenarios, the UE can identify one or more specific traffic flows for which traffic information is to be provided.

[0206] At 1904, in response to receiving an instruction to provide traffic information, UE 106 can generate traffic information related to a data traffic group for a specific traffic flow. The data traffic group may include uplink data from an application or downlink data directed to an application. For example, the data traffic group may include multiple packets that include at least the minimum amount of data required for the application to perform a single function, such as the minimum amount of video data required for the application to encode a video frame or a discrete portion of a video frame.

[0207] Traffic information can include information about the nature, status, performance, and / or constraints of a data traffic group. For example, traffic information may include the size and / or composition of packets in the data traffic group, the number of remaining packets in the data traffic group, priority level indications for packets in the data traffic group, reliability requirements for the data traffic group, the maximum group error rate for the data traffic group, and latency information related to the data traffic group. In some scenarios, latency information can be measured from a reference time, such as the remaining time within a defined latency window in which the transmission of the data traffic group should (or must) be completed. For example, the reference time could be the start of a time slot in which traffic information is transmitted. As another example, the reference time could be the start of the symbol for a PUCCH or PUSCH that begins to carry traffic information.

[0208] In some scenarios, generating traffic information may include generating at least one UCI that includes traffic information.

[0209] In some scenarios, the generated traffic information may include traffic information from more than one data traffic group and / or more than one traffic flow. For example, in some scenarios utilizing periodic or SP scheduling, the UE may generate traffic information related to a specific traffic flow, but typically does not include traffic information specific to a specific data traffic group. It should be understood that such traffic information still belongs to the data traffic group marked at 1904, because that data traffic group is included in the specific traffic flow.

[0210] At 1906, UE 106 can transmit the generated traffic information. In some scenarios, UE 106 can transmit traffic information within the PUCCH (e.g., within a UCI encoded in the PUCCH). In some scenarios, UE 106 can transmit traffic information within the PUSCH (e.g., within the MAC CE of the PUSCH, or within a UCI multiplexed into the PUSCH). In some scenarios, UE 106 can generate additional UCIs (e.g., traffic information carrying additional traffic flows or carrying other types of UCI data such as HARQ-ACK, SR, and / or CSI) for transmission at a time overlapping with the transmission time of the UCI carrying traffic information. In such scenarios, UE 106 can multiplex two or more UCIs from those to be transmitted in a single PUCCH or PUSCH. In some scenarios, because resources within the PUCCH or PUSCH are insufficient to include all available UCIs, UE 106 can omit a portion of the traffic information (such as low-priority information) and / or a portion of the traffic information from one or more additional UCIs. In some scenarios, due to insufficient resources within the PUCCH to include all available UCIs, UE 106 may omit one or more UCIs from the additional UCIs from the PUCCH. In some such scenarios, UE 106 may select the UCI to omit based on the UCI priority index and / or based on the relative priority level of the UCI type. For example, in some implementations, the UE may select the CSI UCI to omit because CSI reports can be considered to have a lower priority than traffic information reports.

[0211] At 1908, UE 106 can transmit or receive data traffic groups. For example, if the data traffic group includes uplink traffic, the UE can transmit the data traffic group, for example, in response to appropriate scheduling and resource allocation by the base station. As another example, if the data traffic group includes downlink traffic, the UE can receive the data traffic group, for example, transmitted by the base station. In some scenarios, UE 106 can transmit / receive multiple data traffic groups as part of a traffic stream. In some scenarios, UE 106 can transmit / receive multiple traffic streams, for example, representing data of a corresponding type or category.

[0212] It should be understood that the aforementioned method is an example, and many variations are envisioned. In some scenarios, one or more steps may be omitted or reordered, and / or additional steps may be added. For example, in some scenarios, 1902 may be omitted, such as when periodic reporting is pre-configured. As another example, the data traffic group transmitted / received at 1908 may include the transmission / reception of multiple packets, which occurs in part before, during, and / or after the transmission of traffic information at 1906. In other words, in some scenarios, UE 106 may perform 1904-1906 multiple times during the entire transmission / reception period of the data traffic group at 1908. In some scenarios, 1908 may be omitted entirely, or the transmission / reception of a portion of the data traffic group may be omitted, for example, at the discretion of the network, such as intelligent scheduling decisions as outlined above.

[0213] As is widely recognized, the use of personally identifiable information should comply with privacy policies and practices that are generally accepted to meet or exceed industry or governmental requirements for protecting user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of authorized use should be clearly explained to users.

[0214] By interpreting each message / signal X received by the user equipment (UE) in the downlink as a message / signal X transmitted by the base station, and interpreting each message / signal Y transmitted by the UE in the uplink as a message / signal Y received by the base station, any method described herein for operating the UE can serve as the basis for a corresponding method for operating the base station.

[0215] Embodiments of this disclosure may be implemented in any of a variety of forms. For example, in some embodiments, the subject matter may be implemented as a computer-implemented method, a computer-readable storage medium, or a computer system. In other embodiments, the subject matter may be implemented using one or more custom-designed hardware devices such as ASICs. In still other embodiments, the subject matter may be implemented using one or more programmable hardware elements such as FPGAs.

[0216] In some embodiments, a non-transitory computer-readable storage medium (e.g., a non-transitory memory element) may be configured to store program instructions and / or data, wherein if the program instructions are executed by a computer system, the computer system performs a method, such as any of the method embodiments described herein, or any combination of the method embodiments described herein, or any subset of any method embodiments described herein, or any combination of such subsets.

[0217] In some embodiments, a device (e.g., a UE) may be configured to include a processor (or a set of processors) and a memory medium (or memory elements), wherein the memory medium stores program instructions, and wherein the processor is configured to read from and execute the program instructions, wherein the program instructions are executable to implement any of the various method embodiments described herein (or any combination of the method embodiments described herein, or any subset or any combination of such subsets of any method embodiments described herein). The device may be implemented in any of a variety of forms.

[0218] Although the above embodiments have been described in considerable detail, many variations and modifications will become apparent to those skilled in the art once the disclosure is fully understood. This disclosure is intended to render the following claims as encompassing all such variations and modifications.

Claims

1. A method for wireless communication, the method comprising: User-equipped UE: Generate traffic information related to a data traffic group, the data traffic group including data from an application running on the UE; as well as The traffic information is transmitted to the base station within the Medium Access Control (MAC) element (CE) in the Physical Uplink Shared Channel (PUSCH), wherein the traffic information indicates the amount of time remaining until the end of the delay period for the associated data traffic group, the amount of time being measured from the beginning of the symbol where the PUSCH begins.

2. The method according to claim 1, further comprising: From the UE: The data traffic group is transmitted, the data traffic group comprising multiple packets, the multiple packets comprising at least the minimum amount of data required for the application to perform a single function.

3. The method of claim 2, wherein the minimum amount of data is the minimum amount of video data required to constitute a discrete portion of the application-encoded video frame.

4. The method of claim 1, wherein the traffic information includes at least one of the following: The reliability requirements of the data traffic group; The priority level of the data traffic group; or The maximum group error rate of the data traffic group.

5. The method according to claim 1, further comprising: From the UE: The base station receives an instruction to provide traffic information about a specific traffic flow, wherein the data traffic group is included in the specific traffic flow, and wherein the traffic information is generated in response to receiving the instruction.

6. The method of claim 5, wherein the indication further indicates periodic resources for the UE to provide traffic information about the particular traffic flow.

7. An apparatus for providing traffic information related to a data traffic group, the apparatus comprising: The memory stores software instructions; and At least one processor, the at least one processor being configured to execute software instructions to cause the apparatus to perform the method according to any one of claims 1 to 5.

8. A non-transitory computer-readable storage medium storing software instructions that, when executed by a processor of a user-equipped UE, cause the UE to perform the method according to any one of claims 1 to 5.

Images