User equipment, scheduling node, method for user equipment, and method for scheduling node

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] This disclosure relates to the transmission and reception of signals in communication systems. In particular, this 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 technologies, also known as 5G, including "New Radio" (NR) radio access technology (RAT) that operates in a frequency range of up to 100 GHz. NR is the successor technology to technologies such as LTE (Long Term Evolution) and LTE Advanced (LTE-A).

[0003] In systems such as LTE and NR, further improvements and options can facilitate the efficient operation of not only the communication system but also specific 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 [Overview of the Initiative] [Problems that the invention aims to solve]

[0005] One non-limiting and exemplary embodiment facilitates efficient processing when RA-SDT data arrives 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 is characterized by an apparatus (e.g., a user equipment (UE)). The apparatus includes a transceiver and a circuit. The circuit, in a non-active state, detects that second data of a second logical channel is being transmitted in the non-active state during procedures for transmitting first data of a first logical channel. The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data. For the second logical channel, (i) CG resources for transmission in the non-active state are not set, and (ii) random access (RA) resources for transmission in the non-active state are set. Further, the circuit determines whether there is a transmission opportunity to wait for, and the transmission opportunity to wait for is (i) a transmission opportunity for transmitting at least a part of the first data, and (ii) 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 there is no longer an expectation that a transmission opportunity to wait for will occur, the circuit starts an RA procedure to transmit the second data using the RA resources. Further, when it is determined that there is a transmission opportunity to wait for and that transmission opportunity occurs, the circuit controls the transceiver to transmit a traffic indication indicating detection of the second data using that transmission opportunity.

[0008] Note that a general or specific embodiment can be implemented as a system, a method, an integrated circuit, a computer program, a storage medium, or any optional combination thereof.

[0009] Further benefits and advantages of the disclosed embodiments will become apparent from the specification and the drawings. These benefits and / or advantages can be obtained individually by various embodiments and features of the specification and the drawings, and it is not necessary to provide all of these features in order to obtain one or more of such benefits and / or advantages.

Brief Description of the Drawings

[0010] Hereinafter, exemplary embodiments will be described in more detail with reference to the accompanying drawings and figures. [Figure 1] An exemplary architecture of a 3GPP NR system is shown. [Figure 2] It is a schematic diagram showing the separation of functions between NG-RAN and 5GC. [Figure 3] It is a sequence diagram of an RRC connection establishment / reconfiguration procedure. [Figure 4] It is a schematic diagram showing usage scenarios of enhanced mobile broadband (eMBB), massive machine type communications (mMTC), and ultra reliable and low latency communications (URLLC). [Figure 5] It is a block diagram showing an exemplary architecture of a 5G system in a non-roaming case. [Figure 6] It shows contention-based RACH procedures and non-contention RACH procedures. [Figure 7] It shows contention-based RACH procedures and non-contention RACH procedures. [Figure 8] It shows possible RRC state changes. [Figure 9] It shows message exchanges in an RRC resume procedure. [Figure 10] It shows message exchanges in an RRC release procedure. [Figure 11] It shows message exchanges in an RRC release procedure. [Figure 12] It shows prior art message exchanges for uplink data transmission, including the state change of a UE from an inactive state to a connected state. [Figure 13]These examples show exemplary 4-step and 2-step RACH methods that can be used by RRC_INACTIVE UE to send small data uplink. [Figure 14] These examples show exemplary 4-step and 2-step RACH methods that can be used by RRC_INACTIVE UE to send small data uplink. [Figure 15] An exemplary SDT procedure is shown, which includes a single transmission of small data during the RACH procedure. [Figure 16] An exemplary SDT procedure is shown, which includes sending small data multiple times during the RACH procedure. [Figure 17] This document illustrates an exemplary SDT procedure, including the transmission of small data during and after the RACH procedure. [Figure 18] This block diagram shows an exemplary functional structure of network nodes and user equipment. [Figure 19] Figure 18 is a block diagram showing an exemplary functional structure of a circuit that processes incoming non-SDT DRB data, which can be included in the exemplary user device. [Figure 20] This block diagram shows an exemplary functional structure of a traffic instruction processing circuit that can be included in the exemplary scheduling device shown in Figure 18. [Figure 21] This flowchart illustrates exemplary steps performed by the user's device. [Figure 22] This flowchart illustrates exemplary steps performed by network nodes. [Figure 23] This shows the different timings at which non-SDT data arrives during the SDT procedure. [Figure 24] This flowchart illustrates exemplary steps performed by the user's device. [Figure 25] This shows an exemplary structure of a Msg3 message, including a MAC subframe that has a subheader indicating the arrival of a non-SDT DRB and does not have a CE. [Figure 26] This shows an exemplary structure of a Msg3 message, including a MAC subframe that contains a subheader indicating the arrival of a non-SDT DRB and a CE indicating the buffer size of the SDT DRB data. [Figure 27] The top panel shows an exemplary MAC CE structure indicating the buffer size of a logical channel group, and the bottom panel shows an exemplary MAC CE structure indicating the buffer size of a logical channel group and the arrival of non-SDT DRB data. [Figure 28] This block diagram shows an exemplary functional structure of network nodes and user equipment. [Figure 29] Figure 28 is a block diagram showing an exemplary functional structure of a circuit that processes incoming non-SDT DRB data, which can be included in the example user device. [Figure 30] This block diagram shows an exemplary functional structure of a traffic instruction processing circuit that can be included in the exemplary scheduling device shown in Figure 28. [Figure 31] This flowchart illustrates exemplary steps performed by the user's device. [Figure 32] This flowchart illustrates exemplary steps performed by network nodes. [Figure 33] This shows an exemplary logical channel configuration for the UE. [Figure 34] This is a schematic diagram showing the arrival of RA-SDT traffic. [Figure 35] This is a schematic diagram illustrating an example of the processing of incoming RA-SDT traffic. [Modes for carrying out the invention]

[0011] <5G NR System Architecture and Protocol Stack> 3GPP is working on the next release of fifth-generation cellular technology (simply called 5G), which will include the development of a new radio access technology (NR) that will operate at frequencies up to 100 GHz. The first version of the 5G standard will be completed at the end of 2017, which will allow for testing and commercial deployment of smartphones compliant with the 5G NR standard.

[0012] In particular, the overall system architecture envisions an NG-RAN (Next Generation Radio Access Network) with gNBs, which terminate the NG Radio Access User Plane (SDAP / PDCP / RLC / MAC / PHY) and Control Plane (RRC) protocols toward the UE. The gNBs are interconnected with each other via Xn interfaces. Furthermore, the gNBs are connected to the NGC (Next Generation Core) via Next Generation (NG) interfaces, more specifically to the AMF (Access and Mobility Management Function) (e.g., a specific core entity that performs the AMF) via the NG-C interface, and to the UPF (User Plane Function) (e.g., a specific core entity that performs the UPF) via the NG-U interface. Figure 1 shows the architecture of the 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 Non-Patent Literature 1) includes the PDCP (Paper Data Convergence Protocol, see section 6.4 of Non-Patent Literature 1) sublayer, the RLC (Radio Link Control, see section 6.3 of Non-Patent Literature 1) sublayer, and the MAC (Medium Access Control, see section 6.2 of Non-Patent Literature 1) sublayer, which are terminated at the gNB on the network side. In addition, a new access layer (AS) sublayer (SDAP: Service Data Adaptation Protocol) is introduced on top of PDCP (see, for example, section 6.5 of Non-Patent Literature 1). A control plane protocol stack is also defined in NR (see, for example, section 4.4.2 of Non-Patent Literature 1). An overview of the Layer 2 functions is described in section 6 of Non-Patent Literature 1. The functions of the PDCP sublayer, RLC sublayer, and MAC sublayer are described in sections 6.4, 6.3, and 6.2 of Non-Patent Document 1, respectively. The function of the RRC layer is described in section 7 of Non-Patent Document 1.

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

[0015] The physical layer (PHY) is responsible for tasks such as encoding, PHY HARQ processing, modulation, multi-antenna processing, and mapping signals to appropriate physical time-frequency resources. Furthermore, the physical layer (PHY) handles the mapping of transport channels to physical channels. The physical layer (PHY) serves the MAC layer in the form of transport channels. A physical channel corresponds to a set of time-frequency resources used for transmitting a particular transport channel, and each transport channel is mapped to a corresponding physical channel. For example, physical channels for uplinks include PRACH (Physical Random Access Channel), PUSCH (Physical Uplink Shared Channel), and PUCCH (Physical Uplink Control Channel), while for downlinks, there are PDSCH (Physical Downlink Shared Channel), PDCCH (Physical Downlink Control Channel), and PBCH (Physical Broadcast Channel).

[0016] NR use cases / deployment scenarios include Enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and Massive Machine-Type Communications (mMTC), and these services have diverse requirements regarding data rate, latency, and coverage. For example, eMBB is expected to support peak data rates of the order of three times that provided by IMT-Advanced (20 Gbps downlink and 10 Gbps uplink) and user-perceived data rates. URLLC, on the other hand, has even more stringent requirements, including extremely low latency (user plane latency of 0.5 ms for both uplink and downlink) and high reliability (1-10 ms within 1 ms). -5) is imposed. Furthermore, in mMTC, a high connection density (1km in urban environments) is required. 2 Preferably, a capacity of 1,000,000 devices per unit, wide coverage in harsh environments, and extremely long-life batteries (15 years) to reduce device costs may be required.

[0017] Therefore, OFDM numerology suitable for one use case (e.g., subcarrier interval, OFDM symbol duration, cyclic prefix (CP) duration, number of symbols per scheduling interval) may not work well for another use case. For example, low-latency services may prefer shorter symbol durations (and thus larger subcarrier intervals) and / or fewer symbols per scheduling interval (also known as TTI) than mMTC services. Furthermore, in placement scenarios with large channel delay spreads, longer cyclic prefix (CP) durations may be preferred than in scenarios with smaller delay spreads. To maintain a similar level of cyclic prefix (CP) overhead, the subcarrier interval should be optimized according to the delay spread. NR may support two or more values ​​for the subcarrier interval. Therefore, currently, subcarrier intervals of 15kHz, 30kHz, 60kHz, ... are being considered. Symbol duration T u The subcarrier spacing Δf is given by the equation Δf = 1 / T u Therefore, it is directly related. As with LTE systems, the term “resource element” can be used to represent 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 each of the uplink and downlink. Each element within the resource grid is called a resource element and is identified based on a frequency index in the frequency domain and a symbol position in the time domain (see Non-Patent Document 2). For example, downlink and uplink transmissions are organized into frames with a duration of 10 ms, and each frame is composed of 10 subframes each with a duration of 1 ms. 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, each slot containing 14 OFDM symbols.

[0019] 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] <Functional Split of 5G NR between NG-RAN and 5GC> Figure 2 shows the functional split 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, and dynamic resource allocation (scheduling) to UEs in both uplink and downlink directions. - IP header compression, encryption, and data integrity protection - Selection of AMF when UE attaches if routing to AMF cannot be determined from the information provided by the UE. - Routing user plane data to UPF - Routing of control plane information to AMF - Establishing and releasing connections - Scheduling and sending paging messages - Scheduling and transmission of system broadcast information (sent from AMF or OAM) - Setting up measurements and measurement reporting for mobility and scheduling. - Transport-level packet marking in uplink - Session management - Support for network slicing - QoS flow management and mapping to data radio bearers - Support for UEs in the RRC_INACTIVE state - NAS message delivery function - Wireless access network sharing - Double connection - Close interworking between NR and E-UTRA

[0022] The Access and Mobility Management Function (AMF) handles the following key functions: - Termination of Non-Access Stratum (NAS) signaling - NAS signaling security - Security control at the Access Layer (AS) - Core Network (CN) node-to-node signaling for mobility between 3GPP access networks - Reachability of idle mode UE (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 check - Mobility management and control (subscriptions and policies) - Support for network slicing - Selection of Session Management Function (SMF)

[0023] Furthermore, the User Plane Function (UPF) handles the following key functions: - Anchor points for mobility within / between RATs (when applicable) - External PDU session points for interconnection with the data network - Packet routing and forwarding - User plane portion of packet inspection and policy rule enforcement - Traffic usage report - Uplink classifier to support routing of traffic flow to data networks - Branching points to support multi-homed PDU sessions - User plane QoS processing (e.g., packet filtering, gating, UL / DL rate enforcement) - Uplink traffic verification (mapping from SDF to QoS flow) - 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 configuring UEs and gNBs. Specifically, in this transition, the AMF creates context data for the UE (e.g., including PDU session context, security key, UE radio capability, UE security capability, etc.) and sends it to the gNB via an Initial Context Setup Request. The gNB then activates AS security with the UE, which is done by the gNB sending a SecurityModeCommand message to the UE, and the UE responding to the gNB with a SecurityModeComplete message. The gNB then performs a reconfiguration to establish the Signaling Radio Bearer 2 (SRB2) and Data Radio Bearer (DRB), which is done 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, SRB2 and DRB are not established, so these steps related to RRCReconfiguration are skipped. Finally, the gNB notifies the AMF that the establishment procedure is complete by sending an Initial Context Setup Response.

[0027] Accordingly, this disclosure provides a fifth-generation core (5GC) entity (e.g., AMF, SMF, etc.) comprising, during operation, a control circuit for establishing a next-generation (NG) connection with a gNodeB, and, during operation, a transmitter for sending an initial context setting message to the gNodeB via the NG connection to establish a signaling radio bearer between the gNodeB and the user equipment (UE). Specifically, the gNodeB sends RRC (Radio Resource Control) signaling, which includes resource allocation setting information elements, to the UE via the signaling radio bearer. The UE performs uplink transmission or downlink reception based on the resource allocation setting.

[0028] <IMT Usage Scenarios from 2020 Onward> Figure 4 illustrates some use cases for 5G NR. The 3GPP (Third Generation Partnership Project) New Radio (3GPP NR) considers three anticipated use cases to support various services and applications using IMT-2020. Phase 1 specifications for Enhanced Mobile Broadband (eMBB) have been finalized. Current and future work includes further expanding eMBB support, as well as standardization of Ultra-Reliable Low-Latency Communications (URLLC) and Massive Machine-Type Communications. Figure 4 shows some examples of anticipated use scenarios for IMT beyond 2020 (see, for example, Figure 2 in Non-Patent Document 4).

[0029] URLLC use cases have stringent requirements regarding capabilities such as throughput, latency, and availability, and are envisioned as one means of realizing 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. The ultra-high reliability of URLLC is supported by identifying the technology to meet the requirements set out in Non-Patent Document 5. In NR URLLC of Release 15, the main requirements include a target user plane latency of 0.5 ms for UL (uplink) and 0.5 ms for DL ​​(downlink). Typical URLLC requirements for a single packet transmission are 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, several ways to improve reliability are possible. Current approaches to reliability improvements include defining separate CQI tables for URLLC, a more compact DCI format, and PDCCH iteration. However, as NR becomes more stable and development progresses (regarding key requirements for NR URLLC), the scope for achieving ultra-high reliability may expand. Specific use cases for NR URLLC in Release 15 include augmented reality / virtual reality (AR / VR), e-health, e-safety, and mission-critical applications.

[0031] Furthermore, the technical enhancements targeted by NR URLLC aim to improve latency and reliability. Technical enhancements for improving latency include configurable numerology, non-slot-based scheduling using flexible mapping, grant-free (configured grant) uplinks, slot-level iteration on data channels, and downlink preemption. Preemption means that a transmission for which resources have already been allocated is aborted, and those resources are used for another transmission requested later with lower latency / higher priority requirements. Thus, a transmission that has already been permitted 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 (e.g., eMBB). Technical enhancements related to improved reliability include a dedicated CQI / MCS table for the 1E-5 target BLER.

[0032] The use case for mMTC (Massive Machine Type Communication) is characterized by a very large number of connected devices transmitting relatively small amounts of data, which are generally less affected by latency. These devices are required to be low-cost and have extremely long battery life. From a noise reduction (NR) perspective, utilizing a very narrow bandwidth is one possible solution to achieve power savings from a UE perspective and enable long battery life.

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

[0034] In the case of NR URLLC, further use cases with more stringent requirements have been identified, such as factory automation, transportation, and power distribution. These stringent requirements, depending on the use case, include higher reliability (up to 10%). -6 The features include higher availability, a maximum packet size of 256 bytes, time synchronization down to the order of a few microseconds (values ​​ranging from 1 microsecond to several microseconds depending on the frequency range), and low latency on the order of 0.5 to 1 ms, particularly a target user plane latency of 0.5 ms.

[0035] Furthermore, in the case of NR URLLC, several technical enhancements have been identified from a physical layer perspective. In particular, enhancements related to the PDCCH (Physical Downlink Control Channel) include a more compact DCI, PDCCH repetition, and increased PDCCH monitoring. Enhancements related to the UCI (Uplink Control Information) include improved HARQ (Hybrid Auto Retransmission Request) and enhanced CSI feedback. Enhancements to PUSCH related to mini-slot level hopping and retransmission / repetition have also been recognized. The term "mini-slot" refers to a TTI (Transmission Time Interval) containing 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 transmitted 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, while referring 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 standard architecture for 5G NR (see Section 4.23 of Non-Patent Literature 6). Application Functions (AFs) (e.g., external application servers handling 5G services as illustrated in Figure 4) interact with the 3GPP core network for the purpose of providing services. For example, they support the application's influence on traffic routing, access Network Exposure Functions (NEFs), and interact with policy frameworks for policy control (e.g., QoS control) (see Policy Control Functions (PCFs)). Based on the operator's deployment, application functions (AFs) that are considered trusted by the operator may be allowed to interact directly with the relevant Network Functions. Application functions (AFs) that are not permitted by the operator to directly access Network Functions interact with the relevant Network Functions using external exposure frameworks via NEFs.

[0039] Figure 5 shows further functional units of the 5G architecture, namely the 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 services, internet access, or third-party services). All or some of the core network functions and application services may be deployed and run in a cloud computing environment.

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

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

[0042] The uplink control signals (information) related to this disclosure may be signals (information) transmitted via the physical layer PUCCH, or signals (information) transmitted via the upper layer MAC CE or RRC. Furthermore, the uplink control signals may be predefined signals (information). The uplink control signals may be replaced with uplink control information (UCI), first-stage sidelink control information (SCI), or second-stage SCI.

[0043] <Terminal> In LTE and NR, a terminal, user terminal, user device, mobile station, or mobile node is called user equipment (UE). User equipment (UE) may be a mobile device or communication device, such as a radiotelephone, smartphone, tablet computer, or USB (Universal Serial Bus) stick with user equipment functionality. However, the term mobile device is not limited to this, and generally, a repeater may also have the functionality of such a mobile device, and a mobile device may function 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 of communication device, such as an IoT device. A single 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 the same node, another node, or other functional entities in the network. A node may have one or more interfaces to attach itself to communication equipment or communication media, and a node can communicate through these communication equipment or communication media. Similarly, a network entity may have a logical interface for attaching functional entities to communication equipment or communication media, and functional entities may communicate with other functional entities or corresponding nodes through these communication equipment or communication media.

[0044] <Base station> In this disclosure, a base station can 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 side-link communication, a terminal can be used instead of a base station. A base station may also be a relay device that relays communication between a higher-level node and a terminal. A base station may also be a roadside unit. A base station may also be, for example, a scheduling node or network node that forms part of a network for providing services to a terminal. In particular, a base station can provide radio access to a terminal. Communication between a terminal and a base station is generally standardized and can be defined by different layers such as PHY, MAC, and RRC. In LTE and NR, the radio interface protocol stack includes the physical layer, the medium access layer (MAC), and the upper layers. 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 a terminal, and the terminal can communicate with the base station to perform control tasks such as establishing and changing connections and bearers, measurements, and other functions. The term used in LTE is eNB (or eNodeB), and the term 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. Like mobile stations, 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 the same node or another node or other functional entities in the network. Physical entities perform several control tasks related to communication devices, including one or more of scheduling and configuration.It should be noted that the functions of a base station and a communication device may be integrated into a single device. For example, a mobile terminal can also perform base station functions for other terminals. The technical term used in LTE is eNB (or eNodeB), while the technical term currently used in 5G NR is gNB.

[0045] <Uplink / Downlink / Sidelink> This disclosure can be applied to uplinks, downlinks, and sidelinks.

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

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

[0048] <Data Channel / Control Channel> This disclosure can be applied to either data channels or control channels. The channels in this 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 the base station and the mobile station, and each reference signal may be called a reference signal (RS) or, if applicable, a pilot signal. A reference signal may be any of the following: DMRS, Channel State Information - Reference Signal (CSI-RS), Tracking Reference Signal (TRS), Phase Tracking Reference Signal (PTRS), Cell-specific Reference Signal (CRS), and Sounding Reference Signal (SRS).

[0050] <Time interval> In this disclosure, the unit of time resource is not limited to slots and symbols, or a combination thereof, but may be a time resource unit such as a frame, superframe, subframe, slot, time slot subslot, or minislot, or a time resource unit such as a symbol, orthogonal frequency division multiplexing (OFDM) symbol, single carrier-frequency division multiplexing access (SC-FDMA) symbol, or any other time resource unit. The number of symbols contained in one slot is not limited to the number exemplified in the embodiments described above, but may be a different number of symbols.

[0051] <Frequency Band> This disclosure can be applied to both licensed and unlicensed bands.

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

[0053] Furthermore, this disclosure can be applied to either terrestrial networks or non-terrestrial networks (NTNs) that use satellites or high-altitude pseudo-satellites (HAPS). In addition, this disclosure may be applied to networks with large cell sizes or terrestrial networks where the delay is large relative 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. That is, an antenna port does not necessarily refer to a single physical antenna, but can also refer to an array antenna or other structure formed from multiple antennas. For example, the number of physical antennas forming an antenna port is not defined; instead, the smallest unit from which a terminal can transmit a reference signal is defined as an antenna port. Furthermore, an antenna port may also be defined as the smallest unit for multiplication of pre-coding vector weights.

[0055] <Monitoring of Downlink Control Channels, PDCCH, DCI> Many of the functions operated by the UE include, for example, monitoring a downlink control channel (e.g., PDCCH; see section 5.2.3 of Non-Patent Document 1) to receive specific control information or data destined for the UE.

[0056] The following is a list of such features (not exhaustive): - Paging message monitoring function, - System information acquisition function, - Signaling monitoring operation in discontinuous reception (DRX) function, - Inactivity monitoring operation in the Discontinuous Reception (DRX) function. - Receiving random access responses in random access functionality, - Packet Data Convergence Protocol (PDCP) layer reordering function

[0057] As mentioned above, PDCCH monitoring is performed by the UE to identify and receive information targeting 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] Downlink control information (which can be called downlink control information, or DCI) serves the same purpose in 5G NR as it does in LTE, namely, a special set of control information for scheduling downlink data channels (e.g., PDSCH) or uplink data channels (e.g., PUSCH). In 5G NR, many different DCI formats have already been defined (see Section 7.3.1 of Non-Patent Document 7).

[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 duration 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 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 the 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] In addition to the RNTIs shown above, further IDs such as Inactive-RNTI (I-RNTI) may exist (see, for example, section 6.3.2 of Non-Patent Literature 9). Inactive-RNTI is used for UEs in the RRC_INACTIVE state and is used, for example, in the process of identifying and locating the suspended UE context of that UE. In one implementation, the network assigns an I-RNTI (for example, as part of the RRCRelease message in SuspendConfig) when the UE transitions to the RRC_INACTIVE state (for example, from RRC_CONNECTED). There are two types of I-RNTI: full I-RNTI and short I-RNTI. The network can notify the UE which I-RNTI to use when resuming the connection (for example, as part of SIB1 (System Information Block 1)). A full I-RNTI is a 40-bit bit string, and a short I-RNTI is a 24-bit bit string.

[0064] <Random Access Procedure> Similar to LTE, 5G NR provides the RACH (Random Access Channel) procedure (or simply the 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, as follows: • When establishing synchronization to a new cell during a handover. • Re-establish uplink synchronization to the current cell if synchronization is lost due to a prolonged period without uplink transmission from the device. • If a dedicated scheduling request resource is not configured on the device, request uplink scheduling.

[0065] There are numerous events that can trigger a UE to execute a random access procedure (see Section 9.2.6 of Non-Patent Document 1), including the following. Random access procedures are triggered by many events. - First access from RRC_IDLE - RRC connection re-establishment procedure - When the UL synchronization state is "asynchronous", DL data or UL data arrives when RRC_CONNECTED is activated. - UL data arrives at RRC_CONNECTED when PUCCH resources for SR are unavailable. - SR failure - Required by RRC during synchronization reset (e.g., handover) - Transition from RRC_INACTIVE - Establish time alignment for secondary TAGs. - Other SI requirements (see Section 7.3) - Beam malfunction recovery - UL LBT repeatedly fails in SpCell

[0066] If a mobile terminal's uplink transmission is time-synchronized, the mobile terminal can be scheduled for uplink transmission. Therefore, the Random Access Channel (RACH) procedure serves as an interface between a non-synchronized mobile terminal (UE) 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 achieved or has lost uplink synchronization. Once user equipment achieves uplink synchronization, the base station can schedule uplink transmission resources for that user equipment. One scenario related to random access is when user equipment in the RRC_CONNECTED state hands over from the current serving cell to a new target cell and performs the 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 enable access on a competition basis (i.e., inherently involving a risk of conflict) and those that enable access without competition (on a non-competition basis). An exemplary definition of a random access procedure is given in Section 5.1 of Non-Patent Document 10.

[0068] Next, the RACH procedure will be described in more detail with reference to Figures 6 and 7. Below, the conflict-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 called, for example, a four-step RACH procedure. First, the user device sends a random access preamble to the base station over a physical random access channel (PRACH) (i.e., message 1 of the RACH procedure). After the base station detects the RACH preamble, it sends a Random Access Response (RAR) message (message 2 of the RACH procedure) over a PDSCH (Physical Downlink Shared Channel) which is addressed over a PDCCH using (random access) RA-RNTI that identifies the time frequency and slot in which the preamble was detected. If multiple user devices send the same RACH preamble over the same PRACH resource (this is also called a collision), those user devices receive the same random access response message. A RAR message can convey the detected RACH preamble, a timing alignment command (TA command) for synchronizing 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 T-CRNTI (Temporary Cell Radio Network Temporary Identifier). This T-CRNTI is used by the base station to address the mobile object in which the RACH preamble was detected until the RACH procedure is completed, because at this point the base station does not know the mobile object's "true" identification information.

[0069] User equipment monitors the PDCCH to receive Random Access Response messages within a predetermined time window (e.g., called the RAR reception window) that may be set by the base station. In response to the RAR message received from the base station, user equipment sends an initial scheduled uplink transmission over the radio resources allocated by the grant in the Random Access Response. This scheduled uplink transmission carries an actual message with a specific function, such as an RRC connection request, an RRC reactivation request, or a buffer status report.

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

[0071] Figure 7 illustrates a no-conflict random access procedure, which is simplified compared to a conflict-based random access procedure. In the first step, the base station provides the user equipment with a dedicated preamble for random access to avoid the risk of collisions (i.e., multiple user devices transmitting the same preamble). The user equipment then transmits the preamble signaled by the base station over the uplink on the PRACH resource. In no-conflict random access, the case where multiple UEs transmit the same preamble is avoided, so the no-conflict random access procedure essentially terminates after the random access response has been successfully received by the UE.

[0072] 3GPP also defines a two-step (conflict-based) RACH procedure for 5G NR, in which message 1 (called MsgA), corresponding to messages 1 and 3 in the four-step LTE / NR RACH procedure, is sent first. This two-step RACH type MsgA includes a preamble on the physical random access channel (PRACH) and a payload on the physical uplink shared channel (PUSCH). After sending MsgA, the UE monitors for a response from the gNB within a configured time window. The gNB then responds with message 2 (called MsgB), corresponding to messages 2 and 4 in the four-step LTE / NR RACH procedure. This MsgB can include, for example, a successful random access response (RAR), a fallback RAR, and optionally a backoff instruction. If the UE receives a successful RAR and successfully resolves the conflict, it terminates the random access procedure. On the other hand, if the UE receives a fallback RAR in MsgB, it sends message 3 (similar to the four-step RACH procedure) and monitors for conflict resolution. The two-step RACH procedure involves several more exemplary assumptions, such as the UE determining the RACH type (e.g., two-step RACH) and then continuing to retry the same RACH type until it fails. However, it may also be possible for the UE to switch to the four-step RACH procedure after retrying sending the MsgA a certain number of times.

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

[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 savings, UE autonomous mobility, and no established connection between the UE and 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, following the "Release Connection via Suspend" procedure, change from RRC_CONNECTED to RRC_INACTIVE For example, follow the "Resume Connection" procedure to change from RRC_INACTIVE to RRC_CONNECTED For example, following the "connection release" procedure, change from RRC_INACTIVE to RRC_IDLE (unidirectional)

[0077] The new RRC state, RRC Inactive, is defined for new 5G 3GPP radio technologies to benefit from supporting a wide range of services with extremely different requirements regarding signaling, power saving, and latency, such as eMBB (Enhanced Mobile Broadband), mMTC (Massive Machine Type Communications), and URLLC (Ultra-Reliable Low-Latency Communications). Therefore, the new RRC Inactive state is designed to minimize signaling, power consumption, and resource costs in radio access and core networks, while enabling, for example, low-latency data transfer.

[0078] According to an exemplary implementation of 5G NR, these different states can be characterized as follows (see Section 4.2.1 of Non-Patent Document 12): "RRC_IDLE" - UE-specific DRX can be configured by the upper layer. - Mobility controlled by the UE based on network settings - UE is - Monitor short messages sent via DCI using P-RNTI (see Section 6.5). - Monitoring paging channels in CN paging using 5G-S-TMSI - Perform measurement of adjacent cells and (re)selection of cells. - System information can be retrieved and SI requests can be sent (if configured). - Log available measurements along with the location and time of the measured UE recorded in the log. - RRC_INACTIVE - UE-specific DRX can be configured by the upper layer or the RRC layer. - Mobility controlled by the UE based on network settings - UE stores the UEInactive AS context. - RAN-based notification area is configured by the RRC layer. UE is - Monitor short messages sent via DCI using P-RNTI (see Section 6.5). - Monitoring paging channels in CN paging using 5G-S-TMSI and RAN paging using full I-RNTI. - Perform measurement of adjacent cells and (re)selection of cells. - Perform RAN-based notification area updates periodically and when moving outside the configured RAN-based notification area. - System information can be retrieved and SI requests can be sent (if configured). - Log available measurements along with the location and time of the measured UE recorded in the log. - RRC_CONNECTED: - UE stores AS context - Transfer of unicast data to and from the UE - In the lower layers, you can set a UE-specific DRX for the UE. - For UEs that support CA, use SpCell and one or more aggregated SCELLs to widen the bandwidth. - For UEs that support DC, use one aggregated SCG with an MCG to increase bandwidth. - Network-controlled mobility within the NR and between E-UTRA - UE is - If configured, monitor short messages sent via DCI using P-RNTI (see Section 6.5). - Monitor the control channel associated with the shared data channel and determine whether data is scheduled to the shared data channel. - Provide channel quality and feedback information. - Perform measurements and report measurements on adjacent cells. - Obtain system information - Report available locations and perform MDT measurements immediately.

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

[0080] Furthermore, the paging mechanism (also known as a notification mechanism, for example) for user devices within a wireless cell is based on a so-called Radio Access Network (RAN)-based notification area (RNA). The RAN should be aware of the current RNA where the user device is located, and the user device can assist the gNB in ​​tracking the UE as it moves between different RNAs. RNAs can be UE-specific.

[0081] The following describes an example of an RRC restart procedure for a UE to transition from the RRC_Inactive state to the RRC_Connected state (see Section 5.3.13 of Non-Patent Document 12), with reference to Figure 9. The purpose of this procedure is to restart suspended RRC connections (which may include restarting signaling radio bearers and data radio bearers).

[0082] This procedure allows sending either an RRCResumeRequest message or an RRCResumeRequest1 message. When sending an RRCResumeRequest message, a short I-RNTI (e.g., truncated I-RNTI) is used as the UE's identity (exemplified by "resumeIdentity"). When sending an RRCResumeRequest1 message, a full I-RNTI is used as the UE's identity (exemplified by "resumeIdentity"). The UE checks the instruction "useFullResumeID" in SIB1 and decides whether to send an RRCResumeRequest message or an RRCResumeRequest1 message. If "useFullResumeID" indicates "true", the UE sends an RRCResumeRequest1 using the full I-RNTI; otherwise, the UE sends an RRCResumeRequest using the short I-RNTI. The actions that the UE performs in the RRC restart procedure (see section 5.3.13.4 of Non-Patent Document 12) include restarting SRB2 and all DRBs (which were suspended when they transitioned to the RRC Inactive state (see the release procedure below)).

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

[0084] The following describes an example of the subsequent RRC connection release procedure for transitioning a UE from the RRC_Connected state to the RRC Inactive state (see Section 5.3.8 of Non-Patent Literature 12), with reference to Figure 11. The purpose of this procedure is to release or suspend the RRC connection. For example, a network initiates the RRC connection release procedure to transition a UE in RRC_CONNECTED to RRC_IDLE or RRC_INACTIVE. Actions performed by the UE in the RRC connection release procedure (see Section 5.3.8.3 of Non-Patent Literature 12) include suspending all SRBs (Signaling Radio Bearers) and DRBs (Data Radio Bearers) except SRB0 if the release is performed by suspension (e.g., RRCRelease includes suspendConfig). Therefore, a UE in the RRC Inactive state has neither suspended nor active DRBs (the UE only has suspended DRBs). SRB0 remains active even in the RRC Inactive state and can be used by the UE to execute RACH procedures when conveying RRC messages such as RRCResumeRequest, RRCResumeRequest1, and RRCSetupRequest.

[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 impossible, or a non-common 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 explain completely, a UE in the idle state does not have a data connection through which the UE can transmit 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 (regular 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 resumption) 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. - Smart phone applications: Traffic from instant messaging services (WhatsApp, QQ, WeChat, etc.) Heartbeat / keep-alive traffic from IM / email clients and other apps Push notifications from various applications - Applications other than smartphones: ○ Traffic from wearable devices (such as periodic location information) 〇 Sensors (such as industrial wireless sensor networks that transmit temperature and pressure measurements periodically or event-triggered). 〇 Smart meters and smart meter networks that transmit periodic meter readings

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

[0089] In detail, the UE can send a preamble to the current gNB, then receive a corresponding random access response containing a (small) UL grant for radio resources, and the UE uses these radio resources to send an RRCResumeRequest message as msg3 of the RACH procedure. Finally, the new gNB provides the UE with an 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 send UL data.

[0090] The gNB can decide whether the UE should actually transition to the RRC_CONNECTED state after sending this UL small data. The UE can request the resumption of the RRC connection, but control over this is 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. 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 can decide to transition the UE from the RRC_INACTIVE state to the RRC_CONNECTED state (for example, by the gNB sending an 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 can decide to keep the UE in the RRC_INACTIVE state (for example, by the gNB sending an RRCRelease message). Furthermore, by omitting buffer status reports from Msg3 / MsgA, it's possible to indicate to the gNB, for example, that there is no further data in the UE's buffer, allowing the UE to remain in RRC_INACTIVE.

[0091] As can be understood from the explanation in Figure 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 on the uplink, introduces latency and consumes a considerable amount of power on the UE each time user data is transmitted. Furthermore, the signaling overhead incurred by the INACTIVE UE when transmitting small data packets is a common problem and worsens as the number of UEs increases in 5G NR.

[0092] Therefore, 3GPP intends to allow RRC_Inactive UEs to transmit (small) data on the uplink without changing the UE state to RRC Connected. Generally, devices that have intermittent (small) data packets while in the INACTIVE state will benefit from the ability to transmit (small) data while in the INACTIVE state.

[0093] With respect to Figures 13 and 14, and the following assumptions made to illustrate the concepts, solutions, and variations of the present invention, should be considered illustrative only and not limiting to RACH-based small data uplink transmissions.

[0094] Furthermore, considering RACH-based small data uplink transmission as an example, the UE can transmit small data on the uplink using either a 2-step or 4-step RACH (see MsgA or Msg3), and Figures 13 and 14 illustrate a simplified, exemplary RACH-based small data uplink transmission procedure. In both Figures 13 and 14, it is illustratively assumed that the UE is already in the RRC_INACTIVE state and has small data that can be transmitted. Figure 13 assumes a 4-step RACH procedure and shows how the UE transmits small data using Msg3. Figure 14 assumes a 2-step RACH procedure and shows how the UE transmits small data using MsgA.

[0095] For example, control messages and small data are sent together to the base station, for example, within the same transport block. In this case, the UE constructs the transport block using resources and multiplexes the data and signaling together within the same transport block at the MAC layer. In the case of a 4-step RACH, small data is sent in Msg3, for example, based on radio resources granted through the uplink grant received from the gNB in ​​Msg2. In the case of a 2-step RACH, small data is sent in MsgA, for example, using radio resources selected by the UE from several radio resources previously configured, for example, in relation to a selected RACH preamble.

[0096] Furthermore, Figures 13 and 14 show that buffer status reports can be included in Msg3 and MsgA, respectively, although BSRs are only shown in parentheses to reflect that including a BSR is merely an illustrative possibility. For example, Figure 13 exemplifies the assumption that gNB decides to keep the UE in the RRC_Inactive state because, for example, no BSR exists, or the BSR indicates only a small amount of uplink small data in the UE's buffer. Correspondingly, an RRCRelease message is sent in Msg4. On the other hand, Figure 14 exemplifies the assumption that gNB decides to transition the UE to the RRC_Connected state because, for example, the BSR indicates a significant amount of uplink data in the UE buffer that must be sent by the UE. Correspondingly, an RRCResume message is sent to MsgA.

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

[0098] In summary, exemplary implementations of small data uplink transmission for RRC_INACTIVE UE are possible, and can be based, for example, on the RACH procedure, i.e., a 2-step RACH procedure or a 4-step RACH procedure (see Figures 13 and 14).

[0099] The above described a single small data uplink transmission (for example, using RACH's Msg3 / MsgA). Furthermore, 3GPP agreed that a UE in the RRC_INACTIVE state should be able to send (and receive) multiple UL (and possibly DL) transmissions using the same procedure without transitioning to the RRC_CONNECTED state.

[0100] Figure 15 shows a more detailed exemplary implementation of a single SDT transmission procedure than the simplified illustrative diagram in Figure 13. For the sake of illustration and subsequent explanation, it is assumed, illustratively, that the multi-SDT transmission procedure is based on a 4-step RACH.

[0101] Furthermore, we can exemplify the case where, while in the RRC_INACTIVE state, the UE transitions from the previous gNB (anchor gNB) to the current gNB (and therefore the current serving gNB). For this reason, the serving gNB may need to obtain the UE context from the anchor gNB as part of the RACH procedure, for example, so that the serving gNB can authenticate a UE (which is unknown to the serving gNB).

[0102] In this context, we can exemplify the case where a Contention Resolution Identity MAC Control Element (CR MAC CE) is sent separately from the response to the UE's RRCResumeRequest message (the RRCRelease message in the example in Figure 15). The primary purpose of this Msg4 and the corresponding CR MAC CE is to resolve any conflicts that may occur in a conflict-based RACH, and therefore does not need to wait for the serving gNB to acquire the UE context. Thus, the serving gNB can send the CR MAC CE as soon as possible (e.g., when the result of conflict resolution is determined in the serving gNB), while the sending of the response message to the RRCResumeRequest message from the UE can be performed by the serving gNB after it has received and processed the UE context. Alternatively, in another scenario, the Contention Resolution Identity MAC Control Element can be sent together with the RRC response message (e.g., RRCRelease or RRCResume).

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

[0104] 1. A UE with small data to send initiates RACH to perform the transmission of the small data. Therefore, the UE sends a preamble to the serving gNB.

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

[0106] 3. Next, the UE sends an RRC Resumption Request message along with the UL Small data, based on the UL Grant received earlier. Furthermore, the UE starts a timer (called T319) that is effectively responsible for controlling the RRC Resumption Request procedure at that point. Further details about timer T319 are described below.

[0107] More specifically, according to an exemplary 5G-compliant implementation, the T319 timer regulates the maximum duration of an RRC restart request procedure. Timer T319 is started when an RRCResumeRequest message is sent and stopped when a corresponding response (such as an RRCRelease or RRCResume message) is received. If T319 expires before it is stopped, the UE determines that its RRC restart request procedure has failed and transitions to the RRC_IDLE state.

[0108] Exemplary, the value applied to T319 is determined by taking into account the time required for a gNB to obtain the UE context from another anchor gNB. The longer T319, 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 within its own cell by a gNB using, for example, system information (SIB), and therefore the T319 timer is cell-specific, not UE-specific.

[0109] 4. The serving gNB attempts to retrieve the UE context from the anchor gNB based on the informational content of the RRCResumeRequest message. The RRCResumeRequest message contains, for example, the corresponding UE ID (Inactive-RNTI, I-RNTI, etc.) for retrieving the context.

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

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

[0112] 7. Next, we assume that the serving gNB successfully retrieves the UE context from the anchor gNB.

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

[0114] 9. Furthermore, as a result of the RRCRelease message, the UE remains in RRC_INACTIVE and therefore releases (or discards) the C-RNTI. In contrast, when the UE receives an RRCResume message, for example, as a response to the previous RRCResumeRequest message in step 3 above, it retains the C-RNTI.

[0115] To support multi-SDT transmissions, it may be necessary to extend the above series of steps, which currently only include a single small data transmission in step 3. For example, the UE can acquire additional suitable UL radio resources and perform one or more UL small data transmissions accordingly.

[0116] However, 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 a temporary C-RNTI has been converted to a C-RNTI) to which the uplink resource grant (such as a DCI in format 0_0, 0_1, or 0_2) is addressed. In other words, the validity of the C-RNTI is important for implementing the multi-SDT procedure. However, whether the UE has a C-RNTI or not depends, as is clear from the above, on the response the UE receives in relation to the initiated RRCResumeRequest and the operation of timer T319.

[0117] More specifically, the UE's C-RNTI is released when the UE receives an RRCRelease message (see step 8 above) or when the T319 expires (for example, before receiving an RRCRelease message). For example, the current standard in Non-Patent Literature 12 defines the UE's behavior when an RRCRelease message is received in section 5.3.8.3, which includes releasing the C-RNTI (for example, as part of a MAC reset). Furthermore, the current standard in Non-Patent Literature 12 also defines the UE's behavior when, for example, the T319 timer expires in section 5.3.13.5, which includes transitioning to RRC_IDLE, and this behavior (see section 5.3.11 of Non-Patent Literature 12) includes releasing the C-RNTI (for example, as part of releasing all resources such as RLC entities and MAC settings).

[0118] In summary, the UE's C-RNTI remains valid within the UE while the T319 timer is running and until an RRCRelease message is received. As a result, the C-RNTI is only available for a limited time, which may be insufficient for the UE to perform multi-SDT procedures.

[0119] One possible solution is to perform one or more additional small data transmissions at the earliest possible time, for example, after the UE receives the conflict resolution for Msg4 (see Figure 15 and the explanation for 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 this solution, the serving gNB sends an uplink grant addressed to the C-RNTI to the UE, and the UE uses the allocated uplink radio resources to perform the corresponding small data uplink transmission before the RRCRease message is sent by the serving gNB.

[0121] Optionally, small data transmissions can be sent along with buffer status reports, so that the serving gNB can recognize how much more data exists in the UE's buffer, determine if further small data transmissions are needed, and, if necessary, create the next UL grant accordingly.

[0122] Thus, according to the solution in Figure 16, small data transmission can be carried out efficiently and quickly.

[0123] However, such a solution may have the drawback that the UE has not yet been authenticated by the serving gNB because the serving gNB has not yet received the UE context from the anchor gNB. Generally, it is preferable that the UL radio resources are actually reserved and allocated to such a new UE only after the UE has been authenticated by the serving gNB (based on the UE context). For example, the acquisition of the UE context may fail, or the UE may be found to be fraudulent or fake, and thus the allocated radio resources intended for the UL SDT may be wasted.

[0124] Furthermore, in the exemplary scenario in Figure 16, it is assumed that two additional small data transmissions (a total of three SDTs) are possible before the UE context is acquired and the gNB sends an RRCRelease message to the UE. The UE then stops the T319 timer and releases the C-RNTI. After that, further UL small data transmissions are no longer possible. However, the length of time available depends on the time required to acquire the UE context, which can vary greatly and may actually be very short.

[0125] As a possible variation of the described solution, the gNB could wait for the UE to send an RRCRelease message to avoid discarding the C-RNTI. For example, the gNB could wait until just before the UE receives the RRCRelease message and stops the T319 timer, thus avoiding the failure of the RRCResumeRequest procedure and the possible transition to the RRC_IDLE state. This maximizes the time available for small data transmissions, somewhat independently 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, because the serving gNB must send the RRCRelease within the time 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 2000ms (see Non-Patent Literature 12, Section 6.3.2, Information Element "UE-TimersAndConstants", "ENUMERATED{ms100, ms200, ms300, ms400, ms600, ms1000, ms1500, ms2000}"). This maximum value of 2000ms is defined to accommodate UE context acquisition from another gNB, including delays that may occur 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 support multi-SDT procedures and is therefore likely to be too small.

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

[0127] However, setting the T319 timer to a higher value also has drawbacks, as it negatively impacts other UEs that do not perform or even support multiple small data transmissions. The T319 timer value is broadcast within its cell by the serving gNB as part of the system information and is adopted by all UEs, including those that do not perform or support multiple small data transmissions, as well as UEs that only plan to perform RNA (RAN-based notification area updates) and UEs that plan to resume RRC connections. Therefore, an extended T319 timer value negatively impacts the RRCResumeRequest procedure of these UEs because if the RRCResumeRequest procedure fails, the UE will only detect this later, when the T319 timer has expired.

[0128] Multi-SDT procedures can take much longer than single-SDT transmission procedures. In particular, multi-SDT transmission procedures may involve the transmission of several subsequent UL grants after the initial UL SDT transmission (see also Figures 13 and 14). This makes multi-SDT procedures likely to be significantly longer than, for example, the single-SDT transmission procedure described above.

[0129] At RAN2#111_e meeting, it was agreed that Small Data Transmission (SDT) would be configured by the network on a per-Data Radio Bearer (DRB) basis. More specifically, when SDT DRB traffic arrives in RRC_INACTIVE, the SDT procedure is triggered, while when non-SDT DRB traffic arrives in RRC_INACTIVE, the legacy RRC restart procedure (requesting a return to RRC_CONNECTED) is triggered. In other words, when data arrives at a DRB configured by the network (e.g., by a base station) to allow data transmission in an inactive state, the SDT procedure is triggered, while when data arrives at a DRB not configured by the network, the UE is triggered to initiate the (legacy) RRC restart procedure to enter a connected state. At RAN2#112_e meeting, it was further agreed that the UE would suspend all DRBs when entering RRC_INACTIVE, and only SDT DRBs would be restarted (by the UE) at the start of the SDT procedure.

[0130] Therefore, the term SDT procedure, or procedure for transmitting SDT DRB data, means a procedure for transmitting data in an inactive state (e.g., RRC_INACTIVE), and does not necessarily mean the amount of data transmitted by the SDT procedure. Thus, the terms small data and SDT DRB data mean data that can be transmitted in an inactive state (of the UE), and do not necessarily mean the size of this data. In particular, small data or SDT DRB data can be any data in a DRB configured for transmission in an inactive state (such DRBs are also referred to herein as SDT DRBs). Similarly, the term non-SDT DRB data means 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 can be any data in a DRB that is not configured for transmission in an inactive state (such DRBs are also referred to herein as non-SDT DRBs).

[0131] The procedure for transmitting SDT DRB data can be a procedure based on and / or initiated within a RACH procedure. In particular, this RACH procedure can be a 4-step RACH procedure or a 2-step RACH procedure. More specifically, as used herein, an SDT procedure based on a RACH procedure means an SDT procedure initiated during a RACH procedure. This includes not only SDT procedures in which small data is transmitted only once during a RACH procedure, as shown in Figures 13 to 15, but also SDT procedures in which small data is transmitted two or more times during and / or following a RACH procedure, as shown in Figure 16. Furthermore, it also includes SDT procedures in which the SDT procedure does not terminate with the RACH procedure in which it was initiated, as shown in Figure 17.

[0132] More specifically, Figure 17 shows a multi-SDT procedure, i.e., an SDT procedure based on a 4-step RACH procedure that includes two or more small data transmissions. As can be seen from the figure, the SDT procedure in Figure 17 does not terminate with the RACH procedure but continues after receiving Msg4. More specifically, the UE receives UL Grant 1700 after receiving Msg4 and uses UL Grant 1700 to perform small data transmissions. In Figure 17, there is only one small data transmission before the termination of the RACH procedure and only one small data transmission after the termination of the RACH procedure. However, generally, multiple small data transmissions can occur before and / or after the termination of the RACH procedure.

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

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

[0135] <Data connection> As used herein, the term “data connection” can be understood as a connection that enables the transmission of data (e.g., small data) between, for example, a UE and a radio base station. More specifically, a UE without a data connection cannot immediately transmit data, even if it is connected to a radio base station based on, for example, a signaling connection. In this context, data can be broadly understood as, for example, user data from an application running on the UE, as opposed to, for example, control information transmitted using 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, this application further distinguishes different states of data connections, e.g., non-existent, existing but suspended, existing but not in use (which may also be called unsuspended or inactive), and existing and currently in use for transmitting data (which may also be called active). According to this classification of data connections, a suspended data connection exists but cannot be immediately used to transmit data (e.g., in the uplink) because the data connection is suspended by both endpoints (e.g., the UE and the radio base station) and must first be reactivated. An unsuspended data connection, on the other hand, can immediately transmit data (without further steps such as reactivating the data connection). For example, referring to an exemplary 5G NR implementation currently defined in the 3GPP standard, a UE in the RRC inactive state has one or more suspended data connections (the DRB is suspended). A UE in the RRC connected state may have one or more active data connections and possibly other unsuspended data connections (not currently in active use). A UE in an RRC idle state has no data connections (suspended and active data connections). On the other hand, according to the improved data transmission procedure described below, unlike the 5G NR implementation currently defined in the 3GPP standard, a UE in an RRC inactive state has one or more available, unsuspended data connections (these data connections are inactive because no data is exchanged until small data transmissions).

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

[0139] <Technical Terms> The following describes UEs, base stations, and procedures for new radio access technologies envisioned in 5G mobile communication systems (although these can also be used in LTE mobile communication systems). Several different implementations and variations are also described. The following disclosures are facilitated by, and can be based on, at least some of, the discussions and findings described above.

[0140] In general, many assumptions are made in this specification to explain the underlying principles in a clear and easily understandable manner. However, these assumptions are merely illustrative examples and should not be used to limit the scope of this disclosure.

[0141] Furthermore, while certain terminology used in the context of new radio access technologies for the next 3GPP 5G communication systems is not yet fully determined or may ultimately change, some of the terms used below, such as procedures, entities, and layers, are closely related to the terminology used in LTE / LTE-A systems or in current 3GPP 5G standardization. Therefore, while terminology may change in the future, this will not affect the functionality of the embodiments. Accordingly, it will be recognized by those skilled in the art that embodiments and their scope of protection are not limited to certain terms used exemplarily herein because no newer or finally agreed-upon terminology exists, but should be understood more broadly in terms of the functions and concepts that form the basis of the functionality and principles of this disclosure.

[0142] <Embodiment> In general, when non-SDT data arrives during an SDT procedure, a UE in RRC_INACTIVE may i) trigger a RACH procedure to enter a connected state regardless of other circumstances, which can 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, in which case a significant amount of effort may be required to change the specification.

[0143] In view of this, the Disclosure provides a technique that enables efficient handling of non-SDT DRB data arriving during an SDT procedure. In particular, the disclosed procedure makes it possible to use a transmission opportunity already occurring for the transmission of small data for the purpose of transmitting a traffic instruction indicating the arrival of non-SDT DRB data. By using an already occurring transmission opportunity, it is possible to avoid the UE needing another UL grant to transmit an instruction for the arrival of non-SDT data and / or initiating an additional RACH procedure to enter a connected state, thus saving power to the UE, reducing overhead and avoiding collisions with other UEs.

[0144] This disclosure provides a base station and user equipment. As shown in Figure 18, user equipment 1810 and base station 1860 can communicate with each other via a radio channel in a wireless communication system. For example, user equipment may be NR user equipment, and base station may be a network node or scheduling node such as an eNB or NR gNB, in particular a gNB in ​​a non-terrestrial network (NTN) NR system. This disclosure further provides a system including a scheduled device and a scheduling device, as well as corresponding methods and programs. An example of such a communication system is shown in Figure 18. Communication system 1800 may be a wireless communication system in accordance with the technical specifications of 5G, in particular an NR communication system. However, this disclosure is not limited to 3GPP NR and may also be applicable to other wireless systems such as NTN or cellular systems. Figure 18 shows a simplified, general, and exemplary block diagram of user equipment 1810 (also referred to as a communication device) and scheduling device 1860, which is hereforeignly assumed to be located at a base station (network node). However, generally, the scheduling device may be a terminal in the case of a side-link connection between two terminals. Furthermore, 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 for a connected vehicle or automated machinery in an industrial plant. Additionally, the communication device 1810 may function as a relay between the base station 1860 and other communication devices (for example, this disclosure is not limited to communication “terminals” or user “terminals”).

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

[0146] As shown in Figure 18 (left), according to an exemplary embodiment, a user device (UE) 1810 is provided. The UE 1810 comprises a transceiver 1820 and a circuit 1830. When operating, the circuit 1830 detects that non-SDT DRB data is to be transmitted in a connected state during a procedure to transmit SDT DRB data in an inactive state. When operating, the circuit 1830 determines whether there is a transmission opportunity to wait for. If it is determined that there is no transmission opportunity to wait for, or that there is no prospect of such an opportunity occurring, the circuit initiates a Random Access Channel (RACH) procedure to enter a connected state. If it is determined that there is a transmission opportunity to wait for, and that transmission opportunity occurs, the circuit controls the transceiver to use that transmission opportunity to transmit a traffic instruction indicating the detection of non-SDT DRB data.

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

[0148] In relation to the UE described above, another exemplary embodiment provides a communication method performed by the UE. As shown in Figure 21, this method involves the following steps: - Step S2110 of the procedure for transmitting SDT DRB data in an inactive state, which detects that non-SDT DRB data is transmitted in a connected state, - Step S2120 determines whether or not there is a transmission opportunity to wait for, - If it is determined in S2120 that there are no transmission opportunities to wait for, or that there is no prospect of any transmission opportunities to wait for occurring ("No" in S2140), then step S2130 initiates the Random Access Channel (RACH) procedure to enter a connected state, - Step S2150 is performed if it is determined in S2120 that there is a transmission opportunity to wait for, and if that transmission opportunity occurs (yes in S2140), then use that transmission opportunity to send a traffic instruction indicating the detection of non-SDT DRB data. Includes.

[0149] As shown in Figure 18 (right side), according to another exemplary embodiment, a scheduling device 1860 is provided. The scheduling device 1860 comprises a transceiver 1870 and a circuit 1880. When in operation, the circuit 1880 controls the transceiver to receive transmissions containing SDT DRB data from inactive user equipment (UEs). When in operation, the circuit 1880 obtains a traffic instruction from the received transmission containing SDT DRB data. The traffic instruction indicates that non-SDT DRB data has been detected by the UE. Non-SDT DRB data is data transmitted by a connected UE, and the traffic instruction is signaled by a predefined value of the Logical Channel ID (LCID) in the MAC subheader, where the predefined value of the LCID indicates that non-SDT DRB data has been detected.

[0150] Figure 20 shows an exemplary functional structure of the traffic instruction processing circuit 1885. In particular, the traffic instruction processing circuit 1885 may include a traffic instruction evaluation circuit 2036 and an RRC state transition circuit 2037. Circuit 2036 can be responsible for acquiring and interpreting traffic instructions from transmissions containing small data. Furthermore, once circuit 2036 has acquired traffic instructions from the received transmission, circuit 2037 can be responsible for sending an RRC message to the UE to transition the UE from an inactive state to a connected state.

[0151] Furthermore, a communication method is provided that corresponds to the base station described above and is performed by a scheduling device. As shown in Figure 22, this method consists of the following steps: - Step S2210 receives a transmission containing SDT DRB data from a user device (UE) that is in an inactive state, - Step S2220 of obtaining a traffic instruction from a transmission containing SDT DRB data, indicating that non-SDT DRB data has been detected by the UE, i) the non-SDT DRB data is data transmitted by a connected UE, ii) the traffic instruction is signaled by a predefined value of the Logical Channel ID (LCID) in the MAC subheader, and iii) the predefined value of the 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 comprises a receiver and / or a transmitter, and / or can function as a receiver and / or a transmitter. In this disclosure, in other words, 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 radio signals over the radio channel 1850. Thus, a transceiver corresponds to a receiver, a transmitter, or a combination of a receiver and a transmitter. Generally, base stations and communication devices are assumed to be capable of transmitting and receiving radio signals. However, particularly with respect to some applications of eMBB, mMTC, and URLLC (such as smart homes, smart cities, and industrial automation), there may be cases where devices such as sensors only receive signals. Furthermore, the term “circuit” includes processing circuits formed by one or more processors or processing units, etc. Circuits 1830 and 1880 (or processing circuits) can be one or more processors or one or more hardware such as any LSIs. An input / output point (or node) exists between the transceiver and the processing circuit, and the processing circuit can control the transceiver through this input / output point (or node) during operation, i.e., control the receiver and / or transmitter to exchange received / transmitted data. The transceiver may include an RF (radio frequency) front, including one or more antennas, amplifiers, RF modulators / demodulators, etc., as both transmitter and receiver. The processing circuit can perform control tasks such as controlling the transceiver to transmit user data and control data provided by the processing circuit, and / or to receive user data and control data that is further processed by the processing circuit. The processing circuit may also be responsible for performing other processing such as judgment, determination, calculation, and measurement. The transmitter may be responsible for performing the processing of the transmission and other related processing.The receiver can be responsible for processing the received signal and other related processes (such as monitoring the channel).

[0153] Furthermore, note that any of the steps / operations described below can be performed or controlled by circuit 1830 (on the UE side) and / or circuit 1880 (on the base station side).

[0154] In further description, details and embodiments apply to the transceiver devices, scheduling devices (or scheduling nodes), and methods, respectively, unless otherwise indicated by explicit description or context.

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

[0156] As shown in Figure 23, the statement that a UE is in an SDT procedure does not necessarily mean that the UE has already performed the transmissions associated with the SDT procedure, but rather that the UE has determined that (small) data will be transmitted in an inactive state. Therefore, an SDT procedure can begin with determining that (small) data will be transmitted in an inactive state, and may include a RACH procedure that initiates the SDT procedure, and / or may follow that RACH procedure.

[0157] As used herein, "arrival" means arrival from the upper layer. Therefore, in other words, non-SDT data becomes transmissible. Further, the term "detected" includes not only the detection that the data has actually arrived, but also the detection / determination that non-SDT DRB data is expected to arrive for transmission.

[0158] As shown in FIG. 23, non-SDT DRB data arrives at time T A or time T B and / or can be detected. More specifically, the arrival timing T A of non-SDT traffic means a timing before the first transmission of small data (e.g., Msg3 / MsgA). Instead of this, or in addition to this, the timing T A can also be a period before the UE executes all of its RACH transmissions. Therefore, if non-SDT traffic arrives within the period of T A , there is at least one UL grant (or transmission opportunity) for the transmission of small data, and the UE can use this UL grant (or transmission opportunity) 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, T A can start when the UE triggers the SDT procedure or immediately thereafter, and can end when the UE transmits Msg3 / MsgA or immediately before that. On the other hand, the timing T B means that non-SDT traffic arrives after the first transmission of small data (e.g., Msg3 / MsgA). Therefore, if non-SDT traffic arrives within the period of T B , depending on whether there is a subsequent data transmission, there may or may not be a UL grant available for the UE to indicate the arrival of non-SDT traffic. For example, as shown in FIG. 23, the timing T B can start when the UE transmits Msg3 and end before the UE receives the RRCRelease message / MsgB. Further, in FIG. 23, T B is TA Although it has been shown to be a shorter period, depending on the network decision, T B Please note that this could be a longer period of time.

[0159] When the arrival of non-SDT DRB data is detected, the UE can initiate a new RRC restart procedure, for example, using a CCCH message. Therefore, even if an ongoing RRC restart procedure (for sending SDT DRB data) exists, the UE can initiate a new RACH procedure and resend an RRC restart request in Msg3. However, if a new RACH is triggered regardless of whether an UL grant or transmission opportunity will eventually occur, resource utilization becomes inefficient and RACH conflicts with other UEs may increase.

[0160] Therefore, the processing in the case of the RACH-based SDT procedure, which will be explained in more detail below, can be summarized as follows: A If non-SDT traffic arrives at T, the UE can use the remaining transmission opportunity to send traffic instructions. Furthermore, T B If non-SDT traffic arrives in the UE, the UE may i) send a non-SDT traffic instruction to the gNB for one or more dedicated UL resources received before the end of the SDT procedure, or ii) if it has not received or is not expected to receive one or more dedicated UL resources, it may initiate a new RACH procedure (RRC restart procedure) to enter a connected state. Furthermore, the UE may also initiate a new RACH procedure if it (after) determines that it is no longer expected to receive the expected UL grant, in other words, it is no longer expected to receive a dedicated UL grant.

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

[0162] 1. Already known transmission opportunities Generally, when deciding whether or not to wait for a transmission opportunity, the resources for that transmission opportunity may be known to the UE.

[0163] Generally, if the procedure for sending SDT DRB data is initiated within a RACH procedure, the transmission opportunity to wait for can be the first transmission of the RACH procedure. For example, if an SDT procedure is initiated within a two-step RACH procedure and the UE has not yet sent its first transmission (e.g., MsgA), the UE can use this first transmission to send a traffic instruction. In other words, the UE can use RACH resources (e.g., RACH opportunity resources) to send SDT DRB data (or parts thereof) and traffic instructions. Thus, non-SDT DRB data can be detected by the UE after it has triggered a RACH procedure (e.g., decided to start a RACH procedure) and before it sends the first transmission of that RACH procedure. For example, non-SDT data may arrive while the UE is waiting for a RACH resource that it plans to use (e.g., the next one). In this case, the transmission opportunity (to wait for or not to wait for) can be provided by that RACH resource.

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

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

[0166] <Monitoring known transmission opportunities - S2140> After determining that there is a transmission opportunity to wait for, the UE may monitor that transmission opportunity (S2140). If the UE already knows one or more resources of that transmission opportunity, this step may include waiting for that transmission opportunity to occur (S2140). More specifically, the resources of that transmission opportunity will occur at some point thereafter, and therefore the UE must wait until those resources are available for sending a traffic instruction. 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 Generally, when deciding whether or not to wait for a transmission opportunity, the resources for that transmission opportunity may not be known to the UE. In this case, the UE can expect to receive a UL grant from the scheduling device specifying the resources for that transmission opportunity. As will be further explained below, there are several scenarios in which the UE can expect to receive a UL grant from the scheduling device.

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

[0169] For example, a circuit can control the transceiver and expect to receive an uplink grant after sending the first transmission of the RACH procedure. In particular, the RACH procedure can be a 4-step RACH procedure, where after sending Msg1, the UE expects to receive an UL grant by Msg2.

[0170] Alternatively, or in addition to this, the circuit can expect to receive an uplink grant after it has controlled the transceiver and sent a buffer status report (BSR) indicating the amount (e.g., a non-zero amount) of SDT DRB data to be further transmitted. This BSR may be transmitted as part of the RACH procedure (e.g., in MsgA or Msg3) or after the completion of the RACH procedure, along with a portion of the SDT DRB data. For example (as shown in Figure 17), the UE may not transmit the entire SDT DRB data in MsgA / Msg3 (e.g., considering 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, along with a BSR indicating the non-zero size of the remaining SDT DRB data, in MsgA / Msg3. The UE can then wait for and / or expect a further uplink grant (no longer part of the RACH procedure) to transmit the rest of the SDT DRB data.

[0171] Furthermore, or in addition to this, an uplink grant can be expected to be received after the BSR has been transmitted and the circuit has controlled the transceiver to transmit a portion of the SDT DRB data, in which case the amount of the portion of the SDT DRB data is smaller than the amount indicated by the BSR. In other words, after transmitting a BSR concerning SDT DRB data, the UE can expect an UL grant from the time of the transmission of that BSR until it (successfully) transmits SDT DRB data of the size indicated by that BSR.

[0172] <Monitoring transmission opportunities - S2140> After determining that there is a transmission opportunity to wait for, the UE may monitor that transmission opportunity (S2140). If it is expected that one or more resources for that transmission opportunity will be indicated by a UL grant, this step may include waiting for that UL grant (S2140). This wait may include monitoring the PDCCH for the UL grant. If a UL grant is received, the UE may continue waiting for the transmission opportunity as already described above.

[0173] However, generally, a UE may not receive an expected uplink grant. In response, when the UE is monitoring for a transmit opportunity (S2140), it may determine under certain conditions that it is unlikely to receive an expected uplink grant and / or that an opportunity will not arise. In particular, a transmit opportunity to wait for may be deemed unlikely to arise when an expected uplink grant has not been received and is no longer expected to be received. In response, the UE may determine that no transmit opportunity will arise and / or initiate a (new) RACH procedure to enter a connected state. In particular, if the UE has not received an UL grant upon receiving an RRCRelease message, the UE may initiate an RRC restart procedure. In particular, the UE may then immediately initiate a legacy RRC restart procedure (e.g., without waiting for the completion of an SDT procedure and / or the RACH procedure that initiated that SDT procedure).

[0174] For example, if a transceiver receives an instruction indicating the end of the procedure for transmitting SDT DRB data, it can be assumed that it will not receive the expected uplink grant. Note that this instruction indicating the end of the SDT procedure may be the receipt of Msg4 or MsgB. However, as mentioned above, the RACH procedure may generally end earlier than the SDT procedure. More specifically, as shown in Figure 17, the RACH procedure generally ends when the conflict is resolved, while the SDT procedure generally ends when an RRCRelease message is received. Therefore, the instruction indicating the end of the SDT procedure may be an RRCRelease message received from the base station.

[0175] In general, or in addition to this, if a predetermined time has elapsed since the first or previous transmission of at least a portion of the SDT DRB data, it may be determined that there is no prospect of receiving an expected uplink grant. The predetermined time can be given, for example, by the T319 timer or a timer similar to T319 as described above. However, the predetermined time used by the UE to determine whether the reception of an UL grant is still expected may be another predetermined period during which the UE waits for the reception of the UL grant.

[0176] <Determination of whether or not 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 can determine that there is an opportunity to wait for the first send of the RACH procedure (in other words, if the non-SDT traffic is T A (Arrives at [location]). The UE then waits for a transmission opportunity (S2140) and can use that transmission opportunity to send a traffic instruction.

[0177] Furthermore, non-SDT traffic is T BIf the UE anticipates that a UL grant will soon be allocated by the gNB (i.e., that it has previously sent a BSR but the gNB has not yet allocated a grant for the SDT DRB's BSR), the UE may determine that there is a transmission opportunity to wait for. In particular, the UE may determine that the resources for that transmission opportunity to wait for are specified by the expected UL grant. The UE may then wait for the next UL grant (S2140) and send a non-SDT traffic instruction to the gNB at that grant.

[0178] However, generally speaking, non-SDT traffic is T B If non-SDT traffic arrives at T, the UE may not have a further UL grant to transmit DCCH, and therefore may need to initiate a new RACH just to transmit DCCH. Thus, if only SDT DRB can be transmitted in the SDT procedure, the UE needs another UL grant to transmit the instruction. Therefore, if non-SDT traffic arrives during a RACH-based SDT procedure, and the UE has already transmitted the first transmit of the RACH procedure and has no prospect of receiving a UL grant, the UE can determine that there is no transmit opportunity to wait for. In particular, the UE can determine that there is no transmit opportunity to wait for after transmitting (all) SDT DRB data (for example, when circuit 1830 controls transceiver 1820 to transmit SDT DRB data). In other words, if non-SDT traffic arrives at T B If the UE does not expect that the UL grant will arrive at the specified location and that the UL grant will be allocated by the gNB (i.e., has not previously sent a BSR, or the BSR has been resolved by the gNB), the UE may determine that there is no opportunity to wait for a transmission and may initiate a legacy RRC restart procedure (for example, immediately, without waiting for the completion of the SDT procedure and / or the RACH procedure that initiated the SDT procedure).

[0179] Let us summarize once again, with reference to Figure 24 which illustrates the process, 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. More specifically, Figure 24 exemplifies the case where SDT traffic arrives when the UE is in RRC_INACTIVE, and the UE triggers the SDT procedure accordingly (S2410). Furthermore, we assume that the UE has already sent a RACH preamble for a four-step RACH procedure to start the SDT procedure. Note that here, the term "triggered" means that the UE internally decides / determines to perform the SDT procedure, while the term "start" means the first message of the SDT procedure that makes the scheduling device aware of the UE's decision to perform the SDT procedure. Thus, after S2410, the UE enters a RACH-based SDT procedure to transmit small data. We further assume that non-SDT traffic then arrives and / or is detected by the UE.

[0180] To further understand, when non-SDT traffic arrives, the UE can first determine whether it has already sent the initial RACH message (yes or no in S2420). However, the UE may first determine whether there is still an ongoing SDT procedure (yes or no in S2430), that is, whether it has already received a message to terminate the SDT procedure (e.g., an RRCRelease message), which should be noted as meaning no in both S2420 and S2430. In other words, the UE can perform the individual determinations associated with S2420, S2430, S2440, and S2450, but does not necessarily have to, and in particular does not have to perform these determinations in the specific order shown in Figure 24.

[0181] As shown in Figure 24, if non-SDT traffic arrives before the UE sends all of its own messages for the RACH procedure (e.g., sending Msg3 / MsgA) ("yes" in S2420), the UE may include a traffic instruction in the subsequent RACH message indicating the discovery of non-SDT DRB data (S2421). In other words, if non-SDT DRB data arrives before period T A If detected within the system, the UE can determine that there is an opportunity to wait for a transmission (i.e., a subsequent RACH message). As further shown in Figure 24, the scheduling device may respond to this traffic instruction by terminating 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 can receive a message indicating a transition to a connected state (S2422) and enter a connected state (e.g., the RRC_CONNECTED state) (S2423). The UE can then transmit non-SDT DRB data.

[0182] To further understand, i) (No in S2420) if non-SDT traffic arrives after the UE has sent all of its own messages for the RACH procedure (e.g., Msg3 / MsgA), and ii) (No in S2430) after the UE has received a message to terminate the SDT procedure (S2431), the UE will be in / remain in RRC_INACTIVE (S2432). In other words, if non-SDT DRB data is detected and the UE has already received a message to terminate the SDT procedure, and / or there is no ongoing SDT procedure, it can determine that there is no opportunity to send and wait. Therefore, the UE can initiate the RACH procedure (Legacy RRC Restart Procedure) to enter a connected state and send the non-SDT DRB data.

[0183] Furthermore, if i) non-SDT traffic arrives after the UE has performed all of its own RACH procedure transmissions (No in S2420), and ii) non-SDT traffic arrives before receiving a message indicating the end of the SDT procedure (Yes in S2430), and iii) the UE has not sent a buffer status report indicating a non-zero buffer size for the SDT DRB data (No in S2440), then the UE may initiate the RACH procedure (Legacy RRC Restart Procedure) to enter a connected state (S2442) and enable the transmission of non-SDT DRB data (S2441). In particular, if i) the UE has performed all of its own RACH procedure transmissions, and ii) the UE has not sent a buffer status report indicating a non-zero buffer size for the SDT DRB data, then the UE may determine that there are no transmission opportunities to wait for. Similarly, if a UE sends a BSR but has already received the corresponding UL grants and has used those UL grants to send small data (using those UL grants to send data of the size specified in the BSR), the UE can determine that there are no transmission opportunities to wait for.

[0184] On the other hand, if i) non-SDT traffic arrives after the UE has performed all of its own transmissions in the RACH procedure ("No" in S2420), and ii) non-SDT traffic arrives before receiving a message indicating the end of the SDT procedure ("Yes" in S2430), and iii) the UE has sent a buffer status report indicating a non-zero buffer size for the SDT DRB data ("Yes" in S2440), then the UE can determine that there is a transmission opportunity to wait for (i.e., a transmission expected to be indicated by a UL grant that is expected to be received in response to its BSR). Thus, the UE can 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 instruction indicating the discovery of non-SDT DRB data in a transmission using the resources indicated by the UL grant (S2451). Receiving the UL grant may mean that a transmission opportunity to wait for has arisen. In response to the traffic instruction, 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., the RRC_CONNECTED state) (S2453). The UE can then transmit non-SDT DRB data.

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

[0187] 2. Configured Grant (CG) Procedure As already mentioned above, the procedure for sending SDT DRB data may be a configured grant (CG) procedure for sending SDT DRB data. As will be 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 instruction to the gNB at a dedicated UL resource received before the end of the SDT procedure, or ii) initiate a legacy RRC restart procedure. Here, the dedicated UL resource may be a CG resource configured for the UE to send SDT DRB data before / when the UE enters an inactive state.

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

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

[0190] Note that in the case of a CG-based SDT procedure, the determination step S2120 may include determining whether the next RACH resource is earlier than (or not later than) the next CG resource.

[0191] In other words, if non-SDT traffic arrives while CG resources for SDT transmission are configured on the UE, the UE can send a non-SDT traffic instruction to the scheduling device on (part of) the CG resources, or initiate a legacy RRC restart procedure, depending on which delay is shorter.

[0192] Alternatively, a delay threshold can be signaled to the UE. In this case, the UE can compare the delay threshold with the time to the next CG resource and make a decision accordingly. For example, 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 to the next CG resource), the UE can determine that the next CG resource is a transmission opportunity to wait for. 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 met: 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. Therefore, the UE can decide to initiate the RACH procedure to enter a connected state if both of the following conditions are met: 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 delay thresholds allow for flexible adjustment of the delay that a UE tolerates, taking into account traffic conditions such as the probability of RACH collisions with other UEs.

[0194] If the next CG resource has the same latency as the next RACH resource (in other words, neither the next CG resource nor the next RACH resource is faster), the UE can choose the CG resource, which has the advantage of avoiding conflicts with other UEs.

[0195] <Instructions for non-SDT DRB traffic> Traffic instructions indicate 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 instructions, which are further described below. In particular, the UE (e.g., circuits 1830 and / or 1835) can generate and / or include each traffic instruction in a transmission, especially a small data transmission. The base station (e.g., circuits 1880, 1885, and / or 2036) can extract traffic instructions from a transmission, especially a small data transmission, and / or interpret the extracted traffic instructions as intended by the UE.

[0196] In general, traffic instructions can also indicate that the UE expects non-SDT DRB to arrive (for example, in the near future). In other words, if the UE expects such an arrival before the non-SDT data actually arrives, the UE can determine that the non-SDT data is arriving and then use traffic instructions to indicate the arrival to the base station.

[0197] Generally, the traffic indication can be sent together with at least a part of the SDT DRB data indicated by the uplink grant and / or a buffer status report (BSR) indicating the amount of SDT DRB data (e.g., the amount to be further transmitted). Generally, the BSR of non-SDT DRB data can also be included in the message containing the traffic indication or can be used as the traffic indication. However, if the UE does not resume the non-SDT DRB when the SDT procedure is triggered, the traffic from the non-SDT DRB may not reach the layer 2 buffer, so the UE may not be able to generate the BSR of the non-SDT DRB.

[0198] The non-SDT traffic indication is for notifying 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 can be signaled by a predefined value of the logical channel ID (LCID) in the MAC subheader, and the predefined value of the LCID indicates that non-SDT DRB data has been detected.

[0200] For example, a pre-defined value of the LCID indicating the arrival of non-SDT traffic can (further) indicate that the MAC control element (CE) is not added to the MAC sub-header. This is shown in FIG. 25, where the traffic indication corresponds to the last MAC sub-header with LCID index = 50. Generally, a MAC sub-header with a specific LCID index (e.g., index #50 as shown in FIG. 25 and Table 1 below) can be used to indicate the arrival of non-SDT traffic, and at this time, no BSR MAC CE is added after the sub-header. In other words, the MAC sub-frame containing the traffic indication (i.e., the MAC sub-header with its specific / predetermined LCID index) does not carry a MAC CE. For example, this MAC sub-frame can be composed of the MAC sub-header.

[0201] By not adding a BSR MAC CE to the sub-header indicating the arrival of non-SDT DRB data, the UE can refrain from restarting the non-SDT DRB at the start of the SDT procedure. More specifically, when the upper layer (e.g., the SDAP layer) recognizes / detects the arrival of non-SDT data, the UE can send such a MAC sub-header at that time to notify the arrival of non-SDT data. Since the UE does not need to send a BSR for non-SDT data, the UE does not need to restart the non-SDT DRB. Furthermore, the MAC sub-header typically consumes only 8 bits, while the BSR MAC CE consumes at least 16 bits (8 bits for the short BSR + 8 bits for the sub-header), so the overhead can be reduced.

Table 2

[0202] Alternatively, the LCID indicating the arrival of non-SDT traffic can (further) indicate that a BSR MAC control element (CE) is added to the MAC sub-header, and the BSR MAC CE further indicates the amount of SDT DRB data to be transmitted.

[0203] Therefore, if non-SDT traffic arrives and the UE is still holding some pending data from the SDT DRB, the UE can notify 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 indicating the amount of remaining SDT DRB data after this subheader. This is illustrated in Figure 26, where the traffic instruction corresponds to the last MAC subheader with LCID index=51. As can be seen from the figure, this MAC subheader with LCID index=51 is appended with a short BSR MAC CE indicating the size of the remaining SDT DRB data.

[0204] By adding a 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 since the buffer size of the non-SDT DRB is not expected to be reported, the UE does not need to restart the non-SDT DRB at the start of the SDT procedure.

[0205] Alternatively, if you are resuming non-SDT DRB at the start of the SDT procedure, note that you can also use the BSR MAC CE to indicate the amount of non-SDT DRB data being sent.

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

[0207] 2. Traffic instruction by MAC control elements Generally, traffic instructions can be part of the MAC control element (CE). For example, one bit of the MAC CE indicates whether non-SDT DRB data has been detected, two bits of the MAC CE indicate the logical channel group (LCG) of the SDT DRB data among the LCGs that support data transmission in an inactive state, and five bits of the MAC CE indicate the amount of further SDT DRB data to be transmitted corresponding to the indicated LCG.

[0208] In other words, when reporting the buffer status of an SDT DRB, a new BSR MAC CE can be used to indicate the arrival of non-SDT DRB data. Figure 27 shows 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 here that each SDT DRB is typically mapped to one LCG (many-to-one mappings are also possible), and such mappings are set 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 4. Therefore, the new BSR MAC CE can be used only to indicate the buffer sizes 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 impossible to have a BSR 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. Note 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, not only the BSR of SDT DRB data but also the arrival of non-SDT traffic can be reported. Also, since a BSR for inactive LCGs is not expected, the UE can refrain from restarting non-SDT DRBs at the start of the SDT procedure.

[0212] <RRC level indication> In general, traffic instructions may be at the Radio Resource Control (RRC) level. These RRC-level instructions can be conveyed, for example, in a new UL DCCH message. For instance, a new DCCH message could be similar to an RRCReestablishmentComplete message, which is mostly empty. An example of such a UL-DCCH message is shown below (new information elements are bolded and underlined). The message type indNonSDTDRBArrival has been introduced to signal instructions for the arrival of non-SDT DRB data. [Table 3]

[0213] The INDNonSDTDRBArrival message in this example has no specific informational elements except for the following formal description, and is very similar to the RRCReestablishmentComplete message specified in Non-Patent Document 13. When this message exists (is received), it indicates the following: [Table 4]

[0214] <UE standards for redundancy> If non-SDT DRB is also reactivated at the start of the SDT procedure, BSR reporting for non-SDT traffic is also possible. In this case, upon receiving a UL grant for sending SDT DRB data, the UE may choose to send one or more of the following using the resources indicated by the UL grant: - SDT DRB user data (e.g., SDT DRB data), - BSR of SDT traffic (e.g., the size of further SDT DRB data being sent), - In the case of detection / arrival of non-SDT DRB data, non-SDT DRB arrival instructions (e.g., traffic instructions), - In the case of detection / arrival of non-SDT DRB data, the BSR for non-SDT traffic (e.g., the size of the arrived / detected non-SDT DRB data)

[0215] The selection criteria can be based on the comparison of priorities (between SDT traffic and non-SDT traffic) and the size of the grant. Note that when the BSR for non-SDT data is transmitted, it can be noted that an additional traffic indication indicating the arrival of non-SDT data is not required. Furthermore, when all SDT DRB data is transmitted using the resources indicated by the current UL grant, it can be noted that the BSR for SDT data is not required.

[0216] Therefore, generally, when the resources indicated by the UL grant are sufficient, the UE can transmit the entire user data and the BSR for non-SDT data. On the other hand, when the resources indicated by the UL grant are not sufficient to transmit the entire user data and the BSR for non-SDT data, do as follows. - When the priority of non-SDT data is higher than the priority of SDT data, the UE can determine to transmit the BSR for non-SDT data, the BSR for SDT data, and a part of SDT (in this order of priority) using the resources indicated by the UL grant. - When the priority of SDT data is higher than the priority of non-SDT data, the UE can determine to transmit the following using the resources indicated by the UL grant. 〇 Traffic indication and all SDT data, or 〇 When the resources are not sufficient to transmit the traffic indication and all SDT data, the traffic indication, the BSR for SDT data, and a part of 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 the 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, the efficient use of the allocated resources can be promoted.

[0219] <Processing of SDT traffic with RA-SDT set> The handling described above for non-SDT traffic arriving during an ongoing SDT procedure can also be applied to traffic associated with LCH limits. In particular, the handling described above can be applied when RA-SDT traffic arrives / is detected during an 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 arrival of non-SDT traffic. In particular, the UE can send a traffic instruction to the scheduling device indicating the arrival / detection of RA-SDT traffic. For example, the UE can signal a traffic instruction to the gNB upon arrival of SDT traffic on an LCH not associated with a CG-SDT procedure. Such a traffic instruction is intended to inform the gNB of the arrival of traffic configured solely for RA-SDT. The UE can initiate an RA-SDT procedure if it has not received or is not expected to receive CG-SDT resources. In other words, RA-SDT traffic plays the role of non-SDT traffic in the embodiments described above. For example, the arrival / detection of non-SDT traffic corresponds to the arrival / detection of RA-SDT traffic, and the traffic instructions sent by the UE indicate the arrival of RA-SDT data, not the arrival of non-SDT data.

[0220] The main difference is that both types of data (data being transmitted in progress and newly detected data) are transmitted while the system is inactive. As a result, if there are no transmission opportunities to wait for, instead of initiating the RACH procedure to enter the connected state (S2130), the UE initiates the 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 instruction, the scheduling device provides the UE with one or more grants for transmitting RA-SDT data without transitioning the UE to the connected state.

[0221] The following provides a more detailed explanation of this procedure. However, not all of the above explanation for non-SDT data applies to the arrival of RA-SDT data. In this regard, it should be noted that, apart from the differences described above, everything stated above regarding the processing of the arrival of "non-SDT data" can be applied to the processing of the arrival of "RA-SDT data" by, for example, replacing the term "non-SDT data" with "RA-SDT data," unless the context specifically indicates otherwise.

[0222] In particular, as shown in Figure 28 (left), an exemplary embodiment provides a user device (UE) 2810. The UE 2810 comprises a transceiver 2820 and a circuit 2830. Circuit 2830 (e.g., circuit 2835) detects, during operation, that during a procedure for transmitting first data on a first logical channel in an inactive state, second data on a second logical channel is to be transmitted in an inactive state. The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, wherein the second logical channel (i) has no CG resources configured for transmission in an inactive state, and (ii) has random access (RA) resources configured for transmission in an inactive state. Circuit 2830, during operation, determines whether there is a transmission opportunity to wait for. This transmission opportunity 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 are no transmission opportunities to wait for, or that there is no prospect of any transmission opportunities to wait for occurring, circuit 2830, when operational, initiates an RA procedure to transmit a second data using the RA resource. When it is determined that there are transmission opportunities to wait for, and when such transmission opportunities occur, circuit 2830, when operational, controls transceiver 2820 to use those transmission opportunities to send a traffic instruction indicating the detection of the second data.

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

[0224] In relation to the UE described above, another exemplary embodiment provides a communication method performed by the UE. As shown in Figure 31, this method involves the following steps: - Step S3110 of detecting that second data is transmitted on the second logical channel while in an inactive state, during the procedure for transmitting first data on the first logical channel in an inactive state, - Step S3120 determines whether or not there is a transmission opportunity to wait for, - If it is determined in S3120 that there are no transmission opportunities to wait for, or that no transmission opportunities to wait for will occur ("No" in S3140), step S3130 initiates the RA procedure to send second data using the RA resource, - Step S3150, when it is determined that there is a transmission opportunity to wait for (S3120), and when that transmission opportunity occurs (S3140, "yes"), to use that transmission opportunity to send a traffic instruction indicating the discovery of the second data, Includes.

[0225] As shown in Figure 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. When in operation, the circuit 2880 controls the transceiver 2870 to receive a transmission containing first data for a first logical channel from an inactive user equipment (UE). When in operation, the circuit 2880 obtains a traffic instruction from the received transmission containing the first data. The traffic instruction indicates that second data for a second logical channel has been detected by the UE. The second data is data transmitted by an inactive UE, and the traffic instruction is signaled by a predefined value of the Logical Channel ID (LCID) in the MAC subheader, where the predefined value of the LCID indicates that the second data has been detected.

[0226] Figure 30 shows an exemplary functional structure of the traffic instruction processing circuit 2885. In particular, the traffic instruction processing circuit 2885 may include a traffic instruction evaluation circuit 3036 and a scheduling circuit 3037. Circuit 3036 can be responsible for acquiring and interpreting traffic instructions from transmissions containing small data. Furthermore, once circuit 3036 has acquired traffic instructions from the received transmission, circuit 3037 can be responsible for sending a grant to the UE for transmitting RA-SDT data (i.e., "second data").

[0227] Furthermore, a communication method is provided that corresponds to the base station described above and is performed by a scheduling device. As shown in Figure 32, this method consists of the following steps: - Step S3210 receives a transmission from an inactive UE that includes first data for the first logical channel, - Step S3220 of obtaining a traffic signal from a transmission containing first data, indicating that second data on a second logical channel has been detected by a UE, wherein i) the second data is data transmitted by a UE in an inactive state, ii) the traffic signal is signaled by a predefined value of the logical channel ID (LCID) in the MAC subheader, and iii) the predefined value of the LCID indicates that second data has been detected, Includes.

[0228] As with the arrival of non-SDT data, it should be noted that transmission opportunities to wait for mean (i) transmission opportunities to transmit at least a portion of the first data, and (ii) transmission opportunities that are expected to occur as part of the procedure for transmitting the first data.

[0229] Here, the terms RA-SDT traffic and RA-SDT data refer, respectively, to traffic and data on a logical channel (hereinafter also referred to as the second logical channel) that does not have a CG resource configured for transmission in the inactive state, but does have a Random Access (RA) resource configured for transmission in the inactive state. In particular, the second logical channel (LCH) may have only an RA resource configured and / or associated with transmission in the inactive state. Note that RA-SDT data is also referred to as second data. Note that the RA resource for transmitting data in the inactive state may be different from 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 on a logical channel (hereinafter also referred to as the first logical channel) configured with CG resources for transmission in an inactive state, respectively. Note that RA-SDT data is also referred to as the first data. Note that the first LCH may or may not have RA resources configured. 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] Generally, a UE can be configured with multiple logical channels (LCHs). An LCH can be configured with an RA-SDT resource for transmission in an inactive state and / or a CG-SDT resource for transmission in an inactive state. For example, an LCH can be configured with either (i) RA-SDT, or (ii) CG-SDT and RA-SDT. This is illustrated in Figure 33, where the UE is configured with two logical channels, represented as LCH1 and LCH2, respectively. As illustrated, LCH1 is configured with both CG-SDT and RA-SDT, while LCH2 is configured with only RA-SDT. If traffic is available on LCH1, and the CG-SDT criterion is met, the UE can transmit traffic via CG-SDT. Otherwise, if the criterion is not met, the UE can transmit traffic via RA-SDT. On the other hand, if traffic is available on LCH2, the UE can transmit traffic only via RA-SDT. Generally, existing signaling can also be reused to enforce LCH restrictions. How the restrictions are set can be left to the gNB. In other words, the base station can configure RA-SDT and / or CG-SDT for each LCH.

[0232] As already mentioned above, the traffic instructions, the determination of whether or not there are transmissions to wait for, and other aspects of processing when RA-SDT traffic arrives during an ongoing CG-SDT procedure are substantially the same as the corresponding aspects described above for processing the arrival of non-SDT traffic. In particular, these are as follows:

[0233] Generally, if the next resource in a CG procedure is earlier than the next RA resource among the RA resources, the circuit can determine that there is a transmission opportunity to wait for (S3120). In this case, the traffic instruction can be sent using that transmission opportunity. Furthermore, if the next resource in a CG procedure is later than the next RA resource, the circuit can determine that there is no transmission opportunity to wait for (S3120) and can initiate an RA procedure to send the second data using the RA resource (S3130). In other words, the UE can either send a traffic instruction 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 generally, the UE may also determine 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 (S3120). In other words, a delay threshold can be signaled to the UE so that it compares it with the time to the next CG resource and makes a decision based on the result of that 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, if the time to the transmission opportunity is equal to the threshold, the UE may also decide not to wait. Furthermore, generally, the UE may take other criteria into consideration when deciding whether or not to wait for a transmission opportunity. Such thresholds may be signaled by gNB, pre-set, or be predetermined values.

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

[0236] Furthermore, in the case of RA-SDT data arrivals, as in the case of non-SDT data arrivals, traffic instructions can be at the Radio Resource Control (RRC) level and / or the Media Access Control (MAC) level. In particular, as already explained with respect to Figures 25-27, traffic instructions can be signaled within the MAC subheader by a predefined value of the Logical Channel ID (LCID) within the MAC subheader, where the 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 or without the BSR MAC CE appended.

[0237] In this regard, it should be noted that the UE (e.g., circuit 2830) may decide whether or not to append a BSR MAC CE to the MAC subheader indicating (i) the amount of first data to be further transmitted, and / or (ii) the amount of second data. This decision may depend, for example, on the size of the configured grant. More specifically, the UE may decide to append a BSR if the CG resources of the transmission opportunity are greater than or equal to a threshold, and / or not to append a BSR if the size of the transmission opportunity is less than a threshold. In particular, the threshold described above may correspond to the size of the BSR. In other words, if the size of the unused portion of the configured grant is greater than or equal to (one or more) BSRs, then (one or more) BSRs may be included. More specifically, the UE may include (one or more) BSRs if the size of the configured grant (i.e., the transmission opportunity used to transmit the traffic instruction) is sufficient to convey (one or more) BSRs. Here, “sufficient” means, for example, that the size of the configured grant is sufficient to transmit (i) data for the first logical channel to be transmitted, (ii) traffic instructions, and (iii) one or more BSRs for the first and / or second data. The data for the first logical channel to be transmitted may be, for example, currently available data for the first logical channel, data for the first logical channel that the UE has decided to transmit using the configured grant, and / or data for the first logical channel that is transmitted as a result of considering, for example, the QoS of the services 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) of 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, the 5 bits can indicate the amount of the first data to be further transmitted.

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

[0241] <Implementation of this disclosure through hardware and software> This disclosure can be implemented by software, by hardware, or by software working in conjunction 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 combination of LSIs. An LSI can be formed individually as a chip, or it can be formed as a single chip containing some or all of the functional blocks. An LSI can include data input / output units coupled to itself. Here, LSIs are also referred to as ICs, system LSIs, super LSIs, or ultra LSIs, depending on the degree of integration. However, the technology for implementing integrated circuits is not limited to LSIs and may be implemented using dedicated circuits, general-purpose processors, or dedicated processors. Furthermore, FPGAs (field-programmable gate arrays) that can be programmed after the manufacture of the LSI, or reconfigurable processors that can reconfigure the connections and settings of circuit cells located inside the LSI can also be used. This disclosure can be implemented as digital or analog processing. If LSIs are replaced by future integrated circuit technologies as a result of advancements in semiconductor technology or other derivative technologies, functional blocks can be integrated using those future integrated circuit technologies. Biotechnology can also be applied.

[0242] This disclosure can be implemented by any type of device, apparatus, or system having communication capabilities (referred to as a communication apparatus).

[0243] A communication device may comprise a transceiver and a processing / control circuit. The transceiver may comprise a receiver and a transmitter, and / or may function as both a receiver and a transmitter. A transceiver acting as both 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-exclusive examples of such communication devices include telephones (e.g., mobile 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, smartwatches, tracking devices), game consoles, e-readers, telemedicine / telemedicine devices, vehicles providing communication capabilities (e.g., automobiles, airplanes, ships), and various combinations thereof.

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

[0246] Communication may include steps such as exchanging data through cellular systems, wireless LAN systems, satellite systems, and others, and various combinations thereof.

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

[0248] Communication equipment may further include base stations, access points, and any other devices, devices, or systems that communicate with or control infrastructure equipment, such as the devices 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. Combinations of software modules and hardware implementations are also possible. Software modules can be stored in any type of computer-readable storage medium. In particular, according to another implementation, a non-transient computer-readable recording medium is provided. The recording medium stores a program, and when the program is executed by one or more processors, one or more processors perform the steps of the method according to this disclosure.

[0250] As an example, and without limiting the scope of this invention, such computer-readable storage media may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage devices, magnetic disk storage devices or other magnetic storage devices, 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. Furthermore, 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 technology such as infrared, radio, or microwave, then coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technology such as infrared, radio, or microwave are included in the definition of a medium. However, it should be understood that computer-readable storage media and data storage media do not include connections, carriers, signals, or other transient media; instead, they refer to non-transient tangible storage media. The magnetic and optical disks used herein include compact discs (CDs), laserdiscs, optical discs, digital-purpose discs (DVDs), floppy disks, and Blu-ray discs. Magnetic disks typically reproduce data magnetically, while optical discs reproduce data optically using a laser. Any combination of the above is also included within the scope of computer-readable media.

[0251] Furthermore, it should be noted that individual features of several different embodiments may be the subject of other embodiments, individually or in any combination. Those skilled in the art will understand that numerous changes and / or modifications are possible to the disclosure shown in specific embodiments. Therefore, the embodiments described herein should be considered as illustrative in all respects and not as limiting the invention.

[0252] <Further aspects> According to the first embodiment, a user device (UE) is provided. The UE comprises a transceiver and a circuit. When operating, the circuit detects that a second data will be transmitted in a connected state during a procedure for transmitting a first data in an inactive state. When operating, 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 there is no longer any prospect of such an opportunity occurring, the circuit initiates a Random Access Channel (RACH) procedure to enter a 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 instruction indicating the 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 opportunities to wait for are indicated by i) the first transmission in a RACH procedure, ii) an uplink grant received as part of a RACH procedure, or iii) an uplink grant received to transmit the first data after the completion of a RACH procedure.

[0254] According to a third aspect provided in addition to the first aspect, the procedure for transmitting first data is a procedure initiated in a RACH procedure, i) the circuit has controlled the transceiver to transmit first data during operation and has determined that there is no transmission opportunity to wait for, or ii) a transmission opportunity to wait for is expected to be indicated by an uplink grant, which is expected to be received to transmit a portion of the first data as part of the RACH procedure or after the 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 circuit controls the transceiver to i) transmit a first transmission of the RACH procedure, ii) transmit a buffer status report (BSR) indicating the amount of first data to be transmitted further, and / or iii) transmit a portion of the first data after transmitting this BSR, wherein the amount of the portion of the first data is less than the amount indicated by the BSR.

[0256] According to a fifth aspect provided in addition to the third or fourth aspect, a transmission opportunity to wait is no longer likely to occur when an expected uplink grant has not been received and is no longer likely to be received, and an expected uplink grant is no longer likely to be received if i) the transceiver has received an instruction indicating the end of the procedure for transmitting the first data, and / or ii) a predetermined amount of 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 aspect of the first to fifth aspects, the traffic instruction is transmitted together with i) at least a portion of the first data that uses resources indicated by the uplink grant, and / or ii) a buffer status report (BSR) indicating the 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 first data is a configured grant (CG) procedure for transmitting first data, wherein the circuit, in operation, i) determines that there is a transmission opportunity to wait for if the next resource for the CG procedure is earlier than the next RACH resource, and controls the transceiver to use that transmission opportunity to transmit a traffic instruction; and ii) determines that there is no transmission opportunity to wait for if the next resource for 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, traffic instructions are signaled by a predefined value of a logical channel ID (LCID) in the MAC subheader, where the predefined value of the LCID indicates that a second data has been detected.

[0261] According to a tenth aspect provided in addition to the ninth aspect, the predefined value of LCID indicates that the MAC control element CE is not attached 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 attached to the MAC subheader, and the BSR MAC CE indicates the amount of first data to be transmitted further.

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

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

[0265] According to a fourteenth aspect, a method for a user equipment (UE) is provided. This method comprises the following steps: - During the procedure for transmitting the first data in an inactive state, the step of detecting that the second data is transmitted in a connected state, - A step of determining whether there is a transmission opportunity to wait for, wherein the transmission opportunity to wait for is i) a transmission opportunity for transmitting at least a portion of a first data, and ii) is expected to occur as part of a procedure for transmitting the first data. - When it is determined that there are no transmission opportunities to wait for, or that there is no prospect of any transmission opportunities to wait for occurring, the step of initiating a Random Access Channel (RACH) procedure to enter a connected state, - The steps include determining that a transmission opportunity to wait exists, and when that transmission opportunity occurs, using that transmission opportunity to send a traffic instruction indicating the discovery of a second data, Includes.

[0266] According to the 15th aspect, a scheduling device is provided. The scheduling device comprises a transceiver and a circuit, the circuit controlling the transceiver to receive a transmission containing first data from an inactive user device (UE) during operation. During operation, the circuit obtains a traffic signal from the transmission containing the first data indicating that a UE has detected second data, i) the second data is data transmitted by a connected UE, ii) the traffic signal 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.

[0267] According to the sixteenth aspect, a method for a scheduling device is provided. This method comprises the following steps: - A step of receiving a transmission containing first data from a user device (UE) that is in an inactive state, - A step of obtaining a traffic signal from a transmission containing first data, indicating that a second data has been detected by a UE, wherein i) the second data is data transmitted by a connected UE, ii) the traffic signal is signaled by a predefined value of the 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.

[0268] According to the 17th aspect provided in addition to the 15th or 16th aspect, the transmission containing the first data is transmitted as part of a procedure initiated in the RACH procedure.

[0269] According to the 18th aspect provided in addition to the 17th aspect, the RACH procedure is a 4-step RACH procedure or a 2-step RACH procedure.

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

[0271] According to a 20th aspect provided in addition to one of the 15th to 19th aspects, the predefined value of the LCID indicates that a MAC control element (CE) is not attached to the MAC subheader.

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

[0273] According to the 22nd aspect, a scheduling device is provided. The scheduling device comprises a transceiver and a circuit, the circuit controlling the transceiver to receive a transmission containing first data from a user device (UE) in an inactive state during operation. During operation, the circuit obtains a traffic instruction from the transmission containing the first data indicating that a second data has been detected by the UE, i) the second data is data transmitted by a connected UE, ii) the traffic instruction 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 the logical channel group (LCG) of the first data among the LCGs that support the transmission of data in an inactive state, and five bits of the MAC CE indicate the amount of further transmission of the first data corresponding to the indicated LCG.

[0274] According to a 23rd aspect, a method for a scheduling device is provided. This method comprises the following steps, namely: - A step of receiving a transmission containing first data from a user device (UE) that is in an inactive state, - A step of obtaining a traffic instruction from a transmission containing first data, indicating that a second data has been detected by a UE, wherein i) the second data is data transmitted by a connected UE, and ii) the traffic instruction 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 the logical channel group (LCG) of the first data among the LCGs that support data transmission in an inactive state, and five bits of the MAC CE indicate the amount of the first data to be further transmitted corresponding to the indicated LCG. Includes.

[0275] According to the 24th aspect, a user device (UE) is provided. The UE comprises a transceiver and a circuit. When operating, the circuit detects that a second data on a second logical channel is to be transmitted in an inactive state during a procedure for transmitting a first data on 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 has (i) no CG resources configured for transmission in an inactive state, and (ii) a random access (RA) resource configured for transmission in an inactive state. When operating, the circuit determines whether there is a transmission opportunity to wait for, which is (i) a transmission opportunity to transmit 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 there is no prospect of such an opportunity occurring, the circuit, when operating, 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 that transmission opportunity occurs, the circuit, when operating, controls the transceiver to use that transmission opportunity to send a traffic instruction indicating the discovery of the second data.

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

[0278] According to a 26th aspect provided in addition to the 24th aspect, the circuit determines, during operation, 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, traffic instructions are signaled in the media access control (MAC) subheader by a predefined value of the logical channel ID (LCID) in the MAC subheader, where the predefined value of the LCID indicates that a second data has been detected.

[0280] According to a 28th aspect provided in addition to the 27th aspect, the circuit determines whether, during operation, to append a BSR MAC CE to the MAC subheader indicating (i) the amount of first data to be further transmitted, and / or (ii) the amount of second data.

[0281] According to a 29th aspect provided in addition to the 27th aspect, the predefined value of LCID indicates that a MAC control element (CE) is not attached to the MAC subheader.

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

[0283] According to a 31st aspect provided in addition to one aspect from the 24th to the 30th aspects, the traffic instruction includes an instruction indicating a second amount of data.

[0284] According to a 32nd aspect provided in addition to one aspect from the 24th to the 26th aspects, the traffic instruction is part of a medium access control (MAC) control element (CE), where (i) one bit of the MAC CE indicates whether or not a second data has been detected, (ii) two bits of the MAC CE indicate the logical channel group (LCG) of the first data among the LCGs that support the 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 aspect from the 24th to the 31st aspects, the traffic instruction is a radio resource control (RRC) level instruction and / or a media access control (MAC) level instruction.

[0286] According to the 34th aspect, a method for a user device (UE) is provided. The method includes, during a procedure for transmitting first data on a first logical channel in an inactive state, the step of detecting that second data on a second logical channel is to be 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 an inactive state, and (ii) has a random access (RA) resource configured for transmitting in an inactive state. The method further includes the step of determining whether there is a transmission opportunity to wait for, which is (i) a transmission opportunity to transmit 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 there is no longer any prospect of a transmission opportunity to wait for occurring, the 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 that transmission opportunity occurs, the transmission opportunity is used to transmit a traffic instruction indicating the discovery of the second data.

[0287] According to the 35th aspect, a scheduling device is provided. The scheduling device comprises a transceiver and a circuit. When operating, the circuit (i) controls the transceiver to receive a transmission containing first data for a first logical channel from an inactive user device (UE), and (ii) obtains a traffic instruction from the transmission containing the first data indicating that the UE has detected second data for a second logical channel. The second data is data transmitted by the inactive UE, and the procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data. The second logical channel (i) does not have a CG resource configured for transmission in the inactive state, and (ii) has a random access (RA) resource configured for transmission in the inactive state. The traffic instruction is signaled by a predefined value of a logical channel ID (LCID) in a media access control (MAC) subheader, the predefined value of the LCID indicating that the second data has been detected.

[0288] According to the 36th aspect, a method for a scheduling device is provided. The method includes (i) receiving a transmission from an inactive user device (UE) containing first data for a first logical channel, and (ii) obtaining a traffic instruction from the transmission containing the first data indicating that the UE has detected second data for a second logical channel. The second data is data transmitted by the inactive UE, and 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 transmission in the inactive state, and (ii) has a random access (RA) resource configured for transmission in the inactive state. The traffic instruction is signaled by a predefined value of a logical channel ID (LCID) in a media access control (MAC) subheader, the predefined value of the LCID indicating that the second data has been detected.

[0289] In summary, the invention provides a user equipment (UE), a corresponding scheduling device, and methods for each of the UE and scheduling devices.

[0290] In particular, this disclosure provides a UE comprising a transceiver and circuitry, the circuitry detecting during a procedure for transmitting first data in an inactive state that second data will be transmitted in a connected state. The circuitry determines whether there is a transmission opportunity to wait for. A transmission opportunity to wait for is i) a transmission opportunity to transmit at least a portion of the first data, and ii) an opportunity that 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 there is no longer any prospect of such an opportunity occurring, the circuitry initiates a Random Access Channel (RACH) procedure to enter a connected state. When it is determined that there is a transmission opportunity to wait for, and that transmission opportunity occurs, the circuitry controls the transceiver to use that transmission opportunity to transmit a traffic instruction indicating the detection of the second data.

[0291] The disclosure also provides a UE comprising a transceiver and a circuit, the circuit detecting during a procedure for transmitting first data on a first logical channel in an inactive state that second data on a second logical channel will be transmitted in an inactive state. More specifically, 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 a random access (RA) resource configured for transmitting in an inactive state. The circuit determines whether there is a transmission opportunity to wait for. A transmission opportunity to wait for is i) a transmission opportunity to transmit 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 there is no longer any prospect of a transmission opportunity to wait for occurring, the circuit initiates an RA procedure to transmit the second data using the RA resource. On the other hand, if it is determined that a transmission opportunity to wait exists and that transmission opportunity arises, the circuit controls the transceiver to use that transmission opportunity to send a traffic instruction indicating the detection of a second data.

Claims

1. User equipment (UE), Transmitter and receiver, It is a circuit, During the procedure for transmitting the first data in an inactive state, it is detected that the second data will be transmitted in a connected state. Determine whether or not there is a transmission opportunity allocated by the base station for transmitting the first data. When it is determined that there is no opportunity to transmit the first data, a Random Access Channel (RACH) procedure is initiated to enter a connected state. When it is determined that the aforementioned transmission opportunity exists, the transceiver is controlled to use the transmission opportunity to transmit a traffic instruction indicating the detection of the second data. The aforementioned circuit, Equipped with, The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, When the transceiver receives the delay threshold, The aforementioned circuit, If the time until the next resource in the CG procedure is less than the delay threshold, it is determined that a transmission opportunity exists, and the transceiver is controlled to use the transmission opportunity to transmit the traffic instruction. If the time until the next resource in the CG procedure is greater than the delay threshold, it is determined that there is no transmission opportunity, and the RACH procedure is started to enter the connection state. User equipment (UE).

2. The aforementioned traffic instruction, - Using the resources indicated by the uplink grant, at least a portion of the first data and / or, - Buffer status report (BSR) indicating the amount of the first data, Sent together with, The UE according to claim 1.

3. The RACH procedure is either a 4-step RACH procedure or a 2-step RACH procedure. The UE according to claim 1.

4. If the transceiver does not receive the delay threshold, The aforementioned circuit, If the next resource in the CG procedure is earlier than the next RACH resource, it is determined that a transmission opportunity exists, and the transceiver is controlled to use the transmission opportunity to transmit the traffic instruction. If the next resource in the CG procedure is slower than the next RACH resource, it is determined that there is no transmission opportunity, and the RACH procedure is started to enter the connection state. The UE according to claim 1.

5. The aforementioned traffic instruction is signaled by a predefined value of the Logical Channel ID (LCID) in the MAC subheader. The predefined value of the LCID indicates that the second data has been detected. The UE according to claim 1.

6. The predefined value of the LCID indicates that the MAC control element CE is not attached to the MAC subheader. The UE according to claim 5.

7. The LCID indicates that the BSR MAC control element (CE) is attached to the MAC subheader. The BSR MAC CE indicates the amount of the first data to be transmitted further. The UE according to claim 5.

8. The aforementioned traffic instruction is part of the MAC control element (CE), - One bit of the MAC CE indicates whether the second data has been detected or not. - The two bits of the MAC CE indicate the first data logical channel group (LCG) among the LCGs that support data transmission in the inactive state. - The five bits of the MAC CE indicate the amount of the first data corresponding to the LCG shown above that will be transmitted further. The UE according to claim 1.

9. The traffic instruction is a Radio Resource Control (RRC) level instruction. The UE according to claim 1.

10. A method for user equipment (UE), wherein the method comprises the following steps, namely: - A step of detecting that a second data is transmitted in a connected state during the procedure for transmitting a first data in an inactive state, The steps include determining whether or not there is a transmission opportunity allocated by the base station for transmitting the first data, When it is determined that there is no opportunity to transmit the first data, the steps include: initiating a Random Access Channel (RACH) procedure to enter a connection state; When it is determined that there is an opportunity to transmit the first data, the step of using the transmission opportunity to transmit a traffic instruction indicating the detection of the second data, Includes, The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, When the UE receives the delay threshold, If the time until the next resource in the CG procedure is less than the delay threshold, it is determined that a transmission opportunity exists, and the traffic instruction is transmitted using the transmission opportunity. If the time until the next resource in the CG procedure is greater than the delay threshold, it is determined that there is no transmission opportunity, and the RACH procedure is started to enter the connection state. method.

11. An integrated circuit that controls a process of a user device (UE), wherein the process comprises the following steps, namely: The procedure for transmitting first data in an inactive state includes the step of detecting that second data is transmitted in a connected state, The steps include determining whether or not there is a transmission opportunity allocated by the base station for transmitting the first data, When it is determined that there is no opportunity to transmit the first data, the steps include: initiating a Random Access Channel (RACH) procedure to enter a connection state; When it is determined that there is an opportunity to transmit the first data, the step of using the transmission opportunity to transmit a traffic instruction indicating the detection of the second data, Includes, The procedure for transmitting the first data is a configured grant (CG) procedure for transmitting the first data, When the UE receives the delay threshold, If the time until the next resource in the CG procedure is less than the delay threshold, it is determined that a transmission opportunity exists, and the traffic instruction is transmitted using the transmission opportunity. If the time until the next resource in the CG procedure is greater than the delay threshold, it is determined that there is no transmission opportunity, and the RACH procedure is started to enter the connection state. Integrated circuit.

Images