Communication method and related device

Abstract

Provided in an embodiment of the present application are a communication method and a related device, the method comprising: receiving a first request message sent by an AF, the first request message comprising first information and second information, the first information being information related to network registration by a terminal, and the second information being information related to checking by the terminal; sending a first request message or a second request message to the terminal, wherein the second request message is used for requesting to perform network registration and checking on the terminal; receiving registration feedback information and an inventory result sent by the terminal; and sending registration feedback information and a checking result of the terminal to the AF. By adopting the embodiment of the invention, the number of signaling in the checking process can be reduced, the communication overhead is reduced, and the checking efficiency is improved.

Description

TECHNICAL FIELD

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

[0002] An Ambient IoT (AIoT) device is a new type of IoT device that collects energy from radio waves, light, motion, heat, or any other available environmental energy and is driven by it. Since the AIoT device does not require additional power supply and does not need to replace the battery, the maintenance cost is extremely low, and it can be widely used in smart warehousing, smart logistics, smart agriculture, industrial wireless sensor network, smart transportation, smart medical care, etc. It is expected to become a basic enabling technology for the Internet of Everything.

[0003] AIoT devices are widely used, and the number of AIoT devices will increase explosively in the future. A large number of AIoT devices usually need to be registered to the network so as to be able to communicate and be managed with the network. Registration to the network is an important step to ensure that the AIoT device can be identified, authenticated and authorized by the network. Considering that most AIoT devices reflect or absorb electromagnetic waves transmitted by the reader for information transmission in a backscatter manner, the current research mainly considers two types of traffic, Device-terminated (DT) and Device-originated-device-terminated triggered (DO-DTT). Since the AIoT device cannot actively initiate the registration process, the registration can only be triggered by the network side.

[0004] Since AIoT devices are often used in batches, AIoT device registration is usually completed in batches or periodically, such as during the unattended operation period in the early morning, the base station broadcasts device registration messages to trigger device registration. However, the time of the third-party application function (Application function, AF) to issue a service request (such as an inventory request, used to inventory the situation of AIoT devices in a certain area) is relatively random. This may lead to the following situation: the AF wants to inventory all AIoT devices in warehouse A, but there are still a batch of newly deployed AIoT devices in warehouse A that have not been registered to the network. Since the unregistered AIoT device has not undergone identity verification in the core network, the service request is not reachable to it, and the response data of the unregistered AIoT device will not be parsed and processed by the 5G core network (5G Core network, 5GC). In this scenario, the registration of the unregistered AIoT device needs to be initiated first, and the inventory request is issued after the registration is completed. The number of signaling interactions in this process is large, and the processing overhead of the 5GC is also large, which slows down the response speed of the AIoT device and reduces the inventory efficiency. SUMMARY

[0005] The communication method and related apparatus provided in this application can reduce the number of signaling calls during inventory counting, improve response speed, and increase inventory counting efficiency.

[0006] In a first aspect, embodiments of this application provide a communication method applied to a network device, the method comprising:

[0007] Receive a first request message sent by the application function network element AF, wherein the first request message includes first information and second information, the first information being information related to the terminal's network registration, and the second information being information related to the terminal's inventory.

[0008] Send a first request message or a second request message to the terminal, wherein the second request message is used to request network registration and inventory of the terminal;

[0009] Receive registration feedback information and inventory results sent by the terminal;

[0010] Send the terminal registration feedback information and inventory results to the AF.

[0011] In this implementation, the network device can be an access network device (such as RAN), a core network device (such as AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as NEF. Different types of network devices may process the first request message differently. For example, the first request message sent by the RAN may carry information added by the RAN, while the first request message sent by the NEF may carry information added by the NEF. In addition, different types of network devices may receive different registration feedback information. For example, the registration feedback information received by the RAN includes some parameters used for registration, while the registration feedback information received by the AMF may include the registration status (such as registered). The NEF, AMF, AIoT, etc. mentioned in the embodiments of this application all belong to core network elements.

[0012] In this embodiment, the network device receives a message sent by the AF (Agent First). This can be done either by the AF sending the message directly to the network device and the network device receiving it directly, or by the AF sending the message indirectly to the network device. For example, if there are one or more communication nodes between the AF and the network device, the message sent by the AF is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the network device receives the message. Similarly, the network device sends a message to the AF. This can be done either by the network device sending the message directly to the AF and the AF receiving it directly, or by the network device sending the message indirectly to the AF. For example, if there are one or more communication nodes between the AF and the network device, the message sent by the network device is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the AF receives the message. The same principle applies to the relationship between the network device and the terminal. The network device sends a message to the terminal. This can be done either by the network device sending the message directly to the terminal and the terminal receiving it directly, or by the network device sending the message indirectly to the terminal. For example, if there are one or more communication nodes between the terminal and the network device, the message sent by the network device is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the terminal receives the message. Similarly, when a network device receives a message sent by a terminal, it can be that the terminal sends the message directly to the network device and the network device receives it directly, or it can be that the terminal sends the message indirectly to the network device. For example, there are one or more communication nodes between the terminal and the network device. The message sent by the terminal is forwarded through one or more intermediate nodes (or it may be processed before being forwarded), and then the network device will receive the message.

[0013] Therefore, receiving a message from the AF can be understood as receiving a message sent from the AF link direction, specifically it could be receiving a message sent by a node between the network device and the AF (or possibly the AF itself); sending a message to the AF can be understood as sending a message in the AF link direction, specifically it could be sending a message to a node between the network device and the AF (or possibly the AF itself); receiving a message from the terminal can be understood as receiving a message sent from the terminal link direction, specifically it could be receiving a message sent by a node between the network device and the terminal (or possibly the terminal itself); sending a message to the terminal can be understood as sending a message in the terminal link direction, specifically it could be sending a message to a node between the network device and the terminal (or possibly the terminal itself).

[0014] In one alternative scheme, the network device is NEF, and the above method is as follows: NEF receives the first request message sent by AF; NEF sends the first request message or the second request message to the core network device; NEF receives the terminal registration feedback information and inventory results sent by the core network device; NEF sends the terminal registration feedback information and inventory results to AF.

[0015] In another alternative scheme, the network device is a core network device, and the above method is as follows: the core network device receives the first request message sent by NEF, the core network device sends the first request message or the second request message to the access network device, the core network device receives the terminal registration feedback information and inventory results sent by the access network device, and the core network device sends the terminal registration feedback information and inventory results to NEF.

[0016] In another alternative scheme, the network device is an access network device, and the above method is as follows: the access network device receives a first request message sent by the core network device; the access network device sends a first request message or a second request message to the terminal; the access network device receives the terminal's registration feedback information and inventory results sent by the terminal; and the access network device sends the terminal's registration feedback information and inventory results to the core network device.

[0017] Of course, there are other options, which will not be listed here.

[0018] The first request message can be in the format of a registration request (enhancing an existing registration request to include inventory-related information), or in the format of an inventory request (enhancing an existing inventory request to include network registration-related information), or in other formats, which are not limited here. Furthermore, after receiving the first request message, the network device can continue to send the first request message to the next network element. For example, if the first request message is a first registration request, it can be sent to the next network element. Alternatively, after receiving the first request message, the network device can also convert the first registration request into other message types before sending it to the next network element. For example, if the first request message is a first inventory request, the network device can generate a first registration request (i.e., the second request message mentioned above) based on the first inventory request and then send the first registration request (i.e., the second request message mentioned above) to the next network element.

[0019] Furthermore, the received terminal registration feedback information and inventory results are generally relayed or processed by other devices before being sent. Regarding the terminal registration feedback information and inventory results, these can be sent in a single message, for example, both encapsulated in a single Registration Response, or both encapsulated in a single Inventory Response, or encapsulated in other types of messages. Alternatively, the registration feedback information and inventory results can be sent in separate messages; for example, the registration feedback information can be encapsulated in a single Registration Response, while the inventory results can be encapsulated in a single Inventory Response. Similarly, the terminal registration feedback information and inventory results sent by the network device can be encapsulated in a single message or in two messages of different types; the principle is explained in the preceding descriptions. In addition, the registration feedback information and inventory results of the terminals received by the network device and the registration feedback information and inventory results of the terminals sent by the network device can be encapsulated in different types of messages. For example, the registration feedback information and inventory results of the terminals received by the network device can be encapsulated in a Registration Response, while the registration feedback information and inventory results of the terminals received by the network device can be encapsulated in an Inventory Response. The specific settings can be configured according to the needs of the scenario.

[0020] In addition, information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0021] It is understandable that the first request message includes both information related to network registration and information related to inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0022] In conjunction with the first aspect, one possible implementation also includes:

[0023] The terminal will be registered to the core network based on the registration feedback information.

[0024] It is understandable that the registration feedback information here includes some parameters required for registration. For example, the RAN, AMF, or other core network elements register the terminal with the core network based on the registration feedback information.

[0025] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation, the first request message is a first registration request, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried.

[0026] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminals to be registered, such as the terminal's device ID and the region information of the terminal's location. The second information indicates that these terminals that need to be registered also need to be inventoried. The second information can be an inventory indicator indi_inventory. In one implementation, all terminals to be registered correspond to one inventory indicator indi_inventory to indicate that these terminals need to be inventoried. In another implementation, each terminal among the terminals to be registered that also needs to be inventoried corresponds to one inventory indicator indi_inventory to indicate that the corresponding terminal needs to be inventoried.

[0027] In conjunction with the first aspect, or any of the possible implementations of the first aspect described above, in yet another possible implementation, the first registration request further includes third information. This third information is used to instruct the access network device and / or core network device that provides services to the terminal to be registered. In this implementation, the network device may also need to know the information of the access network device, AMF, and other devices corresponding to the terminal to be registered and inventoried. Therefore, the third information can be used to instruct the relevant network elements to provide this information. It should be noted that the core network device mentioned in this embodiment can also be called a core network element, and can be a physical device or a functional entity.

[0028] In combination with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation:

[0029] The receiving terminal sends registration feedback information and inventory results, including:

[0030] The receiving terminal sends a first registration response, which includes the terminal's registration feedback information and inventory results;

[0031] Send the terminal registration feedback information and inventory results to the AF, including:

[0032] Send the first registration response to the AF or a registration response generated based on the first registration response.

[0033] This implementation primarily demonstrates that if the first request message sent by the network device is a registration request (i.e., a registration request message), then the final response received can be a corresponding registration response (i.e., a first registration response). The first registration response can also be sent to other network elements (such as the AF). It's important to note that generally, if a network device receives a request from a network element, it needs to send a corresponding response to that element; conversely, if a network device sends a request to a network element, it will receive a response from that element regarding that request. For example, if the network device is NEF, NEF receives the first registration request from the AF, sends the first registration request to AMF, receives the first registration response from the AMF, and then sends the first registration response to the AF. The principle is the same when the network device is another network element.

[0034] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation, the first request message is a first inventory request, the second information includes information about the terminals that need to be inventoried, and the first information includes a list of terminals that need to be inventoried and need to be registered on the network; the second request message is a first registration request.

[0035] In this implementation, the first request message is specifically in the form of an inventory request. Correspondingly, the second information includes information about the terminals to be inventoried, such as the terminal's device ID and the region information of the terminal's location. The first information includes a list of terminals that need to be inventoried and registered; however, it doesn't necessarily have to be a list, as long as it indicates which terminals among those to be inventoried still need to be registered (i.e., not registered). After receiving the first inventory request, the network device generates a first registration request and sends it to the next network node.

[0036] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation, the information of the terminals to be inventoried includes one or more of the following: a list of terminal identifiers, terminal filtering conditions, and group identifiers.

[0037] In combination with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation:

[0038] The receiving terminal sends registration feedback information and inventory results, including:

[0039] The receiving terminal sends a first registration response, which includes the terminal's registration feedback information and inventory results;

[0040] Send the terminal registration feedback information and inventory results to the AF, including:

[0041] Send a first inventory response to the AF or an inventory response generated based on the first inventory response. The first inventory response includes the terminal's registration feedback information and the inventory results.

[0042] This implementation method mainly reflects that if the network receives the first inventory request and sends out the first registration request, then the feedback received in response to the first registration request can be the first registration response, and the feedback sent out by the network device in response to the first inventory request can be the first inventory response.

[0043] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation, the first request message is a second registration request, the first information includes information about the terminal to be registered, the second information also includes a waiting instruction, the waiting instruction is used to indicate that after waiting for a first time, the second registration request and the services associated with the second registration request will be processed together, and the method further includes: receiving a second inventory request sent by AF, wherein the second inventory request is used to request an inventory of the terminal, and the second inventory request belongs to the services associated with the second registration request.

[0044] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminal to be registered, such as the terminal's device ID and the region information of the area where the terminal is located. The second information includes a waiting instruction, which is used to instruct the registration request and subsequent associated services to be processed together. For example, when the inventory request is set as an associated service of the registration request, after the network element receives the second registration request, it can process the second registration request and the subsequently received second inventory request together, that is, the registration and inventory will be started together.

[0045] In conjunction with the first aspect, or any of the above-mentioned possible implementations of the first aspect, another possible implementation further includes:

[0046] Send a second inventory request to the terminal.

[0047] In this implementation, after receiving the second registration request and the second inventory request, the network device may not merge the two requests temporarily, but instead send them to the next network node for merging.

[0048] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation, the registration result and inventory result sent by the receiving terminal include:

[0049] The receiving terminal sends a second registration response, wherein the second registration response includes the terminal's registration feedback information;

[0050] The receiving terminal sends a second inventory response, wherein the second inventory response includes the terminal's inventory results.

[0051] In this implementation, the registration results and inventory results received by the network device are encapsulated in different types of messages. For example, the registration feedback information is encapsulated in the second registration response, while the inventory results are encapsulated in the second inventory response.

[0052] In conjunction with the first aspect, or any of the above-mentioned possible implementations of the first aspect, another possible implementation further includes:

[0053] After the waiting time indicated by the waiting instruction is reached, a first registration request is generated based on the second inventory request and the second registration request, wherein the first registration request is used to request network registration and inventory of the terminal.

[0054] In this implementation, the network device merges the second registration request and the subsequently received second inventory request for processing, that is, the registration and inventory are initiated together.

[0055] In conjunction with the first aspect, or any of the above possible implementations of the first aspect, in yet another possible implementation, the receiving terminal sends registration feedback information and inventory results, including:

[0056] The receiving terminal sends a first registration response, which includes the terminal's registration feedback information and inventory results.

[0057] In this implementation, since the network device processes the second registration request and the subsequent received second inventory request together, the feedback information received is a first registration response that includes registration feedback information and inventory results.

[0058] Secondly, embodiments of this application provide a communication method applied to a network device, the method comprising:

[0059] Receive a second inventory request sent by AF, wherein the second inventory request is used to request an inventory of the terminal;

[0060] Send a first registration request to the terminal, wherein the first registration request is used to request network registration and inventory of the terminal;

[0061] The receiving terminal sends a first registration response, wherein the first registration response includes the terminal's registration feedback information and inventory results;

[0062] Send a second inventory response to the AF, wherein the second inventory response includes the inventory results of the terminal.

[0063] In this embodiment, the network device receives a message sent by the AF (Agent First). This can be done either by the AF sending the message directly to the network device and the network device receiving it directly, or by the AF sending the message indirectly to the network device. For example, if there are one or more communication nodes between the AF and the network device, the message sent by the AF is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the network device receives the message. Similarly, the network device sends a message to the AF. This can be done either by the network device sending the message directly to the AF and the AF receiving it directly, or by the network device sending the message indirectly to the AF. For example, if there are one or more communication nodes between the AF and the network device, the message sent by the network device is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the AF receives the message. The same principle applies to the relationship between the network device and the terminal. The network device sends a message to the terminal. This can be done either by the network device sending the message directly to the terminal and the terminal receiving it directly, or by the network device sending the message indirectly to the terminal. For example, if there are one or more communication nodes between the terminal and the network device, the message sent by the network device is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the terminal receives the message. Similarly, when a network device receives a message sent by a terminal, it can be that the terminal sends the message directly to the network device and the network device receives it directly, or it can be that the terminal sends the message indirectly to the network device. For example, there are one or more communication nodes between the terminal and the network device. The message sent by the terminal is forwarded through one or more intermediate nodes (or it may be processed before being forwarded), and then the network device will receive the message.

[0064] Therefore, receiving a message from the AF can be understood as receiving a message sent from the AF link direction, specifically it could be receiving a message sent by a node between the network device and the AF (or possibly the AF itself); sending a message to the AF can be understood as sending a message in the AF link direction, specifically it could be sending a message to a node between the network device and the AF (or possibly the AF itself); receiving a message from the terminal can be understood as receiving a message sent from the terminal link direction, specifically it could be receiving a message sent by a node between the network device and the terminal (or possibly the terminal itself); sending a message to the terminal can be understood as sending a message in the terminal link direction, specifically it could be sending a message to a node between the network device and the terminal (or possibly the terminal itself).

[0065] In this implementation, the network device can be an access network device (such as RAN), a core network device (such as AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as NEF. Different types of network devices may handle the second inventory request differently. For example, a second inventory request sent via RAN may carry information added by RAN, while a second inventory request sent via NEF may carry information added by NEF. Furthermore, different types of network devices may receive different registration feedback information. For example, the registration feedback information received by RAN includes parameters used for registration, while the registration feedback information received by AMF may include registration status (e.g., registered).

[0066] If a network device receives a second inventory request from a network element, it needs to send a second inventory response to that network element. If a network device sends a first registration request to a network element, it will receive a first registration response from that network element.

[0067] In addition, information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0068] It is understandable that the first registration request includes both information related to network registration and information related to inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0069] Thirdly, embodiments of this application provide a communication method applied to a network device, the method comprising:

[0070] Receive the second inventory request from AF, wherein the second inventory request is used to request an inventory of the terminal;

[0071] A third registration request is sent to the terminal, wherein the first registration request is used to request network registration of the terminal;

[0072] The receiving terminal sends a third registration response, wherein the first registration response includes the terminal's registration feedback information;

[0073] Register the terminal to the core network based on the third registration response;

[0074] Query the terminal inventory results from the storage network elements of the core network;

[0075] Send a second inventory response to the AF, wherein the second inventory response includes the inventory results of the terminal.

[0076] In this embodiment, the network device receives a message sent by the AF (Agent First). This can be done either by the AF sending the message directly to the network device and the network device receiving it directly, or by the AF sending the message indirectly to the network device. For example, if there are one or more communication nodes between the AF and the network device, the message sent by the AF is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the network device receives the message. Similarly, the network device sends a message to the AF. This can be done either by the network device sending the message directly to the AF and the AF receiving it directly, or by the network device sending the message indirectly to the AF. For example, if there are one or more communication nodes between the AF and the network device, the message sent by the network device is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the AF receives the message. The same principle applies to the relationship between the network device and the terminal. The network device sends a message to the terminal. This can be done either by the network device sending the message directly to the terminal and the terminal receiving it directly, or by the network device sending the message indirectly to the terminal. For example, if there are one or more communication nodes between the terminal and the network device, the message sent by the network device is forwarded through these one or more intermediate nodes (or possibly processed before forwarding), and then the terminal receives the message. Similarly, when a network device receives a message sent by a terminal, it can be that the terminal sends the message directly to the network device and the network device receives it directly, or it can be that the terminal sends the message indirectly to the network device. For example, there are one or more communication nodes between the terminal and the network device. The message sent by the terminal is forwarded through one or more intermediate nodes (or it may be processed before being forwarded), and then the network device will receive the message.

[0077] Therefore, receiving a message from the AF can be understood as receiving a message sent from the AF link direction, specifically it could be receiving a message sent by a node between the network device and the AF (or possibly the AF itself); sending a message to the AF can be understood as sending a message in the AF link direction, specifically it could be sending a message to a node between the network device and the AF (or possibly the AF itself); receiving a message from the terminal can be understood as receiving a message sent from the terminal link direction, specifically it could be receiving a message sent by a node between the network device and the terminal (or possibly the terminal itself); sending a message to the terminal can be understood as sending a message in the terminal link direction, specifically it could be sending a message to a node between the network device and the terminal (or possibly the terminal itself).

[0078] In this implementation, the network device can be an access network device (such as RAN), a core network device (such as AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as NEF. Different types of network devices may handle the second inventory request differently. For example, a second inventory request sent via RAN may carry information added by RAN, while a second inventory request sent via NEF may carry information added by NEF. Furthermore, different types of network devices may receive different registration feedback information. For example, the registration feedback information received by RAN includes parameters used for registration, while the registration feedback information received by AMF may include registration status (e.g., registered).

[0079] If a network device receives a second inventory request from a network element, it needs to send a second inventory response to that network element. If a network device sends a third registration request to a network element, it will receive a third registration response from that network element.

[0080] In addition, information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0081] It is understandable that the third registration request includes information related to network registration. Therefore, the network registration process can be initiated through the third registration request. After registration, there is no need to interact with the terminal again to obtain the inventory results. Instead, the inventory results can be queried directly, thus saving signaling and interaction processes and improving inventory efficiency.

[0082] Optionally, the third registration request sent after receiving the second inventory request targets unregistered terminals. For registered terminals, upon receiving the second inventory request, the system can directly search the core network for inventory results of these registered devices and then send the results back to the AF (directly or indirectly). Optionally, the inventory results retrieved for registered devices and the results retrieved for unregistered devices after new registration can be aggregated and then sent back to the AF via the second inventory response.

[0083] Fourthly, embodiments of this application provide a communication method applied to an application function network element (AF), the method comprising:

[0084] Send a first request message to the network device, wherein the first request message includes first information and second information, the first information being information related to terminal network registration, and the second information being information related to terminal inventory;

[0085] Receive terminal registration feedback information and inventory results sent by network devices.

[0086] In this implementation, the first request message can be either a Registration Request message (enhancing an existing registration request to include inventory-related information) or an Inventory Request message (enhancing an existing inventory request to include network registration-related information), or any other message format, which is not limited here. Furthermore, the received terminal's registration feedback information and inventory results are generally relayed or processed by other devices before being sent. Regarding the terminal's registration feedback information and inventory results, they can be sent in a single message, for example, both encapsulated in a Registration Response, both encapsulated in an Inventory Response, or encapsulated in other message types. Alternatively, the registration feedback information and inventory results can be sent in separate messages; for example, the registration feedback information can be encapsulated in a Registration Response, while the inventory results can be encapsulated in an Inventory Response.

[0087] In addition, the information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; the information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc. The inventory in this application embodiment may also be referred to as inventory.

[0088] It is understandable that the first request message includes both information related to network registration and information related to inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0089] In conjunction with the fourth aspect, in one possible implementation, the first request message is a first registration request, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried.

[0090] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminals to be registered, such as the terminal's device ID and the region information of the terminal's location. The second information indicates that these terminals that need to be registered also need to be inventoried. The second information can be an inventory indicator indi_inventory. In one implementation, all terminals to be registered correspond to one inventory indicator indi_inventory to indicate that these terminals need to be inventoried. In another implementation, each terminal among the terminals to be registered that also needs to be inventoried corresponds to one inventory indicator indi_inventory to indicate that the corresponding terminal needs to be inventoried.

[0091] In conjunction with the fourth aspect, or any of the possible implementations of the fourth aspect described above, in yet another possible implementation, the first registration request further includes third information. This third information is used to instruct the access network equipment and / or core network equipment providing services to the terminal to be registered. In this implementation, the AF may also need to know the information of the access network equipment, core network equipment (such as AMF), and other equipment corresponding to the terminal to be registered and inventoried. Therefore, the third information can be used to instruct the relevant network elements to provide this information.

[0092] In conjunction with the fourth aspect, or any of the possible implementations of the fourth aspect described above, in yet another possible implementation, receiving the terminal's registration feedback information and inventory results sent by the network device includes: receiving a first registration response sent by the network device, the first registration response including the terminal's registration feedback information and inventory results. This implementation primarily reflects that if the first request message sent by the AF is a first registration request, i.e., a message in the format of a registration request (RegistrationRequest), then the final received feedback can be a corresponding message in the format of a registration response (RegistrationResponse), i.e., the first registration response.

[0093] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in yet another possible implementation, the first request message is a first inventory request, the second information includes information about the terminals that need to be inventoried, and the first information includes a list of terminals that need to be inventoried and registered.

[0094] In this implementation, the first request message is specifically in the form of an inventory request. Correspondingly, the second information includes information about the terminals that need to be inventoried, such as the terminal's device ID and the region information of the terminal's location. The first information includes a list of terminals that need to be inventoried and registered. Of course, it does not have to be in the form of a list, as long as it can indicate the terminals that need to be inventoried but also need to be registered (i.e., not registered).

[0095] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in yet another possible implementation, receiving the device registration feedback information and inventory results sent by the network device includes:

[0096] Receive the first inventory response sent by the network device. The first inventory response includes the terminal's registration feedback information and the inventory results.

[0097] This implementation method mainly reflects that if the first request message sent out by AF is the first inventory request, that is, an inventory request message in the format of inventory request, then the feedback received at the end can be a corresponding inventory response message in the format of inventory response, that is, the first inventory response.

[0098] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in yet another possible implementation, the first request message is a second registration request, the first information includes information about the terminal to be registered, the second information includes a waiting instruction, the waiting instruction is used to indicate that after waiting for a first time, the second registration request and the services associated with the second registration request will be processed together, and the method further includes: sending a second inventory request to the network device, wherein the first inventory request is used to request an inventory of the terminal, and the second inventory request belongs to the services associated with the second registration request.

[0099] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminal to be registered, such as the terminal's device ID and the area information of the region where the terminal is located. The second information includes a waiting instruction, which is used to instruct the registration request and subsequent associated services to be processed together. For example, when the inventory request is set as an associated service of the registration request, the network element that receives the second registration request can process the second registration request and the subsequent second inventory request together, that is, the registration and inventory will be started together.

[0100] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in yet another possible implementation, receiving the terminal registration feedback information and inventory results sent by the network device includes:

[0101] Receive a second registration response sent by the network device, wherein the second registration response includes registration feedback information from the terminal;

[0102] Receive a second inventory response sent by the network device, wherein the second inventory response includes the inventory results of the terminal.

[0103] This implementation method mainly reflects that if the first request message sent by AF is a second registration request (i.e., a message in the format of a registration request), and a second inventory request (i.e., a message in the format of an inventory request) is also sent, then the final feedback received can include a registration response message in the format of a registration response corresponding to the second registration request (i.e., a second registration response), and an inventory response message in the format of an inventory request (i.e., a second inventory response).

[0104] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in yet another possible implementation, the inventory results of the terminal include one or more of the following: the terminal's electronic product code (such as EPC), the time information of the inventory execution, etc.

[0105] In conjunction with the fourth aspect, or any of the above possible implementations of the fourth aspect, in yet another possible implementation, the registration feedback information includes one or more of the parameters to be used for registration, or registration status, etc.

[0106] Fifthly, embodiments of this application provide a communication method applied to a terminal, the method comprising:

[0107] Receive a first registration request sent by a network device, wherein the first registration request is used to request the terminal to perform network registration and inventory.

[0108] Send registration feedback information and inventory results to network devices.

[0109] In this implementation, the information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; the information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0110] It is understandable that the first registration request requests both network registration and inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0111] In conjunction with the fifth aspect, in one possible implementation, sending registration feedback information and inventory results to the network device includes: sending a first registration response to the network device, wherein the first registration response includes registration feedback information and inventory results.

[0112] In this implementation, the registration feedback information and inventory results are contained in a registration response message, i.e., the first registration response.

[0113] Sixthly, embodiments of this application provide a communication method applied to a terminal, the method comprising:

[0114] Receive a second inventory request sent by a network device, wherein the second inventory request is used to request an inventory of the terminal;

[0115] If not registered with the core network, send registration feedback information and inventory results to the network devices, or...

[0116] If the terminal is not registered with the core network, a report message is sent to the network device. The report message is used to request the issuance of a second registration request, which is used to register the terminal with the network.

[0117] In this implementation, upon receiving the second inventory request, the terminal determines whether it has already registered with the core network. If not, it directly reports the information to request other network elements to initiate a network registration process. After registration, it responds to the second inventory request, such as a second inventory response. Alternatively, it directly reports the information needed for subsequent registration, enabling other network elements (such as the core network) to promptly register the terminal and respond to the second inventory request, such as a second inventory response, after registration. In other words, if a terminal is not registered during the inventory process, the terminal proactively triggers the network registration process to ensure the smooth completion of the inventory.

[0118] In conjunction with the sixth aspect, one possible implementation also includes:

[0119] If already registered with the core network, send a second inventory response to the network devices. The second inventory response includes the inventory results.

[0120] In this implementation, if the terminal has already registered after receiving the second inventory request, it will directly report the inventory results.

[0121] Seventhly, embodiments of this application provide a communication device, which can be a network device or a device or functional module within a network device, wherein:

[0122] The communication device includes a module for performing the method described in the first aspect or any possible implementation thereof;

[0123] Alternatively, the communication device may include a module for performing the method described in the second aspect or any possible implementation thereof;

[0124] Alternatively, the communication device may include a module for performing the method described in the third aspect or any possible implementation thereof;

[0125] Alternatively, the communication device includes a processor for performing the method described in the first aspect or any possible implementation thereof.

[0126] Alternatively, the communication device may include a processor for performing the method described in the second aspect or any possible implementation thereof.

[0127] Alternatively, the communication device may include a processor for performing the method described in the third aspect or any possible implementation thereof.

[0128] Eighthly, embodiments of this application provide a communication device, which can be an AF or a device or functional module in an AF, wherein:

[0129] The communication device includes a module for performing the method described in the fourth aspect or any possible implementation of the fourth aspect;

[0130] Alternatively, the communication device includes a processor for performing the method described in the fourth aspect or any possible implementation thereof.

[0131] Ninthly, embodiments of this application provide a communication device, which can be a network device or a device or functional module within a network device, wherein:

[0132] The communication device includes a module for performing the method described in the fifth aspect or any possible implementation of the fifth aspect;

[0133] Alternatively, the communication device may include a module for performing the method described in the sixth aspect or any possible implementation thereof;

[0134] Alternatively, the communication device may include a processor for performing the method described in the fifth aspect or any possible implementation thereof.

[0135] Alternatively, the communication device may include a processor for performing the method described in the sixth aspect or any possible implementation thereof.

[0136] In a tenth aspect, embodiments of this application provide a communication device, including a logic circuit and an interface, wherein the logic circuit and the interface are coupled; the interface is used for inputting and / or outputting information, wherein:

[0137] The logic circuit is used to perform the method described in the first aspect or any possible implementation thereof, or...

[0138] The logic circuit is used to execute the method described in the second aspect or any possible implementation thereof, or...

[0139] The logic circuit is used to execute the method described in the third aspect or any possible implementation thereof, or...

[0140] The logic circuit is used to perform the method described in the fourth aspect or any possible implementation thereof, or...

[0141] The logic circuit is used to perform the method described in the fifth aspect or any possible implementation thereof, or...

[0142] The logic circuit is used to perform the method described in the sixth aspect or any possible implementation thereof.

[0143] Eleventhly, embodiments of this application provide a computer-readable storage medium for storing a computer program, wherein:

[0144] When the computer program is executed, it is capable of implementing the first aspect or any possible implementation of the first aspect, or...

[0145] When the computer program is executed, it is capable of implementing the second aspect or any possible implementation of the second aspect, or...

[0146] When the computer program is executed, it is capable of implementing the third aspect or any possible implementation of the third aspect, or...

[0147] When the computer program is executed, it is capable of implementing the fourth aspect or any possible implementation of the fourth aspect, or...

[0148] When the computer program is executed, it is capable of implementing the fifth aspect or any possible implementation of the fifth aspect, or...

[0149] When the computer program is executed, it is capable of implementing the sixth aspect or any possible implementation of the sixth aspect.

[0150] In a twelfth aspect, embodiments of this application provide a communication system, which includes an AF, a network device, and a terminal, wherein:

[0151] The network device is used to perform the method described in the first aspect or any possible implementation of the first aspect, or the second aspect or any possible implementation of the second aspect, or the third aspect or any possible implementation of the third aspect;

[0152] The AF is used to perform the method described in the fourth aspect or any possible implementation thereof;

[0153] The terminal is used to execute the method described in the fifth aspect or any possible implementation of the fifth aspect, or in the sixth aspect or any possible implementation of the sixth aspect.

[0154] It should be understood that the descriptions of technical features, technical solutions, beneficial effects, or similar language in this application do not imply that all features and advantages can be achieved in any single embodiment. Rather, it is understood that the description of a feature or beneficial effect means that a specific technical feature, technical solution, or beneficial effect is included in at least one embodiment. Therefore, the descriptions of technical features, technical solutions, or beneficial effects in this specification do not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions, and beneficial effects described in this embodiment can be combined in any suitable manner. Those skilled in the art will understand that embodiments can be implemented without one or more specific technical features, technical solutions, or beneficial effects of a particular embodiment. In other embodiments, additional technical features and beneficial effects may be identified in specific embodiments that do not embody all embodiments. Attached Figure Description

[0155] The accompanying drawings used in the embodiments of this application are described below.

[0156] Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application;

[0157] Figure 2 This is a schematic diagram of a network topology provided in an embodiment of this application;

[0158] Figure 3 This is a schematic diagram of a network topology provided in an embodiment of this application;

[0159] Figure 4 This is a schematic diagram of a network topology provided in an embodiment of this application;

[0160] Figure 5 This is a schematic diagram of a network topology provided in an embodiment of this application;

[0161] Figure 6 This is a schematic diagram of an AIoT device registration process provided in an embodiment of this application;

[0162] Figure 7 This is a schematic diagram of an AIoT device inventory process provided in an embodiment of this application;

[0163] Figure 8 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0164] Figure 9 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0165] Figure 10 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0166] Figure 11A This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0167] Figure 11B This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0168] Figure 12 This is a flowchart illustrating a communication method provided in an embodiment of this application;

[0169] Figure 13 This is a schematic diagram illustrating the execution logic of a communication method provided in an embodiment of this application;

[0170] Figure 14 This is a schematic diagram illustrating the execution logic of a communication method provided in an embodiment of this application;

[0171] Figure 15 This is a schematic diagram illustrating the execution logic of a communication method provided in an embodiment of this application;

[0172] Figure 16 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0173] Figure 17 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0174] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items.

[0175] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature, and in the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0176] Please see Figure 1 , Figure 1 This is a schematic diagram of the architecture of a communication system provided in an embodiment of this application. The communication system includes, but is not limited to, the following network elements:

[0177] User equipment (UE): This is a device with communication needs, capable of communicating with access network equipment (such as RAN) using some kind of air interface technology. For example, the UE can be a handheld terminal, laptop computer, subscriber unit, cellular phone, smartphone, wireless data card, personal digital assistant (PDA) computer, tablet computer, wireless modem, handheld device, laptop computer, cordless phone, wireless local loop (WLL) station, machine type communication (MTC) terminal, or other devices that can access the network.

[0178] (R)AN: Equipment that provides access for user equipment, including RAN equipment and AN equipment. RAN equipment is mainly radio network equipment in 3GPP networks, while AN can be access network equipment defined outside of 3GPP. Radio Access Network (RAN) equipment is mainly responsible for functions such as radio resource management, quality of service (QoS) management, data compression, and encryption on the air interface side. The RAN equipment can include various forms of base stations, such as macro base stations, micro base stations (also known as small stations), relay stations, and access points. In systems using different radio access technologies, the names of equipment with base station functions may differ. For example, in 5G systems, it is called RAN or gNB (5G NodeB); in LTE systems, it is called evolved NodeB (eNB or eNodeB); and in 3G systems, it is called Node B, etc. Access Network Equipment: This network element allows user equipment to interconnect with the 3GPP core network using non-3GPP technologies. Examples of non-3GPP technologies include Wireless Fidelity (Wi-Fi), Worldwide Interoperability for Microwave Access (WiMAX), and Code Division Multiple Access (CDMA) networks. For ease of description, regardless of whether (R)AN stands for RAN or AN, it will be uniformly referred to as Access Network Equipment.

[0179] The User Plane Function (UPF) network element is responsible for forwarding and receiving user data in the UE. It can receive user data from the data network and transmit it to the UE through access network equipment; the UPF network element can also receive user data from the UE through access network equipment and forward it to the data network. The transmission resources and scheduling functions providing services to the UE in the UPF network element are managed and controlled by the SMF network element.

[0180] Data Network (DN): This refers to a service network that provides data transmission services to users, such as IP Multimedia Service (IMS) and the Internet. The UE accesses the DN through a Packet Data Unit (PDU) session established between the UE and the DN.

[0181] Access and mobility management function (AMF) network elements: mainly responsible for mobility management in mobile networks, such as user location updates, user registration with the network, and user handover.

[0182] The Session Management Function (SMF) network element is responsible for session management in the mobile network, such as session establishment, modification, and release. Specific functions include assigning IP addresses to users and selecting a UPF (User-Defined Provider) to provide packet forwarding capabilities.

[0183] Authentication Server Function (AUSF): Responsible for authentication and authorization.

[0184] Policy control function (PCF) network element: It mainly provides a unified policy framework to control network behavior, provides policy rules to the control layer network functions, and is also responsible for obtaining user subscription information related to policy decisions.

[0185] Application Function (AF) network elements: These mainly support interaction with the 3GPP core network to provide services, such as influencing data routing decisions, policy control functions, or providing some third-party services to the network side.

[0186] Unified Data Management (UDM) network elements are used for generating authentication credentials, processing user identifiers (such as storing and managing permanent user identities), controlling access authorization, and managing subscription data.

[0187] The Network Slice Selection Function (NSSF) is used to select network slices, a new feature introduced in 5G. Multiple slices can be deployed in a network, and slice selection is achieved through NSSF.

[0188] The Network Exposure Function (NEF) provides capabilities that can be made public, such as exporting 5G network capabilities to external networks, including terminal location information. The NEF can also receive external information and manage it by updating certain network information.

[0189] The Network Repository Function (NRF) primarily manages all NFs that support service-oriented interfaces in 5G. These NFs can register with the NRF first. When NFs look up each other, they query the NRF to find each other. This function is somewhat similar to DNS in 4G networks, but the function of NRF is far more complex than that of DNS.

[0190] It should be noted that, in order to make important connections clearer, some network elements or connections are not shown. Their absence does not mean they do not exist. For example, UDRs and their connections with other network elements (NFs), such as PCFs, are not described in the point-to-point section. Those skilled in the art can understand the network elements and connections that are not shown based on common sense.

[0191] It should be noted that, with the iteration and evolution of communication technologies, some network elements in the above communication system may be renamed or given more or fewer functions. Furthermore, the above communication system is illustrated using a 5G communication architecture as an example; the related methods and processes described later can actually be implemented based on other communication architectures, such as 3G, 4G, 6G, and new communication technologies introduced in the future. This application's embodiments do not limit the scope of these implementations.

[0192] by Figure 1 Based on the communication system shown, Ambient IoT (AIoT) devices can be deployed. For example, the user equipment (UE) mentioned earlier can be specifically an AIoT device. The number of AIoT devices can be one or more, but usually there are multiple. The aforementioned AF can maintain a batch of AIoT devices. For example, if there are multiple factories (distributed in different areas) and a batch of AIoT devices are deployed in each factory, then an AF can be deployed in each factory to manage the AIoT devices in the corresponding factory. For example, the AF corresponding to factory 1 manages 10 AIoT devices in factory 1.

[0193] AIoT devices can have various network topologies in communication systems. Several examples are listed below:

[0194] Topology 1, such as Figure 2 As shown, the path from the AIoT device to the access network device (R)AN is: AIoT device —— (R)AN.

[0195] Topology 2, such as Figure 3 As shown, the path from the AIoT device to the access network device (R)AN is: AIoT device —— intermediate node —— (R)AN.

[0196] Topology 3, such as Figure 4As shown, the path from the AIoT device to the access network device (R)AN is: (R)AN——AIoT device——assisting node——(R)AN.

[0197] Topology 4, such as Figure 5 As shown, the network access function of (R)AN is replaced on the mobile node (such as UE): AIoT device - UE.

[0198] The subsequent methodology will focus on Figure 2 The topology shown is illustrated using topology 1 as an example. In reality, when the topology is changed to... Figure 3 , Figure 4 , Figure 5 In other topologies, the overall logic of the method flow remains unchanged, except that the relevant communication messages will pass through other nodes, or the processing of the relevant communication messages will change to other nodes.

[0199] This application's embodiments mainly focus on the registration and inventory of AIoT devices. The registration and inventory process will be described below.

[0200] Please see Figure 6 , Figure 6 This is a schematic diagram of an AIoT device registration process provided in an embodiment of this application. The method can be based on... Figure 1 The architecture shown, and the related topology mentioned above, are implemented using the following methods:

[0201] Step 0: Pre-configuration before registration. For example, before registering an AIoT device, the AIoT device owner pre-configures the necessary information for registration with the network. This information may include the default AIoT device ID and default security credential. Furthermore, before the AIoT device leaves the factory, the manufacturer assigns each device a unique tag ID (TID); and 5GC internal and third-party security credential holders also pre-configure the device TID, default security certificate, and device registration status (unregistered).

[0202] Before an AIoT device completes registration, its default Instance ID value can be 0. The Instance ID value changes after registration. Therefore, an AIoT device can determine its registration status based on whether the locally stored Instance ID is 0. Furthermore, based on the Operator ID (e.g., OperatorID) and Group ID (e.g., GroupID) included in the default AIoT device ID, security certificate holders can be flexibly deployed among service operators, roaming operators, enterprise users, or third-party service providers (AFs) to achieve different network architectures.

[0203] Step 1: The AF sends a registration request to the NEF. This registration request may include the following parameters: transaction number (e.g., TransactionID), TID list (e.g., including the TID of the device to be registered), operator ID list (e.g., Operator ID), area information (e.g., the geographical location information of the area where the device to be registered is located), AF identifier (e.g., AF ID), etc.

[0204] Step 2: NEF receives the registration request and performs the following operations:

[0205] The AF is authenticated to determine whether it is allowed to access the 5G system.

[0206] Check authorization: Determine whether the AF is allowed to initiate the registration process.

[0207] Check authorization: Determine whether the operators in the operator list are authorized.

[0208] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the registration request to the corresponding core network device.

[0209] It should be noted that 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as registration) for executing AIoT services. AIoTF can be a standalone network element or integrated into other network elements (such as AMF). If no new AIoTF is added, AMF can replace its related functions (managing AIoT devices and related processes (such as registration)).

[0210] In addition, NEF only issues a registration request after AF has successfully authenticated and authorized the user.

[0211] Step 3: NEF sends a registration request to AMF or AIoTF. This registration request may carry information such as the TID list, Transaction ID, Operator ID list, and TA list mentioned above.

[0212] Step 4: AMF or AIoTF selects the NG-RAN reader / writer from the TA list.

[0213] Step 5: The AMF or AIoTF sends a registration request to the selected NG-RAN reader / writer. This registration request includes a list of TIDs, a list of Operator IDs, etc.

[0214] Step 6: After receiving the registration request, the NG-RAN reader broadcasts the registration request, which includes a list of TIDs and a list of Operator IDs. If the information of an AIoT device matches the TID and Operator ID lists in the registration request, the registration process is performed after activation using the locally stored default device ID, TID, and security certificate information, including sending a registration message containing the default device ID, TID, and security certificate information to the NG-RAN reader.

[0215] Optionally, if the registration request broadcast by the NG-RAN reader does not include a list of TIDs, all unregistered AIoT devices that match the Operator ID list in the registration request need to perform the registration process. For example, an AIoT device can determine whether it is registered or unregistered based on whether the Instance ID value in its device ID is 0.

[0216] Step 7: The NG-RAN reader forwards the registration message to the AMF or AIoTF.

[0217] Step 8: After receiving the registration message from the reader, the AMF or AIoTF determines the target certificate holder based on the Operator ID and / or Group ID obtained from the default device ID.

[0218] Step 9: The AMF or AIoTF and the certificate holder perform device authentication using the TID (as the username) and a security certificate. Once authentication is successful, 5GC (or the federated AF) generates a unique and non-zero Instance ID (a component of the device ID) for the device. This newly generated device ID will be used between 5GC and the AIoT device.

[0219] Step 10: 5GC stores the newly generated device ID, TID, registration status (registered) for a specific AIoT device in UDM, AMF, or AIoTF; the principle is the same for other AIoT devices.

[0220] Step 11: AMF or AIoTF sends the newly generated device ID (such as a non-zero InstanceID) to the corresponding AIoT device.

[0221] Step 12: AMF or AIoTF sends a registration response to NEF.

[0222] Step 13: NEF sends a registration response to AF.

[0223] Please see Figure 7 , Figure 7 This is a schematic diagram of an AIoT device inventory process provided in an embodiment of this application. The method can be based on... Figure 1 The architecture shown, and the related topology mentioned above, are implemented using the following methods:

[0224] Step 1: The AF sends an inventory request to the NEF. This request may include the following parameters: transaction number (e.g., TransactionID), device identification information, region information (e.g., the geographical location of the device to be inventoried), and AF identifier (e.g., AF ID). The device identification information can be information assigned to the device to be inventoried that distinguishes it from other devices. This device identification information can be a TID or other device identifier. For example, the EPC or AF assigns a local identifier to each terminal within its management scope. Within the AF's management scope, different terminals have different local identifiers. By using the AF's identifier and the local identifier, any two different terminals can be distinguished globally. In one optional scheme, the device identification information may be the TID.

[0225] Step 2: NEF receives the inventory request and performs the following operations:

[0226] The AF is authenticated to determine whether it is allowed to access the 5G system.

[0227] Check authorization: Determine whether the AF is allowed to initiate the inventory process.

[0228] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the inventory request to the corresponding core network device.

[0229] It should be noted that 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as inventory). AIoTF can be a standalone network element or integrated into other network elements (such as AMF). If no new AIoTF is added, AMF can replace its related functions (managing AIoT devices and related processes such as inventory).

[0230] In addition, NEF only issues the inventory request after AF has successfully authenticated and authorized the data.

[0231] Step 3: NEF sends an inventory request to AMF or AIoTF. This inventory request can carry information such as the above-mentioned device identification information list, Transaction ID, TA list, etc.

[0232] Step 4: AMF or AIoTF selects the NG-RAN reader / writer from the TA list.

[0233] Step 5: The AMF or AIoTF sends an inventory request to the selected NG-RAN reader, which includes a list of device identification information, etc.

[0234] Step 6: After receiving the inventory request, the NG-RAN reader broadcasts the inventory request, which contains a list of device identification information.

[0235] Step 7: If the information of an AIoT device matches the list of device identification information in the inventory request (other information may also need to be confirmed to match, such as the Operator), then obtain the inventory result and send an inventory response (also called inventory result) to the NG-RAN reader. For example, the inventory response includes the AIoT device identification code, which may be the device's Electronic Product Code (EPC).

[0236] Step 8: The NG-RAN reader forwards the inventory response to the AMF or AIoTF.

[0237] Step 9: After receiving the inventory response from the reader, the AMF or AIoTF interacts with the AUSF and UDM and verifies the device identity based on the device identifier reported by the device. Optionally, the AMF or AIoTF stores the inventory results of the AIoT devices in the UDM, AMF, or AIoTF.

[0238] Step 10: AMF or AIoTF sends an inventory response to NEF.

[0239] Step 11: NEF returns an inventory count response to AF.

[0240] The applicant believes that when the registration and inventory requests issued by the AF target the same group (or individual), the related execution processes are similar or repetitive, and there is a dependency between inventory and registration. Therefore, the applicant considers merging the registration and inventory processes. For example, when the AIoT device that the AF wants to inventory is not registered, the AF or the core network CN instructs the AIoT device to complete registration and report the inventory results simultaneously, in order to reduce the number of signaling messages and CN processing overhead, thereby improving the response speed of AIoT devices and the efficiency of inventory. The following is a combination of... Figures 8-13 The plan to combine the registration and inventory processes will be explained in detail.

[0241] Please seeFigure 8 , Figure 8 This is a flowchart illustrating a communication method provided in an embodiment of this application. This communication method can be based on... Figure 1 The architecture shown, or other architecture implementations, depend on a topology that may be Figures 2-5 The method may use any of the topologies shown or other topologies. In this method, the registration request sent by the AF is enhanced so that it indicates both inventory and registration. The method includes, but is not limited to, the following steps:

[0242] Step S801: AF sends the first registration request to NEF.

[0243] The first registration request includes first information and second information. The first information is related to the terminal's network registration, and the second information is related to the terminal's inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. The terminal can be an Internet of Things (IoT) device (such as an AIoT device) or other types of devices.

[0244] Optionally, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried. The message format of the first registration request is a registration request, which is equivalent to an enhanced registration request, adding the function of requesting an inventory of the terminals.

[0245] In this case, the first information includes information about the terminal to be registered. Specifically, the first information may include a list of device information for one or more terminals to be registered, such as a list of device first identifiers (e.g., a TID list). Alternatively, the first information may include regional information, which indicates that terminals within the corresponding region belong to the terminal to be registered. Of course, other methods can also be used to indicate the terminal to be registered. The information used to indicate the terminal to be registered may be one or more items.

[0246] The second information may include an inventory indicator, indi_inventory. For example, an additional inventory indicator, indi_inventory, is set for each terminal to be registered that is involved in the first information, indicating that the terminal to be registered needs to be inventoried. Alternatively, an inventory indicator, indi_inventory, can be set for all terminals to be registered that are involved in the first information, indicating that all unregistered terminals need to be inventoried.

[0247] The first registration request may also include third information, which is used to indicate information from the access network equipment (such as RAN) and / or core network equipment (such as AMF) that provides services to the terminal to be registered. For example, the third information may include a reader identifier (indi_reader) to indicate information from the RAN reader (such as a timestamped RAN ID or UE ID for timely updates of the RAN information associated with the terminal by the AF or other network elements), and an AMF identifier (indi_AMF) to indicate information from the AMF, such as an AMF ID. This AMF ID can have various possibilities, such as a globally unique AMF identifier (GUAMI) or a custom AMF name, used in network management and maintenance scenarios to facilitate administrator identification and management of different AMF instances. The AMF name may contain geographical location information (such as "AMF-NewYork") or a functional description (such as "AMF-HighCapacity"). It can also be a Network Function Instance Identifier (NF Instance ID), used to uniquely identify each network function instance in the 5G core network, including the AMF. This NF Instance ID can be assigned and managed by the Network Function Registration Function (NRF). Of course, in addition to instructing feedback of information from access network devices or the AMF, the third-party information processing can also instruct feedback of information from other network elements, based on the same principle as the AMF and RAN.

[0248] The initial registration request may also include other information, such as a transaction number (e.g., Transaction ID), a list of operator IDs (e.g., Operator ID), and an AF identifier (AF ID). Optionally, before a terminal completes registration, the Instance ID value in its default terminal ID can be 0; the Instance ID value will change after registration. Therefore, the terminal can determine its registration status based on whether the locally stored Instance ID is 0. The list of operator IDs (e.g., Operator ID) can identify the operator providing services to the unregistered terminal, and the AF identifier (AF ID) can identify the AF managing the unregistered terminal. Alternatively, the terminal may not have a default ID and instead determine its registration status through other information stored locally or remotely.

[0249] Step S802: NEF receives the first registration request.

[0250] After receiving the first registration request, NEF can perform one or more of the following operations:

[0251] The AF is authenticated to determine whether it is allowed to access the 5G system (or other communications).

[0252] Check authorization: Determine whether the AF is allowed to initiate the registration process.

[0253] Check authorization: Determine whether the operators in the operator list are authorized (this operation can be performed if an operator list exists).

[0254] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the first registration request to the corresponding core network device.

[0255] Optionally, after NEF has successfully authenticated the AF and verified the authorization, it issues a first registration request. Optionally, the first registration request may include a list of TAs.

[0256] It should be noted that NEF can perform other related operations before issuing the first registration request, such as performing other condition checks, and issuing the first registration request only if other conditions are met.

[0257] It should be noted that NEF can parse the first registration request to obtain the content indicated by the first registration request, or it can choose not to parse the first registration request and only pass it through. The specific choice can be pre-configured as needed.

[0258] Step S803: NEF sends the first registration request to the core network equipment.

[0259] The specific device or function within the core network referred to here is not limited; the network element involved may differ in different scenarios. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as registration) for executing AIoT services. AIoTF can be an independent network element or integrated into other network elements (such as AMF). If no new AIoTF is added, the AMF can replace its related functions (managing AIoT devices and related processes (such as registration)). Therefore, in this case, the core network device can be either AIoTF or AMF.

[0260] Step S804: The core network device receives the first registration request.

[0261] It should be noted that before the core network device sends out the first registration request, it can also perform other related operations, such as performing other condition checks, and sending out the first registration request if other conditions are met.

[0262] It should be noted that core network devices can parse the first registration request to obtain the content indicated by it. For example, the received first registration request may not carry a transaction ID; instead, the core network device (such as the AMF) adds the transaction ID to the first registration request. Similarly, the first registration request received by the core network may not carry the aforementioned third information; instead, the core network device adds the third information to the first registration request and sends the first registration request carrying the third information to the next node (such as the access network device RAN). In practical applications, the AF may not need to obtain RAN reader / writer information and AMF information, while the core network device does. Therefore, the core network device adds the corresponding requirement to the first registration request. The subsequent processing principle can be that whoever requests it should receive the feedback. That is, if the third information is added to the first registration request by the AF, then the RAN reader / writer information and AMF information should ultimately be fed back to the AF; if the third information is added to the first registration request by the core network device, then the RAN reader / writer information and AMF information should ultimately be fed back to the core network device, without needing to be fed back to the AF. Of course, core network devices may also choose not to parse the first registration request, but only to pass it through. The specific choice can be pre-configured as needed.

[0263] Step S805: The core network device sends the first registration request to the access network device.

[0264] Specifically, the core network equipment can select the corresponding access network equipment (RAN) from the TA list, such as the NG-RAN reader, and then send the first registration request to the NG-RAN reader.

[0265] Step S806: The access network device receives the first registration request.

[0266] Step S807: The access network device sends the first registration request to the terminal.

[0267] The access network device can send the first registration request via broadcast or unicast.

[0268] Step S808: The terminal receives the first registration request.

[0269] Step S809: The terminal sends a first registration response to the access network device.

[0270] On the one hand, the terminal can learn from the first information in the first registration request that network registration is required. Specifically, the first registration request includes a first identifier list (such as a TID list). The terminal determines whether its own information matches the first identifier list in the first registration request. If they match, after activation, it uses the default device ID, first identifier (such as TID), and security certificate stored locally to perform the registration process, including sending the default device ID, first identifier (such as TID), and security certificate to the access network device (such as an NG-RAN reader). This can be considered as the registration feedback information returned by the terminal to the access network device.

[0271] Optionally, when determining a match, other information may also need to be matched. The specific information to be matched can be pre-configured as needed. For example, it might be necessary to match the Operator ID.

[0272] If the first registration request includes a list of Operator IDs, optionally, if the first registration request broadcast by the access network device (such as an NG-RAN reader) does not include a list of First Identifiers (TIDs), then all unregistered terminals matching the Operator ID list in the first registration request need to perform the registration procedure. For example, a terminal can determine whether it is registered or unregistered based on whether the Instance ID value in the device ID is 0.

[0273] On the other hand, the terminal can learn that an inventory needs to be carried out based on the second information in the first registration request. Therefore, the terminal will obtain the inventory results and report them. Optionally, the inventory results include EPC.

[0274] Therefore, the first registration response includes registration feedback information (e.g., terminal default device ID, first identifier (e.g., TID), security certificate, etc.) and inventory results (e.g., EPC).

[0275] In one alternative approach, the content of the first registration request can be entirely or partially encapsulated in a non-access stratum message (NAS Msg) within a Next Generation Application Protocol (NGAP) message / NGAP-like Msg. Correspondingly, the first registration response (RegistrationResponse) from the end device can also be entirely or partially encapsulated in a single NAS Msg. For example, the first identifier (e.g., TID), OperatorID, and credentials from the first registration response can be encapsulated in the NAS Msg. The content of this NAS Msg is not visible to access network devices (e.g., RAN readers). The self-inventory results reported by the terminal (e.g., EPC) can be included in the NAS Msg or encapsulated in a NASMsg container. Core network devices (e.g., AMF / AIoTF) are also not visible to the contents of the NASMsg container; that is, the core network devices cannot parse the inventory results reported by the terminal, ensuring data security and privacy during core network transmission. The specific content to be encapsulated in the NAS Msg, the content to be encapsulated outside the NAS Msg, and other possible content encapsulation methods can be configured according to the needs of the scenario.

[0276] Step S810: The access network device receives the first registration response.

[0277] Step S811: The access network device sends the first registration response to the core network device.

[0278] Step S812: The access network device receives the first registration response.

[0279] Step S813: The core network equipment determines the target certificate holder based on the first registration response.

[0280] For example, the target certificate holder can be determined based on the Operator ID and / or Group ID obtained from the default device ID included in the first registration response.

[0281] Step S814: The core network device and the certificate holder authenticate the device using TID and security certificate.

[0282] Among them, TID can be used as a username. Taking 5GC as an example, once authentication is successful, 5GC (or AF in conjunction with 5GC) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0283] The newly generated device IDs will be used between the core network (e.g., 5GC) and the terminals (e.g., AIoT devices).

[0284] Step S815: The core network device will store the newly generated device ID, first identifier, and registration status for the terminal in the core network.

[0285] Once registration is complete, the registration status here is "registered". The information that needs to be stored includes the newly generated device ID, first identifier (such as TID), and registration status of the terminal, as well as other information, such as inventory results (such as EPC) and RAN ID. The information stored in the core network can be specifically stored in network elements or functions such as UDM, AMF, or AIoTF in the core network.

[0286] For example, using the terminal's new device ID as an index, the new device ID, first identifier (such as TID), registration status (already registered), EPC (if the device reported EPC), RAN ID (if the RAN reader received the indi_reader instruction and returned the RANID), and AMF ID (if the AMF or AIoTF received the indi_AMF instruction and returned the AMF ID) are stored in UDM, AMF, and AIoTF to construct device context information.

[0287] Step S816: The core network device sends the newly generated device ID to the terminal through the access network device.

[0288] For example, the newly generated device ID can be a non-zero instance ID.

[0289] Using the above method, the terminal can be registered to the core network; the registration principle for other terminals is the same.

[0290] For more details on this registration section, please refer to [link / reference]. Figure 6 Steps 7-11 in the method flow shown.

[0291] Step S817: The core network device sends the first registration response to NEF.

[0292] The information carried in the first registration response received by the core network device may differ from the information carried in the first registration response sent by the core network device. For example, the first registration response received by the core network device includes information for registering the terminal to the core network and inventory results; while the first registration response sent by the core network device includes information that the terminal has already registered to the core network and inventory results. Furthermore, if the third information is added to the first registration request by the core network device, the RAN ID and / or AMF ID returned in response to the third information may be carried in the first registration response received by the core network device, but may not be carried in the first registration response sent by the core network device.

[0293] Step S818: NEF receives the first registration response.

[0294] Step S819: NEF sends the first registration response to AF.

[0295] Specifically, NEF can parse the content of the first registration response or directly forward the first registration response.

[0296] Step S820: AF receives the first registration response.

[0297] For example, the first registration response includes a Transaction ID, a first identifier (such as a TID), registration feedback information (such as a state indicating that the terminal has completed registration), and inventory results (such as EPC information). Optionally, if the third information is added to the first registration request by the AF, then the RAN ID and / or AMF ID for the feedback of the third information can be carried in the first registration response received by the AF. The message format of this first registration response is a Registration response.

[0298] At this point, AF has completed the registration and inventory of one or more terminals.

[0299] exist Figure 8 In the method shown, when a device has both registration and inventory requirements, the first registration request sent by the AF explicitly informs the terminal that it is not registered and needs to be inventoried. This causes the core network to trigger the registration process and issue an inventory instruction at the same time. Subsequently, network registration and inventory are completed synchronously. This saves the core network from the identity verification steps of the terminal after receiving the inventory results, reduces the number of signaling in the network and the number of terminal reports, improves the energy efficiency of the terminal, and reduces the processing overhead of the core network.

[0300] Please see Figure 9 , Figure 9 This is a flowchart illustrating a communication method provided in an embodiment of this application. This communication method can be based on... Figure 1 The architecture shown, or other architecture implementations, depend on a topology that may be Figures 2-5 The method may use any of the topologies shown or other topologies. In this method, the inventory request sent by the AF is enhanced so that it indicates both inventory and registration. The method includes, but is not limited to, the following steps:

[0301] Step S901: AF sends the first inventory request to NEF.

[0302] The first inventory request includes first information and second information. The first information is related to the terminal's network registration, and the second information is related to the terminal's inventory. Therefore, the first inventory request can initiate both the network registration process and the inventory process. The terminal can be an Internet of Things (IoT) device (such as an AIoT device) or other types of devices.

[0303] Optionally, the second information includes information about the terminals that need to be inventoried, and the first information includes a list of terminals that need to be inventoried and registered on the network; the message format of the first inventory request is an inventory request, which is equivalent to enhancing the inventory request by adding the function of requesting the terminals to register on the network.

[0304] In this scenario, the second information includes information about the terminals that need to be inventoried. Specifically, the second information can include a list of device information for one or more terminals that need to be inventoried, such as a list of second device identifiers (e.g., an EPC list, a third-party AF custom local identifier, or other types of identifiers). Alternatively, the second information can include region information, indicating that terminals within a specific region belong to the terminals that need to be inventoried. Of course, other methods can also be used to indicate which terminals need to be inventoried. The information used to indicate which terminals need to be inventoried can be one or more pieces. Optionally, the second information can also include an inventory strategy, which indicates the relevant requirements or rules for inventory, such as inventory frequency and inventory cycle.

[0305] The first information may include a registration indicator `indi_registration`. For example, among the terminals requiring inventory as mentioned in the second information, some or all may not have been registered yet. Therefore, an additional registration indicator `indi_registration` is set for all these unregistered terminals to indicate that they need to be registered. Alternatively, a single registration indicator `indi_registration` can be set for all unregistered terminals among those requiring inventory as mentioned in the first information, indicating that all these unregistered terminals need to be registered. Therefore, the first information may include a registration list `unregistered_list(X,Y,Z,...)` containing information about all unregistered terminals (such as device IDs) and a registration indicator `indi_registration`. This `indi_registration` indicates that all terminals recorded in the registration list need to be registered on the network. Here, X, Y, Z,... represent the device IDs of different terminals. In one alternative scheme, the first information includes a list of terminals that need to be both registered and inventoried, such as a first identifier list (e.g., a TID list), with the registration indicator indi_registration indicating that all terminals in this list need to be registered. The second information includes a list of all terminals that need to be inventoried, such as an EPC list.

[0306] The first inventory request may also include third information, which is used to indicate the information of the access network equipment (such as RAN) and / or core network equipment (such as AMF) that provides services to the terminal to be registered. For example, the third information includes a reader identifier indi_reader to indicate the feedback of RAN reader information (such as a timestamped RAN ID or UE ID, for timely updates of the reader RAN information associated with the terminal by the AF or other network elements), and an AMF identifier indi_AMF to indicate the feedback of AMF information, such as an AMF ID. The AMF ID has several possibilities, such as a globally unique AMF identifier (GUAMI), or a custom AMF name, used in network management and operation scenarios to facilitate administrators in identifying and managing different AMF instances. The AMF name may contain geographical location information (such as "AMF-NewYork") or functional description (such as "AMF-HighCapacity"). It can also be a Network Function Instance Identifier (NF Instance ID), used to uniquely identify each network function instance in the 5G core network, including the AMF. This NF Instance ID can be assigned and managed by the Network Function Registration Function (NRF). Of course, in addition to instructing feedback of information from access network devices or the AMF, the third-party information processing can also instruct feedback of information from other network elements, based on the same principle as the AMF and RAN.

[0307] Optionally, the first inventory request may also include other information, such as an AF identifier (AF ID), which can be used to identify the AF managing the terminal that needs to be inventoried.

[0308] Step S902: NEF receives the first inventory request.

[0309] After receiving the first inventory request, NEF can perform one or more of the following operations:

[0310] The AF is authenticated to determine whether it is allowed to access the 5G system (or other communications).

[0311] Check authorization: Determine whether the AF is allowed to initiate the inventory process.

[0312] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the corresponding message to the corresponding core network device, such as the first registration request.

[0313] Optionally, after NEF authenticates AF, it generates a first registration request based on the first inventory request. For example, NEF can know from the second information in the first inventory request that one or more terminals need to be inventoried, and at the same time, it can know from the first information in the first inventory request that some devices have not yet registered with the network. Therefore, it converts the first inventory request into a first registration request. The message format of the first registration request is a registration request, which is equivalent to enhancing the registration request by adding the function of requesting terminals to be inventoried.

[0314] Optionally, the first registration request generated in this step may include the following: transaction number (e.g., Transaction ID), first identifier list (e.g., TID list), registration list unregistered_list(X,Y,Z), inventory indicator indi_inventory, etc. The registration list unregistered_list(X,Y,Z) indicates the list of terminals that need to register for network access, and the inventory indicator indi_inventory indicates that these terminals also need to be inventoried. Optionally, before a terminal completes registration, the default Instance ID value in its terminal ID can be 0. After registration, the Instance ID value will change. Therefore, the terminal can determine its registration status based on whether the locally stored Instance ID is 0. Of course, the terminal may determine its registration status through other methods; the specific method used to determine the registration status can be pre-configured. Optionally, the aforementioned first identifier list can be determined based on the aforementioned second identifier list and a pre-stored identifier mapping relationship. For example, if a mapping relationship between the second and first identifiers is pre-stored, knowing the second identifiers of some terminals allows us to determine the first identifiers of these terminals, thus obtaining the first identifier list. Optionally, the second identifier may be the same as the first identifier. In this case, there is no need to determine the list of first identifiers through mapping relationships. It should be noted that the first identifier and the second identifier mentioned in the embodiments of this application are both terminal identifiers. The first identifier is described using TID as an example, and the second identifier is described using EPC as an example. In fact, the first identifier may also be EPC or other identifiers, and the second identifier may also be TID or other identifiers. The second identifier may be the same as the first identifier.

[0315] After generating the first registration request, the first registration request is sent out. Optionally, the first registration request may include a list of TAs.

[0316] It should be noted that NEF can perform other related operations before issuing the first registration request, such as performing other condition checks, and issuing the first registration request only if other conditions are met.

[0317] Step S903: NEF sends the first registration request to the core network equipment.

[0318] The specific device or function within the core network referred to here is not limited; the network element involved may differ in different scenarios. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as registration) for executing AIoT services. AIoTF can be an independent network element or integrated into other network elements (such as AMF). If no new AIoTF is added, the AMF can replace its related functions (managing AIoT devices and related processes (such as registration)). Therefore, in this case, the core network device can be either AIoTF or AMF.

[0319] Step S904: The core network device receives the first registration request.

[0320] It should be noted that before the core network device sends out the first registration request, it can also perform other related operations, such as performing other condition checks, and sending out the first registration request if other conditions are met.

[0321] It should be noted that core network devices can parse the first registration request to obtain the content indicated by it. For example, the received first registration request may not carry a transaction ID; instead, the core network device (such as the AMF) adds the transaction ID to the first registration request. Similarly, the first registration request received by the core network may not carry the aforementioned third information; instead, the core network device adds the third information to the first registration request and sends the first registration request carrying the third information to the next node (such as the access network device RAN). In practical applications, the AF may not need to obtain RAN reader / writer information and AMF information, while the core network device does. Therefore, the core network device adds the corresponding requirement to the first registration request. The subsequent processing principle can be that whoever requests it should receive the feedback. That is, if the third information is added to the first registration request by the AF, then the RAN reader / writer information and AMF information should ultimately be fed back to the AF; if the third information is added to the first registration request by the core network device, then the RAN reader / writer information and AMF information should ultimately be fed back to the core network device, without needing to be fed back to the AF. Of course, core network devices may also choose not to parse the first registration request, but only to pass it through. The specific choice can be pre-configured as needed.

[0322] Step S905: The core network device sends the first registration request to the access network device.

[0323] Specifically, the core network equipment can select the corresponding access network equipment (RAN) from the TA list, such as the NG-RAN reader, and then send the first registration request to the NG-RAN reader.

[0324] Step S906: The access network device receives the first registration request.

[0325] Step S907: The access network device sends the first registration request to the terminal.

[0326] The access network device can send the first registration request via broadcast or unicast.

[0327] Step S908: The terminal receives the first registration request.

[0328] Step S909: The terminal sends a first registration response to the access network device.

[0329] On one hand, the terminal learns from the first registration request that network registration is required. Specifically, this first registration request includes a first identifier list (such as a TID list). The terminal determines whether its own information matches the first identifier list (such as the TID list) in the first registration request. If they match, after activation, it uses locally stored information such as the default device ID, the first identifier (such as the TID), and the security certificate to perform the registration process. This includes sending registration messages such as the default device ID, TID, and security certificate to access network devices (such as NG-RAN readers). This can be considered as registration feedback information returned by the terminal to the access network devices. Optionally, determining whether a match occurs may also involve judging other information. The specific information judged can be configured as needed. For example, it can also judge whether the Operator ID matches.

[0330] On the other hand, the terminal can know that an inventory count is required based on the indi_inventory in the first registration request. Therefore, the terminal will obtain the inventory count results and report them. Optionally, the inventory count results include EPC.

[0331] Therefore, the first registration response includes registration feedback information (e.g., terminal default device ID, first identifier (e.g., TID), security certificate, etc.) and inventory results (e.g., EPC).

[0332] In one alternative approach, the content of the first registration request can be entirely or partially encapsulated within a NAS Msg in a Next Generation Application Protocol (NGAP) / NGAP-like Msg. Correspondingly, the first registration response from the end device can also be entirely or partially encapsulated within a single NAS Msg. For example, the TID, Operator ID, and credentials from the first registration response can be encapsulated within the NAS Msg. The content of this NAS Msg is not visible to access network devices (such as RAN readers). The inventory results reported by the terminal (such as EPC) can be included in the NAS Msg or encapsulated within a NASMsg container. Core network devices (such as AMF / AIoTF) are also not visible to the contents of the NASMsg container; that is, the core network devices cannot parse the inventory results reported by the terminal, ensuring data security and privacy during core network transmission. The specific content encapsulated within the NAS Msg, the content encapsulated outside the NAS Msg, and other possible encapsulation methods can be configured according to the needs of the scenario.

[0333] Step S910: The access network device receives the first registration response.

[0334] Step S911: The access network device sends a first registration response to the core network device.

[0335] Step S912: The access network device receives the first registration response.

[0336] Step S913: The core network equipment determines the target certificate holder based on the first registration response.

[0337] For example, the target certificate holder can be determined based on the Operator ID and / or Group ID obtained from the default device ID included in the first registration response.

[0338] Step S914: The core network device and the certificate holder authenticate the device using the first identifier (such as TID) and the security certificate.

[0339] Among them, TID can be used as a username. Taking 5GC as an example, once authentication is successful, 5GC (or AF in conjunction with 5GC) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0340] The newly generated device IDs will be used between the core network (e.g., 5GC) and the terminals (e.g., AIoT devices).

[0341] Step S915: The core network device will store the newly generated device ID, first identifier (such as TID), and registration status for the terminal in the core network.

[0342] Once registration is complete, the registration status here is "registered". The information that needs to be stored includes the newly generated device ID, first identifier (such as TID), and registration status of the terminal, as well as other information, such as inventory results (such as EPC) and RAN ID. The information stored in the core network can be specifically stored in network elements or functions such as UDM, AMF, or AIoTF in the core network.

[0343] For example, using the terminal's new device ID as an index, the new device ID, first identifier (such as TID), registration status (already registered), EPC (if the device reported EPC), RAN ID (if the RAN reader received the indi_reader instruction and returned the RANID), and AMF ID (if the AMF or AIoTF received the indi_AMF instruction and returned the AMF ID) are stored in UDM, AMF, and AIoTF to construct device context information.

[0344] Step S916: The core network device sends the newly generated device ID to the terminal through the access network device.

[0345] For example, the newly generated device ID can be a non-zero instance ID.

[0346] Using the above method, the terminal can be registered to the core network; the registration principle for other terminals is the same.

[0347] For more details on this registration section, please refer to [link / reference]. Figure 6 Steps 7-11 in the method flow shown.

[0348] Step S917: The core network device sends the first registration response to NEF.

[0349] The information carried in the first registration response received by the core network device may differ from the information carried in the first registration response sent by the core network device. For example, the first registration response received by the core network device includes information for registering the terminal to the core network, as well as inventory results; while the first registration response sent by the core network device includes information that the terminal has already registered to the core network, as well as inventory results. Furthermore, if the third information is added to the first registration request by the core network device, the RAN ID and / or AMF ID returned in response to the third information may be carried in the first registration response received by the core network device, but may not be carried in the first registration response sent by the core network device.

[0350] Step S918: NEF receives the first registration response.

[0351] Step S919: NEF sends the first inventory count response to AF.

[0352] It should be noted that since NEF sends the first registration request to the core network equipment, it will receive a response to this first registration request from the core network equipment, i.e., the first registration response, with the message format "Registrationresponse". However, NEF receives the first inventory request from AF, and therefore sends a response to this first inventory request back to AF, i.e., the first inventory response, with the message format "Inventory response".

[0353] In other words, NEF needs to convert the first registration response into a first inventory response. This first inventory response can include inventory results, such as the terminal's EPC information. It can also include information such as the Transaction ID and the first identifier (e.g., TID).

[0354] Optionally, the first inventory response may also include indication information, such as state, to indicate that the terminal has registered with the network; further, optionally, if the third information is added to the first inventory request by the AF, then the RAN ID and / or AMF ID fed back for the third information may be carried in the first inventory response received by the AF.

[0355] Step S920: AF receives the first inventory count response.

[0356] AF can obtain the terminal's inventory results and registration status based on the first inventory response.

[0357] At this point, AF has completed the registration and inventory of one or more terminals.

[0358] It should be noted that in the above process, the conversion of the first inventory request into a first registration request is performed by the NEF. However, this conversion can also be performed by either the core network device or the access network device. For example, after receiving the first inventory request, the NEF sends it to the core network device, which then converts it into a first registration request and sends it to the access network device. In short, which network element specifically converts the first inventory request into a first registration request can be configured according to the specific scenario and actual needs; this is not limited here.

[0359] Of course, even in some alternative schemes, after the first inventory request is received by the NEF, it does not need to be converted into a first registration request, but continues to send the first inventory request. The NEF can still add additional information to the received first inventory request to obtain a new first inventory request and send it to the next node. The additional information is the information required to complete the above process.

[0360] Furthermore, in one alternative scheme, after the NEF receives the first inventory request, if it finds that among the terminals that need to be inventoried in the first inventory request, some terminals have completed network registration while others have not, then for the terminals that have not completed registration, the NEF sends the aforementioned first registration request to the core network equipment, while for the terminals that have completed registration, the NEF sends a third inventory request to the core network equipment. The third inventory request includes information on the registered terminals that need to be inventoried, and the message format of the third inventory request is an inventory request.

[0361] The third inventory request includes information on the registered terminals that need to be inventoried. Specifically, the third inventory request may include a second identifier list (such as an EPC list) of one or more registered terminals that need to be inventoried. Alternatively, the third inventory request may include regional information, indicating that terminals within a certain region belong to the terminals that need to be inventoried. Of course, other methods can also be used to indicate the terminals that need to be inventoried. The information used to indicate the terminals that need to be inventoried can be one or more pieces. Optionally, the third inventory request may also include an inventory strategy, which is used to indicate the relevant requirements or rules for inventory, such as inventory frequency, inventory cycle, etc.

[0362] For the inventory process of registered terminals that require inventory checks, please refer to [the relevant documentation / guideline]. Figure 7 The inventory process shown will not be repeated here. It should be noted that the inventory results in the third inventory response received by NEF in response to the third inventory request can be aggregated with the inventory results in the first registration response received by NEF to obtain the inventory results of all terminals involved in the second inventory request. Based on the inventory results of all terminals, a first inventory response is generated and then fed back to AF.

[0363] It should be noted that in the above process, the operation of generating the third inventory request based on the first inventory request is performed by NEF. In reality, this conversion can also be performed by core network equipment or access network equipment. For example, after receiving the first inventory request, NEF sends it to the core network equipment. The core network equipment identifies the registered terminals, generates the third inventory request, and then sends the third inventory request to the access network equipment. In short, which network element generates the third inventory request can be configured according to the specific scenario and actual needs; no limitation is made here.

[0364] exist Figure 9 In the method shown, when a device has both registration and inventory requirements, the first inventory request sent by the AF explicitly informs the terminal that it is not registered and needs to be inventoried. This causes the core network to trigger the registration process and issue an inventory instruction at the same time. Subsequently, network registration and inventory are completed synchronously. This saves the core network from the identity verification steps of the terminal after receiving the inventory results, reduces the number of signaling in the network and the number of terminal reports, improves the energy efficiency of the terminal, and reduces the processing overhead of the core network.

[0365] Please see Figure 10 , Figure 10 This is a flowchart illustrating a communication method provided in an embodiment of this application. This communication method can be based on... Figure 1 The architecture shown, or other architecture implementations, depend on a topology that may be Figures 2-5 The method can be any of the topologies shown or other topologies. In this method, when a terminal is not registered to the network, the AF (Active Network Element) sends both an inventory request and a registration request so that the terminal can return the inventory result after registration. However, the second registration request sent by the AF includes a wait indicator. The network element receiving the second registration request can combine the second registration request with other subsequently received service requests (such as the second inventory request) according to the wait indicator. This method includes, but is not limited to, the following steps:

[0366] Step S1001: AF sends a second registration request to NEF.

[0367] The second registration request includes first information and second information. The first information is related to the terminal's network registration, such as information about the terminal to be registered. The second information is related to the terminal's inventory, such as a waiting instruction. The waiting instruction indicates that the second registration request and the services associated with the second registration request will be processed together after a first period of time. For example, the inventory request can be set as a service associated with the second registration request. The message format of this second registration request is a registration request, which is equivalent to an enhanced registration request, adding the function of waiting for the service to be merged for processing.

[0368] Therefore, the second registration request can both initiate the network registration process for the terminal and support the terminal inventory process. This terminal can be an IoT device (such as an AIoT device) or other types of devices.

[0369] In this case, the first information includes information about the terminal to be registered. Specifically, the first information may include a list of device information for one or more terminals to be registered, such as a first identifier list (e.g., a TID list). Alternatively, the first information may include regional information, which indicates that terminals within the corresponding region belong to the terminal to be registered. Of course, other methods can also be used to indicate the terminal to be registered. The information used to indicate the terminal to be registered may be one item or multiple items.

[0370] The second information may include a wait indicator (e.g., NEF) to instruct the network element receiving the second registration request to temporarily suspend processing the request and wait for a first period of time (the duration can be set as needed) before merging similar or related service requests issued within that first period with the second registration request for processing. The inventory request can be configured as a service associated with the second registration request. Optionally, service requests from the same AF that contain the same Association ID (e.g., an identifier generated by the AF and carried in the service request to indicate the association between multiple services) can be set as associated services. Of course, related services can also be defined using other rules; specific rules are not limited here.

[0371] The second registration request may also include other information, such as a transaction number (e.g., Transaction ID), a list of operator IDs (e.g., Operator ID), and an AF identifier (AF ID). Before a terminal completes registration, its default Instance ID value can be 0; this value changes after registration. Therefore, the terminal can determine its registration status based on whether the locally stored Instance ID is 0. The list of operator IDs (e.g., Operator ID) identifies the operator providing services to the unregistered terminal, and the AF identifier (AF ID) identifies the AF managing the unregistered terminal.

[0372] Step S1002: AF sends a second inventory request to NEF.

[0373] Specifically, the second inventory request may include information about the terminals to be inventoried, such as a second identifier list (e.g., an EPC list) of one or more terminals to be inventoried. It may also include region information, indicating that terminals within a specific region belong to the terminals requiring inventory. Other methods can also be used to indicate which terminals require inventory. The information used to indicate which terminals require inventory can be one or more pieces. Optionally, an inventory strategy may also be included, which indicates the relevant requirements or rules for inventory, such as inventory frequency and inventory cycle.

[0374] The second inventory request may also include third information, which is used to indicate the information of the access network equipment (such as RAN) and / or core network equipment (such as AMF) that provides services to the terminal to be registered. For example, the third information includes a reader identifier indi_reader to indicate the feedback of RAN reader information (such as a timestamped RAN ID or UE ID, for timely updates of the reader RAN information associated with the terminal by the AF or other network elements), and an AMF identifier indi_AMF to indicate the feedback of AMF information, such as an AMF ID. The AMF ID has several possibilities, such as a globally unique AMF identifier (GUAMI), or a custom AMF name, used in network management and operation scenarios to facilitate administrators in identifying and managing different AMF instances. The AMF name may contain geographical location information (such as "AMF-NewYork") or functional description (such as "AMF-HighCapacity"). It can also be a Network Function Instance Identifier (NF Instance ID), used to uniquely identify each network function instance in the 5G core network, including the AMF. This NF Instance ID can be assigned and managed by the Network Function Registration Function (NRF). Of course, in addition to instructing feedback of information from access network devices or the AMF, the third-party information processing can also instruct feedback of information from other network elements, based on the same principle as the AMF and RAN.

[0375] Step S1003: NEF receives the second registration request.

[0376] Step S1004: NEF receives the second inventory request.

[0377] It should be noted that after receiving the second registration request, NEF starts a timer according to the wait indicator in the second registration request. It receives the second inventory request within the first time frame and, upon reaching the first time frame, merges the services requested by the second registration request and the services requested by the second inventory request. For example, NEF can determine from the second registration request that a terminal needs network registration, and from the second inventory request that a terminal needs inventory, thus generating a first registration request. This first registration request includes first and second information. The message format of this first registration request is a registration request, which is essentially an enhanced version of the registration request, adding the function of requesting a terminal inventory.

[0378] The first information includes information about the terminals to be registered. Specifically, the first information includes a list of device information for one or more terminals to be registered, such as a first identifier list (e.g., a TID list), a TA list, etc.

[0379] The second information may include an inventory indicator, indi_inventory. For example, an additional inventory indicator, indi_inventory, is set for each terminal to be registered that is involved in the first information, indicating that the terminal to be registered needs to be inventoried. Alternatively, an inventory indicator, indi_inventory, can be set for all terminals to be registered that are involved in the first information, indicating that all unregistered terminals need to be inventoried.

[0380] Optionally, the first registration request may also include some of the information mentioned above that is carried in the second registration request and / or the second inventory request, such as third information, AF identifier (AF ID), etc., which will not be elaborated here.

[0381] Optionally, after NEF receives the second registration request and waits for a first time according to the wait indicator, it may perform one or more of the following operations before generating the first registration request:

[0382] The AF is authenticated to determine whether it is allowed to access the 5G system (or other communications).

[0383] Check authorization: Determine whether the AF is allowed to initiate the registration process.

[0384] Check authorization: Determine whether the operators in the operator list are authorized (this operation can be performed if an operator list exists).

[0385] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the registration request to the corresponding core network device.

[0386] Optionally, after NEF successfully authenticates the AF and checks the authorization, it generates and issues a first registration request. Optionally, the first registration request may include a list of TAs.

[0387] It should be noted that NEF can perform other related operations before generating the first registration request, such as performing other condition checks, and generating the first registration request if other conditions are met.

[0388] Step S1005: NEF sends the first registration request to the core network equipment.

[0389] The specific device or function within the core network referred to here is not limited; the network element involved may differ in different scenarios. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as registration) for executing AIoT services. AIoTF can be an independent network element or integrated into other network elements (such as AMF). If no new AIoTF is added, the AMF can replace its related functions (managing AIoT devices and related processes (such as registration)). Therefore, in this case, the core network device can be either AIoTF or AMF.

[0390] Step S1006: The core network device receives the first registration request.

[0391] It should be noted that before the core network device sends out the first registration request, it can also perform other related operations, such as performing other condition checks, and sending out the first registration request if other conditions are met.

[0392] It should be noted that core network devices can parse the first registration request to obtain the content indicated by it. For example, the received first registration request may not carry a transaction ID; instead, the core network device (such as the AMF) adds the transaction ID to the first registration request. Similarly, the first registration request received by the core network may not carry the aforementioned third information; instead, the core network device adds the third information to the first registration request and sends the first registration request carrying the third information to the next node (such as the access network device RAN). In practical applications, the AF may not need to obtain RAN reader / writer information and AMF information, while the core network device does. Therefore, the core network device adds the corresponding requirement to the first registration request. The subsequent processing principle can be that whoever requests it should receive the feedback. That is, if the third information is added to the first registration request by the AF, then the RAN reader / writer information and AMF information should ultimately be fed back to the AF; if the third information is added to the first registration request by the core network device, then the RAN reader / writer information and AMF information should ultimately be fed back to the core network device, without needing to be fed back to the AF. Of course, core network devices may also choose not to parse the first registration request, but only to pass it through. The specific choice can be pre-configured as needed.

[0393] Step S1007: The core network device sends the first registration request to the access network device.

[0394] Specifically, the core network equipment can select the corresponding access network equipment (RAN) from the TA list, such as the NG-RAN reader, and then send the first registration request to the NG-RAN reader.

[0395] Step S1008: The access network device receives the first registration request.

[0396] Step S1009: The access network device sends the first registration request to the terminal.

[0397] The access network device can send the first registration request via broadcast or unicast.

[0398] Step S1010: The terminal receives the first registration request.

[0399] Step S1011: The terminal sends a first registration response to the access network device.

[0400] On one hand, the terminal can learn from the first information in the first registration request that network registration is required. Specifically, the first registration request includes a first identifier list (such as a TID list). The terminal determines whether its own information matches the first identifier list (such as a TID list) in the first registration request. If they match, after activation, it uses locally stored information such as the default device ID, the first identifier list (such as a TID list), and the security certificate to perform the registration process. This includes sending registration messages such as the default device ID, TID, and security certificate to the access network device (such as an NG-RAN reader / writer). This can be considered as registration feedback information returned by the terminal to the access network device. Optionally, when determining whether a match is found, it may also be necessary to determine whether other information matches, such as whether the Operator ID matches.

[0401] If the first registration request includes an Operator ID, optionally, if the first registration request broadcast by the access network device (such as an NG-RAN reader) does not include a first identifier list (such as a TID list), then all unregistered terminals matching the Operator ID list in the first registration request need to perform the registration procedure. For example, a terminal can determine whether it is registered or unregistered based on whether the Instance ID value in the device ID is 0.

[0402] On the other hand, the terminal can learn that an inventory needs to be carried out based on the second information in the first registration request. Therefore, the terminal will obtain the inventory results and report them. Optionally, the inventory results include EPC.

[0403] Therefore, the first registration response includes registration feedback information (e.g., terminal default device ID, first identifier list (such as TID list), security certificate, etc.) and inventory results (such as EPC).

[0404] In one alternative approach, the content of the first registration request can be entirely or partially encapsulated within a NAS Msg in a Next Generation Application Protocol (NGAP) / NGAP-like Msg. Correspondingly, the first registration response from the end device can also be entirely or partially encapsulated within a single NAS Msg. For example, the TID, Operator ID, and credentials from the first registration response can be encapsulated within the NAS Msg. The content of this NAS Msg is not visible to access network devices (such as RAN readers). The inventory results reported by the terminal (such as EPC) can be included in the NAS Msg or encapsulated within a NASMsg container. Core network devices (such as AMF / AIoTF) are also not visible to the contents of the NASMsg container; that is, the core network devices cannot parse the inventory results reported by the terminal, ensuring data security and privacy during core network transmission. The specific content encapsulated within the NAS Msg, the content encapsulated outside the NAS Msg, and other possible encapsulation methods can be configured according to the needs of the scenario.

[0405] Step S1012: The access network device receives the first registration response.

[0406] Step S1013: The access network device sends a first registration response to the core network device.

[0407] Step S1014: The access network device receives the first registration response.

[0408] Step S1015: The core network equipment determines the target certificate holder based on the first registration response.

[0409] For example, the target certificate holder can be determined based on the Operator ID and / or Group ID obtained from the default device ID included in the first registration response.

[0410] Step S1016: The core network device and the certificate holder authenticate the device using the first identifier and the security certificate.

[0411] The first identifier (such as TID) can be used as the username. Taking 5GC as an example, once authentication is successful, 5GC (or AF in conjunction with 5GC) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0412] The newly generated device IDs will be used between the core network (e.g., 5GC) and the terminals (e.g., AIoT devices).

[0413] Step S1017: The core network device will store the newly generated device ID, first identifier, and registration status for the terminal in the core network.

[0414] Once registration is complete, the registration status here is "registered". The information that needs to be stored includes the newly generated device ID, first identifier (such as TID), and registration status of the terminal, as well as other information, such as inventory results (such as EPC) and RAN ID. The information stored in the core network can be specifically stored in network elements or functions such as UDM, AMF, or AIoTF in the core network.

[0415] For example, using the terminal's new device ID as an index, the new device ID, first identifier (such as TID), registration status (already registered), EPC (if the device reported EPC), RAN ID (if the RAN reader received the indi_reader instruction and returned the RANID), and AMF ID (if the AMF or AIoTF received the indi_AMF instruction and returned the AMF ID) are stored in UDM, AMF, and AIoTF to construct device context information.

[0416] Step S1018: The core network device sends the newly generated device ID to the terminal through the access network device.

[0417] For example, the newly generated device ID can be a non-zero instance ID.

[0418] Using the above method, the terminal can be registered to the core network; the registration principle for other terminals is the same.

[0419] For more details on this registration section, please refer to [link / reference]. Figure 6 Steps 7-11 in the method flow shown.

[0420] Step S1019: The core network device sends the first registration response to NEF.

[0421] The information carried in the first registration response received by the core network device may differ from the information carried in the first registration response sent by the core network device. For example, the first registration response received by the core network device includes information for registering the terminal to the core network and inventory results; while the first registration response sent by the core network device includes information that the terminal has already registered to the core network and inventory results. Furthermore, if the third information is added to the first registration request by the core network device, the RAN ID and / or AMF ID returned in response to the third information may be carried in the first registration response received by the core network device, but may not be carried in the first registration response sent by the core network device.

[0422] Step S1020: NEF receives the first registration response.

[0423] It should be noted that since the NEF sends a first registration request to the core network equipment, it will receive a response to this first registration request from the core network equipment, namely the first registration response, with the message format "Registrationresponse". However, the NEF receives a second registration request and a second inventory request from the AF. Therefore, the messages fed back to the AF include a second inventory response to the second inventory request and a second registration response to the second registration request. Thus, the NEF needs to generate the second registration response and the second inventory response based on the first registration response.

[0424] The second registration response includes information indicating that the terminal has completed registration, such as state, and optionally, Transaction ID, first identifier (such as TID), etc. The second inventory response includes inventory results, such as EPC information.

[0425] Optionally, if the second registration request carries the aforementioned third information, then the RANID and / or AMF ID fed back in response to the third information can be carried in the second registration response received by the AF. Optionally, if the second inventory request carries the aforementioned third information, then the RANID and / or AMF ID fed back in response to the third information can be carried in the second inventory response received by the AF.

[0426] Step S1021: NEF sends a second registration response to AF.

[0427] Step S1022: NEF sends a second inventory response to AF.

[0428] Step S1023: AF receives the second registration response.

[0429] The AF can determine the registration status of the terminal based on the second registration response.

[0430] Step S1024: AF receives the second inventory count response.

[0431] The AF can obtain the inventory results of the terminal based on the second inventory response.

[0432] At this point, AF has completed the registration and inventory of one or more terminals.

[0433] It should be noted that in the above process, the operation of merging the second registration request and the second inventory request to generate the first registration request is performed by the NEF. In reality, this merging process can also be performed by either the core network device or the access network device. For example, after receiving the second registration request and the second inventory request, the NEF sends them to the core network device. The core network device then merges the second registration request and the second inventory request to generate the first registration request, and then sends the first registration request to the access network device. In short, which network element performs the merging process can be configured according to the specific scenario and actual needs; no limitation is made here.

[0434] Of course, even in some alternative schemes, after the second registration request and / or the second inventory request are received by the NEF, they do not need to be merged and processed at the NEF. Instead, the second registration request and the second inventory request are sent to the next node. The NEF can still add additional information to the received second registration request and the second inventory request to obtain new second registration request and second inventory request, and send them to the next node. The additional information is the information required to complete the above process.

[0435] exist Figure 10 In the method shown, when a device has both registration and inventory requirements, the first registration request sent by the AF explicitly informs the terminal that it is not registered. The wait indicator in the first registration request indicates that after waiting for a certain period of time, the registration process requested by the first registration request and the inventory process requested by the subsequent received second inventory request are merged for processing, so that network registration and inventory can be completed synchronously in the future. This saves the core network from the authentication steps of the terminal after receiving the inventory results, reduces the number of signaling in the network and the number of terminal reports, improves the energy efficiency of the terminal, and reduces the processing overhead of the core network.

[0436] Please see Figure 11A , Figure 11A This is a flowchart illustrating a communication method provided in an embodiment of this application. This communication method can be based on... Figure 1 The architecture shown, or other architecture implementations, depend on a topology that may be Figures 2-5 The method can be any of the topologies shown or other topologies. In this approach, the AF initiating the inventory request is unaware of or does not determine whether the terminal has already registered with the network. Whether the terminal is registered and how it registers are all handled by the core network element. This method includes, but is not limited to, the following steps:

[0437] Step S1101: AF sends a second inventory request to NEF.

[0438] The second inventory request includes information about the terminal that needs to be inventoried. The message format of the second inventory request is an inventory request, and the terminal can be an Internet of Things (IoT) device (such as an AIoT device) or other types of devices.

[0439] The second inventory request includes information about the terminals to be inventoried. Specifically, the second inventory request may include a list of device information for one or more terminals to be inventoried, such as a second identifier list (e.g., an EPC list or a third-party AF-defined local identifier). Alternatively, the second inventory request may include region information, indicating that terminals within the corresponding region belong to the terminals to be inventoried. Of course, other methods can also be used to indicate the terminals to be inventoried. The information used to indicate the terminals to be inventoried can be one or more items. Optionally, the second inventory request may also include an inventory strategy, which indicates the relevant requirements or rules for inventory, such as inventory frequency and inventory cycle.

[0440] Optionally, the second inventory request may also include other information, such as AF information (e.g., AF identifier), which can be used to identify the AF managing the terminal that needs to be inventoried.

[0441] The second inventory request may also include third information, which is used to indicate the information of the access network equipment (such as RAN) and / or core network equipment (such as AMF) that provides services to the terminal to be registered. For example, the third information includes a reader identifier indi_reader to indicate the feedback of RAN reader information (such as a timestamped RAN ID or UE ID, for timely updates of the reader RAN information associated with the terminal by the AF or other network elements), and an AMF identifier indi_AMF to indicate the feedback of AMF information, such as an AMF ID. The AMF ID has several possibilities, such as a globally unique AMF identifier (GUAMI), or a custom AMF name, used in network management and operation scenarios to facilitate administrators in identifying and managing different AMF instances. The AMF name may contain geographical location information (such as "AMF-NewYork") or functional description (such as "AMF-HighCapacity"). It can also be a Network Function Instance Identifier (NF Instance ID), used to uniquely identify each network function instance in the 5G core network, including the AMF. This NF Instance ID can be assigned and managed by the Network Function Registration Function (NRF). Of course, in addition to instructing feedback of information from access network devices or the AMF, the third-party information processing can also instruct feedback of information from other network elements, based on the same principle as the AMF and RAN.

[0442] Step S1102: NEF receives the second inventory request.

[0443] After receiving the first inventory request, NEF can perform one or more of the following operations:

[0444] The AF is authenticated to determine whether it is allowed to access the 5G system (or other communications).

[0445] Check authorization: Determine whether the AF is allowed to initiate the inventory process.

[0446] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the corresponding message to the corresponding core network device, such as the second inventory request.

[0447] Optionally, after successfully authenticating the AF, the NEF sends a second inventory request to the core network equipment. Optionally, this second inventory request may include information such as a TA list and AF information (e.g., AF ID).

[0448] It should be noted that NEF can perform other related operations before issuing the second inventory count request, such as performing other condition checks, and issuing the second inventory count request only if other conditions are met.

[0449] Step S1103: NEF sends a second inventory request to the core network equipment.

[0450] The specific device or function within the core network referred to here is not limited; the network element involved may differ in different scenarios. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as registration) for executing AIoT services. AIoTF can be an independent network element or integrated into other network elements (such as AMF). If no new AIoTF is added, the AMF can replace its related functions (managing AIoT devices and related processes (such as registration)). Therefore, in this case, the core network device can be either AIoTF or AMF.

[0451] Step S1104: The core network equipment receives the second inventory request.

[0452] The core network device generates a first registration request based on the second inventory request. For example, the core network device can learn from the second inventory request that one or more terminals need to be inventoried. At the same time, the core network device can obtain information such as the registration status of terminal information from the UDM, that is, it can know which devices have not registered to the network (the core network may not store the EPC or third-party custom identifiers of unregistered devices). Therefore, the core network device generates a first registration request based on the second inventory request and the information of the terminals that have not registered to the network. The message format of the first registration request is a registration request, which is equivalent to enhancing the registration request, so that the registration request additionally adds the function of requesting the terminals to be inventoried.

[0453] Optionally, the first registration request generated in this step may include the following: a transaction number (e.g., Transaction ID), an unregistered device list (unregistered_list(X,Y,Z)) (such as an EPC list or a third-party AF custom identifier list), and an inventory indicator (indi_inventory). The unregistered device list (unregistered_list(X,Y,Z)) indicates the list of terminals that have not registered with the network, and the inventory indicator (indi_inventory) indicates that these terminals that need to register with the network also need to be inventoried. Optionally, before a terminal completes registration, its default Instance ID value can be 0. After registration, the Instance ID value will change. Therefore, the terminal can determine its registration status based on whether the locally stored Instance ID is 0. Of course, the terminal may also determine whether it has registered through other methods; the specific method used can be configured according to actual needs.

[0454] For example, the second inventory request received by the core network device does not carry the aforementioned third information. Instead, the core network device generates a first registration request carrying the third information and sends this first registration request to the next node (such as the access network device RAN). The corresponding practical application scenario is that the AF may not have a need to obtain RAN reader / writer information and AMF information, but the core network device does. Therefore, the core network device adds the corresponding requirement to the first registration request. The subsequent processing principle can be to feed back to the one that requested it. That is, if the third information is added to the first registration request by the core network, then the RAN reader / writer information and AMF information should eventually be fed back to the core network device. If the third information is added to the first registration request by other devices, then the RAN reader / writer information and AMF information should eventually be fed back to those other devices, without needing to be fed back to the AF.

[0455] Step S1105: The core network device sends a first registration request to the access network device.

[0456] Specifically, the core network equipment can select the corresponding access network equipment (RAN) from the TA list, such as the NG-RAN reader, and then send the first registration request to the NG-RAN reader.

[0457] Step S1106: The access network device receives the first registration request.

[0458] Step S1107: The access network device sends the first registration request to the terminal.

[0459] The access network device can send the first registration request via broadcast or unicast.

[0460] Step S1108: The terminal receives the first registration request.

[0461] Step S1109: The terminal sends a first registration response to the access network device.

[0462] On the one hand, the terminal can learn from the first registration request that network registration is required. Specifically, the first registration request includes a second identifier list (such as an EPC list or a third-party custom identifier list) and AF information (such as an AF ID). The terminal determines whether its own information matches the second identifier list and AF information (AF ID) in the first registration request. If they match, after activation, the terminal uses the locally stored default device ID, second identifier, and security certificate to perform the registration process, including sending registration messages such as the default device ID, second identifier, and security certificate to the access network device (such as an NG-RAN reader). This can be considered as the registration feedback information returned by the terminal to the access network device.

[0463] On the other hand, the terminal can know that an inventory needs to be carried out based on the indi_inventory in the first registration request. Therefore, the terminal will obtain the inventory results and report them. Optionally, the inventory results include EPC, third-party custom identifiers, etc.

[0464] Therefore, the first registration response includes registration feedback information (e.g., terminal default device ID, security certificate, etc.) and inventory results (e.g., EPC, third-party custom identifier, etc.).

[0465] In one alternative approach, the content of the first registration request can be entirely or partially encapsulated within a NAS Msg in an NGAP / NGAP-like Msg. Similarly, the first registration response from the end device can also be entirely or partially encapsulated within a single NAS Msg. For example, the second identifier, Operator ID, and credentials from the first registration response can be encapsulated within the NAS Msg. The content of this NAS Msg is not visible to access network devices (such as RAN readers). The inventory results reported by the terminal (such as EPC) can be included in the NAS Msg or encapsulated within a NASMsg container. The AMF / AIoTF is also not visible to the contents of the NASMsg container, meaning the core network cannot parse the inventory results reported by the device, thus ensuring data security and privacy during core network transmission. The specific content encapsulated within the NASMsg, the content encapsulated outside the NAS Msg, and other possible encapsulation methods can be configured according to the specific scenario requirements.

[0466] Step S1110: The access network device receives the first registration response.

[0467] Step S1111: The access network device sends the first registration response to the core network device.

[0468] Step S1112: The access network device receives the first registration response.

[0469] Step S1113: The core network equipment determines the target certificate holder based on the first registration response.

[0470] For example, the target certificate holder can be determined based on the Operator ID and / or Group ID obtained from the default device ID included in the first registration response.

[0471] Step S1114: The core network device and the certificate holder authenticate the device using the second identifier and security certificate.

[0472] The second identifier (such as EPC) can be used as the username. Taking 5GC as an example, once authentication is successful, 5GC (or AF in conjunction with 5GC) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0473] The newly generated device IDs will be used between the core network (e.g., 5GC) and the terminals (e.g., AIoT devices).

[0474] Step S1115: The core network device will store the newly generated device ID, second identifier, and registration status for the terminal in the core network.

[0475] Once registration is complete, the registration status here is "registered". The information that needs to be stored includes the newly generated device ID, secondary identifier, and registration status of the terminal, as well as other information, such as inventory results (e.g., EPC), RANID, etc. The information stored in the core network can be specifically stored in network elements or functions such as UDM, AMF, or AIoTF in the core network.

[0476] For example, using the terminal's new device ID as an index, the new device ID, second identifier, registration status (already registered), EPC (if the device reported EPC), RAN ID (if the RAN reader received the indi_reader instruction and returned the RAN ID), and AMFID (if the AMF or AIoTF received the indi_AMF instruction and returned the AMF ID) are stored in UDM, AMF, and AIoTF to construct device context information.

[0477] Step S1116: The core network device sends the newly generated device ID to the terminal through the access network device.

[0478] For example, the newly generated device ID can be a non-zero instance ID.

[0479] Using the above method, the terminal can be registered to the core network; the registration principle for other terminals is the same.

[0480] For more details on this registration section, please refer to [link / reference]. Figure 6 Steps 7-11 in the method flow shown.

[0481] Step S1117: The core network device sends a second inventory response to NEF.

[0482] It is understandable that core network equipment can learn about the registration status of the terminal, such as whether it has been registered, and the inventory results of the terminal, such as the terminal's EPC, from the first registration response.

[0483] It should be noted that since NEF sends a second inventory request to the core network equipment, it will receive a response to this second inventory request from the core network equipment, namely the second inventory response, and the message format is Inventory response.

[0484] In other words, the core network equipment needs to convert the first registration response into a second inventory response. This second inventory response can include inventory results, such as the terminal's EPC information, and may also include information such as the Transaction ID.

[0485] Step S1118: NEF receives the second inventory count response.

[0486] Step S1119: NEF sends a second inventory response to AF.

[0487] Step S1120: AF receives the second inventory count response.

[0488] AF can obtain the inventory results of the terminal based on the second inventory response, such as the terminal's EPC information.

[0489] At this point, AF has completed the inventory of one or more terminals.

[0490] It should be noted that in the above process, the conversion of the second inventory request into a first registration request is performed by the core network equipment (such as AMF / AIoTF). In fact, this conversion can also be performed by the NEF. For example, after receiving the second inventory request, the NEF identifies unregistered terminals and generates a first registration request based on the information of the unregistered terminals and the second inventory request, then sends the first registration request to the AMF / AIoTF. In short, which network element generates the first registration request based on the second inventory request and the information of the unregistered terminals can be configured according to the specific scenario and actual needs; this is not limited here.

[0491] Of course, even in some alternative schemes, after the second inventory request is received by the NEF, there is no need for the NEF to convert it into a first registration request. The NEF can still add additional information to the received second inventory request to obtain a new second inventory request and send it to the next node. The additional information is the information required to complete the above process.

[0492] Furthermore, in an optional scheme, after the AMF / AIoTF receives the second inventory request and obtains information such as the registration status of the terminals from the UDM, if it finds that among the terminals that need to be inventoried in the second inventory request, some terminals have completed network registration while others have not, then for the terminals that have completed registration, the AMF / AIoTF sends a third inventory request to the access network device. The third inventory request includes information on the registered terminals that need to be inventoried, and the message format of the third inventory request is an inventory request.

[0493] The third inventory request includes information on the registered terminals that need to be inventoried. Specifically, the third inventory request can include a list of device information for one or more registered terminals that need to be inventoried, such as a device identifier list (e.g., a TID list). Alternatively, the third inventory request can include region information, indicating that terminals within a certain region belong to the terminals that need to be inventoried. Of course, other methods can also be used to indicate the terminals that need to be inventoried. The information used to indicate the terminals that need to be inventoried can be one or more pieces. Optionally, the third inventory request can also include an inventory strategy, which is used to indicate the relevant requirements or rules for inventory, such as inventory frequency, inventory cycle, etc.

[0494] For the inventory process of registered terminals that require inventory checks, please refer to [the relevant documentation / guideline]. Figure 7 The inventory process shown will not be repeated here. It should be noted that the inventory results in the third inventory response received by AMF / AIoTF in response to the third inventory request can be aggregated with the inventory results in the first registration response received by AMF / AIoTF to obtain the inventory results of all terminals involved in the second inventory request. Based on the inventory results of all terminals, a first inventory response is generated and then fed back to AF.

[0495] It should be noted that in the above process, the operation of generating the third inventory request based on the second inventory request is performed by the AMF / AIoTF. In reality, this conversion can also be performed by other devices. For example, after receiving the second inventory request, the NEF identifies the registered terminals and generates the third inventory request based on the information of the registered terminals and the second inventory request, then sends the third inventory request to the AMF / AIoTF. In short, which network element generates the third inventory request based on the second inventory request and the information of the registered terminals can be configured according to the specific scenario and actual needs, and is not limited here.

[0496] exist Figure 11A In the method shown, when a device needs to be inventoried, a second inventory request sent by the AF explicitly informs the terminal that an inventory check is required. After receiving the second inventory request, if other network elements find that the terminal has not yet registered, they generate a first registration request based on the second inventory request and send it to subsequent nodes. This first registration request can simultaneously trigger the registration process and the inventory process, so that network registration and inventory can be completed synchronously. This saves the core network from the authentication steps of the terminal after receiving the inventory results, reduces the number of signaling in the network and the number of terminal reports, improves the energy efficiency of the terminal, and reduces the processing overhead of the core network.

[0497] Please see Figure 11B , Figure 11B This is a flowchart illustrating a communication method provided in an embodiment of this application. This communication method can be based on... Figure 1 The architecture shown, or other architecture implementations, depend on a topology that may be Figures 2-5 The method can be any of the topologies shown or other topologies. In this approach, the AF initiating the inventory request is unaware of or does not determine whether the terminal has already registered with the network. Whether the terminal is registered and how it registers are all handled by the core network element. This method includes, but is not limited to, the following steps:

[0498] Step S1161: AF sends a second inventory request to NEF.

[0499] The second inventory request includes information about the terminal that needs to be inventoried. The message format of the second inventory request is an inventory request, and the terminal can be an Internet of Things (IoT) device (such as an AIoT device) or other types of devices.

[0500] The second inventory request includes information about the terminals to be inventoried. Specifically, the second inventory request may include a list of device information for one or more terminals to be inventoried, such as a second identifier list (e.g., an EPC list or a third-party AF-defined local identifier). Alternatively, the second inventory request may include region information, indicating that terminals within the corresponding region belong to the terminals to be inventoried. Of course, other methods can also be used to indicate the terminals to be inventoried. The information used to indicate the terminals to be inventoried can be one or more items. Optionally, the second inventory request may also include an inventory strategy, which indicates the relevant requirements or rules for inventory, such as inventory frequency and inventory cycle.

[0501] Optionally, the second inventory request may also include other information, such as AF information (e.g., AF identifier), which can be used to identify the AF managing the terminal that needs to be inventoried.

[0502] The second inventory request may also include third information, which is used to indicate the information of the access network equipment (such as RAN) and / or core network equipment (such as AMF) that provides services to the terminal to be registered. For example, the third information includes a reader identifier indi_reader to indicate the feedback of RAN reader information (such as a timestamped RAN ID or UE ID, for timely updates of the reader RAN information associated with the terminal by the AF or other network elements), and an AMF identifier indi_AMF to indicate the feedback of AMF information, such as an AMF ID. The AMF ID has several possibilities, such as a globally unique AMF identifier (GUAMI), or a custom AMF name, used in network management and operation scenarios to facilitate administrators in identifying and managing different AMF instances. The AMF name may contain geographical location information (such as "AMF-NewYork") or functional description (such as "AMF-HighCapacity"). It can also be a Network Function Instance Identifier (NF Instance ID), used to uniquely identify each network function instance in the 5G core network, including the AMF. This NF Instance ID can be assigned and managed by the Network Function Registration Function (NRF). Of course, in addition to instructing feedback of information from access network devices or the AMF, the third-party information processing can also instruct feedback of information from other network elements, based on the same principle as the AMF and RAN.

[0503] Step S1162: NEF receives the second inventory request.

[0504] After receiving the first inventory request, NEF can perform one or more of the following operations:

[0505] The AF is authenticated to determine whether it is allowed to access the 5G system (or other communications).

[0506] Check authorization: Determine whether the AF is allowed to initiate the inventory process.

[0507] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the corresponding message to the corresponding core network device, such as the second inventory request.

[0508] Optionally, after successfully authenticating the AF, the NEF sends a second inventory request to the core network equipment. Optionally, this second inventory request may include information such as a TA list and AF information (e.g., AF ID).

[0509] It should be noted that NEF can perform other related operations before issuing the second inventory count request, such as performing other condition checks, and issuing the second inventory count request only if other conditions are met.

[0510] Step S1163: NEF sends a second inventory request to the core network equipment.

[0511] The specific device or function within the core network referred to here is not limited; the network element involved may differ in different scenarios. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element, AIoTF, to manage AIoT devices and related processes (such as registration) for executing AIoT services. AIoTF can be an independent network element or integrated into other network elements (such as AMF). If no new AIoTF is added, the AMF can replace its related functions (managing AIoT devices and related processes (such as registration)). Therefore, in this case, the core network device can be either AIoTF or AMF.

[0512] Step S1164: The core network equipment receives the second inventory request.

[0513] The core network equipment queries the UDM for information about the terminal corresponding to each second identifier in the second identifier list (such as the EPC list or a third-party AF-defined local identifier). This information includes the terminal's registration status, the information of the AF to which it belongs (such as the AF identifier), TID, EPC, or the AF-defined local identifier. If the information of the corresponding terminal cannot be found in the UDM using the second identifier, it is assumed that the terminal has not yet registered in the core network (e.g., 5G C). If the information of the corresponding terminal can be found in the UDM using the second identifier, it is assumed that the terminal has already registered in the core network (e.g., 5G C). Next, a list of second identifiers for registered terminals and a list of second identifiers for unregistered terminals are generated, such as unregistered_list(X,Y,Z).

[0514] Specifically, the second identifier list for registered terminals includes information about these devices that the core network equipment has retrieved from the UDM based on the second identifier. Therefore, the relevant information can be associated with the corresponding second identifier to serve as the inventory result for the corresponding device. For example, the TID and second identifier can be associated and used as the inventory result for the corresponding terminal. In other words, all or part of the information in the second identifier list of registered terminals can be used as the inventory result for each terminal involved in that second identifier list.

[0515] The third registration request is generated by the core network equipment based on the unregistered_list (X, Y, Z) of the unregistered terminal's second identifier list. This third registration request includes: a transaction ID, the unregistered terminal's second identifier list (such as an EPC list or a third-party AF-defined local identifier list), AF information (such as an AF ID; optionally, if the second identifier is an AF-defined local identifier, the AF ID needs to be combined with this local identifier to uniquely identify the globally unique terminal), and inventory policies (such as inventory frequency and inventory cycle). The message format of this third registration request is a registration request.

[0516] Step S1165: The core network device sends a third registration request to the access network device.

[0517] Specifically, the core network equipment can select the corresponding access network equipment (RAN) from the TA list, such as the NG-RAN reader, and then send a third registration request to the NG-RAN reader.

[0518] Step S1166: The access network device receives a third registration request.

[0519] Step S1167: The access network device sends a third registration request to the terminal.

[0520] Access network devices can send third-party registration requests via broadcast or unicast.

[0521] Step S1168: The terminal receives a third registration request.

[0522] Step S1169: The terminal sends a third registration response to the access network device.

[0523] On one hand, the terminal learns from the third registration request that network registration is required. Specifically, the first registration request includes a second identifier list (such as an EPC list or a third-party custom identifier list) and AF information (such as an AF ID). The terminal determines whether its own information matches the second identifier list and AF information (AF ID) in the third registration request. If they match, after activation, it uses locally stored information such as the default device ID, the first identifier, and the security certificate to perform the registration process. This includes sending registration messages such as the default device ID, the first identifier (such as a TID), and the security certificate to the access network device (such as an NG-RAN reader / writer). This can be considered as registration feedback information returned by the terminal to the access network device. Therefore, the third registration response includes registration feedback information (e.g., the terminal's default device ID, security certificate, and first identifier (such as a TID)).

[0524] Step S1170: The access network device receives the third registration response.

[0525] Step S1171: The access network device sends a third registration response to the core network device.

[0526] Step S1172: The access network device receives the third registration response.

[0527] Step S1173: The core network determines the target certificate holder based on the third registration response.

[0528] For example, the target certificate holder can be determined based on the Operator ID and / or Group ID obtained from the default device ID contained in the third registration response.

[0529] Step S1174: The core network device and the certificate holder authenticate the device using the first identifier and the security certificate.

[0530] The first identifier (such as TID) can be used as the username. Taking 5GC as an example, once authentication is successful, 5GC (or AF in conjunction with 5GC) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0531] The newly generated device IDs will be used between the core network (e.g., 5GC) and the terminals (e.g., AIoT devices).

[0532] Step S1175: The core network device will store the newly generated device ID, first identifier, and registration status for the terminal in the core network.

[0533] Once registration is complete, the registration status here is "registered". The information to be stored can be specifically stored in network elements or functions such as UDM, AMF, or AIoTF in the core network.

[0534] For example, using the terminal's new device ID as an index, the new device ID, first identifier, registration status (already registered), etc., are stored in UDM, AMF, and AIoTF to construct device context information.

[0535] Step S1176: The core network device sends the newly generated device ID to the terminal through the access network device.

[0536] For example, the newly generated device ID can be a non-zero instance ID.

[0537] Using the above method, the terminal can be registered to the core network; the registration principle for other terminals is the same.

[0538] In this embodiment of the application, the third registration request sent out by the core network device carries a second identifier (such as EPC), and the third registration response received subsequently carries a first identifier (such as TID). Therefore, the core network device can use a pre-configured mechanism to match the second identifier (such as EPC) corresponding to the first identifier after obtaining the first identifier (such as TID), and then use the matched EPC as the inventory result of the terminal corresponding to the first identifier (such as TID).

[0539] For more details on this registration section, please refer to [link / reference]. Figure 6 Steps 7-11 in the method flow shown.

[0540] Step S1177: The core network equipment sends a second inventory response to NEF.

[0541] It is understandable that core network equipment can obtain the terminal's registration status, such as "already registered," from the third registration response, and match the terminal's inventory results, such as the second identifier (e.g., EPC), using the first identifier in the third registration response. Therefore, core network equipment can generate a second inventory response, which includes the terminal's inventory results.

[0542] It should be noted that, as mentioned earlier, after the core network equipment receives the second inventory request, it will directly query the inventory results of the registered terminals. For unregistered terminals, the new registration of these terminals is achieved by sending a third registration request and receiving a third registration response. Subsequently, the inventory results of the newly registered terminals can be matched with the first identifier in the third registration response. Therefore, the inventory results of the terminals involved in the second inventory request can be obtained. Thus, the second inventory response here can include the inventory results of each terminal involved in the second inventory request.

[0543] Optionally, the second inventory response may only include the inventory results of newly registered terminals, while the inventory results of previously registered terminals may be sent through a separate inventory response. The specific implementation method is not limited here.

[0544] It should be noted that since NEF sends a second inventory request to the core network equipment, it will receive a response to this second inventory request from the core network equipment, namely the second inventory response, and the message format is Inventory response.

[0545] In other words, the core network equipment needs to convert the third registration response into a second inventory response. This second inventory response can include inventory results, such as the terminal's EPC information, and may also include information such as the Transaction ID.

[0546] Step S1178: NEF receives the second inventory count response.

[0547] Step S1179: NEF sends a second inventory response to AF.

[0548] Step S1180: AF receives the second inventory count response.

[0549] AF can obtain the inventory results of the terminal based on the second inventory response, such as the terminal's EPC information.

[0550] At this point, AF has completed the inventory of one or more terminals.

[0551] It should be noted that in the above process, the conversion of the second inventory request into a third registration request is performed by the core network equipment (such as AMF / AIoTF). In fact, this conversion can also be performed by the NEF. For example, after receiving the second inventory request, the NEF identifies unregistered terminals and generates a third registration request based on the information of the unregistered terminals and the second inventory request, then sends the third registration request to the AMF / AIoTF. In short, which network element generates the third registration request based on the second inventory request and the information of the unregistered terminals can be configured according to the specific scenario and actual needs, and is not limited here.

[0552] Of course, even in some alternative schemes, after the second inventory request is received by the NEF, there is no need for the NEF to convert it into a third registration request. The NEF can still add additional information to the received second inventory request to obtain a new second inventory request and send it to the next node. The additional information is the information required to complete the above process.

[0553] exist Figure 11B In the method shown, when a terminal needs to perform an inventory check, a second inventory check request sent by the AF explicitly informs the terminal that an inventory check is required. After receiving the second inventory check request, other network elements can directly query the inventory check results corresponding to the terminal if they find that the terminal has already registered. If they find that the terminal has not yet registered, they generate a third registration request based on the second inventory check request and send it to subsequent nodes. This third registration request can trigger the registration process. After registration, the inventory check results corresponding to the terminal are queried. In this scheme, the terminal's inventory check results are directly queried from the corresponding storage location, rather than being reported by the terminal. This reduces the number of signaling calls and terminal reporting times within the network, improves terminal energy efficiency, and reduces core network processing overhead.

[0554] Please see Figure 12 , Figure 12 This is a flowchart illustrating a communication method provided in an embodiment of this application. This communication method can be based on... Figure 1 The architecture shown, or other architecture implementations, depend on a topology that may be Figures 2-5 In any of the topologies shown or other topologies, if a terminal successfully registers, it can store its registration state in local non-volatile storage (i.e., it can retain it even after the terminal is powered off), or implicitly identify its registration state through some means. This method includes, but is not limited to, the following steps:

[0555] Step S1201: AF sends a second inventory request to NEF.

[0556] The second inventory request may include the following parameters: transaction number (e.g., Transaction ID), second identifier list (e.g., EPC list, or a third-party AF-defined local identifier list), area information (e.g., geographical location information of the area where the device to be inventoried is located), AF identifier (e.g., AF ID), etc.

[0557] Step S1202: NEF receives the second inventory request.

[0558] After receiving the second inventory request, NEF performs the following operations:

[0559] The AF is authenticated to determine whether it is allowed to access the 5G system.

[0560] Check authorization: Determine whether the AF is allowed to initiate the inventory process.

[0561] The location information is converted into a TA list. NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) based on the TA list, and then send the second inventory request to the corresponding core network device.

[0562] Optionally, after successfully authenticating the AF, the NEF issues a second inventory request, which may include a list of TAs.

[0563] It should be noted that NEF can perform other related operations before issuing the second inventory count request, such as performing other condition checks, and issuing the second inventory count request only if other conditions are met.

[0564] It should be noted that NEF can parse the second inventory request to obtain the content indicated by the second inventory request, or it can choose not to parse the second inventory request and only pass it through. The specific choice can be pre-configured as needed.

[0565] Step S1203: NEF sends a second inventory request to the core network equipment.

[0566] The second inventory request may carry information such as a second identifier list (e.g., an EPC list, or a third-party AF-defined local identifier list), Transaction ID, TA list, and AF information (e.g., AF ID).

[0567] Step S1204: The core network equipment receives the second inventory request.

[0568] The core network equipment selects the access network equipment based on the TA list. For example, the access network equipment could be an NG-RAN reader / writer.

[0569] Step S1205: The core network device sends a second inventory request to the selected access network device.

[0570] The second inventory request includes a second list of identifiers, etc.

[0571] Step S1206: The access network device receives the second inventory request.

[0572] Step S1207: The access network device sends a second inventory request.

[0573] The access network device can send the second inventory request via unicast or broadcast. The second inventory request includes information such as the second identifier list (AF).

[0574] Step S1208: The terminal receives the second inventory request.

[0575] The terminal will determine whether its device information matches the second identifier list and AF information (if any) in the second inventory request. The terminal will also determine whether it has completed network registration based on the stored information or the information that can be obtained.

[0576] Several possible scenarios exist for the subsequent execution process:

[0577] In scenario one, an unregistered terminal cannot respond to business requests other than the registration request, i.e., it cannot respond to the second inventory request.

[0578] Method 1: such as Figure 13 As shown, after receiving the second inventory request, the terminal first checks its own registration status. If it is not registered, it remains silent and does not respond to the second inventory request. If it is registered, it checks whether its own device information (such as device ID) matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request. If they match, it needs to respond to the second inventory request, that is, execute step S1209, which is to send the second inventory response. If they do not match, it remains silent and does not respond to the second inventory request. In this method, the terminal's registration must be triggered by the registration request on the network side.

[0579] Method 2: such as Figure 14 As shown, after receiving the second inventory request, the terminal first determines its own registration status. If it is already registered, it checks whether its device information (such as device ID) matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request. If they match, it needs to respond to the second inventory request, i.e., execute the subsequent step S1209. If they do not match, it remains silent, i.e., it does not respond to the second inventory request. If it is not registered, it then checks whether its device information (such as device ID) matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request. If they do not match, it remains silent. If they match, it reports to the network side that it is in an unregistered state and requests the network side to issue a registration request. After the terminal receives the registration request, it interacts with the relevant network elements to complete the registration. If the registration is completed, it responds to the second inventory request.

[0580] Scenario 2: Unregistered devices can respond to business requests other than registration requests.

[0581] Method 3: such as Figure 15As shown, after receiving the second inventory request, the terminal first checks whether its own device information (such as device ID) matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request. That is, it determines whether it is the terminal for this second inventory request. If not, it remains silent. If so, it checks its registration status. If registered, it responds to the second inventory request; if not registered, it directly returns a registration response. This registration response is used by access network devices, core network devices, etc., to complete the registration of the terminal. After registration, it responds to the second inventory request. Optionally, the registration response and the response to the second inventory request can be sent in one message or in two separate messages.

[0582] In this embodiment of the application, the terminal may respond to the second inventory request by sending a second inventory response to the access network device. The second inventory response includes a second identifier of the terminal, such as the device's Electronic Product Code (EPC) or a local identifier customized by a third-party AF.

[0583] Step S1209: The terminal sends a second inventory response to the access network device.

[0584] Step S1210: The access network device receives the second inventory response.

[0585] Step S1211: The access network device sends a second inventory response to the core network device.

[0586] Step S1212: The core network equipment receives the second inventory response.

[0587] Step S1213: The core network equipment interacts with AUSF and UDM and authenticates the terminal based on the information fed back by the terminal.

[0588] Optionally, core network equipment can store the terminal inventory results (such as EPC) in the UDM and core network.

[0589] Once identity verification is successful, you can proceed to the next steps.

[0590] Step S1214: The core network device sends a second inventory response to NEF.

[0591] Step S1215: NEF receives the second inventory count response.

[0592] Step S1216: NEF sends a second inventory response to AF.

[0593] Step S1217: AF receives the second inventory count response.

[0594] It is understandable that AF can obtain the terminal's inventory results from the second inventory response, such as EPC.

[0595] Optionally, if the second inventory request also carries third information, the second inventory response may also include information about the access network equipment and / AMF.

[0596] exist Figure 12 In the method shown, when a device needs to be inventoried, a second inventory request sent via the AF explicitly informs the terminal that an inventory check is required. After other network elements receive and forward the second inventory request to the terminal, if the terminal finds that it is not registered, it reports to the core network to trigger the registration process and provides feedback on the inventory results after registration is completed. Alternatively, if it finds that it is not registered, it can directly initiate the registration process and provide feedback on the inventory results. This reduces the number of signaling calls within the network and the number of terminal reports, improves terminal energy efficiency, and reduces core network processing overhead.

[0597] It should be understood that the steps in the above-described method embodiments provided in this application can be implemented by integrated logic circuits in the processor hardware or by instructions in software form. The method steps disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0598] This application divides the communication device into functional modules according to the above-described method embodiments. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. It should be noted that the module division in this application is illustrative and represents only one logical functional division; other division methods may be used in actual implementation. The following will combine... Figure 16 The communication device of the embodiments of this application is described in detail.

[0599] Figure 16 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application, such as... Figure 16As shown, the communication device includes a processing module 1601 and a transceiver module 1602. The transceiver module 1602 can implement corresponding communication functions; for example, the transceiver module 1602 can also be called an interface, communication interface, or communication module. The processing module 1601 is used for data processing, such as generating a first registration request, generating a first inventory response, etc. The transceiver module 1602 can have its own control logic, or it can execute corresponding operations under the control of the processing module 1601. In some embodiments of this application, the communication device can be used to execute the actions performed by the sending end in the above method embodiments. For example, the sending end can be the device itself or a chip or functional module configurable in the device. The transceiver module 1602 is used to execute operations related to information transmission and reception in the above method embodiments, and the processing module 1601 is used to execute data processing-related operations in the above method embodiments (such as generating a first registration request, generating a first inventory response, etc.). The processing module 1601 can execute corresponding operations by calling a computer program or by executing corresponding operations through corresponding hardware circuits. The transceiver module 1602 can perform transceiver operations independently, or it can perform corresponding transceiver operations under the control of the processing module 1601.

[0600] For example, Figure 16 The communication device shown can be an AF or a device in an AF. The processing module 1601 and the transceiver module 1602 in the communication device can respectively perform the following operations:

[0601] Send a first request message to the network device, wherein the first request message includes first information and second information, the first information being information related to terminal network registration, and the second information being information related to terminal inventory;

[0602] Receive the registration feedback information and inventory results of the terminal sent by the network device.

[0603] In this implementation, the first request message can be either a Registration Request message (enhancing an existing registration request to include inventory-related information) or an Inventory Request message (enhancing an existing inventory request to include network registration-related information), or any other message format, which is not limited here. Furthermore, the received terminal's registration feedback information and inventory results are generally relayed or processed by other devices before being sent. Regarding the terminal's registration feedback information and inventory results, they can be sent in a single message, for example, both encapsulated in a Registration Response, both encapsulated in an Inventory Response, or encapsulated in other message types. Alternatively, the registration feedback information and inventory results can be sent in separate messages; for example, the registration feedback information can be encapsulated in a Registration Response, while the inventory results can be encapsulated in an Inventory Response.

[0604] In addition, information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0605] It is understandable that the first request message includes both information related to network registration and information related to inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0606] In one possible implementation, the first request message is a first registration request, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried.

[0607] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminals to be registered, such as the terminal's device ID and the region information of the terminal's location. The second information indicates that these terminals that need to be registered also need to be inventoried. The second information can be an inventory indicator indi_inventory. In one implementation, all terminals to be registered correspond to one inventory indicator indi_inventory to indicate that these terminals need to be inventoried. In another implementation, each terminal among the terminals to be registered that also needs to be inventoried corresponds to one inventory indicator indi_inventory to indicate that the corresponding terminal needs to be inventoried.

[0608] In another possible implementation, the first registration request further includes third information, which is used to indicate information about the access network equipment and / or core network equipment that provides services to the terminal to be registered. In this implementation, the AF may also need to know the information of the access network equipment, AMF, and other equipment corresponding to the terminal to be registered and inventoried, and therefore can use the third information to instruct the relevant network elements to provide this information.

[0609] In another possible implementation, regarding receiving the terminal's registration feedback information and inventory results sent by the network device, the transceiver module 1602 is specifically used to: receive a first registration response sent by the network device, the first registration response including the terminal's registration feedback information and inventory results. This implementation primarily reflects that if the first request message sent by the AF is a first registration request, i.e., a message in the format of a registration request, then the final received feedback can be a corresponding message in the format of a registration response, i.e., a first registration response.

[0610] In another possible implementation, the first request message is a first inventory request, the second information includes information about the terminals that need to be inventoried, and the first information includes a list of terminals that need to be inventoried and registered.

[0611] In this implementation, the first request message is specifically in the form of an inventory request. Correspondingly, the second information includes information about the terminals that need to be inventoried, such as the terminal's device ID and the region information of the terminal's location. The first information includes a list of terminals that need to be inventoried and registered. Of course, it does not have to be in the form of a list, as long as it can indicate the terminals that need to be inventoried but also need to be registered (i.e., not registered).

[0612] In another possible implementation, regarding the method for receiving the registration feedback information and inventory results of the terminal sent by the network device, the transceiver module 1602:

[0613] The system receives a first inventory response from a network device, the first inventory response including the terminal's registration feedback information and inventory results.

[0614] This implementation method mainly reflects that if the first request message sent out by AF is the first inventory request, that is, an inventory request message in the format of inventory request, then the feedback received at the end can be a corresponding inventory response message in the format of inventory response, that is, the first inventory response.

[0615] In another possible implementation, the first request message is a second registration request, the first information includes information about the terminal to be registered, the second information includes a waiting indication, the waiting indication is used to indicate that the second registration request and the services associated with the second registration request will be processed together after waiting for a first time, and the transceiver module 1602 is further used to: send a second inventory request to the network device, wherein the first inventory request is used to request an inventory of the terminal, and the second inventory request belongs to the services associated with the second registration request.

[0616] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminal to be registered, such as the terminal's device ID and the area information of the region where the terminal is located. The second information includes a waiting instruction, which is used to instruct the registration request and subsequent associated services to be processed together. For example, when the inventory request is set as an associated service of the registration request, the network element that receives the second registration request can process the second registration request and the subsequent second inventory request together, that is, the registration and inventory will be started together.

[0617] In another possible implementation, regarding receiving the registration feedback information and inventory results of the terminal sent by the network device, the transceiver module 1602 is specifically used for:

[0618] Receive a second registration response sent by a network device, wherein the second registration response includes registration feedback information of the terminal;

[0619] Receive a second inventory response sent by the network device, wherein the second inventory response includes the inventory results of the terminal.

[0620] This implementation method mainly reflects that if the first request message sent by AF is a second registration request (i.e., a message in the format of a registration request), and a second inventory request (i.e., a message in the format of an inventory request) is also sent, then the final feedback received can include a registration response message in the format of a registration response corresponding to the second registration request (i.e., a second registration response), and an inventory response message in the format of an inventory request (i.e., a second inventory response).

[0621] In another possible implementation, the inventory results of the terminal include one or more of the following: the terminal's electronic product code (such as EPC), the time information of the inventory execution, etc.

[0622] In another possible implementation, the registration feedback information includes one or more of the parameters required for registration or registration status.

[0623] Reuse Figure 16 In other embodiments of this application, exemplarily, Figure 16 The communication device shown can be a network device or a component of a network device. The processing module 1601 and the transceiver module 1602 in the communication device can respectively perform the following operations:

[0624] The transceiver module 1602 receives a first request message sent by the AF, wherein the first request message includes first information and second information, the first information being information related to the terminal registering on the network, and the second information being information related to the terminal taking inventory.

[0625] The transceiver module 1602 sends the first request message or the second request message to the terminal, wherein the second request message is used to request network registration and inventory of the terminal;

[0626] The transceiver module 1602 receives the registration feedback information and inventory results sent by the terminal;

[0627] The transceiver module 1602 sends the terminal's registration feedback information and inventory results to the AF.

[0628] In this implementation, the network device can be an access network device (such as RAN), a core network device (such as AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as NEF. Different types of network devices may process the first request message differently. For example, the first request message sent by the RAN may carry information added by the RAN, while the first request message sent by the NEF may carry information added by the NEF. Furthermore, different types of network devices may receive different registration feedback information. For example, the registration feedback information received by the RAN includes some parameters used for registration, while the registration feedback information received by the AMF may include the registration status (e.g., registered).

[0629] In one alternative scheme, the network device is NEF, and the above method specifically involves: NEF receiving a first request message sent by AF; NEF sending the first request message or a second request message to the core network device; NEF receiving the registration feedback information and inventory results of the terminal sent by the core network device; and NEF sending the registration feedback information and inventory results of the terminal to AF.

[0630] In another alternative scheme, the network device is a core network device, and the above method is specifically as follows: the core network device receives a first request message sent by the NEF; the core network device sends the first request message or a second request message to the access network device; the core network device receives the registration feedback information and inventory results of the terminal sent by the access network device; and the core network device sends the registration feedback information and inventory results of the terminal to the NEF.

[0631] In another alternative scheme, the network device is an access network device, and the above method specifically involves: the access network device receiving a first request message sent by the core network device; the access network device sending the first request message or a second request message to the terminal; the access network device receiving the terminal's registration feedback information and inventory results sent by the terminal; and the access network device sending the terminal's registration feedback information and inventory results to the core network device.

[0632] Of course, there are other options, which will not be listed here.

[0633] The first request message can be in the format of a registration request (enhancing an existing registration request to include inventory-related information), or in the format of an inventory request (enhancing an existing inventory request to include network registration-related information), or in other formats, which are not limited here. Furthermore, after receiving the first request message, the network device can continue to send the first request message to the next network element. For example, if the first request message is a first registration request, it can be sent to the next network element. Alternatively, after receiving the first request message, the network device can also convert the first registration request into other message types before sending it to the next network element. For example, if the first request message is a first inventory request, the network device can generate a first registration request (i.e., the second request message mentioned above) based on the first inventory request and then send the first registration request (i.e., the second request message mentioned above) to the next network element.

[0634] Furthermore, the received terminal registration feedback information and inventory results are generally relayed or processed by other devices before being sent. Regarding the terminal registration feedback information and inventory results, these can be sent in a single message, for example, both encapsulated in a single Registration Response, or both encapsulated in a single Inventory Response, or encapsulated in other types of messages. Alternatively, the registration feedback information and inventory results can be sent in separate messages; for example, the registration feedback information can be encapsulated in a single Registration Response, while the inventory results can be encapsulated in a single Inventory Response. Similarly, the terminal registration feedback information and inventory results sent by the network device can be encapsulated in a single message or in two messages of different types; the principle is explained in the preceding descriptions. In addition, the registration feedback information and inventory results of the terminals received by the network device and the registration feedback information and inventory results of the terminals sent by the network device can be encapsulated in different types of messages. For example, the registration feedback information and inventory results of the terminals received by the network device can be encapsulated in a Registration Response, while the registration feedback information and inventory results of the terminals received by the network device can be encapsulated in an Inventory Response. The specific settings can be configured according to the needs of the scenario.

[0635] In addition, information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0636] It is understandable that the first request message includes both information related to network registration and information related to inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0637] In one possible implementation:

[0638] The processing module 1601 registers the terminal to the core network based on the registration feedback information.

[0639] It is understandable that the registration feedback information here includes some parameters required for registration. For example, the RAN, AMF, or other core network elements register the terminal with the core network based on the registration feedback information.

[0640] In another possible implementation, the first request message is a first registration request, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried.

[0641] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminals to be registered, such as the terminal's device ID and the region information of the terminal's location. The second information indicates that these terminals that need to be registered also need to be inventoried. The second information can be an inventory indicator indi_inventory. In one implementation, all terminals to be registered correspond to one inventory indicator indi_inventory to indicate that these terminals need to be inventoried. In another implementation, each terminal among the terminals to be registered that also needs to be inventoried corresponds to one inventory indicator indi_inventory to indicate that the corresponding terminal needs to be inventoried.

[0642] In another possible implementation, the first registration request further includes third information, which is used to instruct the access network device and / or core network device that provides services to the terminal to be registered. In this implementation, the network device may also need to know the access network device, AMF, and other devices corresponding to the terminal to be registered and inventoried, and therefore can use the third information to instruct the relevant network elements to provide this information.

[0643] In yet another possible implementation:

[0644] Regarding receiving the registration feedback information and inventory results sent by the terminal, the transceiver module 1602 is specifically used for:

[0645] Receive a first registration response sent by the terminal, the first registration response including the terminal's registration feedback information and inventory results;

[0646] Regarding the sending of the terminal's registration feedback information and inventory results to the AF, the transceiver module 1602 is specifically used for:

[0647] Send the first registration response or a registration response generated based on the first registration response to the AF.

[0648] This implementation primarily demonstrates that if the first request message sent by the network device is a registration request (i.e., a registration request message), then the final response received can be a corresponding registration response (i.e., a first registration response). The first registration response can also be sent to other network elements (such as the AF). It's important to note that generally, if a network device receives a request from a network element, it needs to send a corresponding response to that element; conversely, if a network device sends a request to a network element, it will receive a response from that element regarding that request. For example, if the network device is NEF, NEF receives the first registration request from the AF, sends the first registration request to AMF, receives the first registration response from the AMF, and then sends the first registration response to the AF. The principle is the same when the network device is another network element.

[0649] In another possible implementation, the first request message is a first inventory request, the second information includes information about the terminals that need to be inventoried, and the first information includes a list of terminals that need to be inventoried and registered on the network; the second request message is a first registration request.

[0650] In this implementation, the first request message is specifically in the form of an inventory request. Correspondingly, the second information includes information about the terminals to be inventoried, such as the terminal's device ID and the region information of the terminal's location. The first information includes a list of terminals that need to be inventoried and registered; however, it doesn't necessarily have to be a list, as long as it indicates which terminals among those to be inventoried still need to be registered (i.e., not registered). After receiving the first inventory request, the network device generates a first registration request and sends it to the next network node.

[0651] In another possible implementation, the information of the terminals to be inventoried includes one or more of the following: a list of terminal identifiers, terminal filtering criteria, and group identifiers.

[0652] In yet another possible implementation:

[0653] Regarding receiving the registration feedback information and inventory results sent by the terminal, the transceiver module 1602 is specifically used for:

[0654] Receive a first registration response sent by the terminal, the first registration response including the terminal's registration feedback information and inventory results;

[0655] Regarding the sending of the terminal's registration feedback information and inventory results to the AF, the transceiver module 1602 is specifically used for:

[0656] Send a first inventory response to the AF or an inventory response generated based on the first inventory response, wherein the first inventory response includes the terminal's registration feedback information and inventory results.

[0657] This implementation method mainly reflects that if the network receives the first inventory request and sends out the first registration request, then the feedback received in response to the first registration request can be the first registration response, and the feedback sent out by the network device in response to the first inventory request can be the first inventory response.

[0658] In another possible implementation, the first request message is a second registration request, the first information includes information about the terminal to be registered, and the second information also includes a waiting indication. The waiting indication is used to indicate that the second registration request and the services associated with the second registration request will be processed together after waiting for a first time. The transceiver module 1602 is also used to receive a second inventory request sent by the AF, wherein the second inventory request is used to request an inventory of the terminal, and the second inventory request belongs to the services associated with the second registration request.

[0659] In this implementation, the first request message is specifically in the form of a registration request. Accordingly, the first information includes information about the terminal to be registered, such as the terminal's device ID and the region information of the area where the terminal is located. The second information includes a waiting instruction, which is used to instruct the registration request and subsequent associated services to be processed together. For example, when the inventory request is set as an associated service of the registration request, after the network element receives the second registration request, it can process the second registration request and the subsequently received second inventory request together, that is, the registration and inventory will be started together.

[0660] Another possible implementation includes:

[0661] The transceiver module 1602 sends the second inventory request to the terminal.

[0662] In this implementation, the transceiver module 1602 may receive a second registration request and a second inventory request, but instead of merging them, it may send them to the next network node for merging.

[0663] In another possible implementation, regarding receiving the registration results and inventory results sent by the terminal, the transceiver module 1602 is specifically used for:

[0664] Receive a second registration response sent by the terminal, wherein the second registration response includes registration feedback information from the terminal;

[0665] Receive a second inventory response sent by the terminal, wherein the second inventory response includes the inventory results of the terminal.

[0666] In this implementation, the registration results and inventory results received by the network device are encapsulated in different types of messages. For example, the registration feedback information is encapsulated in the second registration response, while the inventory results are encapsulated in the second inventory response.

[0667] Another possible implementation includes:

[0668] After the waiting time indicated by the waiting indication is reached, the transceiver module 1602 generates a first registration request based on the second inventory request and the second registration request, wherein the first registration request is used to request network registration and inventory of the terminal.

[0669] In this implementation, the network device merges the second registration request and the subsequently received second inventory request for processing, that is, the registration and inventory are initiated together.

[0670] In another possible implementation, regarding receiving the registration feedback information and inventory results sent by the terminal, the transceiver module 1602 is specifically used for:

[0671] The system receives a first registration response from the terminal, wherein the registration response includes the terminal's registration feedback information and inventory results.

[0672] In this implementation, since the network device processes the second registration request and the subsequent received second inventory request together, the feedback information received is a first registration response that includes registration feedback information and inventory results.

[0673] Reuse Figure 16 In other embodiments of this application, exemplarily, Figure 16 The communication device shown can be a network device or a component within a network device. The processing module 1601 and the transceiver module 1602 in the communication device can respectively perform the following operations:

[0674] The transceiver module 1602 receives a second inventory request sent by the AF, wherein the second inventory request is used to request an inventory of the terminal;

[0675] The transceiver module 1602 sends a first registration request to the terminal, wherein the first registration request is used to request network registration and inventory of the terminal;

[0676] The transceiver module 1602 receives a first registration response sent by the terminal, wherein the first registration response includes the terminal's registration feedback information and inventory results;

[0677] The transceiver module 1602 sends a second inventory response to the terminal, wherein the second inventory response includes the inventory results of the terminal.

[0678] In this implementation, the network device can be an access network device (such as RAN), a core network device (such as AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as NEF. Different types of network devices may handle the second inventory request differently. For example, a second inventory request sent via RAN may carry information added by RAN, while a second inventory request sent via NEF may carry information added by NEF. Furthermore, different types of network devices may receive different registration feedback information. For example, the registration feedback information received by RAN includes parameters used for registration, while the registration feedback information received by AMF may include registration status (e.g., registered).

[0679] If a network device receives a second inventory request from a network element, it needs to send a second inventory response to that network element. If a network device sends a first registration request to a network element, it will receive a first registration response from that network element.

[0680] In addition, information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0681] It is understandable that the first registration request includes both information related to network registration and information related to inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0682] Reuse Figure 16 In other embodiments of this application, exemplarily, Figure 16 The communication device shown can be a terminal or a device within a terminal. The processing module 1601 and the transceiver module 1602 in the communication device can respectively perform the following operations:

[0683] The transceiver module 1602 receives a first registration request sent by the network device, wherein the first registration request is used to request the terminal to perform network registration and inventory.

[0684] The transceiver module 1602 sends registration feedback information and inventory results to the network device.

[0685] In this implementation, the information related to terminal network registration may include one or more of the following: information that triggers network registration, all or part of the information used in the registration process, information that provides the timing or conditions for network registration, etc.; the information related to terminal inventory may include one or more of the following: information that triggers inventory, all or part of the information used in the inventory process, information that provides the timing or conditions for inventory, etc.

[0686] It is understandable that the first registration request requests both network registration and inventory. Therefore, the first registration request can initiate both the network registration process and the inventory process. Subsequent steps can then merge the registration and inventory processes, which can save on signaling and interaction processes and improve inventory efficiency.

[0687] In one possible implementation, regarding sending registration feedback information and inventory results to the network device, the transceiver module 1602 is specifically used to: send a first registration response to the network device, wherein the first registration response includes registration feedback information and inventory results.

[0688] In this implementation, the registration feedback information and inventory results are contained in a registration response message, i.e., the first registration response.

[0689] Reuse Figure 16 In other embodiments of this application, exemplarily, Figure 16 The communication device shown can be a terminal or a device within a terminal. The processing module 1601 and the transceiver module 1602 in the communication device can respectively perform the following operations:

[0690] The transceiver module 1602 receives a second inventory request sent by the network device, wherein the second inventory request is used to request an inventory of the terminal;

[0691] If transceiver module 1602 is not registered with the core network, it sends registration feedback information and inventory results to the network devices, or...

[0692] If the terminal is not registered with the core network, a report message is sent to the network device. The report message is used to request the issuance of a second registration request, which is used to register the terminal with the network.

[0693] In this implementation, upon receiving the second inventory request, the terminal determines whether it has already registered with the core network. If not, it directly reports the information to request other network elements to initiate a network registration process. After registration, it responds to the second inventory request, such as a second inventory response. Alternatively, it directly reports the information needed for subsequent registration, enabling other network elements (such as the core network) to promptly register the terminal and respond to the second inventory request, such as a second inventory response, after registration. In other words, if a terminal is not registered during the inventory process, the terminal proactively triggers the network registration process to ensure the smooth completion of the inventory.

[0694] In one possible implementation, the transceiver module 1602 is also used for:

[0695] If already registered with the core network, send a second inventory response to the network devices. The second inventory response includes the inventory results.

[0696] In this implementation, if the terminal has already registered after receiving the second inventory request, it will directly report the inventory results.

[0697] The specific descriptions of the transceiver module and processing module shown in the above embodiments are merely examples. For the specific functions or execution steps of the transceiver module and processing module, please refer to the above method embodiments, which will not be described in detail here.

[0698] The communication device according to the embodiments of this application has been described above. The following describes the possible product forms of the communication device. Any device possessing the above-described... Figure 16 Any form of product that incorporates the functionality of the aforementioned communication device falls within the protection scope of the embodiments of this application.

[0699] The following description is merely an example and does not limit the product form of the communication device in the embodiments of this application to this.

[0700] In one possible implementation, Figure 16 In the communication device shown, the processing module 1601 can be one or more processors, and the transceiver module 1602 can be a transceiver, or the transceiver module 1602 can also be a transmitting module and a receiving module. The transmitting module can be a transmitter, and the receiving module can be a receiver. The transmitting module and the receiving module are integrated into one device, such as a transceiver. In this embodiment, the processor and the transceiver can be coupled, etc., and the connection method between the processor and the transceiver is not limited in this embodiment. During the execution of the above method, the process of sending information in the above method can be the process of the processor outputting the above information. When outputting the above information, the processor outputs the above information to the transceiver so that the transceiver can transmit it. After the above information is output by the processor, it may need to undergo other processing before reaching the transceiver. Similarly, the process of receiving information in the above method can be the process of the processor receiving the input above information. When the processor receives the input information, the transceiver receives the above information and inputs it to the processor. In addition, after the transceiver receives the above information, the above information may need to undergo other processing before being input to the processor.

[0701] like Figure 17 As shown, the communication device 170 includes one or more processors 1720 and transceivers 1710. Exemplarily, the transceiver 1710 is used to perform actions such as... Figure 16 The transceiver module 1602 shown implements the functions or steps, and the processor 1720 is used to execute such functions or steps. Figure 16The processing module 1601 shown implements the functions or steps described. The transceiver 1710 may have its own processing logic or may execute related operations under the control of the processor 1720. Optionally, the communication device 170 may also include a memory 1730, which can store computer programs. The processor 1720 performs operations by calling the computer programs stored in the memory 1730, such as generating a first registration request, generating a first inventory response, etc. For detailed descriptions of the processor 1720 and transceiver 1710, please refer to [link to relevant documentation]. Figure 16 Alternatively, the method embodiments shown above will not be described in detail here. For explanations of relevant steps and information in the above embodiments, please refer to the descriptions in the above method embodiments; they will not be detailed here. Figure 17 In various implementations of the communication apparatus shown, the transceiver may include a receiver for performing a receiving function (or operation) and a transmitter for performing a transmitting function (or operation). The transceiver is also used to communicate with other devices / appliances via a transmission medium.

[0702] This application also provides a chip system, which includes at least one processor for implementing the functions involved in the methods executed by the AF, network device, or terminal in any of the above embodiments.

[0703] In one possible design, the chip system further includes a memory for storing program instructions and data, which may be located within or outside the processor.

[0704] The chip system can consist of chips or include chips and other discrete components.

[0705] Optionally, the chip system may contain one or more processors. These processors can be implemented in hardware or software. When implemented in hardware, the processor can be a logic circuit, an integrated circuit, etc. When implemented in software, the processor can be a general-purpose processor, implemented by reading software code stored in memory.

[0706] Optionally, the chip system may contain one or more memories. The memory may be integrated with the processor or disposed separately from it; this application embodiment does not limit this. For example, the memory may be a non-transient processor, such as a read-only memory (ROM), which may be integrated with the processor on the same chip or disposed separately on different chips. This application embodiment does not specifically limit the type of memory or the arrangement of the memory and processor.

[0707] For example, the chip system may be a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), a system on chip (SoC), a central processor unit (CPU), a network processor (NP), a digital signal processor (DSP), a micro controller unit (MCU), a programmable logic device (PLD), or other integrated chips.

[0708] This application also provides a computer program product, the computer program product comprising: a computer program (also referred to as code or instructions), which, when the computer program is run, causes a computer to perform the method executed by the AF or network device or terminal in any of the above embodiments.

[0709] This application also provides a computer-readable storage medium storing a computer program (also referred to as code or instructions). When the computer program is run, it causes the computer to perform the method executed by the AF, network device, or terminal in any of the above embodiments.

[0710] The various embodiments of this application can be combined arbitrarily to achieve different technical effects.

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

[0712] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

[0713] In summary, the above description is merely an embodiment of the technical solution of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made based on the disclosure of this application should be included within the scope of protection of this application.

Claims

1. A communication method, characterized in that, Applied to network devices, the method includes: Receive a first request message sent by the application function network element AF, wherein the first request message includes first information and second information, the first information is information related to the terminal registering on the network, and the second information is information related to the terminal taking inventory. Send the first request message or the second request message to the terminal, wherein the second request message is used to request network registration and inventory of the terminal; Receive registration feedback information and inventory results sent by the terminal; Send the terminal's registration feedback information and inventory results to the AF.

2. The method according to claim 1, characterized in that, The first request message is a first registration request, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried.

3. The method according to claim 2, characterized in that, The first registration request also includes third information, which is used to indicate information about the access network equipment and / or core network equipment that provides services to the terminal to be registered.

4. The method according to claim 2 or 3, characterized in that: The receipt of registration feedback information and inventory results sent by the terminal includes: Receive a first registration response sent by the terminal, the first registration response including the terminal's registration feedback information and inventory results; Sending the terminal's registration feedback information and inventory results to the AF includes: Send the first registration response or a registration response generated based on the first registration response to the AF.

5. The method according to claim 1, characterized in that, The first request message is a first inventory request, and the second information includes information about the terminals that need to be inventoried. The first information includes a list of terminals that need to be inventoried and registered on the network. The second request message is a first registration request.

6. The method according to claim 5, characterized in that, The information of the terminals that need to be inventoried includes one or more of the following: a list of terminal identifiers, terminal filtering criteria, and group identifiers.

7. The method according to claim 5, characterized in that: The receipt of registration feedback information and inventory results sent by the terminal includes: Receive a first registration response sent by the terminal, the first registration response including the terminal's registration feedback information and inventory results; Sending the terminal's registration feedback information and inventory results to the AF includes: Send a first inventory response to the AF or an inventory response generated based on the first inventory response, wherein the first inventory response includes the terminal's registration feedback information and inventory results.

8. The method according to claim 1, characterized in that, The first request message is a second registration request. The first information includes information about the terminal to be registered, and the second information includes a waiting indication. The waiting indication is used to indicate that the second registration request and the services associated with the second registration request will be processed together after a first period of time. The method further includes: The system receives a second inventory request sent by the AF, wherein the second inventory request is used to request an inventory of the terminal and the second inventory request belongs to the service associated with the second registration request.

9. The method according to claim 8, characterized in that, Also includes: Send the second inventory request to the terminal.

10. The method according to claim 9, characterized in that, The receipt of the registration result and inventory result sent by the terminal includes: Receive a second registration response sent by the terminal, wherein the second registration response includes registration feedback information from the terminal; The terminal sends a second inventory response, wherein the second inventory response includes the inventory results of the terminal.

11. The method according to claim 8, characterized in that, Also includes: After the waiting time indicated by the waiting instruction is reached, a first registration request is generated based on the second inventory request and the second registration request, wherein the first registration request is used to request network registration and inventory of the terminal.

12. The method according to claim 11, characterized in that, The receipt of registration feedback information and inventory results sent by the terminal includes: The system receives a first registration response from the terminal, wherein the registration response includes the terminal's registration feedback information and inventory results.

13. A communication method, characterized in that, Applied to network devices, the method includes: Receive a second inventory request sent by the application function network element AF, wherein the second inventory request is used to request an inventory of the terminal; Send a first registration request to the terminal, wherein the first registration request is used to request network registration and inventory of the terminal; Receive a first registration response sent by the terminal, wherein the first registration response includes the terminal's registration feedback information and inventory results; Send a second inventory response to the AF, wherein the second inventory response includes the inventory results of the terminal.

14. A communication method, characterized in that, The method, applied to the application function network element (AF), includes: Send a first request message to the network device, wherein the first request message includes first information and second information, the first information being information related to terminal network registration, and the second information being information related to terminal inventory; Receive the registration feedback information and inventory results of the terminal sent by the network device.

15. The method according to claim 14, characterized in that, The first request message is a first registration request, the first information includes information about the terminal to be registered, and the second information is used to instruct the terminal to be registered to be inventoried.

16. The method according to claim 15, characterized in that, The first registration request also includes third information, which is used to indicate information about the access network equipment and / or core network equipment that provides services to the terminal to be registered.

17. The method according to claim 15 or 16, characterized in that, The receipt of the terminal's registration feedback information and inventory results sent by the network device includes: The terminal receives a first registration response sent by the network device, the first registration response including the terminal's registration feedback information and inventory results.

18. The method according to claim 14, characterized in that, The first request message is a first inventory request, the second information includes information about the terminals that need to be inventoried, and the first information includes a list of terminals that need to be inventoried and registered.

19. The method according to claim 18, characterized in that, The receipt of the terminal's registration feedback information and inventory results sent by the network device includes: The system receives a first inventory response from the network device, the first inventory response including the terminal's registration feedback information and inventory results.

20. The method according to claim 14, characterized in that, The first request message is a second registration request. The first information includes information about the terminal to be registered, and the second information includes a waiting indication. The waiting indication is used to indicate that the second registration request and the services associated with the second registration request will be processed together after a first period of time. The method further includes: Send a second inventory request to the network device, wherein the first inventory request is used to request an inventory of the terminal, and the second inventory request belongs to the service associated with the second registration request.

21. The method according to claim 20, characterized in that, The receipt of the terminal's registration feedback information and inventory results sent by the network device includes: Receive a second registration response sent by the network device, wherein the second registration response includes registration feedback information from the terminal; The system receives a second inventory response sent by the network device, wherein the second inventory response includes the inventory results of the terminal.

22. The method according to any one of claims 14-21, characterized in that, The inventory results of the terminal include the electronic product code of the terminal and the time information of the time the inventory was performed.

23. The method according to any one of claims 14-22, characterized in that, The registration feedback information includes parameters required for registration, or one or more of the registration statuses.

24. A communication method, characterized in that, Applied to a terminal, the method includes: Receive a first registration request sent by a network device, wherein the first registration request is used to request the terminal to perform network registration and inventory; Send registration feedback information and inventory results to the network device.

25. The method according to claim 24, characterized in that, Sending registration feedback information and inventory results to the network device includes: Send a first registration response to the network device, wherein the first registration response includes registration feedback information and inventory results.

26. A communication method, characterized in that, Applied to a terminal, the method includes: Receive a second inventory request sent by a network device, wherein the second inventory request is used to request an inventory of the terminal; If not registered with the core network, send registration feedback information and inventory results to the network device, or... If the terminal is not registered with the core network, a report message is sent to the network device. The report message is used to request the issuance of a second registration request, which is used to register the terminal with the network.

27. The method according to claim 26, characterized in that, Also includes: If already registered with the core network, a second inventory response is sent to the network device, the second inventory response including the inventory results.

28. A communication device, characterized in that, in: The communication device includes a module for performing the method as described in any one of claims 1-12; or, The communication device includes a processor for performing the method as described in any one of claims 1-12.

29. A communication device, characterized in that, in: The communication device includes a module for performing the method as described in any one of claims 13-23; or, The communication device includes a processor for performing the method as described in any one of claims 13-23.

30. A communication device, characterized in that, in: The communication device includes a module for performing the method as described in any one of claims 24-27; or, The communication device includes a processor for performing the method as described in any one of claims 24-27.

31. A communication device, characterized in that, It includes logic circuitry and an interface, the logic circuitry and the interface being coupled; the interface is used for inputting and / or outputting information, and the logic circuitry is used for performing the method as described in any one of claims 1-27.

32. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store a computer program, which, when executed, performs the method as described in any one of claims 1-27.

33. A communication system, characterized in that, It includes a first communication device, a second communication device, and a third communication device, wherein: The first communication device is used to perform the method according to any one of claims 1-12; The second communication device is used to perform the method according to any one of claims 13-23; The fourth communication device is used to perform the method according to any one of claims 24-27.

34. A computer program product containing instructions, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-27.

Images