Network method for small data transmission termination and signaling - Patents.com
The network-centric method enables efficient management of small data transmissions by allowing a distributed unit to determine the termination of multi-shot transactions, reducing unnecessary state transitions and conserving power, addressing inefficiencies in existing systems.
Patent Information
- Application Number
- JP2023537382
- Authority / Receiving Office
- JP · JP
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-19
- Filing Date
- 2021-12-07
- Publication Date
- 2025-10-14
- Estimated Expiration
- 2041-12-07
AI Technical Summary
Existing wireless communication systems face challenges in efficiently managing small data transmissions from user equipment (UE) in the RRC_INACTIVE state, leading to unnecessary overhead and inefficiencies in transitioning to active connection states for small data exchanges.
A network-centric method where a distributed unit (gNB-DU) in a base station determines the termination of multi-shot small data transmission (SDT) transactions by evaluating local and UE-provided information, signaling the end of the transaction to the central unit (gNB-CU) through control or user plane interfaces, thereby optimizing resource usage and minimizing power consumption.
This approach reduces unnecessary transitions to active connection states, conserves power resources, and enhances efficiency in managing small data transmissions by allowing multiple data exchanges without repeated context establishment, thus optimizing network performance.
Smart Images

Figure 0007753367000001 
Figure 0007753367000002 
Figure 0007753367000003
Abstract
Description
[Technical Field]
[0001] The present description relates to communications. [Background technology]
[0002] A communication system may be a facility that enables communication between two or more nodes or devices, such as fixed or mobile communication devices. The signals may be carried by wired or wireless carriers.
[0003] An example of a cellular communication system is the architecture being standardized by the Third Generation Partnership Project (3GPP). Recent developments in this field are often referred to as the long-term evolution (LTE) of Universal Mobile Telecommunications System (UMTS) radio access technology. E-UTRA (Evolved UMTS Terrestrial Radio Access) is the air interface of 3GPP's LTE upgrade path for mobile networks. In LTE, base stations or access points (APs) are called enhanced node APs (eNBs) and provide wireless access within a coverage area or cell. In LTE, mobile devices or mobile stations are called user equipment (UEs). LTE has included several improvements or developments.
[0004] Facing a global bandwidth shortage, wireless carriers have been motivated to consider underutilized millimeter wave (mmWave) frequency spectrum for future broadband cellular communications networks. mmWave (or very high frequency) can include, for example, the 30-300 gigahertz (GHz) frequency range. Radio waves in this band can have wavelengths ranging from 10 to 1 millimeter, giving rise to the name millimeter band or millimeter wave. The volume of wireless data will likely increase significantly in the coming years. Various techniques have been used to address this challenge, including acquiring more spectrum, having smaller cell sizes, and using improved technology that allows for more bits / s / Hz. One factor that can be used to acquire more spectrum is moving to higher frequencies, for example, above 6 GHz. For fifth-generation wireless systems (5G), access architectures for the deployment of cellular wireless devices employing mmWave radio spectrum have been proposed. Other illustrative spectrum, such as cmWave radio spectrum (e.g., 3-30 GHz), can also be used. Summary of the Invention
[0005] According to an example implementation, the method includes a distributed unit (target gNB-DU) of a target base station performing multi-shot ( Multiple calls The method includes receiving a UL SDT packet from a user equipment (UE) in a wireless network during a multi-shot SDT transaction. The method further includes determining whether the UL SDT packet is a terminating UL SDT packet. The method further includes generating termination data indicating an end of the multi-shot SDT transaction in response to determining that the UL SDT packet is a terminating UL SDT packet, and transmitting the termination data along a path in the wireless network to a base station central unit (gNB-CU), where the termination data indicates an end of the SDT transaction.
[0006] According to an example implementation, the apparatus includes at least one processor and at least one memory including computer program code, the at least one memory and the computer program code being configured, using the at least one processor, to cause the apparatus to at least receive, by a distributed unit (target gNB-DU) of a target base station, a UL SDT packet from a user equipment (UE) in a wireless network during a multi-shot SDT transaction. The apparatus further determines whether the UL SDT packet is a terminal UL SDT packet. In response to determining that the UL SDT packet is a terminal UL SDT packet, the apparatus further generates termination data indicating an end of the multi-shot SDT transaction and transmits the termination data along a path in the wireless network to a central unit (gNB-CU) of the base station, where the termination data indicates an end of the SDT transaction.
[0007] According to an example implementation, the apparatus includes means for receiving, by a distributed unit (target gNB-DU) of a target base station, a UL SDT packet from a user equipment (UE) in a wireless network during a multi-shot SDT transaction. The apparatus further includes means for determining whether the UL SDT packet is a terminal UL SDT packet. In response to determining that the UL SDT packet is a terminal UL SDT packet, the apparatus further includes means for generating termination data indicating an end of the multi-shot SDT transaction and transmitting the termination data along a path in the wireless network to a central unit (gNB-CU) of the base station, where the termination data indicates an end of the SDT transaction.
[0008] According to an example implementation, a computer program product includes a computer-readable storage medium storing executable code configured, when executed by at least one data processing device, to cause a distributed unit (target gNB-DU) of a target base station to receive a UL SDT packet from a user equipment (UE) in a wireless network during a multi-shot SDT transaction. The at least one data processing device is further configured to determine whether the UL SDT packet is a terminal UL SDT packet. In response to determining that the UL SDT packet is a terminal UL SDT packet, the at least one data processing device is further configured to generate termination data indicating an end of the multi-shot SDT transaction and transmit the termination data along a path in the wireless network to a central unit (gNB-CU) of the base station, where the termination data indicates an end of the SDT transaction.
[0009] According to an example implementation, a method includes transmitting, by a user equipment (UE), one or more uplink (UL) small data transmission (SDT) packets of a multi-shot SDT transaction to a base station distributed unit (gNB-DU). The method also includes, after transmitting the one or more UL SDT packets, receiving radio resource control release (RRC_RELEASE) data from the gNB-DU indicating that the multi-shot SDT transaction has been closed, where the closure of the multi-shot SDT transaction is determined by the gNB-DU.
[0010] According to an example implementation, an apparatus includes at least one processor and at least one memory containing computer program code, the at least one memory and the computer program code being configured, using the at least one processor, to cause the apparatus to at least transmit, by a user equipment (UE), one or more uplink (UL) small data transmission (SDT) packets of a multi-shot SDT transaction to a base station distributed unit (gNB-DU). After transmitting the one or more UL SDT packets, the apparatus is further configured to receive radio resource control release (RRC_RELEASE) data from the gNB-DU indicating that the multi-shot SDT transaction has been closed, where the closure of the multi-shot SDT transaction is determined by the gNB-DU.
[0011] According to an example implementation, an apparatus includes means for transmitting, by a user equipment (UE), one or more uplink (UL) small data transmission (SDT) packets of a multi-shot SDT transaction to a base station distributed unit (gNB-DU). The apparatus also includes means for receiving, after transmitting the one or more UL SDT packets, radio resource control release (RRC_RELEASE) data from the gNB-DU indicating that the multi-shot SDT transaction has been closed, where the closure of the multi-shot SDT transaction is determined by the gNB-DU.
[0012] According to an example implementation, a computer program product includes a computer-readable storage medium storing executable code configured, when executed by at least one data processing device, to cause the at least one data processing device to transmit, by a user equipment (UE), one or more uplink (UL) small data transmission (SDT) packets of a multi-shot SDT transaction to a base station distributed unit (gNB-DU). The at least one data processing device is also configured, after transmitting the one or more UL SDT packets, to receive radio resource control release (RRC_RELEASE) data from the gNB-DU indicating that the multi-shot SDT transaction has been closed, where the closure of the multi-shot SDT transaction is determined by the gNB-DU.
[0013] The details of one or more example implementations are set forth in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims. [Brief explanation of the drawings]
[0014] [Figure 1] FIG. 1 is a block diagram of a digital communication network in accordance with an example implementation. [Figure 2] FIG. 1 illustrates three SDT solutions: a 4-step RACH-based SDT, a 2-step RACH-based SDT, and a CG-based SDT, according to an example implementation. [Figure 3] FIG. 10 illustrates the contents of a UL MAC PDU for SDT Msg3 / MsgA, or a CG-based SDT transmission for the baseline RRC-based method, according to an example implementation. [Figure 4] 1 illustrates a 5G-RAN distributed (left) and split CU-DU architecture (right) for both the user plane (UP) and control plane (CP), according to an example implementation. [Figure 5]FIG. 10 illustrates a multi-shot SDT procedure including two UL data transmissions, according to an example implementation. [Figure 6] FIG. 1 illustrates a RAN Notification Area (RNA) update procedure without anchor relocation. [Figure 7] A flowchart showing the final UL data determination for a received gNB-DU according to an example implementation. [Figure 8] A sequence diagram showing the final UL data determination of a gNB-DU using inter-gNB SDT without anchor relocation and a notification path including a target gNB-CU-CP according to an example implementation. [Figure 9] A sequence diagram showing gNB-DU final UL data determination using inter-gNB SDT without anchor relocation and a notification path including anchor gNB-CU-UP according to an example implementation. [Figure 10] A sequence diagram showing the final UL data determination of gNB-DU using inter-gNB SDT with anchor relocation and the direct notification path to the target gNB-CU-CP according to an example implementation. [Figure 11] A sequence diagram showing the final UL data determination of gNB-DU using inter-gNB SDT with target relocation, and the notification path including target gNB-CU-UP. [Figure 12] 10 is a flowchart illustrating a process for finalizing a multi-shot SDT transaction, according to an example implementation. [Figure 13] 10 is a flowchart illustrating a process for finalizing a multi-shot SDT transaction, according to an example implementation. [Figure 14] 1 is a block diagram of a node or wireless station (e.g., a base station / access point, a relay node, or a mobile station / user device) in accordance with an example implementation. DETAILED DESCRIPTION OF THE INVENTION
[0015] Figure 1 is a block diagram of a digital communications system, such as wireless network 130, according to an example implementation. In wireless network 130 of Figure 1, user devices 131, 132, 133, and 135, which may also be referred to as mobile stations (MSs) or user equipment (UEs), may be connected to (and in communication with) base station (BS) 134, which may also be referred to as an access point (AP), enhanced Node B (eNB), gNB (which may be a 5G base station), or network node. At least some of the functionality of an access point (AP), base station (BS), or (e)Node B (eNB) may also be performed by any node, server, or host that may be operatively coupled to a transceiver, such as a remote radio head. BS (or AP) 134 provides wireless coverage within cell 136, including user devices 131, 132, 133, and 135. Although only four user devices are shown connected to or attached to BS 134, any number of user devices may be provided. BS 134 is also connected to core network 150 via interface 151. This is just one simple example of a wireless network; others may be used.
[0016] A user device (user terminal, user equipment (UE)) may refer to a portable computing device, including, by way of example, a wireless mobile communication device that operates with or without a subscriber identity module (SIM), including, but not limited to, the following types of devices: a mobile station (MS), a mobile phone, a cell phone, a smartphone, a personal digital assistant (PDA), a handset, a device that uses a wireless modem (such as an alarm or measuring device), a laptop and / or touchscreen computer, a tablet, a phablet, a game console, a notebook, and a multimedia device. It should be understood that a user device may also be almost exclusively an uplink-only device, an example of which is a camera or camcorder that loads images or video clips onto the network.
[0017] In LTE (for example), the core network 150 may be referred to as the Evolved Packet Core (EPC), which may include a Mobility Management Entity (MME) that handles or assists user device mobility / handover between BSs, one or more gateways that may forward data and control signals between the BSs and a packet data network or the Internet, and other control functions or blocks. In 5G, the core network 150 may be an Access Management Function (AMF).
[0018] Various example implementations may apply to a wide variety of wireless technologies, wireless networks (such as LTE, LTE-A, 5G (New Radio or NR), cmWave, and / or mmWave band networks), or any other wireless network or use case. LTE, 5G, cmWave, and mmWave band networks are provided merely as illustrative examples, and various example implementations may apply to any wireless technology / wireless network. Various example implementations may also apply to a variety of different applications, services, or use cases, such as, for example, Ultra-Reliable Low Latency Communications (URLLC), Internet of Things (IoT), Time-Sensitive Communications (TSC), Enhanced Mobile Broadband (eMBB), Massive Machine-Type Communications (MMTC), Vehicle-to-Vehicle (V2V), Vehicle-to-Device, etc. Each of these use cases, or types of UE, may have its own set of requirements.
[0019] Some IoT applications involve the exchange of relatively small amounts of data. For example, metering and alarm applications typically involve small amounts of mobile-originated (MO) data, while various queries, update notifications, actuator activations, and the like involve small amounts of mobile-terminated (MT) data. Unfortunately, establishing a connection between a mobile device and a network involves a large overhead (compared to the small amount of data). In some cases, a UE may be placed in an inactive state, such as an RRC_INACTIVE state, which represents an intermediate area between a connected state and an inactive state.
[0020] Enabling data transmission to and from a UE (or other type of mobile device) in the RRC_INACTIVE state makes sense when the UE has a small amount of data to transmit and the radio access network (RAN) has no data or only a small amount of data to transmit, but the UE is in the RRC_INACTIVE state. If the UE or RAN has subsequent data to transmit, the overhead of transitioning to an active connection state (e.g., RRC_CONNECTED mode) may be justified, and thus the data can be sent using dedicated resources.
[0021] When a UE is in RRC_INACTIVE state, an inactive radio network temporary identifier (I-RNTI) is allocated to the UE transitioning to RRC_INACTIVE state by the anchor gNB (i.e., the last serving gNB). The I-RNTI is configured as part of an RRC release message with a suspended configuration, and the UE transmits the I-RNTI in an RRC resume request message. The I-RNTI (40 bits) may include a means for identifying both the UE and the last serving gNB, and therefore may include a UE ID portion and a gNB ID portion. The algorithm used to construct the I-RNTI is vendor-specific, including the decision on the location within the I-RNTI and some bits used for the UE ID and gNB ID portions.
[0022] In some implementations, the UE identifier is an SDT UE ID, in which case the I-RNTI is a special case of such an identifier.
[0023] For 3GPP Rel-17, a work item titled "NR small data transmissions in INACTIVE state" [RP-193252] has been initiated. Three solutions to enable small data transmissions (SDT) triggered by uplink transmissions in 5G NR systems are proposed here, focusing first on UL transmissions: · 4-step RACH based SDT: User plane (UP) or control plane (CP) data carried in Msg3 of the 4-step RACH procedure (i.e., small payload multiplexed with the RRC connection resumption request). Two-step RACH-based SDT:UP (or CP) data transmission occurs in MsgA of the two-step RACH procedure and specifically on PUSCH resources, which are reconfigured by the gNB and broadcast in the system information with associated physical transmission parameters; Configured grant-based SDT: A UE in RRC_CONNECTED state can receive a CG type 1 configuration indicating specific pre-configured PUSCH resources to be used for UL data transmission. This (type of) CG configuration can also be configured to be used when the UE is in RRC_INACTIVE state as long as the UE timing advance is valid.
[0024] In the above-mentioned solutions for enabling SDT, a radio resource control (RRC) based approach is assumed and is illustrated in Figure 2. Figure 2 is a diagram 200 illustrating three SDT solutions: a four-step RACH-based SDT 210, a two-step RACH-based SDT 220, and a CG-based SDT 230. In a four-step RACH-based SDT 210, the user equipment (UE) sends an SDT RACH preamble to the base station (gNB) as MSG1 at 211. The gNB sends a random access response (RAR) to the UE as MSG2 at 212. The UE sends an RRC_RESUME_REQUEST message and any uplink (UL) data to the gNB as MSG3 at 213. The gNB sends an RRC_RELEASE with a suspend indication and any downlink (DL) data to the UE as MSG4 at 214. In two-step RACH-based SDT 220, the UE sends an SDT RACH preamble, an RRC_RESUME_REQUEST message, and any uplink (UL) data as MSGA to the gNB at 221. At 222, the gNB sends an RRC_RELEASE with a suspend indication and any downlink (DL) data as MSGB to the UE. For CG-based SDT 230, the UE is in PRC_CONNECTED state. At 231, the gNB sends a CONFIGURED_GRANT_CONFIGURATION for SDT to the UE. The UE then moves to PRC_INACTIVE state. At 232, the UE sends a CONFIGURED_GRANT PUSCH transmission containing an RRC_RESUME_REQUEST and any UL data to the gNB. At 233, the UE sends an RRC_RESUME with a suspend indication and any DL data to the gNB.
[0025] The RRC-based approach involves the UE sending an RRC message containing information about, for example, the UE identity and its authentication token (i.e., MAC-I). An RRC Resume Request message is used for this, but it is envisioned that in some implementations a different message may be employed as well; FIG. 3 shows a corresponding uplink media access channel protocol data unit (UL MAC PDU) 300. The SDT procedure is then closed upon receipt by the UE of another RRC message. An RRC-less approach instead envisions that the RRC layer need not be involved and that the necessary information, such as the UE authentication token, can be provided by the UE in the MAC header or as a MAC CE.
[0026] The RAN architecture may be split into a centralized baseband unit and distributed radio units. The NG-RAN architecture defined in NR is shown in Figure 4. Figure 4 illustrates 5G-RAN distributed (left) and split CU-DU architectures (right) 400 for both the user plane (UP) and control plane (CP). In Figure 4, the distributed architecture on the left shows a traditional gNB 410 with all RAN protocol layers. On the right, an NG-RAN split architecture 420 is shown with a separation at higher layers into a central unit (CU) that controls distributed units (DUs) 422 and, possibly, one or more remote units (RUs) 424 on the network side. Such a split architecture applies functional splitting at one or more protocol layers on the network side, potentially leading to cost reduction, improved scalability, and more efficient scheduling coordination.
[0027] It is noted that UP packets are UL payloads, in contrast to CP packets, which are lower layer packets such as MAC CE.
[0028] In a CU / DU split architecture, the following assumptions can be made for the gNB and cell that transitions the UE to the RRC inactive state: The UE and CU-CP store the UE context when the UE transitions to RRC_INACTIVE. The DU releases the UE context stored when the UE transitions to RRC_INACTIVE and the corresponding F1-U tunnel established between the DU and the CU-UP. CU-UP may keep UE context in suspended state when the UE is in RRC_INACTIVE.
[0029] Multi-shot SDT involves that multiple UL / DL transmissions can be sent subsequent to the first UL SDT transmission without transitioning the UE to RRC_CONNECTED, i.e. as part of the same SDT procedure.
[0030] To enable the UE to use multi-shot SDT, the network should be capable of determining when more data is present in the UE buffer for transmission (e.g., based on BSR), and the UE should be capable of being assigned a dynamic or configured grant for transmitting subsequent UL data, as shown in Figure 5.
[0031] 5 illustrates a multi-shot SDT procedure 500 including two UL data transmissions. At 501, the UE sends an RRC_RESUME_REQUEST message, the first UL data, and a buffer status report (BSR) to the gNB. At 502, the gNB sends connection resolution information and an UL dynamic grant to the UE. At 503, the UE sends a scheduled PUSCH transmission including the second UL data to the gNB. At 504, the gNB sends an RRC_RELEASE message with a suspend indication and any DL data to the UE.
[0032] Nevertheless, even when using RRC-based SDT, only the first UL SDT transmission in a multi-shot SDT procedure will contain an RRC message (e.g., RRC_RESUME_REQUEST) to enable UE verification based on MAC-I information, while subsequent UL SDT transmissions may not contain an RRC message. On the one hand, there is no need to repeat UE verification multiple times within the SDT procedure, and on the other hand, the UE identity in subsequent transmissions can be based on the dedicated resource allocation in the scheduling grant.
[0033] The absence of an RRC message in the subsequent UL SDT transmission means that the gNB CU-CP is still unaware of whether there will be a subsequent SDT transmission and when the SDT should end. Therefore, it is unclear when and how the gNB-CU-CP can close an ongoing SDT procedure, i.e., what is the trigger for the gNB-CU-CP to send an RRC_RELEASE message (or similar) to the UE.
[0034] There is also ambiguity in the gNB-DU regarding the handling of such subsequent SDT data packets: the control plane procedures performed to establish the UE context information required for data forwarding are too expensive to repeat with each UL SDT transmission.
[0035] Furthermore, in the case of inter-gNB SDT, where the network operates without anchor relocation, the associated gNB-CU-CP resides at the anchor gNB. In this case, the conventional approach to perform SDT transmission is through the periodic RAN Notification Area (RNA) update procedure without anchor relocation, as shown in Figure 6.
[0036] Figure 6 illustrates a RAN Notification Area (RNA) update procedure 600 without anchor relocation. In Figure 6, the UE is in RRC_INACTIVE CM_CONNECTED state. At 601, the UE sends an RRC_RESUME_REQUEST and an RNA update to the gNB. At 602, the gNB sends a RETRIEVE_UE message and an RNA update to the final serving (anchor) gNB. At 603, the final serving gNB sends a RETRIEVE_UE_CONTEXT_FAILURE message to the gNB. At 603, the gNB sends an RRC_RELEASE message and a suspend indication to the UE. The RRC release message is immediately provided to the gNB by the final serving gNB (as part of step 603 of Figure 6) for transmission to the UE.
[0037] In contrast to the conventional UL SDT transmission described above, which is unclear as to how to terminate, an improved technique for implementing a multi-shot SDT transaction involves a distributed unit (DU) in a base station (gNB) in a wireless network determining conditions for terminating the multi-shot small data transmission (SDT) and providing a termination indication to an entity within the wireless network. For example, when a UE initiates a multi-shot SDT transaction, the UE sends an initial UL SDT data packet to a target gNB-DU. When the UE notifies an associated network entity, such as a target gNB-CU-CP, to acquire the UE context, the gNB-DU receives an instruction to establish a path for forwarding UL and DL data. As the gNB-DU continues to receive UL SDT data packets from the UE, the DU determines whether the UL SDT data packet is a terminating UL SDT data packet, i.e., the final data packet of the transaction. Once the gNB-DU makes this determination, it generates termination data indicating the termination of the multi-shot SDT transaction and transmits the termination data along the established path per the instruction received from the associated network entity.
[0038] The improved technique described above allows the base station central unit control plane (gNB-CU-CP) to send a termination message to the UE, which can save significant power resources in the wireless network and the UE by minimizing the duration of PDCCH monitoring.
[0039] In some implementations, the data representing the route is used to send subsequent UL SDT packets over the indicated route.
[0040] The network-centric method to be implemented in the target gNB-DU specifies that the target gNB-DU determines when to terminate an ongoing multi-shot SDT transaction for a given UE and signal an "SDT transaction end indication" to the relevant network entity in the RAN split architecture of the anchor or target node (i.e., towards the gNB-CU-CP) depending on the following two possible scenarios: "Scenario #1": SDT without anchor relocation · "Scenario #2": SDT with anchor relocation. This then allows the anchor or target gNB-CU-CP to timely trigger the generation of an RRC_RELEASE message with the suspension information, which also allows the target gNB-DU to forward this RRC release message for transmission to the UE in order to signal the end of the SDT transaction and transition the UE back to RRC_INACTIVE.
[0041] The SDT termination decision is made on the network side in the DU based on local information in the DU or based on information provided by the UE (i.e., network-centric approach). When based on information provided by the UE, there are two variants: there is a signaling impact to the UE (e.g., the UE includes the SDT transaction end in the MAC CE), for example, by utilizing existing MAC / RLC signaling such as BSR (e.g., with a special predefined value), or there is no signaling impact to the UE.
[0042] The network-centric method described above has several options depending on whether anchor relocation is not used (Scenario #1) or is used (Scenario #2), as described above. The network-centric method also depends on the forwarding solution for the UL SDT transaction end indication. "Alternative A": UL SDT transaction end indication transferred via the CP interface; "Alternative B": UL SDT transaction end indication forwarded via UP tunnel, The selection is made by the target gNB-CU-CP, which then informs the target DU of the selected alternative.
[0043] The steps involved in the above network-centric method are described below, taking into account both scenarios with and without anchor relocation (scenarios 1 and 2), and both data forwarding solutions (alternatives A and B). Step 1: Upon or after receiving the first UL SDT transmission from the UE, the target gNB-DU receives information about the chosen forwarding solution for the SDT from the target gNB-CU-CP. o This information can be provided from the target gNB-CU-CP to the target gNB-DU in response to the initial UL RRC message (F1: UE Context Setup procedure) sent by the DU (in the first UL SDT packet). Scenario 1 (Inter-gNB SDT without anchor relocation): The target gNB-DU receives information from the target gNB-CU-CP that the selected forwarding solution is data to be forwarded to the anchor gNB-CU-CP, i.e., without anchor relocation. Scenario 2 (Inter-gNB SDT with anchor relocation or intra-gNB SDT): The target gNB-DU receives information from the target gNB-CU-CP that the selected forwarding solution is data to be forwarded to the target gNB-CU-CP, i.e., with anchor relocation. Step 2: While the SDT procedure is then ongoing for the UE, the target gNB-DU evaluates / determines whether the UL SDT transaction should be terminated. o The evaluation / decision can be based on previous information received from the UE about data in the buffer (BSR / SR) and / or local monitoring and information (e.g. monitoring of the number of UL SDT transmissions already performed by the UE in ongoing SDT transactions, data inactivity monitoring, load level), in which case there is no UE impact. o The decision can also be made via explicit new signaling from the UE, for example a new SDT end indication encoded in the MAC CE. o The decision can be made constantly, periodically, or event-based (e.g., upon receipt of a UL SDT). · Step 3: If the target gNB-DU determines that the UL SDT transaction should be terminated, it signals a termination indication to the relevant network entity (i.e., gNB-CU-CP or gNB-CU-UP) depending on whether alternative A or B is chosen for this step (applies to both scenarios 1 and 2). After receiving the initial UL SDT packet of the transaction, it is noted that data representing the path along which the termination data is transmitted in the wireless network and sent to the gNB-DU is generated by the anchor gNB-CU-UP. Alternative A (UL SDT transaction termination via CP interface F1-C / Xn-C) ◆ Step 3.1: The target gNB-DU instructs the target gNB-CU-CP via F1-C information regarding the SDT procedure termination, for example using a UL SDT transaction termination indication. The above F1-C UL SDT transaction end indication is included in the F1-C message, which may or may not further include a final UL SDT packet depending on the chosen forwarding path. ◆ Scenario 1 (Inter-gNB SDT without anchor relocation): ● Step 3.2: The anchor gNB may control the UL SDT transaction termination, therefore the target gNB-CU-CP informs the anchor gNB-CU-CP of information regarding the UL SDT transaction termination. o This can be done by using existing XnAP messages (eg XnAP Release or XnAP Retrieve Context Request) or new XnAP messages. ● Step 3.3: Upon receiving the information about the UL SDT transaction termination, the anchor gNB-CU-CP constructs an RRC_RELEASE message with the temporary suspension information to the UE and delivers this message via the target CU CP via Xn. o UL SDT transaction completion can be delayed if DL data is expected. ◆ Scenario 2 (Inter-gNB SDT or Intra-gNB SDT with anchor relocation): ● Step 3.2: The target gNB-CU-CP controls the UL SDT transaction termination, and therefore, upon receiving the information about the UL SDT transaction termination, it constructs an RRC release message with the suspension information to the UE and delivers this message via the target gNB-DU. o UL SDT transaction completion can be delayed if DL data is expected. Alternative B (UL SDT transaction termination via UP interface F1-U) ◆ Scenario 1 (Inter-gNB SDT without anchor relocation): ● Step 3.1: The target gNB-DU instructs the anchor gNB-CU-UP via F1-U, for example using a UL SDT transaction end indication. ● Step 3.2: Upon receiving the information about the UL SDT transaction completion, the anchor CU-UP informs the anchor CU-CP via E1. ● Step 3.3: Upon receiving the information about the UL SDT transaction termination, the anchor CU-CP constructs an RRC_RELEASE message with the suspension information to the UE and delivers this message to the UE via the target CU-CP via Xn via an existing XnAP message or a new XnAP message. o UL SDT transaction completion can be delayed if DL data is expected. ◆ Scenario 2 (Inter-gNB SDT or Intra-gNB SDT with anchor relocation) (in this scenario the UE context is transferred to or already exists in the target gNB, therefore the final RRC_RELEASE with suspend indication is also generated by the target gNB-CU-CP): ● Step 3.1: The target gNB-DU instructs the target gNB-CU-UP via F1-U, for example using a UL SDT transaction end indication. ● Step 3.2: Upon receiving the information about the UL SDT transaction completion, the target CU-UP informs the target CU-CP via E1. ● Step 3.3: Upon receiving the information about the UL SDT transaction termination, the target CU-CP constructs an RRC_RELEASE message with the suspension information to the UE and delivers this message to the UE via the target gNB-DU. o UL SDT transaction completion can be delayed if DL data is expected.
[0044] In all cases, the target gNB-DU is proposed to store a temporary UE context based on the I-RNTI received from the UE / gNB-CU-CP during the UL SDT transaction. This may exist until the completion of the UL SDT transaction and may be relinquished only after sending an RRC_RELEASE message to the UE. Furthermore, resource release is also performed in the corresponding logical entities, e.g., gNB-DU and gNB-CU-UP, after the UL SDT transaction ends.
[0045] FIG. 7 is a flowchart illustrating a receiving gNB-DU UL SDT transaction termination 700.
[0046] At 702, it is determined whether the gNB-DU UL receives the UL SDT data packet.
[0047] If the UL SDT data packet is not received at the gNB-DU, the gNB-DU detects whether there is any inactivity in the UL SDT transaction at 704. If not, the gNB-DU continues to determine whether a UL SDT data packet has been received. If so, the gNB-DU determines that the UL SDT transaction has ended.
[0048] If a UL SDT data packet is received at the gNB-DU, at 706 the gNB-DU determines whether there is an indication that the UL SDT data packet is a terminated UL SDT data packet.
[0049] At 708, if the gNB-DU determines that there is no indication that the UL SDT data packet is a terminating UL SDT data packet, the gNB-DU waits for another UL SDT data packet.
[0050] If the gNB-DU determines that there is an indication that the UL SDT data packet is a terminating UL SDT data packet, at 710 the gNB-DU sends a UL SDT transaction termination indication to the relevant entity in the network.
[0051] Figures 8 to 11 show the UL SDT transaction termination process for both Scenarios 1 and 2 and Alternatives A and B. Note that in Scenario 1, where the UE initiates SDT to a gNB different from the anchor gNB and anchor relocation is not performed, both the first and subsequent (UL) data will be processed in the anchor gNB-CU-UP, and the data can be forwarded directly from the target gNB-DU to the anchor gNB-CU-UP.
[0052] Figure 8 is a sequence diagram showing Scenario 1, Alternative A, i.e., gNB-DU decision 800 of UL SDT transaction termination using inter-gNB SDT without anchor relocation, and the notification path via the CP interface to the anchor gNB-CU-CP. At 801 and 802, the target gNB-DU receives the first SDT data packet from the UE, communicates with the target gNB-CU-CP via F1-C to obtain the UE context (e.g., UL TEID address), and establishes a DL+UL forwarding F1-U tunnel for the UE's SDT DRB to the anchor gNB-CU-UP. o Note: The DU establishes a UE context using the received I-RNTI as a key and maintains the UE context until the end of the SDT procedure. In 803, the UE may perform one or more subsequent UL SDT data packet transmissions to the target gNB-DU as part of the same SDT procedure (or transaction), i.e. without switching to RRC_CONNECTED. The first SDT data packet may have already indicated, e.g. via BSR, that there is additional data in the buffer, or the UE may indicate that there is more data after the first SDT transmission. At 804, for each SDT data packet, the target gNB-DU determines, based on information provided by the UE or using local information, whether the current UL SDT data packet is the last of an ongoing UL SDT transaction for the UE. o When this assessment is based on information provided by the UE, there are two variants depending on whether UE signaling is impacted or not. ◆ Variant 1: No UE signaling impact, i.e., the target gNB-DU determines the end of the UL SDT transaction based on previous information from the UE. ● The UE may provide the BSR to the network. ● In some implementations, a BSR index indicating a predefined value (eg, 0 bytes) may convey an indication that the UE has chosen to close an ongoing SDT procedure. ● In some implementations, if the UE does not include a BSR, but there is no room for a BSR, it may convey an indication that the UE has chosen to close an ongoing SDT procedure. In some implementations, the transmission of the UE's opt-in indication is performed via a lower protocol layer. ◆ Variant 2: If there is a UE signaling impact, the gNB-DU determines the end of the UL SDT transaction based on new signaling information from the UE. ● In some implementations, if the UE determines that the current UL SDT data packet is the last UL SDT data packet in the buffer and no further data is expected to arrive in the buffer soon, the UE sends information in the SDT transmission to the target gNB-DU, for example via a MAC CE or RLC message indicating the UL SDT transaction end. At 805, the target gNB-DU sends a UL SDT transaction completion indication to the target gNB-CU-CP via F1-C. o In some implementations, the indication is "F1: UL SDT Transfer" with an IE indicating "End of UL SDT" or the like. o In some implementations, the target gNB-DU sends a UE Inactivity Notification message including an IE with "End of UL SDT" to the target gNB-CU-CP. At 806, in response to receiving the UL SDT transaction end indication, the target gNB-CU-CP informs the anchor gNB-CU-CP that it will send an RRC_RELEASE to conclude the UL SDT procedure. o The XnAP_UE_RELEASE or XnAP_CONTEXT_RETRIEVE_REQUEST messages can be reused or extended for this. In some implementations, a new XnAP message can be used. o The target gNB CU-CP stores the UE context (i.e., the UE's I-RNTI) during an SDT procedure where anchor relocation is not performed. At 807 and 808, the anchor gNB-CU-CP may release the DL tunnel to the anchor gNB-CU-UP and the target gNB-DU after delivery of any remaining DL data. At 809, the anchor gNB-CU-CP generates an RRC_RELEASE that terminates the SDT transaction and appends the RRC_RELEASE to a new or existing XnAP message (e.g., an XnAP Release message) to the target gNB-CU-CP. At 810, the target gNB-CU-CP may release the target gNB-DU by adding an RRC_RELEASE to the UE. o In some implementations, a different message is used for this. o In some implementations, the gNB-DU and gNB-CU-CP discard the UE context at this point. At 811, an RRC_RELEASE message is sent to the UE, the RRC message indicating (requesting) the closure of the SDT procedure.
[0053] Figure 9 is a sequence diagram showing Scenario 1, Alternative B, i.e., gNB-DU decision 900 of UL SDT transaction termination using inter-gNB SDT without anchor relocation, and the notification path via the UP tunnel including anchor gNB-CU-UP to anchor gNB-CU-CP. At 901 and 902, the target gNB-DU receives the first SDT data packet from the UE, communicates with the target gNB-CU-CP via F1-C to obtain the UE context (e.g., UL TEID address), and establishes a DL+UL forwarding F1-U tunnel for the UE's SDT DRB to the anchor gNB-CU-UP. o Note: The DU establishes a UE context using the received I-RNTI and maintains the UE context until the end of the SDT procedure. At 903, the UE may perform one or more subsequent UL SDT data packet transmissions to the target gNB-DU as part of the same SDT procedure, i.e. without switching to RRC_CONNECTED. The first SDT data packet may have already indicated, e.g. via BSR, that there is additional data in the buffer, or the UE may indicate that there is more data after the first SDT transmission. At 904, for each SDT data packet, the target gNB-DU determines, based on information provided by the UE or using local information, whether the current UL SDT data packet is the last of an ongoing UL SDT transaction for the UE. o When this assessment is based on information provided by the UE, there are two variants depending on whether UE signaling is impacted or not. ◆ Variant 1: No UE signaling impact, i.e., the target gNB-DU determines the end of the UL SDT transaction based on previous information from the UE. ● The UE may provide the BSR to the network. ● In some implementations, a BSR index indicating a predefined value (eg, 0 bytes) may convey an indication that the UE has chosen to close an ongoing SDT procedure. ● In some implementations, if the UE does not include a BSR, but there is no room for a BSR, it may convey an indication that the UE has chosen to close an ongoing SDT procedure. ◆ Variant 2: If there is a UE signaling impact, the gNB-DU determines the end of the UL SDT transaction based on new signaling information from the UE. ● In some implementations, if the UE determines that the current UL SDT data packet is the last UL SDT data packet in the buffer and data is not expected to arrive in the buffer soon, the UE sends information in the SDT transmission to the target gNB-DU, for example via a MAC CE or RLC message indicating the UL SDT transaction end. At 905, the target gNB-DU indicates a terminate UL SDT data packet indication when transporting UL data to the anchor gNB-CU-UP via a User Plane (UP) Frame Protocol PDU (e.g., TS38.425). At 906 and 907, the anchor gNB-CU-UP receives the terminate UL SDT data packet indication and sends any pending DL data to the target gNB-DU, after which it signals the end of the UL SDT transaction to the anchor gNB-CU-CP, and its own resources are then released. At 908, the anchor gNB-CU-CP transmits a new message to the target gNB-CU-CP embedding the RRC_RELEASE message to be sent to the UE. At 909 and 910, the target gNB-CU-CP forwards the received RRC_RELEASE to the UE via the target gNB-DU.
[0054] Figure 10 is a sequence diagram showing gNB-DU determination 1000 of terminated UL data using inter-gNB SDT with anchor relocation and the notification path via the CP interface to the target gNB-CU-CP. At 1001 and 1002, the target gNB-DU receives the first SDT data packet from the UE, communicates with the target gNB-CU-CP via F1-C to obtain the UE context (e.g., UL TEID address), and establishes a DL+UL forwarding F1-U tunnel for the UE's SDT DRB to the target gNB-CU-UP. In 1003, the UE may perform one or more subsequent UL SDT data packet transmissions to the target gNB-DU as part of the same SDT procedure, i.e. without switching to RRC_CONNECTED. The first SDT data packet may have already indicated, e.g. via BSR, that there is additional data in the buffer, or the UE may indicate that there is more data after the first SDT transmission. At 1004, for each SDT data packet, the target gNB-DU determines, based on information provided by the UE or using local information, whether the current UL SDT data packet is the last of an ongoing UL SDT transaction for the UE. o When this assessment is based on information provided by the UE, there are two variants depending on whether UE signaling is impacted or not. ◆ Variant 1: No UE signaling impact, i.e., the target gNB-DU determines the end of the UL SDT transaction based on previous information from the UE. ● The UE may provide the BSR to the network. ● In some implementations, a BSR index indicating a predefined value (eg, 0 bytes) may convey an indication that the UE has chosen to close an ongoing SDT procedure. ● In some implementations, if the UE does not include a BSR, but there is no room for a BSR, it may convey an indication that the UE has chosen to close an ongoing SDT procedure. ◆ Variant 2: If there is a UE signaling impact, the gNB-DU determines the end of the UL SDT transaction based on new signaling information from the UE. ● In some implementations, if the UE determines that the current UL SDT data packet is the last UL SDT data packet in the buffer and data is not expected to arrive in the buffer soon, the UE sends information in the SDT transmission to the target gNB-DU, for example via a MAC CE or RLC message indicating the UL SDT transaction end. At 1005, the target gNB-DU sends a UL SDT transaction completion indication to the target gNB-CU-CP via F1-C. o In some implementations, the indication is "F1: UL SDT Transfer" with an IE indicating "End of UL SDT" or the like. o In some implementations, the target gNB-DU sends a UE Inactivity Notification message including an IE with "End of UL SDT" to the target gNB-CU-CP. At 1006 and 1007, the target gNB-CU-CP may release the DL tunnels to the target gNB-CU-UP and target gNB-DU after delivery of any remaining DL data by the target gNB-CU-UP. At 1008, the target gNB-CU-CP may release the target gNB-DU by adding an RRC_RELEASE to the UE. o In some implementations, a different message is used for this. o In some implementations, the gNB-DU and gNB-CU-CP discard the UE context at this point. At 1009, an RRC_RELEASE message is sent to the UE, the RRC message indicating (requesting) the closure of the SDT procedure.
[0055] Figure 11 is a sequence diagram showing the final UL data determination of gNB-DU using inter-gNB SDT with anchor relocation and the notification path to target gNB-CU-CP via the UP tunnel to target gNB-CU-UP. At 1101 and 1102, the target gNB-DU receives the first SDT data packet from the UE, communicates with the target gNB-CU-CP via F1-C to obtain the UE context (e.g., UL TEID address), and establishes a DL+UL forwarding F1-U tunnel for the UE's SDT DRB to the target gNB-CU-UP. At 1103, the UE may perform one or more subsequent UL SDT data packet transmissions to the target gNB-DU as part of the same SDT procedure, i.e. without switching to RRC_CONNECTED. The first SDT data packet may have already indicated, e.g. via BSR, that there is additional data in the buffer, or the UE may indicate that there is more data after the first SDT transmission. At 1104, for each SDT data packet, the target gNB-DU determines, based on information provided by the UE or using local information, whether the current UL SDT data packet is the last of an ongoing UL SDT transaction for the UE. o When this assessment is based on information provided by the UE, there are two variants depending on whether UE signaling is impacted or not. ◆ Variant 1: No UE signaling impact, i.e., the target gNB-DU determines the end of the UL SDT transaction based on previous information from the UE. ● The UE may provide the BSR to the network. ● In some implementations, a BSR index indicating a predefined value (eg, 0 bytes) may convey an indication that the UE has chosen to close an ongoing SDT procedure. ● In some implementations, if the UE does not include a BSR, but there is no room for a BSR, it may convey an indication that the UE has chosen to close an ongoing SDT procedure. ◆ Variant 2: If there is a UE signaling impact, the gNB-DU determines the end of the UL SDT transaction based on new signaling information from the UE. ● In some implementations, if the UE determines that the current UL SDT data packet is the last UL SDT data packet in the buffer and data is not expected to arrive in the buffer soon, the UE sends information in the SDT transmission to the target gNB-DU, for example via a MAC CE or RLC message indicating the UL SDT transaction end. At 1105, the target gNB-DU indicates a terminate UL SDT data packet indication when transporting UL data to the target gNB-CU-UP via a User Plane (UP) Frame Protocol PDU (e.g., TS38.425). At 1106 and 1107, the target gNB-CU-UP receives the Terminate UL SDT data packet indication and sends any pending DL data to the target gNB-DU, after which it signals the end of the UL SDT transaction to the target gNB-CU-CP, and its own resources are then released. At 1108 and 1109, the target gNB-CU-CP forwards the received RRC_RELEASE to the UE via the target gNB-DU.
[0056] Example 1-1: Figure 12 is a flowchart showing an example method 1200 for implementing the improved technique. Operation 1210 includes receiving, by a distributed unit (target gNB-DU) of a target base station, a UL SDT packet from a user equipment (UE) in a wireless network during a multi-shot SDT transaction. Operation 1220 includes determining whether the UL SDT packet is a terminal UL SDT packet. Operation 1230 includes, in response to determining that the UL SDT packet is a terminal UL SDT packet, generating termination data indicating an end of the multi-shot SDT transaction, and transmitting the termination data along a path in the wireless network to a central unit (gNB-CU) of the base station, where the termination data indicates an end of the SDT transaction.
[0057] Example 1-2: According to an implementation example of Example 1-1, the base station is an anchor (anchor gNB) different from the target gNB, the anchor gNB is the final serving gNB for the UE, and the path within the wireless network terminates at the control plane of the central unit of the anchor base station (anchor gNB-CU-CP).
[0058] Example 1-3: According to an implementation of the example of Example 1-2, the route within the wireless network terminates at the anchor gNB-CU-CP via the target gNB-CU-CP.
[0059] Example 1-4: According to an implementation form of the example of Example 1-3, after transmitting the termination data, it further includes receiving Radio Resource Control Release (RRC_RELEASE) data from the anchor gNB-CU-CP via the target gNB-CU-CP in the XnAP message, indicating that the multi-shot SDT transaction has been closed, and transmitting the RRC_RELEASE data to the UE.
[0060] EXAMPLE 1-5: According to an implementation of any of the examples of Examples 1-3 and 1-4, determining whether the UL SDT packet is a terminating UL SDT packet is based on information provided by the UE.
[0061] Example 1-6: According to an implementation of the example of Example 1-5, further including receiving buffer status report (BSR) data from the UE, the BSR data including an index indicating a condition under which the UL SDT packet is determined to be a terminated UL SDT packet.
[0062] Example 1-7: According to an implementation form of any of the examples of Examples 1-4 to 1-6, determining whether a UL SDT packet is a terminal UL SDT packet is based on a threshold time lapse since receiving the previous UL SDT data packet.
[0063] Example 1-8: According to an implementation form of any of the examples from Example 1-2 to Example 1-7, the route within the wireless network terminates at the anchor gNB-CU-CP via the anchor gNB-CU-UP.
[0064] Example 1-9: According to implementation forms of the examples of Examples 1-2 to 1-8, the method further includes receiving downlink (DL) data from the anchor gNB-CU-UP, receiving radio resource control release (RRC_RELEASE) data from the anchor gNB-CU-CP indicating that the multi-shot SDT transaction has been closed, and transmitting the RRC_RELEASE data to the UE after transmitting the DL data packet.
[0065] Example 1-10: According to an implementation form of any of the examples of Examples 1-1 to 1-9, the gNB is a target gNB, and the path within the wireless network terminates at the control plane of the central unit of the target base station (target gNB-CU-CP).
[0066] Example 1-11: According to an implementation form of any of Examples 1-1 to 1-10, the route within the wireless network terminates at the target gNB-CU-CP via the target gNB-CU-UP.
[0067] Example 1-12: According to an implementation of the example of Example 1-11, after determining that the UL SDT data packet is a terminal UL SDT packet, further includes receiving Radio Resource Control Release (RRC_RELEASE) data from the target gNB-CU-CP indicating that the multi-shot SDT transaction has ended, and transmitting the RRC_RELEASE data to the UE.
[0068] Example 1-13: According to an implementation form of any of Examples 1-10 to 1-12, the route within the wireless network terminates directly from the target gNB-DU to the target gNB-CU-CP.
[0069] Example 1-14: According to an implementation of the example of Example 1-10, further including receiving downlink (DL) data from the target gNB-CU-UP, receiving radio resource control release (RRC_RELEASE) data from the target gNB-CU-CP indicating that the multi-shot SDT transaction has ended, and transmitting the RRC_RELEASE data to the UE after transmitting the received DL data packet.
[0070] Example 1-15: According to an implementation form of any of Examples 1-1 to 1-14, after receiving the initial UL SDT data packet, the method further includes receiving data from a control plane of a central unit of the target base station (target gNB-CU-CP) indicating a path along which the terminated data will be transmitted in the wireless network.
[0071] EXAMPLE 1-16: According to an implementation of the example of Example 1-14, further including receiving an inactive radio network temporary identifier (I-RNTI), generating a temporary UE context based on the I-RNTI, and storing the temporary UE context for the duration of the multi-shot SDT transaction.
[0072] Example 1-17: According to an implementation of the examples of Examples 1-15 and 1-16, further including receiving Radio Resource Control Release (RRC_RELEASE) data from the target gNB-CU-CP indicating that the multi-shot SDT transaction has ended, transmitting the RRC_RELEASE data to the UE, and discarding the temporary UE context after transmitting the RRC_RELEASE data to the UE.
[0073] Example 1-18: According to the implementation form of any of the examples of Examples 1-1 to 1-17, the UL SDT packet can be one of a UL SDT user plane packet, a UL SDT control plane packet, or a combination of a user plane packet and a control plane packet.
[0074] Example 1-19: According to an implementation form of any of Examples 1-1 to 1-18, further including not generating termination data in response to determining that the UL SDT packet is not a terminal UL SDT packet.
[0075] Example 1-20: An apparatus having means for carrying out any of the methods of Examples 1-1 to 1-18.
[0076] Example 1-21: A computer program product including a non-transitory computer-readable storage medium storing executable code configured, when executed by at least one data processing device, to cause the at least one data processing device to perform any of the methods of Examples 1-1 to 1-18.
[0077] 13 is a flowchart illustrating a method 1300. Operation 1310 includes transmitting one or more uplink (UL) small data transmission (SDT) packets of a multi-shot SDT transaction by a user equipment (UE) to a base station distributed unit (gNB-DU). Operation 1320 includes, after transmitting the one or more UL SDT packets, receiving radio resource control release (RRC_RELEASE) data from the gNB-DU indicating that the multi-shot SDT transaction has ended, where the end of the multi-shot SDT transaction is determined by the gNB-DU.
[0078] Example 2-2: According to an implementation of the example of Example 2-1, further including initiating a multi-shot SDT transaction in response to obtaining the payload in the buffer of the UE.
[0079] Example 2-3: According to an implementation of the example of Example 2-2, further including transmitting an indication that the UE has elected to terminate the multi-shot SDT transaction.
[0080] Example 2-4: According to an implementation of any of the examples of Examples 2-2 to 2-3, transmitting the indication that the UE has selected is transmitted in response to at least one of determining a last user plane data packet or determining that no further user plane data packets are expected for a subsequent period of time.
[0081] Example 2-5: According to an implementation of the example of Example 2-3, further including transmitting a Buffer Status Report (BSR) to the target gNB-DU in the UL SDT, the BSR including an index indicating a condition under which the UL SDT data packet is determined to be a terminating UL SDT data packet, the condition indicating the end of the multi-shot SDT transaction.
[0082] Example 2-6: According to the example implementation of Example 2-5, the index of the BSR indicates that there is no additional data in the UE's buffer.
[0083] EXAMPLE 2-7: According to an implementation of the example of Example 2-6, the indication is transmitted in a radio link channel (RLC) PDU.
[0084] EXAMPLE 2-8: According to an implementation of the example of Example 2-6, the indication is transmitted in a media access channel (MAC) control element (CE).
[0085] Example 2-9: An apparatus having means for carrying out any of the methods of Examples 2-1 to 2-8.
[0086] Example 2-10: A computer program product including a non-transitory computer-readable storage medium storing executable code configured, when executed by at least one data processing device, to cause the at least one data processing device to perform any of the methods of Examples 2-1 to 2-8.
[0087] List of example abbreviations: AMF Access and Mobility Management Features CP Control Plane CU Centralized Unit DU Distributed Unit NR new radio gNB 5G Node B I-RNTI Inactive Radio Network Temporary Identifier Message Authentication Code for MAC-I Integrity NCC Next Hop Chain Count NG-RAN Next Generation Radio Access Network NR new radio UP User Plane RAN Radio Access Network RNA RAN Notification Area RNAU RAN Notification Area Update RRC Radio Resource Control Protocol SDT Small Data Transmission UE User Equipment UP User Plane Xn / Xn network interface term: - NR Cell Global Identifier (NCGI): Used to globally identify an NR cell. The NCGI is constructed from the PLMN identity to which the cell belongs and the NR Cell Identity (NCI) of the cell. - gNB Identifier (gNB ID): Used to identify a gNB within a PLMN. The gNB ID is included in the NCI of the cell. - Global gNB ID: Used to identify the gNB globally. The global gNB ID is constructed from the PLMN identity to which the gNB belongs and the gNB ID. The MCC and MNC are the same as those contained in the NCGI. - Global gNB ID = PLMN ID + gNB ID - Full I-RNTI: The full I-RNTI, 40 bits in length, that may be included in a 64-bit RRCResumeRequest1 message via common control channel 1. - Short I-RNTI: A short I-RNTI of length 24 bits that can be included in a 48-bit RRC Resume Request message common control channel.
[0088] 14 is a block diagram of a wireless station (e.g., AP, BS, eNB, UE, or user device) 1400 according to an example implementation. The wireless station 1400 may include, for example, one or two RF (radio frequency) or wireless transceivers 1402A, 1402B, each including a transmitter for transmitting signals and a receiver for receiving signals. The wireless station also includes a processor or control unit / entity (controller) 1404 for executing instructions or software and controlling the transmission and reception of signals, and a memory 1406 for storing data and / or instructions.
[0089] The processor 1404 may also make decisions or determinations, generate frames, packets, or messages for transmission, decode received frames or messages for further processing, and perform other tasks or functions described herein. The processor 1404 may be a baseband processor and may, for example, generate messages, packets, frames, or other signals for transmission via the wireless transceiver 1402 (1402A or 1402B). The processor 1404 may control the transmission of signals or messages over a wireless network and may control the reception of signals, messages, etc. over a wireless network (e.g., after being downconverted by the wireless transceiver 1402). The processor 1404 may be programmable and capable of executing software or other instructions stored in memory or other computer media to perform various tasks and functions described above, such as one or more of the tasks or methods described above. The processor 1404 may, for example, be (or include) hardware, programmable logic, a programmable processor executing software or firmware, and / or any combination thereof. Using other terminology, the processor 1404 and the transceiver 1402 together may be considered, for example, a wireless transmitter / receiver system.
[0090] Additionally, with reference to FIG. 14, a controller (or processor) 1408 may execute software and instructions and may provide overall control for the station 1400, may provide control for other systems not shown in FIG. 14, such as controlling input / output devices (e.g., display, keypad), and / or may execute software for one or more applications that may be provided in the wireless station 1400, such as, for example, an email program, an audio / video application, a word processor, a voice-over-IP application, or other application or software.
[0091] Additionally, a storage medium may be provided containing stored instructions that, when executed by a controller or processor, may cause the processor 1404, or another controller or processor, to perform one or more of the functions or tasks described above.
[0092] According to another example implementation, the RF or wireless transceiver 1402A / 1402B may receive signals or data and / or transmit or transmit signals or data. The processor 1404 (and possibly the transceiver 1402A / 1402B) may control the RF or wireless transceiver 1402A or 1402B to receive, transmit, broadcast, or transmit signals or data.
[0093] The embodiments are nevertheless not limited to the system shown as an example, but those skilled in the art may apply the solution to other communication systems. Another example of a suitable communication system is the 5G concept. It is assumed that the network architecture of 5G will be very similar to that of LTE-Advanced. 5G uses multiple-input multiple-output (MIMO) antennas, many more base stations or nodes than LTE (the so-called small cell concept) (including macro sites that work in conjunction with smaller stations and possibly also employ various radio technologies for better coverage and enhanced data rates).
[0094] It should be understood that future networks will almost certainly utilize network function virtualization (NFV), a network architecture concept that proposes virtualizing network node functions into "building blocks" or entities that can be operatively connected or linked together to provide services. A virtualized network function (VNF) may comprise one or more virtual machines that run computer program code using standard or general-purpose servers rather than customized hardware. Cloud computing or data storage may also be utilized. In wireless communications, this may mean node operations that may be performed, at least in part, in a server, host, or node operatively coupled to a remote radio head. Node operations may also be distributed among multiple servers, nodes, or hosts. It should also be understood that the distribution of work between core network operations and base station operations may differ from that of LTE or perhaps even be absent.
[0095] Implementations of the various techniques described herein may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or combinations thereof. Implementations may be implemented as a computer program product, i.e., as a computer program tangibly embodied in an information carrier, e.g., a machine-readable storage device or a propagated signal, for execution by or to control the operation of a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers. Implementations may also be provided on a computer-readable medium or computer-readable storage medium, which may be a non-transitory medium. Implementations of the various techniques may also include implementations provided via a transitory signal or medium and / or program and / or software implementations downloadable via the Internet or other networks, either wired and / or wireless. Additionally, implementations may be provided via machine-type communications (MTC) and even via the Internet of Things (IoT).
[0096] The computer program may be in source code form, object code form, or some intermediate form, and may be stored on some kind of carrier, distribution medium, or computer-readable medium, which may be any entity or device capable of carrying a program. Such carriers include, for example, recording media, computer memory, read-only memory, optical-electronic and / or electrical carrier wave signals, telecommunications signals, and software distribution packages. Depending on the processing power required, the computer program may be executed in a single electronic digital computer or distributed among several computers.
[0097] Furthermore, implementations of various techniques described herein may use cyber-physical systems (CPSs) (systems of collaborating computer elements that control physical entities). CPSs may enable the implementation and utilization of vast amounts of interconnected ICT devices (sensors, actuators, processors, microcontrollers, ...) embedded in physical objects at different locations. Mobile cyber-physical systems, where the physical systems in question have inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronic devices transported by humans or animals. The increasing popularity of smartphones has sparked interest in the area of mobile cyber-physical systems. Thus, various implementations of techniques described herein may be provided via one or more of these technologies.
[0098] Computer programs, such as those described above, can be written in any type of programming language, including compiled or interpreted languages, and can be implemented in any form, including as a stand-alone program or as a module, component, subroutine, or other unit or component suitable for use in a computing environment. A computer program can be implemented to be executed on one computer or on multiple computers at one site or distributed across multiple sites and interconnected by a communication network.
[0099] The method steps may be performed by one or more programmable processors executing computer programs or computer program portions to perform functions by manipulating input data and generating output. The method steps may also be performed by, and an apparatus may be implemented as, a special purpose logic circuitry device, for example an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).
[0100] Processors suitable for executing a computer program include, by way of example, both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer, chip, or chipset. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory, or both. Elements of a computer may include at least one processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer also includes one or more mass storage devices for storing data, such as, for example, magnetic, magneto-optical, or optical disks, or may be operatively coupled to receive data from, or transfer data to, one or more mass storage devices, or both. Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including, by way of example, semiconductor memory devices (such as, for example, EPROM, EEPROM, and flash memory devices), magnetic disks (such as, for example, internal hard disks or removable disks), magneto-optical disks, and CD-ROM and DVD-ROM disks. The processor and memory may be supplemented by, or incorporated in, special-purpose logic circuitry.
[0101] To provide for user interaction, implementations may run on a computer having a display device, e.g., a cathode ray tube (CRT) or liquid crystal display (LCD) monitor, for displaying information to the user, and a user interface, such as a keyboard and a pointing device, e.g., a mouse or trackball, through which the user can provide input to the computer. Other types of devices can be used to provide for user interaction as well; for example, feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback, and input from the user can be received in any form, including acoustic, speech, or tactile input.
[0102] An implementation may be implemented in a computing system that includes back-end components such as, for example, a data server, or includes middleware components such as, for example, an application server, or includes front-end components such as, for example, a client computer having a graphical user interface or a web browser through which a user can interact with the implementation, or includes any combination of such back-end, middleware, or front-end components. The components may be interconnected by any form or medium of digital data communication, such as, for example, a communication network. Examples of communication networks include local area networks (LANs) and wide area networks (WANs) such as, for example, the Internet.
[0103] While certain features of the described implementations have been shown as described herein, many modifications, substitutions, changes, and equivalents will now occur to those skilled in the art. It is therefore to be understood that the appended claims are intended to cover all such modifications and changes as fall within the true spirit of the various embodiments.
Claims
1. An apparatus for a distributed unit (target gNB-DU) of a target gNB, comprising: at least one processor; at least one memory containing computer program code; Equipped with The at least one memory and the computer program code include at least: receiving, by the target gNB-DU, an uplink (UL) small data transmission (SDT) packet from a user equipment (UE) in a wireless network during a multi-shot small data transmission (SDT) transaction; determining whether the UL SDT packet is a terminating uplink (UL) small data transmission (SDT) packet; In response to determining that the UL SDT packet is the terminating UL SDT packet, generating end data indicating an end of the multi-shot SDT transaction; and Transmitting the termination data along a path within the wireless network to a base station central unit (gNB-CU), wherein the termination data indicates an end of the multi-shot SDT transaction, the base station is an anchor gNB different from the target gNB, and the anchor gNB is a final serving gNB for the UE. and causing the device to: The path within the wireless network terminates in the control plane of the central unit of the anchor gNB (anchor gNB-CU-CP) via the control plane of the central unit of the target gNB (target gNB-CU-CP); Device.
2. The at least one memory and the computer program code include at least: After transmitting the termination data, receiving radio resource control release (RRC_RELEASE) data from the anchor gNB-CU-CP via the target gNB-CU-CP in an XnAP message, the radio resource control release (RRC_RELEASE) data indicating that the multi-shot SDT transaction has been closed; transmitting the RRC_RELEASE data to the UE; The apparatus of claim 1 , further configured to cause the apparatus to:
3. The apparatus of claim 1 , wherein the determining whether the UL SDT packet is a terminating UL SDT packet is based on information provided by the UE.
4. The at least one memory and the computer program code include at least: receiving buffer status report (BSR) data from the UE, the BSR data including an index indicating a condition under which a UL SDT packet is determined to be a terminated UL SDT packet; The apparatus of claim 3 , further configured to cause the apparatus to:
5. The apparatus of claim 1 , wherein the determining whether the UL SDT packet is a terminal UL SDT packet is based on a threshold amount of time elapsed since receiving a previous UL SDT packet.
6. The device of claim 1 , wherein the route within the wireless network terminates at the anchor gNB-CU-CP via the anchor gNB-CU-UP.
7. The at least one memory and the computer program code include at least: Receiving downlink (DL) data from the anchor gNB-CU-UP; receiving radio resource control release (RRC_RELEASE) data from the anchor gNB-CU-CP indicating that the multi-shot SDT transaction has been closed; After transmitting the DL data packet, transmitting the RRC_RELEASE data to the UE. The apparatus of claim 1 , further configured to cause the apparatus to:
8. The at least one memory and the computer program code include at least: After receiving the UL SDT packet of the multi-shot SDT transaction, receiving data from a control plane of a central unit (target gNB-CU-CP) of the target base station indicating a path along which the terminated data will be transmitted within the wireless network. The apparatus of claim 1 , further configured to cause the apparatus to:
9. The at least one memory and the computer program code include at least: receiving an inactive wireless network temporary UE identifier; generating a temporary UE context based on the inactive radio network temporary UE identifier; storing the temporary UE context for the duration of the multi-shot SDT transaction; The apparatus of claim 8 , further configured to cause the apparatus to:
10. The at least one memory and the computer program code include at least: receiving radio resource control release (RRC_RELEASE) data from the target gNB-CU-CP indicating that the multi-shot SDT transaction has ended; transmitting the RRC_RELEASE data to the UE; Discarding the temporary UE context after transmitting the RRC_RELEASE data to the UE; The apparatus of claim 9 , further configured to cause the apparatus to:
11. 10. The apparatus of claim 1, wherein the UL SDT packets can be one of UL SDT user plane packets, UL SDT control plane packets, or a combination of user plane packets and control plane packets.
12. The at least one memory and the computer program code include at least: and not generating the termination data in response to the determining that the UL SDT data packet is not the termination UL SDT data packet. The apparatus of claim 1 , further configured to cause the apparatus to:
13. 1. An apparatus for a user equipment (UE), comprising: at least one processor; at least one memory containing computer program code; Equipped with The at least one memory and the computer program code include at least: Transmitting one or more uplink (UL) small data transmission (SDT) packets of a multi-shot small data transmission (SDT) transaction by the UE to a base station distributed unit (gNB-DU); and receiving, after transmitting the one or more of the UL SDT packets, radio resource control release (RRC_RELEASE) data from the gNB-DU indicating that the multi-shot SDT transaction has terminated, the termination being based on generating termination data and transmitting the termination data along a path within a wireless network; Receiving that the path in the wireless network terminates at the control plane of the central unit of the anchor gNB (anchor gNB-CU-CP) via the control plane of the central unit of the target gNB (target gNB-CU-CP), the base station is an anchor gNB different from the target gNB, and the anchor gNB is a final serving gNB for the UE. An apparatus configured to cause the apparatus to perform the following.
14. The at least one memory and the computer program code comprise at least: Initiating the multi-shot SDT transaction in response to obtaining user plane packets in a buffer of the UE. The apparatus of claim 13 , further configured to cause the apparatus to:
15. The at least one memory and the computer program code include at least: transmitting an indication that the UE has chosen to terminate the multi-shot SDT transaction. The apparatus of claim 14 , further configured to cause the apparatus to:
16. 16. The apparatus of claim 15, wherein transmitting the indication that the UE has opted is transmitted in response to at least one of determining a last user plane data packet or determining that no further user plane data packets are expected for a subsequent period of time.
17. The at least one memory and the computer program code include at least: Transmitting a Buffer Status Report (BSR) to the gNB-DU in an UL SDT, the BSR including an index indicating a condition under which a UL SDT packet is determined to be a terminal UL SDT packet, the condition indicating the end of the multi-shot SDT transaction. The apparatus of claim 15 , further configured to cause the apparatus to:
18. 18. The apparatus of claim 17, wherein the index of the BSR indicates that there is no additional data in the buffer of the UE.
19. 16. The apparatus of claim 15, wherein the indication is transmitted in a Radio Link Channel (RLC) PDU.
20. The apparatus of claim 15 , wherein the indication is transmitted in a media access channel (MAC) control element (CE).
21. An apparatus for an anchor base station central unit control plane (anchor gNB-CU-CP), comprising: at least one processor; at least one memory containing computer program code; Equipped with The at least one memory and the computer program code include at least: receiving, by the anchor gNB-CU-CP, end data indicating the end of a small data transmission (SDT) transaction; generating radio resource control release (RRC_RELEASE) data; and transmitting the RRC_RELEASE data to a user equipment (UE); An apparatus configured to cause the apparatus to perform the following.
22. The at least one memory and the computer program code configured to cause the device to receive the termination data include at least: receiving the termination data from at least one of a target gNB-CU-CP and an anchor base station central unit user plane (gNB-CU-UP); 22. The apparatus of claim 21, further configured to cause the apparatus to:
23. The at least one memory and the computer program code configured to cause the device to transmit the RRC_RELEASE data include at least: transmitting the RRC_RELEASE data to the target CU-CP via at least one of the XnAP messages; 22. The apparatus of claim 21, further configured to cause the apparatus to:
24. the at least one memory and the computer program code In the target gNB-CU-CP, receiving termination data indicating the end of the SDT transaction, generating RRC release data and transmitting it to the UE; or At the target gNB-CU-CP, receiving end data indicating the end of the SDT transaction and propagating the end data to the anchor gNB-CU-CP.
22. The apparatus of claim 21, further configured to cause the apparatus to perform at least one of:
25. The at least one memory and the computer program code configured to cause the device to receive termination data include at least: Receiving the termination data from a base station distributed unit (gNB-DU).
25. The apparatus of claim 24, further configured to cause the apparatus to:
26. The at least one memory and the computer program code configured to cause the device to transmit the RRC_RELEASE data include at least: Transmitting the RRC release data to the DU via an F1-C message.
22. The apparatus of claim 21, further configured to cause the apparatus to:
27. Receiving, by a distributed unit (target gNB-DU) of a target gNB, an uplink (UL) small data transmission (SDT) packet from a user equipment (UE) in a wireless network during a multi-shot small data transmission (SDT) transaction time; determining whether the UL SDT packet is a terminating uplink (UL) small data transmission (SDT) packet; In response to determining that the UL SDT packet is the terminating UL SDT packet, generating end data indicating the end of the multi-shot SDT transaction; transmitting the termination data along a path within the wireless network to a base station central unit (gNB-CU), the termination data indicating the termination of the SDT transaction, the base station being an anchor gNB different from the target gNB, the anchor gNB being a final serving gNB for the UE; Including, The path within the wireless network terminates in the control plane of the central unit of the anchor gNB (anchor gNB-CU-CP) via the control plane of the central unit of the target gNB (target gNB-CU-CP); method.
28. A non-transitory computer readable storage medium storing executable code configured, when executed by at least one data processing device, to cause the at least one data processing device to perform a method according to any of claims 1 to 27.
29. Apparatus comprising means for carrying out the method according to any one of claims 1 to 27.
Citation Information
Patent Citations
Mobility management for inter-gnb (next generation node-b) handover in new radio (NR) systems
US20190342800A1
Radio resource control resume wthout contex fetch
US20200037210A1
Signaling for inactive small data transmission without path switching
WO2020191059A1