EP4623621A1

EP4623621A1 - Autonomous transmissions over shared resources

Info

Publication number: EP4623621A1
Application number: EP22818831.4A
Authority: EP
Inventors: Bikramjit Singh; Jonas Pettersson; Massimo CONDOLUCI
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2022-11-22
Filing date: 2022-11-22
Publication date: 2025-10-01
Also published as: CN120570030A; WO2024110017A1

Abstract

Methods performed by a wireless device and a network node and corresponding apparatus are provided. The methods and apparatus are provided for managing uplink transmissions using a common resource pool. In some embodiments a method (1300) for performing uplink transmission comprises transmitting (1310) a first transmission using dedicated resources according to a first scheduled data allocation. When further data is required to be transmitted which exceeds the first scheduled data allocation, the method comprises transmitting (1350) a second transmission comprising at least a part of the further data being using a common resource pool preconfigured for a plurality of wireless devices wherein the second uplink transmission is identified by a control sequence.

Description

AUTONOMOUS TRANSMISSIONS OVER SHARED RESOURCES

TECHNICAL FIELD

Embodiments herein relate generally to a network node and a method in the network node, and to a wireless device and a method in the wireless device. More particularly the embodiments herein relate to radio communications, and in particular, to autonomous transmissions using shared common resources.

BACKGROUND

For many services the uplink scheduling delay is of importance. In systems where the base-station schedules the uplink (like LTE and NR) a big part of the problem is that the node that allocates the medium does not know whether the terminals have data or not and not how much.

When transmitting delay sensitive data, such as a frame of video or XR content it is important to be able to transfer the entire frame within the delay budget. These frames often vary in size and if the resources scheduled by the base station is insufficient for the current frame, it will cost additional time before the base station is made aware of this and can schedule additional resources.

The default mechanism in LTE and NR, as described for example in 3^rd Generation Partnership Project (3GPP) Technical Specification (TS) 38.321 V17.2.0 is that a terminal first sends a Scheduling Request (SR). The Scheduling Request (SR) is used for requesting UL-SCH resources for new transmission. When the base station receives an SR, it knows that the terminal has data to send but not how much. A grant indicating the resources to use and the number of bits to transmit is sent to the terminal. If the number of bits scheduled ae not sufficient to empty the buffer, the UL transmission includes a buffer status report (BSR) which indicates how much more data that it has in its send buffer. The base station then issues another grant to empty the buffer. Another mechanism is to use persistent or semi-persistent scheduling (also known as configured grants), which consists of periodic fixed size allocations. If the number of bits is too small to empty the buffer, a BSR can be included and an ordinary grant for the excess data can be transmitted from the base station.

There are also mechanisms based on contention such as slotted ALOHA This kind of mechanisms gives more control to the terminal and hence makes it possible to schedule transmissions without waiting for the base station to gain knowledge about the buffer sizes. The terminals can transmit directly (or after a backoff timer expires) and if transmissions collide and therefore cannot be received by the base station this is handled by retransmissions. When considering a contention-based approach, a way to see it from a mobile network point of view is that a set of common resources can be used by several UEs (a group or all UEs of a certain cell) and consequently there could be cases where multiple UEs are transmitting over the same time/frequency resource.

For exchanging information between UE and base station, a cellular system such as 3GPP, e.g. New Radio (NR), also referred to as 5G, uses Uplink control information (UCI) messages. UCIs can be used for scheduling purpose (e.g., carrying an SR) as well as for exchanging information about ongoing transmissions (e.g., carrying a hybrid automatic repeat request acknowledgment (HARQ-ACK), or for other information such as channel state information (CSI). These UCIs are encoded and transmitted through the physical uplink control channel (PUCCH) or are multiplexed on a physical uplink shared channel (PUSCH).

3GPP (e.g. as part of NR standardisation) has already standardised various kinds of UCI for following purposes: ^Transmitting HARQ-ACK in UL for DL transmission; ii) Sending CSI report; iii) Sending SR. In addition, in NR-unlicensed (NR-U), an additional UCI is supported in the form of a configured grant (CG) UCI (CG-UCI), which helps to indicate some parameters related autonomous CG PUSCH transmission for CG in 3GPP Release 16 and NR-U/NR-U CG. For example when radio resource control (RRC) parameter cgRetransmissionTimer is enabled. The CG-UCI can indicate following parameters: HARQ ID, RV, NDI, COT sharing information, CRC. CG-UCI is included in every CG-PUSCH transmission (for unlicensed spectrum 6-7 GHz, provided cgRetransmissionTimer is enabled) and includes the information listed in above point; CG-UCI is mapped as per 3GPP Release 15 rules with CG-UCI having the highest priority. It is mapped on the symbols starting after first DMRS symbol. To determine the number of REs used for CG-UCI, the mechanism of beta-offset in Release 15 NR for HARQ-ACK on CG-PUSCH is reused. Nonetheless, a new RRC configured beta-offset for CG-UCI is defined

The UCI is sent over PUCCH channel which can be multiplexed with PUSCH depending on the rules. The specific details of user equipment (UE) procedures for reporting control information are further described in Section 9 of 3GPP TS 38.213 V17.3.0.

SUMMARY

One or more of the disclosed embodiments provide at least the advantage of minimising the delay in transmitting unsent (underestimated) data when a previously allocated transmission is insufficient. Solutions advantageously provide minimal additional signaling between the wireless device and the base station. In some examples a further advantage is provided that exclusive reservation of resources is avoided.

Further advantages are that a scheduler in the base-station can control the access to a common pool and enforce priorities between different users. This can minimise the risk for collisions when using a common pool of resources and thereby minimise delays and resource usage as a result.

The need for blind decoding in the common pool can be avoided or at least optimized (compared with traditional contention) because the base station knows which UE(s) intend to transmit, which modulation and coding scheme to be used.

One or more embodiments provides the advantage of removing the reliance on a specific control channel to request additional resources for unsent data, once a shared data channel is assigned for the transmission. In some examples a further advantage in addition to saving of specific UL control channel resources, such as PUCCH, is provided through simplifying multiplexing rules. For example where a CP-UCI is directly transmitted over PUSCH, for example in certain resource elements which are excluded from the PUSCH REs. Avoiding complex multiplexing and prioritization rules enables simplified implementation and energy savings.

In some examples the reliance on blind decoding can be reduced or optimized, for example a first UCI over PUCCH can indicate some information related to contention-based PUSCH. Based on this initial UCI a gNB can deterministically identify a subsequent PUSCH. The remaining parameters of the PUSCH can be retrieved from a second-stage UCI in the PUSCH for the PUSCH decoding. In some examples another advantage is that a “request to use common resources” is enhanced with additional information, e.g., HARQ process, logical channel priority, which allows the base station to gather more information to be used when choosing (e.g., prioritizing) which UE should use the common resources (where multiple UEs are attempting to access the common resources simultaneously).

In a first aspect a method performed by a wireless device for performing uplink transmission is provided. The method comprising transmitting a first transmission using dedicated resources according to a first scheduled data allocation, wherein further data is required to be transmitted which exceeds the first scheduled data allocation, and transmitting a second transmission comprising at least a part of the further data transmitted using a common resource pool preconfigured for a plurality of wireless devices, wherein the second uplink transmission is identified by a control sequence.

In a second aspect a method performed by a network node for receiving uplink transmissions from a wireless device is provided. The method comprising receiving a first transmission using dedicated resources according to a first scheduled data allocation, and receiving a second uplink transmission using a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation. In a third aspect a wireless device for performing uplink transmissions is provided. The wireless device is configured to perform a first transmission using dedicated resources according to a first scheduled data allocation, wherein further data is required to be transmitted which exceeds the first scheduled data allocation, and perform a second transmission comprising at least a part of the further data transmitted using a common resource pool preconfigured for a plurality of wireless devices wherein the second uplink transmission is identified by a control sequence.

In an alternative to the above third aspect the wireless device comprises processing circuitry, memory, and communication interface circuitry comprising a transmitter and receiver, and the processing circuitry being operative to obtain instructions from the memory and cause the transmitter to perform a first transmission using dedicated resources according to a first scheduled data allocation, wherein further data is required to be transmitted which exceeds the first scheduled data allocation, and perform a second transmission comprising at least a part of the further data transmitted using a common resource pool preconfigured for a plurality of wireless devices wherein the second uplink transmission is identified by a control sequence.

In a fourth aspect a network node for receiving uplink transmissions is provided. The network node is configured to receive a first transmission using dedicated resources according to a first scheduled data allocation, and receive a second uplink transmission using a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation.

In an alternative to the fourth aspect, the network node comprises processing circuitry, memory, and the processing circuitry comprising transceiver circuitry, the processing circuitry being operative to obtain instructions from the memory and cause the transceiver circuitry to receive a first transmission using dedicated resources according to a first scheduled data allocation, and receive a second uplink transmission using a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation.

In a fifth aspect, a computer program or memory or carrier comprising a computer program is provided. The computer program includes instructions which when executed on a processor of a wireless device, cause the wireless device to perform any of the methods described for a wireless device and when executed on a processor of a network node cause the network node to perform any of the methods described for a network node.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a block diagram illustrating an example according to embodiments of the present disclosure.

Figure 2 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 3 is a block diagram illustrating another example according to embodiments of the present disclosure.

Figure 4 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 5 is a flow diagram illustrating an exemplary method implemented by a device according to embodiments of the present disclosure.

Figure 6 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 7 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 8 is a block diagram illustrating a further example according to embodiments of the present disclosure. Figure 9 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 10 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 11 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 12 is a block diagram illustrating a further example according to embodiments of the present disclosure.

Figure 13 is a flow diagram illustrating a method according to embodiments of the present disclosure.

Figure 14 is a flow diagram illustrating a method according to embodiments of the present disclosure.

Figure 15 is a block diagram illustrating a network environment according to embodiments of the present disclosure.

Figure 16 is a block diagram illustrating a user equipment device according to embodiments of the present disclosure.

Figure 17 is a block diagram illustrating a network node according to embodiments of the present disclosure.

Figure 18 is a block diagram illustrating a host server according to embodiments of the present disclosure.

Figure 19 is a block diagram illustrating a virtualization environment according to embodiments of the present disclosure.

Figure 20 is a block diagram illustrating a service environment according to embodiments of the present disclosure.

DETAILED DESCRIPTION

In the case of grant-based uplink scheduling, there will be extra latency every time the number of granted bits is insufficient to empty the buffer. This is true regardless of whether an ordinary dynamic scheduling is used or if there is a periodic configured grant. The base station must first be made aware of that more data is present ( e.g. via a BSR). Then a new resource must be scheduled, and a grant transmitted from the base station. It is further difficult for the wireless terminal to prepare the transmission until the grant has been received and decoded, which adds even more delay in the form of a delay between the time when the grant is received until the transmission occurs. During the time the wireless terminal is waiting for the grant after the BSR transmission, new data might reach the buffer of the wireless terminal, which means that a new SR/BSR should be sent to get a new grant.

To avoid additional delay for certain applications such as bounded latency traffic for example video/XR or non-deterministic URLLC and using a periodic configured grant. The size of the grant must be at least as large as the largest possible frame, with a period matching average packet arrival. With such urgent transmissions, the size of the periodic occasion may be set as large as the largest possible frame size or, e.g., 80^th percentile of maximum size. This is in practice not feasible. Partly because the frame size is not readily known and partly because the cost in terms of radio resources would be too great as the frame sizes are random - either the resource remains unused or the allocation is less (in that case, resource is not wasted). The largest possible frame size is often many times larger than the average size. And, for other applications or services without the frame concept, e.g., legacy web browsing, it is not even possible to set the grant as large as the largest object or similar.

The base station does not know that the terminal has additional data with respect to the last received BSR. In particular, schemes for static prioritization between users or groups of users, such as described in 3GPP technical report (TR) 38.824 V16.0.0, are not available. Since the base station does not know that a user has data since it has not been reported, the base station cannot prioritize it.

A preconfigured grant format could be defined which could reduce “the delay between the grant is received until the transmission occurs”, but all the other problems will remain. A contention-based uplink can be an alternative which allows transmission of all data without waiting for scheduling, where multiple users may have rights to utilize the resource as per policies defined by the network. If transmissions are random, contentionbased procedures help to improve spectral efficiency. However, one of the side effects is that it will increase the blind decoding cost, as the base station does not know which user and on what resource, a user is transmitting. Depending on the design, the base station may not even know the information related to the transmission decoding, e.g., modulation and coding scheme, FDRA/TDRA, and this will further increase the blind decoding cost.

Focusing on blind decoding issue, the UE may utilize PUCCH resource to indicate related information to ease PUSCH decoding, just like CG-UCI to indicate parameters, e.g., HARQ ID as an example for NR-U CG. However, if there is an inherent issue of decoding for contention-based transmission, then configuring separately both channels PUCCH and PUSCH is not desirable where both are indispensable to decoding data transmissions all the time.

A contention-based uplink allows transmission of all data without waiting for scheduling, where multiple users may have rights to utilize the resource as per policies defined by the network. If transmissions are random, contention-based procedures help to improve spectral efficiency. However, one of the side effects is that it will increase the blind decoding cost, as the base station does not know which user and on what resource, a user is transmitting. Depending on the design, the base station may not even know the information related to the transmission decoding, e.g., modulation and coding scheme, FDRA/TDRA, and this will further increase the blind decoding cost.

Focusing on blind decoding issue, the UE may utilize PUCCH resource to indicate related information to ease PUSCH decoding, just like CG-UCI to indicate parameters, e.g., HARQ ID as an example for NR-U CG. However, if there is an inherent issue of decoding for contention-based transmission, then configuring separately both channels PUCCH and PUSCH is not desirable where both are indispensable to decoding data transmissions all the time. In addition, collisions and perhaps additional backoff result in extra latency and jitter. The collisions also lead to inefficient use of the resources: below 37% in the case of slotted ALOHA, for example. The base station further has little control over the resources, and it is difficult to prioritize between different users or different types of data.

The mechanism in WiFi called RTS/CTS (Request-To-Send/Clear-to-send) reduces the “hidden node problem”. The RTS is an ordinary contention-based transmission which may collide with other transmissions. The CTS repeats the network allocation information in the RTS so that hidden nodes will know that a transmission is ongoing even if they did not receive the RTS.

Various embodiments disclosed herein assume that a common resource pool is configured which allows a plurality of wireless devices or user equipment (UE) to transmit. A common resource pool is typically contention based due to the fact that the resources are shared between more than one wireless device and each wireless device does not have dedicated use of the resources via current scheduling means. This does not preclude the application of mechanisms to minimize or mitigate the effects of contention when using the common resources.

In one example, a groupcast or multicast DCI or DCI format 2_0 or broadcast Radio Resource Control (RRC) signaling is used to allocate the common/shared resource for UL transmissions for multiple UEs. The information regarding the common resource can bandwidth (BW) information, bandwidth part(s) (BWP(s)), carrier ID(s), cell ID(s), PRBs, etc. over where the pool is located/formed.

In one example, a new Radio Network Temporary Identifier (RNTI) (which can be called e.g., a Group Common RNTI (GC-RNTI) or a Shared Pool RNTI (SP-RNTI)) can be defined, which is scrambled with Cyclic Redundancy Check (CRC) of DCI (group common format), e.g., format 2_0 (or equivalent format in 6G) indicating common or shared pool allocation for UL transmissions.

In one example, the PRBs and (mini-)slots of the shared pool (or size of the shared pool in time and frequency domain, pattern (gaps, repetitions, etc.)), the BWP, UL/SUL indicator associated with the pool can be indicated using: a. Group-common DCI, e.g., Format 2_0, b. Unicast DCI, e.g., one can utilize TDRA, FDRA fields or other fields such as BWP/UL/SUL indicator in format 0_0, 0_1 , 0_2, 0_X, c. RRC signaling (unicast or broadcast), d. Medium Access Control (MAC) Control Element(s) (CE(s)), e. System Information Block (SIB) based indication, f. Master Information Block (MIB) based indication, or g. a combination of any two or more of a-f.

In another example, the allocation of a shared pool is indicated through a combination of the methods where multiple configurations of PRBs etc. are indicated statically through, e.g., RRC, SIB, or similar mechanism while which of the common pool configurations that is active in a given (mini)slot is indicated by dynamic signaling, e.g., a group-common DCI.

In one example, the DCI or RRC messaging broadcasted for shared pool allocation can include information related to load, e.g., a. UE IDs allowed b. User group ID permitted in the pool, where a user group is set of UE IDs which is represented by a group ID

The specific details of how these common resources are defined and configured are non-limiting on the present disclosure which assumes that such common resources as referred to herein are available and the ways and means to configure such resources are understood by the skilled reader. When referring to the use of said common resources the skilled reader will furthermore understand that the embodiments (unless explicitly stated) are not limited to the application of common resources. The use of a common resource pool provides flexibility and efficiency and thus has some advantages of its own but should not be understood as essential for the embodiments disclosed.

In some embodiments a request to use a common resource pool within a previously decided/scheduled transmission is included. With such a mechanism it is possible to handle situations when there is more data than can fit into the current allocation while adding minimal delay. In some examples a pool request, PR, is added as a separately decodable control information to allow fast decoding.

When the base station receives the pool request, it can respond with a downlink control signal that indicates whether the terminal can use the requested resources in the common pool or not. This can be a permission to use the requested resource (single bit), or the omission of such a bit corresponding to sending a denial to use the requested resource. In some examples the response further includes information that specifies which resource in the common pools should be used.

In some examples the relation between the resource that the pool request is transmitted in and the resource in the common pool is configured through prior signaling, thus enabling a single information bit in the pool request.

Upon getting permission to use the common resource pool, the excess data may be transmitted using resources in the common pool without the need to send a scheduling request (SR)/BSR and then waiting for an ordinary grant. In some examples a separately encoded request to use a common resource pool is included in a previously decided/scheduled/configured uplink transmission.

The base station may decode the pool request and respond with an indication whether the request is allowed or not. If the request is permitted, the terminal may send additional data in a transmission using resources in the common resource pool.

The pool request differs from a “scheduling request” (SR), which is an indication from a wireless device that a terminal that did not have anything to transmit now wants to transmit. The proposed pool request differs in that the base station already knows that there is data to transmit, but not how much, so the UE is not requesting a new data transmission in accordance with a scheduling request. The proposed pool request also differs from a ’’buffer status report”, as currently defined, which is decoded together with the data and only informs the base-station how much data that remains to transmit; the proposed pool request specifically allocates at least a part of the unsent data to additional resources. Likewise, the proposed pool request differs from an RTS in Wi-Fi specifications, which is a contentionbased transmission that may collide with other transmissions just as any other transmission.

In some embodiments a UCI, may be multiplexed together with a data transmission, is used from the UE to inform the base station about its intention to perform a subsequent transmission over a certain set of common/shared resources/pool. In some examples the UCI is a small-size UCI (implicitly referring to a certain common resource). In other examples the UCI contains more information e.g., HARQ process of the transmission.

After the transmission of the aforementioned UCI, the UE may continue with the transmission over the common resources unless instructed differently from the base station.

In some examples the common resources are configured through prior signaling, thus enabling a small-size UCI. In some examples further information is included in the UCI.

In some examples an uplink control message (e.g., UCI) is generated by a UE to inform the base station about its intention to use a certain set of common resources. The base station then decodes the uplink control message to get information about the intention of the UE for transmitting over the target common resources. If multiple UEs provide such signalling the base station becomes aware of which UEs intend to transmit over the common resources.

If the requested transmission is allowed, the UE sends additional data in a transmission using the common resources to which the uplink control message was referring. In some examples the particular set of resources is indicated in a downlink control message. The information in the UCI can be used by the base station receiver to decode the transmission over the common resources.

The UL data or PUSCH TB transmission over a common/shared resource pool is not deterministic transmission, and thus in certain embodiments a UCI (which is, based on a standardised procedure) is sent via a PUCCH channel (which can be additionally or alternatively multiplexed with PUSCH depending on the rules) along with PUSCH to supply necessary parameters or reduce blind decoding for the given PUSCH or other associated PUSCH transmissions

In some examples the UCI may be transmitted over PUSCH, (for brevity, this will be referred to as a common pool-UCI or CP-UCI) without the PUCCH (being multiplexed). This means that no PUCCH is allocated or utilized or needed to transmit CP-UCI. Thus, a UE utilizes only the PUSCH to transmit CP-UCI. We can also call this PUSCH as CP-PUSCH, where CP-PUSCH carries both data and CP-UCI (directly over CP-PUSCH). Note, other UCI types (e.g., CSI, HARQ-ACK codebooks) which require PUCCH can be multiplexed with PUSCH if the PUSCH overlaps with PUCCH in a conventional manner

In some examples a two-step control information transmission is performed. A UE has the possibility to utilize PUCCH to indicate some control information related CP-PUSCH. The remining control information (i.e., CP-UCI) may be included in CP-PUSCH itself. To decode CP-PUSCH, the decoding of both control information is necessary (i.e., in PUCCH and CP-PUSCH). For a given common resource pool (group-common or contention or shared resource pool) allocated for group of UEs for their UL data transmissions (physical shared channels or PUSCHs), the UL control signaling (e.g., UCI) that helps in decoding PUSCH is sent over the data channel (physical shared channel) without multiplexing with control channel (i.e. physical control channel or PUCCH).

Certain embodiments will be described in more detail and were appropriate in conjunction with the appended figures.

Figure 1 depicts a communication system 100 according to some embodiments. The communication system 100 may comprise many additional entities not depicted but comprises at least a radio base station 110, e.g. a 3GPP LTE eNB or NR gNB, and a plurality of wireless devices 180. In some examples the base station 110 is configured to receive a scheduling request 120 from a wireless device (e.g. 180a). In response, the base station provides a grant 130, for example in a downlink control information (DCI) and in response to the grant 130 the wireless device (e.g. 180a in Figure 1) performs an uplink transmission. In another example, a wireless device (e.g. 180b in Figure 1) which has previously received a grant and performed an uplink transmission (in a similar manner as 180a in Figure 1) has more data to send. Instead of requesting a further scheduling request, the wireless device 180b sends a ‘transmission request’ 150, also referred to herein as a ‘pool request’, to request use of further resources, e.g. common pool resources. The base station 110 accepts the request with a ‘permit’ indication 160 and as a result the wireless device 180b can transmit further uplink data 170.

In accordance with the flowchart depicted in Figure 2, a transmission from a terminal is initially agreed (for example dynamic, pre-scheduled, or pre-configured) and the maximum number of bits and which resources to use is decided. The terminal determines at step 210 whether it has more data than it is possible to fit into the given resources (and, in general, any rules to send a pool request are satisfied) and if not the procedure ends at step 220. If more data to send, the terminal includes a request at step 230 to use resources in a common pool that are available to many terminals. The request may be separately encoded so that it can be decoded by the base station without having to decode the entire transmission. It can for example be done by using two versions of DMRS where one indicates pool request. Another option is stealing L1 bits from the encoded data block and inserting a special signature instead. The common pool resources and what modulation and coding scheme(s) to use and possibly rules that drive the usage of the common pool are assumed to have previously been signaled to the terminal, either by means of system information, common downlink control information or by individual downlink control information to each terminal - or a combination thereof. This is very similar to other allocations of resources in medium access control, for example configured grants: A future resource is indicated, perhaps repeated with a period (which may be every slot). The only difference is that all or a subset of the users (wireless devices or terminals) connected to the base station are allocated the same resources (so broadcast/multicast may be used to allocate such common resources). These resources may have the additional condition that a pool request must be transmitted (and allowed) before using it. There may also be other preconfigured rules that must be fulfilled, such as that there is overshoot data not known by the base station (see below).

If the base station receives multiple requests that are mapped to the same shared pool resources, it can select which of the requests that should be allowed and deny the remaining ones. The user’s identity is known and the scheduler can therefore determine the importance of each request just as in ordinary scheduling based on QoS-configurations (such as priority and latency bounds), earlier events (which users that have been allowed to use the common pool, ...). It is also possible for the base station to allow multiple users to transmit based on estimates whether it will be able to resolve all of them in the receiver. In this case also spatial information regarding the radio channel can be included in the decision.

Since the parameters of the transmission are determined beforehand, the terminal can prepare this additional transmission while waiting for a permission (e.g. a ‘permit’ response) to use the common resource. Either using a fixed modulation and coding scheme or one of multiple alternatives. The latter option may require blind decoding at the base station.

The terminal listens for a permission-signal to use the requested resources, in accordance with the flowchart in Figure 2, the terminal decodes the response from the base station at step 240 and determines at step 250 whether the response gives the terminal permission to transmit or not. When the permission is received, the wireless device goes ahead and transmits 270 using the common resources. Alternatively, a negative signaling could be used where the wireless device goes ahead with the transmission at step 270 unless it received a signal that denies or blocks it from using the common resources within a given time. At step 260 the terminal may perform another procedure such as implementing a delay and performing another pool request after s certain time or sending a new UL scheduling request. Such procedures may be left to the implementation of the terminal or influenced by certain indications within the negative response.

Figures 3, 4 and 5 depict the resource allocations over time. Whilst the vertical access depicts frequency aspect of the resources, there is no specific meaning intended from the relative proportions of the allocations.

Figure 3 demonstrates a pool request 300 comprising a time/frequency resource within previously granted resources 310. The pool request 310 may identify requested resources within a common resource pool 330. In response to the pool request the wireless device may receive downlink control information, e.g. DCI, in resource 320. As described previously this may indicate explicitly that the pool request is permitted. In other examples this may indicate that the pool request is denied. Additional information may also be received in the downlink control information such as particular pool resource information or indication whether a backoff should be performed when the request is denied.

In Figure 4 an alternative resource allocation is depicted, where a pool request 400 comprising a time/frequency resource within previously granted resources 410. The pool request 400 may identify requested resources within a common resource pool 430. In response to the pool request the wireless device may receive downlink control information, e.g. DCI, in resource 420. In this example the request 400 maps to more than one alternative resource. The downlink control information/request response 420 may then comprise or include a permit and additionally indicates which alternative resource to use from the resources 430. This requires that the configuration of the common pool resources as described in the previous example contains multiple alternatives. For example, a large common pool of resources could be divided into K separate allocations. The permit response 420 would then be ceil(log2(K)) bits. A-priori rules related to the pool request can be introduced to control pool request transmissions of a terminal. This is to avoid that, e.g., common pool resources are overused or underused. These rules may be associated to the common pool resource configuration (i.e., common pool-specific rules). In other examples these rules may be associated to a certain scheduled transmission for example included in the grant of a granted transmission 310, 410 (i.e., UE-specific rules saying whether the received grant allows to complement the transmission with a pool request). Examples of such rules are for associating a pool request to a grant; for determining how to send the request in dependence of the unsent data and associating the pool request 400 with certain pool resources. For example, the rule may indicate that the pool request is associated to a transmission scheduled via dynamic scheduling but not to a transmission scheduled via configured grant. In another example the rule indicates that pool request may be sent together with the transmission scheduled via a configured grant only if the periodicity of the resources scheduled with configured grant is larger than a certain threshold. In some examples the rule indicates that pool request may be sent together with the transmission scheduled via a configured grant only if the time until the next occurrence is larger than a threshold.

In some examples the rule indicates that the pool request may be sent only if the terminal has more than X bits that didn’t fit the first transmission. In other examples the rule depends on the terminal having less than X bits. In some examples an a-priori configuration of the pool is provided (e.g., resource in time, frequency, or spatial domain, pool ID, etc.) to the UE. In addition the configuration may include information related to associated signaling, such as pool request.

In Figure 5 an alternative resource allocation is depicted, where a pool request 500 comprising a time/frequency resource within previously granted resources 510. The pool request 500 may identify requested resources within a common resource pool 540. In response to the pool request the wireless device may receive downlink control information, e.g. DCI, in resource 520.

In this example the transmission in the common pool 540 could contain a pool request 530 to use another common pool 560. This may require a separate mapping from the request 530 to the allocation in the common pool 560. In addition a second downlink control information 550 (permit) may be required to permit the use of the second common resource 560. In some examples the second pool request may be for the same common pool 530 as the first request 500. In other examples the first common pool resources 530 are permitted by the downlink control information 550 in response to a request for the second resources 560. In other examples the second request 530 is for the same resources as the first request and the permit is for the second resources.

In some examples, the downlink control information (permit) 320, 420, 520 indicates a specific Pool ID. In some examples the “permit” does not indicate specific pool resources, rather UE can autonomously select a resource in pool for its UL transmission. In some examples, the “permit” has a time to live period, meaning that the response is valid for a certain time or time window. In some examples when a UE has one or more transmission needs within the time window, it may transmit in the pool without any subsequent pool requests.

In some examples, the terminal sends a pool request, it starts a timer which covers different time-occasions of the common pool. In some examples the value of this timer is signaled together with the configuration of the common pool. In other examples the timer is defined as part of configuration I rules associate to the pool request, or pre-defined. The terminal then waits for the reception of the permission-signal within such time period (i.e. when the timer is active. In this case, it is assumed that permission-signal is a confirmation that the common pool resources can be used. When the permission-signal is received then the terminal can send its data over the next upcoming time-occasion of the common pool. In the case that several terminals send a pool-request within a close (i.e., several pool requests are received before the occasion of the common pool resources), the timer gives the possibility to the base station to separate over time different transmissions over the common pool resources without the need of (i) terminals sending additional pool requests and (ii) the base station to allocate separate grants.

In Figure 6 a UE has scheduled dedicated resources for an uplink transmission 600. The scheduling may be dynamic, pre-scheduled, or pre-configured, or configured grant). The UE determines it has unsent data which exceeds the previous scheduled uplink transmission resource allocation. The UE prepares and adds a UCI or a flag 610 to inform the bases station that it needs to use common resources (already configured). In some examples the UCI also indicates to the base station its need to use a certain sub-set of common resources. In other examples the base station triggers a message I signalling towards the UE which transmitted the UCI to allow/revoke the transmission over the common resource 620 (as depicted in previous figures). In some example the base station may transmit (broadcast or multicast) towards the UEs associated to the common resource pool 620 to indicate which UE is allowed to transmit over the common resource pool.

In this example the UCI 610 is multiplexed with the scheduled data transmission 600 to inform the base station about its needs to use a certain set of common resources 620. The base station uses information provided in the UCI to decode the subsequent uplink transmission 630. In some examples, as depicted in Figure 6, the information contained in the UCI points to the transmissions over common resource to decode this transmission (reducing the need for blind decoding).

In some examples the UE includes this UCI because of several reasons, e.g., the UE has more data to be transmitted which didn’t fit within the current transmission, the UE is aware or expects to receive more data in the buffer by the time the common resource is going to be used, etc. The UCI, in addition to an indication about which common resources the UE is intended to use, may contain information such as HARQ process of the transmission intended to be transmitted over the common resources. The UCI may indicate HARQ ID x, y, z, 3 HARQ processes over common resource, wherein each HARQ process may be accompanied with repetitions, which can be derived from TDRA/FDRA tables either RRC configured or indicated in UCI, or combination of both. In some examples the priority of the UL transmissions intended to be transmitted over the common resources. The priority may, for example, be dependent on UE ID, or type of traffic. In some examples the priority is the same as DMRS. In other examples a new sequence is inserted in the PUSCH or UCI to indicate specific priority. In some examples a transmission pattern of HARQ processes (including repetitions) over shared resource is included. The transmission pattern may be dependent on UE ID, then it is not required to indicate explicitly in UCI. In some examples the UE ID comprises a DMRS sequence in scheduled PUSCH in which UCI is included. In some examples the transmissions parameters related to transmissions over common resource are agreed a-priori. The UCI inclusion may be disabled, i.e., no UCI is included, and if transmissions are present over common resource, then gNB either does blind decoding or may have a-priori knowledge of where the transmissions could be. For example the gNB knows the UE ID from scheduled PUSCH, and then gNB tries to decode successive transmissions over common resource based on a-priori parameters TDRA, FDRA, MCS, repetitions, etc. In some examples the UCI indicates optional information for transmissions. For example a 1 -bit UCI indicates whether transmissions are present over common resource or not and a Multi-bit UCI providing information pointing to the transmissions over the shared resources. In some examples this is not agreed a-priori and the UCI indicates necessary and plus optional information for transmissions. For example the UCI indicates which MCS or additional parameters used to encode transmissions.

In Figure 7, a UE uses UCI 720 multiplexed with a data transmission 710 over a common resource of a plurality of common resources 720 to inform the base station about its needs to use a certain set of common resources for a subsequent transmission 730, consequently UE X can use such common resources (unless instructed otherwise from the base station). In this example, the UE is performing a transmission by using a set of common resources. This may be a subsequent transmission as described in Figure 6 or it may be an initial transmission using contention based resources. The transmission 710 includes a UCI 720 in the data transmission over the common resources 700 to indicate to the base station about its need to use (or to continue using in this case) a certain set of common resources. In advance of the transmission the UE prepares the UCI 720 when it determines it has (or expects to have) more data to transmit and transmits this UCI 720 together with its data transmission 710. The UE may perform the data transmission plus the UCI transmission over PUSCH in common/shared pool. In another example the UCI (over PUCCH) is not be multiplexed with PUSCH if the UCI resources and the PUSCH resources are mutually exclusive (non-overlapping). The UE transmits the data over PUSCH(s) in the shared resource pool, where data is encoded according to the information indicated by the UCI. In some examples he UCI is included (multiplexed with) in the PUSCH belonging to non-pool resource, e.g., CG or dynamic PUSCH using legacy methods. In other examples the UCI is included (multiplexed with) in the PUSCH belonging to pool resource, where the PUSCH containing UCI and the PUSCH to be encoded based on UCI’s indicated information are separate. In other examples the PUSCH containing UCI and the PUSCH to be encoded based on UCI’s indicated information are the same.

In some examples the base station uses the UCI information previously received from the UE to decode the data received from the UE over the shared resource pool. This assists the base station to reduce blind-decoding as the UCI information indicates for example, the MCS of the transmission, resource indication, TBS size, etc. In some examples the UCI indicates the PUSCH resource to be decoded over the shared pool. The provides the advantage that the base station does not need to try to decode the PUSCH blindly with various permutations and combinations of resources in the pool and thus avoids increased the blind-decodes which would cause an increase in energy consumption and processing time.

In one or more of the embodiments described above, the UE has information about the configuration of set of common resources (which resources, modulation and coding scheme(s), rules that drive the usage of common resources, etc. In one or more of the embodiments described above the resource for shared/common allocation is one of licensed, unlicensed, TDD, FDD spectrum or any combination thereof. The term UCI is used to indicate uplink control message/information. In certain embodiments the UCI may comprise one or more of: an UL flag; a MAC CE; an UL sequence; a PUCCH; an UL header; multiplexed UCI which is part of PUSCH/data.

The terms shared pool, common pool, contention pool etc. may be used interchangeably. In certain embodiments the UCI may comprise a UCI transmission type which specifies where UCI is transmitted. In one option the UCI is included in PUSCH where the PUSCH is scheduled over dedicated resource (dynamic or CG based). In another option, UCI is included in PUSCH where the PUSCH is a part of common or shared or contention-based allocation. In a further option, UCI is sent over PUCCH without multiplexing with PUSCH where PUCCH and PUSCH can be transmitted separately over, e.g., time or frequency or spatial or combination of domains.

In certain embodiments the content of UCI comprises parameters applied to PUSCH or data transmissions transmitted over shared/common resource. In one or more examples the parameters comprise one or more of:

Repetition pattern in the shared resource;

HARQ IDs in the shared resource;

MCS of the indicated transmissions;

RV pattern;

Priority;

Channel sensing information, e.g., what LBT class is applied;

- CRC;

- TDRA indication of transmissions;

FDRA indications of transmissions;

UL power control;

K repetitions per HARQ process;

Shared/common pool/resource ID/type;

- BSR;

Pointer to PUSCH in shared pool;

- TBS size;

- NDI;

COT sharing information - UE-initiated COT or gNB-initiated COT and the respective COT ID;

Repetition behaviour; slot-based, mini-slot based, PUSCH type A/B repetition (back-to-back or otherwise);

PUSCH mapping type; and

RB set information (wideband mode 2 in NR-U);

It will be understood by the skilled reader that combinations of parameters and UCI transmission types are feasible and intended without explicitly disclosing each and every combination.

As described above a UCI may be included in the PUSCH that belongs to the nonpool or pool resource or PUCCH. Further, the UCI can indicate information to gNB for decoding of PUSCH where these PUSCHs/transmissions/TBs can be separate PUSCHs or same PUSCH (containing UCI) or both. Different TBs or HARQ processes may be indicated. A CG-PUSCH (over non-pool resource with HARQ ID#X) may include a UCI where the UCI indicates TDRA/FDRA and HARQ ID (say #Y) information of the PUSCH transmitted in shared pool. A PUSCH (transmitted over shared pool with HARQ ID#X) may include a UCI where UCI indicates the carrier ID of the next PUSCH (HARQ ID#Y) transmitted in shared pool. A PUSCH (transmitted over shared pool with TB/HARQ ID#X) may include a UCI where UCI indicates the RV and NDI information (for the same PUSCH, HARQ ID#X) and the MCS information of next PUSCH (say HARQ ID#Y) transmitted in shared pool. A PUSCH (transmitted over shared pool with it may include a UCI indicating its HARQ ID, RV, TDRA, FDRA. Different repetitions of the same TB/HARQ process may be indicated. A dynamic PUSCH (over non-pool resource with HARQ ID#X, repetition R1) may include a UCI where UCI indicates TDRA/FDRA information of the PUSCH repetition R2 (same TB/HARQ process ID#X) transmitted in shared pool. A PUSCH (transmitted over shared pool with HARQ ID#X repetition) may include a UCI where UCI indicates the RV of the following/next/consecutive PUSCH repetition(s) which are part of the same TB/HARQ ID#X transmitted over the shared pool. A PUSCH repetition R1 (transmitted over shared pool belonging to TB/HARQ ID#X) may include a UCI where UCI indicates its RV (for the same repetition R1) and RV of the following/next/consecutive PUSCH repetition(s) (say repetition R2 and R3) which are part of the same TB/HARQ ID#X transmitted over the shared pool. A PUSCH with 2 repetitions belong to a TB/HARQ process transmitted over shared pool where each repetition may include a UCI indicating its RV and NDI information (for each repetition for itself, i.e., no cross-indication). A UCI may be included in some PUSCH transmission (say HARQ ID X) which indicates the information related to say repetitions of TB/HARQ ID X and also information related to PUSCH TB/HARQ ID Y.

In some embodiments the UCI comprises the parameters relevant for PUSCH decoding in the shared pool or blind decoding reduction. In some examples UCI can mean all kinds of UCIs (which can also be not related to shared pool scheduling method), however in the IvD we use terminology UCI (or CP-UCI sometimes) to indicate primarily for shared pool allocation. In some examples the same UCI is used to indicate control information that is not meant specifically for shared pool allocation, e.g., UCI based on HARQ-ACK, CSI, SR, etc.

In some exmples the UCI or Common Pool-UCI (CP-UCI) is sent to indicate parameters for transmission in shared or common resource pool in PUSCH directly, i.e. without the PUCCH being multiplexed with PUSCH.

In some examples the PUSCH in common resource pool, is configured to include UCI or CP-UCI without the PUCCH overlapping. In other examples the PUSCH in common resource pool, is configured to include UCI or CP-UCI only if PUCCH overlap with the PUSCH where UCI is sent over PUCCH and multiplexed with PUSCH. In other examples some UCIs (CP-UCI) are included in PUSCH without PUCCH overlap requirement, but for other UCI(s), PUCCH is necessary for UCI transmission (which can be multiplexed with PUSCH), e.g., UCI is based on HARQ-ACK, CSI, etc.

In one example, when CP-UCI is sent directly over PUSCH the network configures which PUSCH allocation from the pool may contain CP-UCI.

In one example, all the PUSCH in the pool can contain UCI. In other examples only certain or subset of PUSCHs or pools are allowed to carry UCI directly, and for other PUSCHs, it is not possible to carry UCI directly (e.g., it may need PUCCH to multiplex UCI over PUSCH).

In some examples the network defines the location of CP-UCI in the PUSCH. For example the CP-UCI may be present in a 1st or last symbol or ‘x’ number of symbols of PUSCH. In other examples the CP-UCI may be present in the nth symbol(s) of the PUSCH. In other examples the CP-UCI presence is define in relation to a DMRS, e.g., after ‘y’ number of symbols from DMRS symbol in PUSCH. In other examples when y is 1 , then CP- UCI is present after DMRS and when y is negative, then CP-UCI is present before DMRS.

In one embodiment, a two stage UCI procedure is proposed. In accordance with Figure. 8, a first UCI 800 is transmitted over PUCCH 810. In this example the UCI points to a PUSCH allocation 820 in the shared pool 830, e.g., TDRA, FDRA of PUSCH 820 in the pool 830. A second stage UCI (CP-UCI) 840 is included in the PUSCH directly where this PUSCH is pointed to by the 1st stage UCI 800. In some examples the second stage UCI 840 indicates decoding parameters of PUSCH.

In some examples of this embodiment the 1st stage UCI 800 points to the 2nd stage UCI in PUSCH by indicating the PRB or symbol where 2nd UCI is present. In some examples the 1 stage UCI 800 points to the 1st symbol of PUSCH. In some examples, based on PUSCH allocation, the network can derive the 2nd UCI location in the PUSCH. In some examples the DMRS symbol of the PUSCH is indicated and the UCI is known to be transmitted relative to the DMRS.

In some examples the 1st stage UCI 800 indicates multiple PUSCHs (HARQ processes) or multi-slot allocation in the pool or shared resource. With reference to Figure.

9, . a UE transmits a first UCI 900 in PUCCH 910 which points to a second stage UCI in PUSCH. Multiple PUSCH resources 920, 950, 970, may be configured in common resources 930. Any of these PUSCHs can have 2nd stage UCI 940, 960, 980 or not, e.g., some may and some may not be indicated by the first stage UCI 900.

In one example of this embodiment, the 1st stage UCI 900 is applicable for PUSCHs (HARQ processes) transmitted over the certain time window or period. Thelst stage UCI 900 may map to many 2nd stage UCIs 940, 960, 980. In some examples the 1 stage UCI indicates time and frequency resources of the multiple PUSCHs 920, 950, 970.

In one example of this embodiment, the location of the second stage CP-UCI 940, 960, 980 in PUSCH 920, 950, 970 is determined to be in the first symbol of PUSCH. In other examples the location is determined to be in the last symbol of PUSCH. In other examples the location is determined in relation to the DMRS of PUSCH.

In some examples the UCI location is fixed in the PUSCH, e.g., always 1st symbol or N-th symbol in the slot where PUSCH is being transmitted. In one some examples, a slot or a block of resource can be divided into parts. For example, in accordance with Figure 10, the slot or block of resource is divided into two parts, where in the initial part, e.g., of a slot or resource block, PUCCH resource is allocated 1000, and in the later part PUSCH 1010 is allocated. The PUSCH optionally contains a 2^nd stage UCI 1020.

In other examples, according to Figure 11 , the slot or block of resource is divided into three parts, where in the initial part, e.g., of a slot or resource block, PUCCH resource 1100 is allocated, and in the middle part PUSCH 1130 is allocated, and in the last part, feedback resource (in DL) 1150 is allocated, In some examples the PUCCH 1100 includes a first stage UCI which points to a first PUSCH resources 1120. The first PUSCH resources 1120 may contain a 2^nd stage UCI. In some examples this first PUSCH has an allocated PDSCH 1150 for DL feedback. Then the second and 3^rd parts of the slot may comprise corresponding PUCCH 1130, 1160 which may comprise 1 ^st stage UCI for second and third PUSCH 1140, 1170 respectively and those PUSCH resources may also contain 2^nd stage UCI

In summary, the PUSCH may contain 2nd stage UCI and certain slots may have feedback (DL symbols) resource allocated in the end of the slot. In some examples certain slots may not have feedback resource. In other examples in certain slots, whole slot is allocated for feedback resource.

In some examples the 1st stage UCI or UCI over PUCCH is defined to be at least K symbols/slots before the start of an associated PUSCH or a first PUSCH from multi-PUSCH. In other examples the 1^st stage UCI is defined to be at least K symbols/slots before the 2nd stage UCI in PUSCH. In some examples, if a multi-slot PUSCH is transmitted, then 2nd stage UCI is included only with the 1st PUSCH.

In Figure 12 a further example is depicted, where a 1^st stage UCI is transmitted as part of a PUCCH 1200. The 1^st Stage UCI indicates first PUSCH resources 1210 within the first the slot. As part of the first PUSCH resources 1210, a 2nd UCI may then indicate parameters for remaining 2^nd or 3^rd PUSCH resources 1220, 1230 in the second and/or 3^rd slots, such as physical resources, encoding schemes, number of PUSCHs, etc.

In some examples, the parameters for decoding of PUSCH#2,#3, are indicated in 2nd stage UCI (in PUSCH#1) 1210. In other examples these parameters are indicated in 1st stage UCI 1200. In some examples the parameters are indicated partly in both UCIs.

In some examples or one or more of the above disclosed embodiments, a UE indicates a capability to gNB for its UCI transmission over PUSCH.

In some examples a UE performs LBT/CSMA before transmitting UCI (PUCCH) if there is LBT success.

In some examples the UCI or 1st stage UCI (over PUCCH) is broadcasted/multicasted to other UEs (allocated in the pool), i.e., other UEs can receive and read the UCI which indicates PUSCH resource reservation in the pool.

In some examples the UE is not required to sense channel before PUSCH (with optional 2nd stage UCI) transmission. The reason for this may be that UE already had performed a successful channel sensing procedure before the UCI transmission (over PUCCH).

In some examples the content of 1st stage UCI indicating PUSCH parameters comprises one or more of: a time resource, e.g., TDRA; a frequency resource, FDRA; a priority indication; a DMRS; a format of 2nd stage UCI or CP-UCI; a location of 2nd stage UCI in PUSCH or CP-UCI or beta-offset indicator; a number of DMRS ports/sequences; a pool ID type; a pool reservation time; and a feedback request (for PUSCH transmission).

In some examples the content of 2nd stage UCI (CP-UCI) indicating PUSCH(s) (in the pool) parameters comprises one or more of: a HARQ ID; a feedback request (for PUSCH transmission); a number of PUSCHs/HARQ IDs; a CSI request; an NDI; an RV or RV pattern (K repetitions); and a number of PUSCHs or multi-slot allocation. In some examples a network node defines the UCI design configuration, and configures PUSCHs or resource pools. For example, the presence of the UCI may be defined/configured based on the options according to Table 1 .

Table 1 : UCI presence configuration options

In some examples when multiple users have requested to use the common pool and a user was not prioritized to do so, the scheduler may send an ordinary grant to that user. This may take longer than if the common pool could be used but is likely to still be faster than the UE waiting until the data in the transmission is decoded and the buffer status report is processed by the base station.

Figure 13 depicts an exemplary method 1300 which may be performed by a wireless device configured for performing uplink transmission. The method begins at step 1310 of transmitting a first transmission using dedicated resources according to a first scheduled data allocation. For example the dedicated resources may be physical uplink shared channel (PUSCH) resources. The first scheduled data allocation may be scheduled dynamically via dedicated signalling such as PDCCH or downlink control information (DCI). In other examples the first scheduled data allocation may be according to a configured grant or semi- persistent scheduling (e.g. SPS).

When further data is required to be transmitted which exceeds the first scheduled data allocation, for example the wireless device has more data left in its buffer or receives higher layer indications (e.g. application level signalling) that more data is to be transmitted, the method proceeds with transmitting 1350 a second transmission comprising at least a part of the further data being transmitted using a common resource pool. For example, the resources may also be defined as physical uplink shared channel (PUSCH) resources. The common resource pool may be preconfigured for a plurality of wireless devices. The second uplink transmission is identified by a control sequence. In some examples this identification corresponds to indicating the location of the second transmission in the common pool resources. In other examples this can include information to decode the second transmission. In other examples the control sequence includes a combination of these information. The control sequence may be defined by a standard such as a 3GPP specification as one or more bits. In other examples the control sequence is defined by a standardised parameter with a number of options. In some examples the options may comprise a set of values wherein depending on the various embodiments described herein, the method comprises the wireless device selecting one or more of the options or sequences to identify the second uplink transmission. In some examples the control sequence is transmitted in association with a physical uplink shared channel and a physical uplink control channel carries other control information and the control sequence is independent from the physical uplink control channel. For example the control sequence may be transmitted in the first transmission and identifies resources in the common resource pool, e.g. to request the use of the PUSCH resource. In other examples the control sequence is transmitted as part of the second transmission and identifies the second uplink transmission with specific parameters which assist the receiving network node/base station in decoding the PUSCH. In some examples the control sequence is received by the wireless device from the network, for example to identify resources to be used for the second transmission, either independently or in response to a request for use of these common resources. In some examples the control sequence comprises one or more data bits transmitted within the common resource pool, the one or more data bits being transmitted separately from a physical uplink control channel. The physical uplink control channel (e.g. PUCCH) may comprise the other uplink control information and may be multiplexed with the PUSCH. In other words, in some examples the control sequence has its own resource elements/symbols and is not multiplexed with a PUSCH, as is a PUCCH. In some examples the second data transmission on the physical uplink shared channel is detectable and/or demodulated based on the control sequence. For example the control sequence contains modulation and coding information and/or resource location information for the PUSCH resources in the common resource pool. In some examples there is a first stage control sequence which identifies or requests the resources to be used for the second transmission. In this case, the control sequence is a second stage control sequence and the physical uplink shared channel resources with which the second stage control sequence is associated is pointed to or indicated by a first stage control sequence. The second stage control sequence identifies the second transmission by providing information to enable the network node/base station to detect the uplink transmission in common resource pool. The control sequence may be defined as a Common Pool Uplink Control Information (CP-UCI).

The method may include the step 1320 of requesting permission to use the common resource pool for a subsequent transmission of data which exceeded the previously scheduled data. In some examples the first stage control sequence requests (1320) the use of the common resource pool. In some examples the first stage control sequence comprises one or more of: a time domain resource allocation; a frequency domain resource allocation; a priority indication; a format of the second stage control sequence; a location of the second stage control sequence or a beta-offset indicator; a DMRS and/or a number of DMRS ports or sequences; a pool ID type a pool reservation time; and a feedback request for the physical uplink shared channel transmission. In some examples the first stage control sequence is transmitted in a physical uplink control channel associated with the first transmission. In some examples the location of the one or more bits of the second stage control sequence is identified according to one or more of: a physical resource block; a symbol position in the physical uplink shared resource channel; a relation to a demodulation reference signal. In some examples the first stage control sequence indicates or points to a plurality of physical uplink shared channel resources in the common resource pool wherein the second stage control sequence is associated with one or more of the plurality of physical uplink shared channels, for example the first stage control sequence may be a request to use one or more of a plurality of the PUSCH resources in common resource pool and the second stage control sequence is associated with one or more of those PUSCH resources. In some examples the requested PUSCH and the associated PUSCH are the same. In other examples they may be different due to a response from the network.

The method may include the step of receiving (1330) an indication permitting the second uplink transmission using the common resource pool. In some examples the permitted use of the common resource pool is restricted to a predefined time period or transmission window.

The method may include starting a transmission timer 1340, the timer corresponding to the time period in which the second uplink transmission is permitted. In some examples a third uplink transmission is performed after the second uplink transmission when the time period permitted for the second uplink transmission (e.g. the transmission timer) has not expired.

In some examples the second stage control sequence comprises one or more of: a hybrid automatic repeat request, HARQ, ID; a feedback request; a number of PUSCHs or HARQ IDs a channel state information request; a new data indication; a redundancy value, RV, indication or RV pattern. In some examples the control sequence which identifies the resources for the second transmission comprises a request to use the common resource pool transmitted as part of or in association with the first uplink transmission. In some examples the control sequence identifies the amount of resources for the second transmission and the receiving step 1330 comprise a response indicating the permission to use the common resource pool for the second uplink transmission wherein the response identifies time and/or frequencies resources within the common resource pool permitted to be used. In some examples the control sequence further comprises time and/or frequency resources of the common resource pool requested for second uplink transmission. The time and/or frequency resources requested in the control sequence may be different from the time and/or frequency resources permitted in the response. The methods as discussed above may be performed by a wireless device, such as a UE, MTC device loT device etc.

Figure 14 depicts and exemplary method 1400 performed by a network node for receiving uplink transmissions from a wireless device. The method 1400 begins with step 1410 of receiving a first transmission using dedicated resources according to a first scheduled data allocation. The previously scheduled data allocation can be as described previously for the method 1300. The method proceeds with receiving 1450 a second uplink transmission using a common resource pool. The common resource pool comprises preconfigured resources for a plurality of wireless devices/ Although the specific preconfiguration details are not deemed to be limited by the scope of this disclosure, i.e. many specific implementations will be available to the skilled reader but as an example via a system broadcast or multicast signalling. The second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation. Specific details of how the UE determines the further data need is described above. In some examples the second uplink transmission is identified by a control sequence associated with physical uplink shared channel of the second uplink transmission and the control sequence is independent from a physical uplink control channel. In some examples the control sequence is transmitted as one or more data bits within the common resource pool, the one or more data bits being transmitted separately from a physical uplink control channel comprising the other uplink control information. For example UCI carried in a PUCCH multiplexed with PUSCH. The method may include detecting and/or demodulating the second data transmission based on the control sequence.

In some examples there is a first stage control sequence transmitted in the first transmission which indicates the location/resources in the common resource pool for the second transmission. As such the control sequence is a second stage control sequence and the physical uplink shared channel resources with which the second stage control sequence is associated is pointed to or indicated by a first stage control sequence. In some examples the method includes the step of receiving a request 1420 to the use of the common resource pool, for example with the first stage control sequence. In some examples the first stage control sequence comprises one or more of: a time domain resource allocation; a frequency domain resource allocation; a priority indication; a format of the second stage control sequence; a location of the second stage control sequence or a beta-offset indicator; a DMRS and/or a number of DMRS ports or sequences; a pool ID type a pool reservation time; and a feedback request for the physical uplink shared channel transmission. In some examples the first stage control sequence is received in a physical uplink control channel associated with the first transmission. In some examples the location of the control sequence is indicated according to one or more of: a physical resource block; a symbol position in the physical uplink shared resource channel; a relation to a demodulation reference signal. For example this may be the one or more bits of the second stage control sequence. In some examples the first stage control sequence points to or indicates one or more of a plurality of physical uplink shared channel resources in the common resource pool wherein the second stage control sequence is associated with one or more of the plurality of physical uplink shared channels. For example the first stage control sequence may request the use of one or more PUSCH resources in the common resource pool and the second stage control sequence provides decoding assistance to those requested resources. In other examples the network node indicates different resources and therefore the second stage control sequence is associated with other PUSCH as indicated by the network node. The control sequence may be defined as a common pool uplink control information, e.g. CP-UCI.

The method may include the step of transmitting 1430 an indication permitting the second uplink transmission to use the common resource pool. In some examples the use of the common resource pool is restricted to a predefined time period or transmission window. The method may include the step of starting a transmission timer 1440 corresponding to the time period in which the second uplink transmission is permitted. In some examples a third uplink transmission is received after the second uplink transmission when the time period permitted for the second uplink transmission has not expired. In some examples the second stage control sequence comprises one or more of: a hybrid automatic repeat request, HARQ, ID; a feedback request; a number of PUSCHs or HARQ IDs a channel state information request; a new data indication; a redundancy value, RV, indication or RV pattern. In some examples the control sequence which identifies the resources for the second transmission comprises a request to use the common resource pool transmitted as part of or in association with the first uplink transmission. In some examples the control sequence identifies the amount of resources for the second transmission and the method further comprising transmitting a response indicating the permission to use the common resource pool for the second uplink transmission wherein the response identifies time and/or frequencies resources within the common resource pool permitted to be used. In some examples the control sequence further comprises time and/or frequency resources of the common resource pool requested for second uplink transmission. In some examples the time and/or frequency resources requested in the control sequence are different from the time and/or frequency resources permitted in a response indicating the permission to use the common resource pool. The methods as discussed above may be performed by a network node for example a radio base station such as 3GPP eNB, gNB or other radio access nodes such as a transmission-reception point (TRP).

Figure 15 shows an example of a communication system 1500 in accordance with some embodiments. In the example, the communication system 1500 includes a telecommunication network 1502 that includes an access network 1504, such as a radio access network (RAN), and a core network 1506, which includes one or more core network nodes 1508. The access network 1504 includes one or more access network nodes, such as network nodes 1510a and 1510b (one or more of which may be generally referred to as network nodes 1510), or any other similar 3^rd Generation Partnership Project (3GPP) access node or non-3GPP access point. The network nodes 1510 facilitate direct or indirect connection of user equipment (UE), such as by connecting UEs 1512a, 1512b, 1512c, and 1512d (one or more of which may be generally referred to as UEs 1512) to the core network 1506 over one or more wireless connections. Example wireless communications over a wireless connection include transmitting and/or receiving wireless signals using electromagnetic waves, radio waves, infrared waves, and/or other types of signals suitable for conveying information without the use of wires, cables, or other material conductors. Moreover, in different embodiments, the communication system 1500 may include any number of wired or wireless networks, network nodes, UEs, and/or any other components or systems that may facilitate or participate in the communication of data and/or signals whether via wired or wireless connections. The communication system 1500 may include and/or interface with any type of communication, telecommunication, data, cellular, radio network, and/or other similar type of system.

The UEs 1512 may be any of a wide variety of communication devices, including wireless devices arranged, configured, and/or operable to communicate wirelessly with the network nodes 1510 and other communication devices. Similarly, the network nodes 1510 are arranged, capable, configured, and/or operable to communicate directly or indirectly with the UEs 1512 and/or with other network nodes or equipment in the telecommunication network 1502 to enable and/or provide network access, such as wireless network access, and/or to perform other functions, such as administration in the telecommunication network 1502.

In the depicted example, the core network 1506 connects the network nodes 1510 to one or more hosts, such as host 1516. These connections may be direct or indirect via one or more intermediary networks or devices. In other examples, network nodes may be directly coupled to hosts. The core network 1506 includes one more core network nodes (e.g., core network node 1508) that are structured with hardware and software components. Features of these components may be substantially similar to those described with respect to the UEs, network nodes, and/or hosts, such that the descriptions thereof are generally applicable to the corresponding components of the core network node 1508. Example core network nodes include functions of one or more of a Mobile Switching Center (MSC), Mobility Management Entity (MME), Home Subscriber Server (HSS), Access and Mobility Management Function (AMF), Session Management Function (SMF), Authentication Server Function (AUSF), Subscription Identifier De-concealing function (SIDF), Unified Data Management (UDM), Security Edge Protection Proxy (SEPP), Network Exposure Function (NEF), and/or a User Plane Function (UPF).

The host 1516 may be under the ownership or control of a service provider other than an operator or provider of the access network 1504 and/or the telecommunication network 1502, and may be operated by the service provider or on behalf of the service provider. The host 1516 may host a variety of applications to provide one or more service. Examples of such applications include live and pre-recorded audio/video content, data collection services such as retrieving and compiling data on various ambient conditions detected by a plurality of UEs, analytics functionality, social media, functions for controlling or otherwise interacting with remote devices, functions for an alarm and surveillance center, or any other such function performed by a server.

As a whole, the communication system 1500 of Figure 15 enables connectivity between the UEs, network nodes, and hosts. In that sense, the communication system may be configured to operate according to predefined rules or procedures, such as specific standards that include, but are 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 standard (e.g., 6G); wireless local area network (WLAN) standards, such as the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standards (WiFi); and/or any other appropriate wireless communication standard, such as the 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. In some examples, the telecommunication network 1502 is a cellular network that implements 3GPP standardized features. Accordingly, the telecommunications network 1502 may support network slicing to provide different logical networks to different devices that are connected to the telecommunication network 1502. For example, the telecommunications network 1502 may provide Ultra Reliable Low Latency Communication (URLLC) services to some UEs, while providing Enhanced Mobile Broadband (eMBB) services to other UEs, and/or Massive Machine Type Communication (mMTC)ZMassive loT services to yet further UEs.

In some examples, the UEs 1512 are configured to transmit and/or receive information without direct human interaction. For instance, a UE may be designed to transmit information to the access network 1504 on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the access network 1504. Additionally, a UE may be configured for operating in single- or multi-RAT or multi-standard mode. For example, a UE may operate with any one or combination of Wi-Fi, NR (New Radio) and LTE, i.e. being configured for multi-radio dual connectivity (MR-DC), such as E- UTRAN (Evolved-UMTS Terrestrial Radio Access Network) New Radio - Dual Connectivity (EN-DC).

In the example, the hub 1514 communicates with the access network 1504 to facilitate indirect communication between one or more UEs (e.g., UE 1512c and/or 1512d) and network nodes (e.g., network node 1510b). In some examples, the hub 1514 may be a controller, router, content source and analytics, or any of the other communication devices described herein regarding UEs. For example, the hub 1514 may be a broadband router enabling access to the core network 1506 for the UEs. As another example, the hub 1514 may be a controller that sends commands or instructions to one or more actuators in the UEs. Commands or instructions may be received from the UEs, network nodes 1510, or by executable code, script, process, or other instructions in the hub 1514. As another example, the hub 1514 may be a data collector that acts as temporary storage for UE data and, in some embodiments, may perform analysis or other processing of the data. As another example, the hub 1514 may be a content source. For example, for a UE that is a VR headset, display, loudspeaker or other media delivery device, the hub 1514 may retrieve VR assets, video, audio, or other media or data related to sensory information via a network node, which the hub 1514 then provides to the UE either directly, after performing local processing, and/or after adding additional local content. In still another example, the hub 1514 acts as a proxy server or orchestrator for the UEs, in particular in if one or more of the UEs are low energy loT devices.

The hub 1514 may have a constant/persistent or intermittent connection to the network node 1510b. The hub 1514 may also allow for a different communication scheme and/or schedule between the hub 1514 and UEs (e.g., UE 1512c and/or 1512d), and between the hub 1514 and the core network 1506. In other examples, the hub 1514 is connected to the core network 1506 and/or one or more UEs via a wired connection. Moreover, the hub 1514 may be configured to connect to an M2M service provider over the access network 1504 and/or to another UE over a direct connection. In some scenarios, UEs may establish a wireless connection with the network nodes 1510 while still connected via the hub 1514 via a wired or wireless connection. In some embodiments, the hub 1514 may be a dedicated hub - that is, a hub whose primary function is to route communications to/from the UEs from/to the network node 1510b. In other embodiments, the hub 1514 may be a non-dedicated hub - that is, a device which is capable of operating to route communications between the UEs and network node 1510b, but which is additionally capable of operating as a communication start and/or end point for certain data channels.

Figure 16 shows a UE 1600 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and/or operable to communicate wirelessly with network nodes and/or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded/integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3GPP), including a narrow band internet of things (NB-loT) UE, a machine type communication (MTC) UE, and/or an enhanced MTC (eMTC) UE. A UE may support device-to- device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (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 relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

The UE 1600 includes processing circuitry 1602 that is operatively coupled via a bus 1604 to an input/output interface 1606, a power source 1608, a memory 1610, a communication interface 1612, and/or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in Figure 16. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

The processing circuitry 1602 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 1610. The processing circuitry 1602 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, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 1602 may include multiple central processing units (CPUs). In the example, the input/output interface 1606 may be configured to provide an interface or interfaces to an input device, output device, or one or more input and/or output devices. Examples of an output device include a speaker, a sound card, a video card, a display, a monitor, a printer, an actuator, an emitter, a smartcard, another output device, or any combination thereof. An input device may allow a user to capture information into the UE 1600. Examples of an input device include a touch-sensitive or presence-sensitive display, a camera (e.g., a digital camera, a digital video camera, a web camera, etc.), a microphone, a sensor, a mouse, a trackball, a directional pad, a trackpad, a scroll wheel, a smartcard, and the like. The presence-sensitive display may include a capacitive or resistive touch sensor to sense input from a user. A sensor may be, for instance, an accelerometer, a gyroscope, a tilt sensor, a force sensor, a magnetometer, an optical sensor, a proximity sensor, a biometric sensor, etc., or any combination thereof. An output device may use the same type of interface port as an input device. For example, a Universal Serial Bus (USB) port may be used to provide an input device and an output device.

In some embodiments, the power source 1608 is structured as a battery or battery pack. Other types of power sources, such as an external power source (e.g., an electricity outlet), photovoltaic device, or power cell, may be used. The power source 1608 may further include power circuitry for delivering power from the power source 1608 itself, and/or an external power source, to the various parts of the UE 1600 via input circuitry or an interface such as an electrical power cable. Delivering power may be, for example, for charging of the power source 1608. Power circuitry may perform any formatting, converting, or other modification to the power from the power source 1608 to make the power suitable for the respective components of the UE 1600 to which power is supplied.

The memory 1610 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 1610 includes one or more application programs 1614, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 1616. The memory 1610 may store, for use by the UE 1600, any of a variety of various operating systems or combinations of operating systems.

The memory 1610 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD-DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, smartcard memory such as tamper resistant 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 ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUlCC), integrated UICC (iUICC) or a removable UICC commonly known as ‘SIM card.’ The memory 1610 may allow the UE 1600 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 1610, which may be or comprise a device-readable storage medium.

The processing circuitry 1602 may be configured to communicate with an access network or other network using the communication interface 1612. The communication interface 1612 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 1622. The communication interface 1612 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 1618 and/or a receiver 1620 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 1618 and receiver 1620 may be coupled to one or more antennas (e.g., antenna 1622) and may share circuit components, software or firmware, or alternatively be implemented separately. In the illustrated embodiment, communication functions of the communication interface 1612 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and/or standards, such as IEEE 802.11 , Code Division Multiplexing 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 networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

Regardless of the type of sensor, a UE may provide an output of data captured by its sensors, through its communication interface 1612, via a wireless connection to a network node. Data captured by sensors of a UE can be communicated through a wireless connection to a network node via another UE. The output may be periodic (e.g., once every 15 minutes if it reports the sensed temperature), random (e.g., to even out the load from reporting from several sensors), in response to a triggering event (e.g., when moisture is detected an alert is sent), in response to a request (e.g., a user initiated request), or a continuous stream (e.g., a live video feed of a patient).

As another example, a UE comprises an actuator, a motor, or a switch, related to a communication interface configured to receive wireless input from a network node via a wireless connection. In response to the received wireless input the states of the actuator, the motor, or the switch may change. For example, the UE may comprise a motor that adjusts the control surfaces or rotors of a drone in flight according to the received input or to a robotic arm performing a medical procedure according to the received input. A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door/window sensor, a flood/moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or item-tracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and/or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 1600 shown in Figure 16.

As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another UE and/or a network node. The UE may in this case be an M2M device, which may in a 3GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3GPP NB-loT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

In practice, any number of UEs may be used together with respect to a single use case. For example, a first UE might be or be integrated in a drone and provide the drone’s speed information (obtained through a speed sensor) to a second UE that is a remote controller operating the drone. When the 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 and/or the second UE can also include more than one of the functionalities described above. For example, a UE might comprise the sensor and the actuator, and handle communication of data for both the speed sensor and the actuators.

In reference to Figure 16, an exemplary embodiment may comprise the wireless device 1600 arranged for performing uplink transmissions. The wireless device 1600 configured to perform a first transmission using physical uplink shared channel resources according to a first scheduled data allocation, wherein further data is required to be transmitted exceeding the first scheduled data allocation, and perform a second transmission comprising at least a part of the further data transmitted using physical uplink shared channel resources from a common resource pool preconfigured for a plurality of wireless devices wherein the resources for the second uplink transmission are identified by a control sequence. In some embodiments the wireless device 1600 is comprising processing circuitry 1602, memory 1610, and communication interface circuitry 1612 comprising a transmitter 1618 and receiver (1620). The processing circuitry 1602 is operative to obtain instructions from the memory 1610 and cause the transmitter 1618 to perform a first transmission using physical uplink shared channel resources according to a first scheduled data allocation, wherein further data is required to be transmitted exceeding the first scheduled data allocation, and perform a second transmission comprising at least a part of the further data transmitted using physical uplink shared channel resources from a common resource pool preconfigured for a plurality of wireless devices wherein the resources for the second uplink transmission are identified by a control sequence. In some examples the wireless device 1600 is further configured to perform any of the methods described herein for a wireless device.

Figure 17 shows a network node 1700 in accordance with some embodiments. As used herein, network node refers to equipment capable, configured, arranged and/or operable to communicate directly or indirectly with a UE and/or with other network nodes or equipment, in a telecommunication 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 NodeBs (gNBs)).

Base stations may be categorized based on the amount of coverage they provide (or, stated differently, their transmit power level) and so, depending on the provided amount of coverage, 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 controlling a relay. A network node may also include one or more (or all) parts of a distributed radio base station such as centralized digital units and/or remote radio units (RRUs), sometimes referred to as Remote Radio Heads (RRHs). Such remote radio units may or may not be integrated with an antenna as an antenna integrated radio. Parts of a distributed radio base station may also be referred to as nodes in a distributed antenna system (DAS).

Other examples of network nodes include multiple transmission point (multi-TRP) 5G access nodes, multi-standard radio (MSR) equipment such as MSR BSs, network controllers such as radio network controllers (RNCs) or base station controllers (BSCs), base transceiver stations (BTSs), transmission points, transmission nodes, multi-cell/multicast coordination entities (MCEs), Operation and Maintenance (O&M) nodes, Operations Support System (OSS) nodes, Self-Organizing Network (SON) nodes, positioning nodes (e.g., Evolved Serving Mobile Location Centers (E-SMLCs)), and/or Minimization of Drive Tests (MDTs).

The network node 1700 includes a processing circuitry 1702, a memory 1704, a communication interface 1706, and a power source 1708. The network node 1700 may be composed of multiple physically separate components (e.g., a NodeB component and a RNC component, or a BTS component and a BSC component, etc.), which may each have their own respective components. In certain scenarios in which the network node 1700 comprises multiple separate components (e.g., BTS and BSC components), one or more of the separate components may be shared among several network nodes. For example, a single RNC may control multiple NodeBs. In such a scenario, each unique NodeB and RNC pair, may in some instances be considered a single separate network node. In some embodiments, the network node 1700 may be configured to support multiple radio access technologies (RATs). In such embodiments, some components may be duplicated (e.g., separate memory 1704 for different RATs) and some components may be reused (e.g., a same antenna 1710 may be shared by different RATs). The network node 1700 may also include multiple sets of the various illustrated components for different wireless technologies integrated into network node 1700, for example GSM, WCDMA, LTE, NR, WiFi, Zigbee, Z- wave, LoRaWAN, Radio Frequency Identification (RFID) or Bluetooth wireless technologies. These wireless technologies may be integrated into the same or different chip or set of chips and other components within network node 1700.

The processing circuitry 1702 may comprise a combination of one or more of a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application-specific integrated circuit, field programmable gate array, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other network node 1700 components, such as the memory 1704, to provide network node 1700 functionality. In some embodiments, the processing circuitry 1702 includes a system on a chip (SOC). In some embodiments, the processing circuitry 1702 includes one or more of radio frequency (RF) transceiver circuitry 1712 and baseband processing circuitry 1714. In some embodiments, the radio frequency (RF) transceiver circuitry 1712 and the baseband processing circuitry 1714 may be on separate chips (or sets of chips), boards, or units, such as radio units and digital units. In alternative embodiments, part or all of RF transceiver circuitry 1712 and baseband processing circuitry 1714 may be on the same chip or set of chips, boards, or units.

The memory 1704 may comprise any form of volatile or non-volatile computer- readable memory including, without limitation, persistent storage, solid-state memory, remotely mounted memory, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), mass storage media (for example, a hard disk), removable storage media (for example, a flash drive, a Compact Disk (CD) or a Digital Video Disk (DVD)), and/or any other volatile or non-volatile, non-transitory device-readable and/or computer-executable memory devices that store information, data, and/or instructions that may be used by the processing circuitry 1702. The memory 1704 may store any suitable instructions, data, or information, including a computer program, software, an application including one or more of logic, rules, code, tables, and/or other instructions capable of being executed by the processing circuitry 1702 and utilized by the network node 1700. The memory 1704 may be used to store any calculations made by the processing circuitry 1702 and/or any data received via the communication interface 1706. In some embodiments, the processing circuitry 1702 and memory 1704 is integrated.

The communication interface 1706 is used in wired or wireless communication of signaling and/or data between a network node, access network, and/or UE. As illustrated, the communication interface 1706 comprises port(s)/terminal(s) 1716 to send and receive data, for example to and from a network over a wired connection. The communication interface 1706 also includes radio front-end circuitry 1718 that may be coupled to, or in certain embodiments a part of, the antenna 1710. Radio front-end circuitry 1718 comprises filters 1720 and amplifiers 1722. The radio front-end circuitry 1718 may be connected to an antenna 1710 and processing circuitry 1702. The radio front-end circuitry may be configured to condition signals communicated between antenna 1710 and processing circuitry 1702. The radio front-end circuitry 1718 may receive digital data that is to be sent out to other network nodes or UEs via a wireless connection. The radio front-end circuitry 1718 may convert the digital data into a radio signal having the appropriate channel and bandwidth parameters using a combination of filters 1720 and/or amplifiers 1722. The radio signal may then be transmitted via the antenna 1710. Similarly, when receiving data, the antenna 1710 may collect radio signals which are then converted into digital data by the radio front-end circuitry 1718. The digital data may be passed to the processing circuitry 1702. In other embodiments, the communication interface may comprise different components and/or different combinations of components.

In certain alternative embodiments, the network node 1700 does not include separate radio front-end circuitry 1718, instead, the processing circuitry 1702 includes radio front-end circuitry and is connected to the antenna 1710. Similarly, in some embodiments, all or some of the RF transceiver circuitry 1712 is part of the communication interface 1706. In still other embodiments, the communication interface 1706 includes one or more ports or terminals 1716, the radio front-end circuitry 1718, and the RF transceiver circuitry 1712, as part of a radio unit (not shown), and the communication interface 1706 communicates with the baseband processing circuitry 1714, which is part of a digital unit (not shown).

The antenna 1710 may include one or more antennas, or antenna arrays, configured to send and/or receive wireless signals. The antenna 1710 may be coupled to the radio front-end circuitry 1718 and may be any type of antenna capable of transmitting and receiving data and/or signals wirelessly. In certain embodiments, the antenna 1710 is separate from the network node 1700 and connectable to the network node 1700 through an interface or port.

The antenna 1710, communication interface 1706, and/or the processing circuitry 1702 may be configured to perform any receiving operations and/or certain obtaining operations described herein as being performed by the network node. Any information, data and/or signals may be received from a UE, another network node and/or any other network equipment. Similarly, the antenna 1710, the communication interface 1706, and/or the processing circuitry 1702 may be configured to perform any transmitting operations described herein as being performed by the network node. Any information, data and/or signals may be transmitted to a UE, another network node and/or any other network equipment.

The power source 1708 provides power to the various components of network node 1700 in a form suitable for the respective components (e.g., at a voltage and current level needed for each respective component). The power source 1708 may further comprise, or be coupled to, power management circuitry to supply the components of the network node 1700 with power for performing the functionality described herein. For example, the network node 1700 may be connectable to an external power source (e.g., the power grid, an electricity outlet) via an input circuitry or interface such as an electrical cable, whereby the external power source supplies power to power circuitry of the power source 1708. As a further example, the power source 1708 may comprise a source of power in the form of a battery or battery pack which is connected to, or integrated in, power circuitry. The battery may provide backup power should the external power source fail.

Embodiments of the network node 1700 may include additional components beyond those shown in Figure 17 for providing certain aspects of the network node’s functionality, including any of the functionality described herein and/or any functionality necessary to support the subject matter described herein. For example, the network node 1700 may include user interface equipment to allow input of information into the network node 1700 and to allow output of information from the network node 1700. This may allow a user to perform diagnostic, maintenance, repair, and other administrative functions for the network node 1700.

In conjunction with Figure 17, an exemplary embodiment may comprise a network node 1700 arranged for receiving uplink transmissions. The network node 1700 configured to receive a first transmission using physical uplink shared channel resources according to a first scheduled data allocation, and receive a second uplink transmission using a physical uplink shared channel in a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation. In some examples the network node 1700 comprising processing circuitry 1702, memory 1704, the processing circuitry 1702 comprising transceiver circuitry 1712. The processing circuitry 1702 is operative to obtain instructions from the memory 1704 and cause the transceiver circuitry 1712 to receive a first transmission using physical uplink shared channel resources according to a first scheduled data allocation, and receive a second uplink transmission using a physical uplink shared channel in a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation. In some examples the network node 1700 is further configured to perform any of the methods described herein related to a network node or radio base station.

Figure 18 is a block diagram of a host 1800, which may be an embodiment of the host 1516 of Figure 15, in accordance with various aspects described herein. As used herein, the host 1800 may be or comprise various combinations hardware and/or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 1800 may provide one or more services to one or more UEs.

The host 1800 includes processing circuitry 1802 that is operatively coupled via a bus 1804 to an input/output interface 1806, a network interface 1808, a power source 1810, and a memory 1812. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as Figures 16 and 17, such that the descriptions thereof are generally applicable to the corresponding components of host 1800.

The memory 1812 may include one or more computer programs including one or more host application programs 1814 and data 1816, which may include user data, e.g., data generated by a UE for the host 1800 or data generated by the host 1800 for a UE. Embodiments of the host 1800 may utilize only a subset or all of the components shown. The host application programs 1814 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (WC), 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 multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 1814 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 1800 may select and/or indicate a different host for over-the-top services for a UE. The host application programs 1814 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG-DASH), etc.

Figure 19 is a block diagram illustrating a virtualization environment 1900 in which functions implemented by some embodiments may be virtualized. In the present context, virtualizing means creating virtual versions of apparatuses or devices which may include virtualizing hardware platforms, storage devices and networking resources. As used herein, virtualization can be applied to any device described herein, or components thereof, and relates to an implementation in which at least a portion of the functionality is 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) implemented in one or more virtual environments 1900 hosted by one or more of hardware nodes, such as a hardware computing device that operates as a network node, UE, core network node, or host. Further, in embodiments in which the virtual node does not require radio connectivity (e.g., a core network node or host), then the node may be entirely virtualized.

Applications 1902 (which may alternatively be called software instances, virtual appliances, network functions, virtual nodes, virtual network functions, etc.) are run in the virtualization environment Q400 to implement some of the features, functions, and/or benefits of some of the embodiments disclosed herein.

Hardware 1904 includes processing circuitry, memory that stores software and/or instructions executable by hardware processing circuitry, and/or other hardware devices as described herein, such as a network interface, input/output interface, and so forth. Software may be executed by the processing circuitry to instantiate one or more virtualization layers 1906 (also referred to as hypervisors or virtual machine monitors (VMMs)), provide VMs 1908a and 1908b (one or more of which may be generally referred to as VMs 1908), and/or perform any of the functions, features and/or benefits described in relation with some embodiments described herein. The virtualization layer 1906 may present a virtual operating platform that appears like networking hardware to the VMs 1908.

The VMs 1908 comprise virtual processing, virtual memory, virtual networking or interface and virtual storage, and may be run by a corresponding virtualization layer 1906. Different embodiments of the instance of a virtual appliance 1902 may be implemented on one or more of VMs 1908, and the implementations may be made in different ways. Virtualization of the hardware is in some contexts referred to as network function virtualization (NFV). NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which can be located in data centers, and customer premise equipment.

In the context of NFV, a VM 1908 may be a software implementation of a physical machine that runs programs as if they were executing on a physical, non-virtualized machine. Each of the VMs 1908, and that part of hardware 1904 that executes that VM, be it hardware dedicated to that VM and/or hardware shared by that VM with others of the VMs, forms separate virtual network elements. Still in the context of NFV, a virtual network function is responsible for handling specific network functions that run in one or more VMs 1908 on top of the hardware 1904 and corresponds to the application 1902.

Hardware 1904 may be implemented in a standalone network node with generic or specific components. Hardware 1904 may implement some functions via virtualization. Alternatively, hardware 1904 may be part of a larger cluster of hardware (e.g. such as in a data center or CPE) where many hardware nodes work together and are managed via management and orchestration 1910, which, among others, oversees lifecycle management of applications 1902. In some embodiments, hardware 1904 is coupled to one or more radio units that each include one or more transmitters and one or more receivers that may be coupled to one or more antennas. Radio units may communicate directly with other hardware nodes via one or more appropriate network interfaces and may be used in combination with the virtual components to provide a virtual node with radio capabilities, such as a radio access node or a base station. In some embodiments, some signaling can be provided with the use of a control system 1912 which may alternatively be used for communication between hardware nodes and radio units.

The VMs may comprise, as depicted in VM1908A for example, a transmission module 1914 wherein the transmission module 1914 is configured to perform a first transmission using physical uplink shared channel resources according to a first scheduled data allocation. When further data is required to be transmitted which exceeds the first scheduled data allocation, for example the wireless device has more data left in its buffer or receives higher layer indications (e.g. application level signalling) that more data is to be transmitted, the transmission module 1914 is further configured to perform a second transmission comprising at least a part of the further data being transmitted using physical uplink shared channel resources from a common resource pool. The VMs may comprise additional modules such as a permission module and a timing module and be further configured to perform any of the methods described herein, such as those described for method 1300.

The VMs may comprise, as depicted in VM1908B for example, a reception module 1916 wherein the reception module 1916 is configured to receive a first transmission using physical uplink shared channel resources according to a first scheduled data allocation. The previously scheduled data allocation can be as described previously for the method 1300. The receiving module 1916 is further configured to receive a second uplink transmission using a physical uplink shared channel in a common resource pool. The common resource pool comprises preconfigured resources for a plurality of wireless devices The VMs may comprise additional modules such as a timing module and may be further configured to perform any of the methods described herein, such as those described for method 1400. Figure 20 shows a communication diagram of a host 2002 communicating via a network node 2004 with a UE 2006 over a partially wireless connection in accordance with some embodiments. Example implementations, in accordance with various embodiments, of the UE (such as a UE 1512a of Figure 15 and/or UE 1600 of Figure 16), network node (such as network node 1510a of Figure 15 and/or network node 1700 of Figure 17), and host (such as host 1516 of Figure 15 and/or host 1800 of Figure 18) discussed in the preceding paragraphs will now be described with reference to Figure 20.

Like host 1800, embodiments of host 2002 include hardware, such as a communication interface, processing circuitry, and memory. The host 2002 also includes software, which is stored in or accessible by the host 2002 and executable by the processing circuitry. The software includes a host application that may be operable to provide a service to a remote user, such as the UE 2006 connecting via an over-the-top (OTT) connection 2050 extending between the UE 2006 and host 2002. In providing the service to the remote user, a host application may provide user data which is transmitted using the OTT connection 2050.

The network node 2004 includes hardware enabling it to communicate with the host 2002 and UE 2006. The connection 2060 may be direct or pass through a core network (like core network 1506 of Figure 15) and/or one or more other intermediate networks, such as one or more public, private, or hosted networks. For example, an intermediate network may be a backbone network or the Internet.

The UE 2006 includes hardware and software, which is stored in or accessible by UE 2006 and executable by the UE’s processing circuitry. The software includes a client application, such as a web browser or operator-specific “app” that may be operable to provide a service to a human or non-human user via UE 2006 with the support of the host 2002. In the host 2002, an executing host application may communicate with the executing client application via the OTT connection 2050 terminating at the UE 2006 and host 2002. In providing the service to the user, the UE's client application may receive request data from the host's host application and provide user data in response to the request data. The OTT connection 2050 may transfer both the request data and the user data. The UE's client application may interact with the user to generate the user data that it provides to the host application through the OTT connection 2050.

The OTT connection 2050 may extend via a connection 2060 between the host 2002 and the network node 2004 and via a wireless connection 2070 between the network node 2004 and the UE 2006 to provide the connection between the host 2002 and the UE 2006. The connection 2060 and wireless connection 2070, over which the OTT connection 2050 may be provided, have been drawn abstractly to illustrate the communication between the host 2002 and the UE 2006 via the network node 2004, without explicit reference to any intermediary devices and the precise routing of messages via these devices.

As an example of transmitting data via the OTT connection 2050, in step 2008, the host 2002 provides user data, which may be performed by executing a host application. In some embodiments, the user data is associated with a particular human user interacting with the UE 2006. In other embodiments, the user data is associated with a UE 2006 that shares data with the host 2002 without explicit human interaction. In step 2010, the host 2002 initiates a transmission carrying the user data towards the UE 2006. The host 2002 may initiate the transmission responsive to a request transmitted by the UE 2006. The request may be caused by human interaction with the UE 2006 or by operation of the client application executing on the UE 2006. The transmission may pass via the network node 2004, in accordance with the teachings of the embodiments described throughout this disclosure. Accordingly, in step 2012, the network node 2004 transmits to the UE 2006 the user data that was carried in the transmission that the host 2002 initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In step 2014, the UE 2006 receives the user data carried in the transmission, which may be performed by a client application executed on the UE 2006 associated with the host application executed by the host 2002.

In some examples, the UE 2006 executes a client application which provides user data to the host 2002. The user data may be provided in reaction or response to the data received from the host 2002. Accordingly, in step 2016, the UE 2006 may provide user data, which may be performed by executing the client application. In providing the user data, the client application may further consider user input received from the user via an input/output interface of the UE 2006. Regardless of the specific manner in which the user data was provided, the UE 2006 initiates, in step 2018, transmission of the user data towards the host 2002 via the network node 2004. In step 2020, in accordance with the teachings of the embodiments described throughout this disclosure, the network node 2004 receives user data from the UE 2006 and initiates transmission of the received user data towards the host 2002. In step 2022, the host 2002 receives the user data carried in the transmission initiated by the UE 2006.

One or more of the various embodiments improve the performance of OTT services provided to the UE 2006 using the OTT connection 2050, in which the wireless connection 2070 forms the last segment. More precisely, the teachings of these embodiments may improve the data rate and in particular the latency due to avoiding further scheduling requests or processing of BSR’s when further data is to be sent. This enables more flexible applications or OTT services to be offered and supported using shared common resources and more dynamic or autonomous transmissions and thereby provide benefits such as improved response times and resolution due to the more efficient data transmission techniques.

In an example scenario, factory status information may be collected and analyzed by the host 2002. As another example, the host 2002 may process audio and video data which may have been retrieved from a UE for use in creating maps. As another example, the host 2002 may collect and analyze real-time data to assist in controlling vehicle congestion (e.g., controlling traffic lights). As another example, the host 2002 may store surveillance video uploaded by a UE. As another example, the host 2002 may store or control access to media content such as video, audio, VR or AR which it can broadcast, multicast or unicast to UEs. As other examples, the host 2002 may be used for energy pricing, remote control of nontime critical electrical load to balance power generation needs, location services, presentation services (such as compiling diagrams etc. from data collected from remote devices), or any other function of collecting, retrieving, storing, analyzing and/or transmitting data.

In some examples, a measurement procedure may be provided for the purpose of monitoring data rate, latency and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 2050 between the host 2002 and UE 2006, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection may be implemented in software and hardware of the host 2002 and/or UE 2006. In some embodiments, sensors (not shown) may be deployed in or in association with other devices through which the OTT connection 2050 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 2050 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not directly alter the operation of the network node 2004. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling that facilitates measurements of throughput, propagation times, latency and the like, by the host 2002. The measurements may be implemented in that software causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 2050 while monitoring propagation times, errors, etc.

Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and/or software needed to perform the tasks, features, functions and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and/or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and/or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer- readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer- readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and/or by end users and a wireless network generally.

Some specific example embodiments relating to Figure 20 are suggested below: i) 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 transmission of the user data to a cellular network for transmission to a user equipment (UE), wherein the UE comprises a communication interface and processing circuitry, the communication interface and processing circuitry of the UE being configured to perform any of the steps of any of the methods relating to method 1300 to receive the user data from the host. ii). The host of embodiment i), wherein the cellular network further includes a network node configured to communicate with the UE to transmit the user data to the UE from the host. iii) The host of embodiments i) or ii), wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the 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. iv) A method implemented by a host operating in a communication system that further includes a network node and a user equipment (UE), the method comprising: providing user data for the UE; and initiating a transmission carrying the user data to the UE via a cellular network comprising the network node, wherein the UE performs any of the operations of any of the methods relating to method 1300 to receive the user data from the host. v) The method of the previous embodiment, further comprising: at the host, executing a host application associated with a client application executing on the UE to receive the user data from the UE. vi) The method of embodiment v), further comprising: at the host, transmitting input data to the client application executing on the UE, the input data being provided by executing the host application, wherein the user data is provided by the client application in response to the input data from the host application. vii) 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 configured to receive the user data from a network node in a cellular network, the network node having a communication interface and processing circuitry, the processing circuitry of the network node configured to perform any of the operations of any of the methods associated with method 1400 to receive the user data from a user equipment (UE) for the host. viii) The host of embodiment vii), wherein: the processing circuitry of the host is configured to execute a host application, thereby providing the 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. ix) The host of the any of embodiments vii) or viii), wherein the initiating receipt of the user data comprises requesting the user data. x) A method implemented by a host configured to operate in a communication system that further includes a network node and a user equipment (UE), the method comprising: at the host, initiating receipt of user data from the UE, the user data originating from a transmission which the network node has received from the UE, wherein the network node performs any of the steps of any of the methods according to method 1400 to receive the user data from the UE for the host. xi) The method of the previous embodiment, further comprising at the network node, transmitting the received user data to the host.

It should be noted that the above-mentioned examples illustrate rather than limit the invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims. Any reference signs in the claims shall not be construed so as to limit their scope.

Claims

1. A method (1300) performed by a wireless device for performing uplink transmission, the method comprising: transmitting a first transmission (1310) using dedicated resources according to a first scheduled data allocation, wherein further data is required to be transmitted which exceeds the first scheduled data allocation, and transmitting a second transmission (1350) comprising at least a part of the further data transmitted using a common resource pool preconfigured for a plurality of wireless devices, wherein the second uplink transmission is identified by a control sequence.

2. The method of claim 1 , wherein the control sequence is transmitted in the first or second transmission in association with a physical uplink shared channel and a physical uplink control channel carries other control information, wherein the control sequence is independent from the physical uplink control channel.

3. The method of claim 1 or 2, wherein the control sequence comprises one or more data bits transmitted within the common resource pool, the one or more data bits being transmitted separately from a physical uplink control channel multiplexed with a physical uplink shared channel comprising the other uplink control information.

4. The method of claims 1 - 3, wherein the second data transmission on the physical uplink shared channel is detectable and/or demodulated based on the control sequence.

5. The method of any of claims 1 - 4, wherein the control sequence is a second stage control sequence and the physical uplink shared channel resources with which the second stage control sequence is associated is indicated by a first stage control sequence.

6. The method according to claim 5 wherein the first stage control sequence requests (1320) the use of the common resource pool.

7. The method of any one of the preceding claims, wherein the control sequence comprises one or more of: a time domain resource allocation; a frequency domain resource allocation; a priority indication; a format of the second stage control sequence; a location of the second stage control sequence or a beta-offset indicator; a DMRS and/or a number of DMRS ports or sequences; a pool ID type a pool reservation time; and a feedback request for the physical uplink shared channel transmission.

8. The method according to any of claims 5 to 7, wherein the first stage control sequence is transmitted in a physical uplink control channel associated with the first transmission.

9. The method according to any of claims 5 to 8, wherein the location of the control sequence is indicated according to one or more of: a physical resource block; a symbol position in the physical uplink shared resource channel; and a relation to a demodulation reference signal.

10. The method according to any of claims 5 to 9, wherein the first stage control sequence indicates one or more of a plurality of physical uplink shared channel resources in the common resource pool; and wherein the second stage control sequence is transmitted in association with one or more of the plurality of physical uplink shared channels.

11 . The method according to any of claims 1 to 10, further comprising: receiving (1330) an indication permitting the second uplink transmission to use the common resource pool.

12. The method according to any claim, wherein the use of the common resource pool is restricted to a predefined time period or transmission window.

13. The method according to claim 12, further comprising starting a transmission timer corresponding to the time period in which the second uplink transmission is permitted.

14. The method according to claim 12 or 13, wherein a third uplink transmission is performed after the second uplink transmission when the time period permitted for the second uplink transmission has not expired.

15. The method according to any of claims 5 to 14, wherein the second stage control sequence comprises one or more of: a hybrid automatic repeat request, HARQ, ID; a feedback request; a number of PUSCHs or HARQ IDs a channel state information request; a new data indication; a redundancy value, RV, indication or RV pattern.

16. The method of claim 1 or 2, wherein the control sequence which identifies the second transmission comprises a request to use the common resource pool transmitted as part of or in association with the first uplink transmission.

17. The method of claim 16 wherein the control sequence identifies the amount of resources for the second transmission; and the method further comprising: receiving a response indicating the permission to use the common resource pool for the second uplink transmission; wherein the response identifies time and/or frequency resources within the common resource pool permitted to be used.

18. The method of claim 16 or 17 wherein the control sequence further comprises time and/or frequency resources of the common resource pool requested for second uplink transmission.

19. The method of claim 18, wherein the time and/or frequency resources requested in the control sequence are different from the time and/or frequency resources permitted in the response.

20. A method (1400) performed by a network node for receiving uplink transmissions from a wireless device, the method comprising: receiving (1410) a first transmission using dedicated resources according to a first scheduled data allocation, and receiving (1450) a second uplink transmission using a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation.

21 . The method of claim 20, wherein the second uplink transmission is identified by a control sequence associated with a physical uplink shared channel of the second uplink transmission and the control sequence is independent from a physical uplink control channel.

22. The method of any of claims 20 to 21 , wherein the control sequence is transmitted as one or more data bits within the common resource pool, the one or more data bits being transmitted separately from a physical uplink control channel comprising the other uplink control information.

23. The method of any of claims 20 to 22, further comprising detecting and/or demodulating the second data transmission based on the control sequence.

24. The method of any of claims 20 to 23, wherein the control sequence is a second stage control sequence and the physical uplink shared channel resources with which the second stage control sequence is associated is pointed to by a first stage control sequence.

25. The method according to claim 24 further comprising receiving (1420) a request to use the common resource pool, wherein the first stage control sequence includes the request.

26. The method of any of claims 20 to 25, wherein the control sequence comprises one or more of: a time domain resource allocation; a frequency domain resource allocation; a priority indication; a format of the second stage control sequence; a location of the second stage control sequence or a beta-offset indicator; a DMRS and/or a number of DMRS ports or sequences; a pool ID type a pool reservation time; and a feedback request for the physical uplink shared channel transmission.

27. The method according to any of claims 24 to 26, wherein the first stage control sequence is received in a physical uplink control channel associated with the first transmission.

28. The method according to any of claims 20 to 27, wherein the location of the control sequence is identified according to one or more of: a physical resource block; a symbol position in the physical uplink shared resource channel; a relation to a demodulation reference signal.

29. The method according to any of claims 24 to 28, wherein the first stage control sequence indicates one or more of a plurality of physical uplink shared channel resources in the common resource pool and wherein the second stage control sequence is associated with one or more of the plurality of physical uplink shared channels.

30. The method according to any of claims 20 to 29, further comprising: transmitting (1430) an indication permitting the second uplink transmission to use the common resource pool.

31. The method according to claim 30, wherein the use of the common resource pool is restricted to a predefined time period or transmission window.

32. The method according to claim 31 , further comprising starting a transmission timer corresponding to the time period in which the second uplink transmission is permitted.

33. The method according to claim 31 or 32, wherein a third uplink transmission is received after the second uplink transmission when the time period permitted for the second uplink transmission has not expired.

34. The method according to any of claims 24 to 33, wherein the second stage control sequence comprises one or more of: a hybrid automatic repeat request, HARQ, ID; a feedback request; a number of PUSCHs or HARQ IDs a channel state information request; a new data indication; a redundancy value, RV, indication or RV pattern.

35. The method of claim 20 or 21 , wherein the control sequence which identifies the resources for the second transmission comprises a request to use the common resource pool transmitted as part of or in association with the first uplink transmission.

36. The method of claim 35 wherein the control sequence identifies the amount of resources for the second transmission and the method further comprising: transmitting a response indicating the permission to use the common resource pool for the second uplink transmission wherein the response identifies time and/or frequencies resources within the common resource pool permitted to be used.

37. The method of claim 35 or 36 wherein the control sequence further comprises time and/or frequency resources of the common resource pool requested for second uplink transmission.

38. The method of claim 37, wherein the time and/or frequency resources requested in the control sequence are different from the time and/or frequency resources permitted in a response indicating the permission to use the common resource pool.

39. A wireless device (1600) for performing uplink transmissions, the wireless device (1600) configured to: perform a first transmission using dedicatedresources according to a first scheduled data allocation, wherein further data is required to be transmitted which exceeds the first scheduled data allocation, and perform a second transmission comprising at least a part of the further data transmitted using a common resource pool preconfigured for a plurality of wireless devices wherein the second uplink transmission is identified by a control sequence.

40. A wireless device (1600) comprising processing circuitry (1602), memory (1610), and communication interface circuitry (1612) comprising a transmitter (1618) and receiver (1620), the processing circuitry (1602) operative to obtain instructions from the memory (1610) and cause the transmitter (1618) to: perform a first transmission using dedicated resources according to a first scheduled data allocation, wherein further data is required to be transmitted which exceeds the first scheduled data allocation, and perform a second transmission comprising at least a part of the further data transmitted using a common resource pool preconfigured for a plurality of wireless devices wherein the second uplink transmission is identified by a control sequence.

41 . The wireless device (1600) of claim 39 or 40, further configured to perform any of the methods of claims 2 to 19.

42. A network node (1700) for receiving uplink transmissions, the network node configured to: receive a first transmission using dedicated resources according to a first scheduled data allocation, and receive a second uplink transmission using a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation.

43. A network node (1700) comprising processing circuitry (1702), memory (1704), the processing circuitry (1702) comprising transceiver circuitry (1712), the processing circuitry (1702) operative to obtain instructions from the memory (1704) and cause the transceiver circuitry (1712) to: receive a first transmission using dedicated resources according to a first scheduled data allocation, and receive a second uplink transmission using a common resource pool, the common resource pool comprising preconfigured resources for a plurality of wireless devices and wherein the second uplink transmission comprises further data not received in the first transmission and exceeding the first scheduled data allocation.

44. The network node of claim 42 or 43, further configured to perform any of the methods of claims 21 to 38.

45. A computer program or memory or carrier comprising a computer program, the computer program including instructions which when executed on a processor of a wireless device, cause the wireless device to perform any of the methods of claims 1 to 19 and when executed on a processor of a network node cause the network node to perform any of the methods of claims 20 to 38.