Method for transmitting uplink control information and communication device

Abstract

A dynamic scheme is disclosed that indicates one or more CG PUSCH occasions or resources that will not be used by a UE. A method performed by a network node includes sending an indication of a minimum value of a UCI timeline in advance to one or more CG PUSCH occasions that are not used. In one embodiment, a method performed by a UE includes transmitting a UCI indicating that one or more CG PUSCH opportunities that are not used occur at a value that is at least later than a UCI timeline. A network node and a UE respectively performing the method are also disclosed.

Description

Technical Field

[0001] The present disclosure relates to wireless communication systems, and more particularly, to uplink control information ("UCI") indication timelines for reporting unused resources. Background Art

[0002] Figure 1 An example of a new radio (“NR”) network (e.g., a 5th generation (“5G”) network) is shown, including a 5G core (“5GC”) network 130, network nodes 120a-b (e.g., 5G base stations (“gNBs”)), and multiple communication devices 110 (also referred to as user equipment (“UE”)).

[0003] In the ongoing Rel-18 study item on Extended Reality (“XR”), multiple enhancements are being proposed to increase the XR capabilities of 5G Advanced systems.

[0004] Extended Reality (XR), XR includes services provided by computer technology and wearable devices that allow human-computer interaction in a real / virtual hybrid environment. XR includes virtual reality ("VR"), augmented reality ("AR"), mixed reality ("MR"), cloud gaming, and their intersections [2]. Therefore, XR is often regarded as a hybrid eMBB / URLLC service; e.g. Figure 2 As shown in Figure 2, XR services are a mixture of heterogeneous UL / DL data flows, including video, audio, and control services [3].

[0005] Figure 2 An example of XR service characteristics and requirements identified by 3GPP is shown [3].

[0006] Figure 2 It is highlighted that XR traffic flows have different characteristics (e.g., packet rate in frames per second [fps] and bit rate in bits per second [bps]) and requirements in terms of (application) packet delay budget ("PDB") [ms]. In XR flows, DL video and UL scene traffic are periodic (especially in the presence of possible jitter in DL) and have application packets of variable and large size.

[0007] The CG-UCI is included in every NR-U CG-PUSCH transmission and consists of Figure 3The CG-UCI is mapped according to the Rel-15 rules for uplink control information (UCI) multiplexing on the PUSCH, where the CG-UCI has the highest priority. It is mapped on symbols starting after the first DMRS symbol. To determine the number of REs used for the CG-UCI, the mechanism used in Rel-15 NR for the beta offset of HARQ-ACK on the CG-PUSCH is reused. Nevertheless, a beta offset for the new RRC configuration for the CG-UCI is defined.

[0008] Figure 3 An example of CG-UCI content is shown.

[0009] If the CG-PUSCH resources overlap with PUCCH carrying CSI-part1 and / or CSI-part2, the latter can be sent on CG-PUSCH or CG-PUSCH. An RRC configuration can be provided to the UE to indicate whether to multiplex CG-UCI and HARQ-ACK. If configured, CG-UCI and HARQ-ACK are jointly encoded as one UCI type in the case where PUCCH overlaps with one or more CG-PUSCHs within the PUCCH group. Otherwise, if the CG-PUSCH overlaps with the PUCCH carrying HARQ ACK feedback, the configured licensed PUSCH is skipped. Summary of the invention

[0010] Certain challenges currently exist. The 3rd Generation Partnership Project ("3GPP") has agreed to study whether / how enhanced Configuration Grant ("CG") candidate technologies are necessary and beneficial for improving Extended Reality ("XR") capacity. In some examples, there is at least concern about dynamic indication by the UE of one or more CG PUSCH opportunities or resources that are not used and / or increasing CG PUSCH transmission opportunities in a duration. No consensus has been reached to continue studying the differentiation of XR multi-flows based on CG enhancements in RAN1 XRSI.

[0011] The problem is that for XR, the CG will have more or increased PUSCH in the CG period and due to the nature of XR traffic, the UE may not need all the PUSCH. Therefore, it can send some UCI to inform the gNB about the unused resources / PUSCH. Various embodiments in this document describe how this UCI will work and what is its timeline with respect to unused PUSCH.

[0012] Certain aspects of the present disclosure and embodiments thereof may provide solutions to these or other challenges.Various embodiments herein describe processes for designing a UCI notification timeline and providing related parameters / features, wherein the notification indicates which resources are not used by the UE for UL PUSCH transmission.

[0013] When UCI is sent to inform about unused resources, there are some time constraints associated with UCI transmission. The value of the UCI timeline must be chosen in a way that the timeline is greater than the minimum required delay from UCI transmission until the gNB is able to use the unused UE's resources for other purposes (e.g. reallocate to other UEs).

[0014] According to some embodiments, a method of a communication device operating in a communication network including a network node is provided. The method includes determining a threshold number of symbols at which uplink control information (UCI) indicating a physical uplink shared channel (PUSCH) that the communication device will not use for transmission is to be sent at the threshold number of symbols before the PUSCH that the communication device will not use for transmission. The method further includes: sending the UCI indicating the PUSCH at least the threshold number of symbols before the PUSCH.

[0015] According to other embodiments, a method of a network node operating in a communication network including a communication device is provided. The method includes receiving uplink control information UCI from the communication device, the UCI indicating a physical uplink shared channel PUSCH not used for transmission by the communication device, the UCI being at least a threshold number of symbols before the PUSCH not used for transmission. The method further includes adjusting the use of symbols associated with the PUSCH not used for transmission based on receiving the UCI.

[0016] Certain aspects of the present disclosure and embodiments thereof may provide technical advantages. In order to send large or large data, 3GPP is considering increasing PUSCH resources in the CG. However, there may be a problem that this may result in waste if the resources are not fully utilized (e.g., low data volume in the buffer). To stop the waste, 3GPP is interested in utilizing UCI-based notifications to indicate unused resources. The innovations in this article propose a timeline in which UCI must be sent, so that this waste can be minimized. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings illustrate certain non-limiting embodiments of the inventive concept, and are included to provide a further understanding of the present disclosure, and are incorporated into and constitute a part of this application. In the drawings:

[0018] Figure 1 is a schematic diagram illustrating an example of a fifth generation ("5G") network;

[0019] Figure 2 is a table showing examples of extended reality (“XR”) service characteristics and requirements identified by the 3rd Generation Partnership Project (“3GPP”);

[0020] Figure 3 is a table showing an example of CG-UCI content;

[0021] Figure 4 is a schematic diagram showing an example of a UE indicating UCI notification X symbols before an unused PUSCH resource allocation according to some embodiments;

[0022] Figure 5 is a diagram illustrating an example of UCI always transmitted in the last PUSCH according to some embodiments;

[0023] Figure 6 is a diagram illustrating an example of a UE indicating unused resources within a time period of Z time units via UCI according to some embodiments;

[0024] Figure 7 is a flow chart illustrating an example of operations performed by a communication device according to some embodiments;

[0025] Figure 8 is a flow chart illustrating an example of operations performed by a network node according to some embodiments;

[0026] Figure QQ1 shows a block diagram of a communication system according to some embodiments;

[0027] Figure QQ2 shows a block diagram of a user equipment according to some embodiments;

[0028] Figure QQ3 shows a block diagram of a network node according to some embodiments;

[0029] Figure QQ4 is a block diagram of a host according to some embodiments, which may be an embodiment of the host of Figure QQ1;

[0030] Figure QQ5 is a block diagram of a virtualized environment according to some embodiments; and

[0031] Figure QQ6 shows a communication diagram of a host communicating with a user device via a network node over a partially wireless connection according to some embodiments. DETAILED DESCRIPTION

[0032] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. The embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art, wherein examples of embodiments of the inventive concept are shown. However, the inventive concept can be embodied in many different forms and should not be construed as being limited to the embodiments described herein. On the contrary, these embodiments are provided so that the present disclosure will be thorough and complete and will fully convey the scope of the inventive concept to those skilled in the art. It should also be noted that these embodiments are not mutually exclusive. Components from one embodiment may be defaulted to being present in / used in another embodiment.

[0033] Additional information may also be found in one or more of the documents provided in the appendices.

[0034] In some embodiments, the term "uplink control information ("UCI") based notification" is used herein to refer to the gNB notifying an unused configuration grant ("CG") physical uplink shared channel ("PUSCH"). In some examples, the UCI based notification is referred to as UCI and should not be assumed to be the same as other UCI (e.g., hybrid automatic repeat request ("HARQ") acknowledgement ("ACK") unless explicitly specified otherwise.

[0035] Additional or alternative embodiments described herein may be applicable to licensed, shared, New Radio - Unlicensed (“NR-U”), New Radio (“NR”), Time Division Duplex (“TDD”), and Frequency Division Duplex (“FDD”) types of spectrum.

[0036] The innovations herein are generally described with respect to the Uplink Configuration Grant ("ULCG") scenario, where, for the UL data transmission use case, transmission ("Tx") is performed by the communication device (also referred to as User Equipment ("UE")) and reception ("Rx") is performed by the gNB. However, the same concepts can be applied to the Sidelink (SL) use case where both Tx and Rx are UE, i.e., on the PC5 interface, which can be based on Mode 1 and Mode 2 (autonomous) resource allocation.

[0037] In some embodiments, the term "multiple transport block ("TB") allocation in a period". It may also be called multi-slot or multi-HARQ or multi-transmission or multi-PUSCH transmission. The essence is that the scheduled resource allocation may span multiple scheduled time units in a CG period (i.e., N time units, N is an integer and N>1), where a time unit may be a slot (hence: multi-slot allocation), or a time unit may be a mini-slot (hence: multi-mini-slot allocation), or a time unit may be a group of N consecutive symbols. Scheduling does not have to be purely slot-based. For example, a CG period of 3 slots may have resources allocated for 3 TBs in a period spanning 1.5 slots, i.e., sym0 to sym5 for TB1, sym6 to sym13 for TB2, and sym0 to sym6 in the next slot for TB3, i.e., a type of multi-slot allocation with 3 TBs or HARQ processes in each period.

[0038] The UCI indication timeline for notifying unused CG PUSCH is described as follows and is Figure 4 is shown in .

[0039] In some embodiments, when the gNB receives a UCI indication where the UE indicates a PUSCH not to be used for transmission no earlier than X symbols after the first symbol indicated by the UCI, this gives the gNB enough time to reclaim or use the unused PUSCH for other purposes, such as allocation to another UE.

[0040] Figure 4 An example is shown where the UE must indicate UCI notification X symbols before the unused PUSCH resource allocation.

[0041] In an additional or alternative embodiment, parameter X is configured by the gNB / network and may be a bit field in an RRC parameter and / or a CG activation DCI.

[0042] In additional or alternative embodiments, the gNB may determine the parameter X based on the delay it experiences, the delay comprising a non-limiting amount, the non-limiting amount comprising at least one of: UCI reception and decoding time; physical downlink control channel ("PDCCH") (downlink control information ("DCI")) preparation and transmission time; UE's PDCCH reception and decoding time; time alignment delay due to slot boundaries or mini-slot boundaries or TDD mode or control resource set ("CORESET") allocation; and K2 delay. Therefore, different gNBs / cells may have different numerical choices for parameter X.

[0043] In an additional or alternative embodiment, for unused PUSCH indicated by the UE, the gNB shall not trigger a retransmission grant for the corresponding PUSCH or HARQ process.

[0044] In additional or alternative embodiments, if the UCI indicates an unused PUSCH, this may be accomplished by indicating non-restrictive options (eg, HARQ ID of the PUSCH; resource allocation of the PUSCH; and / or time-frequency region of the PUSCH).

[0045] In additional or alternative embodiments, the resources may be divided into time-frequency regions / groups, where each group has P physical resource blocks ("PRBs") and S symbols of the same size. Each group is assigned a unique identifier ("ID"). If the UE wants to indicate unused PUSCH resources, it may indicate those group IDs that have PUSCH overlap, which the UE does not intend to use. The time-frequency regions / resources may be jointly indicated by a two-dimensional ("2D") bitmap on the time-frequency partitions within the reference region. The reference design may be similar to a downlink ("DL") preemption indication or uplink ("UL") cancellation indication reference region design.

[0046] In additional or alternative embodiments, UCI-based notification is applicable to certain capability UEs (eg, XRUEs).

[0047] In an additional or alternative embodiment, UCI-based notification applies if the CG resources are configured with multiple PUSCH / resources / opportunities in the CG period.

[0048] In an additional or alternative embodiment, the UCI notification is sent to indicate unused resources (e.g., within the same CG cycle, which means that the UCI must be sent within that CG cycle and the unused resource indication applies to the same cycle; and / or one or more CG cycles).

[0049] In additional or alternative embodiments, UCI-based motivation may be allowed only when the UE is configured with N PUSCHs. For example, in a CG period, if the number of allocated PUSCHs is small, the UE is not allowed to use UCI-based notification). In some examples, UCI-based motivation may be allowed only when the UE is configured with a number of PUSCHs spanning T time units from the first to the last PUSCH. In additional or alternative examples, UCI-based motivation may be allowed only when the UE is configured with a number of PUSCHs spanning Y symbols from the first to the last PUSCH (e.g., parameter Y>X).

[0050] In additional or alternative embodiments, the UE is not allowed to transmit UCI notifications in the last L PUSCHs, where L = 1 or more.

[0051] In an additional or alternative embodiment, the UE is allowed to send UCI in the last symbol before unused resources / PUSCH, which are indicated by the same UCI. This feature ensures very relaxed timelines and keeps UE complexity low, but at the cost of wasting some resources (such as Figure 5 shown).

[0052] Figure 5 An example is shown in which UCI is always transmitted in the last PUSCH.

[0053] In some embodiments, the UE must send the UCI notification in the first PUSCH.

[0054] In additional or alternative embodiments, the UE must send UCI notification in all PUSCHs (transmitted or used PUSCHs).

[0055] In additional or alternative embodiments, PUSCH transmissions not used by the UE are counted toward the number of PUSCHs that the UE can support per timeslot.

[0056] In an additional or alternative embodiment, UCI may be sent on PUCCH which may be allocated in different carriers. It means that PUSCH is allocated in carrier C1 and UCI is sent on carrier C2.

[0057] In additional or alternative embodiments, different carriers may be of different numerologies or subcarrier spacings ("SCS").

[0058] In an additional or alternative embodiment, the UE may send a UCI notification to indicate unused PUSCH for certain repetitions. For example, if 4 repetitions are allocated for PUSCH, the UE may send a UCI to indicate that the unused resources correspond to 2 repetitions.

[0059] In additional or alternative embodiments, if the PUSCH includes UCI notification (multiplexed UCI notification), other UCI (eg, HARQ-ACK based UCI) cannot be multiplexed (or piggybacked) with the same PUSCH.

[0060] In an additional or alternative embodiment, if the gNB has canceled "one or more" PUSCHs using a Cancellation Indication (CI), then if the UE does not want to use it, the UE does not need to report / indicate those "multiple" PUSCHs using UCI notification because they have been canceled by the gNB.

[0061] In additional or alternative embodiments, for example, where dynamic multi-slot UL allocation is used, UCI notification may be applied for dynamic grant-based allocations, including multiple PUSCHs.

[0062] In an additional or alternative embodiment, if UCI is sent in a certain PUSCH (e.g., PUSCH #A) to indicate unused other PUSCH resources, where the unused PUSCH resources are expected to serve similar services, such as service #V (services with the same PHY priority or LCH restriction) being served by PUSCH #A. However, if the same UE has other resources allocated for other services that overlap with the unused resources, the UE is free to use the unused resources for the other services, but if the UE has reported the unused resources through UCI, the unused resources cannot be used for service #V.

[0063] In additional or alternative embodiments, UCI notification may be accomplished via CG-UCI. Currently, CG-UCI is used in NR-U. For NR, it is disabled. Therefore, CG-UCI may be enabled in NR and reuse its existing bit field to indicate UCI notification.

[0064] In an additional or alternative embodiment, the UCI notification may be sent using the CG-UCI, wherein the HARQ field in the CG-UCI may indicate the HARQ ID #J of the unused PUSCH. In an additional option, all HARQ IDs of the PUSCH allocated after HARQ ID #J will also be considered unused - let's take an example where the CG period has allocated 6 PUSCHs with HARQ IDs (e.g. 6, 8, 10, 12, 1, 3). If the UCI sent by the UE is a certain one and the HARQ ID in the UCI notification based on the CG-UCI is 12, then it means that the PUSCHs corresponding to HARQ IDs 12, 1 and 3 are unused.

[0065] In additional or alternative embodiments, the network may define resources for sending UCI notifications, which may be, for example, (1) UCI ​​is always sent at a specific time in a time slot; and / or (2) UCI ​​can be sent in any one or more symbols within a range of X symbols in a time slot.

[0066] In an additional or alternative embodiment, the UE may further indicate a time period or length of unused resources, such as Z symbols / time unit / resource. Figure 6 The value Z may be configured in the radio resource control ("RRC") or may be indicated by the UE in the UCI.

[0067] Figure 6An example is shown in which the UE indicates, via UCI, unused resources for a period of Z time units.

[0068] An embodiment in which the UE indicates one or more unused CG opportunities / resources is described below.

[0069] In some embodiments, using a hybrid approach or pre-scheduling to implement dynamic granting ("DG") provides the greatest gains. The capacity gains for any CG enhancement do not appear to exceed DG significantly enough to justify the enhancement.

[0070] With regard to a specific enhancement technique, in which oversubscribed CG resources can be reused by enabling dynamic indications from the UE to provide information about the utility of the configured resources, several observations can be made. In some examples, the scheme aims to reduce SR / BSR delays when DG is applied, but brings inefficient resource utilization efficiency. The proposed solution to improve resource utilization is through signaling from the UE. However, the usefulness of the scheme depends on the signaling delay. This is because there will always be a delay between the CG indication transmission and the sending of DCI to other / same UEs to utilize the unused resources and the final transmission by the UE on the unused resources. Therefore, even if the CG indication function is enabled, resource waste cannot be completely reduced. In an additional or alternative example, the utilization of UCI will negatively affect the shared channel capacity slightly, which may be small but not zero. In an additional or alternative example, incorporating dynamic signaling into the CG will bring the CG closer to the DG and its existing implementation style. In an additional or alternative example, unless the indication is based on the existing CG-UCI framework (which has been standardized for NR-UCG PUSCH transmission), the specification workload may be large.

[0071] There is a delay between the UCI indication for unused resources in the CG and transmission over those unused resources again. Based on the above observations, it may not be advantageous to pursue such enhancements when not enough capacity gain is provided to counter the dynamic approach (with or without XR awareness).

[0072] In some embodiments, a process is provided to not pursue CG enhancement based on dynamic indication of one or more CG opportunities / resources that are not used by the UE. In some examples, if such enhancement is considered, there is no need to introduce a new framework, where the CG-UCI framework can be reused to provide indications.

[0073] In additional or alternative embodiments, enhancements based on the CG-UCI framework to provide the UE with an indication of one or more CGPUSCH opportunities or resources that are not used may be considered to investigate whether corresponding capacity performance gains are provided with reasonable signaling delay assumptions.

[0074] Reference will now be made to some embodiments according to the present invention. Figure 7 The flowchart of FIG. QQ200 discusses the operation of the communication device QQ200 (implemented using the structure of the block diagram of FIG. QQ2). For example, the modules may be stored in the memory QQ210 of FIG. QQ2, and these modules may provide instructions so that when the instructions of the modules are executed by the corresponding communication device processing circuit QQ202, the processing circuit QQ202 performs the corresponding operations in the flowchart.

[0075] Figure 7 Examples of operations performed by a communications device according to some embodiments are shown.

[0076] At block 710, the processing circuit QQ202 determines a threshold number of symbols indicating that UCI for an unused PUSCH is to be sent the threshold number of symbols before the unused PUSCH.

[0077] At block 720 , the processing circuit QQ 202 sends UCI indicating an unused PUSCH via the communication interface QQ 206 .

[0078] With respect to some embodiments of communication devices and related methods, Figure 7 Various operations of the flowcharts may be optional.

[0079] Reference will now be made to some embodiments according to the present invention. Figure 8 The flowchart of discusses the operation of the RAN node QQ300 (implemented using the structure of Figure QQ3). For example, the modules may be stored in the memory QQ304 of Figure QQ3, and these modules may provide instructions so that when the instructions of the modules are executed by the corresponding RAN node processing circuit QQ220, the RAN node QQ300 performs the corresponding operations in the flowchart.

[0080] Figure 8 Examples of operations performed by a network node according to some embodiments are shown.

[0081] At block 810 , the processing circuit QQ302 receives, via the communication interface QQ312 , UCI indicating an unused PUSCH at least a threshold number of symbols before the unused PUSCH.

[0082] At block 820 , the processing circuit QQ302 adjusts usage of symbols associated with unused PUSCH.

[0083] For some embodiments of RAN nodes and related methods, Figure 8 Various operations in the flowcharts may be optional.

[0084] although Figure 8The description is about RAN nodes, but any suitable network node can perform these operations. For example, these operations can be performed by core network CN node QQ300 (implemented using the structure of Figure QQ3).

[0085] Figure QQ1 shows an example of a communication system QQ100 according to some embodiments.

[0086] In this example, the communication system QQ100 includes a telecommunications network QQ102, which includes an access network QQ104 (e.g., a radio access network (RAN)) and a core network QQ106, which includes one or more core network nodes QQ108. The access network QQ104 includes one or more access network nodes, such as network nodes QQ110a and QQ110b (one or more of which may be generally referred to as network node QQ110), or any other similar third generation partnership project (3GPP) access node or non-3GPP access point. The network node QQ110 facilitates direct or indirect connection of user equipment (UE), such as connecting UE QQ112a, QQ112b, QQ112c, and QQ112d (one or more of which may be generally referred to as UE QQ112) to the core network QQ106 through one or more wireless connections.

[0087] Example wireless communications via wireless connections include sending and / or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and / or other types of signals suitable for transferring information without the use of wires, cables, or other material conductors. In addition, in different embodiments, the communication system QQ100 may include any number of wired or wireless networks, network nodes, UEs, and / or any other components or systems that can facilitate or participate in the communication of data and / or signals, whether via a wired or wireless connection. The communication system QQ100 may include and / or interface with any type of communication, telecommunications, data, cellular, radio network, and / or other similar types of systems.

[0088] UE QQ 112 may be any of a variety of communication devices, including wireless devices that are arranged, configured and / or operable to communicate wirelessly with network node QQ 110 and other communication devices. Similarly, network node QQ 110 is arranged, capable, configured and / or operable to communicate directly or indirectly with UE QQ 112 and / or with other network nodes or devices in telecommunication network QQ 102 to enable and / or provide network access (e.g., wireless network access) and / or perform other functions (e.g., management in telecommunication network QQ 102).

[0089] In the depicted example, the core network QQ106 connects the network node QQ110 to one or more hosts (e.g., host QQ116). These connections can be direct or indirect connections through one or more intermediate networks or devices. In other examples, the network node can be directly coupled to the host. The core network QQ106 includes one or more core network nodes (e.g., core network node QQ108), which are composed of hardware and software components. The features of these components can be substantially similar to the features described for the UE, network node and / or host, so that their description is generally applicable to the corresponding components of the core network node QQ108. Example core network nodes include one or more of the following: a mobile switching center (MSC), a mobility management entity (MME), a home subscriber server (HSS), an access and mobility management function (AMF), a session management function (SMF), an authentication server function (AUSF), a subscription identifier de-hiding function (SIDF), a unified data management (UDM), a security edge protection agent (SEPP), a network open function (NEF) and / or a user plane function (UPF).

[0090] The host QQ 116 may be owned or controlled by a service provider other than the operator or provider of the access network QQ 104 and / or the telecommunications network QQ 102, and may be operated by or on behalf of the service provider. The host QQ 116 may host various applications to provide one or more services. Examples of such applications include live and pre-recorded audio / video content, data collection services (e.g., retrieval and compilation of data of various environmental conditions detected by multiple UEs), analysis functions, social media, functions for controlling or otherwise interacting with remote devices, functions for alarm and monitoring centers, or any other such functions performed by a server.

[0091] In general, the communication system QQ100 of FIG. QQ1 enables connectivity between UEs, network nodes, and hosts. In this sense, the communication system QQ100 can be configured to operate according to predefined rules or procedures, such as specific standards, including but not limited to: Global System for Mobile Communications (GSM); Universal Mobile Telecommunications System (UMTS); Long Term Evolution (LTE) and / or other suitable 2G, 3G, 4G, 5G standards, or any applicable future generation standards (e.g., 6G); Wireless Local Area Network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard (WiFi); and / or any other appropriate wireless communication standards, such as Worldwide Interoperability for Microwave Access (WiMax), Bluetooth, Z-Wave, Near Field Communication (NFC) ZigBee, LiFi, and / or any Low Power Wide Area Network (LPWAN) standards, such as LoRa and Sigfox.

[0092] In some examples, telecommunication network QQ 102 is a cellular network that implements 3GPP standardized features. Therefore, telecommunication network QQ 102 can support network slicing to provide different logical networks to different devices connected to telecommunication network QQ 102. For example, telecommunication network QQ 102 can provide ultra-reliable low-latency communication (URLLC) services to some UEs, while providing enhanced mobile broadband (eMBB) services to other UEs, and / or provide massive machine type communication (mMTC) / massive IoT services to more UEs.

[0093] In some examples, UE QQ112 is configured to send and / or receive information without direct human-computer interaction. For example, the UE can be designed to transmit information to the access network QQ104 according to a predetermined timeline, when triggered by an internal or external event, or in response to a request from the access network QQ104. In addition, the UE can be configured to operate in a single or multi-RAT or multi-standard mode. For example, the UE can operate using any one or a combination of Wi-Fi, NR (New Radio), and LTE, that is, configured for multi-radio dual connectivity (MR-DC), such as E-UTRAN (Evolved UMTS Terrestrial Radio Access Network) New Radio-Dual Connectivity (EN-DC).

[0094] In this example, the hub QQ114 communicates with the access network QQ104 to facilitate indirect communication between one or more UEs (e.g., UE QQ112c and / or QQ112d) and a network node (e.g., network node QQ110b). In some examples, the hub QQ114 may be a controller, a router, a content source and an analyzer, or any other communication device described herein with respect to the UE. For example, the hub QQ114 may be a broadband router that enables the UE to access the core network QQ106. As another example, the hub QQ114 may be a controller that sends commands or instructions to one or more actuators in the UE. The command or instruction may be received from the UE, the network node QQ110, or may be received by an executable code, a script, a process, or other instructions in the hub QQ114. As another example, the hub QQ114 may be a data collector that acts as a temporary storage for UE data, and in some embodiments, may perform analysis or other processing of the data. As another example, the hub QQ114 may be a content source. For example, for a UE that is a VR headset, display, speaker, or other media delivery device, the hub QQ 114 can retrieve VR assets, video, audio, or other media or data related to sensor information via a network node, and then the hub QQ 114 provides it to the UE directly, after performing local processing, and / or after adding additional local content. In another example, the hub QQ 114 acts as a proxy server or coordinator for the UE, especially when one or more of the UEs are low-energy IoT devices.

[0095] Hub QQ114 can have constant / persistent or intermittent connection with network node QQ110b. Hub QQ114 can also allow different communication schemes and / or scheduling between hub QQ114 and UE (e.g., UE QQ112c and / or QQ112d) and hub QQ114 and core network QQ106. In other examples, hub QQ114 is connected to core network QQ106 and / or one or more UEs via a wired connection. In addition, hub QQ114 can be configured to be connected to M2M service provider and / or connected to another UE via direct connection through access network QQ104. In some scenarios, UE can establish wireless connection with network node QQ110, while still connected via hub QQ114 via wired connection or wireless connection. In some embodiments, hub QQ114 can be a dedicated hub, that is, a hub whose main function is to route communication from UE to network node QQ110b and / or from network node QQ110b to UE. In other embodiments, hub QQ 114 may be a non-dedicated hub, ie, a device operable to route communications between UEs and network node QQ 110b, but which is additionally operable as a communications origin and / or endpoint for certain data channels.

[0096] Figure QQ2 shows a UE QQ200 according to some embodiments. As used herein, UE refers to a device capable of, configured, arranged and / or operable to wirelessly communicate with a network node and / or other UEs. Examples of UEs include, but are not limited to, smartphones, mobile phones, cellular phones, voice over IP (VoIP) phones, wireless local loop phones, desktop computers, personal digital assistants (PDAs), wireless cameras, game consoles or devices, music storage devices, playback devices, wearable terminal devices, wireless endpoints, mobile stations, tablet computers, laptops, laptop embedded devices (LEEs), laptop mounted devices (LMEs), smart devices, wireless client equipment (CPEs), vehicle-mounted or vehicle-mounted embedded / integrated wireless devices, etc. Other examples include any UE identified by the Third Generation Partnership Project (3GPP), including narrowband Internet of Things (NB-IoT) UEs, machine type communications (MTC) UEs, and / or enhanced MTC (eMTC) UEs.

[0097] A UE may support device-to-device (D2D) communications, for example, by implementing 3GPP standards for sidelink communications, dedicated short-range communications (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the associated device. Rather, a UE may represent a device that is intended to be sold to or operated by a human user, but may not be associated with a particular human user, or may not initially be associated with a particular human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended to be sold to or operated by an end user, but may be associated with or operated for the benefit of a user (e.g., a smart meter).

[0098] UE QQ200 includes processing circuit QQ202, which is operably coupled to input / output interface QQ206, power supply QQ208, memory QQ210, communication interface QQ212 and / or any other components, or any combination thereof, via bus QQ204. Some UEs may use all or part of the components shown in Figure QQ2. The degree of integration between components may vary from UE to UE. In addition, some UEs may include multiple instances of components, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0099] The processing circuit QQ202 is configured to process instructions and data, and may be configured to implement any sequential state machine operable to execute instructions stored in the memory QQ210 as a machine-readable computer program. The processing circuit QQ202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors (e.g., microprocessors or digital signal processors (DSPs)) together with appropriate software; or any combination of the above. For example, the processing circuit QQ202 may include multiple central processing units (CPUs).

[0100] In this example, the input / output interface QQ206 can be configured to provide one or more interfaces to an input device, an output device, or one or more input and / or output devices. Examples of output devices include speakers, sound cards, video cards, displays, monitors, printers, actuators, transmitters, smart cards, another output device, or any combination thereof. An input device can allow a user to capture information into the UE QQ200. Examples of input devices include touch-sensitive or presence-sensitive displays, cameras (e.g., digital cameras, digital video cameras, web cameras, etc.), microphones, sensors, mice, trackballs, direction pads, trackpads, rollers, smart cards, etc. Presence-sensitive displays can include capacitive or resistive touch sensors to sense input from users. Sensors can be, for example, accelerometers, gyroscopes, tilt sensors, force sensors, magnetometers, optical sensors, proximity sensors, biosensors, etc., or any combination thereof. An output device can use an interface port of the same type as an input device. For example, a universal serial bus (USB) port can be used to provide input devices and output devices.

[0101] In some embodiments, the power supply QQ208 is configured as a battery or a battery pack. Other types of power supplies may be used, such as an external power supply (e.g., a power socket), a photovoltaic device, or a battery. The power supply QQ208 may also include a power supply circuit for delivering power from the power supply QQ208 itself and / or an external power supply to the various components of the UEQQ200 via an input circuit or interface (e.g., a power cable). The delivered power may be used, for example, to charge the power supply QQ208. The power supply circuit may perform any formatting, conversion, or other modification on the power from the power supply QQ208 so that the power is suitable for the various components of the UEQQ200 being powered.

[0102] The memory QQ210 may be a memory or be configured to include a memory such as a random access memory (RAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a magnetic disk, an optical disk, a hard disk, a removable cartridge, a flash drive, etc. In one example, the memory QQ210 includes one or more application programs QQ214, such as an operating system, a web browser application, a widget, a gadget engine, or other applications, and corresponding data QQ216. The memory QQ210 may store any of a variety of operating systems or operating system combinations for use by the UE QQ200.

[0103] The memory QQ210 may be configured to include a plurality of physical drive units, such as a redundant array of independent disks (RAID), a flash memory, a USB flash drive, an external hard drive, a thumb drive, a pen drive, a key drive, a high-density digital versatile disc (HD-DVD) optical drive, an internal hard drive, a Blu-ray optical drive, a holographic digital data storage (HDDS) optical drive, an external micro dual in-line memory module (DIMM), a synchronous dynamic random access memory (SDRAM), an external micro DIMM SDRAM, a smart card memory (e.g., a tamper-proof module in the form of a universal integrated circuit card (UICC), including one or more subscriber identity modules (SIMs), such as a USIM and / or an ISIM, other memories, or any combination thereof. The UICC may be an embedded UICC (eUICC), an integrated UICC (iUICC), or a removable UICC commonly referred to as a “SIM card”. The memory QQ210 may allow the UE to QQ200 accesses instructions, applications, etc. stored on temporary or non-temporary storage media to offload data or upload data. An article of manufacture (e.g., an article of manufacture utilizing a communication system) may be tangibly embodied as or located in memory QQ210, which may be or include a device-readable storage medium.

[0104] The processing circuit QQ202 can be configured to communicate with an access network or other network using a communication interface QQ212. The communication interface QQ212 may include one or more communication subsystems and may include or may be communicatively coupled to an antenna QQ222. The communication interface QQ212 may include one or more transceivers for communication, for example, by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or network node in the access network). Each transceiver may include a transmitter QQ218 and / or a receiver QQ220 suitable for providing network communications (e.g., optical, electrical, frequency allocation, etc.). In addition, the transmitter QQ218 and the receiver QQ220 may be coupled to one or more antennas (e.g., antenna QQ222) and may share circuit components, software or firmware, or may alternatively be implemented separately.

[0105] In the illustrated embodiment, the communication functions of the communication interface QQ212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communication (e.g., Bluetooth, near field communication), location-based communication (e.g., using a global positioning system (GPS) to determine location), another similar communication function, or any combination thereof. Communication may be implemented according to one or more communication protocols and / or standards, such as IEEE 802.11, code division multiple access (CDMA), wideband code division multiple access (WCDMA), GSM, LTE, new radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / Internet protocol (TCP / IP), synchronous optical network (SONET), asynchronous transfer mode (ATM), QUIC, hypertext transfer protocol (HTTP), etc.

[0106] Regardless of the sensor type, the UE can provide an output of the data captured by its sensor via a wireless connection to a network node through its communication interface QQ212. The data captured by the UE's sensor can be transmitted to the network node via another UE via a wireless connection. The output can be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to balance the load of reports from multiple sensors), in response to a trigger event (e.g., sending an alarm when moisture is detected), in response to a request (e.g., a user-initiated request), or a continuous stream (e.g., a live video feed of a patient).

[0107] As another example, the UE includes an actuator, motor, or switch associated with a communication interface that is configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input, the state of the actuator, motor, or switch can change. For example, the UE can include a motor that adjusts a control surface or rotor of a drone in flight based on the received input, or adjusts a robotic arm performing a medical procedure based on the received input.

[0108] When the UE is in the form of an Internet of Things (IoT) device, it can be a device for one or more application areas, including but not limited to urban wearable technology, extended industrial applications, and healthcare. Non-limiting examples of such IoT devices include or are embedded in the following devices: connected refrigerators or freezers, televisions, connected lighting devices, electricity meters, robotic vacuum cleaners, voice-controlled smart speakers, home security cameras, motion detectors, thermostats, smoke detectors, door / window sensors, flood / humidity sensors, electric door locks, connected doorbells, air conditioning systems (such as heat pumps), self-driving cars, surveillance systems, weather monitoring devices, vehicle parking monitoring devices, electric vehicle charging stations, smart watches, fitness trackers, head-mounted displays for augmented reality (AR) or virtual reality (VR), wearable devices for tactile enhancement or sensory enhancement, sprinklers, animal or item tracking devices, sensors for monitoring plants or animals, industrial robots, unmanned aerial vehicles (UAVs), and any type of medical equipment (such as heart rate monitors or teleoperated surgical robots). A UE in the form of an IoT device includes, in addition to the other components described in relation to the UE QQ200 shown in FIG. QQ2 , circuits and / or software depending on the intended application of the IoT device.

[0109] As another specific example, in an IoT scenario, a UE may represent a machine or other device that performs monitoring and / or measurement and transmits the results of such monitoring and / or measurement to another UE and / or a network node. In this case, the UE may be an M2M device, which may be referred to as an MTC device in the 3GPP context. As a specific example, a UE may implement the 3GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, bus, truck, ship, and airplane, or other device capable of monitoring and / or reporting its operating status or other functions related to its operation.

[0110] In practice, any number of UEs may be used together for a single use case. For example, a first UE may be a drone or integrated into a drone and provide the drone's speed information (obtained via a speed sensor) to a second UE, which is a remote controller that operates the drone. When a user makes changes from the remote controller, the first UE may adjust the throttle on the drone (e.g., by controlling an actuator) to increase or decrease the drone's speed. The first UE and / or the second UE may also include more than one of the above functions. For example, the UE may include sensors and actuators, and handle communications for data from the speed sensors and actuators.

[0111] Figure QQ3 shows a network node QQ300 according to some embodiments. As used herein, a network node refers to a device capable of, configured, arranged and / or operable to communicate directly or indirectly with a UE and / or other network nodes or devices in a telecommunications network. Examples of network nodes include, but are not limited to, access points (APs) (e.g., radio access points), base stations (BSs) (e.g., radio base stations, Node Bs, evolved Node Bs (eNBs), and NR Node Bs (gNBs)).

[0112] Base stations may be classified according to the coverage they provide (or in other words, their transmit power level), and therefore, depending on the coverage provided, base stations may be referred to as femto base stations, pico base stations, micro base stations, or macro base stations. A base station may be a relay node or a relay donor node that controls a relay. A network node may also include one or more (or all) parts of a distributed radio base station, such as a centralized digital unit and / or a remote radio unit (RRU), sometimes referred to as a remote radio head (RRH). Such a remote radio unit may or may not be integrated with an antenna as an antenna-integrated radio. The parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

[0113] Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment (e.g., MSR BS), network controllers (e.g., radio network controllers (RNC) or base station controllers (BSC)), base transceiver stations (BTS), transmission points, transmission nodes, multi-cell / multicast coordination entities (MCEs), operations and maintenance (O&M) nodes, operations support system (OSS) nodes, self-organizing network (SON) nodes, positioning nodes (e.g., evolved serving mobile positioning center (E-SMLC)) and / or minimization of drive tests (MDT).

[0114] The network node QQ300 includes a processing circuit QQ302, a memory QQ304, a communication interface QQ306, and a power supply QQ308. The network node QQ300 may be composed of a plurality of physically independent components (e.g., a node B component and an RNC component, or a BTS component and a BSC component, etc.), each of which may have its own components. In certain scenarios where the network node QQ300 includes a plurality of independent components (e.g., a BTS and a BSC component), one or more of the independent components may be shared between a plurality of network nodes. For example, a single RNC may control a plurality of node Bs. In this case, each unique node B and RNC pair may be considered as a single independent network node in certain cases. In some embodiments, the network node QQ300 may be configured to support a plurality of radio access technologies (RATs). In such embodiments, some components may be repeated (e.g., separate memories QQ304 for different RATs), and some components may be reused (e.g., the same antenna QQ310 may be shared by different RATs). The network node QQ300 may also include various illustrated components for multiple groups of different wireless technologies, such as GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z-wave, LoRaWAN, radio frequency identification (RFID), or Bluetooth wireless technologies, integrated into the network node QQ300. These wireless technologies may be integrated into the same or different chips or chipsets and other components within the network node QQ300.

[0115] The processing circuit QQ302 may include a combination of one or more of the following: a microprocessor, a controller, a microcontroller, a central processing unit, a digital signal processor, an application-specific integrated circuit, a field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software, and / or encoded logic, which may be used alone or in combination with other network node QQ300 components (e.g., memory QQ304) to provide network node QQ300 functionality.

[0116] In some embodiments, the processing circuit QQ302 includes a system on a chip (SOC). In some embodiments, the processing circuit QQ302 includes one or more of a radio frequency (RF) transceiver circuit QQ312 and a baseband processing circuit QQ314. In some embodiments, the radio frequency (RF) transceiver circuit QQ312 and the baseband processing circuit QQ314 may be located on separate chips (or chipsets), circuit boards, or units (e.g., a radio unit and a digital unit). In alternative embodiments, part or all of the RF transceiver circuit QQ312 and the baseband processing circuit QQ314 may be located on the same chip or a set of chips, boards, or units.

[0117] The memory QQ304 may include any form of volatile or non-volatile computer-readable memory, including but not limited to persistent memory, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (e.g., hard disk), removable storage media (e.g., flash drive, compact disk (CD) or digital video disk (DVD)) and / or any other volatile or non-volatile, non-transient device-readable and / or computer-executable memory device for storing information, data and / or instructions that can be used by the processing circuit QQ302. The memory QQ304 may store any suitable instructions, data or information, including computer programs, software, applications, including one or more of the following: logic, rules, codes, tables and / or other instructions that can be executed by the processing circuit QQ302 and utilized by the network node QQ300. The memory QQ304 may be used to store any calculations performed by the processing circuit QQ302 and / or any data received via the communication interface QQ306. In some embodiments, the processing circuit QQ302 and the memory QQ304 are integrated.

[0118] The communication interface QQ306 is used for wired or wireless communication of signaling and / or data between network nodes, access networks and / or UEs. As shown, the communication interface QQ306 includes a port / terminal QQ316 for sending data to the network and receiving data from the network, for example, via a wired connection. The communication interface QQ306 also includes a radio front-end circuit QQ318, which can be coupled to the antenna QQ310, or in some embodiments can be coupled to a part of the antenna QQ310. The radio front-end circuit QQ318 includes a filter QQ320 and an amplifier QQ322. The radio front-end circuit QQ318 can be connected to the antenna QQ310 and the processing circuit QQ302. The radio front-end circuit QQ318 can be configured to adjust the signal transmitted between the antenna QQ310 and the processing circuit QQ302. The radio front-end circuit QQ318 can receive digital data to be sent to other network nodes or UEs via a wireless connection. The radio front-end circuit QQ318 can use a combination of the filter QQ320 and / or the amplifier QQ322 to convert the digital data into a radio signal with appropriate channel and bandwidth parameters. The radio signal may then be transmitted via antenna QQ310. Similarly, when receiving data, antenna QQ310 may collect the radio signal, which may then be converted to digital data by radio front end circuit QQ318. The digital data may be passed to processing circuit QQ302. In other embodiments, communication interface QQ306 may include different components and / or different combinations of components.

[0119] In certain alternative embodiments, the network node QQ300 does not include a separate radio front end circuit QQ318; instead, the processing circuit QQ302 includes the radio front end circuit and is connected to the antenna QQ310. Similarly, in some embodiments, all or part of the RF transceiver circuit QQ312 is part of the communication interface QQ306. In other embodiments, the communication interface QQ306 includes one or more ports or terminals QQ316, the radio front end circuit QQ318, and the RF transceiver circuit QQ312 as part of the radio unit (not shown), and the communication interface QQ306 communicates with the baseband processing circuit QQ314, which is part of the digital unit (not shown).

[0120] Antenna QQ310 may include one or more antennas or antenna arrays configured to send and / or receive wireless signals. Antenna QQ310 may be coupled to radio front end circuit QQ318 and may be any type of antenna capable of wirelessly sending and receiving data and / or signals. In some embodiments, antenna QQ310 is separate from network node QQ300 and may be connected to network node QQ300 via an interface or port.

[0121] The antenna QQ310, the communication interface QQ306 and / or the processing circuit QQ302 may be configured to perform any receiving operation and / or certain acquisition operations as performed by the network node described herein. Any information, data and / or signal may be received from the UE, another network node and / or any other network device. Similarly, the antenna QQ310, the communication interface QQ306 and / or the processing circuit QQ302 may be configured to perform any sending operation as performed by the network node QQ300 described herein. Any information, data and / or signal may be sent to the UE, another network node and / or any other network device.

[0122] The power supply QQ308 provides power to the various components of the network node QQ300 in a form suitable for the various components (e.g., at the voltage and current levels required by each of the various components). The power supply QQ308 may also include or be coupled to a power management circuit to provide power to the components of the network node QQ300 for performing the functions described herein. For example, the network node QQ300 may be connected to an external power source (e.g., a power grid or a power outlet) via an input circuit or an interface such as a cable, whereby the external power source supplies power to the power circuit of the power supply QQ308. As a further example, the power supply QQ308 may include a power source in the form of a battery or a battery pack, which is connected to the power circuit or integrated in the power circuit. If the external power source fails, the battery can provide backup power.

[0123] Embodiments of the network node QQ300 may include additional components in addition to those shown in FIG. QQ3 to provide certain aspects of the network node functionality, including any functionality described herein and / or any functionality required to support the subject matter described herein. For example, the network node QQ300 may include a user interface device to allow information to be input into the network node QQ300 and to allow information to be output from the network node QQ300. This may allow a user to perform diagnostics, maintenance, repair, and other management functions on the network node QQ300.

[0124] FIG. QQ4 is a block diagram of a host QQ400 according to various aspects described herein, which may be an embodiment of the host QQ116 of FIG. QQ1. As used herein, the host QQ400 may be or include a combination of various hardware and / or software, including processing resources in a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, a container, or a server farm. The host QQ400 may provide one or more services to one or more UEs.

[0125] The host QQ400 includes a processing circuit QQ402, which is operably coupled to an input / output interface QQ406, a network interface QQ408, a power supply QQ410, and a memory QQ412 via a bus QQ404. Other components may be included in other embodiments. The features of these components may be substantially similar to the features described with respect to the devices in the previous figures (e.g., Figures QQ2 and QQ3), so that their descriptions are generally applicable to the corresponding components of the host QQ400.

[0126] The memory QQ412 may store one or more computer programs (including one or more host applications QQ414) and data QQ416, which may include user data, such as data generated by the UE for the host QQ400 or data generated by the host QQ400 for the UE. An embodiment of the host QQ400 may utilize only a subset or all of the components shown. The host application QQ414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for a variety of different categories, types, or implementations of UE (e.g., mobile phones, desktop computers, wearable display systems, heads-up display systems). The host application QQ414 may also provide user authentication and license checks, and may periodically report health status, routing, and content availability to a central node (e.g., a device in a core network or on the edge). Thus, the host QQ 400 may select and / or indicate different hosts for over-the-top (OTT) services for the UE. The host application QQ 414 may support various protocols, such as HTTP Live Streaming (HLS) protocol, Real-time Messaging Protocol (RTMP), Real-time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

[0127] Figure QQ5 is a block diagram showing a virtualized environment QQ500, in which the functions implemented by certain embodiments can be virtualized. In this context, virtualization means creating a virtual version of a device or equipment, which may include a virtualized hardware platform, storage device, and network resources. As used herein, virtualization may be applied to any device or component thereof described herein, and relates to the implementation of at least a portion of the functions being implemented as one or more virtual components. Some or all of the functions described herein may be implemented as virtual components executed by one or more virtual machines (VMs), which are implemented in one or more virtual environments QQ500 hosted by one or more hardware nodes (e.g., hardware computing devices running as network nodes, UEs, core network nodes, or hosts). In addition, in embodiments where a virtual node does not require a radio connection (e.g., a core network node or host), the node may be fully virtualized.

[0128] Application QQ502 (which may also be referred to as a software instance, a virtual device, a network function, a virtual node, a virtual network function, etc.) runs in the virtualization environment QQ500 to implement some features, functions and / or advantages of some embodiments disclosed herein.

[0129] Hardware QQ504 includes processing circuitry, memory storing software and / or instructions executable by the hardware processing circuitry, and / or other hardware devices described herein, such as network interfaces, input / output interfaces, etc. The software may be executed by the processing circuitry to instantiate one or more virtualization layers QQ506 (also referred to as virtual machine hypervisors or virtual machine monitors (VMMs)), provide VM QQ508a and QQ508b (one or more of which may be collectively referred to as VM QQ508), and / or perform any functions, features, and / or advantages associated with some embodiments described herein. Virtualization layer QQ506 may present a virtual operating platform to VM QQ508 that looks like networked hardware.

[0130] VM QQ508 includes virtual processing, virtual memory, virtual network or interface and virtual storage device, and can be operated by corresponding virtualization layer QQ506. Different embodiments of the instance of virtual device QQ502 can be implemented on one or more VMQQ508, and can be implemented in different ways. Virtualization of hardware is sometimes referred to as network function virtualization (NFV). NFV can be used to integrate many network device types onto industry-standard high-capacity server hardware, physical switches and physical storage, which can be located in data centers and client devices.

[0131] In the context of NFV, VM QQ508 can be a software implementation of a physical machine that runs programs as if they were running on a physical, non-virtualized machine. Each VM QQ508 and the portion of hardware QQ504 on which the VM runs (whether it is hardware dedicated to the VM or hardware shared by the VM with other VMs) form a separate virtual network element. Still in the context of NFV, a virtual network function is responsible for handling a specific network function running in one or more VM QQ508 on top of hardware QQ504 and corresponds to an application QQ502.

[0132] Hardware QQ504 can be implemented in a standalone network node with general or specific components. Hardware QQ504 can implement some functions via virtualization. Alternatively, hardware QQ504 can be part of a larger hardware cluster (for example, in a data center or CPE), where many hardware nodes work together and are managed via management and orchestration QQ510, which, among other things, oversees the life cycle management of application QQ502. In some embodiments, hardware QQ504 is coupled to one or more radio units, each of which includes one or more transmitters and one or more receivers, which can be coupled to one or more antennas. The radio unit can communicate directly with other hardware nodes via one or more appropriate network interfaces, and can be used in combination with virtual components to provide radio capabilities to virtual nodes (such as radio access networks or base stations). In some embodiments, some signaling can be provided using a control system QQ512, which can be used alternatively for communication between hardware nodes and radio units.

[0133] Figure QQ6 shows a communication diagram of a host QQ602 communicating with a UE QQ606 over a partial wireless connection via a network node QQ604 according to some embodiments. According to various embodiments, an example implementation of a UE (e.g., UE QQ112a of Figure QQ1 and / or UE QQ200 of Figure QQ2), a network node (e.g., network node QQ110a of Figure QQ1 and / or network node QQ300 of Figure QQ3) and a host (e.g., host QQ116 of Figure QQ1 and / or host QQ400 of Figure QQ4) discussed in the previous paragraphs will now be described with reference to Figure QQ6.

[0134] As with the host QQ400, an embodiment of the host QQ602 includes hardware, such as a communication interface, a processing circuit, and a memory. The host QQ602 also includes software, which is stored in or accessible by the host QQ602 and can be executed by the processing circuit. The software includes a host application, which is operable to provide services to a remote user, such as a UE QQ606 connected via an over-the-top (OTT) connection QQ650 extending between the UE QQ606 and the host QQ602. In providing services to the remote user, the host application can provide user data transmitted using the OTT connection QQ650.

[0135] The network node QQ 604 includes hardware that enables the network node QQ 604 to communicate with the host QQ 602 and the UE QQ 606. The connection QQ 660 can be direct, or through a core network (such as the core network QQ 106 of FIG. QQ 1) and / or one or more other intermediate networks (e.g., one or more public, private or managed networks). For example, the intermediate network can be a backbone network or the Internet.

[0136] UE QQ606 includes hardware and software, the software is stored in UE QQ606 or can be accessed by UE QQ606, and can be executed by the processing circuit of UE. The software includes a client application, such as a web browser or an operator-specific "application", which is operable to provide services to human users or non-human users via UE QQ606 with the support of host QQ602. In host QQ602, the executing host application can communicate with the executing client application via the OTT connection QQ650 terminated at UE QQ606 and host QQ602. When providing services to users, the client application of UE can receive request data from the host application of the host and provide user data in response to the request data. OTT connection QQ650 can transmit both request data and user data. The client application of UE can interact with the user to generate user data, which is provided to the host application through OTT connection QQ650.

[0137] The OTT connection QQ650 may extend via a connection QQ660 between the host QQ602 and the network node QQ604 and via a wireless connection QQ670 between the network node QQ604 and the UE QQ606 to provide connectivity between the host QQ602 and the UE QQ606. The connection QQ660 and the wireless connection QQ670 (via which the OTT connection QQ650 may be provided) have been drawn abstractly to illustrate communications between the host QQ602 and the UE QQ606 via the network node QQ604, without explicit reference to any intermediate devices and the precise routing of messages via these devices.

[0138] As an example of transmitting data via OTT connection QQ650, in step QQ608, host QQ602 provides user data, which can be performed by running a host application. In some embodiments, user data is associated with a specific human user interacting with UE QQ606. In other embodiments, user data is associated with UE QQ606 that shares data with host QQ602 without explicit human interaction. In step QQ610, host QQ602 initiates a transmission carrying user data to UE QQ606. Host QQ602 can initiate transmission in response to a request sent by UE QQ606. The request can be caused by human interaction with UE QQ606, or by the operation of a client application running on UE QQ606. According to the teachings of the embodiments described in the present disclosure, the transmission can be transmitted via network node QQ604. Therefore, in step QQ612, according to the teachings of the embodiments described throughout the present disclosure, network node QQ604 transmits the user data carried in the transmission initiated by host QQ602 to UE QQ606. In step QQ614 , UE QQ606 receives the user data carried in the transmission, which may be performed by a client application running on UE QQ606 , which is associated with a host application running on host QQ602 .

[0139] In some examples, UE QQ606 runs a client application that provides user data to host QQ602. User data can be provided as a reaction or response to data received from host QQ602. Therefore, in step QQ616, UE QQ606 can provide user data, which can be performed by running a client application. When providing user data, the client application can also consider user input received from the user via the input / output interface of UE QQ606. Regardless of the specific manner of providing user data, UE QQ606 initiates the transmission of user data to host QQ602 via network node QQ604 in step QQ618. In step QQ620, according to the teachings of the embodiments described in the present disclosure, network node QQ604 receives user data from UE QQ606 and initiates the transmission of the received user data to host QQ602. In step QQ622, host QQ602 receives the user data carried in the transmission initiated by UE QQ606.

[0140] One or more of the various embodiments improve the performance of OTT services provided to UE QQ 606 using OTT connection QQ 650, wherein wireless connection QQ 670 forms the last leg. More specifically, the teachings of these embodiments can improve data rate and / or latency, thereby providing benefits such as reduced user waiting, better responsiveness, and improved user experience.

[0141] In an example scenario, host QQ602 can collect and analyze plant status information. As another example, host QQ602 can process audio and video data that may have been retrieved from the UE for use in creating a map. As another example, host QQ602 can collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, host QQ602 can store surveillance videos uploaded by the UE. As another example, host QQ602 can store or control access to media content such as video, audio, VR, or AR that can be broadcast, multicast, or unicast to the UE. As other examples, host QQ602 can be used for energy pricing, remote control of non-time-critical power loads to balance power generation demand, location services, presentation services (compiling, for example, charts of data collected from remote devices, etc.), or any other function of collecting, retrieving, storing, analyzing, and / or transmitting data.

[0142] In some examples, a measurement process may be provided for monitoring data rate, latency, and other factors that one or more embodiments improve. There may also be an optional network function for reconfiguring the OTT connection QQ650 between the host QQ602 and the UE QQ606 in response to changes in the measurement results. The measurement process and / or the network function for reconfiguring the OTT connection may be implemented in the software and hardware of the host QQ602 and / or the UE QQ606. In some embodiments, sensors (not shown) may be deployed in or associated with other devices through which the OTT connection QQ650 passes; the sensors may participate in the measurement process by providing the values ​​of the monitoring quantities exemplified above or by providing the values ​​of other physical quantities, and the software may calculate or estimate the monitoring quantities based on the values ​​of the other physical quantities. The reconfiguration of the OTT connection QQ650 may include message formats, retransmission settings, preferred routes, etc.; the reconfiguration does not require direct changes to the operation of the network node QQ604. Such processes and functions are known and practiced in the art. In some embodiments, the measurement may involve proprietary UE signaling, which helps the host QQ602 measure throughput, propagation time, latency, etc. The measurement can be achieved by software causing a message (particularly an empty or "dummy" message) to be transmitted using the OTT connection QQ650 while monitoring propagation time, errors, etc.

[0143] Although the computing devices (e.g., UE, network node, host) described herein may include the hardware component combinations shown, other embodiments may include computing devices with different component combinations. It will be understood that these computing devices may include any suitable hardware and / or software combination required to perform the tasks, features, functions and methods disclosed herein. The determination, calculation, acquisition or similar operations described herein may be performed by a processing circuit, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or the converted information with the information stored in the network node, and / or performing one or more operations based on the obtained information or the converted information, and making a determination based on the result of the processing. In addition, although the components are depicted as being located within a larger box or nested within multiple boxes, in practice, a computing device may include multiple different physical components constituting a single illustrated component, and functions may be divided between separate components. For example, a communication interface may be configured to include any component described herein, and / or the functions of a component may be divided between a processing circuit and a communication interface. In another example, the non-computationally intensive functions of any such component may be implemented in software or firmware, while the computationally intensive functions may be implemented in hardware.

[0144] In some embodiments, some or all of the functionality described herein may be provided by a processing circuit that executes instructions stored in a memory, which in some embodiments may be a computer program product in the form of a non-temporary computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by a processing circuit without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hardwired manner. In any of these specific embodiments, the processing circuit may be configured to perform the described functionality, regardless of whether instructions stored on a non-temporary computer-readable storage medium are executed. The benefits provided by such functionality are not limited to processing circuits alone or to other components of a computing device, but may generally be enjoyed by the entire computing device and / or end users and wireless networks. Example 1. A method of operating a communication device in a communication network comprising a network node, the method comprising: Determining a threshold number of symbols, uplink control information UCI indicating that a physical uplink shared channel PUSCH that the communication device will not use for transmission is to be sent at the threshold number of symbols before the PUSCH that the communication device will not use for transmission; and UCI indicating the PUSCH is sent at least the threshold number of symbols before the PUSCH. 2. The method of embodiment 1, wherein determining the threshold number of symbols comprises receiving an indication of the threshold number of symbols from a network node as part of at least one of: Radio Resource Control (RRC) parameters; and The configuration permission in the downlink control information is activated. 3. The method of embodiment 2, wherein determining a threshold number of symbols comprises determining a threshold based on a delay experienced by a network node. 4. The method of embodiment 3, wherein the delay comprises at least one of the following: UCI acceptance time; UCI decoding time; Physical downlink control channel (PDCCH) preparation time; PDCCH transmission time; Downlink Control Information (DCI) preparation time; DCI transmission time; a reception time of a PDCCH associated with the communication device; a decoding time of a PDCCH associated with the communication device; Due to time alignment delays at slot boundaries; Due to time alignment delays at mini-slot boundaries; Due to the time alignment delay of the time division duplex (TDD) mode; Time alignment delay due to control resource set (CORESET) allocation; and K2 delay. 5. The method of any one of embodiments 1-4, wherein sending the UCI comprises sending the UCI in a first PUSCH in a configured grant used by the communication device. 6. The method of any one of embodiments 1-4, wherein sending the UCI comprises sending the UCI in each PUSCH in a configured grant used by the communication device. 7. A method of operating a network node in a communication network comprising a communication device, the method comprising: receiving uplink control information UCI from a communication device, the UCI indicating a physical uplink shared channel PUSCH not used for transmission by the communication device, the UCI being at least a threshold number of symbols before the PUSCH not used for transmission; and Based on the received UCI, usage of symbols associated with the PUSCH not used for transmission is adjusted. 8. The method according to embodiment 7, further comprising: sending an indication of a threshold number of symbols to a communications device as part of at least one of: Radio Resource Control (RRC) parameters; and The configuration permission in the downlink control information is activated. 9. The method according to embodiment 7, further comprising: Based on the delay experienced by the network nodes, a threshold is determined. 10. The method according to embodiment 9, wherein the delay comprises at least one of the following: UCI acceptance time; UCI decoding time; Physical downlink control channel PDCCH preparation time; PDCCH transmission time; Downlink control information DCI preparation time; DCI transmission time; a reception time of a PDCCH associated with the communication device; a decoding time of a PDCCH associated with the communication device; Due to time alignment delays at slot boundaries; Due to time alignment delays at mini-slot boundaries; Due to the time alignment delay in time division duplex TDD mode; Due to the time alignment delay of the control resource set CORESET allocation; and K2 delay. 11. The method of any one of embodiments 7-10, wherein receiving the UCI comprises receiving the UCI in a first PUSCH in a configured grant used by the communication device. 12. The method of any one of embodiments 7-10, wherein receiving UCI comprises receiving UCI in each PUSCH in a configured grant used by the communication device. 13. A communication device (QQ200) in a communication network comprising a network node, the communication device comprising: processing circuit (QQ202); and A memory (QQ210) coupled to the processing circuit and having instructions stored therein, the instructions being executable by the processing circuit to cause the entity to perform operations including any of the operations in Embodiments 1-6. 14. A computer program comprising program code executed by a processing circuit (QQ202) of a communication device (QQ200) in a communication network comprising a network node, whereby execution of the program code causes an entity to perform operations including any of the operations in embodiments 1-6. 15. A computer program product comprising a non-temporary storage medium (QQ210), the non-temporary storage medium comprising a program code to be executed by a processing circuit (QQ202) of a communication device (QQ200) in a communication network comprising network nodes and communication devices, whereby execution of the program code causes the entity to perform operations including any of the operations in Examples 1-6. 16. A non-transitory computer-readable medium having instructions stored therein executable by a processing circuit (QQ202) of a communication device (QQ200), the communication device being configured to perform operations including any of the operations of embodiments 1-6. 17. A network node (QQ300) in a communication network comprising communication devices, the entity comprising: processing circuit (QQ302); and A memory (QQ304) coupled to the processing circuit and having instructions stored therein, the instructions being executable by the processing circuit to cause the entity to perform operations including any of the operations of embodiments 7-12. 18. A computer program comprising program code, the program code being executed by a processing circuit (QQ302) of a network node (QQ300) in a communication network comprising communication devices, whereby execution of the program code causes the entity to perform operations including any of the operations in embodiments 7-12. 19. A computer program product comprising a non-transitory storage medium (QQ304) comprising program code to be executed by a processing circuit (QQ302) of a network node (QQ300) in a communication network comprising a communication device, whereby execution of the program code causes the entity to perform operations including any operations of embodiments 7-12. 20. A non-transitory computer-readable medium having instructions stored therein executable by a processing circuit (QQ302) of a network node (QQ300), the network node configured to perform operations including any of the operations of embodiments 7-12. 21. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and A network interface is configured to initiate a user data transmission to a network node in a cellular network for transmission to a user equipment (UE), the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to perform the following operations to send the user data from the host to the UE: receiving uplink control information UCI from the communication device, the UCI indicating a physical uplink shared channel PUSCH not used for transmission by the communication device, the UCI being at least a threshold number of symbols before the PUSCH not used for transmission; and Based on the received UCI, usage of symbols associated with the PUSCH not used for transmission is adjusted. 22. The host of the preceding embodiment, wherein: The processing circuitry of the host is configured to run a host application that provides user data; and The UE includes processing circuitry configured to run a client application associated with a host application to receive a transmission of user data from the host. 23. A method implemented in a host, the host being configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising: providing user data for the UE; and Initiating a transmission carrying user data to a UE via a cellular network including a network node, wherein the network node performs the following operations to send the user data from a host to the UE: receiving uplink control information UCI from the communication device, the UCI indicating a physical uplink shared channel PUSCH not used for transmission by the communication device, the UCI being at least a threshold number of symbols before the PUSCH not used for transmission; and Based on the received UCI, usage of symbols associated with the PUSCH not used for transmission is adjusted. 24. The method of the preceding embodiment further comprises sending, at the network node, user data for the UE provided by the host. 25. The method of any of the two preceding embodiments, wherein the user data is provided at the host by running a host application that interacts with a client application running on the UE, the client application being associated with the host application. 26. A communication system configured to provide an over-the-top service, the communication system comprising: Host, including: A processing circuit configured to provide user data for a user equipment (UE), the user data being associated with an over-the-top service; and a network interface configured to initiate transmission of the user data to a cellular network node for transmission to the UE, the network node having a communication interface and the processing circuit, the processing circuit of the network node being configured to perform the following operations to send the user data from the host to the UE: receiving uplink control information UCI from the communication device, the UCI indicating a physical uplink shared channel PUSCH not used for transmission by the communication device, the UCI being at least a threshold number of symbols before the PUSCH not used for transmission; and Based on the received UCI, usage of symbols associated with the PUSCH not used for transmission is adjusted. 27. The communication system of the previous embodiment further comprises: Network nodes; and / or User equipment. 28. The communication system of the first two embodiments, wherein: The processing circuitry of the host is configured to run a host application to provide user data; and The host application is configured to interact with a client application executing on the UE, the client application being associated with the host application. 29. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to initiate receipt of user data; and A network interface is configured to receive user data from a network node in a cellular network, the network node having a communication interface and a processing circuit, the processing circuit of the network node being configured to perform the following operations to receive user data for a host from a UE: receiving uplink control information UCI from the communication device, the UCI indicating a physical uplink shared channel PUSCH not used for transmission by the communication device, the UCI being at least a threshold number of symbols before the PUSCH not used for transmission; and Based on the received UCI, usage of symbols associated with the PUSCH not used for transmission is adjusted. 30. The host in the above two embodiments, wherein: The processing circuitry of the host is configured to run a host application to provide user data; and The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. 31. The host described in any one of the above two embodiments, wherein initiating reception of user data includes requesting user data. 32. A method implemented by a host, the host being configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising: At the host, reception of user data from the UE is initiated, the user data originating from a transmission that the network node has received from the UE, wherein the network node performs the following operations to receive user data for the host from the UE: Receive uplink control information UCI from a communication device, wherein the UCI indicates a physical uplink shared channel PUSCH not used for transmission by the communication device, wherein the UCI is at least a threshold number of symbols before the PUSCH not used for transmission; and based on receiving the UCI, adjust the use of symbols associated with the PUSCH not used for transmission. 33. The method of the aforementioned embodiment further comprises, at the network node, sending the received user data to the host. 34. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to provide user data; and A network interface configured to initiate a user data transmission to a cellular network for transmission to a user equipment (UE), wherein the UE includes a communication interface and a processing circuit, the communication interface and the processing circuit of the UE are configured to perform the following operations to receive the user data from the host: Determine a threshold number of symbols, indicate that uplink control information UCI of a physical uplink shared channel PUSCH that the communication device will not use for transmission will be sent at a threshold number of symbols before the PUSCH that the communication device will not use for transmission; and send the UCI indicating the PUSCH at least a threshold number of symbols before the PUSCH. 35. The host of the preceding embodiment, wherein the cellular network further comprises a network node configured to communicate with the UE to send user data from the host to the UE. 36. The host of the above two embodiments, wherein: The processing circuitry of the host is configured to run a host application to provide user data; and The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. 37. A method implemented by a host, the host operating in a communication system further comprising a network node and a user equipment (UE), the method comprising: providing user data for the UE; and Initiating a transmission carrying user data to a UE via a cellular network including a network node, wherein the UE performs the following operations to receive the user data from the host: Determining a threshold number of symbols, uplink control information UCI indicating that a physical uplink shared channel PUSCH that the communication device will not use for transmission is to be sent at the threshold number of symbols before the PUSCH that the communication device will not use for transmission; and UCI indicating the PUSCH is sent at least a threshold number of symbols before the PUSCH. 38. The method of the previous embodiment further comprises: At the host, a host application associated with the client application running on the UE is run to receive user data from the UE. 39. The method of the previous embodiment further comprises: At the host, input data is sent to a client application running on the UE, the input data being provided by running the host application, wherein user data is provided by the client application in response to the input data from the host application. 40. A host configured to operate in a communication system to provide an over-the-top (OTT) service, the host comprising: processing circuitry configured to utilize user data; and a network interface configured to receive a transmission of user data transmitted by a user equipment (UE) to a cellular network, The UE includes a communication interface and a processing circuit, and the communication interface and the processing circuit of the UE are configured to perform the following operations to send the user data to the host: Determining a threshold number of symbols, uplink control information UCI indicating that a physical uplink shared channel PUSCH that the communication device will not use for transmission is to be sent at the threshold number of symbols before the PUSCH that the communication device will not use for transmission; and UCI indicating the PUSCH is sent at least a threshold number of symbols before the PUSCH. 41. The host of the preceding embodiment, wherein the cellular network further comprises a network node configured to communicate with the UE to send user data from the UE to the host. 42. The host of the above two embodiments, wherein: The processing circuitry of the host is configured to run a host application to provide user data; and The host application is configured to interact with a client application running on the UE, the client application being associated with the host application. 43. A method implemented by a host, the host being configured to operate in a communication system further comprising a network node and a user equipment (UE), the method comprising: At a host, user data sent by a UE to the host via a network node is received, wherein the UE performs the following operations to send the user data to the host: Determining a threshold number of symbols, uplink control information UCI indicating that a physical uplink shared channel PUSCH that the communication device will not use for transmission is to be sent at the threshold number of symbols before the PUSCH that the communication device will not use for transmission; and UCI indicating the PUSCH is sent at least a threshold number of symbols before the PUSCH. 44. The method of the previous embodiment further comprises: At the host, a host application associated with the client application running on the UE is run to receive user data from the UE. 45. The method of the above embodiment further comprises: At the host, input data is sent to the client application running on the UE, the input data being provided by running the host application, The user data is provided by the client application in response to input data from the host application. appendix 3GPP TSG-RAN WG1 Meeting #111 R1-2210923 Toulouse, France, November 14-18, 2022 Agenda item: 9.10.2 Source: Ericsson Title: Discussion on Capacity Enhancement for XR Documents are used for: discussion, decision 1 Introduction At the RAN Plenary Meeting 94-e[1], a new SI[1] for Rel-18 on Extended Reality (XR) was agreed, with objectives covering 1) XR perception in the RAN, 2) XR-specific power savings, and 3) XR-specific capacity improvements. In this contribution, we discuss possible research topics related to the third area, following the objectives in [1]: “Regarding the targets for XR-specific capacity improvements (RAN1, RAN2): ● Research mechanisms to provide more efficient resource allocation and scheduling for XR service characteristics (periodicity, multi-stream, jitter, latency, reliability, etc.). Focus on the following mechanisms: ○SPS and CG enhancements; ○ Dynamic scheduling / licensing enhancements.” 2 Discussions 2.1CG Enhancement A number of enhancement techniques have been proposed regarding the use of Configuration Grant (CG) based transmission for uplink (UL) video XR services. Based on the discussions during the last meeting, it was agreed that two areas of CG enhancements will be prioritized for further study during the remainder of the SI: From RAN1#110-bis-e[2]: In the following, we discuss our views on the necessity and benefits of CG-based transmission enhancement and the relevant focus areas listed in the above agreement. 2.2.1 Analysis and performance evaluation XR services consist of downlink (DL) and uplink (UL) traffic flows, such as DL / UL video application packets (also called scene traffic in UL), DL audio application packets, and UL gesture / control application packets. These flows have different characteristics (e.g., bit rate, period, jitter) and requirements in terms of (application) packet delay budget (PDB) [5]. The heterogeneity of XR traffic flows may require the use of different transmission schemes. When these transmission schemes are mapped onto XR services, we make the following observations: Dynamic Scheduling and Grant (DG) is a suitable transmission scheme to handle the varying and large size of application packets and possible jitter for DL / UL video XR traffic. Configuration Grant (CG) is a suitable transmission scheme for predictable and fixed small-sized UL traffic, such as gesture / control and BSR triggered by UL video XR traffic. In our view, dynamic scheduling is in principle a better alternative to the current CG framework and related enhancements in order to handle dynamic XR traffic. If the transmission parameters need to be updated due to changes in channel conditions, traffic arrival, packet size, jitter, etc., new dynamic grants can be provided to adapt to such changes. The main criticism of DG scheduling for improving XR capacity is the delay caused by SR and / or BSR in the gNB determining the appropriate grant size after receiving the BSR. In our view, the delay can be reduced based on the use of mechanisms from existing specifications (relying on or not on XR awareness). Below, we explain the reasons accompanied by simulation results that support: It should be known that the network can implement DG scheduling in a variety of ways. ● For example, dynamic allocation based pre-scheduling (already available in gNB implementations) can be used to emulate configured scheduling while keeping the flexibility to grant dynamic resources to dynamic XR traffic. There, we consider XR awareness related information available to the gNB, such as traffic period information and / or statistics about data packet sizes. Thus, grants can be periodically allocated to UEs without requiring the UE to send SRs, while retaining the dynamic scheduling property by updating link adaptation. ●Similarly, the normal DG scheme (non-pre-scheduled) can also take advantage of XR awareness. In this case, after receiving the SR sent by the UE, the gNB can provide an initial grant that enables the UE to initiate data transmission at the same time as sending the BSR. The resource allocation in the initial grant (after the SR) can take advantage of information about the XR packet size statistics (e.g., a grant that fits a minimum-sized XR packet can be provided). The BSR can then be used to decide whether further resources are required in the next time slot to complete the transmission of the XR packet. ●Another DG implementation variant is to rely on CG resources to indicate the arrival of new data to the gNB instead of indicating SR. The NW can configure CG resources to receive not only the indication of new data, but also the BSR to have the initial grant informed. After receiving the data on the CG, the gNB continues to serve the XR service using dynamic scheduling. We have simulated the capacity performance for UL video traffic (10 Mbps and 60 fps) using CG and DG scheduling for system parameters in accordance with Table A.1 in the Appendix, PDB = 30 ms and PDB = 15 ms. We have considered the following cases in our simulations, for which we also provide relevant graphs in the dedicated figures: ●Case 1: Dynamic grant using SR followed by a small initial UL grant: ○ Scheduling is based on dynamic grants, where it is assumed that SR is triggered when a new video packet arrives in the UE buffer. The network provides a small initial grant of 288 bits after receiving the SR. It is assumed that XR traffic is not known. See Figure 1 . Figure 1 : Shows a dynamic scheduling grant scheme using SR, followed by an initial small UL grant (Case 1) ●Case 2: Dynamic grant using SR followed by a large initial UL grant: ○ Scheduling is based on dynamic grants, where it is assumed that SR is triggered when a new video packet arrives in the UE buffer. The network provides an initial grant of 117 kbit size after receiving the SR as the minimum XR packet size used in the simulation (see Note 1 below). It is assumed that the XR traffic period is unknown. See Figure 2 . NOTE 1: Given the traffic model specified in 38.838 [4], a frame rate of 60 fps and a data rate of 10 Mbit / s gives an approximate average packet size of 167 kbit. The minimum and maximum packet sizes are derived in a way that covers 99% of the range of a Gaussian distribution centered on the mean, i.e. from the mean minus three standard deviations to the mean plus three standard deviations. This gives a minimum packet size of 117 kbit and a maximum packet size of 217 kbit. Figure 2 : shows a dynamic scheduling grant scheme using SR followed by an initial large UL grant (Case 2) ●Case 3: Pre-scheduling dynamic licensing (pre-scheduling DG): ○ Scheduling is based on dynamic grants, where the network is assumed to be provided with XR traffic cycles. Without using SR, an initial grant is sent to the UE when its traffic is expected (based on implemented learning). The network provides an initial grant of size 117 kbit as the minimum XR packet size used in the simulation. See Figure 3 . Figure 3: shows the pre-scheduling dynamic admission scheme (case 3) ●Case 4: Configuration permission: ○ Scheduling is based on configuration grants, where it is assumed that the network uses information about traffic period, size statistics, TDD mode, PDB, etc. to derive the appropriate configuration for CG size and period. Initial transmissions occur only on CG occasions, and Retransmissions may occur on dynamic grants. See Figure 4 . ○ We have simulated the performance curves for the following CG configuration parameters and picked out the best configuration to compare with other solutions. ■PDB=30ms, with CGs of size / period (30kbit / 2.5ms), (60kbit / 5ms) and (90kbit / 7.5ms) ●The CG configuration with a period of 5ms and an opportunity size of 60kbit outperforms other CG configurations. ■PDB=15ms, with CGs of size / period (60kbit / 2.5ms) and (100kbit / 2.5ms) ●The CG configuration with a period of 2.5ms and an opportunity size of 60Kbit outperforms other CG configurations. Figure 4 : Show configuration permission scheduling scheme (Case 4) ●Case 5: Configuration and dynamic licensing based on hybrid scheduling (hybrid CG-DG): ○ Scheduling is based on a combination of configuration and dynamic grants. SR resources are not used. Instead, CG resources are configured with a minimum size in each UL timeslot to send a BSR and a small amount of data when new data arrives. Whenever an XR packet arrives in the buffer, the UE uses the nearest possible CG opportunity for BSR transmission and possibly a small amount of data. Therefore, the network can use the BSR to provide dynamic grants for subsequent data transmissions. It is assumed that the XR traffic period is unknown. See Figure 5 . Figure 5 : Show configuration and dynamic authorization based on hybrid scheduling (hybrid CG-DG) (Case 5) ●Case 6: Dynamic scheduling using Elf BSR (DG using Elf BSR): ○ Scheduling is based on dynamic grants, where it is assumed that when a new packet arrives in the UE buffer, a BSR with zero delay is available at the scheduler, which the scheduler will use to indicate the UL grant to the UE. Hence, no SR or BSR delay is assumed in this case. This case is simulated to show an upper bound on capacity performance. See Figure 6 . Figure 6 : Dynamic scheduling without SR and using sprite BSR at gNB (Case 6) Figure 7 The capacity-performance results for PDB=15 ms and PDB=30 ms are shown in . The results show that for larger PDBs, if any potential enhancements are applied to the dynamic adaptation of CG, there will still be no or very limited capacity gain, because the performance using static parameters already matches very close to the upper limit. On the other hand, in the case of smaller PDBs, there may be room for CG improvements. However, in both scenarios, pre-scheduled DG (an improved version of DG) and hybrid allocation (a combination of CG and DG) appear to be cost-effective options, as they can provide better performance than CG or ordinary DG, which is close to the upper limit. For smaller PDB scenarios, hybrid allocation seems to be slightly better than pre-scheduled DG. For pre-scheduled DG, the scheduling operation relies on the availability of periodic information (XR-aware information) at the network. If such a framework related to the transmission of XR-aware information is not provided / standardized, other implementation options (such as scheduling based on hybrid CG and DG) may bring capacity gains. The results support our view that the periodic nature of video XR traffic does not motivate the use of CG-based transmission. Instead, this characteristic motivates the use of dynamic license pre-scheduling or hybrid allocation schemes that are already used in practice. Figure 7 : Percentage of satisfied users, using the XR capacity KPI with a target of 99% packet success rate, for dynamic scheduling with or without SR and for different assumptions on initial grant size, pre-scheduled DG, traditional CG and hybrid CG-DG for transmission of XR video in UL, for PDB=15ms, bottom and PDB=30ms. For convenience, the results and relative gains shown in the figures are summarized in Table 1 below. Table 1 Overview of simulation results for DG and CG scenarios In summary, we believe that research on dynamic adaptation for CG to serve video traffic is poorly motivated and may bring negligible gains in capacity, and on the contrary, may significantly increase power consumption and system complexity. In summary, we propose the following guidelines for evaluating the necessity and benefits of enhancements to DG and CG schemes for XR services. In order to evaluate the necessity and benefits of candidate enhancement technologies for improving the capacity of XR video services, DG-based enhancement technologies are prioritized. In order to evaluate the necessity and benefits of candidate CG enhancement technologies for improving the capacity of XR video services, CG-based transmission for XR video services should be compared with DG-based transmission for XR video services. The necessity and benefits of candidate enhancement technologies for DG and CG schemes for XR services should be evaluated in comparison with existing schemes based on Rel-17 specifications and / or under the assumption of XR perception at the RAN. In addition, based on the analysis and evaluation results of different research cases, we observed the following: The dynamic nature of XR services with frequent / periodic occasions can be handled through existing specifications and gNB implementations. The necessity to support new features to enable dynamic adaptation of CG transports is not justified. Based on our observations, we recommend: Lower the priority of studying enhancements based on dynamic adaptation for CG-based transmissions. 2.2.2 Indication by UE of one or more unused CG opportunities / resources From our CG and DG evaluations, implementations of DG using a hybrid approach or pre-scheduling provide the largest gains. The capacity gains for any CG enhancement do not appear to be significantly greater than DG to justify the enhancement. With regard to the specific enhancement technique, where oversubscribed CG resources can be reused by enabling dynamic indications from the UE to provide information about the utility of the configured resources, we make the following observations: ● This scheme aims to reduce the SR / BSR delay when DG is applied, but there is a problem of inefficient resource utilization. The proposed solution to improve resource utilization is through signaling from the UE. However, the practicality of this scheme depends on the signaling delay. This is because there is always a delay between the CG indication transmission and the sending of DCI to other / same UE to utilize the unused resources and finally the transmission by the UE on the unused resources. Therefore, even if we adopt the CG indication function, the resource waste cannot be completely saved. ●The use of UCI will slightly negatively impact the shared channel capacity, which may be small but not zero. ● Incorporating dynamic signaling into CG will bring CG closer to DG and its existing implementation style. ● The specification effort may be large unless the directive is based on the existing CG-UCI framework, which already targets NR-U CG PUSCH transmission is standardized. There is a delay between the UCI indication for unused resources in the CG and the transmission again on these unused resources. Based on the above observations, we discourage pursuing such enhancements when they do not provide sufficient capacity gains to compete against dynamic approaches (with or without XR-awareness, which we discussed in the previous section). CG enhancement based on dynamic indication by the UE of one or more unused CG opportunities / resources is not pursued. If such enhancement is considered, there is no need to introduce a new framework, where the CG-UCI framework can be reused to provide the indication. Enhancements based on the CG-UCI framework to provide an indication by the UE of unused one or more CG PUSCH opportunities or resources may be considered to study whether corresponding capacity performance gains are provided with reasonable signaling delay assumptions. 2.2.3 Increase the CG PUSCH transmission opportunity in the duration One of the enhancements to CG discussed in the last meeting was to support multiple PUSCH opportunities per CG period to accommodate large video packets. As we concluded in the previous section, DG-based allocation is already able to support dynamic changes in XR video traffic, so any enhancement to CG is unable to provide capacity above that of dynamic license scheduling. In addition to the questionable capacity-performance gains that motivate such enhancements, we discuss the following challenges related to the complexity of the proposed candidate schemes. Regarding the proposed enhancements based on grouping of multiple CG configurations with the same period but different offsets, our views are as follows. Considering the enhancements made in Rel-16, in order to optimize multiple CG frameworks for multiple PUSCHs per cycle, joint activation is missing. It was discussed in Rel-16 whether multiple CG configurations can be grouped and whether they can be jointly activated / reactivated / deactivated using a single DCI. However, only joint deactivation is specified in Rel-16. The shortcomings we observed in supporting joint activation are summarized as follows: For activation as a group, we see the following challenges: ●The network may need to expend signaling to allocate a single CG ID and then configure the group IDs of the group mapped to the single CG ID in order to activate / update / reactivate the CG with the required parameters. ●It may increase latency and PDCCH resource usage as control signaling will be spent, possibly to create a single CG in the first place. • It may also be necessary to modify the DCI, or even add fields for group activation. This is not similar to group deactivation, where many fields in the HARQ bit fields provided by ConfiguredGrantConfigType2DeactivationStateList are not useful, and are therefore used to verify or indicate the group ID. ● To make all CGs belonging to a group have the same parameters (e.g. MCS, RV mode, etc.), it does not make sense to create multiple CGs with the same parameters. Instead, one can aim to design multiple allocations with similar parameters within a single CG. Therefore, we are not convinced to use grouping of CG configurations with joint activation because the complexity of signaling and specifications is high. Based on the above discussion, we make the following suggestions: Enhancements based on joint activation to enable multiple CG opportunities in a cycle are not pursued. While we are not convinced that CG enhancement is justified or necessary to improve XR traffic capacity performance, extending the multi-PUSCH allocation framework to a single CG seems to be the most reasonable approach from a specification and complexity perspective if there is a reason to do so. For extending the multi-PUSCH allocation framework to a single CG, since the number of allocated timeslots is already included in the TDRA table, the activation / reactivation DCI for the CG can be used to support it. The specification complexity may be low compared to the CG-based grouping solution. Upon activation, multiple HARQ processes can be automatically associated with a single CG configuration. At the same time, since there is only one configuration associated with the multi-PUSCH allocation, there is no increase in PDCCH monitoring. In addition, any potential enhancements to the multi-PUSCH framework for dynamic licensing can be inherited. Enhancements based on multiple PUSCH allocation for a single CG may be considered to study whether corresponding capacity performance gains are provided and whether the specification workload is low. 2.2 Dynamic Scheduling Retransmission Enhancement Regarding DG enhancement, the following agreement was reached during RAN1#110-bis-e. From RAN1#110-bis-e[2]: Below, we provide our views on the above aspects. First, for LAA, functionality has been discussed before to enable HARQ retransmissions of TBs on different cells for DL. Several companies have argued that this functionality is not critical for LAA, and we have no reason to believe that this is critical for XR at this time. This functionality has implications for gNB / UE implementation complexity and has implications for signaling. As the proponents say, a signaling mechanism will need to be introduced to indicate that a TB originally sent on a first carrier using a first HARQ process will be retransmitted on a second carrier using a second HARQ process. At a high level, the functionality may appear simple, but the specification details are often complex. One such complexity that we expect to arise is around timing. There are already complex timing rules in the current specification for, for example, the PUSCH preparation time. The PUSCH preparation time has been discussed in depth in previous releases, and the resulting rules have become increasingly complex as new functionality has been introduced. We expect that if a TB will be retransmitted on a different carrier than the one used for the previous transmission, additional time will need to be introduced for the PUSCH preparation time. If the carriers involved will have different numerologies, it is likely that the result will be complex rules. Since the soft bits to be combined do not originate from the same carrier, gNB processing latency will also likely be affected by the TB being retransmitted on different carriers. Scheduling restrictions are imposed due to timing constraints, and this in turn limits the potential gain of using this feature. Retransmitting a TB on another carrier than the one used for the initial transmission will likely result in timing constraints for both the UE and the gNB: - For uplink TB transmission, additional UE restrictions on PUSCH preparation time are expected. - For downlink, additional UE constraints on PDSCH to HARQ feedback time are expected. - Longer gNB processing delays can be expected in both UL and DL cases. - Even stricter restrictions may apply when the two carriers have different numerology sets. Scheduling constraints imposed by time constraints will negatively impact capacity for time-critical services. Based on our observations and the limited time remaining for this SI, we recommend: This mechanism is downgraded to enable the priority of HARQ retransmissions of TBs on different carriers. 2.3 Measurement gap enhancement Below, we consider the above suggestions and discuss our views in this regard. Regarding the Measurement Gap (MG) enhancement, the following agreement was reached during RAN1#109-e From RAN1#109-e[2][3]: The issue of scheduling constraints during measurement gaps and SMTC windows has been extensively discussed in previous sessions. It has been demonstrated that scheduling constraints can negatively impact XR capacity in at least some scenarios and parameter settings. In general, the configuration of MG and SMTC is controlled by the gNB, which can choose the measurement parameters to find the best balance between measurement sampling rate, mobility performance and XR capacity. The specifications today already provide different options and flexibility for the configuration of measurement gaps and SMTC windows, for example, the SMTC window can be 1-5 milliseconds, and there are scenarios where MG is not required. Therefore, we believe that the optimization of scheduling constraints cannot be studied out of context. When it comes to the simulations provided by the proponent companies, we want to ask a few questions: ● In general, how do other parameter settings affect XR capacity, such as shorter MG or shorter SMTC window? In case of signalling from the UE to the gNB regarding the use of measurement periods: ○ How will UE signaling preparation delay and scheduling delay affect XR performance? o Is it possible that the UE will always make measurements and never skip measurements? ○ Is the same functionality already possible today if the gNB does RRC reconfiguration based on available measurements and turns measurement gaps on / off when needed? ● In case of signaling from the gNB to the UE regarding skipping of measurements: o If some measurement cycles are skipped, how will it affect the measurement accuracy in the first order and the mobility performance in the second order, such as handover success rate, radio link failure in handover? ○ How will signaling design affect XR performance? Once again we wish to highlight the fact that the measurement procedures to be performed by the UE are defined in 38.133, which is handled by RAN4. Therefore, any possible changes or studies of potential enhancements to the RAN4 specifications should involve the RAN4 group. Furthermore, the RRM procedures are defined in the TS 38.321 specification, which is handled by RAN2. RAN1 can only provide usable simulation results and recommend that RAN2 and RAN4 further study potential enhancements. As RAN4 is not included in the Rel-18 XR SI, such studies are outside the agreed Rel-18 scope and allocated resources. However, appropriate studies involving all required groups can be performed in the future. RAN1 may suggest that RAN2 and RAN4 study in the future the need and possibility for potential improvements to scheduling restrictions due to measurements, at least for certain scenarios. 3 Conclusion In the previous sections, we made the following observations: Observation 1 Dynamic scheduling and granting (DG) is a suitable transmission scheme to handle the changing traffic for DL / UL video XR services. ized and large application packets and possible jitter. Observation 2 Configuration Grant (CG) is a suitable transmission scheme for predictable and fixed small size UL traffic. Services such as gesture / control and BSR triggered by UL video XR services. Observation 3: Dynamics of XR services with frequent / periodic timings can be handled by existing specifications and gNB implementations sex. Observation 4 The necessity of supporting new features to enable dynamic adaptation of CG transmissions is not justified. Observation 5 UCI indication for unused resources in CG and transmission on these unused resources again There is a delay between Observation 6 Retransmitting a TB on a different carrier than that used for the initial transmission may result in Timing constraints on both UE and gNB: - For uplink TB transmission, additional PUSCH preparation time is expected UE restrictions. - For downlink, additional UE restrictions are expected regarding PDSCH to HARQ feedback time. - In UL and DL - When the two carriers have different numerologies, even longer gNB processing delays can be expected. Tighter restrictions. Observation 7 Scheduling constraints imposed by time constraints will negatively impact capacity for time-critical services. Based on the discussion in the previous sections, we make the following recommendations: Recommendation 1: To evaluate the necessity and benefits of candidate enhancement technologies for improving the capacity of XR video services, priority should be given to DG enhancement technology. Recommendation 2: To evaluate the necessity and benefits of candidate CG enhancement technologies for improving the capacity of XR video services, the use CG-based transmission for XR video services is compared with DG-based transmission for XR video services. Recommendation 3 should be compared with existing solutions based on Rel-17 specifications and / or assumptions about XR perception at the RAN In this paper, the necessity and benefits of candidate enhancement technologies for DG and CG solutions for XR services are evaluated. Recommendation 4 lowers the priority of studying enhancements based on dynamic adaptation for CG-based transmissions. Recommendation 5 does not pursue CG enhancement based on dynamic indication by the UE of one or more unused CG opportunities / resources. Proposal 6 is based on the CG-UCI framework to provide the UE with information on one or more unused CGPUSCH opportunities or resources. The indicated enhancements may be considered to investigate whether they provide corresponding capacity performance gains with reasonable signaling delay assumptions. Proposal 7 does not pursue enhancements based on joint activation to enable multiple CG opportunities in a cycle. Proposal 8 Enhancements based on multiple PUSCH allocation for a single CG may be considered to study whether to provide corresponding Capacity performance gain and regulate if workload is low. Proposal 9 lowers the priority of the mechanism to enable HARQ retransmissions of TBs on different carriers. Proposal 10 RAN1 may recommend that RAN2 and RAN4 study in the future the maximum limit for scheduling restrictions due to measurements. Less need and possibility for potential improvements in certain scenarios. References RP-213587, Study on XR Enhancements for NR, Nokia, RAN#94e, December 2021 3GPP TSG RANWG1#110-bis-e RAN1 Chairman’s Notes, October 10-19, 2022 3GPP TSG RAN WG1#109-e RAN1 Chairman’s Notes, May 9-20, 2022 3GPP TSG RAN WG1#110 Toulouse RAN1 Chair Notes, 22-26 August 2022 3GPP TSG RAN, “Study on XR (Extended Reality) Evaluation for NR (Release 17)”, TR 38.838v1.0.1 appendix Table A.1: System simulation parameters

Claims

1. A method performed by a network node in a communication network comprising a communication device, comprising: sending an indication of a threshold number of symbols to the communications device, such that when the communications device sends an uplink control information (UCI) message indicating that one or more physical uplink shared channel (PUSCH) transmission opportunities configured by the network node will not be used by the communications device, the UCI should be sent at least the threshold number of symbols before the one or more PUSCH transmission opportunities that will not be used; receiving, from the communications device, a UCI message indicating one or more PUSCH transmission opportunities that are not to be used; as well as Adjusting usage of the indicated one or more PUSCH transmission opportunities that are not to be used by the communications device.

2. The method according to claim 1, wherein: Sending the indication includes: sending a radio resource control RRC message, the threshold number being indicated in an RRC parameter in the RRC message; or sending a downlink control information DCI message indicating configuration permission CG activation.

3. The method according to claim 1 or 2, wherein: Receiving the UCI message indicating one or more PUSCH transmission opportunities that will not be used includes: receiving the UCI including a bitmap of time-frequency regions of PUSCH transmission opportunities configured for the communication device, the bitmap indicating the one or more PUSCH transmission opportunities that will not be used.

4. The method according to any one of claims 1 to 3, wherein: The UCI is received within the same CG period to which one or more PUSCH transmission opportunities indicated to be not used belong.

5. A method according to any one of the preceding claims, wherein: Before sending the indication of the threshold number of symbols, further comprising: determining the threshold number of symbols based on at least one of: UCI acceptance time; UCI decoding time; PDCCH preparation time; PDCCH transmission time; DCI preparation time; DCI transmission time; a reception time of the PDCCH associated with the communication device; a decoding time of the PDCCH associated with the communication device; Due to time alignment delays at slot boundaries; Due to time alignment delays at mini-slot boundaries; Due to the time alignment delay in time division duplex TDD mode; Due to the time alignment delay of the control resource set CORESET allocation; and K2 delay.

6. A method according to any one of the preceding claims, wherein: Adjusting usage of the indicated one or more PUSCH transmission opportunities not to be used by the communications device comprises: The one or more PUSCH transmission opportunities are scheduled for another communication device.

7. A network node in a communication network including a communication device, comprising: Processing circuit; and a memory coupled to the processing circuit and having instructions stored therein, the instructions being executable by the processing circuit to cause the network node to: sending an indication of a threshold number of symbols to the communications device, such that when the communications device sends an uplink control information (UCI) message indicating that one or more physical uplink shared channel (PUSCH) transmission opportunities configured by the network node will not be used by the communications device, the UCI should be sent at least the threshold number of symbols before the one or more PUSCH transmission opportunities that will not be used; receiving, from the communications device, a UCI message indicating one or more PUSCH transmission opportunities that are not to be used; as well as Adjusting usage of the indicated one or more PUSCH transmission opportunities that are not to be used by the communications device.

8. The network node according to claim 7, wherein: According to the instructions stored in the memory, the processing circuit further causes the network node to perform the method according to any one of claims 2 to 6.

9. A method performed by a communication device in a communication network comprising a network node, comprising: receiving an indication of a threshold number of symbols from the network node such that when the communications device sends an uplink control information (UCI) message indicating that one or more physical uplink shared channel (PUSCH) transmission opportunities configured by the network node are not to be used by the communications device, the UCI should be sent at least the threshold number of symbols before the one or more PUSCH transmission opportunities that are not to be used; as well as A UCI message is sent at least the threshold number of symbols before one or more PUSCH transmission opportunities that are not to be used, the UCI message indicating the one or more PUSCH transmission opportunities that are not to be used.

10. The method according to claim 9, wherein: The indication of a threshold number of received symbols includes: receiving an RRC message, wherein the threshold number is indicated in an RRC parameter in the RRC message; or receiving a DCI message indicating CG activation.

11. The method according to claim 9 or 10, wherein: The transmitted UCI comprises a bitmap of time-frequency regions of PUSCH transmission opportunities configured for the communication device, the bitmap indicating the one or more PUSCH transmission opportunities not to be used by the communication device.

12. The method according to any one of claims 9 to 11, wherein: The UCI is sent within the same CG period to which one or more PUSCH transmission opportunities indicated to be not used belong.

13. The method according to any one of claims 9 to 12, further comprising: A decoding time of a PDCCH associated with the communication device is sent to the network node.

14. A communication device in a communication network comprising a network node, comprising: Processing circuit; and a memory coupled to the processing circuit and having instructions stored therein, the instructions being executable by the processing circuit to cause the communication device to: receiving an indication of a threshold number of symbols from the network node such that when the communications device sends a UCI message indicating that one or more physical PUSCH transmission opportunities configured by the network node are not to be used by the communications device, the UCI should be sent at least the threshold number of symbols before the one or more PUSCH transmission opportunities that are not to be used; and A UCI message is sent at least the threshold number of symbols before one or more PUSCH transmission opportunities that are not to be used, the UCI message indicating the one or more PUSCH transmission opportunities that are not to be used.

15. The communication device according to claim 14, wherein: According to the instructions stored in the memory, the processing circuit further causes the communication device to perform the method according to any one of claims 10 to 13.

Images