Communication method and device

Abstract

The invention provides a communication method and device, and belongs to the technical field of communication. The method comprises the following steps: sending first information, and receiving a first identifier of a first terminal; the first information comprises at least one of M identification lengths or N length intervals, and M and N are positive integers; the length of the first identifier and a first identifier length in the M identifier lengths meet a preset rule, and / or the length of the first identifier is located in a first length interval in the N length intervals.

Description

Technical Field

[0001] This application relates to the field of communications, and more particularly to a communication method and apparatus. Background Technology

[0002] With the development of communication technology, the 3rd Generation Partnership Project (3GPP) defined Ambient IoT (A-IoT). A-IoT terminals obtain energy from the environment and communicate with the network to realize business processes in various scenarios, such as warehousing / transportation / inventory management, and fixed asset management. In these business processes, A-IoT terminals need to send their device identifiers to the reader. Due to the diverse nature of A-IoT business scenarios, device identifiers can be varied.

[0003] How to ensure the efficiency of business processes in the face of diverse device identifiers is a current research issue. Summary of the Invention

[0004] To address the aforementioned technical issues, embodiments of this application provide a communication method and apparatus that enable the network side to maintain high efficiency in business processes even when dealing with device identifiers of varying lengths.

[0005] To achieve the above objectives, this application adopts the following technical solution:

[0006] Firstly, a communication method is provided. This method is applied to a first network entity. The method includes: sending first information and receiving a first identifier of a first terminal. The first information includes M identifier lengths and / or N length intervals, where M and N are positive integers; the length of the first identifier satisfies a preset rule with the length of the first identifier among the M identifier lengths, and / or the length of the first identifier is located within a first length interval among the N length intervals.

[0007] Therefore, the first network entity can specify the identifier length and / or length range by sending the first information. If, after receiving the first information, the first terminal determines that the length of its own device identifier meets the preset rules and / or falls within the length range, the first terminal can report its own device identifier, such as the first identifier; otherwise, it will not report it. This allows for batch and orderly reporting, ensuring that the network side can still guarantee the efficiency of the business process for device identifiers of different lengths.

[0008] In one possible design scheme, the length of the first identifier satisfies a preset rule, including: the length of the first identifier is the same as the first identifier length, or the first identifier is determined based on the second identifier of the first terminal, and the length of the second identifier is the same as the first identifier length. That is, the first identifier can be an identifier directly reported by the first terminal, or it can be an identifier reported after processing; the choice can be made flexibly according to the implementation requirements. For example, if there are few types of identifier lengths, the network can choose to report directly; otherwise, the network can choose to report after processing, such as processing to the same length before reporting.

[0009] Optionally, the first information also includes the reporting length. When the first identifier is determined based on the second identifier, the length of the first identifier is the same as the reporting length. For example, the second identifier can be truncated or padded to the reporting length to obtain the first identifier. In this way, identifiers of different lengths can be processed to the same length before being reported, thereby improving the execution efficiency of the business process.

[0010] In one possible design, the M identifier lengths include K identifier lengths, or in other words, the M identifier lengths contain the same length and / or different lengths, resulting in a total of K lengths, where K is a positive integer. For example, the M identifier lengths are 3: the first identifier length is L1, the second identifier length is L2, and the third identifier length is L2. These 3 identifier lengths include L1 and L2. The K identifier lengths belong to the L identifier lengths, where L is an integer greater than or equal to K. The first network entity can select K identifier lengths from the L identifier lengths as the required length for the identifiers to be reported in this instance, based on actual needs. For example, if there are many types of identifier lengths, i.e., L is large, the first network entity can select a portion of the identifier lengths as the required length for each report, i.e., report in batches to reduce the overhead of each report. Conversely, the first network entity can select all types of identifier lengths as the required length for each report, i.e., report all at once to reduce the overall latency of the business process.

[0011] Optionally, the method described in the first aspect may further include: receiving a service request from a second network entity, and determining L types of identifier lengths based on the service request. The second network entity is the requester of the first service, and the service request may instruct the execution of the first service on a terminal that meets preset conditions. The first terminal is the terminal that meets the preset conditions, that is, the determination of L types of identifier lengths can be triggered by the service request, so as to achieve on-demand determination according to service requirements.

[0012] Furthermore, the third network entity is pre-configured with L types of identifier lengths. Determining the L types of identifier lengths based on the service request includes: obtaining the L types of identifier lengths from the third network entity based on the service request. In this case, the service request may not need to include the L types of identifier lengths to reduce signaling overhead. Alternatively, the service request may also include the L types of identifier lengths. Determining the L types of identifier lengths based on the service request includes: obtaining the L types of identifier lengths from the service request to reduce interaction overhead between network elements / entities.

[0013] Furthermore, terminals that meet the preset conditions may include at least one of the following: terminals located within the indicated area, or terminals identified as an identifier type. In this case, the first network entity is not certain whether the identifiers of these terminals are all of the same identifier length, and therefore can determine L identifier lengths accordingly.

[0014] Furthermore, the primary business is environmental IoT (A-IoT) business, or any other possible business, without restriction.

[0015] Optionally, the L types of identifier lengths can also be the default identifier length of the first network entity. That is, the first network entity can pre-configure or predefine the L types of identifier lengths without obtaining them from signaling or other network elements / entities, thereby further reducing overhead.

[0016] In one possible design, the first information is carried in a mask, that is, existing information cells are reused to transmit the first information, so as to reduce the implementation difficulty. Alternatively, it can be transmitted independently, decoupled from existing information cells, making information transmission more flexible.

[0017] Optionally, the mask mentioned above includes an identifier type, and the type of the first identifier matches the identifier type included in the mask. For example, the identifier type can be any of the following: an identifier assigned by the operator network, an identifier assigned by a non-operator network, a product electronic identifier, or a non-product electronic identifier, to achieve orderly reporting by length and type.

[0018] In one possible design, the method described in the first aspect may further include: sending second information, the second information including P identifier lengths and / or Q length intervals, where P and Q are positive integers, the P identifier lengths are different from the M identifier lengths, and the Q length intervals are different from the N length intervals, so as to achieve batch reporting.

[0019] Optionally, the first and second information can be carried in the same message. For example, if the first network entity is A-IoTMF, A-IoTMF can send a message to the access network device containing the first and second information. The access network device can then send the first and second information in batches, such as sending them separately in different random access procedures. Alternatively, the first and second information can be carried in separate messages. If the first network entity is A-IoTMF, A-IoTMF can send the first and second information to the access network device separately through different messages, which the access network device can then directly forward to the corresponding A-IoT terminal.

[0020] In one possible design, the first network entity supports reader functionality, and the first terminal is an Aspect-Oriented Internet of Things (A-IoT) terminal.

[0021] Secondly, a communication method is provided. This method is applied to a first terminal, or a chip within the first terminal. Taking application to a first terminal as an example, the method includes: receiving first information, and sending a first identifier of the first terminal based on the first information. The first information includes M identifier lengths and / or N length intervals, where M and N are positive integers; the length of the first identifier satisfies a preset rule with the length of the first identifier among the M identifier lengths, and / or the length of the first identifier is located within a first length interval among the N length intervals.

[0022] In one possible design, the length of the first identifier and the length of the second identifier satisfy a preset rule, including: the length of the first identifier is the same as the length of the first identifier, or the first identifier is determined according to the second identifier of the first terminal, and the length of the second identifier is the same as the length of the first identifier.

[0023] Optionally, the first information also includes a reporting length, where the length of the first identifier is the same as the reporting length if the first identifier is determined based on the second identifier.

[0024] In one possible design, the method described in the second aspect further includes: if the length of the second identifier is greater than the reporting length, then the second identifier is truncated to the reporting length to obtain the first identifier; if the length of the second identifier is less than the reporting length, then the second identifier is padded to the reporting length to obtain the first identifier; wherein, if the length of the second identifier is equal to the reporting length, then the second identifier and the first identifier are the same identifier.

[0025] In one possible design, receiving the first information includes receiving a mask, in which the first information is carried.

[0026] Optionally, the mask includes an identifier type, wherein the type of the first identifier matches the identifier type included in the mask.

[0027] Furthermore, the identification type can be any of the following: an identification assigned by the operator's network, an identification assigned by a non-operator network, a product electronic identification, or a non-product electronic identification.

[0028] In one possible design, the first terminal is an environmental Internet of Things (A-IoT) terminal.

[0029] It is understandable that the technical effects of the method described in the second aspect can also refer to the relevant introduction of the method described in the first aspect above, and will not be repeated here.

[0030] Thirdly, a communication method is provided. This method is applied to a reader and includes: obtaining the length of a device identifier; determining a transmission resource based on the length of the device identifier; the size of the transmission resource matching the length of the device identifier; and the transmission resource being used to carry the device identifier.

[0031] Therefore, it can be seen that for device identifiers of different lengths, the reader can allocate transmission resources, or wireless resources, that match the length. For example, for device identifiers with longer lengths, relatively more transmission resources are allocated, while for device identifiers with shorter lengths, relatively less transmission resources are allocated, in order to avoid wasting transmission resources and improve communication efficiency.

[0032] In one possible design, obtaining the length of the device identifier includes: receiving the length of the device identifier from the first terminal; or: receiving the length of the device identifier from the core network element used to manage the terminal. That is, the length of the device identifier can be reported by the terminal or provided by the network side. There is no specific restriction, and the choice can be made flexibly according to the actual situation.

[0033] In one possible design, the method described in the third aspect may further include: transmitting the device identifier of the first terminal on the transmission resources.

[0034] In one possible design, the first terminal is an environmental Internet of Things (A-IoT) terminal.

[0035] It is understandable that the technical effects of the method described in the third aspect can also refer to the relevant introduction in the first aspect above, and will not be repeated here.

[0036] Fourthly, a communication apparatus is provided. The communication apparatus includes a module for performing the communication method described in any implementation of the first or third aspect.

[0037] In this application, the communication device may be a terminal device or a network device, or a chip (system) or other component or assembly, or a device containing the terminal device or network device. The aforementioned chip (system) or other component or assembly may be disposed within the terminal device or network device.

[0038] It should be understood that the communication device includes modules, units, or means corresponding to the communication method described in either the first or third aspect above. These modules, units, or means can be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units for performing the functions involved in the aforementioned communication method.

[0039] Fifthly, a communication device is provided. The communication device includes a processor configured to execute the communication method described in any possible implementation of the first or third aspect.

[0040] In one possible design, the communication device may further include a transceiver. This transceiver may be a transceiver circuit or an interface circuit. The transceiver can be used for communication between the communication device described in the fifth aspect and other communication devices.

[0041] In one possible design, the communication device may further include a memory. This memory may be integrated with the processor or disposed separately. The memory may be used to store computer programs and / or data relating to the communication method described in either the first or third aspect.

[0042] In this application, the communication device may be a terminal device or a network device, or a chip (system) or other component or assembly, or a device containing the terminal device or network device. The aforementioned chip (system) or other component or assembly may be disposed within the terminal device or network device.

[0043] A sixth aspect provides a communication device. The communication device includes a processor coupled to a memory, the processor executing a computer program stored in the memory, such that the communication device performs the communication method described in any possible implementation of the first or third aspect.

[0044] In one possible design, the communication device may also include a transceiver. This transceiver can be a transceiver circuit or an interface circuit. The transceiver can be used for communication between the communication device and other communication devices.

[0045] In this application, the communication device may be a terminal device or a network device, or a chip (system) or other component or assembly, or a device containing the terminal device or network device. The aforementioned chip (system) or other component or assembly may be disposed within the terminal device or network device.

[0046] A seventh aspect provides a communication device, comprising: a processor and a memory; the memory being used to store a computer program, which, when executed by the processor, causes the communication device to perform the communication method described in any one of the first or third aspects.

[0047] In one possible design, the communication device may also include a transceiver. This transceiver can be a transceiver circuit or an interface circuit. The transceiver can be used for communication between the communication device and other communication devices.

[0048] In this application, the communication device may be a terminal device or a network device, or a chip (system) or other component or assembly, or a device containing the terminal device or network device. The aforementioned chip (system) or other component or assembly may be disposed within the terminal device or network device.

[0049] Eighthly, a communication device is provided, comprising: a processor; the processor being coupled to a memory, and after reading a computer program from the memory, executing, according to the computer program, any implementation of the first or third aspect.

[0050] In one possible design, the communication device may also include a transceiver. This transceiver can be a transceiver circuit or an interface circuit. The transceiver can be used for communication between the communication device and other communication devices.

[0051] In this application, the communication device may be a terminal device or a network device, or a chip (system) or other component or assembly, or a device containing the terminal device or network device. The aforementioned chip (system) or other component or assembly may be disposed within the terminal device or network device.

[0052] A ninth aspect provides a processor. The processor is configured to execute the communication method described in any possible implementation of the first or third aspect.

[0053] In a tenth aspect, a chip is provided. The chip may include a processor for executing the communication method described in any possible implementation of the first or third aspect.

[0054] Optionally, the chip also includes a memory coupled to the processor, the memory storing a program for executing the communication method described in any of the possible implementations of the first or third aspect.

[0055] Eleventhly, a communication system is provided. The communication system includes one or more terminal devices for performing any possible implementation of the first or third aspect, and one or more network devices for performing any possible implementation of the first or third aspect.

[0056] In a twelfth aspect, a computer-readable storage medium is provided. The computer-readable storage medium includes a computer program or instructions; when the computer program or instructions are executed, the communication method described in any possible implementation of the first or third aspect is implemented.

[0057] In a thirteenth aspect, a computer program product is provided. This computer program product includes a computer program or instructions that, when executed, cause the communication method described in any possible implementation of the first or third aspect to be implemented.

[0058] Furthermore, the technical effects of the communication devices described in aspects four through thirteen above can be referenced to the technical effects of the communication methods described in aspects one or three above, and will not be repeated here. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the A-IoT architecture;

[0060] Figure 2 A schematic diagram of the A-IoT process Figure 1 ;

[0061] Figure 3 A schematic diagram of the A-IoT process Figure 2 ;

[0062] Figure 4 Schematic diagram of the communication system architecture provided in the embodiments of this application Figure 1 ;

[0063] Figure 5 Schematic diagram of the communication system architecture provided in the embodiments of this application Figure 2 ;

[0064] Figure 6 Flowchart of the communication method provided in the embodiments of this application Figure 1 ;

[0065] Figure 7 Flowchart of the communication method provided in the embodiments of this application Figure 2 ;

[0066] Figure 8 Flowchart of the communication method provided in the embodiments of this application Figure 3 ;

[0067] Figure 9 Flowchart of the communication method provided in the embodiments of this application Figure 4 ;

[0068] Figure 10 Flowchart of the communication method provided in the embodiments of this application Figure 5 ;

[0069] Figure 11 Schematic diagram of the communication device provided in the embodiments of this application Figure 1 ;

[0070] Figure 12 Schematic diagram of the communication device provided in the embodiments of this application Figure 2 . Detailed Implementation

[0071] The technical solutions of this application embodiment can be applied to various communication systems, such as Wi-Fi wireless network systems, vehicle-to-everything (V2X) communication systems, device-to-device (D2D) communication systems, vehicle-to-everything (V2X) communication systems, fourth-generation (4G) mobile communication systems, such as long-term evolution (LTE) systems, worldwide interoperability for microwave access (WiMAX) communication systems, fifth-generation (5G) mobile communication systems, such as new radio (NR) systems, and future communication systems.

[0072] The technical terms and related technical solutions in this application will be described below with reference to the accompanying drawings.

[0073] 1. Ambient IoT (A-IoT):

[0074] With the development of communication technology, the 3rd Generation Partnership Project (3GPP) defined A-IoT. A-IoT is also known as ambient power-enabled IoT or passive IoT (P-IoT). A-IoT can be applied to a variety of valuable scenarios.

[0075] For example, in warehousing / transportation / materials: by embedding or attaching passive or semi-passive IoT tags to goods stored in warehouses, shopping malls, etc., the relevant information of the goods is automatically collected by the reader during the logistics process. Managers can quickly query the information of the goods in the system, reducing the risk of loss or theft, improving the speed of goods handover, increasing accuracy, and preventing cross-selling and counterfeiting.

[0076] For example, fixed asset management: places with large assets or valuable items, such as libraries, art galleries and museums, need complete management procedures or rigorous protection measures. When there are abnormal changes in the storage information of books or valuable items, the system will immediately remind the administrator to handle the relevant situation.

[0077] Figure 1 This is a schematic diagram of the A-IoT architecture, such as... Figure 1 As shown, the architecture may include: a server, an ambient IoT management function (AIoTMF), a reader, an A-IoT terminal, or a terminal that supports A-IoT.

[0078] The server can be an application function (AF), an application server (AS), or an environmental IoT / passive IoT application function (A-IoT / P-IoT AF), etc., and there are no restrictions on the specific name.

[0079] AIoTMF can process service requests from service requesters (AFs) and execute corresponding service operations (such as instructing the reader to perform inventory procedures for AIoT terminals) and transmit instructions (such as read operations, write operations, and deactivation operations). AIoTMF can also manage IoT devices and perform security authentication processes.

[0080] A-IoT terminals can be categorized into three types: Device A, Device B, and Device C. Device A or Device 1a can be understood as a passive A-IoT terminal. Passive A-IoT terminals can be in the form of tags or any other terminal form, without restriction. Device B or Device 1b can be understood as a semi-passive A-IoT terminal. Semi-passive A-IoT terminals can obtain energy through solar, radio frequency, wind, hydro, or tidal power, with no restriction on the energy acquisition method. These nodes do not have their own power supply devices such as batteries, but obtain energy from the environment to support data sensing, transmission, and distributed computing. Device C or Device 1c can be understood as an active A-IoT terminal. For ease of understanding, the terms "A-IoT terminal" and "tag" are interchangeable.

[0081] A reader can be an access network (RAN) device, such as a base station, pole station, micro base station, or macro station, or it can be a terminal device, such as a mobile phone, IoT device, or handheld reader. Readers can conduct contactless two-way data communication via radio frequency (RF) to read and write tags, thereby achieving target identification and data exchange. For example, for passive tags, when they enter the effective identification range of the reader, they can receive the RF signal emitted by the reader and transmit the information stored in the chip using the energy obtained from the induced current. Alternatively, for semi-passive or active tags, they can actively transmit signals at a specific frequency. The reader receives and decodes the information and sends it to the central information system for relevant data processing. Furthermore, a reader can also be called a reader-writer.

[0082] Specifically, when a server (or service requester, such as an application function (AF) or application server (AS)) operates on a tag, it can send operation instructions through the core network (CN). These instructions can include, but are not limited to: obtaining tag information, inventory operations (or storage operations), read operations, write operations, expiration operations, and interacting with the tag. Operation instructions can include area location information, tag identification information, etc. The reader sends an access instruction to the tag. After a tag successfully connects randomly, the reader sends instructions to the tag, such as forwarding the aforementioned operation instructions. The tag obtains or sends corresponding information according to the instructions. For example, when the operation instruction is an inventory instruction or an inventory operation, the tag sends its identification information; when the operation instruction is a read instruction or a read operation, the tag sends the data information stored in its storage area; when the operation instruction is a write instruction or a write operation, the tag stores the data information to be written to the tag, included in the operation instruction, in its storage area. The reader then sends (or forwards) the information sent by the tag to the core network, which in turn sends it to the server.

[0083] It should be understood that the server can send operation commands via the control plane channel. For example, the AF / AS / A-IoT / P-IoT AF sends operation commands to the ambient IoT function (or ambient IoT function, AIoTF), which then sends the operation commands to the reader via the access and mobility management function (AMF). Alternatively, the A-IoT / P-IoT AF sends operation commands to the AIoTMF via network function elements, which then send them to the reader. Network function elements can include, but are not limited to: network exposure function (NEF), session management function (SMF), policy control function (PCF), user plane function (UPF), unified data management (UDM), and network slice-specific and SNPN authentication and authorization function (NSSAAF), etc. Alternatively, the server can send the operation command via the user plane channel. For example, the server sends the operation command to the reader via the UPF. If the reader is a terminal device, the server also sends the operation command to the RAN device via the user plane device first, and the RAN device forwards it to the reader.

[0084] Servers or service requesters can perform various operations on environmental IoT devices (or environmental IoT terminals (A-IoT terminals)), such as tags. Several common business operations are listed below. The following description uses tags as a specific device form for environmental IoT devices, but does not limit the device form of environmental IoT devices.

[0085] Inventory checking, or checking the existing tags, can also be understood as obtaining tag identifiers. Each tag has a corresponding identifier. Tag identifiers can be assigned by the enterprise (i.e., written into the tag when it's printed) or by the operator. In one possible implementation, the tag 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 server can issue inventory instructions. Typically, inventory instructions include information such as the tag's identifier range, reader identifier, and location information. After receiving the inventory instruction, the reader will check the tags according to the instructions and send the tag's identifier to the server. Alternatively, the server sends the inventory instruction, and the reader transmits the instruction to the tags. The tags, recognizing the inventory operation based on the content of the instruction, send their identifiers to the reader, and the reader sends the tag's identifiers to the server; or, the tags send their identifiers to the core network through the reader, and the core network then sends the tag's identifiers to the server.

[0086] A read operation involves reading data from the tag. Tags can have storage capabilities, and their storage area can store data. If a server wants to perform a read operation on a tag, it sends a read command. The reader or core network then reads the data from the tag's storage area according to the command and sends the data back to the server. A write operation involves writing data to the tag. The server can send a write command, and the reader or core network then writes data to the tag's storage area according to the command.

[0087] The deactivation operation involves invalidating or deactivating a tag. The server can send a deactivation command, which may include the tag identifier (i.e., the identifier of the tag to be deactivated or invalidated). The reader or core network performs the deactivation operation on the tag according to the command. After the operation is completed, the tag will be invalidated or deactivated and cannot be inventoried or subjected to other operations.

[0088] 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 server is inventorying tags or reading tag data. This operation will obtain tag information, which can be the tag's identification information or information stored in the tag storage area.

[0089] The message interaction operation with the tag can be understood as a higher-level description of the various operations mentioned above. After receiving instructions from the server, the reader interacts with the tag to exchange information or messages and sends information from the tag back to the server. This operation is mainly applicable to scenarios where the reader does not view the content of the instructions, but only forwards messages sent by the server to the tag and messages sent by the tag to the server. Therefore, in this scenario, the operation performed by the reader on the tag can be understood as a message interaction operation with the tag.

[0090] 2. A-IoT Operation Process:

[0091] like Figure 2 As shown, one of its processes is as follows.

[0092] S200, the core network sends inventory messages to the reader.

[0093] Inventory messages contain instructions, such as read / write / storage instructions, without specific restrictions. The following text uses read instructions as an example; others can be understood by referring to the same example. Inventory messages also include inventory sessions, actions, masks, etc.

[0094] 1) The session and the subsequent flag are bound together. Each flag corresponds to a session. The disk storage session will specify which session's flag is set.

[0095] 2) The behavior specifies how to set the flag, such as the behavior indicator 1 or 0. If the mask matches after the tag is received, the flag corresponding to the session will be set, such as A (action=1) or B (action=0).

[0096] 3) A mask can be understood as a prefix of the label's identifier. A mask is used to filter which labels are selected. For example, if a label stores a complete 96-bit identifier, the mask can indicate that the label whose first 16 bits are 111...111 is selected.

[0097] After determining that an A-IoT service operation (such as read / write / inventory operation) is to be performed, the core network can send an inventory message to the reader.

[0098] S201, the reader sends a select message or a paging message.

[0099] The select message or paging message is used to select a group of tags. The select message or paging message can contain the information in the inventory message mentioned above.

[0100] When a tag receives a selection message, the matching tag sets the selection message and the corresponding flag. For example, if the inventory session indicates session S0 and the behavior indicator is 0, and the mask matches, the tag sets the flag for session S0 to A, which is the initial flag setting. Afterwards, the device identifier (e.g., EPC) success flag will be flipped to B. Thus, A represents tags that haven't yet transmitted EPC, and B represents tags that have successfully transmitted it. If the mask matches, the tag can further set its flag according to the session's indication and then listen for subsequent paging messages (queries).

[0101] S202, the reader sends a query message or a query duplicate message (queryRep).

[0102] Query messages can carry Q-values, session information, or flags.

[0103] Suppose that the session carried by the query message is S0 and the flag bit is A. The session and flag bit of the tag are matched with it, so a random number between 0 and 2^Q-1 is randomly generated according to Q as the initial value of the counter.

[0104] Querying duplicate messages does not require carrying content, has no Q value or session, and can be sent multiple times.

[0105] If no tag sends a response, such as RN16, the reader continues to send duplicate query messages. If a tag receives a duplicate query message, the tag decrements its counter by 1, e.g., Counter = Counter - 1.

[0106] S203, tag sent RN16.

[0107] If the tag's count value is 0, the tag responds with RN16; otherwise, it does not respond. RN16 is a 16-bit random number (or it could be 16 bits or 8 bits) used for contention resolution. For example, after the tag receives (potentially multiple) duplicate query messages, its count value decreases to 0, and the tag responds with RN16; otherwise, it does not respond. For example, each duplicate query message corresponds to the start or end of an access time slot. Each duplicate query message received by the tag signifies the end of the previous time slot and the start of the next time slot. The tag can randomly select an access time slot to initiate access, send uplink data (EPC), or receive downlink data.

[0108] S204, the reader returns an acknowledgment message (ACK).

[0109] When the reader receives the RN16 sent by the tag, if there is no collision (e.g., only one tag's RN16 is received), it sends back an ACK, which includes the received RN16 and indicates that the contention has been successfully resolved.

[0110] S205, Tag Transmitting Device ID.

[0111] If the tag receives an ACK and the RN16 matches, the device identifier of the tag is fed back; otherwise, no feedback is given. In one possible implementation, the device identifier can be carried in an uplink (UL) non-access-stratum (NAS) message. The ULNAS message can also carry data, such as data read according to a read command.

[0112] S206, the reader sends a query duplicate message (queryRep).

[0113] If the tag sends the device identifier and receives a duplicate query message, it indicates that the transmission was successful and the flag bit is flipped to B. For example, the flag bit can be used to prevent tags that have been stored from being stored again. If the subsequent paging message carries the flag bit A, the tag will not respond if the flag bit is flipped to B.

[0114] S207, the reader sends an N2 message to the core network.

[0115] The N2 message includes the aforementioned UL NAS message. Furthermore, the execution order of S206 and S207 is not limited. In one possible implementation, if the interface between the reader and the core network is not an NGAP interface, the N2 message can be replaced with other message types, i.e., messages corresponding to the interface between the reader and the core network, such as AIoT NGAP. This application does not impose any limitations.

[0116] It can be seen that in the above Figure 2 In the illustrated process, the tag only needs to report the device identifier and / or the data to be read along with a single UL NAS message, without any subsequent signaling interaction. Therefore, when the reader receives the UL NAS message from the tag, it can continue to trigger random access procedures for other tags, such as continuing to broadcast paging messages or repeating queries, without waiting for other instructions from the core network elements.

[0117] For example Figure 3 As shown, taking the A-IoT terminal as a tag as an example, another process is as follows.

[0118] In S300, the core network sends inventory messages to the reader.

[0119] Inventory messages contain inventory sessions, actions, or masks. Unlike S200 described above, inventory messages do not carry instructions.

[0120] S301, the reader sends a selection message or a paging message.

[0121] S302, the reader sends a query message or queries for duplicate messages.

[0122] S303, tag sent RN16.

[0123] S304, the reader returns ACK.

[0124] S305, Identifier for tag sending device.

[0125] The device identifier is carried in the UL NAS message.

[0126] In one possible implementation, the device identifier is carried in the UL NAS message, but unlike S206 above, the UL NAS message in S306 does not carry data.

[0127] S306, the reader sends a duplicate query message.

[0128] S307, the reader sends an N2 message to the core network.

[0129] The N2 message includes the UL NAS message in S306. In one possible implementation, if the interface between the reader and the core network is not an NGAP interface, the N2 message can be replaced with other message types, i.e., messages corresponding to the interface between the reader and the core network, such as AIoT NGAP. This application does not impose any limitations.

[0130] It is understandable that the relevant introductions of S200-S208 can be referred to for S300-S308, and will not be repeated here.

[0131] At this point, the random tag insertion is complete.

[0132] S308, the core network sends instructions to the reader.

[0133] In one possible implementation, the core network sends downlink (DL) NAS messages to the reader.

[0134] DL NAS messages carry instructions, such as read instructions.

[0135] S309, the reader sends instructions to the tag.

[0136] This instruction can be a read instruction.

[0137] In one possible implementation, the reader sends a DL NAS message from the core network to the tag, the DL NAS message including instructions.

[0138] S310, the tag sends data to the reader.

[0139] This data is read according to a read command. In one possible implementation, this data is carried in a UL NAS message.

[0140] S311, the reader sends an N2 message to the core network.

[0141] The N2 message in S311 includes the UL NAS message in S310. In one possible implementation, if the interface between the reader and the core network is not an NGAP interface, the N2 message can be replaced with another message type, i.e., a message corresponding to the interface between the reader and the core network, such as an AIoT NGAP message. This application does not impose any limitations.

[0142] S312, the core network sends an inventory message to the reader.

[0143] Among them, the inventory message in S312 can carry an instruction to continue inventory.

[0144] In the above Figure 2 and Figure 3In the illustrated process, the device identifier of the A-IoT terminal can have different types or implementations. These can be operator-allocated identifiers, such as operator-allocated A-IoT device ID, user permanent identifier (SUPI), international mobile subscriber identity (IMSI), generic public subscribing identifier (GPSI), globally unique temporary UE identity (GUTI), permanent equipment identifier (PEI), 3GPP-defined identifier, or ambient IoT device ID. Alternatively, it can be an identifier allocated by the enterprise (or a third party), one possible implementation of which is the electronic product code (EPC). Since A-IoT has various application scenarios, the type and length of the device identifier can differ depending on the application scenario. For radio resource scheduling, the network typically allocates radio resources according to the maximum length of the device identifier (e.g., 496 bits) to ensure transmission stability and reliability. However, how to ensure service efficiency (such as efficient inventory management) when multiple device identifiers coexist is a problem that needs to be solved. In addition, device identifier reporting usually relies on tail pilots, which can be understood as a terminator to mark the end of device identifier reporting. However, in wireless communication systems, wireless resources are directly scheduled by the base station and cannot be determined by the A-IoT terminal itself. Therefore, relying on tail pilots is not applicable to wireless communication systems.

[0145] To address the aforementioned technical problems, this application proposes the following technical solutions. The technical solutions in this application will now be described in conjunction with the accompanying drawings.

[0146] This application will present various aspects, embodiments, or features relating to systems that may include multiple devices, components, modules, etc. It should be understood and appreciated that individual systems may include additional devices, components, modules, etc., and / or may not include all the devices, components, modules, etc. discussed in conjunction with the accompanying drawings. Furthermore, combinations of these approaches are also possible.

[0147] Furthermore, in the embodiments of this application, words such as "exemplarily" and "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as an "example" in this application should not be construed as being better or more advantageous than other embodiments or designs. Rather, the use of the word "example" is intended to present the concept in a specific manner.

[0148] First, in this application, "instruction" can include both direct and indirect instructions. When describing a certain "information" instruction A, it can include either direct or indirect instructions A, but does not necessarily mean that the information carries A.

[0149] The information indicated by a given piece of information is called the information to be indicated. In the specific implementation process, there are many ways to indicate the information to be indicated, such as, but not limited to, directly indicating the information to be indicated, such as the information to be indicated itself or its index. It can also be indirectly indicated by indicating other information, where there is a relationship between the other information and the information to be indicated. It can also indicate only a part of the information to be indicated, while the other parts are known or pre-agreed upon. For example, the indication of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing the indication overhead to some extent. At the same time, common parts of various pieces of information can be identified and indicated uniformly to reduce the indication overhead caused by individually indicating the same information.

[0150] Furthermore, the specific indication method can also be any existing indication method, such as, but not limited to, the above-mentioned indication methods and their various combinations. Specific details of various indication methods can be found in existing technologies, and will not be repeated here. As described above, for example, when multiple pieces of information of the same type need to be indicated, the indication methods for different pieces of information may differ. In the specific implementation process, the required indication method can be selected according to specific needs. This application embodiment does not limit the selected indication method; therefore, the indication methods involved in this application embodiment should be understood to cover various methods that enable the party to be indicated to obtain the information to be indicated.

[0151] The information to be instructed can be sent as a whole or divided into multiple sub-information messages, and the sending period and / or timing of these sub-information messages can be the same or different. This application does not limit the specific sending method. The sending period and / or timing of these sub-information messages can be predefined, for example, according to a protocol, or configured by the transmitting device by sending configuration information to the receiving device. This configuration information can include, for example, but not limited to, one or a combination of at least two of radio resource control (RRC) signaling, medium access control (MAC) layer signaling, and physical layer signaling. MAC layer signaling includes, for example, a MAC control element (CE); physical (PHY) layer signaling includes, for example, downlink control information (DCI).

[0152] Second, in the embodiments shown below, the terms "first," "second," and various numerical designations are merely distinctions for descriptive convenience and are not intended to limit the scope of the embodiments of this application. For example, they distinguish different indication information.

[0153] Third, "pre-defined," "pre-configured," or "pre-specified" can be achieved by pre-saving corresponding codes, tables, or other means of indicating relevant information in the device (e.g., including terminal devices and network devices), or by pre-defining them in a protocol. This application does not limit the specific implementation method. "Saving" can refer to saving in one or more memories. These memories can be separate installations or integrated into the encoder, decoder, processor, or communication device. Alternatively, some memories can be separately installed, while others are integrated into the decoder, processor, or communication device. The type of memory can be any form of storage medium, and this application does not limit this.

[0154] Fourth, the “protocol” involved in the embodiments of this application may refer to standard protocols in the field of communication, such as 3GPP’s LTE protocols (such as technical specification (TS) 36, i.e., the TS36 series of technical specifications), NR protocols (such as the TS38 series of technical specifications), and related protocols applied to future communication systems. This application does not limit this.

[0155] The network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0156] The network architecture and business scenarios described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0157] To facilitate understanding of the embodiments of this application, let's first take... Figure 4 The communication system illustrated herein is used as an example to illustrate a communication system applicable to embodiments of this application. For example, Figure 4 This is a schematic diagram of the architecture of a communication system to which the method provided in the embodiments of this application applies.

[0158] Figure 4 This is a schematic diagram of the architecture of a communication system, which mainly includes: terminals and network entities.

[0159] The terminal can be a device or module that accesses the communication system and has corresponding communication functions. The terminal can also be called terminal equipment, user equipment (UE), mobile station, or mobile terminal. Specifically, it can be virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearables, smart transportation, smart cities, etc., or it can be a mobile phone, tablet computer, computer with wireless transceiver capabilities, wearable device, vehicle, drone, helicopter, airplane, ship, robot, robotic arm, smart home device, transportation vehicle with wireless communication capabilities, communication module, etc.

[0160] Terminals can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), and the Internet of Things (IoT), such as A-IoT, referred to as A-IoT terminals. The embodiments of this application do not limit the device form of the terminal. Terminals typically contain communication modules, circuits, or chips that perform corresponding communication functions. The terminal can also be configured with program instructions for performing these communication functions.

[0161] It is understandable that there can be one or more terminals. For ease of description, the following text will use the first terminal as an example.

[0162] Network entities can be core network elements, such as network elements that perform IoT management functions. This network element could be an A-IoTMF (Access and Mobility Management Function), primarily responsible for IoT management functions or environmental IoT management functions. Alternatively, it could be an IoT device management function (IDMF), primarily responsible for transmitting business data from IoT devices, managing IoT terminals, ensuring the security of IoT terminals, or instructing readers to perform IoT business operations according to the business operations indicated by the business requester. This application does not limit the naming of the network element performing IoT management functions; it can have other names, such as access and mobility management function (AMF), or any other network element that can be named as such.

[0163] Alternatively, a network entity can also be an access network device, also known as a radio access network (RAN) node, or a network device with core network logical functions. RAN nodes can be 3GPP-related cellular systems, such as 4G, 5G mobile communication systems, or future-oriented evolution systems. RAN nodes can also be open RAN (O-RAN or ORAN), cloud radio access network (CRAN), or wireless fidelity (WiFi) systems. RAN nodes can also be communication systems that integrate two or more of the above systems. RAN nodes are sometimes also referred to as access network devices, RAN entities, or access nodes, forming part of the communication system to help terminals achieve wireless access. Multiple RAN nodes in a communication system can be of the same type or different types.

[0164] In one possible scenario, the RAN node can be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next-generation NodeB (gNB), a base station in a future mobile communication system, or an access node in a WiFi system. The RAN node can be a macro base station, a micro base station, an indoor station, a relay node, a donor node, or a radio controller in a CRAN scenario. Optionally, the RAN node can also be a server, a wearable device, a vehicle, or in-vehicle equipment. For example, the access network equipment in vehicle-to-everything (V2X) technology can be a roadside unit (RSU). All or part of the functions of the RAN node in this application can also be implemented through software functions running on hardware, or through virtualization functions instantiated on a platform (e.g., a cloud platform). The RAN node can also be equipped with communication modules, circuits, or chips that perform corresponding communication functions. The RAN node can also be configured with program instructions for performing corresponding communication functions and corresponding program instructions. The RAN node in this application can also be a logical node, logical module, or software that can implement all or part of the functions of the RAN node.

[0165] In another possible scenario, multiple RAN nodes collaborate to assist the terminal in achieving wireless access, with each RAN node performing some of the functions of the base station. For example, RAN nodes can be central units (CU), distributed units (DU), or radio units (RU), etc.

[0166] In some examples, the CU is a logical node carrying the radio resource control (RRC) layer, service data adaptation protocol (SDAP) layer, packet data convergence protocol (PDCP) layer, and other control functions of the access network equipment. The CU connects to network nodes such as the core network through interfaces, which can be interfaces such as E2 interfaces. Optionally, the CU may have some core network functions. The CU (e.g., PDCP layer and higher layers) connects to the DU (e.g., RLC layer and lower layers) through interfaces, which can be interfaces such as F1 interfaces. In some examples, these interfaces (e.g., F1 interfaces) can provide control plane (C-plane) and user plane (U-plane) functions (e.g., interface management, system information management, UE context management, RRC message transmission, etc.). F1AP is the application protocol of the F1 interface, defining the signaling procedures of F1 in some examples. The F1 interface supports control plane F1-C and user plane F1-U.

[0167] In some examples, the CU can be split into the CU control plane (CU-CP) and the CU user plane (CU-UP). The CU-CP is a logical node carrying the RRC layer and the PDCP control plane (PDCP-C) layer, used to implement the CU's control plane functions. The CU-CP can interact with network elements in the core network used to implement control plane functions. These network elements in the core network can be access and mobility function network elements, such as the AMF in a 5G system. The AMF is responsible for mobility management in the mobile network, such as terminal device location updates, terminal device registration with the network, and terminal device handover. The CU-UP is a logical node carrying the SDAP layer and the PDCP user plane (PDCP-U) layer, used to implement the CU's user plane functions. The CU-UP can interact with network elements in the core network used to implement user plane functions.

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

[0169] In some examples, a DU is a logical node that carries the radio link control (RLC) layer, medium access control (MAC) layer, higher physical layer (PHY) layer, and other functions. In some examples, a DU can control at least one RU. The DU connects to the RU through interfaces, which can be fronthaul interfaces. In some examples, the higher physical layer includes parts of the PHY layer processing, such as forward error correction (FEC) encoding and decoding, scrambling, modulation, and demodulation.

[0170] In some examples, the RU may be included in a radio frequency (RF) device or unit, such as a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). The RU is a logical node that carries both lower physical layer (PHY) and radio frequency (RF) processing. In some examples, the RU may be a 3GPP transmission reception point (TRP), a remote radio head (RRH), or other similar functionalities. In some examples, the Low-PHY includes PHY processing functions such as Fast Fourier Transform (FFT), Inverse Fast Fourier Transform (IFFT), digital beamforming, and filtering. The RU communicates with one or more UEs via a radio link.

[0171] The DU and RU may or may not be co-located. The DU and RU exchange control plane and user plane information via a fronthaul link through a lower-layer split-control, user, and synchronization (LLS-CUS) interface. LLS-CUS may include LLS-C and LLS-U interfaces, respectively providing the control plane (C-plane) and user plane (U-plane). In some examples, the control plane (C-plane) refers to real-time control between the DU and RU. The DU and RU exchange management information via a fronthaul link interface; the management plane (M-plane) refers to non-real-time management operations between the DU and RU.

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

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

[0174] In the ORAN system, RAN nodes communicate with the core network (CN) via backhaul links and with terminals via air interfaces. The ORAN system also includes RAN intelligent controllers (RICs), which can be non-real-time (Non-RT) RAN intelligent controllers and near-real-time (Near-RT) RAN intelligent controllers. The Non-RT RIC is used for non-real-time intelligent management of RAN functions and resides within the Service Management and Orchestration Framework (SMO) module. The Near-RT RIC is used for near-real-time intelligent management of the RAN, achieving near-real-time control and optimization of ORAN modules and resources through data collection and related operations on the E2 interface.

[0175] It is understandable that there can be one or more network entities. For ease of description, the following text will use the first network entity as an example.

[0176] In some examples, the communication system of this application embodiment can be applied to A-IoT scenarios.

[0177] like Figure 5 As shown in (a), the A-IoT terminal and the reader communicate directly in two directions, including interactive environment IoT data and / or signaling, such as the reader sending downlink data / signaling to the A-IoT terminal and the reader receiving uplink data / signaling from the A-IoT terminal.

[0178] like Figure 5 As shown in (b), the A-IoT terminal and the reader communicate bidirectionally through an intermediate node. The intermediate node can be a repeater, an integrated access and backhaul (IAB) node, a UE, or other devices that enable environmental IoT, used to transmit environmental IoT data and / or signaling between the A-IoT terminal and the reader.

[0179] like Figure 5 As shown in (c), the A-IoT terminal receives data / signaling from the auxiliary node and sends data / signaling to the reader; or the A-IoT terminal receives data / signaling from the reader and sends data / signaling to the auxiliary node. The auxiliary node can be a repeater, IAB, UE, or other device capable of realizing environmental IoT.

[0180] like Figure 5 As shown in (d), the A-IoT terminal communicates bidirectionally with the terminal device, such as exchanging environmental IoT data and / or signaling. This terminal device can be a terminal device that supports reader functionality; that is, a reader can also be understood as a terminal device.

[0181] Based on this, the first terminal in the communication system can be Figure 5 In the A-IoT terminal, the first network entity in the communication system acts as an access network device. This access network device can support the functions of a reader, specifically... Figure 5 The combination of one or more readers, intermediate nodes, and auxiliary nodes in the network, such as reader, intermediate node, reader + intermediate node, reader + auxiliary node, etc., or the access network device can also be replaced with Figure 5 The terminal equipment in (d) is used to implement this. When the first network entity acts as an access network device, its equipment form can be a pole station, micro base station, base station, small station, macro station, etc., without any specific restrictions.

[0182] The first terminal can interact with the first network entity to exchange environmental IoT data and / or signaling, and realize corresponding environmental IoT services, such as inventory, positioning, sensing, and command. For example, the first terminal usually needs to send its own identifier to the first network entity. In this case, the first network entity can first specify the identifier length and / or length range by sending first information. If, after receiving the first information, the first terminal determines that the length of its own device identifier meets the preset rules and / or is within the length range, the first terminal can report its own device identifier, such as the first identifier; otherwise, it will not report it, so as to achieve batch and orderly reporting, thereby ensuring the efficiency of the business process on the network side for device identifiers of different lengths.

[0183] Additionally, for access network devices, for identifiers of different lengths from different terminals, the access network devices can allocate transmission resources, or radio resources, that match the length. For example, for identifiers with longer lengths, relatively more transmission resources are allocated, while for identifiers with shorter lengths, relatively fewer transmission resources are allocated. Compared to the existing technology of allocating transmission resources based on the maximum length, this avoids wasting transmission resources and improves communication efficiency.

[0184] It should be understood that the communication method provided in the embodiments of this application can be applied to... Figure 4 The device shown can be specifically implemented using the method embodiments described below, and will not be repeated here. The solutions in this application embodiment can also be applied to other communication systems, and the corresponding names can be replaced by the names of the corresponding functions in other communication systems.

[0185] It should also be understood that Figure 4 This is a simplified diagram for ease of understanding only. The communication system may also include other network devices and / or other terminal devices. Figure 4 It was not drawn in the middle.

[0186] The following will combine Figures 6 to 10 The interaction process between devices in the above-described communication system is specifically described through method embodiments. The communication method provided in this application can be applied to the above-described communication system, and will be described in detail below.

[0187] Figure 6 This is a flowchart illustrating the communication method. Figure 1 This communication method is applicable to the interaction between the first terminal and the first network entity, such as... Figure 6 As shown, the flow of this communication method is as follows:

[0188] S601, the first network entity sends the first information. Correspondingly, the first terminal receives the first information.

[0189] The first information may include M identifier lengths and / or N length ranges, where M and N are positive integers.

[0190] The identifier length can refer to the identifier of the terminal, or the length of the device ID. Device IDs can have various lengths, and it can be understood that there are multiple lengths of device IDs in the network, such as 496 / 128 / 96 bits, or other lengths. This application embodiment does not impose specific limitations. In one possible implementation, the device ID can have multiple types, such as an identifier assigned by the operator, specifically such as the operator-assigned A-IoT device ID, SUPI, IMSI, etc., or an identifier assigned by the enterprise (or a third party or business requester), such as EPC. Please refer to the relevant descriptions above for details. Different types of device IDs may have different lengths, or the same type of device ID may also have multiple lengths, such as the different lengths of EPCs from different enterprises.

[0191] In addition, the specific implementation of equipment identification can be found in the "First Identifier" and "Second Identifier" sections below, and will not be repeated here.

[0192] For any of the M identifier lengths, the identifier length can be a quantized length value. For example, the identifier length can be the number of length units, or expressed by the number of length units. The length unit can be bits, such as 16 bits, 24 bits, 36 bits, 96 bits, 128 bits, 192 bits, 256 bits, 496 bits, etc.; or, the length unit can also be words, such as how many 16 bits, or how many words, are represented by 16 bits as one word; or, the length unit can also be bytes, such as how many 8 bits, or how many bytes, are represented by 8 bits as one byte. Alternatively, the identifier length can also be expressed as an index. For example, for the eight lengths of 16 bits, 24 bits, 36 bits, 96 bits, 128 bits, 192 bits, 256 bits, and 496 bits, the index can be a 3-bit bitmap. For instance, index0 = 000 indicates an identifier length of 16 bits, index1 = 001 indicates an identifier length of 24 bits, index1 = 010 indicates an identifier length of 36 bits, and so on, up to index7 = 111, which indicates an identifier length of 496 bits. Alternatively, the index can be replaced with any other possible name, such as gear, length gear, rank, length rank, type, length type, level, length level, etc., with no specific naming restrictions.

[0193] M identifier lengths can include K different identifier lengths, or in other words, the M identifier lengths contain the same length and / or different lengths, for a total of K possible lengths, where K is a positive integer. For example, if there are 3 identifier lengths in the M identifier set, with the first identifier length being L1, the second identifier length being L2, and the third identifier length being L3, then these 3 identifier lengths include both L1 and L2. As another example, if there are 3 identifier lengths in the M identifier set, with the first identifier length being L1, the second identifier length being L2, and the third identifier length being L3, then these 3 identifier lengths include L1, L2, and L3.

[0194] K identifier lengths can be subsumed under L identifier lengths, where L is an integer greater than or equal to K. In other words, L identifier lengths can be understood as a set of different identifier length types, and K identifier lengths can be understood as a subset of this set. L identifier lengths can be a relatively localized length type, applicable to a specific service requester or service (such as the first service or the service requester of the first service described below). The device identifiers involved in this service requester or service have a total of L identifier lengths, and different service requesters or services may involve different types of identifier lengths. Alternatively, L identifier lengths can be a relatively global length type, applicable to multiple service requesters or multiple services (including the first service or the service requester of the first service described below). The device identifiers involved in these service requesters or services have a total of L identifier lengths. L identifier lengths can be defaulted to by the first network entity (or pre-configured in the first network entity), or they can be dynamically obtained by the first network entity, as described below.

[0195] Scenario 1, dynamically obtained:

[0196] The first network entity can receive service requests from the second network entity and determine L types of identifier lengths based on the service requests. That is, the determination of L types of identifier lengths can be triggered by the service requests, so as to achieve on-demand determination according to service requirements. This will be described in detail below.

[0197] The second network entity can be the requester of the first service, or in other words, the service requester. For example, the second network entity can be an application function (AF) or an application server (AS). Specifically, it can be a third-party application function or application server, or it can be an application function or application server within the operator's network; there are no specific restrictions. The first network entity can receive service requests through other network functions (such as network exposure functions, NEF). The message type of the service request received by the first network entity from other network functions can be the same as or different from the message type of the service request received by those other network functions from the second network entity. That is, the other network function can transparently transmit the service request to the first network entity, or process the received service request (such as changing the message type) before sending it to the first network entity; there are no specific restrictions.

[0198] The primary business can be A-IoT business, or any other possible business, without restriction.

[0199] For example, the first business can be a business related to the application scenario, such as including at least one of the following: inventory business, command business, positioning business, sensing business, proximity determination, reading business, writing business, deactivation business, locking business, or security business (such as authentication, authorization, registration, etc.), or it can be a newly defined business type in the future, and there are no restrictions on the specific naming.

[0200] For example, the first service can also be a process-related service, such as including at least one of the following: access process, or data transmission process, etc., which can be understood as performing the first service being the corresponding process. The access process can be random access, such as contention-based random access or contention-free random access. Optionally, the access process may include reporting the device identifier. The data transmission process can be device (e.g., A-IoT terminal) - reader (device-to-reader, D2R) / uplink data transmission, reader-to-device (reader-to-device, R2D) / downlink data transmission, etc. Optionally, the data transmission process may also include reporting the device identifier. Optionally, the access process and the data transmission process are not strictly distinguished, and the two can be combined. For example, data transmission can also occur within the access process, such as contention-free random access, where the device can send D2R / uplink data in the first message.

[0201] A service request can instruct the execution of a first service for a terminal that meets preset conditions. The terminal meeting these preset conditions can include at least one of the following: a terminal located within the indicated area, a terminal identified as an identifier type, a terminal whose identifier contains specified characteristics, or any other possible condition, without specific limitations. For example, a service request can include at least one of the following information elements: service requester identifier, type of the first service, identifier of the first service, information about the indicated area, identifier type information (denoted as identifier type information #1), or identifier description information (denoted as identifier description information #1), which will be described below.

[0202] 1) The service requester identifier can indicate the service requester, such as AF ID. The operator network can store subscription information related to the service requester, such as the area or device identification range that allows the execution of the first service, so that the operator network can authorize the execution of the first service based on the subscription information.

[0203] 2) The type of the first service can indicate the type of the first service, such as inventory service, command service, positioning service, sensing service, proximity determination, read service, write service, deactivation service, lock service, or security service (such as authentication, authorization, registration, etc.), or it can be a newly defined service type in the future, and there are no restrictions on the specific naming.

[0204] 3) The identifier for the first service can be used to uniquely identify the first service, and the specific identifier type is not limited. In one possible implementation, the identifier for the first service can identify the type of the first service. In another possible implementation, the identifier for the first service can identify the service request, such as a service identifier (transaction ID).

[0205] 4) The information indicating the region can indicate one or more regions, such as being represented by geometric (geographical) location information, such as province, city, district, or coordinate values, latitude and longitude ranges, etc., or it may be represented by topological (network) location information that can be recognized by network elements within the core network, such as data network access identifier (DNAI), track area identifier (TAI), TAI list, area ID, area ID list, reader identifier, reader identifier list, cell ID, or cell ID list, etc. In another possible implementation, the information indicating the region can be represented by configuration information configured in the core network elements. This information can include the correspondence between indexes and location information, or the correspondence between indexes and reader IDs / reader ID sets. The index can be a target ID or a target set ID; the location information can be the aforementioned geometric (geographical) location information, or topological (network) location information that can be recognized by the core network elements, etc. If the reader is an access network device, the reader identifier can be gNodeB ID, RAN ID, etc. If the reader is a terminal device, the reader identifier can be UE ID, GPSI, SUPI, or GUTI, etc.

[0206] 5) Identifier type information #1 can indicate the identifier type of the device identifier, which can be one or more of the following: an identifier assigned by the operator network, an identifier assigned by a non-operator network, a product electronic identifier, such as EPC, or a non-product electronic identifier, such as non-EPC.

[0207] 6) Identifier description information #1 (or identifier feature information) can indicate a specific value in the device identifier, or a part of the device identifier that needs to be matched, such as the specific value of the x-th bit of the device identifier, for example, the value of the 3rd bit is 1, or the specific values ​​from the x-th bit to the y-th bit, for example, the 0th bit to the 7th bit is 11001110.

[0208] Therefore, the information elements contained in the service request can be combined to instruct the execution of the first service for at least one of the following: a terminal located in the indicated area, a terminal whose device identifier belongs to the identifier type indicated by identifier type information #1, or a terminal whose device identifier contains a specific value indicated by identifier description information #1.

[0209] It should be understood that the business request is an exemplary name, which can be replaced with a more specific name. For example, if the first business is an inventory management business, the business request can be replaced with "Inventory Management Request." Similarly, if the first business is a deactivation business, the business request can be replaced with "Deactivation Request." Furthermore, if the first business is a command, such as read / write / lock, the business request can be replaced with "Command." In this case, the message name of the business request can serve as information indicating the type of the first business.

[0210] It can be seen that the terminals targeted by the service requests are usually non-deterministic. The first network entity may assume that these terminals may have device identifiers of various lengths, or that it cannot determine whether the device identifiers of these terminals have a single length. Alternatively, the first network entity may not be able to determine the specific mask and also assume that these terminals may have device identifiers of various lengths. Therefore, the first network entity can obtain L types of identifier lengths.

[0211] For example, a third network entity is pre-configured with L types of identifier lengths. This third network entity can be a data management network element, such as a unified data management (UDM) network element, or a data storage network element, such as a unified data repository (UDR) network element. Thus, the first network entity can obtain the L types of identifier lengths from the third network entity based on a business request. For example, the first network entity can schedule the service interface of the third network entity to request an identifier length. The third network entity can determine the L types of identifier lengths based on the request from the first network entity. In one possible implementation, the L types of identifier lengths are relatively localized, such as those applicable to the first business or the business requester of the first business. In this case, the third network entity can select the identifier length involved in the first business or the business requester of the first business from the global length types, i.e., the L types of identifier lengths, based on the request from the first network entity. For example, if there are 8 global length types, the identifier length involved in the business requester is one of the 1st to 3rd types. Alternatively, the L types of identifier lengths are relatively global, and the third network entity can obtain the global length type, i.e., the L types of identifier lengths, by default based on the request from the first network entity. Subsequently, the third network entity can send L types of identifier lengths to the first network entity. Alternatively, the service request can also contain L types of identifier lengths, meaning the L types of identifier lengths can be pre-configured by the second network entity, and the service request is passed to the first network entity. In this case, the first network entity can obtain the L types of identifier lengths from the service request, thereby reducing the interaction overhead between network elements / entities.

[0212] Scenario 2, pre-configured or default:

[0213] The L identifier lengths can also be the default identifier length of the first network entity, meaning the first network entity can preconfigure or predefine the L identifier lengths according to the protocol. If the first network entity determines, based on the service request, that there may be multiple device identifier lengths, then the first network entity can obtain the L identifier lengths locally without needing to obtain them from signaling or other network elements / entities, thereby further reducing overhead.

[0214] The first network entity can select K identifier lengths from L identifier lengths as the required length for the identifiers to be reported, based on actual needs. For example, if there are many types of identifier lengths, i.e., L is large, the first network entity can select some of the identifier lengths as the required length for the reported identifiers each time. For example, if L = 8, four lengths can be selected this time, i.e., K = 4, which means reporting in batches to reduce the overhead of each report. Conversely, the first network entity can select all types of identifier lengths as the required length for the reported identifiers at once, i.e., reporting all at once to reduce the overall latency of the business process.

[0215] The length range refers to the range in which the terminal identifier, or device identifier, is located.

[0216] For any of the N length intervals, the length interval can be represented by a quantized length value, such as [Lmin, Lmax], (Lmin, Lmax], [Lmin, Lmax), or (Lmin, Lmax). Lmin and Lmax are endpoint values, which can be a specific number of bits or a number of length units. For details, please refer to the above introduction on identifier lengths, which will not be repeated here. Alternatively, the length interval can also be represented by an index, such as index0 = 000, representing a length interval of [16 bits, 24 bits], index1 = 001, representing a length interval of (24 bits, 36 bits), and so on. For details, please refer to the above introduction on identifier lengths, which will not be repeated here. Furthermore, there are no restrictions on the open or closed form of the length interval. When dealing with the minimum or maximum value of the identifier length, it is possible for all intervals to be closed, such as using the minimum value as L1. The maximum value is L2. Dividing it into two length intervals can be represented as [L1,Ln1], (Ln1,L2] or [L1,Ln1), [Ln1,L2]. Dividing it into three length intervals can be represented as [L1,Ln1], (Ln1,Ln2], (Ln2,L2] or [L1,Ln1), [Ln1,Ln2), [Ln2,L2], and so on. The values ​​of Ln1 and Ln2 are between L1 and L2.

[0217] N length intervals can include S types of length intervals, or in other words, N length intervals contain intervals with the same length and / or different length intervals, resulting in a total of S types of intervals, where S is a positive integer. For example, if there are 3 N length intervals, with the first length interval being [L1, Ln1), the second length interval being [L1, Ln1], and the third length interval being (Ln1, L2] (meaning the first and second length intervals are the same), then these 3 length intervals include the two types of intervals [L1, Ln1] and (Ln1, L2]. As another example, if there are 3 N length intervals, with the first length interval being [L1, Ln1), the second length interval being [Ln1, Ln2), and the third length interval being [Ln2, L2], then these 3 length intervals include the three types of intervals [L1, Ln1), [Ln1, Ln2), and [Ln2, L2].

[0218] S length intervals can belong to T length intervals, where T is an integer greater than or equal to S. That is, T length intervals can be understood as a set of different intervals, and S length intervals can be understood as a subset of this set. The T length intervals can be determined by default by the first network entity, or they can be dynamically obtained by the first network entity. The specific implementation is similar to that of the L identifier lengths mentioned above, and can be referred to for understanding; it will not be elaborated further here. Alternatively, the T length intervals can also be determined based on the L identifier lengths, such as using any two identifier lengths from the L identifier lengths as endpoint values ​​to determine the T length intervals.

[0219] Optionally, the first information may also include the reporting length. The reporting length can be a unique reporting length applicable to the M identifier lengths and / or N length intervals. Alternatively, the reporting length can also be the reporting length corresponding to each of the M identifier lengths and / or N length intervals; these reporting lengths may be the same or different. For example, for the same identifier length, its corresponding reporting length is usually the same, and vice versa. Similarly, for the same length interval, its corresponding reporting length is usually the same, and vice versa. The reporting length corresponding to each length interval is usually located within that length interval. For an identifier length matching a certain length interval, such as an identifier length located within that length interval, the length interval and the reporting length corresponding to that identifier length can be the same. For example, if identifier lengths are 24 bits and 36 bits respectively, and they are located within a length interval of 0 to 50 bits, their corresponding reporting length can be 30 bits. Furthermore, similar to the identifier lengths described above, the reporting length can also be represented by a quantized length value or by an index; for details, please refer to the relevant introduction to identifier lengths, which will not be elaborated here. In addition, the method by which the first network entity obtains the reported length is similar to that of obtaining the identifier length or length range mentioned above. For example, it can be provided by the second network entity, obtained from the third network entity, or determined by the first network entity itself. This can be understood by reference and will not be elaborated here.

[0220] The first information can be carried in the mask, that is, the existing information cells are reused to transmit the first information to reduce the implementation difficulty, or it can be transmitted independently, decoupled from the existing information cells, making information transmission more flexible. Optionally, the mask may also include at least one of identification type information (denoted as identification type information #2) or identification description information (denoted as identification description information #2).

[0221] The identifier type information #2 can be determined based on the identifier type information #1 mentioned above. For example, the first network entity can determine the identifier type information #1 as the identifier type information #2, or it can select a portion of the identifier types indicated by the identifier type information #1 as the identifier type indicated by the identifier type information #2. Specifically, it can be one or more of the following four identifier types: identifiers assigned by the operator network, identifiers assigned by a non-operator network, product electronic identifiers, or non-product electronic identifiers, to achieve orderly reporting by length and / or by type; or, the identifier type information #2 can also be determined by the first network entity itself, such as deciding what type of identifier to store this time and carrying it into the mask; or, the identifier type information #2 can also be determined based on the identifier of the service requester. For example, the operator network (such as the third network entity or the first network entity locally) stores the correspondence between the identifier of the service requester and the identifier type. The first network entity can determine the identifier type information #2 corresponding to the identifier of the service requester based on the identifier of the service requester and the correspondence, and carry it into the mask. The content indicated by different identification type information #2 can be different. The implementation of each identification type information #2 is similar, so it will not be described in detail.

[0222] Identifier description information #2 can indicate a specific value in the device identifier, or a portion of the device identifier that needs to be matched. Identifier description information #2 can also be determined based on the aforementioned identifier description information #1. For example, the first network entity can determine identifier description information #1 as identifier description information #2, or the first network entity can select a portion of the information contained in identifier description information #1 as identifier description information #2. For example, identifier description information #1 contains the specific value of the x-th bit of the device identifier, or the specific values ​​from the x-th to the y-th bit, and the first network entity selects the specific values ​​from the x-th to the y-th bit as identifier description information #2. There can be one or more identifier description information #2s, and the content indicated by different identifier description information #2s can be different. The implementation of each identifier description information #2 is similar and will not be described in detail further.

[0223] For example, an exemplary structure for a mask can be shown in Table 1 below.

[0224] Table 1

[0225]

[0226] As shown in Table 1, the mask may specifically include at least one of the following: first information, length field, offset field, and value field. In the mask, the first information can be a 12 / 16 / 24-bit cell, or it can be a cell of other bit numbers; the first information can be carried as an independent cell, or it can be encapsulated within other cells of the mask, and the specific implementation is not limited. The length field and offset field can have the same number of bits, such as an 8-bit cell, or they can have different numbers of bits, without limitation. The value field can be a cell of up to 256 bits, or it can have other values, without limitation. At least one of the length field, value field, and offset field can be used to represent identification description information #2 or identification type information #2.

[0227] For example, for the identification description information #2, taking the length field #1, offset field #1, and value field #1 as an example:

[0228] The length field #1 indicates the length of the value field #1. For example, when the value field #1 represents the value 3, if the length field #1 indicates a length of 3 bits, then the value field #1 can represent the identification description information #2 as 011 using 3 bits; if the length field #1 indicates a length of 5 bits, then the value field #1 can represent the identification description information #2 as 00011 using 5 bits. If the mask does not contain the length field #1, then the value field #1 can be a specific form of bits, such as a bit string, for example, 011 or 00011, to represent the identification description information #2. The offset field #1 indicates the bit position of the value field #1 (or the identification description information #2) within the device identifier, or the offset relative to the most significant bit. Similarly, if the mask includes multiple identifier description information #2, it can also be represented by length field #2, offset field #2 and value field #2, as well as length field #3, offset field #3 and value field #3 (not shown in Table 1), etc. The principle is similar and will not be elaborated further.

[0229] For example, for identification type information #2, let's still take the length field #1, offset field #1, and value field #1 as an example:

[0230] When there are four device identifier types, identifier type information #2 can be one of them. The length field #1 can indicate a 2-bit length, and the value field #1 is also 2 bits. For example, 00 represents a value of 0, meaning identifier type information #2 is the first device identifier type; 01 represents a value of 1, meaning identifier type information #2 is the second device identifier type; 10 represents a value of 2, meaning identifier type information #2 is the third device identifier type; and 11 represents a value of 3, meaning identifier type information #2 is the fourth device identifier type. Furthermore, when the device identifier also contains identifier type information #2 (see the description below for details), the offset field #1 can indicate the bit position of value field #1 (or identifier type information #2) within the device identifier, or the offset relative to the most significant bit. In this case, it can also be considered that identifier description information #2 can include identifier type information #2, meaning that specific values ​​contained in identifier description information #2 can implicitly represent identifier type information #2. Similarly, if the mask includes multiple identifier type information #2, it can also be represented by length field #2, offset field #2 and value field #2, as well as length field #3, offset field #3 and value field #3 (not shown in Table 1), etc. The principle is similar and will not be elaborated further.

[0231] It should be understood that if there is only one identifier type information #2 or identifier description information #2, then the length field #2, offset field #2, and value field #2 may be omitted. Additionally, the mask can be optional information; when no mask is provided, it can indicate any terminal (or all terminals). Alternatively, the identifier type information #2 and / or identifier description information #2 contained in the mask may not indicate a value, or may indicate an arbitrary value, and can also indicate any terminal (or all terminals).

[0232] It should also be understood that the mask is an exemplary name and can be replaced with any other possible name, such as paging identifier, paging code, etc., without any specific restrictions.

[0233] For the first network entity, if it is a core network element (e.g., A-IoTMF) and the access network device supports reader functionality, or acts as a reader, then the core network element can send a mask to the access network device, which will then forward it. This mask can be included in selection and / or paging messages, or any other possible messages, and then broadcast. Alternatively, if the first network entity is a core network element and the terminal device supports reader functionality, or acts as a reader, then the core network element can first send a mask to the access network device, which will then forward it to the terminal device. The terminal device will then include the mask in selection and / or paging messages, or any other possible messages, and then broadcast it. If the first network entity is an access network device that supports reader functionality, then the access network device can directly broadcast the mask, such as broadcasting selection and / or paging messages carrying the mask, or any other possible messages; the specific message type is not limited. Of course, the first information may not be carried in the mask. For example, the first network entity can send the first information independently. Its sending method is similar to the mask types described above and will not be elaborated further. In this case, the first network entity can still send the mask, or not send the mask; there are no specific restrictions. Correspondingly, the first terminal can receive the first information, such as receiving the mask and obtaining the first information from it, or receiving the first information independently. The first terminal is a terminal that meets the above preset conditions.

[0234] S602, the first terminal sends its first identifier according to the first information. Correspondingly, the first network entity receives the first identifier of the first terminal.

[0235] The first identifier can be the identifier reported by the first terminal. If the information contained in the first information is different, then the implementation of the first identifier will also be different, which will be described in detail below.

[0236] Case 1: The first piece of information includes M identifiers of length.

[0237] The length of the first identifier can satisfy a preset rule with the length of the first identifier among the M identifier lengths. This preset rule can include: the length of the first identifier is the same as the length of the first identifier, or the first identifier is determined based on the second identifier of the first terminal, and the length of the second identifier is the same as the length of the first identifier. The second identifier can be the identifier of the first terminal, used to uniquely identify the first terminal. As shown in Table 2 below, the second identifier can contain one or more of the following parts.

[0238] Table 2

[0239]

[0240] In Table 2 above:

[0241] 1) A sequence (or entity / instance) can be used to identify the first terminal, meaning the second identifier can identify the first terminal through its contained sequence, such as consecutive characters, strings, numbers, arrays, or codes. If the second identifier is an identifier assigned by an operator network, since the Public Land Mobile Network (PLMN) ID itself can distinguish different operator networks, the operator network only needs to ensure that the sequence is unique within that operator network when assigning the sequence, in order to shorten the sequence length. If the second identifier is a product electronic identifier, it may be impossible to distinguish different operator networks because the home network ID is a special value (see below). When a third-party organization assigns this sequence, the sequence needs to be globally unique.

[0242] 2) The home network identifier can represent the network that manages the first terminal or the network that assigned the terminal identifier to the first terminal, such as the network that performs identifier verification or security authentication operations on the first terminal. This network stores the first terminal's subscription data, information, or security parameters such as keys. The home network identifier can be a PLMN ID, such as a mobile country code (MCC) and a mobile network code (MNC). If the second identifier is not assigned by the operator, or is not assigned by the operator, such as an identifier assigned by a third-party organization, such as an EPC, then the home network identifier can be a special value that does not represent any specific network or operator. For example, it can be 999999, or any other possible value, to indicate that the second identifier is not assigned by the operator. Additionally, the home network identifier is optional, and the second identifier may not contain this information.

[0243] 3) The device ID length can be used to indicate the length of the second identifier. The device ID length can also be represented by a quantized length value or by an index; please refer to the above introduction on identifier length for details, which will not be repeated here. The device ID length can be part of the second identifier or stored independently of the second identifier. Alternatively, the device ID length can be dynamically calculated without storing this information; please refer to the relevant introduction below for details, which will not be repeated here. Furthermore, the device ID length is optional, and the second identifier may not contain this information.

[0244] 4) Identifier type information (denoted as Identifier Type Information #3), for example, IsEPC, can characterize the type of sequence. Identifier type information can indicate whether it is an identifier assigned by an operator or an identifier assigned by a third party, such as whether it is constructed based on an electronic product code (EPC). If the sequence is constructed based on an EPC, or has an identifier assigned by a third party, or has an identifier not assigned by an operator, then the Identifier Type Information can be set to 1. If the sequence is not constructed based on an EPC, or has an identifier assigned by an operator, or has an identifier not assigned by a third party, then the Identifier Type Information can be set to 0, or vice versa. Alternatively, Identifier Type Information #3 can also be replaced with the aforementioned Identifier Type Information #2. Identifier type information is optional. For example, if the sequence has an identifier assigned by a non-operator network, then the home network identifier is a special value that can implicitly indicate that the sequence has an identifier assigned by a third party, or is constructed based on an EPC. Therefore, the second identifier may not contain identifier type information. However, in the scenario of the first terminal for operator network management, the identifier assigned by the operator network (such as the sequence mentioned above) may also be assigned by a third party or constructed based on EPC. In this case, the home network identifier being a special value does not indicate whether it is an identifier assigned by a third party or whether it is constructed based on EPC. Therefore, it is necessary to indicate it through identifier type information.

[0245] Based on this, if the first information does not include the reported length, the first terminal can determine that the length of the second identifier is the same as the length of one of the M identifier lengths. For example, the first terminal can obtain the device identifier length from the second identifier, or from other storage areas, or determine the device identifier length based on the address of the second identifier in the storage area. The address of this storage area can be pre-configured in the first terminal or provided by the first network entity, such as a start address and an end address. If the above length unit is bits, then the end address is set to addr1, the start address to addr2, addr1-addr2=Δaddr, and the number of bits contained in Δaddr is the device identifier length. If the above length unit is a word or byte, then the end address is set to addr1, the start address to addr2, addr1-addr2=Δaddr, and the number of bits contained in Δaddr divided by the number of bits contained in a word or byte is the device identifier length. The first terminal can determine whether the device identifier length is the same as the length of one of the M identifier lengths. If the device identifier length is the same as the first identifier length, the first terminal will report the second identifier as the first identifier, that is, the second identifier and the first identifier are the same identifier.

[0246] If the first information also includes the reported length, then if the first terminal determines that the length of the second identifier is the same as the length of the first identifier, the first terminal can also determine the length relationship between the length of the second identifier and the reported length.

[0247] For example, if the length of the second identifier is greater than the reporting length, the first terminal can truncate the second identifier to the reporting length to obtain the first identifier. Truncation can be done in either forward or backward order. For instance, if the second identifier is 120 bits long and the reporting length is 96 bits, the first terminal can remove either the last 24 bits or the first 24 bits of the second identifier to obtain the first identifier. Alternatively, truncation can be done from the middle, such as truncating the part before the x-th bit and the part after the y-th bit of the second identifier. There are no specific restrictions on the method. Other methods are also possible, such as using the first x1 bits after the specific value indicated by the mask in the second identifier as the first identifier, where x1 is the reporting length.

[0248] For example, if the length of the second identifier is less than the reporting length, the first terminal will pad the second identifier to the reporting length to obtain the first identifier. This padding can be done by adding bits set to 0 or 1 at the end of the second identifier. For instance, if the second identifier is 70 bits and the reporting length is 96 bits, the first terminal can pad the end of the 70 bits with 26 bits set to 0 to obtain the first identifier.

[0249] For example, when padding occurs after the end, whether the second identifier is filled with a 0 or a 1 depends on the bit value of the last character in the second identifier. If the last character's bit value is 0, then a 1 is filled; if the last character's bit value is 1, then a 0 is filled. Similarly, when padding occurs before the beginning, whether the second identifier is filled with a 0 or a 1 depends on the bit value of the first character in the second identifier. If the first character's bit value is 0, then a 1 is filled; if the first character's bit value is 1, then a 0 is filled. In other words, the difference in bit values ​​indicates that subsequent 1-bit values ​​represent padding, enabling the network to correctly identify the padding portion in the first identifier and obtain the second identifier from it.

[0250] For example, if the length of the second identifier is equal to the reported length, then the second identifier and the first identifier are the same identifier.

[0251] Case 2: The first piece of information includes N length intervals.

[0252] The length of the second identifier can be located within the first length interval of N length intervals.

[0253] For example, if the first information does not include the reported length, the first terminal can determine that the length of the second identifier is within the first length range and report the second identifier as the first identifier, that is, the second identifier and the first identifier are the same identifier.

[0254] For example, if the first information also includes the reporting lengths corresponding to N length intervals, then, after determining that the length of the second identifier is within the first length interval, the first terminal can also determine the length relationship between the second identifier and the reporting length. If the length of the second identifier is greater than the reporting length, the first terminal can truncate the second identifier to the reporting length to obtain the first identifier. If the length of the second identifier is less than the reporting length, the first terminal can pad the second identifier to the reporting length to obtain the first identifier. If the length of the second identifier is equal to the reporting length corresponding to the first length interval, then the second identifier and the first identifier are the same identifier. The specific implementation of truncation and padding can be referred to the relevant introduction in Case 1 above, and will not be repeated here.

[0255] Furthermore, Situations 1 and 2 above can be implemented in combination. For example, the first information includes M identifier lengths and N length intervals. The first terminal needs to determine whether the length of the second identifier is the same as the length of one of the M identifier lengths, and whether the length of the second identifier is within one of the N length intervals. If these conditions are met, the first terminal reports the second identifier as the first identifier; otherwise, it does not report it. Optionally, if the first information also includes a reporting length, then if the above conditions are met, the first terminal further shortens / pads / does not process the second identifier according to the reporting length to obtain the first identifier, and then reports the first identifier.

[0256] As can be seen, the aforementioned first identifier can be an identifier directly reported by the first terminal, or it can be an identifier reported after processing. The specific choice can be made based on the implementation flexibility. For example, if there are few types of identifier lengths, the network (such as the first network entity) can choose to report directly. Otherwise, the network can choose to report after processing, such as truncating / padding to the same reporting length before reporting, in order to improve the execution efficiency of the business process.

[0257] Optionally, if the mask also includes identifier type information #2, the first terminal must also determine whether the type of the first identifier matches (or is the same as) the identifier type indicated by identifier type information #2. For example, if the identifier type is a product electronic identifier, and the type of the first identifier / second identifier is also a product electronic identifier, then it is considered a match, and the first terminal reports the first identifier; otherwise, it is not reported. Similarly, if the mask also includes identifier description information #2, the first terminal must also determine whether the second identifier contains the specific value indicated by identifier description information #2. For example, if the specific value is that the xth to yth bits of the device identifier are 1011, and the xth to yth bits of the second identifier are also 1011, then it is considered a match, and the first terminal reports the first identifier; otherwise, it is not reported.

[0258] If the first network entity is a core network element, such as A-IoTMF, and the access network device supports the function of a reader, or acts as a reader, then the first terminal can send the first identifier to the access network device, which will then forward it to the core network element. Alternatively, if the first network entity is a core network element and the terminal device supports the function of a reader, or acts as a reader, then the first terminal can first send the first identifier to that terminal device, which will then forward it to the access network device, and finally forward it to the core network element. If the first network entity is an access network device that supports the function of a reader, then the first terminal can directly send the first identifier to that access network device. The first identifier can be carried in any possible message, whether it is an existing message or a newly defined message; there are no restrictions on its specific naming or type.

[0259] In summary, the first network entity can specify the identifier length and / or length range by sending the first information. If, after receiving the first information, the first terminal determines that the length of its own device identifier meets the preset rules and / or falls within the specified length range, the first terminal can report its own device identifier, such as the first identifier. Otherwise, it will not report it, thus achieving batch-order reporting. This ensures that the network side can maintain the efficiency of the business process even for device identifiers of different lengths. Furthermore, since the length of the first identifier reported by the first terminal is fixed, the network side can allocate corresponding transmission resources based on the length of the first identifier, improving resource utilization. It also eliminates the need to rely on the tail pilot to determine the end point of the first identifier, making it applicable to wireless communication systems.

[0260] Optionally, in conjunction with the above S601-S602, the method further includes: the first network entity sending second information.

[0261] The second information includes P identifier lengths and / or Q length intervals, where P and Q are positive integers.

[0262] The P identifier lengths differ from the M identifier lengths; the P identifier lengths encompass L types of identifier lengths. Similarly, the Q length intervals differ from the N length intervals; the different intervals contained within the Q length intervals also belong to T length intervals, enabling batch reporting. For example, if there are 4 types of identifier lengths (L), the M identifier lengths include the first 2 / 3, and the P identifier lengths include the last 2 / 3. Or, for another example, if there are 4 types of length intervals (T), the N length intervals include the first 2 / 3, and the Q length intervals include the last 2 / 3.

[0263] The first and second information can be carried in the same message. For example, if the first network entity is a core network element, the core network element can send a message to a reader (such as an access network device or terminal device that supports reader functionality). This message can contain a task identifier assigned by the core network element, as well as the first and second information. The access network device then sends the first and second information in batches, such as sending the first and second information separately in different random access procedures. Alternatively, the first and second information can also be carried in separate messages. If the first network entity is a core network element, the core network element can send the first and second information to the reader (such as an access network device or terminal device that supports reader functionality) through different messages. These different messages can also carry different task identifiers assigned by the core network element, which are then forwarded by the reader to the corresponding terminal.

[0264] Furthermore, the terminal that receives the second information, such as the second terminal, reports its identifier in a similar way to the first terminal, which can be understood by reference and will not be elaborated here.

[0265] It should be understood that, in the above Figure 6 In the method shown, the first network entity can also be replaced by a terminal device that supports reader functionality. Figure 6 The method shown is only one example. For instance, the first information could also be replaced with a reporting length, meaning the first network entity could issue a reporting length to instruct the device identifier to be reported according to that length. The first terminal then fills in or truncates its own device identifier to the reporting length and then reports it.

[0266] The above combination Figure 6 The workflow of the communication method provided in the embodiments of this application is described below. Figures 7-8 The specific process of the communication method provided in the embodiments of this application is described in detail.

[0267] Figure 7 Flowchart of the communication method provided in the embodiments of this application Figure 2 .like Figure 7As shown, the process involves AF (such as the second network entity), NEF network element, UDM / UDR network element (such as the third network entity), A-IoTMF network element (such as the first network entity), reader, A-IoT device #1 (such as the first terminal), and A-IoT device #2 (such as the second terminal).

[0268] Specifically, such as Figure 7 As shown, the flow of this communication method is as follows:

[0269] S700a, UDM / UDR network elements are pre-configured with identifier length and / or length range.

[0270] The identifier length pre-configured for UDM / UDR network elements can be one of the L identifier lengths mentioned above, and the length range can be one of the S length ranges mentioned above. For details, please refer to the relevant introduction in S601 above, which will not be repeated here. Optionally, UDM / UDR network elements can also pre-configure length ranges. For details, please refer to the relevant introduction in S601 above, which will not be repeated here.

[0271] It should be understood that S700a is optional, and L-type identifier length and / or S-type length range can also be carried in the following business request.

[0272] S700b, A-IoT device #1 pre-configures the device identifier length of A-IoT device #1.

[0273] The identifier length of A-IoT device #1 can be the length of device identifier #1 of A-IoT device #1 (such as the second identifier mentioned above).

[0274] S700c, A-IoT device #2 pre-configured device identifier length for A-IoT device #2.

[0275] The device identifier length of A-IoT device #2 can be the length of device identifier #A of A-IoT device #2.

[0276] It should be understood that S700c is optional, and the embodiments of this application may only involve A-IoT device #1, without A-IoT device #2.

[0277] S701, AF sends service request #1 to NEF network element.

[0278] Service request #1 can instruct the execution of a first service, such as inventory management, for terminals that meet preset conditions.

[0279] Business request #1 may include at least one of the following: business requester identifier, such as AF ID; type of the first business, such as inventory business; information of the first business, such as inventory business identifier; information of the indication area; identifier type information #1; or identifier description information #1. Optionally, it may also include L types of identifier lengths and / or S types of length ranges. Optionally, it may include the reporting length, as detailed above. Figure 6 The details regarding business requests will not be repeated here.

[0280] S702, the NEF network element sends service request #2 to the A-IoTMF network element.

[0281] In this context, business request #2 and business request #1 can be the same message or different messages, without restriction. If business request #2 and business request #1 are different messages, then business request #2 also contains the content of business request #1. That is, the NEF network element obtains the content of business request #1 and then carries it into business request #2.

[0282] In one implementation, the AF can send service request #1 to the AIoTMF (e.g., when the AF is trusted).

[0283] S703, A-IoTMF network elements need to be inventoried in batches.

[0284] A-IoTMF network elements can determine the existence of multiple identifier lengths based on the fact that the terminal is a non-deterministic terminal under preset conditions, thus determining the need for batch inventory, i.e., inventorying according to different identifier lengths. In one possible implementation, batch inventory can be understood as breaking down the business operation corresponding to business request #1 into several processes or tasks. For example, by sending multiple inventory requests to the reader, each inventory request executes an inventory process for a different A-IoT device. In these multiple inventory processes, different A-IoT devices can be distinguished by different device identifier lengths.

[0285] S704, the A-IoTMF network element obtains L types of identifier lengths and / or S types of length ranges from the UDM / UDR network element.

[0286] S704 is optional. If the service request #2 carries L types of identifier length and / or S types of length range, the A-IoTMF network element can also obtain L types of identifier length and / or S types of length range from the service request #2. S704 can also refer to the relevant introduction in S601 above, and will not be repeated here.

[0287] Optionally, the A-IoTMF network element can also obtain the reporting length from the UDM / UDR network element or service request #2.

[0288] S705, the A-IoTMF network element sends inventory #1 to the reader.

[0289] Inventory #1 can also be called inventory message #1, inventory instruction #1, or any other possible name, without any restrictions.

[0290] Inventory #1 may contain at least one of the following: task ID #1, ID length #1 and / or length range #1, and mask #1.

[0291] Task identifier #1 can be an identifier assigned by an A-IoTMF network element for batch inventory checks. For example, if the first round of inventory checks is considered as a task, such as task #1, a task identifier #1 is assigned to task #1 to indicate task #1. Alternatively, task identifier #1 can be an identifier assigned by the NEF based on the service request #1 sent by the AF. Task identifier #1 can also be called a transaction identifier (e.g., transaction ID) or other names; this invention does not limit the name of the task identifier. Information that can be used to identify the service operation or process performed in response to service request #1 can be used as a task identifier. Identifier length #1 can be one of L types of identifier lengths, and length range #1 can be one of S types of length ranges. Identifier length #1 and / or length range #1 can be understood as the first information mentioned above; for details, please refer to the relevant description of the first information mentioned above, which will not be repeated here. Identifier length #1 can be carried in mask #1 or used as an independent information element other than mask #1. Mask #1 can refer to the relevant description of masks mentioned above, which will not be repeated here.

[0292] Optionally, if the A-IoTMF network element obtains the reporting length in S703, then inventory #1 may also include the reporting length.

[0293] S706, the reader sends selection message #1 or paging message #1.

[0294] Select message #1 or paging message #1 can carry identifier length #1 and / or length range #1, as well as mask #1, and optionally also include the reporting length.

[0295] S707, A-IoT device #1 determines that the device identifier length matches.

[0296] Optionally, if the reader sends the identifier length #1 and / or length range #1 in S706 (e.g., as an independent cell or carried in a mask #1), then A-IoT device #1 can determine whether the device identifier length of A-IoT device #1 is the same as the identifier length #1, and / or whether the device identifier length of A-IoT device #1 is within the length range #1. If yes, A-IoT device #1 determines that the device identifier lengths match; otherwise, A-IoT device #1 determines that the device identifier lengths do not match, or determines not to continue with subsequent steps.

[0297] Optionally, if message #1 or paging message #1 includes a reporting length, then A-IoT device #1, after determining that the device identifier length matches, can also determine the size relationship between the device identifier length and the reporting length. If A-IoT device #1 determines that the device identifier length is greater than the reporting length, then A-IoT device #1 can truncate device identifier #1 (i.e., the second identifier) ​​to the reporting length to obtain device identifier #2 (i.e., the first identifier). If A-IoT device #1 determines that the device identifier length is less than the reporting length, then A-IoT device #1 can fill device identifier #1 into the reporting length to obtain device identifier #2. If A-IoT device #1 determines that the device identifier length is equal to the reporting length, then A-IoT device #1 can do nothing, and device identifier #1 is device identifier #2.

[0298] It is understood that the description of the second identifier can be referred to as above for device identifier #1, and the description of the first identifier can be referred to as above for device identifier #2. These will not be repeated here.

[0299] If the device identifier length matches, A-IoT device #1 performs random access, such as S708.

[0300] Optionally, if the reader sends mask #1 in step S706, then if the device identifier #1 matches the mask #1, the A-IoT device #1 performs random access, as in step S708.

[0301] Optionally, if the reader sends the identifier length #1 and / or length range #1, and the mask #1 in step S706, then AIoT device #1 performs random access if the device identifier length matches and the device identifier #1 matches the mask #1, as in step S708.

[0302] S708, A-IoT device #1 sends device identifier #2.

[0303] In one possible implementation, A-IoT device #1 sends device identifier #2 to the reader, and the reader sends device identifier #2 to the A-IoTMF network element.

[0304] In another possible implementation, A-IoT device #1 (via a reader) sends a UL NAS message #1 to the A-IoTMF network element. The UL NAS message #1 may carry the device identifier #2.

[0305] S709, A-IoTMF network element performs verification on device identifier #2.

[0306] The A-IoTMF network element's verification of device identifier #2 can include checking if its length matches, if the content is complete, and if device identifier #2 is a valid device identifier. Furthermore, step S709 is optional; the A-IoTMF network element may choose not to perform this verification or to perform other operations, without specific restrictions.

[0307] It is understood that there may be one or more A-IoT devices #1, that is, the above S705-S709 process can be applied to A-IoT devices whose device identifier length is the same as the identifier length #1, and / or whose device identifier length is within the length range #1.

[0308] S710, the A-IoTMF network element sends inventory #2 to the reader.

[0309] Similar to inventory #1, inventory #2 can also be called inventory message #2, inventory instruction #2, or any other possible name, without limitation. Inventory #2 may contain at least one of the following: task ID #2, device ID length #2 and / or length range #2, and mask #2.

[0310] Task identifier #2 can be an identifier assigned by the A-IoTMF network element for batch inventory checks. For example, if the second round of inventory checks is considered as a task, such as task #2, then task #2 is assigned a task identifier #2 to indicate task #2. Alternatively, task identifier #2 can be an identifier assigned by the NEF based on the service request #2 sent by the AF. Task identifier #2 can also be called a transaction identifier or other names; this invention does not limit the name of the task identifier. Information that can be used to identify the service operation or process performed in response to service request #2 can be used as a task identifier. Device identifier length #2 can also be one of L types of identifier lengths and can be different from identifier length #1. Length range #2 can also be one of S types of length ranges and can also be different from length range #1. Identifier length #1 and / or length range #1 can be understood as the second information mentioned above, and the specific principle is similar to the first information mentioned above, which can be understood by reference and will not be repeated here. The device identifier length #2 can be carried in the mask #2, or it can be used as an independent information cell other than the mask #2. The implementation principle of the mask #2 is similar to that of the mask #1. You can also refer to the relevant introduction of the mask above, which will not be repeated here.

[0311] Optionally, if the A-IoTMF network element obtains the reporting length in S703, then inventory #2 may also include the reporting length.

[0312] S711, the reader sends selection message #2 or paging message #2.

[0313] Select message #2 or paging message #2 can carry identifier length #2 and / or length range #2, as well as mask #1, and optionally also include the reporting length.

[0314] S712, A-IoT device #2 determines that the device identifier length matches.

[0315] Optionally, if the reader sends the identifier length #2 and / or length range #2 in S711 (e.g., as an independent cell or carried in a mask #2), then the A-IoT device #2 can determine whether the device identifier length of the A-IoT device #2 is the same as the device identifier length #2, and / or whether the device identifier length of the A-IoT device #2 is within the length range #2. If yes, the A-IoT device #2 determines that the device identifier lengths match; otherwise, the A-IoT device #2 determines that the device identifier lengths do not match, or determines not to continue with the subsequent steps.

[0316] Optionally, if message #2 or paging message #2 also includes a reporting length, then A-IoT device #2, after determining that the device identifier length matches, can also determine the relationship between the device identifier length and the reporting length. If A-IoT device #2 determines that the device identifier length is greater than the reporting length, then A-IoT device #2 can truncate device identifier #A to the reporting length to obtain device identifier #B. If A-IoT device #2 determines that the device identifier length is less than the reporting length, then A-IoT device #2 can fill device identifier #A into the reporting length to obtain device identifier #B. If A-IoT device #2 determines that the device identifier length is equal to the reporting length, then A-IoT device #2 can do nothing, and device identifier #A is device identifier #B.

[0317] It is understandable that the description of the second identifier mentioned above can be used as a reference for the device identifier #A, and the description of the first identifier mentioned above can also be used as a reference for the device identifier #B. Therefore, it will not be repeated here.

[0318] If the device identifier length matches, A-IoT device #2 performs random access, such as S713.

[0319] Optionally, if the reader sends mask #2 in step S711, then if the device identifier #2 matches the mask #2, the A-IoT device #2 performs random access, as in step S713.

[0320] Optionally, if the reader sends the identifier length #2 and / or length range #2, and the mask #2 in step S711, then AIoT device #2 performs random access if the device identifier length matches and the device identifier #2 matches the mask #2, as in step S713.

[0321] S713, A-IoT device #2 sends device identifier #B.

[0322] In one possible implementation, A-IoT device #2 sends device identifier #B to the reader, and the reader sends device identifier #B to the A-IoTMF network element.

[0323] In another possible implementation, A-IoT device #2 (via a reader) sends a UL NAS message #B to the A-IoTMF network element. The UL NAS message #2 may carry the device identifier #B.

[0324] S714, A-IoTMF network element performs verification on device identifier #B.

[0325] The A-IoTMF network element's verification of device identifier #B can include checking if its length matches, if the content is complete, and if device identifier #2 is a valid device identifier. Furthermore, step S714 is optional; the A-IoTMF network element may choose not to perform this verification or to perform other operations, without specific restrictions.

[0326] It is understood that there may be one or more A-IoT devices #2, that is, the above S710-S714 process can be applied to A-IoT devices whose device identifier length is the same as the device identifier length #2, and / or whose device identifier length is within the length range #2.

[0327] It can also be understood that S710-S714 are optional. If there is no A-IoT device #2, then S710-S714 will not be executed.

[0328] In addition, the above Figure 7 The process shown uses A-IoT devices #1 and #2 as examples, but it is not limited to them. There can be other devices with different identifier lengths, such as A-IoT device #3, etc. The specific principle is similar and will not be described in detail here.

[0329] Figure 8 Flowchart of the communication method provided in the embodiments of this application Figure 3 .like Figure 8As shown, the process involves AF (such as the second network entity), NEF network element, UDM / UDR network element (such as the third network entity), A-IoTMF network element (such as the first network entity), reader, A-IoT device #1 (such as the first terminal), and A-IoT device #2 (such as the second terminal).

[0330] Specifically, such as Figure 8 As shown, the flow of this communication method is as follows:

[0331] S800a, UDM / UDR network element pre-configured identifier length and / or length range.

[0332] S800b, A-IoT device #1 pre-configures the device identifier length of A-IoT device #1.

[0333] S800c, A-IoT device #2 pre-configured device identifier length for A-IoT device #2.

[0334] S801, AF sends service request #1 to NEF network element.

[0335] S802, the NEF network element sends service request #2 to the A-IoTMF network element.

[0336] S803, the A-IoTMF network element obtains L types of identifier lengths and / or S types of length ranges from the UDM / UDR network element.

[0337] S803 is optional. If the service request #2 carries L types of identifier length and / or S types of length range, the A-IoTMF network element can also obtain L types of identifier length and / or S types of length range from the service request #2. S803 can also refer to the relevant introduction in S601 above, and will not be repeated here.

[0338] Optionally, the A-IoTMF network element can also obtain the reporting length from the UDM / UDR network element or service request #2.

[0339] For S800a-S803, please refer to the above-mentioned introductions of S700a-S702 and S704, which will not be repeated here.

[0340] S804, the A-IoTMF network element sends inventory data to the reader.

[0341] Inventory can also be called inventory message, inventory instruction, or any other possible name, without any restrictions.

[0342] The inventory can include at least one of the following: task ID, K types of ID lengths and / or S types of length ranges, and multiple masks, etc. That is, the difference from S705 and S710 mentioned above is that the A-IoTMF network element can send all received information to the reader, which then splits and allocates the information for inventory. Furthermore, the information elements can be referenced in the descriptions of S705 and S710 above, and will not be repeated here.

[0343] Optionally, if the A-IoTMF network element obtains the reported length in the service request #2 of S802, the inventory may also include the reported length.

[0344] S805, the reader sends selection message #1 or paging message #1.

[0345] The selection message #1 or paging message #1 can carry an identifier length #1 and / or a length range #1, as well as a mask #1, and optionally, a reporting length. That is, the reader can select identifier length #1 from L stored identifier lengths, and / or select length range #1 from S stored length ranges, and can also select mask #1 from multiple stored masks, and then carry it into the selection message #1 or paging message #1.

[0346] S806, A-IoT device #1 determines that the device identifier length matches.

[0347] S807, A-IoT device #1 sends device identifier #2.

[0348] S808, the A-IoTMF network element performs verification on device identifier #2.

[0349] For S806-S808, please refer to the relevant introductions of S707-S709 above, and they will not be repeated here.

[0350] S809, the reader sends selection message #2 or paging message #2.

[0351] Select message #2 or paging message #2 can carry identifier length #2 and / or length range #2, as well as mask #2, and optionally also include the reporting length. That is, the reader can select identifier length #2 from L stored identifier lengths, and / or select length range #2 from S stored length ranges, and can also select mask 2 from multiple stored masks, and then carry it into select message #2 or paging message #2.

[0352] S810, A-IoT device #2 determines that the device identifier length matches.

[0353] S811, A-IoT device #2 sends device identifier #B.

[0354] S812, A-IoTMF network element performs verification on device identifier #B.

[0355] For S810-S812, please refer to the relevant introduction of S712-S714 above, and we will not repeat it here.

[0356] In addition, the above Figure 8 The process shown uses A-IoT devices #1 and #2 as examples, but it is not limited to them. There can be other devices with different identifier lengths, such as A-IoT device #3, etc. The specific principle is similar and will not be described in detail here.

[0357] Figure 9 This is a flowchart illustrating the communication method. Figure 4 This communication method is applicable to the interaction between the first terminal and the reader, such as... Figure 9 As shown, the flow of this communication method is as follows:

[0358] S901, the reader obtains the length of the device identifier.

[0359] The reader can be one of the access network devices mentioned above, such as an access network device that supports reader functionality, or it can be one of the terminal devices mentioned above, such as a terminal device that supports reader functionality.

[0360] The length of the device identifier can also be called the identifier length or device identifier length; there are no restrictions on the specific name. The length of the device identifier can be specified by the number of length units, which can be bits, words, bytes, etc. Please refer to the above for details. Figure 6 The relevant information will not be repeated here.

[0361] The reader can receive the length of the device identifier from a core network element (such as the first network entity mentioned above) used for managing terminals (e.g., A-IoT devices). For example, if M identifier lengths are received, the length of the device identifier is the first identifier length among them. See the following for details. Figure 6 The relevant details will not be repeated here. Alternatively, the reader can receive the length of the device identifier from the first terminal (such as the A-IoT terminal mentioned above), that is, the length of the first terminal's own device identifier (such as the second identifier mentioned above). The length of this device identifier can be transmitted together with the first terminal's RN16 (i.e., 16-bit random number), or separately, without any specific restrictions.

[0362] As can be seen, the length of the device identifier can be reported by the terminal or provided by the network side, with no specific restrictions, and can be flexibly selected according to the actual situation.

[0363] S902, the reader determines the transmission resources based on the length of the device identifier.

[0364] Transmission resources (or wireless resources / wireless transmission resources / air interface resources) can be at least one of the following: time-domain resources, frequency-domain resources, spatial resources, etc. Time-domain resources can be one or more continuous or discontinuous elements, including at least one of the following: symbols, slots, mini-slots, subframes, radioframes, etc. Frequency-domain resources can be one or more continuous or discontinuous elements, including at least one of the following: sub-channels, resource pools, carriers, subcarriers, bandwidth parts (BWP), etc. Spatial resources can be one or more continuous or discontinuous elements, including at least one of the following: spatial vectors, ports, antenna ports, reference signal ports, etc. Time-domain and frequency-domain resources can form resource blocks (RBs) or resource elements (REs), and can be layered in the spatial domain through spatial resources. That is, multiple RBs or REs can be reused at the same time-frequency location to further improve resource utilization.

[0365] Transmission resources are used to carry device identifiers. The size of the transmission resources matches the length of the device identifier. For example, the length of the device identifier is the number of bits, such as X length units, where X is an integer greater than 1. The size of the transmission resources can be the number of RBs or REs, such as Y RBs or REs, where Y is an integer greater than or equal to 1. Y RBs or REs can carry X length units, or slightly more than X, such as 110%, 105%, etc., of X; the specific ratio is not limited. In other words, the transmission resources can exactly carry the length of the device identifier to avoid resource waste.

[0366] If the reader is an access network device, it can allocate the transmission resource itself. Alternatively, if the reader is a terminal device, it can report the length of its device identifier to the access network device to request the access network device to allocate the transmission resource.

[0367] Optionally, in conjunction with S901-S902, the method may further include: the reader transmitting the device identifier of the first terminal on the transmission resource, such as sending the device identifier of the first terminal or receiving the device identifier of the first terminal from the first terminal. For example, the reader can configure the transmission resource to the first terminal, such as sending configuration information indicating the transmission resource to the first terminal. The configuration information may include the resource location index of the transmission resource, such as the index of time-domain resources, such as the sequence number of time slots or symbols; the index of frequency-domain resources, such as the sequence number of carriers or subcarriers; the index of spatial-domain resources, such as the antenna port number, etc. In this way, the reader can transmit the device identifier of the first terminal on the transmission resource. In addition, the device identifier of the first terminal may be an existing identifier, or it may be the first identifier or the second identifier mentioned above, as detailed above. Figure 6 The relevant information will not be repeated here.

[0368] In summary, for device identifiers of different lengths, the reader can allocate transmission resources, or wireless resources, that match the length. For example, a longer device identifier will be allocated more transmission resources, while a shorter device identifier will be allocated less transmission resources, in order to avoid wasting transmission resources and improve communication efficiency.

[0369] Figure 10 Flowchart of the communication method provided in the embodiments of this application Figure 5 .like Figure 10 As shown, this process involves the interaction between A-IoT devices (such as the first terminal) and the reader.

[0370] Specifically, such as Figure 10 As shown, the flow of this communication method is as follows:

[0371] S1000, the length of the device identifier of the A-IoT device is pre-configured.

[0372] S1001, the reader sends a selection message or a paging message.

[0373] S1002, the reader sends a query message or queries for duplicate messages.

[0374] For S1001-S1002, please refer to the relevant introduction of S201-S202 above, and it will not be repeated here.

[0375] S1003, the A-IoT device sends RN16 and the length of the A-IoT device identifier.

[0376] In other words, when an A-IoT device decides to access the network randomly, it can pass the length of the RN16 and the device identifier of the A-IoT device to the reader.

[0377] S1004, the reader determines the transmission resources.

[0378] The size of the transmission resource matches the length of the device identifier. For details, please refer to the relevant introduction of S902 above, which will not be repeated here.

[0379] S1005, the reader returns a confirmation message.

[0380] Optionally, the confirmation message may include configuration information indicating the output resource.

[0381] S1006, the A-IoT device sends its device identifier on the transmission resources.

[0382] S1007, the reader returns a query for duplicate messages.

[0383] For S1005-S1007, please refer to the relevant introductions of S204-S206 above, and they will not be repeated here.

[0384] Figure 11 This is a schematic diagram of the structure of the communication device provided in the embodiments of this application. Figure 1 For example, such as Figure 11 As shown, the communication device 1100 includes a transceiver module 1102 and a processing module 1101. For ease of explanation, Figure 11 Only the main components of the communication device are shown.

[0385] The communication device 1100 can be applied to the above. Figures 6-10 The communication method is used to implement the corresponding functions. For example, the transceiver module 1102 can be used to implement the above. Figures 6-10 The sending and receiving functions in the communication method can be implemented by the processing module 1101. Figures 6-10 The communication methods include functions other than sending and receiving.

[0386] Optionally, the transceiver module 1102 may include a transmitting module ( Figure 11 (not shown in the image) and receiving module ( Figure 11 (Not shown in the diagram). The transmitting module is used to implement the transmitting function of the communication device 1100, and the receiving module is used to implement the receiving function of the communication device 1100.

[0387] Optionally, the communication device 1100 may also include a storage module. Figure 11 (Not shown in the image), the storage module stores programs or instructions. When the processing module 1101 executes the program or instructions, the communication device 1100 can perform the aforementioned... Figures 5-8 The functions in the method shown.

[0388] It is understood that the communication device 1100 may be a network device, or a chip (system) or other component or assembly that can be set in the network device, or a device that includes the network device. This application does not limit this.

[0389] Furthermore, the technical effects of the communication device 1100 can be referenced from the technical effects of the communication method described above, and will not be repeated here.

[0390] Figure 12 Schematic diagram of the communication device provided in the embodiments of this application Figure 2 For example, the communication device can be a terminal, or a chip (system) or other component or assembly that can be set in the terminal. Figure 12 As shown, the communication device 1200 may include a processor 1201. Optionally, the communication device 1200 may also include a memory 1202 and / or a transceiver 1203. The processor 1201 is coupled to the memory 1202 and the transceiver 1203, for example, they may be connected via a communication bus.

[0391] The following is combined with Figure 12 A detailed description of each component of the communication device 1200 is provided below:

[0392] The processor 1201 is the control center of the communication device 1200. It can be a single processor or a collective term for multiple processing elements. For example, the processor 1201 can be one or more central processing units (CPUs), application-specific integrated circuits (ASICs), or one or more integrated circuits configured to implement the embodiments of this application, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0393] Optionally, the processor 1201 can perform various functions of the communication device 1200, such as the functions described above, by running or executing software programs stored in the memory 1202 and calling data stored in the memory 1202. Figures 6-10 The communication method shown.

[0394] In a specific implementation, as one example, the processor 1201 may include one or more CPUs, for example... Figure 12 CPU0 and CPU1 are shown in the diagram.

[0395] In a specific implementation, as one example, the communication device 1200 may also include multiple processors, for example... Figure 12 The processors 1201 and 1204 are shown. Each of these processors can be a single-core processor (CPU) or a multi-core processor (CPU). Here, "processor" can refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0396] The memory 1202 is used to store the software program that executes the solution of this application, and is controlled by the processor 1201 to execute it. The specific implementation method can be referred to the above method embodiment, and will not be repeated here.

[0397] Optionally, the memory 1202 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory 1202 may be integrated with the processor 1201 or exist independently, and may be connected via the interface circuit of the communication device 1200. Figure 12 (Not shown in the image) is coupled to the processor 1201, and this embodiment does not specifically limit this.

[0398] Transceiver 1203 is used for communication with other communication devices. For example, if communication device 1200 is a terminal, transceiver 1203 can be used to communicate with a network device or with another terminal device. As another example, if communication device 1200 is a network device, transceiver 1203 can be used to communicate with a terminal or with another network device.

[0399] Optionally, transceiver 1203 may include a receiver and a transmitter. Figure 12 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the sending function.

[0400] Optionally, the transceiver 1203 can be integrated with the processor 1201, or it can exist independently and be connected via the interface circuit of the communication device 1200. Figure 12 (Not shown in the image) is coupled to the processor 1201, and this embodiment does not specifically limit this.

[0401] Understandable Figure 12 The structure of the communication device 1200 shown does not constitute a limitation on the communication device. Actual communication devices may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0402] Furthermore, the technical effects of the communication device 1200 can be referred to the technical effects of the method described in the above method embodiments, and will not be repeated here.

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

[0404] It should also be understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0405] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, in the form of a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0406] This application also provides a computer-readable storage medium storing a computer program that, when executed by a computer, enables the computer to perform the aforementioned communication method. Alternatively, the computer program includes instructions for implementing the aforementioned communication.

[0407] This application also provides a computer program product, including: computer program code, which, when run on a computer, enables the computer to execute the communication method provided above.

[0408] This application also provides a communication system, which includes a first device and a second device for performing the communication method described above.

[0409] This application also provides a chip, which may include a processor that executes the communication method described above. Optionally, the chip may also include a memory coupled to the processor, the memory storing a program for executing the communication method described above.

[0410] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0411] In this application, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or multiple items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0412] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0413] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0414] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0415] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0416] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0417] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0418] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0419] 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 the claims.

Claims

1. A communication method, characterized in that, Applied to a first network entity, the method includes: Send a first message, which includes at least one of M identifier lengths or N length intervals, where M and N are positive integers; The first identifier of the first terminal is received, and the length of the first identifier satisfies a preset rule with the length of the first identifier among the M identifier lengths, and / or the length of the first identifier is located within the first length interval among the N length intervals.

2. The method according to claim 1, characterized in that, The length of the first identifier satisfies the preset rule, including: The length of the first identifier is the same as the length of the first identifier; or, The first identifier is determined based on the second identifier of the first terminal, and the length of the second identifier is the same as the length of the first identifier.

3. The method according to claim 2, characterized in that, The first information also includes a reporting length, wherein, when the first identifier is determined based on the second identifier, the length of the first identifier is the same as the reporting length.

4. The method according to any one of claims 1-3, characterized in that, The M identifier lengths include K identifier lengths, and the K identifier lengths belong to L identifier lengths, where K is a positive integer and L is an integer greater than or equal to K.

5. The method according to claim 4, characterized in that, The method further includes: Receive a service request from a second network entity, the second network entity being the requester of the first service, the service request indicating that the first service be executed for a terminal that meets preset conditions, the first terminal being a terminal that meets the preset conditions; Based on the business request, determine the length of the L types of identifiers.

6. The method according to claim 5, characterized in that, Determining the length of the L types of identifiers based on the service request includes: Based on the service request, obtain the L types of identifier lengths from the third network entity; or... The service request includes the L types of identifier lengths.

7. The method according to claim 5, characterized in that, Determining the length of the L types of identifiers based on the service request includes: Obtain the L types of identifier lengths from the business request.

8. The method according to claim 5 or 6, characterized in that, Terminals that meet the preset conditions include at least one of the following: terminals located within the indicated area, or terminals identified as an identification type.

9. The method according to claim 5 or 6, characterized in that, The first business is the Environmental Internet of Things (A-IoT) business.

10. The method according to claim 4, characterized in that, The L-type identifier length is the default identifier length of the first network entity.

11. The method according to any one of claims 1-10, characterized in that, The first information is carried in the mask.

12. The method according to claim 11, characterized in that, The mask includes an identifier type, and the type of the first identifier matches the identifier type included in the mask.

13. The method according to claim 12, characterized in that, The identifier type is any of the following: an identifier assigned by an operator network, an identifier assigned by a non-operator network, a product electronic identifier, or a non-product electronic identifier.

14. The method according to any one of claims 1-13, characterized in that, The method further includes: Send a second message, which includes P identifier lengths and / or Q length intervals, where P and Q are positive integers. The P identifier lengths are different from the M identifier lengths, and the Q length intervals are different from the N length intervals.

15. The method according to claim 14, characterized in that, The first information and the second information are carried in the same message, or the first information and the second information are carried in different messages.

16. The method according to any one of claims 1-15, characterized in that, The first network entity supports reader functionality, and the first terminal is an environmental IoT (A-IoT) terminal.

17. A communication method, characterized in that, The method includes: Receive first information, which includes at least one of M identifier lengths or N length intervals, where M and N are positive integers; Based on the first information, a first identifier of the first terminal is sent, wherein the length of the first identifier satisfies a preset rule with the length of the first identifier among the M identifier lengths, and / or the length of the first identifier is located within the first length interval among the N length intervals.

18. The method according to claim 17, characterized in that, The length of the first identifier satisfies the preset rule as follows: The length of the first identifier is the same as the length of the first identifier; or, The first identifier is determined based on the second identifier of the first terminal, and the length of the second identifier is the same as the length of the first identifier.

19. The method according to claim 18, characterized in that, The first information also includes a reporting length, wherein, when the first identifier is determined based on the second identifier, the length of the first identifier is the same as the reporting length.

20. The method according to claim 18 or 19, characterized in that, The method further includes: If the length of the second identifier is greater than the reporting length, then the second identifier is truncated to the reporting length to obtain the first identifier; If the length of the second identifier is less than the reporting length, then the second identifier is padded to the reporting length to obtain the first identifier; Wherein, if the length of the second identifier is equal to the reporting length, then the second identifier and the first identifier are the same identifier.

21. The method according to any one of claims 17-20, characterized in that, The receipt of the first information includes: Receive a mask, in which the first information is carried.

22. A communication method, characterized in that, Applied to a reader, the method includes: Get the length of the device identifier; Based on the length of the device identifier, a transmission resource is determined, the size of which matches the length of the device identifier, and the transmission resource is used to carry the device identifier.

23. The method according to claim 22, characterized in that, The length of the obtained device identifier includes: Receive the length of the device identifier from the first terminal; or; Receive the length of the device identifier from the core network element used for management terminal.

24. The method according to claim 22 or 23, characterized in that, The method further includes: The device identifier of the first terminal is transmitted on the transmission resource.

25. The method according to any one of claims 22-24, characterized in that: The first terminal is an environmental Internet of Things (A-IoT) terminal.

26. A communication device, wherein the communication device is a first network entity, characterized in that, The communication device is used to perform the method as described in any one of claims 1-16.

27. A communication device, characterized in that, The communication device is used to perform the method as described in any one of claims 17-21.

28. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a computer program or instructions that, when executed, cause the method of any one of claims 1-16 to be implemented, or the method of any one of claims 17-21 to be implemented, or the method of any one of claims 22-25 to be implemented.

29. A computer program product, characterized in that, The computer program product includes: a computer program or instructions that, when executed, cause the method as described in any one of claims 1-16 to be implemented, or the method as described in any one of claims 17-21 to be implemented, or the method as described in any one of claims 22-25 to be implemented.

Images