Second Network Device and Method

Abstract

The present disclosure relates to a communication method, a communication device, and a communication medium. The communication method includes, in accordance with a determination that a terminal device in an inactive state has requested a first network device to transmit uplink data, determining whether to relocate an anchor of a context of the terminal device from a second network device that maintains the context of the terminal device to the first network device. The method further includes, in accordance with a determination that the anchor of the context of the terminal device is not to be relocated, forwarding the uplink data to a destination via the second network device based on the maintained context of the terminal device.

Description

Technical Field

[0001] Embodiments of the present disclosure generally relate to the field of electronic communications, and more particularly, to methods, devices, and media for communication.

Background Art

[0002] Since the introduction of the fourth generation (4G) communication system, efforts have been made to develop an improved fifth generation (5G) or pre-5G communication system to meet the increasing demand for wireless data traffic. The new communication system can support various types of service applications for terminal devices.

[0003] In a communication system, a terminal device can transition between an inactive state and a connected state with a network device. By putting the terminal device in the inactive state, power consumption benefits can be obtained. Conventionally, data transfer is not supported in the inactive state. Therefore, the terminal device has to establish or re-establish a connection with the network device for any downlink data or uplink data. Even if the packet size is small and infrequent, a connection is established every time data is transmitted and then released to the inactive state. This leads to unnecessary power consumption and signaling overhead. In the case of an application where a small amount of data is included in a single transmission, the overhead for establishing a connection between the terminal device and the network device is much higher compared to the small amount of data.

[0004] The signaling overhead from the terminal device in the inactive state in the case of small data transmission (SDT) is a common problem. As the number of terminal devices in the communication system increases, the signaling overhead becomes an important issue, affecting not only the performance and efficiency of the network but also the battery performance of the terminal device.

Summary of the Invention

Problems to be Solved by the Invention

[0005] Overall, exemplary embodiments of the present disclosure provide a solution for data transmission of a terminal device in an inactive state.

Means for Solving the Problems

[0006] In a first aspect, a method for communication is provided. The method includes determining whether to relocate an anchor for the context of the terminal device from a second network device that maintains the context of the terminal device to the first network device according to a determination that the terminal device in an inactive state has requested transmission of uplink data to the first network device, and transferring the uplink data to a destination via the second network device based on the maintained context of the terminal device according to a determination that the anchor for the context of the terminal device is not to be relocated.

[0007] In a second aspect, a method for communication is provided. The method includes determining, in a terminal device in an inactive state, whether a predetermined type of uplink transmission has been triggered to a first network device that does not have the context of the terminal device or to a second network device that maintains the context of the terminal device, establishing an RLC entity of the RLC layer based on a default setting for the radio link control (RLC) layer defined for the predetermined type of uplink transmission according to a determination that the predetermined type of uplink transmission has been triggered to the first network device, and transmitting the uplink data to the first network device based at least on the entity for the RLC layer.

[0008] In a third aspect, a network device is provided. The network device includes a processing unit and a memory coupled to the processing unit and storing instructions, and when the instructions are executed by the processing unit, the method according to the first aspect is performed.

[0009] In a fourth aspect, a terminal device is provided. The terminal device includes a processing unit and a memory coupled to the processing unit and storing instructions, and when the instructions are executed by the processing unit, the method according to the second aspect is performed.

[0010] In a fifth aspect, a computer-readable medium storing instructions is provided, and when the instructions are executed on at least one processor, the at least one processor is caused to perform the method according to the first aspect.

[0011] In a sixth aspect, a computer-readable medium storing instructions is provided, and when the instructions are executed on at least one processor, the at least one processor is caused to perform the method according to the second aspect.

[0012] Other features of the present disclosure will be readily understood from the following description.

Brief Description of the Drawings

[0013] The above and other objects, features, and advantages of the present disclosure will become more apparent from a more detailed description of some exemplary embodiments of the present disclosure in the accompanying drawings. In the drawings,

[0014]

Figure 1

[0015]

Figure 2

[0016]

Figure 3A

Figure 3B

[0017]

Figure 4

[0018]

Figure 5

[0019]

Figure 6

[0020]

Figure 7

[0021]

Figure 8

[0022]

Figure 9

[0023]

Figure 10

[0024] Throughout the drawings, the same or similar reference numerals represent the same or similar elements.

Embodiments for Carrying Out the Invention

[0025] Here, the principles of the present disclosure will be described with reference to some exemplary embodiments. It should be understood that these embodiments are described for illustrative purposes only and are intended to assist those skilled in the art in understanding and implementing the present disclosure, without suggesting any limitation on the scope of the present disclosure. The disclosure described in the text can be implemented in various ways different from those described below.

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

[0027] As used herein, the term "network device" means a device that can provide or host a cell or coverage with which a terminal device can communicate. Examples of network devices include, but are not limited to, Node B (NodeB or NB), evolved Node B (eNodeB or eNB), new radio access Node B (gNB), remote radio unit (RRU), radio head (RH), remote radio head (RRH), femto node, pico node, and other low-power nodes, star network devices, aircraft network devices, etc. Hereinafter, for the sake of discussion, some exemplary embodiments will be described with reference to eNB as an example of a network device.

[0028] As used herein, the term "terminal device" means 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 Everything (IoE) device, machine type communication (MTC) devices or evolved MTC (eMTC) devices, in-vehicle devices for V2X communication, etc. Here, "X" in V2X represents a pedestrian, a vehicle, or infrastructure / network, or an image acquisition device such as a digital camera, a game device, a music storage and playback device, or an Internet appliance enabling wireless or wired Internet access and browsing. In the following description, the terms "terminal device", "communication device", "terminal", "user equipment" and "UE" can be used interchangeably.

[0029] In one embodiment, the terminal device can 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 regarding different RATs can be transmitted from at least one of the first network device and the second network device to the terminal device. In one embodiment, the first information may be transmitted from the first network device to the terminal device, and the second information may be transmitted from the second network device directly or via the first network device to the terminal device. In one embodiment, information regarding the settings of the terminal device set by the second network device can be transmitted from the second network device via the first network device. Information regarding the re - settings of the terminal device set by the second network device can be transmitted from the second network device directly or via the first network device to the terminal device.

[0030] The communications discussed in this specification can comply with any suitable standard, including but not limited to New Radio (NR) access, Long-Term Evolution (LTE), LTE-Evolution, LTE-Advanced (LTE-A), Wideband Code Division Multiple Access (WCDMA), Code Division Multiple Access (CDMA), cdma2000, and Global System for Mobile Communications (GSM). Further, the communications can be performed according to any generation of communication protocol known currently or developed in the future. Examples of communication protocols include, but are not limited to, the 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 techniques described in the present text can be used in the above-mentioned wireless networks and wireless technologies, as well as other wireless networks and wireless technologies.

[0031] As used herein, the singular forms "a", "an", and "the" include the plural forms as well, unless the context clearly dictates otherwise. The terms "comprising" and its variants are to be understood as open-ended terms meaning "including, but not limited to". The term "based on" is to be understood as "based at least in part on". The terms "one embodiment" and "an embodiment" are to be understood as "at least one embodiment". The term "another embodiment" is to be understood as "at least one other embodiment". The terms "first", "second", etc. can refer to different or the same object. Other explicit and implicit definitions may be included below.

[0032] In some instances, values, processes, or devices are referred to as "best", "lowest", "highest", "minimum", "maximum", etc. Such descriptions are intended to indicate that a selection can be made from among a number of functional alternatives used, and it should be understood that such a selection need not be better, smaller, higher, or otherwise more preferred than other selections. Environmental example

[0033] FIG. 1 shows an exemplary communication environment 100 in which an exemplary embodiment of the present disclosure can be implemented. In the example of FIG. 1, a plurality of network devices 110, 120 are arranged to provide services to terminal devices. The serving areas of network devices 110, 120 are called cells 112, 122. A terminal device can be located within a cell of a network device. FIG. 1 shows a terminal device 130 located within cell 112 of network device 110, and the terminal device can communicate with network device 110. Network devices 110, 120, and optionally other network devices, can form an access network.

[0034] Communication between terminal device 130 and network devices 110, 120, and communication between network devices 110, 120 and CN 140 can be realized according to any suitable communication protocol. Communication in the direction from terminal device 130 to network device 110 or 120 is called UL communication, and communication in the direction from network device 110 or 120 to terminal device 130 is called DL communication. Terminal device 130 can move between the coverage areas of network devices 110, 120, and optionally other network devices.

[0035] In UL communication, the terminal device 130 can transmit UL data and control information to the network device 110 or 120 via the UL channel. In some examples, the UL data can be transmitted on the physical uplink shared channel (PUSCH) and / or any other available UL channel used for data transmission. In some examples, the UL control information can be transmitted on the physical uplink control channel (PUCCH) and / or any other available UL channel that can be used to transmit control information. In DL transmission, the network device 110 or 120 can transmit DL data and control information to the terminal device 130 via the DL channel. In some examples, the DL data can be transmitted on the physical downlink shared channel (PDSCH) and / or any other available DL channel used for data transmission. In some examples, the DL control information can be transmitted on the physical downlink control channel (PDCCH) and / or any other available DL channel available for control information transmission.

[0036] Network devices 110 and 120 can be connected to the core network (CN) 140. The core network 140 can include functional elements and / or network functions that support various functions. The functional elements or network functions may vary depending on the type of network. For example, CN 140 can include an access and mobility management function (AMF) 142 that can provide functions such as NAS encryption and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception, and transfer for session management. CN 140 can include a user plane function (UPF) 144 that can provide packet routing and forwarding, the user plane part of packet inspection and policy rule enforcement, lawful interception (UP collection), traffic usage reporting, an uplink classifier that supports routing of traffic flows to the data network, quality of service (QoS) processing for the user plane, uplink (UL) traffic verification, transport level packet marking in UL and DL, downlink (DL) packet buffering, DL data notification trigger, etc. Although not shown, CN 140 can include one or more other functional elements and / or network functions such as a session management function (SMF), a policy control function (PCF), and a network exposure function (NEF). The scope of the embodiments of the present disclosure is not limited in this regard.

[0037] It should be understood that the number of network devices and terminal devices in FIG. 1 is provided for illustrative purposes only and no limitations are implied. Environment 100 can include any suitable number of network devices and terminal devices suitable for implementing the embodiments of the present disclosure. For example, one or more terminal devices can be located within cell 112 and / or cell 122. CN 140 can include more, fewer, or different functional elements and / or network functions.

[0038] The 3GPP working group is working on a new feature called the inactive state. The terminal device can transition between the inactive state and the connected state. The inactive state may be referred to as the inactive mode, the RRC_INACTIVE state, or the inactive state in the RRC_CONNECTED mode, and these terms are used interchangeably in this text. The connected state may be referred to as the connected mode or the RRC_CONNECTED state, and these terms are used interchangeably in this text.

[0039] In the inactive state, the terminal device does not have dedicated resources (e.g., time and frequency resources) for transmission and / or reception. In the connected state, a connection is established between the terminal device and the network device, so the terminal device can communicate normally with the network device via this connection.

[0040] As described above, in order to transition the terminal device from the inactive state to the connected state by establishing or re - establishing the connection between the terminal device and the network device, a certain amount of signaling overhead and power consumption occur. Therefore, if connection establishment and subsequent release occur for each data transmission of a terminal device in the inactive state, unnecessary power consumption and signaling overhead may occur regardless of how small and infrequent the data packets are. Therefore, allowing data transmission to and / or from a terminal device in the inactive state makes sense when the terminal device transmits intermittent small data packets. It is agreed to support small data transmission (SDT) for the terminal device without requiring the terminal device in the inactive state to establish a connection with the network device. As used in this text, although other terms may be used, the term "SDT" means a transmission type that triggers a small amount of data.

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

[0042] However, currently, there is no specific solution for data transmission for terminal devices in an inactive state. The inventors have discovered that one potential problem in data transmission, especially UL data transmission in an inactive state, is related to the re-anchoring of the context of the terminal device. In an inactive state, the last serving network device maintains the context of the terminal device. When the terminal device moves into the coverage area of another network device and requests data transmission, since there is no connection established between this new network device and the terminal device in an inactive state, the new network device may not have the context of the terminal device that supports data transmission.

[0043] Normally, the new network device can request the context of the terminal device from the last serving network device and initiate a path switching procedure to the CN to send UL data to the UPF within the CN. However, such a procedure requires the exchange of a certain amount of signaling between the two network devices and may cause a delay in data transmission. Operation principle and method example

[0044] According to an exemplary embodiment of the present disclosure, a solution for data transmission for a terminal device in an inactive state is proposed. In this solution, according to the determination that the terminal device in the inactive state requests UL data transmission, the network device can determine whether to perform an anchor relocation for the context of the terminal device. The network device may be the network device that is requested to transmit UL data from the terminal device, or may be the network device that currently maintains the context of the terminal device. If it is determined that no relocation for the context of the terminal device has been performed, UL data can be transmitted from the requested network device to the network device that maintains the context of the terminal device, and the network device can then forward the UL data to the destination based on the maintained context. In this way, the requested network device or the network device that maintains the context can determine whether to perform an anchor relocation according to various actual requirements.

[0045] Some exemplary embodiments of the present disclosure will be described in detail below. First, referring to FIG. 2, a flowchart of an exemplary method 200 for data transmission for a terminal device 130 in an inactive state according to some embodiments of the present disclosure is shown. For the sake of discussion, method 200 will be described with reference to FIG. 1.

[0046] In an exemplary embodiment of the present disclosure, a method 200 including determining whether to perform an anchor relocation can be executed by a network device requested to transmit data from a terminal device or a network device currently maintaining the context of the terminal device. For a terminal device in an inactive state, when the terminal device is in a connected state, the network device maintaining the context of the terminal device is usually the last serving network device of the terminal device. When the terminal device transitions from a connected state to an inactive state, the last serving network device still maintains the context of the terminal device. On the other hand, a terminal device in an inactive state can move to a new location and request data transmission from another network device. Such another network device may be a new network device (with respect to the last serving network device).

[0047] In the example of FIG. 1, assume that network device 110 is a new network device 110 for terminal device 130 and network device 120 is the last serving network device 120 for terminal device 130. For the discussion in the present text, the new network device 110 may be referred to as the first network device, and the last serving network device 120 may be referred to as the second network device.

[0048] In block 210, the network device (new network device 110 or last serving network device 120) determines whether the terminal device 130 in the inactive state requests the network device 110 to transmit UL data. The new network device 110 can directly receive a request from the terminal device 130 and further receive UL data from the terminal device 130. Thereby, the new network device 110 itself can determine the request for UL data transmission. In some embodiments where method 200 is executed by the last serving network device 120, the new network device 110 may notify the last serving network device 120 of the request for UL data transmission.

[0049] In some embodiments, the transmission of UL data from the terminal device 130 to the new network device 110 can be based on a random access (RA) procedure. The terminal device 130 can initiate an RA procedure to the new network device 110. It can initiate any type of RA procedure, including a 4-step RA procedure, a 2-step RA procedure, etc. In the 4-step RA procedure, the terminal device 130 transmits a RA preamble to the new network device 110 within a first message (represented as "MSG1") via a physical random access channel (PRACH), and the new network device 110 transmits a RA response (RAR, which may also be called "MSG2") to the RA preamble. Upon receiving the RA response, the terminal device 130 transmits a message (which may also be called "MSG3") scheduled by the RAR to the new network device 110 and can include UL data in MSG3. In the 2-step RA procedure, the terminal device 130 transmits both the RA preamble and the UL data to the new network device 110 within one message (which may be represented as "MSGA" in some cases), where the preamble RA can be transmitted within the PRACH and the UL data can be transmitted within the PUSCH. In other types of RA procedures, the UL data may be transmitted to the new network device 110 within other messages.

[0050] When it is determined that the terminal device 130 in the inactive state requests the new network device 110 to transmit UL data, in block 220, the network device (the new network device 110 or the last serving network device 120) determines whether to relocate the anchor of the context of the terminal device 130 from the last serving network device 120 to the new network device 110. The last serving network device 120 maintains the context of the terminal device 130 and is regarded as the anchor (or anchor network device) of the context of the terminal device 130. As used herein, the term "anchor" generally refers to a network device (e.g., eNB / GNB) that has been connected to a previously inactive terminal device and has the context of the terminal device for subsequent communication. The new network device 110 does not have the context of the terminal device 130. As used herein, the context of the terminal device 130 can include various parameters and configuration information necessary for communicating with the terminal device 130.

[0051] A network device (new network device 110 or last serving network device 120) can determine whether to relocate an anchor of the context of the terminal device 130 based on one or more of various factors. Such factors can include one or more aspects of the UL data, the terminal device 130, and / or the current state of the last serving network device 120 or the new network device 110. In some embodiments, the network device 110 or 120 may determine based on one or more of the payload size of the UL data, the delay requirement for UL data transmission, etc. For example, the network device 110 or 120 can determine not to perform anchor relocation according to the determination that the payload size is relatively small (e.g., lower than the payload threshold), and / or according to the determination that the transmission of the UL data is sensitive to delay. In some exemplary embodiments, for the purpose of assisting the network in making a decision, the terminal device 130 can send a buffer status report (BSR) to the new network device 110 together with the UL data.

[0052] Alternatively, or in addition, the network device 110 or 120 can determine based on the number of UL transmissions from the terminal device 130 (or specifically, the number of SDTs from the terminal device 130). If the terminal device 130 frequently requests UL transmissions (the number of UL transmissions is more than the threshold number), the network device 110 or 120 can determine that relocating the context of the terminal device 130 to the new network device 110 can facilitate the continuous support of data transmission from the new network device 110 to the terminal device 130 and / or data transmission from the terminal device 130.

[0053] In some embodiments, the workloads at the new network device 110 and / or the last serving network device 120 may be taken into account when making decisions regarding anchor relocation and non-relocation. It should be understood that the factors affecting the decision are provided for illustrative purposes only, and one or more other factors may be considered.

[0054] If it is determined not to relocate the anchor of the context of the terminal device 130 (anchor non-relocation or anchor non-relocation scenario), in block 230, the network device (new network device 110 or last serving network device 120) transfers the UL data to the destination via the last serving network device 120 based on the context of the terminal device 130 maintained at the last serving network device 120. The UL data can be transferred between network devices, i.e., from the new network device 110 to the last serving network device 120. And the last serving network device 120 can use the context of the terminal device 130 to transfer the UL data. In this case, the signaling overhead for anchor relocation is saved and the delay in UL data transmission is reduced.

[0055] The destination of the UL data from the terminal device 130 may be within the CN 140. In some embodiments, the UL data can be sent to the UPF 144 within the CN 140. The UL data may be further processed within the CN 140. The scope of the embodiments of the present disclosure is not limited to the destination of the UL data.

[0056] In some embodiments, when it is determined to relocate the anchor of the context of the terminal device 130 to a new network device 110 (anchor relocation or an anchor relocation scenario), an anchor relocation can be performed between the network devices 110, 120 and the CN 140. In some embodiments, in method 200, the transmission of the UL data may be of the SDT type, which means that the size of the UL data may be relatively small. When the terminal device 130 triggers the SDT type, the new network device 110 or the last serving network device 120 can execute method 200. Process example without anchor relocation and process example with anchor relocation

[0057] As described above, the new network device 110 or the last serving network device 120 can determine whether to relocate the anchor and not to relocate the context of the terminal device 130 in the inactive state. In such two cases, the signaling between these devices may be different. Some exemplary embodiments will be described in more detail.

[0058] FIGS. 3A and 3B are signaling diagrams showing processes 300 and 305 of UL transmission without anchor relocation according to some embodiments of the present disclosure. For discussion purposes, processes 300 and 305 will be described with reference to FIG. 1. Processes 300 and 305 can include the terminal device 130, the network device 110, the network device 120, and the CN 140 of FIG. 1. In process 300 of FIG. 3A, it is the last serving network device 120 that determines whether to perform an anchor relocation of the context of the terminal device 130. In process 305 of FIG. 3B, it is the new network device 110 that determines whether to perform an anchor relocation.

[0059] First, the process 300 in FIG. 3A will be described. During operation, the terminal device 130 is in an inactive state. When the terminal device 130 has UL data to be sent to a specific destination, it requests the network device to send the UL data. If the terminal device 130 is within the coverage area of the new network device 110, the terminal device 130 requests the network device 110 to send the UL data (310). The new network device 110 receives the request and further receives the UL data from the terminal device 130. As described above, in some embodiments, the transmission of the UL data from the terminal device 130 to the new network device 110 can be based on the RA procedure.

[0060] When the new network device 110 receives the UL data from the terminal device 130, it sends an indication that the inactive terminal device 130 is requesting the transmission of the UL data (which may also be referred to as the "first indication" in the text) to the last serving network device 120 (320). In some exemplary embodiments, the network device 110 may send a context request to the last serving network device 120 to request the context of the terminal device 130. The context request may be a RETRIEVE UE CONTEXT REQUEST message. In one embodiment, the context request can include a resume cause that indicates the type of UL data transmission (e.g., SDT type). Alternatively or additionally, the context request can include information regarding the payload size of the UL data.

[0061] When the last serving network device 120 receives an indication that the terminal device 130 is requesting to transmit UL data, it determines (330) whether to relocate the anchor for the context of the terminal device 130 from the last serving network device 120 to the new network device 110. As described above, the last serving network device 120 can determine whether to perform anchor relocation based on one or more of various factors.

[0062] If it is determined not to relocate the anchor for the context of the terminal device 130, the last serving network device 120 transmits (340) an indication indicating not to relocate the anchor to the new network device 110. In some embodiments, the indication indicating not to relocate the anchor may be indicated within a response to a context request transmitted by the new network device 110. For example, the indication indicating not to relocate the anchor can be a RETRIEVE UE CONTEXT FAILURE message indicating that the request for the context of the terminal device 130 has failed.

[0063] Then, the new network device 110 transmits (350) the UL data of the terminal device 130 to the last serving network device 120. The UL data can be transmitted using a user plane interface (e.g., Xn-U interface) or a control plane interface (e.g., Xn-C interface) between the new network device 110 and the last serving network device 120. In embodiments using the user plane interface, the new network device 110 may need the data transfer address of the last serving network device 120. The last serving network device 120 can transmit, for example, information regarding its data transfer address to the new network device 110 within a RETRIEVE UE CONTEXT FAILURE message along with an indication indicating not to relocate the anchor. Of course, the information regarding the data transfer address may be transmitted to the new network device 110 in another message. The transmission of the data transfer address and the indication indicating not to relocate the anchor can be performed via the control plane interface between the new network device 110 and the last serving network device 120. The new network device 110 can transmit the UL data of the terminal device 130 to the last serving network device 120 via the user plane interface based on the provided data transfer address.

[0064] In an embodiment of transmitting UL data using a control plane interface, the new network device 110 can encapsulate the UL data within a control message and transmit the control message to the last serving network device 120 via the control plane interface. For example, the UL data may be included within a container carried within a control message (e.g., an Xn-C message). In some embodiments, the control message can also include an authentication code, such as an integrity message authentication code (MAC-I) (e.g., resume MAC-I), for the last serving network device 120 to perform authentication of the terminal device 130.

[0065] When receiving UL data (via a user plane interface or a control plane interface), the last serving network device 120 transmits the UL data to the destination of the UL data (355) based on the maintained context of the terminal device 130. In some embodiments, the destination of the UL data may be the CN 140. The last serving network device 120 can transmit the UL data to the UPF 144 within the CN 140.

[0066] Referring to process 305 of FIG. 3B, the new network device 110 determines whether to perform an anchor relocation. During operation, the terminal device 130 is in an inactive state. The terminal device 130 requests the transmission of UL data to the network device 110 (360). The new network device 110 receives the request and further receives the UL data. The transmission of the UL data from the terminal device 130 to the new network device 110 is similar to the transmission in process 300.

[0067] When receiving UL data from the terminal device 130 in the inactive state, since the new network device 110 does not have the context of the terminal device 130, it determines (370) whether to relocate the anchor of the context of the terminal device 130 from the last serving network device 120 to the new network device 110. As described above, the new network device 110 can determine whether to perform anchor relocation based on one or more of various factors.

[0068] If it is determined not to relocate the anchor of the context of the terminal device 130, the new network device 110 transmits the UL data of the terminal device 130 to the last serving network device 120 380. The UL data can be transmitted using the user plane interface (e.g., Xn-U interface) or the control plane interface (e.g., Xn-C interface) between the new network device 110 and the last serving network device 120.

[0069] In an embodiment that uses the user plane interface for UL data transmission, the new network device 110 may need the data transfer address of the last serving network device 120. The new network device 110 can request the data transfer address from the last serving network device 120. The last serving network device 120 can send a response containing the data transfer address for this request. The request and response can be sent via the control plane interface. As an example, the new network device 110 can send an Xn-U ADDRESS REQUEST message to the last serving network device 120 via the Xn-C interface to request a data transfer address for communication. The last serving network device 120 can respond with the data transfer address in an Xn-U ADDRESS INDICATION message. Of course, the information regarding the transfer address may be sent to the new network device 110 in any other message. Then, based on the provided data transfer address, the new network device 110 can send the UL data of the terminal device 130 to the last serving network device 120 via the user plane interface.

[0070] In an embodiment where UL data is transmitted using the control plane interface, the new network device 110 may not need to request a data transfer address. The new network device 110 can encapsulate the UL data within a control message and send the control message to the last serving network device 120 via the control plane interface. For example, the UL data may be included within a container carried within a control message (e.g., an Xn-C message). In some embodiments, the control message can also include an authentication code, such as an integrity message authentication code (MAC-I) (e.g., resumeMAC-I), for the last serving network device 120 to perform authentication of the terminal device 130.

[0071] When receiving UL data (via the user plane interface or the control plane interface), the last serving network device 120 transmits the UL data to the destination of the UL data (390) based on the maintained context of the terminal device 130. In some embodiments, the destination of the UL data may be the CN 140. The last serving network device 120 can send the UL data to the UPF 144 within the CN 140.

[0072] Above, embodiments of the scenario without anchor relocation have been described. FIG. 4 is a signaling diagram showing a process 400 of UL transmission with anchor relocation according to some embodiments of the present disclosure. For discussion purposes, the process 400 will be described with reference to FIG. 1. In the process 400, the decision on whether to perform anchor relocation may be made by the last serving network device 120 or the new network device 110.

[0073] During operation, the terminal device 130 is in an inactive state. The terminal device 130 requests (410) the network device 110 to transmit UL data. The new network device 110 receives the request and further receives the UL data. The transmission of UL data from the terminal device 130 to the new network device 110 is similar to the transmission in process 300.

[0074] The new network device 110 or the last serving network device 120 determines whether to relocate the anchor of the context of the terminal device 130 and decides to relocate the anchor (420). The new network device 110 retrieves the context of the terminal device 130 from the last serving network device 120 (430). In some cases where the new network device 110 makes a decision regarding relocation or non-relocation of the anchor, the new network device 110 can send a context request to the last serving network device 120 to request the context of the terminal device 130. The context request may be a RETRIEVE UE CONTEXT REQUEST message. In one embodiment, the context request can include a resume cause that indicates the type of UL data transmission (e.g., SDT). Alternatively, or in addition, the context request can include information regarding the payload size of the UL data. The last serving network device 120 can utilize the resume cause of the SDT or the payload size of the UL data to determine whether to provide the context of the terminal device 130 to the SDT. The last serving network device can send the maintained context of the terminal device 130 to the new network device 11 in, for example, a RETRIEVE UE CONTEXT RESPONSE message. In some cases where the last serving network device 120 makes a decision regarding relocation and non-relocation of the anchor, the new network device 110 can send a context request to the last serving network device 120 before making a decision to perform the anchor relocation. Thus, the last serving network device 120 can provide the maintained context of the terminal device 130 as a response to the context request, for example, in a RETRIEVE UE CONTEXT RESPONSE message.

[0075] Then, the new network device 110 can initiate a path switching procedure with CN 140. Specifically, the new network device 110 sends a PATH SWITCH REQUEST message 440 to the AMF 142 (440), and the AMF 142 responds to the new network device 110 with a PATH SWITH REQUEST RESPONS message (450). After the path switching is completed, the context of the terminal device 130 is transferred to the new network device 110. Based on the context, the new network device 110 can directly send the UL data of the terminal device 130 to its destination, for example, the UPF 144 in the CN 140 (460). Data transfer process example

[0076] Regardless of which network device makes the decision not to relocate the anchor for the context of the terminal device 130, without performing anchor relocation, the UL data of the terminal device 130 is sent from the new network device 110 to the last serving network device 120 and then sent to the UPF 144. In this case, the context of the terminal device 130 is unknown to the new network device 110 side, and each entity of the respective network protocol layers may be configured to support the communication of the UL data.

[0077] Generally speaking, in the case of a communication device (e.g., a terminal device or a network device), there are multiple entities of multiple network protocol layers that are in a stack structure, and these entities may be configured to execute corresponding processes on the data sent from and received by the communication device. To support the UL and DL communications of a specific terminal device, the configuration of the entities may be determined based on the context of the terminal device.

[0078] Entities in the network protocol layer can include one or more entities in the upper layers (Layer 2 and Layer 3), including entities in Layer 1, namely, entities in the physical (PHY) layer (also called PHY entities), entities in the media access control (MAC) layer (also called MAC entities), entities in the radio link control (RLC) layer (also called RLC entities), entities in the packet data convergence protocol (PDCP) layer (also called PDCP layer), and entities in the service data application protocol (SDAP) layer (also called SDAP layer, which is established in 5G and subsequent generation networks). In some cases, PHY, MAC, RLC, PDCP, and SDAP entities are in a stack structure.

[0079] In some embodiments, to support the transmission of UL data without transferring the context of the terminal device 130, the new network device 110 may establish an entity in the network protocol layer (sometimes referred to herein as "the first entity of the first network protocol layer") based on the default settings of the network protocol layer. The default settings are independent of the specific context of the terminal device 130. Generally, default settings may be applied to some lower network protocol layers. Establishing entities in the lower network protocol layers using default settings may not have a significant impact on communication performance.

[0080] In some embodiments, the new network device 110 can establish a PHY entity and a MAC entity based on the corresponding settings of the PHY layer and the MAC layer. The entities in the terminal device 130 and the last serving network device 120 may be established and configured to enable communication with the new network device 110. FIG. 5 shows a block diagram of network protocol layer entities established in a device according to some embodiments, where the new network device 110 establishes the entities of the network protocol layer based on default settings.

[0081] As shown in FIG. 5, for the communication of the UL data of the terminal device 130, the new network device 110 establishes a PHY entity 521 and a MAC entity 522 based on the respective default settings of the PHY layer and the MAC layer. The default setting of the PHY layer can be, for example, the L1 layer setting, and the default setting of the MAC layer can be, for example, the MAC cell group setting. The new network device 110 does not have to establish entities of network protocol layers higher than the MAC layer, such as the RLC entity, the PDCP entity, and the SDAP entity. Therefore, the UL data transmitted from the new network device 110 is packaged within an RLC protocol data unit (PDU).

[0082] On the last serving network device 120 side, in order to receive and process the RLC PDU from the new network device 110, all entities of all network protocol layers can be established based on the context of the maintained terminal device 130. However, entities of network protocol layers higher than the highest network protocol layer with the entities established in the new network device 110 may be established. The last serving network device 120 may not establish entities of network protocol layers lower than the RLC layer, such as MAC entities and PHY entities.

[0083] In the example of FIG. 5, the last serving network device 120 establishes an RLC entity 531 and one or more entities of network protocol layers higher than the RLC layer, such as a PDCP entity 532 and optionally an SDAP entity 533, based on the context of the maintained terminal device 130. When not relocating the anchor, the new network device 110 can use the PHY entity 521 and the MAC entity 522 to support the transmission of the UL data of the terminal device 130 to the last serving network device 120. An RLC PDU containing the UL data may be transmitted to the last serving network device 120. The last serving network device 120 can use the established RLC entity 531, PDCP entity 532, and SDAP entity 533 to process the received RLC PDU, and finally, transmit the UL data from the last serving network device 120 to the destination (e.g., UPF 144 within the CN 140).

[0084] In some embodiments, since the RLC PDU containing UL data is transmitted from the new network device 110 to the last serving network device 120, the data transfer address of the last serving network device 120 may be for each logical channel (LCH) between the last serving network device 120 and the new network device 110. Then, the new network device 110 can transmit the RLC PDU containing UL data to the last serving network device 120 based on the data transfer address for each LCH. In some embodiments, the information regarding the data transfer address provided by the last serving network device 120 can include a list of LCH identifiers (LCH IDs) indicating a list of LCHs for data transfer. Exemplary information elements (IEs) of the information regarding the data transfer address can be provided in Table 1 below, where "M" represents mandatory, "O" represents optional, and "UP TNL" represents the user plane transport network layer. (Table 1) IEs of Information Regarding Data Transfer Address TIFF0007690962000001.tif73167

[0085] On the terminal device 130 side, in order to enable the processing of UL data by the PHY entity 521 and MAC entity 522 established based on the corresponding default settings, the terminal device 130 can establish its PHY entity 511 and MAC entity 512 based on the same default settings for the PHY layer and MAC layer. The terminal device 130 can establish entities of network protocol layers higher than the MAC layer based on the context maintained locally thereon (e.g., access stratum (AS) context). Specifically, the terminal device 130 can establish the RLC entity 513, PDCP entity 514, and optionally, the SDAP entity 515 based on the context stored therein.

[0086] In some embodiments, the terminal device 130 can determine whether the triggered transmission of UL data is a specific type of UL transmission, such as the SDT type. If it is a specific type of UL transmission and there is a possibility of determining not to relocate the anchor in response to such a type of UL transmission, the terminal device 130 can establish the PHY entity 511 and the MAC entity 512 based on the default settings.

[0087] In some embodiments, it is expected that when anchor non-relocation occurs, the new network device 110 can establish an entity of a network protocol layer higher than the MAC layer, such as the RLC entity. In one embodiment, the default settings of the RLC layer may be predefined, which can be used in the case of SDT. Next, the new network device 110 can establish the RLC entity of the RLC layer based on the default settings defined for the SDT of the terminal device. FIG. 6 shows a block diagram of the network protocol layer entities established in the device in these embodiments.

[0088] Unlike the network protocol layer entities established in the example of FIG. 6, in the anchor non-relocation scenario, the new network device 110 can further establish the RLC entity 623 of the RLC layer. In one example, the RLC entity 623 is established based on the determination that the UL data of the terminal device 130 is a UL transmission of a predetermined type, for example, the SDT type. In other examples, when the new network device 110 or the last serving network device 120 determines not to perform anchor relocation for the context of the terminal device 130, the new network device 110 can establish the RLC entity 623. The new network device 110 can transmit a PDCP PDU including UL data to the last serving network device 120 based on the established RLC entity 623, MAC entity 522, and PHY entity 521.

[0089] On the side of the last serving network device 120, in order to receive and process the PDCP PDU from the new network device 110, it may not be necessary to establish other entities of the network protocol layer lower than the PDCP layer. As shown in FIG. 6, the last serving network device 120 can establish the PDCP entity 532 and the SDAP entity 533 based on the maintained context of the terminal device 130. The last serving network device 120 can receive the PDCP PDU from the new network device 110 and process the PDCP PDU using the PDCP entity 532 and the SDAP entity 533.

[0090] In some embodiments, since the PDCP PDU containing UL data is transmitted from the new network device 110 to the last serving network device 120, the data transfer address of the last serving network device 120 may be for each data radio bearer (DRB) between the last serving network device 120 and the new network device 110. Then, the new network device 110 can transmit the PDCP PDU containing UL data to the last serving network device 120 based on the data transfer address for each DRB.

[0091] On the terminal device 130 side, in order to enable the processing of UL data by the PHY entity 521, MAC entity 522, and RLC entity 623 established based on the corresponding default settings, the terminal device 130 can establish its PHY entity 511 and MAC entity 512 based on the default settings for the PHY layer and MAC layer, and establish the RLC entity 613 based on the default settings defined for the SDT of the terminal device 130. The terminal device 130 can further establish entities of network protocol layers higher than the RLC layer based on the context maintained locally therein. Specifically, as shown in the example of FIG. 5, the terminal device 130 can establish the PDCP entity 514 and, optionally, the SDAP entity 515 based on the context stored therein.

[0092] In some embodiments, the terminal device 130 can determine whether to establish the RLC entity 623 based on default settings or the context of the terminal device 130. FIG. 7 shows a flowchart of a method 700 implemented in the terminal device 130 according to some embodiments of the present disclosure.

[0093] In block 710, the terminal device 130 in the inactive state determines whether a UL transmission of a predetermined type is triggered to a first network device (i.e., the new network device 110) that does not have the context of the terminal device, or to a second network device (i.e., the last serving network device 120) that maintains the context of the terminal device. The UL transmission of the predetermined type may be, for example, an SDT type where the amount of UL data to be transmitted is relatively small.

[0094] If the terminal device 130 determines that a UL transmission of a predetermined type is triggered to the first network device (i.e., the new network device 110), in block 720, the terminal device 130 establishes an RLC entity of the RLC layer based on the default settings of the RLC layer defined for the UL transmission of the predetermined type. In block 730, the terminal device 130 transmits UL data to the first network device (i.e., the new network device 110) based on at least the entity of the RLC layer (e.g., the RLC entity 613) and other entities (e.g., the PHY entity 511, the MAC entity 512, the PDCP entity 514, and the SDAP entity 515 in the example of FIG. 6).

[0095] In some embodiments, a PDU (RLC PDU or PDCP PDU) including UL data transmitted from the new network device 110 to the last serving network device 120 can be transmitted via the control plane interface (e.g., the Xn-C interface) described above. The UL data may be included in a container when transmitted via the control plane interface. The container can include a user plane PDCP PDU (referred to as a PDCP-U PDU) or a user plane RLC PDU (referred to as an RLC-U PDU). Table 2 below can provide examples of IEs of UL data carried in a control message via the control plane interface. (Table 2) IEs of UL data carried in the message TIFF0007690962000002.tif80162 Process example of DL transmission in an anchor non-relocation scenario

[0096] In the anchor non-relocation scenario, there may be DL information sent to the terminal device 130. FIG. 8 is a signaling diagram showing a DL transmission process 800 according to some embodiments of the present disclosure. In process 800, the last serving network device 120 determines to send DL data 810 to the terminal device 130. Such DL data 810 can be transferred to the terminal device 130 by the new network device 110.

[0097] In some embodiments, the DL data 810 may be data provided to the last serving network device 120 of the terminal device 130 by the destination of the UL data (e.g., UPF 144 within CN 140) (e.g., as a response to the transmission of the UL data). In some embodiments where the MAC entity 522 is used to transmit UL data within the RLC PDU from the new network device 110 (as shown in the example of FIG. 5), the last serving network device 120 can send a status report of the RLC PDU containing the UL data. Such a status report can be sent as an RLC PDU and is regarded as the DL data 810.

[0098] The transmission of DL data can be performed via the user plane interface. Thus, the last serving network device 120 may need the data transfer address of the new network device 110. The last serving network device 120 sends (820) an address request to the new network device 110 to request the data transfer address of the new network device 110. As an example, the last serving network device 120 can send an Xn-U ADDRESS REQUEST message to the new network device 110 via the Xn-C interface to request a data transfer address for DL transmission. The new network device 110 responds (830) with information regarding the data transfer address, for example, within an Xn-U ADDRESS INDICATION message. In some embodiments, the new network device 110 may include its data transfer address in a message sent to the last serving network device 120 without being requested. For example, in some embodiments where the last serving network device 120 makes a decision on whether to perform an anchor relocation, information regarding the data transfer address may be included in a RETRIEVE UE CONTEXT REQUEST message sent to the last serving network device 120. As another example, if the new network device 110 requests the data transfer address of the last serving network device 120, information regarding the data transfer address may be included in an Xn-U ADDRESS REQUEST message sent to the last serving network device 120. Of course, information regarding the transfer address may be sent to the last serving network device 120 within any other message.

[0099] Then, the last serving network device 120 transmits (840) the DL data to the new network device 110 based on the data transfer address, for example, via the user plane interface between the last serving network device 120 and the new network device 110. The new network device 110 transfers (850) the DL data to the terminal device 130.

[0100] In some embodiments, in addition to the DL data, the last serving network device 120 may provide DL control information to the new network device 110 so that the network device 110 transfers it to the terminal device 130. In some embodiments, the DL control information may include control information for setting the terminal device 130 to the normal inactive state.

[0101] FIG. 9 is a signaling diagram showing a DL transmission process 800 according to some other embodiments of the present disclosure. In process 900, the last serving network device 120 is involved. When the anchor is not relocated, the last serving network device 120 transmits (910) an instruction (which may also be referred to as the second instruction) indicating to maintain the terminal device 130 in the inactive state to the terminal device 130 via the new network device 110.

[0102] In some embodiments, if the UE context is not relocated, the last serving network device transmits a control message that includes an RRC release message encapsulated within a PDU (e.g., an RLC-C PDU or a PDCP-C PDU). The control message may be an RRC TRANSFER message. The new network device 110 transmits (920) an instruction to the terminal device 130 to maintain the terminal device 130 in an inactive state so that the terminal device 130 remains in the inactive state. The new network device 110 may extract the RRC release message encapsulated in the PDU received from the last serving network device, and this message may instruct the terminal device 130 to remain in the inactive state.

[0103] In addition to, or as some alternatives to, the instruction to maintain the terminal device in an inactive state, it should be understood that other types of control information may be transmitted from the last serving network device 120, transferred by the new network device 110, and transmitted to the terminal device 130. In some embodiments, the DL data and the DL control information may be transmitted together in a message. The scope of the present disclosure is not limited in these respects. Device example

[0104] FIG. 10 is a schematic block diagram of a device 1000 suitable for implementing an embodiment of the present disclosure. The device 1000 can be considered as another exemplary embodiment of the terminal device 130, the network device 120, or the network device 110 shown in FIG. 1. Therefore, the device 1000 can be implemented in, or as at least a part of, the terminal device 130, the network device 120, or the network device 110.

[0105] As shown, device 1000 includes a processor 1010, a memory 1020 coupled to the processor 1010, a suitable transmitter (TX) and receiver (RX) 1040 coupled to the processor 1010, and a communication interface coupled to the TX / RX 1040. The memory 1020 stores at least a portion of a program 1030. The TX / RX 1040 is for bidirectional communication. The TX / RX 1040 has at least one antenna to facilitate communication, although the access nodes referred to herein can actually have multiple antennas. The communication interface can represent any interface necessary for communication with other network elements, such as an X2 interface for bidirectional communication between eNBs, an S1 interface for communication between a mobility management entity (MME) / serving gateway (S-GW) and an eNB, a Un interface for communication between an eNB and a relay node (RN), or a Uu interface for communication between an eNB and a terminal device.

[0106] Assume that when program 1030 is executed by the relevant processor 1010, as described in the text with reference to FIGS. 2 through 9, it includes program instructions that enable device 1000 to operate in accordance with embodiments of the present disclosure. The embodiments of the text can be realized by computer software executable by the processor 1010 of device 1000, or by hardware, or by a combination of software and hardware. The processor 1010 can be configured to implement various embodiments of the present disclosure. Further, the combination of the processor 1010 and the memory 1020 can form processing means 1050 suitable for realizing various embodiments of the present disclosure.

[0107] Memory 1020 may be of any type suitable for a local technology network and, by way of non-limiting example, may be implemented using any suitable data storage technology such as a non-transitory computer-readable storage medium, a semiconductor-based memory device, magnetic memory devices and systems, optical memory devices and systems, fixed memory, and removable memory. Although only one memory 1020 is shown within device 1000, there may be several physically different memory modules within device 1000. Processor 1010 may be of any type suitable for a local technology network and, by way of non-limiting example, may include one or more of a general-purpose computer, a dedicated computer, a microprocessor, a digital signal processor (DSP), and a processor based on a multi-core processor architecture. Device 1000 may have a plurality of processors, for example, an application-specific integrated circuit chip that is temporally dependent on a clock that synchronizes the main processor.

[0108] Overall, the various embodiments of the present disclosure can be implemented in hardware or dedicated circuitry, software, logic, or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software executable by a controller, a microprocessor, or other computing device. Although the various aspects of the embodiments of the present disclosure are illustrated and described using block diagrams, flowcharts, or some other pictorial representation, it should be understood that the blocks, devices, systems, techniques, or methods described herein can be implemented, by way of non-limiting example, in hardware, software, firmware, dedicated circuitry or logic, general-purpose hardware or a controller or other computing device, or some combination thereof.

[0109] 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 program modules, that are executed within a device on a target physical processor or virtual processor to perform the processes or methods described above with reference to any one of FIGS. 2 to 9. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of the program modules can be combined or divided among the program modules as needed. The machine-executable instructions of the program modules can be executed within a local or distributed device. In a distributed device, the program modules may be located in both local and remote storage media.

[0110] The program code for executing the method of the present disclosure can be described in any combination of one or more programming languages. This program code is provided to a processor or controller of a general-purpose computer, a dedicated computer, or other programmable data processing device, and when executed by the processor or controller, realizes the functions / operations specified in the flowchart and / or block diagram with the program code. The program code can be executed entirely on the machine, partially on the machine, as an independent software package, partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0111] The above program code can be implemented on a machine-readable medium, which may be any tangible medium that can be used by or associated with an instruction execution system, apparatus, or device and that can contain or store a program for them. The machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium can include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the above. More specific examples of the machine-readable storage medium can 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 above.

[0112] Also, although the operations are described in a particular order, it should not be understood that this requires the operations to be performed in the particular order shown or in a sequential order, or that all of the shown operations be performed, to obtain the desired result. 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 present disclosure, but rather as descriptions of features that may be specific to a particular embodiment. Some features described in the context of individual embodiments may be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may be implemented separately in multiple embodiments, or in any suitable sub-combination.

[0113] Although the present disclosure has been described in language specific to structural features and / or methodological acts, it is to be understood that the disclosure 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 illustrative forms of implementing the claims.

Claims

1. A second network device, comprising: means for receiving, from a first network device, a request message regarding small data transmission (SDT) of a terminal device in an inactive state, the request message including SDT indication information indicating that the terminal device is requesting the SDT and first information indicating the amount of uplink (UL) data of the SDT; means for determining, based on the first information, not to relocate the context of the terminal device from the second network device; means for transmitting, to the first network device, user plane (UP) transport layer information indicating an address for the UL data of the SDT in an Xn user plane interface between the first network device and the second network device; means for receiving, from the first network device, the UL data of the SDT in the Xn user plane interface; A second network device having the above.

2. The second network device according to claim 1, further comprising means for transmitting the UL data of the SDT to a core network.

3. The second network device according to claim 1, wherein the address is a destination address of the second network device.

4. The second network device according to claim 1, wherein the request message is a RETRIEVE UE CONTEXT REQUEST message.

5. The second network device according to claim 1, wherein a radio link control (RLC) entity related to the SDT is established in the first network device and a packet data convergence protocol (PDCP) entity is maintained in the second network device.

6. The second network device according to claim 1, wherein the UL data of the SDT is received in the form of a packet data convergence protocol (PDCP) protocol data unit (PDU).

7. The second network device according to claim 1, further comprising means for receiving, from the first network device, second information indicating an address for downlink (DL) data of the SDT in the Xn user plane interface between the first network device and the second network device.

8. The second network device according to claim 1, wherein the UL data of the SDT is received in the form of a packet data convergence protocol (PDCP) protocol data unit (PDU).

9. The second network device according to claim 1, further comprising means for receiving, from the first network device, second information indicating an address for downlink (DL) data of the SDT in the Xn user plane interface between the first network device and the second network device.

10. ​ ​ Furthermore, means for receiving the DL data of the SDT from a core network; means for transferring the DL data of the SDT to the first network device; and having The second network device according to claim 7.

9. Furthermore, having means for transmitting a radio resource control (RRC) transfer message including the DL control data of the SDT to the first network device. The second network device according to claim 8.

10. Furthermore, having means for transmitting a message in which a radio resource control (RRC) release message is encapsulated to the first network device, The RRC release message includes an indication that the terminal device is in the inactive state. The second network device according to claim 8.

11. A method executed by a second network device, the method comprising: Receiving, from a first network device, a request message regarding small data transmission (SDT) of a terminal device in an inactive state, the request message including SDT indication information indicating that the terminal device is requesting the SDT and first information indicating an amount of uplink (UL) data of the SDT; Determining, based on the first information, not to relocate the context of the terminal device from the second network device; Transmitting, to the first network device, user plane (UP) transport layer information indicating an address for the uplink (UL) data of the SDT in an Xn user plane interface between the first network device and the second network device; Receiving the UL data of the SDT from the first network device in the Xn user plane interface; A method including.

Images