Terminal management method and core network device
By managing the number of terminals accessing the network and the authentication process through core network equipment, the problem of terminal access management in passive IoT has been solved, enabling fast and accurate terminal access control and authentication, and improving management efficiency and security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-01-30
- Publication Date
- 2026-03-17
AI Technical Summary
In passive IoT architectures, existing technologies struggle to effectively manage the number of terminals accessing the network, potentially exceeding the number of terminals allowed by the requesting party, and lacking a fast and accurate authentication mechanism.
The core network equipment receives messages from terminals requesting network access, determines whether access is allowed based on quantity and identification information, and executes an authentication process, including one-way or two-way authentication, to ensure that the terminal is trustworthy. The core network equipment also communicates with the requesting party to manage the number of terminals.
It enables rapid and accurate management of terminal access to the network, avoids excessive access, ensures terminal trustworthiness, reduces signaling overhead, and improves the efficiency and security of terminal management.
Smart Images

Figure CN116567780B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communications, and more particularly to a terminal management method and core network equipment. Background Technology
[0002] A passive IoT (P-IoT) architecture can include passive terminals, readers, and operation requesters. Passive terminals can be in the form of tags or any other terminal form. The following explanation uses a terminal as an example. The reader uses radio frequency (RF) to read and write to the terminal (e.g., an electronic tag or RFID card) to identify targets and exchange data. When an operation requester performs terminal operations, it can send operation instructions to the reader through the core network equipment. These instructions can include, but are not limited to, performing operations such as obtaining terminal information, inventory operations (or storage operations), read operations, write operations, invalidation operations, and interacting with the terminal. Upon receiving the operation instruction, the reader sends it to the terminal; the terminal then obtains or sends corresponding information based on the instruction. For example, when the operation instruction is an inventory instruction or an inventory operation, the terminal sends its identification information. Similarly, when the operation instruction is a read instruction or a read operation, the terminal sends the data information stored in its storage area. For example, when the operation instruction is a write instruction or a write operation is performed, the terminal stores the data information to be written to the terminal, included in the instruction, in the terminal's storage area. The reader receives the information sent by the terminal and sends the information to the operation requester through the core network equipment. Summary of the Invention
[0003] This application discloses a terminal management method and a core network device, which can realize the management of terminals.
[0004] In a first aspect, embodiments of this application provide a terminal management method, comprising: a first core network device receiving a first message from a terminal, the first message being used to request access to a network; the first core network device, upon determining, based on quantity information, that the terminal is permitted to access the network, sending a second message to an operation requester to which the terminal belongs; the quantity information including the number of terminals permitted to be used by the operation requester; the second message containing first identification information, the first identification information including one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0005] In this embodiment, when the first core network device determines that a terminal is allowed to access the network based on quantity information, it sends a second message to the operation requester to which the terminal belongs. That is, before sending the second message, the first core network device needs to determine whether a terminal is allowed to access the network based on quantity information, rather than directly allowing the terminal to access the network. By determining whether a terminal is allowed to access the network based on quantity information, the first core network device avoids a situation where the number of terminals connected to the network corresponding to the operation requester is greater than or equal to the number of terminals allowed to be used by the operation requester.
[0006] In one possible implementation, determining whether the terminal is allowed to access the network based on quantity information includes: when the number of terminals accessing the network among the terminals corresponding to the operation requester is less than a quantity threshold, the first core network device determines that the terminal is allowed to access the network; the quantity threshold is the number of terminals that the operation requester is allowed to use.
[0007] In this implementation, when the number of terminals accessing the network in the terminal corresponding to the operation requester is less than the number threshold, the first core network device determines that the terminal is allowed to access the network. This can quickly and accurately determine whether to allow the terminal to access the network and prevent the number of terminals accessing the network in the terminal corresponding to the operation requester from being greater than or equal to the number threshold.
[0008] In one possible implementation, the method further includes: the first core network device, upon determining based on the quantity information that the terminal is not allowed to access the network, sending a third message to the terminal; the third message indicating that the terminal is denied access to the network.
[0009] In this implementation, if the first core network device determines that a terminal is not allowed to access the network based on the quantity information, it sends a third message to the terminal; this can prevent the number of terminals accessing the network from being greater than or equal to the number of terminals allowed to be used by the operation requester.
[0010] In one possible implementation, determining that the terminal is not allowed to access the network based on the quantity information includes: when the number of terminals accessing the network among the terminals corresponding to the operation requester is greater than or equal to a quantity threshold, the first core network device determines that the terminal is not allowed to access the network; the quantity threshold is the number of terminals that the operation requester is allowed to use.
[0011] In this implementation, when the number of terminals accessing the network in the terminal corresponding to the operation requester is greater than or equal to a threshold, the first core network device determines that the terminal is not allowed to access the network; this allows for a quick and accurate determination of whether to allow terminal access.
[0012] In one possible implementation, the method further includes: the first core network device sending a fourth message to the second core network device; the fourth message is used to request the execution of an authentication process for the terminal; the fourth message includes second identification information and authentication information, the second identification information and the authentication information are used to execute the authentication process; the second identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0013] In this implementation, the first core network device sends a fourth message to the second core network device to perform an authentication process on the terminal, thereby ensuring that the terminal is a trusted terminal.
[0014] In one possible implementation, after the first core network device determines that the terminal is allowed to access the network based on the quantity information, the first core network device sends a fourth message to the second core network device; the fourth message is used to request the terminal to perform an authentication process; the fourth message includes second identification information and authentication information, the second identification information and the authentication information are used to perform the authentication process; the second identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0015] In this implementation, the first core network device sends a fourth message to the second core network device to perform an authentication process on the terminal, thereby ensuring that the terminal is a trusted terminal.
[0016] In one possible implementation, the fourth message further includes indication information indicating that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication by the terminal to the network or the operation requester, or one-way authentication by the network or the operation requester to the terminal.
[0017] In this implementation, the indication information indicates whether the authentication process is a one-way authentication process or a two-way authentication process, so that the second core network device can determine the authentication process to be executed based on the indication information.
[0018] In one possible implementation, the method further includes: the first core network device performing an authentication process on the terminal according to the first message; the first message includes third identification information and authentication information, the third identification information and the authentication information being used to perform the authentication process; the third identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0019] In this implementation, the first core network device performs an authentication process on the terminal based on the first message. The first core network device can perform the authentication process on the terminal on its own without interacting with other devices, which can reduce signaling overhead.
[0020] In one possible implementation, after the first core network device determines that the terminal is allowed to access the network based on the quantity information, it performs an authentication process on the terminal according to the first message; the first message includes third identification information and authentication information, which are used to perform the authentication process; the third identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0021] In this implementation, the first core network device performs an authentication process on the terminal based on the first message. The first core network device can perform the authentication process on the terminal on its own without interacting with other devices, which can reduce signaling overhead.
[0022] In one possible implementation, the method further includes: the first core network device determining the operation requester to which the terminal belongs based on the third identification information included in the first message; the third identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0023] In this implementation, the first core network device determines the operation requester to which the terminal belongs based on the third identification information included in the first message, so as to determine whether to allow the terminal to access the network based on the quantity information.
[0024] In one possible implementation, the first core network device determines the operation requester to which the terminal belongs based on the third identification information included in the first message. This includes: the first core network device determining the operation requester to which the terminal belongs based on the third identification information and a first correspondence relationship; the first correspondence relationship indicates that the terminal belongs to the operation requester. Optionally, the first correspondence relationship includes the correspondence between the terminal's application identifier (terminal identifier or network identifier) and the operation requester identifier, where the operation requester identifier is the identifier of the operation requester.
[0025] In this implementation, the first core network device can quickly and accurately determine the operation requester to which the terminal belongs based on the third identification information and the first correspondence.
[0026] In one possible implementation, before the first core network device determines the operation requester to which the terminal belongs based on the third identification information included in the first message, the method further includes: the first core network device determining a second correspondence based on an operation instruction from the operation requester; the second correspondence indicates that the terminal belongs to the operation requester; the first core network device determining the operation requester to which the terminal belongs based on the third identification information included in the first message includes: the first core network device determining the operation requester to which the terminal belongs based on the third identification information and the second correspondence. The operation instruction may include a first identifier of the terminal, which may be any one of a terminal identifier, an encrypted terminal identifier, a terminal application identifier, or a terminal network identifier.
[0027] In this implementation, the first core network device determines the second correspondence based on the operation instructions from the operation requester. It is not necessary to pre-store the correspondence between each terminal and its corresponding operation requester, which can reduce storage overhead and reduce the workload of retrieving the operation requester to which the terminal belongs.
[0028] In one possible implementation, the method further includes: the first core network device receiving a fifth message; the first core network device sending a sixth message to the terminal; the fifth message indicating that the authentication process is successful, and the sixth message indicating that the terminal is allowed to access the network; or, the fifth message indicating that the authentication process is unsuccessful, and the sixth message indicating that the terminal is denied access to the network.
[0029] In this implementation, instructions can be given in a timely manner to accept or reject terminal access to the network.
[0030] In one possible implementation, the method further includes: the first core network device acquiring the quantity information and / or the first identification information.
[0031] In this implementation, the first core network device obtains quantity information and / or first identification information in order to determine whether to allow the terminal to access the network based on the quantity information, and to implement the authentication process for the terminal.
[0032] In one possible implementation, the method further includes: the first core network device counting the number of terminals connected to the network in the terminal corresponding to the operation requester.
[0033] In this implementation, the first core network device counts the number of terminals connected to the network among the terminals corresponding to the operation requester, so as to determine whether to allow the terminal to access the network based on the terminal device and the number threshold.
[0034] In one possible implementation, the first core network device counts the number of terminals accessing the network in the terminal corresponding to the operation requester by: after the terminal is authenticated, the first core network device updates the number of terminals accessing the network in the terminal corresponding to the operation requester according to the first identification information and the third correspondence relationship, wherein the third correspondence relationship includes one or more of the following: terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0035] In this implementation, the first core network device updates the number of terminals accessing the network in the terminal corresponding to the operation requester based on the first identification information and the second correspondence; it can accurately count the number of terminals accessing the network in the terminal corresponding to the operation requester and prevent multiple terminals from using the same identifier to access the network.
[0036] Secondly, this application provides another terminal management method, characterized in that it includes: an operation requester obtaining quantity information, the quantity information indicating the number of terminals that the operation requester is allowed to use; and the operation requester obtaining one or more terminal application identifiers based on the quantity information.
[0037] In this embodiment of the application, the operation requester obtains one or more terminal application identifiers based on the quantity information; this can prevent the number of terminal application identifiers obtained by the operation requester from exceeding the number of terminals allowed to be used by the operation requester.
[0038] In one possible implementation, the method further includes: the operation requester sending an operation instruction, the operation instruction including a first application identifier, the first application identifier being contained in one or more terminal application identifiers; the operation instruction being used to perform an operation on the terminal corresponding to the first application identifier.
[0039] In this implementation, the operation instruction includes a first application identifier; by using the operation instruction containing the first application identifier, operations can be conveniently performed on the terminal corresponding to the first application identifier.
[0040] In one possible implementation, the method further includes: the operation requester obtaining network identification information, the network identification information including one or more terminal network identifiers.
[0041] In this implementation, the operation requester obtains network identification information so that it can use the network identification information to manage the terminal.
[0042] In one possible implementation, the method further includes: the operation requester sending the one or more terminal application identifiers and / or the operation requester identifier to the first core network device.
[0043] In this implementation, the operation requester sends one or more terminal application identifiers and / or operation requester identifiers to the first core network device so that the first core network device can use the one or more terminal application identifiers and / or operation requester identifiers to perform terminal management.
[0044] Thirdly, this application provides another terminal management method, including: an operation requester obtaining one or more terminal application identifiers; the operation requester sending an operation instruction, the operation instruction including a first application identifier, the first application identifier being contained within the one or more terminal application identifiers; the operation instruction being used to perform an operation on the terminal corresponding to the first application identifier.
[0045] In this embodiment, the operation requester obtains one or more terminal application identifiers and sends an operation instruction including a first application identifier, which can perform an operation on the terminal corresponding to the first application identifier. In other words, based on the obtained one or more terminal application identifiers, an operation can be performed on the corresponding terminal.
[0046] In one possible implementation, the operation requester obtaining one or more terminal application identifiers includes: the operation requester receiving the one or more terminal application identifiers from a first core network device.
[0047] In this implementation, the operation requester receives one or more terminal application identifiers from the first core network device; it does not need to allocate terminal application identifiers itself.
[0048] In one possible implementation, the method further includes: the operation requester obtaining quantity information, the quantity information indicating the number of terminals that the operation requester is allowed to use.
[0049] In this implementation, the requesting party obtains quantity information and can determine the number of terminals it is allowed to use.
[0050] Fourthly, this application provides another terminal management method, comprising: a second core network device acquiring quantity information, the quantity information indicating the number of terminals allowed to be used by an operation requester; the second core network device sending the quantity information and / or first identification information to a first core network device; the first identification information including one or more of the following: terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier; the operation requester identifier being the identifier of the operation requester, and the terminal belonging to the operation requester.
[0051] In this embodiment, the second core network device sends quantity information and / or first identification information to the first core network device so that the first core network device can determine whether to allow the terminal to access the network based on the quantity information.
[0052] In one possible implementation, the method further includes: the second core network device configuring the number of terminals that the operation requester is allowed to use.
[0053] In this implementation, the second core network device configures the number of terminals that the operation requester is allowed to use, so as to perform terminal management using that number of terminals.
[0054] In one possible implementation, after the second core network device obtains the quantity information, the method further includes: the second core network device obtaining (e.g., assigning) the terminal network identifier of the terminal based on the quantity information.
[0055] In this implementation, the second core network device obtains the terminal network identifier of the terminal based on the quantity information, so as to perform terminal management on the terminal in the future based on the terminal network identifier.
[0056] In one possible implementation, after the second core network device obtains (e.g., assigns) the terminal network identifier of the terminal based on the quantity information, the method further includes: the second core network device sending the terminal network identifier of the terminal to the operation requester.
[0057] In this implementation, the second core network device sends a terminal network identifier to the operation requester, so that the operation requester can use the terminal network identifier to perform terminal management on the corresponding terminal.
[0058] In one possible implementation, the method further includes: the second core network device receiving one or more terminal application identifiers from the operation requester; the one or more terminal application identifiers include the terminal application identifier of the terminal.
[0059] In this implementation, the second core network device receives one or more terminal application identifiers from the operation requester, so as to subsequently use these terminal application identifiers to perform terminal management on the corresponding terminals.
[0060] In one possible implementation, after the second core network device receives one or more terminal application identifiers from the operation requester, the method further includes: the second core network device configuring the one or more terminal application identifiers.
[0061] In this implementation, the second core network device is configured with one or more terminal application identifiers so that these terminal application identifiers can be used to manage the corresponding terminals in the future.
[0062] In one possible implementation, the method further includes: the second core network device acquiring a seventh message; the seventh message including the quantity information and fourth identification information; the fourth identification information including one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. The second core network device acquiring the seventh message may be by receiving a seventh message sent from other devices (e.g., devices belonging to an operator).
[0063] In this implementation, the second core network device obtains the seventh message in order to use the seventh message to obtain the first identification information.
[0064] In one possible implementation, the method further includes: the second core network device sending the application identifier of the terminal and / or the quantity information to the operation requester.
[0065] In this implementation, the requesting party can obtain the application identifier and / or quantity information of the terminal.
[0066] In one possible implementation, the method further includes: the second core network device receiving a fourth message from the first core network device, the fourth message being used to request an authentication process to be performed on the terminal; the fourth message including second identification information and authentication information, the second identification information including one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier; the second core network device performing the authentication process on the terminal according to the fourth message.
[0067] In this embodiment of the application, the second core network device performs an authentication process on the terminal according to the fourth message, which can quickly authenticate the terminal.
[0068] In one possible implementation, the fourth message further includes indication information indicating that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication by the terminal to the network or the operation requester, or one-way authentication by the network or the operation requester to the terminal; the method further includes: the second core network device determining the type of the authentication process based on the indication information.
[0069] In this implementation, the second core network device determines the type of authentication process based on the instruction information, so as to perform the corresponding authentication process on the terminal.
[0070] In one possible implementation, the second identification information includes an operation requester identifier but does not include the terminal identifier, encrypted terminal identifier, terminal application identifier, and terminal network identifier; after the second core network device performs the authentication process on the terminal according to the fourth message, the method further includes: if the terminal passes authentication, assigning a terminal network identifier to the terminal.
[0071] In this implementation, a terminal network identifier is assigned to the terminal after authentication. This eliminates the need for the terminal's network identifier to be pre-configured in the operation requester's configuration, preventing the requester from using a single terminal's network identifier across multiple terminals. In other words, the process of obtaining the terminal network identifier is streamlined and more secure.
[0072] In one possible implementation, the method further includes: the second core network device counting the number of terminals connected to the network among the terminals corresponding to the operation requester.
[0073] In this implementation, the second core network device counts the number of terminals connected to the network among the terminals corresponding to the operation requester, so as to determine whether to allow the terminal to access the network based on the terminal device and the number threshold.
[0074] In one possible implementation, the second core network device counts the number of terminals accessing the network in the terminal corresponding to the operation requester by: after the terminal is authenticated, the second core network device updates the number of terminals accessing the network in the terminal corresponding to the operation requester according to the first identification information and the third correspondence relationship, wherein the third correspondence relationship includes one or more of the following: terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0075] In this implementation, the second core network device updates the number of terminals accessing the network in the terminal corresponding to the operation requester based on the first identification information and the third correspondence; it can accurately count the number of terminals accessing the network in the terminal corresponding to the operation requester and prevent multiple terminals from using the same identifier to access the network.
[0076] In one possible implementation, after the second core network device counts the number of terminals connected to the network in the terminal corresponding to the operation requester, the method further includes: the second core network device notifying the first core network device of the number of terminals connected to the network in the terminal corresponding to the operation requester.
[0077] In this implementation, the first core network device can know the number of terminals connected to the network in the terminal corresponding to the operation requester.
[0078] In one possible implementation, the terminal is a tag; the method further includes: the second core network device updating or deleting the identification information of the invalid tag, wherein the identification information of the invalid tag includes one or more of the following: the terminal application identifier, terminal network identifier, terminal identifier, encrypted terminal identifier, and a third correspondence relationship of the invalid tag, wherein the third correspondence relationship includes two or more of the correspondence relationships of the terminal application identifier, terminal network identifier, terminal identifier, and encrypted terminal identifier of the invalid tag.
[0079] In this implementation, the second core network equipment updates or deletes the identification information of invalid tags in order to better manage the tags.
[0080] In one possible implementation, the method further includes: receiving a tag message from the operation requester; the second core network device updating or deleting the identification information of the invalid tag includes: the second core network device updating or deleting the identification information of the invalid tag according to the tag information.
[0081] In this implementation, the identification information of expired tags can be updated or deleted according to the instructions of the operation requester.
[0082] Fifthly, embodiments of this application provide a communication device that has the function of implementing the behavior described in the first aspect of the method embodiment. The function can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described function. In one possible implementation, it includes a transceiver module and a processing module, wherein: the transceiver module is configured to receive a first message from a terminal, the first message being a request to access the network; the transceiver module is further configured to send a second message to the operation requesting party to which the terminal belongs when the processing module determines, based on quantity information, that the terminal is allowed to access the network; the quantity information includes the number of terminals allowed to be used by the operation requesting party; the second message includes first identification information, the first identification information including one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requesting party identifier.
[0083] In one possible implementation, the processing module is specifically configured to determine that the terminal is allowed to access the network when the number of terminals connected to the network in the terminal corresponding to the operation requester is less than a number threshold; the number threshold is the number of terminals that the operation requester is allowed to use.
[0084] In one possible implementation, the transceiver module is further configured to send a third message to the terminal if the processing module determines, based on the quantity information, that the terminal is not allowed to access the network; the third message indicates that the terminal is denied access to the network.
[0085] In one possible implementation, the processing module is specifically configured to determine that the terminal is not allowed to access the network when the number of terminals connected to the network in the terminal corresponding to the operation requester is greater than or equal to a number threshold; the number threshold is the number of terminals that the operation requester is allowed to use.
[0086] In one possible implementation, the transceiver module is further configured to send a fourth message to the second core network device; the fourth message is used to request the execution of an authentication process for the terminal; the fourth message includes second identification information and authentication information, the second identification information and the authentication information being used to execute the authentication process; the second identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0087] In one possible implementation, the fourth message further includes indication information indicating that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication by the terminal to the network or the operation requester, or one-way authentication by the network or the operation requester to the terminal.
[0088] In one possible implementation, the processing module is further configured to perform an authentication process on the terminal according to the first message; the first message includes third identification information and authentication information, the third identification information and the authentication information being used to perform the authentication process; the third identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0089] In one possible implementation, the processing module is further configured to determine the operation requester to which the terminal belongs based on the third identification information included in the first message; the third identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0090] In one possible implementation, the processing module is specifically configured to determine the operation requester to which the terminal belongs based on the third identification information and the first correspondence relationship; the first correspondence relationship indicates that the terminal belongs to the operation requester. Optionally, the first correspondence relationship includes the correspondence between the terminal's application identifier (terminal identifier or network identifier) and the operation requester identifier, wherein the operation requester identifier is the identifier of the operation requester.
[0091] In one possible implementation, the processing module is specifically configured to determine a second correspondence based on an operation instruction from the operation requester; the second correspondence indicates that the terminal belongs to the operation requester; and determine the operation requester to which the terminal belongs based on the third identification information and the second correspondence. The operation instruction may include a first identifier of the terminal, which may be any one of a terminal identifier, an encrypted terminal identifier, a terminal application identifier, or a terminal network identifier.
[0092] In one possible implementation, the transceiver module is further configured to receive a fifth message; send a sixth message to the terminal; the fifth message indicates that the authentication process is successful, and the sixth message indicates that the terminal is allowed to access the network; or, the fifth message indicates that the authentication process is unsuccessful, and the sixth message indicates that the terminal is denied access to the network.
[0093] In one possible implementation, the processing module is further configured to acquire the quantity information and / or the first identification information.
[0094] In one possible implementation, the processing module is further configured to count the number of terminals connected to the network in the terminal corresponding to the operation requester.
[0095] In one possible implementation, the processing module is specifically used to update the number of terminals connected to the network in the terminal corresponding to the operation requester after the terminal passes authentication, based on the first identification information and the third correspondence. The third correspondence includes one or more of the following: the terminal identifier of the terminal, the encrypted terminal identifier, the terminal application identifier, the terminal network identifier, and the operation requester identifier.
[0096] For the technical effects of the various possible implementations of the fifth aspect, please refer to the introduction of the technical effects of the first aspect or the various possible implementations of the first aspect.
[0097] Sixthly, embodiments of this application provide a communication device that has the function of implementing the behavior described in the first aspect of the method embodiment. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described function. In one possible implementation, it includes a transceiver module and a processing module, wherein: the transceiver module is used to acquire quantity information, the quantity information indicating the number of terminals allowed by the operation requester; the processing module is used to acquire one or more terminal application identifiers based on the quantity information.
[0098] In one possible implementation, the transceiver module is further configured to send an operation instruction, the operation instruction including a first application identifier, the first application identifier being contained within one or more terminal application identifiers; the operation instruction is used to perform an operation on the terminal corresponding to the first application identifier.
[0099] In one possible implementation, the transceiver module is further configured to acquire network identification information, which includes one or more terminal network identifiers.
[0100] In one possible implementation, the transceiver module is further configured to send the one or more terminal application identifiers and / or the operation requester identifiers to the first core network device.
[0101] For the technical effects of the various possible implementations of the sixth aspect, please refer to the introduction of the technical effects of the second aspect or the various possible implementations of the second aspect.
[0102] Seventhly, embodiments of this application provide a communication device that has the function of implementing the behavior described in the third aspect of the method embodiment. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described function. In one possible implementation, a transceiver module is included, wherein: the transceiver module is configured to acquire one or more terminal application identifiers; send an operation instruction, the operation instruction including a first application identifier, the first application identifier being contained within the one or more terminal application identifiers; the operation instruction is used to perform an operation on the terminal corresponding to the first application identifier.
[0103] In one possible implementation, the transceiver module is specifically configured to receive one or more terminal application identifiers from the first core network device.
[0104] In one possible implementation, the transceiver module is further configured to acquire quantity information, which indicates the number of terminals that the operation requester is allowed to use.
[0105] For the technical effects of the various possible implementations of the seventh aspect, please refer to the introduction of the technical effects of the various possible implementations of the third aspect.
[0106] Eighthly, embodiments of this application provide a communication device that has the function of implementing the behavior described in the fourth aspect of the method embodiments. The function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the above-described function. In one possible implementation, a transceiver module is included, wherein: the transceiver module is used to acquire quantity information, the quantity information indicating the number of terminals allowed by the operation requester; and to send the quantity information and / or first identification information to a first core network device; the first identification information includes one or more of the following: a terminal identifier, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier; the operation requester identifier is the identifier of the operation requester, and the terminal belongs to the operation requester.
[0107] In one possible implementation, the communication device further includes a processing module for configuring the number of terminals that the operation requester is allowed to use.
[0108] In one possible implementation, the processing module is specifically configured to obtain (e.g., assign) the terminal network identifier of the terminal based on the quantity information.
[0109] In one possible implementation, the transceiver module is further configured to send the terminal network identifier of the terminal to the operation requester.
[0110] In one possible implementation, the transceiver module is further configured to receive one or more terminal application identifiers from the operation requester; the one or more terminal application identifiers include the terminal application identifier of the terminal.
[0111] In one possible implementation, the processing module is further configured to configure the one or more terminal application identifiers.
[0112] In one possible implementation, the transceiver module is further configured to acquire a seventh message; the seventh message includes the quantity information and the fourth identification information; the fourth identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier.
[0113] In one possible implementation, the transceiver module is further configured to send the application identifier of the terminal and / or the quantity information to the operation requester.
[0114] In one possible implementation, the transceiver module is further configured to receive a fourth message from the first core network device, the fourth message being used to request the execution of an authentication process for the terminal; the fourth message includes second identification information and authentication information, the second identification information including one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier; the processing module is further configured to execute an authentication process for the terminal based on the fourth message.
[0115] In one possible implementation, the fourth message further includes indication information indicating that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication by the terminal to the network or the operation requester, or one-way authentication by the network or the operation requester to the terminal; the processing module is specifically used to determine the type of the authentication process based on the indication information.
[0116] In one possible implementation, the second identification information includes an operation requester identifier but does not include the terminal identifier, encrypted terminal identifier, terminal application identifier, and terminal network identifier; the processing module is further configured to assign a terminal network identifier to the terminal if the terminal passes authentication.
[0117] In one possible implementation, the processing module is further configured to count the number of terminals connected to the network in the terminal corresponding to the operation requester.
[0118] In one possible implementation, the processing module is specifically used to update the number of terminals accessing the network in the terminal corresponding to the operation requester after the terminal passes authentication, based on the first identification information and the third correspondence. The third correspondence includes one or more of the following: the terminal identifier of the terminal, the encrypted terminal identifier, the terminal application identifier, the terminal network identifier, and the operation requester identifier.
[0119] In one possible implementation, the transceiver module is further configured to notify the first core network device of the number of terminals connected to the network among the terminals corresponding to the operation requester. For example, the transceiver module sends a notification message to the first core network device, the notification message including the number of terminals connected to the network among the terminals corresponding to the operation requester.
[0120] In one possible implementation, the terminal is a tag; the processing module is further configured to update or delete the identification information of an expired tag, wherein the identification information of the expired tag includes one or more of the following: the terminal application identifier, the terminal network identifier, the terminal identifier, the encrypted terminal identifier, and a third correspondence relationship, wherein the third correspondence relationship includes two or more of the following correspondence relationships: the terminal application identifier, the terminal network identifier, the terminal identifier, and the encrypted terminal identifier of the expired tag.
[0121] In one possible implementation, the transceiver module is further configured to receive a tag message from the operation requester; the second core network device updating or deleting the identification information of invalid tags includes: the second core network device updating or deleting the identification information of invalid tags according to the tag information.
[0122] For the technical effects of the various possible implementations of the eighth aspect, please refer to the introduction of the technical effects of the various possible implementations of the fourth aspect.
[0123] Ninthly, this application provides a communication device including a processor that can execute computer execution instructions stored in a memory to execute the method shown in the first aspect or any possible implementation thereof, or to execute the method shown in the second aspect or any possible implementation thereof, or to execute the method shown in the third aspect or any possible implementation thereof, or to execute the method shown in the fourth aspect or any possible implementation thereof.
[0124] In this embodiment of the application, during the execution of the above method, the process of sending information can be understood as a process of outputting information based on processor instructions. When outputting information, the processor outputs the information to the transceiver so that the transceiver can transmit it. After the information is output by the processor, it may need to undergo other processing before reaching the transceiver. Similarly, when the processor receives input information, the transceiver receives the information and inputs it into the processor. Furthermore, after the transceiver receives the information, it may need to undergo other processing before being input into the processor.
[0125] Unless otherwise specified, or unless their actual function or internal logic in the relevant description is contradicted, the sending and / or receiving operations involved by the processor can generally be understood as processor instruction output.
[0126] In implementation, the processor described above can be a dedicated processor for executing these methods, or it can be a processor that executes computer instructions stored in memory to execute these methods, such as a general-purpose processor. For example, the processor can also be used to execute a program stored in memory, which, when executed, causes the communication device to perform the methods as described in the first aspect or any possible implementation thereof. In one possible implementation, the memory is located outside the communication device. In another possible implementation, the memory is located inside the communication device.
[0127] In this embodiment of the application, the processor and memory may also be integrated into a single device, that is, the processor and memory may be integrated together.
[0128] In one possible implementation, the communication device further includes a transceiver for receiving or sending messages, etc.
[0129] In a tenth aspect, this application provides a data processing apparatus, which includes a processing circuit and an interface circuit. The interface circuit is used to acquire data or output data. The processing circuit is used to execute a corresponding method as shown in the first aspect or any possible implementation thereof, or to execute a corresponding method as shown in the second aspect or any possible implementation thereof, or to execute a corresponding method as shown in the third aspect or any possible implementation thereof, or to execute a corresponding method as shown in the fourth aspect or any possible implementation thereof.
[0130] Eleventhly, this application provides a computer-readable storage medium for storing a computer program that, when run on a computer, causes the method shown in the first aspect or any possible implementation thereof to be executed, or causes the method shown in the second aspect or any possible implementation thereof to be executed, or causes the method shown in the third aspect or any possible implementation thereof to be executed, or causes the method shown in the fourth aspect or any possible implementation thereof to be executed.
[0131] In a twelfth aspect, this application provides a computer program product comprising a computer program or computer code that, when run on a computer, causes the method shown in the first aspect or any possible implementation thereof to be executed, or causes the method shown in the second aspect or any possible implementation thereof to be executed, or causes the method shown in the third aspect or any possible implementation thereof to be executed, or causes the method shown in the fourth aspect or any possible implementation thereof to be executed.
[0132] In a thirteenth aspect, this application provides a communication system comprising one or more of the first core network device of the fifth aspect or any possible implementation thereof, the operation requester of the sixth or seventh aspect thereof, and the second core network device of the eighth aspect or any possible implementation thereof. Attached Figure Description
[0133] To more clearly illustrate the technical solutions in the embodiments of this application or the background art, the accompanying drawings used in the embodiments of this application or the background art will be described below.
[0134] Figure 1 This is a schematic diagram of a passive Internet of Things (IoT) service flow.
[0135] Figure 2A , Figure 2B , Figure 2C The diagram illustrates three architectures for 3GPP networks supporting P-IoT.
[0136] Figure 3 This application provides an example of a UE registration process.
[0137] Figure 4 Examples of several methods for allocating application identifiers for terminals provided in embodiments of this application are shown;
[0138] Figure 5 A flowchart of a terminal management method provided in an embodiment of this application;
[0139] Figure 6A A flowchart of another terminal management method provided in this application embodiment;
[0140] Figure 6B A flowchart of another terminal management method provided in this application embodiment;
[0141] Figure 7 A flowchart of another terminal management method provided in this application embodiment;
[0142] Figure 8 A flowchart of another terminal management method provided in this application embodiment;
[0143] Figure 9 A flowchart of another terminal management method provided in this application embodiment;
[0144] Figure 10 A flowchart of another terminal management method provided in this application embodiment;
[0145] Figure 11A flowchart of another terminal management method provided in this application embodiment;
[0146] Figure 12 A schematic diagram of the structure of a communication device 1200 is shown;
[0147] Figure 13 A schematic diagram of another communication device 130 provided in the embodiments of this application;
[0148] Figure 14 This is a schematic diagram of another communication device 140 provided in an embodiment of this application. Detailed Implementation
[0149] The terms "first" and "second," etc., used in the specification, claims, and drawings of this application are used only to distinguish different objects and not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0150] The term "embodiment" as used herein means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.
[0151] The terminology used in the following embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to include the plural expressions as well, unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in this application refers to and includes any or all possible combinations of one or more of the listed items. For example, “A and / or B” can mean: only A exists, only B exists, and both A and B exist, where A and B can be singular or plural. The term “at least one” as used in this application means one or more, and “more” means two or more. “At least one of the following” or similar expressions refer to any combination of these items, including any combination of singular or plural items. For example, at least one of a, b, and c can mean: a, or, b, or, c, or, a and b, or, a and c, or, b and c, or, a, b, and c. a, b, and c can be a single or multiple.
[0152] The following section first introduces the terminology and technical features involved in the embodiments of this application.
[0153] Passive Internet of Things (P-IoT)
[0154] In a passive Internet of Things (IoT) system, some network nodes can be passive, obtaining energy through solar, radio frequency, wind, hydro, or tidal power sources, with no restrictions on the energy acquisition method. These nodes do not possess or rely on batteries or other power supply devices; instead, they obtain energy from the environment to support data sensing, transmission, and distributed computing. These nodes can also store the acquired energy. The passive IoT architecture can include passive terminals, readers, and operation requesters. Passive terminals can be in the form of tags (e.g., electronic tags) or any other terminal form; this application makes no restrictions. Readers can use radio frequency (RF) methods to read and write electronic tags or RFID cards, thereby achieving target identification and data exchange. There are two ways it works: one is that when the tag enters the reader's effective identification range, it receives the radio frequency signal emitted by the reader and uses the energy obtained from the induced current to emit the information stored in the chip (corresponding to a passive tag); the other is that the tag (which can be called a semi-passive or semi-active tag) can store some electrical energy through solar energy or other means, enabling it to actively send signals of a certain frequency or use the stored electrical energy for communication, data reading, or data writing. After the reader receives and decodes the information, it sends it to the central information system for relevant data processing. In this application, the tag can refer to an electronic tag or a passive or semi-passive IoT tag (such as a non-electronic tag used for embedding or attaching to an object). In this application, one example of a terminal is a tag. In this application, the reader can be an access network device, including base stations, pole stations, micro base stations, wireless access network devices, wireless access network nodes, integrated access and backhaul nodes, etc., which are not limited in this application. In this application, the operation requester may be a server, a passive IoT server (P-IoT server), an application function (AF), a passive IoT application function (P-IoT AF), or other device that sends operation instructions.
[0155] This technology is widely used in various industries. Below are two simple application scenarios.
[0156] Warehousing / Transportation / Materials: Passive or semi-passive tags are embedded or affixed to goods. During the logistics process, relevant information about goods stored in warehouses, shopping malls, etc., is automatically collected by readers via IoT tags. Managers can then quickly query goods information in the system, reducing the risk of goods being discarded or stolen, improving the speed and accuracy of goods handover, and preventing cross-selling and counterfeiting.
[0157] Fixed asset management: Places with large assets or valuable items, such as libraries, art galleries, and museums, require complete management procedures or rigorous protection measures. Any abnormal changes in the storage information of books or valuable items will promptly alert the administrator, allowing for appropriate action.
[0158] Figure 1 This is a schematic diagram of a passive Internet of Things (IoT) service flow. Figure 1 The following steps are illustrated: 1. The requesting party sends an operation command to the access network device via the AMF. 2. The terminal executes the operation. After receiving the operation command from the mobility management device, the access network device sends the command to the terminal. The terminal obtains or sends corresponding information according to the operation command, i.e., executes the corresponding operation. 3. The terminal accesses the core network. 4. The terminal accesses the core network via core network equipment (e.g., ...). Figure 1 The AMF (Application Function) shown sends the operation result to the operation requester. The operation result is obtained by the terminal executing the corresponding operation according to the operation instruction.
[0159] like Figure 1 As shown, when an operation requester requests to operate on a terminal, it can send operation instructions to the terminal through core network equipment (such as access and mobility management function (AMF) equipment) or access network equipment. Operation instructions may include, but are not limited to, performing operations such as acquiring tag information, inventory operations (or storage operations), read operations, write operations, invalidation operations, and interacting with tag information. An AMF equipment is an example of a mobility management device. Operation instructions may include area location information, terminal identification information, etc. When the access network equipment receives the operation instruction, it sends the operation instruction to the terminal. The terminal acquires or sends corresponding information according to the operation instruction. For example, when the operation instruction is an inventory instruction or an instruction to perform an inventory operation, the terminal sends its identification information. As another example, when the operation instruction is a read instruction or an instruction to perform a read operation, the terminal sends the data information stored in its storage area. As yet another example, when the operation instruction is a write instruction or an instruction to perform a write operation, the terminal stores the data information to be written to the terminal included in the operation instruction into the terminal's storage area. Access network devices receive information sent by terminals and then transmit that information to the operation requester through core network devices. The operation requester can send instructions to the access network devices via control plane channels; for example, the operation requester can send instructions to the access network devices through control plane devices. Control plane devices may include mobility management devices, network open function devices, session management devices, policy control devices, unified data management devices, unified data storage devices, etc. Figure 1 Taking the control plane device as an example of a mobile management device. Figure 1As shown: The operation requester sends instructions to the AMF; in this case, the operation requester can be understood as an application function (AF), server, passive IoT application function (P-IoT AF), or passive IoT server. In one possible implementation, the P-IoT AF sends instructions to the AMF. In another possible implementation, the P-IoT AF sends instructions to the AMF through a control plane device. This control plane device can be a network exposure function (NEF), session management function (SMF), policy control function (PCF), unified data management (UDM), or unified data repository (UDR). Furthermore, the operation requester can also send instructions to the access network device through the user plane channel. In one possible implementation, the operation requester sends instructions to the reader through a user plane function (UPF). Another possible implementation involves the requesting party sending instructions to the reader through user plane equipment and other access network equipment, such as radio access network (RAN) equipment. In this case, the reader can be a pole station, an integrated access and backhaul (IAB) node, a terminal device, etc.
[0160] Terminal operation
[0161] The requesting party can perform various terminal operations on the terminal. Several common terminal operations are listed below.
[0162] Inventory checking (also known as inventory management) involves taking stock of the current number of terminals, or obtaining their identification information. Each terminal has its own identifier. These identifiers can be assigned by the enterprise or a third-party entity (i.e., written into the terminal during production or manufacturing), or by the operator. In one possible implementation, the terminal identifier can be a globally unique code, such as an electronic product code (EPC), or it can be a temporary identifier or a non-globally unique identifier. During the inventory process, the requesting party can issue an inventory instruction to the reader. Typically, the inventory instruction includes information such as the terminal's identification range, the reader's identifier, and location information. Upon receiving the inventory instruction, the reader will perform an inventory check on the corresponding terminals according to the instruction and send the terminal's identification information to the requesting party. Alternatively, the requesting party can send an instruction to the reader, which will then send the instruction to the corresponding terminal. The terminal, recognizing the instruction as part of an inventory check, will send its identification information to the reader. The reader will then send the terminal's identification information to the requesting party.
[0163] A read operation is the process of reading data from a terminal. A terminal may have storage capabilities, and its storage area can store data. If a requesting party wants to perform a read operation on the terminal, it sends a read command to the reader. The reader then performs the read operation according to the command, retrieving data from the terminal's storage area and sending the data back to the requesting party.
[0164] A write operation is the act of writing data to the terminal. The requesting party can send a write command to the reader, which then performs the write operation on the terminal, writing data to the terminal's storage area according to the command.
[0165] A failure operation disables a terminal. The requesting party can send a failure command to the reader, which may include a terminal identifier (i.e., the identifier of the terminal to be disabled). The reader performs the failure operation on the terminal according to the command. After the operation is completed, the terminal is disabled and can no longer be inventoried or subjected to other operations. In this application, the terminal is exemplified by a tag. For example, a failure operation can disable a tag, and the failure command may include a tag identifier (i.e., the identifier of the tag to be disabled).
[0166] Obtaining tag information can be understood as a higher-level description of the various operations mentioned above (such as the higher-level description of inventory and read operations). It does not distinguish whether the operation requester is inventorying the terminal or reading terminal data. This operation will obtain terminal information, which may be the terminal's identification information or information stored in the terminal's storage area.
[0167] The message interaction operation with the terminal can be understood as a higher-level description of the various operations mentioned above. After receiving the instruction sent by the operation requester, the reader interacts with the terminal in terms of information or messages and sends information from the terminal back to the operation requester. This operation mainly applies to situations where the reader does not view the instruction content but only forwards messages sent by the operation requester to the terminal and messages sent by the terminal to the operation requester. Therefore, in this scenario, the operation performed by the reader on the terminal can be understood as a message interaction operation with the terminal.
[0168] Several possible architectures for passive Internet of Things
[0169] When the 3rd generation partnership project (3GPP) network supports passive IoT, it needs to support the transmission of passive IoT commands. Figure 2A , Figure 2B , Figure 2C The diagram illustrates three architectures for 3GPP networks supporting P-IoT. Figure 2A The diagram illustrates the architecture of technical path 1 for 3GPP networks supporting P-IoT. Figure 2B This diagram illustrates the architecture of technology path 2 for 3GPP networks supporting P-IoT. Figure 2C This diagram illustrates the architecture of technology path 3 for supporting P-IoT in 3GPP networks.
[0170] For technical path 1, instructions can be transmitted via user plane connection. Figure 2A The slashed areas in the diagram represent user plane connections or user plane channels, with N2, N3, N4, N6, and N11 all indicating interfaces. For example, the RAN and UPF communicate through the N3 interface, or it can be understood that the RAN and UPF have established an N3 tunnel. Another example is that the interface between the UPF and the data network is N6. In one possible implementation, the reader establishes a user plane connection, and the operation requester (e.g., a server) sends instructions to the reader through the user plane connection. The reader can be a terminal device, a radio access network device, a base station, a microcell, an integrated access and backhaul (IAB) station, a pole station, etc. Figure 2A The following is an example using a reader as an access network device.
[0171] For technical path 2, instructions can still be transmitted via user plane connection. Figure 2B The slashed area in the text represents a user plane connection or user plane channel. Figure 2BIn this context, N2, N3, N4, N6, and N11 all represent interfaces. For example, the RAN and UPF communicate through the N3 interface, or it can be understood that the RAN and UPF have established an N3 tunnel. Another example is that the interface between the UPF and the data network is N6. Unlike technical path 1, the reader establishes a user plane connection with the user plane device, and the user plane device establishes a connection with the operation requester (e.g., a server). That is, the reader does not establish a session at the data network level. For example, if server 1 is located in data network (DN) 1, and server 2 is located in data network 2, in technical path 1, the reader needs to establish two sessions to connect to data network 1 and data network 2 respectively. In technical path 2, the reader only needs to establish one user plane connection with the same user plane device, which then establishes connections with both server 1 and server 2. The advantage of technical path 2 is that when the server needs to send instructions to multiple access network devices, and multiple readers are all served by the same user plane device, in technical path 1, the server needs to send multiple instructions to that user plane device; while in technical path 2, the server only needs to send one instruction to the user plane device, which then sends instructions to multiple readers. In technical path 2, the reader can be a terminal device, or a wireless access network device, base station, microcell, integrated access and backhaul (IAB) station, pole station, etc. Figure 2B The following is an example using a reader as an access network device.
[0172] For technical path 3, the instruction transmission method can be through the control plane channel, that is, the server (or application function) sends instructions to the AMF through the NEF. Figure 2C In this context, N2, N3, N4, and N11 all represent interfaces. For example, the RAN and UPF communicate through the N3 interface, or it can be understood that the RAN and UPF have established an N3 tunnel. The AMF sends this instruction to the access network device. After the access network device completes information exchange with the terminal, it sends information (such as information from the terminal) to the AMF. The AMF sends information to the server through the NEF. Figure 2C The following example illustrates the process using a reader as an access network device. When the reader is a terminal device, in technical path 3, the instruction transmission method can be that the server (or application function) sends instructions to the AMF via the NEF. The AMF then sends the instruction to the reader through the access network device.
[0173] 3GPP networks support passive IoT operating models.
[0174] The business models for passive Internet of Things (IoT) supported by 3GPP networks established by operators may include the following:
[0175] (1) Operators build independent networks for enterprises, which support passive Internet of Things (IoT). Operators profit by charging enterprises for site construction fees.
[0176] (2) Operators can establish independent or non-independent networks for enterprises, which support passive IoT. Operators charge enterprises through contracts or packages. For example, an operator can sign a contract with an enterprise for 100 yuan per month, allowing the enterprise to use 10,000 terminals (e.g., tags).
[0177] (3) Operators may have other business models, and this application does not restrict the operator's business model. Except for the first business model in which the operator does not need to obtain the terminal used by the enterprise, for other situations where the operator needs to obtain the terminal used by the enterprise or where the operator needs to manage the terminal, access authentication, billing, etc., the operator needs to obtain the terminal's identification information in order to manage the terminal.
[0178] Terminal registration process
[0179] In this application, the terminal may be referred to as terminal equipment or user equipment (UE), and UE will be used to refer to the terminal thereafter. Figure 3 This is an example of a UE registration process provided in an embodiment of this application. Figure 3 As shown, a possible UE registration process is as follows:
[0180] 1. The UE sends a registration request message to the RAN.
[0181] The registration request message may include the registration type and the UE's identification information. The UE's identification information may include one or more of the following: a subscription concealed identifier (SUCI), a globally unique temporary UE identity (5G-GUTI), or a permanent equipment identifier (PEI).
[0182] The registration types are as follows:
[0183] Initial registration: The registration process initiated when the UE is in the deregistration state;
[0184] Mobility registration update: A registration process initiated by a UE when it needs to move.
[0185] Periodic registration update: A registration process initiated when the UE is in the registration state due to the expiration of the periodic registration update timer;
[0186] Emergency registration: A registration process initiated when a UE is in a service-restricted state.
[0187] For UE identification information, if the UE has a valid 5G-GUTI (a temporary identity identifier assigned by the AMF serving it), it carries the 5G-GUTI in the registration request; if the UE does not have a valid 5G-GUTI, it carries the SUCI. In emergency registration, if the UE does not have a valid 5G-GUTI and does not have a SUPI (i.e., no SUCI, where SUCI is an encrypted SUPI), it carries the PEI.
[0188] 2. Select AMF for RAN.
[0189] 3. The RAN forwards the registration request message sent by the UE to the AMF.
[0190] 4. The AMF selects a suitable AUSF for authentication and other security procedures; the UE, AMF, AUSF, and UDM interact to complete authentication and other security procedures.
[0191] 5. After the UE and the network side successfully authenticate each other, the AMF and UDM interact to obtain the UE's subscription data.
[0192] 6. AMF sends an N2 message to RAN.
[0193] The N2 message may include a NAS message that the RAN needs to forward to the UE. This NAS message may include a registration acceptance message (NAS message) sent by the AMF to the UE.
[0194] 7. The RAN forwards the registration acceptance message sent by the AMF to the UE.
[0195] When an operation requester performs terminal operations, it needs to identify the terminal using its identifier so that the terminal being operated on can determine whether the instruction corresponds to itself. Therefore, the operation requester needs to use a terminal identifier to identify the terminal. In this application, the identifier used by the operation requester to identify the terminal is called the terminal application identifier (or terminal application identifier). 3GPP networks support passive IoT. If the 3GPP network wants to perform access authentication, management, or billing for terminals, it also needs to obtain the terminal's identification information. In this application, the identification information used by the network to identify the terminal can be called the terminal network identifier (or terminal network identifier). In one possible implementation, the application identifier and network identifier of the same terminal can be the same or different. In another possible implementation, the enterprise (or operator) allocates the terminal's application identifier and / or network identifier. Since enterprises may have security and privacy concerns and do not want the network to obtain the terminal's application identifier, one possible implementation is that the terminal's application identifier and network identifier are different, with the application identifier allocated by the enterprise and the network identifier allocated by the operator. If operators need to obtain terminal identification information to manage terminals, how to prevent enterprises from misusing tags (e.g., different terminals using the same network identifier to access the network, resulting in an enterprise being able to use more than 10,000 tags per month when only 10,000 tags can be used) is a problem that needs to be considered and solved. In this application, the entity corresponding to the enterprise is the equipment that provides services to the enterprise, such as a server or application function; the entity corresponding to the operator is the equipment that provides services to the operator, such as a business and operation support system (BOSS), a server, or core network equipment. It can be understood that when an enterprise allocates application identifiers and / or network identifiers to terminals, it means that the operation requesting party (e.g., a server or application function) allocates application identifiers and / or network identifiers to terminals; when an operator allocates application identifiers and / or network identifiers to terminals, it means that the operator allocates application identifiers and / or network identifiers to terminals through its corresponding equipment (e.g., servers, business and operation support systems, or core network equipment).
[0196] In this application, "enterprise" can be understood as a third party, application provider, service provider, entity outside of the core network or network or mobile network.
[0197] Since the requesting party and the terminal need to communicate through core network equipment, it is necessary to study a solution for terminal access management. Examples of issues involved in terminal access management include: 1. How to reasonably allocate terminal identifiers, such as how to allocate network identifiers and / or application identifiers; 2. Who allocates the terminal's network identifiers and / or application identifiers; 3. How to prevent the theft of terminal identifiers; 4. How to authenticate and authorize terminals; 5. Who writes the terminal identifiers.
[0198] This application provides several possible schemes for how to assign terminal identifiers.
[0199] Option 1: The operator pre-configures the application identifier for the terminal.
[0200] The operator assigns an application identifier to the terminal (similar to an operator assigning a mobile phone number). In this application, the operator can be replaced by a network, operating system, server, or core network equipment. Alternatively, the requesting party assigns the application identifier to the terminal and notifies the operator. The operator writes the identifier to the terminal (similar to an operator issuing a SIM card) or an authorized enterprise writes the identifier to the terminal. When writing the identifier to the terminal, security parameters (or security context) can be written. Security parameters can include, but are not limited to, pre-configured keys (e.g., used for identifier encryption / decryption or verification operations) or hash parameters (e.g., used for authentication or authorization); the network authenticates the terminal's application identifier (e.g., by authenticating a random number and the hashed verification value (AUTH value)). In this application, the network can refer to the core network and / or access network. The authentication process is performed by writing security parameters to the terminal. The terminal can send a terminal identifier (or an encrypted terminal identifier). The network records the correspondence between the terminal's application identifier and the terminal identifier. One terminal's application identifier can only correspond to one terminal identifier, thereby preventing multiple terminals from using the same identifier, i.e., preventing the theft of the terminal's identifier. In one possible implementation, the terminal is a tag, the terminal identifier is a tag identifier (TID), and the encrypted terminal identifier is a concealed tag identifier (CTID). The TID is a unique identifier for the tag. During tag production, the TID and / or CTID are written to the tag's storage area, which is read-only. The TID can be used to identify the tag itself and can be different from the tag's application identifier.
[0201] Option 2: The enterprise or the party requesting the operation allocates the application identifier of the terminal, and the operator does not pre-configure the application identifier of the terminal (i.e., the operator does not obtain the application identifier of the terminal in advance).
[0202] Enterprises write identifiers to terminals, or operators authorize enterprises to write identifiers to terminals. In one possible implementation, the terminal is a tag, and writing an identifier to the terminal means writing the tag's identification information into the tag. Security parameters (or security context) can be written when writing the identifier to the terminal. The terminal is authenticated by writing security parameters when writing the identifier to the terminal. The terminal identifier is sent during terminal registration; the network records the terminal identifier and can monitor the number of terminals used by the enterprise based on the terminal identifier.
[0203] Option 3: The enterprise or operation requester assigns the application identifier to the terminal, and the operator assigns the network identifier to the terminal.
[0204] The network identifier assigned to a terminal by the operator can be written into the terminal by an authorized enterprise or operation requester. Security parameters (or security context) can be written when writing the identifier to the terminal. Authorized terminals are authenticated by writing security parameters when writing the identifier to the terminal. The terminal identifier can be sent during terminal registration, and the network records the terminal identifier. The number of terminals used by an enterprise is monitored based on the terminal identifier to prevent the terminal identifier from being stolen.
[0205] Option 4: Enterprises or operation requesters assign application identifiers to terminals, while operators assign network identifiers to terminals through online contract signing.
[0206] In this application, online signing can refer to a terminal using a default credential to access the network. After network authentication, the network sends signing data or credentials to the terminal for subsequent network access (i.e., it can be understood as obtaining signing data online). One possible implementation is that the terminal uses an identifier or credential at the enterprise or operation requester level, or a default credential, to access the network. After successful authentication, the network sends a network identifier to the terminal. The terminal then uses the obtained network identifier to access the network. When writing the identifier to the terminal, security parameters (or security context) can be written. The network authenticates the enterprise-level identifier (e.g., the AUTH value obtained by calculating a random number and a key), thus enabling network authentication of the terminal.
[0207] When a terminal performs an online contract signing, it needs to send an enterprise identifier or a default identifier. The network assigns a network identifier based on the enterprise identifier or the default identifier. The default identifier can be any identifier negotiated or agreed upon by the terminal and the network. During terminal registration, a network identifier needs to be sent, and the network records this identifier. The network records or monitors the number of terminals used by the enterprise (or operation requester) based on the network identifier, thereby preventing the number of terminals used by the enterprise (or operation requester) from exceeding the allowed number (i.e., the quantity threshold). An example of the network recording or monitoring the number of terminals used by an enterprise (or operation requester) based on the network identifier is that UDM or AMF records or monitors the number of terminals used by an enterprise (or operation requester) based on the network identifier.
[0208] To address the problem of terminal access management, this application provides a terminal management method. Using this method, terminal access management can be achieved, preventing the theft of terminal identifiers. The terminal management method provided in this application is applicable to… Figures 2A to 2C The passive IoT architecture shown is also applicable to other architectures for managing terminal access. This application uses a 5G network as an example to illustrate this solution. It should be noted that the terminal management method provided in this application is also applicable to 4G, 6G networks, etc.
[0209] The system architecture of 5G networks involves core network equipment, such as AMF, AUSF, and UDM, as well as servers, such as operation requesters (i.e., servers that issue commands or application functions AF). The equipment involved in this application is described below.
[0210] Mobility Management Entities (AMIs): Primarily used for mobility management and access management, MMEs can implement functions other than session management, such as lawful monitoring and access authorization / authentication. An MME (also known as Access and Mobility Management Equipment, Access and Mobility Management Function Entity, Access and Mobility Management Function Network Entity, Mobility Management Entity, or Mobility Management Entity) is a type of core network equipment. MMEs manage user equipment access control and mobility. An example of an MME is the AMF (Access and Mobility Management Function) element in 5G. In practical applications, the AMF element includes the access and mobility management functions of the MME in the Long Term Evolution (LTE) network framework, and adds access management functions. Specifically, the AMF element can be responsible for user equipment registration, mobility management, tracking area update procedures, reachability detection, selection of session management entities, and mobility state transition management. For example, in 5G, the Access and Mobility Management element can be an Access and AMF element. In future communications, such as 6G, the Access and Mobility Management (AMF) network element can still be an AMF network element, or it may have other names; this application does not limit this. When the AMF network element is an AMF network element, it can provide Namf services. For example, the AMF can provide the N1N2 message transfer service (Namf_Communication_N1N2MessageTransfer service), through which other core network elements can send N1 messages to terminal devices or N2 messages to access network devices.
[0211] User plane network elements are used for packet routing and forwarding, as well as quality of service (QoS) processing of user plane data. In 5G communication systems, these user plane network elements can be user plane function (UPF) network elements, including intermediate user plane function (I-UPF) network elements and PDU session anchor user plane function (PSA-UPF) network elements. In future communication systems, user plane network elements can still be UPF network elements, or they can have other names; this application does not limit this. A UPF network element (also called a user plane device) is a type of core network equipment. A UPF network element is responsible for forwarding and receiving user data in user equipment. A UPF network element can receive user data from the data network and transmit it to the user equipment through access network elements. User plane function network elements can also receive user data from user equipment through access network elements and forward the user data to the data network. The transmission resources and scheduling functions in the user plane function network element that provide services to the user equipment are managed and controlled by the session management function network element.
[0212] Session management network elements are primarily used for session management, allocation and management of Internet Protocol (IP) addresses for terminal devices, selection of manageable terminal device plane functions, policy control, and endpoints for charging function interfaces, as well as downlink data notification. In 5G communication systems, this session management network element can be a session management function (SMF) network element, which may include intermediate session management function (I-SMF) network elements and anchor session management function (A-SMF) network elements. In future communication systems, the session management network element may still be an SMF network element, or it may have other names; this application does not limit this. An SMF network element (also called a session management device) is a type of core network equipment. SMF network elements can be used to manage user equipment sessions (including session establishment, modification, and release), select and reselect user plane function network elements, allocate Internet Protocol (IP) addresses for user equipment, and control quality of service (QoS). For example, in 5G, the session management network element can be a session management function (SMF) network element. In future communication systems, such as 6G, the session management network element can still be an SMF network element, or it may have other names; this application does not limit this. When the session management network element is an SMF network element, the SMF network element can provide NSMF services.
[0213] Authentication service network element: Used for authentication services, generating keys to achieve two-way authentication of terminal devices, and supporting a unified authentication framework. In 5G communication systems, this authentication service network element can be an authentication server function (AUSF) network element. In future communication systems, the authentication server function network element can still be an AUSF network element, or it can have other names; this application does not limit this.
[0214] Application function network elements: Application function network elements can interact with the 5G system to access network open function network elements or interact with the policy framework for policy control, etc. In the 5G communication system, this application function network element can be an application function (AF) network element. In future communication systems, the application function network element can still be an AF network element, or it can have other names; this application does not limit this.
[0215] Network Exposure Function (NEF) network elements: These are used to provide customized network exposure functions. In 5G communication systems, this NEF network element can be a Network Exposure Function (NEF) network element. In future communication systems, this NEF network element can still be a NEF network element, or it can have other names; this application does not limit this. 5G communication systems can also use NEF network elements to expose 5GC-supported capabilities to external application function network elements, such as providing small data transmission capabilities. The NEF network element (also called a network exposure device) is a type of core network equipment. The NEF network element can be used to enable 3GPP to securely provide network service capabilities to third-party AFs (e.g., servicescapability servers (SCS), application servers (AS), etc.). For example, in 5G, the network exposure function (NEF) network element can be a Network Exposure Function (NEF) network element. In future communication systems, such as 6G, the network exposure function (NEF) network element can still be a NEF network element, or it can have other names; this application does not limit this. When the network open element is a NEF element, the NEF element can provide Nnef services to other network function elements.
[0216] Data management network element: Used for handling terminal device identification, access authentication, registration, and mobility management. In a 5G communication system, this data management network element can be a unified data management (UDM) network element or a unified data repository (UDR) network element. In future communication systems, unified data management can still be a UDM or UDR network element, or it can have other names; this application does not limit this. In the embodiments of this application, the UDM or UDR network element can refer to a user database. It can exist as a single logical repository for storing user data. UDM network element (also called unified data management device, data management device, unified data management entity). In a 5G communication system, the unified data management network element can be a UDM network element or a unified data management device. In future communication systems, the unified data management network element can still be a UDM network element, or it can have other names; this application does not limit this. The unified data management device can be a core network device. The unified data management device can be a control plane device. The UDR network element (also called a user database device, user database entity) can be understood as the naming of the unified data storage network element in the 5G architecture. The user database mainly includes the following functions: storage and retrieval functions for data types such as contract data, strategy data, and application data.
[0217] User equipment (UE) can also be called terminal equipment, terminal, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, wireless communication equipment, user agent, or user device. The UE can also be a cellular phone, cordless phone, session initiation protocol (SIP) phone, wireless local loop (WLL) station, personal digital assistant (PDA), handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, in-vehicle device, wearable device, terminal device in a 5G network, or terminal device in a future evolved public land mobile network (PLMN) or non-terrestrial networks (NTN). It can also be an end device, logical entity, or smart device, such as a mobile phone or smart terminal. Furthermore, it can be a server, gateway, base station, controller, or other communication device, or an Internet of Things (IoT) device, such as tags (passive, active, semi-active, semi-passive), sensors, electricity meters, water meters, etc. The UE can also be an unmanned aerial vehicle (UAV) with communication capabilities. When the terminal is a passive, semi-passive, or semi-active terminal or tag, it can acquire energy to receive or transmit data. Energy can be acquired through radio waves, solar energy, light energy, wind energy, hydropower, thermal energy, kinetic energy, etc. This application does not limit the method of energy acquisition for passive, semi-passive, or semi-active terminals. The embodiments of this application are not limited in this respect.
[0218] Operation requester: An operation requester can be understood as a device that sends operation commands. For example, an operation requester can be a server, a P-IoT server, an application function (AF), or other devices that send operation commands. An operation requester can correspond to a certain type of user, which can include enterprises, tenants, third parties, or companies, without restriction. Here, "an operation requester corresponding to a certain type of user" means that the operation requester belongs to that type of user and is managed by that type of user.
[0219] Access network devices interact with terminals (e.g., tags) via radio frequency signals or wireless signals. It should be understood that this application does not limit the name of the access network device; it can also be named by other names. The access network device described here possesses some or all of the functions involved in the reader described in this application, such as the ability to perform the operations described in this application on the terminal (e.g., tag) (e.g., acquiring tag information, inventory operations, read operations, write operations, invalidation operations, or message interaction operations with the tag), the ability to acquire billing-related information and / or billing information, and the ability to send billing information to the charging function (CHF), etc. In one possible implementation, the access network device can send instructions from a server, application function, or core network device to the terminal (e.g., tag), or the access network device can send messages from the terminal (e.g., tag) to a server or application function. In another possible implementation, the access network device can acquire information stored in a specified terminal (e.g., tag) according to instructions issued by the server. For example, in an inventory operation (or storage operation), the access network device obtains the identification information of the terminal (e.g., a tag); this identification information can be a unique identifier for the terminal or a temporary identifier. For example, in a read operation, the access network device reads data from the terminal's storage area or sends data from the terminal's storage area to the core network device. Optionally, in situations where it is necessary to rewrite information stored in the terminal, the access network device can have a write function. For example, in a write operation, the access network device writes data to the terminal's (e.g., a tag's) storage area or forwards instructions from a server, application function, or core network device to the terminal (e.g., a tag) to write data to the tag's storage area. In addition, the access network device can also perform an invalidation operation on the terminal (e.g., a tag). After an invalidation operation is performed on the terminal (e.g., a tag), the terminal (e.g., a tag) becomes invalid, and the terminal (e.g., a tag) cannot be used for operations such as obtaining tag information, inventory operations, read operations, message interaction operations with the terminal, or write operations. In one possible implementation, "unable to obtain tag information due to terminal failure" can be understood as the access network device being unable to obtain the tag information of the failed terminal after the terminal fails. In another possible implementation, "unable to perform message interaction operations with the terminal due to terminal failure" can be understood as the access network device being unable to interact with the failed terminal after the terminal fails. In this application, the access network device can be a pole station, eNodeB, gNodeB, integrated access and backhaul (IAB) node, etc., and this application does not limit the form of the access network device. In this application, the reader can be an access network device or a terminal device. This application does not limit the form of the reader.
[0220] Before introducing some possible embodiments provided in this application, let's first give an overview of several possible methods for allocating the terminal's application identifier and / or network identifier. This way, when describing the various embodiments later, one or more of these possible methods can be directly referenced, avoiding repetition. Figure 4 Examples of several methods for allocating application identifiers for terminals provided in embodiments of this application are shown.
[0221] Method 1: The requesting party assigns the application identifier to the terminal, and the second core network device obtains the number of numbers to be issued.
[0222] The number of terminals issued can be understood as the number of terminals that the requesting party (e.g., an enterprise) is allowed to use. In one possible implementation, the terminal is a tag, and the number of terminals is either the number of tag identifiers or the number of physical tags. The difference is that the former is the number of tag identifiers; if a tag is damaged, it can be replaced with a new tag, but the tag identifier of the new tag can be the tag identifier of the original damaged tag. The latter is the tag itself, the terminal. In this embodiment, the second core network device can be a UDM, UDR, or other core network elements. Figure 4 As shown, the application identifier allocation for the terminal in Method 1 includes the following operations:
[0223] 401. The second core network device obtains the first information.
[0224] The first information may include the number of numbers released. In this application, the number of numbers released can be understood as the number of phone numbers, the number of terminals, or the number of identifiers. The number of numbers released can be interchanged with the number of identifiers, the number of terminals, the number of phone numbers, or quantity information. One possible implementation of step 401 is as follows: The second core network device receives the first information (which may be called the number release message) sent by the operator's business and operation support system (BOSS). BOSS can be replaced by other entities corresponding to the operator. That is to say, the embodiments of this application do not limit the method by which the operator sends the first information to the second core network device.
[0225] In one possible implementation, the first information may further include an enterprise identifier. The enterprise identifier is used to identify the enterprise. Since an enterprise can deploy an independent network, the second core network device (e.g., UDM or UDR) can serve only that enterprise; therefore, the enterprise identifier is an optional parameter. For public network scenarios or when the core network device serves multiple enterprises, the enterprise identifier can be used to identify different enterprises. In this application, the enterprise identifier can be understood or replaced by an operation requester identifier or a user identifier. The operation requester identifier may include one or more of the following: address information, identification information, port number, service identifier, and transaction number.
[0226] 402. Number of numbers allocated for the second core network equipment configuration.
[0227] The second core network equipment is configured with a number of phone numbers to be issued, so that access management can be performed based on this number. Performing access management based on the number of phone numbers issued may include one or more of the following: assigning network identifiers to terminals based on the number of phone numbers issued; assigning application identifiers to terminals based on the number of phone numbers issued; determining the number of terminals that the operation requester is allowed to use based on the number of phone numbers issued; and determining whether the number of terminals already used by the operation requester exceeds the number of terminals that the operation requester is allowed to use based on the number of phone numbers issued.
[0228] 403. The operation requester obtains the second information.
[0229] The second information includes the number of numbers released. One possible implementation of step 403 is as follows: The operation requester receives the second information (e.g., a number release message) sent by the operator's BOSS system. The BOSS can be replaced by other entities corresponding to the operator. That is, this application embodiment does not limit the method by which the operator sends the second information to the operation requester. The first and second information can be the same or different. For example, both the first and second information are number release messages and both contain the number of numbers released. Another example is that the first information contains the number of numbers released and the enterprise identifier, while the second information contains the number of numbers released but does not contain the enterprise identifier. In method one, the order of steps 401 and 403 is not limited. It can be understood that the operations performed by the second core network device (steps 401 and 402) are independent of the operations performed by the operation requester (steps 403 and 404).
[0230] 404. The operation requester assigns the application identifier of the terminal.
[0231] In one possible implementation, the requesting party allocates application identifiers for terminals based on the number of numbers to be released. For example, if the number of numbers to be released is 10,000, the requesting party allocates application identifiers for 10,000 terminals, with each terminal corresponding to one application identifier.
[0232] 405. The first core network device receives quantity information and / or first identification information from the second core network device.
[0233] The first core network device can be an AMF (Application Management Function). The first identification information includes one or more of the following: the terminal identifier, the encrypted terminal identifier, the terminal application identifier, the terminal network identifier, and the operation requester identifier. The operation requester identifier identifies the operation requester. Quantity information may include the number of terminals allowed to be used by the operation requester (which can be understood as the number of phone numbers issued).
[0234] Method 2: The operation requester assigns the terminal's application identifier, and the operator assigns the terminal's network identifier and sends the terminal's network identifier to the operation requester, or the operation requester assigns the terminal's network identifier.
[0235] 411. The second core network device obtains the first information.
[0236] Step 411 can be referred to step 401. The first information may also include the enterprise identifier or the terminal's network identifier. In one possible implementation, the terminal's network identifier is assigned by the BOSS system, in which case the first information may also include the terminal's network identifier. In another possible implementation, the terminal's network identifier is assigned by a second core network device (e.g., UDM or UDR), in which case the first information does not need to include the terminal's network identifier.
[0237] 412. Number of second core network equipment configurations and number of numbers issued.
[0238] Step 412 can be found in step 402.
[0239] 413. The operation requester obtains the second information.
[0240] Step 413 can be found in step 403. The second information may also include the terminal's network identifier. If the terminal's network identifier is assigned by the BOSS system, the second information will also include the terminal's network identifier. If the terminal's network identifier is assigned by a second core network device (e.g., UDM or UDR), the second information does not need to include the terminal's network identifier.
[0241] 414. The operation requester assigns the application identifier of the terminal.
[0242] Step 414 can be found in step 404.
[0243] 415. Network identifier assigned to the terminal by the second core network equipment.
[0244] One possible implementation of step 415 is as follows: The second core network device allocates network identifiers for terminals based on the number of numbers issued. The terminal network identifier allocated by the second core network device can be the terminal network identifier allocated by the second core network device for the operation requester, that is, the network identifier allocated to the terminal of the operation requester.
[0245] Step 415 can be replaced by: The first information includes the network identifier of the terminal, and the second core network device obtains the network identifier of one or more terminals based on the first information.
[0246] 416. The second core network device sends the terminal's network identifier to the operation requester.
[0247] Steps 415 and 416 are optional, not mandatory. It is understood that if the terminal's network identifier is assigned by the second core network device, the second core network device can assign the terminal's network identifier based on the number of numbers issued, so as to perform access management based on the terminal's network identifier. If the terminal's network identifier is assigned by the second core network device, after executing step 415, the second core network device sends the assigned terminal network identifier to the operation requester, i.e., executes step 416. In one possible implementation, the second core network device can send the assigned terminal network identifier to the operation requester via NEF. If the terminal's network identifier is assigned by the operator, both the first and second information can contain the network identifier assigned by the operator to the operation requester's terminal. In this case, the second core network device can obtain the terminal's network identifier based on the first information, and the operation requester can obtain the terminal's network identifier based on the second information. That is, if the terminal's network identifier is assigned by the operator, the second core network device does not need to assign the terminal's network identifier, nor does it need to execute step 416.
[0248] 417. The first core network device receives quantity information and / or first identification information from the second core network device.
[0249] Step 417 can be found in step 405.
[0250] Method 3: The operation requester allocates the application identifier of the terminal, and the second core network device obtains the number of numbers issued and the application identifier of the terminal allocated by the operation requester.
[0251] 421. The second core network device obtains the first information.
[0252] Step 421 can be found in step 401.
[0253] 422. Number of devices configured and issued for the second core network.
[0254] Step 422 can be found in step 402.
[0255] 423. The operation requester obtains the second information.
[0256] Step 423 can be found in step 403.
[0257] 424. The operation requester assigns the application identifier of the terminal.
[0258] Step 424 can be found in step 404.
[0259] 425. The second core network equipment obtains the application identifier of the terminal.
[0260] Step 425 can be implemented as follows: The second core network device receives the application identifiers of the terminals allocated by the operation requester according to the number of numbers issued. Accordingly, the operation requester sends the allocated terminal application identifiers to the second core network device. In one possible implementation, the operation requester sends a list of terminal application identifiers to the second core network device, i.e., a list including the application identifiers of one or more terminals. In another possible implementation, the operation requester sends a message to the second core network device containing one or more terminal application identifiers. Optionally, the message containing terminal application identifiers sent by the operation requester to the second core network device may also include an enterprise identifier. The enterprise identifier is used to identify the enterprise. Since an enterprise can deploy an independent network, the second core network device can serve only that enterprise; therefore, the enterprise identifier is an optional parameter. For public network scenarios or when the second core network device serves multiple enterprises, the enterprise identifier can be used to identify different enterprises. In one possible implementation, the operation requester sends a message including the application identifiers of one or more terminals to the second core network device via NEF.
[0261] 426. Application identifier for the terminal configured in the second core network equipment.
[0262] The application identifier configured by the second core network device can be either a mapping between the terminal identifier and the terminal application identifier stored in the second core network device, or it can be configured as a terminal application identifier available to the operation requester.
[0263] 427. The first core network device receives quantity information and / or first identification information from the second core network device.
[0264] Step 427 can be found in step 405.
[0265] Method 4: The operator assigns the terminal's application identifier and sends the terminal's application identifier to the operation requester.
[0266] 431. The application identifier of the terminal assigned by the operator's BOSS system.
[0267] One possible implementation of step 431 is as follows: The operator's BOSS system allocates application identifiers for terminals based on the number of numbers issued. In other words, the operator's BOSS system allocates a corresponding number of terminal application identifiers to the operation requester based on the number of terminals allowed to be used by the operation requester.
[0268] 432. The second core network device obtains the first information.
[0269] The first information includes the number of numbers issued and the terminal application identifier. The terminal application identifier included in the first information may be the application identifier of the terminal assigned to the operation requester by the operator's BOSS system in step 431. The first information may also include the enterprise identifier. Step 432 can be referred to step 401.
[0270] 433. Configure the number of numbers issued and the application identifier of the terminal in the second core network equipment.
[0271] 434. The operation requester obtains the application identifier of the terminal.
[0272] In step 434, the application identifier of the terminal obtained by the operation requester may be the terminal application identifier assigned to the operation requester.
[0273] Step 434 can be implemented in the following way: the operation requester receives a terminal application identifier sent by the operator's BOSS system. The operation requester may also obtain one or more terminal application identifiers from the equipment providing services to the operator through other means. Optionally, the operation requester may also obtain the number of numbers issued and / or the enterprise identifier. For example, the operation requester receives second information from the operator's BOSS system, which includes one or more terminal application identifiers assigned to the operation requester by the operator. This second information may also include the number of numbers issued and / or the enterprise identifier.
[0274] Another possible implementation of step 434 is that the operation requester receives a terminal application identifier sent by the second core network device. For example, the operation requester receives second information from the second core network device, which includes one or more terminal application identifiers assigned to the operation requester by the operator. This second information may also include the number of numbers issued and / or an enterprise identifier.
[0275] 435. The first core network device receives quantity information and / or first identification information from the second core network device.
[0276] Step 435 can be found in step 405.
[0277] It should be noted that methods one to four are merely examples of several possible application identifiers and / or network identifiers for allocation terminals provided in the embodiments of this application, and not all examples.
[0278] Figure 4 Examples of several possible allocation methods for terminal application identifiers and / or network identifiers implemented by the operation requester, the BOSS system, the second core network device, and the first core network device are shown. The method flow executed by the operation requester in allocating terminal application identifiers and / or network identifiers is described separately below with reference to the accompanying drawings.
[0279] In this application, the first core network equipment can be a mobility management device, session management device, policy control device, unified data management device, unified data repository, network open function device, or user plane device; this application does not limit the type of first core network equipment. Similarly, in this application, the second core network equipment can be a mobility management device, session management device, policy control device, unified data management device, unified data repository, network open function device, or user plane device; this application does not limit the type of first core network equipment.
[0280] In this application, "terminal access to the network" can be understood as "terminal registration to the network," "terminal successful registration to the core network," or "terminal successful execution of the process." "Network accepting terminal access to the network" can be understood as "network accepting terminal registration," "network accepting terminal registration requests," "network accepting terminal registration to the network," "network accepting terminal registration procedures," "core network accepting terminal registration to the network," or "core network accepting terminal registration to the core network." "Network rejecting terminal access to the network" can be understood as "network rejecting terminal registration," "network rejecting terminal registration requests," "network rejecting terminal registration to the network," "network rejecting terminal registration procedures," "core network rejecting terminal registration to the network," or "core network rejecting terminal registration to the core network."
[0281] Figure 5 This is a flowchart illustrating a terminal management method provided in an embodiment of this application. Figure 5 As shown, the method includes:
[0282] 501. The operation requester obtains quantity information.
[0283] The quantity information indicates the number of terminals that the operation requester is allowed to use. The operation requester can obtain the quantity information by receiving quantity information sent by the BOSS system, as described in step 403.
[0284] 502. The operation requester obtains one or more terminal application identifiers based on the quantity information.
[0285] One possible implementation of step 502 is as follows: The operation requester allocates one or more terminal application identifiers based on the quantity information; wherein the number of terminal application identifiers allocated by the operation requester is the number of terminals allowed to be used by the operation requester. For example, if the number of terminals allowed to be used by the operation requester is 10,000, the operation requester allocates 10,000 terminal application identifiers, and each terminal application identifier corresponds to one terminal.
[0286] The operation requester may also perform the following operations: send an operation instruction, the operation instruction including a first terminal application identifier, which is contained within one or more terminal application identifiers; the operation instruction is used to perform an operation on the terminal corresponding to the first terminal application identifier. These operations may include inventory (or stocktaking), requesting tag information, reading, writing, invalidation, security authentication, etc. The operation requester can send the operation instruction to the terminal through core network equipment or access network equipment.
[0287] The operation requester may also perform the following operation: obtain network identification information, which includes one or more terminal network identifiers. The operation requester may obtain the network identification information by receiving one or more terminal network identifiers sent by the second core network device, or by receiving one or more terminal network identifiers from the BOSS system.
[0288] The operation requester may also perform the following operations: send one or more terminal application identifiers and / or the operation requester identifier to the core network equipment. Figure 4 The operation of sending a terminal application identifier and / or an operation requester identifier to the second core network device is an example of sending one or more terminal application identifiers and / or operation requester identifiers to the core network device.
[0289] Figure 5 The method flow described in the document is a possible example of an operation requester obtaining one or more terminal application identifiers. Figure 5 The method flow described herein refers to the method flow executed by the operation requester in Method 1, Method 2, and Method 3. Steps 501 and 502 can be replaced by: the operation requester obtaining one or more terminal application identifiers (see step 434). The operation requester obtaining one or more terminal application identifiers can be receiving one or more terminal application identifiers from the BOSS system, or it can be receiving the one or more terminal application identifiers from the core network equipment. For example, after receiving the first information from the BOSS system, the second core network equipment sends one or more terminal application identifiers to the operation requester, the first information containing the terminal application identifiers assigned to the operation requester by the operator's BOSS system.
[0290] In this embodiment of the application, the operation requester obtains one or more terminal application identifiers based on the quantity information, so that the number of obtained terminal application identifiers is less than or equal to or no more than the number of terminals allowed to be used by the operation requester.
[0291] The terminal management method provided in this application is described below with reference to the accompanying drawings.
[0292] Figure 6AA flowchart illustrating another terminal management method provided in this application embodiment. The first core network device executes... Figure 6A Before the method flow in the middle, quantity information and / or first identification information can be obtained by performing the operations executed in methods one through four. For example... Figure 6A As shown, the method includes:
[0293] 601A, the first core network device receives the first message from the terminal.
[0294] The first message is used to request access to a network, which may include a core network, an access network, or other networks, and may deploy one or more core network devices and access network devices. For example, the network the terminal requests access to may be an independent network deployed by an enterprise, a public network, or a public network integrated with a non-public network. Another example is that the network the terminal requests access to may be a network shared by multiple enterprises. The first core network device may be a mobility management device (AMF) or other devices capable of implementing terminal management functions. The first message may be a registration request message for requesting network access. The first message may be a non-access stratum (NAS) message or other protocol message; this application does not impose any restrictions.
[0295] The first core network device receiving the first message from the terminal can be the first core network device receiving the first message from the terminal forwarded by the access network device. For example, the terminal sends a registration request message (an example of the first message) to the access network device, and the first core network device receives the registration request message forwarded to it by the access network device.
[0296] In one possible implementation, the first message includes first identification information that identifies the terminal. This first identification information includes one or more of the following: a terminal identifier, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
[0297] In one possible implementation, the first message includes identification information and authentication information, which are used to execute the authentication process. The identification information includes one or more of the following: terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. The authentication information may include one or more of the following: random number, message authentication code (MAC), checksum, token, etc.
[0298] 602A. When the first core network device determines that a terminal is allowed to access the network based on the quantity information, it sends a second message to the operation requester to which the terminal belongs.
[0299] The quantity information includes the number of terminals allowed to be used by the operation requester to which the terminal belongs, i.e., the number of numbers issued. The number of terminals allowed to be used by the operation requester can be understood as the number of terminals that the operation requester is permitted to use. The second message may contain first identification information, which includes one or more of the following: the terminal identifier, the encrypted terminal identifier, the terminal application identifier, the terminal network identifier, and the operation requester identifier. For example, the second message is used to provide the operation requester with the identification information of the terminal accessing the network; or the second message serves as a response message for the operation requester's request to obtain terminal information.
[0300] In one possible implementation, the first core network device is an AMF (Active Network Provider). When the first core network device determines whether a terminal is allowed to access the network based on the quantity information, it sends a second message to the operation requester to which the terminal belongs via the NEF (Non-Active Network Provider). For example, the second message is the operation result obtained by the terminal executing the operation instruction from the operation requester.
[0301] One possible implementation of step 602A is as follows: When the number of terminals connected to the network among the terminals corresponding to the operation requester is less than or equal to a quantity threshold, the core network device determines that the terminal is allowed to access the network; the quantity threshold is the number of terminals allowed to be used by the operation requester. The terminal corresponding to the operation requester refers to a terminal belonging to the operation requester or a terminal allowed to be used by the operation requester. The number of terminals connected to the network among the terminals corresponding to the operation requester can be understood as the number of terminals belonging to the operation requester that have already connected to the network. Assume there are F terminals belonging to the operation requester, H of which have already connected to the network, and the number of terminals connected to the network among the terminals corresponding to the operation requester is H, where F and H are both integers greater than or equal to 0.
[0302] In this embodiment, when the first core network device determines that a terminal is allowed to access the network based on quantity information, it sends a second message to the operation requester to which the terminal belongs. That is, before sending the second message, the first core network device needs to determine whether a terminal is allowed to access the network based on quantity information, rather than directly allowing the terminal to access the network. By determining whether a terminal is allowed to access the network based on quantity information, the first core network device avoids a situation where the number of terminals connected to the network corresponding to the operation requester is greater than or equal to the number of terminals allowed to be used by the operation requester.
[0303] Figure 6B A flowchart illustrating another terminal management method provided in this application embodiment. The first core network device executes... Figure 6A Prior to the method flow, quantity information and / or first identification information can be obtained by performing the operations executed in methods one through four. Figure 6B The method flow is as follows Figure 6AOne possible implementation of the method described in [the document]. For example... Figure 6B As shown, the method includes:
[0304] 601B, The first core network device receives the first message from the terminal.
[0305] Step 601B can be found in step 601A.
[0306] 602B. When the first core network device determines whether a terminal is allowed to access the network based on the quantity information, it sends a fourth message to the second core network device.
[0307] The second core network device can be a UDM, UDR, or other core network device. For example, the first core network device sends a fourth message to the second core network device through another core network device (such as AUSF).
[0308] In one possible implementation, the fourth message is used to request an authentication or authorization process to be performed on the terminal. In this application, authentication and authorization can be the same concept and can be interchanged. The authentication process can be a one-way authentication of whether the terminal is a trusted or authorized terminal; or the authentication process can be a one-way authentication of whether the terminal authenticates the network or the requesting party is a trusted network or the requesting party; or the authentication process can be a two-way authentication, i.e., the authentication process includes both the terminal authenticating the network or the requesting party and the network or the requesting party authenticating the terminal.
[0309] In one possible implementation, the fourth message includes second identification information and authentication information. The second identification information and the authentication information are used to execute the authentication process. The second identification information includes one or more of the following: terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. The authentication information may include a random number, MAC address, etc. In one possible implementation, the fourth message further includes indication information; the indication information indicates that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication from the terminal to the network or operation requester, or one-way authentication from the network or operation requester to the terminal. In one possible implementation, the indication information indicates that the authentication process is an authentication process applied to passive Internet of Things (IoT). For example, the fourth message is an authentication request message, and the indication information contained in this fourth message indicates that the authentication is an authentication process applied to passive IoT.
[0310] In one possible implementation, after receiving a first message from a terminal, the first core network device determines the operation requester to which the terminal belongs based on third identification information included in the first message. The third identification information includes one or more of the following: terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. The first core network device determines the operation requester to which the terminal belongs in order to determine whether to allow the terminal to access the network based on quantity information. For example, the first core network device determines the operation requester to which the terminal belongs based on the third identification information and a first correspondence; the first correspondence indicates that the terminal belongs to the operation requester. Optionally, the first correspondence includes a correspondence between the terminal's application identifier (terminal identifier or network identifier) and the operation requester identifier, where the operation requester identifier is the identifier of the operation requester. The first core network device may configure or store one or more correspondences between terminals and their respective operation requesters, and the first core network device can determine the operation requester to which a terminal belongs based on this correspondence. For example, the first core network device determines a second correspondence based on the operation instruction from the operation requester, indicating that the terminal belongs to the operation requester; the first core network device then determines the operation requester to which the terminal belongs based on the third identification information included in the first message and the second correspondence. The operation instruction may include a first identifier of the terminal, which may be any one of the following: a terminal identifier, an encrypted terminal identifier, a terminal application identifier, or a terminal network identifier.
[0311] 603B, The first core network device receives the fifth message from the second core network device.
[0312] The fifth message indicates whether the requesting party successfully received or failed to receive the terminal's identification information, or whether the terminal's authentication process passed or failed. The fifth message can notify the terminal of its authentication result, allowing the terminal to perform corresponding subsequent operations based on that result. The first core network device receives the fifth message from other core network devices. The second core network device can be a UDM, UDR, or other core network device. In one possible implementation, the first core network device is an AMF, which receives fifth messages from other core network devices (e.g., a UDM or AUSF). For example, the first core network device is an AMF, which receives fifth messages from a UDM (corresponding to the second core network device) via an AUSF or receives fifth messages from an AUSF (corresponding to the second core network device).
[0313] In one possible implementation, steps 602B and 603B can be replaced by: the first core network device performing an authentication process on the terminal based on the first message. The first message includes third identification information and authentication information, which are used to execute the authentication process. The third identification information includes one or more of the terminal's terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. For example, the first message includes the terminal's application identifier, a random number, and a message authentication code; the first core network device retrieves security parameters based on the terminal's application identifier and verifies the message authentication code based on the security parameters and the random number; if they match, the terminal is considered to have passed authentication (or is considered a trusted terminal); if they do not match, the terminal is considered to have failed authentication (or is considered an untrusted terminal). The security parameters can be a key or a hash algorithm. If it is a key, the message authentication code can be the value of the random number encrypted using the key. If it is a hash algorithm, the message authentication code can be the value obtained by processing the random number using the hash algorithm.
[0314] 604B. The first core network device sends the sixth message to the terminal.
[0315] The fifth message indicates that the operation requester has successfully received the terminal's identification information or that the authentication process has passed, and the sixth message indicates that the terminal is accepted to access the network. Alternatively, if the fifth message indicates that the operation requester has not successfully received the terminal's identification information or that the authentication process has failed, the sixth message indicates that the terminal is denied access to the network. One possible implementation of step 604B is as follows: The first core network device sends a sixth message to the terminal based on the fifth message. If the fifth message indicates that the operation requester has successfully received the terminal's identification information or that the terminal's authentication process has passed, the first core network device sends a sixth message to the terminal indicating that the terminal is accepted to access the network. If the fifth message indicates that the operation requester has not successfully received the terminal's identification information or that the terminal's authentication process has failed, the first core network device sends a sixth message to the terminal indicating that the terminal is denied access to the network. In other words, the first core network device can send a corresponding sixth message to the terminal based on the fifth message.
[0316] In one possible implementation, the first core network device may further perform the following operations: acquiring the quantity information and / or first identification information; the first identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. The first core network device may also configure the number of numbers issued (or quantity information) and the first identification information. For example, the first core network device configures one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier, as well as the number of numbers issued (or quantity information). In some embodiments, the first core network device may be... Figure 4 The first core network device obtains quantity information and / or first identification information by executing any of the methods from Method 1 to Method 4. It should be understood that the first core network device can only execute [the following steps] after obtaining the quantity information and / or first identification information. Figure 6A and Figure 6B The method and process in the process.
[0317] 605B, the first core network device sends a second message to the operation requester to which the terminal belongs.
[0318] In this embodiment of the application, the first core network device sends a fourth message to the second core network device to perform an authentication process on the terminal, thereby ensuring that the terminal is a trusted terminal.
[0319] In this embodiment, before sending the second message, the first core network device needs to determine whether to allow terminal access to the network based on the quantity information. If the first core network device determines that the terminal is not allowed to access the network based on the quantity information, it is unnecessary to send the fourth message requesting the authentication process for the terminal, thus reducing signaling overhead. The first core network device's determination of whether to allow terminal access based on the quantity information allows for a quick and accurate determination of whether to perform the authentication process for the terminal. It should be understood that the first core network device's determination of whether to allow terminal access based on the quantity information does not necessarily mean that the terminal will pass the authentication process.
[0320] Figure 7 A flowchart illustrating another terminal management method provided in this application embodiment. The first core network device executes... Figure 6A Prior to the method flow, quantity information and / or first identification information can be obtained by performing the operations executed in methods one through four. Figure 7 and Figure 6A These are two different process flows that the first core network device may execute after receiving the first message from the terminal. For example... Figure 7 As shown, the method includes:
[0321] 701. The first core network device receives the first message from the terminal.
[0322] Step 701 can be referred to step 601B. The first core network device can be an AMF or other devices that can perform the functions of an AMF.
[0323] 702. If the first core network device determines, based on the quantity information, that a terminal is not allowed to access the network, it sends a third message to the terminal.
[0324] The third message indicates that the terminal is denied access to the network. The third message may be a registration rejection message. The quantity information includes the number of terminals allowed to be used by the operation requester to which the terminal belongs, which can be understood as the number of phone numbers issued.
[0325] One possible implementation of step 702 is as follows: When the number of terminals connected to the network in the terminal corresponding to the operation requester is greater than or equal to a number threshold, the first core network device determines that the terminal is not allowed to access the network; the number threshold is the number of terminals that the operation requester is allowed to use.
[0326] In one possible implementation, the first core network device may further perform the following operations: acquiring the quantity information and / or first identification information; the first identification information includes one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier. The core network device may also configure the number of numbers issued and the identification information. For example, the first core network device configures one or more of the terminal identifier, encrypted terminal identifier, terminal application identifier, terminal network identifier, and operation requester identifier, as well as the number of numbers issued. In some embodiments, the first core network device may be... Figure 4 The first core network device obtains quantity information and / or first identification information by executing any of the methods from Method 1 to Method 4. It should be understood that the first core network device can only execute [the following steps] after obtaining the quantity information and / or first identification information. Figure 7 The method and process in the process.
[0327] In this embodiment, when the first core network device determines that a terminal is not allowed to access the network based on the quantity information, it sends a third message to the terminal. This eliminates the need to perform an authentication process on the terminal, reduces unnecessary operations, and promptly rejects the terminal's access.
[0328] The following describes some possible terminal management methods and processes provided in the embodiments of this application, with reference to the accompanying drawings.
[0329] The following describes specific embodiments. Figure 8 Regarding the above embodiments Figure 6A , Figure 6B as well as Figure 7 The terminal management methods in the document will be explained in detail. Figure 8This is an interactive flowchart of a terminal management method provided in an embodiment of this application. Figure 8 As shown, the method includes:
[0330] 801. UDM and the operation requester obtain the application identifier of the terminal.
[0331] One possible implementation of step 801 is as follows: UDM (or UDR), the operation requester, and the operator's BOSS system allocate the terminal's application identifier according to method three or method four above. Figure 8 UDM in Figure 4 An example of a second core network device in the network. Figure 8 The UDM in the code can be replaced with UDR or other core network elements. (See also...) Figure 4 As can be seen from methods three and four, when the terminal's application identifier is allocated according to method three or four, both the second core network device (e.g., UDM or UDR) and the operation requester can obtain the terminal's application identifier, while the first core network device ( Figure 8 The AMF in the data can obtain quantity information and / or identification information. Figure 8 AMF in Figure 4 An example of the first core network device in the network.
[0332] 802. Terminal initialization.
[0333] When the terminal is a tag, terminal initialization can be understood as the tag printer printing the tag. The tag printer can be an operator or an operation requester. The terminal's tag can be printed by the operator or by an operation requester authorized by the operator (e.g., a company). The terminal initialization content may include the terminal's application identifier. Optionally, the terminal's tag content may also include security parameters (or security context). Security parameters may include pre-configured keys, hash parameters, etc. The pre-configured key can be used for encrypting or decrypting data, for generating or deriving keys, or for executing hash algorithms or other algorithms used for authentication. The hash parameter is used for hash operations. A hash operation can be understood as a hash algorithm, also known as a digest algorithm. Its function is to calculate a fixed-length output digest for any set of input data. The most important characteristic of a hash algorithm is that the same input will always produce the same output; different inputs are likely to produce different outputs.
[0334] Steps 801 and 802 are optional. Steps 801 and 802 can be performed during execution. Figure 8 The operations that are completed before the other steps in the process. Figure 8In the method flow, steps 801 and 802 can be considered as operations performed in the preparation phase, while the other steps are operations performed in the application phase. It should be understood that if the terminal's label has been printed, and the UDM and the operation requester have obtained the terminal's application identifier, then execution can proceed directly. Figure 8 The steps following step 803 in the method flow (including step 803) are used to implement terminal access management.
[0335] 803. The operation requester sends an operation command to the access network device.
[0336] The operation command may include application identifiers of one or more terminals. The operation requester can send the operation command to the access network device through the control plane channel or the user plane channel. Figure 8 The example illustrates how an operation requester (e.g., a P-IoT AF) sends operation commands to an access network device via a control plane channel. For instance, the operation requester can send operation commands to the access network device through NEF or AMF network elements. Alternatively, the operation requester can send operation commands to the access network device through the AMF. If sent via a user plane channel, the operation requester (e.g., a P-IoT server) can send operation commands to the access network device through a UPF.
[0337] In one possible implementation, step 803 may involve the operation requester sending an operation instruction to the core network device, which then sends the operation instruction to the terminal via the access network device. It is understood that the operation instruction (or message) sent by the operation requester to the core network device may differ from the operation instruction (or message) sent by the core network device to the terminal; that is, the core network device can generate the operation instruction (or message) to be sent to the terminal based on the operation instruction from the operation requester. In one possible implementation, the operation requester and the core network device communicate using a first protocol, while the core network device and the terminal communicate using a second protocol. The first protocol may be the same as or different from the second protocol. For example, the first protocol may be a service-oriented interface protocol or an application programming interface protocol; the second protocol may be a NAS protocol or other non-access stratum protocol.
[0338] 804. Messages exchanged between access network equipment and terminals.
[0339] In one possible implementation, the access network device can learn the content of the operation instruction and perform the corresponding operation based on the learned operation instruction. For example, the access network device exchanges messages with the terminal to perform an inventory operation, a read operation, or a write operation.
[0340] In another possible implementation, the access network device forwards operation instructions to the terminal and interacts with the terminal via messages.
[0341] 805. The terminal determines its own registration status.
[0342] Step 805 is optional, not mandatory. The terminal can determine its own registration status. If the terminal is not registered, steps 805 to 816 can be executed; if the terminal is registered, step 817 can be executed. If the terminal does not have the ability to determine its own registration status, or does not have the ability to record the registration status, then the terminal needs to execute step 806.
[0343] 806. The terminal sends a registration request message to the access network device.
[0344] The registration request message (e.g., registration request) may include the application identifier of the terminal. In one possible implementation, the registration request message may also include one or more of the following: terminal identifier, encrypted terminal identifier, random number, message authentication code (MAC), checksum, and token. The registration request message may include multiple random numbers and message authentication codes. The terminal identifier can be understood as an identifier used to uniquely identify the terminal (or to uniquely identify the terminal object or device). The encrypted terminal identifier can be understood as an identifier encrypted from the terminal identifier. In this embodiment, one possible form of the terminal is a tag; a tag identifier (TID) can be used as an example of a terminal identifier, and an encrypted tag identifier (CTID) can be used as an example of an encrypted terminal identifier.
[0345] In one possible implementation, the terminal uses a pre-configured key (or pre-configured key) to encrypt the terminal identifier to obtain the encrypted terminal identifier. In another possible implementation, the encrypted terminal identifier can be written to the terminal. Possible methods include the requesting party pre-generating the encrypted terminal identifier and writing it into the terminal (e.g., the label) when printing the label or after printing the label. Random numbers and message authentication codes can be used to identify or authenticate whether messages have been tampered with during transmission, or to authenticate whether a terminal is a trusted terminal. The terminal can generate random numbers and perform calculations with security parameters to obtain a message authentication code (also called a verification value or token). The security parameter can be a key or a hash algorithm. If it is a key, the message authentication code can be the value of the random number encrypted with that key. If it is a hash algorithm, the message authentication code can be the value obtained by processing the random number using that hash algorithm. The random number and message authentication code can be included in the registration request message. In one possible implementation, the registration request message is a NAS message (e.g., a NAS registration request).
[0346] 807. Access network equipment should be selected from AMFs that support P-IoT.
[0347] Step 807 is optional. In one possible implementation, the access network device can directly send a registration request message from the terminal to any AMF, without having to select an AMF that supports P-IoT.
[0348] 808. The access network device sends a registration request message from the terminal to the AMF.
[0349] Figure 8 AMF in Figure 6A , Figure 6B and Figure 7 The example of the first core network device in the process is shown below. The AMF receiving the registration request message is an example of the first core network device receiving the first message from the terminal.
[0350] 809. AMF determines whether to allow a terminal to access the network based on the quantity information.
[0351] One possible implementation of step 809 is as follows: When the number of terminals accessing the network among the terminals corresponding to the operation requester is less than or equal to a quantity threshold, the AMF determines that the terminal is allowed to access the network; otherwise, the AMF determines that the terminal is not allowed to access the network. If the AMF determines that the terminal is allowed to access the network, then step 810 is executed; if the AMF determines that the terminal is not allowed to access the network, then step 816 is executed, that is, a registration rejection message is sent to the terminal. The AMF can count and record the number of terminals belonging to the same operation requester accessing the network. For example, after one or more terminals pass authentication or authorization, the AMF updates the number of terminals used by the operation requester to which the one or more terminals belong. The AMF can determine whether the number of terminals accessing the network for the operation request exceeds the quantity threshold based on the count of terminals accessing the network for the operation requester.
[0352] In one possible implementation, after the AMF determines which terminals are allowed to access the network based on the quantity information, it can determine which ASF (Automatic Authentication and Authorization Service) supports P-IoT based on the terminal's application identifier in the registration request message; then, it sends an authentication request message to that ASF. In one possible implementation, the terminal's application identifier differs from 3GPP (3rd Generation Partnership Project) terminal identifiers such as Subscription Concealed Identifier (SUCI), Subscription Permanent Identifier (SUPI), 5G Globally Unique Temporary Identity (5G-GUTI), and Temporary Mobile Subscriber Identity (TMSI). Based on the terminal's application identifier, the AMF determines whether the terminal is a passive IoT terminal or a P-IoT terminal and needs to select an ASF that supports P-IoT. In another possible implementation, the AMF may not select an ASF that supports P-IoT but instead send a first authentication request message to any ASF.
[0353] 810. AMF sends the first authentication request message to AUSF.
[0354] The first authentication request message (e.g., Nausf_UEAuthentication_Authenticate Request) may include the application identifier of the terminal. One possible implementation of step 810 is as follows: The AMF selects an AUSF that supports P-IoT and sends the first authentication request message to the selected AUSF. Another possible implementation of step 810 is as follows: The AMF sends the first authentication request message to any AUSF. If the registration request message sent by the terminal contains one or more of the following: terminal identifier, encrypted terminal identifier, random number, and message authentication code, then the first authentication request message sent by the AMF to the AUSF may include one or more of the following: terminal identifier, encrypted terminal identifier, random number, and message authentication code. In one possible implementation, the AMF sends indication information 1 (e.g., P-IoT indication information) to the AUSF to indicate that the authentication corresponding to the first authentication request message is for authentication applied to passive IoT or for authentication of passive IoT terminals. For example, the first authentication request message may contain indication information 1, which indicates that the first authentication request message is used to perform authentication applied to passive IoT or for authentication of passive IoT terminals. For example, the AMF sends indication information 1 to the ASF via a message other than the first authentication request message. Indication information 1 indicates that the authentication corresponding to the first authentication request message is for authentication applied to passive IoT, or for authentication of passive IoT terminals. In one possible implementation, indication information 1 indicates that the authentication process is one or more of the following: one-way authentication, two-way authentication, terminal authentication to the network or operation requester, or network or operation requester authentication to the terminal.
[0355] 811. AUSF selects a UDM that supports P-IoT.
[0356] In one possible implementation, the AUSF determines whether to select a P-IoT-supporting UDM based on instruction information 1 sent by the AMF or based on the terminal's application identifier. In this implementation, the terminal's application identifier differs from 3GPP terminal identifiers such as SUCI, SUPI, 5G-GUTI, TMSI, etc. The AUSF determines whether the terminal is a passive IoT terminal or a P-IoT terminal based on the application identifier, and therefore needs to select a P-IoT-supporting UDM. For example, the first authentication request message contains instruction information 1 instructing the AUSF to select a P-IoT-supporting UDM, and the AUSF selects the P-IoT-supporting UDM based on this instruction information 1.
[0357] Step 811 is optional. In one possible implementation, AUSF may not select a UDM, but instead send a second authentication request message directly to any UDM.
[0358] 812. AUSF sends a second authentication request message to UDM.
[0359] The second authentication request message (e.g., Nudm_UEAuthentication GetRequest) may include the terminal's application identifier. If the first authentication request message sent by the AMF to the AUSF includes one or more of the following: terminal identifier, encrypted terminal identifier, random number, and message authentication code, then the second authentication request message sent by the AUSF to the UDM may include one or more of the following: terminal identifier, encrypted terminal identifier, random number, and message authentication code. In one possible implementation, the second authentication request message sent by the AUSF to the UDM includes indication information 2 (e.g., P-IoT indication information), which indicates that the authentication corresponding to the second authentication request message is for authentication applied to passive IoT, or for authentication of passive IoT terminals. In another possible implementation, indication information 2 indicates that the authentication process is one or more of the following: one-way authentication, two-way authentication, terminal authentication to the network or operation requester, or network or operation requester authentication to the terminal.
[0360] 813. UDM authenticates the terminal based on the second authentication request message.
[0361] In one possible implementation, the second authentication request message includes the terminal's application identifier, a random number, and a message authentication code. The UDM can retrieve security parameters based on the terminal's application identifier and verify the message authentication code based on the security parameters and the random number. If they match, the terminal is considered authenticated (or considered a trusted terminal); if they do not match, the terminal is considered unauthenticated (or considered an untrusted terminal). The security parameters can be a key or a hash algorithm. If it is a key, the message authentication code can be the value of the random number encrypted with the key. If it is a hash algorithm, the message authentication code can be the value obtained by processing the random number using the hash algorithm. In another possible implementation, if any terminal passes authentication, the UDM marks the application identifier as used; if the message authentication code in the second authentication request message passes verification and the terminal's application identifier is not marked as used, the terminal's application identifier is considered authenticated.
[0362] In one possible implementation, the UDM can select the authentication method for the terminal based on the instruction information 2 sent by the AUSF to the UDM (i.e., select the authentication method applicable to passive IoT or passive IoT terminals).
[0363] In one possible implementation, if the second authentication request message sent by AUSF to UDM includes a terminal identifier, UDM can record the correspondence between the terminal's application identifier and the terminal identifier. If the second authentication request message sent by AUSF to UDM includes an encrypted terminal identifier, UDM can decrypt the encrypted terminal identifier to obtain the terminal identifier. UDM can record the correspondence between the terminal's application identifier and the terminal identifier, or record the correspondence between the terminal's application identifier and the encrypted terminal identifier, or record the correspondence between the terminal's application identifier, the encrypted terminal identifier, and the terminal identifier. UDM can count the number of terminals that have been used based on the recorded terminal application identifier or correspondence. For example, the second authentication request message includes terminal application identifier 1 and terminal identifier 1; if UDM has recorded the correspondence between terminal application identifier 1 and terminal identifier 2, then the terminal is determined to have failed authentication, and the count of the number of terminals used by the operation requester remains unchanged. In this example, UDM has recorded the correspondence between terminal application identifier 1 and terminal identifier 2, indicating that terminal application identifier 1 has been used by other terminals, i.e., terminal application identifier 1 has been stolen. As can be seen, the UDM can determine whether a terminal application identifier is used by multiple terminals based on the recorded correspondence between the terminal application identifier and the terminal identifier (or the encrypted terminal identifier). In one possible implementation, the UDM determines that the terminal fails authentication if the terminal application identifier has been used by another terminal. That is, if the terminal's application identifier is stolen, the terminal fails authentication. For example, the second authentication request message includes terminal application identifier 1 and terminal identifier 1; if the UDM has recorded terminal application identifier 1, it determines that the terminal fails authentication, and the count of terminals used by the operation requester remains unchanged. In this example, the UDM has recorded terminal application identifier 1, indicating that terminal application identifier 1 has been used by another terminal, i.e., terminal application identifier 1 has been stolen. For example, the second authentication request message includes terminal application identifier 1 and terminal identifier 1; if the UDM has not recorded the correspondence between terminal application identifier 1 and other terminal identifiers and has not recorded terminal application identifier 1, then the UDM records the correspondence between terminal application identifier 1 and terminal identifier 1, and increments the count of terminals used by the operation requester by one. In this example, the UDM does not record the correspondence between terminal application identifier 1 and other terminal identifiers, and it does not record terminal application identifier 1 either, indicating that terminal application identifier 1 is not used. The UDM can count the number of terminals that have been used based on the recorded terminal application identifiers or correspondences.
[0364] 814. UDM sends the first authentication response message to AUSF.
[0365] The first authentication response message (e.g., Nudm_UEAuthentication_Get Response) may include an authentication result, such as authentication successful or authentication failed. Successful authentication means the terminal has passed authentication. Authentication failed means the terminal has failed authentication.
[0366] In one possible implementation, if the authentication process corresponds to one-way authentication between the network and the terminal, or two-way authentication between the terminal and the network, the first authentication response message sent by the UDM to the AUSF may include a random number generated by the UDM and a MAC value (or checksum or token). For example, the MAC value may be generated by the UDM based on the terminal's corresponding security parameters and the random number; or, the MAC value may be generated by the UDM based on a random number sent by the terminal, a random number generated by the UDM, and the terminal's corresponding security parameters. This MAC value (or checksum or token) is sent to the terminal through the core network. The terminal parses the random number based on the pre-configured security parameters and the MAC value (or checksum or token), and authenticates whether the network is a trusted network based on the parsed random number. For example, when the parsed random number includes a random number generated by the terminal, the network is considered a trusted network.
[0367] 815. AUSF sends a second authentication response message to AMF.
[0368] The second authentication response message (e.g., Nausf_UEAuthentication_Authenticate Response) may include an authentication result, such as authentication successful or authentication failed. The authentication result included in the second authentication response message is the same as the authentication result included in the first authentication response message.
[0369] 816. AMF sends a registration acceptance message or a registration rejection message to the terminal.
[0370] In one possible implementation, if the terminal passes authentication, the AMF sends a registration acceptance message (e.g., registrationaccept) to the terminal; if the terminal fails authentication, the AMF sends a registration rejection message (e.g., registrationreject) to the terminal. In another possible implementation, the registration acceptance or rejection message can be a NAS message (e.g., NAS Registration Accept or NAS Registration Reject). If the terminal has the ability to record its registration status, it can record that it is registered after receiving the registration acceptance message, thus allowing the terminal to determine its own registration status. That is, before receiving the registration acceptance message, the terminal is in an unregistered state, indicating that it is not registered; after receiving the registration acceptance message, the terminal changes from an unregistered state to a registered state, indicating that it is registered.
[0371] 817. The terminal sends a NAS message to the AMF.
[0372] After successful terminal registration, if the terminal needs to send information (such as the terminal's application identifier) to the operation requester (P-IoT AF or P-IoT server), and the information sent by the terminal is sent to the P-IoT AF via the control plane channel, it can be sent to the AMF via a NAS message, and the AMF will then forward it to the P-IoT AF (or the AMF can forward it to the P-IoT AF via the NEF). Figure 8 As shown.
[0373] In one possible implementation, if the terminal and AMF are to use a NAS encryption mechanism, the AMF needs to interact with the terminal to exchange security parameters before executing step 817 in order to execute the NAS security mechanism.
[0374] In another possible implementation, if the information sent by the terminal is sent to the P-IoT server through the user plane channel, it can be sent to the access network device via an RRC message, and the access network device can then send it to the P-IoT server through the user plane channel (for example, the access network device sends it to the P-IoT server through the UPF network element).
[0375] 818. The AMF sends data from the terminal to the operation requester via the NEF.
[0376] If the terminal sends information to the P-IoT AF via the control plane channel, the AMF can send data from the terminal to the P-IoT AF via the NEF. For example, the terminal's data may include the terminal's application identifier and information stored in the terminal's storage area. Step 818 can be replaced by: the AMF sending data from the terminal to the operation requester via the NEF. If the terminal sends information to the P-IoT server via the user plane channel, the terminal can send an RRC message to the access network device, which then sends it to the P-IoT server via the user plane channel.
[0377] 819. The operation request direction sends an invalidation message to the UDM.
[0378] The failure information indicates one or more failed terminals. If the operation requester has one or more failed terminals (e.g., tags) and needs to replace them, the operation requester can send the terminal identifier (or encrypted terminal identifier) of the failed terminals to the UDM (via NEF). The failure information may contain the terminal identifiers (or encrypted terminal identifiers) of one or more failed terminals.
[0379] 820. UDM updates or deletes the identification information of invalid terminals.
[0380] The identification information of a failed terminal may include one or more of the following: application identifier, network identifier, terminal identifier, encrypted terminal identifier, and a second correspondence relationship, wherein the second correspondence relationship includes two or more of the application identifier, network identifier, terminal identifier, and encrypted terminal identifier of the failed terminal.
[0381] Step 820 can be implemented as follows: The UDM updates or deletes the identification information of the failed terminals based on the failure information. For example, if the failure information indicates that terminals 1 and 5 are failed, the UDM deletes the application identifier, network identifier, terminal identifier, and encrypted terminal identifier of terminal 1, or deletes or updates two or more of the corresponding relationships among the application identifier, network identifier, terminal identifier, and encrypted terminal identifier of terminal 1. Similarly, the UDM deletes the application identifier, network identifier, terminal identifier, and encrypted terminal identifier of terminal 5, or deletes or updates two or more of the corresponding relationships among the application identifier, network identifier, terminal identifier, and encrypted terminal identifier of terminal 5.
[0382] It is understood that steps 806 to 816 are steps for the terminal to register or access the network (e.g., the core network).
[0383] In one possible implementation, steps 813 and 814 performed by the UDM can be implemented by the AMF, and steps 810 to 815 can be replaced by: the AMF retrieving security parameters based on the terminal's application identifier, and verifying the message authentication code based on the security parameters and a random number; if they match, the terminal is considered to have passed authentication (or is considered a trusted terminal); if they do not match, the terminal is considered to have failed authentication (or is considered an untrusted terminal). If the AMF considers the terminal to have passed authentication, it sends a registration acceptance message to the terminal; if the AMF considers the terminal to have failed authentication, it sends a registration rejection message to the terminal.
[0384] In this embodiment, the AMF determines whether to allow a terminal to access the network based on the quantity information. If the AMF determines that a terminal is not allowed to access the network based on the quantity information, it is not necessary to send a message requesting the execution of an authentication process for the terminal, thus reducing signaling overhead.
[0385] In this embodiment, before the terminal registers with the network, the UDM obtains the terminal's application identifier and uses it to authenticate the terminal. By counting the number of terminals, it prevents the application identifier of one terminal from being used by multiple terminals, which is beneficial for network tag management and billing.
[0386] In this embodiment, the application identifier of the terminal is used for access management. If terminal authentication is required, security parameters can be written to or configured on the terminal when printing the label, after printing the label, or during label initialization. This allows the terminal to send authentication information (such as random numbers and message authentication codes) to the network when registering with the network. Furthermore, the terminal identifier can prevent the application identifier of one terminal from being used by multiple terminals, which is beneficial for operators to manage and bill terminals.
[0387] The following describes specific embodiments. Figure 9 Regarding the above embodiments Figure 6A , Figure 6B as well as Figure 7 The terminal management methods in the document will be explained in detail. Figure 9 This is an interactive flowchart of another terminal management method provided in an embodiment of this application. Figure 9 As shown, the method includes:
[0388] 901. The operation requester obtains the terminal's application identifier, and the AMF obtains quantity information and / or identifier information.
[0389] One possible implementation of step 901 is as follows: The operation requester and the operator's BOSS system allocate the terminal's application identifier according to method one. Figure 9 UDM in Figure 4 An example of a second core network device in the network. Figure 9The UDM in the code can be replaced with UDR or other core network elements. (See also...) Figure 4 As can be seen from Method 1, according to Method 1, the terminal's application identifier is allocated, and the operation requester can obtain the terminal's application identifier. The second core network device (corresponding to...) Figure 9 The UDM in the process did not obtain the application identifier of the terminal. Figure 9 In one implementation, the operator does not pre-configure the terminal's application identifier; the operation requester allocates the terminal's application identifier. In one possible implementation, the UDM, the operation requester, and the operator's BOSS system execute the method flow in method one. This allows the UDM to configure the number of numbers issued, and the operation requester to obtain the terminal's application identifier. The first core network device (…) Figure 9 The AMF in the data can obtain quantity information and / or identification information.
[0390] 902. Terminal initialization.
[0391] Step 902 can be found in step 802. Steps 901 and 902 are optional. Steps 901 and 902 can be operations performed in advance before executing subsequent steps.
[0392] 903. The operation requester sends an operation command to the access network device.
[0393] Step 903 can be found in step 803.
[0394] 904. Messages exchanged between access network equipment and terminals.
[0395] Step 904 can be found in step 804.
[0396] 905. The terminal determines its own registration status.
[0397] Step 905 can be found in step 805.
[0398] 906. The terminal sends a registration request message to the access network device.
[0399] Step 906 can be found in step 806.
[0400] 907. Access network devices can select AMF that supports P-IoT.
[0401] Step 907 can be found in step 807.
[0402] 908. The access network device sends a registration request message from the terminal to the AMF.
[0403] Step 908 can be found in step 808.
[0404] 909. AMF determines whether to allow a terminal to access the network based on the quantity information.
[0405] Step 909 can be referred to step 809. If the AMF determines that the terminal is allowed to access the network, then proceed to step 910; if the AMF determines that the terminal is not allowed to access the network, then proceed to step 916, that is, send a registration rejection message to the terminal.
[0406] 910. AMF sends the first authentication request message to AUSF.
[0407] Step 910 can be referred to step 810. The difference between step 910 and step 810 is that the first authentication request message does not include the terminal's application identifier.
[0408] The first authentication request message (e.g., Nausf_UEAuthentication_Authenticate Request) may include a terminal identifier (or an encrypted terminal identifier). In one possible implementation, the first authentication request message may include one or more of the following: a terminal identifier, an encrypted terminal identifier, a random number, and a message authentication code.
[0409] 911. AUSF selects a UDM that supports P-IoT.
[0410] Step 911 can be found in step 811.
[0411] 912. AUSF sends a second authentication request message to UDM.
[0412] Step 912 can be referred to step 812. The second authentication request message (e.g., Nudm_UEAuthenticationGetRequest) may include a terminal identifier (TID) or an encrypted terminal identifier (CTID). The difference between step 912 and step 812 is that the second authentication request message does not include the terminal's application identifier. If the first authentication request message sent by the AMF to the AUSF includes one or more of the following: terminal identifier, encrypted terminal identifier, random number, and message authentication code, then the second authentication request message sent by the AUSF to the UDM may include one or more of the following: terminal identifier, encrypted terminal identifier, random number, and message authentication code.
[0413] 913. UDM authenticates the terminal based on the second authentication request message.
[0414] Step 913 can be found in step 813.
[0415] In one possible implementation, the second authentication request message includes the terminal's terminal identifier (or encrypted terminal identifier), a random number, and a message authentication code. The UDM can retrieve security parameters based on the terminal's terminal identifier or the plaintext portion of the encrypted terminal identifier, and verify the message authentication code based on the security parameters and the random number. If they match, the terminal is considered to have passed authentication (or is considered a trusted terminal). If they do not match, the terminal is considered to have failed authentication (or is considered an untrusted terminal).
[0416] 914. UDM sends the first authentication response message to AUSF.
[0417] Step 914 can be found in step 814.
[0418] 915. AUSF sends a second authentication response message to AMF.
[0419] Step 915 can be found in step 815.
[0420] 916. AMF sends a registration acceptance message or a registration rejection message to the terminal.
[0421] Step 916 can be found in step 816.
[0422] 917. The terminal sends a NAS message to the AMF.
[0423] Step 917 can be found in step 817.
[0424] 918. The AMF sends data from the terminal to the operation requester via the NEF.
[0425] Step 918 can be found in step 818.
[0426] 919. The operation request direction sends an invalidation message to the UDM.
[0427] Step 919 can be found in step 819.
[0428] 920. UDM updates or deletes the identification information of invalid terminals.
[0429] Step 920 can be found in step 820.
[0430] In one possible implementation, steps 913 and 914 performed by the UDM can be implemented by the AMF, and steps 910 to 915 can be replaced by: the AMF retrieving security parameters based on the terminal identifier or the plaintext portion of the encrypted terminal identifier, and verifying the message authentication code based on the security parameters and a random number; if they match, the terminal is considered to have passed authentication (or is considered a trusted terminal); if they do not match, the terminal is considered to have failed authentication (or is considered an untrusted terminal). If the AMF considers the terminal to have passed authentication, it sends a registration acceptance message to the terminal; if the AMF considers the terminal to have failed authentication, it sends a registration rejection message to the terminal.
[0431] In this embodiment, the UDM performs access management and authentication of the terminal without obtaining the terminal's application identifier. Compared to Figure 8 The proposed method can meet the privacy and security needs of enterprises, users, or operation requesters, meaning the network does not obtain the application identifier of the terminal. Similarly, based on the terminal identifier, the network (i.e., UDM) can count the number of terminals in use and prevent the theft of terminal identifiers.
[0432] In this embodiment, UDM uses terminal identifiers for access management. If terminal authentication is required, security parameters can be written to the terminal when or after label printing, so that when the terminal registers with the network, it can send authentication information (such as random numbers and message authentication codes) to the network. Simultaneously, the terminal identifier can prevent one terminal identifier from being used by multiple terminals, which is beneficial for operators to manage and bill terminals.
[0433] The following describes specific embodiments. Figure 10 Regarding the above embodiments Figure 6A , Figure 6B as well as Figure 7 The terminal management methods in the document will be explained in detail. Figure 10 This is an interactive flowchart of another terminal management method provided in an embodiment of this application. Figure 10 As shown, the method includes:
[0434] 1001. The operation requester obtains the application identifier of the terminal, and the UDM obtains the network identifier of the terminal.
[0435] One possible implementation of step 1001 is as follows: The requesting party, UDM (or UDR), and the operator's BOSS system allocate the terminal's application identifier and network identifier according to method two. (See also...) Figure 4 As can be seen from Method 2, the terminal's application identifier and network identifier are allocated according to Method 2. The operation requester can obtain the terminal's application identifier, and the second core network device can obtain the terminal's network identifier. Figure 10 UDM in Figure 4An example of a second core network device in the network. Figure 10 The UDM in the code can be replaced with UDR or other core network elements. Figure 10 AMF in Figure 4 An example of the first core network device in the network. Figure 10 In one implementation, the operator does not pre-configure the terminal's application identifier; the operation requester allocates the terminal's application identifier. In one possible implementation, the second core network device (e.g., UDM or UDR), the first core network device (e.g., AMF), the operation requester, and the operator's BOSS system execute the method flow in method two. This allows the second core network device to obtain the terminal's network identifier, the operation requester to obtain the terminal's application identifier, and the first core network device (…). Figure 10 The AMF in the data can obtain quantity information and / or identification information.
[0436] 1002. Terminal initialization.
[0437] Step 1002 can be found in step 802. Steps 1001 and 1002 are optional. Steps 1001 and 1002 can be operations performed in advance before executing subsequent steps.
[0438] 1003. The operation requester sends an operation command to the access network device.
[0439] Step 1003 can be found in step 803.
[0440] 1004. Messages exchanged between access network equipment and terminals.
[0441] Step 1004 can be found in step 804.
[0442] 1005. The terminal determines its own registration status.
[0443] Step 1005 can be found in step 805.
[0444] 1006. The terminal sends a registration request message to the access network device.
[0445] Step 1006 can be referred to step 806. The registration request message may include the terminal's network identifier. In one possible implementation, the registration request message may also include one or more of the following: the terminal's application identifier, the terminal identifier (or an encrypted terminal identifier), a random number, and a message authentication code. The terminal's network identifier is an identifier assigned to the terminal by the operator for access management or authentication.
[0446] 1007. Access network equipment should be selected from AMFs that support P-IoT.
[0447] Step 1007 can be found in step 807.
[0448] 1008. The access network device sends a registration request message from the terminal to the AMF.
[0449] Step 1008 can be found in step 808.
[0450] 1009. AMF determines whether to allow a terminal to access the network based on the quantity information.
[0451] Step 1009 can be referred to step 809. If the AMF determines that the terminal is allowed to access the network, then step 1010 is executed; if the AMF determines that the terminal is not allowed to access the network, then step 1016 is executed, that is, a registration rejection message is sent to the terminal.
[0452] 1010. AMF sends the first authentication request message to AUSF.
[0453] Step 1010 can be found in step 810.
[0454] The first authentication request message (e.g., Nausf_UEAuthentication_Authenticate Request) may include the terminal's network identifier. One difference between step 1010 and step 810 is that the first authentication request message includes the terminal's network identifier.
[0455] 1011. AUSF selects a UDM that supports P-IoT.
[0456] Step 1011 can be found in step 811.
[0457] 1012. AUSF sends a second authentication request message to UDM.
[0458] Step 1012 can be referred to step 812. The second authentication request message (e.g., Nudm_UEAuthenticationGetRequest) may include the terminal's network identifier. The difference between step 1012 and step 812 is that the second authentication request message includes the terminal's network identifier. If the first authentication request message sent by the AMF to the AUSF includes one or more of the following: the terminal's network identifier, the terminal identifier, an encrypted terminal identifier, a random number, and a message authentication code, then the second authentication request message sent by the AUSF to the UDM may include one or more of the following: the terminal's network identifier, the terminal identifier, an encrypted terminal identifier, a random number, and a message authentication code.
[0459] 1013. UDM authenticates the terminal based on the second authentication request message.
[0460] Step 1013 can be referred to step 813. One difference between step 1013 and step 813 is that the UDM authenticates or authorizes the terminal in different ways. In one possible implementation, the second authentication request message includes the terminal's network identifier, a random number, and a message authentication code; the UDM can retrieve security parameters based on the terminal's network identifier and verify the message authentication code based on the security parameters and the random number; if they match, the terminal is considered to have passed authentication (or is considered a trusted terminal); if they do not match, the terminal is considered to have failed authentication (or is considered an untrusted terminal).
[0461] In one possible implementation, if the second authentication request message sent by AUSF to UDM includes a terminal network identifier, a terminal application identifier, a terminal identifier, and an encrypted terminal identifier, then UDM can record the correspondence. This correspondence includes the correspondence between two or more of the terminal network identifier, terminal application identifier, terminal identifier, and encrypted terminal identifier. If the second authentication request message sent by AUSF to UDM includes an encrypted terminal identifier, then UDM can decrypt the encrypted terminal identifier to obtain the terminal identifier. UDM can use this correspondence to count the number of terminals used by the operation requester.
[0462] One possible implementation of step 1013 is as follows: The UDM retrieves security parameters based on the terminal network identifier in the second authentication request message, and verifies the message authentication code based on the security parameters and a random number. If the verification is successful, the terminal network identifier is recorded, and the number of terminals used by the operation requester is counted. For example, the second authentication request message includes terminal network identifier 1 for terminal 1. After terminal 1 passes the verification, the UDM checks whether terminal network identifier 1 is recorded. If terminal network identifier 1 is not recorded, the number of terminals used by the operation requester is incremented by one. If terminal network identifier 1 is recorded, the number of terminals used by the operation requester remains unchanged.
[0463] Another possible implementation of step 1013 is as follows: The UDM retrieves security parameters based on the terminal network identifier in the second authentication request message, and verifies the message authentication code based on the security parameters and a random number. If the verification is successful, the UDM can record the correspondence between the terminal network identifier and the terminal network identifier. This correspondence includes the correspondence between the terminal network identifier and one or more of the following: encrypted terminal identifier, terminal identifier, and terminal application identifier. The UDM can use this correspondence to count the number of terminals used by the operation requester. For example, if the second authentication request message includes terminal network identifier 1 for terminal 1, after terminal 1 passes verification, the UDM checks whether the correspondence between terminal network identifier 1 and terminal network identifier 1 is recorded. If neither terminal network identifier 1 nor its correspondence is recorded, the number of terminals used by the operation requester is incremented by one. If terminal application identifier 1 or its correspondence is recorded, the number of terminals used by the operation requester remains unchanged.
[0464] 1014. UDM sends the first authentication response message to AUSF.
[0465] Step 1014 can be found in step 814.
[0466] 1015. AUSF sends a second authentication response message to AMF.
[0467] Step 1015 can be found in step 815.
[0468] 1016. AMF sends a registration acceptance message or a registration rejection message to the terminal.
[0469] Step 1016 can be found in step 816.
[0470] 1017. The terminal sends a NAS message to the AMF.
[0471] Step 1017 can be found in step 817.
[0472] 1018. AMF sends data from the terminal to the operation requester via NEF.
[0473] Step 1018 can be found in step 818.
[0474] 1019. The operation request direction sends an invalidation message to the UDM.
[0475] Step 1019 can be found in step 819.
[0476] 1020. UDM updates or deletes the identification information of invalid terminals.
[0477] Step 1020 can be found in step 820.
[0478] In one possible implementation, steps 1013 and 1014 performed by the UDM can be implemented by the AMF, and steps 1010 to 1015 can be replaced by: the AMF retrieving security parameters based on the terminal's network identifier, and verifying the message authentication code based on the security parameters and a random number; if they match, the terminal is considered to have passed authentication (or is considered a trusted terminal); if they do not match, the terminal is considered to have failed authentication (or is considered an untrusted terminal). If the AMF considers the terminal to have passed authentication, it sends a registration acceptance message to the terminal; if the AMF considers the terminal to have failed authentication, it sends a registration rejection message to the terminal.
[0479] In this embodiment, the core network can perform access management and authentication of terminals without obtaining the terminal's application identifier. Compared to Figure 8 The method and process described herein can meet the privacy and security needs of enterprises, namely, that the network does not obtain the application identifier of the terminal. Compared to Figure 9 The proposed method involves the network using the terminal's network identifier for access management and authentication. This mechanism can meet the needs of enterprises that do not report data to the network (e.g., enterprises do not need to report the application identifier and terminal identifier of the terminal). Similarly, based on the terminal identifier, the network can count the number of terminals in use and prevent the theft of terminal identifiers.
[0480] The following describes specific embodiments. Figure 11 Regarding the above embodiments Figure 6A , Figure 6B as well as Figure 7 The terminal management methods in the document will be explained in detail. Figure 11 This is an interactive flowchart of another terminal management method provided in an embodiment of this application. Figure 11 As shown, the method includes:
[0481] 1101. The operation requester obtains the terminal's application identifier and configures the number of numbers to be issued in the UDM.
[0482] Step 1001 can be implemented as follows: The requesting party, the second core network device (e.g., UDM or UDR), and the first core network device (… Figure 11 The method and process for executing Method 1 in the AMF (Advanced Management Functions) and operator's BOSS system. See also... Figure 4 As can be seen from Method 1, the method flow of Method 1 allows the requesting party to obtain the terminal's application identifier. The second core network device can be configured to issue a certain number of numbers, and the first core network device ( Figure 8 The AMF in the data can obtain quantity information and / or identification information. Figure 11 UDM in Figure 4 An example of a second core network device in the network. Figure 11 The UDM in the code can be replaced with UDR or other core network elements. Figure 11 AMF in Figure 4 An example of the first core network device in the network. Figure 11 In the method embodiment, the operator does not pre-configure the application identifier of the terminal, and the operation requester allocates the application identifier of the terminal.
[0483] 1102. Terminal initialization.
[0484] Step 1102 can be found in step 802. Steps 1101 and 1102 are optional. Steps 1101 and 1102 can be operations performed in advance before executing subsequent steps.
[0485] 1103. AMF sends the first instruction to the access network equipment.
[0486] The first instruction (which may be referred to as the online signing instruction) is used to execute online signing or to trigger the terminal to execute online signing. Alternatively, the first instruction instructs the terminal to execute online signing.
[0487] 1104. Access network equipment receives and interacts with terminal messages.
[0488] One possible implementation is that the access network device, upon learning that the first instruction is an online contract signing instruction, interacts with the terminal based on this instruction, for example, by notifying or triggering the terminal to perform online contract signing. Another possible implementation is that the access network device forwards the first instruction to the terminal, interacts with the terminal, and notifies or triggers the terminal to perform online contract signing.
[0489] 1105. The terminal determines the contract status.
[0490] In one possible implementation, after receiving the first instruction forwarded by the access network device, the terminal can determine its subscription status. If the terminal is in an unsubscribed state or has not obtained subscription data, the terminal executes step 1106. If the terminal has obtained subscription data or is in a subscribed state, steps 1106 to 1116 can be skipped. The subscription data may include the terminal's identification information and / or authentication information. The identification information may include the terminal's network identifier. After the terminal obtains the identification information and / or authentication information assigned by the core network device (e.g., UDM), the terminal changes from an unsubscribed state to a subscribed state. Alternatively, before the terminal obtains the identification information and / or authentication information assigned by the core network device (e.g., UDM), the terminal does not obtain subscription data; after the terminal obtains the identification information and / or authentication information assigned by the core network device (e.g., UDM), the terminal obtains subscription data.
[0491] In one possible implementation, after the terminal learns that it needs to perform online signing by interacting with the access network device, it can determine its own signing status. If the terminal is in an unsigned state or has not obtained signing data, the terminal executes step 1106. If the terminal has obtained signing data or is in a signed state, it can skip step 1106 to step 1116.
[0492] Step 1105 is optional. In one possible implementation, the terminal may skip step 1105 and instead execute step 1106 directly after executing step 1104.
[0493] 1106. The terminal sends a first request message to the access network device.
[0494] The first request message (e.g., an online signing request message or a registration request message, but the registration request message is used to instruct the registration network to perform online signing) is used to request the performance of online signing.
[0495] In one possible implementation, the first request message may include one or more of the following: an enterprise identifier (or an operation requester identifier or a user identifier), a network identifier for a terminal that is an empty set (i.e., an empty terminal network identifier), a random number, and a message authentication code. The message authentication code may be a value obtained by encrypting the random number or by hashing it. In one possible implementation, if the network serves multiple enterprises, users, or operation requesters, the network may assign a network identifier based on the enterprise identifier (or user identifier or operation requester identifier) sent by the terminal. If the network serves only one enterprise (or user or operation requester), the terminal may not need to send an enterprise identifier (or user identifier or operation requester identifier). In another possible implementation, the first request message sent by the terminal includes a random number and a message authentication code; the network may assign a network identifier to the terminal after the terminal is authenticated.
[0496] Access network equipment should be selected from AMFs that support P-IoT.
[0497] Access network devices can select an AMF that supports P-IoT online signing. An AMF that supports P-IoT online signing has the capability to execute... Figure 11 The functions performed by AMF in the system.
[0498] 1107. Access network equipment should be selected from AMFs that support P-IoT.
[0499] Access network devices can select an AMF that supports P-IoT online signing. An AMF that supports P-IoT online signing has the capability to execute... Figure 11 The functions performed by AMF in the system.
[0500] 1108. The access network device sends the first request message from the terminal to the AMF.
[0501] The first request message may include one or more of the following: enterprise identifier (or user identifier or operation requester identifier), empty terminal network identifier, random number, and message authentication code.
[0502] 1109. AMF determines whether to allow a terminal to access the network based on the quantity information.
[0503] If the AMF determines that the terminal is allowed to access the network, then step 1110 is executed; if the AMF determines that the terminal is not allowed to access the network, then step 1116 is executed, that is, a registration rejection message is sent to the terminal.
[0504] 1110. AMF sends a second request message to AUSF.
[0505] The second request message (e.g., an authentication message, Nausf_UEAuthentication_AuthenticateRequest) is used to request the core network device (e.g., UDM) to perform online signing. If the first request message sent by the terminal includes one or more of the following: enterprise identifier (or user identifier or operation requester identifier), empty terminal network identifier, random number, and message authentication code, then the second request message sent by the AMF to the AUSF may include one or more of the following: enterprise identifier (or user identifier or operation requester identifier), empty terminal network identifier, random number, and message authentication code. In one possible implementation, the AMF sends indication information 3 (e.g., P-IoT indication information) to the AUSF to indicate online signing, or online signing for passive IoT, or online signing for a passive IoT terminal. The indication information 3 sent by the AMF to the AUSF may be included in the second request message or in other messages.
[0506] Before sending the second request message to the AMF, the AMF can select an AMF that supports P-IoT (or supports P-IoT online signing). An AMF that supports P-IoT (or supports P-IoT online signing) has the capability to execute... Figure 11The AMF performs the functions of the ASF in the system. In one possible implementation, the AMF can select an ASF that supports P-IoT (or supports P-IoT online signing) based on a first request message or information obtained from the access network device. In another possible implementation, the first request message is of a specific type, and the AMF can determine the ASF that supports P-IoT (or supports P-IoT online signing) based on the message type of the first request message. In yet another possible implementation, the access network device has P-IoT capabilities, and the AMF determines the ASF that supports P-IoT (or supports P-IoT online signing) based on the access network device or its capabilities.
[0507] 1111. AUSF selects UDM.
[0508] AUSF selects a UDM that supports P-IoT (or supports P-IoT online signing). A UDM that supports P-IoT (or supports P-IoT online signing) has the capability to execute... Figure 11 The functions performed by the UDM in the process. One possible implementation is that the AUSF learns from the instruction information 3 sent by the AMF or from the second request message that it needs to select a UDM that supports P-IoT (or supports P-IoT online signing).
[0509] 1112. AUSF sends a third request message to UDM.
[0510] The third request message (e.g., an authentication request message, Nudm_UEAuthentication GetRequest) is used to request authentication or authorization of the terminal. The third request message may include one or more of the following: an enterprise identifier (or a user identifier or an operation requester identifier), an empty terminal network identifier, a random number, and a message authentication code. For example, the second request message sent by the AMF to the AUSF includes one or more of the following: an enterprise identifier (or a user identifier or an operation requester identifier), an empty terminal network identifier, a random number, and a message authentication code. The third request message sent by the AUSF to the UDM may include one or more of the following: an enterprise identifier (or a user identifier or an operation requester identifier), an empty terminal network identifier, a random number, and a message authentication code. In one possible implementation, the AUSF sends indication information 4 (e.g., P-IoT indication information) to the UDM to indicate online signing, or online signing for passive IoT, or online signing for a passive IoT terminal. The indication information 4 sent by the AUSF to the UDM may be included in the third request message or in other messages.
[0511] 1113. UDM performs authentication based on the enterprise identifier (or user identifier or operation requester identifier) and assigns a network identifier to the terminal after successful authentication.
[0512] After a terminal is authenticated, the UDM can assign security parameters to it, which are used to authenticate the terminal. The UDM can also record the correspondence between the network identifier assigned to the terminal and the security parameters, so that the security parameters can be retrieved based on the terminal's network identifier. For example, the terminal can use the security parameters assigned by the UDM to process a random number to obtain a message authentication code; the registration request message sent by the terminal can contain this random number and the message authentication code; the UDM can retrieve the security parameters based on the terminal's network identifier and use these security parameters to verify the message authentication code.
[0513] In one possible implementation, the third request message includes one or more of the following: an enterprise identifier (or a user identifier or an operation requester identifier), an empty terminal network identifier, a random number, and a message authentication code. The UDM then retrieves security parameters based on the enterprise identifier (or user identifier or operation requester identifier). The UDM verifies the message authentication code based on the retrieved security parameters and the random number; if they match, the terminal is considered authenticated (or the terminal is considered a trusted terminal, or the terminal originates from a trusted operation requester). The UDM verifies the message authentication code based on the security parameters and the random number; if they do not match, the terminal is considered unauthenticated (or the terminal is considered an untrusted terminal). In another possible implementation, the UDM can select an authentication method based on the instruction information 4 sent by the AUSF to the UDM (i.e., selecting an online signing method suitable for online signing, or a passive IoT online signing method, or an online signing method suitable for passive IoT terminals).
[0514] In one possible implementation, after the UDM assigns a network identifier to a terminal, the UDM can record the mapping between the terminal's network identifier and the enterprise identifier (or user identifier or operation requester identifier). Optionally, the UDM can count the number of terminals used by the operation requester based on the terminal's network identifier or this mapping. The UDM can also count the number of terminals used by the operation requester during subsequent terminal registration. For details on how the UDM can count the number of terminals used based on the terminal's network identifier or this mapping, please refer to [link to relevant documentation]. Figure 10 Step 1013 in the process.
[0515] 1114. UDM sends the first response message to AUSF.
[0516] The first response message (e.g., an authentication response message, Nudm_UEAuthentication_GetResponse) may include an authentication result. This authentication result may include, for example, authentication successful or authentication failed. If the first response message includes an authentication successful result, it may also include the network identifier and security parameters assigned to the terminal by the UDM. If the first response message includes an authentication successful result, it may only include that authentication result.
[0517] 1115. AUSF sends a second response message to AMF.
[0518] The second response message (e.g., an authentication response message, such as Nausf_UEAuthentication_Authenticate Response) may include an authentication result, such as authentication successful or authentication failed. If the second response message includes an authentication successful result, it may also include the network identifier and security parameters assigned to the terminal by the UDM.
[0519] 1116. AMF sends a registration acceptance message or a registration rejection message to the terminal.
[0520] A registration acceptance message (or online contract acceptance message, online contract completion message) may include a network identifier assigned to the terminal. The registration acceptance message may also include security parameters. A registration acceptance message indicates that the terminal's online contract signing has succeeded. Alternatively, a registration acceptance message indicates that the terminal has completed the online contract signing. A registration rejection message (or online contract signing failure message, online contract signing failure message, etc.) indicates that the terminal's online contract signing has failed. Alternatively, a registration rejection message indicates that the terminal's online contract signing has failed or not been completed.
[0521] In one possible implementation, if the terminal passes authentication, the AMF sends the terminal an online contract acceptance message, an online contract completion message, or a registration acceptance message (e.g., registrationaccept). These messages all contain a network identifier assigned to the terminal. If the terminal fails authentication, the AMF sends the terminal an online contract failure message, an online contract rejection message, or a registration rejection message (e.g., Registration Reject). These messages all indicate that the online contract failed or the terminal failed authentication.
[0522] In one possible implementation, the registration acceptance message or registration rejection message can be a NAS message or be included in a NAS message (e.g., NAS Registration Accept, NAS Onboarding Accept, NASOnboarding complete, NAS Registration Reject, NAS Onboarding Reject, NASOnboarding failed).
[0523] 1117. The operation requester sends an operation command to the access network device.
[0524] Step 1003 can be found in step 803.
[0525] The operation command may include application identifiers of one or more terminals. The operation requester can send the operation command to the access network device through either the control plane channel or the user plane channel. The diagram illustrates an example of the operation requester sending an operation command to the access network device through the control plane channel. The operation requester (e.g., P-IoT AF) can send the operation command to the access network device through NEF or AMF, or it can send the operation command through the AMF. If sent through the user plane channel, the operation requester (P-IoT server) can send the operation command to the access network device through UPF.
[0526] 1118. Messages exchanged between access network devices and terminals.
[0527] Step 1118 can be found in step 804.
[0528] 1119. The terminal determines its own registration status.
[0529] Step 1119 can be found in step 805.
[0530] 1120. The terminal sends a registration request message to the AMF.
[0531] The registration request message may include the terminal's network identifier. In one possible implementation, the registration request message may also include one or more of the following: the terminal's application identifier, the terminal identifier (or an encrypted terminal identifier), a random number, and a message authentication code. The terminal's network identifier is an identifier assigned to the terminal by the operator for access management or authentication.
[0532] Step 1120 can be replaced by: the terminal sending a registration request message to the AMF through the access network device. In one possible implementation, the registration request message is a NAS message (e.g., NAS Registration Request); the terminal sends the registration request message to the access network device, which can select an AMF that supports P-IoT and send the registration request message from the terminal to the selected AMF.
[0533] 1121. AMF sends the first authentication request message to AUSF.
[0534] Step 1121 can be found in step 810.
[0535] The first authentication request message (e.g., Nausf_UEAuthentication_Authenticate Request) may include the terminal's network identifier. The first authentication request message is used to request authentication or authorization of the terminal. If the registration request message sent by the terminal includes one or more of the terminal's application identifier, terminal identifier (or encrypted terminal identifier), random number, and message authentication code, then the first authentication request message sent by the AMF to the AUSF may include one or more of the terminal's application identifier, terminal identifier (or encrypted terminal identifier), random number, and message authentication code. In one possible implementation, the AMF sends indication information 1 (e.g., P-IoT indication information) to the AUSF to indicate that the authentication is for passive IoT or for passive IoT terminals.
[0536] Optionally, the AMF selects an ASF that supports P-IoT. In one possible implementation, the AMF can determine whether to select an ASF that supports P-IoT based on the terminal's network identifier in the registration request message or based on indication information 1. In another possible implementation, the terminal's network identifier differs from 3GPP terminal identifiers such as SUCI, SUPI, 5G-GUTI, TMSI, etc. The AMF determines whether the terminal is a passive IoT terminal or a P-IoT terminal based on the terminal's application identifier, and therefore needs to select an ASF that supports P-IoT.
[0537] 1122. AUSF sends a second authentication request message to UDM.
[0538] Step 1122 can be found in step 812.
[0539] The second authentication request message (e.g., Nausf_UEAuthentication_Authenticate Request) may include the terminal's network identifier. The second authentication request message is used to request authentication or authorization of the terminal. If the first authentication request message sent by the AMF to the AUSF includes one or more of the terminal's application identifier, terminal identifier (or encrypted terminal identifier), random number, and message authentication code, then the second authentication request message sent by the AUSF to the UDM may include one or more of the terminal's application identifier, terminal identifier (or encrypted terminal identifier), random number, and message authentication code. In one possible implementation, the AMF sends indication information 2 (e.g., P-IoT indication information) to the AUSF to indicate that the authentication is for passive IoT or for passive IoT terminals. In another possible implementation, indication information 2 indicates that the authentication process is one or more of the following: one-way authentication, two-way authentication, terminal authentication to the network or operation requester, or network or operation requester authentication to the terminal.
[0540] Optionally, AUSF selects a UDM that supports P-IoT. In one possible implementation, AUSF determines the need to select a UDM that supports P-IoT based on instructions sent by AMF or based on the network identifier of the terminal.
[0541] 1123. UDM authenticates the terminal based on the second authentication request message.
[0542] Step 1123 can be found in step 1013.
[0543] 1124. UDM sends the first authentication response message to AUSF.
[0544] Step 1124 can be found in step 814.
[0545] 1125. AUSF sends a second authentication response message to AMF.
[0546] Step 1125 can be found in step 815.
[0547] 1126. AMF sends a registration acceptance message or a registration rejection message to the terminal.
[0548] Step 1126 can be found in step 816.
[0549] 1127. The terminal sends a NAS message to the AMF.
[0550] Step 1127 can be found in step 817.
[0551] 1128. The AMF sends data from the terminal to the operation requester via the NEF.
[0552] Step 1128 can be found in step 818.
[0553] 1129. The operation request direction sends an invalidation message to the UDM.
[0554] Step 1129 can be found in step 819.
[0555] 1130. UDM updates or deletes the identification information of invalid terminals.
[0556] Step 1130 can be found in step 820.
[0557] In one possible implementation, steps 1113 and 1114 performed by the UDM can be implemented by the AMF, and steps 1110 to 1115 can be replaced by: the AMF performing authentication based on the enterprise identifier and assigning a network identifier to the terminal upon successful authentication. It should be understood that if the terminal passes authentication, a registration acceptance message is sent to the terminal; otherwise, a registration rejection message is sent to the terminal.
[0558] Figure 11 In the method flow, steps 1101 to 1116 are the process of performing online signing to obtain the network identifier of the terminal, and steps 1107 to 1130 are the steps of performing the registration process.
[0559] Figure 11 The methods and processes in Figure 10 Compared to the previous method, the terminal's network identifier is sent to the terminal through the online signing process. Its advantages include: the terminal's network identifier does not need to be pre-configured within the enterprise, preventing the enterprise from using a single terminal's network identifier for multiple terminals; in other words, the process of obtaining the terminal's network identifier is streamlined and more secure. Furthermore, the AMF determines whether to allow a terminal to access the network based on quantity information. If the number of terminal devices corresponding to the operation requester accessing the network is less than or equal to the quantity threshold, then it is not necessary to assign a network identifier to the terminal requesting online signing (belonging to that operation requester), thus reducing unnecessary operations.
[0560] Figure 12 A schematic diagram of a communication device 1200 is shown. This communication device 1200 can correspondingly implement the core network equipment (e.g., ...) described in the various method embodiments above. Figure 4 and Figure 6BThe functions or steps implemented by the first core network device and the second core network device in the above-described method embodiments can also be implemented by the operation requester. The communication device may include a processing module 1210 and a transceiver module 1220. Optionally, it may also include a storage unit, which can be used to store instructions (code or program) and / or data. The processing module 1210 and the transceiver module 1220 may be coupled to the storage unit; for example, the processing module 1210 can read instructions (code or program) and / or data from the storage unit to implement the corresponding method. The above-described units can be set independently or partially or completely integrated. For example, the transceiver module 1220 may include a sending module and a receiving module.
[0561] In some possible implementations, the communication device 1200 can correspondingly implement the operation and functions of the first core network device in the above method embodiments. For example, the communication device 1200 can be the first core network device, or it can be a component (e.g., a chip or circuit) applied in the first core network device. The transceiver module 1220 can, for example, be used to perform... Figure 4 , Figure 6A , Figure 6B , Figure 7 , Figure 8 , Figure 9 , Figure 10 , Figure 11 In the embodiments, all receive or transmit operations performed by the first core network device or AMF, for example Figure 4 Steps 405, 417, 427, and 435 in the illustrated embodiments are as follows: Figure 6A Steps 601A and 602A in the illustrated embodiments, and / or other processes used to support the techniques described herein. Processing module 1210 is used to execute... Figure 6A , Figure 6B , Figure 7 , Figure 8 , Figure 9 , Figure 10 , Figure 11 In the embodiments, all operations except for transmit and receive operations performed by the first core network device or AMF, such as Figure 6A Step 602A in the illustrated embodiment, Figure 7 Step 702 in the illustrated embodiment, Figure 8 Step 809 in the illustrated embodiment.
[0562] In some possible implementations, the communication device 1200 can correspondingly implement the operation and functions of the second core network device in the above method embodiments. For example, the communication device 1200 can be the second core network device, or it can be a component (e.g., a chip or circuit) applied in the second core network device. The transceiver module 1220 can, for example, be used to perform... Figure 4 , Figure 6B , Figure 8 , Figure 9 , Figure 10 , Figure 11 In the embodiments, all receive or transmit operations performed by the second core network device, for example... Figure 4 Steps 401, 405, 411, 417, 421, 425, 427, 432, and 435 in the illustrated embodiment are shown. Figure 6B Steps 602B and 603B in the illustrated embodiment are shown. Figure 8 Steps 812, 814, and 819 in the illustrated embodiments, and / or other processes used to support the technology described herein. Processing module 1210 is used to execute... Figure 4 , Figure 8 , Figure 9 , Figure 10 , Figure 11 In the embodiments, all operations performed by the second core network device except for transmit and receive operations, such as Figure 4 Steps 402, 412, 415, 422, 426, and 433 in the illustrated embodiment, and Figure 8 Steps 813 and 820 in the illustrated embodiment.
[0563] In some possible implementations, the communication device 1200 can correspondingly implement the operations and functions of the operation requester in the above method embodiments. For example, the communication device 1200 can be the operation requester or a component (e.g., a chip or circuit) applied in the operation requester. The transceiver module 1220 can, for example, be used to perform... Figure 4 , Figure 5 , Figure 6A , Figure 6B , Figure 8 , Figure 9 , Figure 10 , Figure 11 In the embodiments, all receive or send operations performed by the operation requester, such as Figure 4 Steps 403, 413, 416, 423, 425, and 434 in the illustrated embodiment, and Figure 5 Step 501 in the illustrated embodiment, Figure 6A Step 602A in the illustrated embodiment, Figure 8Steps 803, 818, and 819 in the illustrated embodiments, and / or other processes used to support the techniques described herein. Processing module 1210 is used to execute... Figure 4 , Figure 5 , Figure 8 , Figure 9 , Figure 10 , Figure 11 In the embodiments, all operations performed by the operation requester other than the send and receive operations are included, for example... Figure 4 Steps 401, 414, and 424 in the illustrated embodiment are shown. Figure 5 Step 502 in the illustrated embodiment, and Figure 8 Step 801 in the illustrated embodiment.
[0564] Figure 13 This is a schematic diagram of another communication device 130 provided in an embodiment of this application. Figure 13 The communication device in the network can be the aforementioned first core network equipment. Figure 13 The communication device in the network can be the aforementioned second core network equipment. Figure 13 The communication device in the above-mentioned operation requester can be the communication device in the above-mentioned operation requester.
[0565] like Figure 13 As shown, the communication device 130 includes at least one processor 1320 and a transceiver 1310.
[0566] In other embodiments of this application, the processor 1320 and transceiver 1310 can be used to perform the functions or operations performed by the first core network device described above. For example, the processor 1320 can perform one or more of the following operations: Figure 6A Step 602A in the illustrated embodiment, Figure 7 Step 702 in the illustrated embodiment, Figure 8 Step 809 in the illustrated embodiment. The transceiver 1310 may perform one or more of the following operations, for example: Figure 4 Steps 405, 417, 427, and 435 in the illustrated embodiment are shown. Figure 6A Steps 601A and 602A in the illustrated embodiment.
[0567] In some embodiments of this application, the processor 1320 and transceiver 1310 can be used to perform the functions or operations performed by the second core network device described above. For example, the processor 1320 can perform one or more of the following operations: Figure 4 Steps 402, 412, 415, 422, 426, and 433 in the illustrated embodiment, and Figure 8 Steps 813 and 820 in the illustrated embodiment. Transceiver 1310 may perform one or more of the following operations, for example: Figure 4 Steps 401, 405, 411, 417, 421, 425, 427, 432, and 435 in the illustrated embodiment are shown. Figure 6B Steps 602B and 603B in the illustrated embodiment are shown. Figure 8 Steps 812, 814, and 819 in the illustrated embodiment.
[0568] In some embodiments of this application, the processor 1320 and transceiver 1310 can be used to perform functions or operations requested by the operation requester. For example, the processor 1320 can perform one or more of the following operations: Figure 4 Steps 401, 414, and 424 in the illustrated embodiment are shown. Figure 5 Step 502 in the illustrated embodiment, and Figure 8 Step 801 in the illustrated embodiment. The transceiver 1310 may perform one or more of the following operations: Figure 4 Steps 403, 413, 416, 423, 425, and 434 in the illustrated embodiment, and Figure 5 Step 501 in the illustrated embodiment, Figure 6A Step 602A in the illustrated embodiment, Figure 8 Steps 803, 818, and 819 in the illustrated embodiment.
[0569] Transceiver 1310 is used to communicate with other devices / appliances via a transmission medium. Processor 1320 uses transceiver 1310 to send and receive data and / or signaling, and to implement the methods in the above-described method embodiments. Processor 1320 can implement the functions of processing module 1210, and transceiver 1310 can implement the functions of transceiver module 1220.
[0570] Optionally, the communication device 130 may further include at least one memory 1330 for storing program instructions and / or data. The memory 1330 is coupled to the processor 1320. The coupling in this embodiment is an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, for information exchange between devices, units, or modules. The processor 1320 may operate in conjunction with the memory 1330. The processor 1320 may execute program instructions stored in the memory 1330. At least one of the at least one memory may be included in the processor.
[0571] This application embodiment does not limit the specific connection medium between the transceiver 1310, processor 1320, and memory 1330. This application embodiment... Figure 13The memory 1330, processor 1320, and transceiver 1310 are connected via a bus 1340. Figure 13 The connections between other components are shown in thick lines only and are not intended to be limiting. This bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, Figure 13 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.
[0572] In the embodiments of this application, the processor may be a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.
[0573] Figure 14 This is a schematic diagram of another communication device 140 provided in an embodiment of this application. (See attached diagram.) Figure 14 As shown, Figure 14 The communication device shown includes logic circuit 1401 and interface 1402. Figure 12 The processing module 1210 can be implemented using logic circuit 1401. Figure 12 The transceiver module 1220 can be implemented using interface 1402. The logic circuit 1401 can be a chip, processing circuit, integrated circuit, or system-on-chip (SoC) chip, etc., and the interface 1402 can be a communication interface, input / output interface, etc. In this embodiment, the logic circuit and the interface can also be coupled to each other. The specific connection method between the logic circuit and the interface is not limited in this embodiment.
[0574] In some embodiments of this application, the logic circuit and interface can be used to perform the functions or operations performed by the first core network device described above.
[0575] In other embodiments of this application, the logic circuit and interface can be used to perform the functions or operations performed by the second core network device described above.
[0576] In other embodiments of this application, the logic circuit and interface can be used to perform the functions or operations performed by the requesting party as described above.
[0577] In some embodiments of this application, the logic circuit and interface can be used to perform the functions or operations performed by the access network device 2 described above.
[0578] This application also provides a computer-readable storage medium storing computer code that, when executed on a computer, causes the computer to perform the methods described in the above embodiments.
[0579] This application also provides a computer program product, which includes computer code or a computer program, such that when the computer code or computer program is run on a computer, the authentication and authorization method in the above embodiments is executed.
[0580] This application also provides a communication system, including a terminal device, an access network device 1, a second access network device, and a third access network device.
[0581] This application also provides a communication system, including a terminal device and an access network device 2.
[0582] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of protection of the above claims.
Claims
1. A terminal management method characterized by comprising: Comprise: The first core network device receives a first message from a terminal, the first message being used for requesting access to a network; The first core network device sends a second message to an operation requester to which the terminal belongs when it is determined according to quantity information that the terminal is allowed to access the network; The quantity information includes the number of terminals allowed to be used by the operation requester, and the second message includes first identification information, the first identification information including one or more of a terminal identifier of the terminal, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
2. The method of claim 1, wherein, The determination of whether the terminal is allowed to access the network according to the quantity information includes: When the number of terminals accessing the network among terminals corresponding to the operation requester is less than a quantity threshold, the first core network device determines that the terminal is allowed to access the network; the quantity threshold is the number of terminals allowed to be used by the operation requester.
3. The method according to claim 1 or 2, characterized in that, The method further comprises: The first core network device sends a third message to the terminal when it is determined according to the quantity information that the terminal is not allowed to access the network; the third message indicates that the terminal is rejected to access the network.
4. The method of claim 3, wherein, The determination of whether the terminal is allowed to access the network according to the quantity information includes: When the number of terminals accessing the network among terminals corresponding to the operation requester is greater than or equal to a quantity threshold, the first core network device determines that the terminal is not allowed to access the network; the quantity threshold is the number of terminals allowed to be used by the operation requester.
5. The method according to any one of claims 1 to 4, characterized in that, The method further comprises: The first core network device sends a fourth message to a second core network device; the fourth message is used for requesting to perform an authentication process on the terminal; the fourth message includes second identification information and authentication information, the second identification information and the authentication information being used for performing the authentication process; the second identification information includes one or more of a terminal identifier of the terminal, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
6. The method of claim 5, wherein, The fourth message further includes indication information, the indication information indicating that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication of the terminal to the network or the operation requester, and one-way authentication of the network or the operation requester to the terminal.
7. The method according to any one of claims 1 to 4, characterized in that, The method further comprises: The first core network device performs an authentication process on the terminal according to the first message; the first message includes third identification information and authentication information, the third identification information and the authentication information being used for performing the authentication process; the third identification information includes one or more of a terminal identifier of the terminal, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
8. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: The first core network device determines the operation requester to which the terminal belongs according to the third identification information included in the first message; the third identification information includes one or more of a terminal identifier of the terminal, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
9. The method according to claim 5 or 6 or 7, characterized in that, The method further comprises: The first core network device receives a fifth message; The first core network device sends a sixth message to the terminal; the fifth message indicates that the authentication process is passed, and the sixth message indicates that the terminal is accepted to access the network; or the fifth message indicates that the authentication process is not passed, and the sixth message indicates that the terminal is rejected to access the network.
10. The method according to any one of claims 1 to 9, characterized in that, The method further comprises: The core network device acquires the quantity information and / or the first identification information.
11. A communications device, characterized by Comprise: The transceiver module is used for receiving a first message from a terminal, the first message being used for requesting access to a network; The transceiver module is further used for sending a second message to an operation requester to which the terminal belongs when the processing module determines to allow the terminal to access the network according to quantity information; the quantity information comprises a quantity of terminals allowed to be used by the operation requester, and the second message comprises first identification information, the first identification information comprising one or more of a terminal identification of the terminal, an encrypted terminal identification, a terminal application identification, a terminal network identification, and an operation requester identification.
12. The apparatus of claim 11, wherein The processing module is specifically configured to determine to allow the terminal to access the network when a quantity of terminals in the operation requester corresponding terminals that access the network is less than a quantity threshold; the quantity threshold being the quantity of terminals allowed to be used by the operation requester.
13. The apparatus of claim 11 or 12, wherein The transceiver module is further used for sending a third message to the terminal when the processing module determines not to allow the terminal to access the network according to the quantity information; the third message indicating to reject the terminal to access the network.
14. The apparatus of claim 13, wherein The processing module is specifically configured to determine not to allow the terminal to access the network when the quantity of terminals in the operation requester corresponding terminals that access the network is greater than or equal to a quantity threshold; The quantity threshold being the quantity of terminals allowed to be used by the operation requester.
15. The apparatus of any one of claims 11 to 14, wherein The transceiver module is further used for sending a fourth message to a second core network device; the fourth message being used for requesting to perform an authentication process on the terminal; the fourth message comprising second identification information and authentication information, the second identification information and the authentication information being used for performing the authentication process; the second identification information comprising one or more of a terminal identification of the terminal, an encrypted terminal identification, a terminal application identification, a terminal network identification, and an operation requester identification.
16. The apparatus of claim 15, wherein, The fourth message further comprises indication information, the indication information indicating that the authentication process is any one of one-way authentication, two-way authentication, one-way authentication of the terminal to the network or the operation requester, and one-way authentication of the network or the operation requester to the terminal.
17. The apparatus of any one of claims 11 to 14, wherein The processing module is further configured to perform an authentication procedure for the terminal according to the first message; the first message comprises third identification information and authentication information, and the third identification information and the authentication information are used to perform the authentication procedure; the third identification information comprises one or more of a terminal identifier of the terminal, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
18. The apparatus of any of claims 11-17, wherein The processing module is further configured to determine the operation requester to which the terminal belongs according to third identification information comprised in the first message; the third identification information comprises one or more of a terminal identifier of the terminal, an encrypted terminal identifier, a terminal application identifier, a terminal network identifier, and an operation requester identifier.
19. The apparatus of any of claims 15-17, wherein The transceiver module is further configured to receive a fifth message and send a sixth message to the terminal; the fifth message indicates that the authentication procedure is passed, and the sixth message indicates that the terminal is accepted to access the network; or the fifth message indicates that the authentication procedure is not passed, and the sixth message indicates that the terminal is rejected to access the network.
20. The apparatus of any of claims 11-19, wherein The processing module is further configured to acquire the quantity information and / or the first identification information.
21. A computer-readable storage medium, characterized in that, The computer program is stored in the computer readable storage medium, and includes program instructions. When the program instructions are executed by the processor, the processor executes the method in any of claims 1-10.
22. A communications device, characterized by The apparatus includes a processor and a memory, The memory is configured to store a computer program or instructions. The processor is configured to execute the computer program or instructions in the memory, so that the method in any of claims 1-10 is executed.
23. A communication system, characterized by The apparatus includes a device for executing the method in any of claims 1-10.