Communication method and related apparatus

Abstract

Provided in the embodiments of the present application are a communication method and a related apparatus. The method comprises: 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 a terminal performing network registration, and the second information being information related to the terminal taking inventory; sending to the terminal the first request message or a second request message, the second request message being used for requesting the terminal to perform network registration and take inventory; receiving registration feedback information and an inventory result which are sent by the terminal; and sending to the AF the registration feedback information and the inventory result of the terminal. Using the embodiments of the present application can reduce the number of signalings for taking inventory, thus reducing communication overheads, and improving inventory efficiency.

Description

Communication method and related apparatus

[0001] This application claims priority to the Chinese patent application No. 202411091083.X, filed on August 08, 2024, and entitled "A communication method and related apparatus", the content of which is incorporated herein by reference in its entirety. TECHNICAL FIELD

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

[0003] Ambient IoT (AIoT) devices are a new type of IoT devices that collect energy from radio waves, light, motion, heat, or any other available environmental energy and are driven by it. Since AIoT devices do not require additional power supply and do not need to replace batteries, the maintenance cost is extremely low, and can be widely applied in intelligent warehousing, smart logistics, smart agriculture, industrial wireless sensor network, intelligent transportation, intelligent medical treatment and other fields, and is expected to become a basic enabling technology for Internet of Everything.

[0004] 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 AIoT devices can be identified, authenticated and authorized by the network. Considering that most AIoT devices reflect or absorb electromagnetic waves transmitted by the reader by backscattering to transmit information, the current research mainly considers two types of traffic, Device-terminated (DT) and Device-originated-device-terminated triggered (DO-DTT). Since AIoT devices cannot actively initiate the registration process, registration can only be triggered by the network side.

[0005] Since AIoT devices are often used in batches, AIoT device registration is also usually completed in batches or periodically, such as during an unmanned operation period in the early morning, a base station broadcasts a device registration message to trigger device registration. However, the time when a third-party application function (AF) issues a service request (such as an inventory request, used to inventory the status of AIoT devices in a certain area) is relatively random. This can 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. Since the unregistered AIoT devices have not been authenticated in the core network, the service request is not reachable to them, and the response data of the unregistered AIoT devices will not be parsed and processed by the 5G core network (5GC). In this scenario, the registration of the unregistered AIoT devices needs to be initiated first, and then the inventory request is issued after the registration is completed. This process has a large number of signaling interactions and a large processing overhead of the 5GC, which slows down the response speed of the AIoT device and reduces the inventory efficiency. SUMMARY

[0006] The communication method and related device provided by the embodiments of the present application can reduce the number of signaling in the inventory process, improve the response speed, and improve the inventory efficiency.

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

[0008] receiving a first request message sent by an application function network element (AF), wherein the first request message comprises first information and second information, the first information is information related to network registration of a terminal, and the second information is information related to inventory of the terminal;

[0009] sending the 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;

[0010] receiving registration feedback information and inventory results sent by the terminal;

[0011] sending the registration feedback information and the inventory results of the terminal to the AF.

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

[0013] In the embodiments of the present application, the network device receiving the message sent by the AF can be that the AF directly sends to the network device, which is directly received by the network device, or that the AF indirectly sends to the network device. For example, there is one or more communication nodes between the AF and the network device, and the message sent by the AF is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the network device receives the message. Similarly, the network device sending a message to the AF can be that the network device directly sends to the AF, which is directly received by the AF, or that the network device indirectly sends to the AF. For example, there is one or more communication nodes between the AF and the network device, and the message sent by the network device is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the AF receives the message. It can be understood that the same is true between the network device and the terminal. The network device sending a message to the terminal can be that the network device directly sends to the terminal, which is directly received by the terminal, or that the network device indirectly sends to the terminal. For example, there is one or more communication nodes between the terminal and the network device, and the message sent by the network device is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the terminal receives the message. Similarly, the network device receiving the message sent by the terminal can be that the terminal directly sends to the network device, which is directly received by the network device, or that the terminal indirectly sends to the network device. For example, there is one or more communication nodes between the terminal and the network device, and the message sent by the terminal is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the network device receives the message.

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

[0015] In an optional solution, the network device is the NEF, and the above method specifically includes: the NEF receiving the first request message sent by the AF, the NEF sending the first request message or the second request message to the core network device, and the NEF receiving the registration feedback information and the inventory result of the terminal sent by the core network device; and the NEF sending the registration feedback information and the inventory result of the terminal to the AF.

[0016] In another optional solution, the network device is the core network device, and the above method specifically includes: the core network device receiving the first request message sent by the NEF, the core network device sending the first request message or the second request message to the access network device, and the core network device receiving the registration feedback information and the inventory result of the terminal sent by the access network device; and the core network device sending the registration feedback information and the inventory result of the terminal to the NEF.

[0017] In another optional solution, the network device is the access network device, and the above method specifically includes: the access network device receiving the first request message sent by the core network device, the access network device sending the first request message or the second request message to the terminal, and the access network device receiving the registration feedback information and the inventory result of the terminal sent by the terminal; and the access network device sending the registration feedback information and the inventory result of the terminal to the core network device.

[0018] Of course, there are other optional solutions, which are not listed here.

[0019] The first request message can be a registration request (Registration Request) format message, i.e., the existing registration request is enhanced to simultaneously carry the information related to the inventory, the first request message can also be an inventory request (Inventory Request) format message, i.e., the existing inventory request is enhanced to simultaneously carry the information related to the network registration, the first request message can also be a message of other formats, which is not limited here. Further, 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 the first registration request, the first registration request can be continued to be sent to the next network element; after receiving the first request message, the network device can also convert the first registration request into a message of other types and then send it to the next network element, for example, if the first request message is the first inventory request, the network device can generate a first registration request (i.e., the second request message described above) according to the first inventory request, and then send the first registration request (i.e., the second request message described above) to the next network element.

[0020] In addition, the received registration feedback information and inventory result of the terminal are generally sent after being transferred or processed by other devices. For the registration feedback information and inventory result of the terminal, the registration feedback information and inventory result here can be sent in one message, for example, both are encapsulated in a registration response (Registration Response) and sent, or both are encapsulated in an inventory response (Inventory Response) and sent, or are encapsulated in a message of other types and sent. In addition, the registration feedback information and inventory result can also be sent in different messages respectively, for example, the registration feedback information is encapsulated in a registration response (Registration Response) and sent, while the inventory result is encapsulated in an inventory response (Inventory Response) and sent. Similarly, the registration feedback information and inventory result of the terminal sent by the network device can be encapsulated in one message or two different types of messages, and the principle can be referred to the related description above. In addition, the registration feedback information and inventory result of the terminal received by the network device and the registration feedback information and inventory result of the terminal sent by the network device can be encapsulated in different types of messages, for example, the registration feedback information and inventory result of the terminal received by the network device are encapsulated in a registration response (Registration Response), while the registration feedback information and inventory result of the terminal received by the network device sent by the network device are encapsulated in an inventory response (Inventory Response), which can be set according to the needs of the scene.

[0021] In addition, the terminal network registration related information can include one or more of the following: information triggering network registration, all or part of information to be used in the registration process, information providing timing or conditions for network registration, and the like; the terminal inventory related information can include one or more of the following: information triggering inventory, all or part of information to be used in the inventory process, information providing timing or conditions for inventory, and the like.

[0022] It can be understood that the first request message includes both network registration related information and inventory related information, so that the network registration process and the inventory process can be initiated through the first registration request, and the subsequent link can combine and execute the registration and inventory processes, thereby saving signaling and interaction processes and improving inventory efficiency.

[0023] In combination with the first aspect, in a possible implementation, the method further includes:

[0024] Registering the terminal to the core network according to the registration feedback information.

[0025] It can be understood that the registration feedback information includes some parameters required for registration, for example, the RAN or the AMF or other core network elements register the terminal to the core network according to the registration feedback information.

[0026] In combination with the first aspect, or any of the above possible implementation modes of the first aspect, in another possible implementation, the first request message is a first registration request, the first information includes information of a terminal to be registered, and the second information is used to indicate that the terminal to be registered is inventoried.

[0027] In this implementation, the first request message specifically exists in the form of a registration request (Registration Request), and correspondingly, the first information includes information of a terminal to be registered, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information is an indication of the need for inventory of these terminals to be registered. In one implementation, one inventory indicator indi_inventory corresponds to all the terminals to be registered, to indicate that these terminals need to be inventoried. In another implementation, one inventory indicator indi_inventory corresponds to each terminal to be registered that needs to be inventoried, to indicate that the corresponding terminal needs to be inventoried.

[0028] With reference to the first aspect or any possible implementation of the first aspect, in a possible implementation, the first registration request further comprises third information, the third information being used to indicate information of the access network device and / or the core network device that provides service for the terminal to be registered. In this implementation, the network device can also need to know the information of the access network device, AMF, or other device corresponding to the terminal to be registered and inventoried, and thus the relevant network element can be instructed to feed back the information through the third information. It should be noted that the core network device mentioned in the embodiments of the present application can also be referred to as a core network network element, and can be a physical device or a functional entity.

[0029] With reference to the first aspect or any possible implementation of the first aspect, in a possible implementation:

[0030] receiving the registration feedback information and the inventory result sent by the terminal, comprising:

[0031] receiving the first registration response sent by the terminal, the first registration response comprising the registration feedback information and the inventory result of the terminal;

[0032] sending the registration feedback information and the inventory result of the terminal to the AF, comprising:

[0033] sending the first registration response or a registration response generated according to the first registration response to the AF.

[0034] This implementation mainly embodies that if the first request message sent by the network device in the foregoing is the first registration request, that is, a message in the format of a registration request (Registration Request), then the feedback finally received can be a message in the format of a corresponding registration response (Registration Response), that is, the first registration response. The first registration response can also be further fed back to other network elements (for example, the AF). It should be noted that generally, if a network device receives a request from a certain network element, the network device needs to subsequently send a corresponding response to the network element, and if the network device sends a request to a certain network element, the network device will subsequently receive a response about the request from the network element. For example, assuming that the network device is an NEF, the NEF receives the first registration request from the AF, the NEF sends the first registration request to the AMF, the NEF receives the first registration response from the AMF, and the NEF sends the first registration response to the AF. The principle is the same when the network device is another network element.

[0035] With reference to the first aspect or any possible implementation of the first aspect, in a possible implementation, the first request message is a first inventory request, the second information comprises information of the terminal to be inventoried, the first information comprises a list of the terminal to be inventoried and to be registered in the network, and the second request message is a first registration request.

[0036] In this implementation manner, the first request message specifically exists in the form of an inventory request, and correspondingly, the second information includes information of the terminal to be inventoried, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the first information includes a list of the terminal to be inventoried and registered, and of course, the list can not exist in the form of a list, as long as the terminal to be inventoried and registered (that is, not registered) can be indicated. After receiving the first inventory request, the network device generates the first registration request and sends the first registration request to the next network node.

[0037] With reference to the first aspect or any possible implementation manner of the first aspect, in a further possible implementation manner, the information of the terminal to be inventoried includes one or more of a terminal identifier list, a terminal screening condition, and a group identifier.

[0038] With reference to the first aspect or any possible implementation manner of the first aspect, in a further possible implementation manner,

[0039] The registration feedback information and the inventory result of the terminal are received, and the registration feedback information and the inventory result include:

[0040] The first registration response sent by the terminal is received, and the first registration response includes the registration feedback information and the inventory result of the terminal.

[0041] The registration feedback information and the inventory result of the terminal are sent to the AF, and the registration feedback information and the inventory result include:

[0042] The first inventory response or an inventory response generated according to the first inventory response is sent to the AF, and the first inventory response includes the registration feedback information and the inventory result of the terminal.

[0043] This implementation manner mainly embodies that if the first inventory request is received by the preceding network and the first registration request is sent out, then the feedback received at last for the first registration request can be the first registration response, and the feedback sent out by the network device for the first inventory request can be the first inventory response.

[0044] With reference to the first aspect or any possible implementation manner of the first aspect, in a further possible implementation manner, the first request message is a second registration request, the first information includes information of a terminal to be registered, and the second information further includes a waiting indication, the waiting indication being used to indicate that the second registration request and a service associated with the second registration request are to be processed after a first time elapses, and the method further includes: receiving a second inventory request sent by the AF, where the second inventory request is used to request to inventory the terminal, and the second inventory request belongs to the service associated with the second registration request.

[0045] In the implementation, the first request message is in the form of a registration request, and the first information includes information of the terminal to be registered, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information includes a waiting indication, which is used to indicate that the registration request and the subsequent associated service are processed together, for example, when the inventory request is set as the associated service of the registration request, the network element can process the second registration request and the subsequently received second inventory request together after receiving the second registration request, that is, the registration and the inventory are started together subsequently.

[0046] With reference to the first aspect or any possible implementation of the first aspect, in another possible implementation, the method further includes:

[0047] sending the second inventory request to the terminal.

[0048] In the implementation, the network device can temporarily not process the second registration request and the second inventory request together after receiving the two, but send them to a next network node for processing together.

[0049] With reference to the first aspect or any possible implementation of the first aspect, in another possible implementation, the method further includes:

[0050] receiving a second registration response sent by the terminal, wherein the second registration response includes registration feedback information of the terminal.

[0051] receiving a second inventory response sent by the terminal, wherein the second inventory response includes the inventory result of the terminal.

[0052] In the implementation, the registration result and the inventory result 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, and the inventory result is encapsulated in the second inventory response.

[0053] With reference to the first aspect or any possible implementation of the first aspect, in another possible implementation, the method further includes:

[0054] generating a first registration request according to the second inventory request and the second registration request after the waiting time indicated by the waiting indication is reached, wherein the first registration request is used to request network registration and inventory of the terminal.

[0055] In the implementation, the network device processes the second registration request and the subsequently received second inventory request together, that is, the registration and the inventory are started together subsequently.

[0056] With reference to the first aspect or any possible implementation of the first aspect, in a possible implementation, the registration feedback information and the inventory result are received from the terminal.

[0057] The first registration response is received from the terminal, wherein the registration response comprises the registration feedback information and the inventory result of the terminal.

[0058] In this implementation, the feedback information received by the network device after the second registration request and the subsequently received second inventory request are processed is the first registration response comprising the registration feedback information and the inventory result.

[0059] In a second aspect, an embodiment of the present application provides a communication method, applied to a network device, and the method comprises the following steps.

[0060] The second inventory request is received from the AF, wherein the second inventory request is used to request to inventory the terminal;

[0061] The first registration request is sent to the terminal, wherein the first registration request is used to request to register and inventory the terminal;

[0062] The first registration response is received from the terminal, wherein the first registration response comprises the registration feedback information and the inventory result of the terminal;

[0063] The second inventory response is sent to the AF, wherein the second inventory response comprises the inventory result of the terminal.

[0064] In an embodiment of the present application, the network device receives the message sent by the AF. The message sent by the AF can be directly sent by the AF to the network device and directly received by the network device, or indirectly sent by the AF to the network device, for example, there is one or more communication nodes between the AF and the network device, the message sent by the AF is forwarded (may be processed and then forwarded) through the one or more intermediate nodes, and then the network device receives the message. Similarly, the network device sends a message to the AF. The message sent by the network device can be directly sent by the network device to the AF and directly received by the AF, or indirectly sent by the network device to the AF, for example, there is one or more communication nodes between the AF and the network device, the message sent by the network device is forwarded (may be processed and then forwarded) through the one or more intermediate nodes, and then the AF receives the message. It can be understood that the same is true between the network device and the terminal. The network device sends a message to the terminal. The message sent by the network device can be directly sent by the network device to the terminal and directly received by the terminal, or indirectly sent by the network device to the terminal, for example, there is one or more communication nodes between the terminal and the network device, the message sent by the network device is forwarded (may be processed and then forwarded) through the one or more intermediate nodes, and then the terminal receives the message. Similarly, the network device receives the message sent by the terminal. The message sent by the terminal can be directly sent by the terminal to the network device and directly received by the network device, or indirectly sent by the terminal to the network device, for example, there is one or more communication nodes between the terminal and the network device, the message sent by the terminal is forwarded (may be processed and then forwarded) through the one or more intermediate nodes, and then the network device receives the message.

[0065] Therefore, receiving the message sent by the AF can be understood as receiving the message sent from the AF in the link direction, and therefore can specifically be receiving the message sent by a node between the network device and the AF (may be the AF itself). Sending a message to the AF can be understood as sending a message to the AF in the link direction, and therefore can specifically be sending a message to a node between the network device and the AF (may be the AF itself). Receiving the message sent by the terminal can be understood as receiving the message sent from the terminal in the link direction, and therefore can specifically be receiving the message sent by a node between the network device and the terminal (may be the terminal itself). Sending a message to the terminal can be understood as sending a message to the terminal in the link direction, and therefore can specifically be sending a message to a node between the network device and the terminal (may be the terminal itself).

[0066] In this implementation, the network device here can be an access network device (such as a RAN), a core network device (such as an AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as a NEF. Different types of network devices can process different second inventory requests, for example, a second inventory request sent through a RAN can carry information added by the RAN, and a second inventory request sent through a NEF can carry information added by the NEF. In addition, different types of network devices can receive different registration feedback information, for example, the registration feedback information received by the RAN includes some parameters for registration, and the registration feedback information received by the AMF can include registration status (such as registered).

[0067] The network device receives the second inventory request sent by which network element, and then needs to feed back the second inventory response for the second inventory request to the network element. The network device sends the first registration request to which network element, and then receives the first registration response for the first registration request from the network element.

[0068] In addition, the information related to the network registration of the terminal can include one or more of the following information: information triggering network registration, all or part of the information to be used in the registration process, information providing timing or conditions for network registration, and the like; the information related to the inventory of the terminal can include one or more of the following information: information triggering inventory, all or part of the information to be used in the inventory process, information providing timing or conditions for inventory, and the like.

[0069] It can be understood that the first registration request includes both information related to network registration and information related to inventory, so that the network registration process and the inventory process can be initiated through the first registration request, and the subsequent link can combine and execute the registration and inventory processes, thereby saving signaling and interaction processes and improving inventory efficiency.

[0070] In a third aspect, an embodiment of the present application provides a communication method applied to a network device, the method comprising:

[0071] receiving a second inventory request sent by an AF, wherein the second inventory request is used to request to inventory a terminal;

[0072] sending a third registration request to the terminal, wherein the first registration request is used to request to register the terminal to a network;

[0073] receiving a third registration response sent by the terminal, wherein the first registration response includes registration feedback information of the terminal;

[0074] registering the terminal to a core network according to the third registration response;

[0075] query the inventory result of the terminal from the storage network element of the core network;

[0076] send a second inventory response to the AF, wherein the second inventory response comprises the inventory result of the terminal.

[0077] In an embodiment of the present application, the network device receives the message sent by the AF. The network device can directly receive the message sent by the AF, or the network device indirectly receives the message sent by the AF. For example, there is one or more communication nodes between the AF and the network device. The message sent by the AF is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the network device receives the message. Similarly, the network device sends a message to the AF. The AF can directly receive the message sent by the network device, or the AF indirectly receives the message sent by the network device. For example, there is one or more communication nodes between the AF and the network device. The message sent by the network device is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the AF receives the message. It can be understood that the same is true between the network device and the terminal. The network device sends a message to the terminal. The terminal can directly receive the message sent by the network device, or the terminal indirectly receives the message sent by the network device. For example, there is one or more communication nodes between the terminal and the network device. The message sent by the network device is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the terminal receives the message. Similarly, the network device receives a message sent by the terminal. The terminal can directly send the message to the network device, or the terminal indirectly sends the message to the network device. For example, there is one or more communication nodes between the terminal and the network device. The message sent by the terminal is forwarded (or processed and then forwarded) through the one or more intermediate nodes, and then the network device receives the message.

[0078] Therefore, receiving the message sent by the AF can be understood as receiving the message sent from the AF in the link direction. Therefore, it can be specifically understood as receiving the message sent by a node (which can be the AF itself) between the network device and the AF. Sending a message to the AF can be understood as sending the message to the AF in the link direction. Therefore, it can be specifically understood as sending the message to a node (which can be the AF itself) between the network device and the AF. Receiving the message sent by the terminal can be understood as receiving the message sent from the terminal in the link direction. Therefore, it can be specifically understood as receiving the message sent by a node (which can be the terminal itself) between the network device and the terminal. Sending a message to the terminal can be understood as sending the message to the terminal in the link direction. Therefore, it can be specifically understood as sending the message to a node (which can be the terminal itself) between the network device and the terminal.

[0079] In this implementation, the network device here can be an access network device (such as a RAN), a core network device (such as an AMF, AIoT, etc.), or other nodes that perform corresponding functions in the network, such as a NEF. Different types of network devices can process different second inventory requests, for example, a second inventory request sent through a RAN can carry information added by the RAN, and a second inventory request sent through a NEF can carry information added by the NEF. In addition, different types of network devices can receive different registration feedback information, for example, the registration feedback information received by the RAN includes some parameters for registration, and the registration feedback information received by the AMF can include registration status (such as registered).

[0080] The network device receives the second inventory request sent by which network element, and then needs to feed back the second inventory response for the second inventory request to the network element. The network device sends the third registration request to which network element, and then receives the third registration response for the third registration request from the network element.

[0081] In addition, the information related to the network registration of the terminal can include one or more of the following information: information triggering network registration, all or part of the information to be used in the registration process, information providing timing or conditions for network registration, and the like; the information related to the inventory of the terminal can include one or more of the following information: information triggering inventory, all or part of the information to be used in the inventory process, information providing timing or conditions for inventory, and the like.

[0082] It can be understood that the third registration request includes information related to network registration, so that the network registration process can be initiated through the third registration request, and after the registration is completed, there is no need to interact with the terminal again to obtain the inventory result, but the inventory result is directly queried, so that signaling and interaction process can be saved, and inventory efficiency can be improved.

[0083] Optionally, the above sending of the third registration request after receiving the second inventory request is for a terminal that is not registered. For a terminal that is registered, after receiving the second inventory request, the inventory result of the terminal that is registered can be searched from the core network, and then fed back to the AF (directly or indirectly sent). Optionally, the inventory result queried for the terminal that is registered and the result queried after the terminal that is not registered is newly registered can be aggregated, and then fed back to the AF through the second inventory response.

[0084] In a fourth aspect, an embodiment of the present application provides a communication method, which is applied to an application function network element AF, and the method comprises:

[0085] sending a first request message to the network device, wherein the first request message comprises first information and second information, the first information is information related to terminal network registration, and the second information is information related to terminal inventory;

[0086] receiving registration feedback information of the terminal and an inventory result sent by the network device.

[0087] In this implementation, the first request message can be a message in a registration request (Registration Request) format, i.e., the existing registration request is enhanced to simultaneously carry information related to inventory. The first request message can also be a message in an inventory request (Inventory Request) format, i.e., the existing inventory request is enhanced to simultaneously carry information related to network registration. The first request message can also be a message in other formats, which are not limited herein. In addition, the registration feedback information of the terminal and the inventory result are generally sent after being relayed or processed by other devices. For the registration feedback information of the terminal and the inventory result, the registration feedback information and the inventory result can be sent in one message, e.g., both are encapsulated in a registration response (Registration Response) and sent, or both are encapsulated in an inventory response (Inventory Response) and sent, or are encapsulated in other types of messages and sent. In addition, the registration feedback information and the inventory result can also be sent in different messages, e.g., the registration feedback information is encapsulated in a registration response (Registration Response) and sent, and the inventory result is encapsulated in an inventory response (Inventory Response) and sent.

[0088] In addition, the information related to terminal network registration can comprise one or more of the following information: information triggering network registration, all or part of information to be used in the registration process, information providing timing or conditions for network registration, and the like. The information related to terminal inventory can comprise one or more of the following information: information triggering inventory, all or part of information to be used in the inventory process, information providing timing or conditions for inventory, and the like. The inventory in the embodiments of the present application can also be referred to as inventorying.

[0089] It can be understood that the first request message comprises both information related to network registration and information related to inventory. Therefore, the network registration process and the inventory process can be initiated through the first registration request. Therefore, the subsequent links can combine and execute the registration and inventory processes, which can save signaling and interactive processes and improve inventory efficiency.

[0090] In a possible implementation manner, the first request message is a first registration request, the first information includes information of the terminal to be registered, and the second information is used to instruct to inventory the terminal to be registered.

[0091] In this implementation manner, the first request message is specifically in the form of a registration request (Registration Request), and correspondingly, the first information includes information of the terminal to be registered, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information is an instruction that the terminals to be registered also need to be inventoried. In one implementation manner, one inventory indicator indi_inventory is corresponding to all the terminals to be registered, to instruct that the terminals all need to be inventoried. In another implementation manner, one inventory indicator indi_inventory is corresponding to each terminal to be registered that also needs to be inventoried, to instruct that the corresponding terminal needs to be inventoried.

[0092] In a possible implementation manner, the first registration request further includes third information, and the third information is used to instruct to feed back information of an access network device and / or a core network device that provides service for the terminal to be registered. In this implementation manner, the AF can also need to know information of an access network device, a core network device (such as an AMF), and other devices corresponding to the terminal to be registered and inventoried, and therefore, the related network element can be instructed to feed back the information through the third information.

[0093] In a possible implementation manner, the registration feedback information and the inventory result of the terminal are received, including: receiving a first registration response sent by the receiving network device, and the first registration response includes the registration feedback information and the inventory result of the terminal. This implementation manner mainly embodies that if the first request message sent by the AF in the foregoing is the first registration request, that is, a message in the form of a registration request (Registration Request), then the feedback finally received can be a message in the form of a corresponding registration response (Registration Response), that is, a first registration response.

[0094] In a possible implementation manner, the first request message is a first inventory request, the second information includes information of the terminal to be inventoried, and the first information includes a list of the terminal to be inventoried and to be registered.

[0095] In this implementation, the first request message specifically takes the form of an inventory request, and correspondingly, the second information includes information of terminals that need to be inventoried, such as device IDs of the terminals, area information of areas where the terminals are located, and the like, and the first information includes a list of terminals that need to be inventoried and registered, or can not take the form of a list, as long as it can indicate terminals that need to be registered (i.e., not registered) among the terminals that need to be inventoried.

[0096] With reference to the fourth aspect or any possible implementation of the fourth aspect above, in another possible implementation, the receiving the registration feedback information and the inventory result of the terminal sent by the network device comprises:

[0097] The first inventory response sent by the network device is received, and the first inventory response includes the registration feedback information and the inventory result of the terminal.

[0098] This implementation mainly embodies that if the first request message sent by the preceding AF is a first inventory request, that is, a message in the form of an inventory request (Inventory Request), then the feedback finally received can be a message in the form of an inventory response (Inventory Response), that is, a first inventory response.

[0099] With reference to the fourth aspect or any possible implementation of the fourth aspect above, in another possible implementation, the first request message is a second registration request, the first information includes information of terminals to be registered, and the second information includes a waiting indication, the waiting indication being used to indicate that the second registration request and a service associated with the second registration request are to be processed after a first time, and the method further comprises: sending a second inventory request to the network device, wherein the first inventory request is used to request inventory of the terminal, and the second inventory request belongs to the service associated with the second registration request.

[0100] In this implementation, the first request message specifically takes the form of a registration request (Registration Request), and correspondingly, the first information includes information of terminals to be registered, such as device IDs of the terminals, area information of areas where the terminals are located, and the like, and the second information includes a waiting indication, which is used to indicate that the registration request and a subsequent associated service are to be processed together, for example, when the inventory request is set as the associated service of the registration request, a network element that receives the second registration request can process the second registration request and a subsequent second inventory request together, that is, subsequently start registration and inventory together.

[0101] With reference to the fourth aspect or any possible implementation of the fourth aspect above, in another possible implementation, the receiving the registration feedback information and the inventory result of the terminal sent by the network device comprises:

[0102] receiving a second registration response sent by the network device, wherein the second registration response comprises registration feedback information of the terminal;

[0103] receiving a second inventory response sent by the network device, wherein the second inventory response comprises an inventory result of the terminal.

[0104] This implementation mainly embodies that if the first request message sent by the preceding AF is a second registration request, i.e., a message in a Registration Request format, and a second inventory request, i.e., a message in an Inventory Request format, is also sent, then the last received feedback can comprise a registration response (Registration Response) format message corresponding to the second registration request, i.e., a second registration response, and an inventory response (Inventory Response) corresponding to the second inventory request, i.e., a second inventory response.

[0105] With reference to the fourth aspect, or any possible implementation manner of the fourth aspect, in a further possible implementation manner, the inventory result of the terminal comprises one or more of an electronic product code (such as an EPC) of the terminal, time information of performing the inventory, and the like.

[0106] With reference to the fourth aspect, or any possible implementation manner of the fourth aspect, in a further possible implementation manner, the registration feedback information comprises one or more of a parameter to be used for registration, a registration state, and the like.

[0107] In the fifth aspect, an embodiment of the present application provides a communication method applied to a terminal, and the method comprises the following steps.

[0108] receiving a first registration request sent by the network device, wherein the first registration request is used for requesting the terminal to perform network registration and inventory;

[0109] sending, to the network device, registration feedback information and an inventory result.

[0110] In this implementation manner, the terminal network registration related information can comprise one or more of the following information: information triggering network registration, all or part of information to be used in the registration process, information providing a time or condition for network registration, and the like; the terminal inventory related information can comprise one or more of the following information: information triggering inventory, all or part of information to be used in the inventory process, information providing a time or condition for inventory, and the like.

[0111] It can be understood that the first registration request simultaneously requests network registration and inventory, so that the network registration process and the inventory process can be initiated through the first registration request, and the subsequent link can combine and execute the registration and inventory processes, thereby saving signaling and interaction processes and improving inventory efficiency.

[0112] With reference to the fifth aspect, in a possible implementation manner, the sending of the registration feedback information and the inventory result to the network device comprises: sending a first registration response to the network device, wherein the first registration response comprises the registration feedback information and the inventory result.

[0113] In this implementation manner, the registration feedback information and the inventory result are contained in a message in a registration response (Registration Response) format, i.e., the first registration response.

[0114] The sixth aspect, the embodiments of the present application provide a communication method, the method is applied to a terminal, and the method comprises:

[0115] receiving a second inventory request sent by the network device, wherein the second inventory request is used for requesting inventory of the terminal;

[0116] if not registered to the core network, sending registration feedback information and inventory result to the network device, or

[0117] if not registered to the core network, sending a report message to the network device, wherein the report message is used for requesting the second registration request to be issued, and the second registration request is used for network registration of the terminal.

[0118] In this implementation manner, after receiving the second inventory request, the terminal judges whether it has been registered to the core network, and if not, directly feeds back report information to request other network elements to initiate a network registration process, and feeds back a response, e.g., a second inventory response, to the second inventory request after registration. Alternatively, the terminal directly feeds back information required for subsequent registration, so that other network elements, e.g., the core network, can complete registration of the terminal in time, and feed back a response, e.g., a second inventory response, to the second inventory request after registration. That is, in the inventory process, if the terminal is not registered, the terminal initiates a network registration process to facilitate smooth completion of the inventory.

[0119] With reference to the sixth aspect, in a possible implementation manner, the method further comprises:

[0120] if registered to the core network, sending a second inventory response to the network device, wherein the second inventory response comprises the inventory result.

[0121] In this implementation manner, if the terminal has been registered after receiving the second inventory request, the terminal directly feeds back the inventory result.

[0122] In a seventh aspect, an embodiment of the present application provides a communication apparatus, which can be a network device or a device or functional module in a network device, and can include:

[0123] The communication apparatus includes a module for performing the method in the first aspect or any possible implementation manner of the first aspect.

[0124] Or, the communication apparatus includes a module for performing the method in the second aspect or any possible implementation manner of the second aspect.

[0125] Or, the communication apparatus includes a module for performing the method in the third aspect or any possible implementation manner of the third aspect.

[0126] Or, the communication apparatus includes a processor configured to perform the method in the first aspect or any possible implementation manner of the first aspect.

[0127] Or, the communication apparatus includes a processor configured to perform the method in the second aspect or any possible implementation manner of the second aspect.

[0128] Or, the communication apparatus includes a processor configured to perform the method in the third aspect or any possible implementation manner of the third aspect.

[0129] In an eighth aspect, an embodiment of the present application provides a communication apparatus, which can be an AF or a device or functional module in an AF, and can include:

[0130] The communication apparatus includes a module for performing the method in the fourth aspect or any possible implementation manner of the fourth aspect.

[0131] Or, the communication apparatus includes a processor configured to perform the method in the fourth aspect or any possible implementation manner of the fourth aspect.

[0132] In a ninth aspect, an embodiment of the present application provides a communication apparatus, which can be a network device or a device or functional module in a network device, and can include:

[0133] The communication apparatus includes a module for performing the method in the fifth aspect or any possible implementation manner of the fifth aspect.

[0134] Or, the communication apparatus includes a module for performing the method in the sixth aspect or any possible implementation manner of the sixth aspect.

[0135] Alternatively, the communication apparatus comprises a processor configured to perform the method of the fifth aspect or any possible implementation of the fifth aspect.

[0136] Alternatively, the communication apparatus comprises a processor configured to perform the method of the sixth aspect or any possible implementation of the sixth aspect.

[0137] In a tenth aspect, an embodiment of the present application provides a communication apparatus, comprising a logic circuit and an interface, wherein the logic circuit and the interface are coupled; the interface is configured to input and / or output information, and wherein:

[0138] the logic circuit is configured to perform the method of the first aspect or any possible implementation of the first aspect, or

[0139] the logic circuit is configured to perform the method of the second aspect or any possible implementation of the second aspect, or

[0140] the logic circuit is configured to perform the method of the third aspect or any possible implementation of the third aspect, or

[0141] the logic circuit is configured to perform the method of the fourth aspect or any possible implementation of the fourth aspect, or

[0142] the logic circuit is configured to perform the method of the fifth aspect or any possible implementation of the fifth aspect, or

[0143] the logic circuit is configured to perform the method of the sixth aspect or any possible implementation of the sixth aspect.

[0144] In an eleventh aspect, an embodiment of the present application provides a computer readable storage medium, configured to store a computer program, wherein:

[0145] the computer program is configured to implement the method of the first aspect or any possible implementation of the first aspect, or

[0146] the computer program is configured to implement the method of the second aspect or any possible implementation of the second aspect, or

[0147] the computer program is configured to implement the method of the third aspect or any possible implementation of the third aspect, or

[0148] the computer program is configured to implement the method of the fourth aspect or any possible implementation of the fourth aspect, or

[0149] The computer program, when executed, can implement the method of the fifth aspect or any possible implementation manner of the fifth aspect, or

[0150] The computer program, when executed, can implement the method of the sixth aspect or any possible implementation manner of the sixth aspect.

[0151] In a twelfth aspect, an embodiment of the present application provides a communication system, comprising an AF, a network device and a terminal, wherein:

[0152] The network device is configured to perform the method of the first aspect or any possible implementation manner of the first aspect or the second aspect or any possible implementation manner of the second aspect or the third aspect or any possible implementation manner of the third aspect;

[0153] The AF is configured to perform the method of the fourth aspect or any possible implementation manner of the fourth aspect;

[0154] The terminal is configured to perform the method of the fifth aspect or any possible implementation manner of the fifth aspect or the sixth aspect or any possible implementation manner of the sixth aspect.

[0155] It should be understood that the description of technical features, technical solutions, advantages or similar language in the present application does not imply that all features and advantages can be realized in any single embodiment. On the contrary, it can be understood that the description of a feature or advantage means that the specific technical feature, technical solution or advantage is included in at least one embodiment. Therefore, the description of technical features, technical solutions or advantages in the specification does not necessarily refer to the same embodiment. Furthermore, the technical features, technical solutions and advantages described in the embodiments can be combined in any appropriate manner. Those skilled in the art will understand that the embodiments can be implemented without one or more specific technical features, technical solutions or advantages of a specific embodiment. In other embodiments, additional technical features and advantages can be identified in specific embodiments that do not embody all embodiments. BRIEF DESCRIPTION OF DRAWINGS

[0156] The following describes the drawings used in the embodiments of the present application.

[0157] Fig. 1 is a schematic diagram of an architecture of a communication system provided by an embodiment of the present application;

[0158] Fig. 2 is a schematic diagram of a network topology provided by an embodiment of the present application;

[0159] Fig. 3 is a schematic diagram of a network topology provided by an embodiment of the present application;

[0160] FIG. 4 is a schematic diagram of a network topology according to an embodiment of the present application;

[0161] FIG. 5 is a schematic diagram of a network topology according to an embodiment of the present application;

[0162] FIG. 6 is a schematic diagram of a process of AIoT device registration according to an embodiment of the present application;

[0163] FIG. 7 is a schematic diagram of a process of AIoT device inventory according to an embodiment of the present application;

[0164] FIG. 8 is a schematic diagram of a process of a communication method according to an embodiment of the present application;

[0165] FIG. 9 is a schematic diagram of a process of a communication method according to an embodiment of the present application;

[0166] FIG. 10 is a schematic diagram of a process of a communication method according to an embodiment of the present application;

[0167] FIG. 11A is a schematic diagram of a process of a communication method according to an embodiment of the present application;

[0168] FIG. 11B is a schematic diagram of a process of a communication method according to an embodiment of the present application;

[0169] FIG. 12 is a schematic diagram of a process of a communication method according to an embodiment of the present application;

[0170] FIG. 13 is a schematic diagram of an execution logic of a communication method according to an embodiment of the present application;

[0171] FIG. 14 is a schematic diagram of an execution logic of a communication method according to an embodiment of the present application;

[0172] FIG. 15 is a schematic diagram of an execution logic of a communication method according to an embodiment of the present application;

[0173] FIG. 16 is a schematic diagram of a structure of a communication apparatus according to an embodiment of the present application;

[0174] FIG. 17 is a schematic diagram of a structure of a communication apparatus according to an embodiment of the present application. DETAILED DESCRIPTION

[0175] The terminology used in the following description of the embodiments herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in the description of the embodiments and the appended claims, the singular forms "a," "an" and "the" are intended to include both singular and plural forms, unless the context clearly indicates otherwise. It will be further understood that the terms "and / or," as used herein, refers to and encompasses any and all possible combinations of one or more of the associated listed items.

[0176] Hereinafter, the terms "first", "second", "third", "fourth", "fifth", "sixth", "seventh" and "eighth" are used only for descriptive purposes and are not to be construed as implying or implying relative importance or implying indicating the number of technical features indicated. Therefore, the features defined with "first", "second", "third", "fourth", "fifth", "sixth", "seventh" and "eighth" can explicitly or implicitly include one or more of the features, and in the description of the embodiments of the present application, unless otherwise specified, the meaning of "a plurality of" is two or more.

[0177] Please refer to FIG. 1, which is a schematic diagram of the architecture of a communication system according to an embodiment of the present application. The communication system includes, but is not limited to, the following network elements:

[0178] User equipment (UE): The UE is a device with communication needs, which can communicate with access network equipment (such as RAN) using certain air interface technology. For example, the UE can be a handheld terminal, a notebook computer, a subscriber unit, a cellular phone, a smart phone, a wireless data card, a personal digital assistant (PDA) computer, a tablet computer, a wireless modem, a handheld device, a laptop computer, a cordless phone or a wireless local loop (WLL) station, a machine type communication (MTC) terminal or other devices that can access the network.

[0179] (R)AN: a device providing access for user equipment, including RAN devices, AN devices. RAN devices are mainly wireless network devices of 3GPP networks, and AN can be access network devices defined by non-3GPP. Radio Access Network (RAN) device: 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 device can include various forms of base stations, such as macro base stations, micro base stations (also known as small stations), relay stations, access points, etc. In systems using different wireless access technologies, the names of devices with base station functions may vary, such as RAN or gNB (5G NodeB) in the 5th generation (5G) system, eNB (eNodeB) in the LTE system, Node B (Node B) in the 3rd generation (3G) system, etc. Access Network (Access Network) device: this network element allows user equipment and 3GPP core networks to interconnect and interwork using non-3GPP technologies, such as Wireless Fidelity (Wi-Fi), Worldwide Interoperability for Microwave Access (WiMAX), Code Division Multiple Access (CDMA) network, etc. For ease of description, whether (R)AN is RAN or AN, it is uniformly referred to as access network equipment.

[0180] User Plane Function (UPF) network element: responsible for forwarding and receiving user data in the UE. User data can be received from the data network and transmitted to the user equipment through the access network device; the UPF network element can also receive user data from the user equipment through the access network device and forward it to the data network. The transmission resources and scheduling functions provided by the UPF network element for user equipment are managed and controlled by the SMF network element.

[0181] Data Network (Data Network, DN): refers to a service network that provides data transmission services for users, such as IP Multi-media Service (IMS), Internet, etc. UE accesses the DN through the Packet Data Unit (PDU) session established between the UE and the DN.

[0182] Access and mobility management function (AMF) network element: mainly responsible for mobility management in the mobile network, such as user location update, user registration network, user handover, etc.

[0183] Session management function (SMF) network element: responsible for session management in the mobile network, such as session establishment, modification, release. Specific functions such as allocating IP addresses for users, selecting UPF to provide message forwarding functions, etc.

[0184] Authentication server function (AUSF): responsible for authentication and authorization.

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

[0186] Application function (AF) network element: mainly supports interaction with the 3GPP core network to provide services, such as affecting data routing decisions, policy control functions, or providing third-party services to the network side.

[0187] Unified data management (UDM) network element: used to generate authentication credentials, user identity processing (such as storing and managing user permanent identity, etc.), access authorization control and subscription data management, etc.

[0188] The network slice selection function (NSSF): used for slice selection. Slice is a new function introduced in 5G. Many slices can be deployed in the network, and slice selection is achieved through NSSF.

[0189] The network exposure function (NEF): provides capability exposure, such as outputting the capabilities of the 5G network to external networks, such as the location information of the terminal to the outside, etc. At the same time, NEF can also accept external information and update some network information for management.

[0190] The Network Repository Function (NRF): The main function is to manage all 5G support service interfaces NFs, which can be registered to NRF first, and when NFs find each other, they can query NRF to find each other. This function is similar to the DNS in the 4G network, but the function of NRF is much more complex than that of DNS.

[0191] It should be noted that in order to make the important connection relationship clearer, part of the network element or connection relationship is not shown, and not shown does not mean that it does not exist, for example, UDR and its connection with other NFs, such as PCF, are not described in point-to-point. Those skilled in the art can know the network elements and connection relationships not shown according to common sense.

[0192] It should be noted that with the iteration and evolution of communication technology, some network elements in the above communication system may be replaced by other names, and more or less functions may be assigned. In addition, the above communication system is an example based on the 5G communication architecture, and in fact, the related method processes described later can also be implemented based on other communication architectures, such as 3G, 4G, 6G, and new communication technologies to be launched in the future. The embodiments of the present application are not limited.

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

[0194] There are many network topologies for AIoT devices in the communication system, and the following are some examples of topologies:

[0195] Topology 1, as shown in FIG. 2, the path of the AIoT device to the access network device (R)AN is: AIoT device—(R)AN.

[0196] Topology 2, as shown in FIG. 3, the path of the AIoT device to the access network device (R)AN is: AIoT device—intermediate node—(R)AN.

[0197] Topology 3, as shown in FIG. 4, the path of the AIoT device to the access network device (R)AN is: (R)AN-AIoT device-assisting node-(R)AN.

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

[0199] The subsequent method flow is mainly described by taking the topology 1 shown in FIG. 2 as an example. In fact, when the topology is changed to FIG. 3, FIG. 4, FIG. 5 or other topologies, the overall logic of the method flow does not change, only the relevant communication messages pass through other nodes, or the processing process of the relevant communication messages is changed to other nodes.

[0200] The embodiments of the present application mainly aim at the registration and inventory of AIoT devices. The registration and inventory process will be introduced first.

[0201] Please refer to FIG. 6, which is a flowchart of AIoT device registration provided by an embodiment of the present application. The method can be implemented based on the architecture shown in FIG. 1 and the related topologies mentioned above. The method includes the following steps:

[0202] Step 0: Pre-configuration before registration, for example, before the AIoT device registers, the AIoT device owner pre-configures the required information for the AIoT device to register to the network, which can include default AIoT device ID and default security credential, etc. In addition, before the AIoT device is shipped, the manufacturer will assign a unique tag identification (Tag ID, TID) to each AIoT device; and the 5GC internal and third-party security credential holder will also pre-configure the device TID, default security credential, device registration state (unregistered), etc.

[0203] The instance identification (Instance ID) value in the default AIoT device ID of the AIoT device can be 0 before the registration is completed, and the Instance ID value will change after the registration is completed. Therefore, the AIoT device can judge its registration state according to whether the locally stored Instance ID is 0. In addition, the security credential holder can be flexibly deployed in the business operator, roaming operator, enterprise or third-party AF according to the operator ID (such as Operator ID) and group identification (such as Group ID) contained in the default AIoT device ID, so as to realize different networking architectures.

[0204] Step 1: AF sends a registration request to NEF, which can contain the following parameters: Transaction ID, TID list (e.g., including TIDs of devices to be registered), Operator ID list, Area information (e.g., geographic location information of the area where the devices to be registered are located), AF ID, etc.

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

[0206] Verifies the identity of the AF and decides whether to allow it to access the 5G system.

[0207] Checks authorization: determines whether the AF is authorized to initiate the registration process.

[0208] Checks authorization: determines whether the operators in the operator list are authorized.

[0209] Converts the location information into a TA list, and NEF selects the corresponding core network equipment (e.g., AMF, AIoTF, etc.) based on the TA list, and then sends the registration request to the corresponding core network equipment.

[0210] Note that 5GC can add a new network element AIoTF for AIoT business execution to manage AIoT devices and corresponding processes (such as registration). AIoTF can be a standalone network element or can be integrated into other network elements (such as AMF). If no AIoTF is added, AMF can replace its related functions (manage AIoT devices and corresponding processes such as registration).

[0211] In addition, NEF only sends the registration request after the AF identity verification and authorization checks are passed.

[0212] Step 3: NEF sends a registration request to AMF or AIoTF, which can carry the above-mentioned TID list, Transaction ID, Operator ID list, TA list, etc.

[0213] Step 4: AMF or AIoTF selects NG-RAN reader based on the TA list.

[0214] Step 5: AMF or AIoTF sends a registration request to the selected NG-RAN reader, which includes the TID list, Operator ID list, etc.

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

[0216] Optionally, if the TID list is not carried in the registration request broadcast by the NG-RAN reader, all unregistered AIoT devices that match the Operator ID list in the registration request need to perform the registration procedure. For example, an AIoT device can determine whether it is in a registered or unregistered state according to whether the Instance ID value in the device ID is 0.

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

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

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

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

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

[0222] Step 12: The AMF or AIoTF sends a registration response to the NEF.

[0223] Step 13: The NEF sends a registration response to the AF.

[0224] Please refer to FIG. 7, which is a flowchart of AIoT device inventory provided by an embodiment of the present application. The method can be implemented based on the architecture shown in FIG. 1 and the related topologies mentioned above, and includes the following steps:

[0225] Step 1: The AF sends an inventory request to the NEF, which can contain the following parameters: transaction number (e.g. Transaction ID), device identification information, area information (such as geographic location information of the area where the device to be inventoried is located), AF identifier (e.g. AF ID), etc. The device identification information can be information that can distinguish the device to be inventoried from other devices. The device identification information can be a TID or other device identifier, for example, an EPC or a local identifier assigned by the AF to each terminal within its management scope. Within the management scope of the AF, the local identifiers of different terminals are different, and any two different terminals can be distinguished from a global perspective through the identifier of the AF and the local identifier. In an optional scheme, the device identification information can be the TID.

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

[0227] Verifying the identity of the AF and determining whether to allow it to access the 5G system.

[0228] Checking authorization: determining whether to allow the AF to initiate the inventory process.

[0229] Converting the location information into a TA list, and the NEF will select the corresponding core network device (e.g. AMF, AIoTF, etc.) according to the TA list, and will subsequently send the inventory request to the corresponding core network device.

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

[0231] In addition, the NEF will only send the inventory request after the identity verification of the AF and the authorization check are passed.

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

[0233] Step 4: The AMF or AIoTF selects an NG-RAN reader according to the TA list.

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

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

[0236] Step 7: If the information of the AIoT device matches the list of device identification information in the inventory request (and possibly also confirms that other information matches, such as Operator), the inventory result is obtained and an inventory response (which can also be referred to as an inventory result) is sent to the NG-RAN reader, for example, the inventory response includes the AIoT device identification code, which can be the Electronic Product Code (EPC) of the device.

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

[0238] 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 identification reported by the device. Optionally, the AMF or AIoTF stores the inventory result of the AIoT device in the UDM, AMF or AIoTF.

[0239] Step 10: The AMF or AIoTF sends the inventory response to the NEF.

[0240] Step 11: The NEF returns the inventory response to the AF.

[0241] The applicant believes that when the registration request and the inventory request issued by the AF are directed to the same group (or individual), the related execution processes are similar or repetitive, and there is a dependency relationship between inventory and registration. Therefore, it is considered to combine and execute the registration process and the inventory process, 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 while reporting the inventory result, so as to reduce the number of signaling and the processing overhead of the CN, thereby improving the response speed of the AIoT device and the inventory efficiency. The following describes the scheme of combining and executing the registration process and the inventory process in combination with FIG. 8-FIG. 13.

[0242] Please refer to FIG. 8, which is a flowchart of a communication method provided by an embodiment of the present application. The communication method can be implemented based on the architecture shown in FIG. 1 or other architectures, and the topology structure can be any one of the topology structures shown in FIG. 2-FIG. 5 or other topology structures. In this method, the registration request sent by the AF is enhanced, so that the registration request indicates both inventory and registration. The method includes but is not limited to the following steps:

[0243] Step S801: The AF sends a first registration request to the NEF.

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

[0245] Optionally, the first information includes information of a terminal to be registered, and the second information is used to indicate that the terminal to be registered is to be inventoried. The message format of the first registration request is a registration request (Registration Request), which is equivalent to an enhanced registration request (Registration Request) that additionally includes a function of requesting the terminal to be inventoried.

[0246] In this case, the first information includes information of a terminal to be registered, which can specifically include a list of device information of one or more terminals to be registered, such as a list of first identifiers of devices (such as a list of TIDs). Alternatively, the first information includes area information, which indicates that the terminals in the corresponding area belong to the terminals to be registered. Of course, other ways can also be used to indicate the terminals to be registered. The information used to indicate the terminals to be registered can be one item or multiple items.

[0247] The second information can include an inventory indicator indi_inventory. For example, an inventory indicator indi_inventory is additionally set for each terminal to be registered involved in the first information, which is used to indicate that the terminal to be registered needs to be inventoried. For another example, an inventory indicator indi_inventory can be set for all terminals to be registered involved in the first information as a whole, which is used to indicate that all the terminals to be registered need to be inventoried.

[0248] The first registration request can further include third information indicating information of an access network device (e.g., RAN) and / or a core network device (e.g., AMF) that provides services for the terminal to be registered. For example, the third information includes a reader identifier indi_reader indicating information of a RAN reader (e.g., a RAN ID or a UE ID with a timestamp for an AF or other network element to update information of the reader RAN associated with the terminal in time), and the third information includes an AMF identifier indi_AMF indicating information of an AMF (e.g., an AMF ID), which can be a globally unique AMF identifier (GUAMI) or a self-defined AMF name for network management and operation scenarios to facilitate an administrator to identify and manage different AMF instances. The AMF Name can include geographic location information (e.g., “AMF-NewYork”) or a functional description (e.g., “AMF-HighCapacity”). The AMF Name can also be a network function instance identifier (NF Instance ID) for uniquely identifying each network function instance in the 5G core network, including an AMF, which can be assigned and managed by a network function registration function (NRF). Of course, the third information can indicate information of other network elements in addition to the access network device or the AMF, and the principle is the same as that of the AMF and the RAN.

[0249] The first registration request can further include other information, such as a transaction number (e.g., Transaction ID), a list of operator IDs (e.g., Operator ID), an AF identifier (e.g., AF ID), and the like. Optionally, the Instance ID in the default terminal ID of the terminal can be 0 before the terminal completes registration, and the Instance ID value will change after the registration is completed. Therefore, the terminal can determine its registration state according to whether the locally stored Instance ID is 0. The list of operator IDs (e.g., Operator ID) can identify the operator that provides services for the unregistered terminal, and the AF identifier (e.g., AF ID) can identify the AF that manages the unregistered terminal. Alternatively, the terminal can not have a default ID, but determine whether it is in a registered state through other information stored locally or remotely.

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

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

[0252] The AF is authenticated, and it is determined whether to allow it to access the 5G system (or other communication).

[0253] Check authorization: determine whether the AF is allowed to initiate the registration procedure.

[0254] Check authorization: determine whether the operator in the operator list is authorized (if there is an operator list, this operation can be performed).

[0255] Convert the location information into a TA list, and the NEF selects the corresponding core network device (such as AMF, AIoTF, etc.) according to the TA list, and then sends the first registration request to the corresponding core network device.

[0256] Optionally, the NEF sends the first registration request after the AF is authenticated and the authorization check is passed. Optionally, the first registration request can include a TA list.

[0257] It should be noted that before the NEF sends the first registration request, other related operations can also be performed, such as performing other condition judgments, and sending the first registration request under the condition that other conditions are met.

[0258] It should be noted that the NEF can parse the first registration request to obtain the content indicated by the first registration request, or can not parse the first registration request, but only transmit the first registration request. Whether it is the case can be pre-configured as needed.

[0259] Step S803: The NEF sends the first registration request to the core network device.

[0260] The core network device is not limited here, and the network element involved in different scenarios can be different. 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 corresponding processes (such as registration). AIoTF can be an independent network element, or it can be integrated into other network elements (such as AMF). If no AIoTF is added, the AMF can replace its related functions (manage AIoT devices and corresponding processes (such as registration)). Therefore, in this case, the core network device can be AIoTF or AMF.

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

[0262] It should be noted that before the core network device sends the first registration request, other related operations can also be performed, such as performing other condition judgments, and sending the first registration request under the condition that other conditions are met.

[0263] It should be noted that the core network device can parse the first registration request to obtain the content indicated by the first registration request. For example, the first registration request received does not carry a transaction ID, and the transaction ID is added to the first registration request by the core network device (such as AMF). For another example, the first registration request received by the core network does not carry the third information mentioned above, and 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). The corresponding actual application scenario is that the AF does not have the demand for RAN reader information and AMF information, but the core network device has the demand, so the core network device adds the corresponding demand in the first registration request. The subsequent processing principle can be who requests who feeds back, that is, if the third information is added to the first registration request by the AF, the RAN reader information and the AMF information finally need to be fed back to the AF, and if the third information is added to the first registration request by the core network device, the RAN reader information and the AMF information finally need to be fed back to the core network device, without the need to be fed back to the AF. Of course, the core network device can also not parse the first registration request, but only transmit the first registration request in a transparent manner. The specific condition can be pre-configured as needed.

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

[0265] Specifically, the core network device can select a corresponding access network device RAN according to the TA list, for example, NG-RAN reader, and then send the first registration request to the NG-RAN reader.

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

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

[0268] The access network device can send the first registration request in a broadcast or unicast manner.

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

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

[0271] In one aspect, the terminal can learn from the first information in the first registration request that network registration is needed. Specifically, the first registration request contains a first identifier list (e.g., a TID list). The terminal determines whether its own information matches the first identifier list in the first registration request. If the match is found, the terminal performs the registration procedure using the locally stored default device ID, first identifier (e.g., TID), and security certificate after activation, including sending the default device ID, first identifier (e.g., TID), and security certificate to the access network device (e.g., NG-RAN reader), which can be considered as the registration feedback information returned by the terminal to the access network device.

[0272] Optionally, when determining whether the match is found, other information may also need to be matched. Specifically, which information needs to be matched can be pre-configured as needed. For example, the Operator ID may need to be matched.

[0273] In the case where the first registration request carries the Operator ID list, optionally, if the first registration request broadcast by the access network device (e.g., NG-RAN reader) does not carry the first identifier (TID) list, all unregistered terminals that match the Operator ID list in the first registration request need to perform the registration procedure. For example, the terminal can determine whether it is in a registered or unregistered state according to whether the Instance ID value in the device ID is 0.

[0274] On the other hand, the terminal can learn from the second information in the first registration request that inventory is needed, so the terminal will obtain the inventory result and report it. Optionally, the inventory result includes the EPC.

[0275] 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).

[0276] In an optional solution, the content in the first registration request can be all or part of the non-access layer message (NAS Msg) encapsulated in the next generation application protocol (NGAP) message / NGAP-like message (NGAP-like Msg), and the first registration response Registration Response returned by the terminal can also be all or part of the NAS Msg, such as the first identifier (such as TID), Operator ID, credential, etc. in the first registration response are encapsulated in the NAS Msg. The content in the NAS Msg is invisible to the access network device (such as RAN reader). The terminal's self-checking result (such as EPC, etc.) can also be included in the NAS Msg, or encapsulated in the container of the NAS Msg. The core network device (such as AMF / AIoTF) cannot see the container content of the NAS Msg, that is, the core network device cannot analyze the terminal's checking result, ensuring the security and privacy of data transmission in the core network. Whether the content is encapsulated in the NAS Msg or not, and other possible encapsulation methods can be set according to the scene needs.

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

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

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

[0280] Step S813: The core network device determines the target certificate holder according to the first registration response.

[0281] For example, the target certificate holder is determined according to the Operator ID and / or Group ID obtained from the default device ID contained in the first registration response.

[0282] Step S814: The core network device and the certificate holder perform device identity authentication using TID and security certificate.

[0283] Wherein, TID can be used as a username. For example, once the authentication is successful, the 5GC (or joint AF) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0284] The newly generated device ID will be used between the core network (for example, 5GC) and the terminal (such as AIoT device).

[0285] Step S815: The core network device stores the newly generated device ID of the terminal, the first identifier, and the registration status to the core network.

[0286] The registration status here is "registered" after registration, and the information to be stored includes the newly generated device ID of the terminal, the first identifier (such as TID), and the registration status, and can also include other information, such as inventory results (such as EPC), RAN ID, etc., which can be stored in UDM, AMF or AIoTF or other network elements or functions in the core network.

[0287] For example, the new device ID, the first identifier (such as TID), the registration status (registered), the EPC (if the device reports the EPC), the RAN ID (if the RAN reader receives the indi_reader indication and feeds back the RAN ID), the AMF ID (if the AMF or AIoTF receives the indi_AMF indication and feeds back the AMF ID), etc. are stored in UDM, AMF, AIoTF with the new device ID of the terminal as the index, to construct the device context information.

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

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

[0290] In the above manner, the terminal can be registered to the core network; the registration principles of other terminals are the same.

[0291] The details of this part of the registration can also refer to steps 7-11 in the method flow shown in FIG. 6.

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

[0293] The information carried in the first registration response received by the core network device can be different from the information carried in the first registration response sent by the core network device, such as the first registration response received by the core network device including some information for registering the terminal to the core network, and the inventory result; while the first registration response sent by the core network device includes the information that the terminal has been registered to the core network, and the inventory result. For another example, if the third information is added to the first registration request by the core network device, the RAN ID and / or AMF ID fed back for the third information can be carried in the first registration response received by the core network device, but can not be carried in the first registration response sent by the core network device.

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

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

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

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

[0298] 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, the RAN ID and / or the AMF ID fed back for the third information can be carried in the first registration response received by the AF. The message format of the first registration response is Registration response.

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

[0300] In the method shown in FIG. 8, when the device has both registration requirements and inventory requirements, the first registration request sent by the AF explicitly indicates that the terminal is not registered and needs to be inventoried, so that the core network triggers the registration process while issuing the inventory instruction, and subsequently completes the network registration and inventory simultaneously, saving the identity verification step of the terminal after the core network receives the inventory result, reducing the number of network signaling and the number of terminal reports, improving the terminal energy efficiency, and reducing the core network processing overhead.

[0301] Please refer to FIG. 9, which is a flowchart of a communication method provided by an embodiment of the present application. The communication method can be implemented based on the architecture shown in FIG. 1 or other architectures, and the topology structure can be any of the topology structures shown in FIGS. 2-5 or other topology structures. In this method, the inventory request sent by the AF is enhanced to indicate both inventory and registration. The method includes but is not limited to the following steps:

[0302] Step S901: The AF sends a first inventory request to the NEF.

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

[0304] Optionally, the second information includes information of 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 in the network; the message format of the first inventory request is an inventory request (Inventory Request), which is equivalent to an enhanced inventory request (Inventory Request) that additionally requests the terminals to register in the network.

[0305] In this case, the second information includes information of terminals that need to be inventoried, which can specifically include a list of device information of one or more terminals that need to be inventoried, such as a list of second identifiers of devices (such as a list of EPCs or a list of third-party AF self-defined local identifiers or other types of identifiers), or the second information includes area information that indicates that terminals in the corresponding area belong to terminals that need to be inventoried, and of course, other ways can also be used to indicate terminals that need to be inventoried. The information used to indicate terminals that need to be inventoried can be one or more. Optionally, the second information can also include an inventory strategy, which is used to indicate related requirements or rules of inventory, such as inventory frequency, inventory period, etc.

[0306] The first information can include a registration indicator indi_registration. For example, among the terminals that need to be inventoried according to the second information, some or all of them can not have been registered, and therefore, the registration indicator indi_registration is additionally set for all these unregistered terminals to indicate that the terminal needs to be registered. For another example, a registration indicator indi_registration can be set for all the unregistered terminals that need to be inventoried according to the first information to indicate that all these unregistered terminals need to be registered. Therefore, the first information can include a registration list unregistered_list (X, Y, Z, …) of information (such as device ID) of all unregistered terminals and a registration indicator indi_registration, which is used to indicate that the terminals recorded in the registration list need to be registered in the network. Wherein, X, Y, Z, … respectively represent the device ID of different terminals. In an optional scheme, the first information includes a list of terminals that need to be registered and inventoried, such as a list of first identifiers (such as a list of TIDs), and the registration indicator indi_registration indicates that the terminals in the list need to be registered. The second information includes a list of all terminals that need to be inventoried, such as a list of EPCs.

[0307] The first inventory request can further include third information for indicating information of an access network device (e.g., RAN) and / or a core network device (e.g., AMF) that provides service for the terminal to be registered. For example, the third information includes a reader identifier indi_reader for indicating information of a RAN reader (e.g., a RAN ID or a UE ID with a timestamp for an AF or other network element to update information of a reader RAN associated with the terminal in time), and the third information includes an AMF identifier indi_AMF for indicating information of an AMF (e.g., an AMF ID), which can be a globally unique AMF identifier (GUAMI) or a self-defined AMF name for network management and operation scenarios to facilitate an administrator to identify and manage different AMF instances. The AMF Name can include geographical location information (e.g., “AMF-NewYork”) or a functional description (e.g., “AMF-HighCapacity”). The AMF Name can also be a network function instance identifier (NF Instance ID) for uniquely identifying each network function instance in the 5G core network, including an AMF, which can be assigned and managed by a network function registration function (NRF). Of course, the third information can also indicate information of other network elements in addition to the access network device or the AMF, and the principle is the same as that of the AMF and the RAN.

[0308] Optionally, the first inventory request can further include other information, such as an AF identifier (AF ID), which can be used to identify an AF that manages the terminal to be inventoried.

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

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

[0311] Identity verification is performed on the AF to determine whether to allow it to access the 5G system (or other communication network).

[0312] Authorization check: Determine whether to allow the AF to initiate the inventory process.

[0313] Convert the location information into a TA list, and the NEF will select corresponding core network devices (e.g., AMF, AIoTF, etc.) according to the TA list, and will subsequently send corresponding messages (e.g., a first registration request) to the corresponding core network devices.

[0314] Optionally, the NEF generates a first registration request according to the first inventory request after identity verification of the AF is passed. For example, the NEF can learn from the second information in the first inventory request that one or more terminals need to be inventoried, and can learn from the first information in the first inventory request that a device has not been registered to the network. Therefore, the first inventory request is converted into a first registration request, and the message format of the first registration request is a registration request (Registration Request), which is equivalent to an enhanced registration request (Registration Request) that additionally adds the function of requesting the terminal to be inventoried.

[0315] Optionally, the first registration request generated in this link can include the following contents: transaction number (such as Transaction ID), first identification list (such as 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 be registered to the network, and the inventory indicator indi_inventory is used to indicate that these terminals that need to be registered to the network also need to be inventoried. Optionally, before the terminal completes registration, the Instance ID value in the default terminal ID of the terminal can be 0, and the Instance ID value will change after registration is completed. Therefore, the terminal can judge its registration state according to whether the locally stored Instance ID is 0. Of course, the terminal can judge its registration state through other ways, and the specific way to judge the registration state can be preconfigured. Optionally, the above-mentioned first identification list can be determined according to the above-mentioned second identification list and the pre-stored identification mapping relationship. For example, the mapping relationship between the second identification and the first identification is pre-stored, so that the first identification list of some terminals can be determined when the second identification of these terminals is known, so as to obtain the first identification list. Optionally, the second identification can be the first identification, in which case, the process of determining the first identification list through the mapping relationship does not exist. It should be noted that the first identification and the second identification mentioned in the embodiments of the present application are both identifications of the terminal. The first identification is described by taking TID as an example, and the second identification is described by taking EPC as an example. Actually, the first identification can also be EPC or other identifications, and the second identification can also be TID or other identifications. The second identification can be the first identification.

[0316] After the first registration request is generated, the first registration request is issued. Optionally, the first registration request can include a TA list.

[0317] It should be noted that before the NEF issues the first registration request, other related operations can also be performed, such as performing other condition judgments, and issuing the first registration request under the condition that other conditions are met.

[0318] Step S903: The NEF sends a first registration request to the core network device.

[0319] The core network device is not limited here, and the network element involved in different scenarios can be different. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element AIoTF to perform AIoT business to manage AIoT devices and corresponding processes (such as registration). The AIoTF can be an independent network element, or it can be integrated into other network elements (such as AMF). If no AIoTF is added, the AMF can replace its related functions (manage AIoT devices and corresponding processes (such as registration)). Therefore, in this case, the core network device can be AIoTF or AMF.

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

[0321] It should be noted that before the core network device issues the first registration request, other related operations can also be performed, such as performing other condition judgments, and issuing the first registration request under the condition that other conditions are met.

[0322] It should be noted that the core network device can parse the first registration request to obtain the content indicated by the first registration request, for example, the received first registration request does not carry a transaction ID, but the core network device (such as AMF) adds a transaction ID to the first registration request. For another example, the first registration request received by the core network does not carry the third information mentioned above, but 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). The corresponding actual application scenario is that the AF may not have the demand to obtain the RAN reader information and the AMF information, but the core network device has the demand, therefore, the core network device adds the corresponding demand in the first registration request, and the subsequent processing principle can be who requests who feedbacks, that is, if the third information is added to the first registration request by the AF, the RAN reader information and the AMF information finally need to be fed back to the AF, and if the third information is added to the first registration request by the core network device, the RAN reader information and the AMF information finally need to be fed back to the core network device, without the need to be fed back to the AF. Of course, the core network device can also not parse the first registration request, but only transmit the first registration request in a transparent manner, and the specific situation can be pre-configured as needed.

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

[0324] Specifically, the core network device can select a corresponding access network device RAN according to the TA list, for example, NG-RAN reader, and then send a first registration request to the NG-RAN reader.

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

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

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

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

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

[0330] On the one hand, the terminal can learn from the first registration request that network registration is required. Specifically, the first registration request contains a first identity list (such as a TID list), and the terminal judges whether its own information matches the first identity list (such as the TID list) in the first registration request. If it matches, it will use the locally stored default device ID, first identity (such as TID) and security certificate and other information to perform the registration process after activation, including sending a default device ID, TID and security certificate and other registration messages to the access network device (such as the NG-RAN reader), which can be considered as registration feedback information returned by the terminal to the access network device. Optionally, when judging whether it matches, other information may also be involved in the judgment, and specific information to be judged can be configured as needed. For example, it can also be judged whether the Operator ID matches.

[0331] On the other hand, the terminal can learn from the indi_inventory in the first registration request that inventory is required, so the terminal will obtain the inventory result and report it. Optionally, the inventory result includes EPC.

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

[0333] In an optional solution, the content in the first registration request can be all or partially encapsulated in a NAS Msg in a Next Generation Application Protocol (NGAP) / NGAP-like Msg, and the first registration response Registration Response replied by the terminal can also be all or partially encapsulated in a NAS Msg, such as TID, Operator ID, credential, etc. in the first registration response, which are encapsulated in the NAS Msg. The content in the NAS Msg is invisible to the access network device (such as RAN reader), and the inventory result (such as EPC, etc.) reported by the terminal can be included in the NAS Msg or encapsulated in the container of the NAS Msg. The core network device (such as AMF / AIoTF) cannot see the container content of the NAS Msg, that is, the core network device cannot analyze the inventory result reported by the terminal, ensuring the security and privacy of data in the core network transmission process. Whether the content is encapsulated in the NAS Msg or not, and other possible encapsulation manners can be set according to the scene needs.

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

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

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

[0337] Step S913: The core network device determines the target certificate holder according to the first registration response.

[0338] For example, the target certificate holder is determined according to the Operator ID and / or Group ID obtained from the default device ID contained in the first registration response.

[0339] Step S914: The core network device performs device identity authentication with the certificate holder by using the first identity (such as TID) and the security certificate.

[0340] For example, the TID can be used as a username. For example, once the authentication is successful, the 5GC (or joint AF) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0341] The newly generated device ID will be used between the core network (for example, 5GC) and the terminal (such as AIoT device).

[0342] Step S915: The core network device stores the newly generated device ID of the terminal, the first identifier (such as TID), and the registration status to the core network.

[0343] After registration, the registration status here is "registered", and the information to be stored includes the newly generated device ID of the terminal, the first identifier (such as TID), and the registration status, and can also include other information, such as inventory results (such as EPC), RAN ID, etc. The storage to the core network can be specifically stored in the UDM, AMF or AIoTF or other network elements or functions in the core network.

[0344] For example, the new device ID, the first identifier (such as TID), the registration status (registered), the EPC (if the device reports the EPC), the RAN ID (if the RAN reader receives the indi_reader indication and feeds back the RAN ID), the AMF ID (if the AMF or AIoTF receives the indi_AMF indication and feeds back the AMF ID) and the like are stored in the UDM, AMF, AIoTF as an index of the new device ID of the terminal, so as to construct the device context information.

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

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

[0347] In the above manner, the terminal can be registered to the core network; the registration principles of other terminals are the same.

[0348] The details of this part of the registration can also refer to steps 7-11 in the method flow shown in FIG. 6.

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

[0350] The information carried in the first registration response received by the core network device can be different 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 some information for registering the terminal to the core network, and the inventory result; while the first registration response sent by the core network device includes the information that the terminal has been registered to the core network, and the inventory result. For another example, if the third information is added to the first registration request by the core network device, the RAN ID and / or AMF ID fed back for the third information can be carried in the first registration response received by the core network device, but can not be carried in the first registration response sent by the core network device.

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

[0352] Step S919: The NEF sends a first inventory response to the AF.

[0353] It should be noted that since the NEF sends the first registration request to the core network device, it will receive a response to the first registration request, i.e., a first registration response, from the core network device, and the message format is Registration response. However, the NEF receives the first inventory request from the AF, and thus feeds back a response to the first inventory request, i.e., a first inventory response, to the AF, and the message format is Inventory response.

[0354] That is, the NEF needs to convert the first registration response into a first inventory response, which can include inventory results, such as EPC information of the terminal, and the like. It can also include Transaction ID, first identifier (such as TID), and the like.

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

[0356] Step S920: The AF receives the first inventory response.

[0357] The AF can obtain the inventory results and registration status of the terminal according to the first inventory response.

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

[0359] It should be noted that in the above method flow, the operation of converting the first inventory request into the first registration request is completed by the NEF. In fact, this conversion can also be completed by the core network device or the access network device. For example, the NEF receives the first inventory request, sends the first inventory request to the core network device, the core network device converts the first inventory request into the first registration request, and then sends the first registration request to the access network device. In summary, which network element converts the first inventory request into the first registration request can be set according to specific scenarios and actual needs, which is not limited here.

[0360] Of course, even in some optional schemes, the first inventory request is received by the NEF without being converted into the first registration request, but the first inventory request is continued to be sent. 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 added is the information required to complete the above process.

[0361] Further, in an optional solution, after the NEF receives the first inventory request, if it is found that some of the terminals that need to be inventoried in the first inventory request have completed network registration, and some of the terminals have not completed registration, then for the part of the terminals that have not completed registration, the NEF sends the core network device the first registration request described above, and for the part of the terminals that have completed registration, the NEF sends the core network device a third inventory request, the third inventory request including information of the registered terminals that need to be inventoried, and the message format of the third inventory request is an inventory request.

[0362] The third inventory request including information of the registered terminals that need to be inventoried can specifically be that the third inventory request includes a second identifier list (such as an EPC list) of one or more registered terminals that need to be inventoried, or the third inventory request includes area information, which indicates that the terminals in the corresponding area belong to the terminals that need to be inventoried, and of course, other ways can also be used to indicate the terminals that need to be inventoried, and the information used to indicate the terminals that need to be inventoried can be one or more. Optionally, the third inventory request can also include an inventory policy, which is used to indicate related requirements or rules of the inventory, such as inventory frequency, inventory period, etc.

[0363] For the inventory process of the registered terminals that need to be inventoried, reference can be made to the inventory process shown in FIG. 7, which will not be described here. It should be noted that the inventory result in the third inventory response received by the NEF for the third inventory request can be aggregated with the inventory result in the first registration response received by the NEF to obtain the inventory result of all the terminals involved in the second inventory request, and then a first inventory response is generated according to the inventory result of all the terminals and fed back to the AF.

[0364] It should be noted that in the above method process, the operation of generating the third inventory request according to the first inventory request is completed by the NEF, and in fact, this conversion can also be completed by the core network device or the access network device, for example, the NEF receives the first inventory request and sends it to the core network device, the core network device identifies the registered terminals and generates a third inventory request, and then sends the third inventory request to the access network device. In summary, which network element generates the third inventory request can be set according to the specific scene and actual needs, which is not limited here.

[0365] In the method shown in FIG. 9, in the case where the device has both a registration requirement and an inventory requirement, the first inventory request sent by the AF explicitly informs the terminal that it is not registered and needs to be inventoried, so that the core network triggers the registration process while issuing the inventory instruction, and subsequently completes the network registration and inventory, saves the identity verification step of the terminal after the core network receives the inventory result, reduces the number of network signaling and the number of terminal reports, improves the terminal energy saving efficiency, and reduces the core network processing overhead.

[0366] Please refer to FIG. 10, which is a flowchart of a communication method provided by an embodiment of the present application. The communication method can be implemented based on the architecture shown in FIG. 1 or other architectures, and the topology structure can be any of the topology structures shown in FIGS. 2-5 or other topology structures. In this method, when the terminal is not registered to the network, the AF needs to send both an inventory request and a registration request, so that the terminal returns the inventory result after the registration is completed, but the second registration request sent by the AF increases a wait indicator, and the network element receiving the second registration request can merge and process the second registration request and other service requests (such as the second inventory request) received subsequently according to the indication of the wait. The method includes but is not limited to the following steps:

[0367] Step S1001: The AF sends a second registration request to the NEF.

[0368] The second registration request includes first information and second information. The first information is information related to network registration of the terminal, for example, the first information includes information of the terminal to be registered. The second information is information related to inventory of the terminal, for example, the second information includes a wait indication, which is used to indicate that the second registration request and a service associated with the second registration request are merged and processed after a first time. For example, the inventory request can be set as a service associated with the second registration request. The message format of the second registration request is a registration request (Registration Request), which is equivalent to an enhanced registration request (Registration Request), so that the registration request additionally has the function of waiting for service merging and processing.

[0369] Therefore, through the second registration request, the network registration process of the terminal can be initiated, and the inventory process of the terminal can be supported. The terminal can be an Internet of Things device (such as an AIoT device) or other types of devices.

[0370] In this case, the first information includes information of the terminal to be registered, which can specifically be that the first information includes a list of device information of one or more terminals to be registered, such as a list of first identifiers (such as a list of TIDs), or that the first information includes area information, which indicates that the terminals in the corresponding area belong to the terminals to be registered. Of course, other ways can also be used to indicate the terminals to be registered, and the information used to indicate the terminals to be registered can be one or more.

[0371] The second information can include a wait indicator wait to indicate that the network element (such as the NEF) receiving the second registration request does not process the request at present, but waits for a first time (which can be set according to the need), and then processes similar or related service requests issued within the first time together with the second registration request. The inventory request can be configured as a service associated with the second registration request. Alternatively, service requests from the same AF and containing the same Association ID (for example, an identifier generated by the AF and carried in the service request to indicate that multiple services are associated) can be set as associated services. Of course, other rules can also be used to define related services, and specific rules are not limited here.

[0372] The second registration request can also include other information, such as a transaction number (for example, Transaction ID), a list of operator IDs (such as Operator ID), an AF identifier (AF ID), etc. Among them, the value of the Instance ID in the default terminal ID of the terminal before the registration is completed can be 0, and the value of the Instance ID will change after the registration is completed. Therefore, the terminal can judge its registration state according to whether the locally stored Instance ID is 0. The list of operator IDs (such as Operator ID) can identify the operator providing services for the unregistered terminal, and the AF identifier (AF ID) can identify the AF managing the unregistered terminal.

[0373] Step S1002: The AF sends a second inventory request to the NEF.

[0374] Specifically, the second inventory request can include information of the terminal to be inventoried, for example, a list of second identifiers (such as a list of EPCs) of one or more terminals to be inventoried. Of course, area information can also be included, which indicates that the terminals in the corresponding area belong to the terminals to be inventoried. Of course, other ways can also be used to indicate the terminals to be inventoried, and the information used to indicate the terminals to be inventoried can be one or more. Optionally, an inventory strategy can also be included, which is used to indicate related requirements or rules of the inventory, such as inventory frequency, inventory period, etc.

[0375] The second inventory request can further include third information for indicating information of the access network device (such as RAN) and / or core network device (such as AMF) that provides services for the terminal to be registered. For example, the third information includes a reader identifier indi_reader for indicating information of the RAN reader (such as a time-stamped RAN ID or UE ID for the AF or other network element to update the information of the reader RAN associated with the terminal in time), and the third information includes an AMF identifier indi_AMF for indicating information of the AMF, such as an AMF ID, which has multiple possibilities, such as a globally unique AMF identifier (GUAMI), and can also be a self-defined AMF name for network management and operation scenarios, facilitating administrators to identify and manage different AMF instances. The AMF Name can 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) for uniquely identifying each network function instance in the 5G core network, including the AMF, which can be assigned and managed by a network function registration function (NRF). Of course, the third information can also indicate information of other network elements in addition to the information of the access network device or AMF, and the principle is the same as that of the AMF and RAN.

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

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

[0378] It should be noted that the NEF receives the second registration request first, and according to the indication of the wait indicator wait in the second registration request, starts a timer, receives the second inventory request within the first time, and after the first time is reached, processes the service requested by the second registration request and the service requested by the second inventory request. For example, the NEF can know from the second registration request that the terminal is to be registered in the network, and can know from the second inventory request that the terminal is to be inventoried, and thus generates a first registration request including the first information and the second information. The message format of the first registration request is a registration request (Registration Request), which is equivalent to an enhanced registration request (Registration Request), which additionally increases the function of requesting the terminal to be inventoried, wherein:

[0379] The first information includes information of the terminal to be registered. Specifically, the first information includes a list of device information of one or more terminals to be registered, such as a list of first identifiers (e.g., a list of TIDs), a list of TAs, and the like.

[0380] The second information can include an inventory indicator indi_inventory. For example, an inventory indicator indi_inventory is additionally set for each terminal to be registered involved in the first information, indicating that the terminal to be registered needs to be inventoried. For another example, an inventory indicator indi_inventory can be set for all terminals to be registered involved in the first information as a whole, indicating that all the terminals to be registered need to be inventoried.

[0381] Optionally, the first registration request can also include some of the information mentioned above that is carried in the second registration request and / or the second inventory request, such as the third information, an AF identifier (AF ID), and the like, which will not be described here again.

[0382] Optionally, after the NEF receives the second registration request and waits for the first time according to the waiting indicator wait, before generating the first registration request, one or more of the following operations can be performed:

[0383] Identity verification is performed on the AF to determine whether the AF is allowed to access the 5G system (or other communication system).

[0384] Authorization check is performed to determine whether the AF is authorized to initiate the registration process.

[0385] Authorization check is performed to determine whether the operator in the operator list is authorized (if the operator list is available, the operation can be performed).

[0386] The location information is converted into a list of TAs, and the NEF selects a corresponding core network device (e.g., an AMF, an AIoTF, or the like) according to the list of TAs. The registration request will be sent to the corresponding core network device in the future.

[0387] Optionally, after the identity verification of the AF is passed and the authorization check is passed, the NEF generates the first registration request and sends the first registration request. Optionally, the first registration request can include the list of TAs.

[0388] It should be noted that before the NEF generates the first registration request, other related operations can also be performed, such as performing other condition judgments, and generating the first registration request under the condition that other conditions are met.

[0389] Step S1005: The NEF sends the first registration request to the core network device.

[0390] The core network device is specifically a device or function in the core network, which is not limited here, and the network elements involved in different scenarios can be different. For example, taking the 5G core network (5GC) as an example, the 5GC can add a new network element AIoTF to perform AIoT business to manage AIoT devices and corresponding processes (such as registration). The AIoTF can be a standalone network element, or it can be integrated into other network elements (such as AMF). If no AIoTF is added, the AMF can replace its related functions (manage AIoT devices and corresponding processes (such as registration)). Therefore, in this case, the core network device can be AIoTF or AMF.

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

[0392] It should be noted that before the core network device issues the first registration request, it can also perform other related operations, such as performing other condition judgments, and issuing the first registration request under the condition that other conditions are met.

[0393] It should be noted that the core network device can parse the first registration request to obtain the content indicated by the first registration request. For example, the received first registration request does not carry a transaction ID, and the core network device (such as AMF) adds a transaction ID to the first registration request. For another example, the first registration request received by the core network does not carry the third information mentioned above, and 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). The corresponding actual application scenario is that the AF may not have the demand to obtain the RAN reader information and the AMF information, and the core network device has the demand, therefore, the core network device adds the corresponding demand in the first registration request, and the subsequent processing principle can be who requests who feedbacks, that is, if the third information is added to the first registration request by the AF, the RAN reader information and the AMF information are finally fed back to the AF, and if the third information is added to the first registration request by the core network device, the RAN reader information and the AMF information are finally fed back to the core network device, and do not need to be fed back to the AF. Of course, the core network device can also not parse the first registration request, but only transmit the first registration request in a transparent manner, and the specific situation can be pre-configured as needed.

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

[0395] Specifically, the core network device can select a corresponding access network device RAN according to the TA list, for example, NG-RAN reader, and then send the first registration request to the NG-RAN reader.

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

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

[0398] Optionally, the access network device can send the first registration request through broadcasting or unicasting.

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

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

[0401] In one aspect, the terminal can learn from the first information in the first registration request that network registration is needed. Specifically, the first registration request contains a first identifier list (such as a TID list), and 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, the terminal performs a registration process using the locally stored default device ID, the first identifier list (such as the TID list), and the security certificate after activation, including sending a registration message such as the default device ID, the TID, and the security certificate to the access network device (such as the NG-RAN reader), which can be considered as the registration feedback information returned by the terminal to the access network device. Optionally, when determining whether they match, other information may also need to be determined, such as whether the Operator ID matches.

[0402] In the case where the Operator ID is carried in the first registration request, optionally, if the first registration request broadcast by the access network device (such as the NG-RAN reader) does not carry the first identifier list (such as the TID list), all terminals that match the Operator ID list in the first registration request need to perform the registration procedure. For example, the terminal can determine whether it is in a registered or unregistered state according to whether the Instance ID value in the device ID is 0.

[0403] On the other hand, the terminal can learn from the second information in the first registration request that inventory is needed, so the terminal will obtain the inventory result and report it, and optionally, the inventory result includes the EPC.

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

[0405] In an optional solution, the content in the first registration request can be all or partially encapsulated in a NAS Msg in a Next Generation Application Protocol (NGAP) / NGAP-like Msg, and the first registration response Registration Response replied by the terminal can also be all or partially encapsulated in a NAS Msg, such as TID, Operator ID, credential, etc. in the first registration response, which are encapsulated in the NAS Msg. The content in the NAS Msg is invisible to the access network device (such as RAN reader). The inventory result (such as EPC, etc.) reported by the terminal can also be included in the NAS Msg, or encapsulated in the container of the NAS Msg. The container content of the NAS Msg is invisible to the core network device (such as AMF / AIoTF), that is, the core network device cannot analyze the inventory result reported by the terminal, ensuring the security and privacy of data in the core network transmission process. Whether the content is encapsulated in the NAS Msg or not, and other possible encapsulation methods, can be set according to the scene needs.

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

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

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

[0409] Step S1015: The core network device determines the target credential holder according to the first registration response.

[0410] For example, the target credential holder is determined according to the Operator ID and / or Group ID obtained from the default device ID contained in the first registration response.

[0411] Step S1016: The core network device and the credential holder perform device identity authentication using the first identity and the security certificate.

[0412] For example, the first identity (such as TID) can be used as a username. For example, once the authentication is successful, the 5GC (or joint AF) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0413] The newly generated device ID will be used between the core network (for example, 5GC) and the terminal (such as AIoT device).

[0414] Step S1017: The core network device stores the newly generated device ID of the terminal, the first identifier, and the registration status to the core network.

[0415] The registration status here is "registered" after registration, and the information to be stored includes the newly generated device ID of the terminal, the first identifier (such as TID), and the registration status, and can also include other information, such as inventory results (such as EPC), RAN ID, etc. The storage to the core network can be specifically stored in UDM, AMF or AIoTF or other network elements or functions in the core network.

[0416] For example, the new device ID, the first identifier (such as TID), the registration status (registered), the EPC (if the device reports the EPC), the RAN ID (if the RAN reader receives the indi_reader indication and feeds back the RAN ID), the AMF ID (if the AMF or AIoTF receives the indi_AMF indication and feeds back the AMF ID) and the like are stored in UDM, AMF, AIoTF with the new device ID of the terminal as the index, so as to construct the device context information.

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

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

[0419] In the above manner, the terminal can be registered to the core network; the registration principles of other terminals are the same.

[0420] The details of this part of the registration can also refer to steps 7-11 in the method flow shown in FIG. 6.

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

[0422] The information carried in the first registration response received by the core network device can be different 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 some information for registering the terminal to the core network, and the inventory result; while the first registration response sent by the core network device includes the information that the terminal has been registered to the core network, and the inventory result. For another example, if the third information is added to the first registration request by the core network device, the RAN ID and / or AMF ID fed back for the third information can be carried in the first registration response received by the core network device, but can not be carried in the first registration response sent by the core network device.

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

[0424] It should be noted that since the NEF sends the first registration request to the core network device, a response to the first registration request, i.e., a first registration response, will be received from the core network device, and the message format is Registration response. However, the NEF receives the second registration request and the second inventory request from the AF, and thus the message fed back to the AF includes a second inventory response to the second inventory request and a second registration response to the second registration request. Therefore, the NEF needs to generate the second registration response and the second inventory response according to the first registration response.

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

[0426] Optionally, if the third information is carried in the second registration request, the RAN ID and / or the AMF ID fed back for the third information can be carried in the second registration response received by the AF. Optionally, if the third information is carried in the second inventory request, the RAN ID and / or the AMF ID fed back for the third information can be carried in the second inventory response received by the AF.

[0427] Step S1021: The NEF sends the second registration response to the AF.

[0428] Step S1022: The NEF sends the second inventory response to the AF.

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

[0430] The AF can learn the registration state of the terminal according to the second registration response.

[0431] Step S1024: The AF receives the second inventory response.

[0432] The AF can learn the inventory result of the terminal according to the second inventory response.

[0433] Up to now, the AF has completed the registration and inventory of one or more terminals.

[0434] It should be noted that in the above method process, the operation of combining the second registration request and the second inventory request to generate the first registration request is completed by the NEF. In fact, this combination process can also be completed by 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 the second registration request and the second inventory request to the core network device, the core network device combines the second registration request and the second inventory request, generates the first registration request, and then sends the first registration request to the access network device. In summary, the specific network element that performs the combination process can be set according to the specific scene and actual needs, which is not limited here.

[0435] Of course, even in some optional schemes, the second registration request and / or the second inventory request do not need to be combined at the NEF after being received by the NEF, but continue to be sent to the next node. The NEF can still add additional information to the received second registration request and second inventory request to obtain new second registration request and second inventory request, and send it to the next node. The additional information added is the information required to complete the above process.

[0436] In the method shown in FIG. 10, in the case where the device has both registration and inventory requirements, the first registration request sent by the AF explicitly informs the terminal that it is not registered. After the wait indicator wait in the first registration request indicates waiting for the first time, the registration process requested by the first registration request and the inventory process requested by the subsequently received second inventory request are combined to process, so that the network registration and inventory are subsequently completed synchronously, saving the identity verification step of the terminal after the core network receives the inventory result, reducing the number of network signaling and the number of terminal reports, improving the terminal energy efficiency, and reducing the core network processing overhead.

[0437] Please refer to FIG. 11A, which is a flowchart of a communication method provided by an embodiment of the present application. The communication method can be implemented based on the architecture shown in FIG. 1 or other architectures, and the topology it relies on can be any of the topologies shown in FIGS. 2-5 or other topologies. In this way, the AF that initiates the inventory request does not perceive or judge whether the terminal is registered to the network, whether the terminal is registered, how to register, etc. The core network element is responsible for this. The method includes but is not limited to the following steps:

[0438] Step S1101: The AF sends a second inventory request to the NEF.

[0439] The second inventory request includes information of a terminal that needs to be inventoried. The message format of the second inventory request is an inventory request (Inventory Request). The terminal can be an Internet of Things device (such as an AIoT device) or other types of devices.

[0440] The second inventory request includes information of terminals that need to be inventoried. Specifically, the second inventory request includes a list of device information of one or more terminals that need to be inventoried, such as a list of second identifiers (such as an EPC list or a local identifier defined by a third-party AF), or the second inventory request includes area information, which indicates that terminals in the corresponding area belong to terminals that need to be inventoried. Of course, other ways can also be used to indicate terminals that need to be inventoried. The information used to indicate terminals that need to be inventoried can be one or more. Optionally, the second inventory request can also include an inventory strategy, which is used to indicate related requirements or rules of inventory, such as inventory frequency, inventory period, etc.

[0441] Optionally, the second inventory request can also include other information, such as AF information (such as an AF identifier), which can be used to identify an AF that manages terminals that need to be inventoried.

[0442] The second inventory request can also include third information, which is used to indicate information of access network devices (such as RAN) and / or core network devices (such as AMF) that provide services for the terminal to be registered. For example, the third information includes a reader identifier indi_reader, which is used to indicate information of a RAN reader (such as a time-stamped RAN ID or UE ID, which is used by an AF or other network element to update information of a reader RAN associated with a terminal in a timely manner). The third information includes an AMF identifier indi_AMF, which is used to indicate information of an AMF, such as an AMF ID, which has multiple possibilities, such as a globally unique AMF identifier (GUAMI), or a self-defined AMF name, which is used in network management and operation scenarios to facilitate administrators to identify and manage different AMF instances. The AMF Name can include geographic 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), which is used to uniquely identify each network function instance in the 5G core network, including an AMF. The NF Instance ID can be assigned and managed by a network function registration function (NRF). Of course, in addition to indicating information of access network devices or AMFs, the third information can also indicate information of other network elements, and the principle is the same as that of AMF and RAN.

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

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

[0445] Identity verification of the AF, and determine whether to allow it to access the 5G system (or other communication).

[0446] Check authorization: determine whether to allow the AF to initiate the inventory process.

[0447] Convert the location information into a TA list, and the NEF will select the corresponding core network device (such as AMF, AIoTF, etc.) according to the TA list, and then send a corresponding message, such as a second inventory request, to the corresponding core network device.

[0448] Optionally, the NEF sends a second inventory request to the core network device after identity verification of the AF is passed. Optionally, the second inventory request can include a TA list, AF information (such as AF ID), and other information.

[0449] It should be noted that before the NEF issues the second inventory request, it can also perform other related operations, such as performing other conditional judgments, and issuing the second inventory request if other conditions are met.

[0450] Step S1103: The NEF sends a second inventory request to the core network device.

[0451] The core network device is not limited to a specific device or function in the core network, and the network element involved in different scenarios can be different. For example, in a 5G core network (5GC), a new network element AIoTF can be added to perform AIoT business to manage AIoT devices and corresponding processes (such as registration). AIoTF can be an independent network element, or it can be integrated into other network elements (such as AMF). If no AIoTF is added, the AMF can replace its related functions (manage AIoT devices and corresponding processes (such as registration)). Therefore, in this case, the core network device can be AIoTF or AMF.

[0452] Step S1104: The core network device receives the second inventory request.

[0453] The core network device generates a first registration request according to 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, and the core network device can obtain the registration state of terminal information from the UDM, that is, it can learn which devices are not registered to the network (the core network may not store the EPC or third-party custom identifier of the unregistered device). Therefore, the core network device generates a first registration request according to the second inventory request and the information of the terminal not registered to the network. The message format of the first registration request is a registration request (Registration Request), which is equivalent to an enhanced registration request (Registration Request) that adds the function of requesting the terminal to be inventoried.

[0454] Optionally, the first registration request generated in this link can include the following contents: transaction number (such as Transaction ID), unregistered device list unregistered_list (X, Y, Z) (such as EPC list or third-party AF custom identifier list), inventory indicator indi_inventory, etc. The unregistered device list unregistered_list (X, Y, Z) indicates the list of terminals that have not been registered to the network, and the inventory indicator indi_inventory is used to indicate that these terminals need to be registered to the network and also need to be inventoried. Optionally, before the terminal completes registration, the Instance ID value in the default terminal ID can be 0, and the Instance ID value will change after registration is completed. Therefore, the terminal can judge its registration state according to whether the locally stored Instance ID is 0. Of course, the terminal can also judge whether it has been registered through other ways. The specific way of judging can be configured according to actual needs.

[0455] For another example, the second inventory request received by the core network device does not carry the third information mentioned above, but the first registration request carrying the third information is generated by the core network device, and the first registration request carrying the third information is sent to the next node (such as the access network device RAN). The corresponding actual application scenario is that the AF may not have the demand to obtain the RAN reader information and the AMF information, but the core network device has the demand, so the core network device adds the corresponding demand in the first registration request. The subsequent processing principle can be who requests and who is fed back, that is, if the third information is added to the first registration request by the core network, the RAN reader information and the AMF information finally need to be fed back to the core network device, and if the third information is added to the first registration request by other devices, the RAN reader information and the AMF information finally need to be fed back to the other devices, without the need to be fed back to the AF.

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

[0457] Specifically, the core network device can select a corresponding access network device RAN, for example, NG-RAN reader, according to the TA list, and then send a first registration request to the NG-RAN reader.

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

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

[0460] The access network device can send the first registration request in a broadcast or unicast manner.

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

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

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

[0464] On the other hand, the terminal can learn from the indi_inventory in the first registration request that inventory is required. Therefore, the terminal will obtain the inventory result and report it. Optionally, the inventory result includes EPC, third-party custom identity, etc.

[0465] Therefore, the first registration response includes registration feedback information (such as the terminal's default device ID, security certificate, etc.) and inventory results (such as EPC, third-party custom identity, etc.).

[0466] In an optional solution, the content in the first registration request can be encapsulated in a NAS Msg in the NGAP / NGAP-like Msg in whole or in part, and the first registration response Registration Response returned by the terminal can also be encapsulated in a NAS Msg in whole or in part, such as the second identifier, Operator ID, credential, etc. in the first registration response, which are encapsulated in the NAS Msg. The content in the NAS Msg is invisible to the access network device (such as the RA N reader). The inventory result (such as EPC) reported by the terminal can be included in the NAS Msg or encapsulated in the container of the NAS Msg. The AMF / AIoTF cannot see the container content of the NAS Msg, that is, the core network cannot analyze the inventory result reported by the terminal, ensuring the security and privacy of the data in the core network transmission process. Whether the content is encapsulated in the NAS Msg or not, and other possible encapsulation methods, can be set according to the scene needs.

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

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

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

[0470] Step S1113: The core network device determines the target certificate holder according to the first registration response.

[0471] For example, the target certificate holder is determined according to the Operator ID and / or Group ID obtained from the default device ID contained in the first registration response.

[0472] Step S1114: The core network device and the certificate holder perform device identity authentication using the second identifier and the security certificate.

[0473] For example, the second identifier (such as EPC) can be used as a username. For example, once the authentication is successful, the 5GC (or joint AF) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0474] The newly generated device ID will be used between the core network (for example, 5GC) and the terminal (such as AIoT device).

[0475] Step S1115: The core network device stores the newly generated device ID, the second identifier, and the registration state for the terminal in the core network.

[0476] Wherein, after the registration, the registration status here is "registered", the information to be stored can include other information in addition to the terminal newly generated device ID, the second identifier, the registration status, for example, the inventory result (such as EPC), RAN ID, etc., and is stored to the core network, which can be specifically stored in the UDM, AMF or AIoTF or other network elements or functions in the core network.

[0477] For example, taking the new device ID of the terminal as an index, the new device ID, the second identifier, the registration status (registered), the EPC (if the device reports the EPC), the RAN ID (if the RAN reader receives the indi_reader indication and feeds back the RAN ID), the AMF ID (if the AMF or AIoTF receives the indi_AMF indication and feeds back the AMF ID) and the like are stored in the UDM, AMF, AIoTF to construct the device context information.

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

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

[0480] In the above manner, the terminal can be registered in the core network; the registration principles of other terminals are the same.

[0481] The details of this part of the registration can also refer to steps 7-11 in the method flow shown in FIG. 6.

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

[0483] It can be understood that the core network device can know the registration status of the terminal, such as registered, and the inventory result of the terminal, such as the EPC of the terminal, from the first registration response.

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

[0485] That is, the core network device needs to convert the first registration response into the second inventory response, which can include the inventory result, such as the EPC of the terminal and the like. It can also include Transaction ID and other information.

[0486] Step S1118: The NEF receives the second inventory response.

[0487] Step S1119: The NEF sends a second inventory response to the AF.

[0488] Step S1120: The AF receives the second inventory response.

[0489] The AF can obtain the inventory result of the terminal, such as the EPC information of the terminal, according to the second inventory response.

[0490] Up to now, the AF has completed the inventory of one or more terminals.

[0491] It should be noted that in the above method flow, the operation of converting the second inventory request into the first registration request is completed by the core network device (such as AMF / AIoTF), and in fact, this conversion can also be completed by the NEF, for example, the NEF receives the second inventory request, identifies the unregistered terminal, and generates the first registration request according to the information of the unregistered terminal and the second inventory request, and then sends the first registration request to the AMF / AIoTF. In short, which network element generates the first registration request according to the second inventory request and the information of the unregistered terminal can be set according to the specific scene and actual needs, which is not limited here.

[0492] Of course, even in some optional schemes, the NEF does not need to convert the second inventory request into the first registration request after receiving the second inventory request, and 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.

[0493] Further, in an optional scheme, after the AMF / AIoTF receives the second inventory request and obtains the registration state information of the terminal from the UDM, if it is found that among the terminals that need to be inventoried in the second inventory request, a part of the terminals have completed network registration and another part of the terminals have not completed registration, then for the part of the terminals that have completed registration, the AMF / AIoTF sends a third inventory request to the access network device, the third inventory request includes the information of the terminals that need to be inventoried and have been registered, and the message format of the third inventory request is an inventory request (Inventory Request).

[0494] The third inventory request includes information of the registered terminal that needs to be inventoried. Specifically, the third inventory request includes a list of device information of one or more registered terminals that need to be inventoried, such as a list of device identifiers (e.g., a list of TIDs). Alternatively, the third inventory request includes area information, which indicates that the terminals in the corresponding area belong to the terminals that need to be inventoried. Of course, other ways 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. Optionally, the third inventory request can also include an inventory strategy, which is used to indicate related requirements or rules of the inventory, such as inventory frequency, inventory period, and the like.

[0495] For the inventory process of the registered terminal that needs to be inventoried, the inventory process shown in FIG. 7 can be referred to, which will not be described here. It should be noted that the inventory result in the third inventory response to the third inventory request received by the AMF / AIoTF can be aggregated with the inventory result in the first registration response received by the AMF / AIoTF to obtain the inventory result of all terminals involved in the second inventory request, and the first inventory response is generated according to the inventory result of all terminals and then fed back to the AF.

[0496] It should be noted that in the above method process, the operation of generating the third inventory request according to the second inventory request is completed by the AMF / AIoTF. In fact, this conversion can also be completed by other devices, such as the NEF receiving the second inventory request, identifying the registered terminal, and generating the third inventory request according to the information of the registered terminal and the second inventory request, and then sending the third inventory request to the AMF / AIoTF. In summary, whether the network element generates the third inventory request according to the second inventory request and the information of the registered terminal can be set according to the specific scene and actual needs, which is not limited here.

[0497] In the method shown in FIG. 11A, when the device has an inventory requirement, the second inventory request sent by the AF explicitly indicates that the terminal needs to be inventoried. After receiving the second inventory request, if it is found that the terminal has not been registered, the first registration request is generated according to the second inventory request, and then sent to the subsequent node. The first registration request can synchronously trigger the registration process and the inventory process, so as to complete the network registration and the inventory synchronously, save the identity verification step of the terminal after the core network receives the inventory result, reduce the number of signaling in the network and the number of terminal reporting times, improve the terminal energy saving efficiency, and reduce the core network processing overhead.

[0498] Please refer to FIG. 11B, which is a flow diagram of a communication method provided in the embodiments of the present application. The communication method can be implemented based on the architecture shown in FIG. 1 or other architectures, and the topology relied on can be any of the topologies shown in FIGS. 2-5 or other topologies. In this way, the AF initiating the inventory request does not perceive or judge whether the terminal has registered to the network, whether the terminal has been registered, how to register, etc. The terminal registration is responsible by the core network element. The method includes but is not limited to the following steps:

[0499] Step S1161: The AF sends a second inventory request to the NEF.

[0500] The second inventory request includes the information of the terminal to be inventoried. The message format of the second inventory request is an inventory request (Inventory Request). The terminal can be an Internet of Things device (such as an AIoT device) or other types of devices.

[0501] The second inventory request includes the information of the terminal to be inventoried. Specifically, the second inventory request includes a device information list of one or more terminals to be inventoried, such as a second identifier list (such as an EPC list or a local identifier defined by a third-party AF). Alternatively, the second inventory request includes area information, which indicates that the terminals in the corresponding area belong to the terminals to be inventoried. Of course, other ways 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.

[0502] Optionally, the second inventory request can also include other information, such as AF information (such as an AF identifier). The AF identifier (AF ID) can be used to identify the AF managing the terminals to be inventoried.

[0503] The second inventory request can further include third information indicating information of an access network device (e.g., a RAN) and / or a core network device (e.g., an AMF) that provides services for the terminal to be registered. For example, the third information includes a reader identifier indi_reader to indicate information of a RAN reader (e.g., a RAN ID or a UE ID with a timestamp, for an AF or other network element to update information of a reader RAN associated with the terminal in time), and the third information includes an AMF identifier indi_AMF to indicate information of an AMF, such as an AMF ID, which can have multiple possibilities, such as a globally unique AMF identifier (GUAMI), or a self-defined AMF name for network management and operation scenarios, to facilitate an administrator to identify and manage different AMF instances. The AMF Name can include geographic location information (e.g., “AMF-NewYork”) or a functional description (e.g., “AMF-HighCapacity”). It can also be a network function instance identifier (NF Instance ID) for uniquely identifying each network function instance in the 5G core network, including an AMF, which can be assigned and managed by a network function registration function (NRF). Of course, the third information can indicate information of other network elements in addition to the access network device or the AMF, and the principle is the same as that of the AMF and the RAN.

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

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

[0506] Identity verification is performed on the AF to determine whether to allow it to access the 5G system (or other communication system).

[0507] Authorization check: Determine whether to allow the AF to initiate the inventory process.

[0508] Convert the location information into a TA list, and the NEF selects corresponding core network devices (e.g., AMF, AIoTF, etc.) according to the TA list, and then sends corresponding messages, such as a second inventory request, to the corresponding core network devices.

[0509] Optionally, the NEF sends a second inventory request to the core network device after identity verification of the AF is passed. Optionally, the second inventory request can include a TA list, AF information (e.g., an AF ID), and the like.

[0510] It should be noted that before the NEF issues the second inventory request, other related operations can also be performed, such as performing other condition judgments, and in the case that other conditions are met, the second inventory request is issued.

[0511] Step S1163: The NEF sends a second inventory request to the core network device.

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

[0513] Step S1164: The core network device receives the second inventory request.

[0514] The core network device queries the information of the terminal corresponding to each second identifier in the second identifier list from the UDM according to the second identifier list (such as the EPC list or the local identifier defined by the third-party AF), including the registration state of the terminal, the information of the AF to which the terminal belongs (such as the AF identifier), the TID, the EPC, or the local identifier defined by the AF, etc. If the information of the corresponding terminal cannot be queried in the UDM through the second identifier, it is considered that the terminal has not been registered in the core network (for example, 5G C), and if the information of the corresponding terminal is queried in the UDM through the second identifier, it is considered that the terminal has been registered in the core network (for example, 5G C), and then a second identifier list of registered terminals and a second identifier list of unregistered terminals are generated, such as unregistered_list (X, Y, Z).

[0515] Among them, for the second identifier list of registered terminals, the core network device has queried various information of these devices from the UDM based on the second identifier, so the related information and the corresponding second identifier can be associated as the inventory result of the corresponding device, for example, the TID and the second identifier are associated and served as the inventory result of the corresponding terminal. That is, all or part of the information in the second identifier list of the registered terminal can be used as the inventory result of each terminal involved in the second identifier list.

[0516] The unregistered terminal second identifier list unregistered_list (X, Y, Z) is generated by the core network device according to the unregistered terminal second identifier list unregistered_list, and the third registration request includes: transaction number (Transaction ID), unregistered terminal second identifier list (such as EPC list or third party AF self-defined local identifier list), AF information (such as AF ID, optional, if the second identifier is the AF self-defined local identifier, the AF ID needs to be combined with the local identifier to identify the globally unique terminal), inventory strategy (such as inventory frequency and inventory period) and the like. The message format of the third registration request is a registration request (Registration Request).

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

[0518] Specifically, the core network device can select the corresponding access network device RAN according to the TA list, for example, NG-RAN reader, and then send the third registration request to the NG-RAN reader.

[0519] Step S1166: The access network device receives the third registration request.

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

[0521] The access network device can send the third registration request through broadcast or unicast.

[0522] Step S1168: The terminal receives the third registration request.

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

[0524] On the one hand, the terminal can know that network registration is needed according to the third registration request. Specifically, the first registration request contains the second identifier list (such as EPC list or third party self-defined identifier list), AF information (such as AF ID). The terminal judges whether the terminal information matches the second identifier list and AF information (AF ID) in the third registration request, if matched, the terminal uses the locally stored default device ID, first identifier and security certificate to execute the registration process after activation, including sending the default device ID, first identifier (such as TID) and security certificate to the access network device (such as NG-RAN reader) registration message, which can be considered as the registration feedback information returned by the terminal to the access network device. Therefore, the third registration response includes the registration feedback information (for example, terminal default device ID, security certificate, first identifier (such as TID) and the like).

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

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

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

[0528] Step S1173: The core network device determines the target certificate holder according to the third registration response.

[0529] For example, the target certificate holder is determined according to the Operator ID and / or Group ID obtained from the default device ID contained in the third registration response.

[0530] Step S1174: The core network device performs device identity authentication with the certificate holder using the first identity and the security certificate.

[0531] The first identity (such as TID) can be used as a username. For example, in the case of 5GC, once the authentication is successful, the 5GC (or joint AF) will generate a unique and non-zero Instance ID (a component of the device ID) for the device.

[0532] The newly generated device ID will be used between the core network (such as 5GC) and the terminal (such as AIoT device).

[0533] Step S1175: The core network device stores the newly generated device ID for the terminal, the first identity, and the registration status in the core network.

[0534] After registration, the registration status here is "registered", and the information to be stored can be stored in network elements or functions such as UDM, AMF, or AIoTF in the core network.

[0535] For example, the new device ID, the first identity, the registration status (registered), etc. are stored in UDM, AMF, AIoTF with the new device ID of the terminal as the index, to construct device context information.

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

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

[0538] In this way, the terminal can be registered in the core network; the registration principle of other terminals is the same.

[0539] In the embodiment of the present application, the third registration request sent by the core network device carries the second identifier (such as EPC), and the third registration response received subsequently carries the first identifier (such as TID), so that the core network device can match the second identifier (such as EPC) corresponding to the first identifier (such as TID) through the pre-configured mechanism after obtaining the first identifier (such as TID), and then take the matched EPC as the inventory result of the terminal corresponding to the first identifier (such as TID).

[0540] The details of this part of registration can also refer to steps 7-11 in the method flow shown in FIG. 6.

[0541] Step S1177: The core network device sends a second inventory response to the NEF.

[0542] It can be understood that the core network device can learn the registration state of the terminal from the third registration response, such as registered, and match the inventory result of the terminal through the first identifier in the third registration response, such as the second identifier (such as EPC). Therefore, the core network device can generate a second inventory response, which includes the inventory result of the terminal.

[0543] It should be noted that as mentioned earlier, after the core network device receives the second inventory request, it will directly query the inventory result of the registered terminal, and for the unregistered terminal, it will achieve new registration of this part of the terminal by sending a third registration request and accepting a third registration response, and the inventory result of the newly registered terminal can be matched through the first identifier in the third registration response. Therefore, the inventory result of the terminal involved in the second inventory request can be obtained, and therefore the second inventory response here can include the inventory result of each terminal involved in the second inventory request.

[0544] Optionally, the second inventory response can also only include the inventory result of the newly registered terminal, and the inventory result of the originally registered terminal can be sent through another inventory response, and the specific implementation manner is not limited here.

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

[0546] That is, the core network device needs to convert the third registration response into a second inventory response, which can include the inventory result, such as the EPC and other information of the terminal. It can also include Transaction ID and other information.

[0547] Step S1178: The NEF receives the second inventory response.

[0548] Step S1179: The NEF sends a second inventory response to the AF.

[0549] Step S1180: The AF receives the second inventory response.

[0550] The AF can obtain the inventory result of the terminal, such as the EPC information of the terminal, according to the second inventory response.

[0551] Up to now, the AF has completed the inventory of one or more terminals.

[0552] It should be noted that in the above method process, the operation of converting the second inventory request into the third registration request is completed by the core network device (such as AMF / AIoTF), and in fact, this conversion can also be completed by the NEF, for example, the NEF receives the second inventory request, identifies the unregistered terminal, and generates the third registration request according to the information of the unregistered terminal and the second inventory request, and then sends the third registration request to the AMF / AIoTF. In short, which network element generates the third registration request according to the second inventory request and the information of the unregistered terminal can be set according to the specific scene and actual needs, which is not limited here.

[0553] Of course, even in some optional schemes, the NEF does not need to convert the second inventory request into the third registration request after receiving the second inventory request, and 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.

[0554] In the method shown in FIG. 11B, when the terminal has an inventory requirement, the second inventory request sent by the AF explicitly informs the terminal that it needs to be inventoried. Other network elements receiving the second inventory request can directly query the corresponding inventory result of the terminal if the terminal is found to be registered, or generate a third registration request according to the second inventory request and send it to the subsequent node if the terminal is found to be unregistered. The third registration request can trigger the registration process, and the corresponding inventory result of the terminal is queried after registration. In this scheme, the inventory result of the terminal is directly queried from the corresponding storage location, rather than being reported by the terminal, which reduces the number of network signaling and the number of terminal reports, improves the terminal energy efficiency, and reduces the core network processing overhead.

[0555] Please refer to FIG. 12, which is a flow diagram of a communication method provided in the embodiments of the present application. The communication method can be implemented based on the architecture shown in FIG. 1 or other architectures, and the topology relied on can be any of the topologies shown in FIGS. 2-5 or other topologies. In the method, if the terminal is successfully registered, it can store its own registration state in a local non-volatile storage area (i.e., which can be saved even after the terminal is powered off) or implicitly identify its own registration state through some means. The method includes but is not limited to the following steps:

[0556] Step S1201: The AF sends a second inventory request to the NEF.

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

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

[0559] After the NEF receives the second inventory request, it performs the following operations:

[0560] Verifies the identity of the AF and decides whether to allow it to access the 5G system.

[0561] Checks authorization: determines whether to allow the AF to initiate the inventory process.

[0562] Converts the location information into a TA list, and the NEF will select the corresponding core network device (e.g., AMF, AIoTF, etc.) according to the TA list, and will subsequently send the second inventory request to the corresponding core network device.

[0563] Optionally, the NEF sends the second inventory request after the identity verification of the AF is passed. Optionally, the second inventory request can include the TA list.

[0564] It should be noted that before the NEF sends the second inventory request, it can also perform other related operations, such as performing other conditional judgments, and sending the second inventory request under the condition that other conditions are met.

[0565] It should be noted that the NEF can parse the second inventory request to obtain the content indicated by the second inventory request, or it can not parse the second inventory request and only transmit the second inventory request transparently. Which case is pre-configured as needed.

[0566] Step S1203: The NEF sends the second inventory request to the core network device.

[0567] The second inventory request can carry a second identification list (such as an EPC list or a local identification list defined by a third-party AF), a Transaction ID, a TA list, AF information (such as an AF ID), and the like.

[0568] Step S1204: The core network device receives the second inventory request.

[0569] The core network device selects an access network device according to the TA list. For example, the access network device can be an NG-RAN reader / writer.

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

[0571] The second inventory request includes a second identification list and the like.

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

[0573] Step S1207: The access network device sends the second inventory request.

[0574] The access network device can send the second inventory request in a unicast or broadcast manner, and the second inventory request contains a second identification list, AF information, and the like.

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

[0576] The terminal determines whether its device information matches the second identification list and AF information (if any) in the second inventory request, and determines whether it has completed network registration according to stored information or obtainable information.

[0577] The following execution flow has several possible cases.

[0578] Case 1: An unregistered terminal cannot respond to other service requests in addition to a registration request, i.e., cannot respond to the second inventory request.

[0579] Method 1: As shown in FIG. 13, after receiving the second inventory request, the terminal first determines its registration state. If it is not registered, it remains silent, i.e., does not respond to the second inventory request. If it is registered, it determines whether its device information (such as a device ID) matches the second identification (such as an EPC) list and AF information (if any) in the second inventory request. If they match, the terminal needs to respond to the second inventory request, i.e., performs step S1209, which is to send a second inventory response. If they do not match, the terminal remains silent, i.e., does not respond to the second inventory request. In this method, the registration of the terminal must be triggered by a registration request from the network side.

[0580] Manner 2: As shown in FIG. 14, after receiving the second inventory request, the terminal first judges the registration state of the terminal, if the terminal is registered, judges whether the device information (such as device ID) of the terminal matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request, if yes, the terminal needs to respond to the second inventory request, that is, execute the subsequent step S1209, if no, the terminal remains silent, that is, does not respond to the second inventory request, if the terminal is not registered, then judges whether the device information (such as device ID) of the terminal matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request, if no, the terminal remains silent, if yes, the terminal reports to the network side that the terminal is in an unregistered state, requests the network side to issue a registration request, and after the terminal receives the registration request, interacts with the related network element to complete the registration, and in the case of completing the registration, responds to the second inventory request.

[0581] Case two, the unregistered device can respond to other service requests except the registration request.

[0582] Manner 3: As shown in FIG. 15, after receiving the second inventory request, the terminal first judges whether the device information (such as device ID) of the terminal matches the second identifier (such as EPC) list and AF information (if any) in the second inventory request, that is, judges whether the terminal is the terminal of the second inventory request, if no, the terminal remains silent, if yes, judges the registration state of the terminal, if the terminal is registered, responds to the second inventory request, if the terminal is not registered, directly returns a registration response, which is used for the access network device, the core network device and the like to complete the registration of the terminal, and after completing the registration, responds to the second inventory request. Optionally, the registration response and the response to the second inventory request can be fed back in one message, or can be fed back through two different messages respectively.

[0583] In the embodiment of the application, the manner in which the terminal responds to the second inventory request can be sending a second inventory response to the access network device, and the second inventory response contains the second identifier of the terminal, such as the electronic product code (EPC) of the device or the local identifier defined by the third party AF.

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

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

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

[0587] Step S1212: The core network device receives the second inventory response.

[0588] Step S1213: The core network device interacts with the AUSF and the UDM and performs identity verification on the terminal according to the information fed back by the terminal.

[0589] Optionally, the core network device can store the inventory result (such as EPC) of the terminal in the UDM and the core network.

[0590] After the identity verification is passed, subsequent steps can be continued.

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

[0592] Step S1215: The NEF receives the second inventory response.

[0593] Step S1216: The NEF sends the second inventory response to the AF.

[0594] Step S1217: The AF receives the second inventory response.

[0595] It can be understood that the AF can obtain the inventory result (such as EPC) of the terminal from the second inventory response.

[0596] Optionally, if the third information is also carried in the second inventory request, the second inventory response fed back can also include the information of the access network device and / or the AMF.

[0597] In the method shown in FIG. 12, when the device has an inventory requirement, the second inventory request sent by the AF explicitly informs the terminal to be inventoried. After the 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, so as to trigger the registration process, and feeds back the inventory result after the registration is completed. Or in the case of finding that it is not registered, directly start the registration process, and feed back the inventory result, reduce the number of network signaling and the number of terminal reporting times, improve the terminal energy saving efficiency, and reduce the core network processing overhead.

[0598] It should be understood that each step in the above method embodiments provided by the present application can be completed by integrated logic circuits of hardware in the processor or instructions in the form of software. The method steps disclosed in combination with the embodiments of the present application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor.

[0599] The present application divides the functional modules of the communication device according to the above method embodiments. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be realized in the form of hardware or in the form of a software functional module. It should be noted that the division of the modules in the present application is illustrative, and is only a logical functional division. In actual implementation, another division method can be used. The communication device of the embodiment of the present application will be described in detail below with reference to FIG. 16.

[0600] FIG. 16 is a structural schematic diagram of a communication device according to an embodiment of the present application. As shown in FIG. 16, the communication device includes a processing module 1601 and a transceiver module 1602. The transceiver module 1602 can realize corresponding communication functions. For example, the transceiver module 1602 can also be referred to as an interface, a communication interface, or a communication module, etc. 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 a control logic or can perform corresponding operations under the control of the processing module 1601. In some embodiments of the present application, the communication device can be used to perform the actions performed by the sending end in the above method embodiments. For example, the sending end can be a device itself or a chip or a functional module that can be configured in the device, etc. The transceiver module 1602 is used to perform the operations related to information transmission and reception in the above method embodiments. The processing module 1601 is used to perform the operations related to data processing in the above method embodiments (such as generating a first registration request, generating a first inventory response, etc.). The processing module 1601 can perform corresponding operations by calling a computer program or by using a corresponding hardware circuit. The transceiver module 1602 can independently perform the transmission and reception operations or can perform the corresponding transmission and reception operations under the control of the processing module 1601.

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

[0602] sending a first request message to a network device, wherein the first request message includes first information and second information, the first information is related to terminal network registration, and the second information is related to terminal inventory;

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

[0604] In this implementation, the first request message can be a message in the format of a registration request (Registration Request), i.e. the existing registration request is enhanced to carry the information related to the inventory at the same time, the first request message can also be a message in the format of an inventory request (Inventory Request), i.e. the existing inventory request is enhanced to carry the information related to the network registration at the same time, the first request message can also be a message in other formats, which are not limited here. In addition, the registration feedback information of the receiving terminal and the inventory result are generally sent after being relayed or processed by other devices. For the registration feedback information and the inventory result of the terminal, the registration feedback information and the inventory result here can be sent in one message, for example, both are encapsulated in a registration response (Registration Response) and sent, or both are encapsulated in an inventory response (Inventory Response) and sent, or are encapsulated in other types of messages and sent. In addition, the registration feedback information and the inventory result can also be sent in different messages respectively, for example, the registration feedback information is encapsulated in a registration response (Registration Response) and sent, and the inventory result is encapsulated in an inventory response (Inventory Response) and sent.

[0605] In addition, the information related to the network registration of the terminal can include one or more of the following information: information triggering the network registration, all or part of the information to be used in the registration process, information providing the timing or conditions for the network registration, etc.; the information related to the inventory of the terminal can include one or more of the following information: information triggering the inventory, all or part of the information to be used in the inventory process, information providing the timing or conditions for the inventory, etc.

[0606] It can be understood that the first request message includes both the information related to the network registration and the information related to the inventory, so that the network registration process and the inventory process can be initiated through the first registration request, and the subsequent link can combine and execute the registration and inventory processes, so that the signaling and interaction process can be saved, and the inventory efficiency can be improved.

[0607] In a possible implementation, the first request message is a first registration request, the first information includes information of a terminal to be registered, and the second information is used to instruct to inventory the terminal to be registered.

[0608] In this implementation, the first request message specifically exists in the form of a registration request (Registration Request), and correspondingly, the first information includes information of the terminals to be registered, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information is an indication that these terminals to be registered also need to be inventoried. The second information can be an inventory indicator indi_inventory. In one implementation, one inventory indicator indi_inventory corresponds to all the terminals to be registered, to indicate that these terminals all need to be inventoried. In another implementation, each terminal 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.

[0609] In yet another possible implementation, the first registration request further includes third information, which is used to indicate information of an access network device and / or a core network device that provides service for the terminals to be registered. In this implementation, the AF can also need to know information of an access network device, an AMF, and other devices corresponding to the terminals to be registered and inventoried, and therefore, the third information can be used to indicate the relevant network elements to feed back this information.

[0610] In yet another possible implementation, in terms of receiving the registration feedback information and the inventory result of the terminal sent by the receiving network device, the transceiver module 1602 is specifically configured to receive a first registration response sent by the receiving network device, where the first registration response includes the registration feedback information and the inventory result of the terminal. This implementation mainly embodies that if the first request message sent by the AF in the foregoing is a first registration request, that is, a message in the format of a registration request (Registration Request), then the feedback finally received can be a message in the format of a corresponding registration response (Registration Response), that is, a first registration response.

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

[0612] In this implementation, the first request message specifically exists in the form of an inventory request (Inventory Request), and correspondingly, the second information includes information of the terminals that need to be inventoried, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the first information includes a list of the terminals that need to be inventoried and need to be registered. Of course, the first information can also not exist in the form of a list, as long as it can indicate the terminals that need to be inventoried and also need to be registered (that is, not registered).

[0613] In a further possible implementation, in the method for receiving the registration feedback information and the inventory result of the terminal sent by the network device, the transceiver module 1602 is specifically configured to:

[0614] receive a first inventory response sent by the network device, the first inventory response comprising the registration feedback information and the inventory result of the terminal.

[0615] This implementation mainly embodies that if the first request message sent by the preceding AF is a first inventory request, i.e., a message in the format of an inventory request (Inventory Request), then the feedback finally received can be a message in the format of a corresponding inventory response (Inventory Response), i.e., a first inventory response.

[0616] In a further possible implementation, the first request message is a second registration request, the first information comprises information of a terminal to be registered, and the second information comprises a waiting indication, the waiting indication being used to indicate that the second registration request and a service associated with the second registration request are to be processed after a first time. The transceiver module 1602 is further configured 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 service associated with the second registration request.

[0617] In this implementation, the first request message specifically exists in the form of a registration request (Registration Request), and correspondingly, the first information comprises information of a terminal to be registered, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information comprises a waiting indication, which is used to indicate that the registration request and a subsequent associated service are to be processed in combination. For example, when the inventory request is set as an associated service of the registration request, a network element receiving the second registration request can process the second registration request and a subsequent second inventory request in combination, i.e., subsequently start registration and inventory in combination.

[0618] In a further possible implementation, in the method for receiving the registration feedback information and the inventory result of the terminal sent by the network device, the transceiver module 1602 is specifically configured to:

[0619] receive a second registration response sent by the network device, wherein the second registration response comprises the registration feedback information of the terminal;

[0620] receive a second inventory response sent by the network device, wherein the second inventory response comprises the inventory result of the terminal.

[0621] The implementation mainly embodies that if the first request message sent by the 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, the feedback finally received can include a second registration response, i.e., a message in the format of a Registration Response, corresponding to the second registration request, and a second inventory response, i.e., a message in the format of an Inventory Response, corresponding to the second inventory request.

[0622] In yet another possible implementation, the inventory result of the terminal includes one or more of the following information: an electronic product code (such as an EPC) of the terminal, time information of performing the inventory, and the like.

[0623] In yet another possible implementation, the registration feedback information includes one or more of the following information: a parameter to be used for registration, a registration state, and the like.

[0624] In some other embodiments of the present application, the communication apparatus shown in FIG. 16 can be a network device or a device of a network device, and the processing module 1601 and the transceiver module 1602 in the communication apparatus can perform the following operations, respectively:

[0625] The transceiver module 1602 receives a first request message sent by the AF, where the first request message includes first information and second information, the first information is information related to network registration of a terminal, and the second information is information related to inventory of the terminal;

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

[0627] The transceiver module 1602 receives registration feedback information and an inventory result sent by the terminal;

[0628] The transceiver module 1602 sends the registration feedback information and the inventory result of the terminal to the AF.

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

[0630] In an optional implementation, the network device is a NEF, and the above method specifically includes: the NEF receives the first request message sent by the AF, the NEF sends the first request message or the second request message to a core network device, and the NEF receives the registration feedback information and the inventory result of the terminal sent by the core network device; and the NEF sends the registration feedback information and the inventory result of the terminal to the AF.

[0631] In another optional implementation, the network device is a core network device, and the above method specifically includes: the core network device receives the first request message sent by the NEF, the core network device sends the first request message or the second request message to an access network device, and the core network device receives the registration feedback information and the inventory result of the terminal sent by the access network device; and the core network device sends the registration feedback information and the inventory result of the terminal to the NEF.

[0632] In another optional implementation, the network device is an access network device, and the above method specifically includes: the access network device receives the first request message sent by the core network device, the access network device sends the first request message or the second request message to a terminal, and the access network device receives the registration feedback information and the inventory result of the terminal sent by the terminal; and the access network device sends the registration feedback information and the inventory result of the terminal to the core network device.

[0633] Of course, there are other optional implementations, which are not listed here.

[0634] The first request message can be a registration request (Registration Request) format message, i.e., the existing registration request is enhanced to simultaneously carry the information related to the inventory, the first request message can also be an inventory request (Inventory Request) format message, i.e., the existing inventory request is enhanced to simultaneously carry the information related to the network registration, the first request message can also be a message of other formats, which is not limited here. Further, 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 the first registration request, the first registration request can be continued to be sent to the next network element; after receiving the first request message, the network device can also convert the first registration request into a message of other types and then send it to the next network element, for example, if the first request message is the first inventory request, the network device can generate a first registration request (i.e., the second request message described above) according to the first inventory request, and then send the first registration request (i.e., the second request message described above) to the next network element.

[0635] In addition, the received registration feedback information and inventory result of the terminal are generally sent after being transferred or processed by other devices. For the registration feedback information and inventory result of the terminal, the registration feedback information and inventory result here can be sent in one message, for example, both are encapsulated in a registration response (Registration Response) and sent, or both are encapsulated in an inventory response (Inventory Response) and sent, or are encapsulated in a message of other types and sent. In addition, the registration feedback information and inventory result can also be sent in different messages respectively, for example, the registration feedback information is encapsulated in a registration response (Registration Response) and sent, and the inventory result is encapsulated in an inventory response (Inventory Response) and sent. Similarly, the registration feedback information and inventory result of the terminal sent by the network device can be encapsulated in one message or two messages of different types, and the principle can be referred to the related description above. In addition, the registration feedback information and inventory result of the terminal received by the network device and the registration feedback information and inventory result of the terminal sent by the network device can be encapsulated in messages of different types, for example, the registration feedback information and inventory result of the terminal received by the network device are encapsulated in one registration response (Registration Response), and the registration feedback information and inventory result of the terminal received by the network device sent by the network device are encapsulated in one inventory response (Inventory Response), which can be set according to the needs of the scene.

[0636] In addition, the terminal network registration related information can include one or more of the following information: information triggering network registration, all or part of information to be used in the registration process, information providing timing or conditions for network registration, and the like; the terminal inventory related information can include one or more of the following information: information triggering inventory, all or part of information to be used in the inventory process, information providing timing or conditions for inventory, and the like.

[0637] It can be understood that the first request message includes both network registration related information and inventory related information, so that the network registration process and the inventory process can be initiated through the first registration request, and the subsequent link can combine and perform the registration and inventory processes, thereby saving signaling and interaction processes and improving inventory efficiency.

[0638] In a possible implementation manner, the first request message is a first registration request, the first information includes information of a terminal to be registered, and the second information is used to indicate that the terminal to be registered is subjected to inventory.

[0639] The processing module 1601 registers the terminal to the core network according to the registration feedback information.

[0640] It can be understood that the registration feedback information includes some parameters required for registration, for example, the RAN or the AMF or other core network elements register the terminal to the core network according to the registration feedback information.

[0641] In another possible implementation manner, the first request message is a first registration request, the first information includes information of a terminal to be registered, and the second information is used to indicate that the terminal to be registered is subjected to inventory.

[0642] In this implementation manner, the first request message specifically exists in the form of a registration request (Registration Request), and correspondingly, the first information includes information of a terminal to be registered, for example, a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information is used to indicate that these terminals to be registered also need to be subjected to inventory. The second information can be an inventory indicator indi_inventory. In one implementation, all the terminals to be registered correspond to one inventory indicator indi_inventory, to indicate that these terminals need to be subjected to inventory. In another implementation, each terminal to be registered and subjected to inventory corresponds to one inventory indicator indi_inventory, to indicate that the corresponding terminal needs to be subjected to inventory.

[0643] In a further possible implementation, the first registration request further comprises third information, the third information being used to indicate information of the access network device and / or the core network device that provides service for the terminal to be registered. In this implementation, the network device can also need to know the information of the access network device, AMF, or other device corresponding to the terminal to be registered and inventoried, and thus the relevant network element can be instructed to feedback the information through the third information.

[0644] In a further possible implementation,

[0645] The receiving of the registration feedback information and the inventory result sent by the terminal is specifically implemented by the transceiver module 1602 in the following manner:

[0646] The first registration response sent by the terminal is received, and the first registration response comprises the registration feedback information and the inventory result of the terminal.

[0647] The sending of the registration feedback information and the inventory result of the terminal to the AF is specifically implemented by the transceiver module 1602 in the following manner:

[0648] The first registration response or a registration response generated according to the first registration response is sent to the AF.

[0649] This implementation mainly embodies that if the first request message sent by the preceding network device is the first registration request, that is, a message in the format of a registration request (Registration Request), the feedback finally received can be a message in the format of a corresponding registration response (Registration Response), that is, the first registration response. The first registration response can be further fed back to other network elements (for example, the AF). It should be noted that, generally, if a network device receives a request from a certain network element, the network device needs to subsequently send a corresponding response to the network element, and if the network device sends a request to a certain network element, the network device will subsequently receive a response about the request from the network element. For example, assuming that the network device is a NEF, the NEF receives a first registration request from the AF, the NEF sends the first registration request to the AMF, the NEF receives a first registration response from the AMF, and the NEF sends the first registration response to the AF. The principle is the same when the network device is other network elements.

[0650] In a further possible implementation, the first request message is a first inventory request, the second information comprises information of the terminal that needs to be inventoried, and the first information comprises a list of the terminal that needs to be inventoried and needs to be registered in the network; and the second request message is a first registration request.

[0651] In this implementation, the first request message specifically takes the form of an inventory request, and correspondingly, the second information includes information of terminals that need to be inventoried, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the first information includes a list of terminals that need to be inventoried and registered, and of course, the list can not be in the form of a list, as long as it can indicate the terminals that need to be registered (i.e., not registered) among the terminals that need to be inventoried. After receiving the first inventory request, the network device generates a first registration request and sends the first registration request to the next network node.

[0652] In another possible implementation, the information of the terminal that needs to be inventoried includes one or more of a terminal identifier list, a terminal screening condition, and a group identifier.

[0653] In another possible implementation,

[0654] The receiving of the registration feedback information and the inventory result sent by the terminal is specifically that the transceiver 1602 is configured to:

[0655] The receiving of the first registration response sent by the terminal is specifically that the transceiver 1602 is configured to:

[0656] The sending of the registration feedback information and the inventory result of the terminal to the AF is specifically that the transceiver 1602 is configured to:

[0657] The sending of the first inventory response or an inventory response generated according to the first inventory response to the AF is specifically that the transceiver 1602 is configured to:

[0658] This implementation mainly embodies that if the first inventory request is received by the preceding network and the first registration request is sent out, then the feedback received at last for the first registration request can be the first registration response, and the feedback sent out by the network device for the first inventory request can be the first inventory response.

[0659] In another possible implementation, the first request message is a second registration request, the first information includes information of a terminal to be registered, and the second information further includes a waiting indication, where the waiting indication is used to indicate that the second registration request and a service associated with the second registration request are to be processed after a first time, and the transceiver 1602 is further configured to receive a second inventory request sent by the AF, where the second inventory request is used to request to inventory a terminal, and the second inventory request belongs to the service associated with the second registration request.

[0660] In the implementation, the first request message is in the form of a registration request, and the first information includes information of the terminal to be registered, such as a device ID of the terminal, area information of an area where the terminal is located, and the like, and the second information includes a waiting indication, which is used to indicate that the registration request and the subsequent associated service are processed together, for example, when the inventory request is set as the associated service of the registration request, the network element can process the second registration request and the subsequently received second inventory request together after receiving the second registration request, that is, the registration and the inventory are started together subsequently.

[0661] In yet another possible implementation, the network device further includes:

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

[0663] In the implementation, the network device can temporarily not process the second registration request and the second inventory request together after receiving the two, but send them to a next network node for processing together.

[0664] In yet another possible implementation, in the receiving of the registration result and the inventory result sent by the terminal, the transceiver 1602 is specifically configured to:

[0665] receive a second registration response sent by the terminal, where the second registration response includes registration feedback information of the terminal;

[0666] receive a second inventory response sent by the terminal, where the second inventory response includes an inventory result of the terminal.

[0667] In the implementation, the registration result and the inventory result 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, and the inventory result is encapsulated in the second inventory response.

[0668] In yet another possible implementation, the network device further includes:

[0669] The transceiver 1602 generates a first registration request according to the second inventory request and the second registration request after a waiting time indicated by the waiting indication is reached, where the first registration request is used to request network registration and inventory of the terminal.

[0670] In the implementation, the network device processes the second registration request and the subsequently received second inventory request together, that is, the registration and the inventory are started together subsequently.

[0671] In yet another possible implementation, the receiving the registration feedback information and the inventory result sent by the terminal is specifically for:

[0672] receiving the first registration response sent by the terminal, wherein the registration response comprises the registration feedback information and the inventory result of the terminal.

[0673] In this implementation, since the network device processes the second registration request and the subsequently received second inventory request in combination, the feedback information received is the first registration response comprising the registration feedback information and the inventory result.

[0674] In addition to the embodiments of the present application, the communication apparatus shown in FIG. 16 may, for example, be a network device or a device in a network device, and the processing module 1601 and the transceiver module 1602 in the communication apparatus may perform the following operations, respectively:

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

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

[0677] The transceiver module 1602 receives the first registration response sent by the terminal, wherein the first registration response comprises the registration feedback information and the inventory result of the terminal;

[0678] The transceiver module 1602 sends the second inventory response to the terminal, wherein the second inventory response comprises the inventory result of the terminal.

[0679] In this implementation, the network device herein may 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 different second inventory requests, for example, a second inventory request sent through RAN may carry information added by RAN, and a second inventory request sent through NEF may carry information added by NEF. In addition, different types of network devices may receive different registration feedback information, for example, the registration feedback information received by RAN comprises some parameters for registration, and the registration feedback information received by AMF may comprise registration status (such as registered).

[0680] The network device receives which network element sends the second inventory request, and then needs to feed back the second inventory response to the network element for the second inventory request. The network device sends the first registration request to which network element, and then receives the first registration response from the network element for the first registration request.

[0681] In addition, the information related to the terminal network registration can include one or more of the following information: information triggering the network registration, all or part of the information to be used in the registration process, information providing the timing or condition for the network registration, and the like; the information related to the terminal inventory can include one or more of the following information: information triggering the inventory, all or part of the information to be used in the inventory process, information providing the timing or condition for the inventory, and the like.

[0682] It can be understood that the first registration request includes both the information related to the network registration and the information related to the inventory, so that the network registration process and the inventory process can be initiated through the first registration request, and then the subsequent link can combine and execute the registration and inventory processes, thereby saving the signaling and interaction process and improving the inventory efficiency.

[0683] Referring to FIG. 16, in some embodiments of the present application, the communication device shown in FIG. 16 can be a terminal or a device in the terminal, and the processing module 1601 and the transceiver module 1602 in the communication device can perform the following operations respectively:

[0684] The transceiver module 1602 receives the 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;

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

[0686] In this implementation, the information related to the terminal network registration can include one or more of the following information: information triggering the network registration, all or part of the information to be used in the registration process, information providing the timing or condition for the network registration, and the like; the information related to the terminal inventory can include one or more of the following information: information triggering the inventory, all or part of the information to be used in the inventory process, information providing the timing or condition for the inventory, and the like.

[0687] It can be understood that the first registration request simultaneously requests the network registration and the inventory, so that the network registration process and the inventory process can be initiated through the first registration request, and then the subsequent link can combine and execute the registration and inventory processes, thereby saving the signaling and interaction process and improving the inventory efficiency.

[0688] In a possible implementation, the sending of the registration feedback information and the inventory result to the network device is specifically: the transceiver module 1602 is configured to send a first registration response to the network device, wherein the first registration response comprises the registration feedback information and the inventory result.

[0689] In this implementation, the registration feedback information and the inventory result are contained in a message in a registration response (Registration Response) format, i.e., the first registration response.

[0690] In another embodiment of the present application, the communication apparatus shown in FIG. 16 can be a terminal or a device in a terminal, and the processing module 1601 and the transceiver module 1602 in the communication apparatus can perform the following operations, for example:

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

[0692] If the terminal is not registered to the core network, the transceiver module 1602 sends registration feedback information and an inventory result to the network device, or

[0693] If the terminal is not registered to the core network, the transceiver module 1602 sends a report message to the network device, wherein the report message is used to request a second registration request to be sent, and the second registration request is used to register the terminal to the network.

[0694] In this implementation, after receiving the second inventory request, the terminal judges whether it has been registered to the core network. If not, the terminal directly feeds back report information to request other network elements to initiate a network registration process, and feeds back a response to the second inventory request, e.g., a second inventory response, after registration, or directly feeds back information required for subsequent registration, so as to facilitate other network elements (e.g., the core network) to complete registration of the terminal in time, and feeds back a response to the second inventory request, e.g., a second inventory response, after registration. That is, in the inventory process, if the terminal is not registered, the terminal initiates a network registration process to facilitate smooth completion of the inventory.

[0695] In a possible implementation, the transceiver module 1602 is further configured to:

[0696] If the terminal is registered to the core network, the transceiver module 1602 sends a second inventory response to the network device, wherein the second inventory response comprises the inventory result.

[0697] In this implementation, if the terminal is registered after receiving the second inventory request, the terminal directly feeds back the inventory result.

[0698] The specific description of the transceiver module and the processing module in each of the above embodiments is only an example. For the specific function or executed steps of the transceiver module and the processing module, refer to the above method embodiments, which will not be described in detail here.

[0699] The communication device of the embodiment of the present application is introduced above. The possible product forms of the communication device are introduced below. Any product form with the function of the communication device in FIG. 16 falls within the protection scope of the embodiment of the present application.

[0700] The following introduction is only an example, which does not limit the product form of the communication device of the embodiment of the present application.

[0701] In a possible implementation, in the communication device shown in FIG. 16, 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 sending module and a receiving module, the sending module can be a transmitter, and the receiving module can be a receiver, and the sending module and the receiving module are integrated in one device, for example, a transceiver. In the embodiment of the present application, the processor and the transceiver can be coupled, etc. The connection mode of the processor and the transceiver is not limited in the embodiment of the present application. In the process of executing the above method, the process of sending information in the above method can be the process of outputting the above information by the processor. When the above information is output, the processor outputs the above information to the transceiver, so as to be transmitted by the transceiver. After the above information is output by the processor, it can also need to be processed, and then reaches the transceiver. Similarly, the process of receiving information in the above method can be the process of receiving the input above information by the processor. 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 can need to be processed, and then input to the processor.

[0702] As shown in FIG. 17, the communication apparatus 170 includes one or more processors 1720 and a transceiver 1710. The transceiver 1710 is configured to perform functions or steps implemented by the transceiving module 1602 shown in FIG. 16, and the processor 1720 is configured to perform functions or steps implemented by the processing module 1601 shown in FIG. 16. The transceiver 1710 can have processing logic built-in or can perform operations under control of the processor 1720. Optionally, the communication apparatus 170 can further include a memory 1730, which can store computer programs. The processor 1720 can perform some operations, such as generating the first registration request, generating the first inventory response, and the like, by invoking computer programs stored in the memory 1730. For details of the processor 1720 and the transceiver 1710, refer to the method embodiments described above or shown in FIG. 16, which will not be repeated here. In each of the above embodiments, refer to the descriptions of the related steps and information in the method embodiments described above, which will not be repeated here. In each of the implementation manners of the communication apparatus shown in FIG. 17, the transceiver can include a receiver configured to perform functions (or operations) of receiving and a transmitter configured to perform functions (or operations) of transmitting. The transceiver is configured to communicate with other devices / apparatuses via a transmission medium.

[0703] The present application further provides a chip system including at least one processor configured to implement functions involved in the method performed by the AF or the network device or the terminal in any one of the above embodiments.

[0704] In a possible design, the chip system further includes a memory configured to store program instructions and data, and the memory is located in or out of the processor.

[0705] The chip system can be composed of a chip, or can include a chip and other discrete components.

[0706] Optionally, the processor in the chip system can be one or more. The processor can be implemented by hardware or software. When implemented by hardware, the processor can be a logic circuit, an integrated circuit, or the like. When implemented by software, the processor can be a general-purpose processor, which implements the functions by reading software codes stored in a memory.

[0707] Optionally, the memory in the chip system can also be one or more. The memory can be integrated with the processor, or can be arranged separately from the processor, and the embodiments of the present application are not limited. Exemplarily, the memory can be a non-transient processor, for example, a read-only memory (ROM), which can be integrated on the same chip as the processor, or can be arranged on different chips respectively, and the embodiments of the present application do not make specific limitations on the type of memory and the arrangement manner of the memory and the processor.

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

[0709] The present application also provides a computer program product, which comprises a computer program (also referred to as code or instruction), which, when executed, causes a computer to perform the method executed by the AF or the network device or the terminal in any one of the above embodiments.

[0710] The present application also provides a computer readable storage medium, which stores a computer program (also referred to as code or instruction). When the computer program is executed, it causes a computer to perform the method executed by the AF or the network device or the terminal in any one of the above embodiments.

[0711] The embodiments of the present application can be combined arbitrarily to achieve different technical effects.

[0712] In the above embodiments, all or part of the processes can be implemented by software, hardware, firmware, or any combination thereof. When implemented by software, all or part of the processes can be implemented in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes described in the present application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transferred from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) manner. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. that includes one or more available media sets. The available media can be a magnetic medium (for example, a floppy disk, a hard disk, a magnetic tape), an optical medium (for example, a DVD), or a semiconductor medium (for example, a solid state disk), etc.

[0713] Those of ordinary skill in the art can understand that all or part of the processes in the above embodiments can be implemented by a computer program to instruct the relevant hardware, and the program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the above method embodiments. The storage medium includes ROM or random access memory (RAM), magnetic disk or optical disk, and various media that can store program codes.

[0714] In summary, the above only describes the embodiments of the technical scheme of the present application, and is not used to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made according to the disclosure of the present application shall be included in the protection scope of the present application.

Claims

1. A communication method characterized by comprising: Applied to a network device, the method comprises: receiving a first request message sent by an application function network element (AF), wherein the first request message comprises first information and second information, the first information is information related to network registration of a terminal, and the second information is information related to inventory of the terminal; sending the 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; receiving registration feedback information and inventory results sent by the terminal; sending the registration feedback information and the inventory results of the terminal to the AF.

2. The method of claim 1, wherein, The first request message is a first registration request, the first information comprises information of a terminal to be registered, and the second information is used to instruct to inventory the terminal to be registered.

3. The method of claim 2, wherein, The first registration request further comprises third information, and the third information is used to instruct to feed back information of an access network device and / or a core network device providing service for the terminal to be registered.

4. The method of claim 2 or 3, wherein: the receiving of the registration feedback information and the inventory results sent by the terminal comprises: receiving a first registration response sent by the terminal, wherein the first registration response comprises the registration feedback information and the inventory results of the terminal; the sending of the registration feedback information and the inventory results of the terminal to the AF comprises: sending the first registration response or a registration response generated according to the first registration response to the AF.

5. The method of claim 1, wherein, The first request message is a first inventory request, the second information comprises information of a terminal to be inventoried, and the first information comprises a list of terminals to be inventoried and to be registered in a network; and the second request message is a first registration request.

6. The method of claim 5, wherein, The information of the terminal to be inventoried comprises one or more of a terminal identifier list, a terminal screening condition, and a group identifier.

7. The method of claim 5, wherein: the receiving of the registration feedback information and the inventory results sent by the terminal comprises: receiving a first registration response sent by the terminal, wherein the first registration response comprises the registration feedback information and the inventory results of the terminal; the sending of the registration feedback information and the inventory results of the terminal to the AF comprises: sending a first inventory response or an inventory response generated according to the first inventory response to the AF, wherein the first inventory response comprises the registration feedback information and the inventory results of the terminal.

8. The method of claim 1, wherein, The first request message is a second registration request, the first information comprises information of a terminal to be registered, and the second information comprises a wait instruction, the wait instruction is used to instruct to merge processing of the second registration request and service associated with the second registration request after waiting for a first time, and the method further comprises: receiving a second inventory request sent by the AF, wherein the second inventory request is used to request inventory of a terminal, and the second inventory request belongs to the service associated with the second registration request.

9. The method of claim 8, wherein, Further comprising: sending the second inventory request to the terminal.

10. The method of claim 9, wherein, the receiving of the registration feedback information and the inventory results sent by the terminal comprises: receiving a second registration response sent by the terminal, wherein the second registration response comprises registration feedback information of the terminal; receiving a second inventory response sent by the terminal, wherein the second inventory response comprises an inventory result of the terminal.

11. The method of claim 8, wherein, Further comprising: after the waiting time indicated by the waiting indication reaches, generating a first registration request according to 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 of claim 11, wherein, The receiving of the registration feedback information and the inventory result sent by the terminal comprises: receiving a first registration response sent by the terminal, wherein the registration response comprises registration feedback information and an inventory result of the terminal.

13. A communication method, comprising: The method applied to a network device, the method comprising: receiving a second inventory request sent by an application function network element (AF), wherein the second inventory request is used to request inventory of a terminal; sending a first registration request to the terminal, wherein the first registration request is used to request network registration and inventory of the terminal; receiving a first registration response sent by the terminal, wherein the first registration response comprises registration feedback information and an inventory result of the terminal; sending a second inventory response to the AF, wherein the second inventory response comprises the inventory result of the terminal.

14. A communication method characterized by comprising: The method applied to an application function network element (AF), the method comprising: sending a first request message to a network device, wherein the first request message comprises first information and second information, the first information is information related to network registration of a terminal, and the second information is information related to inventory of the terminal; receiving registration feedback information and an inventory result of the terminal sent by the network device.

15. The method of claim 14, wherein, The first request message is a first registration request, the first information comprises information of a terminal to be registered, and the second information is used to indicate that the terminal to be registered is inventoried.

16. The method of claim 15, wherein, The first registration request further comprises third information, and the third information is used to indicate information of an access network device and / or a core network device that provides services for the terminal to be registered.

17. The method according to claim 15 or 16, characterized in that The receiving of the registration feedback information and the inventory result of the terminal sent by the network device comprises: receiving a first registration response sent by the network device, wherein the first registration response comprises registration feedback information and an inventory result of the terminal.

18. The method of claim 14, wherein, The first request message is a first inventory request, the second information comprises information of a terminal to be inventoried, and the first information comprises a list of terminals to be inventoried and to be registered.

19. The method of claim 18, wherein, The receiving of the registration feedback information and the inventory result of the terminal sent by the network device comprises: receiving a first inventory response sent by the network device, wherein the first inventory response comprises registration feedback information and an inventory result of the terminal.

20. The method of claim 14, wherein, The first request message is a second registration request, the first information comprises information of a terminal to be registered, and the second information comprises a waiting indication, the waiting indication is used to indicate that the second registration request and a service associated with the second registration request are processed after a first time of waiting, and the method further comprises: sending a second inventory request to the network device, wherein the first inventory request is used to request inventory of the terminal, and the second inventory request is associated with the service associated with the second registration request.

21. The method of claim 20, wherein, The receiving the registration feedback information and the inventory result of the terminal sent by the network device comprises: receiving a second registration response sent by the network device, wherein the second registration response comprises the registration feedback information of the terminal; receiving a second inventory response sent by the network device, wherein the second inventory response comprises the inventory result of the terminal.

22. The method according to any one of claims 14-21, characterized by, The inventory result of the terminal comprises an electronic product code of the terminal and time information of performing inventory.

23. The method according to any one of claims 14-22, characterized by, The registration feedback information comprises one or more of parameters to be used for registration, or registration status.

24. A method of communication, comprising: The method applied to a terminal comprises: receiving a first registration request sent by a network device, wherein the first registration request is used to request network registration and inventory of the terminal; sending registration feedback information and inventory result to the network device.

25. The method of claim 24, wherein, The sending the registration feedback information and the inventory result to the network device comprises: sending a first registration response to the network device, wherein the first registration response comprises the registration feedback information and the inventory result.

26. A method of communication, comprising: The method applied to a terminal comprises: receiving a second inventory request sent by a network device, wherein the second inventory request is used to request inventory of the terminal; if not registered to a core network, sending registration feedback information and inventory result to the network device, or if not registered to a core network, sending a report message to the network device, wherein the report message is used to request a second registration request, and the second registration request is used to request network registration of the terminal.

27. The method of claim 26, wherein, Further comprising: if registered to a core network, sending a second inventory response to the network device, wherein the second inventory response comprises the inventory result.

28. A communications device, characterized by The communication device comprises modules for performing the method of any one of claims 1-12; or The communication device comprises a processor configured to perform the method of any one of claims 1-12. The communication device comprises modules for performing the method of any one of claims 13-23; or 29. A communications device, characterized by The communication device comprises a processor configured to perform the method of any one of claims 13-23. The communication device comprises modules for performing the method of any one of claims 24-27; or The communication device comprises a processor configured to perform the method of any one of claims 24-27.

30. A communications device, characterized by The communication device comprises a logic circuit and an interface, the logic circuit and the interface are coupled; the interface is used to input and / or output information, and the logic circuit is used to perform the method of any one of claims 1-27. The computer readable storage medium is used to store a computer program, and the computer program is executed to perform the method of any one of claims 1-27. The first communication device, the second communication device and the third communication device are coupled; and 31. A communications device, characterized by The first communication device is configured to perform the method of any one of claims 1-12.

32. A computer-readable storage medium, comprising: ​ 33. A communication system, characterized by ​ ​ The second communication device is configured to perform the method of any one of claims 13-23. The fourth communication device is configured to perform the method of any one of claims 24-27.

34. A computer program product comprising instructions, wherein: The computer program product, when run on an electronic device, causes the electronic device to perform the method of any one of claims 1-27.

Images