Communication registration method, communication apparatus, and computer-readable storage medium

Abstract

A communication registration method, a communication apparatus, and a computer-readable storage medium, which enable an AIoT device to initiate a registration to access a network. The method may comprise: a second apparatus receiving a registration activation message from a first apparatus; and the second apparatus sending a first message to the first apparatus in response to the registration activation message, wherein the first message is used to request to register with a network, and a registration type that the first message requests to register with is determined on the basis of a stored registration status. In this way, the second apparatus initiates a registration to access a network, and the communication performance of the second apparatus is improved.

Description

Communication registration method, communication device and computer-readable storage medium

[0001] This application claims priority to Chinese Patent Application No. 202510337915.X, filed on March 20, 2025, entitled "Communication Registration Method, Communication Device and Computer-Readable Storage Medium", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communication technology, specifically to a communication registration method, a communication device, and a computer-readable storage medium. Background Technology

[0003] Given the wide range of applications for Ambient Internet of Things (AIoT) devices, the number of AIoT devices is expected to explode in the future. These massive numbers of AIoT devices typically need to register with the network to communicate and be managed. Registration is a crucial step in ensuring that devices can be identified, authenticated, and authorized by the network. However, considering that most AIoT devices have simple structures and limited capabilities, the current methods for terminal devices to initiate registration are not suitable for AIoT devices. Therefore, how AIoT devices can initiate registration is a pressing technical problem that needs to be solved. Summary of the Invention

[0004] This application provides a communication registration method, a communication device, and a computer-readable storage medium, which enables AIoT devices to initiate registration and network access, thereby improving the communication performance of AIoT devices.

[0005] In a first aspect, this application provides a communication registration method, which can be executed by a second device or by a device compatible with the second device, such as a processor, chip, or chip system. The method may include: receiving a registration activation message from a first device; responding to the registration activation message by sending a first message to the first device; the first message is used to request registration on a network, and the registration type requested in the first message is determined based on stored registration status.

[0006] Using the method provided in the first aspect, the second device responds to the registration activation message from the first device, determines the registration type of the requested registration based on the stored registration status, and initiates the corresponding type of registration by sending a first message, thereby enabling the second device to initiate registration and network access, improving the communication performance of the second device, and is suitable for scenarios where AIoT devices initiate registration.

[0007] In one possible implementation, if no network registration is made, the above registration type is initial registration; or, if network registration has been made and the periodic registration conditions are met, the above registration type is periodic registration; or, if network registration has been made and the mobility registration conditions are met, the above registration type is mobility registration.

[0008] In this method, when the second device determines that the registration status of the stored data is not registered on the network, it can effectively determine that the registration type initiated is initial registration; when the second device determines that the registration status of the stored data is already registered on the network, it can determine that the second device has already performed initial registration on the network, and further determine that the registration type initiated is periodic registration based on meeting the periodic registration conditions, or determine that the registration type initiated is mobile registration based on meeting the mobility registration conditions, thereby effectively initiating different types of registration.

[0009] In one possible implementation, the method further includes: determining that the periodic registration condition is met in response to the sum of the most recent successful registration time and the storage period duration being greater than or equal to a first time; wherein the first time is carried by the registration activation message, the first time is the time when the first device sends the registration activation message, and the period duration is the duration of the most recently configured periodic registration period.

[0010] In this method, after judging the registration status of the stored data, the second device determines that the periodic registration conditions are met based on the first time carried in the registration activation message, the time of the most recent successful registration, and the period duration, thereby effectively initiating the periodic registration process. The first time carried in the registration activation message is the time when the first device sends the registration activation message. For different second devices, the first time carried in the registration activation message broadcast by the first device at the same time is the same. The first device does not need to save, maintain, and broadcast different information for judging the periodic registration conditions for different second devices, which reduces the processing burden of the first device and the communication load between the first and second devices, and enables the second device to effectively initiate periodic registration. This method is suitable for registration scenarios of AIoT devices.

[0011] In one possible implementation, the method further includes: determining that the mobility registration conditions are met in response to the location indicated by the environmental IoT location information not belonging to the registration area indicated by the stored environmental IoT registration area information; wherein the environmental IoT location information is carried by the registration activation message, the environmental IoT location information is used to indicate the tracking area where the first device and / or the local terminal is located, and the environmental IoT registration area information is used to indicate the most recently assigned registration area.

[0012] In this method, after judging the stored registration status, the second device determines that the mobility registration conditions are met based on the environmental IoT location information carried in the registration activation message and the stored environmental IoT registration area information, thereby effectively initiating the mobility registration process. The environmental IoT location information carried in the registration activation message is acquired and maintained by the first device. For different second devices, the environmental IoT location information carried in the registration activation message broadcast by the first device at the same time is the same. The first device does not need to save, maintain, and broadcast different information for judging mobility registration conditions for different second devices, which reduces the processing burden of the first device and the communication load between the first and second devices, and enables the second device to effectively initiate mobility registration. This method is suitable for AIoT device registration scenarios.

[0013] Secondly, this application provides a communication registration method, which can be executed by a first device or by a device compatible with the first device, such as a processor, chip, or chip system. The method may include: sending a registration activation message to a second device; receiving a first message from the second device, the first message being used by the second device to request registration on the network, the registration type requested in the first message being determined based on the registration status stored in the second device.

[0014] Using the method provided in the second aspect, the first device sends a registration activation message to the second device, so that the second device responds to the registration activation message from the first device, determines the registration type of the requested registration based on the stored registration status, and initiates the registration of the corresponding registration type by sending a first message, which effectively realizes the second device initiating registration to join the network, and is applicable to scenarios where AIoT devices initiate registration.

[0015] In one possible implementation, the information carried by the registration activation message includes at least one of the following: a first time and environmental IoT location information; wherein, the first time is the time when the registration activation message is sent, and the environmental IoT location information is used to indicate the location of the local device and / or the second device.

[0016] In this method, the registration activation message sent by the first device to the second device carries a first time, which is the time when the first device sends the registration activation message. The first time can be used by the second device to determine whether the periodic registration conditions are met; and / or, the registration activation message carries environmental IoT location information, which is used to indicate the location of the first device and / or the second device. The environmental IoT location information can be used by the second device to determine whether the mobility registration conditions are met. Therefore, the first device does not need to save and maintain a list of registered second devices, nor does it need to carry information about multiple second devices registered to the network in the registration activation message. This allows the second device to initiate the corresponding type of registration process in response to the registration activation message, reducing the processing burden of the first device.

[0017] In one possible implementation, the method further includes sending a first radio resource control message to a third device, the first radio resource control message carrying a first message.

[0018] In this method, the first device carries the first message through the first radio resource control message, and can effectively forward the first message.

[0019] In one possible implementation, when the radio resource control is in the deactivated state, the first radio resource control message is a radio resource control recovery request message or a radio resource control recovery completion message; or, when the radio resource is in the idle state, the first radio resource control message is a radio resource establishment completion message.

[0020] In this method, the first device can adapt to the current RRC state and reuse the RRC messages in the interaction process from the Radio Resource Control deactivation state or the Radio Resource Control idle state to the Radio Resource Control connected state, or reuse the RRC messages in the interaction process of the small data packet transmission mechanism to carry the first message, thereby avoiding the communication load caused by sending the first message alone and effectively transmitting the first message.

[0021] Thirdly, this application provides a communication registration method, which can be executed by a third device or by a device matched with the third device, such as a processor, chip, or chip system. The method may include: receiving a first radio resource control message from a first device, the first radio resource control message carrying a first message, the first message being used by a second device to request registration on a network, the registration type requested in the first message being determined based on the registration status stored by the second device; and sending a second message to a fourth device, the second message carrying the first message.

[0022] The method provided by the third aspect enables the third device to carry the first message through the first radio resource control message and forward the first message to the fourth device. The registration type requested in the first message is determined based on the registration status stored by the second device. This enables the second device to forward the first message to the fourth device through the first and third devices, thereby effectively requesting the fourth device to perform the corresponding type of registration. In other words, it effectively enables the second device to initiate registration and network access, which is applicable to scenarios where AIoT devices initiate registration.

[0023] In one possible implementation, the information carried by the first radio resource control message further includes: first information; the first information is used to instruct the fourth device.

[0024] In this method, the third device can effectively send a second message carrying the first message to the fourth device based on the first information, thereby forwarding the first message to the fourth device to request the corresponding type of registration from the fourth device.

[0025] In one possible implementation, the information carried by the first radio resource control message further includes: second information; the second information is used to instruct the first device; sending the second message to the fourth device includes: sending the second message to the fourth device through the access and mobility management function (AMF); the AMF is determined based on the second information.

[0026] In this method, the third device can determine the AMF based on the second information carried in the first radio resource control message, and send a second message to the fourth device through the AMF, thereby forwarding the first message to the fourth device through the AMF to request the corresponding type of registration from the fourth device.

[0027] In one possible implementation, the method further includes: receiving an initial context establishment request from a fourth device, the initial context establishment request being used to request the establishment of a context for the second device; and in response to the initial context establishment request, sending an initial context establishment response to the fourth device, the initial context establishment response being used to indicate that a context for the second device has been established.

[0028] In this method, the third device receives an initial context establishment request from the fourth device, establishes the context of the second device in response to the initial context establishment request, and sends an initial context establishment response back to the fourth device, thereby establishing the context of the second device on the access network side, which facilitates the second device to communicate with the network side and accept the management of the network side.

[0029] Fourthly, this application provides a communication registration method, which can be executed by a fourth device or by a device matched with the fourth device, such as a processor, chip, or chip system. The method may include: receiving a first message from a second device; the first message being used by the second device to request registration on a network, wherein the registration type requested in the first message is determined based on the registration status stored in the second device; and in response to the first message, sending a third message to the second device, wherein the third message is used to provide feedback on the registration result to the second device.

[0030] The method provided in the fourth aspect allows the fourth device to receive a first message from the second device. The first message requests a registration type that is determined based on the registration status stored in the second device. This facilitates the fourth device to perform the corresponding type of registration processing on the second device based on the first message, and is applicable to scenarios where AIoT devices initiate registration.

[0031] In one possible implementation, the information carried by the third message includes at least one of the following: cycle duration, environmental IoT registration area information, and device core network identifier; wherein, the cycle duration is the duration of the cycle in which the second device performs periodic registration, the environmental IoT registration area information is used to indicate the registration area assigned to the second device, and the device core network identifier is used to identify the second device within the core network.

[0032] In this method, while the fourth device sends the registration result back to the second device, it can also send the period duration back to the second device, so that the second device can determine whether the periodic registration conditions are met based on the period duration and initiate periodic registration; and / or, it can also send the environmental IoT registration area information back to the second device, so that the second device can determine whether the mobility registration conditions are met based on the environmental IoT registration area information and initiate mobility registration; and / or, it can also send the device core network identifier back to the second device, so that the second device can send the device core network identifier to the fourth device when initiating registration, so that the fourth device can verify the identity of the second device based on the device core network identifier and complete the registration process.

[0033] In one possible implementation, sending a third message to the second device includes: sending a third message to the second device via the third device; the method further includes: sending an initial context establishment request to the third device, the initial context establishment request being used to request the third device to establish a context for the second device; and receiving an initial context establishment response from the third device, the initial context establishment response being used to indicate that the third device has established a context for the second device.

[0034] In this method, the fourth device also sends an initial context establishment request to the third device to request the third device to establish the context of the second device, and receives the initial context establishment response from the third device, thereby establishing the context of the second device on the access network side, which facilitates the second device to communicate with the network side and accept the management of the network side.

[0035] In one possible implementation, the method further includes: establishing a context for the second device in response to the first message.

[0036] In this method, the fourth device also responds to the first message to establish a context for the second device, thereby establishing a context for the second device on the core network side, which facilitates communication between the second device and the network side and acceptance of network side management.

[0037] Fifthly, embodiments of this application provide a communication device comprising a module / unit for performing any of the methods described in the first aspect and its possible implementations, or for performing any of the methods described in the second aspect and its possible implementations, or for performing any of the methods described in the third aspect and its possible implementations, or for performing any of the methods described in the fourth aspect and its possible implementations.

[0038] Sixthly, embodiments of this application provide a communication device. This device can be a second device, a chip, chip system, or processor that supports the second device in implementing the above-described methods, or a logic node, logic module, or software capable of implementing all or part of the functions of the second device. The communication device can also be a chip system. The communication device can execute the method described in the first aspect. The functions of the communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above-described functions. These units can be software and / or hardware. The operations performed by the communication device and its beneficial effects can be found in the method described in the first aspect and its beneficial effects described above; repeated descriptions will not be repeated.

[0039] In a seventh aspect, embodiments of this application provide a communication device. This device can be a first device, a chip, a chip system, or a processor that supports the first device in implementing the above-described methods, or a logic node, logic module, or software capable of implementing all or part of the functions of the first device. The communication device can also be a chip system. This communication device can execute the methods described in the second aspect. The functions of the communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above-described functions. These units can be software and / or hardware. The operations performed by the communication device and its beneficial effects can be found in the methods described in the second aspect above, and repeated descriptions will not be repeated here.

[0040] Eighthly, embodiments of this application provide a communication device. This device can be a third device, a chip, chip system, or processor supporting the third device in implementing the above-described methods, or a logic node, logic module, or software capable of implementing all or part of the functions of the third device. The communication device can also be a chip system. This communication device can execute the methods described in the third aspect. The functions of the communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above-described functions. These units can be software and / or hardware. The operations performed by the communication device and its beneficial effects can be found in the methods described in the third aspect and their beneficial effects described above; repeated descriptions will not be repeated.

[0041] Ninthly, embodiments of this application provide a communication device. This device can be a fourth device, a chip, chip system, or processor supporting the fourth device in implementing the above-described methods, or a logic node, logic module, or software capable of implementing all or part of the functions of the fourth device. The communication device can also be a chip system. This communication device can execute the methods described in the fourth aspect. The functions of the communication device can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more units corresponding to the above-described functions. These units can be software and / or hardware. The operations performed by the communication device and its beneficial effects can be found in the methods described in the fourth aspect and their beneficial effects described above; repeated descriptions will not be repeated.

[0042] In a tenth aspect, embodiments of this application provide a communication device, the communication device including a processor coupled to a memory for storing programs or instructions, wherein when the program or instructions are executed by the processor, the communication device performs the method described in any one of the first to fourth aspects.

[0043] Eleventhly, embodiments of this application provide a communication device, which includes a processor and an interface circuit. The interface circuit is used to receive signals from other communication devices outside the communication device and transmit them to the processor, or to send signals from the processor to other communication devices outside the communication device. The processor is used to implement the method described in any one of the first to fourth aspects through logic circuits or execution code instructions.

[0044] In a twelfth aspect, embodiments of this application provide a computer-readable storage medium for storing computer-executable instructions that, when executed, cause the method executed by the second device in the method described in the first aspect to be implemented; or cause the method executed by the first device in the method described in the second aspect to be implemented; or cause the method executed by the third device in the method described in the third aspect to be implemented; or cause the method executed by the fourth device in the method described in the fourth aspect to be implemented.

[0045] In a thirteenth aspect, embodiments of this application provide a computer program product including a computer program, which, when executed, causes the method executed by the second device in the method described in the first aspect to be implemented; or causes the method executed by the first device in the method described in the second aspect to be implemented; or causes the method executed by the third device in the method described in the third aspect to be implemented; or causes the method executed by the fourth device in the method described in the fourth aspect to be implemented.

[0046] In a fourteenth aspect, embodiments of this application provide a communication system, which includes a communication device (e.g., a second device) for performing the method described in the first aspect and a communication device (e.g., a fourth device) for performing the communication method described in the fourth aspect.

[0047] In a fifteenth aspect, embodiments of this application provide a communication system comprising a communication device (e.g., a second device) for performing the method described in the first aspect, a communication device (e.g., a first device) for performing the method described in the second aspect, a communication device (e.g., a third device) for performing the method described in the third aspect, and a communication device (e.g., a fourth device) for performing the method described in the fourth aspect.

[0048] Understandably, the beneficial effects that the communication methods, communication devices, computer-readable storage media, and computer program products provided above can be referenced to the beneficial effects in the first, second, third, or fourth aspects and any possible implementation thereof, which will not be repeated here. Attached Figure Description

[0049] Figure 1 is a schematic diagram of the topology 1 architecture supported by AIoT;

[0050] Figure 2 is a schematic diagram of the Topology 2 architecture supported by AIoT;

[0051] Figure 3 is a schematic diagram of the topology 3 architecture supported by AIoT;

[0052] Figure 4 is a schematic diagram of the Topology 4 architecture supported by AIoT;

[0053] Figure 5 is a schematic diagram of the system architecture applying an embodiment of this application;

[0054] Figure 6 is a schematic diagram of an RRC-based protocol stack architecture provided in an embodiment of this application;

[0055] Figure 7 is a flowchart illustrating a communication registration method provided in an embodiment of this application;

[0056] Figure 8 is a flowchart illustrating a method for enabling a first device to delay sending a first RRC message according to an embodiment of this application.

[0057] Figure 9 is a schematic diagram of the interaction flow of a communication registration method with initial registration type provided in an embodiment of this application;

[0058] Figure 10 is a schematic diagram of the interaction flow of a communication registration method with periodic registration type provided in an embodiment of this application;

[0059] Figure 11 is a schematic diagram of the interaction flow of a communication registration method with mobility registration as the registration type provided in an embodiment of this application;

[0060] Figure 12 is a schematic flowchart of a method for authorizing or allowing a first device to assist a second device in performing mobility registration, provided by an embodiment of this application.

[0061] Figure 13 is a structural schematic diagram of a communication device 1300 provided in an embodiment of this application;

[0062] Figure 14 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation

[0063] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0064] The terms "first," "second," "third," etc., used in the embodiments of this application are to distinguish different objects, rather than to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, it may include a series of steps or units, or optionally, steps or units not listed, or other steps or units inherent to these processes, methods, products, or devices. The terms "one embodiment" or "some embodiments," etc., mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of the embodiments of this application, do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized.

[0065] Furthermore, "at least one" refers to one or more, while "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "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, and c can mean: a, or b, or c, or a and b, or a and c, or b and c, or a, b, and c, where a, b, and c can be single or multiple.

[0066] Given the wide range of applications for AIoT devices, their numbers are expected to explode in the future. These massive numbers of AIoT devices typically need to register with the network to communicate and be managed. Registration is a crucial step in ensuring devices can be recognized, authenticated, and authorized by the network. However, considering the generally simple structure and limited capabilities of most AIoT devices, current methods for terminal devices to initiate registration are not suitable for AIoT devices. Therefore, how AIoT devices can initiate registration is a pressing technical problem that needs to be solved.

[0067] To facilitate understanding of the embodiments of this application, the relevant concepts and terms involved in the embodiments of this application will first be explained.

[0068] The concepts and terms used in the following embodiments of this application are for the purpose of describing specific embodiments only and are not intended to limit this application.

[0069] 1. Ambient Internet of Things (AIoT) and AIoT devices

[0070] AIoT is the Internet of Things, which connects various devices in the environment to sense, process, and transmit environmental information.

[0071] AIoT devices are a new type of Internet of Things (IoT) devices that harvest energy from radio waves, light, motion, heat, or any other available ambient energy source and use this energy to power their devices. For example, AIoT devices can be electronic tags or sensors. These AIoT devices have a simple structure and transmit information by reflecting or absorbing electromagnetic waves emitted by the reader through backscattering. Because these AIoT devices do not require an external power supply or battery replacements, their maintenance costs are extremely low, and they can be widely used in fields such as smart warehousing, smart logistics, smart agriculture, industrial wireless sensor networks, smart transportation, and smart healthcare.

[0072] The embodiments of this application do not limit the form of AIoT devices. The device used to implement the functions of an AIoT device can be a terminal device; it can also be a device capable of supporting the AIoT device to implement the functions, such as a chip or a chip system. This device can be installed in or used in conjunction with an AIoT device. In the embodiments of this application, the chip system can be composed of chips, or it can include chips and other discrete components.

[0073] AIoT can support the four topology architectures shown in Figures 1 to 4:

[0074] In the topology 1 structure shown in Figure 1, AIoT device 101 communicates with network device 102 to transmit AIoT data and / or AIoT signals.

[0075] In the topology 2 architecture shown in Figure 2, AIoT device 101 communicates with network device 102 through intermediate node 103 to transmit AIoT data and / or AIoT signals.

[0076] In the topology 3 architecture shown in Figure 3, network device 102 communicates with AIoT device 101 through assistant node 104 to transmit AIoT data and / or AIoT signals to AIoT device 101; AIoT device 101 communicates with network device 102 to transmit AIoT data and / or AIoT signals to network device 102.

[0077] Optionally, network device 102 and assisting node 104 can communicate via the Uu interface.

[0078] In the topology 4 architecture shown in Figure 4, AIoT device 101 communicates with terminal device 105 to transmit AIoT data and / or AIoT signals.

[0079] The network devices shown in Figures 1-4 are represented as access network devices.

[0080] To execute AIoT services, the core network (CN) (5G Core Network, 5GC) of the 5th generation mobile communication (5G) system has added a new network element—the Ambient IoT Function (AIoTF). The AIoTF manages AIoT devices and related processes. The AIoTF can be a standalone network element or co-located with the Access and Mobility Management Function (AMF) network element in the CN.

[0081] 2. Intermediate nodes in the topology 2 architecture

[0082] Intermediate nodes are network nodes in AIoT that can act as readers. In the topology 2 architecture, intermediate nodes are used for communication between AIoT devices and network devices. For example, intermediate nodes can forward information exchanged between AIoT devices and network devices.

[0083] In the topology 2 architecture, the intermediate node can be a user equipment (UE). For example, the intermediate node can be a legacy terminal device, or it can be a UE reader specifically designed for AIoT services. In this embodiment, the intermediate node can also be referred to as a UE reader.

[0084] Before a terminal device can act as a UE reader, it needs to be authenticated and authorized by the CN (Network Provider Interface) and obtain permission from the CN before it can activate its UE reader capability. The terminal device can request authentication and authorization as a UE reader from the AIoTF (Access Provider Interface) within the CN through the access network device and the AMF (Access Provider Function) within the CN. The AIoTF can then send the authentication and authorization results to the terminal device through the AMF and the access network device. For example, the AIoTF can send first authentication information to the access network device through the AMF. This first authentication information indicates that the terminal device has been authenticated as a UE reader, and the access network device can forward this first authentication information to the terminal device.

[0085] After a terminal device is authenticated as a UEreader, its UEreader context can be stored in the AIoTF. The terminal device's subscription data as a UEreader can be stored in the Unified Data Management (UDM) network element or the first network element. For a description of the UDM and the first network element, please refer to the system architecture introduction later.

[0086] Optionally, AIoTF can also send configuration information to terminal devices authenticated as UEreaders via access network devices. This configuration information carries the duration of the period during which the terminal device broadcasts a Registration Activation Request message and / or the broadcastable area. The Registration Activation Request message is used to trigger the AIoT device to determine whether to initiate a registration process, for example, whether to initiate a registration request; and / or to trigger the AIoT device to determine the registration type for initiating the registration process.

[0087] In addition, terminal devices, as devices, also need to register with the network in order to communicate with the network and be managed by the network. Terminal devices can send a registration request to the AMF (Access Provider Function) through the access network device to request network registration. The AMF can then return a registration response to the terminal device through the access network device, carrying registration acceptance information, thereby completing the terminal device's registration process.

[0088] 3. Radio Resource Control (RRC) status and state transitions of terminal equipment

[0089] The RRC status of the terminal device includes the following three states:

[0090] (1) Radio Resource Connected State (RRC-Connected)

[0091] RRC-connected indicates that an RRC connection has been established between the terminal device and the access network device. Under the RRC-connected state, the terminal device is connected to both the access network device and the core network device.

[0092] Under RRC-connected, the terminal device can perform operations such as receiving data from the access network device, sending data to the access network device, performing mobility management, channel quality reporting, and neighbor cell measurement.

[0093] (2) Radio Resource Deactivated State (RRC-Inactive)

[0094] RRC-Inactive means that the terminal device and the access network device are in a suspended state, but the terminal device and the core network device remain connected.

[0095] Under RRC-Inactive, the terminal device retains the CN context and can receive paging messages and system messages.

[0096] (3) Radio Resource Idle (RRC-Idle)

[0097] RRC-Idle means that the connection between the terminal device and the access network device, as well as the connection between the terminal device and the core network device, are both in a released state.

[0098] Terminal devices in RRC-Idle have no active data transmission and attempt to receive broadcast messages and other important services.

[0099] Terminal devices in RRC-Inactive or RRC-Idle states can perform operations including but not limited to: ① listening for paging messages during paging occasions (POs); ② performing periodic registration. The timer for periodic registration can be allocated to the terminal device by the AMF. When this timer expires, the terminal device sends a registration request of type periodic registration. For a description of periodic registration, please refer to the introduction of registration types below.

[0100] When a terminal in RRC-Inative or RRC-Idle mode acts as a UEreader, it can also perform the following operations: ③ Broadcast registration activation message.

[0101] Terminal devices can transition between three RRC states. The interaction process of a terminal device transitioning from RRC-Inactive to RRC-Connected and from RRC-Idle to RRC-Connected can restore normal communication with network devices.

[0102] The following describes the interaction process for terminal devices to switch from RRC-Inactive to RRC-Connected and from RRC-Idle to RRC-Connected.

[0103] The interaction process for a terminal device to switch from RRC-Inactive to RRC-Connected may include:

[0104] Step 1.1: The terminal device sends a Radio Resource Control Resume Request (RRC Resume Request) to the 5G base station (next generation NodeB, gNB).

[0105] Step 1.2: The gNB sends a request to the last Serving 5G base station to retrieve the UE Context.

[0106] Step 1.3: Last Serving gNB returns a Retrieve UE Context Response to gNB.

[0107] In step 1.3, the Last Serving gNB provides context data for the terminal device.

[0108] Step 1.4: The gNB sends a Radio Resource Control Resume (RRC Resume) message to the terminal device.

[0109] Step 1.5: The terminal device sends a Radio Resource Resume Complete (RRC Resume Complete) message to the gNB.

[0110] In steps 1.4 and 1.5, the gNB and the terminal device complete the RRC connection restoration procedure. If scheduling permits, the terminal device may send data in step 1.5.

[0111] Step 1.6: The gNB sends an Xn-U Address Indication message between the user plane of the next-generation radio access network to the Last Serving gNB to provide a forwarding address to the Last Serving gNB.

[0112] Step 1.6 is to enable the gNB to provide address forwarding functionality in order to prevent the loss of downlink user data cached by the Last Serving gNB.

[0113] Step 1.7: gNB sends a path switching request to AMF.

[0114] Step 1.8: The AMF sends a path switching request response to the gNB.

[0115] Perform a path switch for gNB using steps 1.7 and 1.8.

[0116] Step 1.9: The gNB sends a UE Context Release message to the Last Serving gNB. Correspondingly, the Last Serving gNB receives the UE Context Release message from the gNB.

[0117] Last Serving gNB can release the terminal device's context based on UE Context Release.

[0118] The interaction process for a terminal device to switch from RRC-Idle to RRC-Connected may include:

[0119] Step 2.1: The terminal device sends an RRC Resume Request to the gNB.

[0120] Step 2.2: The gNB sends a Radio Resource Control Setup (RRC Setup) message to the terminal device.

[0121] Step 2.2a: The terminal device sends a Radio Resource Setup Complete (RRC Setup Complete) message.

[0122] Steps 2.2 and 2.2a are the procedures for gNB to complete the RRC establishment.

[0123] Step 2.3: gNB sends an Initial UE Message to AMF.

[0124] The gNB can send the first Non-access stratum (NAS) message included in RRC Setup Complete to the AMF via the Initial UE Message.

[0125] Step 2.4: The AMF sends a Downlink NAS Transport message to the gNB.

[0126] Step 2.4a: The gNB sends a downlink information transfer (DL Information Transfer) message to the terminal device.

[0127] Step 2.5: The terminal device sends an uplink information transfer (UL Information Transfer) message to the gNB.

[0128] Step 2.5a: gNB sends an Uplink NAS Transport message to AMF.

[0129] Steps 2.4, 2.4a, 2.5, and 2.5a are steps for the terminal device and the AMF to exchange some additional NAS messages via the gNB.

[0130] Step 2.6: The AMF sends an Initial Context Setup Request to the gNB.

[0131] In step 2.6, the AMF prepares the context data of the terminal device, including the Protocol Data Unit session context (PDU session context), the Security Key, the UE Radio Capability, and the UE Security Capabilities.

[0132] Step 2.7: The gNB sends a Security Mode Command to the terminal device.

[0133] Step 2.7a: The terminal device sends a "Security Mode Complete" message to the gNB.

[0134] In steps 2.7 and 2.7a, the gNB activates the terminal device's Access Stratum (AS) security encryption and other information.

[0135] Step 2.8: The gNB sends a Radio Resource Control Reconfiguration (RRC Reconfiguration) message to the terminal device.

[0136] Step 2.8a: The terminal device sends a Radio Resource Control Reconfiguration Complete (RRC Reconfiguration Complete) message to the gNB.

[0137] In step 2.8, the gNB performs an RRC Reconfiguration to establish the Signalalling Radio Bearer (SRB)2 and the Data Radio Bearer (DRB).

[0138] Step 2.9: gNB sends an Initial Context Setup Response to AMF.

[0139] In step 2.9, gNB notifies AMF that the process setup is complete.

[0140] In addition, terminal devices in RRC-Inactive mode can also use the Small Data Transmission (SDT) mechanism to send small amounts of data to the gNB.

[0141] When a terminal device in RRC-Inactive sends a small amount of data to a gNB using the SDT mechanism, it may include sending an RRC Resume Request message to the receiving gNB and sending uplink (UL) SDT data or UL SDT signaling.

[0142] Optionally, there are two ways for terminal devices in RRC-Inactive to send small amounts of data to the gNB using the SDT mechanism: terminal device context relocation small data transmission (SDT with UE context relocation) and terminal device context non-relocation small data transmission (SDT without UE context relocation).

[0143] The following section introduces SDT with UE context relocation and SDT without UE context relocation.

[0144] The interaction flow of SDT with UE context relocation includes:

[0145] Step 3.1: The terminal device sends an RRC Resume Request message to the receiving gNB and sends UL SDT data or UL SDT signaling.

[0146] Step 3.2: The receiving gNB uses the Inactive Radio Network Temporary Identifier (I-RNTI) to identify the Last Serving gNB and retrieves the terminal device context from the Last Serving gNB through the interface-application layer signaling protocol (Xn-AP) between next-generation radio access networks.

[0147] In step 3.2, the receiving gNB sends a Retrieve UE Context Request to the Last Serving gNB, indicating that the Retrieve UE Context Request is for SDT and can also provide SDT auxiliary information.

[0148] For example, SDT auxiliary information can be a single data packet, multiple data packets, etc.

[0149] Step 3.3: The Last Serving gNB decides to relocate the terminal device context and responds to the receiving gNB using the Retrieve UE Context Response message.

[0150] Step 3.4: The receiving gNB decides to keep the terminal device in the RRC-Inactive state of the SDT.

[0151] To prevent the loss of downlink (DL) user data buffered in the Last Serving gNB, the receiving gNB provides a forwarding address via an Xn-U Address Indication message.

[0152] Step 3.5: The receiving gNB also initiates the 5G Next Generation-Application layer protocol (NG-AP) path handover process to establish an NG UE signaling connection related to the serving AMF.

[0153] During NG-AP path switching, the receiving gNB can send a path switch request to the serving AMF, and the serving AMF can return a path switch request acknowledgement message.

[0154] Following the path switching process, the buffered UL NAS PDU (if any) is transmitted from the receiving gNB to the AMF. Subsequent UL / DL SDT data and / or signaling are then transmitted between the terminal equipment and the core network via the receiving gNB.

[0155] Step 3.6: After the SDT transmission is completed, receive the RRC Release message generated by the gNB and send it to the UE, which contains a suspension indication, to complete the SDT process and keep the terminal device in RRC-Inactive.

[0156] If DL non-SDT data or DL ​​non-SDT signaling arrives, or if UE assistance information (i.e., UL non-SDT data arrival indication) is received from the terminal device, the receiving gNB can decide to switch the terminal device to RRC-Connected by sending an RRC Resume message.

[0157] Step 3.7: The receiving gNB instructs the Last Serving gNB to remove the terminal device context by sending an Xn-AP UE Context Release message.

[0158] The interaction flow of SDT without UE context relocation includes:

[0159] Step 4.1: The terminal device sends an RRC Resume Request message to the receiving gNB and sends UL SDT data or UL SDT signaling.

[0160] Step 4.2: The receiving gNB uses the Inactive Radio Network Temporary Identifier (I-RNTI) to identify the Last Serving gNB, and retrieves the terminal device context from the Last Serving gNB through the Xn-AP terminal device context retrieval procedure.

[0161] For a description of step 4.2, please refer to the description of step 3.2, which will not be repeated here.

[0162] In step 4.3, the Last Serving gNB decides not to relocate the complete UE context for the SDT.

[0163] Step 4.4, Last Serving gNB transmits the terminal device context, including the SDT-related Radio Link Control (RLC) context.

[0164] In step 4.4, the Last Serving gNB can send a Partial Context Transfer message to the Receiving gNB.

[0165] Step 4.5: The receiving gNB acknowledges receipt of a portion of the terminal device context and provides the relevant Transport Network Layer (TNL) address. The UE context is stored in the Last Serving gNB, and the SDT-related RLC context is established in the receiving gNB. Then, a UL / DL General Packet Radio Service (GPRS) tunneling protocol for the user plane (GTP-U) tunnel (if any) is established for the DRB configured for the SDT, and UL SDT data and / or signaling (if any) are forwarded to the Last Serving gNB and then transmitted to the core network.

[0166] Step 4.6: The gNB detects the end of the SDT session and sends a Retrieve UE Context Confirm message, including whether this is a "normal" end of the SDT transaction or a radio link problem.

[0167] Step 4.7: After receiving the Retrieve UE Context Confirm message and deciding to terminate SDT, the Last Serving gNB responds with a Retrieve UE Context Failure message containing an encapsulated RRC Release message. Based on the Retrieve UE Context Failure message, the receiving gNB should release the established portion of the UE context.

[0168] Step 4.8: Receive the RRC Release message sent by the gNB to the UE.

[0169] If DL non-SDT data or signaling arrives, or auxiliary information (i.e., UL non-SDT data arrival indication) is received from the terminal device, the Last Serving gNB completes the SDT procedure and instructs the terminal device to remain in RRC-Inactive by sending an RRC Release message.

[0170] Step 4.9: If the suspend indication is included in the RRC release message, the terminal device switches to RRC-Inactive; otherwise, the terminal device switches to RRC-Idle.

[0171] The RRC Resume Complete message transmitted during the interaction process of the terminal device switching from RRC-Inactive to RRC-Connected, the RRC Setup Complete message transmitted during the interaction process of the terminal device switching from RRC-Idle to RRC-Connected, the RRC Resume Request message transmitted during the interaction process of SDT with UE context relocation, and the RRC Resume Request message transmitted during the interaction process of SDT without UE context relocation are all RRC messages.

[0172] 4. Registration types of AIoT devices

[0173] In order to communicate with the network and be managed by the network, devices need to register with the network. These devices can be AIoT devices and / or terminal devices.

[0174] The registration types for AIoT devices may include, but are not limited to, initial registration, periodic registration, and mobility registration. The following explains these three types of registration.

[0175] (1) Initial registration

[0176] Initial registration refers to the first time a device registers with the core network (CN).

[0177] After the device completes its initial registration, the network side can obtain the device's location information and capabilities. The network side will also establish a context for the device, including a mobile management context. This mobile management context may include, but is not limited to, the device's identifier, location information, registration status, and authentication information.

[0178] (2) Periodic registration

[0179] Periodic registration refers to the process by which a device, after completing its initial registration, periodically sends registration requests to the network to confirm that the device is still in the service area, maintains its connection with the network, and keeps its registration status valid.

[0180] Through periodic registration, the network can obtain the latest status information of devices, including location, battery level, and service node information. The periodic registration process also increases network security.

[0181] (3) Mobility registration

[0182] Mobility registration refers to a device sending a registration request to the network while in motion, so as to update the device's location in the network in a timely manner.

[0183] Mobility registration enables the CN to quickly locate the device when the Application Function (AF) initiates a service request.

[0184] If a device moves out of the registration area (RA) assigned during previous registration, the device's identity should be verified again during the mobility registration process.

[0185] Terminal devices can also perform the three types of registration mentioned above. In addition to the three types of registration mentioned above, terminal devices can also perform other types of registration, such as emergency registration, without any restrictions.

[0186] Secondly, the system architecture involved in the embodiments of this application will be described:

[0187] This application's embodiments can be applied to communication systems evolving after 5G, such as 5G systems, 6th generation mobile communication (6G) systems, satellite communications, and short-range wireless communication systems. The wireless communication systems mentioned in this application's embodiments include, but are not limited to, AIoT communication systems within 5G / 6G mobile communication systems. A wireless communication system may include one or more network devices, one or more terminal devices, and one or more AIoT devices. Network devices may be access network devices or core network devices.

[0188] The embodiments of this application can be applied to the system architecture shown in Figure 5. The system architecture shown in Figure 5 may include, but is not limited to: AIoT device 501, intermediate node 502, access network device 503, and core network device 504. Optionally, the system architecture shown in Figure 5 may also include a data network 505.

[0189] For AIoT devices 501, please refer to the foregoing related concepts and terms for an introduction to AIoT and AIoT devices.

[0190] Intermediate node 502 can be a terminal device. A terminal device, also known as user equipment (UE), mobile station (MS), or mobile terminal (MT), refers to a device that can provide voice and / or data connectivity to a user. Examples include handheld devices with wireless connectivity and in-vehicle devices. Currently, some examples of terminal devices include: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices, virtual reality (VR) devices, augmented reality (AR) devices, wireless terminals in industrial control, wireless terminals in self-driving cars, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, and wireless terminals in smart homes.

[0191] The embodiments of this application do not limit the form of the terminal device. The device used to implement the function of the terminal device can be the terminal device itself; it can also be a device that supports the terminal device in implementing the function, such as a chip or a chip system. The device can be installed in the terminal device or used in conjunction with the terminal device. In the embodiments of this application, the chip system can be composed of chips or can include chips and other discrete components.

[0192] Access network device 503 can be a device that provides access for terminal devices. For example, it can provide network access functionality for authorized users in a specific area and determine different quality transmission channels to transmit user data based on the user's level and service requirements. The access network device forwards control signals and user data between the terminal devices and the core network devices.

[0193] In one possible scenario, access network equipment can be a base station, an evolved NodeB (eNodeB), a transmitting and receiving point (TRP), a transmitting point (TP), a next-generation NodeB (gNB), a next-generation base station in a 6th-generation (6G) mobile communication system, a base station in a future mobile communication system, a satellite, an integrated access and backhaul (IAB) node, or an access network device in a mobile switching center non-terrestrial network (NTN) communication system. This means it can be deployed on high-altitude platforms or satellites. Access network equipment can be a macro base station, a micro base station or an indoor station, a relay node or a donor node, or a radio controller in a C-RAN scenario. Access network equipment can also function as a base station in device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, drone communication, or machine-to-machine (M2M) communication. Optionally, access network equipment can also be a server, a wearable device, a vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU).

[0194] In another possible scenario, multiple access network devices collaborate to assist terminal devices in achieving wireless access, with each access network device implementing a portion of the base station's functions. For example, access network devices can be central units (CUs), distributed units (DUs), CU-control plane (CPs), CU-user plane (UPs), or radio units (RUs), etc. CUs and DUs can be set up separately or included in the same network element, such as a baseband unit (BBU). RUs can be included in radio equipment or radio units, such as remote radio units (RRUs), active antenna units (AAUs), or remote radio heads (RRHs). It is understood that access network devices can be CU nodes, DU nodes, or devices including both CU and DU nodes. Furthermore, CUs can be classified as access network devices within the RAN (RAN) or the CN (CN), without limitation.

[0195] 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 O-CU (open CU), DU can also be called O-DU, CU-CP can also be called O-CU-CP, CU-UP can also be called O-CU-UP, and RU can also be called O-RU. For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software and hardware modules.

[0196] Core network device 504 is a device in the core network that is responsible for maintaining the subscription data of the mobile network and providing terminal devices with functions including but not limited to session management, mobility management, policy management, and security authentication. The core network can be the core network of a 5G system, the core network of a 6G system, or the core network of other future communication systems.

[0197] Core network equipment may include various functional network elements to implement corresponding core network functions. Embodiments of this application may involve, but are not limited to, the following network elements:

[0198] (1) AIoTF, for a description of AIoT and AIoT devices, see the above-mentioned related concepts and terms.

[0199] (2) The AMF (Access Controller) is responsible for user access and mobility management, including handling user equipment access requests, mobility management, and radio resource allocation. The AMF identifies the location and mobility requirements of user equipment through signaling interaction and allocates corresponding radio resources. Furthermore, the AMF is responsible for maintaining the connection status between user equipment and the network, ensuring the continuity and stability of data transmission.

[0200] (3) Policy Control Function (PCF): Responsible for user policy control, including session policies, mobility policies, Quality of Service (QoS) control, service access control, etc.

[0201] (4) UDM: Responsible for managing user subscription data, including user identity information, service subscription information, roaming control, etc. A unified data warehouse (UDR) is usually used in conjunction with UDM to store UDM's subscription data.

[0202] (5) Network Exposure Function (NEF): Responsible for opening up the capabilities of the 5G network to external systems, promoting the innovation and diversification of network services.

[0203] (6) Network Repository Function (NRF): Responsible for the registration, discovery and selection of network functions, and supports the dynamic management and flexible deployment of network functions.

[0204] (7) Authentication Server Function (AUSF): Responsible for authenticating users’ access to the 3rd Generation Partnership Project (3GPP) and non-3GPP access, ensuring the security and legitimacy of user identity.

[0205] (8) Application function (AF): It communicates with the core network to provide services to users and is the interface between the core network and external applications.

[0206] Furthermore, embodiments of this application may also involve a network element proposed for AIoT, which functions similarly to a UDM and can be responsible for the management and maintenance of subscription data for AIoT devices, subscription data for readers, and / or registration information of AIoTFs serving AIoT. For ease of description and to distinguish it from other network elements, this network element will be referred to as the first network element. Embodiments of this application do not limit the name of the first network element.

[0207] For example, the first network element could be an AIoT Data Management (ADM), which manages and maintains the subscription data of AIoT devices. The subscription data of AIoT devices may include, but is not limited to, the AIoT device's permanent identifier (Permanent ID) and last known AIoTF information. The Permanent ID is used to uniquely identify the AIoT device. The last known AIoTF information indicates the last known AIoTF that served the AIoT device.

[0208] A Data Network (DN) 505, also known as a Packet Data Network (PDU), is a network located outside of the operator's network. The operator's network can access multiple DNs, and each DN can deploy application servers corresponding to various services to provide a variety of possible services to terminal devices, such as data and / or voice services.

[0209] Furthermore, the protocol stack involved in the embodiments of this application will be described as follows:

[0210] Please refer to Figure 6, which is a schematic diagram of an RRC-based protocol stack architecture provided in an embodiment of this application. The protocol stack shown in Figure 6 is suitable for transmitting AIoT data and / or AIoT signals between AIoT devices and AIoTF.

[0211] The end-to-end protocol stack between an AIoT device and an AIoTF includes the AIoT non-access stratum (NAS) layer. The end-to-end protocol stack between an AIoT device and a UE reader includes the AIoT Access Stratum (AS) layer. The end-to-end protocol stack between an AIoT device and an AF includes higher layers, such as the AIoT Data layer as shown in Figure 6.

[0212] The end-to-end protocol stack between the UEreader and the access network equipment includes the Radio Resource Control (RRC) layer, the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, the Medium Access Control (MAC) layer, and the Physical (PHY) layer.

[0213] The end-to-end protocol stack between the access network device and the AMF includes the Next Generation Application Protocol (NGAP) layer and the lower layer. The end-to-end protocol stack between the access network device and the AIoTF includes the first protocol layer.

[0214] The end-to-end protocol stack of AMF and AIoTF includes a service-based interface (SBI) layer and a Lower Layer.

[0215] The end-to-end protocol stack of AIoTF and NEF includes the SBI layer and the Lower Layer.

[0216] The end-to-end protocol stack between NEF and AF includes an Application Programming Interface (API) layer and a Lower Layer.

[0217] The first protocol layer and the NGAP layer are different protocol layers. The first protocol layer can be at a higher level than the NGAP layer in the protocol stack. For example, as shown in Figure 6, the first protocol layer can be a newly defined protocol layer for AIoT services; or, the first protocol layer can be the NGAP layer (not shown in Figure 6); or, the first protocol layer can be a part of the NGAP layer (not shown in Figure 6). Optionally, the first protocol layer can be used, but is not limited to, transmitting information related to AIoT services between the access network device and the AIoTF; there are no restrictions on this. Optionally, the first protocol layer can be called the AIoT Reader Control layer, or any other name; there are no restrictions on this.

[0218] Therefore, it can be concluded that the protocol stacks of AIoT devices and AIoTF have an equivalent protocol layer, namely the AIoT NAS layer, while the protocol stacks of access network devices and AMF do not have an AIoT NAS layer. Consequently, AIoT devices and AIoTF can generate or parse AIoT NAS Protocol Data Units (PDUs), and terminal devices, access network devices, and AMF can transparently transmit AIoT NAS PDUs. In the following embodiments, AIoT NAS PDUs will be referred to simply as NAS PDUs, involving both first and second NAS PDUs.

[0219] Optionally, the AIoT NAS PDU can carry both unencrypted and encrypted information. For example, unencrypted information is plaintext information, such as a portion of all information transmitted between the AIoT device and the AIoTF. Encrypted information is information that has been encrypted with both plaintext and sensitive information; optionally, all information transmitted between the AIoT device and the AIoTF includes both plaintext and sensitive information. Therefore, terminal devices, access network devices, and AMFs can read unencrypted information from the AIoT NAS PDU, but cannot read encrypted information from it.

[0220] It should be noted that when transmitting other data and / or signals between the UEreader and core network elements (e.g., AMF), the end-to-end protocol stack between the UEreader and the core network elements may also include a NAS layer (not shown in Figure 6). This NAS layer is not used to transmit AIoT data and / or AIoT signals. For example, the NAS layer in the end-to-end protocol stack between the UEreader and AMF can be used to transmit a UE NAS PDU, which carries a registration request message used by the UEreader to request registration with the network.

[0221] The communication registration method provided in this application embodiment will be described in detail below based on the system architecture shown in Figure 5 and the protocol stack shown in Figure 6.

[0222] This application embodiment illustrates the interaction process between a first device, a second device, a third device, and a fourth device as an example. The first device can be a UEreader, including its processor, chip, or chip module, or a device or unit compatible with the UEreader. The second device can be an AIoT device, including its processor, chip, or chip module, or a device or unit compatible with the AIoT device. The third device can be an access network device, including its processor, chip, or chip module, or a device or unit compatible with the access network device. For example, the third device can be a gNB, including its processor, chip, or chip module, or a device or unit compatible with the gNB. The fourth device can be a core network device (e.g., a network element in the core network), including its processor, chip, or chip module, or a device or unit compatible with the core network device. For example, the fourth device can be an AIoTF, including its processor, chip, or chip module, or a device or unit compatible with the AIoTF.

[0223] In one alternative implementation, the second device may send a first message to the fourth device. The first message is used by the second device to request registration on the network. The registration type requested in the first message is determined based on the registration status stored by the second device.

[0224] The registration status indicates that the second device has completed initial registration on the network. "Registered on the network" means the second device has completed initial registration on the network, while "Not registered on the network" means the second device has not completed initial registration on the network. If the second device has not completed initial registration on the network, nor periodic or mobility registration on the network, then the network refers to the CN (Network Application Clusters).

[0225] Accordingly, after receiving the first message from the second device, the fourth device will respond by sending a third message to the second device. The third message is used to provide feedback on the registration result to the second device. The registration result can be either registration acceptance or registration rejection.

[0226] Optionally, the second device can send the first message to the fourth device via the third device. Further, the second device can send the first message to the fourth device via both the first and third devices.

[0227] Optionally, the fourth device can send a third message to the second device via the third device. Further, the fourth device can send a third message to the second device via both the third device and the first device.

[0228] The embodiment shown in Figure 7 illustrates this implementation by having the second and fourth devices exchange first and third messages through the first and third devices.

[0229] Please refer to Figure 7, which is a flowchart illustrating a communication registration method provided in an embodiment of this application. This method may include, but is not limited to:

[0230] S701, the first device sends a registration activation message to the second device.

[0231] The first device can periodically broadcast registration activation messages so that the second device can periodically receive them. For example, the first device broadcasts registration activation messages every 3 hours.

[0232] The second device is located within the broadcastable area of ​​the registration activation message. The duration of the first device's broadcast registration activation message period and the broadcastable area can be configured to the first device after the fourth device authenticates the first device as a UEreader. Optionally, the duration of the first device's broadcast registration activation message period and the broadcastable area can be stored as UEreader context in the fourth device, and / or can be stored as UEreader's subscription data in the UDM or the first network element.

[0233] The registration activation message is used to trigger the AIoT device to determine whether to initiate a registration process, such as whether to initiate a registration request; and / or to trigger the AIoT device to determine the registration type of the registration process to be initiated.

[0234] In one possible implementation, the information carried by the registration activation message may include, but is not limited to, at least one of the following:

[0235] 1. Immediately;

[0236] 2. AIoT (Ambient Internet of Things) location information;

[0237] 3. Filtering criteria.

[0238] The first time can be the time when the first device sends the registration activation message. Since the second device has a simple structure and limited capabilities, it may not be able to maintain its clock. Therefore, the first device maintains the clock time and, when broadcasting the registration activation message, includes the first time of sending the registration activation message in the registration activation message and sends it to the second device. The first time can be used by the second device to determine whether the periodic registration conditions are met. The method for determining whether the periodic registration conditions are met can be found in the description of step S702.

[0239] AIoT location information is used to indicate the location of the first device and / or the second device. For example, AIoT location information is used to indicate the physical location of the first device and / or the second device.

[0240] The first device needs to receive the first message sent by the second device; therefore, the location of the first device can be the same as the location of the second device; or, the location of the first device can include the location of the second device.

[0241] Optionally, AIoT location information can be used to indicate the tracking area (TA) where the first device is located and / or the TA where the second device is located. Here, the TA can also be referred to as AIoT-TA.

[0242] To determine the location of AIoT devices and / or terminal devices, the service area of ​​the core network is divided into multiple AIoT-TAs. Each AIoT-TA can be identified by a Tracking Area Identifier (TAI). Optionally, an AIoT-TA can be based on an AIoT cell, and one AIoT-TA can contain several AIoT Cells under several AIoT-enabled gNBs. The TA where the first device is located refers to the TA where the first device's physical location is located, and the TA where the second device is located refers to the TA where the second device's physical location is located.

[0243] Optionally, AIoT location information can be used to indicate the cell where the first device is located and / or the cell where the second device is located. Here, the cell can be an AIoT cell. An AIoT cell can be a cell specifically designated for AIoT applications.

[0244] Optionally, AIoT location information can also be used to indicate the location of the first and / or second devices at other granularities, without limitation.

[0245] For example, AIoT location information is AIoT cell#4, indicating that the tracking area where the first device and / or the second device is located is the cell identified by AIoT cell#4, or that the cell where the first device and / or the second device is located is the cell identified by AIoT cell#4. Here, AIoT cell#4 is the identifier of an AIoT cell.

[0246] Optionally, the AIoT location information can be indicated to the first device by the AIoTF after the first device requests authentication and authorization from the AIoTF to become a UEreader; the first device can also obtain the AIoT location information through other means, without any restrictions.

[0247] Optionally, AIoT location information may include, but is not limited to, at least one of the following:

[0248] (1) The UEreader identifier (ID) of the first device;

[0249] (2) The RAN ID of the access network to which the first device is connected;

[0250] (3) Environmental Internet of Things cell ID (AIoT cell ID).

[0251] The UE reader ID can be configured to the first device after the fourth device authenticates the first device as the UE reader. The UE reader ID can be associated with the location of the first device and / or the second device.

[0252] The access network identifier to which the first device connects is associated with the location of the first device and / or the second device.

[0253] The AIoT cell ID included in the AIoT location information is used to indicate the tracking area or cell where the first device and / or the second device is located. The tracking area indicated by the AIoT cell ID is at the cell level.

[0254] AIoT location information can be used by the second device to determine whether the mobility registration conditions are met. The method for determining whether the mobility registration conditions are met can be found in the description of step S702.

[0255] Filtering criteria are used to select second devices that can respond to the registration activation message. Multiple second devices may exist within the broadcastable area of ​​the registration activation message. The first device may need to perform inventory checks or other operations on second devices of a specified type, group, or range among these multiple second devices. After receiving the registration activation message, multiple second devices determine whether to respond to it based on the filtering criteria.

[0256] Optionally, filtering criteria may include, but are not limited to, at least one of the following:

[0257] (1) Group identifier;

[0258] (2) Equipment type;

[0259] (3) Business type;

[0260] (4) Company information;

[0261] (5) Brand information.

[0262] Accordingly, the second device locally stores its own descriptive information. The second device can compare at least one stored descriptive information with at least one piece of information in the Filtering criteria to determine whether to respond to the registration activation message. For example, if the second device stores a group identifier, it compares the stored group identifier with the group identifier in the Filtering criteria; if they match, it determines whether to respond to the registration activation message. Similarly, if the second device stores the types of services it can support, it compares the stored service types with the service types in the Filtering criteria; if they match, it determines whether to respond to the registration activation message. Furthermore, if the second device stores its own device type information, company information, and brand information, it compares these three pieces of information with the device type information, company information, and brand information in the Filtering criteria respectively; if all three pieces of information match, it determines whether to respond to the registration activation message.

[0263] It is understood that the registration activation message sent by the first device to the second device carries the first time and / or AIoT location information. Since the first time is the time when the first device sends the registration activation message, and the AIoT location information is used to indicate the location of the first device and / or the second device, the second device does not need to save and maintain a list of registered second devices, nor does it need to carry information about multiple second devices that have registered to the network in the registration activation message. This enables the second device to respond to the registration activation message and initiate the registration process, and reduces the processing burden of the first device.

[0264] S702, the second device responds to the registration activation message and sends a first message to the first device. The first message is used to request registration on the network. The registration type requested in the first message is determined based on the stored registration status.

[0265] The second device sends a first message to the first device so that the first device can forward the first message.

[0266] The first message is sent by the second device when initiating the registration process. Optionally, the first message can be encapsulated in the first NAS PDU and transmitted between the second and fourth devices; the first NAS PDU can be forwarded between the second and fourth devices via the first and third devices; the first and third devices can transparently transmit the first NAS PDU without reading the data packets in the first NAS PDU, or the first and third devices can read the unencrypted information in the first NAS PDU, but cannot read the encrypted information in the first NAS PDU.

[0267] In one possible implementation, the information carried by the first message may include, but is not limited to, at least one of the following:

[0268] 1. Registration type;

[0269] 2. Permanent Device ID;

[0270] 3. Device capability;

[0271] The registration type in the first message refers to the registration type requested in the first message. The registration type in the first message can be initial registration, periodic registration, or mobile registration. For a description of these three types of registration, please refer to the section on registration types for AIoT devices in the aforementioned related concepts and terminology.

[0272] The permanent device identifier in the first message, also known as the permanent ID, refers to the permanent device identifier of the second device, used to uniquely identify the second device. In this embodiment, the permanent device identifier of the second device can be used by the fourth device to authenticate the second device.

[0273] The equipment capabilities mentioned in the first message refer to the equipment capabilities of the second device. Optionally, the equipment capabilities of the second device may include, but are not limited to, at least one of the following: security capabilities, power storage capabilities, supported service types, operating frequencies, and equipment types.

[0274] Optionally, security capabilities may include, but are not limited to, at least one of the following: supported encryption and integrity protection algorithms, and security materials for authentication. For example, the encryption algorithm supported by the second device may be, but is not limited to, a symmetric encryption algorithm, and the security material for authentication may be, but is not limited to, a security certificate.

[0275] Optionally, the energy storage capacity may include the maximum amount of electricity that the second device can store.

[0276] Optionally, supported business types may include, but are not limited to, at least one of the following: inventory, command. Commands may include read operations, write operations, disable operations, etc.

[0277] Optionally, the supported business frequency can be the frequency of inventory checks, etc.

[0278] Optionally, the device type may include, but is not limited to, tags, sensors, etc. Optionally, the device type may also be a device type categorized based on its energy storage capacity and signal transmission capability, for example, including but not limited to the following three device types:

[0279] Device type 1; peak power consumption is approximately 1 microwatt, with energy storage capability. The device has no internal downlink or uplink amplification. Uplink transmission relies on an externally provided carrier wave for echo scattering.

[0280] Device type 2a; peak power consumption is approximately several hundred microwatts, with energy storage capability. The device has internal downlink and / or uplink amplification. Uplink transmission relies on an externally provided carrier wave for echo scattering.

[0281] Device type 2b: Peak power consumption is several hundred microwatts, with energy storage capability. The device has internal downlink and / or uplink amplification. Uplink transmission is generated internally by the device.

[0282] When the first message is encapsulated in the first NAS PDU, in addition to carrying information such as registration type, permanent device identifier, and / or device capabilities, the first NAS PDU may also carry the following information:

[0283] 4. Message type.

[0284] The message type in the first NAS PDU is used to indicate the message type of the first NAS PDU. The message type of the first NAS PDU can be a registration request.

[0285] In one possible implementation, before the second device sends the first message to the first device, the second device further performs the following operation: the second device determines the registration type of the registration request in the first message based on the registration status stored in the second device.

[0286] The second device, based on the stored registration status, determines the registration type of the first message request for registration, which may include the following three cases:

[0287] Scenario 1-1: When the second device is not registered on the network, the registration type is initial registration;

[0288] In cases 1-2, if the second device has already registered on the network and meets the periodic registration conditions, the registration type is periodic registration.

[0289] In cases 1-3, if the second device has already registered on the network and meets the mobility registration requirements, the registration type is mobility registration.

[0290] In cases 1-4, if the second device has already registered on the network and meets the periodic registration and mobility registration conditions, the registration type is mobility registration.

[0291] The second device's registration status is "not registered on the network," meaning the first device has never registered on the network, including initial registration, periodic registration, and mobility registration. This can also be understood as the first device not having performed initial registration on the network. Therefore, the second device needs to initiate the initial registration process, i.e., the second device responds to the registration activation message by sending a first message to the first device, requesting initial registration as the registration type.

[0292] The second device's registration status is "already registered on the network," indicating that the first device has already completed initial registration on the network. Therefore, the second device also needs to determine whether the periodic registration conditions and / or mobility registration conditions are met. The periodic registration conditions are used by the second device to determine whether to initiate a periodic registration process. The mobility registration conditions are used by the second device to determine whether to initiate a mobility registration process. When both the periodic registration conditions and the mobility registration conditions are met, mobility registration takes precedence over periodic registration because it requires updating more information, such as the second device's location information.

[0293] It is understandable that the second device can easily determine whether to initiate the initial registration process by judging its own stored registration status, thus avoiding the second device repeatedly initiating the initial registration process due to multiple first devices periodically sending broadcast registration activation messages. This is suitable for registration scenarios of AIoT devices.

[0294] In some embodiments, the second device may determine whether the periodic registration conditions are met by: the second device determining whether the periodic registration conditions are met based on the first time carried in the registration activation message, the time of the most recent successful registration stored, and the storage period duration.

[0295] The most recent successful registration time is the time when the second device most recently successfully registered with the network. Optionally, the most recent successful registration time can be the time when the fourth device most recently authenticated the second device, or the time when the fourth device most recently sent a third message, returned by the fourth device to the second device. For example, the fourth device carries the most recent successful registration time information in the third message and forwards it to the second device through the third device and the first device. Optionally, the most recent successful registration time can be the time when the third device most recently received a fourth message carrying the third message, sent by the third device to the second device. For example, the third device sends the most recent successful registration time information to the second device through the first device. Optionally, the most recent successful registration time can be the time when the first device most recently received a second RRC message carrying the third message, sent by the first device to the second device. Optionally, the most recent successful registration time can be the time when the second device most recently received a third message. Further descriptions of the third message, fourth message, and second RRC message can be found in the subsequent descriptions of execution steps S705, S706a, and S707.

[0296] The period duration stored by the second device is the duration of the period during which the second device was most recently configured to perform periodic registration. The duration of the periodic registration period can be configured to the second device by a core network element, for example, by a fourth device or other AIoTF.

[0297] Optionally, the second device determines that the periodic registration condition is met when the sum of the most recent successful registration time and the period duration stored is greater than or equal to the first time; or, the first device determines that the periodic registration condition is not met when the sum of the most recent successful registration time and the period duration stored is less than the first time.

[0298] If the sum of the time and duration of the most recent successful registration is greater than or equal to the first time, it can also be understood as the sum of the time and duration of the most recent successful registration being later than or equal to the first time. If the sum of the time and duration of the most recent successful registration is less than the first time, it can also be understood as the sum of the time and duration of the most recent successful registration being earlier than the first time.

[0299] It is understandable that after the second device performs a judgment on the stored registration status, it determines that the periodic registration conditions are met based on the first time carried in the registration activation message and the stored time and period of the most recent successful registration. Thus, it effectively initiates the periodic registration process. Since the registration activation message carries the first time that the first device sent the registration activation message, and the first time is maintained by the first device, for different second devices, the first time broadcast by the first device at the same time is the same. The first device does not need to save, maintain, and broadcast different information for judging the periodic registration conditions for different second devices, which reduces the processing burden of the first device and the communication load between the first and second devices. It also enables the second device to effectively initiate periodic registration, so that the network side can promptly grasp the latest device location, related service nodes, and other device information, understand the device reachability status, and facilitate quickly paging the second device when there is a downlink AIoT service request for the device.

[0300] In addition, considering that time formats such as Coordinated Universal Time (UTC) occupy a large amount of memory (for example, UTC time is about 4-7 bytes long), and the second device does not need to store accurate time information (for example, it does not need to store time information such as year and month), in order to reduce the length of time information and save space occupied in the second device, the time format used for the first time, the time of the most recent successful registration, and the period duration can be in hours or minutes.

[0301] 1. Using hours as the time unit, time information such as the first time, the time of the most recent successful registration, and the duration of the cycle can be represented by integers between 0 and 23.

[0302] For example, if the most recent successful registration time is 7:08, and the second device stores only the hour digit of this time (represented by 7), and the period duration is 8 hours (represented by 8), and the first time is 15:03, then the first time carried in the registration activation message (also represented by the hour digit, 15) is greater than 15. This means the sum of the most recent successful registration time and the period duration is later than the first time, satisfying the periodic registration condition. As another example, if the most recent successful registration time is 23:00 (represented by 23), and the period duration is 8 hours (represented by 8), then the first time should be after (23+8) mod 24 = 7 o'clock before the second device responds to the registration activation message and sends the first message. "Mod" represents the modulo operation.

[0303] 2. Using minutes as the time unit, time information such as the first time, the time of the most recent successful registration, and the duration of the cycle can be represented as integers between 0 and 1437.

[0304] For example, if the most recent successful registration time is 7:08, and the timer starts at 00:00 of the same day, 7:08 is converted to 7*60+8=548, so the most recent successful registration time stored on the second device is represented as 548. The cycle duration is 8 hours, which is converted to 60*8=480, so the cycle duration stored on the second device is represented as 480. The first time is 15:03, which is converted to 60*15+3=703. Therefore, (548+480) is greater than 703, meaning the sum of the most recent successful registration time and the cycle duration is later than the first time, satisfying the periodic registration condition. As another example, if the most recent successful registration time is 23:00, represented as 1380, and the cycle duration is 8 hours, represented as 480, then the first time should be after (1380+480) mod 1440=420, that is, after 7:00, before the second device responds to the registration activation message and sends the first message.

[0305] It is understandable that the second device can effectively determine whether the periodic registration conditions are met based on the stored time and period duration of the most recent successful registration and the first time carried in the registration activation message. This eliminates the need for the first device to maintain and send complex and numerous time information or other information used to determine whether the periodic registration conditions are met, thus simplifying the process of the second device initiating periodic registration and reducing the processing burden on the first device.

[0306] In other embodiments, the second device may determine whether the mobility registration conditions are met by the following method: the second device determines whether the mobility registration conditions are met based on the AIoT location information carried in the registration activation message and the stored environmental Internet of Things registration area (AIoT-RA) information.

[0307] The AIoT-RA information stored by the second device indicates the RA most recently assigned to the second device. For example, the AIoT-RA information is registration area information assigned to the second device by a core network element (e.g., a fourth device, or another AIoTF) during previous registrations. This registration area information can be a TAI list, where each TAI indicates one or more TAs. These TAs constitute the registration area of ​​the second device, and they are located within the service range of the core network element that assigned the RA to the second device. Alternatively, the registration area information assigned to the second device by the core network element can be one or more AIoT cell IDs. The AIoT cells identified by these AIoT cell IDs constitute the registration area of ​​the second device, and they are located within the service range of the core network element that assigned the RA to the second device. The core network element that assigned the RA to the second device can be the fourth device or another AIoTF.

[0308] The granularity of the location indicated by the AIoT location information carried in the registration activation message is the same as the granularity of the registration area indicated by the AIoT-RA information stored by the second device. For example, the AIoT-RA most recently allocated by the fourth device to the second device includes multiple AIoT cells, and the AIoT-RA information stored by the second device consists of multiple AIoT cell IDs; correspondingly, the location of the first device and / or the second device contains one AIoT cell, and the AIoT location information carried in the registration activation message is one AIoT cell ID. Each AIoT cell among the multiple AIoT cells included in the registration area indicated by the AIoT-RA information is the same size as the AIoT cell included in the location indicated by the AIoT location information.

[0309] Optionally, the second device determines that the mobility registration conditions are met in response to the fact that the location indicated by the AIoT location information carried in the registration activation message does not belong to the registration area indicated by the AIoT-RA information stored in the second device; or, the second device determines that the mobility registration conditions are not met in response to the fact that the location indicated by the AIoT location information belongs to the registration area indicated by the AIoT-RA information.

[0310] If the second device determines that the location indicated by the AIoT location information does not belong to the registration area indicated by the AIoT-RA information, it can be determined that the second device has moved out of the AIoT-RA most recently allocated to the second device by the CN, and needs to perform mobility registration so that the CN can obtain the location information of the second device in a timely manner; if the second device determines that the location indicated by the AIoT location information belongs to the AIoT-RA indicated by the AIoT-RA information, it can be determined that the second device has not moved out of the AIoT-RA most recently allocated to the first device by the CN, and does not need to perform mobility registration.

[0311] For example, the AIoT-RA information stored in the second device is {AIoT cell#1, AIoT cell#2, AIoT cell#3}, and the AIoT location information carried in the registration activation message is {AIoT cell#4}. AIoT cell#1, AIoT cell#2, AIoT cell#3, and AIoT cell#4 are different AIoT cell IDs. It can be seen that the location indicated by the AIoT location information does not belong to the registration area indicated by the AIoT-RA information, thus satisfying the mobility registration conditions.

[0312] For example, the AIoT-RA information stored in the first device is {AIoT cell#1, AIoT cell#2, AIoT cell#3}, and the AIoT-TA information carried in the registration activation message is {AIoT cell#3}. It can be seen that the location indicated by the AIoT location information belongs to the registration area indicated by the AIoT-RA information, and does not meet the mobility registration conditions.

[0313] It is understandable that after judging the registration status stored, the second device determines that the mobility registration conditions are met based on the AIoT location information carried in the registration activation message and the stored AIoT-RA information, and effectively initiates the periodic registration process. Since the AIoT location information is obtained and maintained by the first device, and the AIoT location information broadcast by the first device at the same time is the same for different second devices, the first device does not need to save, maintain and broadcast different information for judging mobility registration conditions for different second devices. This reduces the processing burden of the first device and the communication load between the first device and the second device. Moreover, the second device can effectively initiate mobility registration so that the second device can promptly inform the network side of its own location changes, which is convenient for the network side to perform mobility management on the second device.

[0314] Optionally, the registration status, the time of the most recent successful registration, the period duration, and the AIoT-RA information can be stored in the non-volatile memory (NVM) in the second device, so that this information can still be stored in the second device after the second device loses power and can be reused to determine the registration type of the first message request registration.

[0315] In addition, there is another scenario 1-5: if the second device has already registered on the network but does not meet the periodic registration conditions or the mobility registration conditions, then the second device will not respond to the registration activation message, that is, it will not initiate the registration process and will not send the first message to the first device.

[0316] S703, the first device sends a first RRC message to the third device, the first RRC message carrying the first message.

[0317] The first device sends a first RRC message to the third device to enable the forwarding of the first message through the third device. For example, the first RRC message carries a first NAS PDU, and the first device sends the first RRC message to the third device to enable the forwarding of the first NAS PDU through the third device.

[0318] In one possible implementation, the information carried by the first RRC message may further include at least one of the following:

[0319] 1. First information;

[0320] 2. Second information;

[0321] 3. The UEreader ID of the first device.

[0322] The first information is used to instruct the fourth device. The third device can send a second message carrying the first information to the fourth device based on the first information.

[0323] The second information is used to instruct the first device. In embodiments of this application, the second information can be used by the third device to determine the AMF (Advanced Feature Provider) for forwarding the second message. The AMF for forwarding the second message can be the AMF serving the first device. The second message carries the first message.

[0324] Optionally, the second information may be the identification information of the first device. The identification information of the first device may be assigned to the first device by the operator; or it may be assigned to the first device by the core network when the first device registers with the network, for example, by the AMF. For example, the identification information of the first device may be a 5G Globally Unique Temporary Identifier (5G-GUTI), or a simplified 5G Globally Unique Temporary Identifier (5G-S-Temporary Mobile Subscriber Identity, 5G-S-TMSI), etc., without limitation. Further descriptions of the first information, second information, and second message can be found in the description of step S704.

[0325] The UEreader ID of the first device can be assigned to the first device by the fourth device after the first device authenticates itself as a UEreader. The UEreader ID can be used to identify the UEreader.

[0326] In one possible implementation, the first device may send a first RRC message to the third device based on the RRC state. The first device sending the first RRC message to the third device based on the RRC state can be performed by at least one of the following four methods:

[0327] In method 1-1, the first device, in response to being in RRC-Connected, sends a first RRC message to the third device. The first RRC message can be a dedicated RRC message.

[0328] The dedicated RRC message here is designed or defined for the transmission of the first message and is used to carry the first message.

[0329] In method 1-2, the first device responds to being in RRC-Inative by sending a first RRC message to the third device. The first RRC message is either an RRC Resume Request message or an RRC Resume Complete message.

[0330] In methods 1-3, the first device, in response to being in RRC-Idle, sends a first RRC message to the third device. The first RRC message is an RRC Setup Complete message.

[0331] In methods 1-4, the first device, in response to being in RRC-Inative or RRC-Idle, delays sending the first RRC message to the third device after receiving the first message from the second device.

[0332] For methods 1-2, after receiving the first message from the second device, the first device can initiate an interactive process to switch from RRC-Inactive to RRC-Connected, and send the RRC Resume Complete message exchanged in the interactive process as the first RRC message to the third device.

[0333] Optionally, for methods 1-2, after receiving the first message from the second device, the second device can send a first RRC message to the third device through the SDT mechanism. Specifically, the first device can send the RRC Resume Request exchanged during the SDT mechanism's interaction flow as the first RRC message to the third device.

[0334] For methods 1-3, after receiving the first message, the second device can initiate an interactive process to switch from RRC-Idle to RRC-Connected, and send the RRC Setup Complete message from this interactive process to the third device as the first RRC message.

[0335] For the interaction process of switching from RRC-Inactive to RRC-Connected, the interaction process of the SDT mechanism, and the interaction process of switching from RRC-Idle to RRC-Connected, please refer to the above explanation of relevant concepts and terms, which will not be repeated here.

[0336] It is understandable that for modes 1-1, 1-2, and 1-3, the first device can adapt to its own RRC state and effectively send the first RRC message. For the first device in RRC-Inactive or RRC-Idle, it can reuse the RRC messages in the interaction process from RRC-Inactive or RRC-Idle to RRC-Connected, or reuse the RRC messages in the interaction process of the SDT mechanism, to carry the first message, avoiding the communication load caused by sending the first message separately, and effectively transmitting the first message.

[0337] For methods 1-4, the first device delaying the transmission of the first RRC message means that the first device sends the first RRC message to the third device after a certain period of time after receiving the first message from the second device.

[0338] Optionally, methods 1-4 can be applied to scenarios where the registration type of the first message request for registration is periodic registration. In methods 1-4, if the first message is encapsulated in the first NAS PDU, and the registration type in the first message is unencrypted information, it can be read by the first device. After determining that the registration type is periodic registration, the first device can implement methods 1-4.

[0339] Please refer to Figure 8, which is a flowchart illustrating a method for enabling a first device to delay sending a first RRC message according to an embodiment of this application. As shown in Figure 8, methods 1-4 can achieve the delay of sending the first RRC message by the first device in the following two ways:

[0340] In method 1-4-1, during the initial registration process of the second device, the registration response message returned by the fourth device carries indication information for indicating that the second device supports Deferring of periodic registration updating.

[0341] The registration response message here can be a third message, which is used to send the registration result back to the second device. For details on third messages, please refer to the description of step S705.

[0342] During this periodic registration process, the second device sends a first message to the first device, which carries first indication information. This first indication information instructs the second device to support delayed periodic registration updates. After receiving the first message, the first device, which is in RRC-Inative or RRC-Idle mode, can delay sending the first RRC message based on the first indication information.

[0343] In method 1-4-1, the fourth device may instruct the second device to support delayed periodic registration updates based on the device type of the second device and / or the service type supported by the device.

[0344] The description of the device type and the service types supported by the device for the second device can be found in the description of the device capabilities in the first message in step S702, which introduces the supported service types and device types.

[0345] For example, if the second device is device type 1, and device type 1 devices have a simple structure and low energy storage capacity, its ability to register and connect to the network may be reduced. The fourth device can instruct the second device to support delayed periodic registration updates. Alternatively, if the second device is limited by its device capacity and only supports inventory operations, and the inventory frequency is limited, the fourth device can instruct the second device to support delayed periodic registration updates to reduce the number of times the second device needs to register repeatedly.

[0346] Optionally, the registration response message returned by the fourth device can be forwarded to the second device through the third device and the first device.

[0347] Optionally, the registration response message returned in method 1-4-1 can also be another AIoTF besides the fourth device, which is used to perform initial registration of the second device before the second device performs this registration.

[0348] In method 1-4-2, during the process of authenticating as a UEreader to the fourth device, the first device sends a first UEreader authentication message (authentication msg) to the fourth device. This first UEreader authentication msg carries the information "Deferring of periodic registration updating is required." The fourth device authorizes the first device to defer periodic registration updating and returns a second UEreader authentication msg to the first device. This second UEreader authentication msg carries the information "Deferring of periodic registration updating is allowed." After receiving the first message from the second device, the first device, which is in RRC-Inative or RRC-Idle mode, can delay sending the first RRC message to the third device.

[0349] Optionally, the first UEreader authentication msg can be forwarded to the fourth device through the third device, and the second UEreader authentication msg can be forwarded to the first device through the third device.

[0350] In some embodiments, for modes 1-4-1 and 1-4-2, the first device delays sending the first RRC message, including but not limited to at least one of the following three cases:

[0351] Case 2-1: The first device delays sending the first RRC message until the next time the first device performs periodic registration;

[0352] Case 2-2: The first device delays sending the first RRC message until the next paging opportunity of the first device;

[0353] In cases 2-3, when the first device moves out of the RAN Notification Area (RNA) and needs to perform an RNA update, it sends the first RRC message.

[0354] Cases 2-1 and 2-2 apply to the first device in RRC-Inative or RRC-Idle. Case 3-3 applies to the first device in RRC-Inative.

[0355] In scenario 2-1, after the first device, which is in RRC-Inative or RRC-Idle state, times out due to the periodic registration timer (e.g., T3512, with a default timeout of 54 minutes), it requests the third device to establish an RRC connection between the first device and the third device. The first device sends a first message and a UE NAS PDU to the third device within the first RRC message. The UE NAS PDU carries a registration request message from the first device requesting registration with the network, and the periodic registration timer is used by the first device for periodic registration.

[0356] In scenario 2-2, the first device, in either RRC-Inative or RRC-Idle mode, listens to the Physical Downlink Control Channel (PDCCH) at a specific paging timing. If it receives a paging message addressed to itself, it requests the establishment of an RRC connection between itself and the access network equipment from the third device, and sends an RRC setup complete message (i.e., the first RRC message) carrying the first message to the third device. The specific paging timing can be the paging timing that is closest to the time when the first device receives the first message from the second device.

[0357] In cases 2-3, the first device in the RRC-Inative state moves out of the RNA and needs to perform RNA update. It then actively sends an RRC resume request message to the third device for RNA update. The RRC resume request message carries the first message and is the first RRC message.

[0358] For descriptions of the RRC setup complete message and the RRC resume request message, please refer to the explanation of the interaction process from RRC-Inactive to RRC-Connected and from RRC-Idle to RRC-Connected in the aforementioned related concepts and terminology.

[0359] Optionally, for mode 1-4-1, the first indication information may also carry a first duration, which is the maximum duration for which the first device can delay sending the first RRC message. The maximum duration for which the first device can delay sending the first RRC message refers to the maximum duration for which the first device can delay sending the first RRC message to the third device after receiving the first message from the second device.

[0360] After receiving the first message, the first device in RRC-Idle queries the time of the next periodic registration of the first device and the time of the next paging of the first device; based on the first duration, it selects to delay until the time of the next periodic registration of the first device or the time of the next paging of the first device, and sends the first RRC message.

[0361] For example, the first device in RRC-Idle can choose the duration with the smallest difference from the first duration between the second and third durations, and delay sending the first RRC message to the third device by that duration. The second duration is the interval between the time when the first device will next periodically register and the time when the first device receives the first message from the second device, and the third duration is the interval between the time when the first device will next page and the time when the first device receives the first message from the second device.

[0362] For example, the second duration is 30 minutes, the third duration is 1 hour, and the first duration is 20 minutes. The interval between the second duration and the first duration is shorter than the interval between the third duration and the first duration. The first device delays sending the first RRC message to the third device until the next periodic registration time.

[0363] Optionally, for method 1-4-2, after the fourth device permits the first device to delay periodic registration updates, it can also instruct the first device to execute a time period for delaying the transmission of the first RRC message. Optionally, this time period is the period during which the first device suspends or prohibits the transmission of the first RRC message, thus the first device cannot send the first RRC message during this time period and needs to delay sending it to another time period outside of this period. For example, if this time period is from 10:00 to 24:00, which is a peak user communication period, the first device needs to delay sending the first RRC message to a low-peak user communication period after 24:00. Optionally, this time period can be the time period during which the first device is allowed to send the first RRC message, and the time when the first device receives the first message from the second device is before this time period, thus the first device needs to wait for this time period to arrive before sending the first RRC message to the third device. For example, if this time period is from 0:00 to 10:00, which is a low-peak user communication period, and the first device receives the first message from the second device at 20:00, it needs to delay sending the first RRC message to the third device after 0:00.

[0364] It is understandable that for periodic registration, the second device does not experience a significant location change. The second device only needs to confirm with the fourth device that it is still in the most recently assigned AIoT-RA and maintain its connection with the network. Therefore, the second device does not have high requirements for communication latency during periodic registration. The first device, which is in RRC-Idle or RRC-Inactive, delays the first RRC message until the time of the first device's next periodic registration or the time of the first device's next paging, avoiding the large processing overhead and resource consumption caused by the first device immediately switching to RRC-Connected or adopting the SDT mechanism. Alternatively, the first device, which is in RRC-Idle or RRC-Inactive, can delay the transmission according to a specified time period, which can avoid the peak time period of user communication and send the first RRC message during the off-peak time period of user communication, thus making reasonable use of communication resources.

[0365] S704, the third device sends a second message to the fourth device, the second message carrying the first message.

[0366] The third device can encapsulate the first message at the first protocol layer to obtain the second message.

[0367] For example, the second message carries the first NAS PDU. The third device forwards the first message to the fourth device by sending the second message.

[0368] In one possible implementation, the information carried by the second message may also include at least one of the following:

[0369] 1. Identification information of the first device;

[0370] 2. The UEreader ID of the first device;

[0371] 3. Location information of the first device;

[0372] 4. Identification information of the third device.

[0373] The identification information of the first device and the UEreader ID of the first device carried in the second message are obtained by the third device from the first device, for example, from the first RRC message. The second information in the first RRC message is the identification information of the first device.

[0374] The location information of the first device is the location information of the first device, such as the New Radio Cell Global Identifier (NR-CGI) of the first device. The location information of the first device can be obtained by the third device from the context of the first device stored in its own memory, and the third device can establish the context of the first device when the first device registers for network access; or, the location information of the first device can be notified to the third device by the first device.

[0375] The identification information of the third device is used to identify the third device or the access network corresponding to the third device. For example, the identification information of the third device can be the Access Network Identifier (RAN ID).

[0376] In one possible implementation, the third device can send a second message to the fourth device via the AMF. The AMF is used to forward the second message from the third device to the fourth device.

[0377] The third device may determine the AMF used to forward the second message by at least one of the following two methods:

[0378] Method 2-1: The third device determines the AMF based on the second information carried by the first RRC message.

[0379] Method 2-2: The third device receives the first authentication information from the AMF and determines the AMF as the AMF used to forward the second message. The first authentication information is used to indicate that the first device is authenticated as a UE Reader.

[0380] For a description of the first authentication information, please refer to the introduction of intermediate nodes in the topology 2 architecture in the aforementioned related concepts and terminology.

[0381] For method 2-1, the first information may include identification information of the AMF used to forward the second message. For example, the first information is the 5G-GUTI or 5G-S-TMSI of the first device, including a globally unique AMF identifier (GUAMI). The third device may determine the AMF currently serving the first device based on the identification information of the AMF included in the first information, and forward the second message to the fourth device through the AMF currently serving the first device.

[0382] For method 2-2, after the fourth device completes the authentication and authorization of the first device, the AMF receives the first authentication information from the fourth device. The AMF will forward the first authentication information to the third device. After receiving the first RRC message, the third device will default to selecting the AMF that previously sent the first authentication information to itself as the forwarding node for forwarding the second message.

[0383] In one possible implementation, the AMF will also forward the second message from the third device to the fourth device based on the information from the fourth device.

[0384] In this case, the AMF may acquire information about the fourth device in at least one of the following two ways:

[0385] In method 3-1, when the third device sends the first RRC message, it will notify the AMF of the first information, which is obtained by the third device from the first RRC message.

[0386] In method 3-2, when the third device sends the first message, it will notify the AMF of the second information. The second information is obtained by the third device from the first RRC message. Based on the second information, the AMF obtains the subscription data of the first device as UEreader from the UDM or the first network element, and obtains the information of the fourth device that authenticates the first device as UEreader from the subscription data.

[0387] For method 3-1, the first information can be the information of the fourth device that authenticates the first device as a UEreader. After authenticating the first device as a UEreader, the fourth device can send its own information to the first device.

[0388] For methods 3-1 and 3-2, the information of the fourth device may include, but is not limited to, the name (AIoTF Name), the identifier (AIoTF ID), and / or the address (AIoTF Address) of the fourth device. For example, the AMF can look up the address of the fourth device in the NRF based on the name and / or identifier of the fourth device, and forward the second message to the fourth device based on the address. Alternatively, the AMF can forward the second message to the fourth device based on the address of the fourth device. Here, the address of the fourth device can be the Internet Protocol Address (IP address) of the fourth device.

[0389] It is understood that the third device can effectively send the second message to the fourth device based on the first information and / or the second information from the first device.

[0390] S705, the fourth device responds to the first message and sends a fourth message to the third device, the fourth message carrying the third message.

[0391] The third message is used to send the registration result back to the second device.

[0392] Optionally, before executing step S705, the fourth device may decapsulate the second message at the first protocol layer to obtain the first message. For example, the fourth device may decapsulate the second message at the first protocol layer to obtain the first NAS PDU.

[0393] The third message can be seen as a registration response to the first message. A registration acceptance message in the third message indicates that the fourth device accepts the registration attempt by the second device. A registration rejection message in the third message indicates that the fourth device rejects the registration attempt by the second device.

[0394] Optionally, the third message can be encapsulated in the second NAS PDU and transmitted between the fourth device and the second device; the second NAS PDU can be forwarded between the fourth device and the second device through the third device and the first device; the third device and the first device can transparently transmit the second NAS PDU without reading the data packets in the second NAS PDU, or the third device and the first device can read the unencrypted information in the second NAS PDU, but cannot read the encrypted information in the second NAS PDU.

[0395] Optionally, the fourth device may encapsulate the third message at the first protocol layer to obtain the fourth message. For example, the fourth device may encapsulate the second NAS PDU at the first protocol layer to obtain the fourth message.

[0396] In one possible implementation, before sending the fourth message to the third device, the fourth device also performs the following operations: 1. The fourth device allocates AIoT-RA and / or configures the cycle duration for the second device.

[0397] For example, the fourth device can select a PCF (Programmable Validation Function), which can be used to allocate AIoT-RA and / or configure the period duration for the second device; obtain access management (AM) related control policies from the PCF, for example, obtain control policies that can be used to determine areas where the second device is not allowed to access; and, in response to the first message, allocate AIoT-RA and / or configure the period duration for the second device based on the AM-related control policies. Here, the period duration refers to the duration of the period during which the second device performs periodic registration.

[0398] Therefore, the information carried by the fourth message may also include, but is not limited to, at least one of the following:

[0399] (1) Cycle duration;

[0400] (2) AIoT-RA information.

[0401] The period duration carried by the fourth message is the period duration of the periodic registration configured for the second device, that is, the period duration of the periodic registration configured for the second device by the fourth device in response to the first message, or the period duration of the periodic registration allocated to the second device for this registration.

[0402] The AIoT-RA information carried in the fourth message is used to indicate the registration area assigned to the second device, that is, the registration area assigned to the second device by the fourth device in response to the first message, or the registration area assigned to the second device for this registration.

[0403] Optionally, the fourth device may also perform the following operation: 2. Assign a device core network identifier (CN ID) to the second device.

[0404] The CN ID can be used to identify the second device within the core network. For example, the CN can be used to uniquely identify the second device within the core network. During the subsequent registration process, the second device can replace the Permanent Device ID in the first message sent in response to the registration activation message with the CN ID. This allows the fourth device to authenticate and authorize the second device based on the CN ID, thereby completing the second device's registration and network access. Since the CN ID is shorter than the Permanent Device ID, it avoids the security risks associated with transmitting long identification information over the air interface and also reduces the consumption of air interface resources.

[0405] Therefore, the information carried by the fourth message may include, but is not limited to: (3) CN ID.

[0406] In the case where the third message is encapsulated in the second NAS PDU, in addition to carrying information such as cycle duration, AIoT-RA information and / or CN ID, the second NAS PDU may also carry the following information:

[0407] (4) Message type.

[0408] The message type in the second NAS PDU is used to indicate the message type of the second NAS PDU. The message type in the second NAS PDU can be registration acceptance or registration rejection.

[0409] In another possible implementation, before sending the fourth message to the third device, the fourth device may perform at least one of the following operations in addition to operations 1 and / or 2:

[0410] 3. Verify the identity of the second device;

[0411] 4. After the second device is authenticated, the contracted data of the second device is stored in the UDM or the first network element;

[0412] 5. After the second device is authenticated, register in the UDM or the first network element;

[0413] 6. Establish or update the context of the second device;

[0414] 7. Obtain the context of the second device from the AIoTF that the second device registered most recently;

[0415] 8. Notify the second device to release the context of the most recently registered AIoTF.

[0416] Operations 1-8 performed by the fourth device are all registration processing operations for the second device performed in response to the first message. For operation 3, the fourth device can authenticate the second device based on the Permanent Device ID or CN ID carried in the first message. For example, the fourth device can determine the credential holder based on the Public Land Mobile Network information (PLMN info) contained in the Permanent Device ID or CN ID, where the credential holder stores the second device's security certificate; obtain the second device's security certificate from the credential holder based on the Permanent Device ID or CN ID; compare the security certificate in the first message with the security certificate obtained from the credential holder; if the two security certificates are the same, the authentication of the second device is successful. Optionally, the authentication process of the fourth device for the second device can be implemented in conjunction with other core network elements. For example, the fourth device can authenticate the second device in conjunction with AUSF and UDM, or the fourth device can authenticate the second device in conjunction with AUSF and the first network element. For a further description of the security certificate in the first message, please refer to the description of step S702.

[0417] Optionally, during the authentication process of the second device, the fourth device may also check the device capabilities carried in the first message, so as to store the device capability information of the second device as the contract data of the second device in the UDM or the first network element.

[0418] For operation 4, the subscription data of the second device stored in the UDM or the first network element may include, but is not limited to, at least one of the following:

[0419] (1) Equipment information, such as, but not limited to, the equipment identification information of the second device, the equipment type of the second device, the registration status of the second device, the company information of the second device, the public land mobile network information list (PLMN list) signed by the second device, and the equipment capabilities of the second device.

[0420] (2) Security and authentication information, such as, but not limited to, the encryption and integrity protection algorithms supported by the second device, the keys used by the second device, the security materials of the second device, and the authentication results of the second device by the fourth device. The security materials of the second device can be used to authenticate the second device; for example, the security materials are the security certificates of the second device.

[0421] (3) Associated nodes, such as, but not limited to, the node information on the AIoT service path, including the last serving UEreader, the first device, the AMF, the fourth device, etc.

[0422] (4) Location information, such as, but not limited to, the AIoT cell identifier information where the second device is located, the identifier information of the third device connected by the second device through the first device, and the latitude and longitude information of the location of the second device.

[0423] (5) Service information, such as, but not limited to, service status, supported service types, and supported service frequencies. For example, service status could indicate whether the service is temporarily disabled, supported service types could be inventory checks, commands, etc., and supported service frequencies could be the frequency of inventory checks, etc. Commands could include read operations, write operations, failure operations, etc.

[0424] For operation 5, the fourth device can register with the UDM or the first network element by sending a registration request. This registration request may include the identification information of the second device.

[0425] For operation 6, if the network element in the core network has not established the context of the second device, the context of the second device can be established in the fourth device; if the network element in the core network has already established the context of the second device, the context of the second device can be updated in the fourth device.

[0426] The context of the second device established or updated in the fourth device may include, but is not limited to, at least one of the following:

[0427] (1) Identification information of the second device (AIoT device ID);

[0428] (2) Current location information of the second device, such as, but not limited to, cell information where the second device is located, access network equipment information to which the cell to which the second device belongs, and latitude and longitude information of the location of the second device;

[0429] (3) For the associated nodes of the second device, please refer to the introduction of associated nodes in the contract data of the second device.

[0430] (4) Registration information of the second device, such as, but not limited to, the registration status of the second device, the registration area of ​​the second device (AIoT-RA), and the area where the second device was last registered.

[0431] (5) For security and authentication information of the second device, please refer to the introduction of security and authentication information in the contract data of the second device.

[0432] Information (2)-(5) in the context of the second device belongs to the mobile management (MM) context of the second device.

[0433] For operation 7, if the fourth device is not the AIoTF most recently registered by the second device, then the fourth device does not have the context of the second device. It needs to query the UDM or the first network element for the AIoTF information most recently registered by the second device based on the identification information of the second device, such as the Permanent Device ID or CN ID in the first message. Based on the queried AIoTF information, it queries the NRF for the address of the most recently registered AIoTF. Based on the address of the most recently registered AIoTF, it requests the context of the second device from the most recently registered AIoTF.

[0434] Optionally, the operations performed by the fourth device before sending the third message to the third device may differ depending on the registration type in the first message.

[0435] For registration type initial registration, the fourth device can perform at least one of operations 3-5, 1-2, and 6. Before the second device performs initial registration, the second device has never registered with the core network, and the core network elements do not have the context of the second device; therefore, when performing operation 6, the fourth device establishes the context of the second device.

[0436] For registration type periodic registration, the fourth device may perform at least one of operations 3-5, 1-2, and 6. The second device has already performed initial registration in the core network before performing periodic registration; therefore, when performing operation 6, the fourth device should update the context of the second device.

[0437] For registration types that are mobile registrations, the following two scenarios are possible:

[0438] In scenario 3-1, the fourth device is the core network element that the second device registered most recently.

[0439] In scenario 3-1, the second device last requested registration from the fourth device before this mobility registration, for example, it last requested initial registration, periodic registration, or mobility registration from the fourth device.

[0440] Case 3-2: The fourth device is not the core network element most recently registered by the second device.

[0441] In scenario 3-1, prior to this mobility registration, the second device most recently requested registration from other core network elements besides the fourth device. For example, the fourth device is the first AIoTF, and the second device most recently requested initial registration, periodic registration, or mobility registration from the second AIoTF.

[0442] For scenario 3-1, the fourth device can perform at least one of operations 1, 6, and 2. Since the core network element registered by the second device this time is the same as the core network element registered in the most recent registration, it is not necessary to obtain the AM from the PCF again when performing operation 1. The AIoT-RA and / or configuration period duration can be allocated to the second device based on the AM used by the fourth device in the previous registration process.

[0443] For scenario 3-2, the fourth device can perform at least one of operations 7, 3-5, 8, 1, 6, and 2. Since the core network element being registered by the second device has changed, when performing any of operations 3-5, 1, 6, and 2, the second device re-executes any of operations 3-5, 1, 6, and 2 relative to the previously executed registration process.

[0444] For example, prior to this registration, the core network element had already configured the cycle duration for the second device. During this registration, the fourth device reconfigures the cycle duration for the second device to dynamically adjust it. For instance, if the fourth device determines that the location of the second device has not changed over a longer period of time, it can extend the cycle duration.

[0445] In another possible implementation, the fourth message may not carry a period duration. In this case, after the second device completes this registration, it can use the period duration configured by the core network element for the first device in other registration processes before this registration to determine the periodic registration conditions; and / or, the fourth message may not carry AIoT-RA information. In this case, after the second device completes this registration, it can use the AIoT-RA information allocated by the core network element for the second device in other registration processes before this registration to determine the mobility registration conditions.

[0446] In another possible implementation, the fourth device, in response to the first message, also sends an initial context setup request to the third device.

[0447] The Initial Context Setup Request is used to request a third device to establish a context for the second device.

[0448] Optionally, the initial context setup request can be carried by a fourth message, that is, the fourth message carries both the third message and the initial context setup request.

[0449] After receiving the fourth message, the third device can also perform the following steps:

[0450] S706a, the third device sends a second RRC message to the second device, the second RRC message carrying the third message.

[0451] Optionally, the third device can forward a third message through the second device by sending a second RRC message to the second device. For example, the second RRC message carries a second NAS PDU, and the third device can forward the second NAS PDU through the second device by sending the second RRC message to the second device.

[0452] S706b, the third device sends an initial context establishment response to the fourth device.

[0453] The initial context establishment response is used to indicate the result information of the third device establishing the context of the second device. For example, the initial context response is used to indicate that the third device has successfully established the context of the second device, or to indicate that the third device failed to establish the context of the second device.

[0454] Optionally, the third device may send a fifth message to the fourth device, the fifth message carrying the initial context establishment response. The third device encapsulates the initial context establishment response at the first protocol layer to obtain the fifth message. Correspondingly, the fourth device decapsulates the initial context establishment response at the first protocol layer to obtain the initial context establishment response.

[0455] Before executing S706b, the third device responds to the initial context establishment request and establishes the context of the second device. The information contained in the context established in the third device may be the same as or different from the information contained in the context of the second device established or updated in the fourth device, without limitation.

[0456] It is understandable that after the fourth device responds to the first message and registers the second device, the third device will also respond to the initial context establishment request sent by the fourth device to establish the context of the second device. Thus, the context of the second device is established on both the access network and the core network side, which is conducive to the second device communicating with the network side and accepting the management of the network side.

[0457] S706a can be executed before or after S706b, and S706a and S706b can also be executed simultaneously. This application and this embodiment do not restrict the execution order between S706a and S706b.

[0458] S707, the first device sends a third message to the second device.

[0459] The third message sent by the fourth device is forwarded to the second device through the third device and the first device. For example, the second NAS PDU sent by the fourth device is forwarded to the second device through the third device and the first device.

[0460] Before the second device performs its initial registration, the second device does not store the cycle duration and AIoT-RA information.

[0461] When the second device receives the third message, if the third message carries a period duration, the second device stores that period duration. For example, if the second device does not currently store a period duration, it stores the period duration carried by the third message in the second device's memory. Or, if the second device currently stores a period duration, it updates the currently stored period duration to the period duration carried by the third message.

[0462] If the second message carries AIoT-RA information, the second device stores the AIoT-RA information. For example, if the second device does not currently store AIoT-RA information, the AIoT-RA information carried by the third message is stored in the second device's memory. Alternatively, if the second device currently stores AIoT-RA information, the currently stored AIoT-RA information is updated to the AIoT-RA information carried by the third message.

[0463] It is understood that the period duration and AIoT-RA information stored by the second device are configured to the second device by the fourth device during registration. This information is used by the second device to determine whether the periodic registration conditions or mobility registration conditions are met when subsequently initiating periodic or mobility registration, thereby effectively initiating the periodic or mobility registration process. In response to the first message, the fourth device returns the period duration and / or AIoT-RA information, enabling the second device to subsequently determine whether the periodic registration conditions are met based on the period duration, or whether the mobility registration conditions are met based on the AIoT-RA information, thus allowing the second device to effectively initiate the registration process.

[0464] In the embodiment shown in Figure 7, the second device determines the registration type in the first message based on the stored registration status, thereby effectively initiating the registration process for that registration type and realizing the registration and network access of the AIoT device. The first message sent by the second device is forwarded to the fourth device through the first and third devices, so that the fourth device can process the registration request of the second device, thus effectively realizing the registration and network access of the second device.

[0465] The following examples illustrate the communication registration method provided in this application, focusing on three registration types that the second device can perform: initial registration, periodic registration, and mobility registration.

[0466] Please refer to Figure 9, which is a schematic diagram of the interaction flow of a communication registration method with initial registration type provided in an embodiment of this application. As shown in Figure 9, in this method, the first device is a terminal device, the second device is an AIoT device, the third device is a gNB, and the fourth device is an AIoTF. The method is illustrated by encapsulating the first message in the first NAS PDU and the third message in the second NAS PDU. This method may include, but is not limited to:

[0467] S901, the terminal device periodically sends registration and activation messages to the AIoT device.

[0468] Optionally, the registration activation message may carry at least one of the following information:

[0469] First time;

[0470] AIoT location information;

[0471] Filtering criteria.

[0472] S902, in response to the registration activation message, the AIoT device sends the first NAS PDU to the terminal device.

[0473] The first NAS PDU is used to request registration in the network, and the registration type requested by the first NAS PDU is initial registration.

[0474] Before executing step S902, the AIoT device determines that the stored registration status is not registered on the network.

[0475] Optionally, the first NAS PDU may carry at least one of the following information:

[0476] Message type: Registration request;

[0477] Registration type: Initial registration;

[0478] Permanent equipment identification;

[0479] Equipment capabilities.

[0480] S903, the terminal device sends a first RRC message to the gNB, and the first RRC message carries the first NAS PDU.

[0481] Optionally, the information carried by the first RRC message may also include at least one of the following:

[0482] The first piece of information is used to indicate AIoTF;

[0483] The second piece of information is used to instruct the terminal device;

[0484] The UEreader ID of the terminal device.

[0485] S904, gNB sends a second message to AIoTF, the second message carrying the first NAS PDU.

[0486] The gNB can determine the AMF used to forward the second message, and forward the second message to the AIoTF through the determined AMF.

[0487] In one possible implementation, the gNB can determine the AMF used to forward the second message based on the second information.

[0488] In another possible implementation, the gNB can receive first authentication information from the AMF, and the gNB identifies the AMF as the AMF used to forward the second message. The first authentication information is used to indicate that the terminal device is authenticated as a UE Reader. This implementation is not shown in Figure 9.

[0489] Optionally, the information carried by the second message may also include at least one of the following:

[0490] Identification information of the terminal device;

[0491] UEreader ID of the terminal device;

[0492] Location information of the terminal device;

[0493] gNB identification information.

[0494] S905, AIoTF sends a fourth message to gNB, which carries the second NAS PDU.

[0495] The second NAS PDU is used to send the registration result back to the AIoT device. The message type of the second NAS PDU can be registration acceptance, used to send a message to the AIoT device that the AIoTF has accepted the registration of the AIoT device.

[0496] Optionally, the AIoTF can send a fourth message to the gNB through the AMF determined by the gNB in ​​step S904.

[0497] Before performing step S905, AIoTF may also perform at least one of the following operations:

[0498] Authenticate AIoT devices and check the device capabilities of the AIoT devices carried by the first NAS PDU;

[0499] After the AIoT device is successfully authenticated, the contracted data of the AIoT device is stored in the UDM or the first network element;

[0500] After the AIoT device is successfully authenticated, it is registered in the UDM or the first network element.

[0501] Select PCF to obtain access management-related control policies from PCF;

[0502] Allocate cycle duration and / or AIoT-RA to AIoT devices based on access management-related control policies;

[0503] Assign CN IDs to AIoT devices;

[0504] Establish the context for AIoT devices.

[0505] Optionally, AIoTF can authenticate AIoT devices by the AIoT device in conjunction with AUSF and UDM, or by AUSF and the first network element, where AUSF is not shown in Figure 9.

[0506] Optionally, the information carried by the second NAS PDU may include, but is not limited to, at least one of the following:

[0507] Message type: Registration accepted;

[0508] Cycle duration;

[0509] AIoT-RA information;

[0510] CN ID.

[0511] Optionally, the fourth message may also carry an initial context establishment request. The initial context establishment request is used to request the gNB to establish the context of the AIoTF device.

[0512] S906a, gNB sends a second RRC message to the terminal device, and the second RRC message carries the second NAS PDU.

[0513] In one possible implementation, gNB can also perform:

[0514] S906b, gNB sends a fifth message to AIoTF, which carries the initial context establishment response.

[0515] The initial context establishment response is used to indicate that the gNB has established the context of the AIoT device.

[0516] S907, the terminal device sends a second NAS PDU to the AIoT device.

[0517] For further descriptions of the embodiments shown in Figure 9, please refer to the embodiments shown in Figure 7, which will not be repeated here.

[0518] In the embodiment shown in Figure 9, when the AIoT device receives the registration activation message periodically broadcast by the terminal device, it can determine that the registration type of the first NAS PDU sent to the terminal device for requesting registration is initial registration based on the stored registration status of not registered to the network. This effectively initiates the initial registration process, avoiding the AIoT device repeatedly initiating the initial registration process due to multiple UEreaders periodically sending broadcast registration activation messages around the AIoT device. It also eliminates the need for the terminal device to save and maintain a list of registered devices and to include the list of registered devices in the registration activation message broadcast by the terminal device. This reduces the processing burden of the terminal device and the communication load between the terminal device and the AIoT device, making it suitable for AIoT device registration scenarios.

[0519] Please refer to Figure 10, which is a schematic diagram of the interaction flow of a communication registration method with periodic registration type provided in an embodiment of this application. As shown in Figure 10, in this method, the first device is a terminal device, the second device is an AIoT device, the third device is a gNB, and the fourth device is an AIoTF. The method is illustrated by encapsulating the first message in the first NAS PDU and the third message in the second NAS PDU. This method may include, but is not limited to:

[0520] S1001, the terminal device periodically sends registration and activation messages to the AIoT device.

[0521] Optionally, the registration activation message may carry at least one of the following information:

[0522] First time;

[0523] AIoT location information;

[0524] Filtering criteria.

[0525] S1002, in response to the registration activation message, the AIoT device sends the first NAS PDU to the terminal device.

[0526] The first NAS PDU is used to request registration in the network, and the registration type requested by the first NAS PDU is periodic registration.

[0527] Before executing step S1002, the AIoT device determines that the stored registration status is already registered on the network and meets the periodic registration conditions.

[0528] Optionally, the first NAS PDU may carry at least one of the following information:

[0529] Message type: Registration request;

[0530] Registration type: Periodic registration;

[0531] Permanent equipment identification;

[0532] Equipment capabilities.

[0533] Optionally, the AIoT device determines whether it meets the periodic registration conditions based on the first time carried in the registration activation message, as well as the stored time information of the most recent successful registration and the period duration.

[0534] For example, if an AIoT device determines that the sum of the time of the most recent successful registration and the period duration is greater than or equal to the first time, it determines that the periodic registration conditions are met; or, if an AIoT device determines that the sum of the time of the most recent successful registration and the period duration is less than the first time, it determines that the periodic registration conditions are not met.

[0535] S1003, the terminal device sends a first RRC message to the gNB, and the first RRC message carries the first NAS PDU.

[0536] Optionally, the information carried by the first RRC message may also include at least one of the following:

[0537] The first piece of information is used to indicate AIoTF;

[0538] The second piece of information is used to instruct the terminal device;

[0539] The UEreader ID of the terminal device.

[0540] S1004, gNB sends a second message to AIoTF, the second message carrying the first NAS PDU.

[0541] The gNB can determine the AMF used to forward the second message, and forward the second message to the AIoTF through the determined AMF.

[0542] In one possible implementation, the gNB can determine the AMF used to forward the second message based on the second information.

[0543] In another possible implementation, the gNB can receive first authentication information from the AMF, and the gNB identifies the AMF as the AMF used to forward the second message. The first authentication information is used to indicate that the terminal device is authenticated as a UE Reader. This implementation is not shown in Figure 10.

[0544] Optionally, the information carried by the second message may also include at least one of the following:

[0545] Identification information of the terminal device;

[0546] UEreader ID of the terminal device;

[0547] Location information of the terminal device;

[0548] gNB identification information.

[0549] S1005, AIoTF sends a fourth message to gNB, which carries the second NAS PDU.

[0550] The second NAS PDU is used to send the registration result back to the AIoT device. The message type of the second NAS PDU can be registration acceptance, used to send a message to the AIoT device that the AIoTF has accepted the registration of the AIoT device.

[0551] Optionally, the AIoTF can send a fourth message to the gNB through the AMF determined by the gNB in ​​step S1004.

[0552] Before performing step S1005, AIoTF may also perform at least one of the following operations:

[0553] Authenticate AIoT devices and check the device capabilities of the AIoT devices carried by the first NAS PDU;

[0554] After the AIoT device is successfully authenticated, the contracted data of the AIoT device is stored in the UDM or the first network element;

[0555] After the AIoT device is successfully authenticated, it is registered in the UDM or the first network element.

[0556] Select or reselect a PCF and obtain access management-related control policies from the PCF;

[0557] Allocate cycle duration and / or AIoT-RA to AIoT devices based on access management-related control policies;

[0558] Assign CN IDs to AIoT devices;

[0559] Create or update the context of an AIoT device.

[0560] Optionally, the information carried by the second NAS PDU may include, but is not limited to, at least one of the following:

[0561] Message type: Registration accepted;

[0562] Cycle duration;

[0563] AIoT-RA information;

[0564] CN ID.

[0565] Optionally, AIoTF can authenticate AIoT devices by combining AIoT devices with AUSF and UDM, or by combining AUSF and the first network element, where AUSF is not shown in Figure 10.

[0566] Optionally, the fourth message may also carry an initial context establishment request. The initial context establishment request is used to request the gNB to establish the context of the AIoTF device.

[0567] S1006a, gNB sends a second RRC message to the terminal device, and the second RRC message carries the second NAS PDU.

[0568] In one possible implementation, gNB can also perform:

[0569] S1006b, gNB sends the fifth message to AIoTF, which carries the initial context establishment response.

[0570] The initial context establishment response is used to indicate that the gNB has established the context of the AIoT device.

[0571] S1007, the terminal device sends a second NAS PDU to the AIoT device.

[0572] For further descriptions of the embodiments shown in Figure 10, please refer to the embodiments shown in Figure 7, which will not be repeated here.

[0573] In the embodiment shown in Figure 10, when an AIoT device receives a registration activation message periodically broadcast by a terminal device, it can determine that the registration type of the first NAS PDU sent to the terminal device for requesting registration is periodic registration based on the stored registration status of not registered to the network and meeting the periodic registration conditions. This effectively initiates the periodic registration process. Since the registration activation message carries the first time the terminal device sent the registration activation message, this first time is maintained by the terminal device. For different AIoT devices, the first time broadcast by the terminal device at the same time is the same. There is no need for the terminal device to save, maintain, and broadcast different information for judging the periodic registration conditions for different AIoT devices. This reduces the processing burden of the terminal device and the communication load between the terminal device and the AIoT device. Moreover, the AIoT device can effectively initiate periodic registration so that the network side can promptly grasp the latest location of the device, related service nodes, and other device information, understand the device's reachability status, and facilitate quickly paging the AIoT device when there is a downlink AIoT service request for the device.

[0574] Please refer to Figure 11, which is a schematic diagram of the interaction flow of a communication registration method with mobility registration as the registration type provided in this application embodiment. As shown in Figure 11, in this method, the first device is a terminal device, the second device is an AIoT device, the third device is a gNB, and the fourth device is a first AIoTF. The first message is encapsulated in the first NAS PDU, and the third message is encapsulated in the second NAS PDU. The method may include, but is not limited to:

[0575] S1101, the terminal device periodically sends registration and activation messages to the AIoT device.

[0576] Optionally, the registration activation message may carry at least one of the following information:

[0577] First time;

[0578] AIoT location information;

[0579] Filtering criteria.

[0580] S1102, in response to the registration activation message, the AIoT device sends the first NAS PDU to the terminal device.

[0581] The first NAS PDU is used to request registration in the network, and the registration type requested by the first NAS PDU is mobility registration.

[0582] Before executing step S1102, the AIoT device determines that the stored registration status is already registered on the network and meets the mobility registration conditions.

[0583] Optionally, the first NAS PDU may carry at least one of the following information:

[0584] Message type: Registration request;

[0585] Permanent equipment identification;

[0586] Equipment capabilities.

[0587] Optionally, based on AIoT location information and stored AIoT-RA information, it can be determined whether the mobility registration conditions are met.

[0588] For example, if an AIoT device determines that the location indicated by the AIoT location information does not belong to the registration area indicated by the AIoT-RA information, then it determines that the mobility registration conditions are met; or, if an AIoT device determines that the location indicated by the AIoT location information belongs to the registration area indicated by the AIoT-RA information, then it determines that the mobility registration conditions are not met.

[0589] S1103, the terminal device sends a first RRC message to the gNB, and the first RRC message carries the first NAS PDU.

[0590] Optionally, the information carried by the first RRC message may also include at least one of the following:

[0591] First information, used to indicate the first AIoTF;

[0592] The second piece of information is used to instruct the terminal device;

[0593] The UEreader ID of the terminal device.

[0594] S1104, gNB sends a second message to the first AIoTF, the second message carrying the first NAS PDU.

[0595] The gNB can determine the AMF used to forward the second message, and forward the second message to the first AIoTF through the determined AMF. The process of forwarding the second message through the AMF is not shown in Figure 11.

[0596] In one possible implementation, the gNB can determine the AMF used to forward the second message based on the second information.

[0597] In another possible implementation, the gNB can receive first authentication information from the AMF, and the gNB identifies the AMF as the AMF used to forward the second message. The first authentication information is used to indicate that the terminal device is authenticated as a UE Reader. This implementation is not shown in Figure 11.

[0598] Optionally, the information carried by the second message may also include at least one of the following:

[0599] Identification information of the terminal device;

[0600] UEreader ID of the terminal device;

[0601] Location information of the terminal device;

[0602] gNB identification information.

[0603] S1105, the first AIoTF sends a fourth message to the gNB, and the fourth message carries the second NAS PDU.

[0604] The second NAS PDU is used to send the registration result back to the AIoT device. The message type of the second NAS PDU can be registration acceptance, used to send a message to the AIoT device that the AIoTF has accepted the registration of the AIoT device.

[0605] Optionally, the AIoTF can send a fourth message to the gNB through the AMF determined by the gNB in ​​step S1104.

[0606] In one possible implementation, the first AIoTF is the core network element most recently registered by the AIoT device; before executing step S1105, the first AIoTF may also perform at least one of the following operations:

[0607] Assign AIoT-RA and / or configuration cycle duration to AIoT devices;

[0608] Update the context of the AIoT device;

[0609] Assign a CN ID to an AIoT device.

[0610] The first AIoTF updates the context of the AIoT device, which may include updating the associated nodes of the AIoT device, the current location information of the AIoT device, and the AIoT-RA information of the AIoT device in the context of the AIoT device.

[0611] This implementation method is not shown in Figure 11.

[0612] In another possible implementation, the first AIoTF is not the AIoTF most recently registered by the AIoT device; the AIoTF most recently registered by the AIoT device is represented by the second AIoTF. Before executing step S1105, the first AIoTF may also perform at least one of the following operations:

[0613] Obtain the context of the AIoT device from the second AIoTF;

[0614] Authenticate AIoT devices and check the device capabilities of the AIoT devices carried by the first NAS PDU;

[0615] After the AIoT device is successfully authenticated, the contracted data of the AIoT device is stored in the UDM or the first network element;

[0616] After the AIoT device is successfully authenticated, it is registered in the UDM or the first network element.

[0617] The second AIoTF is notified to release the context of the AIoT device;

[0618] Select a new PCF and retrieve the access management control policies from the PCF.

[0619] Based on access management-related control policies, the AIoT-RA and / or configuration cycle duration is reassigned to AIoT devices;

[0620] Update the context of the AIoT device;

[0621] Assign a CN ID to an AIoT device.

[0622] Optionally, the first AIoTF can authenticate the AIoT device by the AIoT device in conjunction with AUSF and UDM, or by AUSF and the first network element, where AUSF is not shown in Figure 11.

[0623] Optionally, the information carried by the second NAS PDU may include, but is not limited to, at least one of the following:

[0624] Message type: Registration accepted;

[0625] Periodic duration;

[0626] AIoT-RA information;

[0627] CN ID.

[0628] Optionally, the fourth message may also carry an initial context establishment request. The initial context establishment request is used to request the gNB to establish the context of the AIoTF device.

[0629] S1106a, gNB sends a second RRC message to the terminal device, the second RRC message carrying the second NAS PDU.

[0630] In one possible implementation, gNB can also perform:

[0631] S1106b, gNB sends a fifth message to the first AIoTF, the fifth message carrying the initial context establishment response.

[0632] The initial context establishment response is used to indicate that the gNB has established the context of the AIoT device.

[0633] S1107, the terminal device sends a second NAS PDU to the AIoT device.

[0634] For further descriptions of the embodiments shown in Figure 11, please refer to the embodiments shown in Figure 7, which will not be repeated here.

[0635] In the embodiment shown in Figure 11, when an AIoT device receives a registration activation message periodically broadcast by a terminal device, it can determine that the registration type of the first NAS PDU sent to the terminal device for requesting registration is mobility registration based on the stored registration status of not registered to the network and meeting the mobility registration conditions. This effectively initiates the mobility registration process. Since the registration activation message carries the AIoT location information sent by the terminal device, and the AIoT location information is maintained by the terminal device, the AIoT location information broadcast by the terminal device at the same time is the same for different AIoT devices. This eliminates the need for the terminal device to save, maintain, and broadcast different information for mobility registration condition judgment for different AIoT devices, reducing the processing burden of the terminal device and the communication load between the terminal device and the AIoT device. Furthermore, the AIoT device can effectively initiate mobility registration so that it can promptly inform the network side of its location changes, facilitating the network side's mobility management of the AIoT device.

[0636] In the three different registration types shown in Figures 9, 10, and 11, the registration activation message sent by the terminal device to the AIoT device can be the same, for example, a registration activation message carrying the same information. The terminal device does not need to use different registration activation messages or different ways to trigger the AIoT device to initiate registration depending on the different types of registration that the AIoT device may initiate. The terminal device also does not need to maintain information about all registered devices in the broadcastable area of ​​the registration activation message, such as the device identifier, registration status, and registration period of the registered devices. This reduces the processing burden of the terminal device and the communication load between the terminal device and the AIoT device, and enables the AIoT device to initiate the corresponding type of registration.

[0637] AIoT devices also do not need to run periodic timers to trigger the registration process. They can initiate the corresponding type of registration process through simple judgment logic that meets the registration conditions, which reduces the implementation complexity of AIoT devices and is suitable for registration scenarios of AIoT devices with simple structures.

[0638] In another alternative implementation, there is a special case regarding the mobility registration of the second device: the first device knows information about the second devices around it and the first device moves along the same trajectory as the second device.

[0639] For example, in a logistics tracking scenario, the second device is attached to a container and transported to its destination by a logistics company's truck. During this transportation process, the first device can be dedicated, for example, the truck driver's mobile phone. Therefore, the first device can know what second devices are around, i.e., the second devices on the container, and know that the surrounding second devices will move along with the first device.

[0640] In such special circumstances, the first device can assist the second device in performing mobility registration, which may include, but is not limited to, at least one of the following two methods:

[0641] Method 4-1: The registration area of ​​the second device is the same as that of the first device, and the first device assists the second device in performing mobility registration during the mobility registration process.

[0642] Method 4-2: The registration area of ​​the second device is different from that of the first device. The first device knows the registration area of ​​the second device. If the location of the first device is not within the registration area of ​​the second device, the first device initiates the mobility registration process of the second device on behalf of the second device.

[0643] For methods 4-1 and 4-2, the registration area of ​​the second device can be the registration area indicated by the AIoT-RA information stored in the second device. The AIoT-RA information can be found in the description of the embodiment shown in Figure 7. The registration area of ​​the first device can be the registration area most recently assigned to the first device by the core network element, for example, the registration area assigned to the first device by the AMF during the first device's most recent network registration process.

[0644] For example, in method 4-1, if the registration area of ​​the second device includes the cell indicated by the cell identifier in the set {AIoT cell#1, AIoT cell#2, AIoT cell#3}, and the registration area of ​​the first device also includes the cell indicated by the cell identifier in the set, then the registration area of ​​the second device is the same as the registration area of ​​the first device.

[0645] For example, in method 4-2, the registration area of ​​the second device includes the cells indicated by the cell identifiers in the set {AIoT cell#1, AIoT cell#2, AIoT cell#3}, and the registration area of ​​the first device includes the cells indicated by the cell identifiers in the set {AIoT cell#1, AIoT cell#2, AIoT cell#3, AIoT cell#4, AIoT cell#5, AIoT cell#6, AIoT cell#7, AIoT cell#8, AIoT cell#9, AIoT cell#10}. In this case, the registration area of ​​the second device is different from the registration area of ​​the first device.

[0646] Optionally, the first device's role in assisting the second device with mobility registration during the mobility registration process may include: the first device sending a first message and its registration request message, carried within a first RRC message, to the third device; the third device forwarding the first message and the first device's registration request message to the corresponding core network element, for example, forwarding the first message within a second message to a fourth device, and forwarding the first device's registration request message to the AMF. Optionally, the first device's registration request message may be encapsulated in the UE NAS PDU.

[0647] The fourth device also responds to the first message by sending a third message to the second device through the third device and the first device, thereby completing the mobility registration of the second device.

[0648] Optionally, the first device initiating the mobility registration process for the second device on behalf of the second device may include: the first device sending a first message to a fourth device via a third device; for example, the first device sending a first RRC message carrying the first message to the third device, and the third device sending a second message carrying the first message to the fourth device. In response to the first message, the fourth device sends a third message to the first device via the third device. The first device can then forward the third message to the second device, thus completing the mobility registration for the second device. For example, the fourth device sending a fourth message carrying the third message to the third device, the third device sending a second RRC message carrying the third message to the first device, and the first device sending the third message to the second device.

[0649] In methods 4-1 and 4-2, the registration type in the first message is mobility registration, and the permanent device identifier and / or device capabilities in the first message are obtained by the first device from the surrounding second devices when it takes inventory of the second devices around it. For example, before a truck carrying the second device departs for logistics transportation, the first device takes inventory of the second devices loaded on the truck and obtains the permanent device identifier and device capabilities of the second devices.

[0650] The first and third messages can be found in the description of the embodiment shown in Figure 7. The steps performed by the fourth device after receiving the first message can be found in the description of the embodiments shown in Figures 7 and 11, and will not be repeated here.

[0651] In one possible implementation, the first device needs to be authorized or permitted to assist the second device in registering its mobility before the first device assists the second device in doing so.

[0652] Please refer to Figure 12, which is a schematic flowchart of a method for authorizing or allowing a first device to assist a second device in performing mobility registration according to an embodiment of this application. This method may include, but is not limited to:

[0653] S1201, the fourth device sends an AIoT service request to the first device, the AIoT service request carrying AIoT mobile update (AIoT_mobility_updating) information.

[0654] Optionally, the fourth device can forward AIoT service requests to the first device through the third device.

[0655] Optionally, the AIoT service request is used to request the first device to perform an AIoT service. For example, the AIoT service request can be an inventory request, which requests the first device to perform an inventory check on the second device.

[0656] Optionally, AIoT service requests may also carry information including, but not limited to, at least one of the following:

[0657] 1. Transaction ID;

[0658] 2. Device filtering.

[0659] A Transaction ID is a unique identifier used to identify each transaction or operation. For example, a Transaction ID is used to identify an inventory operation, and different inventory operations will have different Transaction IDs. The first device can execute the transaction or operation identified by the Transaction ID carried in the AIoT service request.

[0660] Device filtering can be used to filter second devices to which a transaction or operation performed by a first device is targeted. For example, device filtering can be used to filter second devices that are being inventoried by the first device.

[0661] Optionally, device filtering may include, but is not limited to, at least one of the following:

[0662] (1) Group identifier;

[0663] (2) Equipment type;

[0664] (3) Business type;

[0665] (4) Company information;

[0666] (5) Brand information.

[0667] The second device stores descriptive information about itself, such as the group identifier of the group to which it belongs, the device type of the second device, the types of services the second device can perform, information about the company that manufactures or sells the second device, and brand information of the second device. The first device can select the second device to which the transaction or operation is targeted based on device filtering. For example, it can select the second device whose stored group identifier is the same as the group identifier in device filtering for inventory. Or, it can select the second device whose stored device type and stored service type are both the same as the service type in device filtering for inventory.

[0668] S1202, the first device performs AIoT services on the second device.

[0669] After receiving an AIoT service request, if the first device agrees to execute the requested AIoT service, it then executes the AIoT service on the second device. For example, it executes an inventory procedure on the second device.

[0670] S1203, the first device sends an AIoT service response to the fourth device, the AIoT service response carrying the device ID list of the second device.

[0671] The first device has executed AIoT services on the second device identified by the device identifier in the device ID list.

[0672] Optionally, the AIoT service response can be an inventory response, which carries a list of device IDs of the first device that has been inventoried by the first device.

[0673] Optionally, the first device can forward the AIoT service response to the fourth device via the third device.

[0674] Optionally, the AIoT service response may also carry information including, but not limited to, at least one of the following:

[0675] 1. Transaction ID;

[0676] 2. AIoT_mobility_updating: OK.

[0677] The Transaction ID carried in the AIoT service response is an identifier of the transaction or operation that the first device has already executed.

[0678] AIoT_mobility_updating: OK is used to indicate that the first device agrees to help the second device register its mobility.

[0679] S1204, the fourth device queries the AIoT-RA information of the second device based on the device ID list carried in the AIoT service response.

[0680] The second device queried by the fourth device is the second device identified by the device ID in the device ID list.

[0681] S1205, the fourth device sends the AIoT mobility updating config information to the first device. The AIoT mobility updating config carries the AIoT-RA information of the second device.

[0682] Optionally, the fourth device can forward the AIoT mobility updating configuration to the first device via the third device.

[0683] Optionally, the AIoT mobility updating configuration may also carry information including, but not limited to, at least one of the following:

[0684] 1. Equipment Scope;

[0685] 2. Assistance period.

[0686] The device scope refers to the second devices that the fourth device configures for the first device to help with mobility registration updates, that is, which second devices can be assisted by the fourth device in mobility registration.

[0687] The assistance period is the time during which the fourth device can assist the second device in registering mobility.

[0688] In the embodiment shown in Figure 12, if the first device knows the information of the second devices around it and the first device moves along the same trajectory as the second device, the first device can help the second device register its mobility without the first device periodically sending registration activation messages to the second device to trigger the second device to initiate registration. This reduces the interaction between the first and second devices and lowers the implementation complexity of the second device's registration, effectively realizing the mobility registration of the second device, which is suitable for the registration scenario of AIoT devices.

[0689] This application provides a communication device that can be used to implement the functions of the second, first, third, or fourth device described above. The communication device can be the second, first, third, or fourth device. The communication device includes units corresponding one-to-one with the methods / operations / steps / actions performed by the second, first, third, or fourth device in the above method embodiments. These units can be hardware circuits, software, or a combination of hardware circuits and software. Please refer to Figure 13, which shows a schematic diagram of the structure of a communication device 1300 provided in this application embodiment. The communication device 1300 may include an interface unit 1301 and a processing unit 1302. Specifically, the processing unit 1302 is used to process signaling and / or data, which can be data received by the interface unit 1301, and the processed signaling and / or data can also be sent by the interface unit 1301.

[0690] In one embodiment, when the communication device 1300 is a second device, wherein:

[0691] Interface unit 1301 is used to receive registration activation messages from the first device;

[0692] Interface unit 1301 is also used to respond to registration activation messages and send a first message to the first device; the first message is used to request registration on the network, and the registration type requested in the first message is determined based on the stored registration status.

[0693] Optionally, if no online registration is made, the registration type is initial registration; or,

[0694] If you have already registered online and meet the conditions for periodic registration, the registration type is periodic registration; or,

[0695] If you have already registered online and meet the mobility registration requirements, the registration type is mobility registration.

[0696] Optionally, the processing unit 1302 is configured to determine that the periodic registration condition is met in response to the sum of the most recent successful registration time and the storage period duration being greater than or equal to a first time; wherein the first time is carried by the registration activation message, the first time is the time when the first device sends the registration activation message, and the period duration is the duration of the period for the most recent configured periodic registration.

[0697] Optionally, the processing unit 1302 is configured to determine that the mobility registration conditions are met in response to the location indicated by the environmental IoT location information not belonging to the registration area indicated by the stored environmental IoT registration area information; wherein the environmental IoT location information is carried by the registration activation message, the environmental IoT location information is used to indicate the location of the first device and / or the local terminal, and the environmental IoT registration area information is used to indicate the most recently assigned registration area.

[0698] In this embodiment, the specific implementation of the interface unit 1301 and the processing unit 1302 can be found in the specific implementation steps of the second device or AIoT device in any of the embodiments shown in Figures 7-12, and will not be repeated here.

[0699] In another embodiment, when the communication device shown in FIG13 is the first device, wherein:

[0700] Interface unit 1301 is used to send a registration activation message to the second device;

[0701] Interface unit 1301 is also used to receive a first message from the second device, the first message being used by the second device to request registration on the network, the registration type requested in the first message being determined based on the registration status stored by the second device.

[0702] Optionally, the registration activation message may carry at least one of the following information:

[0703] Real-time environmental IoT location information;

[0704] The first time refers to the time when the registration and activation message is sent, and the environmental IoT location information is used to indicate the location of the local device and / or the second device.

[0705] Optionally, the interface unit 1301 is also used to send a first radio resource control message to the third device, the first radio resource control message carrying a first message.

[0706] Optionally, when in the radio resource control deactivated state, the first radio resource control message is a radio resource control recovery request message or a radio resource control recovery completion message; or, when in the radio resource idle state, the first radio resource control message is a radio resource establishment completion message.

[0707] In this embodiment, the specific implementation steps of the interface unit 1301 and the processing unit 1302 can be found in any of the embodiments shown in Figures 7-12, and will not be repeated here.

[0708] In another embodiment, when the communication device shown in FIG13 is a third device, wherein:

[0709] Interface unit 1301 is used to receive a first radio resource control message from a first device. The first radio resource control message carries a first message, which is used by the second device to request registration on the network. The registration type requested in the first message is determined based on the registration status stored by the second device.

[0710] The interface unit 1301 is also used to send a second message to the fourth device, the second message carrying the first message.

[0711] Optionally, the information carried by the first radio resource control message may further include: first information; the first information is used to instruct the fourth device.

[0712] Optionally, the information carried by the first radio resource control message may further include: second information; the second information is used to instruct the first device;

[0713] Interface unit 1301 is specifically used to send a second message to the fourth device through the Access and Mobility Management Function (AMF); the AMF determines based on the second message.

[0714] Optionally, interface unit 1301 is further configured to receive an initial context establishment request from the fourth device, the initial context establishment request being used to request the establishment of the context of the second device;

[0715] Interface unit 1301 is also configured to send an initial context establishment response to the fourth device in response to the initial context establishment request, the initial context establishment response being used to indicate that the context of the second device has been established.

[0716] In this embodiment, the specific implementation steps of the interface unit 1301 and the processing unit 1302 can be found in any of the embodiments shown in Figures 7-12, and will not be repeated here.

[0717] In yet another embodiment, when the communication device shown in FIG13 is a fourth device, wherein:

[0718] Interface unit 1301 is used to receive a first message from the second device; the first message is used for the second device to request registration on the network, and the registration type requested in the first message is determined based on the registration status stored by the second device;

[0719] The interface unit 1301 is also used to send a third message to the second device in response to the first message, and the third message is used to provide feedback on the registration result to the second device.

[0720] Optionally, the information carried by the third message includes at least one of the following:

[0721] Cycle duration, environmental IoT registration area information, and device core network identifier;

[0722] Among them, the cycle duration is the duration of the cycle in which the second device performs periodic registration, the environmental IoT registration area information is used to indicate the registration area assigned to the second device, and the device core network identifier is used to identify the second device within the core network.

[0723] Optionally, the interface unit 1301 is specifically used to send a third message to the second device through the third device;

[0724] Interface unit 1301 is also used to send an initial context establishment request to the third device, the initial context establishment request being used to request the third device to establish the context of the second device;

[0725] Interface unit 1301 is also configured to receive an initial context establishment response from a third device, the initial context establishment response being used to indicate that the third device has established a context for the second device.

[0726] Optionally, the processing unit 1302 is used to establish a context for the second device in response to the first message.

[0727] In this embodiment, the specific implementation steps of the interface unit 1301 and the processing unit 1302 can be found in any of the embodiments shown in Figures 7-12, which are the fourth device, AIoTF or the first AIoTF, and will not be repeated here.

[0728] Figure 14 shows a communication device 1400 provided in an embodiment of this application, used to implement the functions of the second device, first device, third device, or fourth device described above. This device can be a communication equipment or a device used within a communication equipment. The communication equipment can be the second device, first device, third device, or fourth device. The device used within the communication equipment can be a chip system or a chip within the communication equipment. The chip system can be composed of chips or can include chips and other discrete components.

[0729] The communication device 1400 includes at least one processor 1410 for implementing the processing functions of the devices (e.g., a second device, a first device, a third device, or a fourth device) in the methods provided in this application embodiment. The communication device 1400 may also include a communication interface 1420 for implementing the transmit and receive operations of the devices (e.g., a second device, a first device, a third device, or a fourth device) in the methods provided in this application embodiment. In this application embodiment, the communication interface may be a transceiver, circuit, bus, module, or other type of communication interface for communicating with other devices via a transmission medium. For example, the communication interface 1420 enables the devices in the communication device 1400 to communicate with other devices. The processor 1410 uses the communication interface 1420 to transmit and receive data and is used to implement the methods described in the above method embodiments.

[0730] The communication device 1400 may further include at least one memory 1430 for storing program instructions and / or data. The memory 1430 is coupled to the processor 1410. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and may be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 1410 may operate in conjunction with the memory 1430. The processor 1410 may execute program instructions stored in the memory 1430. One or more memories may be included in the processor.

[0731] This embodiment does not limit the specific connection medium between the communication interface 1420, processor 1410, and memory 1430. In Figure 14, the memory 1430, processor 1410, and communication interface 1420 are connected via a bus, indicated by a thick line. The connection methods between other components are merely illustrative and not intended to be limiting. The bus can be categorized as an address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 14, but this does not imply that there is only one bus or one type of bus.

[0732] When the communication device 1400 is specifically a device used for equipment (e.g., a second device, a first device, a third device, or a fourth device), for example, when the communication device 1400 is specifically a chip or chip system, the communication interface 1420 may output or receive baseband signals. When the communication device 1400 is specifically a device (e.g., a second device, a first device, a third device, or a fourth device), the communication interface 1420 may output or receive radio frequency signals. In the embodiments of this application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit, a field-programmable gate array or other programmable logic device, a discrete gate or transistor logic device, or a discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0733] When the aforementioned communication device 1400 is a module applied to a base station, the base station module implements the functions of the base station in the above method embodiments. The base station module receives information from other modules (such as radio frequency modules or antennas) in the base station, information sent by the terminal to the base station; or, the base station module sends information to other modules (such as radio frequency modules or antennas) in the base station, information sent by the base station to the terminal. Here, the base station module can be a baseband chip of the base station, or a central unit (CU), distributed unit (DU), or other modules, or a device under an open RAN (O-RAN or ORAN) architecture, such as an open CU, open DU, etc.

[0734] It should be noted that the aforementioned communication interface 1420 can be used to execute the functions of the aforementioned interface unit 1301, and the aforementioned processor 1410 can be used to execute the functions of the aforementioned processing unit 1302, which will not be elaborated further here.

[0735] When the aforementioned communication device is a chip applied to the second device, the chip implements the functions of the second device in the above method embodiments. The chip receives information from other devices; or, the chip sends information to other devices.

[0736] When the aforementioned communication device is a chip applied to the first device, the chip implements the function of the first device in the above method embodiment, and the chip receives information from other devices; or, the chip sends information to other devices.

[0737] When the aforementioned communication device is a chip applied to the third device, the chip implements the function of the third device in the above method embodiment, and the chip receives information from other devices; or, the chip sends information to other devices.

[0738] When the aforementioned communication device is a chip applied to the fourth device, the chip implements the function of the fourth device in the above method embodiment, and the chip receives information from other devices; or, the chip sends information to other devices.

[0739] It is understood that the processor in the embodiments of this application can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. A general-purpose processor can be a microprocessor or any conventional processor.

[0740] The method steps in the embodiments of this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, compact disc-ROMs (CD-ROMs), or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Furthermore, the ASIC can reside in a second, first, third, or fourth device. Alternatively, the processor and storage medium can exist as discrete components in the second, first, third, or fourth device.

[0741] 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 programs or instructions. When the computer program or instructions are loaded and executed on a computer, the processes or functions described in the embodiments of this application are performed entirely or partially. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer program or instructions can be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, hard disk, or magnetic tape; it can also be an optical medium, such as a digital video disk (DVD); or it can be a semiconductor medium, such as a solid-state drive (SSD).

[0742] In the various embodiments of this application, unless otherwise specified or in case of logical conflict, the terminology and / or descriptions of different embodiments are consistent and can be referenced by each other. The technical features of different embodiments can be combined to form new embodiments according to their inherent logical relationship.

[0743] It is understood that the various numerical designations used in the embodiments of this application are merely for descriptive convenience and are not intended to limit the scope of the embodiments of this application. The order of the process numbers described above does not imply the order of execution; the execution order of each process should be determined by its function and internal logic.

[0744] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed, the method performed by the second device, first device, third device, or fourth device in the above method embodiments is implemented.

[0745] This application also provides a computer program product, which includes a computer program that, when executed, causes the method executed by the second device, first device, third device, or fourth device in the above method embodiments to be implemented.

[0746] This application also provides a communication system, which includes a second device and a fourth device. Optionally, it further includes a model management platform. The second device is used to execute the method executed by the second device in the above method embodiments, and the fourth device is used to execute the method executed by the fourth device in the above method embodiments.

[0747] This application also provides a communication system, which includes a second device, a first device, a third device, and a fourth device. Optionally, it also includes a model management platform. Each device is used to execute the methods executed by the devices in the above method embodiments.

[0748] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0749] The descriptions of the various embodiments provided in this application can be referenced mutually. Each embodiment has its own emphasis, and parts not described in detail in a certain embodiment can be referred to the relevant descriptions of other embodiments. For the sake of convenience and brevity, for example, the functions and execution steps of the various devices and equipment provided in the embodiments of this application can be referred to the relevant descriptions of the method embodiments of this application. The method embodiments and the device embodiments can also be referenced, combined or cited from each other.

[0750] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A communication registration method, characterized in that, The method includes: Receive registration activation message from the first device; In response to the registration activation message, a first message is sent to the first device; the first message is used to request registration on the network, and the registration type requested in the first message is determined based on the stored registration status.

2. The method as described in claim 1, characterized in that, If no online registration is made, the registration type is initial registration; or, If the registration has already been completed online and meets the conditions for periodic registration, the registration type is periodic registration; or, If the registration has already been completed online and the mobility registration requirements are met, the registration type is mobility registration.

3. The method as described in claim 2, characterized in that, The method further includes: In response to the fact that the sum of the most recent successful registration time and the storage period duration is greater than or equal to a first time, it is determined that the periodic registration condition is met; wherein, the first time is carried by the registration activation message, the first time is the time when the first device sends the registration activation message, and the period duration is the duration of the most recently configured periodic registration period.

4. The method as described in claim 2, characterized in that, The method further includes: In response to the fact that the location indicated by the environmental IoT location information does not belong to the registration area indicated by the stored environmental IoT registration area information, it is determined that the mobility registration conditions are met; wherein, the environmental IoT location information is carried by the registration activation message, the environmental IoT location information is used to indicate the location of the first device and / or the local terminal, and the environmental IoT registration area information is used to indicate the most recently assigned registration area.

5. A communication registration method, characterized in that, The method includes: Send a registration activation message to the second device; A first message is received from the second device, the first message being used by the second device to request registration on the network, the registration type requested in the first message being determined based on the registration status stored by the second device.

6. The method as described in claim 5, characterized in that, The registration activation message carries at least one of the following information: Real-time environmental IoT location information; Wherein, the first time is the time when the registration activation message is sent, and the environmental IoT location information is used to indicate the location of the local device and / or the second device.

7. The method as described in claim 5 or 6, characterized in that, The method further includes: A first radio resource control message is sent to a third device, the first radio resource control message carrying the first message.

8. The method as described in claim 7, characterized in that, When the radio resource control is in the deactivated state, the first radio resource control message is a radio resource control recovery request message or a radio resource control recovery completion message; or, when the radio resource is in the idle state, the first radio resource control message is a radio resource establishment completion message.

9. A communication registration method, characterized in that, The method includes: Receive a first radio resource control message from a first device, the first radio resource control message carrying a first message, the first message being used by the second device to request registration on the network, the registration type requested in the first message being determined based on the registration status stored by the second device; A second message is sent to the fourth device, the second message carrying the first message.

10. The method as described in claim 9, characterized in that, The information carried by the first radio resource control message further includes: first information; the first information is used to instruct the fourth device.

11. The method as described in claim 9 or 10, characterized in that, The information carried by the first radio resource control message further includes: second information; the second information is used to instruct the first device; Sending the second message to the fourth device includes: The second message is sent to the fourth device via the Access and Mobility Management Function (AMF); the AMF determines based on the second information.

12. The method as described in claim 9 or 10, characterized in that, The method further includes: Receive an initial context establishment request from the fourth device, the initial context establishment request being used to request the establishment of the context of the second device; In response to the initial context establishment request, an initial context establishment response is sent to the fourth device, the initial context establishment response indicating that the context of the second device has been established.

13. A communication registration method, characterized in that, The method includes: Receive a first message from the second device; the first message is used for the second device to request registration on the network, and the registration type requested in the first message is determined based on the registration status stored by the second device; In response to the first message, a third message is sent to the second device, the third message being used to provide feedback on the registration result to the second device.

14. The method as described in claim 13, characterized in that, The information carried by the third message includes at least one of the following: Cycle duration, environmental IoT registration area information, and device core network identifier; Wherein, the period duration is the duration of the period during which the second device performs periodic registration, the environmental IoT registration area information is used to indicate the registration area assigned to the second device, and the device core network identifier is used to identify the second device within the core network.

15. The method as described in claim 13 or 14, characterized in that, Sending the third message to the second device includes: A third message is sent to the second device via the third device; The method further includes: Send an initial context establishment request to the third device, the initial context establishment request being used to request the third device to establish the context of the second device; Receive an initial context establishment response from the third device, the initial context establishment response being used to indicate that the third device has established the context of the second device.

16. The method as described in claim 13 or 14, characterized in that, The method further includes: In response to the first message, a context for the second device is established.

17. A communication device, characterized in that, The device includes a processor and an interface circuit. The interface circuit is used to receive signals from other communication devices besides the communication device and transmit them to the processor, or to send signals from the processor to other communication devices besides the communication device. The processor is used to implement the method as described in any one of claims 1-4; or the method as described in any one of claims 5-8; or the method as described in any one of claims 9-12; or the method as described in any one of claims 13-16 through logic circuits or executing code instructions.

18. A computer-readable storage medium, characterized in that, The storage medium stores a computer program or instructions, which, when executed by a communication device, implement the method as described in any one of claims 1-4; or the method as described in any one of claims 5-8; or the method as described in any one of claims 9-12; or the method as described in any one of claims 13-16.

Images