Network device and communication method

Abstract

A method according to an embodiment of the present disclosure includes a terminal device determining whether one or more DRBs having uplink data to be transmitted support SDT. If the one or more DRBs support SDT, the terminal device determines whether to transmit the uplink data in an inactive state. If determining to transmit the uplink data in an inactive state, the terminal device transmits the uplink data to a first network device in an inactive state. Upon receiving the uplink data, the first network device transmits to a third network device a request to relocate a context anchor of the terminal device, the request including a first indication as to whether there is remaining data to be transmitted.

Description

[Technical field]

[0001] TECHNICAL FIELD Embodiments of the present disclosure relate generally to the field of telecommunications, and more particularly to a communication method, a communication device, and a computer storage medium for data transmission during an inactive state of a terminal device. [Background technology]

[0002] Typically, a terminal device in an inactive state may still have a small amount of infrequent data traffic (hereinafter also referred to as small data transmission (SDT)) to transmit. Until 3rd Generation Partnership Project (3GPP) Release 16, the inactive state does not support data transmission, and the terminal device must resume the connection (i.e., enter the connected state) for both downlink and uplink data. For each data transmission, no matter how small the amount and frequency of data packets, a connection will be established and then released to the inactive state. This causes unnecessary power consumption and signaling overhead.

[0003] In contrast, 3GPP Release 17 has already approved SDT based on inactive Random Access Channel (RACH) and pre-configured Physical Uplink Shared Channel (PUSCH) resources, thus reducing signaling overhead. In this case, how to implement SDT has become a hot issue. Summary of the Invention [Problem to be solved by the invention]

[0004] Generally, embodiments of the present disclosure provide a communication method, a communication device, and a computer storage medium. [Means for solving the problem]

[0005] In a first aspect, a communication method is provided, the method including: in a terminal device in an inactive state, determining whether one or more Data Radio Bearers (DRBs) having uplink data to be transmitted support data transmission in the inactive state, determining whether to transmit the uplink data in the inactive state based on a payload size associated with the uplink data and a threshold associated with the one or more DRBs according to a determination that the one or more DRBs support data transmission in the inactive state, and transmitting the uplink data in the inactive state to a first network device according to a determination to transmit the uplink data in the inactive state.

[0006] In a second aspect, a communication method is provided, the method including: receiving, in a first network device, uplink data transmitted by a terminal device in an inactive state; and transmitting, to a third network device maintaining a context of the terminal device, a request to relocate an anchor of the context of the terminal device, the request including a first indication as to whether there is remaining data to transmit.

[0007] In a third aspect, a communication method is provided, comprising: receiving, at a second network device, a first request to resume a connection from a terminal device when a cell of the terminal device is reselected from a first cell of a first network device to a second cell of a second network device during a period of data transmission in an inactive state of the terminal device; and sending, at the second network device, a second request to relocate an anchor of a context of the terminal device to a fourth network device that maintains a context of the terminal device.

[0008] In a fourth aspect, a communication method is provided, comprising: receiving, from a first network device in a third network device that maintains a terminal device context, a request to relocate an anchor of the terminal device context in an inactive state, the request including a first indication on whether there is remaining data other than uplink data to be transmitted, determining whether to relocate the anchor based on the first indication, and transmitting at least a part of the context for transmitting the uplink data in the inactive state to the first network device according to the decision not to relocate the anchor.

[0009] In a fifth aspect, a communication method is provided, the method including: receiving, in a fourth network device that maintains a terminal device context, from a second network device, a second request to relocate an anchor of the terminal device context, transmitting, according to a decision to relocate the anchor, information to the second network device regarding a sequence number and a hyperframe number of a data packet associated with uplink data to be transmitted, and transmitting the data packet to the second network device.

[0010] In a sixth aspect, a terminal device is provided, the terminal device comprising: a processor; and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the terminal device to perform the method according to the first aspect of the present disclosure.

[0011] In a seventh aspect, a first network device is provided, the first network device comprising a processor and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the first network device to perform a method according to the second aspect of the present disclosure.

[0012] In an eighth aspect, a second network device is provided, the second network device comprising a processor and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the second network device to perform a method according to the third aspect of the present disclosure.

[0013] In a ninth aspect, a third network device is provided. The third network device includes a processor and a memory coupled to the processor. The memory stores instructions that, when executed by the processor, cause the transmitting device to perform the method according to the fourth aspect of the present disclosure.

[0014] In a tenth aspect, a fourth network device is provided, the fourth network device comprising: a processor; and a memory coupled to the processor, the memory storing instructions that, when executed by the processor, cause the fourth network device to perform a method according to the fifth aspect of the present disclosure.

[0015] In an eleventh aspect, a computer readable medium is provided having instructions stored thereon that, when executed on at least one processor, cause the at least one processor to perform a method according to the first aspect of the present disclosure.

[0016] In a twelfth aspect, there is provided a computer readable medium having instructions stored thereon that, when executed on at least one processor, cause the at least one processor to perform a method according to the second aspect of the present disclosure.

[0017] In a thirteenth aspect, there is provided a computer readable medium having stored thereon instructions that, when executed on at least one processor, cause the at least one processor to perform a method according to the third aspect of the present disclosure.

[0018] In a fourteenth aspect, there is provided a computer readable medium having stored thereon instructions that, when executed on at least one processor, cause the at least one processor to perform a method according to the fourth aspect of the present disclosure.

[0019] In a fifteenth aspect, there is provided a computer readable medium having stored thereon instructions that, when executed on at least one processor, cause the at least one processor to perform a method according to the fifth aspect of the present disclosure.

[0020] Other features of the present disclosure will become readily apparent from the following description. [Brief description of the drawings]

[0021] The above and other objects, features and advantages of the present disclosure will become more apparent from the following detailed description of several embodiments of the present disclosure in the drawings.

[0022] [Figure 1] FIG. 1 illustrates an example communication network in which some embodiments of the present disclosure may be implemented.

[0023] [Diagram 2] FIG. 2 is a schematic diagram illustrating a process for communication during an SDT according to an embodiment of the present disclosure.

[0024] [Diagram 3] FIG. 2 is a schematic diagram illustrating a process for communication during cell reselection in accordance with an embodiment of the present disclosure.

[0025] [Figure 4] FIG. 2 illustrates an example communication method implemented in a terminal device according to some embodiments of the present disclosure.

[0026] [Diagram 5]A diagram illustrating an exemplary communication method implemented in a first network device as a current serving network device in accordance with some embodiments of the present disclosure.

[0027] [Figure 6] A diagram illustrating an exemplary communication method implemented in a second network device as a new serving network device in accordance with some embodiments of the present disclosure.

[0028] [Figure 7] A diagram illustrating an exemplary communication method implemented in a third network device as the last serving network device in an SDT, in accordance with some embodiments of the present disclosure.

[0029] [Figure 8] A diagram illustrating an example communication method implemented in a fourth network device as a last serving network device during cell reselection, in accordance with some embodiments of the present disclosure.

[0030] [Figure 9] FIG. 1 is a schematic block diagram of an apparatus suitable for implementing embodiments of the present disclosure.

[0031] In the drawings, the same or similar reference numbers represent the same or similar elements. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] The principles of the present disclosure will now be described with reference to some embodiments. It should be understood that these embodiments are set forth for illustrative purposes only, to assist those skilled in the art in understanding and implementing the present disclosure, and do not imply any limitations on the scope of the present disclosure. The disclosure described herein can be implemented in various ways different from the methods described below.

[0033] 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.

[0034] As used herein, the term "terminal device" refers to any device having wireless or wired communication capabilities. Examples of terminal devices include, but are not limited to, user equipment (UE), personal computers, desktop computers, mobile phones, cellular phones, smartphones, personal digital assistants (PDAs), portable computers, tablets, wearable devices, Internet of Things (IoT) devices, any Internet of Things (IoE) devices, machine type communication (MTC) devices, in-vehicle devices for V2X communication, etc., where the "X" in V2X represents a pedestrian, vehicle, or infrastructure / network, or an image capture device such as a digital camera, a gaming device, a music storage and playback device, or an Internet appliance that allows wireless or wired Internet access and browsing, etc. The term "terminal device" can be used interchangeably with UE, mobile station, subscriber station, mobile terminal, user terminal, or wireless device. In addition, the term "network device" refers to a device that can provide or host a cell or coverage through which the terminal device can communicate. Examples of network devices include, but are not limited to, low power nodes such as a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), a next generation Node B (gNB), a transmit / receive point (TRP), a remote radio unit (RRU), a radio head (RH), a remote radio head (RRH), a femto node, and a pico node.

[0035] In one embodiment, the terminal device may be connected to a first network device and a second network device. One of the first network device and the second network device may be a master node and the other may be a secondary node. The first network device and the second network device may use different radio access technologies (RATs). In one embodiment, the first network device may be a first RAT device and the second network device may be a second RAT device. In one embodiment, the first RAT device is an eNB and the second RAT device is a gNB. Information about the different RATs may be transmitted to the terminal device from at least one of the first network device or the second network device. In one embodiment, the first information may be transmitted to the terminal device from the first network device, and the second information may be transmitted to the terminal device from the second network device directly or via the first network device. In one embodiment, information about the configuration of the terminal device configured by the second network device may be transmitted from the second network device via the first network device. Information regarding the reconfiguration of the terminal device configured by the second network device can be transmitted to the terminal device directly from the second network device or via the first network device.

[0036] As used herein, the singular forms "a," "an," and "said" include the plural unless the context clearly indicates otherwise. The term "comprises" and variations thereof should be understood as open-ended terms meaning "including, but not limited to." The term "based on" should be understood as "based at least in part on." The terms "one embodiment" and "embodiment" should be understood as "at least one embodiment." The term "another embodiment" should be understood as "at least one other embodiment." Terms such as "first," "second," and the like can refer to different or the same object. Other explicit and implicit definitions may be included below.

[0037] In some instances, values, procedures, or devices are referred to as "best," "lowest," "highest," "minimum," "maximum," etc. Such descriptions are intended to illustrate that selections can be made from among many functional alternatives used, and it should be understood that such selections are not necessarily better, smaller, higher, or otherwise more preferred than other selections.

[0038] Traditionally, there are various applications that exchange data in small amounts and infrequently. For example, in some applications for mobile devices, SDT can include traffic from instant messaging (IM) services, such as heartbeat or keep-alive traffic from IM or email clients and other services, push notifications in various applications, traffic from wearable devices (including, for example, periodic location information), etc. In some applications for non-mobile devices, SDT can include sensor data (e.g., temperature, pressure readings sent periodically or in an event-triggered manner in an IoT network), measurement and alarm information sent from smart meters, etc.

[0039] As mentioned above, 3GPP Release 17 already approves SDT based on inactive RACH and SDT based on pre-configured PUSCH resources. In this case, the realization of SDT needs to be considered in more detail. It also needs to be considered how to support lossless data transmission during cell reselection during SDT.

[0040] In view of this, the embodiments of the present disclosure provide a solution for communication during SDT, which not only realizes enhancement of SDT but also realizes lossless transmission of SDT during movement. The principles and embodiments of the present disclosure are described in detail below with reference to the accompanying drawings.

[0041] Communication Network Example FIG. 1 is a schematic diagram illustrating an exemplary communication network 100 in which embodiments of the present disclosure can be implemented. As shown in FIG. 1, the communication network 100 can include a first network device 110, a second network device 120, a third network device 130, a fourth network device 140, and a terminal device 150. The terminal device 150 can be served by any of the first network device 110, the second network device 120, the third network device 130, and the fourth network device 140. It should be understood that the number of devices in FIG. 1 is given for illustrative purposes and does not imply any limitations on the present disclosure. The communication network 100 can include any suitable number of network devices and / or terminal devices suitable for implementing embodiments of the present disclosure.

[0042] 1, a first network device 110 can communicate with a terminal device 150 over a channel, such as a wireless communication channel. Similarly, each of the second, third and fourth network devices 120, 130 and 140 can also communicate with the terminal device 150 over a channel, such as a wireless communication channel. The first, second, third and fourth network devices 110, 120, 130 and 140 can communicate with each other.

[0043] Communications in the communications network 100 may conform to any suitable standard, including, but not limited to, Global System for Mobile Communications (GSM), Long Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), GSM EDGE Radio Access Network (GERAN), Machine Type Communications (MTC), and the like. Furthermore, communications may be performed according to any generation of communications protocols now known or developed in the future. Examples of communications 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) communications protocols.

[0044] Each of the first, second, third and fourth network devices 110, 120, 130 and 140 may have at least one cell (not shown). In some scenarios, at an earlier stage, the terminal device 150 is served by the third network device 130 in a connected state, and the third network device 130 maintains a context for the terminal device 150. In some cases, the third network device 130 may instruct the terminal device 150 to enter an inactive state, after which the terminal device 150 may enter an inactive state. While the terminal device 150 is moving to the first network device 110, the terminal device 150 is switched to be served by the first network device 110. In this case, the third network device 130 may be the last serving network device that maintains a context for the terminal device 150. In some cases, the first network device 110 may be the last serving network device that maintains a context for the terminal device 150.

[0045] In some other scenarios, due to the movement of the terminal device 150, the terminal device 150 may perform cell reselection from one cell to another cell during the inactive state. For example, the terminal device 150 may perform cell reselection from a first cell of the first network device 110 to a second cell of the second network device 120 during the inactive state. For convenience, it is assumed that the fourth network device 140 is the last serving network device that maintains a context for the terminal device 150 during the cell reselection. In some embodiments, the fourth network device 140 may itself be the first network device 110. In some embodiments, the fourth network device 140 may itself be the third network device 130.

[0046] An embodiment of the present application provides an improved solution for communication in these scenarios, as described below with reference to Figures 2 and 3. Figure 2 is a schematic diagram illustrating a process 200 for communication during SDT according to an embodiment of the present disclosure. For illustrative purposes, the process 200 is described with reference to Figure 1. The process 200 may include a terminal device 150, a first network device 110, and a third network device 130 as shown in Figure 1. In this example, it is assumed that the terminal device 150 is currently served by the first network device 110 and is in an inactive state.

[0047] SDT determination and performance As shown in FIG. 2, when there is new uplink data from one or more DRBs, the terminal device 120 determines (201) whether the one or more DRBs support SDT. In some embodiments, the terminal device 120 may receive signaling from the first network device 110 indicating whether SDT is allowed by the first network device 110 for the DRBs, and determine whether the one or more DRBs support SDT based on the received signaling. In some embodiments, the signaling may be an RRCReconfiguration message. Alternatively, in some embodiments, the signaling may be an RRCRelease message. Of course, any other suitable signaling is also possible.

[0048] If all DRBs support SDT, the terminal device 120 determines (202) whether to transmit the uplink data in an inactive state based on a payload size associated with the uplink data and a threshold associated with the one or more DRBs. In some embodiments, the threshold can be configured by the first network device 110. For example, the threshold can be broadcast in a system message from the first network device 110. As another example, the threshold can be configured to the terminal device 150 using only RRC messages, such as an RRCReconfiguration message or an RRCRelease message.

[0049] In some embodiments, the threshold may be set per terminal device. For example, a first threshold size is set for terminal device 150. In some embodiments, terminal device 150 may determine a total payload size of the uplink data. If terminal device 150 determines that the total payload size is smaller than the first threshold size, terminal device 150 may determine to transmit the uplink data in an inactive state.

[0050] In some embodiments, this threshold may be set for each DRB. For example, a second threshold size is set for the DRB. In some embodiments, only one DRB may be allowed for the SDT. Of course, two or more DRBs may be allowed for the SDT. In some embodiments, the second threshold size is set commonly for each of the DRBs. In these embodiments, the terminal device 150 may determine a payload size of data in the uplink data corresponding to each of the DRBs. If the payload size is smaller than the second threshold size, the terminal device 150 may determine to transmit this uplink data in the inactive state. In some alternative embodiments, the second threshold size is set independently for each of the DRBs. In these embodiments, the terminal device 150 may determine a payload size of data in the uplink data corresponding to each of the DRBs. If the payload size is smaller than the corresponding second threshold size, the terminal device 150 may determine to transmit this uplink data in the inactive state.

[0051] If the terminal device 150 is in an inactive state and determines to transmit the uplink data, the terminal device 150 transmits (203) the uplink data to the first network device 110. In some embodiments, the terminal device 150 may perform a RACH procedure, such as a four-step or two-step RACH procedure, to transmit the uplink data. For example, if the terminal device 150 determines to perform an SDT based on RACH, the terminal device 150 may resume a DRB having at least the uplink data and initiate a four-step or two-step RACH procedure with the uplink data multiplexed in an RRC Resume Request message in message 3 (msg 3) of the four-step RACH procedure or message A (msg A) of the two-step RACH procedure.

[0052] In some embodiments, the terminal device 150 can receive a configuration for a bandwidth portion (BWP) for SDT from the first network device 110, and perform a RACH procedure based on the BWP configuration for uplink data transmission. Thus, the traffic load on the initial BWP can be significantly reduced. In some embodiments, one or more BWPs can be dedicated to the SDT in addition to the initial BWP.

[0053] In some embodiments, the BWP configuration may be broadcast in a system message from the first network device 110. Alternatively, the BWP configuration may be configured in the terminal device 150 via dedicated signaling. For example, the dedicated signaling may be an RRCRelease message. Of course, any other suitable signaling is also possible.

[0054] In some embodiments, the terminal device 150 may also transmit uplink data via pre-configured uplink resources for SDT (also referred to as CG-based SDT). It should be noted that any other suitable method may be used for transmitting uplink data, and no limitation is placed on this in this specification.

[0055] In some embodiments, terminal 150 may also transmit an indication as to whether remaining data other than uplink data is to be transmitted. In some embodiments, terminal 150 may transmit a buffer status report (BSR) to indicate whether remaining data exists, thereby helping the network device decide whether to perform anchoring for terminal 150's context. For example, terminal 150 may transmit the indication in msg 3 of a four-step RACH procedure or msg A of a two-step RACH procedure.

[0056] Anchoring Location Processing for SDT Upon receiving the uplink data transmitted by the terminal device 150, the first network device 110 may send (204) a request to relocate the anchor of the context of the terminal device 150 to the third network device 130. The third network device 130 is the last serving network device that maintains the context. For example, the first network device 110 may determine whether it is a new network device other than the last serving network device. If it determines that it is a new network device, the first network device 110 may send a request to the third network device 130 that serves as the last serving network device.

[0057] For example, the first network device 110 may send a RETRIEVE UE CONTEXT REQUEST message to the third network device 130. In some embodiments, the request includes a first indication as to whether there is remaining data to be transmitted. In other words, the first indication indicates whether there is a one-shot SDT. In this way, it is possible to explicitly indicate to the last serving network device whether there is remaining data to be transmitted. For example, the first indication may be one bit. A first value of the bit may indicate that there is remaining data, and a second value of the bit may indicate that there is no remaining data. Of course, any other suitable manner is also possible.

[0058] In some alternative embodiments, the indication may include user plane transport network layer (UP TNL) information for downlink transmission, which indicates that there is no remaining data. In some alternative embodiments, the indication may include a BSR from terminal device 150 to implicitly indicate whether there is remaining data to transmit.

[0059] When a request to relocate the anchor is received, the third network device 130 determines (205) whether the anchor is to be relocated based on the first indication in the request.

[0060] In some embodiments, if the first indication indicates that there is no remaining data, i.e., it is a one-shot SDT, the third network device 130 may decide whether to relocate the context. In some embodiments, if the first indication indicates that there is remaining data, i.e., it is not a one-shot SDT, the third network device 130 may relocate the anchor to the first network device 110. The reason is that in the case of a non-one-shot SDT, msg4 of the four-step RACH process or msg B of the two-step RACH process should be generated by the new network device using SRB1, so a context is required.

[0061] If anchor location is performed, the third network device 130 may send a response to the request, including the context, to the first network device 110. For example, the third network device 130 may send a RETRIEVE UE CONTEXT RESPONSE message to the first network device 110.

[0062] If anchorage is not performed, the third network device 130 may transmit (206) at least a portion of the context for uplink data transmission in the inactive state to the first network device 110. The first network device 110 may then transmit (207) a data packet associated with the uplink data to the third network device 130 based on the portion of the context, and release (208) the context of the terminal device 150.

[0063] In some embodiments, the third network device 130 may send a message to the first network device 110 including a connection release message to be sent to the terminal device 150, UP TNL information for uplink transmission, and a part of the context including at least the radio link control (RLC) configuration of the terminal device 150. For example, the third network device 130 may feed back a RETRIEVE UE CONTEXT FAILURE message including the encapsulated RRCRelease message, UP TNL information for the uplink data, and a part of the context including at least the RLC configuration of the terminal device 150. Then, the first network device 110 may establish an RLC entity according to the RLC configuration. After the RLC processing, the first network device 110 may send one or more UL PDCP PDUs to the third network device 130. The third network device 130 may perform Service Data Adaptation Protocol (SDAP) and PDCP processing of the uplink data before sending the uplink data to the core network. If there is other downlink (DL) data, the third network device 130 can perform SDAP and PDCP processing of the other downlink data and then send one or more DL PDCP PDUs to the first network device 110. Then, the first network device sends the DL data together with a RRCRelease message to the terminal device 150. The first network device 110 also releases the part of the context.

[0064] In some embodiments, the third network device 130 may send a response to the request to the first network device 110, including the context and a second indication indicating not to relocate the anchor. For example, the third network device 130 may feed back a RETRIEVE UE CONTEXT RESPONSE message with the context and the second indication. As another example, the third network device 130 may feed back a RETRIEVE UE CONTEXT RESPONSE message with the context and the uplink TNL information for the uplink transmission. If the response indicates not to relocate the anchor, the first network device 110 may establish an RLC entity according to the context and send one or more UL PDCP PDUs to the third network device 130 after RLC processing. If DL data is received by the third network device 130, the third network device 130 may send a DL PDCP PDU to the first network device 110 after SDAP and PDCP processing. The first network device 110 sends the DL data to the terminal device 150 after RLC and MAC processing.

[0065] In some embodiments, the first network device 110 may establish RLC, PDCP, and SDAP entities for one or more DRBs, and send the UL data after RLC, PDCP, and SDAP processing to the third network device 130. When the DL data is received by the third network device 130, the third network device 130 may send the DL data to the first network device 110.

[0066] The first network device 110 may generate an RRC message, such as an RRCRelease message, and transmit (209) the RRC message to the terminal device 150 with or without downlink data associated with the uplink data. In some embodiments, the downlink data may be transmitted to the terminal device 150 along with the RRC message in msg 4 of a four-step RACH process or msg B of a two-step RACH process. The first network device 110 should release the context after the SDT procedure.

[0067] Handling new uplink transmissions during SDT During SDT, if there is a new uplink transmission (also referred to as another uplink transmission in this specification), the terminal device 150 can process the other uplink transmission based on whether it is new uplink data or signaling and whether the DRB (also referred to as another DRB) having the new uplink data supports SDT.

[0068] In some embodiments, the terminal device 150 can determine (210) whether the other uplink transmission includes uplink signaling. If it determines that the other uplink transmission includes uplink signaling, the terminal device 150 can suspend (212) a DRB associated with the terminal device 150 and perform (213) the other uplink transmission in a connected state based on a RACH procedure. For example, the terminal device 150 can reset a medium access control (MAC) entity, suspend all DRBs that are not suspended, and initiate an RRC Resume process for normal data transfer. When an RRCResume message is received from the first network device 110, the terminal device 150 can perform RLC re-establishment and PDCP re-establishment as indicated in the RRCResume message. In some embodiments, the terminal device 150 can send a PDCP status report to the first network device 110 for the DRBs that are in acknowledged mode (AM) of the RLC layer. In some embodiments, the terminal device 150 may also perform transmission of data that is not successfully transmitted among the uplink data in the connected state based on the RACH procedure. In some embodiments, the terminal device 150 may cancel transmission of data that is not successfully transmitted among the uplink data.

[0069] If it is determined that the other uplink transmission does not include uplink signaling, i.e., the other uplink transmission includes other uplink data, the terminal device 150 may determine (211) whether the other DRB having the other uplink data is different from each of the current DRBs and supports SDT, and if it is determined that the other DRB does not support SDT, the terminal device 150 may suspend (212) the DRB associated with the terminal device 150 and perform (213) the other uplink transmission in a connected state based on the RACH procedure. For example, the terminal device 150 may reset a MAC entity, suspend all DRBs that are not suspended, and initiate an RRC Resume process for normal data transfer. When an RRCResume message is received from the first network device 110, the terminal device 150 may perform RLC re-establishment and PDCP re-establishment as indicated in the RRCResume message. In some embodiments, the terminal device 150 may transmit a PDCP status report for the DRB in the AM of the RLC layer to the first network device 110. In some embodiments, the terminal device 150 may also perform transmission of data that is not successfully transmitted among the uplink data in the connected state and based on the RACH procedure. In some embodiments, the terminal device 150 may cancel transmission of data that is not successfully transmitted among the uplink data.

[0070] In some embodiments, if the terminal device 150 determines that the other DRB is different from each of the current DRBs and supports SDT, the terminal device 150 may determine (214) whether to perform the other uplink transmission in an inactive state. In some embodiments, the terminal device 150 may determine whether the other uplink transmission and the transmission of data that has not been successfully transmitted among the uplink data (also referred to as an incomplete data transmission in this specification) satisfy the conditions of the SDT. Similar to the determination of the SDT for the uplink data, the terminal device 150 may determine a total payload size of the other uplink transmission and the incomplete data transmission, and if the terminal device 150 determines that the total payload size is smaller than a threshold, the terminal device 150 may determine to perform the other uplink transmission in an inactive state. Other details are omitted here for brevity.

[0071] When determining to perform the other uplink transmission in the inactive state, the terminal device 150 may perform (215) the other uplink transmission in the inactive state. In some embodiments, the terminal device 150 may resume the other DRB, reset the MAC entity, release the MAC cell group configuration, perform RLC re-establishment for the non-suspended DRB, and start an SDT process to perform the other uplink transmission. In some embodiments, the terminal device 150 may also perform transmission of data that is not successfully transmitted among the uplink data in the inactive state. In some embodiments, the terminal device 150 may cancel transmission of data that is not successfully transmitted among the uplink data.

[0072] When determining not to perform the other uplink transmission in the inactive state, the terminal device 150 may suspend the DRB associated with the terminal device 150 and perform the other uplink transmission in the connected state based on the RACH procedure. In some embodiments, the terminal device 150 may perform the other uplink transmission when entering the idle state. Alternatively, the terminal device 150 may initiate an RRC establishment process for the other uplink transmission by resetting the MAC entity, releasing the MAC cell group configuration for the MAC entity, releasing all RLC and PDCP entities, and sending an RRC setup Request message to the first network device 110. Of course, the terminal device 150 may also initiate an RRC Resume process for normal data transmission for the other uplink transmission after the current SDT transmission.

[0073] In some alternative embodiments, during the SDT, whether the SDT is RACH-based, CG-based, or a subsequent SDT, if there is new uplink data from a DRB that does not support SDT (i.e., not configured), or if new uplink signaling arrives, or if there is new uplink data from another DRB other than the current DRB, the terminal device 150 may perform the other uplink transmission upon entering the idle state. Alternatively, the terminal device 150 may initiate an RRC establishment process for the other uplink transmission by resetting the MAC entity, releasing the MAC cell group configuration for the MAC entity, releasing all RLC and PDCP entities, and transmitting an RRC setup Request message to the first network device 110. Of course, the terminal device 150 may also initiate an RRC Resume process for normal data transmission for the other uplink transmission after the current SDT transmission.

[0074] In this way, lossless transmission can be supported in case of a new uplink transmission from the other DRB.

[0075] Cell reselection processing during SDT When the terminal device 150 is performing SDT, whether it is RACH-based SDT, CG-based SDT, or subsequent SDT, when cell reselection occurs from a current cell (also referred to herein as a first cell) to a new cell (also referred to herein as a second cell), the terminal device can check whether the second cell supports SDT, i.e., whether SDT is allowed in the second cell. This will be described in detail with reference to FIG. 3. FIG. 3 is a schematic diagram illustrating a process 300 for communication upon cell reselection according to an embodiment of the present disclosure. For illustrative purposes, the process 300 will be described with reference to FIG. 1. The process 300 may involve the terminal device 150, the second network device 120, and the fourth network device 140 as shown in FIG. 1. In this example, assume that the serving cell of terminal device 150 in an inactive state is reselected from a first cell of first network device 110 to a second cell of second network device 120, and the fourth network device 140 is the last serving network device that maintains the context of terminal device 150.

[0076] New cells that support SDT As shown in FIG. 3, the terminal device 150 may determine (301) whether the SDT can be performed in the second cell. In some embodiments, the terminal device 150 may determine whether the second cell supports SDT and whether the conditions for SDT are met. If the terminal device 150 determines that the second cell supports SDT and the conditions for SDT are met, the terminal device 150 may determine that the SDT can be performed in the second cell. For example, the terminal device 150 may determine whether the second cell supports SDT based on a system message from the second network device 120. As another example, the terminal device 150 may determine whether the conditions for SDT are met based on a payload size of data that is not normally transmitted among the uplink data. This is merely an example, and the present application does not provide any limitation thereon.

[0077] If it is determined that SDT can be performed in the second cell, the terminal device 150 may maintain (302) an inactive state. In some embodiments, while the inactive state is maintained, the terminal device 150 may reset a MAC entity of the MAC layer of the terminal device 150. In some embodiments, the terminal device 150 may release a MAC cell group configuration for the MAC entity. In some embodiments, the terminal device 150 may perform re-establishment of an RLC entity of the RLC layer of the terminal device 150 for a non-suspended DRB associated with the terminal device 150. In some embodiments, the terminal device 150 may perform re-establishment of a PDCP entity of the PDCP layer of the terminal device 150 for a non-suspended DRB associated with the terminal device 150.

[0078] Then, the terminal device 150 may transmit (303) uplink data to the second cell in an inactive state. In some embodiments, the terminal device 150 may initiate an SDT process in the second cell, such as the SDT procedure in the first cell (i.e., the first network device 110) described above. For example, the terminal device 150 may transmit a request (also referred to herein as a first request) to resume a connection to the second network device 120. As an example, the terminal device 150 may transmit an RRC Resume Request message. In some embodiments, the terminal device 150 may transmit a PDCP status report for RLC AM DRB to the second cell 110.

[0079] Upon receiving the first request from the terminal device 150, the second network device 120 may determine whether it is the new network device serving the terminal device 150. If it determines that it is the new network device, the second network device 120 may send (306) a second request to the fourth network device 140 to relocate the anchor of the context of the terminal device 150. In some embodiments, the second request may include UP TNL information for uplink and downlink transmissions (i.e., UP TLN information for data forwarding). For example, the second network device 120 may send a RETREVE UE CONTEXT REQUEST message including UP TNL information for data forwarding. Of course, any other suitable message is also possible.

[0080] Upon receiving the second request to relocate the anchor, the fourth network device 140 can decide (307) whether to relocate the anchor. If the fourth network device 140 decides to relocate the anchor, i.e., to perform anchor location, the fourth network device 140 can send (308) information on the SN and HFN of the data packet associated with the uplink data to the second network device 120. In other words, the fourth network device 140 can send uplink and downlink PDCP SN and HFN status information, i.e., SN and HFN information on the uplink data packet from the terminal device 150 that has not yet been transmitted to the core network and the downlink data packet from the core network that has not yet been successfully transmitted to the terminal device 150.

[0081] In some embodiments, the fourth network device 140 can send this SN and HFN information to the second network device 120 in a response to the second request, including the context. For example, the fourth network device 140 can send the SN and HFN information in a RETRIEVE UE CONTEXT RESPONSE. In some alternative embodiments, the fourth network device 140 can send the SN and HFN information in a message dedicated to sending this information. For example, the fourth network device 140 can send a RETRIEVE UE CONTEXT RESPONSE message including the context and also send the SN and HFN information in a SN STATUS TRANSFER message. Of course, any other suitable message is possible and the application is not limited to the above examples.

[0082] In some embodiments where the second request to relocate the anchor does not include UP TNL information for data forwarding, the fourth network device 140 may send a request to the second network device 120 to obtain UP TNL information for data forwarding (also referred to herein as a third request). In some embodiments, the third request may include a PDU session identity (ID) associated with the UP TNL information for data forwarding. In some alternative or additional embodiments, the third request may include a DRB ID list associated with the UP TLN information for data forwarding.

[0083] In some embodiments, the third request may be included in a response to the second request. For example, the third request may be included in a RETRIEVE UE CONTEXT RESPONSE message. Of course, the third request may be sent in any other suitable message.

[0084] Upon receiving the third request, the second network device 120 may send UP TNL information for data forwarding to the fourth network device 140. In some embodiments where the third request includes a PDU session ID, the second network device 120 may send UP TNL information for the PDU session ID to the fourth network device 140. In some embodiments where the third request includes a DRB ID list, the second network device 120 may send UP TNL information for the DRB ID list to the fourth network device 140. In some embodiments, the second network device 120 may send UP TNL information for data forwarding to the fourth network device 140 via an XN-U ADDRESS INDICATION message. Of course, any other suitable message is possible.

[0085] The fourth network device 140 may then perform (309) a data forwarding procedure to forward the data packets from the fourth network device 140 to the second network device 120. The data packets may include uplink data packets from the terminal device 150 that have not yet been transmitted to the core network and downlink data packets from the core network that have not yet been successfully transmitted to the terminal device 150.

[0086] If the fourth network device 140 determines not to relocate the anchor, i.e., if the fourth network device 140 determines not to perform anchor location, the fourth network device 140 may transmit at least a portion of the context to the second network device 120. Thus, the second network device 120 may transmit a data packet associated with the uplink data to the fourth network device 140 based on the portion of the context, and release the context of the terminal device 150.

[0087] In some embodiments, the fourth network device 140 may send a message to the second network device 120 including a connection release message to be sent to the terminal device 150, UP TNL information for uplink transmission, and a part of the context including at least the RLC configuration of the terminal device 150. For example, the fourth network device 140 may feed back a RETRIEVE UE CONTEXT FAILURE message including the encapsulated RRCRelease message, the UP TNL information, and a part of the context including at least the RLC configuration of the terminal device 150. Thus, the second network device 120 may forward the RRCRelease message to the terminal device 150. Then, the second network device 120 may establish an RLC entity according to the RLC configuration. After RLC processing, the second network device 120 may send one or more UL PDCP PDUs to the fourth network device 140. Then, the second network device 120 may release the context. The fourth network device 140 can perform SDAP and PDCP processing of the uplink data and then send the uplink data to the core network. If there is another DL data, the fourth network device 140 can perform SDAP and PDCP processing of the another downlink data and then send one or more DL PDCP PDUs to the second network device 120.

[0088] In some embodiments, the fourth network device 140 may send a response to the request to the second network device 120, including the context and a second indication indicating not to relocate the anchor. For example, the third network device 130 may feed back a RETRIEVE UE CONTEXT RESPONSE message with the context and the second indication. As another example, the fourth network device 140 may feed back a RETRIEVE UE CONTEXT RESPONSE message with the context and uplink TNL information for uplink transmission. If the response indicates not to relocate the anchor, the second network device 120 may establish an RLC entity according to the context and send one or more UL PDCP PDUs to the fourth network device 140 after RLC processing.

[0089] Second network device 120 may generate an RRC message, such as an RRCRelease message, and transmit the RRC message to terminal device 150 with or without downlink data associated with the uplink data. In some embodiments, the downlink data may be transmitted to terminal device 150 along with the RRC message in msg 4 of a four-step RACH procedure or msg B of a two-step RACH procedure.

[0090] New cells that do not support SDT If it is determined that the second cell does not support SDT, the terminal device 150 may suspend (310) the DRBs associated with the terminal device 150 while remaining in the inactive state. The terminal device 150 may then perform (311) a RACH procedure for transmission of uplink data in the connected state. For example, the terminal device 150 may remain in the inactive state, reset the MAC entity, suspend all non-suspended DRBs, and initiate an RRC Resume procedure for normal data transfer. When an RRCResume message is received from the second network device 120, the terminal device 150 may perform RLC re-establishment and PDCP re-establishment for the DRBs as indicated in the RRCResume message.

[0091] Upon receiving the first request from the terminal device 150, the second network device 120 may determine whether it is the new network device serving the terminal device 150. If it determines that it is the new network device, the second network device 120 may send (312) a second request to the fourth network device 140 to relocate the anchor of the context of the terminal device 150. In some embodiments, the second request may include UP TNL information for uplink and downlink transmissions (i.e., UP TLN information for data forwarding). For example, the second network device 120 may send a RETREVE UE CONTEXT REQUEST message including UP TNL information for data forwarding. Of course, any other suitable message is also possible.

[0092] Upon receiving the second request to relocate the anchor, the fourth network device 140 may transmit (313) information regarding the SN and HFN of the data packets associated with the uplink data to the second network device 120. In other words, the fourth network device 140 may transmit uplink and downlink PDCP SN and HFN status information, i.e., SN and HFN information regarding uplink data packets from the terminal device 150 that have not yet been transmitted to the core network and downlink data packets from the core network that have not yet been transmitted to the terminal device 150.

[0093] In some embodiments, the fourth network device 140 can send this SN and HFN information to the second network device 120 in a response to the second request, including the context. For example, the fourth network device 140 can send the SN and HFN information in a RETRIEVE UE CONTEXT RESPONSE. In some alternative embodiments, the fourth network device 140 can send the SN and HFN information in a message dedicated to sending this information. For example, the fourth network device 140 can send a RETRIEVE UE CONTEXT RESPONSE message including the context and also send the SN and HFN information in a SN STATUS TRANSFER message. Of course, any other suitable message is possible and the application is not limited to the above examples.

[0094] In some embodiments where the second request to relocate the anchor does not include UP TNL information for data forwarding, the fourth network device 140 may send a request to the second network device 120 to obtain UP TNL information for data forwarding (also referred to herein as a third request). In some embodiments, the third request may include a PDU session identity (ID) associated with the UP TLN information for data forwarding. In some alternative or additional embodiments, the third request may include a DRB ID list associated with the UP TLN information for data forwarding.

[0095] In some embodiments, the third request may be included in a response to the second request. For example, the third request may be included in a RETRIEVE UE CONTEXT RESPONSE message. Of course, the third request may be sent in any other suitable message.

[0096] Upon receiving the third request, the second network device 120 may send UP TNL information for data forwarding to the fourth network device 140. In some embodiments where the third request includes a PDU session ID, the second network device 120 may send UP TNL information for the PDU session ID to the fourth network device 140. In some embodiments where the third request includes a DRB ID list, the second network device 120 may send UP TNL information for the DRB ID list to the fourth network device 140. In some embodiments, the second network device 120 may send UP TNL information for data forwarding to the fourth network device 140 via an XN-U ADDRESS INDICATION message. Of course, any other suitable message is possible.

[0097] The fourth network device 140 may then perform (314) a data forwarding procedure to forward the data packets from the fourth network device 140 to the second network device 120. The data packets may include uplink data packets from the terminal device 150 that have not yet been transmitted to the core network and downlink data packets from the core network that have not yet been transmitted to the terminal device 150.

[0098] The process shown in Figure 3 can support lossless transmission during cell reselection during SDT.

[0099] It should be noted that the operations shown in Figures 2 and 3 are not necessarily required to realize the embodiments of the present disclosure, and more or less operations can be adjusted as necessary. Corresponding to the processes illustrated in Figures 2 and 3, the embodiments of the present disclosure provide communication methods implemented in terminal devices and network devices. These methods are described below with reference to Figures 4 to 8.

[0100] Examples of communication methods 4 illustrates an example communication method 400 implemented in a terminal device, according to some embodiments of the present disclosure. For example, method 400 may be performed in terminal device 150 as shown in FIG. For purposes of explanation, method 400 will be described below with reference to FIG. 1. It should be understood that method 400 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the disclosure is not limited in this respect.

[0101] In block 410, the terminal device 150 determines whether one or more DRBs having uplink data to transmit support data transmission in the inactive state of the terminal device 150. That is, the terminal device 150 determines whether the one or more DRBs support SDT.

[0102] If the one or more DRBs support data transmission in the inactive state, terminal device 150 determines whether to transmit uplink data in the inactive state based on a payload size associated with the uplink data and a threshold associated with the one or more DRBs in block 420. In some embodiments, terminal device 150 may determine a total payload size of the uplink data, and if it determines that the total payload size is less than a first threshold size, terminal device 150 may determine to transmit the uplink data in the inactive state.

[0103] In some alternative embodiments, the terminal device 150 may determine a payload size of data in the uplink data corresponding to each of the one or more DRBs, and if the payload size is smaller than a second threshold size, the terminal device 150 may determine to transmit the uplink data in an inactive state. In some additional or alternative embodiments, the second threshold size is set in association with each of the DRBs.

[0104] If it is determined to transmit the uplink data in the inactive state, in block 430, the terminal device 150 transmits the uplink data in the inactive state to the first network device 110. In some embodiments, the terminal device 150 may receive a configuration for the BWP for data transmission in the inactive state from the first network device 110 and perform a RACH procedure for transmission of the uplink data based on the configuration. In some embodiments, the terminal device 150 may also transmit an indication to the first network device 110 regarding whether to transmit remaining data other than the uplink data.

[0105] In some embodiments, upon cell reselection from the first cell of the first network device 110 to the second cell of the second network device 120, the terminal device 150 may determine whether data transmission in the inactive state can be performed in the second cell. In some embodiments, if it is determined that data transmission in the inactive state can be performed in the second cell, the terminal device 150 may maintain the inactive state and transmit uplink data to the second cell in the inactive state.

[0106] In some additional or alternative embodiments, while remaining in the inactive state, terminal device 150 performs at least one of resetting a MAC entity of the MAC layer of terminal device 150, releasing a MAC cell group configuration for the MAC entity, re-establishing an RLC entity of the RLC layer of terminal device 150 for non-suspended DRBs associated with terminal device 150, and re-establishing a PDCP entity of the PDCP layer of terminal device 150 for non-suspended DRBs associated with terminal device 150. In some embodiments, terminal device 150 may further transmit a PDCP status report for the DRBs in the AM of the RLC layer to second cell 110.

[0107] In some embodiments, if it is determined that data transmission in the inactive state cannot be performed in the second cell, the terminal device 150 may suspend the DRB associated with the terminal device 150 while remaining in the inactive state, and perform a RACH procedure for transmission of uplink data in the connected state.

[0108] In some embodiments, terminal device 150 may determine whether the other uplink transmission includes uplink signaling. In some embodiments, if terminal device 150 determines that the other uplink transmission includes uplink signaling, terminal device 150 may suspend a DRB associated with terminal device 150 and perform the other uplink transmission in a connected state based on a RACH procedure.

[0109] In some embodiments, if it is determined that the other uplink transmission does not include uplink signaling, terminal device 150 may determine whether the other DRB having the other uplink transmission is different from each of the one or more DRBs and supports data transmission in an inactive state. In some embodiments, if it is determined that the other DRB does not support data transmission in an inactive state, terminal device 150 may suspend the DRB associated with terminal device 150 and perform the other uplink transmission in a connected state based on a RACH procedure. In some embodiments, terminal device 150 may perform transmission of data of uplink data that has not been normally transmitted in a connected state based on a RACH procedure.

[0110] In some embodiments, if it is determined that the other DRB is different from each of the one or more DRBs and supports data transmission in an inactive state, the terminal device 150 may determine whether to perform the other uplink transmission in the inactive state. In some embodiments, if it is determined to perform the other uplink transmission in the inactive state, the terminal device 150 may perform the other uplink transmission to the first network device in the inactive state. In some embodiments, the terminal device 120 may perform transmission of data that has not been normally transmitted among the uplink data in the inactive state.

[0111] 5 illustrates an example communication method 500 implemented in a first network device (i.e., a current serving network device) according to some embodiments of the present disclosure. For example, method 500 may be performed in the first network device 110 as shown in FIG. 1. For purposes of explanation, method 500 will be described below with reference to FIG. 1. It should be understood that method 500 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the disclosure is not limited in this respect.

[0112] 5, in block 510, the first network device 110 may receive uplink data transmitted by the terminal device 150 in an inactive state. In block 520, the first network device 110 may transmit to a third network device 130 that maintains a context for the terminal device 150 a request to relocate an anchor of the terminal device's context, the request including a first indication as to whether there is remaining data to transmit.

[0113] In some embodiments, the indication includes at least one of UP TNL information for downlink transmission and a BSR from terminal 150.

[0114] In some embodiments, the first network device 110 may further receive a response to the request from the third network device 130, the response including the context and a second indication indicating not to relocate the anchor. In some embodiments, the first network device 110 may transmit a data packet associated with the uplink data to the third network device 130 based on the context and release the context of the terminal device 150. In some embodiments, the second indication includes UP TNL information for the uplink transmission.

[0115] In some embodiments, the first network device 110 may receive a message from the third network device 130 including a connection release message to be sent to the terminal device, UP TNL information for the uplink transmission, and a portion of the context including at least an RLC configuration of the terminal device 150. In some embodiments, the first network device 110 may transmit uplink data to the third network device and transmit a connection release message to the terminal device 150 based on the UP TNL information and the RLC configuration.

[0116] 6 illustrates an example communication method 600 implemented in a second network device (i.e., a new serving network device) according to some embodiments of the present disclosure. For example, the method 600 may be performed in the second network device 120 as shown in FIG. 1. For purposes of explanation, the method 600 will be described below with reference to FIG. 1. It should be understood that the method 600 may include additional blocks not shown and / or may omit some blocks that are shown, and that the scope of the disclosure is not limited in this respect.

[0117] As shown in FIG. 6, in block 610, when the cell of the terminal device 150 is reselected from the first cell of the first network device 110 to the second cell of the second network device 120 during a period of data transmission in an inactive state of the terminal device 150, the second network device 120 receives a first request to resume the connection from the terminal device 150.

[0118] In some embodiments, data transmission in the inactive state may be performed in the second cell, and the second network device 120 may receive unsuccessfully transmitted uplink data in the data transmission from the terminal device 150. In some embodiments, the second network device 120 may also receive a PDCP status report for a DRB in the AM of the RLC layer from the terminal device 150.

[0119] In block 620, the second network device 120 sends a second request to relocate the anchor of the terminal device's context to the fourth network device 140 that maintains the context of the terminal device 150. In some embodiments, the second request may include user plane transport network layer (UP TNL) information for the data transmission. In these embodiments, the second network device 120 may receive a response to the request from the fourth network device 140 that includes the context and information regarding a sequence number and a hyperframe number of a data packet associated with the data transmission. In some embodiments, the second network device 120 may also receive a data packet from the fourth network device based on the context and the information.

[0120] In some alternative embodiments, the second network device 120 can receive a response to the request from the fourth network device 140 that includes the context. In some embodiments, the second network device 120 can also receive a message from the fourth network device 140 that includes information regarding a sequence number and a hyperframe number of a data packet associated with a data transmission, the message being dedicated to the transmission of the information. In some embodiments, the second network device 120 can also receive a data packet from the fourth network device 140 based on the context and the information.

[0121] In some embodiments, the second request does not include UP TNL information for the data transmission. In these embodiments, the second network device 120 may receive a third request from the fourth network device 140 to obtain UP TNL information for the data transmission, and then transmit the UP TNL information for the data transmission to the fourth network device 140. In some embodiments, the third request may include at least one of a PDU session ID and an ID list of one or more DRBs.

[0122] 7 illustrates an example communication method 700 implemented in a third network device (i.e., the last serving network device in the SDT) according to some embodiments of the present disclosure. For example, method 700 may be performed in third network device 130 as shown in FIG. 1. For purposes of explanation, method 700 will be described below with reference to FIG. 1. It should be understood that method 700 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the disclosure is not limited in this respect.

[0123] 7, in block 710, a third network device 130 that maintains a context for terminal device 150 receives a request to relocate an anchor of the context for terminal device 150 in an inactive state, the request including a first indication as to whether there is remaining data other than uplink data to transmit. In some embodiments, the first indication includes at least one of UP TNL information for downlink transmission and a BSR from the terminal device.

[0124] In block 720, the third network device 130 determines whether to relocate the anchor based on the first instruction. In some embodiments, if it is determined not to relocate the anchor, in block 730, the third network device 130 transmits at least a portion of the context for transmitting uplink data in the inactive state to the first network device 110.

[0125] In some embodiments, the third network device 130 may send a message to the first network device 110 including a connection release message to be sent to the terminal device, UP TNL information for the uplink transmission, and a portion of the context including at least the RLC configuration of the terminal device 150. In some alternative embodiments, the third network device 130 may send a response to the request to the first network device 110 including the context and a second indication to the first network device 110 indicating not to relocate the anchor.

[0126] 8 illustrates an example communication method 800 implemented in a fourth network device (i.e., a last serving network device upon cell reselection) in accordance with some embodiments of the present disclosure. For example, method 800 may be implemented in fourth network device 140 as shown in FIG. 1. For purposes of explanation, method 800 will be described below with reference to FIG. 1. It should be understood that method 800 may include additional blocks not shown and / or omit some blocks that are shown, and that the scope of the disclosure is not limited in this respect.

[0127] 8, in block 810, the fourth network device 140 receives a request from the second network device 120 to relocate the anchor of the context of the terminal device 150. The fourth network device 140 maintains the context of the terminal device 150. In some embodiments, the request may include UP TNL information for uplink and downlink transmissions (i.e., UP TNL information for data forwarding).

[0128] In some embodiments, the request does not include UP TNL information for uplink and downlink transmissions (i.e., UP TNL information for data forwarding). In these embodiments, the fourth network device 140 can send a third request to the second network device 120 to obtain UP TNL information for data forwarding, and receive the UP TNL information from the second network device 120.

[0129] In block 820, the fourth network device 140 determines whether to relocate the anchor. If it is determined to relocate the anchor, in block 830, the fourth network device 140 transmits information to the second network device 120 regarding the sequence number and hyperframe number of the data packet associated with the uplink data to be transmitted. In some embodiments, the fourth network device 140 may transmit this information to the second network device 120 in a response to the request that includes the context. In some embodiments, the fourth network device 140 may transmit this information in a message dedicated to transmitting this information.

[0130] At block 840 , the fourth network device 140 transmits the data packet to the second network device 120 .

[0131] The implementation of the methods shown in Figures 4 to 8 basically corresponds to the processes described in relation to Figures 2 and 3, and therefore further details are omitted here. The methods 400 to 800 according to the embodiments of the present disclosure provide an enhanced mechanism for SDT and realize lossless transmission for SDT.

[0132] Equipment example 9 is a schematic block diagram of an apparatus 900 suitable for implementing embodiments of the present disclosure. The apparatus 900 may be considered as another exemplary implementation of the first, second, third and fourth network devices 110, 120, 130, 140 or the terminal device 150 shown in FIG. 1. Thus, the apparatus 900 may be implemented in or as at least a part of the first, second, third and fourth network devices 110, 120, 130, 140 or the terminal device 150.

[0133] As shown, the apparatus 900 comprises a processor 910, a memory 920 coupled to the processor 910, a suitable transmitter (TX) and receiver (RX) 940 coupled to the processor 910, and a communication interface coupled to the TX / RX 940. The memory 910 stores at least a portion of a program 930. The TX / RX 940 is used for bidirectional communication. The TX / RX 940 has at least one antenna to facilitate communication, although the access nodes referred to herein may in practice have multiple antennas. The communication interface may represent any interface required for communication with other network elements, such as an X2 / Xn interface for bidirectional communication between eNBs / gNBs, an S1 / NG interface for communication between a mobility management entity (MME) / access and mobility management function (AMF) / SGW / UPF and an eNB / gNB, an Un interface for communication between an eNB / gNB and a relay node (RN), or an Uu interface for communication between an eNB / gNB and a terminal device.

[0134] It is assumed that the program 930 includes program instructions that, when executed by an associated processor 910, enable the device 900 to operate according to embodiments of the present disclosure, as described herein with reference to Figures 1 to 8. The embodiments of the present disclosure may be realized by computer software executable by the processor 910 of the device 900, or by hardware, or by a combination of software and hardware. The processor 910 may be configured to perform various embodiments of the present disclosure. Furthermore, the combination of the processor 910 and the memory 920 may form a processing means 950 suitable for performing various embodiments of the present disclosure.

[0135] The memory 920 may be of any type suitable for a local technology network and may be implemented using any suitable data storage technology, such as, by way of non-limiting example, non-transitory computer-readable storage media, semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. Although only one memory 920 is shown in the device 900, there may be several physically distinct memory modules in the device 900. The processor 910 may be of any type suitable for a local technology network and may include, by way of non-limiting example, one or more of a general purpose computer, a special purpose computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. The device 900 may have multiple processors, for example application specific integrated circuit chips time-slaved to a clock that synchronizes the main processor.

[0136] Overall, various embodiments of the present disclosure can be realized in hardware or special purpose circuits, software, logic, or any combination thereof. Some aspects may be realized in hardware, while other aspects may be realized in firmware or software that can be executed by a controller, microprocessor, or other computing device. Although various aspects of the embodiments of the present disclosure have been illustrated and described using block diagrams, flow charts, or some other pictorial representations, it should be understood that the blocks, devices, systems, techniques, or methods described herein can be implemented, by way of non-limiting examples, in hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing device, or any combination thereof.

[0137] The present 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, such as instructions included in a program module, that execute in a device on a target real or virtual processor to perform the process or method described above with reference to Figures 2 to 8. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. The machine-executable instructions of the program modules may be executed in local or distributed devices. In a distributed device, the program modules may be located in both local and remote storage media.

[0138] Program codes for carrying out the methods of the present disclosure can be written in any combination of one or more programming languages. These program codes are provided to a processor or controller of a general purpose computer, a special purpose computer, or other programmable data processing device, and when executed by the processor or controller, cause the program code to implement the functions / operations specified in the flowcharts and / or block diagrams. The program code can run entirely on the machine, partially on the machine, as a separate software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0139] The above program code may be implemented on a machine-readable medium, which may be any tangible medium that can contain or store a program used by or associated with an instruction execution system, device, or apparatus. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the aforementioned media. More specific examples of machine-readable storage media may include an electrical connection having one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable optical disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the aforementioned.

[0140] It should be understood that although operations have been described in a particular order, it is not required that such operations be performed in the particular order shown, or in any sequential order, or that all of the operations described be performed, in order to achieve desired results. In some cases, multitasking or parallel processing may be advantageous. Similarly, although some specific implementation details are included in the above discussion, these should not be construed as limitations on the scope of the disclosure, but rather as descriptions of features that may be specific to certain embodiments. Some features that are described in the context of individual embodiments may be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may be implemented in multiple embodiments separately or in any suitable subcombination.

[0141] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it should be understood that the present disclosure, as defined in the appended claims, is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

1. A means for receiving an RRC Resume Request message from a terminal device; means for transmitting to the second network device a first message requesting the second network device to transfer the context of the terminal device to the first network device, the first message including a first indication of whether a subsequent small data transmission (SDT) transmission is expected; means for receiving from the second network device a second message for transferring only a portion of the context of the terminal device; The second message includes a radio link control (RLC) configuration of the terminal device. A first network device.

2. The SDT is based on a random access channel (RACH), The first network device of claim 1 .

3. the first message is a RETRIEVE UE CONTEXT REQUEST message; 3. A first network device according to claim 1 or 2.

4. the second message further includes user plane transport network layer (UP TNL) information for uplink transmission. A first network device according to any one of claims 1 to 3.

5. determining, by the second network device, that the context of the terminal device is not completely relocated; A first network device according to any one of claims 1 to 4.

6. 1. A communication method performed by a first network device, comprising: receiving an RRC Resume Request message from a terminal device; sending a first message to the second network device requesting the second network device to transfer a context of the terminal device to the first network device, the first message including a first indication of whether a subsequent small data transmission (SDT) transmission is expected; receiving a second message from the second network device for transferring only a portion of the context of the terminal device; The second message includes a radio link control (RLC) configuration of the terminal device. Communication methods.

7. The SDT is based on a random access channel (RACH), The method according to claim 6.

8. The first message is a RETRIEVE UE CONTEXT REQUEST message. The method according to claim 6 or 7.

9. the second message further includes user plane transport network layer (UP TNL) information for uplink transmission.

9. The method according to any one of claims 6 to 8.

10. determining, by the second network device, that the context of the terminal device is not completely relocated; 10. The method according to any one of claims 6 to 9.

Images