Initiating small data transmissions based on one or more conditions specific to device type
By obtaining device-specific conditions in the equipment of the wireless communication system and launching a small data transmission program when these conditions are met, the problem of low efficiency in small data transmission management between different device types in the prior art is solved, and the reduction of signaling overhead and power consumption and the improvement of transmission efficiency is achieved.
Patent Information
- Application Number
- CN202510566349.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2021-09-02
- Filing Date
- 2022-08-17
- Publication Date
- 2025-06-20
AI Technical Summary
The prior art is difficult to effectively manage small data transmission between different device types in wireless communication systems, resulting in increased signaling overhead and power consumption.
By implementing a method in the device, one or more conditions specific to the device type are obtained and, when these conditions are met, a small data transmission program can be initiated even if the device is in a radio resource control inactive or idle state.
This method can reduce signaling overhead and power consumption while improving small data transmission efficiency between different device types, and is suitable for various wireless communication systems.
Smart Images

Figure CN120186722A_ABST
Abstract
Description
[0001] This application is a divisional application of a patent application for invention with international application number PCT / EP2022 / 072936, international filing date August 17, 2022, entering the Chinese national phase on February 27, 2024, Chinese national application number 202280058544.6, and invention title "Initiating small data transmission based on one or more conditions specific to a device type". Technical Field
[0002] The following exemplary embodiments relate to wireless communication. Background Art
[0003] Wireless communication systems are constantly evolving. For example, a device may transmit or receive a small amount of data in an inactive state to reduce signaling overhead from connection establishment and minimize power consumption. Summary of the Invention
[0004] The scope of protection sought by the various exemplary embodiments is set forth in the independent claims. Exemplary embodiments and features (if any) described in this specification that do not fall within the scope of the independent claims should be construed as examples useful for understanding the various exemplary embodiments.
[0005] According to one aspect, there is provided a device comprising at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the device to: obtain one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and initiate a small data transmission procedure when in a radio resource control inactive state or an idle state if the one or more first conditions are satisfied.
[0006] According to another aspect, there is provided a device comprising: means for obtaining one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and means for initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if one or more first conditions are satisfied.
[0007] According to another aspect, a method is provided, which includes: obtaining one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if the one or more first conditions are satisfied.
[0008] According to another aspect, a computer program including instructions is provided, the instructions being configured to cause a device to perform at least the following operations: obtaining one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if the one or more first conditions are satisfied.
[0009] According to another aspect, a computer program product including program instructions is provided, the program instructions, when run on a computing device, causing the computing device to perform at least the following operations: obtaining one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if the one or more first conditions are satisfied.
[0010] According to another aspect, a computer-readable medium including program instructions is provided, the program instructions being configured to cause a device to perform at least the following operations: obtaining one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if the one or more first conditions are satisfied.
[0011] According to another aspect, there is provided a non-transitory computer-readable medium including program instructions for causing a device to perform at least the following operations: obtaining one or more first conditions for small data transmission, the one or more first conditions being specific to a first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; and initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if the one or more first conditions are satisfied.
[0012] According to another aspect, there is provided a device including at least one processor and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, together with the at least one processor, cause the device to: transmit, at least to one or more first terminal devices of a first device type, an indication indicating one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0013] According to another aspect, there is provided a device including means for performing the following operations: transmitting, at least to one or more first terminal devices of a first device type, an indication indicating one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0014] According to another aspect, there is provided a method including: transmitting, at least to one or more first terminal devices of a first device type, an indication indicating one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0015] According to another aspect, there is provided a computer program comprising instructions for causing a device to perform at least the following operations: transmitting at least to one or more first terminal devices of a first device type an indication of one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0016] According to another aspect, there is provided a computer program product comprising program instructions which, when run on a computing device, cause the computing device to perform at least the following operations: transmitting at least to one or more first terminal devices of a first device type an indication of one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0017] According to another aspect, there is provided a computer-readable medium comprising program instructions for causing a device to perform at least the following operations: transmitting at least to one or more first terminal devices of a first device type an indication of one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0018] According to another aspect, there is provided a non-transitory computer-readable medium comprising program instructions for causing a device to perform at least the following operations: transmitting at least to one or more first terminal devices of a first device type an indication of one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type.
[0019] According to another aspect, a system is provided that includes at least a terminal device of a first device type and a network element of a wireless communication network. The network element is configured to: transmit, at least to the terminal device of the first device type, an indication of one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type. The terminal device of the first device type is configured to: receive the indication from the network element; and initiate a small data transmission procedure when in a radio resource control inactive state or an idle state if one or more first conditions are met.
[0020] According to another aspect, a system is provided that includes at least a terminal device of a first device type and a network element of a wireless communication network. The network element includes means for: transmitting, at least to the terminal device of the first device type, an indication of one or more first conditions for small data transmission, wherein the first indication is specific to the first device type, and wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type. The terminal device of the first device type includes means for: receiving the indication from the network element; and initiating a small data transmission procedure when in a radio resource control inactive state or an idle state if one or more first conditions are met. BRIEF DESCRIPTION OF THE DRAWINGS
[0021] Hereinafter, various exemplary embodiments will be described in more detail with reference to the accompanying drawings, in which
[0022] the drawings
[0023] Figure 1 show exemplary embodiments of a cellular communication network;
[0024] Figures 2 to 3 show a signaling diagram according to some exemplary embodiments;
[0025] Figures 4 to 7 show a flowchart according to some exemplary embodiments;
[0026] Figures 8 to 9 show a device according to some exemplary embodiments. DETAILED DESCRIPTION
[0027] The following implementation examples are exemplary. Although this specification may refer to "one", "a", or "some" implementation examples at several places in the text, this does not necessarily mean that each reference is to the same implementation example, or that a particular feature applies only to a single implementation example. Individual features of different implementation examples can also be combined to provide other implementation examples.
[0028] Hereinafter, a radio access architecture based on Long Term Evolution - Advanced (LTE - A) or New Radio (NR, 5G) will be used as an example of an access architecture to which exemplary implementation examples can be applied to describe different exemplary implementation examples. However, the exemplary implementation examples are not limited to such an architecture. It will be obvious to those skilled in the art that, by appropriately adjusting parameters and procedures, the exemplary implementation examples can also be applied to other types of communication networks with suitable devices. Some examples of other options for suitable systems may be Universal Mobile Telecommunications System (UMTS) radio access network (UTRAN or E - UTRAN), Long Term Evolution (LTE, substantially the same as E - UTRA), Wireless Local Area Network (WLAN or Wi - Fi), Worldwide Interoperability for Microwave Access (WiMAX), Personal Communication Service (PCS), Wideband Code Division Multiple Access (WCDMA), systems using Ultra - Wideband (UWB) technology, sensor networks, Mobile Ad - Hoc Networks (MANET), and Internet Protocol Multimedia Subsystem (IMS), or any combination thereof.
[0029] Figure 1 An example of a simplified system architecture is depicted, which shows some elements and functional entities, all of which are logical units and their implementation may be different from that shown. Figure 1 The connections shown in are logical connections; the actual physical connections may be different. It will be obvious to those skilled in the art that the system may also include other functions and structures in addition to Figure 1 the functions and structures shown in.
[0030] However, the exemplary implementation examples are not limited to the system given as an example, but those skilled in the art can apply the solution to other communication systems with the necessary attributes.
[0031] Figure 1 The example of shows a part of an exemplary radio access network.
[0032] Figure 1User devices 100 and 102 are shown, which are configured to wirelessly connect to an access node (such as an (e / g)NodeB) 104 that provides the cell on one or more communication channels in the cell. The physical link from the user device to the (e / g)NodeB may be referred to as the uplink or reverse link, and the physical link from the (e / g)NodeB to the user device may be referred to as the downlink or forward link. It should be understood that the (e / g)NodeB or its functionality may be implemented by any entity such as a node, host, server, or access point suitable for this purpose.
[0033] The communication system may include more than one (e / g)NodeB. In this case, the (e / g)NodeB may also be configured to communicate with each other via wired or wireless links designed for this purpose. These links may be used for signaling purposes. The (e / g)NodeB may be a computing device configured to control the radio resources of the communication system to which it is coupled. The (e / g)NodeB may also be referred to as a base station, access point, or any other type of interface device including a relay station capable of operating in a wireless environment. The (e / g)NodeB may include or be coupled to a transceiver. A connection may be provided from the transceiver of the (e / g)NodeB to an antenna unit, which establishes a two-way radio link to the user device. The antenna unit may include multiple antennas or antenna elements. The (e / g)NodeB may also be connected to the core network 110 (CN or Next Generation Core NGC). Depending on the system, the corresponding part on the CN side may be: a Serving Gateway (S-GW, routing and forwarding user data packets); a Packet Data Network Gateway (P-GW) for providing connectivity between the user device (UE) and an external packet data network; or a Mobility Management Entity (MME), etc.
[0034] The user device (also referred to as UE, user equipment, user terminal, terminal device, etc.) shows a type of device to which resources on the air interface can be allocated and assigned, and thus any feature described herein regarding the user device may be implemented by a corresponding device such as a relay node. An example of such a relay node may be a layer 3 relay (self-backhaul relay) towards the base station. The self-backhaul relay node may also be referred to as an Integrated Access and Backhaul (IAB) node. The IAB node may include two logical parts: a Mobile Terminal (MT) part, which is responsible for the backhaul link (i.e., the link between the IAB node and the donor node (also referred to as the parent node)); and a Distributed Unit (DU) part, which is responsible for the access link, i.e., the sub-links between the IAB node and the UE and / or between the IAB node and other IAB nodes (multi-hop scenario).
[0035] A user device may refer to a portable computing device including a wireless mobile communication device operating with or without a subscriber identity module (SIM), including but not limited to the following types of devices: mobile station (mobile phone), smart phone, personal digital assistant (PDA), cellular phone, device using a wireless modem (such as an alarm or measurement device, etc.), laptop computer and / or touch screen computer, tablet computer, gaming device, notebook computer, and multimedia device. It should be understood that the user device may also be an almost exclusive uplink-only device, examples of which may be a camera or video camera that loads images or video clips onto a network. The user device may also be a device capable of operating in an Internet of Things (IoT) network, in which scenario objects may be provided with the ability to transmit data over the network without the need for human-to-human or human-to-computer interaction. The user device may also utilize the cloud. In some applications, the user device may include a small portable device with radio components (such as a watch, headphones, or glasses) and may perform computing in the cloud. The user device (or in some exemplary embodiments, a layer 3 relay node) may be configured to perform one or more of the user equipment functions. The user device may also be referred to as a subscriber unit, mobile station, remote terminal, access terminal, user terminal, terminal device, or user equipment (UE), to mention just a few names or devices.
[0036] The various techniques described herein may also be applied to cyber-physical systems (CPS) (systems of collaborative computing elements that control physical entities). CPS may support the implementation and utilization of a large number of interconnected ICT devices (sensors, actuators, processor microcontrollers, etc.) embedded in physical objects at different locations. Mobile cyber-physical systems are a subcategory of cyber-physical systems, where the physical systems under discussion may have inherent mobility. Examples of mobile physical systems include mobile robots and electronics transported by humans or animals.
[0037] Additionally, although the device has been described as a single entity, different units, processors, and / or memory units may be implemented ( Figure 1 not all shown in
[0038] 5G supports the use of multiple-input multiple-output (MIMO) antennas, more base stations or nodes than LTE (the so-called small cell concept), including macro sites that operate in cooperation with smaller base stations and employ multiple radio technologies depending on service requirements, use cases, and / or available spectrum. 5G mobile communications can support a wide range of use cases and related applications, including video streaming, augmented reality, different ways of data sharing, and various forms of machine-type applications, such as (massive) machine-type communications (mMTC), including vehicle safety, different sensors, and real-time control. 5G is expected to have multiple radio interfaces, namely sub-6 GHz, cmWave, and mmWave, and can also be integrated with existing traditional radio access technologies, such as LTE. At least in the early stages, the integration with LTE can be implemented as a system where macro coverage can be provided by LTE, and 5G radio interface access can come from small cells by aggregating to LTE. In other words, 5G can support inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as sub-6 GHz - cmWave, sub-6 GHz - cmWave - mmWave). One possible concept considered in 5G networks is network slicing, where multiple independent and dedicated virtual sub-networks (network instances) can be created within essentially the same infrastructure to run services with different requirements for latency, reliability, throughput, and mobility.
[0039] The current architecture in LTE networks can be either fully distributed in the radio and fully centralized in the core network. Low-latency applications and services in 5G may require content to be close to the radio, which leads to local offloading and multi-access edge computing (MEC). 5G can support analysis and knowledge generation at the data source. This approach may require leveraging resources that may not be continuously connected to the network, such as laptops, smartphones, tablets, and sensors. MEC can provide a distributed computing environment for application and service hosting. It can also store and process content close to cellular subscribers to achieve faster response times. Edge computing can cover a wide range of technologies, such as wireless sensor networks, mobile data collection, mobile signature analysis, collaborative distributed peer-to-peer ad-hoc networking and processing, and can also be classified as local cloud / fog computing and grid / mesh computing, dew computing, mobile edge computing, micro-clouds, distributed data storage and retrieval, self-healing autonomous networks, remote cloud services, augmented reality and virtual reality, data caching, Internet of Things (massive connectivity and / or latency-critical), critical communications (autonomous vehicles, traffic safety, real-time analytics, time-critical control, healthcare applications).
[0040] The communication system may also be able to communicate with other networks such as the public switched telephone network or the Internet 112, or utilize the services they provide. The communication network may also be able to support the use of cloud services, for example, at least a part of the core network operation may be implemented as a cloud service (which is shown by the "cloud" 114 in Figure 1 . The communication system may also include a central control entity, etc., so as to provide facilities for the networks of different operators to cooperate, for example, in terms of spectrum sharing.
[0041] An edge cloud can be introduced into the radio access network (RAN) by leveraging network function virtualization (NFV) and software-defined networking (SDN). Using the edge cloud may mean that the access node operation is at least partially implemented in a server, host, or node that is operationally coupled to a remote radio head (RRH) or radio unit (RU) or a base station including radio components. The node operation may also be distributed among multiple servers, nodes, or hosts. For example, the RAN real-time function can be implemented on the RAN side (in the distributed unit (DU) 104) and the non-real-time function can be implemented in a centralized manner (in the central unit (CU) 108) by applying the cloudRAN architecture.
[0042] It should also be understood that the labor distribution between the core network operation and the base station operation may be different from that of LTE or even non-existent. Some other technological advancements that can be used may be big data and all-IP, which may change the way of building and managing the network. The 5G (or new radio, NR) network can be designed to support multiple hierarchies, where the MEC server can be placed between the core and the base station or nodeB (gNB). It should be understood that MEC can also be applied to the 4G network.
[0043] 5G can also utilize satellite communication to enhance or supplement the coverage of 5G services, for example, by providing backhaul. Possible use cases may be to provide service continuity for machine-to-machine (M2M) or Internet of Things (IoT) devices or in-vehicle passengers, or to ensure the service availability of critical communications and future railway / sea / air communications. Satellite communication can utilize the geostationary orbit (GEO) satellite system or the low Earth orbit (LEO) satellite system, especially the mega-constellation (a system with hundreds of (nano) satellites deployed). At least one satellite 106 in the mega-constellation can cover several network entities that support the creation of ground cells. The ground cell can be created by a ground relay node 104 or by a gNB located on the ground or in a satellite.
[0044] It will be apparent to those skilled in the art that the described system is only an example of a part of a radio access system, and in practice, the system may include multiple (e / g)NodeBs, user equipment may access multiple radio cells, and the system may also include other devices, such as physical layer relay nodes or other network elements, etc. At least one of the (e / g)NodeBs may be a Home (e / g)nodeB.
[0045] In addition, the (e / g)nodeB or base station may also be divided into: a radio unit (RU), which includes a radio transceiver (TRX), i.e., a transmitter (TX) and a receiver (RX); one or more distributed units (DUs), which may be used for so-called layer 1 (L1) processing and real-time layer 2 (L2) processing; and a central unit (CU) or centralized unit, which may be used for non-real-time L2 and layer 3 (L3) processing. The CU may be connected to one or more DUs, for example, by using the F1 interface. Such a split can achieve the centralization of the CU relative to the cell site and the DU, while the DU may be more decentralized and may even remain at the cell site. The CU and DU may also be collectively referred to as the baseband or baseband unit (BBU). The CU and DU may also be included in a radio access point (RAP).
[0046] The CU may be defined as a logical node that hosts the higher layer protocols of the (e / g)nodeB or base station, such as radio resource control (RRC), service data adaptation protocol (SDAP), and / or packet data convergence protocol (PDCP). The DU may be defined as a logical node that hosts the radio link control (RLC), media access control (MAC), and / or physical (PHY) layer of the (e / g)nodeB or base station. The operation of the DU may be at least partially controlled by the CU. The CU may include a control plane (CU-CP), which may be defined as a logical node that hosts the control plane part of the RRC for the (e / g)nodeB or base station and the PDCP protocol of the CU. The CU may also include a user plane (CU-UP), which may be defined as a logical node that hosts the user plane part of the PDCP protocol and the SDAP protocol of the CU for the (e / g)nodeB or base station.
[0047] A cloud computing platform may also be used to run the CU and / or DU. The CU may run in a cloud computing platform, which may be referred to as a virtualized CU (vCU). In addition to the vCU, there may also be a running virtualized DU (vDU) in the cloud computing platform. In addition, there may also be a combination where the DU may use a so-called bare metal solution, such as an application-specific integrated circuit (ASIC) or a customer-specific standard product (CSSP) system-on-chip (SoC) solution. It should also be understood that the labor distribution between the above-mentioned base station units or between different core network operations and base station operations may be different.
[0048] In addition, in a geographical area of a radio communication system, multiple different types of radio cells as well as multiple radio cells can be provided. A radio cell can be a macro cell (or umbrella cell), which can be a large cell with a diameter of up to dozens of kilometers, or smaller cells such as micro cells, femto cells or pico cells. Figure 1 The (e / g)NodeB can provide any of these types of cells. A cellular radio system can be implemented as a multi-layer network including several types of cells. In a multi-layer network, an access node can provide one or more types of cells, and thus multiple (e / g)NodeBs may be required to provide such a network structure.
[0049] To meet the need for improving the deployment and performance of a communication system, the concept of a "plug-and-play" (e / g)NodeB can be introduced. Networks that may be able to use a "plug-and-play" (e / g)NodeB can include, in addition to a home (e / g)NodeB (H(e / g)nodeB), a home node B gateway or HNB-GW ( Figure 1 not shown in the figure). The HNB gateway (HNB-GW) that can be installed in an operator's network can aggregate traffic from a large number of HNBs back to the core network.
[0050] A number of devices (such as sensors, actuators and similar devices for (massive) machine type communication, or smart phones with chat applications) that are expected to generate (transmit) small amounts of data frequently or infrequently will grow exponentially. (It should be understood that the above list is a non-limiting list of examples of devices that can transmit small amounts of data.) To reduce the signaling overhead from connection establishment and minimize power consumption, in 5G and later versions, devices can be supported to use a process called small data transfer (SDT) procedure (small data transmission procedure) to transmit small amounts of data in an inactive state. If specific criteria are met, for example, if the amount of uplink data to be transmitted is less than a data volume threshold, a device in an inactive state can initiate the small data transfer procedure. The data volume can also be referred to as data size or data quantity. In other words, using 5G terminology, SDT is a procedure that allows data transmission while remaining in the RRC_INACTIVE state (i.e., without transitioning to the RRC_CONNECTED state). Therefore, the SDT procedure can avoid the signaling overhead and latency associated with transitioning from the RRC_INACTIVE state to the RRC_CONNECTED state. If the uplink (UL) data waiting to be transmitted on a radio bearer enabled for SDT is less than the configured amount, the measured reference signal received power (RSRP) in the cell is higher than the configured threshold, and effective resources for SDT transmission are available, then SDT can be enabled and initiated by the UE on a per-radio-bearer basis.
[0051] RRC_INACTIVE is the state in which the UE remains in the CM-CONNECTED state and can move within the area configured by the RAN without notifying the RAN. CM is the abbreviation of Connection Management. In the RRC_INACTIVE state, the last serving gNB maintains the UE context as well as the connections associated with the UE to the serving access and mobility management function (AMF) and the user plane function (UPF). The RRC_INACTIVE state can be used to reduce the UE power consumption by reducing the control plane (CP) procedures and associated latency required when the RRC state changes. When the UE is in the RRC_INACTIVE state, the radio connection is suspended while the core network connectivity remains active (i.e., the UE remains in the CM-CONNECTED state). Both the UE and the RAN store the UE access stratum (AS) context (referred to as the UE inactive AS context) for a quick recovery of the suspended connection, including the latest radio bearer configuration for data / signaling transmission, and the security keys and algorithms for integrity protection and encryption of the radio interface. Compared with a UE in the RRC_IDLE state that needs to establish new connections to the radio network and the core network, based on this retained information, the UE can resume the radio connection with much lower latency and associated signaling overhead.
[0052] The SDT procedure can occur on a random access channel (RACH) resource or a type 1 configured grant (CG) resource. For CG, the SDT resources can be configured on the initial bandwidth part (BWP) or a dedicated BWP. For RACH, the network can also configure whether two-step and four-step random access types can be used. If both random access types can be used, the UE can select one of the two random access types.
[0053] Once initiated, the SDT procedure can continue as long as the UE is not explicitly directed to the RRC_IDLE or RRC_INACTIVE state (via RRCRelease) or the RRC_CONNECTED state (via RRCResume). After the initial SDT transmission, subsequent transmissions can be handled differently depending on the configured resource type. When using CG resources, the network can use dynamic grants to schedule subsequent UL transmissions, or they can occur at the next CG resource occasion. When using RACH resources, the network can use dynamic grants and assignments to schedule subsequent UL and downlink (DL) transmissions respectively after the random access procedure is completed.
[0054] A UE can execute a random access procedure to access the network. The purpose of executing the random access procedure may be, for example, initial access, handover, scheduling request, or timing synchronization. The random access procedure may be a contention-based random access procedure (CBRA) or a contention-free random access procedure (CFRA). CFRA can also be referred to as non-contention-based random access. In CFRA, a given UE has a dedicated (i.e., UE-specific) random access preamble assigned by the network, while in CBRA, the UE can randomly select a preamble from a preamble pool shared with other UEs in the cell. Currently, SDT on the RACH does not support CFRA. In CBRA, if two or more UEs attempt the random access procedure by using the same random access procedure on the same resource, contention (or collision) may occur.
[0055] To avoid contention in CBRA, the RACH preambles can be divided into two groups: Group A and Group B. Once the UE has selected the group to use, the UE can select a preamble from the selected group to transmit to the network. When the amount of uplink data to be transmitted is small and / or when the UE is in poor coverage (e.g., low RSRP), Group A can be used to request normal UL resources. When the amount of uplink data to be transmitted in Msg3 is large and the UE is in good coverage (e.g., high RSRP), Group B can be used to request larger resources.
[0056] 5G aims to address a wide range of use cases with different requirements in terms of data rate, latency, reliability, coverage, energy efficiency, and connection density, such as enhanced mobile broadband (eMBB), ultra-reliable low-latency communication (URLLC), and massive machine type communication (mMTC). mMTC can cover cellular low-power wide-area (LPWA) technologies, such as narrowband Internet of Things (NB-IoT) and long-term evolution for machine type communication (LTE-MTC). Another use case of 5G is time-sensitive communication (TSC). However, between these use cases, there are also some other mid-range use cases, such as industrial wireless sensor networks, video surveillance, and wearable devices (e.g., smart watches, rings, e-health related devices, personal protective equipment, medical monitoring devices, etc.). In other words, the requirements of these mid-range use cases may be higher than LPWA but lower than eMBB and URLLC. To effectively serve these mid-range use cases, the 3rd Generation Partnership Project (3GPP) introduced reduced-capability (RedCap) devices in NR Release 17 (Rel-17). RedCap devices can also be referred to as RedCap UEs, NR-Lite devices, or NR-Light devices.
[0057] Compared with high-end NR UEs (such as eMBB devices and URLLC devices), RedCap devices can have lower complexity (e.g., reduced bandwidth and number of antennas), longer battery life, and smaller form factors. For example, a RedCap device can include 1 receiver branch and 1 transmitter branch (1Rx / 1Tx), or 2 receiver branches and 1 transmitter branch (2Rx / 1Tx) in both frequency range 1 (FR1) and frequency range 2 (FR2). RedCap devices can support all FR1 and FR2 frequency bands for both frequency division duplexing (FDD) and time division duplexing (TDD).
[0058] Industrial wireless sensors and actuators are an example of RedCap devices. It may be desirable to connect these sensors and actuators to the 5G radio access and core network to improve flexibility, enhance productivity and efficiency, and improve operational safety. Industrial wireless sensors can include, for example, pressure sensors, humidity sensors, thermometers, motion sensors, and / or accelerometers, etc. Industrial wireless sensor network use cases include not only very demanding URLLC services but also relatively low-end services with small device form factor requirements and / or fully wireless and battery life up to several years. These low-end services can be provided by RedCap devices. Industrial wireless sensors associated with low-end services may also have the following use case-specific requirements: the communication service availability can be 99.99%, the end-to-end latency can be less than 100 ms; and for all use cases, the reference bit rate can be less than 2 Mbps (possibly asymmetric, e.g., UL heavy traffic), and the device is stationary. For security-related sensors, the latency requirement may be lower, e.g., 5 ms to 10 ms.
[0059] Video surveillance cameras are another example of RedCap devices. For example, the deployment of surveillance cameras may benefit smart city use cases as well as factories and industries to more effectively monitor and control urban / factory resources. Similar to connected industries, 5G connectivity can act as a catalyst for the next wave of smart city innovation. The following requirements may apply to video surveillance use cases: the reference economic video bit rate can be 2 Mbps to 4 Mbps, the latency is less than 500 ms, and the reliability is 99% to 99.9%. High-end video (e.g., for agriculture) may require a video bit rate of 7.5 Mbps to 25 Mbps. It should be noted that the traffic pattern may be dominated by UL transmissions.
[0060] Wearable devices, such as smart watches, rings, electronic health-related devices, personal protective equipment, and / or medical monitoring devices, are another example of RedCap devices. One characteristic of this use case is the small size of the device. The following requirements may apply to wearable devices: The reference bit rate for smart wearable applications can be 5 Mbps to 50 Mbps in DL and 2 Mbps to 5 Mbps in UL, and the peak bit rate of the device can be higher, up to 150 Mbps for the downlink and up to 50 Mbps for the uplink. Additionally, the battery of the wearable device should last for multiple days (e.g., up to 1 to 2 weeks).
[0061] During initial access and thereafter, the maximum bandwidth of FR1 RedCap devices can be 20 MHz. During initial access and thereafter, the maximum bandwidth of FR2 RedCap devices can be 100 MHz.
[0062] For frequency bands where traditional NR UEs need to be equipped with at least 2 Rx antenna ports, the minimum number of Rx branches supported by RedCap devices can be 1. This specification also supports RedCap devices having 2 Rx branches in these frequency bands. Rx is the abbreviation for receiver.
[0063] For frequency bands where traditional NR UEs (instead of 2-Rx vehicle UEs) need to be equipped with at least 4 Rx antenna ports, the minimum number of Rx branches supported by RedCap devices can be 1. This specification also supports RedCap devices having 2 Rx branches in these frequency bands.
[0064] For RedCap devices with 1 Rx branch, 1 DL MIMO layer can be supported. For RedCap devices with 2 Rx branches, 2 DL MIMO layers can be supported. The gNB can know the number of Rx branches of the UE. For FR1 RedCap devices, supporting 256QAM (Quadrature Amplitude Modulation) in DL can be optional (instead of mandatory).
[0065] RedCap devices can be prevented from using capabilities such as carrier aggregation, dual connectivity, and wider bandwidth.
[0066] During the random access procedure, RedCap devices can be explicitly identified by the network through early indications in Message 1 (Msg1, i.e., RACH preamble) and / or Message 3 (Msg3) and Message A (MsgA) (if supported), including capabilities that can be configured by the network. Msg1 and Msg3 can be used in a 4-step random access procedure, while MsgA can be used in a 2-step random access procedure. In a two-step random access procedure, Msg1 and Msg3 can be combined into a single message (i.e., MsgA).
[0067] System information indication can be used to indicate whether a RedCap device can pre-empt a cell / frequency. This indication can be specific to the number of Rx branches of the RedCap device.
[0068] RedCap devices can support extended discontinuous reception (eDRX) in the RRC_INACTIVE and RRC_IDLE states, where the eDRX period is up to 10.24 s without using a paging time window (PTW) and a paging hyperframe (PH). There can be a common design between RRC_INACTIVE and RRC_IDLE (e.g., a common set of eDRX values). Some RedCap devices can support eDRX in the RRC_INACTIVE state and the RRC_IDLE state, where the eDRX period is up to 10485.76 s. SDT can be used at least with an eDRX period less than or equal to 10.24 s.
[0069] For RRC_INACTIVE / RRC_IDLE and / or RRC_CONNECTED, there can be radio resource management (RRM) relaxations for the neighboring cells of a RedCap device. The enabling and disabling of RRM relaxations can be under the control of the network and signaled via broadcast or dedicated signaling.
[0070] It should be noted that RedCap devices can coexist with non-RedCap UEs (i.e., both RedCap devices and non-RedCap UEs can be present in a given cell).
[0071] However, the limited capabilities of RedCap devices (e.g., reduced number of antennas, reduced bandwidth support, etc.) are not currently considered in the SDT procedure, and thus the SDT procedure is not currently optimal for RedCap devices. For example, a RedCap device with a reduced number of antennas may not be able to transmit and / or receive at the power required for a successful SDT session, which may cause continuous failures and interference to other devices performing SDT. Therefore, there is a need to improve the SDT procedure for RedCap devices.
[0072] Some exemplary embodiments can enhance SDT resource selection and / or SDT grant determination for devices such as RedCap devices. In some exemplary embodiments, the SDT grant determination and resource selection criteria for RedCap devices can be adjusted by considering the limited capabilities of the RedCap devices.
[0073] Figure 2 A signaling diagram according to an exemplary embodiment is shown, where the network explicitly indicates the conditions under which a RedCap device should adjust SDT. Refer to Figure 2, a network element of a wireless communication network transmits an indication 201 for adjusting one or more conditions for SDT to one or more UEs, where the indication is specific to RedCap devices (i.e., non-RedCap UEs can ignore the indication). The one or more UEs may include at least one RedCap device. The network element may be a base station, such as a gNB.
[0074] The indication 201 may include at least one threshold and / or a rule for adjusting one or more conditions. The rule and the at least one threshold may be specific to RedCap devices (i.e., non-RedCap UEs cannot use them). Alternatively or additionally, the indication 201 may at least include an offset value for adjusting at least one of the one or more conditions.
[0075] The at least one threshold may include at least one of the following: an uplink data volume threshold for adjusting the uplink data volume condition for SDT permission, an RSRP threshold for adjusting the RSRP condition for SDT permission, and / or a data volume threshold for a RACH preamble group (A or B) for resource selection, where these thresholds may be specific to RedCap devices.
[0076] The indication 201 may be transmitted to at least one RedCap device by using dedicated signaling (i.e., by transmitting a device-specific indication to at least one RedCap device).
[0077] Alternatively, the indication 201 may be broadcast, for example, via system information block (SIB) signaling to a plurality of UEs (e.g., all UEs in a cell) including at least one RedCap device and at least one non-RedCap UE. The broadcast may cause a subset of the plurality of UEs to adjust one or more conditions for SDT. For example, the subset of the plurality of UEs may include at least one RedCap device, but non-RedCap UEs may not be included in the subset. In other words, the indication (including, for example, at least one threshold) may be broadcast to both RedCap devices and non-RedCap UEs, but only RedCap devices may use the indication to adjust one or more conditions. Therefore, only a specific type of device (e.g., a RedCap device) may be capable of performing the adjustment of SDT conditions.
[0078] At least one RedCap device adjusts 202 one or more conditions at least partially based on the rule, the at least one threshold, and / or the offset value received in the indication from the network element.
[0079] If at least one RedCap device determines 203 that the adjusted one or more conditions are satisfied, at least one RedCap device initiates 204 an SDT procedure and transmits a small data transfer to the network element.
[0080] The adjusted one or more conditions may also be referred to as one or more first conditions, and the original (unadjusted) one or more conditions may be referred to as one or more second conditions. In other words, one or more first conditions may be obtained by adjusting one or more second conditions.
[0081] It should be noted that some exemplary embodiments are not limited to RedCap devices, and one or more conditions for SDT may also be adjusted by other types of devices / UEs.
[0082] Figure 3 A signaling diagram according to another exemplary embodiment is shown, in which the network signals different sets of conditions for SDT to different types of UEs. Refer to Figure 3 , a network element of a wireless communication network transmits 301 a first indication indicating one or more first conditions for SDT to one or more first UEs (denoted as UE1). The network element transmits 302 a second indication indicating one or more second conditions for SDT to one or more second UEs (denoted as UE2).
[0083] One or more first conditions are specific to a first device type including one or more first UEs. The one or more second conditions are associated with or specific to a second device type including one or more second UEs. One or more first conditions and one or more second conditions are at least partially different. For example, one or more first conditions may include a first uplink data volume threshold and / or a first RSRP threshold for SDT permission, and one or more second conditions may include a second uplink data volume threshold and / or a second RSRP threshold for SDT permission, where the value of the second uplink data volume threshold and / or the value of the second RSRP threshold may be different from the value of the first uplink data volume threshold and / or the value of the first RSRP threshold, respectively.
[0084] The first device type is different from the second device type. For example, the first device type may include or refer to a RedCap device, in which case one or more first UEs may be RedCap devices. The second device type may include or refer to non-RedCap UEs, in which case one or more second UEs may be non-RedCap UEs. The network element may be a base station, such as a gNB.
[0085] As another example, the first device type may refer to a 1Rx RedCap device, in which case one or more first UEs may be 1Rx RedCap devices. In this case, the second device type may include or refer to 2Rx RedCap devices and / or non-RedCap UEs, in which case one or more second UEs may include 2Rx RedCap devices and / or non-RedCap UEs. A 1Rx RedCap device refers to a RedCap device that includes a single receiver. A 2Rx RedCap device refers to a RedCap device that includes two receivers.
[0086] If one or more first conditions are met at one or more first UEs, then the one or more first UEs initiate a 303 SDT procedure and transmit a first small data transfer to a network element. If one or more second conditions are met at one or more second UEs, then the one or more second UEs initiate a 304 SDT procedure and transmit a second small data transfer to a network element.
[0087] It should be noted that some exemplary embodiments are not limited to RedCap devices, and the first device type may also be some other device type other than RedCap devices.
[0088] Figure 4 A flowchart according to an exemplary embodiment is shown. Figure 4 The functions shown in may be performed by a network element such as a base station or a device included in a network element. Refer to Figure 4 , at least a first indication indicating one or more first conditions for SDT is transmitted to one or more first UEs of the first device type, where the first indication is specific to the first device type. The one or more first conditions are different from one or more second conditions for small data transfer, and the one or more second conditions are associated with a second device type different from the first device type.
[0089] The first device type may refer to, for example, a RedCap device, and one or more first UEs may include one or more RedCap devices. The second device type may refer to, for example, a non-RedCap UE.
[0090] As another example, the first device type may refer to a 1Rx RedCap device, in which case one or more first UEs may be 1Rx RedCap devices. In this case, the second device type may include or refer to 2Rx RedCap devices and / or non-RedCap UEs, in which case one or more second UEs may include 2Rx RedCap devices and / or non-RedCap UEs.
[0091] The indication 401 may include at least one threshold specific to the first device type. The at least one threshold may include at least one of the following: an uplink data volume threshold, an RSRP threshold, and / or a RACH preamble group data volume threshold. Alternatively or additionally, the indication 401 may at least include an offset value for adjusting at least one of one or more second conditions.
[0092] The indication 401 may be broadcast to a plurality of UEs, the plurality of UEs including at least one or more first UEs and one or more second UEs of a second device type. The broadcast may cause one or more first UEs to obtain one or more first conditions by adjusting one or more second conditions based on the indication, such as by applying the indicated at least one threshold and / or offset value to one or more second conditions. Alternatively, the indication 401 may be transmitted to one or more first UEs using dedicated signaling.
[0093] Figure 5 A flowchart for determining SDT permission according to an exemplary embodiment is shown. Figure 5 The functions shown may be performed by a terminal device (UE) (e.g., a RedCap device) or a device included in the terminal device. Refer to Figure 5 , obtain 501 one or more first conditions for SDT, the one or more first conditions being specific to the first device type. The one or more first conditions are different from one or more second conditions for SDT, the one or more second conditions being associated with a second device type different from the first device type. For example, the one or more first conditions may include a condition of uplink data volume and / or a condition of RSRP.
[0094] The first device type may refer to, for example, a RedCap device, and the one or more first UEs may include one or more RedCap devices. The second device type may refer to, for example, a non-RedCap UE.
[0095] As another example, the first device type may refer to a 1Rx RedCap device, in which case the one or more first UEs may be 1Rx RedCap devices. In this case, the second device type may include or refer to 2Rx RedCap devices and / or non-RedCap UEs, in which case the one or more second UEs may include 2Rx RedCap devices and / or non-RedCap UEs.
[0096] One or more first conditions may be obtained at least in part based on at least one of the following: the bandwidth available at the device (the bandwidth supported by the device), the number of antennas included in the device, the number of receivers included in the device, and / or the battery life of the device, thus taking into account the limitations of a first device type (e.g., a RedCap device) compared to a second device type (e.g., a non-RedCap device).
[0097] One or more first conditions and / or one or more second conditions may be obtained, for example, from a predefined 3GPP specification. In other words, one or more first conditions and / or one or more second conditions may be predefined.
[0098] Alternatively, one or more first conditions and / or one or more second conditions may be obtained by receiving one or more first conditions and / or one or more second conditions from the network (e.g., via broadcast or dedicated signaling from the network).
[0099] Alternatively, one or more first conditions may be obtained by adjusting the currently configured values of one or more second conditions (e.g., by dividing, multiplying, adding, or subtracting). In this case, one or more second conditions may refer to, for example, default or existing conditions configured for all UEs in the cell via a predefined 3GPP specification or via broadcast from the network. Thus, the adjustment makes one or more first conditions different from one or more second conditions. The rules for adjusting one or more second conditions may be predefined (e.g., statically specified in a 3GPP specification), or they may be indicated from the network.
[0100] The condition of the uplink data volume (included in one or more first conditions) may be associated with the uplink data volume threshold for allowing the initiation of the SDT procedure. The condition of the uplink data volume (in one or more first conditions) may be obtained by adjusting the uplink data volume threshold associated with one or more second conditions. For example, the uplink data volume threshold may be adjusted by decreasing the uplink data volume threshold. In other words, since there are limitations in non-RedCap UE devices (e.g., antenna and bandwidth limitations) compared to non-RedCap UEs, the uplink data volume threshold may be scaled down such that the first device type (e.g., a RedCap device) allows less data compared to the second device type (e.g., a non-RedCap UE). The rules and / or values for adjusting the uplink data volume threshold may be predefined (e.g., statically specified in a 3GPP specification), or they may be indicated from the network.
[0101] The condition(s) of RSRP (including in one or more first conditions) may be associated with the RSRP threshold for allowing the initiation of the SDT procedure. The condition(s) for RSRP (in one or more first conditions) can be obtained by adjusting the RSRP threshold associated with one or more second conditions. For example, the RSRP threshold can be adjusted by increasing the RSRP threshold such that the RSRP threshold for the first device type (e.g., RedCap device) is higher than that for the second device type (e.g., non-RedCap UE) to allow the initiation of the SDT procedure. The rules and / or values for adjusting the RSRP threshold may be predefined (e.g., statically specified in the 3GPP specification), or they can be indicated from the network.
[0102] If one or more first conditions are met, the 502 small data transfer procedure is initiated when in the Radio Resource Control Inactive state (RRC_INACTIVE) or the Radio Resource Control Idle state (RRC_IDLE).
[0103] If the uplink data volume value of the small data transfer procedure (i.e., the data volume to be transmitted by SDT) is lower than or equal to the adjusted uplink data volume threshold, the condition of the uplink data volume (including in one or more first conditions) can be met. On the other hand, if the uplink data volume value is higher than the (adjusted) uplink data volume threshold, the RedCap device may not be allowed to perform SDT.
[0104] If the RSRP value measured by the device is higher than or equal to the adjusted RSRP threshold, the condition of RSRP (including in one or more first conditions) can be met. On the other hand, if the measured RSRP value is lower than the adjusted RSRP threshold, the RedCap device may not be allowed to perform SDT. The RSRP value can be measured on the reference signal received from the network (e.g., base station) before initiating the SDT procedure.
[0105] In some exemplary embodiments, different adjustments may be accomplished by 1Rx RedCap devices and 2Rx RedCap devices. For example, only 1Rx RedCap devices may perform adjustments to one or more conditions for SDT, and 2Rx RedCap devices may utilize configurations for non-RedCap devices. For example, if the network has measured a configuration such that it is suitable for 2Rx RedCap devices, in this case, 1Rx RedCap devices may need to adjust one or more conditions for SDT. Thus, the characteristics of different devices (such as the number of receivers) may be utilized when configuring and determining the conditions for SDT. In other words, the conditions for SDT may be different for different device types. As previously mentioned, one way to obtain the SDT conditions for a specific device type is to adjust the SDT conditions for different device types. To give just a few examples, the adjustment may be performed according to one or more predefined criteria or according to a configuration received from the network.
[0106] Figure 6 A flowchart according to another exemplary embodiment is shown. Figure 6 Rules for adjusting one or more conditions for SDT permission and initiating an SDT procedure based on the adjusted one or more conditions are shown. Figure 6 The functions shown therein may be performed by a terminal device such as a first device type (e.g., a RedCap device) or a device included in the terminal device.
[0107] Referring Figure 6 , if at least one offset value for adjusting at least one condition for SDT permission is received from a network element of a wireless communication network (e.g., from a base station) (601: Yes), then at least one condition for SDT permission is adjusted 602 by applying the at least one offset value to the at least one condition (e.g., adding or subtracting). The at least one condition may include, for example, a condition of uplink data volume and / or a condition of RSRP. The offset value may be a positive or negative value. As a non-limiting example, an offset value of +3 dB may be added to the RSRP threshold of the condition of RSRP to increase the RSRP threshold.
[0108] On the other hand, if no offset value for adjusting at least one condition for SDT is received (601: No), then SDT is not allowed 605. In other words, in the case where the network does not configure an adjustment and / or an offset value for a device (e.g., a RedCap device) through dedicated or broadcast signaling, then the device is not allowed to perform SDT. In one example, this constraint may only apply to 1Rx RedCap devices and not to 2Rx RedCap devices.
[0109] If at least one of the adjusted conditions (603: yes) is satisfied, then initiate the 604 SDT procedure. For example, if the amount of uplink data to be transmitted is lower than or equal to the adjusted uplink data volume threshold of the adjusted condition of the uplink data volume, and / or if the measured RSRP value is higher than or equal to the adjusted RSRP threshold of the adjusted condition of the RSRP, then at least one of the adjusted conditions may be satisfied.
[0110] On the other hand, if at least one of the adjusted conditions is not satisfied (603: no), then 605 SDT is not allowed.
[0111] Figure 7 A flowchart for SDT resource determination according to an exemplary embodiment is shown. Figure 7 The functions shown in may be performed by a terminal device such as a first device type (e.g., a RedCap device) or a device included in the terminal device.
[0112] Reference Figure 7 , adjust one or more thresholds for selecting between RACH preamble groups. For example, the device (e.g., a RedCap device) may increase or decrease the RACH preamble group data volume threshold and / or the RSRP threshold to be higher or lower than a second device type (e.g., a non-RedCap UE), such that the device (e.g., a RedCap device) is less likely (after increasing the threshold) or more likely (after decreasing the threshold) to select RACH preamble group B compared to the second device type (e.g., a non-RedCap UE).
[0113] Select 702 the RACH preamble group at least partially based on the adjusted one or more thresholds. The selected RACH preamble group may be, for example, group A or group B. For example, when the amount of uplink data to be transmitted is small, i.e., lower than or equal to the adjusted RACH preamble group data volume threshold, and / or when the device is in poor coverage (e.g., the measured RSRP value is lower than the adjusted RSRP threshold), group A may be selected. When the amount of uplink data to be transmitted is large, i.e., higher than the adjusted RACH preamble group data volume threshold, and / or when the device is in good coverage (e.g., the measured RSRP value is higher than or equal to the adjusted RSRP threshold), group B may be selected.
[0114] Alternatively, the device may not be allowed to select a RACH preamble from group B.
[0115] Transmit 703 the random access preamble from the selected RACH preamble group to a network element of the wireless communication network to request uplink resources for SDT. The uplink resources may include time resources and / or frequency resources.
[0116] Receive, from a network element 704, an indication of uplink resources for SDT, such as an uplink grant included in a random access response (i.e., Msg2).
[0117] Initiate 705 the SDT procedure by using the indicated uplink resources. In other words, small data transmissions may be transmitted by using the indicated uplink resources.
[0118] The functions and / or blocks described above by way of Figures 2 to 7 are not necessarily in absolute chronological order, and some of them may be executed simultaneously or in an order different from that described. Other functions and / or blocks may also be executed between or within them.
[0119] Technical advantages provided by some exemplary embodiments are that they may provide an improved SDT procedure that takes into account the limitations of a device (e.g., a RedCap device). Some exemplary embodiments may improve UL and DL SDT transmissions for devices such as RedCap devices such that the SDT procedure is not attempted under poor radio conditions and / or when there is too much data to transmit.
[0120] Figure 8 A device 800 according to an exemplary embodiment is shown, which may be a terminal device of a first device type or a device included in the terminal device. The terminal device may also be referred to herein as a UE, a user equipment, or a RedCap device. The device 800 includes a processor 810. The processor 810 interprets computer program instructions and processes data. The processor 810 may include one or more programmable processors. The processor 810 may include programmable hardware with embedded firmware and may alternatively or additionally include one or more application specific integrated circuits (ASICs).
[0121] The processor 810 is coupled to the memory 820. The processor is configured to read data from the memory 820 and write data to the memory. The memory 820 may include one or more memory cells. The memory cells may be volatile or non-volatile. It should be noted that in some exemplary embodiments, there may be one or more cells of non-volatile memory and one or more cells of volatile memory, or alternatively, there may be one or more cells of non-volatile memory, or alternatively, there may be one or more cells of volatile memory. Volatile memory may be, for example, random access memory (RAM), dynamic random access memory (DRAM), or synchronous dynamic random access memory (SDRAM). Non-volatile memory may be, for example, read-only memory (ROM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), flash memory, optical storage devices, or magnetic storage devices. Generally, the memory may be referred to as a non-transitory computer-readable medium. The memory 820 stores computer-readable instructions executed by the processor 810. For example, the non-volatile memory stores computer-readable instructions, and the processor 810 uses the volatile memory for temporarily storing data and / or instructions to execute the instructions.
[0122] The computer-readable instructions may have been pre-stored in the memory 820, or alternatively or additionally, they may be received by the device via an electromagnetic carrier signal and / or may be copied from a physical entity such as a computer program product. Execution of the computer-readable instructions causes the device 800 to perform one or more of the above-described functionalities.
[0123] In the context of this document, "memory" or "plural computer-readable media" or "computer-readable medium" may be any one or more non-transitory media or devices that can contain, store, transmit, propagate, or transport instructions for use by or in connection with an instruction execution system, apparatus, or device such as a computer.
[0124] The device 800 may also include or be connected to an input unit 830. The input unit 830 may include one or more interfaces for receiving input. The one or more interfaces may include, for example, one or more temperature, motion, and / or orientation sensors, one or more cameras, one or more accelerometers, one or more microphones, one or more buttons, and / or one or more touch detection units. Additionally, the input unit 830 may include an interface to which an external device may be connected.
[0125] Device 800 may also include an output unit 840. The output unit may include or be connected to one or more displays capable of rendering visual content, such as a light-emitting diode (LED) display, a liquid crystal display (LCD), and / or a liquid crystal on silicon (LCoS) display. The output unit 840 may also include one or more audio outputs. The one or more audio outputs may be, for example, speakers.
[0126] Device 800 also includes a connectivity unit 850. The connectivity unit 850 supports wireless connectivity to one or more external devices. The connectivity unit 850 includes at least one transmitter and at least one receiver that may be integrated into device 800 or to which device 800 may be connected. The at least one transmitter includes at least one transmission antenna, and the at least one receiver includes at least one reception antenna. The connectivity unit 850 may include an integrated circuit or a set of integrated circuits that provides wireless communication capabilities for device 800. Alternatively, the wireless connectivity may be a hardwired application-specific integrated circuit (ASIC). The connectivity unit 850 may include one or more components controlled by a corresponding control unit, such as a power amplifier, a digital front end (DFE), an analog-to-digital converter (ADC), a digital-to-analog converter (DAC), a frequency converter, a modulator (demodulator), and / or an encoder / decoder circuitry.
[0127] It should be noted that device 800 may also include Figure 8 various components not shown in
[0128] Figure 9 Device 900 of
[0129] The processor is coupled to a memory 920. The processor is configured to read data from and write data to the memory 920. The memory 920 may include one or more memory cells. The memory cells may be volatile or non-volatile. It should be noted that in some exemplary embodiments, there may be one or more cells of non-volatile memory and one or more cells of volatile memory, or alternatively, there may be one or more cells of non-volatile memory, or alternatively, there may be one or more cells of volatile memory. Volatile memory may be, for example, random access memory (RAM), dynamic random access memory (DRAM), or synchronous dynamic random access memory (SDRAM). Non-volatile memory may be, for example, read-only memory (ROM), programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), flash memory, optical storage devices, or magnetic storage devices. Generally, the memory may be referred to as a non-transitory computer-readable medium. The memory 920 stores computer-readable instructions that are executed by the processor. For example, the non-volatile memory stores the computer-readable instructions, and the processor uses the volatile memory for temporarily storing data and / or instructions to execute the instructions.
[0130] The computer-readable instructions may have been pre-stored into the memory 920, or alternatively or additionally, they may be received by the device via an electromagnetic carrier signal and / or copied from a physical entity such as a computer program product. Execution of the computer-readable instructions causes the device 900 to perform one or more of the above-described functionality.
[0131] The memory 920 may be implemented using any suitable data storage technology (such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and / or removable memory). The memory may include a configuration database for storing configuration data. For example, the configuration database may store a current list of neighboring cells, and in some exemplary embodiments, the structure of the frames used in the detected neighboring cells.
[0132] The device 900 may also include a communication interface 930, which includes hardware and / or software for implementing communication connectivity according to one or more communication protocols. The communication interface 930 includes at least one transmitter (TX) and at least one receiver (RX) that may be integrated into the device 900 or to which the device 900 may be connected. The communication interface 930 provides the device with radio communication capabilities to communicate in a cellular communication system. The communication interface may, for example, provide a radio interface to a terminal device. The device 900 may also include another interface to a core network (such as a network coordinator device) and / or to an access node of a cellular communication system. The device 900 may also include a scheduler 940 configured to allocate resources.
[0133] As used in this application, the term "circuitry" can refer to one or more or all of the following: a) only hardware circuit implementations (such as implementations in only analog and / or digital circuitry); and b) combinations of hardware circuits and software, such as (where applicable): i) combinations of analog and / or digital hardware circuits with software / firmware, and ii) any part of a hardware processor with software (including digital signal processors, software, and memory that work together to cause a device, such as a mobile phone, to perform various functions); and c) hardware circuits and / or processors (such as a microprocessor or a part of a microprocessor) that require software (e.g., firmware) to operate, but the software may not be present when not needed for operation.
[0134] This definition of circuitry applies to all uses of the term in this application (including in any claims). As another example, as used in this application, the term "circuitry" also covers implementations of only a hardware circuit or a processor (or processors) or a part of a hardware circuit or a processor and its (or their) accompanying software and / or firmware. The term "circuitry" also covers (e.g., and where applicable to a particular claim element) a baseband integrated circuit or a processor integrated circuit for a mobile device or a similar integrated circuit in a server, a cellular network device, or other computing or network device.
[0135] The techniques and methods described herein can be implemented by various means. For example, these techniques can be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the devices of the exemplary embodiments can be implemented in one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or combinations thereof. For firmware or software, the implementation can be carried out by modules (e.g., programs, functions, etc.) of at least one chipset that perform the functions described herein. The software code can be stored in a memory unit and executed by a processor. The memory unit can be implemented inside or outside the processor. In the latter case, as is known in the art, it can be communicatively coupled to the processor via various means. Additionally, the components of the systems described herein can be rearranged and / or supplemented by additional components to facilitate achieving the various aspects described thereof, etc., and they are not limited to the exact configurations set forth in a given drawing, as will be appreciated by those skilled in the art.
[0136] It will be apparent to those skilled in the art that, with the progress of technology, the inventive concept can be implemented in various ways. The embodiments are not limited to the above-described exemplary embodiments, but may vary within the scope of the claims. Accordingly, all words and expressions should be construed broadly, and they are intended to illustrate rather than limit the exemplary embodiments.
Claims
1. A terminal device of a first device type, the terminal device of the first device type comprising: At least one processor and at least one memory, the at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the terminal device to: Obtain one or more first conditions for small data transmission, the one or more first conditions being specific to the first device type, wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; Obtain the one or more second conditions by receiving the one or more second conditions from the network; Wherein the one or more first conditions are obtained by adjusting a currently configured value in the one or more second conditions for the small data transmission according to a predefined rule; And If the one or more first conditions are satisfied, initiate a small data transmission procedure when in a radio resource control inactive state or an idle state.
2. The terminal device according to claim 1, wherein the one or more first conditions at least include a condition for uplink data volume; and wherein the terminal device is further caused to: Obtain the condition for the uplink data volume in the one or more first conditions by adjusting an uplink data volume threshold for small data transmission in the one or more second conditions; Wherein, If an uplink data volume value of the small data transmission procedure is lower than or equal to an adjusted uplink data volume threshold for the small data transmission in the one or more second conditions, the condition for the uplink data volume in the one or more first conditions is satisfied.
3. The terminal device according to claim 2, wherein the uplink data volume threshold in the one or more second conditions is adjusted by being decreased.
4. The terminal device according to any one of the preceding claims, wherein the one or more first conditions at least include a condition for reference signal reception power; and wherein the terminal device is further caused to: Obtain the condition for the reference signal reception power in the one or more first conditions by adjusting a reference signal reception power threshold for small data transmission in the one or more second conditions; Wherein, If a measured reference signal received power value is higher than or equal to an adjusted reference signal received power threshold in the one or more second conditions, the condition for the reference signal received power in the one or more first conditions is satisfied.
5. The terminal device according to claim 4, wherein the uplink data volume threshold in the one or more second conditions is adjusted by being increased.
6. The terminal device according to any one of the preceding claims, wherein the terminal device is further caused to: Adjust a random access channel preamble group data volume threshold; Select a random access channel preamble group at least partially based on the adjusted random access channel preamble group data volume threshold; Transmit a random access preamble from the selected random access channel preamble group to request an uplink resource for the small data transmission procedure; And Receive an indication of the uplink resource for the small data transmission procedure; wherein the small data transmission procedure is initiated by using the indicated uplink resource.
7. The terminal device according to any one of the preceding claims, wherein the one or more first conditions are obtained by dividing, multiplying, adding, or subtracting a currently configured value of at least one condition in the one or more second conditions.
8. The terminal device according to any one of claims 1 to 6, wherein the terminal device is further caused to: receive at least one offset value for adjusting at least one of the one or more second conditions; and obtain the one or more first conditions by applying the at least one offset value to the at least one of the one or more second conditions; wherein, If the at least one offset value is received and the one or more first conditions are satisfied, initiate the small data transmission procedure.
9. The terminal device according to any one of the preceding claims, wherein the one or more first conditions are obtained at least in part based on at least one of the following: the bandwidth of the terminal device, the number of antennas, the number of receivers, the battery life.
10. The terminal device according to any one of the preceding claims, wherein the first device type refers to a device with reduced 1Rx capability, and the terminal device is a device with reduced 1Rx capability.
11. A method implemented at a terminal device of a first device type, the method comprising: Obtain one or more first conditions for small data transmission, the one or more first conditions being specific to the first device type, wherein the one or more first conditions are different compared to one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; Obtain the one or more second conditions by receiving the one or more second conditions from the network; Wherein the one or more first conditions are obtained by adjusting a currently configured value in the one or more second conditions for the small data transmission according to a predefined rule; And If the one or more first conditions are satisfied, initiate a small data transmission procedure when in a radio resource control inactive state or an idle state.
12. A computer program comprising instructions for causing a terminal device of a first device type to perform at least the following operations: obtain one or more first conditions for small data transmission, the one or more first conditions being specific to the first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type; Obtain the one or more second conditions by receiving the one or more second conditions from the network; wherein the one or more first conditions are obtained by adjusting current configured values in the one or more second conditions for the small data transmission according to predefined rules; and if the one or more first conditions are satisfied, initiate a small data transmission procedure when in a radio resource control inactive state or an idle state.
13. A system comprising at least a terminal device of a first device type and a network element of a wireless communication network; wherein the terminal device is configured to: obtain one or more first conditions for small data transmission, the one or more first conditions being specific to the first device type, wherein the one or more first conditions are different from one or more second conditions for small data transmission, the one or more second conditions being associated with a second device type different from the first device type, wherein, The network element is configured to: transmit an indication indicating the one or more second conditions for the small data transmission; and wherein the terminal device is configured to: receive the indication from the network element, obtain the one or more first conditions by adjusting current configured values in the one or more second conditions for the small data transmission according to predefined rules, and if the one or more first conditions are satisfied, initiate a small data transmission procedure when in a radio resource control inactive state or an idle state.
Citation Information
Patent Citations
Method and apparatus for random access channel (RACH)-based small data transmission procedure in a wireless communication system
US20210227586A1