Method and apparatus for small data transmission (SDT)
By storing user equipment-specific uplink small data transmission context in network nodes, anchor relocation is avoided, thus solving the signaling overhead and power consumption problems of small data transmission in the RRC_INACTIVE state of the 5G NR system and achieving efficient small data transmission.
Patent Information
- Application Number
- CN202210770651.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2021-06-30
- Filing Date
- 2022-06-30
- Publication Date
- 2026-11-06
- Estimated Expiration
- 2042-06-30
AI Technical Summary
In existing 5G NR systems, user equipment in the RRC_INACTIVE state needs to frequently switch to the RRC_CONNECTED state when transmitting small data, resulting in unnecessary power consumption and signaling overhead, which affects transmission efficiency.
By storing user equipment-specific uplink small data transmission contexts in network nodes, anchor relocation is avoided, enabling multiple small data transmissions and reducing signaling overhead and power consumption.
It improves the efficiency of small data transmission for user equipment in the RRC_INACTIVE state, reduces signaling overhead and power consumption, and meets the NR system's requirement for efficient and flexible transmission of low-throughput short data bursts.
Smart Images

Figure CN115551008B_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims priority to IN provisional application No. 202141029448, filed on June 30, 2021. The entire contents of that earlier application are incorporated herein by reference. Technical Field
[0003] Some example embodiments may generally relate to communications, including mobile or wireless telecommunication systems (such as Long Term Evolution (LTE) or 5G radio access technologies or New Radio (NR) access technologies) or other communication systems. For example, some example embodiments may generally relate to systems and / or methods for signaling for improved Small Data Transmission (SDT). Background Technology
[0004] Examples of mobile or wireless telecommunications systems can include Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Network (UTRAN), Evolved UTRAN (E-UTRAN) for Long Term Evolution (LTE), LTE-A Advanced, MulteFire, LTE-APro, and / or 5G or New Radio (NR) access technologies. 5G wireless systems refer to next-generation (NG) radio systems and network architectures. 5G systems are primarily built on 5G New Radio (NR), but 5G (or NG) networks can also be built on E-UTRA radio. NR is estimated to provide bit rates of 10-20 Gbit / s or higher and can support at least service categories such as enhanced mobile broadband (eMBB), ultra-reliable low-latency communications (URLLC), and massive machine-type communications (mMTC). NR promises to provide ultra-wideband and ultra-robust low-latency connectivity and massive networks to support the Internet of Things (IoT). As IoT and machine-to-machine (M2M) communication become increasingly prevalent, the need for networks capable of meeting the demands for low power consumption, low data rates, and long battery life will continue to grow. Next-Generation Radio Access Network (NG-RAN) represents the RAN for 5G, providing both NR and LTE (and Advanced LTE) radio access. Note that in 5G, nodes that can provide radio access to user equipment (i.e., similar to Node B, NB in UTRAN or Evolved NB, eNB in LTE) can be designated as Next-Generation NB (gNB) when built on NR radio, and as Next-Generation eNB (NG-eNB) when built on E-UTRA radio. Summary of the Invention
[0005] The subject matter of the independent claims is provided according to several aspects. Additional aspects are defined in the dependent claims. Embodiments not falling within the scope of the claims are to be interpreted as examples useful for understanding this disclosure.
[0006] In a first aspect, an exemplary embodiment of the present invention provides a method comprising: storing, at a first network node, a user equipment-specific uplink small data transmission context for a user equipment in a disconnected radio resource control state, wherein the first network node has previously initiated a small data transmission process without anchor relocation via a first network node or a second network node.
[0007] In another aspect of the invention, an exemplary embodiment of the invention provides an apparatus comprising: 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 together with the at least one processor to cause the apparatus to at least: store, at the apparatus, a user equipment-specific uplink small data transmission context for a user equipment in a disconnected radio resource control state, wherein the apparatus has previously initiated a small data transmission process without anchor relocation via the apparatus or another network node.
[0008] In another aspect of the invention, an exemplary embodiment of the invention provides an apparatus comprising: 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, together with the at least one processor, to enable the apparatus to at least: store, at the apparatus, a user equipment-specific downlink small data transmission context for a user equipment in a non-connected radio resource control state, the user equipment initiating a small data transmission procedure to a target network node; and assign one or more uplink tunnel endpoint identifiers for small data transmission procedures without anchor relocation. Attached Figure Description
[0009] To correctly understand the exemplary embodiments, reference should be made to the accompanying drawings, in which:
[0010] Figure 1A An example of an SDT type based on a 4-step RACH according to an embodiment is shown;
[0011] Figure 1B An example of an SDT type based on a 2-step RACH according to an embodiment is shown;
[0012] Figure 1C An example of a CG-based SDT type (without RACH) according to an embodiment is shown;
[0013] Figure 2 An example of an NR RRC state machine according to an embodiment is shown;
[0014] Figure 3 An example signaling diagram of an SDT without anchor relocation according to an embodiment is shown;
[0015] Figure 4A , Figure 4B and Figure 4C An example signaling diagram according to an example embodiment is shown, which depicts an example of an SDT with no anchor relocation and only uplink (UL) data;
[0016] Figure 5A , Figure 5B and Figure 5C Another example signaling diagram according to an example embodiment is shown, which depicts storing a UE-specific DL SDT context at the anchor CU-UP for use in an SDT with DL data;
[0017] Figure 6 An example flowchart of a method according to an example embodiment is shown;
[0018] Figure 7 An example flowchart of a method according to an example embodiment is shown;
[0019] Figure 8A An example block diagram of an apparatus according to an example embodiment is shown;
[0020] Figure 8B An example block diagram of a device according to an embodiment is shown; and
[0021] Figure 8C An example block diagram of an apparatus according to an example embodiment is shown. Detailed Implementation
[0022] It will be readily understood that components of certain example embodiments, as generally described and illustrated in the accompanying drawings, can be arranged and designed in a variety of different configurations. Therefore, the following detailed description of some example embodiments of systems, methods, apparatuses, and computer program products for signaling of improved small data transmission (SDT) is not intended to limit the scope of any particular embodiment, but rather to represent selected example embodiments.
[0023] Features, structures, or characteristics of the exemplary embodiments described throughout this specification may be combined in any suitable manner in one or more exemplary embodiments. For example, the use of the phrases "some embodiments," "some examples," or other similar language throughout this specification means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment. Therefore, the appearance of the phrases "some embodiments," "some examples," "other examples," or other similar language throughout this specification does not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more exemplary embodiments.
[0024] Furthermore, if necessary, the different functions or processes discussed below may be performed in different orders and / or simultaneously with each other. Additionally, if necessary, one or more of the described functions or processes may be optional or may be combined. Therefore, the following description should be considered as illustrating the principles and teachings of certain example embodiments, and not as limiting them.
[0025] As will be discussed in detail below, some example embodiments provide enhancements that enable UEs in a 5G NR Radio Resource Control (RRC) inactive state to perform Small Data Transmission (SDT) with more efficient backhaul signaling.
[0026] Currently, UEs in the RRC_INACTIVE state require infrequent small data transmissions, necessitating RRC connection recovery to switch the UE to an RRC connection state capable of transmitting small data. Consequently, the connection may be paused immediately after the data transmission, returning to the RRC_INACTIVE state. This can occur with every data transmission, leading to unnecessary UE power consumption and signaling overhead, as well as increased packet latency. However, NR systems require efficient and flexible handling of low-throughput short data bursts (e.g., see 3GPP TS 22.891) and support for efficient signaling mechanisms (e.g., signaling less than the payload) while minimizing overall signaling overhead.
[0027] Therefore, in 3GPP Release 17, efforts are being made to address the aforementioned inefficiencies (i.e., the signaling overhead and latency associated with the state transition from RRC_INACTIVE to RRC_CONNECTED for short data transmissions). The SDT functionality is important because the motivation for introducing the RRC_INACTIVE state itself in NR is to enable UEs with infrequent data transmissions to transition to a state with minimal signaling overhead and power consumption. Current objectives for enabling SDT in RRC inactive states include, for UL SDTs based on Random Access Channel (RACH) schemes (i.e., 2-step RACH and 4-step RACH): identifying a common procedure to enable UP data transmission of small data packets from the inactive (INACTIVE) state (e.g., using MSGA or MSG3), enabling a flexible payload size larger than the Release 16 Common Control Channel (CCCH) message size (which is currently likely used in inactive states of MSGA and MSG3 to support user plane (UP) data transmission in the uplink (UL)), and enabling context extraction and data forwarding (with and without anchor relocation) in inactive states of RACH-based solutions. For UL data transmission on pre-configured Physical Uplink Shared Channel (PUSCH) shared resources when the timing advance (TA) is valid (i.e., reuse of configured license type 1), the objectives include identifying the general procedure for SDT from inactive configured license type 1 resources, and enabling the configuration of configured license type 1 resources for SDT in inactive UL.
[0028] Based on the above objectives, three SDT types are defined as follows. A UE in RRC_Inactive state can transmit UL data as part of random access, i.e., "RA-SDT". For example, RA-SDT can include "4-step RA-SDT" and / or "2-step RA-SDT". In 4-step RA-SDT, Msg3 (PUSCH) of the 4-step random access procedure is used to transmit the SDT payload. In 2-step RA-SDT, MsgA (PUSCH) of the 2-step random access procedure is used to transmit the SDT payload. Certain conditions can be defined for the UE to check before allowing the use of the RA-SDT type, such as: the payload should belong to the SDT-permitted Data Radio Bearer (DRB) / Signaling Radio Bearer (SRB); the data volume should be below a defined data volume threshold; the (cell) Reference Signal Received Power (RSRP) should be above a threshold; and / or conditions based on traditional RSRP can be applied when selecting between 2-step and 4-step RACH SDT.
[0029] A UE in RRC_Inactive state can transmit UL data on a pre-configured PUSCH resource "CG-SDT". In this case, when the UE has a valid timing advance (TA) and other conditions are met, the UE can use a PUSCH resource based on configured authorization (CG) type 1 to transmit the SDT payload, i.e., without a random access procedure. The conditions for CG-SDT may include TA validity conditions and / or additional conditions that can be checked before the UE is allowed to use the allocated CG resource. Regarding TA validity conditions, before using the CG-SDT resource, the UE must ensure that its last received TA is valid by, for example, checking whether the TA timer (TAT) is running if a TAT is received; and checking whether (multiple) defined TA validity conditions are also valid. The latter may be based on an RSRP change to be compared with an RSRP change threshold, for example, similar to Early Data Transmission (EDT) based on LTE pre-configured UL resources (PUR). In addition to the above-mentioned TA validity conditions, other conditions to be checked before a UE is allowed to use the allocated CG resources can be defined, such as combinations of the following: the payload should belong to a DRB / SRB allowed for SDT; the data volume should be below a defined data volume threshold; the UE should be in the last serving cell in which the resources were allocated; the CG resources should be valid; and / or the SS-RSRP of the beam selected for SDT transmission via CG-based PUSCH resources should be above a defined RSRP threshold.
[0030] Note that if any of these verification conditions defined for CG-SDT are not met, CG-SDT cannot be used, and the UE can fall back to use RA-SDT (i.e., 4-step RA-SDT type or 2-step RA-SDT type, depending on the specifications / configuration and validity / selection conditions defined for these SDT types).
[0031] Figure 1A , Figure 1B and Figure 1C Examples of the three SDT types discussed above for single-reflection SDT are shown, namely, SDT procedures that include only one UL data and an additional single DL data (optionally). Specifically, Figure 1A An example of an SDT type based on 4-step RACH is shown. Figure 1B An example of an SDT type based on 2-step RACH is shown. Figure 1C An example of a CG-based SDT type is shown (without RACH).
[0032] It has been agreed that "multi-shot" SDT will be supported, meaning an SDT process that includes multiple subsequent UL / DL SDT transmissions (without transitioning to RRC_CONNECTED). In other words, when the UE is in RRC_INACTIVE, it should be able to send multiple UL and DL packets as part of the same SDT mechanism without transitioning to RRC_CONNECTED on dedicated licenses.
[0033] Specific examples of infrequent, small-data services that will benefit from the SDT process can include at least use cases related to smartphone and non-smartphone applications. For example, smartphone applications could include services from instant messaging services, heartbeat / keep-alive services from IM / email clients and other applications, and / or push notifications from various applications. Non-smartphone applications could include, for example, services from wearable devices (periodic location information, etc.), sensors (industrial wireless sensor networks that periodically or event-triggeredly transmit temperature, pressure readings, etc.), and / or smart meters and smart meter networks that send periodic meter readings.
[0034] In 3GPP NR Release 15, a new standalone RRC state called RRC_INACTIVE was introduced to complement the existing states RRC_CONNECTED and RRC_IDLE, with the goal of streamlining signaling and providing energy-efficient support for NR services. Although this design is specifically for mMTC / MIoT services (see, for example, 3GPP TR22.824), it can also efficiently serve small / infrequent traffic for eMBB and URLLC services. Figure 2 An example of an NR RRC state machine is shown. Figure 2 As shown in the example, the RRC_INACTIVE state enables faster recovery of earlier suspended connections compared to the RRC_IDLE state, and allows for the transmission of small or sporadic data with significantly lower initial access latency and associated signaling overhead. This is primarily due to the reduced control signaling required to request and acquire the resumption of suspended RRC connections, resulting in power savings for the UE. Meanwhile, compared to RRC_CONNECTED, a UE in RRC_INACTIVE achieves similar power savings as in RRC_IDLE, benefiting from longer PDCCH monitoring (e.g., for paging) periods and more relaxed measurements.
[0035] Furthermore, compared to keeping the UE in RRC_CONNECTED, the new state minimizes mobility signaling to the RAN (e.g., RRC measurement reports, handover messages) and to the core network (e.g., to / from the AMF), because the UE can transparently move to the RAN within a set of cells (RAN Notification Areas, RNAs) defined by the network. The transition from RRC_CONNECTED to RRC_INACTIVE is triggered by the gNB transmitting an RRC release message, which includes suspend configuration information, including I-RNTI, RAN-PagingCycle, RAN-NotificationAreaInfo, and timer t380 (referring to the timer that controls when the periodic RNA update (RNAU) process occurs at the UE). Note that when the UE moves to RRC_INACTIVE, the UE access stratum (AS) context (called the UE inactive AS context) is maintained on both the UE side and the RAN side (at the last serving gNB, also known as the anchor gNB). This is necessary for quickly resuming the suspended connection, and it is identified on the network side by the UE identifier, namely the inactive RNTI (I-RNTI).
[0036] Both SDT solutions with and without anchor relocation are within the scope of RA-SDT (for RACH-based solutions, context extraction and data forwarding in inactive states with and without anchor relocation), and will be defined in Release 17. Note that the decision regarding whether to perform anchor relocation is network-dependent and transparent to the UE. A plausible assumption is that this decision is made by the anchor gNB based on auxiliary information received from the target gNB. The content of such auxiliary information is yet to be determined; however, it may include indications about whether the UE has any other data to transmit besides the payload(s) included in the initial UL SDT transmission.
[0037] In SDT with anchor relocation, the target gNB initiates the UE AS context retrieval and path handover procedure from the anchor gNB (the last serving gNB). After these two procedures are completed, PDCP processing of the UL data received from the UE can be performed at the target gNB, and the UL data can be forwarded to the UPF. This may be similar to a traditional RRC connection restoration procedure.
[0038] In SDT without anchor relocation, the target gNB initiates UE AS context retrieval from the anchor gNB (the last serving gNB), but the anchor gNB responds with, for example, "Context Retrieve Failed." That is, the anchor gNB does not provide the UE AS context and retains it; furthermore, no path switching occurs, which helps avoid redundant related signaling. This may be similar to a traditional RNA update process without context relocation.
[0039] Figure 3 An example signaling diagram for an SDT without anchor relocation is shown. SDT signaling without anchor relocation is not optimized in Release 17. Specifically, UE-specific RLC contexts have been agreed upon in Release 17. This means that backhaul signaling is required to retrieve the UE's RLC configuration (decomposing the CU-CP in the RAN architecture) from the anchor gNB, which may be necessary for processing the RLC PDU received from the UE at the target gNB. Note that this RLC configuration retrieval may be required even if the UE AS context remains at the anchor gNB (CU-CP), i.e., context or anchor relocation does not occur in an SDT without relocation, as described above. This results in increased backhaul signaling, such as... Figure 3 As shown in the example.
[0040] As will be discussed in detail herein, some example embodiments include methods to streamline signaling for SDTs without anchor relocation, avoiding the need for the target gNB to extract the RLC context for at least the “returning UE”. In one embodiment, a “returning UE” may be defined as a UE that initiates multiple SDT procedures in the same target gNB. In the context of some embodiments, it may be assumed that each SDT procedure has no anchor relocation to save path handover signaling between the RAN and the Access and Mobility Management Function (AMF). For example, the “returning UE” scenario is likely to occur for most smartphone UEs because the smartphone may be served by the same gNB (e.g., a gNB providing coverage for the end user’s home, office, etc.) for an extended period of time (e.g., several hours), during which the UE may perform many SDT procedures to transmit small amounts of data from smartphone applications (e.g., app notifications).
[0041] In one embodiment, a UE-specific UL SDT context may be stored at a previous target node, such as a target DU / CU-CP, for use in an SDT with UL data. For example, a target gNB (e.g., target CU-CP and / or DU) may store a UE-specific UL SDT context for a UE in an RRC inactive state that has previously initiated an SDT procedure without anchor relocation to the same target DU. According to some embodiments, the stored UE-specific UL SDT context may include at least some information previously retrieved by the target CU-CP from the anchor gNB (anchor CU-CP) via the Xn interface (e.g., triggered by a previous SDT procedure of the UE). For example, the information included in the stored UE-specific UL SDT context may include one or more of the following: the UE-specific RLC context of the SDT, the F1 UL Tunnel Endpoint Identifier (TEID) associated with the anchor node CU UP of the UE's DRB, and / or the UE identifier (e.g., I-RNTI). The UE-specific RLC context of the SDT allows the target DU to immediately perform RLC processing on (multiple) RLC PDUs received from a "returning UE" (i.e., a UE initiating a second, third, etc. SDT procedure within the same target DU). Note that the UE-specific RLC context of the SDT includes some or all of the RLC configuration stored in the UE AS context for use in UL SDT transmission, including the RLC mode (e.g., acknowledged mode AM, or unacknowledged mode UM) for each SDT-LCH / DRB, and the RLC sequence number (SN) length for each SDT-LCH / DRB. The F1 UL TEID associated with the anchor node CU-UP of the UE's DRB allows the target DU to immediately forward UL RLC SDUs received from the UE (after RLC processing) to the anchor CU-UP (which can then be processed by PDCP and forwarded to the UPF). The UE identifier (e.g., I-RNTI) allows the UE initiating the SDT procedure to be identified as a "returning UE". Then, when the UE initiates a new SDT procedure to any of these cells, any cell of the target DU can utilize the stored UE-specific UL SDT context.
[0042] Some example implementations may include maintaining UE-specific SDT UL context synchronization in a previous gNB. Furthermore, the anchor gNB may be responsible for updating the UE-specific UL SDT context via the target CU-CP to any previous target DU on the same gNB or a different previous gNB when necessary. For example, the anchor gNB may trigger an update of the UE identifier (e.g., I-RNTI) in any previous target DU or target gNB when the UE completes a new SDT procedure. Alternatively, the anchor gNB may trigger the discarding of the UE-specific UL SDT context at the previous target DU or target gNB, for example, if the UE restores RRC connectivity. Alternatively or additionally, the target DU or target gNB may apply a timer-based method to discard the stored UE-specific UL SDT context. Note that at least the I-RNTI may need to be updated after the SDT procedure.
[0043] According to another embodiment, for an "SDT with UL data scenario," a proactive transmission of the UE-specific UL SDT context to a potential target DU / CU-CP can be performed without prior SDT. For example, after the first SDT procedure to the target gNB, the target CU-CP can proactively send the stored UE-specific UL SDT context to the DU of the target gNB, so that any future SDT procedure to any DU can benefit from the stored UE-specific UL SDT context. Note that the UE-specific RLC context contains static information, and the F1 UL TEID is also static for the UE's DRB. Similarly, after receiving an update to the I-RNTI from the anchor CU-CP, the target CU-CP can update its DU with the updated I-RNTI corresponding to the stored UE-specific UL SDT context.
[0044] On the other hand, the anchor CU-CP can proactively send the stored UE SDT context to some or all neighboring CU-CPs, so that any future SDT procedure to any neighboring gNB can benefit from the stored UE-specific UL SDT context. In the case of an I-RNTI update, the anchor gNB can send the updated I-RNTI to the neighboring gNBs involved.
[0045] In some respects, proactive transmissions for a UE-specific UL SDT context can be based on a combination of estimates / knowledge that the UE will return in the target DU / CU-CP, such as based on the UE's mobility history, and / or based on estimates / knowledge that the UE's SDT process includes more than a certain number of user plane / control plane data packets for transmission and / or reception. For example, proactive transmissions may not occur in a single-load SDT scenario.
[0046] Alternatively, in one embodiment, the anchor CU-CP can store relevant information from the UE AS context or the entire UE AS context in a RAN database (e.g., using a service-based architecture solution). The target CU-CP and / or target DU can retrieve updated information from the RAN database, for example, when a change is notified. This minimizes the Xn signaling load at the anchor CU-CP, eliminating the need for the anchor CU-CP to provide Xn-based updates to all target gNBs.
[0047] According to another embodiment, a UE-specific DL SDT context can be stored at the anchor CU-UP for use in SDTs with DL data. For example, the anchor CU-UP can store a UE-specific SDT DL context for a UE in an RRC inactive state that has previously initiated an SDT procedure to the same target DU. The UE-specific DL SDT context stored at the CU-UP may include at least some information previously received from the target DU (via the target CU-CP and anchor CU-CP, via the F1 / Xn interface, e.g., triggered by a previous SDT procedure of a UE to the same target DU). For example, the information included in the stored UE-specific DL SDT context may include the F1 DL TEID of the UE's DRB at the target DU. This allows the anchor CU-UP to immediately forward pending DL RLC SDUs of the UE's DRB to the target DU.
[0048] According to another embodiment, an active transmission of a UE-specific SDT DL context to the anchor CU-UP for an "SDT with DL data scenario" can be performed. This may be similar to the active transmission of the UE-specific SDT UL context discussed above, except that the UE-specific SDT context is a DL context, which is transmitted to the anchor CU-UP and may include the F1 DL TEID of the potential DU of the previous target node.
[0049] Figure 4A , Figure 4B and Figure 4C An example signaling diagram according to an example embodiment is shown, depicting an example of an SDT with only UL data and no anchor relocation. Figure 4A In the example, the UE-specific UL SDT context can be stored at the previous target node or gNB, for example, at the target DU / CU-CP, for use with the SDT containing UL data.
[0050] More specifically, in Figure 4BIn the example, as shown at 410, the target DU (e.g., target DU1) may store the UE-specific UL SDT context in the same DU after the UE's previous SDT procedure for use in an SDT with UL data but no relocation. In one embodiment, the stored UE-specific UL SDT context may include the I-RNTI, the UE-specific RLC context, and / or the F1 UL TEID of the anchor CU UP. Figure 4A In the example, it is assumed and illustrated that the target DU stores the previously extracted UE-specific UL SDT context. However, alternatively, the target CU-CP (e.g., target CU-CP1) may store the UE-specific UL SDT context and, upon receiving the initial UL transmission of F1-C (e.g., as a response to step 11 (not shown in the figure), may provide it to the target DU in a new additional F1 message (e.g., F1: UE Context Establishment Procedure). Figure 4B As further illustrated in the example, at 420, the target DU (e.g., target DU1) can decide whether to apply the stored context based on the BSR and use the stored RLC context to process the RLC PDU.
[0051] According to some embodiments, the anchor CU-CP can be configured to ensure that the UE-specific UL SDT context is synchronized in the previous target gNB (e.g., the previous target DU / CU-CP). For example, the anchor CU-CP can store the target gNBs that performed SDTs without anchor relocation (note that these may simply be in the UE's RNA). Figure 4C An example is shown at 425, where the anchor CU-CP can transmit a new Xn message to one or more of the stored target gNBs (e.g., to the target DU and / or target CU-CP) to update any portion of the UE-specific UL SDT context, such as the UE identifier (e.g., I-RNTI). In one embodiment, the target DU and / or target CU-CP can store the UE-specific UL SDT context and the updated UE identifier at 430. For example, in one embodiment, the target CU-CP can store all DUs of the target gNB to which the UE previously performed an SDT without anchor relocation and will update their UE-specific UL SDT context received from the anchor CU-CP. Furthermore, in one embodiment, at 435, the target DU and / or target CU-CP can discard the stored UE-specific UL SDT context if necessary, for example, when the UE restores an RRC connection.
[0052] Note that in Figure 4AIn the example, it can be assumed that the UE has already performed an SDT on target DU2, and therefore target DU2 is storing the UE-specific UL SDT context. Conversely, target DU1 may have already completed its first SDT procedure for the UE leading to target DU1 (e.g., as...). Figure 4A (As shown in step 8 of the example) After that, the UE-specific UL SDT context is stored. Alternatively, the target DU1 can also be actively stored as described above.
[0053] In some embodiments, the anchor CU-CP can provide auxiliary information to the target DU / CU-CP regarding whether the UE-specific UL SDT context should be stored and applied by the target DU. For example, according to one embodiment, the anchor CU-CP can provide auxiliary information to the target DU / CU-CP indicating whether the target DU is permitted to store the UE-specific UL SDT context, and / or indicating under what conditions or rules the target DU is permitted to use or apply the stored UE-specific UL SDT context. According to some embodiments, the auxiliary information can be provided by the anchor CU-CP, for example, as a response to an Xn context retrieval request from the target CU-CP, or in an Xn message that provides an RRC release in the form of an indication to “Allow SDT without anchor relocation” (e.g., see...). Figure 4A Step 7 in the example and Figure 5A (Similar to step 7). That is, if the SDT for anchor relocation does not apply to the UE in future SDT processes, then this indication may exist (set to true); otherwise, such a field or information may not exist (or exist with a "not true" value). Such an indication allows for avoiding violations of the current operating assumption that anchor relocation should be performed by the anchor CU-CP.
[0054] In accordance with some embodiments, as part of this assistance information, the conditions / rules on whether the target DU is allowed to use the stored UE-specific UL SDT context (when the UE initiates an SDT procedure to the target DU) may include one or more BSR thresholds. For example, if the UE includes a BSR in its initial UL SDT transmission, and the BSR indicates that the data volume is less than BSR threshold 1 (thr1), then the target DU should not use or apply immediate RLC processing of the received RLC PDUs based on the stored UE-specific UL SDT context (e.g., without previously contacting the anchor gNB CU-CP). This is because, in such a case, the benefit of using this approach may be limited. In another example, if the UE includes a BSR in its initial UL SDT transmission, and the BSR indicates that the data volume is greater than BSR thr2 (BSR thr2>thr1), then the target DU may be allowed to use or apply immediate RLC processing of the received RLC PDUs based on the stored UE-specific UL SDT context (e.g., without previously contacting the anchor gNB CU-CP). This is because, in such a scenario, the benefit of using this approach is greater.
[0055] Figure 5A , Figure 5B and Figure 5C illustrate another example signaling diagram in accordance with example embodiments, which depicts storing the UE-specific DL SDT context at the anchor CU-UP for SDT with DL data, in addition to storing the UE-specific UL SDT context at the previous target DU / CU-CP for SDT with UL data. Note that, Figure 5A , Figure 5B and Figure 5C some of the processes shown in the example may be similar to or correspond to the processes shown in the examples of Figure 4A , Figure 4B and Figure 4C discussed above.
[0056] As shown in the example of Figure 5B , at 510, the anchor CU-UP may store at least the DL target DU address (i.e., the F1 DL TEID of the target DU) at the same target DU based on a previous SDT procedure. Then, in case there is pending DL data for the returning UE at the anchor CU-UP, at 520, the anchor CU-UP may transmit the DL data to the same target DU immediately after receiving the UE's UL data from the same target DU. For example, the anchor CU-UP may Figure 5BIn the example, after step 13, pending DL data is sent to the target DU1. In one embodiment, the anchor CU-UP identifies the UE context containing the DL SDT context via the F1 UL TEID, and in step 13 it uses the F1 UL TEID to receive uplink data. In another aspect, the anchor CU-CP can be configured to update and / or discard the UE-specific DL SDT context stored in the anchor CU-UP as needed.
[0057] Figure 6 An example flowchart of a signaling method for an improved SDT according to an example embodiment is shown. In some example embodiments, Figure 6 The flowchart can be executed by network entities or network nodes in a communication system, such as LTE or 5G NR. In some example embodiments, the execution... Figure 6 The network entities of the method may include or be included in the following: base station, access node, node B, eNB, gNB, NG-RAN node, Transmitter Receiver Point (TRP), High Altitude Platform Station (HAPS), relay station, etc. In one embodiment, the method is executed... Figure 6 The network nodes of the method may include the target network node, the target gNB, or the target cell, such as Figure 4A , Figure 4B and Figure 4C or Figure 5A , Figure 5B and Figure 5C The example shows one or more, or similar, radio nodes in the target DU and / or target CU-CP. Therefore, Figure 6 The methods may include Figure 4A , Figure 4B and Figure 4C or Figure 5A , Figure 5B and Figure 5C One or more operations are shown in the example.
[0058] like Figure 6As illustrated in the example, the method may include, at 600, storing, at a first target network node, a user equipment (UE)-specific uplink (UL) small data transfer (SDT) context for a user equipment (UE) in a connectionless radio resource control (RRC) state, which the UE has previously initiated a small data transfer (SDT) procedure without anchor relocation via the first target network node or another target network node. For example, the connectionless RRC state may include an RRC inactive state and / or an idle state. In one embodiment, storing 600 may include storing the UE-specific uplink (UL) small data transfer (SDT) context in at least one of the distributed cell or centralized cell control plane (CU-CP) of the target node. For example, the stored UE-specific uplink (UL) small data transfer (SDT) context may include information previously received by the first target network node from an anchor network node. In one embodiment, the information stored in the User Equipment (UE)-specific Uplink (UL) Small Data Transmission (SDT) context may include one or more of the following: a UE-specific Radio Link Control (RLC) context for the Small Data Transmission (SDT), an F1 Uplink (UL) Tunnel Endpoint Identifier (TEID) associated with the CU-UP of the User Equipment (UE)’s Data Radio Bearer (DRB) of the anchor CU UP, and / or a User Equipment (UE) identifier (e.g., I-RNTI). More specifically, in one embodiment, the information stored in the User Equipment (UE)-specific Uplink (UL) Small Data Transmission (SDT) context may include at least information about the UE-specific context of the lower layers of the RAN protocol, where the lower layers include, for example, RLC and PHY. In another example embodiment, the information stored in the User Equipment (UE)-specific Uplink (UL) Small Data Transmission (SDT) context may include information about the UL User Plane Network Interface TEID, such as the F1 Uplink TEID of the anchor CU UP.
[0059] like Figure 6As further illustrated in the example, the method may include, at 605, performing radio link control (RLC) processing on a radio link control (RLC) protocol data unit (PDU) received from a user equipment (UE) at a first target network node using a stored user equipment (UE)-specific uplink (UL) small data transmission (SDT) context. In one embodiment, the method may include forwarding the uplink (UL) radio link control (RLC) service data unit (SDU) received from the user equipment (UE) after the RLC processing to an anchor network node. According to some embodiments, the method may include receiving an update to the user equipment (UE)-specific uplink (UL) small data transmission (SDT) context from the anchor network node at a DU or CU-CP of the target network node. In some embodiments, the method may include receiving a trigger from the anchor network node for discarding the user equipment (UE)-specific uplink (UL) small data transmission (SDT) context. In another embodiment, the method may include determining to discard the stored user equipment (UE)-specific uplink (UL) small data transmission (SDT) context based on a timer, for example, based on the expiration of a timer.
[0060] For example Figure 6 As illustrated in the example, after a first Small Data Transmission (SDT) process via a first target network node or another target node, the method may include: at 610, proactively transmitting a stored User Equipment (UE)-specific Uplink (UL) Small Data Transmission (SDT) context to a Potential Distributed Unit (DU) of the first target network node. In one example, proactive transmission 610 may include proactively transmitting the stored User Equipment (UE)-specific Uplink (UL) Small Data Transmission (SDT) context based on at least one of the following: an estimate that the User Equipment (UE) will return to the target network node based on the User Equipment (UE) mobility history; and / or an estimate that the User Equipment (UE)'s Small Data Transmission (SDT) process includes more than a certain number of user plane or control plane data packets to be transmitted or received.
[0061] According to one embodiment, the method may include, at 620, after receiving an update of the User Equipment (UE) identifier from the anchor network node, providing the updated User Equipment (UE) identifier corresponding to the stored User Equipment (UE)-Specific Uplink (UL) Small Data Transmission (SDT) context to the Potential Distributed Unit (DU) of the first target network node. In one embodiment, the method may include, when the first target network node is notified of a change, the first target network node retrieving relevant information about the stored User Equipment (UE)-Specific Uplink (UL) Small Data Transmission (SDT) context from a Radio Access Network (RAN) database. According to some embodiments, the method may include receiving auxiliary information from the anchor network node. For example, the auxiliary information may include: an indication of whether the target network node is permitted to store the User Equipment (UE)-Specific Uplink (UL) Small Data Transmission (SDT) context, an indication of under what conditions the target network node is permitted to use or apply the stored User Equipment (UE)-Specific Uplink (UL) Small Data Transmission (SDT) context, and / or an indication of estimated UE mobility.
[0062] In some embodiments, the method may further include storing the stored User Equipment (UE)-specific Uplink (UL) Small Data Transmission (SDT) context at the CU-CP of the first target network node, and transmitting it to the DU of the first target network node when a new Small Data Transmission (SDT) procedure is initiated via the DU.
[0063] Figure 7 An example flowchart of a method for improving signaling in SDT according to an example embodiment is shown. In some example embodiments, Figure 7 The flowchart can be executed by network entities or network nodes in a communication system, such as LTE or 5G NR. In some example embodiments, the execution... Figure 7 The network entities of the method may include or be included in the following: base station, access node, node B, eNB, gNB, NG-RAN node, Transmitter Receiver Point (TRP), High Altitude Platform Station (HAPS), relay station, etc. In one embodiment, the method is executed... Figure 7 The network nodes of the method can include anchor network nodes, anchor gNBs, or anchor cells, such as Figure 4A , Figure 4B and Figure 4C or Figure 5A , Figure 5B and Figure 5C The example shows one or more anchor CU-CPs, or similar radio nodes. Therefore, Figure 7 The methods may include Figure 4A , Figure 4B and Figure 4C or Figure 5A , Figure 5B and Figure 5C One or more operations are shown in the example.
[0064] like Figure 7 As illustrated in the example, the method may include: at 700, at the anchor network node, storing a user equipment (UE)-specific downlink (DL) small data transmission (SDT) context for a user equipment (UE) in a Radio Resource Control (RRC) disconnected state, the UE initiating an SDT procedure to the same target network node to which it has previously initiated an SDT procedure; and / or assigning one or more UL TEIDs for SDT procedures without anchor relocation. In one embodiment, the stored UE-specific downlink (DL) small data transmission (SDT) context includes information previously received from the target network node. For example, the information included in the stored UE-specific downlink (DL) small data transmission (SDT) context may include at least: the F1 downlink (DL) tunnel endpoint identifier (TEID) of the data radio bearer (DRB) of the user equipment (UE) associated with the DU at the target network node.
[0065] In one embodiment, the method may include: at 705, after receiving uplink (UL) traffic from a target network node via a previously assigned uplink tunnel endpoint identifier (TEID), forwarding any pending downlink (DL) radio link control (RLC) service data units (SDUs) for a user equipment (UE) data radio bearer (DRB) to the target network node. According to some embodiments, the method may further include: at 710, actively transmitting, to the centralized unit user plane (CU-UP) of the anchor network node, a stored user equipment (UE)-specific downlink (DL) small data transmission (SDT) context corresponding to at least one DU of at least one target node. According to one embodiment, the method may include transmitting or sending an indication of whether the target network node is permitted to store and use the user equipment (UE)-specific uplink (UL) small data transmission (SDT) context. In one embodiment, the method may further include sending an indication of whether the anchor network node CU-UP is permitted to store and use the user equipment (UE)-specific downlink (DL) small data transmission (SDT) context.
[0066] Figure 8AAn example of apparatus 10 according to an embodiment is shown. In one embodiment, apparatus 10 may be a node, host, or server in or serving a communications network. For example, apparatus 10 may be a satellite, base station, node B, evolved Node B (eNB), 5G node B or access point, next-generation node B (NG-NB or gNB), WLAN access point, TRP, IAB node, and / or HAPS associated with a radio access network such as an LTE network, 5G, or NR. In an example embodiment, apparatus 10 may be an NG-RAN node, an eNB in LTE, or a gNB in 5G. According to one embodiment, apparatus 10 may be, for example, a target network node, a target gNB, or a target cell.
[0067] It should be understood that in some example embodiments, device 10 may include an edge cloud server as a distributed computing system, wherein the server and radio nodes may be separate devices communicating with each other via a radio path or via a wired connection, or they may reside in the same entity communicating via a wired connection. For example, in some example embodiments where device 10 represents a gNB, it may be configured in a central unit (CU) and distributed unit (DU) architecture that divides gNB functions. In such an architecture, the CU may be a logical node that includes gNB functions such as user data transmission, mobility control, radio access network sharing, location and / or session management, etc. The CU may control the operation of the DU(s) through a fronthaul interface. The DU may be a logical node that includes a subset of gNB functions, depending on the function splitting options. It should be noted that those skilled in the art will understand that device 10 may include Figure 8A Components or features not shown in the diagram.
[0068] like Figure 8A As shown in the example, device 10 may include a processor 12 for processing information and executing instructions or operations. Processor 12 may be any type of general-purpose or special-purpose processor. In fact, for example, processor 12 may include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), and processor based on a multi-core processor architecture. Although Figure 8A A single processor 12 is shown, but multiple processors may be used according to other embodiments. For example, it should be understood that in some embodiments, device 10 may include two or more processors that can form a multiprocessor system capable of supporting multiple processing (e.g., in this case, processor 12 may represent multiple processors). In some embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).
[0069] The processor 12 can perform functions associated with the operation of the device 10, which may include, for example, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming communication messages, formatting of information, and overall control of the device 10, including processes related to communication resource management.
[0070] Device 10 may also include or be coupled to memory 14 (internal or external), which may be coupled to processor 12, for storing information and instructions executable by processor 12. Memory 14 may be one or more memories and may be of any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and / or removable memory. For example, memory 14 may include random access memory (RAM), read-only memory (ROM), static storage devices such as disks or optical discs, hard disk drives (HDDs), or any other type of non-transient memory or computer-readable medium and any combination thereof. Instructions stored in memory 14 may include program instructions or computer program code that, when executed by processor 12, enable device 10 to perform the tasks described herein.
[0071] In one embodiment, device 10 may further include or be coupled to an (internal or external) drive or port configured to accept and read external computer-readable storage media, such as an optical disc, USB drive, flash drive, or any other storage media. For example, the external computer-readable storage media may store computer programs or software that are executed by processor 12 and / or device 10.
[0072] In some embodiments, device 10 may further include or be coupled to one or more antennas 15 for transmitting and / or transmitting signals and / or data to and from device 10. Device 10 may also include or be coupled to a transceiver 18 configured to transmit and receive information. Transceiver 18 may include, for example, multiple radio interfaces that may be coupled to antenna(s) 15. The radio interfaces may correspond to a variety of radio access technologies, including one or more of the following: GSM, NB-IoT, LTE, 5G, WLAN, Bluetooth, BT-LE, NFC, RFID, UWB, MulteFire, etc. The radio interfaces may include components such as filters, converters (e.g., digital-to-analog converters), mappers, Fast Fourier Transform (FFT) modules, etc., to generate symbols for transmission via one or more downlinks and to receive symbols (e.g., via an uplink).
[0073] Therefore, transceiver 18 can be configured to modulate information onto a carrier waveform for transmission by antenna(s)15, and demodulate information received via antenna(s)15 for further processing by other elements of device 10. In other embodiments, transceiver 18 can directly transmit and receive signals or data. Additionally or alternatively, in some embodiments, device 10 may include input and / or output devices (I / O devices).
[0074] In one embodiment, memory 14 may store software modules that provide functionality when executed by processor 12. These modules may include, for example, an operating system that provides operating system functionality to device 10. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality to device 10. Components of device 10 may be implemented in hardware or as any suitable combination of hardware and software.
[0075] According to some embodiments, the processor 12 and the memory 14 may be included in a processing circuitry or a control circuitry, or may be part of it. Furthermore, in some embodiments, the transceiver 18 may be included in a transceiver circuitry, or may be part of it.
[0076] As used herein, the term "circuit system" can refer to hardware circuitry alone (e.g., analog and / or digital circuit systems), a combination of hardware circuitry and software, a combination of analog and / or digital hardware circuitry with software / firmware, any portion of a hardware processor(s) (including digital signal processors) having software that works together to cause a device (e.g., device 10) to perform various functions, and / or to operate using software but where the software may be absent when operation is not required. As another example, as used herein, the term "circuit system" can also encompass hardware circuitry or processors alone (or multiple processors), or a portion of hardware circuitry or processors, and their accompanying software and / or firmware implementation. The term "circuit system" can also encompass baseband integrated circuits, for example, in servers, cellular network nodes or devices, or other computing or networking devices.
[0077] As described above, in some embodiments, device 10 may be an NW node or RAN node, such as a base station, access point, node B, eNB, gNB, WLAN access point, etc. In one embodiment, device 10 may be a source node, source gNB, source cell, etc. For example, in some embodiments, device 10 may be configured to perform one or more of the processes depicted in any flowchart or signaling diagram described herein, such as those in Figures 4 to 5. Figure 7Those described herein. In some embodiments, as discussed herein, for example, apparatus 10 may be configured to perform signaling-related processes with the improved SDT, as described elsewhere herein.
[0078] Figure 8B An example of a device 20 according to another embodiment is shown. In one embodiment, device 20 may be a node or element in or associated with a communication network, such as a UE, communication node, mobile equipment (ME), mobile station, mobile device, fixed equipment, IoT device, or other device. As described herein, UE may alternatively be referred to as, for example, mobile station, mobile equipment, mobile unit, mobile device, user equipment, subscriber station, wireless terminal, tablet computer, smartphone, IoT device, sensor or NB-IoT device, watch or other wearable device, head-mounted display (HMD), vehicle, drone, medical device and its applications (e.g., remote surgery), industrial equipment and its applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. As an example, device 20 may be implemented in, for example, a wireless handheld device, a wireless plug-in accessory, etc. It should be noted that those skilled in the art will understand that device 20 may include... Figure 8B Components or features not shown in the diagram.
[0079] In some example embodiments, device 20 may include one or more processors, one or more computer-readable storage media (e.g., memory, storage device, etc.), one or more radio access components (e.g., modem, transceiver, etc.), and / or a user interface. In some embodiments, device 20 may be configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, Bluetooth, NFC, MulteFire, and / or any other radio access technology. It should be noted that those skilled in the art will understand that device 20 may include... Figure 8B Components or features not shown in the diagram.
[0080] like Figure 8BAs shown in the example, device 20 may include or be coupled to a processor 22 for processing information and executing instructions or operations. Processor 22 may be any type of general-purpose or special-purpose processor. In practice, processor 22 may include one or more of the following: general-purpose computers, special-purpose computers, microprocessors, digital signal processors (DSPs), field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and processors based on multi-core processor architectures. Although Figure 8B A single processor 22 is shown, but multiple processors may be used according to other embodiments. For example, it should be understood that in some embodiments, device 20 may include two or more processors that can form a multiprocessor system capable of supporting multiple processing (e.g., in this case, processor 22 may represent multiple processors). In some embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).
[0081] The processor 22 can perform functions associated with the operation of the device 20, including, for example, precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming communication messages, formatting of information, and overall control of the device 20, including processes related to the management of communication resources.
[0082] Device 20 may also include or be coupled to memory 24 (internal or external), which may be coupled to processor 22 for storing information and instructions executable by processor 22. Memory 24 may be one or more memories and may be of any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and / or removable memory. For example, memory 24 may include random access memory (RAM), read-only memory (ROM), static storage devices such as disks or optical discs, hard disk drives (HDDs), or any other type of non-transient memory or computer-readable medium and any combination thereof. Instructions stored in memory 24 may include program instructions or computer program code that, when executed by processor 22, enable device 20 to perform the tasks described herein.
[0083] In one embodiment, device 20 may further include or be coupled to an (internal or external) drive or port configured to accept and read external computer-readable storage media, such as an optical disc, USB drive, flash drive, or any other storage media. For example, the external computer-readable storage media may store computer programs or software that are executed by processor 22 and / or device 20.
[0084] In some embodiments, device 20 may further include or be coupled to one or more antennas 25 for receiving downlink signals and for transmitting from device 20 via an uplink. Device 20 may also include a transceiver 28 configured to transmit and receive information. Transceiver 28 may also include a radio interface (e.g., a modem) coupled to antenna 25. The radio interface may correspond to various radio access technologies, including GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, Bluetooth, BT-LE, NFC, RFID, UWB, etc. The radio interface may include other components such as filters, converters (e.g., digital-to-analog converters), symbol demappers, signal shaping components, inverse fast Fourier transform (IFFT) modules, etc., to process symbols carried by the downlink or uplink, such as OFDMA symbols.
[0085] For example, transceiver 28 may be configured to modulate information onto a carrier waveform for transmission by antenna(s)25, and demodulate information received via antenna(s)25 for further processing by other elements of device 20. In other embodiments, transceiver 28 may be able to directly transmit and receive signals or data. Additionally or alternatively, in some embodiments, device 20 may include input and / or output devices (I / O devices). In some embodiments, device 20 may also include a user interface, such as a graphical user interface or a touchscreen.
[0086] In one embodiment, memory 24 stores software modules that provide functionality when executed by processor 22. These modules may include, for example, an operating system that provides operating system functionality to device 20. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality to device 20. Components of device 20 may be implemented in hardware or as any suitable combination of hardware and software. According to an example embodiment, device 20 may optionally be configured to communicate with device 10 or device 30 via a wireless or wired communication link or interface 70 according to any radio access technology such as NR.
[0087] According to some embodiments, the processor 22 and memory 24 may be included in, or formed part of, a processing circuit system / device or a control circuit system / device. Furthermore, in some embodiments, the transceiver 28 may be included in, or formed part of, a transceiver circuit system or transceiver device.
[0088] As described above, according to some embodiments, device 20 may be, for example, a UE, a communication node, a mobile device (ME), a mobile station, a mobile device, a fixed device, or an IoT device. According to some embodiments, device 20 may be controlled by memory 24 and processor 22 to perform functions associated with the example embodiments described herein. For example, in some embodiments, device 20 may be configured to perform one or more processes depicted in any flowchart or signaling diagram described herein, such as those in Figures 4 to 5. Figure 7 Those described herein. Therefore, according to one embodiment, apparatus 20 can be configured to perform signaling-related processes associated with the improved SDT, such as those discussed elsewhere herein.
[0089] Figure 8C An example of apparatus 30 according to another exemplary embodiment is shown. In the exemplary embodiment, apparatus 30 may be a node or element in a communication network or a node or element associated with such a network, such as a satellite, base station, Node B, evolved Node B (eNB), 5G Node B or access point, next-generation Node B (NG-NB or gNB), and / or WLAN access point associated with a radio access network (such as an LTE network, 5G, or NR). According to one embodiment, for example, apparatus 30 may be an anchor network node, an anchor gNB, or an anchor cell, or may be included therein.
[0090] In some example embodiments, device 30 may include one or more processors, one or more computer-readable storage media (e.g., memory, storage device, etc.), one or more radio access components (e.g., modem, transceiver, etc.), and / or a user interface. In some example embodiments, device 30 may be configured to operate using one or more radio access technologies, such as GSM, LTE, LTE-A, NR, 5G, WLAN, WiFi, NB-IoT, MulteFire, and / or any other radio access technology. It should be noted that those skilled in the art will understand that device 30 may include... Figure 8C Components or features not shown in the diagram.
[0091] like Figure 8C As shown in the example, device 30 may include or be coupled to processor 32 for processing information and executing instructions or operations. Processor 32 may be any type of general-purpose or special-purpose processor. In fact, for example, processor 32 may include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), and processor based on a multi-core processor architecture. Although Figure 8CA single processor 32 is shown, but multiple processors may be used according to other example embodiments. For example, it should be understood that in some example embodiments, device 30 may include two or more processors that can form a multiprocessor system capable of supporting multiple processing (e.g., in this case, processor 32 may represent multiple processors). In some example embodiments, the multiprocessor system may be tightly coupled or loosely coupled (e.g., to form a computer cluster).
[0092] The processor 32 can perform functions associated with the operation of the device 30. As examples, these functions include precoding of antenna gain / phase parameters, encoding and decoding of individual bits forming communication messages, formatting of information, and overall control of the device 30, including processes related to communication resource management.
[0093] Device 30 may also include or be coupled to memory 34 (internal or external), which may be coupled to processor 32, for storing information and instructions executable by processor 32. Memory 34 may be one or more memories and may be of any type suitable for the local application environment, and may be implemented using any suitable volatile or non-volatile data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and / or removable memory. For example, memory 34 may include random access memory (RAM), read-only memory (ROM), static storage devices such as disks or optical discs, hard disk drives (HDDs), or any other type of non-transient memory or computer-readable medium, and any combination thereof. Instructions stored in memory 34 may include program instructions or computer program code that, when executed by processor 32, enable device 30 to perform the tasks described herein.
[0094] In an example embodiment, device 30 may also include or be coupled to an (internal or external) drive or port configured to accept and read external computer-readable storage media, such as an optical disc, USB drive, flash drive, or any other storage media. For example, the external computer-readable storage media may store computer programs or software that are executed by processor 32 and / or device 30.
[0095] In some example embodiments, device 30 may further include or be coupled to one or more antennas 35 for receiving downlink signals and for transmission from device 30 via an uplink. Device 30 may also include a transceiver 38 configured to transmit and receive information. Transceiver 38 may also include a radio interface (e.g., a modem) coupled to antenna 35. The radio interface may correspond to a variety of radio access technologies, including one or more of the following: GSM, LTE, LTE-A, 5G, NR, WLAN, NB-IoT, BT-LE, RFID, UWB, etc. The radio interface may include other components such as filters, converters (e.g., digital-to-analog converters), symbol demappers, signal shaping components, inverse fast Fourier transform (IFFT) modules, etc., to process symbols carried by the downlink or uplink, such as OFDMA symbols.
[0096] For example, transceiver 38 may be configured to modulate information onto a carrier waveform for transmission by antenna(s)35, and demodulate information received via antenna(s)35 for further processing by other elements of device 30. In other example embodiments, transceiver 38 may be able to directly transmit and receive signals or data. Additionally or alternatively, in some example embodiments, device 30 may include input and / or output devices (I / O devices). In some example embodiments, device 30 may also include a user interface, such as a graphical user interface or a touchscreen.
[0097] In an example embodiment, memory 34 stores software modules that provide functionality when executed by processor 32. These modules may include, for example, an operating system that provides operating system functionality to device 30. The memory may also store one or more functional modules, such as applications or programs, to provide additional functionality to device 30. Components of device 30 may be implemented in hardware or as any suitable combination of hardware and software. According to the example embodiment, device 30 may optionally be configured to communicate with device 10 via wireless or wired communication link 71 and / or with device 20 via wireless or wired communication link 72, depending on any radio access technology (such as NR).
[0098] According to some example embodiments, the processor 32 and the memory 34 may be included in a processing circuit system or a control circuit system, or may be part of a processing circuit system or a control circuit system. Furthermore, in some example embodiments, the transceiver 38 may be included in a transceiver circuit system, or may be part of a transceiver circuit system.
[0099] As described above, according to some example embodiments, device 30 may be, for example, an anchor network node, an anchor gNB, or an anchor cell. According to some example embodiments, device 30 may be controlled by memory 34 and processor 32 to perform functions associated with the example embodiments described herein. For example, in some example embodiments, device 30 may be configured to perform one or more processes depicted in any of the diagrams or signaling flowcharts described herein, such as those in Figures 4 to 5. Figure 7 Those shown. According to certain example embodiments, for example, apparatus 30 may be configured to perform signaling-related processes with the improved SDT, as described elsewhere herein.
[0100] In some embodiments, an apparatus (e.g., apparatus 10 and / or apparatus 20 and / or apparatus 30) may include components for performing the methods, processes, or any variations discussed herein. Examples of such components may include one or more processors, memory, controllers, transmitters, receivers, and / or computer program code for inducing the execution of operations.
[0101] In light of the foregoing, certain example embodiments provide several technical improvements, enhancements, and / or advantages over prior art processes and constitute improvements at least in the field of radio network control and / or management technology. For example, as discussed in detail above, certain embodiments provide a more streamlined signaling approach for anchor-free SDT by avoiding the need for the target gNB to retrieve the RLC context for "returning to the UE". As described above, in one embodiment, if anchor-free SDT is used to avoid core network involvement (i.e., saving path handover signaling between the RAN and AMF), the UE can return in the same DU to perform the SDT procedure several times. In particular, when certain embodiments are applied, the F1 and Xn backhaul signaling used for returning the UE can be reduced because it is not necessary to retrieve the UE-specific RLC context in each SDT procedure initiated in a target DU that is not part of the anchor gNB. This eliminates the need for signaling for certain messages during the SDT procedure. Furthermore, as a result of certain embodiments, the data latency for SDT used to return the UE can be much shorter because the data stream can occur immediately. Therefore, the use of certain example embodiments improves the functionality of communication networks and their nodes (such as base stations, eNBs, gNBs and / or IoT devices, UEs or mobile stations).
[0102] In some example embodiments, the functionality of any methods, processes, signaling diagrams, algorithms, or flowcharts described herein may be implemented by software and / or computer program code or code portions stored in memory or other computer-readable or tangible media and executable by a processor.
[0103] In some example embodiments, an apparatus may include at least one software application, module, unit, or entity or associated therewith, which is configured to perform arithmetic operations or be configured as a program or program portion (including added or updated software routines) executed by at least one operating processor or controller. The program (also referred to as a program product or computer program, including software routines, applets, and macros) may be stored in any device-readable data storage medium and may include program instructions for performing a specific task. The computer program product may include one or more computer-executable components that, when the program runs, are configured to perform some example embodiments. The one or more computer-executable components may be at least one piece of software code or code. Modifications and configurations required to implement the functionality of the example embodiments may be executed as routines, which may be implemented as added or updated software routines. In one example, the software routines may be downloaded to the apparatus.
[0104] As an example, software or computer program code or code portions may be in the form of source code, object code, or some intermediate form, and may be stored on some carrier, distribution medium, or computer-readable medium, which may be any entity or device capable of carrying the program. For example, such a carrier may include recording media, computer memory, read-only memory, optoelectronic and / or electrical carrier signals, telecommunication signals, and / or software distribution packages. Depending on the required processing power, the computer program may execute in a single electronic digital computer or be distributed across multiple computers. The computer-readable medium or computer-readable storage medium may be a non-transient medium.
[0105] In other example embodiments, the functionality of the example embodiments may be performed by hardware or circuitry systems included in the device, such as by using an application-specific integrated circuit (ASIC), a programmable gate array (PGA), a field-programmable gate array (FPGA), or any other combination of hardware and software. In yet another example embodiment, the functionality of the example embodiments may be implemented as a signal, such as an intangible component that can be carried by an electromagnetic signal downloaded from the Internet or another network.
[0106] According to the example embodiments, devices such as nodes, equipment or corresponding components can be configured as circuit systems, computers or microprocessors, such as monolithic computer elements, or configured as chipsets, which may include at least a memory for providing storage capacity for arithmetic operations(s) and / or an arithmetic processor for performing arithmetic operations(s).
[0107] The exemplary embodiments described herein can be applied to both singular and plural implementations, regardless of whether a singular or plural language is used in conjunction with the description of certain embodiments. For example, an embodiment describing the operation of a single network node can also be applied to exemplary embodiments that include multiple instances of network nodes, and vice versa.
[0108] It will be readily understood by those skilled in the art that the exemplary embodiments discussed above can be practiced with a different sequence of processes and / or with different configurations of hardware elements compared to those disclosed. Therefore, although some embodiments have been described based on these exemplary embodiments, it will be apparent to those skilled in the art that certain modifications, variations, and alternative constructions will be readily apparent while remaining within the spirit and scope of the exemplary embodiments.
Claims
1. A method of communication, comprising: At a first network node, a user equipment-specific uplink small data transmission context for a user equipment in a disconnected radio resource control state is stored, wherein the first network node has previously initiated a small data transmission process without anchor relocation via the first network node or the second network node, and wherein the stored user equipment-specific uplink small data transmission context includes a user equipment-specific radio link control context and a user equipment identifier for small data transmission. as well as For small data transfer processes without anchor relocation, assign one or more F1 uplink tunnel endpoint identifiers to the stored context.
2. The method according to claim 1, further comprising: At the first network node, radio link control processing of radio link control protocol data units received from the user equipment is performed using the stored user equipment-specific uplink small data transmission context.
3. The method according to claim 1, further comprising: At the first network node, a trigger for discarding the user equipment-specific uplink small data transmission context is received from the anchor network node.
4. The method according to claim 1, further comprising: Based on a timer, it is determined whether the stored user equipment-specific uplink small data transmission context should be discarded at the first network node.
5. The method according to claim 1, further comprising: After receiving an update to the user equipment identifier from the anchor network node, the updated user equipment identifier corresponding to the stored user equipment-specific uplink small data transmission context is provided to the first network node.
6. The method according to claim 1, further comprising: When the first network node is notified of a change, the first network node retrieves relevant information for the stored user equipment-specific uplink small data transmission context from the radio access network database.
7. The method according to claim 1, further comprising: At the first network node, auxiliary information is received from the anchor network node, wherein the auxiliary information includes at least one of the following: an indication of whether the first network node is allowed to store the UE-specific uplink small data transmission context, an indication of under what conditions the first network node is allowed to use or apply the stored UE-specific uplink small data transmission context, or an indication of estimated UE mobility.
8. A device for communication, comprising: At least one processor; as well as At least one memory, including computer program code, The at least one memory and the computer program code are configured, together with the at least one processor, to make the device at least: At the device, a user equipment-specific uplink small data transmission context for a user equipment in a disconnected radio resource control state is stored, wherein the device has previously initiated a small data transmission process without anchor relocation via the device or another network node, and wherein the stored user equipment-specific uplink small data transmission context includes a user equipment-specific radio link control context and a user equipment identifier for small data transmission. as well as For small data transfer processes without anchor relocation, assign one or more F1 uplink tunnel endpoint identifiers to the stored context.
9. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: At the device, radio link control processing of radio link control protocol data units received from the user equipment is performed using the stored user equipment-specific uplink small data transmission context.
10. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: At the device, a trigger is received from the anchor network node for discarding the user equipment-specific uplink small data transmission context.
11. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: Based on a timer, it is determined whether to discard the stored user equipment-specific uplink small data transmission context at the device.
12. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: After receiving an update to the user equipment identifier from the anchor network node, the user equipment identifier corresponding to the stored user equipment-specific uplink small data transmission context is updated.
13. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: When the device is notified of a change, the device retrieves relevant information from the radio access network database for the stored user equipment-specific uplink small data transmission context.
14. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: At the device, auxiliary information is received from the anchor network node, wherein the auxiliary information includes at least one of the following: an indication of whether the device is allowed to store the UE-specific uplink small data transmission context, an indication of under what conditions the device is allowed to use or apply the stored UE-specific uplink small data transmission context, or an indication of estimated UE mobility.
15. An apparatus for communication, comprising: At least one processor; as well as At least one memory, including computer program code, The at least one memory and the computer program code are configured, together with the at least one processor, to make the device at least: At the device, a user equipment-specific downlink small data transmission context is stored for a user equipment in a non-connected radio resource control state, the user equipment initiating a small data transmission process to a target network node, wherein the stored user equipment-specific downlink small data transmission context includes information previously received from the target network node, and wherein the previously received information from the target network node includes a user equipment-specific radio link control context and a user equipment identifier for small data transmission; as well as For small data transfer processes without anchor relocation, assign one or more F1 uplink tunnel endpoint identifiers to the stored context.
16. The apparatus of claim 15, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: After receiving uplink traffic from the target network node via the previously assigned uplink tunnel endpoint identifier, any pending downlink radio link control service data units for the user equipment data radio bearer are forwarded to the target network node.
17. The apparatus of claim 15, wherein the at least one memory and the computer program code are further configured, together with the at least one processor, to cause the apparatus to at least: Send an indication of whether the target network node is allowed to store and use user equipment-specific uplink small data transmission context.
