Method performed by mobile device, method performed by access network node, mobile device, and access network node

Abstract

A wireless communication system is described that consists of at least one RAN, at least one UE. In particular, herein described are means and methods of implementing contention-based (CB) uplink (UL) data transmissions to at least one RAN node using common / shared resources.

Description

METHOD PERFORMED BY MOBILE DEVICE, METHOD PERFORMED BY ACCESS NETWORK NODE, MOBILE DEVICE, AND ACCESS NETWORK NODE

[0001] The present disclosure relates to a communication system and to parts thereof.

[0002] The disclosure has particular but not exclusive relevance to wireless communication systems and devices thereof operating according to the 3rd Generation Partnership Project (3GPP) standards or equivalents or derivatives thereof (including Long Term Evolution (LTE)-Advanced, Next Generation or 5G / 6G networks, future generations, and beyond). The present disclosure in particular, but not exclusively, relates to contention-based (CB) uplink (UL) data transmissions using common / shared resources, and methods of providing contention resolution for those UL data transmissions.

[0003] Earlier developments of the 3GPP standards were referred to as the Long-Term Evolution (LTE) of Evolved Packet Core (EPC) network and Evolved Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (E-UTRAN), also commonly referred as '4G'. More recently, the term '5G' and 'new radio' (NR) has started to be used to refer to an evolving communication technology that is expected to support a variety of applications and services. Various details of 5G networks are described in, for example, the 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN) Alliance, which document is available from https: / / www.ngmn.org / 5g-white-paper.html. 3GPP intends to support 5G by way of the so-called 3GPP Next Generation (NextGen) radio access network (RAN) and the 3GPP NextGen core network.

[0004] Under the 3GPP standards, a NodeB (or e.g., an eNB in LTE, and gNB in 5G) is the radio access network (RAN) node (or simply 'access node', 'access network node' or 'base station') via which communication devices (user equipments or 'UEs') connect to a core network and communicate with other communication devices or remote servers. For simplicity, the present application will use the term access network node, RAN node or base station to refer to any such access nodes.

[0005] For simplicity, the present application will use the term mobile device, user device, or UE to refer to any communication device that is able to connect to the core network via one or more RAN nodes. Although the present application may refer to mobile devices in the description, it will be appreciated that the technology described can be implemented on any communication devices (mobile and / or generally stationary) that can connect to a communication network for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0006] In the current 5G architecture, the gNB structure may be split into two or more parts. In some RAN implementations there are two parts, known as the Central Unit (CU or gNB-CU) - sometimes referred to as a 'control unit' - and the Distributed Unit (DU or gNB-DU), connected by an F1 interface. This enables the use of a 'split' architecture in which the typically 'higher' CU layers (for example, but not necessarily or exclusively, Packet Data Convergence Protocol (PDCP) and Radio Resource Control (RRC) layers) and the, 'lower' DU layers (for example, but not necessarily or exclusively, Radio Link Control (RLC), Media (sometimes referred to as 'Medium') Access Control (MAC), and Physical (PHY) layers) are separated between a particular CU, and one or more DUs that are connected to and controlled by that CU via the F1 interface. Thus, for example, the higher layer CU functionality for a number of gNBs may be implemented centrally (for example, by a single processing unit, or in a cloud-based or virtualised system), whilst retaining the lower layer DU functionality locally separately for each gNB.

[0007] In more recently proposed RAN distributed architectures, in addition to the CU and DU, the concept of a Radio Unit (RU) - sometimes referred to as a 'remote unit' - has been introduced. In this architecture the RU is responsible for handling the digital front end (DFE), digital beamforming functionality and, typically, the functionality of the lower parts of the PHY layer, whilst the DU typically handles the higher parts of the PHY layer and the RLC and MAC layers. The CU in this architecture continues to be responsible for controlling one or more DUs (each DU corresponding to a different respective gNB) and to handle higher layer signalling (typically RRC and PDCP layers).

[0008] The actual functional split between the CU and DUs (and potentially RUs where applicable) of these distributed architectures is flexible allowing the functionality to be optimised for different use cases. Effectively, the split architecture enables a 5G network to use a different distribution of protocol stacks between CU and DUs (and potentially RUs) depending on, for example, mid-haul availability and network design.

[0009] The choice of how to split functions in the architecture depends on, among other things, factors related to radio network deployment scenarios, constraints and intended supported use cases. Key considerations include: the need to support a specific quality of service for each service offered and for real / non-real time applications; support of specific user density and load demand in a given geographical area; and available transport networks with different performance levels.

[0010] In 5G, core network entities comprise logical nodes (or 'functions') including control plane functions (CPFs) and one or more user plane functions (UPFs). The CPFs include, amongst other things, one or more Access and Mobility Management Functions (AMFs), a session management function (SMF), and one or more location management functions (LMFs). The AMF generally corresponds to the MME in 4G and performs many of the functions performed by the MME. Each UPF combines functionality of both the S-GW and P-GW - specifically user plane functionality of the S-GW (SGW-U) and user plane functionality of the P-GW (PGW-U). The SMF provides session management functionality (that formed part of MME functionality in 4G). The SMF also combines the some of the functionality provided by the S-GW and P-GW - specifically control plane functionality of the S-GW (SGW-C) and control plane functionality of the P-GW (PGW-C). The SMF also allocates IP addresses to each UE.

[0011] 3GPP is also working with the satellite communication industry to specify an integrated satellite and terrestrial network infrastructure in the context of 5G (and beyond). This is referred to as non-terrestrial networks (NTN) which term refers to networks, or segments of networks, using an airborne or spaceborne vehicle for transmission of data and control signalling. Satellites refer to spaceborne vehicles in Low Earth Orbits (LEO), Medium Earth Orbits (MEO), Geostationary Earth Orbit (GEO) or in Highly Elliptical Orbits (HEO). Airborne vehicles refer to High Altitude Platforms (HAPs) encompassing Unmanned Aircraft Systems (UAS) - including tethered UAS, Lighter than Air UAS and Heavier than Air UAS - all operating quasi-stationary at an altitude typically between 8 and 50 km.

[0012] 3GPP Technical Report (TR) 38.811 is a study on New Radio to support such non-terrestrial networks. The study includes, amongst other things, NTN deployment scenarios and related system parameters (such as architecture, altitude, orbit etc.) and a description of adaptation of the 3GPP channel models for non-terrestrial networks (propagation conditions, mobility, etc.). Non-terrestrial networks are expected to: -　　help foster the 5G (and beyond) service roll out in un-served or underserved areas to upgrade the performance of terrestrial networks; -　　reinforce service reliability by providing service continuity for user equipment or for moving platforms (e.g. passenger vehicles - aircraft, ships, high speed trains, buses); -　　increase service availability everywhere; especially for critical communications, future railway / maritime / aeronautical communications; and -　　enable 5G (and beyond) network scalability through the provision of efficient multicast / broadcast resources for data delivery towards the network edges or even directly to the user equipment.

[0013] NTN access typically features the following elements (amongst others): -　　NTN Terminal: this may refer to the 3GPP UE or to a UE specific to the satellite system in the case that the satellite does not serve 3GPP UEs directly; -　　A service link which refers to the radio link between the UE and the space / airborne platform (which may be in addition to a radio link with a terrestrial based RAN); -　　A space or an airborne platform (e.g., a satellite or the like); -　　Gateways that connect the satellite or aerial access network to the core network. It will be appreciated that gateways will mostly likely be collocated with a base station (e.g. a gNB); -　　Feeder links which refer to the radio links between the Gateways and the space / airborne platform.

[0014] Satellite or aerial vehicles typically generate several satellite beams over a given area. The beams have a typically elliptic footprint on the surface of the earth. The beam footprint may be moving over the earth with the satellite or the aerial vehicle motion on its orbit. Alternatively, the beam footprint may be earth fixed (albeit temporarily), in such case some beam pointing mechanisms (mechanical or electronic steering feature) may be used to compensate for the satellite or the aerial vehicle motion. There are different options for beam identification purposes. In one option multiple (nearby / neighbouring) satellite beams may have the same associated physical cell identifier (ID) (PCI) and hence the PCI can remain unchanged as a UE moves from beam-to-beam of the set of beams sharing a PCI. Alternatively, there may be a one-to-one relationship between the PCIs and the satellite beams (at least within a particular satellite's coverage area comprising multiple beams).

[0015] The coverage in many modern communication systems is often beam-based rather than cell based. There is no cell-level reference channel from where the coverage of the cell could be measured. Instead, each cell has one or more so-called synchronization signal / physical broadcast channel (PBCH) block (SSB) beams (which are different to satellite or NTN beams). SSB beams form a matrix of beams covering an entire cell area. Each SSB beam carries an SSB comprising a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH).

[0016] The UE searches for and performs measurements on the SSB beams (e.g., of the synchronization signal reference signal received power, 'SS-RSRP,' synchronization signal reference signal received quality, 'SS-RSRQ,' and / or the synchronization signal to noise and interference ratio, 'SS-SINR'). The UE maintains a set of candidate beams which may contain beams from multiple cells. A PCI and beam ID (or SSB index) thus distinguish the SSB beams from each other. Effectively, therefore, the SSB beams are like mini cells which may be within a larger cell. Once a UE has detected and selected a cell (and / or an SSB beam in the case of 5G) it may attempt to access that cell and / or SSB beam using an initial RRC connection setup procedure comprising a random-access procedure.

[0017] For example, once a UE has detected and selected a cell (and / or a beam in the case of 5G) it may attempt to access that cell and / or beam using an initial RRC connection setup procedure comprising a random access (RACH) procedure that historically involved four distinct steps. More recently, a simplified access procedure has been developed by which a UE may attempt to access that cell and / or beam using a two-step RACH procedure. Both the four step and two step RACH procedures are well known to those skilled in the art.

[0018] In summary, the four-step procedure typically involves the UE selecting random access resources (including, for example, a preamble) that it uses to initiate the RACH procedure. The UE sends the selected preamble in a first message ('Msg1') to a base station over a physical random-access channel (PRACH). In response, the base station responds with a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes, amongst other things, an uplink grant field indicating resources to be used in the uplink for a physical uplink shared channel (PUSCH). The UE then sends a third message ('Msg3') to the network over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE in this step, and the content of the message, depends on the context in which the random-access procedure is being used. For initial RRC connection setup, for example, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The network responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs using the same preamble sequence. When successful, Msg4 also transfers the UE to a connected state.

[0019] As those skilled in the art will appreciate, while a contention based random-access (CBRA) procedure is described, a non-contention based (or 'contention free') procedure may also be used, e.g., in which a dedicated preamble is assigned by the base station to the UE.

[0020] The two-step procedure is similar in terms of the information transferred but involves one UE to base station message ('MsgA') and one base station to UE message ('MsgB'). MsgA, in effect, combines Msg1 and Msg 3 of the four-step procedure, and MsgB, in effect, combines Msg2 and Msg4 of the four-step procedure.

[0021] It will be appreciated that random access procedures such as those mentioned above may also be used in other contexts including, for example, handover, connection reestablishment, requesting UL scheduling where no dedicated resource for a scheduling-request has been configured for the UE, etc.

[0022] More recently, there have been proposals to develop further enhancements to the access procedure, for certain scenarios, to reduce the necessary uplink and downlink signalling to support a so-called early data transmission (EDT) transaction.

[0023] EDT is an enhancement which allows UL data transmission of infrequent and small amounts of data followed by an optional DL data transmission during a CBRA procedure that aims to reduce latency and power consumption at a UE; the reduction in latency being particularly beneficial for e.g., Internet of Things (IoT) and 5G use cases. EDT is typically triggered when upper layers have requested the establishment or resumption of an RRC Connection for mobile originated data (i.e., not signalling, or short message service (SMS)) and the uplink data size is less than or equal to a transport block (TB) size indicated in system information (SI).

[0024] In one current EDT technique, EDT is achieved in a contention based (CB) manner using an appropriate (e.g., four-step) RACH based procedure. In another EDT technique, EDT is achieved in a non-contention based manner in which data is sent early, using one or more dedicate preconfigured uplink resources (PURs), without requiring full establishment / resumption of an RRC connection. For contention-less PUR-based transmission, one or more dedicated PURs are assigned to the UE in advance, for use in an RRC Idle state, which allows for early UL data transmission using those resources without the need for performing a full RRC connection setup / resumption procedure (e.g., without needing to switch to an RRC connected state). The PURs may, for example, be configured on initiation of a transition from an earlier RRC connected state to RRC idle (e.g., by an RRC connection release message or the like). In this case, as the UL resources are preconfigured, the UE 3 does not need to perform a full RACH-like procedure (e.g., a full four-step procedure as described above) but can, instead, skip the transmission of the random-access preamble (Msg1) and the reception of the RAR message (Msg2).

[0025] Other enhancements to EDT procedures have also been proposed, for example to increase Msg3 (e.g., message carrying the early data) throughput. One such enhancement proposed for EDT, for example, is a contention resolution mechanism based on the so-called Additive Links On-line Hawaii Area (ALOHA) protocol. In particular, enhancements have been proposed for EDT that involve diversity slotted ALOHA (DSA), or contention resolution DSA (CRDSA), based techniques. In CRDSA, replica transmissions of the Msg3 transmissions that form part of an EDT procedure are implemented to improve uplink capacity and collision diversity. Thus, in the event that the RAN receives multiple Msg3 transmissions from different UEs in a same random-access (RA) slot (i.e., a same time resource), the RAN may be more likely to be able to correctly decode those Msg3 transmissions. With respect to collision diversity, CRDSA uses an efficient decision-directed interference cancelation technique to enable efficient decoding and processing of the Msg3 transmissions.

[0026] One possible further enhancement to EDT, which is particularly (but not exclusively) relevant in the context of IoT implementations for NTN, is to allow Msg3 transmission without requiring Msg1 transmission, or transmission of the associated RAR (Msg2). One technique for supporting this, for example, might be to further develop the CB RACH procedure to allow (RACH-less) contention-based (CB) Msg3 transmission. Another possible enhancement to EDT is to further develop the current contention-less PUR procedure (based on a preconfigured dedicated resource), which may be referred to as enhanced PUR-based Msg3 transmission. Currently, specifying (RACH-less) CB Msg3 transmission, rather than enhanced contention-less PUR-based Msg3 transmission, is more widely proposed.

[0027] NPL 1: 'NGMN 5G White Paper' V1.0 by the Next Generation Mobile Networks (NGMN), available from https: / / www.ngmn.org / 5g-white-paper.html.

[0028] There is, however, still a need for further development in a number of areas to support effective (RACH-less) CB data transmission without requiring Msg1 / Msg2 transmission. These areas include, for example: how to configure shared PUSCH resources for such CB transmissions; how, and under what conditions, such a CB procedure might be initiated; how a UE might be configured to recognise a response message for that UE (as opposed to another UE), e.g., via the determination of an appropriate radio-network temporary ID (RNTI); the content of any such response message (including for the purposes of contention resolution); the necessity and nature of any fall-back and / or load control procedures; etc.

[0029] It may also be the case that subsequent data transmission (after an initial EDT) may need to be supported. In the event that support for subsequent transmission is required there is a need for further development to determine how such support should be implemented.

[0030] Moreover, DSA / CRDSA may need to be supported. In the event that support for DSA / CRDSA is required there is a need for further development to determine how such support should be implemented.

[0031] The present specification aims to disclose apparatus and methods that at least contribute to addressing one or more of the above needs.

[0032] The disclosure aims to describe one or more apparatus and / or one or more associated methods that contributes to or at least partially addresses one or more of the above needs.

[0033] The various functional means described below that are part of the UE may be provided by a memory and one or more processors that execute instructions stored in the memory. Similarly, the various functional means described below that are part of the access network node may be provided by a memory and one or more processors that execute instructions stored in the memory.

[0034] Various example described below may be implemented by means of a computer program product comprising computer implementable instructions for causing a programmable computer to carry out the any of the methods described below. The computer implementable instructions may be provided as a signal or on a tangible computer readable medium.

[0035] Examples of apparatus and methods will now be described, by way of example, with reference to the accompanying drawings in which:

[0036] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system;Fig. 2A illustrates schematically a non-terrestrial network (NTN) radio access network that may be used in the communication system of Fig. 1;Fig. 2B illustrates schematically a non-terrestrial network (NTN) radio access network that may be used in the communication system of Fig. 1;Fig. 2C illustrates schematically a non-terrestrial network (NTN) radio access network that may be used in the communication system of Fig. 1;Fig. 3 illustrates a possible architecture of an NTN RAN;Fig. 4 is a simplified sequence diagram illustrating an example early data transmission (EDT) procedure using a contention-based four-step RACH procedure that may be implemented in the communication system of Fig. 1;Fig. 5 is a simplified sequence diagram illustrating an example preconfigured uplink resource (PUR)-based EDT procedure that may be implemented in the communication system of Fig. 1;Fig. 6 illustrates an example of a Contention Resolution Diversity Slotted Aloha (CRDSA) time-division multiple access (TDMA) random access (RA) frame comprising N slots;Fig. 7 illustrates a simplified sequence diagram of an example contention-based (CB) data transmission procedure using common / shared uplink (UL) resources that may be implemented in the communication system of Fig. 1;Fig. 8A illustrates a first example RTNI determination method comprising a one-to-one mapping of an RNTI value to a common / shared UL resource that may be implemented in the CB data transmission procedure of Fig. 7;Fig. 8B illustrates an example response MAC PDU format that may be used with the RTNI determination method of Fig. 8A;Fig. 9 illustrates a second example RTNI determination method comprising a one-to-many mapping of an RNTI value to multiple common / shared UL resources that may be implemented in the CB data transmission procedure of Fig. 7;Fig. 10A illustrates an example response MAC PDU formats that may be used with a number of different RTNI determination methods;Fig. 10B illustrates a different example response MAC PDU formats that may be used with a number of different RTNI determination methods;Fig. 11 illustrates a third example RTNI determination method comprising a one-to-many mapping of an RNTI value to multiple common / shared UL resources that may be implemented in the CB data transmission procedure of Fig. 7;Fig. 12 illustrates a fourth example RTNI determination method comprising a one-to-many mapping of an RNTI value to multiple common / shared UL resources that may be implemented in the CB data transmission procedure of Fig. 7;Fig. 13 illustrates a fifth example RTNI determination method comprising a one-to-many mapping of an RNTI value to multiple common / shared UL resources that may be implemented in the CB data transmission procedure of Fig. 7;Fig. 14 illustrates a simplified sequence diagram of an adapted version of the CB data transmission procedure of Fig. 7 that supports subsequent data transmissions;Fig. 15 illustrates a simplified sequence diagram of another adapted version of the CB data transmission procedure of Fig. 7 that supports Diversity Slotted Aloha (DSA) and / or CRDSA;Fig. 16 is a simplified block schematic illustrating the main components of a UE for implementation in the communication system of Fig. 1;Fig. 17 is a schematic block diagram illustrating the main components of a non-distributed base station for the communication system of Fig. 1; andFig. 18 is a schematic block diagram illustrating the main components of a distributed base station for the communication system of Fig. 1.

[0037] <Overview> 　　An exemplary communication system will now be described in general terms, by way of example only, with reference to Figs. 1, 2A to 2C, and 3.

[0038] Fig. 1 schematically illustrates a mobile ('cellular' or 'wireless') communication system 1 to which the examples described herein are applicable.

[0039] In the communication system 1, user equipments (UEs) 3 (3-1, 3-2, 3-3) (e.g., mobile telephones and / or other mobile or stationary devices) can communicate with each other via a corresponding (radio) access network ((R)AN) 5 (5-1, 5-2) that operates according to one or more compatible radio access technologies (RATs). In the illustrated example, each RAN 5 comprises a corresponding base station (5A) 5A-1, 5A-2 (which may be integrated or distributed type base stations) operating one or more associated cells 9 (9-1, 9-2).Communication via each RAN 5 is typically routed through a core network 7 (e.g., a 5G / 6G / later generation core network or evolved packet core network (EPC)) or any other core network.

[0040] As those skilled in the art will appreciate, whilst three UEs 3 and two RANs 5 are shown in Fig. 1 for illustration purposes, the system, when implemented, will typically include other RANs 5 and UEs 3. Each RAN 5 respectively controls the associated cells 9 either directly, or indirectly via one or more other nodes (such as home base stations, relays, remote radio heads, distributed units, and / or the like). It will be appreciated that each RAN 5 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0041] In the illustrated example, one RAN 5-1 is non-terrestrial network (NTN) RAN, while the other RAN 5-2 is a terrestrial network (TN). It will be appreciated that both RANs 5 in the communication system 1 may be TN RANs, or alternatively, both RANs 5 in the communication system 1 may be NTN RANs.

[0042] The UEs 3 and their serving RAN 5 are connected via an appropriate air interface (for example the so-called 'Uu' interface and / or the like). Base stations 5A of neighbouring RANs 5 may be connected to each other via an appropriate base station to base station interface (such as the so-called 'X2' interface, 'Xn' interface and / or the like - not shown in Fig. 1).

[0043] The core network 7 includes a number of logical nodes (or 'functions') for supporting communication in the communication system 1. In this example, the core network 7 comprises control plane functions (CPFs) 10 and one or more network node entities for the communication of user data (e.g., user plane functions (UPFs) 11). The CPFs 10 include one or more network node entities for the communication of control signalling (e.g., Access and Mobility Management Functions (AMFs) 10-1), one or more network node entities for session management (e.g., Session Management Functions (SMFs) 10-2) and a number of other functions 10-n. Additional functions may include, for example: an Authentication Server Function (AUSF) which facilitates security processes; a Unified Data Management (UDM) entity for managing user specific data (e.g., for access authorization, user registration, and data network profiles); a Policy Control Function (PCF); an Application Function (AF); a Security Anchor Function (SEAF) which is in a serving network and acts as a "middleman" during an authentication process between a UE 3 and its home network; an Authentication credential Repository and Processing Function (ARPF) which maintains the authentication credentials; and / or the like. It will be appreciated that the nodes or functions may have different names in different systems.

[0044] Each RAN 5 is connected to the core network nodes via appropriate interfaces (or 'reference points') such as an N2 reference point between the RAN 5 and the AMF 10-1 for the communication of control signalling, and an N3 reference point between the RAN 5 and each UPF 11 for the communication of user data. The UEs 3 are each connected to the AMF 10-1 via a non-access stratum (NAS) connection over an appropriate reference point (e.g. N1 reference point (analogous to the S1 reference point in LTE)). It will be appreciated that N1 communication are routed transparently via the RAN 5.

[0045] Each UPF 11 is connected to an external data network 20 (e.g., an IP network such as the internet) via an appropriate reference point (e.g., an N6 reference point) for communication of the user data. The AMF 10-1 performs mobility management related functions, maintains the NAS connection with each UE 3 and manages UE registration. The AMF 10-1 is also responsible for managing paging. The AMF 10-1 receives user information sent through the network and forwards the information to the SMF 10-2.

[0046] The SMF 10-2 is connected to the AMF 10-1 via an appropriate reference point (e.g., N11 reference point). The SMF 10-2 provides session management functionality (that formed part of MME functionality in LTE) and additionally combines some control plane functions (provided by the serving gateway and packet data network gateway in LTE). The SMF 10-2 uses user information provided via the AMF 10-1 to determine what session manager would be best assigned to the user. The SMF 10-2 may be considered effectively to be a gateway from the user plane to the control plane of the network. The SMF 10-2 also allocates IP addresses to each UE 3.

[0047] Each base station 5A is also configured for transmission of, and the UEs 3 are configured for the reception of, control information and user data via a number of downlink (DL) physical channels and for transmission of a number of physical signals. The DL physical channels correspond to resource elements (REs) carrying information originated from a higher layer, and the DL physical signals are used in the physical layer and correspond to REs which do not carry information originated from a higher layer.

[0048] The DL physical channels may include, for example, a physical downlink shared channel (PDSCH), a physical broadcast channel (PBCH), and a physical downlink control channel (PDCCH). The PDSCH carries data sharing the PDSCH's capacity on a time and frequency basis. The PDSCH can carry a variety of items of data including, for example, user data, UE-specific higher layer control messages mapped down from higher channels, system information blocks (SIBs), and paging. The PDCCH carries downlink control information (DCI) for supporting a number of functions including, for example, scheduling the downlink transmissions on the PDSCH and also the uplink data transmissions on a physical uplink shared channel (PUSCH). The PBCH provides UEs 3 with the Master Information Block (MIB). It also, in conjunction with the PDCCH, supports the synchronisation of time and frequency, which aids cell acquisition, selection and re-selection.

[0049] The DL physical signals may include, for example, signals that do not carry any data, such as, for example, reference signals (RSs) and synchronization signals (SSs). A reference signal (sometimes known as a pilot signal) is a signal with a predefined special waveform known to both the UE 3 and the base station 5A of the corresponding RAN 5. The reference signals may include, for example, cell specific reference signals, UE-specific reference signal (UE-RS), downlink demodulation signals (DMRS), and channel state information reference signal (CSI-RS).

[0050] Similarly, the UEs 3 are configured for transmission of, and the base station 5A of the corresponding RAN 5 is configured for the reception of, control information and user data via a number of uplink (UL) physical channels corresponding to REs carrying information originated from a higher layer, and UL physical signals which are used in the physical layer and correspond to REs which do not carry information originated from a higher layer. The physical channels may include, for example, the PUSCH, a physical uplink control channel (PUCCH), and / or a physical random-access channel (PRACH). The UL physical signals may include, for example, demodulation reference signals (DMRS) for an UL control / data signal, and / or sounding reference signals (SRS) used for UL channel measurement.

[0051] The UEs 3 and each base station 5A of a corresponding RAN 5 are mutually configured for performing a random-access channel (RACH) procedure for the UEs 3 to access the network. Specifically, on detection and selection of a cell (and / or a beam in the case of 5G) a UE 3 is able to attempt access to that cell and / or beam using an initial radio resource control (RRC) connection setup procedure comprising a random-access procedure with the corresponding RAN 5.

[0052] Prior to attempting initial access, the UE 3 chooses random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the base station 5A of the RAN 5 over a physical random-access channel (PRACH) for initiating the process to obtain synchronization in the uplink (UL). In response, the base station 5A responds with a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and includes: a timing-alignment (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a physical uplink shared channel (PUSCH); a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; a modulation and coding scheme (MCS) field from which the UE can determine the MCS for the PUSCH transmission; and a transmit power control (TPC) command value for setting the power of the PUSCH transmission. The UE 3 then sends a third message ('Msg3') to the base station 5A over a physical uplink shared channel (PUSCH) based on the information in the RAR. The specific message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random-access procedure is being used. In the example of initial RRC connection setup, however, Msg3 typically comprises an RRC Setup request or similar message carrying a temporary randomly generated UE identifier. The base station 5A responds with a fourth message ('Msg4') which carries the randomly generated UE identifier received in Msg3 for contention purposes to resolve any collisions between different UEs 3 using the same preamble sequence. When successful, Msg4 also transfers the UE 3 to a connected state.

[0053] While a four-step contention-based RACH procedure is described it will be appreciated that a UE 3 and each base station 5A of a corresponding RAN 5 may also perform a non-contention based (or 'contention free') procedure in which a dedicated preamble is assigned by each base station 5A to the UE 3. Moreover, the UE 3 and each base station 5A of a corresponding RAN 5 may perform a two-step RACH procedure.

[0054] It will be appreciated that while the UE 3 can trigger initiation of the RACH procedure itself (e.g., when the UE 3 needs to connect to the network), initiation of the RACH procedure may be by the network. For example, a RACH procedure may be initiated via a message sent via downlink control information (DCI) with an appropriate DCI format (e.g., 1_0) in a physical downlink control channel (PDCCH) - such a message is commonly known as a PDCCH order. A RACH procedure may be also initiated by each base station 5A of a corresponding RAN 5 when handover is required (e.g., using a handover command message, or the like).

[0055] <NTN RAN Architecture> 　　Figs. 2A to 2C each respectively illustrate a possible architecture of an NTN RAN 5-1 that may be used.

[0056] The architecture of Fig. 2A may be referred to as a 'transparent satellite' based RAN architecture. In this architecture, the base station 5A-1 is a terrestrially located base station that sends and receives communications respectively destined for and originating from the UEs 3 via a (terrestrially located) gateway 5B-1 and via a non-terrestrial space (or air) borne platform 5C-1 that has no base station functionality. The non-terrestrial space (or air) borne platform 5C-1 relays these communications to and from the UEs 3 in one or more cells operated by the base station 5A-1, and from and to the gateway 5B-1 as required. The non-terrestrial space (or air) borne platform 5C-1 relays these communications transparently without on-board processing them in effect acting as a so-called 'bent-pipe'. In this implementation, the feeder link between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 effectively acts as part of the NR-Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3. Similarly, the service link between the non-terrestrial space (or air) borne platform 5C-1 and one or more UEs 3 effectively acts as another part of the NR-Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3. The base station's communication link with the core network 7 (e.g., for signalling over the N2, N3 interface / reference point etc.) is provided solely terrestrially.

[0057] The architecture of Fig. 2B may be referred to as a 'regenerative satellite' based RAN architecture (i.e., in which the satellite performs on board processing of the payload being communicated between the UE 3 and the core network 7). In this architecture, the base station 5A-1 is a base station 5A-1 of a distributed type having a terrestrially located central unit (CU) 5ACU-1 and a distributed unit (DU) 5ADU-1 provided on-board the non-terrestrial space (or air) borne platform 5C-1. The terrestrially located CU 5ACU-1 performs some of the (typically higher layer) functionality of the base station 5A-1 whereas the non-terrestrially located DU 5ADU-1 performs other (typically lower layer) functionality of the base station 5A-1. The terrestrially located CU 5ACU-1 communicates with the non-terrestrially located DU 5ADU-1 via the gateway 5B-1 and an F1 interface implemented via a satellite radio interface between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 in which the DU 5ADU-1 is provided.

[0058] The non-terrestrial space (or air) borne platform 5C-1 transmits communications destined for and originating from the UEs 3 in one or more cells operated by the base station 5A-1, and from and to the gateway 5B-1 as required. However, in this implementation lower layer processing of communication respectively destined for and originating from the UEs 3 is performed on-board the non-terrestrial space (or air) borne platform 5C-1 by the DU 5ADU-1 and higher layer processing of that communication respectively destined for and originating from the UEs 3 is performed by the terrestrially located CU 5ACU-1.

[0059] Accordingly, in this implementation, the feeder link between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 effectively acts as the F1 interface (or reference point) between the CU 5ACU-1 and the DU 5ADU-1 of the base station 5A-1. The service link between the non-terrestrial space (or air) borne platform 5C-1 and one or more UEs 3, on the other hand, effectively acts as the NR-Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3. The base station's communication link with the core network 7 (e.g., for signalling over the N2, N3 interface / reference point etc.) is provided solely terrestrially.

[0060] The architecture of Fig. 2C may also be referred to as a 'regenerative satellite' based RAN architecture (i.e., in which the satellite performs on board processing of the payload being communicated between the UE 3 and the core network 7). In this architecture, the base station 5A-1 is provided on-board the non-terrestrial space (or air) borne platform 5C-1. The base station 5A-1 on board the non-terrestrial space (or air) borne platform 5C-1 transmits communications destined for and originating from the UEs 3 in one or more cells operated by the base station 5A-1, and from and to the core network 7 via the gateway 5B-1 as required. However, in this implementation, processing of communication respectively destined for and originating from the UEs 3 is performed on-board the non-terrestrial space (or air) borne platform 5C-1 by the base station 5A-1.

[0061] Accordingly, in this implementation, the feeder link between the gateway 5B-1 and the non-terrestrial space (or air) borne platform 5C-1 effectively acts as part of the N2 / N3 interfaces (or reference points) between the base station 5A-1 and the core network 7. The base station's communication link with the core network 7 (e.g., for signalling over the N2, N3 interface / reference point etc.) is thus provided partly via the feeder link and partly terrestrially. The service link between the non-terrestrial space (or air) borne platform 5C-1 and one or more UEs 3, on the other hand, effectively acts as the NR-Uu interface (or reference point) between the base station 5A-1 and one or more UEs 3.

[0062] The base station 5A-1 thus controls one or more associated cells via the non-terrestrial space (or air) borne platform 5C-1. It will be appreciated that the base station 5A-1 may be configured to support 4G, 5G, 6G and / or later generations, and / or any other 3GPP or non-3GPP communication protocols.

[0063] <NTN RAN> 　　Fig. 3 illustrate schematically one NTN RAN 5-1 architecture that may be used in the communication system 1 of Fig. 1.

[0064] Fig. 3 depict an NTN RAN 5-1 whose satellite is in regenerative mode as shown in Fig. 2C. It will nevertheless be appreciated that the NTN RAN 5-1 depicted is by way of example only, and that the NTN RAN 5-1 may comprise a satellite in regenerative mode as shown in Fig. 2B, or alternative transparent (bent pipe) mode as shown in Fig. 2A.

[0065] As seen in Fig. 3, the NTN RAN 5-1 comprises a base station 5A-1 operating one or more associated cells 9, a gateway 5B-1, and a non-terrestrial space (or air) borne platform 5C-1 (e.g. comprising one or more satellites and / or airborne vehicles), which may be referred to generally as a 'satellite' 5C-1 for simplicity. Communication via the NTN RAN 5-1 is routed through the core network 7 and external data network 20 (e.g. via the N6 interface / reference point).

[0066] The NTN RAN 5-1 controls a number of directional satellite beams via which associated NTN cells 9 may be provided. Specifically, each satellite beam has an associated footprint on the surface of the Earth which forms an NTN cell, or part of an NTN cell. Each NTN cell has an associated Physical Cell Identifier (PCI). The satellite beam footprints may be moving as the space (or air) borne platform 5C-1 is travelling along its orbit (e.g., as illustrated by the arrows 'A' in Fig. 3). Alternatively, the satellite beam footprint may be earth fixed, in which case an appropriate satellite beam pointing mechanism (mechanical or electronic steering) may be used to compensate for the movement of the non-terrestrial space (or air) borne platform 5C-1. Satellite beams and satellites are not considered visible from a UE perspective in NTN. This does not, however, preclude differentiating at the public land mobile network (PLMN) level the type of network (e.g., NTN vs. TN).

[0067] The base station 5A-1 of the NTN RAN 5-1 is configured to provide ephemeris data for the non-terrestrial space (or air) borne platform 5C-1, to the UEs 3, to help UEs 3 perform measurement and cell selection / reselection and for supporting initial access. This ephemeris data may comprise information on orbital information such as information on orbital plane level or on satellite level and / or information (e.g., a pointer or index) from which more detailed ephemeris data stored in the UE 3 (e.g. in a universal subscriber identity module, 'USIM') may be obtained. At least some of this ephemeris information may, for example, be provided in system information and / or may be provided using UE specific (dedicated) signalling such as RRC signalling.

[0068] Specifically, the base station 5A-1 is able to provide satellite assistance information for the satellite as part of a dedicated system information block (SIB) that is broadcast to UEs 3 in a corresponding cell 9 of the NTN RAN 5-1 (for 5G NTN this may, for example, be SIB19 but for future generations it may be provided in another SIB or in a different way). The satellite assistance information may include, for example, information identifying at least one associated NTN configuration (e.g., as part of an NTN-Config IE or the like). The NTN configuration includes parameters for assisting the UE 3 to access the network using NTN access (e.g., ephemeris data, common timing alignment parameters, a scheduling (e.g., koffset), validity duration for uplink synchronisation information, and an epoch time (a reference time for which assistance information is valid)).

[0069] The satellite assistance information may include, for example, an indication of a time information on when a cell provided via NTN quasi-Earth fixed system is going to stop serving the area it is currently covering (e.g., in a t-Service IE). This may be indicated, for example, as a time in multiples of 10ms after 00:00:00 on a Gregorian calendar date of 1 January 1900 (midnight between Sunday, December 31, 1899, and Monday, January 1, 1900). The exact stop time may be between the time indicated by the value of this field minus 1 and the time indicated by the value of this field.

[0070] With the help of this ephemeris data, a UE 3 may search for the first NTN cell it can connect to. After detecting a synchronization signal / physical broadcast channel (PBCH) block (SSB) of a cell 9 broadcasted via a non-terrestrial space (or air) borne platform 5C-1, the UE 3 may be able to read initial system information of that cell which may contain further ephemeris information relating to the exact location of the cell (and / or to the satellite broadcasting the cell). This ephemeris information may be given relative to information relating, for example, to the orbital plane that the UE 3 may already have obtained. The accuracy of the prediction of a satellite orbit or the satellite position can decrease with time and so, to help ensure accuracy, the ephemeris data provided to the UE 3 is updated (a)periodically.

[0071] The same PCI may be used for several satellite beams, or there may be one PCI per satellite beam. A satellite beam can consist of one or more SSB beams with one cell (PCI) having a maximum of L SSB beams, where L can typically be 4, 8 or 64 depending on the band. During initial access, the UEs 3 perform cell search based on SSBs where each SSB is transmitted in a different respective beam. Each SSB comprises a primary synchronization signal (PSS), secondary synchronization signal (SSS), and physical broadcast channel (PBCH). As the SSB carries synchronization signals (SSs) / PBCH (SS / PBCH) transmissions it is sometimes referred to as an SS / PBCH block.

[0072] As those skilled in the art will understand, while the disclosure is described in the context of an NTN based RAN 5 / base station 5A, many of the technical features described are generally applicable to, and can be implemented in, any RAN / base station of a more conventional (non-NTN) based communication system.

[0073] <Early Data Transmission (EDT)> 　　The UEs 3 and RANs 5 of the communication system 1 are configured to support conventional EDT using a four-step (or two-step) contention-based RACH (CBRA) to allow UL data transmission of infrequent and small amounts of data followed by an optional DL data transmission (e.g., to help reduce latency and power consumption at a UE 3).

[0074] Fig. 4 is a simplified sequence diagram illustrating an example early data transmission procedure using a contention-based four-step RACH procedure that may be implemented in the communication system 1 of Fig. 1.

[0075] As shown in Fig. 4, there is provided the UE 3, and a RAN 5 which provides a serving cell over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst the RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5 (as seen in Fig. 1).

[0076] At the outset, the UE 3 is in an RRC idle state. For example, the UE 3 may start in an RRC idle state when it first camps onto a cell provided by the RAN 5 (e.g., immediately after the UE 3 has been powered up, or after an appropriate cell reselection procedure). Whilst in an RRC idle state, the UE 3 is usually unable to transfer application data, and the like, to the RAN 5.

[0077] At step S402, the UE 3 may have data for transmission to the RAN 5. In response to having data for transmission to the RAN 5, the UE 3 may trigger an appropriate RACH procedure so as to enter an RRC connected state.

[0078] At step S404 the UE 3 chooses random access resources (including, for example, a preamble) to use to initiate the RACH procedure. The UE 3 sends the selected preamble (e.g., in 'Msg1') to the RAN 5 over a PRACH for initiating the process to obtain synchronization in the UL.

[0079] In response, at step S406, the RAN 5 sends a random-access response (RAR) (or 'Msg2'). The RAR indicates reception of the preamble and may include, for example: a timing advance (TA) command for adjusting the transmission timing of the UE 3 based on the timing of the received preamble; an uplink grant field indicating the resources to be used in the uplink for a PUSCH; a frequency hopping flag to indicate whether the UE 3 is to transmit on the PUSCH with or without frequency; an MCS field from which the UE 3 can determine the MCS for the PUSCH transmission; and / or a TPC command value for setting the power of the PUSCH transmission.

[0080] The UE 3 then sends a third message ('Msg3') at step S408 to the network over a PUSCH based on the information in the RAR. The nature of message sent by the UE 3 in this step, and the content of the message, depends on the context in which the random-access procedure is being used. In the example shown in Fig. 4, which is in the context of EDT, Msg3 may typically comprise an RRC early data request (e.g., for early transmission of control-plane (CP) data - referred to as 'CP-EDT') or an RRC connection resume request (e.g., for early transmission of user-plane (UP) data - referred to as 'UP-EDT'), or a similar message. The RRC message sent at S408 may carry (at least part of) the UL data to be transmitted - for example as an uplink NAS protocol data unit (PDU) included in that RRC message for CP-EDT or as uplink data multiplexed with that RRC message for UP-EDT. A cause value may also be included to indicate a cause for the request.

[0081] The RAN 5 responds at step S410 with a fourth message ('Msg4'). The fourth message, in the context of CP-EDT, may comprise either an RRC early data complete message, or an RRC connection setup message as appropriate. The fourth message, in the context of UP-EDT, may comprise either an RRC connection release message, or an RRC connection resume message as appropriate. Additionally, in the case of EDT, Msg4 may also include a DL NAS PDU (for CP-EDT) or be multiplexed with DL data (for UP-EDT) that the RAN 5 wishes to send to the UE 3.

[0082] Where Msg4 comprises an RRC early data complete message or an RRC connection release message (Option A) - for example in the case where the UE 3 and the RAN 5 have no further early data transmissions to send to one another - the UE 3 may release its RRC connection with the RAN 5 and re-enter RRC Idle state at step S412a. Alternatively, where Msg4 comprises an RRC connection setup message or an RRC connection resume message (Option B) - for example in the case where the UE 3 and the RAN 5 have further data transmissions to send to one another - the UE 3 may send, at step S412b, a fifth message ('Msg5') to the RAN 5 which includes an RRC connection setup complete message (for CP-EDT), an RRC connection resume complete message (for UP-EDT), or a similar message. The RRC message sent at S412b may carry (at least part of) any further UL data to be transmitted - for example as an uplink NAS protocol data unit (PDU) included in that RRC message (for CP-EDT) or as uplink data multiplexed with that RRC message (for UP-EDT).

[0083] At step S414b, the UE 3, having entered RRC connected mode with the RAN 5, may exchange further data with the RAN 5. Similarly at step S416b, the RAN 5 may exchange further data with the UE 3.

[0084] EDT procedures such as that described above with reference to Fig. 4 allow data transmission of small amounts of infrequent data to be transmitted between the UE 3 and the RAN 5 while the UE 3 is in an RRC idle state, as the UL data from the UE 3 to the RAN 5, and the DL data sent from the RAN 5 to the UE 3 are both sent prior to the UE 3 completing a transition from an RRC idle state to an RRC connected state. Furthermore, where the EDT is a single round, and no further data transmission is required, the UE 3 may remain in an RRC idle state and never need to enter an RRC connected state. Thus, EDT procedures such as that described above provide reductions in latency and power consumption in the communication system 1.

[0085] In an effort to provide further reductions in latency and power consumption in the communication system 1 beyond those afforded by the implementation of such EDT procedures, the communication system 1 may also implement one or more procedures for using preconfigured grants of one or more UL resources (i.e., pre-configured UL resources (PURs)) to support EDT, as will now be described, by way of example only, with reference to Fig. 5.

[0086] <Preconfigured Uplink Resources (PUR)-based EDTs> 　　Fig. 5 is a simplified sequence diagram illustrating an example PUR-based EDT procedure that may be implemented in the communication system 1 of Fig. 1.

[0087] As shown in Fig. 5, there is provided a UE 3 and a RAN 5 which provides a serving cell over which the UE 3 and the RAN 5 can communicate. It will be appreciated that, in the following procedure, whilst the RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5 (as seen in Fig. 1).

[0088] While in an RRC connected state, the UE 3 may request to be configured with a PUR at step S502 via an appropriate resource configuration request message, or the like (e.g., a PUR Configuration Request message). That resource configuration request message may, by way of example only, include appropriate information to indicate to the RAN 5 the nature of the PUR with which the UE 3 wishes to be configured. For example, the resource configuration request message may include a number of occurrences (e.g., a number of requested PURs), a periodicity of the requested PURs, time offsets between the requested PURs, transport block sizes (TBS) that the UE 3 can support for early data transmission, and whether the UE 3 wishes to receive RRC-type acknowledgements, or the like, upon reception of early data transmissions by the RAN 5.

[0089] It will be appreciated that the RAN 5 may provide the UE 3 with an appropriate resource configuration message, or the like, to preconfigure an UL resource at the UE 3 (i.e., provide one or more PURs to the UE 3) without being prompted by the UE 3.

[0090] The RAN 5 may, for example, decide to configure a PUR at the UE 3 based on a request from the UE 3 and / or subscription information associated with the UE 3, and / or a local policy of the UE 3. It will be appreciated that the PUR may only be valid in a cell where the configuration was received by the UE 3 from the RAN 5.

[0091] At step S504, the RAN 5 decides to move the UE 3 from an RRC connected state to an RRC idle state. For example, where the RAN 5 determines that there is no further data for exchange between the RAN 5 and the UE 3, the RAN 5 may decide to trigger the UE 3 to transition to an RRC idle state to save signalling overhead and power consumption at the UE 3.

[0092] Having decided to trigger the UE 3 to transition from an RRC connected state to an RRC idle state, the RAN 5 may send, at step S506, an appropriate RRC message, or the like (e.g., an RRC Release Connection message), which may include a PUR configuration that indicates, to the UE 3, one or more PURs that may be used by the UE 3 while it is in an RRC Idle state.

[0093] Sometime later, the UE 3 may have data for transmission to the RAN 5. In response to having data for transmission to the RAN 5, at step S508 the UE 3 may trigger an EDT to the RAN 5 using one or more PURs when (i) upper layers request the establishment or resumption of an RRC Connection between the UE 3 and the RAN 5, (ii) the UE 3 has a valid PUR for transmission, and (iii) a timing advance (TA) validation criteria is met (e.g., a PUR TA timer is not configured, or a PUR TA is configured and is running as confirmed by lower layers).

[0094] Where the upper layers request the establishment or resumption of an RRC Connection between the UE 3 and the RAN 5, and the UE 3 has a valid PUR for transmission, the UE 3, at step S510, transmits the data that it wishes to send to the RAN 5 using one or more configured PURs. For example, the UE 3 may send, using a PUR, an appropriate RRC message, or the like, to resume the RRC connection with the RAN 5 (e.g., an RRC Resume Connection message, or the like).

[0095] Additionally, that appropriate RRC message transmitted to the RAN 5 using the PUR also includes (at least part of) the UL data that the UE 3 wishes to send to the RAN 5. That data may, for example, be multiplexed with the appropriate RRC message.

[0096] The RAN 5 responds at step S512 with an appropriate response message (e.g., an RRC connection release message, or an RRC connection resume message, or the like) Additionally, the appropriate response message may also include DL data that the RAN 5 wishes to send to the UE 3. That data may, for example, be multiplexed into the appropriate response message.

[0097] Following step S512, the PUR-based EDT procedure may continue typically as described above with respect to Option A and Option B in Fig. 4.

[0098] Similarly to the EDT procedure described above with reference to Fig. 4, the PUR-based EDT procedure, such as that described above with reference to Fig. 5, allows data transmission of small amounts of infrequent data to be transmitted between the UE 3 and the RAN 5 while the UE 3 is in an RRC idle mode, as the UL data from the UE 3 to the RAN 5, and the DL data sent from the RAN 5 to the UE 3 are both sent prior to the UE 3 completing its transition from an RRC idle mode to an RRC connected mode.

[0099] PUR-based data EDT procedures also provide reductions in latency and power consumption in the communication system 1 over the EDT procedure shown in Fig. 4, as the transmission of small amounts of infrequent data to the RAN 5 by the UE 3 does not require the UE 3 to perform a full RACH procedure to determine appropriate resources for sending the data.

[0100] PUR-based EDT procedures such as that described above remove the need for the UE 3 to send a Msg1 (RACH preamble message) to the RAN 5 to request the assignment of appropriate UL resources for sending the data. Consequently, the RAN 5 also does not need to send Msg2 (RAR) to the UE 3 to acknowledge a RACH preamble and configure the UL resources. Thus, PUR-based EDT procedures provide a streamlined procedure for the transmission of small amounts of infrequent data.

[0101] <Further EDT Enhancements - Contention Resolution Diversity Slotted Aloha (CRDSA)> 　　The communication system 1 may also implement a diversity slotted Aloha (DSA) / contention resolution diversity slotted Aloha (CRDSA) mechanism to help provide increases in transmission throughput of the message carrying the data (e.g., Msg3) in the context of a CB EDT procedure (e.g., as described above with reference to Fig. 4).

[0102] A summary of a CRDSA technique that may be implemented will now be described, by way of example only, with reference to Fig. 6, which illustrates an example of a CRDSA time-division multiple access (TDMA) RA frame comprising N slots (NSlots) that may be used in the communication system 1. It will be appreciated that, in the following summary, whilst a RAN 5 is referred to in general terms, the operations performed by the RAN 5 will typically be performed by the base station 5A of the RAN 5 (as seen in Fig. 1).

[0103] In the example CRDSA of Fig. 6, a number of data (e.g., Msg3) 'packets' are transmitted by different UEs 3 in the slots of the frame are sent during the frame. In the illustrated example these packets are numbered #1 to #6 with replica packets from the same UE 3 having the same number. As shown in Fig. 6, each packet is replicated at least once meaning that there are at least two 'replica' packets for each data transmission (although it will be appreciated that there may be any suitable number of replicas (NReplica)). These replica packets are transmitted in randomly selected slots of the TDMA RA frame. To assist with contention resolution, each packet may contain (e.g., in a payload header), information about the location of the replicas within the allocated TDMA RA frame. Naturally, some of the packets transmitted from different UEs 3 will be sent in the same slot and will thus collide - hence causing associated interference.

[0104] Once received by the RAN 5, the complete frame is sampled and stored. By using simple, yet efficient, decision-directed interference cancellation techniques, the less-interfered or non-interfered packets are initially demodulated (e.g., packet #3 in the fifth slot in Fig. 6), and the interference generated by their replicas on other slots is cancelled (e.g., the effect of packet #3 is removed from the fourth slot) thereby allowing the detection of packet #2 in the fourth slot. By performing iterative processing of the TDMA RA frame, most of the initial collisions can be resolved efficiently.

[0105] For example, in the scenario shown in Fig. 6, following detection of packet #2, the interference generated by packet #2 replicas on other slots may be cancelled (e.g., the effect of packet #2 is removed from the first slot) thereby allowing the detection of packet #1 in the first slot. Following detection of the packet #1, the interference generated by the packet #1 replicas on other slots may be cancelled (e.g., the effect of packet #1 is removed from the last slot depicted) thereby allowing the detection of the packet #6. Following detection of the packet #6, the interference generated by the packet #6 replicas on other slots may be cancelled; however, as shown in Fig. 6, packets #5 and #4 are in the same slots, giving rise to data packet collision. In this scenario, a forward error correction (FEC) procedure may be used by the RAN 5 to decode those colliding packets.

[0106] While Fig. 6 relates to CRDSA as implemented using a TDMA RA frame, it will be appreciated that with appropriate adaptations the same CRDSA technique can also be implemented using a frequency-division multiple access (FDMA) RA frame.

[0107] Nevertheless, while the implementation of CRDSA in the EDT procedure of Fig. 4 improves EDT throughput (e.g., through replicas of Msg3), it will be appreciated that as the number of EDTs increases in the communication system 1, the occurrence of collision-less packets (e.g., packet #3 in Fig. 6) may drop off sharply to the point where no such collision-less packets occur. In that scenario, it will be appreciated that the efficiencies afforded by CRDSA in the EDT procedure may be lost as FEC procedures will need to be performed for every packet received by the RAN 5 to resolve contention between the packets.

[0108] In light of the issues described above with respect to the implementation of CRDSA in the EDT procedure, other enhancements to the EDT procedure may be required to maintain high levels of efficiency in the communication system 1 as the number of EDTs scheduled to occur in the communication system 1 increases.

[0109] <Support for CB Data Transmission> 　　Beneficially, the communication system 1 supports (RACH-less) CB data transmission (without requiring Msg1 / Msg2 transmission). Specifically, the communication system 1 support a CB data transmission procedure in which common (i.e., contention-based) UL resources are (pre)configured for EDTs from a plurality of different UEs 3. It will be appreciated that the configured common resources may be referred to in different ways, for example as a common / shared PUSCH common / shared PURs, and / or the like.

[0110] It will be appreciated that the implementation and use of such common / shared resources for EDTs in the communication system 1 is non-trivial. In particular, appropriate procedures and mechanisms are needed to configure and assign those common / shared resources in the communication system 1 which take account of the possibility of resource contention-based issues.

[0111] Various procedures and techniques for implementing common / shared resources for (early) data transmissions in the communication system 1 will now be described, by way of example only, with reference to Fig. 7 to 15.

[0112] <Contention-based (CB) Data Transmissions> 　　Fig. 7 illustrates a simplified sequence diagram of an example CB data transmission procedure using common / shared UL resources that may be implemented in the communication system of Fig. 1. It will be appreciated that, in the following procedure, whilst a RAN 5 is referred to in general terms, communication performed by the RAN 5 with the UE 3 will typically be performed by the base station 5A of the RAN 5 (as seen in Fig. 1).

[0113] As shown in Fig. 7, there is provided the UE 3, and the RAN 5 which provides a serving cell over which the UE 3 and the RAN 5 can communicate. Although not shown, the UE 3 may, for example, be in an RRC idle state. For example, the UE 3 may start in an RRC idle state when it first camps onto a cell provided by the RAN 5 (e.g., immediately after the UE 3 has been powered up, or after an appropriate cell reselection procedure).

[0114] At step S702, the RAN 5 sends appropriate system information (SI) to the UE 3 necessary for the UE 3 to camp onto a cell. For example, the RAN 5 may send an appropriate system information block (SIB) message (e.g., SIB1) to provide the UE 3 with the minimum information for the UE 3 to perform an initial attachment procedure onto a cell provided by the RAN 5.

[0115] Additionally, the SIB message sent by the RAN 5 to the UE 3 at step S702 may include an appropriate resource configuration to configure common / shared UL resources that the UE 3 may use for the transmission of (early) data transmissions to the RAN 5. For example, the SIB message may include a resource configuration to configure one or more common / shared PUSCH resources (or PURs) for use by the UE 3 for the transmission of (early) data transmissions.

[0116] Additionally, where the SIB message includes a resource configuration to configure common / shared PUSCH resources (or PURs) for use by the UE 3 for the transmission of (early) data transmissions, that resource configuration may include an indication of the periodicity of those common / shared PUSCH resources (or PURs); an appropriate offset associated with those common / shared PUSCH resources (or PURs); an indication of the allocation of those common / shared PUSCH resources (or PURs) in a time and / or frequency domain; an indication of a number of common / shared PUSCH (or PURs) resource occasions in the time and / or frequency domain; an indication of a modulation and coding scheme (MCS) used with those common / shared PUSCH resources (or PURs); a transport block size (TBS) that is supported by those common / shared PUSCH resources (or PURs); and / or an indication of a mapping between SSBs and PUSCH resource (or PUR) occasions of the common / shared PUSCH resources (or PURs). Additionally, where appropriate, the resource configuration may include an indication of an orthogonal cover code (OCC) configuration, or the like.

[0117] Additionally, the resource configuration included in the SIB transmitted at step S702 may include an indication of possible conditions upon which use of the common / shared PUSCH resources (or PURs) is based. By way of example only, possible conditions of using the common / shared PUSCH resources (or PURs) may include conditions associated with the size of the data to be transmitted on the common / shared PUSCH resources (or PURs); and / or an RSRP associated with the PUSCH; and / or a type of data to be transmitted on the common / shared PUSCH resources (or PURs).

[0118] For example, the resource configuration included in the SIB transmitted at step S702 may configure one or more conditions for using the shared PUSCH resources (although it will be appreciated that all or a subset of the conditions may be predefined at the UE 3). The configured (or predefined) conditions may define that the use of common / shared PUSCH resources (or PURs) is conditional on the size of the data to be transmitted on those common / shared PUSCH resources (or PURs) being equal to, or less than, a specified threshold (e.g., a threshold configured in the resource configuration, or which is pre-configured at the UE 3). As an example only, the threshold may be equal to a TBS supported by the common / shared PUSCH resources (or PURs), or alternatively the threshold may be equal to some other configured value (e.g., in the resource configuration, or hardcoded at the UE 3).

[0119] In another example, the configured (or predefined) conditions may (alternatively or additionally) define that the use of the common / shared PUSCH resources (or PURs) is conditional on the size of the data to be transmitted on those common / shared PUSCH resources (or PURs) being within a configured range. In another example, the configured (or predefined) conditions may define that the use of the common / shared PUSCH resources (or PURs) is conditional on an RSRP of the PUSCH being higher than a first configured threshold (e.g., higher than a minimum RSRP value necessary to decode the data transmitted on the common / shared PUSCH resources (or PURs)).

[0120] In another example, the configured (or predefined) conditions may (alternatively or additionally) define that the use of the common / shared PUSCH resources (or PURs) is conditional on an RSRP of the PUSCH being within a configured window i.e., the RSRP of the PUSCH is greater than a first configured threshold and less than a second configured threshold (e.g., the RSRP of the PUSCH may be configured within a range necessary to decode the data transmitted on the common / shared PUSCH resources and / or may be within a range necessary to control a data load on the PUSCH resources (or PURs)).

[0121] In yet another example, the configured (or predefined) conditions may (alternatively or additionally) define that the use of the common / shared PUSCH resources (or PURs) is conditional on the data to be transmitted on those common / shared PUSCH resources (or PURs) being control plane (CP)-data only; or the data to be transmitted being user place (UP)-data from a given data radio bearer (or bearers) (DRBs); or the data to be transmitted being CP-cellular internet of things (CIoT)-data; or the data to be transmitted being UP-CIoT-data.

[0122] Additionally, the resource configuration included in the SIB transmitted at step S702 may include an indication of an appropriate configuration associated with response monitoring e.g., an appropriate configuration to indicate to UE 3 how the RAN 5 will respond / acknowledge data received on common / shared PUSCH resources (or PURs). The UE 3 may for example, based on the configuration associated with response monitoring, be able to calculate a radio-network temporary ID (RNTI) that will be used to respond to the data transmission on a given shared PUSCH resource (or PUR) that the UE 3 used for the data transmission. For example, the resource configuration included in the SIB transmitted at step S702 may include appropriate information (e.g., one or more RNTIs, search space information, and the like) to assist the UE 3 with monitoring for response messages from the RAN 5. It will be appreciated that the resource configuration information may not include an actual RNTI associated with each common / shared PUSCH resource (or PUR). Instead the system information may include information from which the RNTI associated with each common / shared PUSCH resource (or PUR) may be determined. The UE 3 may, based on the information, be able to calculate an RNTI that will be used to respond to the data transmission based on, for example, the shared PUSCH resource that the UE 3 used for the data transmission.

[0123] It will be appreciated that where the resource configuration included in the SIB transmitted at step S702 includes RNTIs, and the like, to assist the UE 3 with monitoring for response messages from the RAN 5, the RAN 5 will need to determine appropriate RNTIs and map those RNTIs to the common / shared PUSCH resources (or PURs) in a manner that enables the UE 3 to correctly monitor for, and identify, response messages from the RAN 5 associated with its corresponding data transmissions. A more detailed explanation of how the RAN 5 may determine appropriate RNTIs and map those RNTIs to the common / shared PUSCH resources (or PUR) will be described in more detail later.

[0124] Additionally, the resource configuration included in the SIB transmitted at step S702 may configure the common / shared PUSCH resources (or PURs) with different TBSs. For example, in an effort to reduce bit padding waste in transport blocks used for (early) data transmissions, as well as to minimise contention between the common / shared PUSCH resources (or PURs), those common / shared PUSCH resources (or PURs) may each be configured with a different TBS in the resource configuration.

[0125] For example, the RAN 5, when preparing the SIB for transmission at step S702, may decide to assign different TBSs for the common / shared PUSCH resources (or PURs) that it wishes to configure at the UE 3 via the resource configuration included in the SIB. The RAN 5 may, for example, decide how many common / shared PUSCH resources (or PURs) are configured for each possible TBS supported. By way of example only, the RAN 5 may configure a first number (X1) of common / shared PUSCH resources (or PURs) with a first TBS (TBSA), a second number (X2) of common / shared PUSCH resources (or PURs) with a second TBS (TBSB), a third number (X3) of common / shared PUSCH resources (or PURs) with a third TBS (TBSC), etc. in each time period.

[0126] At step S704 the UE 3 prepares to send (early) data transmissions to the RAN 5 (e.g., a UL data transmission) using one or more of the configured common / shared PUSCH resources (or PURs) when one or more initiation conditions are met. For example, upon arrival of uplink data at the UE 3 for transmission to the RAN 5, if there is no valid dedicated radio resource configured at the UE 3 for the transmission of that data (e.g., a scheduled resource (SR), a resource indicated to the UE 3 by a dedicated grant (DR), a resource indicated to the UE 3 by a configured grant (CG), a PUR, or the like), then the UE 3 may use the common / shared PUSCH resources (or common / shared PURs) indicated to the UE 3 in the SIB sent to the UE 3 at step S702 subject to any further conditions for using those common / shared PUSCH resources (or PURs) being met.

[0127] Specifically, the common / shared PUSCH resources (or PURs) may only be used by the UE 3 if all the conditions for using those common / shared PUSCH resources (or PURs) indicated in the resource configuration in the SIB sent to the UE 3 at step S702 (and / or predefined at the UE 3) are met. For example, where the resource configuration in the SIB sent to the UE 3 at step S702 indicates (as described in detail above) conditions associated with e.g., the size of the data to be transmitted on the common / shared PUSCH resources (or PURs); and / or a RSRP associated with the PUSCH; and / or a type of data to be transmitted on the common / shared PUSCH resources (or PURs), the UE 3 may only send the data in those common / shared PUSCH resources (or PURs) when every indicated condition is met.

[0128] If the UE 3 determines that the conditions for using those common / shared PUSCH resources (or PURs) indicated in the resource configuration in the SIB sent to the UE 3 at step S702 are not met, then the UE 3 may instead perform a typical initial RACH procedure to receive an indication of appropriate resources from the RAN 5 for the transmission of the data.

[0129] Where the UE 3 decides to use the common / shared PUSCH resources (or PURs) indicated to the UE 3 in the SIB sent to the UE 3 at step S702, and the conditions for using those common / shared PUSCH resources (or PURs) indicated in the resource configuration in the SIB sent to the UE 3 at step S702 (and / or predefined at the UE 3) are met, the UE 3 may select one (or more) of the common / shared PUSCH resources (or PURs) for use in transmission of the data.

[0130] For example, in the scenario where the resource configuration in the SIB sent to the UE 3 at step S702 assigns different TBSs to different common / shared PUSCH resources (or PURs), the UE 3 may first determine a TBS that is needed to accommodate the data to be transmitted to the RAN 5 (e.g., TBSB). Based on the determined TBS that is needed to accommodate the data to be transmitted to the RAN 5, the UE 3 may then subsequently randomly select one of the common / shared PUSCH resources (or PURs) indicated in the resource configuration in the SIB sent to the UE 3 at step S702 that has the same (or the most appropriate) TBS to facilitate a reduction in bit padding waste.

[0131] At step S706 the UE 3 sends an (early) data transmission to the RAN 5 using the selected common / shared PUSCH resources (or PURs) at step S704.

[0132] Following the (early) data transmission at step S706, the UE 3 may begin to monitor for a response message from the RAN 5 that acknowledges receipt of the data and indicates its successful decoding. For example, the UE 3 may begin to monitor a PDCCH and / or PDSCH for a response message, and in particular the PDCCH and / or PDSCH addressed by the RNTI indicated to the UE 3 in the resource configuration included in the SIB transmitted at step S702.

[0133] From the perspective of the RAN 5, having received an (early) data transmission at step S706, the RAN 5 may process (e.g., decode) that data transmission and respond to the UE 3 with an appropriate response message (e.g., a data transmission response (acknowledgement) message, or the like) at step S708 if the RAN 5 was able to successfully decode the data transmission.

[0134] It will be appreciated that the response message sent at step S708 may take the form of a MAC packet data unit (PDU) that is appropriately packaged and sent to the UE 3 over a PDCCH or PDSCH as appropriate.

[0135] In the case where the RAN 5 is able to successfully decode the data transmitted to it by the UE 3, the response message sent by the RAN 5 to the UE 3 to acknowledge successful receipt of the data may also include appropriate contention resolution IDs and / or appropriate contention resolution information to enable the UE 3 to identify that the response message sent to the UE 3 at step S708 corresponds to (i.e., is an acknowledgement of) the specific uplink data that the UE 3 sent to the RAN 5 on the selected common / shared PUSCH resource (or PUR) at step S706.

[0136] For example, the response message sent to the UE 3 at step S708 may include an X-bit random ID that the UE 3 pre-emptively included in the data transmission it sent to the RAN 5 at step S706. In other words, when the UE 3 prepares the data transmission that it plans to send to the RAN 5 at step S706 on a common / shared PUSCH resource (or PUR), it may include a random ID in that data transmission. The RAN 5 may then subsequently echo back that random ID to the UE 3 in an appropriate response message to indicate to the UE 3 that the response message acknowledges that data transmission sent at step S706. For example, the RAN 5 may include the random ID in a header of the MAC PDU that is appropriately packaged and sent to the UE 3 over a PDCCH or PDSCH as appropriate.

[0137] In another example, the response message may take the form of DCI. In this scenario, the response message (i.e., DCI) sent to the UE 3 at step S708 may include an X-bit random ID that the UE 3 pre-emptively included in the data transmission it sent to the RAN 5 at step S706. In other words, when the UE 3 prepares the data transmission that it plans to send to the RAN 5 at step S706 on a common / shared PUSCH resource (or PUR), it may include a random ID in that data transmission. The RAN 5 may then subsequently echo back that random ID to the UE 3 in an appropriate response message (i.e., DCI) to indicate to the UE 3 that the response message acknowledges that data transmission sent at step S706.

[0138] In yet another example, the response message sent to the UE 3 at step S708 may include a portion of the data that was transmitted to the RAN 5 by the UE 3 at step S706. For example, a first number of bits and / or a last number of bits of the data transmitted to the RAN 5 by the UE 3 may be included in the response message and echoed back to the UE 3 at step S708.

[0139] It will be appreciated that based on the random ID or the bits of echoed data included in the response message sent by the RAN 5, the UE 3 can determine, upon receiving the response message, whether the received response message corresponds to (i.e., acknowledges) one of the data transmissions it made to the UE 3. Where the random ID or the bits of echoed data included in the response message received at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0140] On the other hand, if the RAN 5 was unable to successfully decode the data transmission (e.g., because of a contention resolution issue, or the like), the RAN 5 will not send a response to the UE 3 at step S708. It will be appreciated that if the UE 3 does not receive a response message from the RAN at step S708 within a specified response window, the UE 3 may determine that the RAN 5 was unable to decode the transmitted data. It will be appreciated that the response window during which the UE 3 waits for a response may or may not start when the uplink data is transmitted. The response window may, for example, start following a (pre)configured offset (which may be set greater than or equal to zero, e.g., to, or based on, a RAN to UE round-trip-time (RTT)).

[0141] <RNTI Determination> 　　As mentioned above, the resource configuration included in the SIB transmitted at step S702 may include an indication of an appropriate configuration related to the response monitoring e.g., an appropriate configuration to indicate to the UE 3 how the RAN 5 will respond / acknowledge data received on common / shared PUSCH resources (or PURs).

[0142] The resource configuration information may, for example, include information from which the RNTI associated with each common / shared PUSCH resource (or PUR) may be determined (for example one or more RNTIs and / or other information for allowing determination of an RNTI that will be used to respond to the data transmission on a given shared PUSCH resource (or PUR).

[0143] It will be appreciated that several different approaches may be implemented to allow the RAN 5 and UE 3 to determine the appropriate RNTI to be used by the RAN 5 for a response to data received via a given common / shared PUSCH resource (or PUR) (e.g., by mapping the common / shared PUSCH resources (or PUR) used to the correct RNTI. Examples of such approaches will now be described in detail with reference to Figs. 8 and 13.

[0144] <RTNI determination method #1> 　　In a first approach for determining an RNTI for scheduling an appropriate response message at step S708, the RAN 5 may apply a one-to-one mapping between each RNTI and a corresponding common / shared PUSCH resource (or PUR) that is used by the UE 3 at step S706 for transmission of data.

[0145] For example, as shown in Fig. 8A, each RNTI may be associated with a corresponding common / shared PUSCH resource (or PUR) within a specific time window. For example, the RNTI may be re-used in different pre-defined time windows, or in different time windows configured by the RAN 5 (e.g., configured by the resource configuration included in the SIB transmitted at step S702). The time window may, for example, comprise one or multiple radio frames and / or may be equal to a maximum possible RAR window size, or the like.

[0146] As shown in Fig. 8A, each RNTI may be associated with that corresponding common / shared PUSCH resource (or PUR) using a particular formula (relationship). By way of example only, each RNTI may be determined by the UE 3 (for reception) and the RAN 5 (for response transmission) using the following formula: RNTI=RNTI_StartOffset+ID_PUSCH (or ID_PUR) wherein - RNTIStartOffsetis a first RNTI which is to be assigned for scheduling a response message from the RAN 5 to the UE 3 (e.g., configured by the resource configuration included in the SIB transmitted at step S702); and - IDPUSCH(or IDPUR) is an index of the common / shared PUSCH resource (or PUR) within the time window used by the UE 3 for transmission of the data to the RAN 5 (e.g., configured by / derivable from the resource configuration included in the SIB transmitted at step S702).

[0147] It will be appreciated that were such a formula is used, the PUSCH resources (or PURs) may be numbered in a predefined order e.g., in ascending order of code domain first, then in frequency domain, and finally time domain.

[0148] Following transmission of the data on a selected common / shared PUSCH resource (or PUR) at step S706, the UE 3 may monitor the PDCCH for the response message sent at step S708 at a PDCCH addressed by the RNTI associated with the selected common / shared PUSCH resource (or PUR) used by the UE 3 for transmission of the data (e.g., the UE 3 may monitor for DCI having cyclic redundancy check (CRC) bits scrambled with that RNTI).

[0149] As shown in Fig. 8B, the response message sent at step S708 may be sent in a single MAC packet data unit (PDU) that includes a contention resolution ID and / or appropriate contention resolution information (as described previously above) to enable the UE 3 to determine whether the response message it receives at step S708 corresponds to (i.e., is an acknowledgement of) the uplink data transmission that the UE 3 sent to the RAN 5 on a selected common / shared PUSCH resource (or PUR) at step S706.

[0150] For example, the contention resolution ID / information included in the response message sent at step S708 may comprise a random ID (e.g., X-bit random ID) that was included in the data transmission sent by the UE 3 to the RAN 5 at step S706. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in an appropriate MAC control element (CE) of the MAC PDU (e.g., a contention resolution ID MAC CE, or the like) of the response message sent at step S708.

[0151] In another example, where the response message takes the form of a DCI message, the contention resolution ID / information may be sent to the UE 3 on the PDCCH in that DCI message. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in DCI sent to the UE 3 over the PDCCH.

[0152] In another example, rather than using a random ID generated by the UE 3 as a contention resolution ID / information for the data transmission sent by the UE 3 to the RAN 5 at step S706, contention resolution may be achieved by echoing a portion of the actual data transmission sent by the UE 3 to the RAN 5 at step S706 back to the UE 3 in the response message sent at step S708. For example, having received the data transmission at step S706, the RAN 5 may include a set number of first bits (or a set number of last bits) of the data transmission in the response message sent at step S708.

[0153] Where the random ID or the bits of echoed data included in the response message received at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0154] <RTNI determination method #2> 　　In a second approach for determining an RNTI for scheduling an appropriate response message, at step S708, to the transmission of data by the UE 3 at S706, the RAN 5 may apply a one-to-many mapping between each RNTI and the common / shared PUSCH resources (or PURs) configured by the RAN 5.

[0155] For example, as shown in Fig. 9, each RNTI may be associated to common / shared PUSCH resources (or PURs) that share a common starting time, but different respective frequencies / physical resource blocks) and / or different respective cover codes where OCC is used (not shown). By way of example only, each RNTI may be determined by the UE 3 (for reception) and the RAN 5 (for response transmission) using the following formula: RNTI=RNTI_StartOffset+[(SNF*10)+Subframe Number]modW_max wherein - RNTIStartOffsetis a first RNTI which is to be assigned for scheduling a response message from the RAN 5 to the UE 3 (e.g., configured by / derivable from the resource configuration included in the SIB transmitted at step S702); - SNF is the system frame number; and - Wmaxis a value, which may include, by way of example be a maximum time window (e.g., equal to, or greater than, a response window) expressed in subframe units where the associated RNTI needs to be unique (e.g., pre-defined or configured by / derivable from the resource configuration included in the SIB transmitted at step S702).

[0156] It will be appreciated that where Wmaxis a maximum time window expressed in subframe units, each determined RNTI can be reused in every value of Wmax.

[0157] Alternatively, by way of example only, each RNTI may be determined by the RAN 5 using the following formula: RNTI=RNTI_StartOffset+t_ID wherein - RNTIStartOffsetis a first RNTI which is to be assigned for scheduling a response message from the RAN 5 to the UE 3 (e.g., configured by / derivable from the resource configuration included in the SIB transmitted at step S702); and - tIDis an index (0 ? tID< x) of a common / shared PUSCH resources (or PURs) in the time domain, wherein only subframes with configured common / shared PUSCH resources (or PURs) are numbered, and x is the number of subframes with configured common / shared PUSCH resources (or PURs) within a time window.

[0158] Following transmission of the data on a selected common / shared PUSCH resource (or PUR) at step S706, the UE 3 may monitor the PDCCH for the response message sent at step S708 at a PDCCH addressed by the RNTI associated with the selected common / shared PUSCH resource (or PUR) used by the UE 3 for transmission of the data (e.g., the UE 3 may monitor for DCI having cyclic redundancy check (CRC) bits scrambled with that RNTI).

[0159] As shown in Figs. 10a and 10b, the response message sent at step S708 may be sent in a single MAC PDU. However, unlike in the RTNI determination method #1 described above, that MAC PDU may comprise multiple sub-response messages (e.g., Res#1 - Res#m), each sub-response message corresponding to one data transmission sent to the RAN 5 over a respective (possibly different) common / shared PUSCH resource (or PUR) associated with the same RNTI. It will be appreciated that each data transmission may have been sent by the same or different UEs 3.

[0160] Those sub-response messages (e.g., Res#1 - Res#m) may be identified in the response message by a common / shared PUSCH resource (or PUR) identifier, or the like (which in this example may be a common / shared frequency resource ID such as an index in the frequency domain of the specific common / shared PUSCH resource (or PUR)). It will be appreciated that such a common / shared PUSCH resource (or PUR) identifier may not be necessary where the probability that UEs 3 that have selected a common / shared PUSCH resource (or PUR) having the same RNTI, and that have the same contention resolution identifier, is low.

[0161] Additionally, each sub-response message includes a contention resolution ID and / or appropriate contention resolution information to enable the UE 3 to determine whether one of the multiple sub-response messages (e.g., Res#1 - Res#m) received at step S708 in the response message corresponds to (i.e., is an acknowledgement of) the data transmission that the UE 3 sent to the RAN 5 on a selected common / shared PUSCH resource (or PUR) at step S706.

[0162] For example, the contention resolution ID / information included in each sub-response message (e.g., Res#1 - Res#m), sent in the response message at step S708 may comprise a random ID (e.g., X-bit random ID) that was included in the data transmission sent by the UE 3 to the RAN 5 at step S706. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in a MAC CE (e.g., a contention resolution ID MAC CE, or the like) of the MAC PDU, wherein the MAC CE is associated with an appropriate sub-response message (e.g., Res#1, etc.) in the response message.

[0163] In another example, where the response message takes the form of a DCI message, the contention resolution ID / information may be sent to the UE 3 on the PDCCH in DCI. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in an appropriate sub-response message (e.g., Res#1, etc.) in the DCI sent to the UE 3 over the PDCCH.

[0164] In another example, rather than using a random ID generated by the UE 3 as a contention resolution ID / information for the data transmission sent by the UE 3 to the RAN 5 at step S706, contention resolution may be achieved by echoing a portion of the actual data transmission sent by the UE 3 to the RAN 5 at step S706 back to the UE 3 in the response message sent at step S708. For example, having received the data transmission at step S706, the RAN 5 may include a set number of first bits (or a set number of last bits) of the data transmission in an appropriate sub-response message (e.g., Res#1, etc.) of the response message sent at step S708.

[0165] Where the random ID or the bits of echoed data included in a sub-response message in the response message sent at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0166] <RTNI determination method #3> 　　In a third approach for determining an RNTI for scheduling an appropriate response message, at step S708, to the transmission of data by the UE 3 at S706, the RAN 5 may apply a one-to-many mapping between each RNTI and the common / shared PUSCH resources (or PURs) configured by the RAN 5.

[0167] For example, as shown in Fig. 11, each RNTI may be associated to blocks of common / shared PUSCH resources (or PURs), each block of common / shared PUSCH resources having adjacent time or / and frequency resources to the next block of common / shared PUSCH resources (or PURs). It will be appreciated that where each RNTI may be associated to blocks of common / shared PUSCH resources (or PURs), the common / shared PUSCH resources (or PURs) may be numbered in a predefined order e.g., in ascending order of frequency domain, and then time domain (or any other suitable indexing).

[0168] Following transmission of the data on a selected common / shared PUSCH resource (or PUR) at step S706, the UE 3 may monitor the PDCCH for the response message sent at step S708 at a PDCCH addressed by the RNTI associated with the selected common / shared PUSCH resource (or PUR) used by the UE 3 for transmission of the data (e.g., the UE 3 may monitor for DCI having cyclic redundancy check (CRC) bits scrambled with that RNTI).

[0169] As shown in Figs. 10a and 10b, the response message sent at step S708 may be sent in a single MAC PDU. However, unlike in the RTNI determination method #1 described above, that MAC PDU may comprise multiple sub-response messages (e.g., Res#1 - Res#m), each sub-response message corresponding to one data transmission sent to the RAN 5 over a respective (possibly different) common / shared PUSCH resource (or PUR) associated with the same RNTI. It will be appreciated that each data transmission may have been sent by the same or different UEs 3.

[0170] Those sub-response messages (e.g., Res#1 - Res#m) may be identified in the response message by a common / shared PUSCH resource (or PUR) identifier, or the like (which in this example may be indexed in ascending order of frequency domain, and then time domain, or any other suitable indexing) as shown, for example, in Fig. 10B. It will be appreciated that such a common / shared PUSCH resource (or PUR) identifier may not be necessary where the probability that UEs 3 that have selected a common / shared PUSCH resource (or PUR) having the same RNTI, and that have the same contention resolution identifier, is low.

[0171] Additionally, each sub-response message includes a contention resolution ID and / or appropriate contention resolution information to enable the UE 3 to determine whether one of the multiple sub-response messages (e.g., Res#1 - Res#m) received at step S708 in the response message corresponds to (i.e., is an acknowledgement of) the data transmission that the UE 3 sent to the RAN 5 on a selected common / shared PUSCH resource (or PUR) at step S706.

[0172] For example, the contention resolution ID / information included in the response message sent at step S708 may comprise a random ID (e.g., X-bit random ID) that was included in the data transmission sent by the UE 3 to the RAN 5 at step S706. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in an appropriate MAC control element (CE) of the MAC PDU (e.g., a contention resolution ID MAC CE, or the like) of the response message sent at step S708.

[0173] In another example, where the response message takes the form of a DCI message, the contention resolution ID / information may be sent to the UE 3 on the PDCCH in that DCI message. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in DCI sent to the UE 3 over the PDCCH.

[0174] In another example, rather than using a random ID generated by the UE 3 as a contention resolution ID / information for the data transmission sent by the UE 3 to the RAN 5 at step S706, contention resolution may be achieved by echoing a portion of the actual data transmission sent by the UE 3 to the RAN 5 at step S706 back to the UE 3 in the response message sent at step S708. For example, having received the data transmission at step S706, the RAN 5 may include a set number of first bits (or a set number of last bits) of the data transmission in the response message sent at step S708.

[0175] Where the random ID or the bits of echoed data included in the response message received at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0176] <RTNI determination method #4> 　　In a fourth approach for determining an RNTI for scheduling an appropriate response message, at step S708, to the transmission of data by the UE 3 at S706, the RAN 5 may apply a one-to-many mapping between each RNTI and the common / shared PUSCH resources (or PURs) configured by the RAN 5.

[0177] For example, as shown in Fig. 12, each RNTI may be associated with all common / shared PUSCH resources (or PURs) within a specified periodicity.

[0178] It will be appreciated that where each RNTI may be associated to blocks of common / shared PUSCH resources (or PURs) within a specified periodicity, the common / shared PUSCH resources (or PURs) may be numbered in a predefined order e.g., in ascending order of frequency domain, and then time domain (or any other suitable indexing).

[0179] Following transmission of the data on a selected common / shared PUSCH (or PUR) at step S706, the UE 3 may monitor the PDCCH for the response message sent at step S708 at a PDCCH addressed by the RNTI associated with the selected common / shared PUSCH (or PUR) used by the UE 3 for transmission of the data (e.g., the UE 3 may monitor for DCI having cyclic redundancy check (CRC) bits scrambled with that RNTI).

[0180] As shown in Figs. 10a and 10b, the response message sent at step S708 may be sent in a single MAC PDU. That MAC PDU may comprise multiple sub-response messages (e.g., Res#1 - Res#m), each sub-response message corresponding to one data transmission sent to the RAN 5 over a specific common / shared PUSCH resources (or PURs). It will be appreciated that each data transmission may have been sent by the same or different UEs 3.

[0181] Those sub-response messages (e.g., Res#1 - Res#m) may be identified in the response message by a common / shared PUSCH resource (or PUR) identifier, or the like (which in this example may be indexed in ascending order of frequency domain, and then time domain, or any other suitable indexing) as shown, for example, in Fig. 10B. It will be appreciated that such a common / shared PUSCH resource (or PUR) identifier may not be necessary where the probability that UEs 3 that have selected a common / shared PUSCH resource (or PUR) having the same RNTI, and that have the same contention resolution identifier, is low.

[0182] Additionally, each sub-response message includes a contention resolution ID and / or appropriate contention resolution information to enable the UE 3 to determine whether one of the multiple sub-response messages (e.g., Res#1 - Res#m) received at step S708 in the response message corresponds to (i.e., is an acknowledgement of) the data transmission that the UE 3 sent to the RAN 5 on a selected common / shared PUSCH (or PUR) at step S706.

[0183] For example, the contention resolution ID / information included in each sub-response message (e.g., Res#1 - Res#m), sent in the response message at step S708 may comprise a random ID (e.g., X-bit random ID) that was included in the data transmission sent by the UE 3 to the RAN 5 at step S706. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in a MAC CE (e.g., a contention resolution ID MAC CE, or the like) of the MAC PDU, wherein the MAC CE is associated with an appropriate sub-response message (e.g., Res#1, etc.) in the response message.

[0184] In another example, where the response message takes the form of a DCI message, the contention resolution ID / information may be sent to the UE 3 on the PDCCH in DCI. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in an appropriate sub-response message (e.g., Res#1, etc.) in the DCI sent to the UE 3 over the PDCCH.

[0185] In another example, rather than using a random ID generated by the UE 3 as a contention resolution ID / information for the data transmission sent by the UE 3 to the RAN 5 at step S706, contention resolution may be achieved by echoing a portion of the actual data transmission sent by the UE 3 to the RAN 5 at step S706 back to the UE 3 in the response message sent at step S708. For example, having received the data transmission at step S706, the RAN 5 may include a set number of first bits (or a set number of last bits) of the data transmission in an appropriate sub-response message (e.g., Res#1, etc.) of the response message sent at step S708.

[0186] Where the random ID or the bits of echoed data included in a sub-response message in the response message sent at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0187] <RTNI determination method #5> 　　In a fifth approach for determining an RNTI for scheduling an appropriate response message, at step S708, to the transmission of data by the UE 3 at S706, the RAN 5 may apply a one-to-many mapping between each RNTI and the common / shared PUSCH resources (or PURs) configured by the RAN 5.

[0188] For example, as shown in Fig. 13, one RNTI may be associated with all common / shared PUSCH resources (or PURs).

[0189] It will be appreciated that where each RNTI may be associated to all common / shared PUSCH resources (or PURs), the common / shared PUSCH resources (or PURs) (e.g., within a given repeating time window (Wmax)) may be numbered in a predefined order e.g., in ascending order of frequency domain, and then time domain (or any other appropriate indexing). It will also be appreciated that the time window (Wmax) may be configured to be equal to or larger than a time window within which a response might be expected (thereby ensuring that the same common / shared PUSCH resource (or PUR) index is not repeated).

[0190] Following transmission of the data on a selected common / shared PUSCH (or PUR) at step S706, the UE 3 may monitor the PDCCH for the response message sent at step S708 at a PDCCH addressed by the RNTI associated with the selected common / shared PUSCH (or PUR) used by the UE 3 for transmission of the data (e.g., the UE 3 may monitor for DCI having cyclic redundancy check (CRC) bits scrambled with that RNTI).

[0191] As shown in Figs. 10a and 10b, the response message sent at step S708 may be sent in a single MAC PDU. That MAC PDU may comprise multiple sub-response messages (e.g., Res#1 - Res#m), each sub-response message corresponding to one data transmission sent to the RAN 5 over a specific common / shared PUSCH resources (or PURs). It will be appreciated that each data transmission may have been sent by the same or different UEs 3.

[0192] Those sub-response messages (e.g., Res#1 - Res#m) may be identified in the response message by a common / shared PUSCH resource (or PUR) identifier, or the like (which in this example may be indexed in ascending order of frequency domain, and then time domain, or any other suitable indexing) as shown, for example, in Fig. 10B. It will be appreciated that such a common / shared PUSCH resource (or PUR) identifier may not be necessary where the probability that UEs 3 that have selected a common / shared PUSCH resource (or PUR) having the same RNTI, and that have the same contention resolution identifier, is low.

[0193] Additionally, each sub-response message includes a contention resolution ID and / or appropriate contention resolution information to enable the UE 3 to determine whether one of the multiple sub-response messages (e.g., Res#1 - Res#m) received at step S708 in the response message corresponds to (i.e., is an acknowledgement of) the data transmission that the UE 3 sent to the RAN 5 on a selected common / shared PUSCH (or PUR) at step S706.

[0194] For example, the contention resolution ID / information included in each sub-response message (e.g., Res#1 - Res#m), sent in the response message at step S708 may comprise a random ID (e.g., X-bit random ID) that was included in the data transmission sent by the UE 3 to the RAN 5 at step S706. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in a MAC CE (e.g., a contention resolution ID MAC CE, or the like) of the MAC PDU, wherein the MAC CE is associated with an appropriate sub-response message (e.g., Res#1, etc.) in the response message.

[0195] In another example, where the response message takes the form of a DCI message, the contention resolution ID / information may be sent to the UE 3 on the PDCCH in DCI. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in an appropriate sub-response message (e.g., Res#1, etc.) in the DCI sent to the UE 3 over the PDCCH.

[0196] In another example, rather than using a random ID generated by the UE 3 as a contention resolution ID / information for the data transmission sent by the UE 3 to the RAN 5 at step S706, contention resolution may be achieved by echoing a portion of the actual data transmission sent by the UE 3 to the RAN 5 at step S706 back to the UE 3 in the response message sent at step S708. For example, having received the data transmission at step S706, the RAN 5 may include a set number of first bits (or a set number of last bits) of the data transmission in an appropriate sub-response message (e.g., Res#1, etc.) of the response message sent at step S708.

[0197] Where the random ID or the bits of echoed data included in a sub-response message in the response message sent at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0198] <RTNI determination method #6> 　　In a sixth approach for determining an RNTI for scheduling an appropriate response message, at step S708, to the transmission of data by the UE 3 at S706, the RAN 5 may apply a one-to-many mapping between each RNTI and the common / shared PUSCH resources (or PURs) configured by the RAN 5.

[0199] For example, one or multiple RNTIs may be configured by the RAN 5 (e.g., in the resource configuration included in the SIB transmitted at step S702), and each RNTI may be associated with one or multiple common / shared PUSCH resources (or PURs). In this scenario, common / shared PUSCH resources (or PURs) with the same RNTI may be (uniquely) numbered and hence identifiable.

[0200] Following transmission of the data on a selected common / shared PUSCH (or PUR) at step S706, the UE 3 may monitor the PDCCH for the response message sent at step S708 at a PDCCH addressed by the corresponding RNTI associated with the selected common / shared PUSCH (or PUR) used by the UE 3 for transmission of the data (e.g., the UE 3 may monitor for DCI having cyclic redundancy check (CRC) bits scrambled with that RNTI).

[0201] As shown in Figs. 10a and 10b, the response message sent at step S708 may be sent in a single MAC PDU. That MAC PDU may comprise multiple sub-response messages (e.g., Res#1 - Res#m), each sub-response message corresponding to one data transmission sent to the RAN 5 over a specific common / shared PUSCH resources (or PURs). It will be appreciated that each data transmission may have been sent by the same or different UEs 3.

[0202] Those sub-response messages (e.g., Res#1 - Res#m) may be identified in the response message by a PUSCH resource (or PUR) identifier, or the like (for example as configured by the RAN 5) as shown, for example, in Fig. 10B. It will be appreciated that such a common / shared PUSCH resource (or PUR) identifier may not be necessary where the probability that UEs 3 that have selected a common / shared PUSCH resource (or PUR) having the same RNTI, and that have the same contention resolution identifier, is low.

[0203] Additionally, each sub-response message includes a contention resolution ID and / or appropriate contention resolution information to enable the UE 3 to determine whether one of the multiple sub-response messages (e.g., Res#1 - Res#m) received at step S708 in the response message corresponds to (i.e., is an acknowledgement of) the data transmission that the UE 3 sent to the RAN 5 on a selected common / shared PUSCH (or PUR) at step S706.

[0204] For example, the contention resolution ID / information included in each sub-response message (e.g., Res#1 - Res#m), sent in the response message at step S708 may comprise a random ID (e.g., X-bit random ID) that was included in the data transmission sent by the UE 3 to the RAN 5 at step S706. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in a MAC CE (e.g., a contention resolution ID MAC CE, or the like) of the MAC PDU, wherein the MAC CE is associated with an appropriate sub-response message (e.g., Res#1, etc.) in the response message.

[0205] In another example, where the response message takes the form of a DCI message, the contention resolution ID / information may be sent to the UE 3 on the PDCCH in DCI. For example, a random ID may be included in the data transmission sent by the UE 3 to the RAN 5 at step S706, which may then subsequently be echoed back to the UE 3 in an appropriate sub-response message (e.g., Res#1, etc.) in the DCI sent to the UE 3 over the PDCCH.

[0206] In another example, rather than using a random ID generated by the UE 3 as a contention resolution ID / information for the data transmission sent by the UE 3 to the RAN 5 at step S706, contention resolution may be achieved by echoing a portion of the actual data transmission sent by the UE 3 to the RAN 5 at step S706 back to the UE 3 in the response message sent at step S708. For example, having received the data transmission at step S706, the RAN 5 may include a set number of first bits (or a set number of last bits) of the data transmission in an appropriate sub-response message (e.g., Res#1, etc.) of the response message sent at step S708.

[0207] Where the random ID or the bits of echoed data included in a sub-response message in the response message sent at step S708 matches the random ID or the bits of echoed data included in the data transmission sent at step S706, the UE 3 may consider the data transmission it made to have been successfully received and decoded by the RAN 5.

[0208] Additionally, each sub-response messages (e.g., Res#1 - Res#m) received at step S708 may include an appropriate indication of the selected common / shared PUSCH (or PUR) on which data was transmitted to the RAN 5 by the UE 3. For example, each sub-response messages (e.g., Res#1 - Res#m) may include an index (e.g., a unique number) associated with the selected common / shared PUSCH (or PUR) on which data was transmitted to the RAN 5 by the UE 3.

[0209] <Failure / Backoff / Fallback> 　　In the case, where the UE 3 determines that the RAN 5 was unable to decode the transmitted data (e.g., because of a contention resolution issue, or the like), the UE 3 may trigger / initiate a failure procedure; a backoff procedure; a fall-back procedure; or the like at step S710.

[0210] For example, if the UE 3 determines that the RAN 5 was unable to decode the transmitted data, the UE 3 may trigger a failure (and re-transmission) procedure, or the like. The failure and re-transmission procedure may, for example, involve the UE 3 re-sending the data that it transmitted at step S706 to the RAN 5 if a corresponding response message is not received by the UE 3 at step S708 in a configured response time window.

[0211] In this case, the UE 3 may decide to adjust its transmission power (e.g., increase its transmission power by a configured amount compared to the transmission power it used for the previous data transmission). The UE 3 may then re-select a common / shared PUSCH resource (or PUR) for the re-transmission of the data and re-transmit the data over the re-selected common / shared PUSCH resource (or PUR).

[0212] The above re-transmission procedure may be repeated N number of times, wherein N is pre-configured. If after N number of re-transmissions, the UE 3 still does not receive a response message from the RAN 5 to indicate that the data has been received and successfully decoded, the UE 3 may revert to a typical RACH procedure for the transmission of the data (e.g., the EDT procedure of Fig. 5).

[0213] Alternatively, if the UE 3 receives a response message but the response message does not correspond to the data transmission sent by the UE 3 at step S706, the UE 3 may trigger a fallback procedure, or the like. The fallback procedure may, for example, involve the UE 3 falling back to a typical RACH procedure for the transmission of the data.

[0214] For example, the response message sent by the RAN 5 at step S708 may include an appropriate indication (e.g., in a MAC CE of the response message) that the UE 3 is to fallback to a typical RACH procedure for the transmission of its data if the UE 3 is unable to identify a match between the contention ID / information in the response message (e.g., the random ID or the bits of echoed data) and the corresponding contention ID / information generated at the UE 3 (e.g., the random ID generated by the UE 3 or the bits of data included in the data transmission sent at step S706).

[0215] In another example, the response message sent by the RAN 5 at step S708 may include an appropriate indication (e.g., in a MAC CE of the response message) that the UE 3 is to fallback to a typical RACH procedure for the transmission of its data if a common / shared resource ID indicated in the response message matches a common / shared resource ID associated with the common / shared PUSCH resource (or PUR) used by the UE 3 for its data transmission at step S706, but the UE 3 is unable to identify a match between the contention ID / information in the response message (e.g., the random ID or the bits of echoed data) and the corresponding contention ID / information generated at the UE 3 (e.g., the random ID generated by the UE 3 or the bits of data included in the data transmission sent at step S706).

[0216] Alternatively, if the UE 3 receives a response message but the response message does not correspond to the data transmission made by the UE 3 at step S706, the UE 3 may trigger a backoff procedure, or the like. The backoff procedure may, for example, involve the UE 3 waiting for a period of time (e.g., X units of time, wherein X is any value between 0, and some received backoff value e.g., configured by the RAN 5) before attempting to re-transmit the data on selected common / shared PUSCH resources (or PURs).

[0217] For example, the response message sent by the RAN 5 at step S708 may include an appropriate indication (e.g., in a MAC CE of the response message) that the UE 3 is to perform a backoff procedure if the UE 3 is unable to identify a match between the contention ID / information in the response message (e.g., the random ID or the bits of echoed data) and the corresponding contention ID / information generated at the UE 3 (e.g., the random ID generated by the UE 3 or the bits of data included in the data transmission sent at step S706).

[0218] <Additional Enhancements to CB Data Transmissions> <Load Control> 　　In the CB data transmission procedures described above with reference to Figs. 7 to 13, the RAN 5 (or network) may detect, at a given time, that a data load on the configured common / shared PUSCH resources (or PURs) is temporarily high, increasing the risk of data collision events occurring.

[0219] In this scenario, the RAN 5 may temporarily configure / activate, via a MAC CE, additional common / shared PUSCH resources (or PURs) that may be used by the UE 3 for data transmissions. For example, the RAN 5 may include an appropriate MAC CE in its response messages sent at step S708. Upon receiving those response messages, the UE 3 (and any other UEs in the communication system 1 that receive those messages) may decide to use those configured / activated additional common / shared PUSCH resources (or PURs). For example, if a UE (e.g., the UE 3) is unable to identify a match between the contention ID / information in a received response message (e.g., the random ID or the bits of echoed data) and a corresponding contention ID / information generated at the UE 3 (e.g., the random ID generated by the UE 3 or the bits of data included in data transmission sent at step S706), the UE 3 may decide to use configured / activated additional common / shared PUSCH resources (or PURs) where such resources are indicated in the response message via an appropriate MAC CE.

[0220] Alternatively, where the RAN 5 (or network) detects that a data load on the configured common / shared PUSCH resources (or PURs) is temporarily high, the RAN 5 may temporarily configure / activate, via a MAC CE, new (strict) conditions (e.g., a new RSRP threshold value) that has to be met before the UE 3 can use the common / shared PUSCH resources (or PURs). For example, the RAN 5 may include an appropriate MAC CE in its response messages sent at step S708. Upon receiving those response messages, the UE 3 (and any other UEs in the communication system 1 that receive those messages) may be configured with new (strict) conditions (e.g., a new RSRP threshold value) that have to be met before the UE 3 can use the common / shared PUSCH resources (or PURs), thereby limiting the common / shared PUSCH resources (or PURs) that may be used at that time.

[0221] For example, if a UE (e.g., the UE 3) is unable to identify a match between the contention ID / information in a received response message (e.g., the random ID or the bits of echoed data) and a corresponding contention ID / information generated at the UE 3 (e.g., the random ID generated by the UE 3 or the bits of data included in data transmission sent at step S706), the UE 3 may apply the new (strict) conditions (e.g., a new RSRP threshold value) indicated in the response message via an appropriate MAC CE to limit common / shared PUSCH resources (or PURs) that may be used.

[0222] <Subsequent Data Transmissions> 　　In the CB data transmission procedures described above with reference to Figs. 7 to 13, subsequent data transmissions following receipt of the response message at step S708 may need to be supported. For example, where the TBS of the common / shared PUSCH resources (or PURs) used by the UE 3 for the transmission of its data to the RAN 5 are of a standard (static) size and / or are very small, but the data to be transmitted by the UE 3 varies in size, the UE 3 may not be able to transmit all of the data in one go on a selected common / shared PUSCH resource (or PUR).

[0223] Fig. 14 illustrates a simplified sequence diagram of an adapted version CB data transmission procedure of Fig. 7 that supports subsequent data transmissions.

[0224] It will be appreciated that step S1402 of Fig. 14 corresponds to step S702 of Fig. 7. The description above with respect to the SIB message sent by the RAN 5 to the UE 3 at step S702 thus applies to step S1402 of Fig. 14.

[0225] It will be appreciated that step S1404 of Fig. 14 corresponds to step S704 of Fig. 7. The description above with respect to the data transmission sent by the UE 3 to the RAN at step S704 thus applies to step S1404 of Fig. 14.

[0226] Additionally, at step S1404, if the UE 3 decides to use common / shared PUSCH resources (or PURs) indicated to the UE 3 in the SIB sent to the UE 3 at step S1402, but the selected common / shared PUSCH resource (or PUR) cannot accommodate all of the data in the data buffer of the UE 3, the UE 3 may include in its (early) data transmission to the RAN 5 at step S1404, an appropriate indication that the UE 3 has more data to send to the RAN 5 (e.g., the data transmission may include a 1-bit indicator, or a multi-bit buffer status report (BSR)).

[0227] At step S1406 the UE 3 sends to the RAN 5 an (early) data transmission with an appropriate indication that that the UE 3 has more data to send to the RAN 5 (e.g., the data transmission may include a 1-bit indicator, or a multi-bit BSR) using the selected common / shared PUSCH resources (or PUR) at step S1404.

[0228] It will be appreciated that the appropriate response message (e.g., a data transmission response (acknowledgement) message, or the like) sent at step S1408 of Fig. 14 corresponds to step S708 of Fig. 7. The description above with respect to the response message sent by the RAN 5 to the UE 3 at step S708 thus applies to step S1408 of Fig. 14.

[0229] At step S1410, where the data transmission sent at step S1406 included an appropriate indication that the UE 3 has more data in its buffer that it wishes to send to the RAN 5, another message may be sent to the UE 3 that includes an appropriate indication of a new dedicated RNTI and / or a resource grant, or the like, that may be used by the UE 3 to determine resources that it may use for subsequent data transmissions to the RAN 5. It will, nevertheless, be appreciated that the indication of a new dedicated RNTI and / or a resource grant, or the like may be included in the message sent at S1408 rather than a separate message.

[0230] At step S1412, the UE 3 may use the dedicated RNTI and / or the resources indicated in the resource grant that the UE 3 received from the RAN 5 at step S1410 to send the remaining data it has stored in its data buffer.

[0231] <Support of Diversity Slotted Aloha (DSA) and / or CRDSA> 　　In the CB data transmission procedures described above with reference to Figs. 7 to 14, it may be beneficial to allow for the implementation of DSA and / or CRDSA to provide significant increases in (early) CB data transmission throughput in those CB data transmission procedures described above.

[0232] Fig. 15 illustrates a simplified sequence diagram of an adapted version CB data transmission procedure of Fig. 7 that supports DSA and / or CRDSA.

[0233] It will be appreciated that step S1502 of Fig. 15 corresponds to step S702 of Fig. 7. The description above with respect to the SIB message sent by the RAN 5 to the UE 3 at step S702 thus applies to step S1502 of Fig. 15.

[0234] Additionally, at step S1502 the resource configuration in the SIB message sent by the RAN 5 to the UE 3 may also include an appropriate indication to configure a defined resource frame (e.g., a shared PUSCH frame) within which the UE 3 should select configured common / shared PUSCH resources (or PURs) for the transmission of (early) data transmissions.

[0235] Alternatively, the SIB message sent by the RAN 5 to the UE 3 at step S1502 may include a separate resource frame configuration (e.g., a shared PUSCH frame configuration) to configure a defined resource frame (e.g., a shared PUSCH frame) within which the UE 3 should select configured common / shared PUSCH resources (or PURs) for the transmission of (early) data transmissions.

[0236] For example, the resource configuration (or the resource frame configuration) sent in the SIB message at step S1502 may configure a time window of resources (i.e., a resource frame) within which the UE 3 can select two (or more) common / shared PUSCH resources (or PURs) for the transmission of a data transmission and replicas of that data transmission.

[0237] It will be appreciated that each PUSCH resource within the configured shared PUSCH frame may also be numbered in a sequential manner. For example, the PUSCH resources in the shared PUSCH frame may be numbered first in the time domain, and then in the frequency domain so that each PUSCH resource can be identified, and to enable the encoding of a pointer to each PUSCH resource in the shared PUSCH frame for identification of the PUSCH resources in transmissions between the RAN 5 and the UE 3.

[0238] Beneficially, by configuring a resource frame within which the UE 3 can select two (or more) common / shared PUSCH resources (or PURs) for the transmission of a data transmission and replicas thereof (e.g., as part of a DSA and / or CRDSA procedure), the UE 3 can transmit data and replicas of that data to the RAN 5 over a single shared PUSCH frame with a configured duration (e.g., a 20ms shared PUSCH frame). Furthermore, the RAN 5 may configure multiple shared PUSCH frames each of a specified duration (e.g., 20ms) such that a first shared PUSCH frame may extend in the time domain from 0ms to 20ms, a second shared PUSCH frame may extend in the time domain from 20ms to 40ms, a third shared PUSCH frame may extend in the time domain from 40ms to 60ms etc. Each of those different shared PUSCH frames may be used to select two (or more) common / shared PUSCH resources for different sets of data transmissions and corresponding replicas.

[0239] Additionally, where the CB data transmission procedure supports DSA and / or CRDSA, the SIB message at step S1502 may (optionally) configure a number of replicas of the data transmissions that the UE 3 may send to the RAN 5.

[0240] It will be appreciated that step S1504 of Fig. 15 corresponds to step S704 of Fig. 7. The description above with respect to the data transmission sent by the UE 3 to the RAN 5 at step S704 thus applies to step S1504 of Fig. 15, albeit that at step S1504 the UE 3 may select two or more common / shared PUSCH resources (or PURs) in a shared PUSCH frame for use in transmission of the data and replicas of that data.

[0241] At step S1506a the UE 3 sends an (early) data transmission (#n) to the RAN 5 using one of the two or more selected common / shared PUSCH resources (or PURs) that were selected at step S1504. The UE 3 may also include, in that data transmission to the RAN 5, appropriate pointer information (e.g. pointer #m) to point to the other common / shared PUSCH resources (or PURs) of the two or more selected common / shared PUSCH resources (or PURs) that were selected at step S1504, and within which the UE 3 will send replica transmissions of the data.

[0242] At step S1506b the UE 3 sends a replica (early) data transmission (#m) to the RAN 5 using another of the two or more selected common / shared PUSCH resources (or PURs) selected at step S1504, and which is different from the selected common / shared PUSCH resources (or PURs) used at step S1506a. The UE 3 may also include, in that replica data transmission to the RAN 5, appropriate pointer information (e.g., pointer #n) to point to the common / shared PUSCH resource (or PUR) previously used by the UE 3 to send the original data transmission at step S1506a.

[0243] At both steps S1506a and S1506b, the pointer may be added to the original data transmission and replicas of the data transmission at the physical layer and included in appropriate uplink control information (UCI). Alternatively, the pointer may be added to the original data transmission and replicas of the data transmission at the MAC layer and may be included in an appropriate MAC CE.

[0244] Beneficially, my including pointers in the data transmission and replica data transmissions as described above, the RAN 5 is able to identify data transmissions that it receives that are replica transmissions.

[0245] Once the RAN 5 has received data transmissions and replicas of data transmissions, it may perform DSA and / or CRDSA procedures as will be known by the person skilled in the art.

[0246] It will also be appreciated that, where appropriate, the RAN 5 may decide to disable CRDSA functionality (i.e., request the UE 3 not to transmit replicas), and fall back to normal slotted Aloha procedures that will be known by the person skilled in the art.

[0247] <Devices of the Communication System> <User Equipment> 　　Fig. 16 is a schematic block diagram illustrating the main components of a UE 3 as shown in Fig. 1.

[0248] As shown, the UE 3 has a transceiver circuit 31 that is operable to transmit signals to and to receive signals from a RAN 5 via one or more antennas 33 (e.g., comprising one or more antenna elements). The UE 3 has a controller 37 to control the operation of the UE 3. The controller 37 is associated with a memory 39 and is coupled to the transceiver circuit 31. Although not necessarily required for its operation, the UE 3 might, of course, have all the usual functionality of a conventional UE 3 (e.g., a user interface 35, such as a touch screen / keypad / microphone / speaker and / or the like for, allowing direct control by and interaction with a user) and this may be provided by any one or any combination of hardware, software, and firmware, as appropriate. Software may be pre-installed in the memory 39 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example.

[0249] The controller 37 is configured to control overall operation of the UE 3 by, in this example, program instructions or software instructions stored within memory 39. As shown, these software instructions include, among other things, an operating system 41, and a communications control module 43.

[0250] The communication control module 43 is operable to control the communication between the UE 3 and its serving RAN 5 (and other communication devices connected to the RAN 5, such as further UEs and / or core network nodes). The communication control module 43 is configured for the overall handling of uplink communications via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), random access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communication control module 43 is also configured for the overall handling of receipt of downlink communications via associated downlink channels (e.g., of DCI via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-persistent scheduling (e.g., SPS). The communication control module 43 is responsible, for example: for determining where to monitor for downlink control information; for determining the resources to be used by the UE 3 for transmission / reception of UL / DL communications (including interleaved resources and resources subject to frequency hopping); for managing frequency hopping at the UE side; for determining how slots / symbols are configured (e.g., for UL, DL or full duplex communication, or the like); for determining which bandwidth parts are configured for the UE 3; for determining how uplink transmissions should be encoded and the like.

[0251] It will be appreciated that the communication control module 43 may include a number of sub-modules ('layers' or 'entities') to support specific functionalities. For example, the communication control module 43 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an RRC sub-module, etc.

[0252] The communication control module 43 is configured, in particular, to control the UE's communications, where applicable, in accordance with any of the methods described herein.

[0253] <Base Station (non-distributed)> 　　Fig. 17 is a schematic block diagram illustrating the main components of a non-distributed base station 5A for the communication system 1 shown in Fig. 1. As shown, the base station 5A has a transceiver circuit 51 for transmitting signals to and for receiving signals from the communication devices (such as UEs 3) via one or more antennas 53 (e.g., a single or multi-panel antenna array / massive antenna), and a core network interface 55 (e.g., comprising the N2, N3 and other reference points / interfaces) for transmitting signals to and for receiving signals from network nodes in the core network 7. Although not shown, the base station 5A may also be coupled to other base stations 5A via an appropriate interface (e.g., the so-called 'Xn' interface in NR). The base station 5A has a controller 57 to control the operation of the base station 5A. The controller 57 is associated with a memory 59. Software may be pre-installed in the memory 59 and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The controller 57 is configured to control the overall operation of the base station 5A by, in this example, program instructions or software instructions stored within memory 59.

[0254] As shown, these software instructions include, among other things, an operating system 61, and a communications control module 63.

[0255] The communications control module 63 is operable to control the communication between the base station 5A and UEs 3 and other network entities that are connected to the base station 5A. The communications control module 63 is configured for the overall control of the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). The communications control module 63 is also configured for the overall handling the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). The communications control module 63 is also responsible, for example, for determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0256] It will be appreciated that the communications control module 63 may include a number of sub-modules (or 'layers') to support specific functionalities. For example, the communications control module 63 may include a PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc.

[0257] The communication control module 63 is configured, in particular, to control the base station's communications, where applicable, in accordance with any of the methods described herein.

[0258] <Base Station (distributed)> 　　Fig. 18 is a simplified block schematic illustrating the main components of a distributed type of base station 5Adistfor implementation in the system of Fig. 1. As shown, the base station 5Adistincludes a central unit (base station CU) 5ACUand a distributed unit (base station DU) 5ADU(although it may include other base station DUs 5ADUas described above). Each unit 5ACU, 5ADUincludes respective transceiver circuitry 51c, 51d.

[0259] The transceiver circuitry 51d of the distributed unit 5ADUis operable to transmit signals to and to receive signals from UEs 3 via an air interface 53d and one or more antennas and is also operable to transmit signals to and to receive signals from the central unit 5ACUvia an interface, for example the distributed unit side of an F1 interface (which may be provided over a satellite radio interface).

[0260] The transceiver circuitry 51c of the central unit 5ACUis operable to transmit signals to and to receive signals from functions of the core network 7 and / or other base stations via a network interface 55c. The network interface typically includes an N2 and / or N3 interfaces for communicating with the core network and a base station to base station (e.g., Xn) interface for communicating with other base stations 5A. The transceiver circuitry 51c of the central unit 5ACUis also operable to transmit signals to and to receive signals from one or more distributed units 5ADU, for example the central unit side of the F1 interface provided.

[0261] Each unit 5ACU, 5ADUincludes a respective controller 57c, 57d which controls the operation of the corresponding transceiver circuitry 51c, 51d in accordance with software stored in the respective memories 59c and 59d of the central unit 5ACUand the distributed unit 5ACU. The software of each unit may be pre-installed in the memory 59c, 59d and / or may be downloaded via the communication system 1 or from a removable data storage device (RMD), for example. The software of each unit includes, among other things, a respective operating system 61c, 61d, and a respective communications control module 63c, 63d.

[0262] Each communications control module 63c, 63d is operable to control the communication of its corresponding unit 5ACU, 5ADUincluding the communication from one unit to the other. The communications control module 63d of the distributed unit 5ADUcontrols communication between the distributed unit 5ADUand the UEs 3, and the communications control module 63c of the central unit 5ACUcontrols communication between the central unit 5ACUand other network entities that are connected to the distributed base station 5Adist.

[0263] The communications control modules 63c, 63d also respectively control the part played by the central unit 5ACUand distributed unit 5ADUin the flow of uplink and downlink user traffic and control data to be received from and transmitted to the communications devices served by the base station 5A including, for example, control data for managing operation of the UEs 3. Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5ACUand distributed unit 5ADUin the reception and decoding of uplink communications, via associated uplink channels (e.g., via a physical uplink control channel (PUCCH), a random-access channel (RACH), and / or a physical uplink shared channel (PUSCH)) including both dynamic and semi-static signalling (e.g., SRS). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5ACUand distributed unit 5ADUin the overall handling the transmission of downlink communications via associated downlink channels (e.g., via a physical downlink control channel (PDCCH) and / or a physical downlink shared channel (PDSCH)) including both dynamic and semi-static signalling (e.g., CSI-RS, SSBs etc.). Each communication control module 63c, 63d is responsible, for example, for controlling the respective part played by the central unit 5ACUand distributed unit 5ADUin determining and scheduling the resources to be used by the UE 3 for receiving in DL / transmitting in UL, for configuring slots / symbols appropriately (e.g., for UL, DL, flexible, full duplex communication, or the like), for configuring one or more bandwidth parts for the UE 3, and for providing related configuration signalling to the UE 3.

[0264] It will be appreciated that each communication control module 63c, 63d may include a number of sub-modules (or 'layers') to support specific functionalities supported by the by the central unit 5ACUand distributed unit 5ADU. For example, a communications PHY sub-module, a MAC sub-module, an RLC sub-module, a PDCP sub-module, an SDAP sub-module, an IP sub-module, an RRC sub-module, etc may be distributed between the central unit 5ACUand distributed unit 5ADUappropriately depending on where the functional split is configured between the central unit 5ACUand distributed unit 5ADU.

[0265] Each communication control module 63c, 63d is configured, in particular, to control the respective communications of the central unit 5ACUand distributed unit 5ADU, where applicable, in accordance with any of the methods described herein.

[0266] <Modifications and Alternatives> 　　Detailed examples been described above. As those skilled in the art will appreciate, a number of modifications and alternatives can be made to the above examples whilst still benefiting from the concepts embodied therein.

[0267] It will also be appreciated that whilst information elements having specific names have been described differently named information elements but having a similar purpose may be used.

[0268] In the above description the UE and the base station are described for ease of understanding as having a number of discrete functional components or modules. Whilst these modules may be provided in this way for certain applications, for example where an existing system has been modified to implement the disclosed enhancements, in other applications, for example in systems designed with the inventive features in mind from the outset, these modules may be built into the overall operating system or code and so these modules may not be discernible as discrete entities.

[0269] In the above examples, a number of software modules were described. As those skilled in the art will appreciate, the software modules may be provided in compiled or un-compiled form and may be supplied to the UE or base station as a signal over a computer network, or on a recording medium. Further, the functionality performed by part, or all, of this software may be performed using one or more dedicated hardware circuits. However, the use of software modules is preferred as it facilitates the updating of the UE or the base station in order to update their functionalities.

[0270] Each controller may comprise any suitable form of processing circuitry including (but not limited to), for example: one or more hardware implemented computer processors; microprocessors; central processing units (CPUs); arithmetic logic units (ALUs); input / output (IO) circuits; internal memories / caches (program and / or data); processing registers; communication buses (e.g. control, data and / or address buses); direct memory access (DMA) functions; hardware or software implemented counters, pointers and / or timers; and / or the like. Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0271] The User Equipment (or "UE," "mobile station," "mobile device" or "wireless device") in the present disclosure is an entity connected to a network via a wireless interface.

[0272] It should be noted that the present disclosure is not limited to a dedicated communication device and can be applied to any device having a communication function as explained in the following paragraphs.

[0273] The terms "User Equipment" or "UE" (as the term is used by 3GPP), "mobile station", "mobile device", and "wireless device" are generally intended to be synonymous with one another, and include standalone mobile stations, such as terminals, cell phones, smart phones, tablets, cellular IoT devices, IoT devices, and machinery. It will be appreciated that the terms "mobile station" and "mobile device" also encompass devices that remain stationary for an extended period of time.

[0274] A UE may, for example, be an item of equipment for production or manufacture and / or an item of energy related machinery (for example equipment or machinery such as: boilers; engines; turbines; solar panels; wind turbines; hydroelectric generators; thermal power generators; nuclear electricity generators; batteries; nuclear systems and / or associated equipment; heavy electrical machinery; pumps including vacuum pumps; compressors; fans; blowers; oil hydraulic equipment; pneumatic equipment; metal working machinery; manipulators; robots and / or their application systems; tools; moulds or dies; rolls; conveying equipment; elevating equipment; materials handling equipment; textile machinery; sewing machines; printing and / or related machinery; paper converting machinery; chemical machinery; mining and / or construction machinery and / or related equipment; machinery and / or implements for agriculture, forestry and / or fisheries; safety and / or environment preservation equipment; tractors; precision bearings; chains; gears; power transmission equipment; lubricating equipment; valves; pipe fittings; and / or application systems for any of the previously mentioned equipment or machinery etc.).

[0275] A UE may, for example, be an item of transport equipment (for example transport equipment such as: rolling stocks; motor vehicles; motorcycles; bicycles; trains; buses; carts; rickshaws; ships and other watercraft; aircraft; rockets; satellites; drones; balloons etc.).

[0276] A UE may, for example, be an item of information and communication equipment (for example information and communication equipment such as: electronic computer and related equipment; communication and related equipment; electronic components etc.).

[0277] A UE may, for example, be a refrigerating machine, a refrigerating machine applied product, an item of trade and / or service industry equipment, a vending machine, an automatic service machine, an office machine or equipment, a consumer electronic and electronic appliance (for example a consumer electronic appliance such as: audio equipment; video equipment; a loud speaker; a radio; a television; a microwave oven; a rice cooker; a coffee machine; a dishwasher; a washing machine; a dryer; an electronic fan or related appliance; a cleaner etc.).

[0278] A UE may, for example, be an electrical application system or equipment (for example an electrical application system or equipment such as: an x-ray system; a particle accelerator; radio isotope equipment; sonic equipment; electromagnetic application equipment; electronic power application equipment etc.).

[0279] A UE may, for example, be an electronic lamp, a luminaire, a measuring instrument, an analyser, a tester, or a surveying or sensing instrument (for example a surveying or sensing instrument such as: a smoke alarm; a human alarm sensor; a motion sensor; a wireless tag etc.), a watch or clock, a laboratory instrument, optical apparatus, medical equipment and / or system, a weapon, an item of cutlery, a hand tool, or the like. A UE may, for example, be a wireless-equipped personal digital assistant or related equipment (such as a wireless card or module designed for attachment to or for insertion into another electronic device (for example a personal computer, electrical measuring machine)).

[0280] A UE may be a device or a part of a system that provides applications, services, and solutions described below, as to "internet of things (IoT)," using a variety of wired and / or wireless communication technologies.

[0281] Internet of Things devices (or "things") may be equipped with appropriate electronics, software, sensors, network connectivity, and / or the like, which enable these devices to collect and exchange data with each other and with other communication devices. IoT devices may comprise automated equipment that follow software instructions stored in an internal memory. IoT devices may operate without requiring human supervision or interaction. IoT devices might also remain stationary and / or inactive for an extended period of time. IoT devices may be implemented as a part of a (generally) stationary apparatus. IoT devices may also be embedded in non-stationary apparatus (e.g., vehicles) or attached to animals or persons to be monitored / tracked.

[0282] It will be appreciated that IoT technology can be implemented on any communication devices that can connect to a communication system for sending / receiving data, regardless of whether such communication devices are controlled by human input or software instructions stored in memory.

[0283] It will be appreciated that IoT devices are sometimes also referred to as Machine-Type Communication (MTC) devices or Machine-to-Machine (M2M) communication devices. It will be appreciated that a UE may support one or more IoT or MTC applications. Some examples of MTC applications are listed in the following table. This list is not exhaustive and is intended to be indicative of some examples of machine type communication applications.

[0284] Further, the above-described UE categories are merely examples of applications of the technical ideas and exemplary examples described in the present document. Needless to say, these technical ideas and examples are not limited to the above-described UE and various modifications can be made thereto.

[0285] Various other modifications will be apparent to those skilled in the art and will not be described in further detail here.

[0286] For example, the whole or part of the exemplary embodiments disclosed above can be described as, but not limited to, the following supplementary notes. 　　(Supplementary note 1) 　　A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, information for configuration of shared resources among a plurality of mobile devices; 　　transmitting, to the access network node, uplink data using at least one of the shared resources; and 　　monitoring a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), and 　　wherein the RNTI corresponds to one or more of the shared resources. 　　(Supplementary note 2) 　　The method according to supplementary note 1, wherein 　　the transmissing is performed by contention based data transmission. 　　(Supplementary note 3) 　　The method according to supplementary note 1 or 2, wherein 　　the one or more of the shared resources which correspond to the RNTI are included in a specific time / frequency window. 　　(Supplementary note 4) 　　The method according to any one of supplementary notes 1 to 3, wherein 　　the one or more of the shared resources which correspond to the RNTI are adjacent time and frequency resources. 　　(Supplementary note 5) 　　The method according to any one of supplementary notes 1 to 4, wherein 　　the response includes at least one of: 　　　　at least one contention resolution identifier; or 　　　　an identifier of the one or more of the shared resources. 　　(Supplementary note 6) 　　The method according to any one of supplementary notes 1 to 5, wherein 　　the response is included in a Medium Access Control (MAC) protocol data unit (PDU). 　　(Supplementary note 7) 　　The method according to supplementary note 6, wherein 　　the MAC PDU includes a plurality of responses. 　　(Supplementary note 8) 　　The method according to any one of supplementary notes 1 to 7, wherein 　　the response includes at least one of: 　　　　a random identifier for contention resolution, or 　　　　a part of the uplink data for contention resolution. 　　(Supplementary note 9) 　　The method according to any one of supplementary notes 1 to 8, further comprising: 　　in a case where the response was not detected successfully in a specific time window, retransmitting uplink data. 　　(Supplementary note 10) 　　The method according to supplementary note 9, further comprising: 　　receiving, from the access network node, information indicating a backoff time, and 　　wherein the retransmitting the uplink data is delayed based on the backoff time. 　　(Supplementary note 11) 　　The method according to supplementary note 10, wherein 　　the retransmitting the uplink data is delayed based on a value between 0 and the backoff time. 　　(Supplementary note 12) 　　The method according to any one of supplementary notes 1 to 11, further comprising: 　　determining that the transmitting the uplink data is failed; and 　　falling back to radio access channel (RACH) procedure for transmitting the uplink data. 　　(Supplementary note 13) 　　The method according to supplementary note 12, further comprising: 　　receiving, from the access network node, information indicating to fall back to the RACH procedure, and wherein 　　the falling back is performed based on the information indicating the fall back to the RACH procedure. 　　(Supplementary note 14) 　　The method according to supplementary note 12 or 13, wherein 　　the falling back is performed based on a content of the response. 　　(Supplementary note 15) 　　The method according to any one of supplementary notes 1 to 14, wherein 　　the response includes at least one of: 　　　　information indicating at least one further shared resources for further transmitting uplink data, or 　　　　information indicating at least one condition for initiating further transmitting uplink data. 　　(Supplementary note 16) 　　The method according to any one of supplementary notes 1 to 15, wherein 　　the uplink data includes information indicating that there is subsequent data transmission, and 　　the response includes the RNTI or a grant for the subsequent data transmission. 　　(Supplementary note 17) 　　The method according to any one of supplementary notes 1 to 16, wherein 　　the transmitting the uplink data is performed by Diversity Slotted Additive Links On-line Hawaii Area (ALOHA) (DSA) or Contention Resolution Diversity Slotted ALOHA (CRDSA). 　　(Supplementary note 18) 　　The method according to supplementary note 17, wherein 　　the information for configuration of the shared resources includes information indicating a time window where the mobile device selects the shared resources, 　　the at least one of the shared resources for transmitting the uplink data is included in the time window, and the method comprises: 　　transmitting at least one replica of a part of the uplink data in the time window. 　　(Supplementary note 19) 　　The method according to supplementary note 18, wherein 　　the information for configuration of the shared resources includes information indicating a number of the at least one replica for transmitting. 　　(Supplementary note 20) 　　The method according to supplementary note 18 or 19, wherein 　　the uplink data includes information indicating where the at least one replica is in the time window. 　　(Supplementary note 21) 　　The method according to any one of supplementary notes 17 to 20, further comprising: 　　receiving, from the access network node, information indicating to disable DSA / CRDSA; and 　　falling back to transmit the uplink data by normal ALOHA. 　　(Supplementary note 22) 　　A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuration of shared resources among a plurality of mobile devices; 　　receiving, from the mobile device, uplink data using at least one of the shared resources; and 　　in a case where the uplink data is received successfully, transmitting a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), and 　　wherein the RNTI corresponds to one or more of the shared resources. 　　(Supplementary note 23) 　　A mobile device comprising: 　　means for receiving, from an access network node, information for configuration of shared resources among a plurality of mobile devices; 　　means for transmitting, to the access network node, uplink data using at least one of the shared resources; and 　　means for monitoring a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), and 　　wherein the RNTI corresponds to one or more of the shared resources. 　　(Supplementary note 24) 　　An access network node comprising: 　　means for transmitting, to a mobile device, information for configuration of shared resources among a plurality of mobile devices; 　　means for receiving, from the mobile device, uplink data using at least one of the shared resources; and 　　means for transmitting a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), in a case where the uplink data is received successfully, and 　　wherein the RNTI corresponds to one or more of the shared resources.

[0287] This application is based upon and claims the benefit of priority from Great Britain Patent Application No. 2410364.0, filed on July 16, 2024, the disclosure of which is incorporated herein in its entirety by reference.

[0288] 1 COMMUNICATION SYSTEM 3 USER EQUIPMENT 5 RAN 5A BASE STATION 5B GATEWAY 7 CORE NETWORK 9 CELL 10 CONTROL PLANE FUNCTIONS 11 USER PLANE FUNCTIONS 20 EXTERNAL DATA NETWORK 31 TRANSCEIVER CIRCUIT 33 ANTENNA 35 USER INTERFACE 37 CONTROLLER 39 MEMORY 41 OPERATING SYSTEM 43 COMMUNICATIONS CONTROL MODULE 51 TRANSCEIVER CIRCUIT 51c TRANSCEIVER CIRCUIT(CU) 51d TRANSCEIVER CIRCUIT(DU) 53 ANTENNA 53d AIR INTERFACE 55 CORE NETWORK INTERFACE 55c NETWORK INTERFACE 57 CONTROLLER 57c CU CONTROLLER 57d DU CONTROLLER 59 MEMORY 59c CU MEMORY 59d DU MEMORY 61 OPERATING SYSTEM 61c CU OPERATING SYSTEM 61d DU OPERATING SYSTEM 63 COMMUNICATIONS CONTROL MODULE 63c CU COMMUNICATIONS CONTROL MODULE 63d DU COMMUNICATIONS CONTROL MODULE

Claims

1. A method performed by a mobile device, the method comprising: 　　receiving, from an access network node, information for configuration of shared resources among a plurality of mobile devices; 　　transmitting, to the access network node, uplink data using at least one of the shared resources; and 　　monitoring a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), and 　　wherein the RNTI corresponds to one or more of the shared resources.

2. The method according to claim 1, wherein 　　the transmissing is performed by contention based data transmission.

3. The method according to claim 1 or 2, wherein 　　the one or more of the shared resources which correspond to the RNTI are included in a specific time / frequency window.

4. The method according to any one of claims 1 to 3, wherein 　　the one or more of the shared resources which correspond to the RNTI are adjacent time and frequency resources.

5. The method according to any one of claims 1 to 4, wherein 　　the response includes at least one of: 　　　　at least one contention resolution identifier; or 　　　　an identifier of the one or more of the shared resources.

6. The method according to any one of claims 1 to 5, wherein 　　the response is included in a Medium Access Control (MAC) protocol data unit (PDU).

7. The method according to claim 6, wherein 　　the MAC PDU includes a plurality of responses.

8. The method according to any one of claims 1 to 7, wherein 　　the response includes at least one of: 　　　　a random identifier for contention resolution, or 　　　　a part of the uplink data for contention resolution.

9. The method according to any one of claims 1 to 8, further comprising: 　　in a case where the response was not detected successfully in a specific time window, retransmitting uplink data.

10. The method according to claim 9, further comprising: 　　receiving, from the access network node, information indicating a backoff time, and 　　wherein the retransmitting the uplink data is delayed based on the backoff time.

11. The method according to claim 10, wherein 　　the retransmitting the uplink data is delayed based on a value between 0 and the backoff time.

12. The method according to any one of claims 1 to 11, further comprising: 　　determining that the transmitting the uplink data is failed; and 　　falling back to radio access channel (RACH) procedure for transmitting the uplink data.

13. The method according to claim 12, further comprising: 　　receiving, from the access network node, information indicating to fall back to the RACH procedure, and wherein 　　the falling back is performed based on the information indicating the fall back to the RACH procedure.

14. The method according to claim 12 or 13, wherein 　　the falling back is performed based on a content of the response.

15. The method according to any one of claims 1 to 14, wherein 　　the response includes at least one of: 　　　　information indicating at least one further shared resources for further transmitting uplink data, or 　　　　information indicating at least one condition for initiating further transmitting uplink data.

16. The method according to any one of claims 1 to 15, wherein 　　the uplink data includes information indicating that there is subsequent data transmission, and 　　the response includes the RNTI or a grant for the subsequent data transmission.

17. The method according to any one of claims 1 to 16, wherein 　　the transmitting the uplink data is performed by Diversity Slotted Additive Links On-line Hawaii Area (ALOHA) (DSA) or Contention Resolution Diversity Slotted ALOHA (CRDSA).

18. The method according to claim 17, wherein 　　the information for configuration of the shared resources includes information indicating a time window where the mobile device selects the shared resources, 　　the at least one of the shared resources for transmitting the uplink data is included in the time window, and the method comprises: 　　transmitting at least one replica of a part of the uplink data in the time window.

19. The method according to claim 18, wherein 　　the information for configuration of the shared resources includes information indicating a number of the at least one replica for transmitting.

20. The method according to claim 18 or 19, wherein 　　the uplink data includes information indicating where the at least one replica is in the time window.

21. The method according to any one of claims 17 to 20, further comprising: 　　receiving, from the access network node, information indicating to disable DSA / CRDSA; and 　　falling back to transmit the uplink data by normal ALOHA.

22. A method performed by an access network node, the method comprising: 　　transmitting, to a mobile device, information for configuration of shared resources among a plurality of mobile devices; 　　receiving, from the mobile device, uplink data using at least one of the shared resources; and 　　in a case where the uplink data is received successfully, transmitting a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), and 　　wherein the RNTI corresponds to one or more of the shared resources.

23. A mobile device comprising: 　　means for receiving, from an access network node, information for configuration of shared resources among a plurality of mobile devices; 　　means for transmitting, to the access network node, uplink data using at least one of the shared resources; and 　　means for monitoring a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), and 　　wherein the RNTI corresponds to one or more of the shared resources.

24. An access network node comprising: 　　means for transmitting, to a mobile device, information for configuration of shared resources among a plurality of mobile devices; 　　means for receiving, from the mobile device, uplink data using at least one of the shared resources; and 　　means for transmitting a response to the transmitting the uplink data using a radio network temporary identifier (RNTI), in a case where the uplink data is received successfully, and 　　wherein the RNTI corresponds to one or more of the shared resources.

Images