User equipment, scheduling node, method of user equipment, and method of scheduling node - Patents.com

Abstract

The UE includes a transceiver and a circuit. The circuit determines whether there is a transmission opportunity to wait for, which is i) a transmission opportunity for transmitting at least a portion of the first data, and ii) is expected to occur as part of a procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuit initiates an RA procedure to transmit the second data using an RA resource. On the other hand, when it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuit controls the transceiver to use the transmission opportunity to transmit a traffic indication indicating detection of the second data.

Description

[Technical field]

[0001] The present disclosure relates to the transmission and reception of signals in communication systems. In particular, the present disclosure relates to methods and apparatus for such transmission and reception. [Background technology]

[0002] The 3rd Generation Partnership Project (3GPP®) is developing technical specifications for next-generation mobile phone technology, also known as the fifth generation (5G), including "New Radio" (NR) radio access technology (RAT) operating in the frequency range up to 100 GHz. NR is the successor to technologies represented by LTE (Long Term Evolution) and LTE Advanced (LTE-A).

[0003] In systems such as LTE and NR, further improvements and options may facilitate efficient operation of the communication system as well as certain devices associated with the system. [Prior art documents] [Non-patent literature]

[0004] [Non-Patent Document 1] 3GPP TS 38.300 v15.6.0 [Non-Patent Document 2] 3GPP TS 38.211 v15.6.0 [Non-Patent Document 3] 3GPP TS 38.211, v 15.7.0 [Non-Patent Document 4] ITU-R M.2083 [Non-Patent Document 5] TR 38.913 [Non-Patent Document 6] TS 23.501 v16.1.0 [Non-Patent Document 7] TS 38.212 v15.6.0 [Non-Patent Document 8] 3GPP TS 38.321 v15.8.0 [Non-Patent Document 9] TS 38.331 v15.8.0 [Non-Patent Document 10] 3GPP TS 38.321, v16.1.0 [Non-Patent Document 11] 3GPP TS 38.211 V16.2.0 [Non-Patent Document 12] TS 38.331 v16.1.0 [Non-Patent Document 13] TS 38.331, v15.12.0 Summary of the Invention [Problem to be solved by the invention]

[0005] One non-limiting, exemplary embodiment facilitates efficient handling of RA-SDT data arrival during a configured grant (CG) procedure for transmitting data in an inactive state. [Means for solving the problem]

[0006] In one embodiment, the technology disclosed herein features an apparatus (e.g., a user equipment (UE)). The apparatus includes a transceiver and a circuit. The circuit detects, during a procedure for transmitting first data of a first logical channel in an inactive state, that second data of a second logical channel is transmitted in an inactive state. The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data. The second logical channel (i) has no CG resources configured for transmitting in the inactive state, and (ii) has random access (RA) resources configured for transmitting in the inactive state. Furthermore, the circuit determines whether there is a transmission opportunity to wait for, where the transmission opportunity to wait for is a transmission opportunity i) for transmitting at least a portion of the first data, and ii) is expected to occur as part of the procedure for transmitting the first data.

[0007] Furthermore, when it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuitry initiates an RA procedure to transmit the second data using the RA resource, and when it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuitry controls the transceiver to use the transmission opportunity to transmit a traffic indication indicating detection of the second data.

[0008] It should be noted that the general or specific embodiments may be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any combination thereof.

[0009] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and drawings, and these benefits and / or advantages may be obtained individually through the various embodiments and features of the specification and drawings, and it is not necessary for all of these features to be present in order to obtain one or more of such benefits and / or advantages. [Brief description of the drawings]

[0010] Exemplary embodiments are explained in more detail below with reference to the accompanying figures and drawings. [Figure 1] 1 illustrates an example architecture of a 3GPP NR system. [Diagram 2] FIG. 1 is a schematic diagram showing the separation of functions between NG-RAN and 5GC. [Diagram 3] FIG. 1 is a sequence diagram of an RRC connection establishment / reconfiguration procedure. [Figure 4] FIG. 1 is a schematic diagram showing usage scenarios for Enhanced mobile broadband (eMBB), Massive Machine Type Communications (mMTC), and Ultra Reliable and Low Latency Communications (URLLC). [Diagram 5] FIG. 1 is a block diagram illustrating an example 5G system architecture for a non-roaming scenario. [Figure 6] 1 illustrates a contention-based RACH procedure and a contention-free RACH procedure. [Figure 7] 1 illustrates a contention-based RACH procedure and a contention-free RACH procedure. [Figure 8] Possible RRC state changes are shown. [Figure 9] 1 shows message exchange during an RRC Resume procedure. [Figure 10] 1 shows message exchange in an RRC Release procedure. [Figure 11] 1 shows message exchange in an RRC Release procedure. [Figure 12] 1 illustrates a prior art message exchange for uplink data transmission involving a UE state change from an inactive state to a connected state. [Figure 13]13A and 13B respectively show exemplary 4-step and 2-step RACHs that an RRC_INACTIVE UE can use for uplink transmission of small data. [Figure 14] 13A and 13B respectively show exemplary 4-step and 2-step RACHs that an RRC_INACTIVE UE can use for uplink transmission of small data. [Figure 15] 1 illustrates an example SDT procedure that includes one transmission of small data during the RACH procedure. [Figure 16] 1 illustrates an example SDT procedure that includes multiple transmissions of small data during a RACH procedure. [Figure 17] 1 illustrates an example SDT procedure, including transmission of small data during and after the RACH procedure. [Figure 18] FIG. 2 is a block diagram illustrating an example functional structure of a network node and a user equipment. [Figure 19] FIG. 20 is a block diagram illustrating an example functional structure of a circuit for processing the arrival of non-SDT DRB data that may be included in the example user equipment of FIG. 18. [Figure 20] 20 is a block diagram illustrating an example functional structure of a traffic indication processing circuit that may be included in the example scheduling device of FIG. 18. [Figure 21] 4 is a flow chart illustrating exemplary steps performed by a user equipment. [Figure 22] 4 is a flow chart illustrating exemplary steps performed by a network node. [Figure 23] 1 illustrates the different times when non-SDT data arrives during the SDT procedure. [Figure 24] 4 is a flow chart illustrating exemplary steps performed by a user equipment. [Diagram 25] 13 illustrates an example structure of an Msg3 message including a MAC subframe with a subheader indicating the arrival of a non-SDT DRB and no CE. [Figure 26] 13 illustrates an exemplary structure of an Msg3 message, including a MAC subframe that includes a subheader indicating the arrival of a non-SDT DRB and a CE indicating the buffer size of the SDT DRB data. [Figure 27] An exemplary structure of a MAC CE for indicating the buffer size of a logical channel group (top row) and an exemplary structure of a MAC CE for indicating the buffer size of a logical channel group and indicating the arrival of non-SDT DRB data (bottom row) are shown. [Figure 28] FIG. 2 is a block diagram illustrating an example functional structure of a network node and a user equipment. [Figure 29] FIG. 30 is a block diagram illustrating an example functional structure of a circuit for processing the arrival of non-SDT DRB data that may be included in the example user equipment of FIG. 28. [Diagram 30] 30 is a block diagram illustrating an example functional structure of a traffic indication processing circuit that may be included in the example scheduling device of FIG. 28. [Diagram 31] 4 is a flow chart illustrating exemplary steps performed by a user equipment. [Diagram 32] 4 is a flow chart illustrating exemplary steps performed by a network node. [Diagram 33] 1 illustrates an example logical channel configuration for a UE. [Diagram 34] FIG. 2 is a schematic diagram showing the arrival of RA-SDT traffic. [Diagram 35] FIG. 1 is a schematic diagram illustrating an exemplary processing of RA-SDT traffic arrival. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] <5G NR system architecture and protocol stack> 3GPP is working on the next release of fifth-generation cellular technology (known simply as 5G), which includes the development of a new radio access technology (NR) that will operate in frequencies up to 100 GHz. The first version of the 5G standard will be completed at the end of 2017, which will allow smartphones compliant with the 5G NR standard to proceed to testing and commercial deployment.

[0012] In particular, the overall system architecture envisages an NG-RAN (Next Generation - Radio Access Network) with gNBs, which terminate NG radio access user plane (SDAP / PDCP / RLC / MAC / PHY) and control plane (RRC) protocols towards the UEs. The gNBs are interconnected with each other by an Xn interface. Furthermore, the gNBs are connected to an NGC (Next Generation Core) by a Next Generation (NG) interface, more specifically to an AMF (Access and Mobility Management Function) (e.g. a specific core entity running AMF) by an NG-C interface, and to a UPF (User Plane Function) (e.g. a specific core entity running UPF) by an NG-U interface. Figure 1 shows the architecture of an NG-RAN (see, for example, section 4 of Non-Patent Document 1).

[0013] The user plane protocol stack in NR (see, for example, section 4.4.1 of 3GPP) includes the PDCP (Packet Data Convergence Protocol, see section 6.4 of 3GPP), RLC (Radio Link Control, see section 6.3 of 3GPP), and MAC (Medium Access Control, see section 6.2 of 3GPP), which are terminated in the gNB on the network side. In addition, a new sublayer of the access stratum (AS), SDAP (Service Data Adaptation Protocol), is introduced on top of PDCP (see, for example, section 6.5 of 3GPP). A control plane protocol stack is also defined in NR (see, for example, section 4.4.2 of 3GPP). An overview of the functions of Layer 2 is given in section 6 of 3GPP. The functions of the PDCP sublayer, the RLC sublayer, and the MAC sublayer are respectively described in clauses 6.4, 6.3, and 6.2 of 3GPP TS 215.114, and the functions of the RRC layer are described in clause 7 of 3GPP TS 215.114.

[0014] The Medium Access Control (MAC) layer handles, for example, logical channel multiplexing and scheduling and scheduling-related functions (including handling of various numerologies).

[0015] The physical layer (PHY) is responsible for, for example, coding, PHY HARQ processing, modulation, multi-antenna processing, mapping of signals to appropriate physical time-frequency resources. Furthermore, the physical layer (PHY) handles mapping of transport channels to physical channels. The physical layer (PHY) provides services to the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for the transmission of a particular transport channel, and each transport channel is mapped to a corresponding physical channel. For example, the physical channels are PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel) for the uplink, and PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel) for the downlink.

[0016] NR use cases / deployment scenarios include enhanced Mobile Broadband (eMBB), ultra-reliable and low latency communications (URLLC), and massive machine type communications (mMTC), which have diverse requirements in terms of data rates, latency, and coverage. For example, eMBB is expected to support peak data rates (20 Gbps downlink and 10 Gbps uplink) and user-perceived data rates that are on the order of three times higher than those offered by IMT-Advanced. In contrast, URLLC has more stringent requirements, including extremely low latency (user plane latency of 0.5 ms for uplink and downlink, respectively) and high reliability (1-10 Mbps within 1 ms). -5) is imposed. In addition, mMTC requires high connection density (1 km 2 1,000,000 devices per second), wide coverage in harsh environments, and extremely long battery life (15 years) to lower device costs may be desirable.

[0017] Thus, an OFDM numerology (e.g., subcarrier spacing, OFDM symbol duration, cyclic prefix (CP) duration, number of symbols per scheduling interval) suitable for one use case may not work well for another use case. For example, low latency services may preferably require a shorter symbol duration (and therefore a larger subcarrier spacing) and / or fewer symbols per scheduling interval (also referred to as TTI) than mMTC services. Furthermore, deployment scenarios with large channel delay spreads may preferably require a longer cyclic prefix (CP) duration than scenarios with small delay spreads. To maintain a similar cyclic prefix (CP) overhead, the subcarrier spacing should be optimized depending on the delay spread. In NR, more than one value of subcarrier spacing may be supported. Thus, currently, subcarrier spacings of 15 kHz, 30 kHz, 60 kHz, ... are considered. Symbol duration T u and the subcarrier spacing Δf is expressed by the formula Δf=1 / T u As in LTE systems, the term "resource element" can be used to denote the smallest resource unit consisting of one subcarrier for the length of one OFDM / SC-FDMA symbol.

[0018] In the new radio system 5G NR, for each numerology and carrier, a resource grid of subcarriers and OFDM symbols is defined for both the uplink and the downlink. Each element within the resource grid is called a resource element and is identified based on the frequency index in the frequency domain and the symbol position in the time domain (see Non-Patent Document 2). For example, the transmissions in the downlink and uplink are organized into frames with a duration of 10 ms, and each frame is composed of 10 subframes with a duration of 1 ms each. In the implementation of 5G NR, the number of consecutive OFDM symbols per subframe depends on the setting of the subcarrier spacing. For example, when the subcarrier spacing is 15 kHz, one subframe has 14 OFDM symbols (similar to an LTE-compliant implementation assuming a normal cyclic prefix). On the other hand, when the subcarrier spacing is 30 kHz, the subframe has two slots, and each slot contains 14 OFDM symbols.

[0019] When compared with the numerology (subcarrier spacing and symbol length) of LTE, in NR, multiple different types of subcarrier spacings labeled by the parameter μ are supported (in LTE, only a subcarrier spacing of 15 kHz exists, which corresponds to μ = 0 in NR). The types of NR numerology are summarized in Non-Patent Document 3.

[0020] <Split of 5G NR Functions between NG-RAN and 5GC> Figure 2 shows the split of functions between NG-RAN and 5GC. The logical nodes of NG-RAN are gNB or ng-eNB. The logical nodes of 5GC are AMF, UPF, and SMF.

[0021] gNB and ng-eNB handle the following main functions in particular. - Radio Resource Management functions, such as Radio Bearer Control, Radio Admission Control, Connection Mobility Control, dynamic resource allocation (scheduling) to UEs in both uplink and downlink directions - IP header compression, encryption, and data integrity protection - Selection of AMF at UE attach time when routing to AMF cannot be determined from information provided by the UE - Routing user plane data to the UPF - Routing control plane information to AMF - Establishing and releasing connections - Scheduling and sending paging messages - Scheduling and transmission of system broadcast information (from AMF or OAM) - Configuring measurements and measurement reporting for mobility and scheduling - Transport-level packet marking in the uplink - Session Management - Network slicing support - QoS flow management and mapping to data radio bearers - Support for UEs in RRC_INACTIVE state - NAS message delivery function - Wireless Access Network Sharing - Dual Connection - Tight interworking between NR and E-UTRA

[0022] The Access and Mobility Management Function (AMF) handles the following main functions: - Termination of Non-Access Stratum (NAS) signalling - NAS signaling security - Access Stratum (AS) security control - Core Network (CN) inter-node signaling for mobility between 3GPP access networks - Idle mode UE reachability (including control and execution of paging retransmissions) - Registration Area Management - Support for intra-system and inter-system mobility - Access Authentication - Access authentication, including roaming rights checks - Mobility management controls (subscriptions and policies) - Network slicing support - Selection of Session Management Function (SMF)

[0023] In addition, the User Plane Function (UPF) handles the following main functions: - Anchor points for intra-RAT / inter-RAT mobility (when applicable) - External PDU session points for interconnection with data networks - Packet routing and forwarding - User plane part of packet inspection and policy rule enforcement - Traffic usage reports - An uplink classifier to support routing of traffic flows to the data network. - Branching points to support multi-homed PDU sessions - User plane QoS processing (e.g. packet filtering, gating, UL / DL rate enforcement) - Validation of uplink traffic (mapping of SDF to QoS flows) - Buffering of downlink packets and triggering of downlink data notifications

[0024] Finally, the Session Management Function (SMF) processes the following main functions. - Session management - Allocation and management of UE IP addresses - Selection and control of the UP function - Configuration of traffic steering in the User Plane Function (UPF) to route traffic to the correct destination - Policy enforcement and QoS control part - Downlink data notification

[0025] <Procedures for establishment and reconfiguration of RRC connection> Figure 3 shows some interactions between the UE, gNB, and AMF (5GC entity) when the UE transitions from RRC_IDLE to RRC_CONNECTED in the NAS part (see Non-Patent Document 1).

[0026] RRC is a higher layer signaling (protocol) used for the configuration of the UE and the gNB. In particular, in this transition, the AMF creates the UE context data (including e.g. PDU session context, security keys, UE radio capabilities, UE security capabilities, etc.) and sends it to the gNB via an INITIAL CONTEXT SETUP REQUEST. The gNB then activates AS security with the UE, which is performed by the gNB sending a SecurityModeCommand message to the UE and the UE responding with a SecurityModeComplete message to the gNB. The gNB then performs a reconfiguration to establish the signaling radio bearer 2 (SRB2) and data radio bearer (DRB), which is performed by the gNB sending an RRCReconfiguration message to the UE and the gNB receiving an RRCReconfigurationComplete from the UE in response. In the case of a signaling-only connection, these steps related to RRCReconfiguration are skipped since SRB2 and DRB are not established. Finally, the gNB notifies the AMF that the establishment procedure is complete via an INITIAL CONTEXT SETUP RESPONSE.

[0027] Therefore, the present disclosure provides a 5th Generation Core (5GC) entity (e.g., AMF, SMF, etc.), comprising: a control circuit for establishing a next generation (NG) connection with a gNodeB in operation; and a transmitter for transmitting an initial context configuration message to the gNodeB via the NG connection to establish a signaling radio bearer between the gNodeB and a user equipment (UE) in operation. Specifically, the gNodeB transmits RRC (Radio Resource Control) signaling including a resource allocation configuration information element to the UE via the signaling radio bearer. The UE performs uplink transmission or downlink reception based on the resource allocation configuration.

[0028] <IMT usage scenarios after 2020> Figure 4 shows some of the use cases for 5G NR. The 3GPP (3rd Generation Partnership Project) New Radio (3GPP NR) considers three envisioned use cases to support various services and applications with IMT-2020. The specifications for Phase 1 of Enhanced Mobile Broadband (eMBB) have been finalized. Current and upcoming work includes the standardization of Ultra-Reliable and Low-Latency Communications (URLLC) and Large-Scale Machine-Type Communications, in addition to further extending support for eMBB. Figure 4 shows some examples of envisioned usage scenarios for IMT beyond 2020 (see, for example, Figure 2 in Non-Patent Document 4).

[0029] URLLC use cases have stringent requirements on capabilities such as throughput, latency and availability, and are envisioned as one of the enablers of future vertical applications such as wireless control of industrial manufacturing and production processes, remote medical surgery, power distribution automation in smart grids, and transportation safety. URLLC's ultra-high reliability is supported by identifying technologies to meet the requirements set by NR URLLC in Release 15. For NR URLLC in Release 15, the main requirements include a target user plane latency of 0.5 ms on the UL (uplink) and 0.5 ms on the DL (downlink). The general URLLC requirement for a single transmission of a packet is a BLER (block error rate) of 1E-5 for a packet size of 32 bytes with a user plane latency of 1 ms.

[0030] From a physical layer perspective, there are several possible ways to improve reliability. Current scope for improving reliability includes the definition of a separate CQI table for URLLC, more compact DCI formats, PDCCH repetition, etc. However, as NR becomes more stable and developed (for a key requirement of NR URLLC), the scope for achieving ultra-high reliability may increase. Specific use cases for NR URLLC in Release 15 include augmented reality / virtual reality (AR / VR), eHealth, eSafety, and mission-critical applications.

[0031] Furthermore, technology enhancements targeted by NR URLLC target latency improvement and reliability improvement. Technology enhancements for latency improvement include configurable numerology, non-slot-based scheduling with flexible mapping, grant-free (configured grant) uplink, slot-level repetition of data channel, and downlink preemption. Preemption means that a transmission for which resources are already allocated is aborted and the already allocated resources are used for another transmission with smaller latency / higher priority requirement requested later. Thus, an already granted transmission is preempted by a later transmission. Preemption applies regardless of service type. For example, a transmission of service type A (URLLC) can be preempted by a transmission of service type B (eMBB, etc.). Technology enhancements related to reliability improvement include dedicated CQI / MCS tables for a target BLER of 1E-5.

[0032] The mMTC (Massive Machine Type Communication) use case is characterized by a very large number of connected devices transmitting relatively small amounts of data that are generally not sensitive to latency. The devices are required to be low cost and have extremely long battery life. From an NR perspective, utilizing very narrow bandwidth portions is one possible solution to achieve power saving from the UE perspective to enable long battery life.

[0033] As mentioned above, it is expected that the scope of reliability in NR will expand. One key requirement for all cases, especially for URLLC and mMTC, is high or ultra-high reliability. Several mechanisms can be considered to improve reliability from a radio perspective and from a network perspective. In general, there are several key areas that can help improve reliability. These areas include compact control channel information, data channel / control channel repetition, diversity related to frequency domain, time domain, and / or spatial domain. These areas are generally applicable to reliability, regardless of the specific communication scenario.

[0034] For NR URLLC, further use cases with more stringent requirements have been identified, such as factory automation, transportation, and power distribution. The more stringent requirements include higher reliability (up to 10 times faster) depending on the use case. -6 These include: high-speed, low latency, high-speed (high-speed), higher availability, packet sizes up to 256 bytes, time synchronization to the order of a few microseconds (values ​​range from 1 μs to a few μs depending on the frequency range), and low latency in the order of 0.5-1 ms, with a target user plane latency of 0.5 ms in particular.

[0035] Furthermore, for NR URLLC, several technical enhancements have been identified from the physical layer perspective. In particular, enhancements related to the PDCCH (Physical Downlink Control Channel) include compact DCI, PDCCH repetition, and increased PDCCH monitoring. Also, enhancements related to the UCI (Uplink Control Information) include HARQ (Hybrid Automatic Repeat Request) enhancements and CSI feedback enhancements. Also, PUSCH enhancements related to minislot level hopping and retransmission / repetition enhancements have been recognized. The term "minislot" refers to a TTI (Transmission Time Interval) that contains fewer symbols than a slot (a slot contains 14 symbols).

[0036] <QoS Control> The 5G QoS (Quality of Service) model is based on QoS flows and supports both QoS flows that require a guaranteed flow bit rate (GBR QoS flows) and QoS flows that do not require a guaranteed flow bit rate (non-GBR QoS flows). Therefore, at the NAS level, a QoS flow is the finest granularity of QoS differentiation in a PDU session. A QoS flow is identified within a PDU session by a QoS flow ID (QFI) that is carried in the encapsulation header through the NG-U interface.

[0037] The 5GC establishes one or more PDU sessions per UE. The NG-RAN can establish at least one data radio bearer (DRB) per UE together with the PDU session and then configure additional DRBs for the QoS flows of that PDU session as described above, for example with reference to Figure 3 (when to configure is determined by the NG-RAN). The NG-RAN maps packets belonging to different PDU sessions to different DRBs. UL and DL packets are associated with QoS flows by NAS-level packet filters in the UE and 5GC, and UL and DL QoS flows are associated with DRBs by AS-level mapping rules in the UE and NG-RAN.

[0038] Figure 5 shows the non-roaming reference architecture for 5G NR (see section 4.23 of 3GPP 6). Application Functions (AFs) (e.g., external application servers handling 5G services exemplarily described in Figure 4) interact with the 3GPP core network to provide services. For example, they support application influence on traffic routing, access Network Exposure Functions (NEFs), and interact with a policy framework (see Policy Control Function (PCF)) for policy control (e.g., QoS control). Based on the operator's deployment, application functions (AFs) that are considered trusted by the operator can be allowed to interact directly with the relevant network functions (Network Functions). Application functions (AFs) that are not allowed by the operator to directly access network functions interact with the relevant network functions using an external exposure framework via the NEF.

[0039] Figure 5 shows further functional units of the 5G architecture: Network Slice Selection Function (NSSF), Network Repository Function (NRF), Unified Data Management (UDM), Authentication Server Function (AUSF), Access and Mobility Management Function (AMF), Session Management Function (SMF), and Data Network (DN) (e.g. operator's services, internet access, or third-party services). All or part of the core network functions and application services may be located and executed in a cloud computing environment.

[0040] Thus, in the present disclosure, an application server (e.g., an AF in a 5G architecture) is provided which comprises: a transmitter which, when operated, sends a request including QoS requirements for at least one of a URLLC service, an eMBB service, and an mMTC service to at least one of the 5GC functions (e.g., a NEF, an AMF, an SMF, a PCF, an UPF, etc.) to establish a PDU session including a radio bearer between a gNodeB and a UE in accordance with the QoS requirements; and a control circuit which, when operated, performs a service using the established PDU session.

[0041] <Control signal> In this disclosure, the downlink control signal (information) related to this disclosure may be a signal (information) transmitted via a PDCCH of a physical layer, or may be a signal (information) transmitted via a MAC control element (CE) or RRC of a higher layer. The downlink control signal may be a predefined signal (information).

[0042] The uplink control signal (information) related to the present disclosure may be a signal (information) transmitted via a PUCCH of the physical layer, or may be a signal (information) transmitted via a MAC CE or RRC of a higher layer. Furthermore, the uplink control signal may be a predefined signal (information). The uplink control signal may be replaced by uplink control information (UCI), 1st stage sidelink control information (SCI), or 2nd stage SCI.

[0043] <Device> A terminal or user terminal or user device or mobile station or mobile node is called user equipment (UE) in LTE and NR. A user equipment (UE) may be a mobile device or communication device, such as a wireless telephone, a smartphone, a tablet computer, or a USB (Universal Serial Bus) stick with user equipment functionality. However, the term mobile device is not limited thereto, and in general, a repeater may also have such mobile device functionality, and a mobile device may act as a repeater. For example, a terminal is a physical entity (physical node) in a communication network. Furthermore, a communication device may be any machine-type communication device, such as an IoT device. A node may have several functional entities. A functional entity refers to a software or hardware module that implements a given set of functions and / or provides a given set of functions to other functional entities of the same node or another node or network. A node may have one or more interfaces that attach itself to a communication facility or medium, through which the node may communicate. Similarly, a network entity may have logical interfaces that attach functional entities to communication facilities or media through which the functional entities may communicate with other functional entities or corresponding nodes.

[0044] <Base station> In the present disclosure, the base station may be, for example, a Transmission Reception Point (TRP), a cluster head, an access point, a Remote Radio Head (RRH), an eNodeB (eNB), a gNodeB (gNB), a base station (BS), a base transceiver station (BTS), a base unit, or a gateway. Furthermore, in sidelink communication, a terminal may be employed instead of a base station. The base station may be a relay device that relays communication between an upper node and a terminal. The base station may be a roadside unit. The base station may be, for example, a scheduling node or a network node that forms part of a network for providing services to terminals. In particular, the base station may provide wireless access to the terminal. The communication between the terminal and the base station is generally standardized and may be defined by different layers such as PHY, MAC, RRC, etc. In LTE and NR, the air interface protocol stack includes a physical layer, a medium access layer (MAC), and an upper layer. The control plane is provided with a radio resource control protocol, which is an upper layer protocol. Through RRC, the base station can control the configuration of the terminals and the terminals can communicate with the base station to perform control tasks such as establishing and modifying connections and bearers, measurements and other functions. The terminology used in LTE is eNB (or eNodeB) and the terminology currently used in 5G NR is gNB. The term base station or radio base station here refers to a physical entity in a communication network. Similar to a mobile station, a base station can have several functional entities. A functional entity refers to a software or hardware module that implements a given set of functions and / or provides a given set of functions to other functional entities of the same node or another node or network. The physical entity performs several control tasks for the communication device, including one or more of scheduling and configuration.It should be noted that the base station functionality and the communication device functionality may be integrated in a single device. For example, a mobile terminal may also perform the base station functionality for other terminals. The terminology used in LTE is eNB (or eNodeB) and the terminology currently used in 5G NR is gNB.

[0045] <Uplink / Downlink / Sidelink> The present disclosure can be applied to any of the uplink, downlink, and sidelink.

[0046] The present disclosure may be applied to, for example, uplink channels such as PUSCH, PUCCH, and PRACH, downlink channels such as PDSCH, PDCCH, and PBCH, and sidelink channels such as the Physical Sidelink Shared Channel (PSSCH), the Physical Sidelink Control Channel (PSCCH), and the Physical Sidelink Broadcast Channel (PSBCH).

[0047] The PDCCH, PDSCH, PUSCH, and PUCCH are examples of a downlink control channel, a downlink data channel, an uplink data channel, and an uplink control channel, respectively. The PSCCH and PSSCH are examples of a sidelink control channel and a sidelink data channel, respectively. The PBCH and PSBCH are examples of a broadcast channel, and the PRACH is an example of a random access channel.

[0048] <Data Channel / Control Channel> The present disclosure can be applied to both data channels and control channels. The channels in the present disclosure can be replaced with data channels including PDSCH, PUSCH, and PSSCH, and / or control channels including PDCCH, PUCCH, PBCH, PSCCH, and PSBCH.

[0049] <Reference signal> In this disclosure, a reference signal is a signal known to both a base station and a mobile station, and each reference signal may be referred to as a Reference Signal (RS) or sometimes a pilot signal. A reference signal may be any of a DMRS, a Channel State Information - Reference Signal (CSI-RS), a Tracking Reference Signal (TRS), a Phase Tracking Reference Signal (PTRS), a Cell-specific Reference Signal (CRS), and a Sounding Reference Signal (SRS).

[0050] <time interval> In the present disclosure, the unit of time resource is not limited to one or a combination of slots and symbols, and may be a time resource unit such as a frame, a superframe, a subframe, a slot, a time slot subslot, a minislot, or a time resource unit such as a symbol, an Orthogonal Frequency Division Multiplexing (OFDM) symbol, a Single Carrier-Frequency Division Multiplexing Access (SC-FDMA) symbol, or another time resource unit. The number of symbols included in one slot is not limited to the number exemplified in the above-mentioned embodiment, and may be another number of symbols.

[0051] <Frequency band> The present disclosure may be applied to both licensed and unlicensed bands.

[0052] <Communication> The present disclosure can be applied to any of communication between a base station and a terminal (Uu link communication), communication between terminals (sidelink communication), and communication between a vehicle and some entity (V2X: Vehicle to Everything). The channels in the present disclosure can be replaced with PSCCH, PSSCH, Physical Sidelink Feedback Channel (PSFCH), PSBCH, PDCCH, PUCCH, PDSCH, PUSCH, and PBCH.

[0053] Furthermore, the present disclosure can be applied to any of terrestrial networks or non-terrestrial networks (NTN: Non-Terrestrial Network) that use satellites or High Altitude Pseudo Satellites (HAPS). Furthermore, the present disclosure may be applied to networks with large cell sizes or terrestrial networks with large delays compared to the symbol length or slot length, such as ultra-wideband transmission networks.

[0054] <Antenna port> An antenna port refers to a logical antenna (antenna group) formed from one or more physical antennas. In other words, an antenna port does not necessarily refer to one physical antenna, but may refer to an array antenna formed from multiple antennas. For example, the number of physical antennas forming an antenna port is not defined, and instead, the smallest unit by which a terminal can transmit a reference signal is defined as an antenna port. An antenna port may also be defined as the smallest unit for multiplication of a precoding vector weighting.

[0055] <Downlink control channel monitoring, PDCCH, DCI> Many of the functions performed by a UE involve monitoring a downlink control channel (eg, PDCCH, see 3GPP TS 2003-011334, section 5.2.3) for example to receive specific control information or data intended for the UE.

[0056] Below is a non-exhaustive list of such features: - Paging message monitoring function, - System information acquisition function, - signalling supervision operation in discontinuous reception (DRX) functionality; - inactivity monitoring operation in the discontinuous reception (DRX) function; - receiving a random access response in a random access function; - Packet Data Convergence Protocol (PDCP) layer reordering function

[0057] As described above, the PDCCH is monitored by the UE to identify and receive information intended for the UE, such as control information and user traffic (e.g., DCI on the PDCCH, user data on the PDSCH indicated by the PDCCH).

[0058] The control information in the downlink (which can be called Downlink Control Information, DCI) has the same purpose in 5G NR as DCI in LTE, i.e. it is a set of special control information for scheduling, for example, a downlink data channel (e.g. PDSCH) or an uplink data channel (e.g. PUSCH). In 5G NR, many different DCI formats have already been defined (see 3GPP TS 2013-01011, section 7.3.1).

[0059] These DCI formats represent a predetermined format in which each piece of information is formed and transmitted. In particular, DCI formats 0_1 and 1_1 are each used to schedule PUSCH and PDSCH in one cell.

[0060] PDCCH monitoring in each of these functions serves a specific purpose and is thus initiated for that purpose. PDCCH monitoring is generally controlled based at least on a timer that the UE operates. The timer has the purpose of controlling PDCCH monitoring, for example, limiting the maximum time length for which the UE monitors the PDCCH. For example, the UE does not need to monitor the PDCCH indefinitely and can stop monitoring after a certain time to save power.

[0061] As described above, one of the purposes of DCI in the PDCCH is to dynamically schedule resources in the downlink, uplink, or sidelink. In particular, some formats of DCI are provided to convey an indication (resource allocation, RA) of the resources allocated to a data channel for a specific user. The resource allocation can include the specification of resources in the frequency domain and / or time domain.

[0062] <UE Identification> RNTI is an abbreviation for Radio Network Temporary Identifier. For example, RNTI can be used to distinguish and identify UEs within a radio cell. Furthermore, RNTI can also identify a specific radio channel, a group of UEs in the case of paging, a group of UEs for which power control is issued by the eNB, and the system information transmitted to all UEs by the 5G gNB. In 5G NR, many different identification information for UEs is defined, and some of them are shown in the following table (see Section 7.1 of Non-Patent Document 8).

Table 1

[0063] Besides the RNTIs shown above, there may be further IDs such as Inactive-RNTI (I-RNTI) (see e.g. section 6.3.2 of 3GPP TS 2013-0101626). Inactive-RNTI is used for UEs in RRC_INACTIVE state, e.g. in the process of identifying and locating suspended UE contexts of the UE. According to one implementation, the network assigns an I-RNTI (e.g. as part of the RRCRelease message in SuspendConfig) when the UE transitions to RRC_INACTIVE state (e.g. from RRC_CONNECTED). There are two types of I-RNTI: full I-RNTI and short I-RNTI. The network can inform the UE (e.g. as part of SIB1 (System Information Block 1)) which I-RNTI to use when resuming the connection. The full I-RNTI is a bit string of length 40 bits and the short I-RNTI is a bit string of length 24 bits.

[0064] <Random access procedure> Similar to LTE, 5G NR provides a Random Access Channel (RACH) procedure (or simply random access procedure). For example, the RACH procedure can be used by a UE to access a discovered cell. The RACH procedure can also be used in other contexts within NR, for example: During handover, when establishing synchronization to a new cell Re-establishing uplink synchronization to the current cell if synchronization is lost due to too long a period of no uplink transmissions from the device Requests uplink scheduling if the device does not have a dedicated scheduling request resource

[0065] There are many events that may trigger a UE to perform a random access procedure (see section 9.2.6 of 3GPP TS 2.0), including the following: The random access procedure is triggered by a number of events. - First access from RRC_IDLE - RRC connection re-establishment procedure - DL or UL data arrives during RRC_CONNECTED when the UL synchronization state is "asynchronous" - UL data arrives at RRC_CONNECTED when no PUCCH resources for SR are available - SR Failure - Required by RRC during synchronous reconfiguration (e.g. handover) - Transition from RRC_INACTIVE - Establish time alignment for secondary TAGs - Other SI requirements (see section 7.3) - Beam failure recovery - UL LBT fails continuously on SpCell

[0066] If the mobile terminal's uplink transmission is time synchronized, the mobile terminal can be scheduled for uplink transmission. Thus, the Random Access Channel (RACH) procedure serves as an interface between unsynchronized mobile terminals (UEs) and orthogonal transmission of uplink radio access. Random access is used, for example, to achieve uplink time synchronization for user equipment that has not yet acquired or lost uplink synchronization. Once the user equipment acquires uplink synchronization, the base station can schedule uplink transmission resources for the user equipment. One scenario related to random access is when a user equipment in RRC_CONNECTED state hands over from a current serving cell to a new target cell and performs a random access procedure to achieve uplink time synchronization in the target cell.

[0067] There are at least two types of random access procedures: those that allow access on a contention basis (i.e., inherently with the risk of collisions) and those that allow access without contention (non-contention based). An exemplary definition of a random access procedure is given in Section 5.1 of 3GPP TS 2010-01-13211.

[0068] The RACH procedure will now be described in more detail with reference to Figures 6 and 7. In the following, the contention-based random access procedure will be described in more detail with reference to Figure 6. This procedure consists of four "steps" and can therefore be referred to as, for example, a four-step RACH procedure. First, the user equipment transmits a random access preamble to the base station on the Physical Random Access Channel (PRACH) (i.e., message 1 of the RACH procedure). After detecting the RACH preamble, the base station transmits a Random Access Response (RAR) message (message 2 of the RACH procedure) on the Physical Downlink Shared Channel (PDSCH) addressed on the PDCCH with the (random access) RA-RNTI that identifies the time frequency and slot where the preamble was detected. If multiple user equipments transmit the same RACH preamble on the same PRACH resource (also called collision), they will receive the same random access response message. The RAR message may convey the detected RACH preamble, a Timing Alignment Command (TA command) for synchronization of subsequent uplink transmissions based on the timing of the received preamble, an initial uplink resource allocation (grant) for sending the first scheduled transmission, and the allocation of a Temporary Cell Radio Network Temporary Identifier (T-CRNTI) that is used by the base station to address the mobile for which the RACH preamble was detected until the RACH procedure is finished, since at this point the base station does not know the "real" identity of the mobile.

[0069] The user equipment monitors the PDCCH to receive a random access response message within a predefined time window (e.g., called the RAR reception window), which may be set by the base station. In response to the RAR message received from the base station, the user equipment transmits a first scheduled uplink transmission on the radio resources allocated by the grant in the random access response. This scheduled uplink transmission carries the actual message with a specific function, such as an RRC connection request, an RRC resume request, or a buffer status report.

[0070] If a preamble collision occurs in the first message of the RACH procedure (i.e. multiple user equipments transmit the same preamble on the same PRACH resource), the colliding user equipments receive the same T-CRNTI in the random access response and collide on the same uplink resource when transmitting their scheduled transmissions in the third step of the RACH procedure. If the scheduled transmission from one user equipment is successfully decoded by the base station, the contention remains unresolved for the other user equipments. To resolve this type of contention, the base station transmits a contention resolution message (fourth message) addressed to the C-RNTI or temporary C-RNTI. This ends the procedure.

[0071] Figure 7 shows a contention-free random access procedure, which is simplified compared to the contention-based random access procedure. In a first step, the base station provides the user equipment with a dedicated preamble to be used for random access, so that there is no risk of collision (i.e., multiple user equipments transmit the same preamble). The user equipment then transmits the preamble signaled by the base station in the uplink on the PRACH resource. Since contention-free random access avoids the case where multiple UEs transmit the same preamble, the contention-free random access procedure is essentially completed after the random access response is successfully received by the UE.

[0072] 3GPP also defines a two-step (contention-based) RACH procedure for 5G NR, in which message 1 (called MsgA), which corresponds to messages 1 and 3 in the four-step LTE / NR RACH procedure, is transmitted first. MsgA of this two-step RACH type contains a preamble on the physical random access channel (PRACH) and a payload on the physical uplink shared channel (PUSCH). After transmitting MsgA, the UE monitors for a response from the gNB within a configured time window. The gNB then responds with message 2 (called MsgB), which corresponds to messages 2 and 4 of the four-step LTE / NR RACH procedure. This MsgB may contain, for example, a successful random access response (RAR), a fallback RAR, and optionally a backoff indication. If the UE receives a successful RAR and successfully resolves the contention, it terminates the random access procedure. On the other hand, if it receives a fallback RAR in MsgB, the UE performs the transmission of message 3 (similar to the four-step RACH procedure) and monitors the contention resolution. Some further exemplary assumptions are made for the two-step RACH procedure, for example, the UE, after determining the RACH type (e.g., two-step RACH), continues to retry the same RACH type until it fails, however, it may be possible for the UE to switch to the four-step RACH procedure after retrying the transmission of MsgA a certain number of times.

[0073] Furthermore, the mutually exclusive radio resources used to perform the two-step RACH procedure and the four-step RACH procedure can be semi-statically determined by the network. The radio resources used for transmitting the first message in the RACH procedure include at least a RACH opportunity and a preamble. For example, in the two-step RACH procedure, the first message MsgA uses not only the PRACH resource (e.g., the RACH opportunity and the preamble) but also the associated PUSCH resource.

[0074] Generally, for the RACH preamble, refer to, for example, "Table 6.3.3.2-2: Random access configurations for FR1 and paired spectrum / supplementary uplink" and Section 6.3.3.2 "Mapping to physical resources" in Non-Patent Document 11.

[0075] <RRC state (RRC_Connected, RRC_Inactive, RRC Idle)> In LTE, the RRC state machine consists of only two states: the RRC idle state (characterized mainly by high power saving, UE autonomous mobility, and no established UE connection to the core network), and the RRC connected state. In the RRC connected state, the UE can transmit user plane data while mobility is controlled by the network to support lossless service continuity. In 5G NR, the RRC state machine related to LTE can be extended by the inactive state (refer to Figures 4.2.1-1 and 4.2.1-2 in Non-Patent Document 12), as described below.

[0076] In RRC in NR 5G (refer to Section 4 of Non-Patent Document 12), the following three states are supported: RRC Idle, RRC Inactive, and RRC Connected. When the RRC connection is established, the UE is in either the RRC_CONNECTED state or the RRC_INACTIVE state. Otherwise, i.e., when the RRC connection is not established, the UE is in the RRC_IDLE state. As shown in Figure 8, the following state transitions are possible. · From RRC_IDLE to RRC_CONNECTED, for example, following the "connection establishment" procedure · From RRC_CONNECTED to RRC_IDLE, for example, following the "connection release" procedure For example, from RRC_CONNECTED to RRC_INACTIVE according to the "Suspend Connection Release" procedure. For example, following the "restart connection" procedure from RRC_INACTIVE to RRC_CONNECTED For example, from RRC_INACTIVE to RRC_IDLE (unidirectional) following the "Connection Release" procedure.

[0077] The new RRC state, RRC Inactive, has been defined for 5G 3GPP new radio technologies such as eMBB (enhanced Mobile Broadband), mMTC (Massive Machine Type Communications), URLLC (Ultra Reliable and Low Latency Communications) etc., which provide benefits when supporting a wide range of services with very different requirements in terms of signaling, power saving, latency etc. The new RRC Inactive state is therefore designed to minimize signaling, power consumption and resource costs in the radio access network and core network while still allowing, for example, data transfer to be initiated with low latency.

[0078] According to an exemplary implementation of 5G NR, these different states are characterized as follows (see section 4.2.1 of 3GPP TS 2012-010363): "RRC_IDLE" - UE-specific DRX can be configured by higher layers - UE controlled mobility based on network configuration - UE - monitor short messages sent using the P-RNTI over the DCI (see clause 6.5); - Monitoring the paging channel in CN paging using 5G-S-TMSI - Perform neighboring cell measurements and cell (re)selection - Able to get system information and send SI requests (if configured). - Perform logging of available measurements along with the location and time of the logged measurements configured UE - RRC_INACTIVE UE-specific DRX can be configured by higher layers or by the RRC layer - UE controlled mobility based on network configuration - The UE stores the UE Inactive AS context. - RAN-based notification area is configured by the RRC layer UE is - monitor short messages sent using the P-RNTI over the DCI (see clause 6.5); - monitoring the paging channel for CN paging using 5G-S-TMSI and RAN paging using the complete I-RNTI - Perform neighboring cell measurements and cell (re)selection - Update the RAN-based notification area periodically and when moving outside the configured RAN-based notification area - Can retrieve system information and send SI requests (if configured) - Perform logging of available measurements along with the location and time of the logged measurements configured UE - RRC_CONNECTED: - The UE stores the AS context - Forwarding unicast data to and from the UE - Lower layers can configure UE-specific DRX for the UE - For UEs supporting CA, use one or more SCells aggregated with an SpCell to increase bandwidth. - For UEs that support DC, use one SCG aggregated with an MCG to increase bandwidth - Network controlled mobility within NR and to / from E-UTRA - UE - if configured, monitor short messages sent using the P-RNTI over the DCI (see clause 6.5); - monitoring a control channel associated with the shared data channel to determine whether data is scheduled on the shared data channel; - Providing channel quality and feedback information - Perform neighbor cell measurements and measurement reporting - Get system information - Immediate MDT measurements with available location reports

[0079] According to the characteristics of the RRC Inactive state, for an Inactive UE, the connection (both user plane and control plane) with the RAN and the core network is maintained. More specifically, in RRC Inactive, the connection still exists but is suspended, in other words the connection is no longer active. In contrast, in the RRC Connected state, the connection exists and is active in the sense that it is used, for example, for data transmission. In the RRC Idle state, the UE does not have an RRC connection with the RAN and the core network, which also means that, for example, the radio base station does not have the UE's context, does not know, for example, the UE's identity, and does not have security parameters for the UE to be able to correctly decode data transmitted by the UE (security, for example, ensures the integrity of the transmitted data). The UE context may be available in the core network, but must first be acquired by the radio base station.

[0080] Furthermore, the paging mechanism (also called notification mechanism for example) for user equipment in a radio cell is based on so-called Radio Access Network (RAN) based notification areas (RNA for short). The radio access network should be aware of the current RNA where the user equipment is located and the user equipment can assist the gNB to track the UE moving between different RNAs. The RNA can be UE specific.

[0081] In the following, an example of an RRC resumption procedure (see 3GPP TS 21.2006.023, section 5.3.13) for a UE to move from RRC_Inactive state to RRC_Connected state is described with reference to Fig. 9. The purpose of this procedure is to resumption of a suspended RRC connection (which may include resumption of signaling and data radio bearers).

[0082] In this procedure, either an RRCResumeRequest message or an RRCResumeRequest1 message can be sent. When sending the RRCResumeRequest message, a short I-RNTI (e.g., a truncated I-RNTI) is used as the UE's identity (exemplarily called "resumeIdentity"). When sending the RRCResumeRequest1 message, a full I-RNTI is used as the UE's identity (exemplarily called "resumeIdentity"). The UE checks the indication "useFullResumeID" in SIB1 and decides to send either an RRCResumeRequest message or an RRCResumeRequest1 message. If "useFullResumeID" indicates "true", the UE sends the RRCResumeRequest1 message using the full I-RNTI, otherwise the UE sends the RRCResumeRequest using the short I-RNTI. The actions performed by the UE during the RRC resumption procedure (see section 5.3.13.4 of 3GPP TS 2012-010361) include resuming SRB2 and all DRBs that were suspended when the UE transitioned to the RRC Inactive state (see the release procedure below).

[0083] The RRCResume procedure can also be used to perform an RNA update when the UE moves out of the configured RNA. In this case, the network sends RRCRelease instead of RRCResume in response to the RRCResumeRequest / RRCResumeRequest1 message as shown in Figure 10. The UE remains in RRC_INACTIVE after receiving the RRCRelease message.

[0084] In the following, an example of a subsequent RRC connection release procedure for transitioning a UE from RRC_Connected to RRC Inactive state (see 3GPP TS 21.110, section 5.3.8) is described with reference to FIG. 11. The purpose of this procedure is to release the RRC connection or to suspend the RRC connection. For example, the network initiates the RRC connection release procedure to transition a UE in RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE. The actions taken by the UE in the RRC connection release procedure (see 3GPP TS 21.110, section 5.3.8.3) include suspending all SRBs (Signaling Radio Bearers) and DRBs (Data Radio Bearers) except SRB0, if the release is by suspension (e.g. RRCRelease includes suspendConfig). Thus, a UE in RRC Inactive state has no unsuspended or active DRBs (the UE only has suspended DRBs). SRB0 is kept active even in the RRC Inactive state and can be used by the UE to perform the RACH procedure when carrying RRC messages such as, for example, RRCResumeRequest, RRCResumeRequest1, RRCSetupRequest, etc.

[0085] As used in this application, the term "inactive state" is to be broadly understood as a state in which regular and large-scale data exchange between the UE and the base station is not possible, or as an uncommon state. For example, when the UE is in the inactive state (e.g., called an "inactive UE"), it does not have an actively used data connection, but still has one or more inactive data connections (which can also be called existing but currently unused data connections) that enable the transmission of (a small amount of) data without the need to first resume the data connection. To be complete, a UE in the idle state does not have a data connection through which the UE can send data to the base station, while a UE in the connected state has one or more active data connections that can be immediately used to convey data to the base station.

[0086] <Data transmission by UE in RRC inactive state - SDT procedure> More specifically, in 5G NR, the RRC_INACTIVE state is supported, and UEs with low-frequency (periodic and / or aperiodic) data transmission are generally maintained in the RRC_INACTIVE state by the network. Up to Release 16, data transmission is not supported in the RRC_INACTIVE state. Therefore, the UE has to resume the connection (e.g., transition to the RRC_CONNECTED state) for any DL (MobileTerminated) data and UL (MobileOriginated) data. No matter how small and low-frequency the data packets are, for each data transmission, the setup (or resume) of the connection and subsequent release to the RRC_INACTIVE state have to be performed. As a result, unnecessary power consumption and signaling overhead occur.

[0087] Specific examples of small and low-frequency data traffic include the following use cases. - Smartphone applications: Traffic from instant messaging services (whatsapp, QQ, wechat, etc.) Heartbeat / keep-alive traffic from IM / mail clients and other apps * Push notifications from various applications - Non-smartphone applications: Traffic from wearable devices (such as periodic location information) Sensors (e.g. industrial wireless sensor networks transmitting temperature, pressure measurements periodically or in an event-triggered manner). ○ Smart meters and smart meter networks that transmit regular meter readings

[0088] An exemplary prior art procedure (in this case a 5G-NR compliant prior art solution) for enabling a UE in an RRC Inactive state to transmit (small amounts of) data after transitioning to an RRC Connected state is briefly described below with reference to Fig. 12. As is clear from the figure, it is assumed that the UE is in an RRC_Inactive state, in which, for example, the UE (and the gNB) have suspended all data radio bearers and cannot transmit data to the gNB. In order for the UE to be able to transmit data, it must first transition to an RRC Connected state, which it can do by requesting resumption of the RRC connection (here sending an RRCResumeRequest) as part of a RACH procedure (in Fig. 12, for example using a 4-step RACH procedure).

[0089] In detail, the UE can send a preamble to the current gNB, after which it receives a corresponding random access response with a (small) UL grant of radio resources, which the UE uses to send a RRCResumeRequest message as msg3 of the RACH procedure. Finally, the new gNB provides the UE with a RRCResume message, and the UE transitions to the RRC Connected state (including the resumption of all data radio bearers). In the RRC_Connected state, the UE can transmit UL data.

[0090] The gNB may decide that after this transmission of UL small data, the UE should indeed transition to the RRC_CONNECTED state. The UE may request the resumption of the RRC connection, but the control in this respect may be left to the gNB. One exemplary possibility is that the gNB takes into account a buffer status report that the UE may send, for example in Msg3 or MsgA, to decide whether the UE should transition to the RRC_CONNECTED state or not. The buffer status report indicates the actual amount of data in the UE's buffer. For example, if the buffer status report indicates a large amount of data in the UE's buffer, the gNB may decide to transition the UE from the RRC_INACTIVE state to the RRC_CONNECTED state (for example by the gNB sending a RRCResume message). On the other hand, if the buffer status report indicates only a small amount of data in the UE's buffer, the gNB may decide to keep the UE in the RRC_INACTIVE state (for example by the gNB sending a RRCRelease message). Furthermore, the absence of a buffer status report in Msg3 / MsgA can also indicate to the gNB that there is e.g. no more data in the UE's buffer and the UE can remain in RRC_INACTIVE.

[0091] As can be seen from the illustration in Fig. 12, the above process, in which the UE must first transition from an INACTIVE state to a CONNECTED state so that it can transmit user data in the uplink, not only introduces latency but also consumes significant power from the UE every time it transmits user data. Moreover, the signaling overhead incurred by an INACTIVE UE when transmitting small data packets is a common problem that will be exacerbated with the increasing number of UEs in 5G NR.

[0092] Therefore, 3GPP intends to allow an RRC_Inactive UE to transmit (small) data on the uplink without changing the UE's state to RRC Connected. In general, devices that have intermittent (small) data packets when in the INACTIVE state would benefit from allowing transmission of (small) data in the INACTIVE state.

[0093] The following assumptions made with respect to Figures 13 and 14 and for the subsequent description of the concepts, solutions, and variations of the present invention should be considered as illustrative only and are not limiting to RACH-based small data uplink transmission.

[0094] Furthermore, when assuming RACH-based small data uplink transmission as an example, the UE can transmit small data in the uplink using either a two-step RACH or a four-step RACH (see MsgA or Msg3), and Figures 13 and 14 show simplified exemplary RACH-based small data uplink transmission procedures. In both Figures 13 and 14, it is exemplarily assumed that the UE is already in RRC_INACTIVE state and has small data available for transmission. In Figure 13, a four-step RACH procedure is assumed and shows how the UE transmits small data using Msg3. In Figure 14, a two-step RACH procedure is assumed and shows how the UE transmits small data using MsgA.

[0095] According to one example, the control message and the small data are transmitted together, e.g., in the same transport block, to the base station, where the UE uses resources to build the transport block and multiplexes data and signaling together in the same transport block of the MAC layer. In the case of a four-step RACH, the small data is transmitted in Msg3, e.g., based on the radio resources granted through the uplink grant received from the gNB in ​​Msg2. In the case of a two-step RACH, the small data is transmitted in MsgA, e.g., using radio resources selected by the UE from several previously configured radio resources in association with the selected RACH preamble.

[0096] 13 and 14 further show that buffer status reports can be included in Msg3 and MsgA, respectively, but the BSR is only shown in brackets to reflect that including the BSR is merely an exemplary possibility. For example, in FIG. 13, it is exemplarily assumed that the gNB decides to keep the UE in the RRC_Inactive state, e.g. because there is no BSR or the BSR indicates only a small amount of uplink small data in the UE's buffer. In response, an RRCRelease message is sent in Msg4. Meanwhile, in FIG. 14, it is exemplarily assumed that the gNB decides to transition the UE to the RRC_Connected state, e.g. because the BSR indicates a significant amount of uplink data in the UE's buffer that must be transmitted by the UE. In response, an RRCResume message is sent for MsgA.

[0097] Furthermore, although in FIG. 13 the uplink grant is shown separately from the random access response of Msg2, in FIG. 13 and similar implementations below the uplink grant equally belongs to the random access response and can be considered as being part of the random access response.

[0098] In summary, an exemplary implementation of small data uplink transmission for RRC_INACTIVE UEs is possible and can be based, for example, on a RACH procedure, i.e., a two-step RACH procedure or a four-step RACH procedure (see Figures 13 and 14).

[0099] Above we have described one small data uplink transmission (e.g. using Msg3 / MsgA on the RACH). Furthermore, it has been agreed in 3GPP that a UE in RRC_INACTIVE state should be able to send (and receive) multiple UL (and possibly DL) transmissions using the same procedure without transitioning to RRC_CONNECTED state.

[0100] Figure 15 shows an exemplary implementation of a single SDT transmission procedure in more detail than the simplified exemplary illustration of Figure 13. For ease of illustration and the following description, it is exemplarily assumed that the multi-SDT transmission procedure is based on a 4-step RACH.

[0101] Further, it is exemplarily assumed that the UE has transitioned from a previous gNB (anchor gNB) to the current gNB (hence the current serving gNB) while in RRC_INACTIVE state. For this reason, it may be necessary for the serving gNB to obtain the UE context from the anchor gNB, e.g. as part of the RACH procedure, so that the serving gNB can authenticate the (unknown to the serving gNB) UE.

[0102] In this regard, it is also exemplarily assumed that a Contention Resolution Identity MAC Control Element (CR MAC CE) is transmitted separately from the response to the UE's RRCResumeRequest message (RRCRelease message in the example of FIG. 15). The main purpose of this Msg4 and the corresponding CR MAC CE is to resolve possible contention in the contention-based RACH, and thus there is no need to wait for the serving gNB to acquire the UE context. Thus, the serving gNB can transmit the CR MAC CE as soon as possible (e.g., when the result of the contention resolution is determined in the serving gNB), while the transmission of the response message to the RRCResumeRequest message from the UE can be performed by the serving gNB after receiving and processing the UE context. Meanwhile, in another scenario, the Contention Resolution Identity MAC Control Element can be transmitted together with the RRC response message (e.g., RRCRelease or RRCResume).

[0103] The sequence of steps for the single SDT procedure shown in FIG. 15 is as follows:

[0104] 1. A UE with small data available for transmission initiates a RACH to perform the transmission of the small data, and therefore transmits a preamble to the serving gNB.

[0105] 2. The UE then receives a temporary identifier for the UE (e.g., a temporary C-RNTI) and an uplink resource grant from the serving gNB as an RAR.

[0106] 3. The UE then sends an RRCResumeRequest message with UL small data based on the previously received UL grant. The UE also effectively starts a timer (called T319) that is responsible for controlling the RRC Resume Request procedure. More details regarding timer T319 are provided below.

[0107] More specifically, according to an exemplary implementation conforming to 5G, the T319 timer adjusts the maximum duration of the RRC resume request procedure. The timer T319 is started upon sending an RRCResumeRequest message and stopped upon receiving a corresponding response (such as an RRCRelease or RRCResume message). If T319 expires before being stopped, the UE determines that the RRC resume request procedure has failed and transitions to the RRC_IDLE state.

[0108] Exemplarily, the value applied for T319 takes into account the time required for the gNB to retrieve the UE context from another anchor gNB. The longer T319 is, the later the serving gNB can send a response message (e.g. RRCRelease or RRCResume) to the UE. The value of T319 can be broadcast, for example, by the gNB in ​​its own cell using system information (SIB), and thus the T319 timer is cell specific and not UE specific.

[0109] 4. The serving gNB attempts to obtain the UE's context from the anchor gNB based on the information content of the RRCResumeRequest message, which includes, for example, the corresponding UE ID (Inactive-RNTI, I-RNTI, etc.) for obtaining the context.

[0110] 5. The serving gNB sends a contention resolution identity MAC CE to the UE without waiting for the UE context acquisition to be completed, thus completing the RACH procedure. The UE receives this CR MAC CE and compares the contention resolution identity therein with the UE ID (e.g. I-RNTI) previously sent to the serving gNB in ​​the RRCResumeRequest message. If the two IDs match, the contention is positively resolved.

[0111] 6. As a result of the RACH contention being positively resolved, the UE uses the previously received temporary C-RNTI as the C-RNTI.

[0112] 7. Now assume that the serving gNB successfully obtains the UE’s context from the anchor gNB.

[0113] 8. The serving gNB then decides how to respond to the RRCResumeRequest message and, in this exemplary case of Figure 15, sends a RRCRelease message to the UE to keep it in RRC_Inactive. On the UE side, it stops the T319 timer upon receiving this RRCRelease message.

[0114] 9. Furthermore, as a result of the RRCRelease message, the UE remains in RRC_INACTIVE and thus releases (also referred to as discarding) the C-RNTI, whereas the UE retains the C-RNTI when, for example, it received the RRCResume message as a response to a previous RRCResumeRequest message in step 3 above.

[0115] To support multiple SDT transmissions, it may be necessary to extend the above sequence of steps that includes only one small data transmission in step 3. For example, the UE may obtain additional suitable UL radio resources and perform one or more UL small data transmissions correspondingly.

[0116] However, in order for the UE to be able to receive uplink resource grants from the serving gNB, it is advantageous for the UE to have a valid C-RNTI (i.e. after the temporary C-RNTI has been converted to a C-RNTI) to which the uplink resource grants (such as DCIs of format 0_0, 0_1 or 0_2) are addressed. In other words, a valid C-RNTI is important for performing a multi-SDT procedure. However, whether the UE retains the C-RNTI or not depends on the response it receives in relation to the initiated RRCResumeRequest and on the operation of timer T319, as is evident from above.

[0117] More specifically, the UE's C-RNTI is released when the UE receives an RRCRelease message (see step 8 above) or when T319 expires (e.g. before receiving the RRCRelease message). For example, the current standard of 3GPP TS 2012-010621 (T2012-010621) defines in its subclause 5.3.8.3 the UE's behavior upon receiving an RRCRelease message, which includes releasing the C-RNTI (e.g. as part of a MAC reset). Furthermore, the current standard of 3GPP TS 2012-010621 (T2012-010621) also defines in its subclause 5.3.13.5 the UE's behavior upon, for example, the expiration of the T319 timer, which includes transitioning to RRC_IDLE, which includes releasing the C-RNTI (e.g. as part of the release of all resources, e.g. RLC entities, MAC configuration, etc.) (see subclause 5.3.11 of 3GPP TS 2012-010621).

[0118] In summary, the UE's C-RNTI is kept valid in the UE for as long as the T319 timer is running and until the RRCRelease message is received. As a result, the C-RNTI is only available for a certain amount of time, which may not be sufficient for the UE to perform a multi-SDT procedure.

[0119] One possible solution could be to perform one or more additional small data transmissions at the earliest time that is reasonably possible, for example after the UE receives the Msg4 contention resolution (see Figure 15 and the description of step 5), but before receiving the RRCRelease message. Figure 16 illustrates such a solution, which is similar to Figure 15 and makes corresponding assumptions.

[0120] In such a solution, the serving gNB sends an uplink grant addressed to the C-RNTI to the UE, and the UE performs a corresponding small data uplink transmission using the allocated uplink radio resources before the RRCRelease message is sent by the serving gNB.

[0121] Optionally, the small data transmission can be sent together with the buffer status report so that the serving gNB knows how much more data is present in the UE's buffer and can decide whether a further small data transmission is necessary and, if so, make the next UL grant accordingly.

[0122] Thus, according to the solution of FIG. 16, small data transmission can be performed efficiently and quickly.

[0123] However, such a solution may have the drawback that the UE is not yet authenticated by the serving gNB, since the serving gNB has not yet received the UE context from the anchor gNB. In general, it is preferred that the UE is first authenticated by the serving gNB (based on the UE context) before the UL radio resources are actually reserved and assigned to such a new UE. For example, the UE context may fail to be obtained, or the UE may turn out to be fraudulent or fake, and thus the assigned radio resources intended for the UL SDT may be wasted.

[0124] Furthermore, the example scenario of Figure 16 assumes that the UE context is acquired and two additional small data transmissions (three SDTs in total) are possible before the gNB sends an RRCRelease message to the UE. The UE then stops the T319 timer and releases the C-RNTI. Further UL small data transmissions are no longer possible. However, the length of time available depends on the time required for UE context acquisition, which can vary widely and may even be quite short in practice.

[0125] A possible variation of the described solution is for the gNB to wait to send the RRCRelease message to avoid the UE discarding the C-RNTI. For example, the gNB could wait until the exact moment when the UE receives the RRCRelease message and stops the T319 timer, thus avoiding a failure of the RRCResumeRequest procedure and a possible transition to the RRC_IDLE state. This maximizes the time available for small data transmission, somewhat independent of when the serving gNB actually receives the UE context. However, the waiting time by the serving gNB is limited by the value of the T319 timer, since the serving gNB needs to send the RRCRelease within time that the UE can receive it before the T319 timer expires. Therefore, there may not be enough time to perform the required number of small data transmissions. In current 3GPP 5G compliant implementations, the T319 timer can be set to a maximum of 2000 ms (see 3GPP 5G compliant RFC12, section 6.3.2, information element “UE-TimersAndConstants”, “ENUMERATED{ms100, ms200, ms300, ms400, ms600, ms1000, ms1500, ms2000}”). This maximum value of 2000 ms was defined to accommodate UE context acquisition from another gNB, including possible delays due to the backhaul link between the anchor gNB holding the UE context of an inactive UE and the serving gNB. The maximum value of the T319 timer is not designed to accommodate multi-SDT procedures and is therefore likely to be too small.

[0126] As a further optional variation of the above solution (based on FIG. 16), the length of the T319 timer can be extended, i.e. made longer. In this respect, the maximum value to which the T319 timer can be defined can be set much higher (e.g. 8000 ms). The benefit of this is that the improved multi-SDT procedure allows the UE to keep the C-RNTI valid for longer, thus allowing more time for multiple small data transmissions before receiving an RRCRelease message.

[0127] However, setting the T319 timer to a higher value also has a drawback, since other UEs that do not perform or even support multiple small data transmissions are adversely affected. The T319 timer value is broadcasted in its cell by the serving gNB as part of the system information and is adopted by all UEs, including UEs that do not perform or do not support multiple small data transmissions, and even UEs that only plan to perform RNA (RAN-based notification area update) or that plan to resume the RRC connection. Thus, the extended T319 timer value adversely affects the RRCResumeRequest procedure for these UEs, since the UEs will only detect if the RRCResumeRequest procedure fails later, when the T319 timer expires.

[0128] A multi-SDT procedure may take much longer than a single-SDT transmission procedure. In particular, a multi-SDT transmission procedure may involve the transmission of several subsequent UL grants after the first UL SDT transmission (see also Figures 13 and 14). This is likely to make a multi-SDT procedure significantly longer, for example, compared to the single-SDT transmission procedure described above.

[0129] At the RAN2#111_e meeting, it was agreed that Small Data Transmission (SDT) is configured by the network per Data Radio Bearer (DRB). More specifically, the arrival of SDT DRB traffic in RRC_INACTIVE triggers the SDT procedure, whereas the arrival of non-SDT DRB traffic in RRC_INACTIVE triggers the legacy RRC resume procedure (requesting a return to RRC_CONNECTED). In other words, the arrival of data on a DRB that has been configured by the network (e.g., by the base station) to allow transmission of data in the inactive state triggers the SDT procedure, whereas the arrival of data on a DRB that has not been configured by the network triggers the UE to initiate a (legacy) RRC resume procedure to enter the connected state. At the RAN2#112_e meeting, it was further agreed that the UE suspends all DRBs when it enters RRC_INACTIVE, and only the SDT DRBs are resumed (by the UE) at the start of the SDT procedure.

[0130] Thus, the term SDT procedure or procedure for transmitting SDT DRB data refers to a procedure for transmitting data in an inactive state (e.g., RRC_INACTIVE), and does not necessarily refer to the amount of data transmitted by the SDT procedure. Thus, the terms small data and SDT DRB data refer to data that can be transmitted in an inactive state (of the UE), and does not necessarily refer to the size of this data. In particular, small data or SDT DRB data may be any data of a DRB that is configured for transmission in an inactive state (such a DRB is also referred to herein as an SDT DRB). Similarly, the term non-SDT DRB data refers to data that cannot be transmitted in an inactive state (of the UE) and / or data that can only be transmitted in a connected state (of the UE). In particular, non-SDT DRB data may be any data of a DRB that is not configured for transmission in an inactive state (such a DRB is also referred to herein as a non-SDT DRB).

[0131] The procedure for transmitting SDT DRB data may be based on the RACH procedure and / or may be a procedure initiated in the RACH procedure. In particular, the RACH procedure may be a four-step RACH procedure or a two-step RACH procedure. More specifically, in this specification, the SDT procedure based on the RACH procedure means an SDT procedure initiated during the RACH procedure. This includes not only an SDT procedure in which small data transmission is performed only once during the RACH procedure, as shown in, for example, FIG. 13 to FIG. 15, but also an SDT procedure in which small data transmission is performed two or more times during and / or following the RACH procedure, as shown in FIG. 16. Furthermore, as shown in FIG. 17, an SDT procedure that is not terminated together with the RACH procedure in which the SDT procedure was initiated is also included.

[0132] More specifically, FIG. 17 illustrates an SDT procedure including two or more transmissions of small data based on a multi-SDT procedure, i.e., a four-step RACH procedure. As can be seen, the SDT procedure in FIG. 17 does not end with the RACH procedure, but continues after the reception of Msg4. More specifically, the UE receives an UL grant 1700 after receiving Msg4, and performs a transmission of small data using the UL grant 1700. In FIG. 17, there is only one small data transmission before the end of the RACH procedure, and there is only one small data transmission after the end of the RACH procedure. However, in general, multiple transmissions of small data can be performed before and / or after the end of the RACH procedure.

[0133] In summary, an SDT procedure based on a RACH procedure or initiated during a RACH procedure may be a procedure in which one or more data transmissions are performed in an inactive state, i) at least one of these one or more transmissions being performed by the UE together with a message of the RACH procedure, and / or ii) an indication is sent by the UE together with the message of the RACH procedure, which indication indicates a request for a resource grant for a small data transmission.

[0134] However, the term SDT procedure is not limited to RACH-based SDT procedure, because it also includes data transmission in inactive state using configured grant (CG). More specifically, the UE can initiate a CG-based SDT procedure by sending a corresponding instruction to the scheduling device using configured CG resources. The UE can initiate the transmission of SDT DRB data together with the transmission of the instruction or together with a later transmission (which can also use CG resources). For example, the UE can multiplex the SDT DRB data with an RRCResumeRequest message when the SDT DRB data arrives and transmit them in the nearest CG resource. The CG resource is a periodically appearing UL grant that is configured in the UE by the scheduling device before / when the UE enters the inactive state.

[0135] <Data connection> The term "data connection" as used herein may be understood as a connection between, for example, a UE and a radio base station over which data (e.g., small data) can be transmitted. More specifically, a UE that does not have a data connection cannot immediately transmit data even if it is connected to a radio base station based on, for example, a signaling connection. Data in this context may be broadly understood as user data, e.g., from an application running on the UE, as opposed to control information transmitted using, for example, a signaling connection.

[0136] In one exemplary implementation, according to the 5G NR standard, a data connection can be understood as a Data Radio Bearer (DRB) and a signaling connection can be understood as a Signaling Radio Bearer (SRB).

[0137] In some cases, the application further distinguishes between different states of a data connection, e.g., not existing, existing but suspended, existing but not used (which may also be referred to as not suspended or inactive), and existing and currently being used to transmit data (which may also be referred to as active). According to this classification of data connections, a suspended data connection is one in which a data connection exists but cannot be immediately used to transmit data (e.g., in the uplink) because the data connection has been suspended by both endpoints (e.g., the UE and the radio base station) and must be resumed first. On the other hand, a non-suspended data connection can immediately transmit data (e.g., without further steps such as resuming the data connection). For example, with reference to an exemplary 5G NR implementation currently defined in the 3GPP standard, a UE in an RRC inactive state has one or more suspended data connections (DRB is suspended). A UE in an RRC connected state can have one or more active data connections and possibly other non-suspended data connections (not currently being actively used). A UE in RRC idle state has no data connections (suspended and active data connections), whereas according to the improved data transmission procedure described below, unlike the 5G NR implementation currently defined in the 3GPP standard, a UE in RRC inactive state has one or more available non-suspended data connections (these data connections are inactive because no data is exchanged until a small data transmission).

[0138] In this context, the application describes, for example, a UE transmitting small data using a data connection. In this scenario, the data connection is established between the UE and a base station. In one exemplary implementation, the data connection shall be broadly understood as being associated with certain parameters related to coding, security, encryption, etc. Thus, from the perspective of the transmitting side, the UE applies these parameters associated with the data connection to the (small) data transmitted using the data connection. This application may be done, for example, to guarantee a certain quality of service. Correspondingly, from the perspective of the receiving side, the receiver may need to apply the inverse processing (e.g., processing related to coding, security, encryption, etc.) to the transmitting side in order to successfully decode the data transmitted over the data connection.

[0139] <Terminology> In the following, UEs, base stations, and procedures for new radio access technologies envisioned in 5G mobile communication systems (although they can also be used in LTE mobile communication systems) are described. A number of different implementations and variations are also described. The following disclosure is facilitated by, and may be based, for example, at least in part on, the discussion and findings above.

[0140] In general, it should be noted that many assumptions have been made herein to allow the principles underlying the present disclosure to be explained in a clear and easily understandable manner, however, it should be understood that these assumptions are merely examples made herein for the purpose of explanation and are not intended to limit the scope of the present disclosure.

[0141] Furthermore, although the specific terminology used in the context of new radio access technologies for the upcoming 3GPP 5G communication system has not yet been fully determined or may eventually change, some of the terms such as procedures, entities, layers, etc. used below are closely related to the terminology used in the LTE / LTE-A system or in the current 3GPP 5G standardization. Thus, the terminology may change in the future, but without affecting the functionality of the embodiments. Therefore, it will be recognized by those skilled in the art that the embodiments and their scope of protection are not limited to the specific terms used illustratively herein due to the absence of newer or finally agreed terminology, but should be understood more broadly in terms of the functions and concepts underlying the functions and principles of the present disclosure.

[0142] <Embodiment> In general, when non-SDT data arrives during an SDT procedure, a UE that is in RRC_INACTIVE may i) trigger a RACH procedure to enter a connected state regardless of other circumstances, which may be an inefficient approach that degrades overall system performance, and / or ii) trigger a RACH procedure to indicate the arrival of non-SDT data based on factors or conditions that do not yet exist in the current specification, which may require significant effort to change the specification.

[0143] In view of this, the present disclosure provides techniques that enable efficient handling of non-SDT DRB data arrivals during SDT procedures. In particular, the disclosed procedures enable transmission opportunities already occurring for small data transmissions to also be used to transmit traffic indications indicating the arrival of non-SDT DRB data. Using already occurring transmission opportunities can avoid the UE needing another UL grant to transmit the indication of the arrival of non-SDT data and / or initiating an additional RACH procedure to enter a connected state, thus saving UE power, reducing overhead, and avoiding collisions with other UEs.

[0144] The present disclosure provides a base station and a user equipment. As shown in FIG. 18, the user equipment 1810 and the base station 1860 can communicate with each other via a radio channel in a wireless communication system. For example, the user equipment can be an NR user equipment, and the base station can be a network node or a scheduling node, such as an eNB, or an NR gNB, particularly a gNB in ​​a non-terrestrial network (NTN) NR system. The present disclosure further provides a system including a scheduled device and a scheduling device, and corresponding methods and programs. An example of such a communication system is shown in FIG. 18. The communication system 1800 can be a wireless communication system according to the technical specifications of 5G, particularly an NR communication system. However, the present disclosure is not limited to 3GPP NR, and can also be applied to other wireless systems or cellular systems, such as NTN. FIG. 18 shows a simplified general and exemplary block diagram of a user equipment 1810 (also referred to as a communication device) and a scheduling device 1860, which is assumed here to be exemplarily located in a base station (network node). However, in general, the scheduling device may be a terminal in case of a sidelink connection between two terminals. Additionally, particularly with respect to URLLC, eMBB, and mMTC use cases, the communication device 1810 may be a sensor device, a wearable device, or a controller of a connected vehicle, or an automated machine in an industrial factory. Additionally, the communication device 1810 may also act as a relay between the base station 1860 and another communication device (e.g., the disclosure is not limited to a communication "terminal" or a user "terminal").

[0145] The UE and eNB / gNB communicate with each other over (wireless) physical channels 1850 using transceivers 1820 (UE side) and 1870 (base station side), respectively. The base station 1860 and the terminal 1810 together form a communication system 1800. The communication system 1800 may further include other entities as shown in FIG.

[0146] As shown in FIG. 18 (left side), according to an exemplary embodiment, a user equipment (UE) 1810 is provided. The UE 1810 includes a transceiver 1820 and a circuit 1830. The circuit 1830, in operation, detects that non-SDT DRB data is transmitted in a connected state during a procedure of transmitting SDT DRB data in an inactive state. The circuit 1830, in operation, determines whether there is a transmission opportunity to wait for. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuit, in operation, initiates a random access channel (RACH) procedure to enter the connected state. When it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuit, in operation, controls the transceiver to use the transmission opportunity to transmit a traffic indication indicating the detection of non-SDT DRB data.

[0147] FIG. 19 illustrates an exemplary functional structure of the circuit 1830, i.e., the circuit for processing the arrival of non-SDT DRB data. As illustrated, the non-SDT DRB data arrival processing traffic indication processing circuit 1830 may include a non-SDT DRB data detection circuit 1936 and a transmission opportunity determination circuit 1937. More specifically, the circuit 1936 detects non-SDT DRB data, for example, by detecting or determining whether there is non-SDT DRB data to be transmitted. The circuit 1936 may also determine whether the arrival of a non-SDT DRB is expected. The transmission opportunity determination circuit 1937 may determine whether there is a transmission opportunity to wait for. Furthermore, if it is determined that there is a transmission opportunity to wait for, the circuit 1937 may also determine a transmission opportunity to wait for (e.g., a resource for the transmission opportunity).

[0148] Corresponding to the above-mentioned UE, according to another exemplary embodiment, a communication method performed by the UE is provided. As shown in FIG. 21, the method includes the following steps: - a step S2110 of detecting, during a procedure of transmitting SDT DRB data in an inactive state, that non-SDT DRB data is transmitted in a connected state; - a step S2120 of determining whether there is a transmission opportunity to wait for; - step S2130 of initiating a Random Access Channel (RACH) procedure to enter a connected state when it is determined in S2120 that there is no transmission opportunity to wait for or that a transmission opportunity to wait for is no longer likely to occur ("No" in S2140); - if it is determined in S2120 that there is a transmission opportunity to wait for and the transmission opportunity occurs ("Yes" in S2140), a step S2150 of using the transmission opportunity to transmit a traffic indication indicating detection of non-SDT DRB data; Includes.

[0149] As also shown in FIG. 18 (right side), according to another exemplary embodiment, a scheduling device 1860 is provided. The scheduling device 1860 includes a transceiver 1870 and a circuit 1880. In operation, the circuit 1880 controls the transceiver to receive a transmission including SDT DRB data from a user equipment (UE) in an inactive state. In operation, the circuit 1880 obtains a traffic indication from the received transmission including the SDT DRB data. The traffic indication indicates that non-SDT DRB data is detected by the UE. The non-SDT DRB data is data transmitted by a UE in a connected state, and the traffic indication is signaled by a predefined value of a logical channel ID (LCID) in a MAC subheader, and the predefined value of the LCID indicates that non-SDT DRB data is detected.

[0150] 20 illustrates an exemplary functional structure of the traffic indication processing circuit 1885. In particular, the traffic indication processing circuit 1885 may include a traffic indication evaluation circuit 2036 and an RRC state transition circuit 2037. The circuit 2036 may be responsible for obtaining and interpreting a traffic indication from a transmission including small data. Furthermore, when the circuit 2036 obtains a traffic indication from a received transmission, the circuit 2037 may be responsible for sending an RRC message to the UE to transition the UE from an inactive state to a connected state.

[0151] Further, a communication method is provided corresponding to the above-mentioned base station, which is performed by a scheduling device. As shown in FIG. 22, the method includes the following steps: - a step S2210 of receiving a transmission including SDT DRB data from a user equipment (UE) in an inactive state; - a step S2220 of obtaining a traffic indication indicating that non-SDT DRB data has been detected by the UE from a transmission including SDT DRB data, where i) the non-SDT DRB data is data transmitted by a UE in a connected state, ii) the traffic indication is signaled by a predefined value of a Logical Channel ID (LCID) in a MAC subheader, and iii) the predefined value of LCID indicates that non-SDT DRB data has been detected; Includes.

[0152] The communication device 1810 may comprise a transceiver 1820 and a (processing) circuit 1830, and the scheduling device 1860 may comprise a transceiver 1870 and a (processing) circuit 1880. The transceiver 1810 may comprise and / or function as a receiver and / or a transmitter. In other words, in this disclosure, the term "transceiver" is used for hardware and software components that enable the communication device 1810 or the base station 1860 to transmit and / or receive wireless signals over the wireless channel 1850. Thus, a transceiver corresponds to a receiver, a transmitter, or a combination of a receiver and a transmitter. In general, it is assumed that base stations and communication devices can transmit and receive wireless signals. However, in particular for some applications of eMBB, mMTC, and URLLC (such as smart home, smart city, industrial automation, etc.), it may be the case that a device such as a sensor only receives signals. Furthermore, the term "circuit" includes a processing circuit formed by one or more processors or processing units, etc. The circuits 1830 and 1880 (or processing circuits) can be one or more hardware such as one or more processors or any LSI. There is an input / output point (or node) between the transceiver and the processing circuit, through which the processing circuit can control the transceiver in operation, i.e., control the receiver and / or the transmitter to exchange receive / transmit data. The transceiver can include an RF (radio frequency) front, including one or more antennas, amplifiers, RF modulators / demodulators, etc., as a transmitter and a receiver. The processing circuit can perform control tasks such as transmitting user data and control data provided by the processing circuit and / or controlling the transceiver to receive user data and control data that are further processed by the processing circuit. The processing circuit can also be responsible for performing other processing such as judgments, decisions, calculations, measurements, etc. The transmitter can be responsible for processing the transmission and other processing related thereto.The receiver may be responsible for processing the reception and performing other processing related thereto (such as monitoring the channel).

[0153] Further, it should be noted that any of the steps / operations described below may be performed or controlled by circuitry 1830 (on the UE side) and / or circuitry 1880 (on the base station side).

[0154] In the further description, details and embodiments apply to the transceiver device, the scheduling device (or scheduling node), and the method, respectively, unless an explicit description or context indicates otherwise.

[0155] <Non-SDT data arrival> It is assumed that at some point when the UE is in an inactive state, non-SDT DRB data becomes available for transmission, and thus the UE determines that a non-SDT DRB transmission is to be performed. If the UE is not in an SDT procedure when it detects the arrival of non-SDT DRB data, it can initiate a RACH procedure to enter a connected state. Therefore, it is assumed that the UE is in an SDT procedure when it detects the arrival of non-SDT DRB data.

[0156] As shown in Figure 23, the statement that the UE is in an SDT procedure does not necessarily mean that the UE has already performed a transmission related to the SDT procedure, but rather that the UE has determined that (small) data is to be transmitted in an inactive state. Thus, the SDT procedure may begin with determining that (small) data is to be transmitted in an inactive state, may include a RACH procedure that initiates the SDT procedure, and / or may continue after the RACH procedure.

[0157] "Arrival" in this specification means arrival from a higher layer, or in other words, non-SDT data becomes available for transmission. Furthermore, the term "detected" includes not only detection that data has actually arrived, but also detection / determination that non-SDT DRB data is expected to arrive for transmission.

[0158] As shown in FIG. 23, the non-SDT DRB data is A or time T B More specifically, the timing of arrival of non-SDT traffic T A means a timing before the first transmission of small data (e.g., Msg3 / MsgA). Alternatively or in addition, the timing T A T can also be the period before the UE performs all of its RACH transmissions. A If non-SDT traffic arrives within the period T, then there is at least one UL grant (or transmission opportunity) for small data transmission, which the UE can use to indicate the arrival of non-SDT traffic. In particular, there is a transmission opportunity as part of the RACH procedure. For example, as shown in FIG. 23, A can start when the UE triggers the SDT procedure or immediately after, and can end when the UE transmits Msg3 / MsgA or immediately before. B means that non-SDT traffic arrives after the first transmission of small data (e.g., Msg3 / MsgA). Therefore, T B If non-SDT traffic arrives within the period T, there may or may not be an UL grant available for the UE to indicate the arrival of the non-SDT traffic, depending on whether there is a subsequent data transmission. For example, as shown in FIG. 23, B can start when the UE transmits Msg3 and end before the UE receives the RRCRelease message / MsgB. B TA However, depending on the network's decision, the period may be shorter than T B Note that the period may be longer.

[0159] When the arrival of non-SDT DRB data is detected, the UE may initiate a new RRC resumption procedure, e.g., using a CCCH message. Thus, even if there is an ongoing RRC resumption procedure (to transmit SDT DRB data), the UE may initiate a new RACH procedure and send the RRC resumption request again in Msg3. However, if a new RACH is triggered regardless of whether there is an upcoming UL grant or transmission opportunity, this may result in inefficient resource utilization and increased RACH collisions with other UEs.

[0160] Therefore, to summarize the process for the RACH-based SDT procedure, which is described in more detail below, T A If non-SDT traffic arrives at T, the UE can use the remaining transmission opportunity to transmit a traffic indication. B If non-SDT traffic arrives in the gNB, the UE can either i) send a non-SDT traffic indication to the gNB in ​​the dedicated UL resource(s) received before the end of the SDT procedure, or ii) initiate a new RACH procedure (RRC Restart procedure) to enter a connected state if the dedicated UL resource(s) has not been received or is not expected to be received. Furthermore, the UE can also initiate a new RACH procedure if it (later) determines that it is no longer expecting to receive an expected UL grant, in other words that it is no longer expecting to receive a dedicated UL grant.

[0161] <Transmission Opportunity> In general, the term transmission opportunity refers to an opportunity to transmit a traffic indication without initiating a new RACH procedure (e.g., a RACH procedure for initiating SDT DRB data transmission, or a different RACH procedure in addition to an already initiated RACH procedure). Thus, a transmission opportunity is associated with a resource (one or more) that the UE can use to transmit data. In general, these resources may be dedicated resources indicated or expected to be indicated by a dedicated UL grant received as part of the SDT procedure, and / or resources used for the transmission of the RACH procedure (e.g., Msg3 or MsgA), as well as resources assigned to the UE via a configured grant (CG). In particular, a transmission opportunity may be i) a transmission opportunity for transmitting at least a portion of SDT DRB data, and ii) a transmission opportunity expected to occur as part of a procedure for transmitting SDT DRB data.

[0162] 1. Already known sending opportunities Generally, when determining whether to wait for a transmission opportunity, the resource of the transmission opportunity may be known to the UE.

[0163] In general, if the procedure for transmitting SDT DRB data is a procedure that is initiated in a RACH procedure, the transmission opportunity to wait for may be the first transmission of the RACH procedure. For example, if the SDT procedure is initiated in a two-step RACH procedure and the UE has not yet transmitted its first transmission (e.g., MsgA), the UE may use this first transmission to transmit a traffic indication. In other words, the UE may use a RACH resource (e.g., a resource of a RACH opportunity) to transmit the SDT DRB data (or a part thereof) and the traffic indication. Thus, non-SDT DRB data may have been detected by the UE after the UE triggers the RACH procedure (e.g., decides to initiate the RACH procedure) and before transmitting the first transmission of the RACH procedure. For example, non-SDT data may arrive while the UE is waiting for a (e.g., next) RACH resource to be used. In this case, the transmission opportunity (to wait or not to wait) may be given by the RACH resource.

[0164] Furthermore, in general, if the procedure for transmitting SDT DRB data is a procedure that is initiated in a RACH procedure, the transmission opportunity may be the opportunity indicated by an uplink grant received as part of the RACH procedure. For example, the SDT procedure is initiated (started or to be initiated) in a four-step RACH procedure. In this case, the UE may have detected non-SDT DRB data after receiving a random access response and before transmitting the SDT DRB data (or a part thereof) using the resource indicated by the random access response. For example, the UE may have already received Msg2 but not yet transmitted Msg3. Thus, in general, the UE may have received an UL grant during the RACH procedure, which indicates, for example, a transmission opportunity (resource) for transmitting SDT data that has not yet passed. In that case, the transmission opportunity (to wait or not to wait) may be that transmission opportunity indicated by the UL grant.

[0165] Furthermore, in general, if the procedure for transmitting SDT DRB data is a procedure initiated in a RACH procedure, the transmission opportunity to wait for is indicated by an uplink grant received for transmitting SDT DRB data after the completion of the RACH procedure. For example, the SDT procedure is initiated in a RACH procedure (e.g., a two-step or four-step RACH procedure). This RACH procedure may be completed (e.g., the UE has already received a contention resolution MAC CE from the scheduling device), but the SDT procedure initiated in this RACH procedure may still be ongoing. In other words, the UE may still receive an UL grant for transmitting SDT DRB data from the scheduling device. When detecting the arrival of non-SDT DRB data, the UE may have received such an UL grant indicating a transmission opportunity for transmitting SDT data that has not yet passed. In that case, the transmission opportunity (to wait or not to wait) may be that transmission opportunity indicated by the UL grant.

[0166] <Monitoring known transmission opportunities - S2140> After determining that there is a transmission opportunity to wait for, the UE may monitor the transmission opportunity (S2140). If the resource(s) of the transmission opportunity are already known to the UE, this step may include waiting for the transmission opportunity to occur (S2140). More specifically, the resource of the transmission opportunity will occur sometime in the future, and thus the UE must wait until it can use the resource for transmitting a traffic indication. However, monitoring may also include monitoring whether the transmission opportunity is canceled or preempted by the base station before it occurs, in which case the UE may initiate a new RACH procedure to enter a connected state.

[0167] 2. Transmission opportunities indicated by expected uplink (UL) grants In general, when deciding whether to wait for a transmission opportunity, the resource of the transmission opportunity may not be known to the UE. In this case, the UE may expect to receive an UL grant from the scheduling device that specifies the resource of the transmission opportunity. As will be further described below, there are several scenarios in which the UE may expect to receive an UL grant from the scheduling device.

[0168] Generally, the transmission opportunity to wait for may be expected to be indicated by an uplink grant. Moreover, generally, the UE may expect to receive its UL grant indicating resources for transmitting SDT data as part of an SDT procedure. As explained further below, the (expected) uplink grant may be expected to be received as part of a RACH procedure that initiates an SDT procedure, or may be expected to be received not as part of a RACH procedure (but still as part of an SDT procedure). In other words, the UL grant may be an UL grant expected to be received to transmit SDT DRB data or a portion of SDT DRB data after the completion of a RACH procedure.

[0169] For example, the circuitry may control the transceiver to expect an uplink grant to be received after sending a first transmission of the RACH procedure. In particular, the RACH procedure may be a four-step RACH procedure, where after sending Msg1, the UE expects to receive an UL grant via Msg2.

[0170] Alternatively or additionally, the circuitry may control the transceiver to expect the uplink grant to be received after transmitting a buffer status report (BSR) indicating an amount (e.g., a non-zero amount) of SDT DRB data to be further transmitted. This BSR may have been transmitted as part of the RACH procedure (e.g., in MsgA or Msg3) or may have been transmitted together with a portion of the SDT DRB data after the RACH procedure is completed. For example (as shown in FIG. 17), the UE may not transmit the entire SDT DRB data in MsgA / Msg3 (e.g., taking into account the size of the SDT DRB data). Thus, the UE may segment the SDT DRB data and transmit only a portion of the SDT DRB data and a BSR indicating a non-zero size of the remaining SDT DRB data in MsgA / Msg3. The UE may then wait for and / or expect a further uplink grant (no longer part of the RACH procedure) to transmit the remaining portion of the SDT DRB data.

[0171] Further, alternatively or additionally, after transmitting the BSR, the circuitry may control the transceiver to transmit a portion of the SDT DRB data, where the amount of the portion of the SDT DRB data is smaller than the amount indicated by the BSR, and may expect an uplink grant to be received. In other words, after transmitting a BSR for SDT DRB data, the UE may expect an UL grant from the transmission of the BSR until it (successfully) transmits SDT DRB data of the size indicated by the BSR.

[0172] <Monitoring transmission opportunities-S2140> After determining that there is a transmission opportunity to wait for, the UE may monitor the transmission opportunity (S2140). If the resource(s) of the transmission opportunity is expected to be indicated by an UL grant, this step may include waiting for the UL grant (S2140). The waiting may include monitoring the PDCCH for the UL grant. If an UL grant is received, the UE may continue to wait for the transmission opportunity as already described above.

[0173] However, in general, the UE may not receive an expected uplink grant. Correspondingly, when monitoring whether a transmission opportunity occurs (S2140), the UE may determine that under certain conditions, the expected uplink grant is not likely to be received and / or the opportunity is not likely to occur. In particular, the transmission opportunity to wait for may be not likely to occur when the expected uplink grant has not been received and is no longer expected to be received. Correspondingly, the UE may determine that a transmission opportunity will not occur and / or initiate a (new) RACH procedure to enter a connected state. In particular, if the UE has not received a UL grant upon receipt of the RRCRelease message, the UE may initiate an RRC resumption procedure. In particular, the UE may then immediately initiate a legacy RRC resumption procedure (e.g., without waiting for the end of the SDT procedure and / or the RACH procedure that initiated the SDT procedure).

[0174] For example, if the transceiver receives an indication indicating the end of the procedure for transmitting SDT DRB data, it may be unlikely to receive the expected uplink grant. Note that this indication indicating the end of the SDT procedure may be the reception of Msg4 or MsgB. However, as mentioned above, the RACH procedure may generally end earlier than the SDT procedure. More specifically, as also shown in FIG. 17, the RACH procedure generally ends when the contention is resolved, whereas the SDT procedure generally ends when the RRCRelease message is received. Thus, the indication indicating the end of the SDT procedure may be the RRCRelease message received from the base station.

[0175] In general, it may alternatively or additionally be the case that an expected uplink grant is unlikely to be received if a predetermined time has elapsed since the first or previous transmission of at least a portion of the SDT DRB data. The predetermined time may be provided, for example, by a T319 timer or a T319-like timer as described above. However, the predetermined time used by the UE to determine whether an UL grant is still expected may also be another predetermined period of time during which the UE waits to receive an UL grant.

[0176] <Determining whether there is a transmission opportunity to wait for (S2120)> 1. RACH Procedure If non-SDT traffic arrives during a RACH-based SDT procedure, the UE may determine that there is a transmission opportunity to wait for if it has not yet transmitted the first transmission of the RACH procedure (in other words, if the non-SDT traffic arrives after T A The UE then waits for a transmission opportunity (S2140) and may use the transmission opportunity to transmit a traffic indication.

[0177] In addition, non-SDT traffic is BIf a non-SDT traffic indication arrives in S2140 and the UE expects that an UL grant will soon be assigned by the gNB (i.e., it previously sent a BSR, but the gNB has not assigned a grant for the BSR for the SDT DRB), the UE may determine that there is a transmission opportunity for which to wait. In particular, the UE may determine that the resources of the transmission opportunity for which to wait are specified by the expected UL grant. The UE may then wait for the next UL grant (S2140) and send a non-SDT traffic indication in that grant to the gNB.

[0178] However, in general, non-SDT traffic is B , the UE may not have any further UL grant to transmit the DCCH, and therefore may need to initiate a new RACH only to transmit the DCCH. Therefore, if only SDT DRBs can be transmitted in the SDT procedure, another UL grant is required for the UE to transmit the indication. Therefore, if non-SDT traffic arrives during a RACH-based SDT procedure, the UE may determine that there is no transmission opportunity to wait for if the UE has already transmitted the first transmission of the RACH procedure and is not likely to receive an UL grant. In particular, the UE may determine that there is no transmission opportunity to wait for after transmitting (all) SDT DRB data (e.g., when the circuit 1830 has controlled the transceiver 1820 to transmit SDT DRB data). In other words, if non-SDT traffic arrives during the T B If the UL grant arrives at and the UE does not expect that an UL grant is going to be assigned by the gNB (i.e., it has not previously transmitted a BSR or the BSR has been resolved by the gNB), the UE may determine that there is no transmission opportunity to wait for and may initiate a legacy RRC resumption procedure (e.g., immediately without waiting for the completion of the SDT procedure and / or the RACH procedure that initiated the SDT procedure).

[0179] The handling of the arrival of non-SDT traffic during a RACH-based SDT procedure, including the determination S2120 of whether there is a transmission opportunity to wait for, is summarized again with reference to FIG. 24, which exemplarily illustrates this handling. More specifically, in FIG. 24, it is exemplarily assumed that SDT traffic arrived when the UE was in RRC_INACTIVE, and that the UE triggered the SDT procedure accordingly (S2410). It is further assumed that the UE has already transmitted the RACH preamble of the four-step RACH procedure to initiate the SDT procedure. Note that the term "triggered" here means that the UE has internally decided / determined to perform the SDT procedure, whereas the term "initiate" means the first message of the SDT procedure that can make the scheduling device aware of the UE's decision to perform the SDT procedure. Thus, after S2410, the UE enters the RACH-based SDT procedure to transmit small data. It is further assumed that non-SDT traffic then arrives and / or is detected by the UE.

[0180] As can be further appreciated, when non-SDT traffic arrives, the UE may first determine whether it has already sent a first RACH message (YES or NO at S2420). However, it should be noted that the UE may first determine whether there is still an ongoing SDT procedure (YES or NO at S2430), i.e., whether it has already received a message that terminates the SDT procedure (e.g., an RRCRelease message), which implies NO at both S2420 and S2430. In other words, the UE may, but does not necessarily, perform the individual determinations associated with S2420, S2430, S2440, and S2450, and in particular, may not perform these determinations in the particular order illustrated in FIG.

[0181] As shown in FIG. 24, if non-SDT traffic arrives before the UE transmits all its messages of the RACH procedure (e.g., transmits Msg3 / MsgA) (YES in S2420), the UE can include a traffic indication in the subsequent RACH message indicating the detection of non-SDT DRB data (S2421). In other words, if the non-SDT DRB data is within the period T A If the traffic indication is detected within the RACH message, the UE may determine that there is a transmission opportunity (i.e., a subsequent RACH message) to wait for. As further shown in FIG. 24, in response to this traffic indication, the scheduling device may terminate the RACH procedure with a message indicating a transition to a connected state (e.g., an RRCResume message) rather than a message indicating a return to an inactive state (e.g., an RRCRelease message). Thus, the UE may receive a message indicating a transition to a connected state (S2422) and enter a connected state (e.g., an RRC_CONNECTED state) (S2423). The UE may then transmit non-SDT DRB data.

[0182] As can be further understood, if non-SDT traffic arrives after i) ("No" in S2420) the UE has sent all its messages (e.g., Msg3 / MsgA) of the RACH procedure, and ii) ("No" in S2430) the UE has received a message to terminate the SDT procedure (S2431), the UE will be / remain in RRC_INACTIVE (S2432). In other words, if the UE has already received a message to terminate the SDT procedure when non-SDT DRB data is detected and / or there is no ongoing SDT procedure, the UE may determine that there is no transmission opportunity to wait for. Thus, the UE may initiate a RACH procedure (legacy RRC resume procedure) in order to enter a connected state and be able to transmit non-SDT DRB data.

[0183] Furthermore, if i) non-SDT traffic arrives after the UE has performed all of its own transmissions of the RACH procedure ("No" at S2420), and ii) non-SDT traffic arrives before receiving a message indicating the end of the SDT procedure ("Yes" at S2430), and iii) the UE has not sent a buffer status report indicating a non-zero buffer size for SDT DRB data ("No" at S2440), the UE may initiate a RACH procedure (legacy RRC resume procedure) (S2441) to enter a connected state (S2442) and be able to transmit non-SDT DRB data. In particular, if i) the UE has performed all of its own transmissions of the RACH procedure, and ii) the UE has not sent a buffer status report indicating a non-zero buffer size for SDT DRB data, the UE may determine that there is no transmission opportunity to wait for. Similarly, if a UE transmits a BSR but has already received corresponding UL grants that have been used to transmit small data (using those UL grants to transmit data of the size indicated in the BSR), the UE may determine that there is no transmission opportunity to wait for.

[0184] On the other hand, if i) non-SDT traffic arrives after the UE has performed all of its transmissions of the RACH procedure ("No" at S2420), and ii) non-SDT traffic arrives before receiving a message indicating the end of the SDT procedure ("Yes" at S2430), and iii) the UE has sent a buffer status report indicating a non-zero buffer size for SDT DRB data ("Yes" at S2440), the UE may determine that there is a transmission opportunity to wait for (i.e., a transmission expected to be indicated by an UL grant expected to be received in response to its BSR). Thus, the UE may wait for that UL grant and / or monitor the PDCCH.

[0185] If the expected UL grant is received before the SDT procedure is terminated by a corresponding message from the base station ("Yes" in S2450), the UE may include a traffic indication indicating detection of non-SDT DRB data in a transmission using the resources indicated by the UL grant (S2451). Receipt of the UL grant may mean that a transmission opportunity occurs to wait for. In response to the traffic indication, the scheduling device may terminate the SDT procedure with a message indicating a transition to a connected state (e.g., an RRCResume message) rather than a message indicating a return to an inactive state (e.g., an RRCRelease message). Thus, the UE may receive a message indicating a transition to a connected state (S2452) and enter a connected state (e.g., an RRC_CONNECTED state) (S2453). The UE may then transmit non-SDT DRB data.

[0186] On the other hand, if the UE receives a message terminating the SDT procedure (e.g., RRCRelease message) before receiving an UL grant (No at S2450), the UE may initiate a new RACH procedure as already described above in relation to S2441 and S2442. This may involve determining that an expected UL grant is no longer expected, meaning that there is no transmission opportunity to wait for.

[0187] 2. Configured Grant (CG) Procedure As already mentioned above, the procedure for transmitting SDT DRB data may be a Configured Grant for SDT DRB data transmission (CG) procedure. As described in more detail below, if non-SDT DRB traffic arrives during a CG-based SDT procedure, the UE may i) send a non-SDT traffic indication to the gNB in ​​dedicated UL resources received before the end of the SDT procedure, or ii) initiate a legacy RRC resumption procedure. Here, the dedicated UL resources may be CG resources configured for the UE for the transmission of SDT DRB data before / when the UE enters an inactive state.

[0188] When the UE detects (e.g., by circuits 1830, 1835, and / or 1936) the arrival of non-SDT DRB data during a CG-based SDT procedure, if the next resource of the CG procedure is earlier (in the time domain) than the next RACH resource, it may determine (e.g., by circuits 1830, 1835, or circuit 1937 as part of step S2120) that there is a transmission opportunity to wait for. In particular, this determination step may include determining that the next resource(s) of the CG procedure is a transmission opportunity to wait for. The UE (e.g., associated circuitry) may then transmit a traffic indication using the next CG resource(s). For example, after waiting for the transmission opportunity (S2140) (as already described above), the UE (e.g., circuit 1830) may control the transceiver to transmit a traffic indication using the transmission opportunity.

[0189] On the other hand, if the next resource for the CG procedure is later than the next RACH resource, it may be determined (e.g., also as part of step S2120) that there is no transmission opportunity to wait for. In this case, the UE may initiate (S2130) a RACH procedure to enter a connected state using the next RACH resource. In particular, this step may include using the next RACH resource to transmit a first transmission (e.g., Msg1 or MsgA) of the RACH procedure.

[0190] It should be noted that for a CG-based SDT procedure, the determining step S2120 may include determining whether the next RACH resource is earlier than the next CG resource (or is not later than the next CG resource).

[0191] In other words, if non-SDT traffic arrives when the UE is configured with CG resources for SDT transmission, the UE may either send a non-SDT traffic indication in (part of) the CG resources to the scheduling device or initiate a legacy RRC restart procedure, depending on which has the shorter delay.

[0192] Alternatively, the delay threshold can be signaled to the UE. In that case, the UE can compare the delay threshold with the time to the next CG resource and make a decision accordingly. For example, the UE can determine that the next CG resource is a transmission opportunity to wait for if the time to the next CG resource is less than (or not greater than) the delay threshold (even if the delay to the next RACH resource is less than) the delay threshold. In other words, the UE can determine that the next CG resource is a transmission opportunity to wait for if at least one of the following conditions is true: i) the next CG resource is earlier than (or not later than) the next RACH resource, or ii) the time to the next CG resource is less than (or not greater than) the delay threshold. Thus, the UE can decide to initiate a RACH procedure to enter a connected state if both of the following conditions are true: i) the next CG resource is later than (or not earlier than) the next RACH resource, and ii) the time to the next CG resource is greater than (or not less than) the delay threshold.

[0193] Such a delay threshold allows the UE to flexibly adjust the delay it tolerates, taking into account traffic conditions such as the probability of RACH collision with other UEs.

[0194] If the next CG resource has the same delay as the next RACH resource (in other words, neither the next CG resource nor the next RACH resource is earlier), the UE may select the CG resource, which has the advantage of avoiding contention with other UEs.

[0195] <Non-SDT DRB traffic indication> The traffic indication indicates to the scheduling device that the UE has detected non-SDT DRB data, that non-SDT DRB data has arrived, and / or that non-SDT DRB data is expected to arrive. Thus, both the UE and the base station understand the respective traffic indications, which are described further below. In particular, the UE (e.g., circuits 1830 and / or 1835) can generate and / or include the respective traffic indications in transmissions, particularly transmissions of small data. The base station (e.g., circuits 1880, 1885, and / or 2036) can extract the traffic indications from the transmissions, particularly transmissions of small data, and / or can interpret the extracted traffic indications as intended by the UE.

[0196] In general, the traffic indication may also indicate that the UE expects non-SDT DRBs to arrive (e.g., in the near future). In other words, if the UE expects non-SDT data to arrive before such arrival actually occurs, the UE may determine that non-SDT data is arriving and may further indicate the arrival to the base station using the traffic indication.

[0197] In general, the traffic indication may be transmitted together with i) at least a portion of the SDT DRB data using resources indicated by the uplink grant, and / or ii) a buffer status report (BSR) indicating the amount of SDT DRB data (e.g., the amount to be transmitted further). In general, the BSR for non-SDT DRB data may also be included in the message containing the traffic indication or may be the traffic indication. However, if the UE does not resume the non-SDT DRBs when the SDT procedure is triggered, the UE may not be able to generate a BSR for the non-SDT DRBs because traffic from the non-SDT DRBs may not reach the Layer 2 buffer.

[0198] The non-SDT traffic indication is to inform the gNB of the arrival of non-SDT traffic and can be either a MAC level indication or an RRC level indication, as further described below.

[0199] <MAC level indication of non-SDT DRB traffic> 1. Traffic indication by MAC subheader Generally, the traffic indication may be signaled by a predefined value of a logical channel ID (LCID) in the MAC subheader, where the predefined value of the LCID indicates that non-SDT DRB data has been detected.

[0200] For example, a predefined value of LCID indicating the arrival of non-SDT traffic may (further) indicate that no MAC Control Element (CE) is added to the MAC subheader. This is shown in FIG. 25, where the traffic indication corresponds to the last MAC subheader with LCID index=50. In general, a MAC subheader with a particular LCID index (e.g. index #50 as shown in FIG. 25 and Table 1 below) may be used to indicate the arrival of non-SDT traffic, without appending a BSR MAC CE after the subheader. In other words, the MAC subframe containing the traffic indication (i.e. the MAC subheader with that particular / predetermined LCID index) does not carry a MAC CE. For example, this MAC subframe may consist of a MAC subheader.

[0201] By not appending the BSR MAC CE to the subheader indicating the arrival of non-SDT DRB data, the UE can not resume the non-SDT DRB at the beginning of the SDT procedure. More specifically, upon recognizing / detecting the arrival of non-SDT data at higher layers (e.g. SDAP layer), the UE can transmit such a MAC subheader at that time to indicate the arrival of non-SDT data. Since the UE does not need to transmit a BSR for non-SDT data, the UE does not need to resume the non-SDT DRB. Furthermore, overhead can be reduced since the MAC subheader typically consumes only 8 bits, while the BSR MAC CE consumes at least 16 bits (8 bits for short BSR + 8 bits for subheader). [Table 2]

[0202] Alternatively, the LCID indicating the arrival of non-SDT traffic may (further) indicate that a BSR MAC Control Element (CE) has been added to the MAC subheader, the BSR MAC CE indicating the amount of SDT DRB data to be further transmitted.

[0203] Therefore, if the UE still has some pending data for the SDT DRB when non-SDT traffic arrives, the UE can inform the scheduling device of such a situation by using a MAC subheader with a specific LCID index number (e.g. index #51) and appending a short BSR MAC CE after this subheader indicating the amount of remaining SDT DRB data. This is shown in Figure 26, where the traffic indication corresponds to the last MAC subheader with LCID index=51. As can be seen, a short BSR MAC CE is appended to this MAC subheader with LCID index=51 indicating the size of the remaining SDT DRB data.

[0204] By appending the BSR MAC CE to the subheader indicating the arrival of non-SDT DRB data, it becomes easier to indicate the size of the remaining SDT DRB data and can avoid the UE having to restart non-SDT DRBs at the start of an SDT procedure since it is expected that the buffer size of non-SDT DRBs is not reported.

[0205] Alternatively, note that when resuming non-SDT DRBs at the start of an SDT procedure, the BSR MAC CE can also be used to indicate the amount of non-SDT DRB data to be transmitted.

[0206] Furthermore, it should be noted that in general, one or both of the MAC subheaders (indicating no MAC CE attached and that MAC CE attached) can be provided. If both are provided (e.g., as defined in the standard or configured by the scheduling device), the UE can use the MAC subheader for traffic indication with CE attached to indicate the SDT DRB buffer size when appropriate (e.g., if the buffer size is non-zero) and can use the MAC subheader for traffic indication without CE attached to reduce overhead.

[0207] 2. Traffic direction by the MAC control element In general, the traffic indication may be part of the MAC Control Element (CE), for example, one bit of the MAC CE indicating whether non-SDT DRB data is detected, two bits of the MAC CE indicating the Logical Channel Group (LCG) of SDT DRB data among the LCGs that support sending data in the inactive state, and five bits of the MAC CE indicating the amount of SDT DRB data to be sent further corresponding to the indicated LCG.

[0208] In other words, when reporting the buffer status of the SDT DRB, a new BSR MAC CE can be used to indicate the arrival of non-SDT DRB data. Figure 27 shows such an exemplary new MAC CE. More specifically, the upper part of Figure 27 shows a legacy short BSR, and the lower part shows an exemplary MAC CE with traffic indication. As can be seen from Figure 27, the legacy short BSR MAC CE contains 8 bits, of which 3 bits (the first 3 bits in Figure 27) are used to indicate the LCG ID, and the remaining 5 bits (the last 5 bits in Figure 27) are used to indicate the buffer size. Note that each SDT DRB is typically mapped to one LCG (many-to-one mapping is also possible), and such mapping is configured by the gNB.

[0209] The new BSR MAC CE differs from the legacy short BSR MAC CE in that the UE uses only 2 bits (the first 2 bits in Figure 27) to indicate which LCG it is reporting. For example, some LCGs may be suspended and only some LCGs may be active. In other words, the maximum number of active LCGs that the UE can have in RRC_INACTIVE can be set to 4. Therefore, the new BSR MAC CE can only be used to indicate the buffer size of the LCGs that support data transmission in the inactive state. In other words, in the new BSR MAC CE, by reducing the number of bits used to indicate the LCG and reusing the remaining bits, it takes advantage of the fact that it is not possible to report BSRs for suspended LCGs / DRBs (because traffic does not flow into the L2 buffer).

[0210] Furthermore, in the new BSR MAC CE, 5 bits (the last 5 bits in Figure 27) are still used to report the buffer size, and the remaining 1 bit (the 3rd bit in Figure 27) is used to indicate the arrival of non-SDT DRBs. It should be noted that the bit order shown in Figure 27, especially the position of the bit indicating non-SDT traffic, is for illustration only. For example, the position of the bit indicating non-SDT traffic may be any other position, such as the first or last (8th) position.

[0211] Using such a new BSR MAC CE can reduce the signaling overhead because in the new format, it can report not only the BSR of SDT DRB data but also the arrival of non-SDT traffic. Also, since no BSR is expected for inactive LCGs, the UE can refrain from restarting non-SDT DRBs at the start of the SDT procedure.

[0212] <RRC level indication> In general, the traffic indication may be a Radio Resource Control (RRC) level indication. This RRC level indication can be conveyed, for example, in a new UL DCCH message. For example, the new DCCH message can be similar to the almost empty message RRCReestablishmentComplete. Such an exemplary UL-DCCH message is shown below (new information elements are bolded and underlined): The message type indNonSDTDRBArrival is introduced to signal an indication of the arrival of non-SDT DRB data. [Table 3]

[0213] The INDNonSDDTDRBArrival message in this example has no specific information elements, except for the following formal description, and is very similar to the RRCReestablishmentComplete message defined in 3GPP TS 2013. When this message is present (received), it indicates the following: [Table 4]

[0214] <UE criteria for multiplexing> BSR reporting of non-SDT traffic is also possible if non-SDT DRBs are also resumed at the start of the SDT procedure. In this case, upon receiving an UL grant for the transmission of SDT DRB data, the UE may choose to transmit one or more of the following using the resources indicated by the UL grant: - SDT DRB user data (e.g. SDT DRB data), - the BSR of the SDT traffic (e.g. the size of the SDT DRB data to be sent further), - in case of detection / arrival of non-SDT DRB data, a non-SDT DRB arrival indication (e.g. traffic indication), - In case of detection / arrival of non-SDT DRB data, the BSR of non-SDT traffic (e.g. size of arrived / detected non-SDT DRB data)

[0215] The selection criteria may be based on a comparison of priorities (between SDT and non-SDT traffic) and the size of the grant. Note that if a BSR for non-SDT data is sent, then no additional traffic indication may be required to indicate the arrival of non-SDT data. Note further that if all SDT DRB data is sent using the resources indicated by the current UL grant, then a BSR for SDT data may not be required.

[0216] Therefore, in general, if the resources indicated by the UL grant are sufficient, the UE can transmit the entire user data and the BSR of non-SDT data. On the other hand, if the resources indicated by the UL grant are not sufficient to transmit the entire user data and the BSR of non-SDT data, the following is done: - If the priority of non-SDT data is higher than the priority of SDT data, the UE may decide to use the resources indicated by the UL grant to transmit a BSR for non-SDT data, a BSR for SDT data and part of the SDT (in this order of priority). - If the priority of SDT data is higher than the priority of non-SDT data, the UE may decide to use the resources indicated by the UL grant to transmit: o Traffic indications and SDT data in full, or If resources are not sufficient to transmit the entire traffic indication and SDT data, the traffic indication, the BSR of the SDT data, and part of the SDT data

[0217] For example, when the size of user data (including the sub-header) is 88 bits, the size of each BSR (including the sub-header) is 16 bits, and the arrival indication of non-SDT traffic is 8 bits, the UE can choose to transmit the following. - When the grant has a size of 100 bits and non-SDT traffic has a higher priority than SDT traffic, the UE can transmit the BSR of SDT traffic (16 bits), the BSR of non-SDT traffic (16 bits), and 68 bits of user data (the user data can be segmented and 68 bits of the user data are transmitted). Therefore, 100 bits are transmitted using the UL grant. - When the grant has a size of 100 bits and SDT traffic has a higher priority than non-SDT traffic, the UE can transmit all the user data (88 bits) and the arrival indication of non-SDT DRB (8 bits). Therefore, 96 bits are transmitted using the UL grant. - When the size of the grant is 110 bits and SDT traffic has a higher priority than non-SDT traffic, the UE can transmit all the user data and the BSR of non-SDT traffic. Therefore, 104 bits are transmitted using the UL grant.

[0218] By using the grant according to the priority as described above, efficient use of the allocated resources can be promoted.

[0219] <Processing of SDT traffic with RA-SDT set> The above-mentioned process in case of arrival of non-SDT traffic during an ongoing SDT procedure can also be applied to traffic associated with LCH restriction. In particular, the above-mentioned process can be applied in case of arrival / detection of RA-SDT traffic during ongoing transmission of CG-SDT traffic. In other words, if the ongoing SDT procedure is an ongoing CG procedure for transmitting small data, the arrival of RA-SDT traffic can be managed in a similar manner to the case of arrival of non-SDT traffic. In particular, the UE can send a traffic indication to the scheduling device indicating the arrival / detection of RA-SDT traffic. For example, the UE can signal a traffic indication to the gNB upon arrival of SDT traffic of an LCH not associated with a CG-SDT procedure. Such a traffic indication is to inform the gNB of the arrival of traffic with only RA-SDT configured. The UE can initiate the RA-SDT procedure if it has not received or is not expected to receive CG-SDT resources. In other words, the RA-SDT traffic takes the role of non-SDT traffic in the above-mentioned embodiment. For example, the arrival / detection of non-SDT traffic corresponds to the arrival / detection of RA-SDT traffic, and the traffic indication sent by the UE indicates the arrival of RA-SDT data but not the arrival of non-SDT data.

[0220] The main difference is that both data (data of ongoing transmission and newly detected data) are transmitted in the inactive state. As a result, if there is no transmission opportunity to wait for, instead of initiating a RACH procedure to enter a connected state (S2130), the UE initiates an RA procedure and transmits RA-SDT traffic using RA resources (e.g., RA resources associated with a second logical channel) while remaining in the inactive state. Furthermore, in response to receiving a traffic indication, the scheduling device provides the UE with one or more grants for transmission of RA-SDT data without transitioning the UE to a connected state.

[0221] This procedure is explained in more detail below. However, not all of the explanations given above for the case of non-SDT data also apply in the case of RA-SDT data arrival. In this regard, it is noted that, apart from the differences just explained, everything said above regarding the processing of the arrival of "non-SDT data" can also be applied to the processing of the arrival of "RA-SDT data", e.g. by replacing the term "non-SDT data" by the term "RA-SDT data", unless the context indicates otherwise.

[0222] In particular, as shown in FIG. 28 (left side), according to an exemplary embodiment, a user equipment (UE) 2810 is provided. The UE 2810 includes a transceiver 2820 and a circuit 2830. The circuit 2830 (e.g., circuit 2835) in operation detects that second data of a second logical channel is transmitted in an inactive state during a procedure for transmitting first data of a first logical channel in an inactive state. The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, and the second logical channel (i) is not configured with a CG resource for transmitting in the inactive state, and (ii) is configured with a random access (RA) resource for transmitting in the inactive state. In operation, the circuit 2830 determines whether there is a transmission opportunity to wait for. The transmission opportunity (i) is a transmission opportunity for transmitting at least a portion of the first data, and (ii) is expected to occur as part of the procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuit 2830, in operation, initiates an RA procedure to transmit the second data using the RA resource. When it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuit 2830, in operation, controls the transceiver 2820 to use the transmission opportunity to transmit a traffic indication indicating detection of the second data.

[0223] FIG. 29 illustrates an exemplary functional structure of the circuit 2830, i.e., the circuit for processing the arrival of RA-SDT data. As illustrated, the RA-SDT data arrival processing traffic indication processing circuit 2830 may include an RA-SDT data detection circuit 2936 and a transmission opportunity determination circuit 2937. More specifically, the circuit 2936 detects the RA-SDT data, for example, by detecting or determining whether there is RA-SDT data to be transmitted. The circuit 2936 may also determine whether the arrival of RA-SDT is expected. The transmission opportunity determination circuit 2937 may determine whether there is a transmission opportunity to wait for. Furthermore, if the circuit 2937 determines that there is a transmission opportunity to wait for, it may also determine the transmission opportunity (e.g., the resource of the transmission opportunity) to wait for.

[0224] Corresponding to the above-mentioned UE, according to another exemplary embodiment, a communication method performed by the UE is provided. As shown in FIG. 31, the method includes the following steps: - a step S3110 of detecting, during a procedure for transmitting first data of a first logical channel in an inactive state, that second data of a second logical channel is transmitted in an inactive state; - a step S3120 of determining whether there is a transmission opportunity to wait for; - when it is determined in S3120 that there is no transmission opportunity to wait for or that a transmission opportunity to wait for is no longer likely to occur ("No" in S3140), initiating an RA procedure to transmit second data using RA resources S3130; - when it is determined that there is a transmission opportunity to wait for (S3120) and the transmission opportunity occurs ("Yes" in S3140), using the transmission opportunity to transmit a traffic indication indicating detection of second data S3150; Includes.

[0225] As also shown in Fig. 28 (right side), according to another exemplary embodiment, a scheduling device 2860 is provided. The scheduling device 2860 comprises a transceiver 2870 and a circuit 2880. The circuit 2880, in operation, controls the transceiver 2870 to receive a transmission including first data of a first logical channel from a user equipment (UE) in an inactive state. The circuit 2880, in operation, obtains a traffic indication from the received transmission including the first data. The traffic indication indicates that second data of a second logical channel has been detected by the UE. The second data is data transmitted by the UE in an inactive state, and the traffic indication is signaled by a predefined value of a logical channel ID (LCID) in a MAC subheader, and the predefined value of the LCID indicates that the second data has been detected.

[0226] 30 illustrates an exemplary functional structure of the traffic indication processing circuit 2885. In particular, the traffic indication processing circuit 2885 may include a traffic indication evaluation circuit 3036 and a scheduling circuit 3037. The circuit 3036 may be responsible for obtaining and interpreting a traffic indication from a transmission including small data. Furthermore, once the circuit 3036 obtains a traffic indication from a received transmission, the circuit 3037 may be responsible for transmitting a grant to the UE to transmit RA-SDT data (i.e., "second data").

[0227] Further, a communication method is provided corresponding to the above-mentioned base station, which is performed by a scheduling device. As shown in FIG. 32, the method includes the following steps: - a step S3210 of receiving a transmission comprising first data on a first logical channel from a UE in an inactive state; - a step S3220 of obtaining a traffic indication indicating that second data of a second logical channel has been detected by the UE from the transmission including the first data, where i) the second data is data transmitted by the UE in an inactive state, ii) the traffic indication is signaled by a predefined value of a Logical Channel ID (LCID) in the MAC subheader, and iii) the predefined value of the LCID indicates that the second data has been detected; Includes.

[0228] It should be noted that, similar to the case of non-SDT data arrival, a transmission opportunity to await means (i) a transmission opportunity for transmitting at least a portion of the first data, and (ii) a transmission opportunity that is expected to occur as part of the procedure for transmitting the first data.

[0229] It should be noted here that the terms RA-SDT traffic and RA-SDT data refer respectively to (i) traffic and data of a logical channel (also referred to herein as a second logical channel) for which no CG resource is configured for transmission in the inactive state and a random access (RA) resource is configured for transmission in the inactive state. In particular, the second logical channel (LCH) may be configured and / or associated with only RA resources for transmission in the inactive state. It should be noted that the RA-SDT data is also referred to as second data. It should be noted that the RA resource for transmitting data in the inactive state may be different or the same as the RACH resource for entering the active state (e.g., for transmitting msg1).

[0230] The terms CG-SDT traffic and CG-SDT data refer to traffic and data, respectively, of a logical channel (also referred to as the first logical channel in this specification) for which CG resources are configured for transmission in an inactive state. It should be noted that RA-SDT data is also referred to as the first data. It should be noted that the first LCH may or may not be configured with RA resources. However, this embodiment relates to the case where the procedure for transmitting the first data is a Configured Grant (CG) procedure for transmitting the first data.

[0231] In general, a UE may be configured with multiple logical channels (LCHs). An LCH may be configured with RA-SDT resources for transmission in an inactive state and / or CG-SDT resources for transmission in an inactive state. For example, an LCH may be configured with either (i) RA-SDT or (ii) CG-SDT and RA-SDT. This is illustrated in Figure 33, where a UE is configured with two logical channels, denoted as LCH1 and LCH2, respectively. As illustrated, LCH1 is configured with CG-SDT and RA-SDT, and LCH2 is configured with only RA-SDT. If traffic on LCH1 is available, the UE may transmit traffic via CG-SDT if the CG-SDT criteria are met. Otherwise, if the criteria are not met, the UE may transmit traffic via RA-SDT. On the other hand, if traffic on LCH2 is available, the UE may transmit traffic only via RA-SDT. In general, existing signaling may be reused to apply restrictions on LCHs. It may be up to the gNB how the restrictions are configured. In other words, the base station can configure an RA-SDT and / or a CG-SDT for each LCH.

[0232] As already mentioned above, the traffic indication, the determination of whether there is a transmission to await and other aspects of the handling of the arrival of RA-SDT traffic during an ongoing CG-SDT procedure are substantially similar to the corresponding aspects described above for the handling of the arrival of non-SDT traffic, in particular:

[0233] In general, if the next resource of the CG procedure is earlier than the next RA resource of the RA resources, it can determine that there is a transmission opportunity to wait for (S3120). In this case, the transmission opportunity can be used to transmit a traffic indication. Furthermore, if the next resource of the CG procedure is later than the next RA resource, the circuit can determine that there is no transmission opportunity to wait for (S3120) and initiate an RA procedure to transmit second data using the RA resource (S3130). In other words, the UE can transmit a traffic indication to the gNB in ​​the CG resource or initiate an RA-SDT procedure depending on which delay is shorter.

[0234] However, the present invention is not limited thereto, and in general, the UE may also determine whether there is a transmission opportunity to wait for (S3120) based on a comparison of the time to the next resource of the CG procedure with a delay threshold. In other words, a delay threshold may be signaled to the UE for the UE to compare with the time to the next CG resource and make a decision based on the result of the comparison. For example, the UE may decide to wait for a transmission opportunity if the time to the transmission opportunity is less than or equal to the threshold, and / or decide not to wait for a transmission opportunity if the time to the transmission opportunity is greater than the threshold. However, the UE may also decide not to wait if the time to the transmission opportunity is equal to the threshold. Furthermore, in general, the UE may also take other criteria into account when deciding whether to wait for a transmission opportunity. Such a threshold may be signaled by the gNB, pre-configured, or a predetermined value.

[0235] In particular, the traffic indication may include an indication indicating the amount of the second data and / or an indication indicating the amount of the first data to be further transmitted In other words, as already mentioned above for handling the arrival of non-SDT data, the traffic indication may further include a buffer status report.

[0236] Furthermore, similar to the case of non-SDT data arrival, also in the case of RA-SDT data arrival, the traffic indication can be a radio resource control (RRC) level indication and / or a medium access control (MAC) level indication. In particular, as already explained with respect to Figures 25-27, the traffic indication can be signaled in the MAC subheader by a predefined value of the logical channel ID (LCID) in the MAC subheader, which predefined value of the LCID indicates that second data has been detected. For example, a MAC subheader with a specific LCID index (e.g. index #49) can be used to indicate the arrival of traffic with / without the addition of the BSR MAC CE.

[0237] In this regard, it is noted that the UE (e.g., circuit 2830) can decide whether to add a BSR MAC CE to the MAC subheader, indicating (i) the amount of the first data to be further transmitted, and / or (ii) the amount of the second data. This decision can depend, for example, on the size of the configured grant. More specifically, the UE can decide to add a BSR if the CG resource of the transmission opportunity is greater than or equal to a threshold, and / or decide not to add a BSR if the size of the transmission opportunity is less than a threshold. In particular, the just-described threshold can correspond to the size of the BSR. In other words, the BSR(s) can be included if the size of the unused portion of the configured grant is greater than or equal to the BSR(s). More specifically, the UE can include the BSR(s) if the size of the configured grant (i.e., the transmission opportunity used to transmit the traffic indication) is sufficient to convey the BSR(s). Here, "sufficient" means, for example, that the size of the configured grant is sufficient to transmit (i) the data of the first logical channel to be transmitted, (ii) the traffic indication, and (iii) the BSR(s) of the first data and / or the second data. The data of the first logical channel to be transmitted can be, for example, currently available data of the first logical channel, data of the first logical channel that the UE has decided to transmit using the configured grant, and / or data of the first logical channel to be transmitted as a result of, for example, QoS considerations of a service associated with the first logical channel.

[0238] However, the present invention is not limited thereto. Generally, a pre-defined value of the LCID can indicate that no MAC control element (CE) is added to the MAC sub-header. However, generally, the LCID can also indicate that a buffer status report (BSR) MAC control element (CE) is added to the MAC sub-header, and the BSR MAC CE further indicates the amount of the first data to be transmitted. Instead of or in addition to this, the LCID can indicate that a BSR MAC CE indicating the amount of the second data is added to the MAC sub-header.

[0239] Also, in the case of the arrival of RA-SDT data, the traffic indication can be part of a media access control (MAC) control element (CE). In this case, (i) 1 bit of the MAC CE can indicate whether the second data is detected, (ii) 2 bits of the MAC CE can indicate the first logical channel group (LCG) among the LCGs that support the transmission of data in the inactive state, and (iii) 5 bits of the MAC CE can indicate the amount of the second data. It should be noted that. Instead of this, as already described above for the case of the arrival of non-SDT DRB data, 5 bits can indicate the amount of the first data to be further transmitted.

[0240] <Advantages of RA-SDT Traffic Processing> The above-mentioned process when RA-SDT data arrives during an ongoing CG-SDT procedure can reduce overhead, reduce power consumption, and prevent the RA-SDT procedure from affecting the ongoing CG-SDT transmission for LCH1. More specifically, as shown in FIG. 34, if the UE triggers RA-SDT while a CG-SDT procedure is already in progress, the signaling overhead of the UE may increase. As shown, traffic of LCH1 that needs to be transmitted periodically through CG resources is available. During the subsequent transmission of LCH1, traffic of LCH2 becomes available. However, LCH2 is not mapped to a CG configuration. If the UE triggers RA-SDT to transmit data of LCH2 for which CG resources are not configured, not only will the signaling overhead of the UE increase, but the ongoing CG-SDT transmission of LCH1 may be affected (e.g., because the UE may not be able to process CG-SDT and RA-SDT procedures simultaneously). However, according to the above disclosure, when the traffic of LCH2 becomes available, a traffic indication of the traffic of LCH2 can be sent in the next CG resource (e.g. multiplexed with the data of LCH1), as shown in Figure 35. In this way, the UE can avoid triggering the RA-SDT procedure, which may be advantageous in terms of power consumption as well as signaling overhead for the UE.

[0241] Hardware and Software Implementations of the Disclosure The present disclosure can be implemented by software, by hardware, or by software cooperating with hardware. Each functional block used in the description of each embodiment above can be implemented in part or in whole by an LSI such as an integrated circuit, and each process described in each embodiment can be controlled in part or in whole by the same LSI or a combination of LSIs. The LSI can be formed as a chip individually, or a single chip can be formed to include some or all of the functional blocks. The LSI can include a data input / output unit coupled to it. Here, the LSI is also referred to as an IC, a system LSI, a super LSI, or an ultra LSI depending on the degree of integration. However, the technology for implementing the integrated circuit is not limited to the LSI, and may be implemented by using a dedicated circuit, a general-purpose processor, or a dedicated processor. Furthermore, an FPGA (field programmable gate array) that can be programmed after the LSI is manufactured, or a reconfigurable processor that can reconfigure the connection and settings of the circuit cells arranged inside the LSI, can also be used. The present disclosure can be implemented as digital processing or analog processing. If, as a result of advances in semiconductor technology or other derivative technologies, LSI is replaced by a future integrated circuit technology, the future integrated circuit technology can be used to integrate the functional blocks. Biotechnology can also be applied.

[0242] The present disclosure may be implemented by any kind of apparatus, device or system having a communication capability (referred to as a communication apparatus).

[0243] A communication device may include a transceiver and processing / control circuitry. The transceiver may include a receiver and a transmitter and / or function as a receiver and a transmitter. The transceiver as a transmitter and a receiver may include an RF (radio frequency) module including an amplifier, an RF modulator / demodulator, etc., and one or more antennas.

[0244] Some non-limiting examples of such communications devices include phones (e.g., cell phones, smartphones), tablets, personal computers (PCs) (e.g., laptops, desktops, notebooks), cameras (e.g., digital still / video cameras), digital players (digital audio / video players), wearable devices (e.g., wearable cameras, smart watches, tracking devices), game consoles, e-book readers, telehealth / telemedicine equipment, vehicles that provide communications capabilities (e.g., cars, airplanes, ships), and various combinations thereof.

[0245] Communications devices are not limited to portable or mobile, but can also include any type of equipment, device, or system that is non-portable or stationary, such as smart home devices (e.g., appliances, lights, smart meters, control panels), vending machines, and any other "things" in the Internet of Things (IoT) network.

[0246] Communications may include, for example, exchanging data through cellular systems, wireless LAN systems, satellite systems, etc., as well as various combinations thereof.

[0247] A communications device may include devices such as a controller or a sensor coupled to the communications device to perform the communications functions described in this disclosure. For example, a communications device may include a controller or a sensor that generates control or data signals used by the communications device to perform the communications functions of the communications device.

[0248] The communications apparatus may further include infrastructure facilities, such as base stations, access points, and any other apparatus, devices, or systems that communicate with or control apparatuses such as the apparatuses in the non-limiting examples above.

[0249] Furthermore, various embodiments may be implemented by software modules, which are executed by a processor or directly in hardware. Also, a combination of software modules and hardware implementation is possible. The software modules may be stored in any type of computer-readable storage medium. In particular, according to another implementation, a non-transitory computer-readable recording medium is provided. The recording medium stores a program, which, when executed by one or more processors, causes the one or more processors to perform the steps of the method according to the present disclosure.

[0250] By way of example, and not limitation, such computer-readable storage media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. Also, any connection may be referred to as a computer-readable medium. For example, if instructions are transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, radio, microwave, etc., the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, microwave, etc., are included in the definition of media. However, it should be understood that computer-readable storage media and data storage media do not include connections, carrier waves, signals, or other transitory media, but instead cover non-transitory tangible storage media. As used herein, magnetic and optical disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks, where magnetic disks typically reproduce data magnetically and optical disks reproduce data optically using lasers. Combinations of the above are also included within the scope of computer readable media.

[0251] Moreover, it should be noted that individual features of the different embodiments may be the subject of another embodiment, either individually or in any combination. The disclosure shown in the specific embodiments may be subject to numerous changes and / or modifications, as will be understood by those skilled in the art. The embodiments herein are therefore to be considered in all respects as illustrative and not restrictive.

[0252] Further aspects According to a first aspect, a user equipment (UE) is provided. The UE includes a transceiver and a circuit. In operation, the circuit detects that second data is transmitted in a connected state during a procedure for transmitting first data in an inactive state. In operation, the circuit determines whether there is a transmission opportunity to wait for, where the transmission opportunity to wait for is a transmission opportunity i) for transmitting at least a portion of the first data, and ii) is expected to occur as part of the procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuit in operation initiates a random access channel (RACH) procedure to enter the connected state. When it is determined that there is a transmission opportunity to wait for and a transmission opportunity occurs, the circuit in operation controls the transceiver to use the transmission opportunity to transmit a traffic indication indicating detection of the second data.

[0253] According to a second aspect provided in addition to the first aspect, the procedure for transmitting the first data is a procedure initiated in a RACH procedure, and the transmission opportunity to wait for is i) a first transmission of the RACH procedure, ii) indicated by an uplink grant received as part of the RACH procedure, or iii) indicated by an uplink grant received for transmitting the first data after completion of the RACH procedure.

[0254] According to a third aspect provided in addition to the first aspect, the procedure for transmitting the first data is a procedure initiated in a RACH procedure, where i) the circuit, in operation, determines that there is no transmission opportunity to wait for after controlling the transceiver to transmit the first data, or ii) the transmission opportunity to wait for is expected to be indicated by an uplink grant, which is expected to be received as part of the RACH procedure or for transmitting a portion of the first data after completion of the RACH procedure.

[0255] According to a fourth aspect provided in addition to the first aspect, the uplink grant is expected to be received after the circuitry controls the transceiver to: i) transmit a first transmission of the RACH procedure; ii) transmit a Buffer Status Report (BSR) indicating an amount of the first data to be further transmitted; and / or iii) transmit a portion of the first data after transmitting the BSR, the amount of the portion of the first data being smaller than the amount indicated by the BSR.

[0256] According to a fifth aspect, provided in addition to the third or fourth aspect, the transmission opportunity to wait for is no longer likely to occur when an expected uplink grant has not been received and is no longer likely to be received, and the expected uplink grant is no longer likely to be received if i) the transceiver receives an indication indicating the end of the procedure for transmitting the first data, and / or ii) a predetermined time has elapsed since the first or previous transmission of at least a portion of the first data.

[0257] According to a sixth aspect provided in addition to one of the first to fifth aspects, the traffic indication is transmitted together with i) at least a portion of the first data using resources indicated by the uplink grant, and / or ii) a buffer status report (BSR) indicating an amount of the first data.

[0258] According to a seventh aspect provided in addition to one of the first to sixth aspects, the RACH procedure is a four-step RACH procedure or a two-step RACH procedure.

[0259] According to an eighth aspect provided in addition to the first aspect, the procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, and the circuit, in operation, i) determines that there is a transmission opportunity to wait for if the next resource of the CG procedure is earlier than the next RACH resource, and controls the transceiver to transmit a traffic indication using the transmission opportunity, and ii) determines that there is no transmission opportunity to wait for if the next resource of the CG procedure is later than the next RACH resource, and initiates a RACH procedure to enter a connected state.

[0260] According to a ninth aspect provided in addition to one of the first to eighth aspects, the traffic indication is signaled by a predefined value of a logical channel ID (LCID) in a MAC subheader, the predefined value of the LCID indicating that second data has been detected.

[0261] According to a tenth aspect provided in addition to the ninth aspect, a predefined value of LCID indicates that a MAC Control element CE is not added to the MAC subheader.

[0262] According to an eleventh aspect provided in addition to the ninth aspect, the LCID indicates that a BSR MAC Control Element (CE) is added to the MAC subheader, and the BSR MAC CE further indicates the amount of the first data to be transmitted.

[0263] According to a twelfth aspect, provided in addition to one of the first to eighth aspects, the traffic indication is part of a MAC Control Element (CE), and i) one bit of the MAC CE indicates whether second data has been detected or not, ii) two bits of the MAC CE indicate a Logical Channel Group (LCG) of the first data among the LCGs that support transmission of data in an inactive state, and iii) five bits of the MAC CE indicate the amount of the first data corresponding to the indicated LCG to be further transmitted.

[0264] According to a thirteenth aspect provided in addition to one of the first to eighth aspects, the traffic indication is a radio resource control (RRC) level indication.

[0265] According to a fourteenth aspect, there is provided a method for a user equipment (UE), the method comprising the following steps: - detecting, during a procedure for transmitting the first data in an inactive state, that the second data is to be transmitted in a connected state; - determining whether there is a transmission opportunity to wait for, the transmission opportunity being i) a transmission opportunity for transmitting at least a portion of the first data and ii) expected to occur as part of a procedure for transmitting the first data; - initiating a Random Access Channel (RACH) procedure to enter a connected state when it is determined that there is no transmission opportunity to wait for or that a transmission opportunity to wait for is no longer likely to occur; - when it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, using the transmission opportunity to transmit a traffic indication indicating detection of the second data; Includes.

[0266] According to a fifteenth aspect, there is provided a scheduling device comprising a transceiver and a circuit that, in operation, controls the transceiver to receive a transmission including first data from a user equipment (UE) in an inactive state, and, in operation, obtains a traffic indication from the transmission including the first data indicating that second data has been detected by the UE, where i) the second data is data transmitted by the UE in a connected state, ii) the traffic indication is signaled by a predefined value of a logical channel ID (LCID) in a MAC subheader, and iii) the predefined value of the LCID indicates that the second data has been detected.

[0267] According to a sixteenth aspect, there is provided a method for a scheduling device, the method comprising the steps of: - receiving a transmission from a user equipment (UE) in an inactive state, the transmission comprising first data; - obtaining a traffic indication indicating that second data has been detected by the UE from a transmission including the first data, where i) the second data is data transmitted by the UE in a connected state, ii) the traffic indication is signaled by a predefined value of a Logical Channel ID (LCID) in a MAC subheader, and iii) the predefined value of the LCID indicates that the second data has been detected; Includes.

[0268] According to a seventeenth aspect provided in addition to the fifteenth or sixteenth aspect, the transmission comprising the first data is transmitted as part of a procedure initiated in a RACH procedure.

[0269] According to an eighteenth aspect provided in addition to the seventeenth aspect, the RACH procedure is a four-step RACH procedure or a two-step RACH procedure.

[0270] According to a 19th aspect provided in addition to the 15th aspect or the 16th aspect, a transmission including the first data is transmitted as part of a configured grant (CG) procedure for transmitting the first data.

[0271] According to a twentieth aspect, provided in addition to one of the fifteenth to nineteenth aspects, a predefined value of the LCID indicates that a MAC control element (CE) is not added to the MAC subheader.

[0272] According to a 21st aspect provided in addition to one of the 15th to 19th aspects, the LCID indicates that a BSR MAC Control Element (CE) is added to the MAC subheader, and the BSR MAC CE indicates an amount of the first data to be further transmitted.

[0273] According to a twenty-second aspect, there is provided a scheduling device comprising a transceiver and a circuit, the circuit being operable to control the transceiver to receive a transmission comprising first data from a user equipment (UE) in an inactive state, the circuit being operable to obtain a traffic indication from the transmission comprising the first data, the traffic indication indicating that second data has been detected by the UE, where i) the second data is data transmitted by the UE in a connected state, and ii) the traffic indication is part of a MAC Control Element (CE), where one bit of the MAC CE indicates whether the second data has been detected, two bits of the MAC CE indicate a Logical Channel Group (LCG) of the first data among the LCGs supporting transmission of data in the inactive state, and five bits of the MAC CE indicate an amount of the first data to be further transmitted corresponding to the indicated LCG.

[0274] According to a twenty-third aspect, there is provided a method for a scheduling device, the method comprising the following steps: - receiving a transmission from a user equipment (UE) in an inactive state, the transmission comprising first data; - obtaining a traffic indication from a transmission containing the first data, indicating that second data has been detected by the UE, where i) the second data is data transmitted by the UE in a connected state, and ii) the traffic indication is part of a MAC Control Element (CE), where one bit of the MAC CE indicates whether the second data has been detected or not, two bits of the MAC CE indicate a Logical Channel Group (LCG) of the first data among the LCGs supporting transmission of data in an inactive state, and five bits of the MAC CE indicate a further transmitted amount of the first data corresponding to the indicated LCG; Includes.

[0275] According to a twenty-fourth aspect, there is provided a user equipment (UE) comprising: a transceiver and circuitry that, during operation, detects that second data of a second logical channel is transmitted in an inactive state during a procedure for transmitting first data of a first logical channel in an inactive state.

[0276] The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data. The second logical channel (i) has no CG resources configured for transmitting in an inactive state, and (ii) has random access (RA) resources configured for transmitting in an inactive state. The circuit, in operation, determines whether there is a transmission opportunity to wait for, which is (i) a transmission opportunity for transmitting at least a portion of the first data, and (ii) is expected to occur as part of the procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuit, in operation, initiates an RA procedure to transmit the second data using the RA resource. When it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuit, in operation, controls the transceiver to transmit a traffic indication indicating detection of the second data using the transmission opportunity.

[0277] According to a 25th aspect provided in addition to the 24th aspect, the circuit, in operation, (i) determines that there is a transmission opportunity to wait for if the next resource of the CG procedure is earlier than the next RA resource of the RA resource, and controls the transceiver to transmit a traffic indication using the transmission opportunity, and (ii) determines that there is no transmission opportunity to wait for if the next resource of the CG procedure is later than the next RA resource, and initiates an RA procedure to transmit second data using the RA resource.

[0278] According to a 26th aspect provided in addition to the 24th aspect, in operation the circuit determines whether there is a transmission opportunity to wait for based on a comparison of the time to the next resource in the CG procedure with a delay threshold.

[0279] According to a 27th aspect, provided in addition to one of the 24th to 26th aspects, the traffic indication is signaled in a medium access control (MAC) subheader by a predefined value of a logical channel ID (LCID) in the MAC subheader, the predefined value of the LCID indicating that second data has been detected.

[0280] According to a twenty-eighth aspect provided in addition to the twenty-seventh aspect, the circuit, in operation, determines whether to add a BSR MAC CE to a MAC subheader indicating (i) an amount of the first data to be further transmitted and / or (ii) an amount of the second data.

[0281] According to a twenty-ninth aspect provided in addition to the twenty-seventh aspect, a predefined value of the LCID indicates that a MAC Control Element (CE) is not added to the MAC subheader.

[0282] According to a 30th aspect provided in addition to the 27th aspect, the LCID indicates that a Buffer Status Report (BSR) MAC Control Element (CE) is added to the MAC subheader, and the BSR MAC CE indicates an amount of the first data to be further transmitted.

[0283] According to a thirty-first aspect provided in addition to one of the twenty-fourth to thirtieth aspects, the traffic indication includes an indication indicating an amount of the second data.

[0284] According to a 32nd aspect, provided in addition to one of the 24th to 26th aspects, the traffic indication is part of a medium access control (MAC) control element (CE), and (i) one bit of the MAC CE indicates whether second data has been detected, (ii) two bits of the MAC CE indicate a logical channel group (LCG) of the first data among the LCGs that support transmission of data in an inactive state, and (iii) five bits of the MAC CE indicate the amount of the second data.

[0285] According to a 33rd aspect provided in addition to one of the 24th to 31st aspects, the traffic indication is a radio resource control (RRC) level indication and / or a medium access control (MAC) level indication.

[0286] According to a 34th aspect, a method for a user equipment (UE) is provided. The method includes detecting that second data of a second logical channel is transmitted in an inactive state during a procedure for transmitting first data of a first logical channel in an inactive state. The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data. The second logical channel is configured with (i) no CG resource for transmitting in the inactive state and (ii) a random access (RA) resource for transmitting in the inactive state. The method further includes determining whether there is a transmission opportunity to wait for, the transmission opportunity to wait for being (i) a transmission opportunity for transmitting at least a portion of the first data and (ii) expected to occur as part of the procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, an RA procedure is initiated to transmit the second data using the RA resource. When it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the transmission opportunity is used to transmit a traffic indication indicating detection of the second data.

[0287] According to a thirty-fifth aspect, a scheduling device is provided. The scheduling device includes a transceiver and a circuit. In operation, the circuit (i) controls the transceiver to receive a transmission including first data on a first logical channel from a user equipment (UE) in an inactive state, and (ii) obtains a traffic indication from the transmission including the first data, indicating that second data on a second logical channel has been detected by the UE. The second data is data transmitted by the UE in an inactive state, and the procedure for transmitting the first data is a Configured Grant (CG) procedure for transmitting the first data. The second logical channel (i) is not configured with CG resources for transmission in the inactive state, and (ii) is configured with Random Access (RA) resources for transmission in the inactive state. The traffic indication is signaled by a predefined value of a Logical Channel ID (LCID) in a Medium Access Control (MAC) subheader, the predefined value of the LCID indicating that the second data has been detected.

[0288] According to a 36th aspect, a method for a scheduling device is provided, the method including: (i) receiving a transmission including first data of a first logical channel from a user equipment (UE) in an inactive state; and (ii) obtaining a traffic indication from the transmission including the first data, the traffic indication indicating that second data of a second logical channel has been detected by the UE. The second data is data transmitted by the UE in an inactive state, and the procedure for transmitting the first data is a Configured Grant (CG) procedure for transmitting the first data. The second logical channel (i) is not configured with CG resources for transmission in the inactive state, and (ii) is configured with Random Access (RA) resources for transmission in the inactive state. The traffic indication is signaled by a predefined value of a Logical Channel ID (LCID) in a Medium Access Control (MAC) subheader, the predefined value of the LCID indicating that the second data has been detected.

[0289] In summary, a user equipment (UE), a corresponding scheduling device, and respective methods of the UE and the scheduling device are provided.

[0290] In particular, the present disclosure provides a UE including a transceiver and a circuit, the circuit detects that second data is transmitted in a connected state during a procedure for transmitting first data in an inactive state. The circuit determines whether there is a transmission opportunity to wait for. The transmission opportunity to wait for is a transmission opportunity i) for transmitting at least a portion of the first data, ii) expected to occur as part of the procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or that the transmission opportunity to wait for is no longer likely to occur, the circuit initiates a random access channel (RACH) procedure to enter the connected state. When it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuit controls the transceiver to use the transmission opportunity to transmit a traffic indication indicating detection of the second data.

[0291] The present disclosure also provides a UE including a transceiver and a circuit, the circuit detecting that second data of a second logical channel is transmitted in an inactive state during a procedure for transmitting first data of a first logical channel in an inactive state. More specifically, the procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, in which the second logical channel (i) is not configured with a CG resource for transmitting in the inactive state, and (ii) is configured with a random access (RA) resource for transmitting in the inactive state. The circuit determines whether there is a transmission opportunity to wait for. The transmission opportunity to wait for is a transmission opportunity i) for transmitting at least a portion of the first data, and ii) is expected to occur as part of the procedure for transmitting the first data. When it is determined that there is no transmission opportunity to wait for or the transmission opportunity to wait for is no longer expected to occur, the circuit initiates an RA procedure to transmit the second data using the RA resource. On the other hand, if it is determined that there is a transmission opportunity to wait for and the transmission opportunity occurs, the circuitry controls the transceiver to use the transmission opportunity to transmit a traffic indication indicating the detection of the second data.

Claims

1. A user equipment, A transceiver; 1. A circuit comprising: Detecting that second data is to be transmitted in a connected state during a procedure for transmitting first data in an inactive state; determining whether a transmission opportunity exists for transmitting the first data; when it is determined that a transmission opportunity does not exist for transmitting the first data, initiate a Random Access Channel (RACH) procedure to enter a connected state; controlling the transceiver to transmit, when it is determined that the transmission opportunity exists, a traffic indication indicating detection of the second data using the transmission opportunity. The circuit; A user equipment comprising:

2. the procedure for transmitting the first data is initiated in a RACH procedure; The transmission opportunity is - it is the first transmission of the RACH procedure, - indicated by an uplink grant received as part of said RACH procedure, or indicated by an uplink grant received for transmitting the first data after completion of the RACH procedure; The user equipment of claim 1 .

3. the procedure for transmitting the first data is initiated in a RACH procedure; the circuit determines that the transmission opportunity does not exist after controlling the transceiver to transmit the first data, or said transmission opportunity is expected to be indicated by an uplink grant, said uplink grant comprising: As part of the RACH procedure, or for transmitting a portion of said first data after completion of said RACH procedure, is expected to be received, The user equipment of claim 1 .

4. The uplink grant is transmitted by the circuitry controlling the transceiver to after having sent a first transmission of said RACH procedure, after transmitting a Buffer Status Report (BSR) indicating the amount of said first data to be further transmitted, and / or after transmitting the first portion of data after transmitting the BSR, whereby the amount of the first portion of data is smaller than the amount indicated by the BSR; is expected to be received in The user equipment of claim 3.

5. when the expected uplink grant has not been received and is no longer likely to be received, the transmission opportunity is no longer likely to occur; the transceiver receives an indication indicating the end of the procedure for transmitting the first data, and / or if a predetermined time has elapsed since a first or previous transmission of at least a portion of said first data, the expected uplink grant is no longer expected to be received; The user equipment of claim 3.

6. The traffic indication: at least a portion of the first data using resources indicated by an uplink grant; and / or a Buffer Status Report (BSR) indicating an amount of said first data; sent together with The user equipment of claim 1 .

7. The RACH procedure is a four-step RACH procedure or a two-step RACH procedure. The user equipment of claim 1 .

8. the procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data; The circuit, determining that a transmission opportunity exists if the next resource of the CG procedure is earlier than a next RACH resource, and controlling the transceiver to transmit the traffic indication using the transmission opportunity; If the next resource of the CG procedure is later than the next RACH resource, determine that no transmission opportunity exists and initiate the RACH procedure to enter the connected state. The user equipment of claim 1 .

9. the traffic indication is signaled by a predefined value of a Logical Channel ID (LCID) in a MAC subheader; a predefined value of the LCID indicating that the second data was detected; The user equipment of claim 1 .

10. a predefined value of the LCID indicates that no MAC control element (CE) is added to the MAC subheader; 10. The user equipment of claim 9.

11. the LCID indicates that a BSR MAC Control Element (CE) is added to the MAC subheader; the BSR MAC CE indicates an amount of the first data to be further transmitted; 10. The user equipment of claim 9.

12. the traffic indication is part of a MAC Control Element (CE); a bit of said MAC CE indicates whether said second data has been detected or not; - two bits of the MAC CE indicate the first data Logical Channel Group (LCG) among LCGs supporting the transmission of data in the inactive state; - 5 bits of the MAC CE indicate the amount of the first data corresponding to the indicated LCG to be transmitted further; The user equipment of claim 1 .

13. the traffic indication is a radio resource control (RRC) level indication; The user equipment of claim 1 .

14. A method for a user equipment, said method comprising the following steps: detecting, during a procedure for transmitting first data in an inactive state, that second data is to be transmitted in a connected state; determining whether a transmission opportunity exists for transmitting the first data; initiating a Random Access Channel (RACH) procedure to enter a connected state when it is determined that a transmission opportunity does not exist for transmitting the first data; when it is determined that a transmission opportunity exists for transmitting the first data, transmitting a traffic indication using the transmission opportunity indicative of detection of the second data; A method comprising:

15. 1. A scheduling device, comprising: A transceiver; 1. A circuit comprising: controlling the transceiver to receive a transmission from an inactive user equipment, the transmission including first data; obtaining a traffic indication from the transmission including the first data, the traffic indication indicating that second data has been detected by the user equipment; the second data being data transmitted by the user equipment in a connected state; the traffic indication is signaled by the user equipment using the first data transmission opportunity. The circuit; A scheduling device comprising:

16. A method for a scheduling device, said method comprising the following steps: receiving a transmission from a user equipment in an inactive state, the transmission including first data; obtaining a traffic indication from the transmission including the first data, the traffic indication indicating that second data has been detected by the user equipment; the second data being data transmitted by the user equipment in a connected state; the traffic indication is signaled by the user equipment using the first data transmission opportunity. method.

17. An integrated circuit for controlling a process of a user equipment, said process comprising the following steps: detecting, during a procedure for transmitting the first data in an inactive state, that the second data is transmitted in a connected state; determining whether a transmission opportunity exists for transmitting the first data; initiating a Random Access Channel (RACH) procedure to enter a connected state when it is determined that a transmission opportunity does not exist for transmitting the first data; when it is determined that a transmission opportunity exists for transmitting the first data, transmitting a traffic indication using the transmission opportunity indicative of detection of the second data; Including, Integrated circuits.

18. An integrated circuit for controlling a process of a scheduling device, said process comprising the following steps: receiving a transmission from a user equipment in an inactive state, the transmission including first data; obtaining a traffic indication from the transmission including the first data, the traffic indication indicating that second data has been detected by the user equipment; the second data being data transmitted by the user equipment in a connected state; the traffic indication is signaled by the user equipment using the first data transmission opportunity. Integrated circuits.

Images