Data transmission with secure configuration
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ALCATEL LUCENT SHANGHAI BELL CO LTD
- Filing Date
- 2021-02-03
- Publication Date
- 2026-07-17
Smart Images

Figure CN116868678B_ABST
Abstract
Description
Technical Field
[0001] Embodiments of this disclosure generally relate to the telecommunications field, and more particularly to devices, methods, apparatuses, and computer-readable storage media for data transmission with secure configurations. Background Technology
[0002] Fifth-generation mobile networks, also known as 5G New Radio (NR), are a new global wireless standard following 1G, 2G, 3G, and 4G networks. 5G supports a new type of network designed to virtually connect all people and everything, including machines, objects, and devices. 5G wireless technology aims to provide more users with higher peak data speeds of multiple Gbps, extremely low latency, higher reliability, massive network capacity, enhanced availability, and a more unified user experience. Higher performance and improved efficiency enable new user experiences and connect new industries.
[0003] NR proposes a new RRC state, the RRC_INACTIVE state. In the RRC_INACTIVE state, multiple uplink (UL) / downlink (DL) packet transmissions are supported, for example, infrequent and small data flows. UL / DL packet transmissions can occur during Small Data Transmission (SDT) processes, during which the User Equipment (UE) does not transition to the RRC_CONNECTED state. The SDT process in the RRC_INACTIVE state can be implemented based on a Random Access Channel (RACH) procedure or a configured grant (CG). Summary of the Invention
[0004] Overall, the exemplary embodiments of this disclosure provide a data transmission solution with secure configuration.
[0005] In a first aspect, a first device is provided. The first device includes at least one processor; and 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 cause the first device to at least: receive from a second device a first plurality of parameters associated with a connection restoration process between the first device and the second device;, in an inactive state, send a request for connection restoration to the second device, the request including one or more of the first plurality of parameters, based on a determination that the connection restoration process will be executed; and execute the connection restoration process with the second device.
[0006] In a second aspect, a second device is provided. The second device includes at least one processor; and 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 cause the second device to at least: send a first plurality of parameters associated with a connection restoration process between the first device and the second device to a first device; receive a request for connection restoration from the first device, the request including one or more of the first plurality of parameters; and, in response to the request, perform a connection restoration process with the first device.
[0007] In a third aspect, a method is provided. The method includes: at a first device, receiving from a second device a first plurality of parameters associated with a connection restoration process between the first device and the second device; based on determining that the connection restoration process will be executed, sending a request for connection restoration to the second device in an inactive state, the request including one or more of the first plurality of parameters; and executing the connection restoration process with the second device.
[0008] In a fourth aspect, a method is provided. The method includes: sending a first plurality of parameters to a first device in connection with a connection restoration process between the first device and a second device; receiving a request from the first device for connection restoration, the request including one or more of the first plurality of parameters; and, in response to the request, performing a connection restoration process with the first device.
[0009] In a fifth aspect, a first apparatus is provided, comprising: components for receiving a first plurality of parameters from a second apparatus, the first plurality of parameters being associated with a connection restoration process between the first apparatus and the second apparatus; components for sending a request for connection restoration to the second apparatus in an inactive state, the request including one or more of the first plurality of parameters, based on a determination that the connection restoration process will be performed; and components for performing the connection restoration process with the second apparatus.
[0010] In a sixth aspect, a second apparatus is provided, comprising: means for sending a first plurality of parameters to a first apparatus, the first plurality of parameters being associated with a connection restoration process between the first apparatus and the second apparatus; means for receiving a request for connection restoration from the first apparatus, the request including one or more of the first plurality of parameters; and means for performing a connection restoration process with the first apparatus in response to the request.
[0011] In a seventh aspect, a computer-readable medium having a computer program stored thereon is provided, wherein when the computer program is executed by at least one processor of the device, the device performs the method according to the third aspect.
[0012] In an eighth aspect, a computer-readable medium having a computer program stored thereon is provided, wherein when the computer program is executed by at least one processor of the device, the device performs the method according to the fourth aspect.
[0013] Other features and advantages of embodiments of the present disclosure will also become apparent from the following description of specific embodiments when read in conjunction with the accompanying drawings, which illustrate the principles of embodiments of the present disclosure by way of example. Attached Figure Description
[0014] The embodiments disclosed herein are presented in an exemplary sense, and their advantages will be explained in more detail below with reference to the accompanying drawings, in which...
[0015] Figure 1 An example communication network in which example embodiments of this disclosure may be implemented is shown;
[0016] Figure 2 Signaling diagrams illustrating a process for data transmission with a secure configuration according to some example embodiments of the present disclosure are shown;
[0017] Figure 3 A flowchart illustrating an example method for data transmission with secure configuration according to some example embodiments of the present disclosure is shown;
[0018] Figure 4 A flowchart illustrating an example method for data transmission with secure configuration according to some example embodiments of the present disclosure is shown;
[0019] Figure 5 This is a simplified block diagram of a device suitable for implementing embodiments of the present disclosure; and
[0020] Figure 6 A block diagram of an example computer-readable medium according to some embodiments of the present disclosure is shown.
[0021] Throughout the accompanying drawings, the same or similar reference numerals denote the same or similar elements. Detailed Implementation
[0022] The principles of this disclosure will now be described with reference to some exemplary embodiments. It should be understood that these embodiments are described merely for illustration and to help those skilled in the art understand and implement this disclosure, and do not imply any limitation on the scope of this disclosure. The disclosure described herein can be implemented in various other ways besides those described below.
[0023] In the following description and claims, unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure pertains.
[0024] In this disclosure, references to "an embodiment," "embodiment," and "example embodiment," etc., indicate that the described embodiment may include a particular feature, structure, or characteristic, but not every embodiment must include that particular feature, structure, or characteristic. Furthermore, such phrases do not necessarily refer to the same embodiment. Moreover, when a particular feature, structure, or characteristic is described in conjunction with an example embodiment, those skilled in the art will understand that, whether explicitly described or not, combining it with other embodiments to affect such a feature, structure, or characteristic is within the knowledge of those skilled in the art.
[0025] It should be understood that although the terms “first” and “second”, etc., may be used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish the functions of the various elements. As used herein, the term “and / or” includes any and all combinations of one or more of the listed terms.
[0026] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments. The singular forms “a,” “an,” and “the” used herein also include the plural forms unless the context clearly indicates otherwise. Further understanding, the terms “comprises,” “comprising,” “has,” “having,” “includes,” and / or “including” as used herein specify the presence of the stated features, elements, and / or components, but do not exclude the presence or addition of one or more other features, elements, components, and / or combinations thereof.
[0027] As used in this application, the term "circuit system" may refer to one or more or all of the following:
[0028] (a) Pure hardware circuit implementation (such as implementation using only analog and / or digital circuit systems), and
[0029] (b) A combination of hardware circuitry and software, such as (if applicable):
[0030] (i) A combination of (multiple) analog and / or digital hardware circuits and software / firmware, and
[0031] (ii) Any part of a hardware processor(s) having software, including (multiple) digital signal processors(s), software, and (multiple) memories(s), which work together to cause a device (such as a mobile phone or server) to perform various functions, and
[0032] (c) (Multiple) hardware circuits and / or (multiple) processors, such as (multiple) microprocessors or a portion thereof, which require software (e.g., firmware) to operate, but may not exist when operation is not required.
[0033] The definition of "circuit system" applies to all uses of the term in this application, including in any claim. As another example, as used in this application, the term "circuit system" also covers only hardware circuitry or a processor (or processors) or a portion of hardware circuitry or a processor and its accompanying software and / or firmware. For example, if applicable to a particular claim element, the term "circuit system" also covers baseband integrated circuits or processor integrated circuits for mobile devices, or similar integrated circuits in servers, cellular network devices, or other computing or network devices.
[0034] As used herein, the term "communication network" refers to a network that conforms to any suitable communication standard, such as fifth-generation (5G) systems, Long Term Evolution (LTE), LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), High-Speed Packet Access (HSPA), Narrowband Internet of Things (NB-IoT), etc. Furthermore, communication between terminal devices and network devices in a communication network can be performed according to any suitable generation of communication protocol, including but not limited to first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, future fifth-generation (5G) New Radio (NR) communication protocols, and / or any other currently known or to be developed in the future. Embodiments of this disclosure can be applied to various communication systems. Given the rapid development of communications, there will naturally be future types of communication technologies and systems that can embody this disclosure. The scope of this disclosure should not be limited to the systems described above.
[0035] As used herein, the term "network device" refers to a node in a communication network through which terminal devices access the network and receive services. A network device can refer to a base station (BS) or access point (AP), such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next-generation NR Node B (gNB), a remote radio unit (RRU), a radio header (RH), a remote radio header end (RRH), an integrated access and backhaul (IAB) node, a repeater, a low-power node (such as a femtosecond or picosecond), etc., depending on the terminology and technology applied. It is permissible to define a network device as part of a gNB, for example, in a CU / DU separation configuration, in which case the network device is defined as gNB-CU or gNB-DU.
[0036] The term "terminal device" refers to any terminal device capable of wireless communication. By way of example and not limitation, a terminal device may also be referred to as a communication device, user equipment (UE), subscriber station (SS), portable subscriber station, mobile station (MS), or access terminal (AT). Terminal devices can include, but are not limited to, mobile phones, cellular phones, smartphones, VoIP phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices (such as digital cameras), gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, wireless endpoints, mobile stations, laptop embedded devices (LEE), laptop in-vehicle devices (LME), USB dongles, smart devices, wireless customer premises equipment (CPE), Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial devices and applications (e.g., robots and / or other wireless devices operating in the context of industrial and / or automated processing chains), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc. Terminal equipment can also correspond to the mobile terminal (MT) portion of an integrated access and backhaul (IAB) node (also known as a relay node). In the following description, the terms "terminal equipment," "communication equipment," "terminal," "user equipment," and "UE" are used interchangeably.
[0037] While the functions described herein may be implemented in fixed and / or wireless network nodes in various example embodiments, in other example embodiments, the functions may be implemented in a user equipment device (such as a mobile phone, tablet, laptop, desktop computer, mobile IoT device, or fixed IoT device). For example, the user equipment device may be suitably equipped with corresponding capabilities as described in combination with (multiple) fixed and / or wireless network nodes. The user equipment device may be a user equipment and / or a control device, such as a chipset or processor, configured to control the user equipment when installed therein. Examples of such functions include boot server functions and / or home subscriber servers, which may be implemented in the user equipment device by providing software configured to cause the user equipment device to perform from the perspective of these functions / nodes.
[0038] Traditionally, data transmission cannot be performed in the RRC_INACTIVE state. That is, for any DL and UL data, the UE must restore the connection (i.e., transition to the RRC_CONNECTED state). For every data transmission, no matter how small or infrequent the data packet, a connection establishment and subsequent release to an inactive state must be performed, which can result in unnecessary power consumption and signaling overhead.
[0039] The signaling overhead for small data packets in inactive UEs is a significant issue. Generally, any device with intermittent small data packet transmission in inactive states will benefit from enabling small data transmission during inactive states. Therefore, to improve network performance and efficiency, as well as UE battery performance, it has been proposed to support SDT in the RRC_INACTIVE state within the NR. To implement data transmission in the RRC_INACTIVE state, 2-step and 4-step RACH protocols, as well as a configured authorization type 1, have been specified.
[0040] For RACH-based SDT, the UE should monitor the Cell Radio Network Temporary Identifier (C-RNTI) after successful contention resolution. For CG-based SDT, the configuration of the configuration grant resources for UE uplink small data transmission may be included in the RRRCRelease message. This configuration is only for Type 1 CG, and there is no contention resolution process for CG.
[0041] Furthermore, for RACH-based SDT and CG-based SDT, when the UE is in the RRC_INACTIVE state, it is highly likely that multiple UL and DL data packets will be sent as part of the same SDT mechanism without transitioning to RRC_CONNECTED on dedicated licenses.
[0042] During an ongoing SDT (Software-Defined Technology) process, if data arrives on a non-SDT Data Radio Bearer (DRB), the UE can immediately terminate the ongoing SDT process and trigger an RRC (Recovery and Restore) procedure. At this point, the security configuration or its parameters allocated by the base station (e.g., gNB) before the UE entered the RRC_INACTIVE state have already been used for the SDT transmission. Such security configurations or parameters are typically one-time parameters and, due to security requirements, should not be used for another RRC connection / recovery attempt. Therefore, no security configuration is available for use during non-SDT procedures.
[0043] To address the aforementioned and other potential problems, embodiments of this disclosure provide a data transmission solution with secure configurations. Generally, a network device (e.g., a gNB) serving a terminal device (e.g., a UE) pre-provides at least one set of secure configurations, and the terminal device can perform SDT and non-SDT procedures using different secure configurations. For example, while an SDT procedure is in progress, the terminal device can trigger a non-SDT procedure due to the arrival of non-SDT data. Furthermore, when an SDT transmission fails, there is no need to transition the terminal device to the RRC_IDLE state as long as available security parameters exist in the set. Therefore, data transmission can be more efficient and flexible, and unnecessary power consumption and signaling overhead can be reduced.
[0044] The following will describe in detail exemplary embodiments of the present disclosure with reference to the accompanying drawings. The principles and embodiments of the present disclosure will be described in detail below with reference to the accompanying drawings.
[0045] Figure 1 An example communication network 100 that can implement embodiments of this disclosure is shown. For example... Figure 1 As shown, the communication network 100 includes a first device 110 and a second device 120.
[0046] First device 110 (hereinafter also referred to as terminal device 110 or UE 110) is located within cell 102 of second device 120 and can communicate with second device 120. First device 110 can perform SDT and / or non-SDT procedures with second device 120, which will be discussed in detail below. SDT procedures may include first device 110 sending RRC messages in RRC_INACTIVE mode and additionally sending data (user or control plane data). In some examples, the RRC message may be an RRC recovery request message, an RRC establishment request message, an RRC reconstruction request message, an RRC SDT request message, an RRC SDT recovery request message, etc. Non-SDT procedures may include first device 110 transitioning from an RRC_IDLE or RRC_INACTIVE state to an RRC_CONNECTED state. In some examples, non-SDT procedures may include first device 110 sending RRC messages. In some examples, the RRC message may be an RRC recovery request message, an RRC establishment request message, an RRC reconstruction request message, an RRC SDT request message, an RRC SDT recovery request message, etc.
[0047] The second device 120 (also referred to as network device 120 or gNB 120) provides cell 102 and serves the first device 110. The second device 120 can send a security configuration to the first device 110 related to data transmission in the RRC_INACTIVE state. In the context of this disclosure, the security configuration may include, but is not limited to, an Inactive Radio Network Temporary Identifier (I-RNTI) and a Next-Hop Link Count (NCC). The I-RNTI may include a short I-RNTI and / or a full I-RNTI. The short I-RNTI may include the identifier of the first device 110 (e.g., UE ID) and the identifier of the second device 120 (e.g., gNB ID), and the short I-RNTI may be 24 bits. The full I-RNTI may include the identifier of the first device 110 and the identifier of the second device 120, and the full I-RNTI may be 40 bits.
[0048] In addition, the communication network 100 may also include a third device (not shown). The third device may be another network device and provide neighboring cells. The cell reselection process may be triggered by the first device 110 using a security configuration between cell 102 and neighboring cells.
[0049] It should be understood that the number of terminal devices and network devices is for illustrative purposes only and does not indicate any limitation. The communication network 100 may include any suitable number of terminal devices appropriate for implementing embodiments of this disclosure.
[0050] For the sake of discussion only, the first device 110 is shown as a UE and the second device 120 is shown as a base station. It should be understood that the UE and the base station are merely example implementations of the first device 110 and the second device 120 respectively, and do not imply any limitation on the scope of this application. Any other suitable implementation is also possible.
[0051] Depending on the communication technology, Network 100 can be a Code Division Multiple Access (CDMA) network, Time Division Multiple Access (TDMA) network, Frequency Division Multiple Access (FDMA) network, Orthogonal Frequency Division Multiple Access (OFDMA) network, Single Carrier Frequency Division Multiple Access (SC-FDMA) network, or any other network. The communications discussed in Network 100 can conform to any suitable standard, including but not limited to New Radio Access (NR), Long Term Evolution (UTE), LTE Evolution, LTE-A Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), cdma2000, and Global System for Mobile Communications (GSM). Furthermore, communications can be performed according to any generation of communication protocols currently known or to be developed in the future. Examples of communication protocols include, but are not limited to, first-generation (1G), second-generation (2G), 2.5G, 2.75G, third-generation (3G), fourth-generation (4G), 4.5G, and fifth-generation (5G) communication protocols. The technologies described herein can be used with the aforementioned wireless networks and radio technologies, as well as other wireless networks and radio technologies. For clarity, certain aspects of the technology are described below in relation to LTE, and the term LTE is used in most of the following description.
[0052] The following will refer to Figure 2 The principles and implementation of this disclosure are described in detail. Figure 2 Signaling diagrams illustrating the process of data transmission utilizing a secure configuration according to some exemplary embodiments of this disclosure are shown. For discussion purposes, reference will be made to... Figure 1 Process 200 is described. Process 200 may involve a first device 110 and a second device 120.
[0053] like Figure 2As shown, the second device 120 sends 202 a plurality of parameters to the first device 110. These a plurality of parameters may be security parameters associated with the RRC connection restoration process between the first device 110 and the second device 120. The RRC connection restoration process may include either an SDT process or a non-SDT process. The SDT process or the non-SDT process may include an RRC restoration process, an RRC establishment process, and an RRC reconstruction process, etc.
[0054] The first set of parameters may include, but is not limited to, I-RNTI, NCC, etc. The I-RNTI can be a short I-RNTI and / or a full I-RNTI. A short I-RNTI may include the identifier of the first device 110 (e.g., UE ID), the identifier of the second device 120 (e.g., gNB ID), and may include 24 bits. A full I-RNTI may include the identifier of the first device 110 (e.g., UE ID), the identifier of the second device 120 (e.g., gNB ID), and a PLMN identifier, and may include 40 bits.
[0055] For example, the first plurality of parameters may include a plurality of I-RNTIs. In some example embodiments, the first I-RNTI of the plurality of I-RNTIs may be a full I-RNTI or a short I-RNTI that includes the identifier of the first device 110 (e.g., UE ID) and the identifier of the second device 120 (e.g., gNBID), and the remaining I-RNTIs of the plurality of I-RNTIs are I-RNTIs that only include the identifier of the first device 110. In some other example embodiments, all of the plurality of I-RNTIs may include a full I-RNTI or a short I-RNTI. In some other example embodiments, the plurality of I-RNTIs may include both a full I-RNTI and a short I-RNTI.
[0056] In some example embodiments, the first plurality of parameters can be received in various RRC messages, including but not limited to RRC release messages, RRC reconfiguration messages, RRC recovery messages, RRC establishment messages, RRC safe mode command messages, RRC reconstruction messages, etc.
[0057] In some example embodiments, the first plurality of parameters may include a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with non-SDT processes. In these embodiments, the first device 110 may select one or more parameters from the first subset for the SDT process, and select different one or more parameters from the second subset for the non-SDT process.
[0058] In some example embodiments, the first device 110 may use the first plurality of parameters in an order provided by the second device 120 or in a predetermined order, the order provided by the second device 120 or the predetermined order indicating that each parameter of the first plurality of parameters may be associated with an SDT process or a non-SDT process, for example, depending on whether an SDT process or a non-SDT process will be executed. In some examples, the order provided by the second device 120 or the predetermined order is determined to be an ascending or descending order of the first plurality of parameters. Alternatively, the first device 110 may select one or more parameters from the first plurality of parameters in a random order.
[0059] In some example embodiments, the first device 110 may receive an indication from the second device 120 indicating whether each of the first plurality of parameters is associated with an SDT process or with a non-SDT process.
[0060] The first device 110 may receive an indication from the second device 120 indicating whether a second set of parameters associated with or not in an SDT process is released or retained. The second set of parameters may be sent earlier than the first set of parameters, and in some examples, the second set of parameters may not overlap with the first set of parameters.
[0061] In some example embodiments, the second device 120 may send such an indication in an RRC release message used to transition the first device 110 to the RRC_INACTIVE state. In some other embodiments, the second device 120 may send such an indication having a first plurality of parameters. In other embodiments, after receiving the first plurality of parameters, the first device 110 may release all old parameters in the second plurality of parameters, regardless of whether there are any available parameters not used for data transmission. Alternatively, if no new parameters are provided in the RRC release message, the first device 110 may retain the second plurality of parameters.
[0062] The first device 110 can determine that a connection restoration process will be performed and send a request for connection restoration to the second device 120. This request may include one or more parameters from a set of parameters. Depending on whether an SDT (Single-Demand Process) or non-SDT (Short-Demand Process) procedure will be performed, the request may be a first request that causes the SDT procedure to be performed, or a second request that causes the non-SDT procedure to be performed.
[0063] In some example embodiments, the first device 110 determines that the SDT procedure 204 will be executed. The first device 110 sends a first request 206 to the second device 120. The first request may include at least one of a plurality of parameters and may cause the SDT procedure with the second device 120 to be executed.
[0064] After receiving the first request from the first device 110, the second device 120 determines that the first request is for the SDT process and that the first request includes at least one of a plurality of parameters. In this case, the second device 120 then executes the SDT process with the first device 110.
[0065] If the SDT procedure is successful, the first device 110 can send SDT-related data to the second device 120. In some example embodiments, the first device 110 may determine that further SDT-related data will be sent, and none of the first plurality of parameters are available for the SDT procedure. In these embodiments, the first device 110 can send this further data through a non-SDT procedure. For example, the first device 110 can send a further request to the second device 120. This further request may include at least one parameter from the first plurality of parameters for the non-SDT procedure and may cause the non-SDT procedure with the second device 120 to be executed. Once the non-SDT procedure is successful, the first device 110 can send further data to the second device 120 during the non-SDT procedure. For example, the non-SDT procedure may include an RRC recovery procedure, in which the first device 110 is transitioned to the RRC_CONNECTED state with the second device 120.
[0066] In the above embodiment, the first device 110 may send a first indication to the second device 120 indicating that none of the first plurality of parameters are available for the SDT process. Upon receiving the first indication, the second device 120 may send at least a third plurality of parameters associated with the SDT process to the first device 110. For security purposes, for example, the third plurality of parameters should not overlap with the first plurality of parameters.
[0067] The SDT process may fail for various reasons, such as the first device 110 triggering cell reselection during the SDT process, radio conditions, non-SDT data available for transmission, SDT timer expiration, invalid TA, or contention resolution failure. For example, if the SDT process fails and the contention resolution in the first attempt is unsuccessful, at least one parameter selected for the SDT process may not need to be changed. In this case, the first device 110 may send a third request to the second device 120, and the third request may include the at least one parameter.
[0068] In some example embodiments, the first device 110 determines that a non-SDT procedure will be sent. The first device 110 sends a second request to the second device 120. The second request may include at least one additional parameter from the first plurality of parameters and may cause the non-SDT procedure with the second device 120 to be executed.
[0069] After receiving the second request from the first device 110, the second device 120 determines 216 that the second request is for a non-SDT procedure and that the second request includes at least one additional parameter from a set of first parameters. In this case, the second device 120 then executes 218 the non-SDT procedure with the first device 110. For example, the non-SDT procedure may include an RRC recovery procedure, in which the first device 110 transitions to the RRC_CONNECTED state with the second device 120.
[0070] During the SDT process, the first device 110 may initiate a non-SDT process with the second device 120. In some example embodiments, if none of the first plurality of parameters are available for the non-SDT process, the first device 110 may enter the RRC_IDLE state and then trigger the RRC connection establishment process by using an RRC establishment request message.
[0071] In some other embodiments, if none of the first plurality of parameters is available for a non-SDT process, the first device 110 may send a second instruction to the second device 120. Upon receiving the second instruction, the second device 120 may send at least a fourth plurality of parameters associated with the non-SDT process to the first device 110. For security purposes, for example, the fourth plurality of parameters should not overlap with the first plurality of parameters.
[0072] In some example embodiments, during the SDT process, the first device 110 may perform a cell reselection process with a third device. In this case, after the cell reselection process, the first device 110 may use an additional parameter from a set of first parameters in a third request to the third device, the additional parameter being different from the at least one parameter used in the SDT process.
[0073] According to an example embodiment of this disclosure, the network device allocates sets of security parameters for both SDT and non-SDT procedures. In this way, the terminal device can trigger a non-SDT procedure while an SDT procedure is in progress, for example, due to the arrival of non-SDT data. Furthermore, when an SDT transmission fails, the terminal device does not need to transition to the RRC_IDLE state as long as available security parameters are present in the set. Therefore, data transmission can be more efficient and flexible, and unnecessary power consumption and signaling overhead can be reduced.
[0074] Figure 3 A flowchart illustrating an example method 300 for data transmission with a secure configuration according to some example embodiments of the present disclosure is shown. Method 300 can be implemented at a terminal device, for example, referring to... Figure 1 The first device 110 is described. For discussion purposes, reference will be made to... Figure 1 Description method 300.
[0075] At 310, the first device 110 receives a first plurality of parameters from the second device 120. The first plurality of parameters may be associated with a connection restoration process between the first device 110 and the second device 120, including, for example, an SDT process and a non-SDT process.
[0076] In some example embodiments, the first plurality of parameters can be received in various RRC messages, including but not limited to RRC release messages, RRC reconfiguration messages, RRC recovery messages, RRC establishment messages, RRC safe mode command messages, RRC reconstruction messages, etc.
[0077] In some example embodiments, the first plurality of parameters may be security parameters, including but not limited to NCC, I-RNTI, etc. For example, the first plurality of parameters may include multiple I-RNTIs. In some example embodiments, the first I-RNTI among the plurality of I-RNTIs may be a complete I-RNTI or a short I-RNTI that includes the identifier of the first device 110 (e.g., UE ID) and the identifier of the second device 120 (e.g., gNB ID), and the remaining I-RNTIs among the plurality of I-RNTIs are I-RNTIs that only include the identifier of the first device 110. In some other example embodiments, all the plurality of I-RNTIs may include complete I-RNTIs or short I-RNTIs. In some other example embodiments, the plurality of I-RNTIs may include both complete I-RNTIs and short I-RNTIs.
[0078] In some example embodiments, the first plurality of parameters may include a first subset of the first plurality of parameters associated with the SDT process and a second subset of the first plurality of parameters associated with non-SDT processes.
[0079] In some example embodiments, the first plurality of parameters may be ordered in a predetermined order, which indicates that each of the first plurality of parameters is associated with an SDT process or a non-SDT process. The SDT process or the non-SDT process may include an RRC recovery process, an RRC establishment process, an RRC reconstruction process, etc.
[0080] In some example embodiments, the first device 110 may receive an indication from the second device 120 indicating whether each of the first plurality of parameters is associated with an SDT process or a non-SDT process, for example, depending on whether an SDT process or a non-SDT process will be executed. In some examples, the order or predetermined order provided by the second device 120 is determined to be an ascending or descending order of the first plurality of parameters.
[0081] The first device 110 can then enter an inactive state. At 320, the first device 110 determines whether the connection restoration process will be executed.
[0082] If the first device 110 determines at 320 that a connection restoration process will be performed, then the first device 110 sends a request for connection restoration to the second device 120 at 330. This request may include one or more parameters from a set of multiple parameters.
[0083] Depending on whether an SDT (Simplified Derivative Process) or non-SDT (Simplified Derivative Process) procedure will be executed, the request can be a first request to cause the SDT procedure to be executed, or a second request to cause the non-SDT procedure to be executed. For example, if the first device 110 determines at 320 that an SDT will be executed, then the first device 110 sends a first request to the second device 120 at 330. The first request may include at least one parameter from a first set of parameters. In another example, if the first device 110 determines at 320 that a non-SDT will be executed, then the first device 110 sends a second request to the second device 120 at 330. The second request may include at least one additional parameter from the first set of parameters.
[0084] In some example implementations, the request may include, but is not limited to, RRC recovery request, RRC reconstruction request, RRCSDT request, etc.
[0085] In some example embodiments, the first device 110 may determine one or more of the above parameters based on the order of a first plurality of parameters.
[0086] At 340, the first device 110 performs a connection restoration procedure with the second device. If the SDT procedure is executed successfully, the first device 110 may send SDT-related data to the second device 120. If the SDT procedure with the second device 120 fails, the first device 110 may send a third request to the second device 120. The third request may include at least one parameter included in the first request.
[0087] If further data related to the SDT is to be sent and none of the first plurality of parameters are available for the SDT process, the first device 110 may send a further request to the second device 120. This further request may include at least one parameter from the first plurality of parameters used for non-SDT processes and may cause a non-SDT process with the second device 120 to be executed. In this case, the first device 110 may send further data to the second device 120 during the non-SDT process.
[0088] If none of the first plurality of parameters are available for the SDT process, the first device 110 may send a first indication to the second device 120. The first indication may be configured to indicate that none of the first plurality of parameters are available for the SDT process. In this case, the first device 110 may then receive at least a third plurality of parameters associated with the SDT process from the second device 120. The third plurality of parameters should not overlap with the first plurality of parameters.
[0089] If further data related to the non-SDT process is to be sent and none of the first plurality of parameters are available for the non-SDT process, the first device 110 may send a second indication to the second device 120. The second indication may be configured to indicate that none of the first plurality of parameters are available for the non-SDT process. In this case, the first device 110 may then receive at least a fourth plurality of parameters associated with the non-SDT process from the second device 120. Similarly, the fourth plurality of parameters should not overlap with the first plurality of parameters.
[0090] In some example embodiments, the first device 110 may perform a cell reselection process with the third device based on additional parameters among the first plurality of parameters.
[0091] In some example embodiments, the first device 110 may receive an indication from the second device 120 indicating whether a second set of parameters associated with and not associated with the SDT process have been released or retained. The second set of parameters is received earlier than the first set of parameters. For security purposes, the second set of parameters should not overlap with the first set of parameters.
[0092] Figure 4 A flowchart illustrating an example method 400 for data transmission with a secure configuration according to some example embodiments of the present disclosure is shown. Method 400 can be implemented at a network device, for example, as described in reference to... Figure 1 The second device 120 is described. For discussion purposes, reference will be made to... Figure 1 Description method 400.
[0093] Before the first device 110 enters an inactive state (e.g., RRC_INACTIVE state), the second device 120 sends a first plurality of parameters to the first device 110 at 410. The first plurality of parameters may be associated with a connection restoration process between the first device 110 and the second device 120, such as an RRC connection restoration process, which may include an SDT process and non-SDT processes.
[0094] In some example embodiments, the first plurality of parameters can be received in various RRC messages, including but not limited to RRC release messages, RRC reconfiguration messages, RRC recovery messages, RRC establishment messages, RRC safe mode command messages, RRC reconstruction messages, etc.
[0095] In some example embodiments, the first plurality of parameters may be security parameters, including but not limited to NCC, I-RNTI, etc. For example, the first plurality of parameters may include multiple I-RNTIs. In some example embodiments, the first I-RNTI among the plurality of I-RNTIs may be a complete I-RNTI or a short I-RNTI that includes the identifier of the first device 110 (e.g., UE ID) and the identifier of the second device 120 (e.g., gNB ID), and the remaining I-RNTIs among the plurality of I-RNTIs are I-RNTIs that only include the identifier of the first device 110. In some other example embodiments, all the plurality of I-RNTIs may include complete I-RNTIs or short I-RNTIs. In some other example embodiments, the plurality of I-RNTIs may include both complete I-RNTIs and short I-RNTIs.
[0096] In some example embodiments, the first plurality of parameters may include a first subset of the first plurality of parameters associated with the SDT process and a second subset of the first plurality of parameters associated with non-SDT processes.
[0097] In some example embodiments, the first plurality of parameters may be ordered in a predetermined order, the predetermined order indicating that each of the first plurality of parameters is associated with an SDT process or a non-SDT process.
[0098] In some example embodiments, the second device 120 may send an indication to the first device 110 indicating whether each of the first plurality of parameters is associated with an SDT process or a non-SDT process.
[0099] Then, the first device 110 can enter an inactive state and determine that either an SDT process or a non-SDT process will be executed. The SDT process or non-SDT process may include an RRC recovery process, an RRC establishment process, an RRC reconstruction process, etc. To initiate the corresponding SDT process or non-SDT process, the first device 110 may send a request for connection restoration to the second device 120.
[0100] At 420, the second device 120 receives a request from the first device 110 for connection restoration. This request may include one or more parameters from a set of parameters. Depending on whether an SDT (Self-Delivery Technology) or non-SDT (Self-Delivery Technology) procedure will be performed, the request may be a first request that causes an SDT procedure to be performed and a second request that causes a non-SDT procedure to be performed.
[0101] In some example embodiments, the request received from the first device 110 may include, but is not limited to, an RRC recovery request, an RRC rebuild request, an RRC SDT request, etc. The request may include one or more parameters from a set of first plurality of parameters.
[0102] In some example embodiments, the second device 120 may determine whether it has received a first request or a second request from the first device 110. In some example embodiments, the second device 120 may determine whether one or more parameters are associated with an SDT process or a non-SDT process based on the resources on which the request was received.
[0103] At 430, after receiving the request, the second device 120 executes a connection restoration procedure with the first device 110, namely, one of the SDT (Signal Deployment and Deployment) procedure and a non-SDT procedure with the first device. For example, if the second device 120 determines that it has received the first request and the first request includes at least one of a first plurality of parameters, then at 430, the second device 120 executes the SDT procedure with the first device 110. If the SDT procedure is successful, the second device 120 can receive SDT-related data from the first device 110.
[0104] In some example embodiments, if contention resolution for the Random Access (RA) procedure is successful during the SDT process, or if the RA procedure is completed, or if the first device 110 has a valid C-RNTI and the SDT procedure is in progress and there is non-SDT data to be transmitted, the first device 110 may send a new RRC message (e.g., via SRB1), or an existing RRC message (e.g., a UE Assistance Information message indicating its preference to enter a connected mode), or a new MAC CE requesting a connection for the non-SDT data. Upon receiving the RRC message or MAC CE, the second device 120 may transition the first device 110 to the RRC_CONNECTED state.
[0105] If the SDT process fails for various reasons (e.g., cell reselection is triggered during the SDT process, radio conditions, non-SDT data available for transmission, SDT timer expiration, TA validity, contention resolution failure, etc.), a new SDT process can be initiated between the first device 110 and the second device 120.
[0106] In some example embodiments, after performing an SDT procedure with the first device 110, the second device 120 may receive another request from the inactive first device 110. In these embodiments, if the other request is a second request that includes at least one additional parameter from a set of first parameters, the second device 120 may perform a non-SDT procedure with the first device 110.
[0107] In another example, if the second device 120 determines that the second request has been received, then at 430, the second device 120 performs a non-SDT procedure with the first device 110. For example, the non-SDT procedure includes an RRC recovery procedure, in which the first device 110 transitions to the RRC_CONNECTED state with the second device 120.
[0108] In some example embodiments, the second device 120 may receive further requests from the first device 110. If the second device 120 determines that the request is a second request that includes at least one parameter from a first plurality of parameters used for a non-SDT process, then the second device 120 may perform a non-SDT process with the first device 110. The second device 120 may then receive further data during the non-SDT process.
[0109] In the above embodiment, the second device 120 may receive a first indication from the first device 110 that none of the first plurality of parameters are available for the SDT process. Upon receiving the first indication, the second device 120 may send at least a third plurality of parameters associated with the SDT process to the first device 110. For security purposes, the third plurality of parameters should not overlap with the first plurality of parameters.
[0110] If the SDT process is successful, the second device 120 may further receive from the first device 110 a second indication that none of the first plurality of parameters are available for non-SDT processes. Upon receiving the second indication, the second device 120 may send to the first device 110 at least a fourth plurality of parameters associated with the non-SDT process. Similarly, the fourth plurality of parameters should not overlap with the first plurality of parameters.
[0111] In some example embodiments, the second device 120 may send an indication to the first device 110 indicating whether a second set of parameters associated with and not associated with the SDT process are released or retained. The second set of parameters is sent earlier than the first set of parameters, and the second set of parameters should not overlap with the first set of parameters.
[0112] In the above embodiment, the second device 120 may send an RRC release message to the first device 110, which is in an inactive state, to indicate whether the second plurality of parameters should be released or retained. Alternatively, such an indication may be sent together with the first plurality of parameters.
[0113] In the above embodiments, the second device 120 may explicitly indicate to the first device 110 all old parameters in the old set, that is, the second plurality of parameters will be released regardless of whether any available parameters exist. Alternatively, if no new parameters are provided in the RRC release message, it implies that the parameters in the second plurality of parameters should be retained at the first device 110.
[0114] In some example embodiments, a first means capable of performing method 300 (e.g., first device 110) may include components for performing corresponding steps of method 300. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module. The first means may be implemented as first device 110 or included within first device 110. In some embodiments, the components may include at least one processor and 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 cause execution of the first means.
[0115] In some example embodiments, the first device includes: components for receiving from the second device a first plurality of parameters associated with a connection restoration process between the first device and the second device; components for sending a request for connection restoration to the second device in an inactive state, the request including one or more of the first plurality of parameters, based on a determination that the connection restoration process will be performed; and components for performing the connection restoration process with the second device.
[0116] In some example embodiments, the first plurality of parameters includes at least one of the following: next-hop link count (NCC) and inactive radio network temporary identifier (I-RNTI).
[0117] In some example embodiments, the first plurality of parameters includes a plurality of I-RNTIs, wherein the first I-RNTI among the plurality of I-RNTIs includes an identifier of the first device and an identifier of the second device, and the remaining I-RNTIs among the plurality of I-RNTIs include only an identifier of the first device.
[0118] In some example embodiments, the first plurality of parameters includes at least one of the following: a plurality of NCCs, a plurality of complete I-RNTIs, and a plurality of short I-RNTIs.
[0119] In some example embodiments, the first plurality of parameters are received in one of the following: Radio Resource Control (RRC) release message, RRC reconfiguration message, RRC recovery message, RRC establishment message, RRC security mode command message, or RRC reconstruction message.
[0120] In some example embodiments, the connection recovery process includes a small data transfer SDT process and a non-SDT process.
[0121] In some example embodiments, the SDT process or non-SDT process includes one of the following: RRC recovery process, RRC establishment process, and RRC reconstruction process.
[0122] In some example embodiments, the first plurality of parameters includes a first subset of the first plurality of parameters associated with the SDT process and a second subset of the first plurality of parameters associated with non-SDT processes.
[0123] In some example embodiments, the first plurality of parameters are ordered in a predetermined order, which indicates that each of the first plurality of parameters is associated with an SDT process or a non-SDT process.
[0124] In some example embodiments, the request includes one of the following: Radio Resource Control (RRC) recovery request, RRC reconstruction request, or RRC SDT request.
[0125] In some example embodiments, the request includes one of the following: Radio Resource Control (RRC) recovery request, RRC reconstruction request, or RRC SDT request.
[0126] In some example embodiments, the first device further includes a component for receiving from the second device an indication of whether each of the first plurality of parameters is associated with an SDT process or a non-SDT process.
[0127] In some example embodiments, the first device further includes components for determining at least one parameter and at least one additional parameter based on the order of a first plurality of parameters.
[0128] In some example embodiments, the component for sending the request includes: a component for sending a first request to a second device in an inactive state to cause the SDT process to be executed based on a determination that the SDT process will be executed, the first request including at least one of a first plurality of parameters; and a component for sending a second request to the second device in an inactive state to cause a non-SDT process to be executed based on a determination that a non-SDT process will be executed, the second request including at least one additional parameter of the first plurality of parameters.
[0129] In some example embodiments, the first device further includes: a component for sending a further request to the second device to cause a non-SDT process to be performed based on the determination that further data related to the SDT will be sent and that none of the first plurality of parameters are available for the SDT process, the further request including at least one of the first plurality of parameters associated with the non-SDT process; and a component for sending further data to the second device during the non-SDT process.
[0130] In some example embodiments, the first device further includes: a component for sending a first indication to the second device, the first indication indicating that none of the first plurality of parameters are available for the SDT process; and a component for receiving from the second device at least a third plurality of parameters associated with the SDT process, the third plurality of parameters not overlapping with the first plurality of parameters.
[0131] In some example embodiments, depending on whether the SDT process will be executed, the components for executing the SDT process include: components for sending SDT-related data to the second device.
[0132] In some example embodiments, the first device further includes a component for sending a third request, comprising one or more of a first plurality of parameters, to a second device based on a determination that the SDT process has failed.
[0133] In some example embodiments, the first device further includes: a component for sending a second instruction to the second device based on determining that further data related to the non-SDT process will be sent and that none of the first plurality of parameters are available for the non-SDT process; and a component for receiving from the second device at least a fourth plurality of parameters associated with the non-SDT process, the fourth plurality of parameters not overlapping with the first plurality of parameters.
[0134] In some example embodiments, the first device includes: a component for performing a cell reselection process with a third device based on at least one additional parameter among a first plurality of parameters, the third device being different from the second device.
[0135] In some example embodiments, the first device includes a component for receiving an indication from the second device, the indication indicating whether a second plurality of parameters associated with the SDT process and non-SDT processes are released or retained, the second plurality of parameters not overlapping with the first plurality of parameters, and the second plurality of parameters being received earlier than the first plurality of parameters.
[0136] In some example embodiments, the first device includes a terminal device, and the second device includes a network device.
[0137] In some example embodiments, a second means (e.g., a second device 120) capable of performing method 400 may include components for performing corresponding steps of method 400. These components may be implemented in any suitable form. For example, the components may be implemented in a circuit system or a software module. In some embodiments, the components may include at least one processor and 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 cause execution of the second means. The second means may be implemented as or included in the second device 120.
[0138] In some example embodiments, the second device includes: components for sending a first plurality of parameters associated with a connection restoration process between the first device and the second device to the first device; components for sending the first plurality of parameters associated with a connection restoration process between the first device and the second device to the first device; and components for performing a connection restoration process with the first device in response to the request.
[0139] In some example embodiments, the first plurality of parameters includes at least one of the following: next-hop link count (NCC) and inactive radio network temporary identifier (I-RNTI).
[0140] In some example embodiments, the first plurality of parameters includes a plurality of I-RNTIs, wherein the first I-RNTI among the plurality of I-RNTIs includes an identifier of the first device and an identifier of the second device, and the remaining I-RNTIs among the plurality of I-RNTIs include only an identifier of the first device.
[0141] In some example embodiments, the first plurality of parameters includes at least one of the following: a plurality of NCCs, a plurality of complete I-RNTIs, and a plurality of short I-RNTIs.
[0142] In some example embodiments, the first plurality of parameters are received in one of the following: Radio Resource Control (RRC) release message, RRC reconfiguration message, RRC recovery message, RRC establishment message, RRC security mode command message, or RRC reconstruction message.
[0143] In some example embodiments, the connection recovery process includes a small data transfer SDT process and a non-SDT process.
[0144] In some example embodiments, the SDT process or non-SDT process includes one of the following: RRC recovery process, RRC establishment process, and RRC reconstruction process.
[0145] In some example embodiments, the first plurality of parameters includes a first subset of the first plurality of parameters associated with the SDT process and a second subset of the first plurality of parameters associated with non-SDT processes.
[0146] In some example embodiments, the first plurality of parameters are ordered in a predetermined order, which indicates that each of the first plurality of parameters is associated with an SDT process or a non-SDT process.
[0147] In some example embodiments, the request received from the first device includes one of the following: a Radio Resource Control (RRC) recovery request, an RRC reconstruction request, or an RRC SDT request.
[0148] In some example embodiments, the second device further includes a component for sending an instruction to the first device, the instruction indicating whether each of the first plurality of parameters is associated with an SDT process or a non-SDT process.
[0149] In some example embodiments, the second apparatus further includes a component for determining, based on the resource for which the request is received, whether one or more parameters are associated with an SDT process or a non-SDT process.
[0150] In some example embodiments, the request includes either a first request or a second request, the first request being for causing an SDT process to be executed, the second request being for causing a non-SDT process to be executed, and the components for executing a corresponding process include: components for executing an SDT process with the first device in response to the first request; and components for executing a non-SDT process with the first device in response to the second request.
[0151] In some example embodiments, the request is a first request, and after the SDT process is performed, the second device further includes: components for receiving another request from the first device, which is in an inactive state; and components for performing a non-SDT process with the first device based on determining that the other request is a second request that includes at least one additional parameter from a first plurality of parameters.
[0152] In some example embodiments, the second device further includes: components for receiving a further request from the first device; components for performing a non-SDT process with the first device based on determining that the request is a second request including at least one parameter from a first plurality of parameters for a non-SDT process; and components for receiving further data during the non-SDT process.
[0153] In some example embodiments, the second device further includes: a component for receiving from the first device a first indication that no parameter among the first plurality of parameters is available for the SDT process; and a component for receiving from the first device a first indication that no parameter among the first plurality of parameters is available for the SDT process.
[0154] In some example embodiments, a request is made to cause the SDT process to be executed, and the components for executing the SDT process include components for receiving SDT-related data from the first means.
[0155] In some example embodiments, the second device further includes: a component for receiving from the first device a second indication that none of the first plurality of parameters are available for a non-SDT process; and a component for sending to the first device, in response to the second indication, at least a fourth plurality of parameters associated with a non-SDT process, the fourth plurality of parameters not overlapping with the first plurality of parameters.
[0156] In some example embodiments, the second device further includes a component for sending an indication to the first device, the indication indicating whether a second plurality of parameters associated with the SDT process and non-SDT processes are released or retained, the second plurality of parameters not overlapping with the first plurality of parameters, and the second plurality of parameters being sent earlier than the first plurality of parameters.
[0157] In some example embodiments, the first device includes a terminal device, and the second device includes a network device.
[0158] Figure 5 This is a simplified block diagram of a device 500 suitable for implementing embodiments of the present disclosure. The device 500 can be provided to implement a communication device, such as... Figure 1 The first device 110 or the second device 120 shown. As shown, device 500 includes one or more processors 510, one or more memories 520 coupled to processor 510, and one or more transmitters and receivers (TX / RX) 540 coupled to processor 510.
[0159] The TX / RX 540 is used for bidirectional communication. The TX / RX 540 has at least one antenna to facilitate communication. The communication interface can represent any interface necessary for communication with other network components.
[0160] Processor 510 can be of any type suitable for a local technology network, and by way of non-limiting example, can include one or more of the following: general-purpose computer, special-purpose computer, microprocessor, digital signal processor (DSP), and processor based on a multi-core processor architecture. Device 500 can have multiple processors, such as application-specific integrated circuit chips that are time-subordinate to a clock synchronized with the main processor.
[0161] Memory 520 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memories include, but are not limited to, read-only memory (ROM) 524, electrically programmable read-only memory (EPROM), flash memory, hard disk, optical disc (CD), digital video disc (DVD), and other magnetic and / or optical memories. Examples of volatile memories include, but are not limited to, random access memory (RAM) 522 and other volatile memories that do not persist during power-off periods.
[0162] Computer program 530 includes computer-executable instructions that are executed by the associated processor 510. Program 530 may be stored in ROM 520. Processor 510 can perform any suitable actions and processes by loading program 530 into RAM 520.
[0163] The embodiments of this disclosure can be implemented via program 530 so that device 500 can execute the reference. Figures 2 to 4 Any process discussed in this disclosure. Embodiments of this disclosure may also be implemented by hardware or by a combination of software and hardware.
[0164] In some embodiments, program 530 may be tangibly contained in a computer-readable medium, which may be included in device 500 (e.g., memory 520) or other storage device accessible by device 500. Device 500 may load program 530 from the computer-readable medium into RAM 522 for execution. The computer-readable medium may include any type of tangible non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc. Figure 6 An example of a computer-readable medium 600 in the form of a CD or DVD is shown. This computer-readable medium has a program 530 stored thereon.
[0165] Generally, the various embodiments of this disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects can be implemented in hardware, while others can be implemented in firmware or software, which can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of this disclosure are illustrated and described with block diagrams, flowcharts, or some other graphical representation, it should be understood that, as non-limiting examples, the blocks, devices, systems, techniques, or methods described herein can be implemented in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or controllers or other computing devices, or some combination thereof.
[0166] This disclosure also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions that execute in a device on a target real or virtual processor, such as instructions contained in a program module, to perform the above-referenced... Figure 3 and Figure 4 Methods 300 and 400 are described. Typically, a program module includes routines, programs, libraries, objects, classes, components, data structures, etc., that perform specific tasks or implement specific abstract data types. In various embodiments, the functionality of a program module can be combined or separated as needed. The machine-executable instructions of the program module can be executed locally or on a distributed device. In a distributed device, the program module can reside on both local and remote storage media.
[0167] Program code used to perform the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that, when executed by the processor or controller, the program code enables the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a stand-alone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.
[0168] In the context of this disclosure, computer program code or related data may be carried by any suitable carrier to enable a device, apparatus, or processor to perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, etc.
[0169] Computer-readable media can be computer-readable signal media or computer-readable storage media. Computer-readable media can include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any suitable combination thereof. More specific examples of computer-readable storage media include electrical connections having one or more lines, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable optical disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.
[0170] Furthermore, although operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or sequentially, or to perform all of the operations shown, to obtain the desired result. In some cases, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure, but rather as a specific description of the features of particular embodiments. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.
[0171] Although this disclosure is described in language specific to structural features and / or methodological behaviors, it should be understood that the disclosure as defined in the appended claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as exemplary forms of implementing the claims.
Claims
1. A first 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 cause the first device to at least: Receive a first plurality of parameters from the second device, the first plurality of parameters being associated with a connection restoration process between the first device and the second device; Based on the determination that the connection restoration process will be executed, a request for connection restoration is sent to the second device in an inactive state, the request including one or more parameters from the first plurality of parameters; as well as Perform the connection restoration process with the second device. The connection restoration process includes a Small Data Transfer (SDT) process and a non-SDT process, and The first plurality of parameters includes: a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with the non-SDT process.
2. The first device of claim 1, wherein the first plurality of parameters includes at least one of the following: next-hop link count (NCC) and inactive radio network temporary identifier (I-RNTI).
3. The first device according to claim 1, wherein the first plurality of parameters includes a plurality of I-RNTIs, and wherein the first I-RNTI of the plurality of I-RNTIs includes the identifier of the first device and the identifier of the second device, and the remaining I-RNTIs of the plurality of I-RNTIs include only the identifier of the first device.
4. The first device according to claim 1, wherein the first plurality of parameters includes at least one of the following: a plurality of NCCs, a plurality of complete I-RNTIs, and a plurality of short I-RNTIs.
5. The first device according to claim 1, wherein the first plurality of parameters are received in one of the following ways: Radio Resource Control (RRC) release message, RRC reconfiguration message, RRC recovery message, RRC establishment message, RRC security mode command message, or RRC reconstruction message.
6. The first device of claim 1, wherein the request includes one of the following: a Radio Resource Control (RRC) recovery request, an RRC reconstruction request, or an RRC SDT request.
7. The first device according to claim 1, wherein the first device is further configured such that: The one or more parameters are determined based on the order of the first plurality of parameters.
8. The first device according to claim 1, wherein the SDT process or the non-SDT process includes one of the following: a Radio Resource Control (RRC) recovery process, an RRC establishment process, and an RRC reconstruction process.
9. The first device of claim 1, wherein the first plurality of parameters are ordered in a predetermined order, the predetermined order indicating that each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
10. The first device according to claim 1, wherein the first device is further configured such that: Receive from the second device an indication of whether each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
11. The first device according to claim 1, wherein the first device is further configured such that: The second device receives an indication that a second plurality of parameters associated with the SDT process and the non-SDT process are released or retained, the second plurality of parameters not overlapping with the first plurality of parameters, and the second plurality of parameters being received earlier than the first plurality of parameters.
12. The first device of claim 1, wherein the first device is further configured to send the request by: Based on the determination that the SDT process will be executed, a first request for executing the SDT process is sent to the second device in an inactive state, the first request including at least one of the first plurality of parameters; and Based on the determination that the non-SDT process will be executed, a second request is sent to the second device in an inactive state to cause the non-SDT process to be executed, the second request including at least one additional parameter among the first plurality of parameters.
13. The first device according to claim 12, wherein the first device is further configured such that: Based on the determination that further data related to the SDT will be sent, and that none of the first plurality of parameters are available for the SDT process, a further request is sent to the second device to cause the non-SDT process to be executed, the further request including at least one parameter from the first plurality of parameters associated with the non-SDT process; and The further data is sent to the second device during the non-SDT process.
14. The first device according to claim 13, wherein the first device is further configured such that: Send a first indication to the second device to indicate that none of the first plurality of parameters are available for the SDT process; and Receive at least a third plurality of parameters associated with the SDT process from the second device, wherein the third plurality of parameters do not overlap with the first plurality of parameters.
15. The first device of claim 1, wherein, based on the determination that the SDT process will be executed, the first device is caused to execute the SDT process by: Send data related to the SDT to the second device.
16. The first device according to claim 15, wherein the first device is further configured such that: If the SDT process is determined to have failed, a third request is sent to the second device, the third request including one or more of the first plurality of parameters.
17. The first device according to claim 15, wherein after the SDT process, the first device is further configured to: Based on the determination that further data related to the non-SDT will be sent, and that none of the first plurality of parameters are available for the non-SDT process, a second instruction is sent to the second device; and The second device receives at least a fourth plurality of parameters associated with the non-SDT process, the fourth plurality of parameters not overlapping with the first plurality of parameters.
18. The first device according to claim 1, wherein the first device is further configured such that: Based on at least one additional parameter among the first plurality of parameters, a cell reselection process is performed with a third device, which is different from the second device.
19. A second 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 cause the second device to at least: Send a first plurality of parameters to a first device, the first plurality of parameters being associated with a connection restoration process between the first device and the second device; Receive a request for connection restoration from the first device, the request including one or more of the first plurality of parameters; and In response to the request, the connection restoration process with the first device is performed. The connection restoration process includes a Small Data Transfer (SDT) process and a non-SDT process, and The first plurality of parameters includes: a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with the non-SDT process.
20. The second device of claim 19, wherein the first plurality of parameters includes at least one of the following: next-hop link count (NCC) and inactive radio network temporary identifier (I-RNTI).
21. The second device of claim 20, wherein the first plurality of parameters includes a plurality of I-RNTIs, and wherein the first I-RNTI of the plurality of I-RNTIs includes an identifier of the first device and an identifier of the second device, and the remaining I-RNTIs of the plurality of I-RNTIs include only the identifier of the first device.
22. The second device of claim 20, wherein the first plurality of parameters includes a plurality of complete I-RNTIs, the plurality of complete I-RNTIs including the identifier of the first device and the identifier of the second device.
23. The second device of claim 19, wherein the first plurality of parameters are received in one of the following ways: Radio Resource Control (RRC) release message, RRC reconfiguration message, RRC recovery message, RRC establishment message, RRC security mode command message, or RRC reconstruction message.
24. The second device of claim 19, wherein the request received from the first device includes one of the following: a Radio Resource Control (RRC) recovery request, an RRC reconstruction request, or an RRC SDT request.
25. The second device of claim 19, wherein the first plurality of parameters are ordered in a predetermined order, the predetermined order indicating that each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
26. The second device according to claim 19, wherein the second device is further configured such that: Send an indication to the first device indicating whether each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
27. The second device according to claim 19, wherein the second device is further configured such that: Based on the resources for which the above-described request is received, determine whether the one or more parameters are associated with the SDT process or the non-SDT process.
28. The second device of claim 19, wherein the request comprises one of: a first request for causing the SDT process to be executed, or a second request for causing the non-SDT process to be executed, and wherein the second device is caused to execute a corresponding process by: In response to the first request, the SDT procedure with the first device is performed; and In response to the second request, the non-SDT procedure with the first device is performed.
29. The second device of claim 28, wherein the request is the first request, and after performing the SDT procedure, the second device is further caused to: Receive additional requests from the first device while it is inactive; and Based on the determination that the additional request is a second request that includes at least one additional parameter from the first plurality of parameters, the non-SDT process with the first device is performed.
30. The second device according to claim 28, wherein the second device is further configured such that: Receive further requests from the first device; Based on the determination that the request is a second request including at least one parameter from the first plurality of parameters for the non-SDT process, the non-SDT process with the first device is executed; and The further data is received during the non-SDT process.
31. The second device according to claim 30, wherein the second device is further configured such that: Receive a first indication from the first device that none of the first plurality of parameters are available for the SDT process; and In response to the first instruction, at least a third plurality of parameters associated with the SDT process are sent to the first device, the third plurality of parameters not overlapping with the first plurality of parameters.
32. The second device of claim 19, wherein, based on the determination that the SDT process will be performed, the second device is caused to perform the SDT process by: Receive data related to the SDT from the first device.
33. The second device according to claim 32, wherein the second device is further configured such that: Receive a second indication from the first device that none of the first plurality of parameters are available for the non-SDT process; and In response to the second instruction, a fourth plurality of parameters associated with the non-SDT process are sent to the first device, the fourth plurality of parameters not overlapping with the first plurality of parameters.
34. The second device according to claim 19, wherein the second device is further configured such that: Send an indication to the first device to indicate whether a second plurality of parameters associated with the SDT process or the non-SDT process are released or retained, the second plurality of parameters not overlapping with the first plurality of parameters, and the second plurality of parameters being sent earlier than the first plurality of parameters.
35. The second device according to any one of claims 19 to 34, wherein the first device includes a terminal device and the second device includes a network device.
36. A method for communication, comprising: At the first device, a first plurality of parameters are received from the second device, the first plurality of parameters being associated with a connection restoration process between the first device and the second device; Based on the determination that the connection restoration process will be executed, a request for connection restoration is sent to the second device in an inactive state, the request including one or more parameters from the first plurality of parameters; as well as Perform the connection restoration process with the second device. The connection restoration process includes a Small Data Transfer (SDT) process and a non-SDT process. And wherein the first plurality of parameters includes: a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with the non-SDT process.
37. The method of claim 36, wherein the first plurality of parameters includes at least one of the following: next-hop link count (NCC) and inactive radio network temporary identifier (I-RNTI).
38. The method of claim 36, wherein the first plurality of parameters includes a plurality of I-RNTIs, and wherein the first I-RNTI of the plurality of I-RNTIs includes the identifier of the first device and the identifier of the second device, and the remaining I-RNTIs of the plurality of I-RNTIs include only the identifier of the first device.
39. The method of claim 36, wherein the first plurality of parameters includes at least one of the following: a plurality of NCCs, a plurality of complete I-RNTIs, and a plurality of short I-RNTIs.
40. The method of claim 36, wherein the first plurality of parameters is received in one of the following: Radio Resource Control (RRC) release message, RRC reconfiguration message, RRC recovery message, RRC establishment message, RRC security mode command message, or RRC reconstruction message.
41. The method of claim 36, wherein the request comprises one of the following: a Radio Resource Control (RRC) recovery request, an RRC reconstruction request, or an RRC SDT request.
42. The method of claim 36, further comprising: Based on the order of the first plurality of parameters, at least one parameter and at least one other parameter are determined.
43. The method of claim 36, wherein the first plurality of parameters are ordered in a predetermined order, the predetermined order indicating that each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
44. The method of claim 36, further comprising: Receive from the second device an indication of whether each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
45. The method of claim 36, wherein sending the request comprises: Based on the determination that the SDT process will be executed, a first request is sent to the second device in an inactive state to cause the SDT process to be executed, the first request including at least one of the first plurality of parameters; as well as Based on the determination that the non-SDT process will be executed, a second request is sent to the second device in an inactive state to cause the non-SDT process to be executed, the second request including at least one additional parameter among the first plurality of parameters.
46. The method of claim 45, further comprising: Based on the determination that further data related to the SDT will be sent, and that none of the first plurality of parameters are available for the SDT process, a further request is sent to the second device to cause the non-SDT process to be executed, the further request including at least one parameter from the first plurality of parameters associated with the non-SDT process; and The further data is sent to the second device during the non-SDT process.
47. The method of claim 46, further comprising: Send a first indication to the second device to indicate that none of the first plurality of parameters are available for the SDT process; as well as Receive at least a third plurality of parameters associated with the SDT process from the second device, wherein the third plurality of parameters do not overlap with the first plurality of parameters.
48. The method of claim 36, wherein determining that the SDT procedure will be performed, performing the SDT procedure comprises: Send data related to the SDT to the second device.
49. The method of claim 48, further comprising: Based on the determination of the failure of the SDT process, a third request is sent to the second device, the third request including one or more of the first plurality of parameters.
50. The method of claim 48, further comprising: Based on the determination that further data related to the non-SDT will be sent and that none of the first plurality of parameters are available for the non-SDT process, a second instruction is sent to the second device; as well as The second device receives at least a fourth plurality of parameters associated with the non-SDT process, the fourth plurality of parameters not overlapping with the first plurality of parameters.
51. The method of claim 36, further comprising: Based on at least one additional parameter among the first plurality of parameters, a cell reselection process is performed with a third device, which is different from the second device.
52. The method of claim 36, further comprising: The second device receives an indication of whether a second plurality of parameters associated with the SDT process or the non-SDT process are released or retained, the second plurality of parameters not overlapping with the first plurality of parameters, and the second plurality of parameters being received earlier than the first plurality of parameters.
53. A method for communication, comprising: Send a first plurality of parameters to a first device, the first plurality of parameters being associated with a connection restoration process between the first device and the second device; Receive a request to restore connection from the first device, the request including one or more parameters from the first plurality of parameters; and In response to the request, the connection restoration process with the first device is performed. The connection restoration process includes a Small Data Transfer (SDT) process and a non-SDT process, and The first plurality of parameters includes: a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with the non-SDT process.
54. The method of claim 53, wherein the first plurality of parameters includes at least one of the following: next-hop link count (NCC) and inactive radio network temporary identifier (I-RNTI).
55. The method of claim 53, wherein the first plurality of parameters includes a plurality of I-RNTIs, and wherein the first I-RNTI of the plurality of I-RNTIs includes the identifier of the first device and the identifier of the second device, and the remaining I-RNTIs of the plurality of I-RNTIs include only the identifier of the first device.
56. The method of claim 53, wherein the first plurality of parameters includes at least one of the following: a plurality of NCCs, a plurality of complete I-RNTIs, and a plurality of short I-RNTIs.
57. The method of claim 53, wherein the first plurality of parameters is received in one of the following: a Radio Resource Control (RRC) release message, an RRC reconfiguration message, an RRC recovery message, an RRC establishment message, an RRC security mode command message, or an RRC reconstruction message.
58. The method of claim 53, wherein the request received from the first device includes one of the following: a Radio Resource Control (RRC) recovery request, an RRC reconstruction request, or an RRC SDT request.
59. The method of claim 53, wherein the first plurality of parameters are ordered in a predetermined order, the predetermined order indicating that each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
60. The method of claim 53, further comprising: Send an indication to the first device indicating whether each of the first plurality of parameters is associated with the SDT process or the non-SDT process.
61. The method of claim 53, further comprising: Based on the resources for which the above-described request is received, determine whether the one or more parameters are associated with the SDT process or the non-SDT process.
62. The method of claim 53, wherein the request comprises one of: a first request for causing the SDT procedure to be executed, or a second request for causing the non-SDT procedure to be executed, and wherein executing a corresponding procedure comprises: In response to the first request, the SDT procedure with the first device is executed; as well as In response to the second request, the non-SDT procedure with the first device is performed.
63. The method of claim 62, wherein the request is the first request, and after performing the SDT procedure, the method further comprises: Receive additional requests from the first device when it is inactive; as well as Based on the determination that the additional request is a second request that includes at least one additional parameter from the first plurality of parameters, the non-SDT process with the first device is performed.
64. The method of claim 62, further comprising: Receive further requests from the first device; Based on the determination that the request is a second request including at least one parameter from the first plurality of parameters for the non-SDT process, the non-SDT process with the first device is executed; as well as The further data is received during the non-SDT process.
65. The method of claim 64, further comprising: A first indication received from the first device that none of the first plurality of parameters are available for the SDT process; as well as In response to the first instruction, at least a third plurality of parameters associated with the SDT process are sent to the first device, the third plurality of parameters not overlapping with the first plurality of parameters.
66. The method of claim 53, wherein determining that the SDT procedure will be performed, performing the SDT procedure comprises: Receive data related to the SDT from the first device.
67. The method of claim 66, further comprising: A second indication is received from the first device that none of the first plurality of parameters are available for the non-SDT process; as well as In response to the second instruction, a fourth plurality of parameters associated with the non-SDT process are sent to the first device, the fourth plurality of parameters not overlapping with the first plurality of parameters.
68. The method of claim 53, further comprising: Send an indication to the first device to indicate whether a second plurality of parameters associated with the SDT process or the non-SDT process are released or retained, the second plurality of parameters not overlapping with the first plurality of parameters, and the second plurality of parameters being sent earlier than the first plurality of parameters.
69. A first means for communication, comprising: A component for receiving a first plurality of parameters from a second device, the first plurality of parameters being associated with a connection restoration process between the first device and the second device; A component for sending a request for connection restoration to the second device while in an inactive state, based on the determination that a connection restoration process will be performed, the request including one or more of the first plurality of parameters; as well as Components for performing the connection restoration process with the second device. The connection restoration process includes a Small Data Transfer (SDT) process and a non-SDT process, and The first plurality of parameters includes: a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with the non-SDT process.
70. A second means for communication, comprising: A component for sending a first plurality of parameters to a first device, the first plurality of parameters being associated with a connection restoration process between the first device and the second device; A component for receiving a request for connection restoration from the first device, the request including one or more of the first plurality of parameters; as well as Components for performing the connection restoration process with the first device in response to the request. The connection restoration process includes a Small Data Transfer (SDT) process and a non-SDT process, and The first plurality of parameters includes: a first subset of the first plurality of parameters associated with the SDT process, and a second subset of the first plurality of parameters associated with the non-SDT process.
71. A non-transitory computer-readable medium comprising program instructions for causing a device to perform at least the method according to any one of claims 36 to 52.
72. A non-transitory computer-readable medium comprising program instructions for causing a device to perform at least the method according to any one of claims 53 to 68.