Communication method and apparatus

Abstract

A communication method and apparatus, which can be used for reducing the communication latency of a terminal device. In the method, local RAN node identifiers of access network devices can be exchanged by means of a core network device, such that the access network devices can mutually learn of the respective local RAN node identifiers. Therefore, when it is necessary to acquire the context of a first terminal device in an inactive state, a first access network device can identify a corresponding second access network device on the basis of the respective local RAN node identifier, and request, by means of the core network device, the second access network device to acquire the context. In this way, the first terminal device can still enter a connected state from the inactive state, without the need to enter the connected state by means of an RRC connection setup procedure, thereby dispensing with a large number of signaling interaction procedures included in the RRC connection setup procedure, reducing the latency and overheads of the first terminal device entering the connected state, and improving the network efficiency and the user experience.

Description

A communication method and apparatus

[0001] Cross Reference to Related Applications

[0002] This application claims priority to the Chinese Patent Application No. 202510190238.3, filed on February 19, 2025, and entitled “A communication method and apparatus”, the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

[0003] The present application relates to the field of communication technology, and in particular, to a communication method and apparatus. BACKGROUND

[0004] The radio resource control (RRC) state of a user equipment (UE) can include a connected state, an idle state and an inactive state. When the UE switches from the connected state to enter the inactive state, the UE can be configured with a radio access network (RAN)-based notification area (RNA) by an anchor base station (e.g., base station 1) of the UE, and the context of the UE is saved. The anchor base station refers to the last serving RAN node of the UE when the UE is in the connected state. The base station can page the UE in the inactive state within the RNA, and the paged UE can enter the connected state from the inactive state by initiating an RRC connection resume procedure. Since the location of the UE can change, the base station (e.g., base station 2) where the UE initiates the RRC connection resume request can be different from the base station 1. Since the base station 2 does not save the context of the UE, the context of the UE needs to be obtained from the base station 1.

[0005] If the base station 1 and the base station 2 have an Xn interface, the base station 2 can obtain the context of the UE from the base station 1 through the Xn interface. However, if the base station 1 and the base station 2 do not have an Xn interface, or the Xn interface between the base station 1 and the base station 2 fails, the base station 2 will not be able to obtain the context from the base station 1, which will cause the RRC connection resume procedure of the UE to fail. When the RRC connection resume of the UE fails, the UE will enter the connected state through an RRC connection setup procedure, but the RRC connection setup procedure includes a large number of signaling interaction procedures, which results in a large delay for the UE to enter the connected state. SUMMARY

[0006] Embodiments of the present application provide a communication method and device for reducing the communication delay of a terminal device and saving signaling consumption.

[0007] In a first aspect, a communication method is provided, which can be applied to a first access network device. The first access network device is, for example, a first access network equipment, or other equipment including the function of the first access network equipment, or a circuit, or a chip system (or a chip, such as a modem chip, also known as a baseband chip, or a system on chip (SoC) chip or a system in package (SIP) chip containing a modem core) or other functional module capable of realizing the function of the first access network equipment, which is arranged in the first access network equipment, for example. In one example, the first access network device is the first access network equipment or a component (such as a central unit (CU), a distributed unit (DU), or a radio unit (RU)) in the first access network equipment. The following describes the first access network device as the first access network equipment. The method includes: receiving first information from a first core network equipment, the first information including a local RAN node identifier of a second access network equipment; and sending a first request to the first core network equipment, the first request being used to acquire the context of a first terminal device, the first request including a global RAN node identifier of the second access network equipment, the global RAN node identifier of the second access network equipment being determined according to the first information. The second access network equipment is the access network equipment that last served the first terminal device before the first terminal device entered the inactive state, i.e., the anchor base station of the first terminal device, and the first terminal device is in the RRC inactive state.

[0008] It can be seen that the embodiments of the present application provide a scheme in which the local RAN node identifiers of access network equipments can be exchanged through a core network equipment, so that the access network equipments can learn the local RAN node identifiers of each other. In this way, when the context of the first terminal device in the inactive state needs to be acquired, the first access network equipment can identify the corresponding second access network equipment according to the local RAN node identifier, and request the second access network equipment to acquire the context through the core network equipment. Because the first access network equipment can learn the local RAN node identifier of the second access network equipment and acquire the context of the first terminal device through the core network equipment, the first terminal device can still enter the connected state from the inactive state without going through the RRC connection establishment process to enter the connected state, thereby saving a large number of signaling interaction processes included in the RRC connection establishment process, reducing the delay and overhead of the first terminal device entering the connected state, and improving the network efficiency and user experience.

[0009] In a possible implementation, the first access network device is unable to communicate with the second access network device through the first interface, and the first interface is an interface between access network devices. For example, the first interface can be an Xn interface. Based on this implementation, even in the case that the first interface does not exist or is faulty between the access network devices, the first access network device can still interact with the local RAN node identifier through the core network device, and obtain the context of the first terminal device through the core network device, thereby solving the problem that the context cannot be obtained in this case. In addition, since the restriction of the interface between the access network devices no longer exists, the first terminal device can be configured with a wider range of RNA, which can improve the probability of the first terminal device entering the connected state from the inactive state, thereby reducing the communication delay and overhead of the first terminal device as much as possible.

[0010] In a possible implementation, the first information further indicates one or more of the following: a length of the local RAN node identifier of the second access network device; a global RAN node identifier of the first access network device; a global RAN node identifier of the second access network device; a tracking area of the first access network device; or a tracking area of the second access network device. By indicating the length of the local RAN node identifier of the second access network device, the first access network device can accurately identify which part is the local RAN node identifier of the second access network device. For example, the length of the local RAN node identifier can be represented by 2 bits corresponding to a full I-RNTI, and different values of the 2 bits can represent different lengths; or the length of the local RAN node identifier can be represented by 1 bit corresponding to a short I-RNTI, and different values of the 1 bit can represent different lengths. The global RAN node identifier of the first access network device can be, for example, a base station identifier (gNB ID) of the first access network device. By indicating the global RAN node identifier of the first access network device, the first access network device can identify who sends the first information, or identify the global RAN node identifier corresponding to the local RAN node identifier, so as to associate the two. By indicating the global RAN node identifier of the first access network device, the core network device can know which access network device needs to be sent when forwarding information. By indicating the tracking area of the first access network device or the tracking area of the second access network device, the core network device can determine the transit core network device when forwarding information, so as to successfully forward the information to the corresponding access network device. For example, when the first access network device and the second device belong to a cross-core network scenario, by indicating the tracking area of the first access network device, the second core network device corresponding to the second access network device can determine that the first information needs to be transited through the first core network device.

[0011] In one possible implementation, the method further includes: receiving a second request from a first terminal device, the second request being for requesting restoration of the RRC active state, the second request including the inactive radio network temporary identifier (I-RNTI) of the first terminal device; and determining the global RAN node identifier of the second access network device based on the local RAN node identifier in the I-RNTI and the first information. For example, the second request could be an RRC resume request. Based on this approach, the first access network device can identify the global RAN node identifier corresponding to the local RAN node identifier in the I-RNTI, thereby determining which access network device to obtain the context of the first terminal device from, which can solve the problem of not being able to obtain the context in some scenarios due to the inability to identify the local RAN node identifier.

[0012] In one possible implementation, the first request may further include one or more of the following: partial or complete information of the second request; a global RAN node identifier of the first access network device; a first identifier of the first terminal device, the first identifier being used for a second interface, the second interface being the interface between the first access network device and the first core network device; information indicating the tracking area of ​​the first access network device; or, information indicating the tracking area of ​​the second access network device. By including the information contained in the second request (such as an RRC resume request) in the first request, the information transmitted by the first terminal device can be sent to the second access network device, which can assist in achieving verification or identification purposes. For example, the first request may include verification information such as the resume message authentication code-integrity (resume MAC-I) in the second request, and the second access network device can perform verification based on the resume MAC-I to improve the security of the context acquisition process. By including the global RAN node identifier of the first access network device in the first request, it can be characterized that the sender of the first request is the first access network device, which can help ensure that the reply message to the first request is correctly sent to the first access network device. By including the first identifier of the first terminal device in the first request, it can help identify that the context to be acquired is the context of the first terminal device, improving the accuracy of context lookup. By indicating the tracking area of ​​the first access network device or the tracking area of ​​the second access network device in the first request, the core network device can identify the intermediate core network device when forwarding information, so as to smoothly forward the information to the corresponding access network device.

[0013] In one possible implementation, the method further includes sending second information to a first core network device, the second information including the local RAN node identifier of the first access network device. This can be understood as the first access network device also sending its own local RAN node identifier to the second access network device via the core network device. When a second terminal device enters the coverage area of ​​the first access network device from a non-active state, the second access network device can identify the anchor base station of the second terminal device as the first access network device based on the second terminal device's I-RNTI. Furthermore, it can obtain the context of the second terminal device from the first access network device. This allows the second terminal device to transition from a non-active state to a connected state without going through the RRC connection establishment process, reducing latency and overhead for the second terminal device to enter the connected state and improving network efficiency and user experience.

[0014] In one possible implementation, the method further includes receiving a first response from a first core network device. One implementation may include the context of the first terminal device and / or a second identifier, where the second identifier is used for a third interface, which is the interface between the second access network device and the second core network device, the second core network device serving the first terminal device. Based on this implementation, the first access network device can access the context of the first terminal device returned by the core network device. Additionally, the first access network device may also return a second identifier of the first terminal device. This second identifier may, for example, be the AMF UE NGAP ID. This second identifier can be used to locate the context of the first terminal device within the core network device to assist in completing the core network-side relocation process. Another implementation may include a first response indicating a failure to obtain the context of the first terminal device and / or the reason for the failure. For example, when the second access network device determines that a core network-side relocation process is required, it may indicate a failure to obtain the context and the reason for the failure, thereby triggering the core network-side relocation process by the second access network device.

[0015] In one possible implementation, where the first response includes the context and / or second identifier of the first terminal device, the method further includes: sending a third request to the first core network device, the third request requesting a change to a core network device serving the first terminal device, the third request including one or more of the following: the second identifier of the first terminal device; the identifier of the second core network device; or information indicating the tracking area of ​​the second access network device. Based on this implementation, the migration process on the core network side can be triggered by the first access network device, enabling timely switching to a core network device serving the first terminal device in scenarios where the first and second access network devices are cross-core network devices, reducing the probability of failing to address the core network device serving the first terminal device during subsequent communication. Furthermore, by carrying the aforementioned information in the third request, the context of the first terminal device within the core network device can be located, thereby assisting in completing the migration process on the core network side.

[0016] Secondly, a communication method is provided, which can be applied to a second access network device. The second access network device is, for example, a second access network equipment, or other equipment including the functions of a second access network equipment, or a circuit, or a system-on-a-chip (or chip, such as a modem chip, also known as a baseband chip, or a SoC chip or SIP chip containing a modem core) or other functional module, which can implement the functions of the second access network equipment, and is, for example, disposed in the second access network equipment. In one example, the second access network device is a second access network equipment or a component (e.g., CU, DU, or RU) within the second access network equipment. The following description uses the example of a second access network equipment. The method includes: sending first information to a second core network equipment, the first information including the local RAN node identifier of the second access network equipment; receiving a fourth request from the second core network equipment, the fourth request being used to obtain the context of a first terminal equipment, the second access network equipment being the access network equipment that last served the first terminal equipment before entering an inactive state, the first terminal equipment being in an RRC inactive state.

[0017] Optionally, in some scenarios, the first access network device and the second access network device are connected to the same core network device. In this case, the first core network device and the second core network device are the same device. That is, the first core network device and the second core network device can also be described as core network devices.

[0018] In one possible implementation, the first information further indicates one or more of the following: the length of the local RAN node identifier of the second access network device; the global RAN node identifier of the first access network device, wherein the first information is used to indicate the local RAN node identifier of the second access network device to the first access network device; the global RAN node identifier of the second access network device; the tracking area of ​​the first access network device; or, the tracking area of ​​the second access network device.

[0019] In one possible implementation, the first access network device and the second access network device cannot communicate through the first interface, which is the interface between access network devices.

[0020] In one possible implementation, the method further includes: receiving second information from a second core network device, the second information including the local RAN node identifier of the first access network device.

[0021] In one possible implementation, the method further includes sending a first response to a second core network device. The first response includes the context of the first terminal device and / or a second identifier, the second identifier being used for a third interface, the third interface being the interface between the second access network device and the second core network device, the second core network device being a core network device serving the first terminal device; or, the first response indicates a failure to obtain the context of the first terminal device and / or the reason for the failure, the first core network device corresponding to the first access network device being different from the second core network device.

[0022] In one possible implementation, if the first response indicates that obtaining the context of the first terminal device failed and / or the reason for the failure, the method further includes: sending a fifth request to a second core network device, the fifth request being for requesting a change of core network device to serve the first terminal device, the fifth request including the I-RNTI of the first terminal device.

[0023] For the technical effects of the various alternative implementations of the second aspect, please refer to the description of the technical effects of the corresponding implementations of the first aspect.

[0024] Thirdly, a communication method is provided that can be applied to a core network device. This core network device may be, for example, a core network equipment or core network element, or other equipment including core network equipment functions, or a circuit, or a system-on-a-chip (or chip, such as a modem chip, also known as a baseband chip, or a SoC chip or SIP chip containing a modem core) or other functional module, which can implement the functions of the core network equipment, and is, for example, disposed within the core network equipment. In one example, the core network device is an AMF. The following description uses a core network device as an example. The method includes: sending first information to a first access network device, the first information including a local RAN node identifier of a second access network device; receiving a first request from the first access network device, the first request being used to obtain the context of a first terminal device, the first request including a global RAN node identifier of the second access network device, the global RAN node identifier corresponding to the local RAN node identifier, the second access network device being the last access network device that served the first terminal device before the first terminal device entered an inactive state, the first terminal device being in an RRC inactive state; and sending a fourth request to the second access network device, the fourth request being determined based on the first request.

[0025] Optionally, in some scenarios, the first access network device and the second access network device are connected to the same core network device. In this case, after receiving the first request, the core network device can directly send the fourth request to the second access network device. The core network device can be understood as a relay device, forwarding the information in the first request from the first access network device to the second access network device. Optionally, the core network device can transparently transmit the first request, meaning the content of the fourth request is the same as the content of the first request.

[0026] Optionally, in some scenarios, the core network devices connected to the first access network device and the second access network device are different. For example, the first access network device corresponds to the first core network device, and the second access network device corresponds to the second core network device. For instance, the core network device executing the above method can be the first core network device. After receiving the first request from the first access network device, the first core network device can send a fourth request to the second access network device through the second core network device. As another example, the core network device executing the above method can be the second core network device. The second core network device can receive the first request from the first access network device through the first core network device and send a fourth request to the second access network device.

[0027] It should be understood that subsequent actions involving sending or receiving information from access network devices can be interpreted in the same way as the two optional methods mentioned above, and will not be elaborated further.

[0028] In one possible implementation, the first access network device and the second access network device cannot communicate through the first interface, which is the interface between access network devices.

[0029] In one possible implementation, the first information further indicates one or more of the following: the length of the local RAN node identifier of the second access network device; the global RAN node identifier of the first access network device; the global RAN node identifier of the second access network device; the tracking area of ​​the first access network device; or, the tracking area of ​​the second access network device.

[0030] In one possible implementation, the first request may further include one or more of the following: part or all of the information of the second request, the second request being used to request the restoration of the RRC active state; the global RAN node identifier of the first access network device; the first identifier of the first terminal device, the first identifier being used for the second interface, the second interface being the interface between the first access network device and the core network device; information indicating the tracking area of ​​the first access network device; or, information indicating the tracking area of ​​the second access network device.

[0031] In one possible implementation, the method further includes: receiving second information from a first access network device, the second information including a local RAN node identifier of the first access network device; and sending the second information to a second access network device.

[0032] In one possible implementation, the core network device executing the method is a first core network device, and the method further includes: receiving a first response from a second core network device and sending the first response to a first access network device. The second core network device is a core network device serving the first terminal device. The first response includes the context of the first terminal device and / or a second identifier, the second identifier being used for a third interface, the third interface being the interface between the second access network device and the second core network device; or, the first response indicates a failure to obtain the context of the first terminal device and / or the reason for the failure.

[0033] In one possible implementation, the core network device performing the method is a first core network device, and the method further includes: receiving a third request from a first access network device. The third request is used to request a change to a core network device serving the first terminal device, and the third request includes one or more of the following: a second identifier of the first terminal device; an identifier of the second core network device; or information indicating the tracking area of ​​the second access network device.

[0034] In one possible implementation, the core network device performing the method is a first core network device, and the method further includes: receiving a sixth request from a second core network device, the sixth request being used to request a change to a core network device serving the first terminal device, the sixth request including the I-RNTI of the first terminal device; and sending a seventh request to a first access network device, the seventh request being determined based on the sixth request.

[0035] For the technical effects of the various alternative implementations of the third aspect, please refer to the description of the technical effects of the corresponding implementations of the first aspect.

[0036] Fourthly, a communication method is provided, which can be applied to a first access network device. The first access network device is described in the first aspect. The method includes: sending a query request to a core network device (or a first core network device), the query request including the I-RNTI of a first terminal device or a local RAN node identifier included in the I-RNTI; receiving a query response from the core network device (or the first core network device), the query response including a global RAN node identifier of a second access network device; and sending a first request to the core network device (or the first core network device), the first request being used to obtain the context of the first terminal device, the first request including the global RAN node identifier of the second access network device. Wherein, the second access network device is the access network device that last served the first terminal device before it entered an inactive state, i.e., the second access network device is the anchor base station of the first terminal device, and the first terminal device is in an RRC inactive state.

[0037] Based on this implementation, the core network device can store local RAN node identifiers and global RAN node identifiers. When it is necessary to query the global RAN node identifier corresponding to a certain local RAN node identifier, the access network device can query the core network device, thereby solving the problem of the access network device being unable to obtain the context due to its inability to parse the local RAN node identifier. In this way, the first terminal device can still enter the connected state from the inactive state without having to go through the RRC connection establishment process to enter the connected state, reducing the latency and overhead of the first terminal device entering the connected state, and improving network efficiency and user experience.

[0038] In one possible implementation, the method further includes sending the local RAN node identifier and global RAN node identifier of the first access network device to the core network device (or the first core network device).

[0039] Fifthly, a communication method is provided, which can be applied to a core network device. The core network device is described in the third aspect. The method includes: receiving a query request from a first access network device, the query request including the I-RNTI of a first terminal device or a local RAN node identifier included in the I-RNTI; sending a query response to the first access network device, the query response including a global RAN node identifier of a second access network device; and receiving a first request from the first access network device, the first request being used to obtain the context of the first terminal device, the first request including the global RAN node identifier of the second access network device. Wherein, the second access network device is the access network device that last served the first terminal device before it entered an inactive state, i.e., the second access network device is the anchor base station of the first terminal device, and the first terminal device is in an RRC inactive state.

[0040] In one possible implementation, the method further includes: receiving a local RAN node identifier and a global RAN node identifier of a first access network device; and storing the local RAN node identifier and the global RAN node identifier of the first access network device. And / or, receiving a local RAN node identifier and a global RAN node identifier of a second access network device; and storing the local RAN node identifier and the global RAN node identifier of the second access network device.

[0041] For the technical effects of the various alternative implementations of the fifth aspect, please refer to the description of the technical effects of the corresponding implementations of the fourth aspect.

[0042] Sixthly, a communication method is provided, which can be applied to a first access network device. The first access network device is described in the first aspect. The method includes: sending a context acquisition request to a core network device (or a first core network device), the context acquisition request being used to acquire the context of a first terminal device, the context acquisition request including the I-RNTI of the first terminal device. Wherein, the second access network device is the access network device that last served the first terminal device before it entered an inactive state, i.e., the second access network device is the anchor base station of the first terminal device, and the first terminal device is in an RRC inactive state.

[0043] Based on this implementation, a context acquisition request can be initiated directly based on the I-RNTI without parsing the I-RNTI. For example, if the core network device has the ability to parse the local RAN node identifier in the I-RNTI, the access network device does not need to parse the local RAN node identifier, thus solving the problem of the access network device being unable to obtain context due to its inability to parse the local RAN node identifier. In this way, the first terminal device can still enter the connected state from the inactive state without going through the RRC connection establishment process, reducing the latency and overhead of the first terminal device entering the connected state, and improving network efficiency and user experience.

[0044] In one possible implementation, the method further includes sending the local RAN node identifier and global RAN node identifier of the first access network device to the core network device (or the first core network device).

[0045] A seventh aspect provides a communication method applicable to a core network device. This core network device is described in the third aspect. The method includes: receiving a context acquisition request from a first access network device, the context acquisition request being used to acquire the context of a first terminal device, the context acquisition request including the I-RNTI of the first terminal device. Wherein, the second access network device is the access network device that last served the first terminal device before it entered an inactive state, i.e., the second access network device is the anchor base station of the first terminal device, and the first terminal device is in an RRC inactive state. The global RAN node identifier of the second access network device is determined based on the local RAN node identifier included in the I-RNTI. A fourth request is sent to the second access network device, the fourth request containing the global RAN node identifier of the second access network device.

[0046] In one possible implementation, the method further includes: receiving a local RAN node identifier and a global RAN node identifier of a first access network device; and storing the local RAN node identifier and the global RAN node identifier of the first access network device. And / or, receiving a local RAN node identifier and a global RAN node identifier of a second access network device; and storing the local RAN node identifier and the global RAN node identifier of the second access network device.

[0047] For the technical effects of the various alternative implementations of the seventh aspect, please refer to the description of the technical effects of the corresponding implementations of the sixth aspect.

[0048] Eighthly, an apparatus is provided. The apparatus may be a first access network apparatus as described in the first, fourth, or sixth aspects above, and the apparatus possesses the functions of the first access network apparatus. Alternatively, the apparatus may be a second access network apparatus as described in the second aspect above, and the apparatus possesses the functions of the second access network apparatus. For example, the apparatus may implement the functions described in the first, second, fourth, or sixth aspects above. For example, the apparatus includes modules, units, or means corresponding to performing the operations involved in the first, second, fourth, or sixth aspects above. These modules, units, or means may be implemented in software, hardware, or a combination of software and hardware. The apparatus may be, for example, an access network device, or other device including access network device functions, or a chip system (or chip or circuit) or other functional module capable of implementing the functions of an access network device, and the chip system or functional module may be disposed, for example, in an access network device. In one optional implementation, the apparatus includes a baseband device and a radio frequency device. In another optional implementation, the apparatus includes a processing unit (sometimes also called a processing module) and a transceiver unit (sometimes also called a transceiver module). A transceiver unit can perform both sending and receiving functions. When the transceiver unit performs the sending function, it can be called a sending unit (sometimes also called a sending module), and when it performs the receiving function, it can be called a receiving unit (sometimes also called a receiving module). The sending unit and the receiving unit can be the same functional module, which is called the transceiver unit and can perform both sending and receiving functions; or, the sending unit and the receiving unit can be different functional modules, and the transceiver unit is a collective term for these functional modules.

[0049] In an optional implementation, the apparatus may be the first access network apparatus described in the first aspect above. The transceiver unit (or the receiving unit) is configured to receive first information from the first core network device, the first information including the local RAN node identifier of the second access network device. The transceiver unit (or the sending unit) is configured to send a first request to the first core network device, the first request being used to obtain the context of the first terminal device, the first request including the global RAN node identifier of the second access network device, the global RAN node identifier of the second access network device being determined based on the first information. Wherein, the second access network device is the access network device that last served the first terminal device before it entered the inactive state, that is, the second access network device is the anchor base station of the first terminal device, and the first terminal device is in the RRC inactive state.

[0050] In an optional implementation, the transceiver unit (or the receiving unit) is further configured to receive a second request from the first terminal device, the second request being for requesting the restoration of the RRC active state, and the second request including an I-RNTI. The processing unit is configured to determine the global RAN node identifier of the second access network device based on the local RAN node identifier in the I-RNTI and the first information.

[0051] In an optional implementation, the apparatus may be the second access network apparatus described in the second aspect above. The transceiver unit (or the sending unit) is configured to send first information to the second core network device, the first information including the local RAN node identifier of the second access network device. The transceiver unit (or the receiving unit) is configured to receive a fourth request from the second core network device, the fourth request being used to obtain the context of the first terminal device, wherein the second access network device is the access network device that last served the first terminal device before it entered the inactive state, and the first terminal device is in the RRC inactive state.

[0052] In an alternative embodiment, the device further includes a storage unit (sometimes also called a storage module), and the processing unit is configured to couple with the storage unit and execute programs or instructions in the storage unit to enable the device to perform the functions of the first access network device as described in the first, fourth, or sixth aspects above, or to enable the device to perform the functions of the second access network device as described in the second aspect above.

[0053] Ninthly, an apparatus is provided. The apparatus may be a core network device as described in the third, fifth, or seventh aspects above. The apparatus possesses the functions of the aforementioned core network device. For example, the apparatus may implement the functions described in the third, fifth, or seventh aspects. For instance, the apparatus includes modules, units, or means corresponding to the operations involved in the third, fifth, or seventh aspects. These modules, units, or means may be implemented in software, hardware, or a combination of software and hardware. The apparatus may be, for example, a core network device (a first core network device or a second core network device), or other devices including core network device functions, or a chip system (or chip or circuit) or other functional module capable of implementing the functions of the core network device. This chip system or functional module may be, for example, disposed within the core network device. In one optional implementation, the apparatus includes a baseband device and a radio frequency device. In another optional implementation, the apparatus includes a processing unit (sometimes also called a processing module) and a transceiver unit (sometimes also called a transceiver module). For details on the implementation of the transceiver unit, please refer to the description in the fourth aspect.

[0054] In one optional implementation, the transceiver unit (or the sending unit) is configured to send first information to the first access network device, the first information including the local RAN node identifier of the second access network device. The transceiver unit (or the receiving unit) is configured to receive a first request from the first access network device, the first request being used to obtain the context of the first terminal device, the first request including the global RAN node identifier of the second access network device, the global RAN node identifier corresponding to the local RAN node identifier, the second access network device being the last access network device to serve the first terminal device before entering the inactive state, and the first terminal device being in the RRC inactive state. The transceiver unit (or the sending unit) is configured to send a fourth request to the second access network device, the fourth request being determined based on the first request.

[0055] In an alternative embodiment, the device further includes a storage unit (sometimes also called a storage module), the processing unit being coupled to the storage unit and executing programs or instructions in the storage unit to enable the device to perform the functions of the core network device described in the third, fifth, or seventh aspects above.

[0056] A tenth aspect provides an apparatus comprising a memory and one or more processors. The memory is used to store part or all of a computer program or instructions necessary for implementing the functions described in the first, second, fourth, or sixth aspects above. The one or more processors are executable to carry out the computer program or instructions, such that, when executed, the apparatus implements the methods in any possible design or implementation of the first, second, fourth, or sixth aspects above.

[0057] In one possible design, the device may further include interface circuitry, wherein the processor is configured to communicate with other devices or components via the interface circuitry.

[0058] In one possible design, the device may also include the memory.

[0059] The aforementioned device may be an access network device, or a communication module in an access network device, or a chip in an access network device that is responsible for communication functions, such as a modem chip (also known as a baseband chip) or a SoC or SIP chip containing a modem module.

[0060] Eleventhly, an apparatus is provided, the apparatus comprising a memory and one or more processors. The memory is used to store part or all of a computer program or instructions necessary for implementing the functions involved in the third, fifth, or seventh aspects described above. The one or more processors are executable to carry out the computer program or instructions, such that, when executed, the apparatus implements the methods in any possible design or implementation of the third, fifth, or seventh aspects described above.

[0061] In one possible design, the device may further include interface circuitry, wherein the processor is configured to communicate with other devices or components via the interface circuitry.

[0062] In one possible design, the device may also include the memory.

[0063] The aforementioned device may be a core network device, or a communication module in a core network device, or a chip in a core network device that is responsible for communication functions, such as a modem chip (also known as a baseband chip) or a SoC or SIP chip containing a modem module.

[0064] In a twelfth aspect, a communication system is provided, comprising a first access network device, a second access network device, and a core network device. Optionally, the communication system may further include a first terminal device. The second access network device sends first information to the core network device, the core network device sends first information to the first access network device, and the first access network device receives the first information from the core network device. The first information includes the local RAN node identifier of the second access network device. The first access network device sends a first request to the core network device, the core network device sends a fourth request to the second access network device, and the second access network device receives the fourth request from the core network device. The fourth request is determined based on the first request. The first request or the fourth request is used to request the context of the first terminal device, and the first terminal device is in an RRC inactive state. The first request or the fourth request includes the global RAN node identifier of the second access network device, which is determined by the first access network device based on the first information.

[0065] Optionally, the core network equipment in this communication system may include a first core network equipment and a second core network equipment. The first core network equipment is communicatively connected to a first access network equipment, and the second core network equipment is communicatively connected to a second access network equipment, meaning the first and second access network equipment are in a cross-core network scenario. Then, the second access network equipment sends first information to the second core network equipment, the second core network equipment sends first information to the first core network equipment, the first core network equipment sends first information to the first access network equipment, and the first access network equipment receives the first information from the first core network equipment. The first information includes the local RAN node identifier of the second access network equipment. The first access network equipment sends a first request to the first core network equipment, the first core network equipment forwards the first request to the second core network equipment, the second core network equipment sends a fourth request to the second access network equipment, and the second access network equipment receives the fourth request from the core network equipment. The fourth request is determined based on the first request. The first or fourth request is used to request the context of the first terminal equipment, which is in an RRC inactive state. The first request or the fourth request includes the global RAN node identifier of the second access network device, which is determined by the first access network device based on the first information.

[0066] In one possible implementation, the first access network device and the second access network device cannot communicate through the first interface, which is the interface between access network devices.

[0067] In one possible implementation, the first access network device is further configured to perform the methods described in the first, fourth, or sixth aspects above, which are executed by the first access network apparatus. The second access network device is further configured to perform the methods described in the second aspect above, which are executed by the second access network apparatus. The core network device is further configured to perform the methods described in the third, fifth, or seventh aspects above, which are executed by the core network apparatus. For details, please refer to the descriptions of the above aspects; further elaboration is unnecessary.

[0068] In a thirteenth aspect, a computer-readable storage medium is provided for storing a computer program or instructions that, when executed, cause the methods performed by the first access network device, the second access network device, or the core network device in the foregoing aspects to be implemented.

[0069] In a fourteenth aspect, a computer program product containing instructions is provided, which, when the computer program or instructions are run on a computer, causes the methods described in the above aspects to be implemented.

[0070] In a fifteenth aspect, a chip system is provided, including a processor and an interface, the processor being configured to call and execute instructions from the interface to enable the chip system to implement the methods of the above aspects.

[0071] For the technical effects of the implementation methods of aspects eight through fifteen, please refer to the description of the technical effects of aspects one, four, or six and their corresponding implementation methods. Attached Figure Description

[0072] Figure 1 is a schematic diagram of the process of a UE switching from an inactive state to a connected state;

[0073] Figures 2A and 2B are schematic diagrams of application scenarios provided by embodiments of this application;

[0074] Figures 3 to 7 are schematic flowcharts of the communication method provided in the embodiments of this application;

[0075] Figures 8A and 8B are schematic flowcharts of the communication method provided in the embodiments of this application;

[0076] Figure 9 is a schematic diagram of a device provided in an embodiment of this application;

[0077] Figure 10 is a schematic diagram of another device provided in an embodiment of this application. Detailed Implementation

[0078] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0079] The following explanations of some terms or concepts used in the embodiments of this application are provided to facilitate understanding by those skilled in the art.

[0080] (1) The terminal device mentioned in the embodiments of this application is a device with wireless transceiver function, which may be a fixed device, a mobile device, a handheld device (e.g., a mobile phone), a wearable device, an in-vehicle device, or a wireless device (e.g., a communication module, a modem, or a chip system, etc.) built into the above devices. The terminal devices are used to connect people, things, and machines, and can be widely used in various scenarios, including but not limited to the following: satellite communication, sensing scenarios, cellular communication, device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine / machine-type communications (M1M / MTC) communication, Internet of Things (IoT), virtual reality (VR), augmented reality (AR), industrial control, self-driving, remote medical care, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart city, drones, robots, and terminal devices for indoor commercial scenarios (such as mobile phone screen mirroring, file sharing, and mobile phone to VR glasses). When the terminal equipment is applied to V2X, it can also be called a V2X device, such as a smart car, digital car, unmanned car, driverless car, pilotless car, or automobile, self-driving car, or autonomous car, pure electric vehicle (EV), hybrid electric vehicle (HEV), range-extended electric vehicle (REEV), plug-in hybrid electric vehicle (PHEV), new energy vehicle, or roadside unit (RSU). The terminal equipment can also be a device used in D2D communication, such as an electricity meter or water meter.

[0081] Furthermore, in this embodiment of the application, the terminal device can also be a terminal device in an Internet of Things (IoT) system. IoT is an important component of the future development of information technology. Its main technical feature is to connect objects to the network through communication technology, thereby realizing an intelligent network of human-machine interconnection and object-to-object interconnection.

[0082] The various terminal devices described above, if located in a vehicle (e.g., placed inside or installed inside a vehicle), can all be considered in-vehicle terminal devices, also known as on-board units (OBUs). The terminal device of this application can also be an in-vehicle module, in-vehicle component, in-vehicle chip, or in-vehicle unit built into a vehicle as one or more components or units. The vehicle can implement the methods of this application through the built-in in-vehicle module, in-vehicle component, in-vehicle chip, or in-vehicle unit.

[0083] The terminal equipment may sometimes be referred to as user equipment (UE), terminal, access station, UE station, remote station, wireless communication equipment, or user device, etc.

[0084] In this application embodiment, the communication device used to implement the terminal device function can be a terminal device, which can be a terminal device or a device capable of supporting the terminal device to implement the function, such as a chip system. This device can be installed in the terminal device. In the technical solutions provided in this application embodiment, the terminal device is used as an example to describe the technical solutions provided in this application embodiment. For example, in the following description, the terminal device is described as a UE.

[0085] (2) In the embodiments of this application, the access network equipment (or access network element) refers to RAN equipment. RAN can be a cellular system related to the 3rd generation partnership project (3GPP), such as a 5G / NR mobile communication system or a future-oriented evolution system. RAN can also be an open RAN (O-RAN or ORAN), a cloud radioaccess network (CRAN), a virtualized RAN (vRAN), NTN, etc. RAN can also be a communication system that integrates two or more of the above systems. Access network equipment is a device with wireless transceiver capabilities used to communicate with the terminal equipment. Sometimes access network equipment can also be called a RAN node, RAN entity, or access node, etc. The access network equipment includes, but is not limited to, base stations (base transceiver stations, BTS, Node B, evolved Node B (eNodeB) / eNB, access point (AP) or next-generation Node B (gNodeB) / gNB), transmission reception point (TRP), base stations evolved under the 3rd generation partnership project (3GPP), access nodes in Wi-Fi systems, wireless relay nodes, and wireless backhaul nodes. The base stations can be macro base stations, micro base stations, pico base stations, small cells, relay stations, etc. Multiple base stations can support networks using the same access technology or networks using different access technologies. A base station can contain one or more co-located or non-co-located transmission and reception points. The access network equipment can also be a radio controller, centralized unit (CU), and / or distributed unit (DU) in a cloud radio access network (CRAN) scenario. The access network equipment can also be servers, etc. For example, the network equipment in V2X technology can be a roadside unit (RSU). The following description uses a base station as an example to illustrate the access network equipment. A base station can communicate with a terminal device, or it can communicate with a terminal device through a relay station. A terminal device can communicate with multiple base stations using different access technologies.

[0086] In a CU-DU architecture, or in an open RAN (ORAN) system, access network equipment may include one or more logical network elements such as a central unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). CUs and DUs may be separate entities or included in the same network element, such as a baseband unit (BBU). RUs may be included in radio equipment or radio units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs).

[0087] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called an open CU (O-CU), DU can also be called an open DU (O-DU), CU-CP can also be called an open CU-CP (O-CU-CP), CU-UP can also be called an open CU-UP (O-CU-CP), and RU can also be called an open RU (O-RU). For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples in its embodiments. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in the embodiments of this application can be implemented through software modules, hardware modules, or a combination of software modules and hardware modules.

[0088] The CU and DU can be configured according to the protocol layer functions of the wireless network they implement. For example, the CU can be configured to implement the functions of the Packet Data Convergence Protocol (PDCP) layer and above (such as the Radio Resource Control (RRC) layer and / or the Service Data Adaptation Protocol (SDAP) layer); the DU can be configured to implement the functions of protocol layers below the PDCP layer (such as one or more of the Radio Link Control (RLC) layer, Media Access Control (MAC) layer, or Physical (PHY) layer). As another example, the CU can be configured to implement the functions of protocol layers above the PDCP layer (such as the RRC and / or SDAP layers), and the DU can be configured to implement the functions of protocol layers below the PDCP layer (such as one or more of the RLC, MAC, or PHY layers).

[0089] The above CU and DU configurations are merely examples; the functions of the CU and DU can be configured as needed. For instance, the CU or DU can be configured to have more protocol layer functions, or only some protocol layer processing functions. For example, some RLC layer functions and protocol layer functions above the RLC layer can be placed in the CU, while the remaining RLC layer functions and protocol layer functions below the RLC layer can be placed in the DU. Furthermore, the functions of the CU or DU can be divided according to service type or other system requirements, such as by latency. Functions that require low latency can be placed in the DU, while functions that do not require low latency can be placed in the CU.

[0090] DU and RU can cooperate to implement the functions of the PHY layer. A DU can be connected to one or more RUs. The functions of DU and RU can be configured in various ways depending on the design. For example, a DU can be configured to implement baseband functions, and an RU can be configured to implement mid-RF functions. Another example is that a DU can be configured to implement higher-level functions in the PHY layer, and an RU can be configured to implement lower-level functions in the PHY layer, or to implement both lower-level and RF functions. Higher-level functions in the physical layer can include a portion of the physical layer's functions that are closer to the MAC layer, while lower-level functions in the physical layer can include another portion of the physical layer's functions that are closer to the mid-RF side.

[0091] When the RAN is O-RAN, it can also have artificial intelligence (AI) capabilities. For example, O-RAN includes an intelligent controller. The intelligent controller can be a non-real-time RAN intelligent controller (RIC / non-RT RIC / NRT RIC) or a near-real-time RAN intelligent controller (RIC / near-RT RIC / nRT RIC). A non-real-time RIC can be used to implement non-real-time intelligent management of RAN functions, enabling workflows including model training and model updates, and guiding applications / functions in the nRT RIC based on policies. A near-real-time RIC can be used to implement near-real-time intelligent management of the RAN. Through data collection and related operations on the E2 interface, near-real-time control and optimization of O-RAN modules and resources are achieved.

[0092] In this application embodiment, the communication device used to implement the functions of the access network device can be called an access network device. This access network device can be an access network element, an access network device, or a device capable of supporting the access network device or network element to implement the function, such as a chip system. This device can be installed in the access network device. In the technical solutions provided in this application embodiment, the access network device is used as an example to describe the technical solutions provided in this application embodiment. For example, in the following description, a base station is used as an example of the access network device.

[0093] (3) The core network equipment in this application embodiment can be a device that processes and forwards user signaling and data, such as a device that can implement functions such as mobility management, data processing, session management, policy and billing. The names of the devices that implement core network functions may be different in systems with different access technologies, and this application embodiment does not limit this. Taking a 5th generation (5G) mobile communication technology system as an example, the core network equipment may include, for example, access and mobility management function (AMF), session management function (SMF), policy control function (PCF), or user plane function (UPF), etc.

[0094] In this application embodiment, a network element can also be referred to as an entity or a functional entity. For example, an AMF network element can also be referred to as an AMF entity or an AMF functional entity. Optionally, the device name mentioned in this application embodiment can omit "network element". For example, AMF network element and AMF have the same meaning.

[0095] When the RAN is O-RAN, some core network functions can also be implemented through the intelligent controller of the O-RAN. For example, the functions of core network devices (such as AMF) in this embodiment can be implemented through real-time RICs in the O-RAN, or they can also be implemented through non-real-time RICs in the O-RAN. If implemented through a non-real-time RIC, information exchanged between the non-real-time RICs can be relayed through a real-time RIC.

[0096] In this application embodiment, the communication device used to implement the functions of the core network equipment can be called a core network device. This core network device can be a core network element, a core network device, or a device capable of supporting the core network device or network element to implement the function, such as a chip system. This device can be installed in the core network device. In the technical solutions provided in this application embodiment, the core network device is used as an example to describe the technical solutions provided in this application embodiment. For example, in the following description, the core network device is described as an AMF (Advanced Feature Function).

[0097] (4) RRC status of UE.

[0098] The RRC state of a UE includes RRC connected state, RRC idle state, and RRC inactive state.

[0099] RRC Connected State: This can be simply called the connected state, which means that the UE has established an RRC connection with the network. When the UE is in the connected state, it can transmit data with the network device.

[0100] RRC Idle State: This can be simply called the idle state, meaning the UE has not established an RRC connection with the network and cannot transmit data with network devices, but can receive cell broadcast information, such as system information and paging messages. Furthermore, the base station does not store the UE's context. If the UE needs to transition from the idle state to the connected state, it needs to initiate an RRC connection establishment process.

[0101] RRC Inactive State: This can be simply referred to as the inactive state. Before entering the inactive state, the UE is in the connected state. The anchor base station releases the UE's RRC connection and saves the context in both the base station and the UE, allowing the UE to enter the inactive state. If the UE needs to re-enter the connected state from the inactive state, it needs to initiate an RRC connection restoration process at its currently camped base station. Because the UE may be in a mobile state, the UE's currently camped base station and its anchor base station may be the same base station or different base stations. Compared to the RRC connection establishment process, the RRC connection restoration process benefits from the anchor base station saving the UE's context, saving a significant amount of signaling interaction. For example, it saves unnecessary RRC reconfiguration and security mode configuration processes on the Uu interface, and saves the UE context establishment and authentication processes on the NG interface. These saved signaling interaction processes result in shorter UE latency and lower signaling overhead. However, the anchor base station needs to save the UE's context, which incurs storage overhead. The RRC inactive state can also be called the RRC deactivated state, RRC de-active state, RRC de-active state, or simply the inactive state, de-active state, de-active state, or de-activated state.

[0102] (5) Register area (RA) and RAN-based notification area (RNA)

[0103] A RA is a geographical area in a mobile communication network, consisting of one or more tracking areas (TAs). Each TA corresponds to a tracking area identity (TAI) used to manage the mobility and location updates of terminal devices.

[0104] An RNA (Radio Area) is a specific geographic region used for UE mobility management. Generally, an RNA can be a smaller area than the RA (Radio Area). An RNA can cover one or more cells, or one or more RAN (Radio Area) regions. An RNA can include multiple cells, and each RNA corresponds to an RNA identifier (ID).

[0105] For UEs in the RRC inactive state, paging can be performed within the RNA range to further reduce the transmission overhead of paging messages. The RNA is managed by the base station, which can locate the UE by paging it via RNA (RAN paging). This process is called radio access network level terminal tracking.

[0106] (6) I-RNTI, local RAN node identifier and global RAN node identifier

[0107] To support procedures for inactive UEs, the concept of I-RNTI is introduced. I-RNTI identifies the context of a UE in an inactive state. When a base station releases a UE to an inactive state, it assigns an I-RNTI to that UE. Simultaneously, when the network wants to page a UE, it sends a paging message containing the UE's I-RNTI to all cells in the UE's RNA. Upon receiving this paging message, if the UE finds a matching I-RNTI, it initiates an RRC connection recovery procedure to switch to the connected state.

[0108] I-RNTI can include two formats. The first format includes two parts: the first part identifies the anchor base station that assigned the I-RNTI, i.e., the local RAN node identifier of the anchor base station; the second part identifies the UE context stored in the anchor base station. The second format includes three parts: the first part indicates the length of the second part, i.e., the length of the local NG-RAN node identifier of the anchor base station that assigned the I-RNTI; the second part is the local RAN node identifier of the anchor base station; and the third part identifies the UE context stored in the anchor base station.

[0109] A local RAN node identifier is an identifier used to identify a base station within a small area or local region. A base station's local RAN node identifier can be used to resolve or identify its global NG-RAN node identifier. For example, a local RAN node identifier is used to identify a base station in I-RNTI. In 5G, for instance, a local RAN node identifier could be a local NG-RAN node identifier. Typically, local RAN node identifiers are changeable. If a base station uses an additional local RAN node identifier or deletes a currently used one, it needs to notify its neighboring base stations of this change.

[0110] The local RAN node identifier in the I-RNTI can determine which specific anchor base station assigned the I-RNTI, allowing a request to obtain the UE's context from that anchor base station. For example, the local RAN node identifier in the I-RNTI can determine the global RAN node identifier of the anchor base station. The global RAN node identifier is an identifier used to uniquely identify a base station, or it can be understood as an identifier that can uniquely identify a base station within a large scope or globally. For example, the global RAN node identifier can be used to uniquely identify a base station worldwide. In 5G, the global RAN node identifier can also be called the global NG-RAN node identifier. Generally, the global RAN node identifier of a base station does not change. For example, the global RAN node identifier can be a base station identifier (gNB ID) or a global base station identifier (global gNB ID). The gNB ID can uniquely identify a base station in a public land mobile network (PLMN), while the global gNB ID can uniquely identify a base station globally. The global gNB ID can be composed of the identifier of the PLMN to which the base station belongs and the gNB ID. The following text uses the global RAN node identifier gNB ID as an example to introduce the technical solution of this application.

[0111] I-RNTIs can include full I-RNTIs and short I-RNTIs. Typically, a full I-RNTI is 40 bits long, and a short I-RNTI is 24 bits long. Taking the second format as an example, an exemplary structure of an I-RNTI is as follows: the first part begins with the most significant bit (MSB) of the I-RNTI. This part can indicate the I-RNTI profile, also known as an I-RNTI profile, I-RNTI configuration options, or I-RNTI configuration parameters, indicating the length of the local RAN node identifier of the anchor base station that assigned the I-RNTI. The first part of a full I-RNTI is 2 bits long, and the first part of a short I-RNTI is 1 bit long.

[0112] See Table 1 below, which describes the I-RNTI configuration profile for full I-RNTI. The first column represents the options for the full I-RNTI configuration profile, and the second column represents the binary encoding of the values ​​in the full I-RNTI configuration profile.

[0113] Table 1

[0114] See Table 2 below, which describes the I-RNTI configuration profile for short I-RNTI.

[0115] Table 2

[0116] See Table 3 below. Table 3 describes the structure of the local RAN node identifier. The first column of the table represents the name of the information element (IE), the second column represents whether the information element is optional or mandatory, the third column represents the information element region or range, and the fourth column represents the length of the local RAN node identifier indicated by the corresponding I-RNTI profile. For example, "Local NG-RAN Node Identifier Full I-RNTI profile 0" indicates that the length of the local RAN node identifier is 21 bits under full I-RNTI.

[0117] Table 3

[0118] (7) UE identifier

[0119] A UE identifier can be used to identify a UE. A UE may use different identifiers in different scenarios. Various embodiments of this application involve a first identifier and a second identifier for the UE.

[0120] The first identifier can be used for the second interface, which is the interface between the UE's currently camped base station and the corresponding core network equipment. That is, the first identifier is an identifier assigned to the UE by the network equipment on the UE's currently camped side, and can be used to identify the UE on the second interface, or in other words, to identify the UE among devices transmitting information based on this second interface. Optionally, the first identifier can be an identifier assigned to the UE by the base station. For example, the second interface can be the NG interface between the currently camped base station and the core network equipment, and the first identifier can be the NG-RAN UE NGAP ID.

[0121] The second identifier is used for the third interface, which is the interface between the UE's anchor base station and the core network equipment corresponding to the anchor base station. That is, the second identifier is the identifier assigned to the UE by the network equipment corresponding to the UE when the UE transitions from the connected state to the inactive state. It can be used to identify the UE on the third interface, or to identify the UE among devices transmitting information based on this third interface. Optionally, the second identifier can be an identifier assigned to the UE by the core network equipment (such as the AMF). For example, the third interface can be the NG interface between the anchor base station and the core network equipment, and the second identifier can be the AMF UE NGAP ID.

[0122] (8) In the embodiments of this application, the number of nouns, unless otherwise specified, refers to "singular nouns or plural nouns", that is, "one or more". "At least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, or B exists alone, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. For example, A / B means: A or B. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b or c means: a, b, c, a and b, a and c, b and c, or a and b and c, where a, b, and c can be single or multiple.

[0123] (9) In the embodiments of this application, “when…”, “if”, and “if” all refer to the device making a corresponding processing under certain objective circumstances, and are not limited to a time, nor do they require the device to perform a judgment action when it is implemented, nor do they imply any other limitations. Unless otherwise specified, “if” and “if” can be replaced, and “when…” and “in the case of…” can be replaced. “When…” and “if” / “if” can be replaced.

[0124] (10) In the embodiments of this application, the ordinal numbers such as "first" and "second" are used to distinguish multiple objects and are not used to limit the size, content, order, timing, priority, or importance of multiple objects. Furthermore, the numbering of steps in the various embodiments described in this application is only to distinguish different steps and is not used to limit the order of steps. In the embodiments of this application, words such as "exemplarily" and "for example" are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as an "example" in this application should not be construed as being better or more advantageous than other embodiments or design schemes. Specifically, the use of the term "example" is intended to present a concept in a concrete manner. In the embodiments of this application, "of," "corresponding (relevant)," and "corresponding" can sometimes be used interchangeably; it should be noted that their intended meanings are consistent when their differences are not emphasized.

[0125] (11) In the embodiments of this application, the term "storage" or "preservation" may refer to storage in one or more memories. The one or more memories may be separately configured or integrated into an encoder or decoder, processor, or communication device. Alternatively, some of the memories may be separately configured, while others may be integrated into a decoder, processor, or communication device. The type of memory may be any form of storage medium, and this is not limited.

[0126] (12) In the embodiments of this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to XX" can be understood as the destination of the information being XX, which may include sending directly through the air interface or sending indirectly through the air interface by other units or modules. "Receive information from YY" can be understood as the sender of the information being YY, which may include receiving directly from YY through the air interface or receiving indirectly from YY through the air interface by other units or modules. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface. In other words, sending and receiving can be performed between devices, such as between access network devices and terminal devices, or within devices, such as sending or receiving between components, modules, chips, software modules, or hardware modules within a device via a bus, wiring, or interface.

[0127] (13) In the embodiments of this application, "instruction" may include direct instruction, indirect instruction, explicit instruction, and implicit instruction. When a certain instruction information is described as indicating A, it can be understood that the instruction information carries A, directly indicates A, or indirectly indicates A.

[0128] In this embodiment, the information indicated by the instruction information is called the information to be instructed. In specific implementations, there are many ways to indicate the information to be instructed, such as, but not limited to, directly indicating the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly indicate the information to be instructed by indicating other information, where there is a correlation between the other information and the information to be instructed. It can also indicate only a part of the information to be instructed, while the other parts are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various information, thereby reducing instruction overhead to some extent. Furthermore, the information to be instructed can be sent as a whole or divided into multiple sub-information units, and the sending period and / or timing of these sub-information units can be the same or different.

[0129] The technical features involved in the embodiments of this application are described below.

[0130] As described above, the UE receives paging messages in the inactive state. When it detects its own paging message, the UE can initiate an RRC connection restoration procedure to the network side. The network side can decide whether the UE transitions to the connected state, remains in the inactive state, or transitions to the idle state. Figure 1 illustrates the process of a UE switching from the inactive state to the connected state, which may include the following steps:

[0131] S101: The UE sends an RRC resume request message to the currently camped base station, which carries the I-RNTI allocated by the UE's anchor base station. The currently camped base station and the UE's anchor base station may be different, as shown in Figure 1. The example given is base station 1 as the anchor base station and base station 2 as the currently camped base station.

[0132] S102: If base station 2 can resolve the identity of base station 1 contained in I-RNTI, then base station 2 sends a UE context retrieval request to base station 1 through the Xn interface to request base station 1 to provide the UE's context data.

[0133] Two base stations can exchange their respective supported local RAN node identifiers and I-RNTI configuration profile identifiers (i.e., a 2-bit Full I-RNTI configuration profile identifier or a 1-bit Short I-RNTI configuration profile identifier) ​​via the Xn interface. This allows base stations to identify each other's local RAN node identifiers. Therefore, if base station 2 can resolve the identity of base station 1 contained in the I-RNTI, it means that base station 2 has received the local RAN node identifier of base station 1 through the Xn interface between base stations 1 and 2. Based on the local RAN node identifier in the I-RNTI, the anchor base station of the UE can be identified as base station 1.

[0134] S103: Base station 1 sends a UE context retrieval response to base station 2 via the Xn interface to provide UE context data to base station 2.

[0135] S104: Base station 2 instructs the UE to return to RRC connection state.

[0136] S105: The UE completes the restoration of the RRC connection state and returns an RRC resume complete message to base station 2.

[0137] S106: Base station 2 provides Xn user plane (Xn-U) address indication information to base station 1. In this way, base station 1 can send its cached downlink (DL) user data to base station 2 to prevent the loss of DL user data cached in base station 1.

[0138] S107: Base station 2 sends a path switch request to AMF.

[0139] S108: AMF sends a path switch response to base station 2.

[0140] S109: Base station 2 notifies base station 1 to release UE resources, such as UE context resources.

[0141] It is evident that the exchange of UE context data between base station 1 and base station 2 is based on the Xn interface between them. However, due to various limitations, establishing Xn interfaces between all base stations within an operator's entire network is generally not advisable. For example, data transmission between distant base stations may be minimal or nonexistent; establishing Xn interfaces between such base stations would waste unnecessary base station resources. Furthermore, at geographical boundaries, operators generally do not establish Xn interfaces between base stations in different geographical areas based on network management strategies. Finally, even if Xn interfaces are established between base stations, communication between them often fails when link failures occur.

[0142] To avoid potential RAN paging failures and UE context acquisition failures, the anchor base station must ensure that all base stations within the RNA have an Xn interface when configuring the RNA for the UE. Therefore, the RNA configured by the anchor base station for the UE generally cannot include base stations that are far away from the anchor base station. This limits the coverage of the RNA that can be configured for the UE, thereby reducing the beneficial effect of shorter access latency brought by inactive state related functions.

[0143] Therefore, to configure a larger RNA for the UE, it is proposed that there can be no Xn interface between base stations within the RNA configured for the UE; that is, there can be no Xn interface between base station 1 and base station 2. However, if there is no Xn interface between base station 1 and base station 2, according to the current RRC connection recovery procedure, base station 2 will be unable to obtain context from base station 1, which will cause the UE's RRC connection recovery procedure to fail. Furthermore, even if there is an Xn interface between base station 1 and base station 2, if the Xn interface between base station 1 and base station 2 fails—for example, due to network policy restrictions, temporary network interruptions, or recovery time—the connectivity of the Xn interface cannot be continuously guaranteed. According to the current RRC connection recovery procedure, base station 2 will also be unable to obtain context from base station 1, which will also cause the UE's RRC connection recovery procedure to fail. The inability of base station 2 to obtain context from base station 1 may be because the base stations cannot exchange their respective supported local RAN node identifiers through the Xn interface. This means that even if base station 2 receives the I-RNTI, it cannot recognize the local RAN node identifier in the I-RNTI and does not know which base station to obtain the UE's context from, thus leading to failure in obtaining the UE context. The inability of base station 2 to obtain the UE context from base station 1 could also be due to the inability of base stations to transmit the UE context through the Xn interface, thus causing the failure to obtain the UE context.

[0144] When the UE's RRC connection recovery process fails, the UE will enter the connected state through the RRC connection establishment process. However, the RRC connection establishment process includes a large number of signaling interaction processes, which results in a large delay for the UE to enter the connected state.

[0145] Therefore, this application provides a scheme that supports the absence of Xn connectivity between two base stations within the RNA configured for the UE. This scheme allows the core network equipment to exchange the local RAN node identifiers of the base stations between each other. This enables the two base stations to obtain each other's local RAN node identifiers even if they lack an Xn interface or the Xn interface is faulty. Upon receiving an I-RNTI sent by the UE, the core network equipment can identify the base station corresponding to the local RAN node identifier in the I-RNTI and request the UE's context from that base station. Based on this scheme, the UE can enter the connected state from an inactive state without going through the RRC connection establishment procedure, thereby avoiding frequent connection rebuilds, reducing the latency and overhead of the UE entering the connected state, and improving network efficiency and user experience.

[0146] The communication method provided in this application can be applied to fourth-generation (4G) communication systems, such as long-term evolution (LTE) systems, as well as 5G communication systems, such as 5G new radio (NR) systems, or various communication systems evolving after 5G, such as future communication systems. The method provided in this application can also be applied to Bluetooth systems, wireless fidelity (Wi-Fi) systems, Internet of Things (IoT) systems, long-range radio (LoRa) systems, or vehicle-to-everything (V2X) systems. The method provided in this application can be applied to terrestrial networks (TN), non-terrestrial networks (NTN), or converged communication systems of terrestrial and non-terrestrial networks. NTN can refer to a network device located at a high altitude relative to the user equipment (UE). A typical application scenario in NTN is a satellite communication system.

[0147] Please refer to Figure 2A, which is a schematic diagram of an application scenario according to an embodiment of this application. Figure 2A includes a terminal device, a first access network device, a second access network device, and a core network device. As shown in Figure 2A, the first access network device and the second access network device cannot communicate through a first interface. The inability of the first access network device and the second access network device to communicate through the first interface can be understood as the first access network device and the second access network device lacking a first interface, or the first interface between the first access network device and the second access network device being faulty or unavailable. Both the first access network device and the second access network device communicate with the core network device. That is, the core network device connected to the first access network device and the second access network device is the same. The terminal device can communicate with the first access network device or the second access network device through a wireless air interface. For example, the communication system shown in Figure 2A can be a 5G NR communication system, the first interface can be an Xn interface, the first access network device and the second access network device can communicate with the core network device through an NG interface, and the wireless air interface can be a Uu interface.

[0148] Please refer to Figure 2B, which is a schematic diagram of another application scenario of this application embodiment. Figure 2B shows a cross-core network application scenario, including a terminal device, a first access network device, a second access network device, a first core network device, and a second core network device. As shown in Figure 2B, the first access network device and the second access network device cannot communicate with each other through the first interface. The first access network device can communicate with the first core network device, and the second access network device can communicate with the second core network device. That is, the core network devices connected to the first access network device and the second access network device are different. The first core network device and the second core network device can communicate with each other. The terminal device can communicate with the first access network device or the second access network device through a wireless air interface.

[0149] For the terminal device in Figure 2A or Figure 2B, the terminal device can move between the cells provided by the two access network devices. When moving to one of the access network devices (e.g., camping on a cell provided by that access network device), the terminal device can communicate with that access network device. Alternatively, the terminal device may only move between different cells provided by one access network device; or the terminal device may move between cells provided by more access network devices, thus allowing for the presence of more access network devices. Figure 2A or Figure 2B illustrates the presence of two access network devices. The method provided in this application embodiment can be executed by access network devices and core network devices. Figure 2A or Figure 2B is merely illustrative; the number of devices may be fewer or more.

[0150] The method provided in the embodiments of this application is described below with reference to the accompanying drawings. The method in the embodiments of this application can be executed by a first access network device, a second access network device, and a core network device. Optionally, the core network device may include a first core network device and a second core network device. The first core network device can communicate with the first access network device, and the second core network device can communicate with the second access network device. The various embodiments herein can be applied to the scenarios shown in Figure 2A or Figure 2B. For example, the terminal device described in the various embodiments herein can be the terminal device shown in Figure 2A or Figure 2B; the first access network device described in the various embodiments herein can be the first access network device shown in Figure 2A or Figure 2B; the second access network device described in the various embodiments herein can be the second access network device shown in Figure 2A or Figure 2B; the core network device described in the various embodiments herein (equivalent to the same as the first core network device and the second core network device) can be the core network device shown in Figure 2A; the first core network device described in the various embodiments herein can be the first core network device shown in Figure 2B; and the second core network device described in the various embodiments herein can be the second core network device shown in Figure 2B (equivalent to different from the first core network device and the second core network device).

[0151] In various embodiments of this application, both the "local RAN node identifier" and the "global RAN node identifier" can serve as the identifier of the base station. However, the local RAN node identifier can be understood as having specificity or limitations, and can serve as the identifier of the base station in a specific scenario. The global RAN node identifier, on the other hand, has universality or applicability and is the unique identifier of the base station. When sending information to a specific base station, the global RAN node identifier of that base station must be specified. For example, the local RAN node identifier can be used as the identifier of the base station in I-RNTI, and the global RAN node identifier can refer to the gNB ID of the base station. In various embodiments of this application, both the "first identifier" and the "second identifier" of the UE can serve as the identifier of the UE, but the source, function, or scope of the first and second identifiers are different. The different sources of the first and second identifiers can include different network devices that assign the first and second identifiers to the UE. For example, the first identifier is assigned by the base station, while the second identifier is assigned by the core network. As an example, the first identifier can be, for example, the NG-RAN UE NGAP ID, and the second identifier can be the AMF UE NGAP ID. In the accompanying drawings corresponding to various embodiments of this application, all steps indicated by dashed lines are optional steps.

[0152] This application provides a communication method in which an access network device can inform other access network devices of its supported local RAN node identifiers through the core network device. Please refer to Figure 3, which is a flowchart of the method.

[0153] Step 301: The second access network device sends first information to the core network device. Correspondingly, the core network device receives the first information. The first information includes the local RAN node identifier of the second access network device.

[0154] The second access network device can send the first information to the core network device through the interface between the access network device and the core network device. For example, in a 5G NR communication system, the interface between the access network device and the core network device is an NG interface, meaning the second access network device can send the first information to the core network device through the NG interface. It should be understood that in other communication systems, the interface between the access network device and the core network device can be any interface specific to that communication system, and the second access network device can also send the first information to the core network device through the corresponding interface.

[0155] In this embodiment, the first information is information sent from the core network device to the first access network device, meaning the first information ultimately needs to be sent to the first access network device. In some scenarios, the second access network device and the first access network device may not be able to communicate through the first interface, meaning the second access network device cannot directly send the first information to the first access network device through the first interface. Therefore, the second access network device can first send the first information to the core network device, and then the core network device will send the first information to the first access network device. The inability of the first access network device and the second access network device to communicate through the first interface can be understood as the first access network device and the second access network device lacking a first interface, or the first access network device and the second access network device possessing a first interface, but that first interface is unavailable, for example, due to a first interface failure. The first interface is the interface between access network devices. The first interface can be understood as a specific type of interface, i.e., an interface between one access network device and another, rather than an interface between specific access network devices. For example, in a 5G NR communication system, access network devices can communicate through the Xn interface, meaning the first interface can be the Xn interface. The first access network device and the second access network device cannot communicate through the Xn interface, or this can be described as the first access network device and the second access network device lacking Xn connectivity. For example, the first access network device and the second access network device do not have an Xn interface, or the Xn interface between the first access network device and the second access network device is unavailable.

[0156] This can be understood as the first access network device and the second access network device exchanging local RAN node identifiers via the NG interface. This can serve as a supplementary method to exchanging local RAN node identifiers via the Xn interface, allowing one access network device to send its local RAN node identifier to another. For example, if the first and second access network devices cannot exchange local RAN node identifiers via the Xn interface, the NG interface can be used to successfully send the local RAN node identifier. Furthermore, even if the first and second access network devices can exchange local RAN node identifiers via the Xn interface, they can still exchange them via the NG interface; there are no specific restrictions.

[0157] In some embodiments, any access network devices can exchange their local RAN node identifiers through the core network device. That is, the second access network device can be any access network device, meaning any access network device can trigger the execution to inform other access network devices of its local RAN node identifier using the method provided in this application embodiment. The second access network device can determine which access network devices need to send its local RAN node identifier, i.e., determine which access network devices to which it needs to send the local RAN node identifier. Optionally, the core network device can send information instructing other access network devices to the second access network device, so the second access network device can decide to send its local RAN node identifier to one or more access network devices based on this information sent by the core network. These one or more access network devices include the first access network device.

[0158] In other embodiments, the second access network device is the last serving node (i.e., the anchor base station) when the first terminal device is in a connected state. When the RNA of the first terminal device has been determined, but some access network devices within the RNA cannot communicate with the second access network device through the first interface, the second access network device can exchange its local RAN node identifier with these access network devices through the core network device. It can be understood that the method flow of this application embodiment can be triggered by the anchor base station to inform its own local RAN node identifier to other access network devices within the RNA that cannot communicate through the first interface using the method provided in this application embodiment. Optionally, the second access network device can send the first information to the core network device before, simultaneously with, or after sending the RNA to the first terminal device.

[0159] In the application scenario shown in Figure 2A, the first access network device and the second access network device can communicate with the same core network device. This is equivalent to the first core network device corresponding to the first access network device and the second core network device corresponding to the second access network device being the same device. For example, taking the core network device as AMF, both the first access network device and the second access network device correspond to AMF1. This is equivalent to the first terminal device being provided with services by AMF1 when it is in the connected state before entering the inactive state. Even when the first terminal device is moving, it is still provided with services by AMF1. Therefore, the first access network device and the second access network device can achieve local RAN node identification interaction through AMF1.

[0160] In the application scenario shown in Figure 2B, the first access network device and the second access network device correspond to different core network devices. The first access network device corresponds to the first core network device, and the second access network device corresponds to the second core network device. Therefore, the second access network device sending the first information to the core network device can also be described as the second access network device sending the first information to the second core network device. For example, taking the core network device as an AMF, the first access network device corresponds to AMF1, and the second access network device corresponds to AMF2. If the second access network device is the anchor base station of the first terminal device, then when the first terminal device is in the connected state before entering the inactive state, it is provided with services by AMF2. When the second access network device wants to send the local RAN node identifier to the first access network device, because it is an inter-AMF scenario, the second access network device can first send the first information to the second core network device, the second core network device can then send the first information to the first core network device, and then the first core network device sends the first information to the first access network device.

[0161] Optionally, if the second access network device supports multiple local RAN node identifiers, the first information may include a list of local RAN node identifiers, which may include some or all of the local RAN node identifiers supported by the second access network device.

[0162] Optionally, in addition to including the local RAN node identifier, the first information may also indicate (or include) one or more of the following:

[0163] (1) The first information can indicate the length of the local RAN node identifier. In one implementation, the first information indicates the length of the local RAN node identifier in such a way that the length of the local RAN node identifier includes the length of the local RAN node identifier. In another implementation, as previously described, the I-RNTI can include two formats. In the second format, the first part of the I-RNTI can indicate the length of the local RAN node identifier. Therefore, the way the first information indicates the length of the local RAN node identifier can be the same as the way the first part of the I-RNTI indicates the length of the local RAN node identifier. That is, when the I-RNTI allocated by the second access network device is a full I-RNTI, the length of the local RAN node identifier can be indicated by 2 bits, i.e., the first information can include these 2 bits; or, when the I-RNTI allocated by the second access network device is a short I-RNTI, the length of the local RAN node identifier can be indicated by 1 bit, i.e., the first information can include these 1 bit. In some scenarios, the local RAN node identifier and the information indicating the length of the local RAN node identifier can be considered as a whole, i.e., the first information can be understood as including the local RAN node identifier, i.e., the first information already contains the local RAN node identifier and the information indicating the length of the local RAN node identifier. In other scenarios, it can also be understood that the local RAN node identifier and the information indicating the length of the local RAN node identifier are independent of each other, and the first information includes the local RAN node identifier, that is, the first information includes the local RAN node identifier.

[0164] (2) Global RAN node identifier of the first access network device. For example, the first information may include the global RAN node identifier of the first access network device. Indicating the global RAN node identifier of the first access network device through the first information can help the core network device (or the second core network device) identify which access network devices(s) the first information needs to be sent to. Optionally, if there are multiple access network devices that need to send local RAN node identifiers, the first information may include the global RAN node identifiers of these multiple access network devices. For example, the first information may include a list of global RAN node identifiers, which includes some or all of the global RAN node identifiers of the multiple access network devices. These multiple access network devices may include the first access network device.

[0165] As an example, the global RAN node identifier can be either a gNB ID or a global gNB ID. The first access network device is the final recipient of the local RAN node identifier and can be referred to as the target gNB. Alternatively, when a first terminal device moves to the coverage area of ​​the first access network device and is inactive, if the first terminal device needs to access the network, it will send a request message to the first access network device to restore the RRC connection. This first access network device is the serving gNB at the time of access by the first terminal device. In this case, the global RAN node identifier of the first access network device can also be referred to as the serving gNB ID or the target gNB ID, meaning the first information can include either the target gNB ID or the serving gNB ID. If there are multiple access network devices that need to send local RAN node identifiers, the global RAN node identifier of these multiple access network devices is the target gNB ID, and the first information can include a list of target gNB IDs.

[0166] (3) The global RAN node identifier of the second access network device. For example, the first information may include the global RAN node identifier of the second access network device. By indicating the global RAN node identifier of the second access network device through the first information, the first access network device can know which access network device sent the first information, and thus know which access network device the local RAN node identifier contained in the first information corresponds to.

[0167] As an example, the global RAN node identifier can be either a gNB ID or a global gNB ID. The second access network device is the sender of the local RAN node identifier; this second access network device can be called the source gNB. Alternatively, the second access network device can be the last serving node of the first terminal device in the connected state when it is inactive, and it stores the context of the first terminal device; that is, this second access network device can be called the source gNB of the first terminal device. Therefore, the global RAN node identifier of the first access network device can also be called the source gNB ID, meaning the first information can include the source gNB ID.

[0168] (4) Tracking Area Code (TA) of the first access network device. For example, the first information may include the tracking area code (TAC) or tracking area code (TAI) of the first access network device. The TAI is used to identify the TA and may consist of the mobile country code (MCC), the mobile network code (MNC), and the TAC. By indicating the TA of the first access network device in the first information, the core network device can determine the core network device corresponding to the first access network device, and thus successfully forward the first information to the first access network device. For example, if the core network device corresponding to the second access network device is AMF2, after AMF2 receives the first information, it can determine that the core network device corresponding to the first access network device is AMF1 based on the TA of the first access network device, and then AMF2 can send the first information to the first access network device through AMF1.

[0169] If the second access network device needs to send local RAN node identifiers to multiple access network devices, then the first information can indicate the TA of the multiple access network devices. For example, the first information may include a TAC list or a TAI list. The TAC list may include the TACs of one or more access network devices among the multiple access network devices, and the TAI list may include the TAIs of one or more access network devices among the multiple access network devices.

[0170] (5) The TA of the second access network device. For example, the first information may include the TAC or TAI of the TA of the second access network device. By indicating the TA of the second access network device in the first information, the core network device can be helped to determine the core network device corresponding to the second access network device. Thus, when the first access network device replies with response information, the response information can be successfully forwarded to the second access network device. For example, if the core network device corresponding to the first access network device is AMF1 and the core network device corresponding to the second access network device is AMF2, after the first access network device replies with response information to AMF1, AMF1 can determine that the core network device corresponding to the second access network device is AMF2 based on the TA of the second access network device. Then, AMF1 can send the response information to the second access network device through AMF2.

[0171] In addition to its own information, the second access network device can also provide the first access network device with information about other access network devices (i.e., access network devices other than the first and second access network devices). This information may include global RAN node identifiers and local RAN node identifiers. This helps to propagate the global RAN node identifiers and local RAN node identifiers of the access network devices in the network, so that these information can be used directly when needed. For example, the first information may also include the following information (6):

[0172] (6) Global RAN node identifiers and local RAN node identifiers of other access network devices adjacent to the second access network device. For example, access network device 1 and access network device 2 are adjacent nodes of the second access network device, so the first information can also indicate the global RAN node identifier and local RAN node identifier of access network device 1, and the global RAN node identifier and local RAN node identifier of access network device 2. For example, if access network device 1 and the second access network device can communicate through the Xn interface, then the second access network device can directly obtain the global RAN node identifier and local RAN node identifier of access network device 1 through the Xn interface. As another example, if access network device 2 and the second access network device cannot communicate through the Xn interface, for example, if there is no Xn interface between access network device 2 and the second access network device, the second access network device can obtain the global RAN node identifier and local RAN node identifier of access network device 2 through the core network device.

[0173] (7) The deletion of the local RAN node identifier of the second access network device: When the first information includes the deletion of the local RAN node identifier of the second access network device, it can be understood that the second access network device indicates the deletion of the local RAN node identifier. If the first information includes the deletion of the local RAN node identifier of the second access network device, the first information can be included in the RAN configuration update request message or the uplink RAN ​​configuration transfer message. Optionally, the number of local RAN node identifiers to be deleted can be one or more. Optionally, the deleted local RAN node identifier and the local RAN node identifier currently used by the second access network device can be sent separately, or they can be included in the first information and sent together. By indicating the deletion of the local RAN node identifier of the second access network device, the first access network device can be notified to stop using the identifier so that the first access network device can update in a timely manner.

[0174] Optionally, if the core network devices corresponding to the first access network device and the second access network device are the same, the first information may not indicate (4) and (5) of the above information. Alternatively, in cross-core network scenarios (such as inter-AMF scenarios), the first information may indicate (4) and (5) of the above information.

[0175] Optionally, the first access network device can send the first information to the core network device through the interface between the first access network device and the core network device, or the first information can be included in the interface message sent by the first access network device to the core network device. For example, if the core network device is an AMF, the interface between the first access network device and the AMF can be an NG interface. The first access network device can send the first information to the AMF through an NG setup request message, a RAN configuration update request message, or an uplink RAN ​​configuration transfer message. Alternatively, it can also send the first information to the core network device through other interfaces or messages; there are no specific restrictions.

[0176] Step 302: The core network device sends the first information to the first access network device. Correspondingly, the first access network device receives the first information.

[0177] If the core network devices corresponding to the first access network device and the second access network device are the same, the core network device can directly send the first information to the first access network device.

[0178] Optionally, if the core network devices corresponding to the first access network device and the second access network device are different (e.g., the first access network device corresponds to the first core network device, and the second access network device corresponds to the second core network device), then the second access network device can send first information to the second core network device, which in turn sends the first information to the first core network device, and the first core network device then sends information to the first access network device. For example, the first information can indicate the TA (Transmission Access Controller) of the first access network device. The second core network device can determine the first core network device based on the TA indicated by the first information and send the first information to the first core network device, which then sends the first information to the first access network device.

[0179] Optionally, the first information sent by the core network device to the first access network device may include part or all of the information included in the first information in step 301. That is, the first information sent by the core network device to the first access network device may include one or more of the following: the local RAN node identifier of the second access network device, information indicating the length of the local RAN node identifier of the second access network device, information indicating the TA of the second access network device, information indicating the TA of the first access network device, information indicating the global RAN node identifier of the first access network device, information indicating the global RAN node identifier of the second access network device, the global RAN node identifier and local RAN node identifier of other adjacent access network devices, or the deleted local RAN node identifier of the second access network device.

[0180] Optionally, after receiving the first information, the core network device can transparently transmit the first information, meaning it does not need to store it. For example, the first core network device can transparently transmit the first information to the second core network device, and the second core network device can transparently transmit the first information to the first access network device. Alternatively, the first core network device (which is equivalent to the core network device corresponding to the first and second access network devices) can transparently transmit the first information to the first access network device.

[0181] After receiving the first information, the first access network device may save some or all of the information included in the first information. For example, the first access network device may save the local RAN node identifier and the global RAN node identifier of the second access network device. In this way, the first access network device can subsequently determine the global RAN node identifier of the second access network device based on the local RAN node identifier of the second access network device. Alternatively, the first access network device may save the correspondence between the local RAN node identifier and the global RAN node identifier of the second access network device. In this way, the first access network device can subsequently determine the global RAN node identifier of the second access network device based on the correspondence.

[0182] Step 303: The first access network device sends second information to the core network device. Correspondingly, the core network device receives the second information. The second information includes the local RAN node identifier of the first access network device.

[0183] Optionally, the second information may be included in a response message to the first information. Alternatively, the second information may also be included in other messages besides the response message. For example, the second information may be included in a downlink RAN ​​configuration transfer message, without any specific limitation.

[0184] Optionally, in addition to including the local RAN node identifier of the first access network device, the second information may also include one or more of the following: information indicating the length of the local RAN node identifier of the first access network device, information indicating the TA of the second access network device, information indicating the TA of the first access network device, information indicating the global RAN node identifier of the first access network device, or information indicating the global RAN node identifier of the second access network device. For details on the above information, please refer to the description in step 301, which will not be repeated here. Optionally, similar to step 301, in addition to the local RAN node identifier of the first access network device, the local RAN node identifiers of other access network devices may also be provided to the second access network device. For example, the second information may also include the global RAN node identifiers and local RAN node identifiers of other adjacent access network devices of the first access network device. Optionally, the first access network device may also indicate the deletion of the local RAN node identifier of the first access network device to the second access network device. When the second information includes the deletion of the local RAN node identifier of the first access network device, it can be understood that the first access network device indicates the deletion of the local RAN node identifier. If the second information includes the local RAN node identifier of the first access network device to be deleted, the second information may be included in the RAN configuration update request message or the uplink RAN ​​configuration transfer message.

[0185] Step 304: The core network device sends the second information to the second access network device. Correspondingly, the first access network device receives the second information.

[0186] If the core network devices corresponding to the first access network device and the second access network device are the same, after the first access network device sends the second information to the core network device, the core network device can directly send the second information to the first access network device. If the core network devices corresponding to the first access network device and the second access network device are different, the first access network device can send the second information to the first core network device, the first core network device can send the second information to the second core network device, and then the second information is sent from the second core network device to the second core network device.

[0187] Through the above steps, access network devices can inform other access network devices of their local RAN node identifier and also learn the local RAN node identifiers of other access network devices. For example, a second access network device can receive second information from a first access network device to learn the local RAN node identifier of the first access network device. In this way, if the first access network device releases the second terminal device to an inactive state, the first access network device will store the context of the second terminal device. Then, when the second terminal device moves to the coverage area of ​​the second access network device, if the second terminal device requests the second access network device to restore the RRC connection, the second access network device can recognize that the context of the second terminal device is stored in the first access network device based on the previously learned local RAN node identifier, and thus request the first access network device to retrieve the context. This solves the problem that the second access network device cannot obtain the context from the first access network device because it cannot recognize the local RAN node identifier of the first access network device.

[0188] It should be understood that steps 303 and 304 are optional and can be omitted, and are therefore shown as dashed lines in Figure 3.

[0189] In some embodiments, the local RAN node identifiers of two access network devices may be identical. If the local RAN node identifiers of the first access network device and the second access network device are identical, then the local RAN node identifier of one of the access network devices can be updated. For example, after receiving the local RAN node identifier of the second access network device, the first access network device determines that the local RAN node identifier is the same as that of the first access network device. The first access network device can then update its own local RAN node identifier and send the updated local RAN node identifier to the second access network device. In other words, the local RAN node identifier included in the second information can be the updated local RAN node identifier. Alternatively, the first access network device may not update its own local RAN node identifier, while the second access network device, after receiving the local RAN node identifier of the first access network device, determines that the local RAN node identifier is the same as that of the second access network device. In this case, the second access network device can trigger a local RAN node identifier update process, meaning the second access network device can send a new local RAN node identifier to the first access network device again. Optionally, because after the local RAN node identifier is updated, the local RAN node identifier already configured in the I-RNTI may not be able to identify the corresponding access network device. For example, if the second access network device releases the third terminal device to an inactive state and configures an I-RNTI for the third terminal device, and the I-RNTI contains the local RAN node identifier of the second access network device, if the second access network device updates the local RAN node identifier and triggers the update process, then other access network devices will save the updated local RAN node identifier of the second access network device. This will make it impossible for other access network devices to know which access network device the local RAN node identifier in the I-RNTI belongs to when they receive the I-RNTI of the third terminal device, and thus they will be unable to obtain the context of the third terminal device. Therefore, optionally, whether the update is performed by the second access network device or the first access network device can be determined by whether the second access network device or the first access network device has configured I-RNTI. If the second access network device has configured I-RNTI for a terminal device, while the first access network device has not configured I-RNTI, then the first access network device can update the local RAN node identifier; or, if the first access network device has configured I-RNTI for a terminal device, while the second access network device has not configured I-RNTI, then the second access network device can update the local RAN node identifier.

[0190] Step 305: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request.

[0191] The second request may include the I-RNTI of the first terminal device. This second request is used to request network access, or in other words, to request the restoration of the RRC connection between the first terminal device and the network side. For example, the second request could be an RRC connection restoration request.

[0192] The first terminal device is in a connected state before entering the inactive state. For example, the last serving node when the first terminal device is in the connected state is the second access network device, meaning the second access network device is the last access network device that served the first terminal device before it entered the inactive state. The second access network device can configure RNA and I-RNTI for the first terminal device. The second access network device can send the RNA and I-RNTI to the first terminal device before or after the aforementioned steps. For example, the second access network device can send the RNA and I-RNTI to the first terminal device before or after step 301; there is no specific limitation.

[0193] Since the first access network device has already received the first information, which includes the local RAN node identifier of the second access network device, the first access network device can combine the first information to determine the global RAN node identifier of the second access network device. In other words, after receiving the I-RNTI from the first terminal device, the first access network device can determine the global RAN node identifier of the second access network device based on the local RAN node identifier in the I-RNTI and the first information. This can be understood as follows: based on the local RAN node identifier in the I-RNTI and the local RAN node identifier in the first information, the first access network device can determine that the I-RNTI was allocated by the second access network device, and therefore the context of the first terminal device is stored in the second access network device.

[0194] Step 306: The first access network device sends a first request to the core network device. Correspondingly, the core network device receives the first request. The first request is used to obtain the context of the first terminal device, and includes the global RAN node identifier of the second access network device.

[0195] Because there is no first interface between the first access network device and the second access network device, the core network device can still act as a relay to obtain the context of the first terminal device. If the core network devices corresponding to the first access network device and the second access network device are the same, then the core network device can directly request the context of the first terminal device from the second access network device. If the core network devices corresponding to the first access network device and the second access network device are different, such as the first access network device corresponding to the first core network device and the second access network device corresponding to the second core network device, then the first access network device can send a first request to the first core network device, and the first core network device can then request the context of the first terminal device from the second access network device through the second core network device based on the first request.

[0196] For example, the first request could be a retrieve UE context request. As an example, if the global RAN node identifier could be a gNB ID, then the retrieve UE context request could include the gNB ID of the second access network device.

[0197] For example, the first request may indicate the TA (Transmission Acquisition) of the second access network device. Thus, when the core network devices corresponding to the first and second access network devices are different, the first core network device can select the second core network device to send the information contained in the first request based on the TA of the second access network device in the first request. The second core network device then sends the information contained in the first request to the second access network device. Optionally, the first request may include the TAC (Transmission Acquisition Control) or TAI (Transmission Acquisition Information) of the first access network device.

[0198] Step 307: The core network device sends a fourth request to the second access network device. Correspondingly, the second access network device receives the fourth request. This fourth request is determined based on the first request. For example, the fourth request may include part or all of the content of the first request. In addition to the content included in the first request, it may also include other information. If the core network devices corresponding to the first and second access network devices are the same, the core network device can generate the fourth request based on the first request and send it to the second access network device. If the core network devices corresponding to the first and second access network devices are different, the core network device in step 307 can be the second core network device. This is equivalent to the second core network device having already received the content of the first request sent by the first core network device, generating the fourth request based on the content of the first request, and sending it to the second access network device.

[0199] Based on the above implementation, the second access network device can interact with the first access network device using the core network device to exchange local RAN node identifiers. This allows for successful interaction of local RAN node identifiers even when neither the second nor the first access network device possesses a first interface (such as the Xn interface). Consequently, when the first terminal device moves into the coverage area of ​​the first access network device, if the first terminal device requests to restore the RRC connection, the first access network device can successfully identify the local RAN node identifier in the first terminal device's I-RNTI. This allows the first access network device to request the context of the first terminal device from the second access network device via the core network device, without needing to enter the connected state through the RRC connection establishment process, resulting in lower latency and communication overhead.

[0200] This application also provides a communication method in which an access network device can inform a core network device of its supported local RAN node identifiers and global RAN node identifiers. The core network device stores these identifiers, and the access network device can then query the core network device for the global RAN node identifiers of other access network devices. Please refer to Figure 4, which is a flowchart of this method.

[0201] Step 401: The second access network device sends its local RAN node identifier to the core network device. Correspondingly, the core network device receives the local RAN node identifier of the second access network device and stores both the received local RAN node identifier and the global RAN node identifier. For example, the local RAN node identifier of the second access network device can be included in the NG setup request message.

[0202] Step 402: The core network device sends a response message to the second access network device. Correspondingly, the second access network device receives the response message. For example, this response message can be an NG setup response message.

[0203] Step 403: The first access network device sends its local RAN node identifier to the core network device. Correspondingly, the core network device receives the local RAN node identifier of the first access network device. For example, the local RAN node identifier of the first access network device may be included in the NG setup request message.

[0204] Step 404: The core network device sends a response message to the first access network device. Correspondingly, the first access network device receives the response message. For example, this response message can be an NG setup response message.

[0205] Step 405: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request. The second request includes the I-RNTI of the first terminal device, which was assigned to the first terminal device by the second access network device.

[0206] Step 406: The first access network device sends a query request to the core network device. Correspondingly, the core network device receives the query request. This query request is used to query the global RAN node identifier of the access network device corresponding to the local RAN node identifier in the I-RNTI of the first terminal device. Optionally, the query request may include the I-RNTI of the first terminal device or the local RAN node identifier in the I-RNTI. For example, the global RAN node identifier can be a gNB ID or a global gNB ID, and the query request can be called a gNB ID query request.

[0207] Step 407: The core network device returns a query response to the first access network device. Correspondingly, the first access network device receives the query response. The core network device can query the stored local RAN node identifiers based on the local RAN node identifier in the I-RNTI to determine that the local RAN node identifier in the I-RNTI corresponds to the second access network device, and then return the global RAN node identifier of the second access network device to the first access network device. That is, the query response may include the global RAN node identifier of the second access network device. For example, the global RAN node identifier can be a gNB ID or a global gNB ID, and the query response can be called a gNB ID query response. Optionally, the query response may include the I-RNTI of the first terminal device making the query request or the local RAN node identifier in that I-RNTI.

[0208] Step 408: The first access network device sends a first request to the core network device. Correspondingly, the core network device receives the first request. The first request is used to obtain the context of the first terminal device, and includes the global RAN node identifier of the second access network device.

[0209] Step 409: The core network device sends a fourth request to the second access network device. Correspondingly, the second access network device receives the fourth request. This fourth request is determined based on the first request.

[0210] Based on this implementation, the core network equipment can achieve unified management of local RAN node identifiers. When needed, access network equipment can query the core network equipment to obtain the corresponding global RAN node identifier, which can solve the problem of not being able to obtain context due to the inability to recognize the local RAN node identifier in I-RNTI. In addition, access network equipment does not need to store the local RAN node identifiers of other access network equipment, which can save storage resources of access network equipment.

[0211] For the steps shown in Figure 4, please refer to the description of the corresponding steps in the embodiment shown in Figure 3, which will not be repeated here.

[0212] This application also provides a communication method in which an access network device can inform a core network device of its supported local RAN node identifiers and global RAN node identifiers, which are then stored by the core network device and converted into global RAN node identifiers. Please refer to Figure 5, which is a flowchart of this method.

[0213] Step 501: The second access network device sends its local RAN node identifier and global RAN node identifier to the core network device. Correspondingly, the core network device receives and stores the received local RAN node identifier and global RAN node identifier. For example, the local RAN node identifier of the second access network device can be included in the NG setup request message.

[0214] Step 502: The core network device sends a response message to the second access network device. Correspondingly, the second access network device receives the response message. For example, this response message can be an NG setup response message.

[0215] Step 503: The first access network device sends its local RAN node identifier to the core network device. Correspondingly, the core network device receives the local RAN node identifier of the first access network device. For example, the local RAN node identifier of the first access network device may be included in the NG setup request message.

[0216] Step 504: The core network device sends a response message to the first access network device. Correspondingly, the first access network device receives the response message. For example, this response message can be an NG setup response message.

[0217] Step 505: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request. The second request includes the I-RNTI of the first terminal device, which was assigned to the first terminal device by the second access network device.

[0218] Step 506: The first access network device sends a context acquisition request to the core network device. Correspondingly, the core network device receives the context acquisition request. The context acquisition request is used to acquire the context of the first terminal device, and includes the I-RNTI of the first terminal device.

[0219] Step 507: The core network device queries the global RAN node identifier corresponding to the local RAN node identifier in the I-RNTI to determine the global RAN node identifier of the second access network device corresponding to the local RAN node identifier.

[0220] Step 508: The core network device sends a fourth request to the second access network device. Correspondingly, the second access network device receives the fourth request. This fourth request contains the global RAN node identifier of the second access network device.

[0221] Step 509: The second access network device sends the context of the first terminal device to the core network device. Correspondingly, the core network device receives the context of the first terminal device.

[0222] Step 510: The core network device sends a context acquisition response to the first access network device. Correspondingly, the first access network device receives the context acquisition response. This context acquisition response includes the context of the first terminal device.

[0223] The difference between the embodiment shown in Figure 4 and the embodiment shown in Figure 5 is that the first access network device can directly send a context acquisition request to the core network device. The core network device obtains the corresponding global RAN node identifier from the local RAN node identifier in the I-RNTI, and then continues to send a context acquisition request to the corresponding access network device. This not only solves the problem of not being able to obtain context due to the inability to recognize the local RAN node identifier in the I-RNTI, but also reduces the number of interactions between the core network device and the first access network device, thereby reducing communication overhead.

[0224] For the steps shown in Figure 5, please refer to the description of the corresponding steps in the embodiments shown in Figure 3 or Figure 4, which will not be repeated here.

[0225] In real-world scenarios, two access network devices within an RNA may correspond to different core network devices, i.e., the cross-core network device scenario mentioned above. This is because, from the core network device's perspective, an inactive terminal device is actually in a connected state within the core network. In other words, the access network device is aware that the terminal device is inactive, but the core network device is unaware and still assumes the terminal device is connected, continuing to provide core network services. In cross-core network device scenarios (such as inter-AMF), if a terminal device moves to the area served by another core network device, the new core network device should provide services to that terminal device. Therefore, core network device relocation is required, such as AMF relocation and UPF relocation. However, currently, no solution has been proposed for how to implement core network device relocation.

[0226] Therefore, in this embodiment of the application, in scenarios involving cross-core network devices (such as inter-AMF), in addition to triggering the process of obtaining the context from the access network device, the access network device can also trigger the migration process of the core network device, thereby transferring the context of the terminal device stored in the core network device from the core network device serving the terminal device to the new core network device. For example, the access network device can trigger the AMF migration process to transfer the context in the serving AMF of the terminal device to the new AMF, and realize the migration of the user plane, etc.

[0227] Please refer to Figure 6, which is another flowchart illustrating the method provided in this application embodiment. This method allows the first access network device to trigger migration on the core network side, that is, the new serving base station of the first terminal device triggers the migration on the core network side. As shown in Figure 6, the process includes the following steps. In the following text, the first access network device and the second access network device correspond to different core network devices; the first access network device corresponds to the first core network device, and the second core network device corresponds to the second core network device. For ease of description, the following description uses the AMF (Advanced Management Function) as an example, with the first core network device referred to as the first AMF and the second core network device referred to as the second AMF.

[0228] Step 601: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request.

[0229] The second request is used to request the restoration of the RRC connection, and the second request may include the I-RNTI of the first terminal device. For example, the second request may be an RRC connection restoration request. The first access network device can obtain the local RAN node identifier from the I-RNTI, determine the global RAN node identifier of the second access network device corresponding to the local RAN node identifier, and determine the TA information of the second access network device, such as the TAC (TAC list) or TAI (or TAI list) of the second access network device.

[0230] Step 602: The first access network device sends a first request to the first AMF. Correspondingly, the first AMF receives the first request.

[0231] The first request is used to request the context of the first terminal device. The first request includes the global RAN node identifier of the second access network device. The first request can also be called a context request message. Optionally, the first request can be a retrieve UE context request message or an uplink relay XnAP interface message (UL relay XnAP message).

[0232] Optionally, in addition to the global RAN node identifier of the second access network device, the first request may also include one or more of the following:

[0233] (1) Part or all of the information in the second request. For example, the retrieve UE context request can be used as a container to carry part or all of the information contained in the second request. This container can also be called the retrieve UE context request container. For example, the first request may include the resume MAC-I or short recovery complete message authentication code, I-RNTI, RRC recovery reason or new cell ID from the second request.

[0234] (2) Global RAN Node Identifier of the First Access Network Device. For example, the global RAN Node Identifier of the first access network device may be the gNB ID of the first access network device. The global RAN Node Identifier of the first access network device serves as the identifier of the sender of the first request, indicating that the first request was sent by the first access network device. This helps the second access network device to know that it needs to send to the first access network device when returning the context of the first terminal device.

[0235] (3) A first identifier for the first terminal device, which is used for the second interface, which is the interface between the first access network device and the first AMF. For example, the second interface may refer to the NG interface between the first access network device and the first AMF, and the first identifier may be the NG-RAN UE NGAP ID. When the first terminal device communicates with the first access network device, the first access network device will assign a first identifier to the first terminal device.

[0236] The first identifier can be carried when the first request belongs to UE-associated signaling. If the first request does not belong to UE-associated signaling, the first request may not contain the first identifier.

[0237] (4) Instructing the TA of the first access network device. For example, the first request may include the TAC or TAI of the TA of the first access network device.

[0238] (5) Instructing the TA of the second access network device. For example, the first request may include the TAC or TAI of the TA of the second access network device.

[0239] Step 603: The first AMF sends an eighth request to the second AMF. Correspondingly, the second AMF receives the eighth request. The eighth request is determined based on the first request and may include some or all of the information from the first request. The eighth request is used to request the context of the first terminal device. In some scenarios, the first AMF may transparently transmit the first request, meaning the eighth request is the same as the first request.

[0240] The first AMF can determine the second AMF based on the TA information indicating the second access network device in the first request, and then send an eighth request to the second AMF to request the context of the first terminal device.

[0241] Step 604: The second AMF sends a fourth request to the second access network device. Correspondingly, the second access network device receives the fourth request. The fourth request is determined based on the eighth request and may include some or all of the information from the eighth request. The fourth request is used to request the context of the first terminal device; the fourth request can also be called a context request message.

[0242] Optionally, the eighth or fourth request may include one or more of the following:

[0243] (1) A third identifier of the first terminal device, wherein the third identifier is assigned to the first terminal device by the first AMF corresponding to the first access network device, and the third identifier may be, for example, the AMF UE NGAP ID. Optionally, if the request belongs to UE-associated signaling, the request may include the third identifier of the first terminal device.

[0244] (2) Global RAN Node Identifier of the Second Access Network Device. It should be understood that the purpose of the eighth request or the fourth request is to request the second access network device to obtain the context of the first terminal device. Therefore, for the eighth request or the fourth request, the second access network device is the target base station of the request. The global RAN node identifier of the second access network device can also be called the target gNB ID, which can be used for routing from the first AMF or the second AMF to the second access network device.

[0245] (3) Global RAN Node Identifier of the First Access Network Device. It should be understood that the purpose of the eighth request or the fourth request is to request the second access network device to obtain the context of the first terminal device. Therefore, for the eighth request or the fourth request, the first access network device is the source base station of the request. The global RAN node identifier of the first access network device can also be called the source gNB ID, which can be used by the second access network device to know which access network device to send the context to.

[0246] (4) Information indicating the TA of the first access network device. For example, the first request may include the TAC or TAI of the TA of the first access network device. By indicating the TA of the first access network device, the second AMF can determine, upon returning the context, that the context needs to be sent to the first AMF that supports the TA.

[0247] (5) Information indicating the TA of the second access network device. For example, the first request may include the TAC or TAI of the TA of the second access network device. By indicating the TA of the first access network device, the first AMF can determine whether the request needs to be sent to the second AMF that supports the TA.

[0248] (6)retrieve UE context request container.

[0249] Step 605: The second access network device sends a first response to the second AMF. Correspondingly, the second AMF receives the first response.

[0250] After receiving the fourth request, the second access network device can perform verification based on the information in the fourth request. If the verification is successful, it can return the first response. For example, the second access network device can perform verification based on the resume MAC-I in the fourth request. If the MAC-I verification is successful, it can return the first response. The first response can be included in or can be a context response message. For example, the context response message can be a retrieve UE context response or a UL relay XnAP message.

[0251] Optionally, the first response may include one or more of the following:

[0252] (1) The first identifier of the first terminal device. For example, the first identifier is the NG-RAN UE NGAP ID. If the first response is included in a message belonging to UE-associated signaling, the first identifier of the first terminal device may be carried.

[0253] (2) Information indicating the TA of the first access network device. For example, the first request may include the TAC or TAI of the TA of the first access network device. This helps the second AMF to route to the first AMF corresponding to the first access network device.

[0254] (3) Information indicating the TA of the second access network device. For example, the first request may include the TAC or TAI of the TA of the second access network device.

[0255] (4) Context of the first terminal device. Here, the context of the first terminal device refers to the context stored in the second access network device, which can be called the air interface context or RAN-related context, etc. For example, a retrieve UE context response can be used as a container to include the context of the first terminal device; this container can also be called a retrieve UE context response container. Optionally, the container may include a second identifier of the first terminal device. This second identifier is used for a third interface, which is the interface between the second access network device and the second core network device. The second core network device is the core network device that serves the first terminal device. For example, the third interface is the interface between the second access network device and the second AMF, which provides services to the first terminal device. For example, the second identifier may be the AMF UE NGAP ID. The second AMF may be called the serving AMF of the first terminal device, and the AMF UE NGAP ID is assigned to the serving AMF of the first terminal device. Optionally, the container may also include information indicating the TA of the second access network device, such as the TAC or TAI of the second access network device.

[0256] Step 606: The second AMF sends a first response to the first AMF.

[0257] Step 607: The first AMF sends a first response to the first access network device. Correspondingly, the first access network device receives the first response. For example, the first AMF can send the first response to the first access network device via a DL relay XnAP message.

[0258] The first response includes the context of the first terminal device and / or the second identifier. Optionally, the first response may also include one or more of the steps (2) to (4) included in the first response above.

[0259] Step 608: The first access network device sends a third request to the first AMF. Accordingly, the first AMF receives the third request.

[0260] In other words, the migration process of a core network device (such as an AMF) can be triggered by the first access network device. The third request is used to request a change of core network device (such as an AMF) to serve the first terminal device, or in other words, the third request is used to trigger the migration of the core network device (such as an AMF). For example, the third request could be a path switch request or other messages.

[0261] Optionally, the third request may include (or indicate) one or more of the following:

[0262] (1) A second identifier of the first terminal device. This second identifier may be, for example, the AMF UE NGAP ID. This second identifier can be used to look up the context of the first terminal device in serving the AMF.

[0263] (2) The identifier of the second AMF. For example, the identifier can be a globally unique AMF ID (GUAMI) of the second AMF. The identifier of the second AMF can be used by the first AMF to find the AMF serving the first terminal device (i.e., the second AMF), so as to obtain the context of the first terminal device (the context here refers to the context on the core network side) from the second AMF and complete the UPF handover.

[0264] (3) Information indicating the TA of the second access network device. For example, the TAI or TAC of the second access network device. This information indicating the TA can also help the first AMF determine the AMF serving the first terminal device.

[0265] Step 609: The first AMF sends a ninth request to the second AMF based on the identifier of the second AMF carried in the third request. Correspondingly, the second AMF receives the ninth request. The ninth request is used to request the retrieval of the context of the first terminal device (here, context refers to the core network side context) stored in the second AMF. The ninth request may include a second identifier of the first terminal device, used to locate the context of the first terminal device in the second AMF.

[0266] Step 610: The second AMF returns a response message to the first AMF. Accordingly, the first AMF receives the response message. This response message is in response to the third request.

[0267] Step 611: The first AMF sends a response message to the first access network device. Correspondingly, the first access network device receives the response message.

[0268] Optionally, the second AMF may also carry a non-access stratum protocol data unit (NAS-PDU) in the response message. This NAS-PDU may include a system temporary mobile subscriber identity (S-TMSI). The S-TMSI, also known as 5G-S-TMSI in 5G, is used by the core network to paging UEs in an idle state. The S-TMSI is a temporary identifier used during the UE paging process to identify the UE within the network. The S-TMSI is generated by the core network and assigned to the UE, and typically changes when the UE's state is updated.

[0269] Subsequently, the first access network device can send a context release request to the first AMF, for example, by sending an NG UE context release message. The first AMF can then send a context release request to the second access network device via the second MAF, instructing the second access network device to release the context of the first terminal device. Alternatively, the first AMF can send a UE context release message to the second access network device via the second AMF, instructing the second access network device to release the context of the first terminal device.

[0270] Based on the above implementation, for scenarios involving cross-core network devices (such as inter-AMF), not only can the air interface context of the first terminal device be successfully obtained, but successful migration on the core network side can also be achieved. This reduces the probability of being unable to address core network devices. Furthermore, even if the RNA of the first terminal device contains access network devices that cannot communicate through the first interface (such as the Xn interface), the advantage of lower access latency due to the inactive state can still be maintained. Since there is no need to consider whether access network devices can communicate through the first interface, the RNA can be configured more flexibly.

[0271] Please refer to Figure 7, which is another flowchart illustrating the method provided in this application embodiment. This method allows a migration on the core network side to be triggered by a second access network device. As shown in Figure 7, the process includes the following steps. In the following text, the first access network device and the second access network device correspond to different core network devices; the first access network device corresponds to the first core network device, and the second core network device corresponds to the second core network device. For ease of description, the following description uses an AMF (Advanced Management Function) as an example, referring to the first core network device as the first AMF and the second core network device as the second AMF.

[0272] Step 701: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request.

[0273] Step 702: The first access network device sends a first request to the first AMF. Correspondingly, the first AMF receives the first request.

[0274] Step 703: The first AMF sends an eighth request to the second AMF. Correspondingly, the second AMF receives the eighth request. The eighth request is determined based on the first request and may include some or all of the information from the first request.

[0275] The first AMF can determine the second AMF based on the TA information indicating the second access network device in the first request, and then send an eighth request to the second AMF to request the context of the first terminal device.

[0276] Step 704: The second AMF sends a fourth request to the second access network device. Correspondingly, the second access network device receives the fourth request. The fourth request is determined based on the eighth request and may include some or all of the information from the eighth request. The fourth request is used to request the context of the first terminal device; the fourth request can also be called a context request message.

[0277] The process of steps 701 to 704 can be found in the description of steps 601 to 604 in Figure 6, and will not be repeated here.

[0278] Step 705: The second access network device sends a first response to the second AMF. Correspondingly, the second AMF receives the first response.

[0279] After receiving the fourth request, the second access network device can perform verification based on the information in the fourth request. If the verification is successful, the second access network device determines that an AMF migration is required based on the TA received from the first access network device, and then sends a first response. This first response indicates a failure to obtain the context of the first terminal device and / or the reason for the failure. For example, the first response indicates a failure to obtain the context, carrying a reason value for the failure, such as whether the AMF needs to be migrated or whether the AMF needs to be changed. The first response can be included in the context failure message, or it can be the context failure message itself. For example, the context response message can be a retrieve UE context failure message or a UL relay XnAP message.

[0280] Step 706: The second AMF sends a first response to the first AMF.

[0281] Step 707: The first AMF sends a first response to the first access network device. Correspondingly, the first access network device receives the first response. For example, the first AMF can send the first response to the first access network device via a DL relay XnAP message.

[0282] Step 708: The second access network device sends a fifth request to the second AMF. Correspondingly, the first AMF receives the third request.

[0283] In other words, the migration process of core network equipment (such as AMF) can be triggered by the second access network device. The fifth request is used to request the core network equipment (such as AMF) to be changed to serve the first terminal device, or in other words, the fifth request is used to trigger the migration of core network equipment (such as AMF). The fifth request may include the I-RNTI of the first terminal device. For example, the second access network device can implement AMF migration through an NG-based handover procedure, and the fifth request can be a handover required message or other messages. Taking the fifth request as a handover required message as an example, the handover required message includes a source to target container, which may include the I-RNTI of the first terminal device. Optionally, the source to target container may also include the reason for the handover or other indication information, such as the need for AMF migration or AMF change.

[0284] Step 709: The second AMF sends a sixth request to the first AMF. Accordingly, the first AMF receives the sixth request.

[0285] The fifth request may carry information about a new access network device (i.e., the first access network device), such as a TA (Transmission Action) indicating the first access network device. The second AMF can then determine the first AMF based on this TA and send a sixth request to the first AMF. The sixth request can be determined based on the fifth request; for example, the sixth request may include some or all of the information from the fifth request. In one example, the sixth request is the fifth request.

[0286] Step 710: The first AMF sends a seventh request to the first access network device. Correspondingly, the first access network device receives the seventh request. For example, the seventh request is a handover required message. The seventh request can be determined based on the sixth request; for example, the seventh request may include some or all of the information from the sixth request. In one example, the seventh request is the sixth request.

[0287] Optionally, the core network side may update the security key of the first terminal device and send it to the second access network device for storage. The second access network device may decide whether to send it to the first terminal device.

[0288] Step 711: After receiving the seventh request, the first access network device can associate the I-RNTI of the first terminal device with the I-RNTI in the seventh request, and then the first access network device sends a second response to the first AMF. The second response is used to confirm the handover; for example, the second response can be a handover request ack message, or it can be included in the handover request ack message. The second response can be used for data forwarding, but it may not contain the RRC reconfiguration container.

[0289] Step 712: The first AMF sends a second response to the second AMF.

[0290] Step 713: The second AMF sends a handover command to the second access network device. During the handover process, the context of the first terminal device stored in the second access network device will be transferred to the first access network device for storage. At the same time, the core network will also be migrated, that is, the context in the core network will also be transferred.

[0291] Step 714: After the handover is complete, the first access network device sends third information to the first terminal device. This third information may include, for example, an RRC connection recovery response instructing the first terminal device to restore the RRC connection state. Alternatively, this third information may include, for example, an RRC connection release message instructing the first terminal device to remain in the RRC inactive state.

[0292] Step 715: The first access network device sends a handover notification to the first AMF, so that the first AMF can notify the second AMF, and the second AMF can then send a command to the second access network device instructing the release of the context of the first terminal device.

[0293] Based on the above implementation, for scenarios involving cross-core network devices (such as inter-AMF), not only can the air interface context of the first terminal device be successfully obtained, but successful migration on the core network side can also be achieved. This reduces the probability of being unable to address core network devices. Furthermore, even if the RNA of the first terminal device contains access network devices that cannot communicate through the first interface (such as the Xn interface), the advantage of lower access latency due to the inactive state can still be maintained. Since there is no need to consider whether access network devices can communicate through the first interface, the RNA can be configured more flexibly.

[0294] Please refer to Figure 8A, which is another flowchart illustrating the method provided in this application embodiment. This method allows the access network device to indicate failure and a suitable reason value when the core network side cannot forward the request to obtain context in scenarios involving cross-core network or non-cross-core network connections. As shown in Figure 8A, the process includes the following steps.

[0295] Step 801a: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request.

[0296] Step 802a: The first access network device sends a first request to the first AMF. Correspondingly, the first AMF receives the first request.

[0297] The process of steps 801a to 802a can be found in the description of steps 601 to 602 in Figure 6, and will not be repeated here.

[0298] Step 803a: After the first AMF receives the first request, but cannot route it to a suitable AMF or forward the request to the second access network device, the first AMF sends a context acquisition failure message to the first access network device. This context acquisition failure message indicates that context acquisition has failed. For example, the message may include information indicating context acquisition failure, or it may include a reason value indicating the failure. For example, it may indicate AMF failure (i.e., no corresponding AMF can be found), or it may include information indicating that AMF migration is required, or it may include information indicating that the destination base station cannot be found, etc.

[0299] Step 804a: The first access network device sends an RRC connection establishment message to the first terminal device, thereby causing the first terminal device to fall back to the RRC connection establishment process and enter the connected state through the RRC connection establishment process.

[0300] Based on this implementation, a terminal device can enter the connected state by falling back to the RRC connection establishment process if it fails to acquire the context. Furthermore, by indicating the cause value, the access network device can understand the reason for the context acquisition failure, which can then be used for relevant key performance indicator (KPI) statistics, aiding in network optimization and management.

[0301] Please refer to Figure 8B, which is another flowchart illustrating the method provided in this application embodiment. Using this method, in both cross-core network and non-cross-core network scenarios, when the first terminal device fails to acquire its context, the second access network device can also indicate the failure to the first access network device and specify an appropriate reason value. As shown in Figure 8B, taking a non-cross-core network scenario as an example, the process includes the following steps.

[0302] Step 801b: The first terminal device sends a second request to the first access network device. Correspondingly, the first access network device receives the second request.

[0303] Step 802b: The first access network device sends a first request to the first AMF. Correspondingly, the first AMF receives the first request. In scenarios where the core network is not crossed, both the first and second access network devices can communicate with the first AMF.

[0304] The process of steps 801b to 802b can be found in the description of steps 301 to 302 in Figure 3, and will not be repeated here.

[0305] Step 803b: The first AMF sends a fourth request to the second access network device.

[0306] Step 804b: The second access network device sends a context acquisition failure message to the first AMF. This context acquisition failure message indicates that context acquisition failed. For example, the message may include information indicating the failure or a reason value indicating the failure. For example, the reason might be that the second access network device cannot find the context of the first terminal device, the I-RNTI of the first terminal device is invalid, or the information verification of the first terminal device failed.

[0307] Step 805b: The first AMF sends a context acquisition failure message to the second access network device.

[0308] Step 806b: The first access network device sends an RRC connection establishment message to the first terminal device, thereby causing the first terminal device to fall back to the RRC connection establishment process and enter the connected state through the RRC connection establishment process.

[0309] Based on this implementation, a terminal device can also enter the connected state by falling back to the RRC connection establishment process if context acquisition fails. Furthermore, by indicating the cause value, the access network device can understand the reason for the context acquisition failure, which can then be used for relevant KPI statistics to aid in network optimization and management.

[0310] Figure 9 shows a schematic diagram of the structure of an apparatus provided in an embodiment of this application. The communication device 900 can be a first access network device or a circuit system of a first access network device as shown in any of the embodiments shown in Figures 3 to 8B, used to implement the method corresponding to the first access network device in the above method embodiments. The communication device 900 can be a second access network device or a circuit system of a second access network device as shown in any of the embodiments shown in Figures 3 to 8B, used to implement the method corresponding to the second access network device in the above method embodiments. The communication device 900 can be a core network device (first core network device or second core network device) or a circuit system of a core network device as shown in any of the embodiments shown in Figures 3 to 8B, used to implement the method corresponding to the core network device (first core network device or second core network device) in the above method embodiments.

[0311] The communication device 900 includes at least one processor 901. The processor 901 can be used for internal processing within the device to implement certain control processing functions. Optionally, the processor 901 includes instructions. Optionally, the processor 901 can store data. Optionally, different processors can be independent devices, located in different physical locations, or located on different integrated circuits. Optionally, different processors can be integrated into one or more processors, for example, integrated on one or more integrated circuits.

[0312] Optionally, the communication device 900 includes one or more memories 903 for storing instructions. Optionally, the memories 903 may also store data. The processor and the memories may be separate or integrated together.

[0313] Optionally, the communication device 900 includes a communication line 902 and at least one communication interface 904. Since the memory 903, communication line 902, and communication interface 904 are all optional, they are all represented by dashed lines in Figure 9.

[0314] Optionally, the communication device 900 may further include a transceiver and / or an antenna. The transceiver can be used to send information to or receive information from other devices. The transceiver may be referred to as a transceiver unit, transceiver circuit, input / output interface, etc., and is used to realize the transmission and reception functions of the communication device 900 via the antenna. Optionally, the transceiver includes a transmitter and a receiver. For example, the transmitter can be used to generate a radio frequency (RF) signal from a baseband signal, and the receiver can be used to convert the RF signal back into a baseband signal.

[0315] The processor 901 may include a general-purpose central processing unit (CPU), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits for controlling the execution of programs according to the present application.

[0316] Communication line 902 may include a path for transmitting information between the aforementioned components.

[0317] Communication interface 904 uses any transceiver-like device for communicating with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), wired access network, etc.

[0318] Memory 903 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 903 may exist independently and be connected to processor 901 via communication line 902. Alternatively, memory 903 may be integrated with processor 901.

[0319] The memory 903 stores computer execution instructions for implementing the present application's solution, and its execution is controlled by the processor 901. The processor 901 executes the computer execution instructions stored in the memory 903, thereby implementing the steps performed by the first terminal device or the first network device in the embodiments shown in FIG4 or FIG6.

[0320] Optionally, the computer execution instructions in the embodiments of this application may also be referred to as application code, and the embodiments of this application do not specifically limit this.

[0321] In a specific implementation, as one example, processor 901 may include one or more CPUs, such as CPU0 and CPU1 in FIG9.

[0322] In a specific implementation, as one embodiment, the communication device 900 may include multiple processors, such as processors 901 and 905 in FIG. 9. Each of these processors may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0323] When the device shown in Figure 9 is a chip, such as the chip of a first terminal device or a first network device, or in other words, the first terminal device or the first network device is a chip, then the chip includes a processor 901 (and may also include a processor 905), a communication line 902, and a communication interface 904. Optionally, it may include a memory 903. Specifically, the communication interface 904 may be an input interface, pins, or circuits, etc. The memory 903 may be a register, cache, etc. The processor 901 and the processor 905 may be a general-purpose CPU, a microprocessor, an ASIC, or one or more integrated circuits for controlling the execution of a program that controls the communication method of any of the above embodiments.

[0324] This application embodiment can divide the device into functional modules according to the above method examples. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or software functional modules. The module division in this application embodiment is illustrative and only represents one logical functional division; in actual implementation, there may be other division methods. For example, when dividing the device into functional modules according to each function, Figure 10 is a schematic diagram of a device. This device 1000 can be the first access network device, second access network device, or core network device (first core network device or second core network device) involved in the above method embodiments, or it can be a chip in the first access network device, second access network device, or core network device (first core network device or second core network device). The device 1000 includes a processing unit 1002 and a transceiver unit 1001.

[0325] In one optional implementation, the device 1000 can be a first access network device, or the device 1000 can be a chip in the first access network device. The transceiver unit 1001 can be used to receive first information from the first core network device, the first information including the local RAN node identifier of the second access network device. The transceiver unit 1001 can also be used to send a first request to the core network device, the first request being used to obtain the context of the first terminal device, the first request including the global RAN node identifier of the second access network device, the global RAN node identifier of the second access network device being determined based on the first information. Wherein, the second access network device is the access network device that last served the first terminal device before the first terminal device entered the inactive state, that is, the second access network device is the anchor base station of the first terminal device, and the first terminal device is in the RRC inactive state.

[0326] As one implementation of this optional embodiment, the transceiver unit 1001 can also be used to receive a second request from the first terminal device, the second request being for requesting the restoration of the RRC active state, and the second request including the I-RNTI. The processing unit 1002 can be used to determine the global RAN node identifier of the second access network device based on the local RAN node identifier in the I-RNTI and the first information.

[0327] In another alternative implementation, the device 1000 can be a second access network device, or the device 1000 can be a chip in the second access network device. The transceiver unit 1001 is configured to send first information to the core network device, the first information including the local RAN node identifier of the second access network device. The transceiver unit 1001 is also configured to receive a fourth request from the core network device, the fourth request being used to obtain the context of the first terminal device, wherein the second access network device is the access network device that last served the first terminal device before it entered the inactive state, and the first terminal device is in the RRC inactive state.

[0328] In another alternative embodiment, the device 1000 may be a core network device (a first core network device or a second core network device), or the device 1000 may be a chip within the core network device (a first core network device or a second core network device). The transceiver unit 1001 is configured to send first information to the first access network device, the first information including the local RAN node identifier of the second access network device. The transceiver unit 1001 is further configured to receive a first request from the first access network device, the first request being used to obtain the context of the first terminal device, the first request including the global RAN node identifier of the second access network device, the global RAN node identifier corresponding to the local RAN node identifier, the second access network device being the access network device that last served the first terminal device before the first terminal device entered the inactive state, and the first terminal device being in the RRC inactive state. The transceiver unit 1001 is further configured to send a fourth request to the second access network device, the fourth request being determined based on the first request.

[0329] It should be understood that the device 1000 can be used to implement the steps performed by the first access network device, the second access network device, or the core network device (first core network device or second core network device) in the communication method of the embodiments of this application. The relevant features can be referred to the embodiments shown in Figures 3 to 8B above, and will not be repeated here.

[0330] Optionally, the functions / implementation processes of the transceiver unit 1001 and processing unit 1002 in Figure 10 can be implemented by the processor 901 in Figure 9 calling computer execution instructions stored in memory 903. Alternatively, the functions / implementation processes of the processing unit 1002 in Figure 10 can be implemented by the processor 901 in Figure 9 calling computer execution instructions stored in memory 903, and the functions / implementation processes of the transceiver unit 1001 in Figure 10 can be implemented by the communication interface 904 in Figure 9.

[0331] Optionally, when the device 1000 is a chip or circuit, the function / implementation process of the transceiver unit 1001 can also be implemented through pins or circuits, etc. Optionally, the transceiver unit 1001 may include a transmitting unit and / or a receiving unit, whereby the transmitting unit implements the transmitting function and the receiving unit implements the receiving function; or, the transceiver unit 1001 may be an integral module capable of implementing both transmitting and / or receiving functions. Optionally, the transceiver unit 1001 can be implemented using a transceiver.

[0332] This application also provides a computer-readable storage medium storing a computer program or instructions that, when executed, implement the methods performed by the first terminal device or the first network device in the aforementioned method embodiments. Thus, the functions described in the above embodiments can be implemented as software functional units and sold or used as independent products. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to it, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0333] This application also provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method executed by the first terminal device or the first network device in any of the foregoing method embodiments.

[0334] This application also provides a processing apparatus, including a processor and an interface; the processor is used to execute the methods performed by the first access network device, the second access network device, or the core network device (first core network device or second core network device) involved in any of the above method embodiments.

[0335] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0336] The various illustrative logic units and circuits described in the embodiments of this application can be implemented or operate the described functions using a general-purpose processor, digital signal processor (DSP), ASIC, field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof. The general-purpose processor can be a microprocessor; alternatively, it can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented using a combination of computing devices, such as a digital signal processor and a microprocessor, multiple microprocessors, one or more microprocessors combined with a digital signal processor core, or any other similar configuration.

[0337] The steps of the methods or algorithms described in the embodiments of this application can be directly embedded in hardware, software units executed by a processor, or a combination of both. The software units can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM), EEPROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium in the art. Exemplarily, the storage medium can be connected to the processor so that the processor can read information from the storage medium and write information to the storage medium. Optionally, the storage medium can also be integrated into the processor. The processor and storage medium can be disposed in an ASIC, which can be disposed in the various devices described above. Optionally, the processor and storage medium can also be disposed in different components of the various devices described above.

[0338] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0339] The contents of the various embodiments of this application can be referenced to each other. Unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced to each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0340] It is understood that in the embodiments of this application, the first access network device, the second access network device, or the core network device (first core network device or second core network device) may execute some or all of the steps in the embodiments of this application. These steps or operations are merely examples. In the embodiments of this application, other operations or variations of various operations may also be performed. Furthermore, the steps may be executed in different orders as presented in the embodiments of this application, and it is not necessary to execute all the operations in the embodiments of this application.

Claims

1. A communication method, characterized in that, The method, which applies to a first access network device or a chip of the first access network device, includes: Receive first information from a first core network device, the first information including the local radio access network (RAN) node identifier of a second access network device; A first request is sent to the first core network device. The first request is used to obtain the context of the first terminal device. The first request includes the global RAN node identifier of the second access network device. The global RAN node identifier of the second access network device is determined based on the first information. The second access network device is the access network device that last served the first terminal device before the first terminal device entered the inactive state. The first terminal device is in the Radio Resource Control (RRC) inactive state.

2. The method according to claim 1, characterized in that, The first access network device and the second access network device cannot communicate through the first interface, which is the interface between access network devices.

3. The method according to claim 1 or 2, characterized in that, The first information also indicates one or more of the following: The length of the local RAN node identifier of the second access network device; The global RAN node identifier of the first access network device; The global RAN node identifier of the second access network device; The tracking area of ​​the first access network device; or, The tracking area of ​​the second access network device.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: Receive a second request from the first terminal device, the second request being used to request the restoration of the RRC active state, the second request including the inactive wireless network temporary identifier I-RNTI; The global RAN node identifier of the second access network device is determined based on the local RAN node identifier in the I-RNTI and the first information.

5. The method according to claim 4, characterized in that, The first request also includes one or more of the following: The second request includes some or all of the information; The global RAN node identifier of the first access network device; The first identifier of the first terminal device is used for the second interface, and the second interface is the interface between the first access network device and the first core network device. Information indicating the tracking area of ​​the first access network device; or, Information indicating the tracking area of ​​the second access network device.

6. The method according to any one of claims 1 to 5, characterized in that, The method further includes: Send a second message to the first core network device, the second message including the local RAN node identifier of the first access network device.

7. The method according to any one of claims 1 to 6, characterized in that, The method further includes: Receive a first response from the first core network device; wherein, The first response includes the context of the first terminal device and / or a second identifier, the second identifier being used for a third interface, which is the interface between the second access network device and the second core network device, the second core network device being the core network device serving the first terminal device; or, The first response indicates a failure to obtain the context of the first terminal device and / or the reason for the failure.

8. The method according to claim 7, characterized in that, The first response includes the context of the first terminal device and / or a second identifier; the method further includes: A third request is sent to the first core network device, the third request being used to request a change of the core network device serving the first terminal device, the third request including one or more of the following: The second identifier of the first terminal device; The identifier of the second core network device; or, Information indicating the tracking area of ​​the second access network device.

9. A communication method, characterized in that, The method, which applies to a second access network device or a chip of the second access network device, includes: Send first information to the second core network device, the first information including the local RAN node identifier of the second access network device; A fourth request is received from the second core network device. The fourth request is used to obtain the context of the first terminal device. The fourth request includes the global RAN node identifier of the second access network device. The second access network device is the access network device that last served the first terminal device before the first terminal device entered the inactive state. The first terminal device is in the RRC inactive state.

10. The method according to claim 9, characterized in that, The first information also indicates one or more of the following: The length of the local RAN node identifier of the second access network device; The global RAN node identifier of the first access network device, the first information is used to indicate the local RAN node identifier of the second access network device to the first access network device; The global RAN node identifier of the second access network device; The tracking area of ​​the first access network device; or, The tracking area of ​​the second access network device.

11. The method according to claim 10, characterized in that, The first access network device and the second access network device cannot communicate through the first interface, which is the interface between access network devices.

12. The method according to any one of claims 9 to 11, characterized in that, The method further includes: Receive second information from the second core network device, the second information including the local RAN node identifier of the first access network device.

13. The method according to any one of claims 9 to 12, characterized in that, The method further includes: Send a first response to the second core network device; wherein, The first response includes the context of the first terminal device and / or a second identifier, the second identifier being used for a third interface, which is the interface between the second access network device and the second core network device, the second core network device being the core network device serving the first terminal device; or, The first response indicates that obtaining the context of the first terminal device failed and / or the reason for the failure, and the first core network device corresponding to the first access network device is different from the second core network device.

14. The method according to claim 13, characterized in that, The first response indicates a failure to obtain the context of the first terminal device and / or the reason for the failure; the method further includes: A fifth request is sent to the second core network device. The fifth request is used to request a change to a core network device that serves the first terminal device. The fifth request includes the I-RNTI of the first terminal device.

15. A communication method, characterized in that, The method, applied to a core network device or a chip of the core network device, includes: Send first information to the first access network device, the first information including the local RAN node identifier of the second access network device; A first request is received from the first access network device. The first request is used to obtain the context of the first terminal device. The first request includes the global RAN node identifier of the second access network device. The global RAN node identifier corresponds to the local RAN node identifier. The second access network device is the access network device that last served the first terminal device before the first terminal device entered the inactive state. The first terminal device is in the RRC inactive state. A fourth request is sent to the second access network device, the fourth request being determined based on the first request.

16. The method according to claim 15, characterized in that, The first access network device and the second access network device cannot communicate through the first interface, which is the interface between access network devices.

17. The method according to claim 15 or 16, characterized in that, The first information also indicates one or more of the following: The length of the local RAN node identifier of the second access network device; The global RAN node identifier of the first access network device; The global RAN node identifier of the second access network device; The tracking area of ​​the first access network device; or, The tracking area of ​​the second access network device.

18. The method according to any one of claims 15 to 17, characterized in that, The first request also includes one or more of the following: The second request contains part or all of the information, and the second request is used to request the restoration of the RRC active state; The global RAN node identifier of the first access network device; The first identifier of the first terminal device is used for the second interface, and the second interface is the interface between the first access network device and the core network device. Information indicating the tracking area of ​​the first access network device; or, Information indicating the tracking area of ​​the second access network device.

19. The method according to any one of claims 15 to 18, characterized in that, The method further includes: Receive second information from the first access network device, the second information including the local RAN node identifier of the first access network device; Send a second message to the second access network device, the second message including the local RAN node identifier of the first access network device.

20. The method according to any one of claims 15 to 19, characterized in that, The core network device is a first core network device, and the method further includes: The system receives a first response from a second core network device and sends the first response to the first access network device, wherein the second core network device is a core network device serving the first terminal device; wherein... The first response includes the context of the first terminal device and / or a second identifier, the second identifier being used for a third interface, the third interface being the interface between the second access network device and the second core network device; or, The first response indicates a failure to obtain the context of the first terminal device and / or the reason for the failure.

21. The method according to claim 20, characterized in that, The method further includes: A third request is received from the first access network device, the third request being used to request a change of the core network device serving the first terminal device, the third request including one or more of the following: The second identifier of the first terminal device; The identifier of the second core network device; or, Information indicating the tracking area of ​​the second access network device.

22. The method according to claim 20, characterized in that, The method further includes: Receive a sixth request from the second core network device, the sixth request being used to request a change to the core network device serving the first terminal device, the sixth request including the I-RNTI of the first terminal device; A seventh request is sent to the first access network device, the seventh request being determined based on the sixth request.

23. A communication device, characterized in that, The communication device includes a module for performing the method as described in any one of claims 1 to 8, or a module for performing the method as described in any one of claims 9 to 14, or a module for performing the method as described in any one of claims 15 to 22.

24. A communication device, characterized in that, The communication device includes a processor configured to perform the method as described in any one of claims 1 to 8, or the method as described in any one of claims 9 to 14, or the method as described in any one of claims 15 to 22.

25. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program that, when run on a computer, causes the method as described in any one of claims 1 to 8 to be performed, or causes the method as described in any one of claims 9 to 14 to be performed, or causes the method as described in any one of claims 15 to 22 to be performed.

26. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 8, or causes the computer to perform the method as described in any one of claims 9 to 14, or causes the computer to perform the method as described in any one of claims 15 to 22.

Images