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: determining a first length, wherein the first length is the length of first data; determining to transmit the first data through a first mode or a second mode according to the first length; when it is determined that the first data is transmitted in the first mode, transmitting the first data through a first message; or, under the condition that the first data is determined to be transmitted in the second mode, transmitting the first data through the second message and the third message.

Description

TECHNICAL FIELD

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

[0002] With the development of communication technology, the 3rd generation partnership project (3GPP) defines ambient IoT (A-IoT). A-IoT terminals communicate with the network by harvesting energy from the environment to achieve passive IoT communication. However, more scenarios will be introduced in 3GPP, such as warehouse / transportation / stocktaking, fixed asset management, etc. In these business processes, A-IoT terminals need to transmit data with the network, and the amount of data transmitted may differ due to different business processes.

[0003] Therefore, in the case of different amounts of data transmission, how to ensure the efficiency and reliability of data transmission is currently being studied. SUMMARY

[0004] To solve the above technical problems, the embodiments of the present application provide a communication method and device to ensure the efficiency and reliability of data transmission in the case of different amounts of data interaction.

[0005] To achieve the above purpose, the present application adopts the following technical solutions:

[0006] In a first aspect, a communication method is provided. The method is applied to a first device. The method comprises: determining a first length, the first length being a length of first data; determining, according to the first length, whether to transmit the first data by a first mode or a second mode; in a case where it is determined to transmit the first data by the first mode, transmitting the first data by a first message; or in a case where it is determined to transmit the first data by the second mode, transmitting the first data by a second message and a third message.

[0007] Thus, in the case of different first lengths of the first data, or different amounts of data of the first data, the first data can be transmitted by different modes. For example, if the first length is small, the first device can transmit the first data by the first mode, such as by the first message, to ensure the efficiency of data transmission. If the first length is large, the first device can transmit the first data by the second mode, such as by the second message and the third message, to avoid transmission failure due to the first message being unable to transmit the first data, thus ensuring the reliability of data transmission.

[0008] In the first possible design, determining the first length includes: receiving the first data, and determining the first length according to the first data. That is, in the case that the first device sends the first data, the first service request can receive the first data first, to directly determine the first length, which can avoid the overhead caused by interaction with other devices compared with the way of obtaining the first length from other devices.

[0009] It should be understood that, in the first possible design, the first device can be a core network element, such as an A-IoT MF, or other network elements with A-IoT function, and the specific name is not limited. Alternatively, the first device can also be an access network device, such as an access network device supporting reader function, or a terminal device, such as a terminal device supporting reader function, and thus the first device can also be regarded as a reader. Correspondingly, the second device can be a terminal device, such as an A-IoT terminal.

[0010] Optionally, receiving the first data includes: receiving the first service request. The first service request includes the first data, and the first service request is used to request writing the first data to the second device, that is, applicable to a writing scenario, to efficiently and reliably write the first data to the second device.

[0011] Optionally, in the case that it is determined to transmit the first data through the first mode, transmitting the first data through the first message includes: in the case that it is determined to send the first data through the first mode, sending the first message to the second device, the first message including the first data. Alternatively, in the case that it is determined to transmit the first data through the second mode, transmitting the first data through the second message and the third message includes: in the case that it is determined to send the first data through the second mode, sending the second message and the third message to the second device, the second message including the second data, the third message including the third data, and the first data including the second data and the third data.

[0012] It can be seen that the first data can be directly carried in the first message, or can be segmented, such as obtaining the second data and the third data, and carried in the second message and the third message respectively. The specific selection can be made according to the data amount of the first data, that is, the first length, to ensure the efficiency and reliability of data transmission.

[0013] Optionally, the method of the first aspect can further include: determining the second data and the third data according to the first data, that is, the first data can be segmented to be carried in the corresponding message respectively.

[0014] Optionally, the method in the first aspect may further include: sending a first address to the second device, the first address indicating a storage area for storing first data, so that the second device can write the first data into the specified storage area according to the first address. Alternatively, sending a second address and a third address to the second device, the second address indicating a storage area for storing second data and the third address indicating a storage area for storing third data. The second address and the third address can be obtained by segmenting the first address; specifically, they can be consecutive addresses or non-consecutive addresses, without limitation, to enable flexible writing of the second and third data.

[0015] The second possible design involves determining the first length by: obtaining the first length from a third device; or receiving a first address and determining the first length based on the first address. The first address indicates the area where the first data is stored. In other words, the first device can determine the length of the first data in advance based on the obtained address or directly from another device, to determine the mode for subsequently receiving the first data, such as whether to receive the first data via a first mode or a second mode.

[0016] It should be understood that in the second possible design scheme, the equipment types of the first and second devices are similar to those in the first possible design scheme described above, and can be understood by reference, and will not be repeated here.

[0017] Optionally, obtaining the first length from the third device includes: receiving a second service request and obtaining the first length from the third device according to the second service request. The second service request is used to request reading first data from the second device. Optionally, receiving the first address includes: receiving a second service request, the second service request including the first address, the second service request being used to request reading first data from the second device. That is, regardless of whether the second service request carries the first device, the first device can obtain the first address. In addition, the above method can be applied to reading scenarios to achieve efficient and reliable reading of the first data from the second device.

[0018] Optionally, if it is determined that the first data is transmitted via the first mode, transmitting the first data via a first message includes: if it is determined that the first data is received via the first mode, receiving a first message from the second device, wherein the first message includes the first data. Alternatively, if it is determined that the first data is transmitted via the second mode, transmitting the first data via a second message and a third message includes: if it is determined that the first data is received via the second mode, receiving a second message and a third message from the second device, wherein the second message includes the second data, the third message includes the third data, and the first data includes both the second and third data.

[0019] Optionally, after receiving the first message of the second and third messages, the method described in the first aspect may further include: sending a first indication message to the second device, the first indication message instructing the second device to continue sending data, that is, whether the second device should continue sending data can be indicated by the first device, so as to avoid data transmission errors and ensure the reliability and stability of data transmission.

[0020] Optionally, the method described in the first aspect may further include: determining the first data based on the second data and the third data, i.e., realizing data aggregation, so that after receiving the segmented data, the first device can provide the complete data, i.e. the first data, to other entities / network elements on the network side through data aggregation.

[0021] Optionally, the method described in the first aspect may further include: sending a first address to the second device so that the second device can correctly read and send the first data based on the first address, thereby avoiding data reading errors.

[0022] In some possible solutions, the first device is a core network element, and the second device is a terminal device. When it is determined that the first data will be transmitted via the first mode, the access network device is used to forward the first message. The method described in the first aspect further includes: sending a second indication message to the access network device, the second indication message instructing the access network device to continue performing operations for other terminals after forwarding the first message. Alternatively, the first device is an access network device, and the second device is a terminal device. The method described in the first aspect further includes: continuing to perform operations for other terminals after sending the first message. That is, when only the first data is transmitted via the first message, the access network device does not need to wait for subsequent instructions from the network side and can continue to perform operations for other terminals, such as random access by other terminals, to improve operational efficiency.

[0023] In some possible solutions, the first device is a core network element, and the second device is a terminal device. When it is determined that the first data will be transmitted via the second mode, the access network device is used to forward the second and third messages. The method described in the first aspect may further include: sending a third indication message to the access network device, the third indication message instructing the access network device to perform operations on other terminals according to the instructions of the core network element after forwarding the first message in the second and third messages; or, the first device is an access network device, and the second device is a terminal device, and the method described in the first aspect may further include: performing operations on other terminals according to the instructions of the core network after sending the first message in the second and third messages. This avoids the access network device performing operations on other terminals before transmitting the first data, thus preventing the first data transmission from failing and ensuring the reliability of data transmission.

[0024] A third possible design involves determining the first length, including receiving a first address and determining the first length based on the first address. The first address indicates the area where the first data is stored.

[0025] It should be understood that in the third possible design, the first device can be a terminal device, such as an A-IoT terminal. The second device can be an access network device, such as an access network device supporting reader functionality, or it can also be a terminal device, such as a terminal device supporting reader functionality, or it can be considered a reader.

[0026] Optionally, receiving the first address includes: receiving a command, the command including the first address, the command instructing to read first data from the first device, i.e., applicable to a reading scenario, to achieve efficient and reliable reading of the first data from the first device.

[0027] Optionally, if it is determined that the first data will be transmitted via the first mode, transmitting the first data via a first message includes: sending a first message to the second device, wherein the first message includes the first data; or, if it is determined that the first data will be transmitted via the second mode, transmitting the first data via a second message and a third message includes: sending a second message and a third message to the second device, wherein the second message includes the second data, the third message includes the third data, and the first data includes both the second and third data.

[0028] Optionally, after sending the first message of the second message and the third message to the second device, the method of the first aspect further includes: sending a fourth indication message to the second device, the fourth indication message instructing the first device to continue sending data, that is, whether the second device should continue to wait for receiving data can be indicated by the first device, so as to ensure the stability and reliability of data transmission.

[0029] Optionally, the method in the first aspect further includes: determining second data and third data based on the first data, that is, segmenting the first data so that it can be carried separately by different messages.

[0030] Optionally, the method in the first aspect further includes: obtaining first data from a first region based on a first address.

[0031] Optionally, the method in the first aspect further includes: sending a first length to the second device so that the second device can determine whether the first data has been completely received based on the determined first length, so as to avoid the second device performing other operations before receiving the first data, resulting in the failure of the first data transmission, or the second device waiting to receive the first data after receiving the first data, resulting in increased latency.

[0032] In some possible design schemes, when it is determined that the first data is transmitted through the first mode, the first message is the first message used to transmit business data; or, when it is determined that the first data is transmitted through the second mode, the first message in the second or third message is the first message used to transmit business data, so as to further improve transmission efficiency and reduce transmission latency.

[0033] In some possible design schemes, determining whether to transmit the first data via a first mode or a second mode based on the first length includes: if the first length is less than or equal to a length threshold, determining to transmit the first data via the first mode; or, if the first length is greater than the length threshold, determining to transmit the first data via the second mode.

[0034] Optionally, the method described in the first aspect may further include: obtaining a length threshold from a third device, i.e., obtaining a pre-configured length threshold without dynamic determination, to reduce computing power overhead; or, determining the length threshold based on the quality of the link, where the link is used to carry the first data, so that the amount of data transmitted can match the quality of the link. For example, if the link quality is relatively poor, the length threshold is also relatively small to reduce the amount of data transmitted in a single transmission, ensuring the reliability of data transmission in the case of poor link quality; conversely, if the link quality is relatively good, the length threshold is also relatively large to increase the amount of data transmitted in a single transmission, ensuring data transmission efficiency.

[0035] In a second aspect, a communication device is provided. This communication device is used to execute the communication method described in any implementation of the first aspect.

[0036] In this application, the communication device described in the second aspect can 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 can all be disposed within the terminal device or network device.

[0037] It should be understood that the communication apparatus described in the second aspect includes modules, units, or means that implement the communication method described in any of the first aspects 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.

[0038] Thirdly, 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 aspect.

[0039] In one possible design, the communication device described in the third aspect 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 third aspect and other communication devices.

[0040] In one possible design, the communication device described in the third aspect 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 involved in the communication method described in any of the first aspects.

[0041] In this application, the communication device described in the third aspect can 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 can all be disposed within the terminal device or network device.

[0042] Fourthly, a communication device is provided. 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 aspect.

[0043] In one possible design, the communication device described in the fourth aspect 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 fourth aspect and other communication devices.

[0044] In this application, the communication device described in the fourth aspect can 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 can all be disposed within the terminal device or network device.

[0045] Fifthly, a communication device is provided. The communication device includes a processor and a memory; the memory stores a computer program, which, when executed by the processor, causes the communication device to perform the communication method described in any implementation of the first aspect.

[0046] In one possible design, the communication device described in the fifth aspect 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.

[0047] In this application, the communication device described in the fifth aspect can 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 can all be disposed within the terminal device or network device.

[0048] A sixth aspect provides a communication device. The communication device includes a processor; the processor is configured to be coupled to a memory, and after reading a computer program from the memory, to execute a communication method as described in any implementation of the first aspect according to the computer program.

[0049] In one possible design, the communication device described in the sixth aspect 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 sixth aspect and other communication devices.

[0050] In this application, the communication device described in the sixth aspect can 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 can all be disposed within the terminal device or network device.

[0051] In a seventh aspect, a processor is provided. The processor is configured to execute the communication method described in any possible implementation of the first aspect.

[0052] Eighthly, a communication system is provided. The communication system includes a first means and a second means for performing the method described in the first aspect.

[0053] A ninth aspect provides a computer-readable storage medium comprising: a computer program or instructions; wherein, when the computer program or instructions are executed, the communication method described in any possible implementation of the first aspect is implemented.

[0054] In a tenth aspect, a computer program product is provided, comprising a computer program or instructions that, when executed, cause the communication method described in any possible implementation of the first aspect to be implemented.

[0055] Furthermore, the technical effects of the second to eighth aspects mentioned above can be referred to the technical effects of the communication method described in the first aspect, and will not be repeated here. Attached Figure Description

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

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

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

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

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

[0061] Figure 1 Flowchart of the communication method provided in the embodiments of this application Figure 7 ;

[0062] Figure 2 Flowchart of the communication method provided in the embodiments of this application Figure 8 ;

[0063] Figure 3 Flowchart of the communication method provided in the embodiments of this application Figure 9 ;

[0064] Figure 4 Flowchart of the communication method provided in the embodiments of this application Figure 10 ;

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

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

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

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

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

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

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

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

[0073] Figure 1 This is a schematic diagram of the A-IoT architecture, such as... Figure 2 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.

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

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

[0076] 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" can be used interchangeably. Alternatively, an A-IoT terminal can also be considered an A-IoT device.

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

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

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

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

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

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

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

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

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

[0086] 2. A-IoT Operation Process:

[0087] like Figure 3 As shown, one of its processes is as follows.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0102] S203, tag sent RN16.

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

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

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

[0106] S205, Tag Transmitting Device ID.

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

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

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

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

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

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

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

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

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

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

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

[0118] S303, tag sent RN16.

[0119] S304, the reader returns ACK.

[0120] S305, Identifier for tag sending device.

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

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

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

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

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

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

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

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

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

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

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

[0132] This instruction can be a read instruction.

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

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

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

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

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

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

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

[0140] Thus, compared to Figure 4 The process shown is as follows: Figure 4 The difference in the illustrated process lies in the decoupling of device identifiers (such as EPCs) and data transmission; tags report information through multiple messages. For example, after a tag receives an ACK from the reader, it first sends an EPC, which is then forwarded to the core network by the reader. Afterward, the core network determines that the tag is the device requiring a read operation and sends a read command to the tag via the reader. The tag then sends the data to be read to the core network element via the reader. Because this process involves at least two interactions between the tag and the core network, the reader cannot determine whether, after receiving the tag's first uplink message (e.g., a UP NAS message carrying an EPC), it can continue to store other tags, i.e., trigger the random access procedure for other tags. Therefore, in this process, the reader needs to receive an instruction from the core network element to continue the storage process (S312) before triggering the random access procedure for other tags, such as continuing to broadcast query messages or repeating queries.

[0141] As can be seen, in A-IoT scenarios, data transmission between A-IoT terminals and readers / core network elements can be achieved through one or more messages. In this case, how to ensure the efficiency and reliability of data transmission is a current research problem.

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

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

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

[0145] First, in this application, "for indicating" can include both direct and indirect indication. When describing "information" for indicating A, it can include whether the information directly indicates A or indirectly indicates A, but does not necessarily mean that the information carries A.

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

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

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

[0149] Second, in the embodiments shown below, the 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, to distinguish different indication information.

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

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

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

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

[0154] 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 5 This is a schematic diagram of the architecture of a communication system to which the method provided in the embodiments of this application applies.

[0155] Figure 5 This is a schematic diagram of the architecture of a communication system, which mainly includes: a first device and a second device.

[0156] In this configuration, the first device can be a network entity, and the second device can be a terminal device. Alternatively, the first device can be a terminal device, and the second device can be a network entity.

[0157] The terminal device can be a device or module that is connected to the communication system and has corresponding communication functions. The terminal device 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 wearable, smart transportation, smart city, etc., or it can be a mobile phone, tablet computer, computer with wireless transceiver function, wearable device, vehicle, drone, helicopter, airplane, ship, robot, robotic arm, smart home device, transportation vehicle with wireless communication function, communication module, etc.

[0158] Terminal devices 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 an A-IoT terminal. The embodiments of this application do not limit the device form of the terminal. The terminal typically contains a communication module, circuit, or chip that performs the corresponding communication function. The terminal can also be configured with program instructions for performing the corresponding communication function.

[0159] Network entities can be core network elements, such as IoT functions, with no specific name limitation. IoT functions can be ambient IoT function (AIoTF), ambient IoT management function (AIoTMF), IoT device management function (IDMF), IoT management function (IoTMF), tag management function (TMF), or ambient IoT device management function (AIDMF). This application does not limit the naming of network elements performing IoT functions; other names are acceptable. This application uses AIoTMF as an abbreviation for IoT function network elements. AIoTMF can process service requests from service requesters (e.g., AF) and execute corresponding service operations (e.g., instructing readers to perform IoT device inventory procedures) and transmission commands (e.g., read operations, write operations, deactivation operations, etc.). It manages IoT devices, performs security authentication processes, and transmits data.

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

[0161] 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 capable of implementing all or part of the RAN node functions. The equipment form of the RAN node can be a pole station, micro base station, base station, small station, macro station, etc., and there are no specific restrictions.

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

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

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

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

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

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

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

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

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

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

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

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

[0174] like Figure 5As 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.

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

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

[0177] In one possible scenario, the first device could be a core network element, such as A-IoTMF, or other network elements with A-IoT functionality, such as IDMF or AMF; no specific name or restriction is imposed. The second device could be... Figure 5 The A-IoT terminals shown in (a) to (d) are examples. In another possible scenario, the first device can be an access network device, specifically... Figure 5 The first device may be a combination of one or more of the reader, intermediate node, and auxiliary node shown in (a) to (c), such as reader, intermediate node, reader + intermediate node, reader + auxiliary node, etc.; or, the first device may also be a terminal device, such as specifically... Figure 4 The terminal device shown in (d) supports reader functionality. Therefore, the first device can also be understood as a reader. Correspondingly, the second device can still be... Figure 4 The A-IoT terminals shown in (a) to (d) are examples. Alternatively, the device types of the first and second devices can be interchanged, such as the first device being an A-IoT terminal and the second device being a reader.

[0178] In this communication system, the first device and the second device can select the data transmission method, such as direct transmission or segmented transmission, based on different data lengths. Taking the first data as an example, when the length or volume of the first data differs, the first data can be transmitted using different modes. For instance, if the first length is relatively short, the first device can transmit the first data using the first mode, such as transmitting the first data via the first message, to ensure efficient data transmission. If the first length is relatively long, the first device can transmit the first data using the second mode, such as transmitting the first data via the second and third messages, to avoid transmission failure due to the first message not being able to transmit all the first data, thus ensuring the reliability of data transmission.

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

[0180] It should also be understood that Figures 6 to 9 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 6 It was not drawn in the middle.

[0181] The following will combine Figure 1 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.

[0182] Figure 6 This is a flowchart illustrating the communication method. Figures 4-5 This communication method is applicable to the interaction between the first device and the second device, such as... Figures 4-5 As shown, the flow of this communication method is as follows:

[0183] S601, the first device determines the first length.

[0184] S602, the first device determines, based on the first length, whether to transmit the first data via a first mode or a second mode.

[0185] The following is a joint introduction to S601-S602.

[0186] The first length can be the length of the first data.

[0187] The first length can be a quantized length value, such as the number of length units, or the first length can be represented by the number of length units. For example, a length unit can be one bit, that is, how many bits the first length is, such as 16 bits, 24 bits, 36 bits, 96 bits, 128 bits, 192 bits, 256 bits, etc.; or, a length unit can also be multiple bits, such as 16 bits as one word, the first length is how many 16 bits, that is, how many words, or 8 bits as one byte, the first length is how many 8 bits, that is, how many bytes, or a length unit can also be other numbers of bits, such as 3 bits, 4 bits, 5 bits, etc., the specific number is not limited. Additionally, if a length unit contains multiple bits, and the number of bits in a length unit is not divisible by the number of bits in the first data, then the first length can also be represented as the number of length units plus the number of bits. For example, if the first data contains 100 bits and a length unit contains 8 bits, then the first length can be represented as 12 length units plus 4 bits, or rounded up to 13 length units.

[0188] The first data can be data sent by the first device or data received by the first device. The following sections will describe the different scenarios.

[0189] Scenario 1:

[0190] The first data is data sent by the first device, which can be a core network element (such as A-IoTMF) or an access network device (such as a RAN node). The second device can be a terminal device, such as an A-IoT terminal. For details, please refer to [reference needed]. Figures 4-5 The relevant introduction is as follows. Case 1 can be applied to the write scenario, or the write operation / data write operation. In this case, before sending the first data (such as the data to be written), the first device can first receive the first data and determine the first length based on the first data.

[0191] The following section will take the first device as an example, which is either a core network element or an access network device, for further introduction.

[0192] First possible implementation:

[0193] The first device is a core network element (denoted as the first core network element). The first core network element can receive the first service request. For ease of description, the first service request received by the first core network element is denoted as service request #1. In addition, the "#x" mentioned in the embodiments of this application, such as #1, #2, #a, #b, etc., are identifiers used to distinguish different messages / information and should not be understood as part of the message / information. The same applies below, and will not be repeated.

[0194] The first service #1 can be used to request the writing of first data to an A-IoT terminal. For example, the first service #1 can be a service requester, such as an AF, AS, or A-IoT / P-IoT AF sending a request to a first core network element. Service request #1 can include first data, and at least one of the following: the identifier of the service requester, service type, device identifier, data length, or a first address. The identifier of the service requester can identify the service requester, such as an AF ID, AS ID, or A-IoT / P-IoT AF ID, without limitation. The service type can indicate the type of service / operation, such as a write operation. The device identifier can be the identifier or identifier range of the device performing the service / operation, such as the identifier or identifier range / identifier prefix of the A-IoT terminal, where the AIoT device indicated by the identifier range / identifier prefix can include the A-IoT terminal. The first address can indicate the storage area storing the first data, which can be the storage area of ​​the A-IoT terminal, such as an area in the A-IoT terminal's memory / cache / hard disk, specifically an area storing user data. The first address can include at least one of the following: the start address of the storage area, or the end address of the storage area. Data length can indicate the number of bits contained in the first data.

[0195] It should be understood that the first core network element can receive service request #1 through other network functions (such as network exposure function (NEF) elements). The message type of service request #1 received by the first core network element from this other network function can be the same as or different from the message type of the service request received by the other network function from the service requester. That is, the other network function can either transparently transmit service request #1 to the first core network element, or process the received service request (such as changing the message type) to obtain service request #1, and then send it to the first core network element. The specific processing method is not limited.

[0196] The first core network element can obtain the first data from service request #1 and determine the number of bits contained in the first data. Alternatively, if service request #1 contains a first address, the first core network element can also determine the number of bits contained in the first data based on the first address. For example, the first core network element can determine the number of bits contained in the first data based on the start address and end address of the storage area. If the start address of the storage area is add1 and the end address is add2, |add2-add1|=X, meaning the first data contains X bits, where || represents absolute value operation. Alternatively, if service request #1 contains a data length, the first core network element can also determine the number of bits contained in the first data based on that data length. Based on this, the first core network element can quantify the number of bits contained in the first data, such as dividing the number of bits contained in the first data by the length unit to obtain the first length. Of course, if one length unit contains one bit, then the number of bits contained in the first data is the first length.

[0197] It should be understood that business request #1 is an example, and it can also be expressed by other names, such as command #1. The operation corresponding to command #1 (such as a write operation) can also serve as information indicating the business type.

[0198] After determining the first length, the first core network element can compare the first length with the length threshold.

[0199] The length threshold can refer to the maximum length of data transmission, that is, the maximum amount of data to be transmitted in a single message / data length. If the maximum length is exceeded, it may be necessary to transmit the data in multiple messages.

[0200] The length threshold can be pre-configured or protocol-defined information, such as pre-configured in a third device. For case 1, the third device can be a core network element (such as denoted as the second core network element), such as a UDM network element or a unified data repository (UDR) network element, or any other network element that can be used to store or manage data, without specific restrictions.

[0201] In the second core network element, the length threshold can be information at the service requester level, meaning different service requesters may have different length thresholds. The length threshold for one service requester applies to the terminal corresponding to that requester, such as the terminal executing the service requested by that service requester. Alternatively, the length threshold can also be information at the service granularity level. Different types of services may have different length thresholds; for example, read and write can be understood as different types of services, as can inventory and location. The length threshold for one type of service applies to the terminal corresponding to that service, such as the terminal executing that service. Alternatively, the length threshold can also be information at the terminal or device granularity level, such as A-IoT terminals, where different terminals or devices may have different length thresholds.

[0202] The first core network element can obtain the length threshold from the second core network element.

[0203] For example, if the length threshold is information at the service requester granularity, the first core network element can send the service requester's identifier to the second core network element via a service-oriented interface message. The second core network element can determine the length threshold corresponding to the service requester based on the service requester's identifier and return it to the first core network element via a service-oriented interface message. As another example, if the length threshold is information at the service granularity, the first core network element can send the service type to the second core network element via a service-oriented interface message. The second core network element can determine the length threshold corresponding to the service type and return it to the first core network element via a service-oriented interface message. Yet another example, if the length threshold is information at the terminal or device granularity, the first core network element can send the device identifier to the second core network element via a service-oriented interface message. The second core network element can determine the length threshold corresponding to the device identifier and return it to the first core network element via a service-oriented interface message.

[0204] It is understandable that the pre-configuration of the length threshold in the second core network element is just one example and is not restricted. For example, it can also be pre-configured locally in the first core network element, so that the first core network element does not need to obtain it from other network elements.

[0205] The length threshold can also be dynamically determined information. For example, the first core network element can determine the length threshold based on the link status.

[0206] This link can be used to carry the first data (subsequently). For example, this link can be between an access network device supporting reader functionality and an A-IoT terminal. The status of this link can be at least one of the following: packet loss rate, packet error rate, retransmission count, bit error rate, signal-to-noise ratio, etc., or other parameters may be used, without specific restrictions. The lower the value of this at least one parameter, the better the status of the link, and vice versa. The first core network element can obtain the status of this link from the access network device. For example, the first core network element can subscribe to the link status from the access network device to obtain the link quality periodically or under certain conditions (such as the link quality change exceeding a quality threshold), or it can obtain the link quality through other means, without specific restrictions.

[0207] The first core network element can determine a length threshold that matches the link's state to ensure that the amount of data transmitted matches the link's condition. For example, if the link quality is poor, the length threshold will be smaller to reduce the amount of data transmitted in a single transmission, ensuring data transmission reliability even in poor link conditions. Conversely, if the link quality is good, the length threshold will be larger to increase the amount of data transmitted in a single transmission, ensuring data transmission efficiency. For instance, the first core network element can pre-configure or pre-define multiple ranges of link states, each corresponding to a length threshold. The first core network element can then determine the length threshold corresponding to the range in which the link's state falls, i.e., the length threshold matching the link's state. Alternatively, the access network device can determine the length threshold itself based on the link state, without the first core network element needing to determine it; it can receive the length threshold from the access network device.

[0208] It is understandable that the state of a link can be replaced by the quality of the link, or other terms, without restriction.

[0209] If the first length is less than or equal to the length threshold, then the first core network element can determine to send the first data through the first mode; or, if the first length is greater than the length threshold, then the first core network element can determine to send the first data through the second mode.

[0210] The first mode can be a mode that transmits data (or business data) through a single message. This message can be the first message used to transmit business data, or any message used to transmit business data; there are no specific restrictions. Additionally, the first mode can also have other names, such as fast transmit mode or fast command mode. Alternatively, corresponding to a write scenario (or write operation), the first mode can also be called fast write mode, or it can have other names as well; there are no specific restrictions.

[0211] The second mode can be a mode that transmits data (or business data) through multiple messages, or a mode that segments data into multiple messages for transmission. The first message in the multiple messages can be the first message used to transmit business data, or it can be any of the messages used to transmit business data; there are no specific restrictions. Similar to the first mode, the second mode can have other names, such as common transmit mode, common command mode, or long command mode. Alternatively, corresponding to the write scenario (or write operation), the first mode can also be called common write mode or long write mode, or the second mode can have other names as well; there are no specific restrictions.

[0212] Therefore, the first core network element determining to transmit the first data through the first mode can mean that the first core network element determines that it needs to use one message to transmit the first data; similarly, the first core network element determining to transmit the first data through the second mode can mean that the first core network element determines that it needs to segment the first data and use multiple messages to transmit these segments separately.

[0213] It should be understood that the above-mentioned relationship between the first length and the length threshold is only one example. For example, it could also be: if the first length is less than the length threshold, then the core network element can determine to transmit the first data through the first mode, or if the first length is greater than or equal to the length threshold, then the core network element can determine to transmit the first data through the second mode.

[0214] The second possible implementation method:

[0215] The first device is an access network device. The first access network device can receive a first service request. For ease of description, the first service request received by the first access network device is referred to as service request #2.

[0216] Service request #2 can be a request sent by the aforementioned first core network element. For example, after receiving service request #1, the first core network element can directly forward service request #1 to the access network device, meaning service request #1 and service request #2 are the same request. Alternatively, the first core network element can also send service request #2 to the access network device based on service request #1, such as encapsulating the information in service request #1 into service request #2 and then sending service request #2 to the access network device. In this case, the message types of service request #1 and service request #2 may be different.

[0217] It should be understood that business request #2 is also an exemplary name, which can be replaced by other names, such as command #2. The operation corresponding to command #2 (such as a write operation) can also serve as information indicating the business type.

[0218] The access network device can also obtain the first data from service request #2 and determine the first length based on the first data. The specific determination principle is similar to the first possible implementation method described above, and can be understood by referring to it, so it will not be elaborated here. If the first length is less than or equal to the length threshold, the access network device can determine that the first data is transmitted through the first mode; or, if the first length is greater than the length threshold, the access network device can determine that the first data is transmitted through the second mode. The length threshold can also be pre-configured or predefined by the protocol, such as being configured in the second core network element or locally on the access network device. The specific acquisition method is similar to the third possible implementation method described above, and can be understood by referring to it, so it will not be elaborated here. Alternatively, the length threshold can also be dynamically determined information, such as the access network device determining the length threshold based on the state of its own link. The specific implementation principle is similar to the first possible implementation method described above, and can be understood by referring to it, so it will not be elaborated here.

[0219] Furthermore, the second possible implementation described above is merely an example. For instance, the access network device may not need to configure or obtain a length threshold, or it may not need to determine the first length. In this case, the first core network element can determine whether to send the first data using a first mode or a second mode, and send mode indication information to the access network device. This mode indication information could be a single bit, with 0 or 1 values ​​indicating either the first or second mode. Thus, the access network device can determine whether to send the first data using the first mode or the second mode based on the mode indication information.

[0220] Scenario 2:

[0221] The first data can be data received by the first device, which can be a core network element or an access network device. The second device can be a terminal device, such as an A-IoT terminal. For details, please refer to [reference needed]. Figure 6The relevant introduction is provided in the text. Case 2 can be applied to reading scenarios, or reading operations / data reading operations. For example, before receiving the first data (such as the data to be read), the first device can first determine the first length to determine the mode for receiving the first data subsequently, such as whether to receive the first data through the first mode or the second mode.

[0222] The following section will take the first device as an example, which is either a core network element or an access network device, for further introduction.

[0223] The third possible implementation method:

[0224] The first device can also be the first core network element.

[0225] For example, the first core network element can receive the first address and determine the first length based on the first address.

[0226] Specifically, the first core network element can receive the second service request. For ease of description, the second service request received by the first core network element will be referred to as service request #3. Service request #3 can be used to request the reading of first data from the A-IoT terminal. Service request #3 may include the first data, and at least one of the following: the identifier of the service requester, the service type, the device identifier, the data length, or the first address. The service type may indicate the type of service / operation, such as read operation / data read operation. The identifier of the service requester, the device identifier, the data length, and the first address can be referred to the relevant description in the above-mentioned service request #1, and will not be repeated here.

[0227] It should be understood that the first core network element can also receive service request #3 through other network functions (such as NEF elements). In this case, the message type of service request #3 can be the same as or different from the message type of service requests received by other network functions from the service requester. That is, other network functions can also pass the service request #3 to the first core network element, or process the received service request (such as changing the message type) to obtain service request #3, and then send it to the first core network element. The specific processing method is not limited.

[0228] Therefore, the first core network element can obtain the first address from service request #3, and determine the number of bits contained in the first data based on the first address, so as to further determine the first length. The specific determination principle can be referred to the relevant introduction in the first possible implementation method above, and will not be repeated here.

[0229] It should also be understood that business request #3 is an example and can be replaced with other names, such as command #3. The operation corresponding to command #3 (such as a read operation) can also serve as information indicating the business type.

[0230] For example, the first core network element can also obtain the first length from the third device.

[0231] In scenario 2, the third device can also be a second core network element, such as a UDM network element or a UDR network element, or any other network element that can be used to store or manage data, without any specific restrictions.

[0232] The second core network element can pre-configure or pre-define at least one length of data, including a first length. For example, in the second core network element, this at least one length can be information at the service requester level, meaning that the length of data corresponding to different service requesters can be different, and the length of data corresponding to one service requester is applicable to the terminal corresponding to that service requester. Alternatively, this at least one length can also be information at the service level, such as the length of data corresponding to different types of services can be different, and the length of data corresponding to one type of service is applicable to the terminal corresponding to that service. Or, this at least one length can also be information at the terminal or device level, such as A-IoT terminals, where the length of data corresponding to different terminals or devices can be different.

[0233] In this regard, if at least one length is information at the service requester granularity, the first core network element can send the aforementioned device identifier to the second core network element through a service-oriented interface message. The second core network element can determine the first length corresponding to the device identifier based on the device identifier and return it to the first core network element through a service-oriented interface message. If at least one length is information at the service granularity, the first core network element can send the aforementioned service type to the second core network element through a service-oriented interface message. The second core network element can determine the first length corresponding to the service type based on the service type and return it to the first core network element through a service-oriented interface message. If at least one length value is information at the terminal or device granularity, the first core network element can send the aforementioned device identifier to the second core network element through a service-oriented interface message. The second core network element can determine the first length corresponding to the device identifier based on the device identifier and return it to the first core network element through a service-oriented interface message.

[0234] It should be understood that the pre-configuration of at least one length in the second core network element is an example and is not a limitation. For example, it can also be pre-configured locally in the first core network element, so that the first core network element does not need to obtain it from other network elements.

[0235] After determining the first length, the first core network element can compare the first length with a length threshold. If the first length is less than or equal to the length threshold, the first core network element can determine to receive the first data through the first mode; or, if the first length is greater than the length threshold, the first core network element can determine to transmit and receive the first data through the second mode. For specific implementation details, please refer to the relevant introduction of the first possible implementation method above, which will not be repeated here.

[0236] It is understandable that the fact that the first core network element determines to receive the first data through the first mode / second mode does not mean that the first core network element has received the first data. Rather, it should be understood that the first core network element knows that it will need to receive data of a first length through the first mode / second mode, and this data of a first length can be named the first data.

[0237] The fourth possible implementation method:

[0238] The first device can be an access network device.

[0239] For example, the access network device can receive a first address and determine a first length based on that address. Specifically, the access network device can also receive a second service request; for ease of description, this second service request received by the access network device will be denoted as service request #4. Service request #4 can be a request sent by the aforementioned first core network element. For example, after receiving service request #3, the first core network element can directly forward service request #3 to the access network device; that is, service request #3 and service request #4 are the same request. Alternatively, the first core network element can also send service request #4 to the access network device based on service request #3, such as encapsulating the information in service request #3 into service request #4 and then sending service request #4 to the access network device. In this case, the message types of service request #3 and service request #4 may be different.

[0240] Therefore, the access network device can also obtain the first address from service request #4 and determine the first length based on the first address. The specific implementation principle is similar to the first possible implementation method mentioned above, which can be referred to for understanding, and will not be elaborated here.

[0241] It should be understood that business request #4 is also an exemplary name, which can be replaced by other names, such as command #4. The operation corresponding to command #4 (such as a read operation) can also serve as information indicating the business type.

[0242] For example, the access network device can obtain the first length from the second core network element. The second core network element can also be an Internet of Things function (such as AIoTMF), a UDM network element, or a UDR network element. The specific implementation principle is similar to the third possible implementation method mentioned above, which can be referred to for understanding, and will not be elaborated here.

[0243] After obtaining the first length, the access network device can also compare the first length with a length threshold. If the first length is less than or equal to the length threshold, the access network device can determine that it will receive the first data through the first mode; or, if the first length is greater than the length threshold, the access network device can also determine that it will receive the first data through the second mode. For specific implementation details, please refer to the relevant introduction of the first possible implementation method above, which will not be repeated here.

[0244] It is understandable that the access network device's determination to receive the first data through the first mode / second mode does not mean that the access network device has received the first data. Rather, it should be understood that the access network device is aware that it will need to receive data of a first length through the first mode / second mode, and this data of the first length can be named the first data.

[0245] Furthermore, the fourth possible implementation described above is merely an example. For instance, the access network device may not need to configure or obtain a length threshold, or it may not need to determine the first length. In this case, the first core network element can determine whether to receive the first data through a first mode or a second mode, and send mode indication information to the access network device. This mode indication information could be a single bit, with 0 or 1 values ​​indicating either the first or second mode. Thus, the access network device can determine whether to receive the first data through the first mode or the second mode based on the mode indication information.

[0246] Scenario 3:

[0247] The first data can be data sent by the first device, which can be a terminal device, such as an A-IoT terminal. The second device can be an access network device. See reference for details. Figures 7-8 The relevant information is provided in the text. Case 3 can be applied to reading scenarios, or reading operations / data reading operations. For example, before sending the first data (such as the data being read), the A-IoT terminal can first determine the first length to determine the mode for subsequently sending the first data, such as whether to receive the first data through the first mode or the second mode.

[0248] For example, an A-IoT terminal can receive a first address and determine a first length based on the first address.

[0249] Specifically, the A-IoT terminal can receive commands, such as commands from access network devices. These commands can instruct the reading of first data from the A-IoT terminal and can include at least one of the following: service type, device identifier, data length, or first address. The service type can indicate the type of service / operation, such as read operation / data read operation. The device identifier, data length, and first address can be found in the relevant description of service request #1 above and will not be repeated here.

[0250] Therefore, the A-IoT terminal can also obtain the first address from the command and determine the first length based on the first address. The specific implementation principle is similar to the first possible implementation method mentioned above, which can be referred to for understanding, and will not be elaborated here.

[0251] After determining the first length, the A-IoT terminal can compare the first length with a length threshold. If the first length is less than or equal to the length threshold, the A-IoT terminal can determine to send the first data through a first mode; or, if the first length is greater than the length threshold, the A-IoT terminal can determine to send and receive the first data through a second mode.

[0252] The length threshold can be pre-configured locally on the A-IoT terminal, or the A-IoT terminal can obtain the length threshold from a third device.

[0253] In scenario 3, the third device can be an access network device. That is, the access network device can obtain or determine the length threshold in advance, such as through pre-configuration, acquisition from the second core network element, or determination based on the link status. For details, please refer to the relevant description in the first possible implementation above, which will not be repeated here. The access network device can send the length threshold to the A-IoT terminal, either in the command mentioned above or through a separate message; there are no specific restrictions.

[0254] Furthermore, the specific implementation of the length threshold can be found in the introduction of the length threshold in the first possible implementation method, and will not be repeated here.

[0255] If the first length is less than or equal to the length threshold, the A-IoT terminal can determine that the first data is sent through the first mode; or, if the first length is greater than the length threshold, the A-IoT terminal can also determine that the first data is sent through the second mode. The specific determination principle is similar to the first possible implementation method mentioned above, which can be understood by reference and will not be elaborated here.

[0256] S603, if it is determined that the first data is transmitted through the first mode, the first data is transmitted through the first message; or, if it is determined that the first data is transmitted through the second mode, the first data is transmitted through the second message and the third message.

[0257] Continuing with scenario 1:

[0258] 1) If it is determined that the first data is to be sent through the first mode, the first device may send the first message to the second device.

[0259] The first message may include the first data. The first message can be the first downlink message used to transmit service data to improve transmission efficiency, or it can be any downlink message used to transmit service data, such as a NAS message, denoted as NAS message #1, or an RRC message, denoted as RRC message #1.

[0260] For example, the first device is a first core network element, and the second device is an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, and the first core network element determines that it will send the first data using the first mode, then the first core network element can obtain the first data from service request #1 and send the first data to the A-IoT terminal through the access network device, such as sending a NAS message #1 carrying the first data. Alternatively, the first device is a first access network device, and the second device is an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, and the access network device determines that it will send the first data using the first mode, then the access network device can obtain the first data from service request #2 and send the first data to the A-IoT terminal, such as sending an RRC message #1 carrying the first data, or other similar alternative messages.

[0261] Optionally, the first device may also send a first address to the second device, and the second device may receive the first address.

[0262] For example, the first device is a first core network element, and the second device is an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, the first core network element can also obtain a first address from service request #1 and send the first address to the A-IoT terminal, such as by including it in the aforementioned NAS message #1, or by carrying it in a separate message; there are no specific restrictions. Alternatively, the first device is a first access network device, and the second device is an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, the access network device can also obtain a first address from service request #2 and send the first address to the A-IoT terminal, such as by including it in the aforementioned RRC message #1, or by carrying it in a separate message; there are no specific restrictions.

[0263] After receiving the first address, the A-IoT terminal can write the first data into the specified storage area according to the first address.

[0264] It should be understood that if the first address is the default address of the A-IoT terminal, or if the A-IoT terminal decides where to write the first data, then the first core network element or access network device may not need to send the first address to the A-IoT terminal in order to reduce overhead.

[0265] 2) If it is determined that the first data is sent through the second mode, the first device may send a second message and a third message to the second device.

[0266] The first data may include the second data and the third data. For example, the first device can determine the second data and the third data based on the first data, that is, the first data can be segmented to obtain the second data and the third data.

[0267] The second message may include the second data, and the third message may include the third data. The first message in either the second or third message can be the first downlink message used to transmit service data to reduce transmission latency. Alternatively, the second and third messages can be any two downlink messages used to transmit service data; there are no specific restrictions. Both the second and third messages can be NAS messages, such as NAS message #2 and NAS message #3 respectively, or both can be RRC messages, such as RRC message #2 and RRC message #3 respectively.

[0268] For example, the first device is a first core network element, and the second device is an A-IoT terminal. If the A-IoT terminal successfully accesses the network, and the first core network element determines that it will send the first data via the second mode, then the first core network element can obtain the first data from service request #1 and divide it into multiple segments, either equally or unequally. The number of data segments can be determined by the first core network element itself, such as a first length of L, a length threshold of Lmax, and the number of data segments... This indicates rounding up. For example, the first core network element can be divided into N-1 segments according to a length threshold, and the length of the Nth segment is L-(Lmax*(N-1)). Alternatively, the first core network element can also be divided into segments with a length of... The length of the Nth segment is the length of the first N-1 segments. This indicates rounding down. In this case, the second and third data segments can be the first two segments of N data segments. The first core network element can carry the second data into NAS message #2 and send NAS message #2 to the A-IoT terminal through the access network device. The first core network element can then carry the third data into NAS message #3 and send NAS message #3 to the A-IoT terminal through the access network device.

[0269] Alternatively, the first device can be a first access network device, and the second device can be an A-IoT terminal. If the A-IoT terminal successfully accesses the network, and the access network device determines that it will send the first data via the second mode, it can obtain the first data from service request #2 and divide it into multiple segments, either equally or unequally. The principle of segmentation is similar to that of the first core network element described above, and will not be elaborated further. Then, the access network device can carry the second data into RRC message #2 and send RRC message #2 to the A-IoT terminal. The access network device then carries the third data into RRC message #3 and sends RRC message #3 to the A-IoT terminal.

[0270] Optionally, the first device may send a first address to the second device, and the second device may receive the first address.

[0271] For example, the first device is a first core network element, and the second device is an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, the first core network element can also obtain a first address from service request #1 and send the first address to the A-IoT terminal through the access network device. This can be done by including it in the aforementioned NAS message #2 or NAS message #3, or by carrying it in a separate message; there are no specific restrictions. Alternatively, the first device can be a first access network device, and the second device can be an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, the access network device can also obtain a first address from service request #2 and send it to the A-IoT terminal. This can be done by including it in the aforementioned RRC message #2 or RRC message #3, or by carrying it in a separate message; there are no specific restrictions.

[0272] In this way, after receiving the first address, the A-IoT terminal can sequentially write the second and third data into the storage area indicated by the first address. For example, the first address includes a start address add1 and an end address add2, |add2-add1| = X, where X is 240 bits. The second and third data are data received sequentially by the A-IoT terminal, and each is 60 bits. The A-IoT terminal can then write the 60 bits of the second data into the area corresponding to the first 60 bits of the 240 bits, and write the 60 bits of the third data into the area corresponding to bits 61 to 120 of the 240 bits, and so on.

[0273] Alternatively, the first device can send a second address and a third address to the second device. The second device can receive the second address and the third address.

[0274] For example, the first device is a first core network element, and the second device is an A-IoT terminal. When the A-IoT terminal successfully accesses the network, the first core network element can obtain a first address from service request #1 and segment the first address according to the segmentation method of the first data to obtain multiple address segments, such as N address segments. These N address segments can be consecutive or non-consecutive, without restriction, ensuring that the sum of the lengths of the N address segments equals the length of the first address, such as |add2-add1|=X. The second and third addresses can be the first two segments of the N address segments, corresponding to the second and third data respectively. The first core network element can send the second and third addresses to the A-IoT terminal through the access network device, such as carrying the second address in the aforementioned NAS message #2 and the third address in the aforementioned NAS message #3, or carrying them in separate messages, without specific restrictions. Alternatively, the first device can be a first access network device, and the second device can be an A-IoT terminal. If the A-IoT terminal successfully accesses the network randomly, the access network device can also obtain the first address from service request #2 and segment the first address according to the segmentation method of the first data to obtain N address segments. For the second and third addresses, the access network device can send the second and third addresses to the A-IoT terminal, such as carrying the second address in the aforementioned RRC message #2 and the third address in the aforementioned RRC message #3, or it can carry them in separate messages; there are no specific restrictions.

[0275] In this way, after receiving the first address, the A-IoT terminal can write the second data into the storage area indicated by the second address and write the third data into the storage area indicated by the third address.

[0276] It should be understood that if the above address is the default address of the A-IoT terminal, or if the A-IoT terminal decides where to write the first data, then the first core network element or access network device may not need to send the above address, such as the first address, or the second and third addresses, to the A-IoT terminal in order to reduce overhead.

[0277] It should also be understood that the above is based on the second and third data as examples. The first data can be further divided into more data, such as the fourth and fifth data. The principle is similar to that of the second and third data, which can be understood by reference and will not be elaborated further.

[0278] Continuing with scenario 2:

[0279] 1) When it is determined that the first data is received through the first mode, the first device receives the first message from the second device, such as first sending the first address to the second device, so as to receive the first message returned by the second device according to the first address.

[0280] The first message may include the first data. The first message may be the first uplink message used to transmit service data in order to improve transmission efficiency, or it may be any uplink message used to transmit service data, such as a NAS message, denoted as NAS message #a, or an RRC message, denoted as RRC message #a.

[0281] For example, the first device is a first core network element, and the second device is an A-IoT terminal.

[0282] When the first core network element determines that the first data will be sent via the first mode, it can obtain the first address from service request #3 and send the first address to the A-IoT terminal via the access network device. For example, the first core network element can first send an N2 message carrying the first address, or any other possible message, to the access network device. The access network device then sends a message carrying the first address to the A-IoT terminal, such as a selection message / paging message, or any other possible message. The A-IoT terminal can read the first data from the storage area indicated by the first address and determine the length of the first data, such as the first length. The A-IoT terminal is pre-configured with a length threshold, and can determine that the first data does not need to be segmented based on whether the first length is less than or equal to the length threshold. When sending the first data, such as when the device identifier of the A-IoT terminal needs to be reported to the network during random access, or after random access is completed, the A-IoT terminal can carry the first data in a NAS message #a and send the NAS message #a to the first core network element via the access network device. The first core network element can receive the NAS message #a to obtain the first data. The first core network element can determine the received data, such as the relationship between the length of the first data and the first length. In this case, if the length of the first data is equal to the first length, it indicates that the data transmission of the A-IoT terminal is complete, and the first core network element can send the first data to the service requester.

[0283] For example, the first device is an access network device, and the second device is an A-IoT terminal.

[0284] When the access network device determines that it will send the first data via the first mode, it can obtain the first address from service request #4 and send the first address to the A-IoT terminal, such as sending a selection / paging message carrying the first address, or any other possible message. The A-IoT terminal can also read the first data from the storage area indicated by the first address and determine the first length. The A-IoT terminal is pre-configured with a length threshold, and can determine that the first data does not need to be segmented based on whether the first length is less than or equal to the length threshold. When sending the first data, such as when the device identifier of the A-IoT terminal needs to be reported to the network during random access, or after random access is completed, the A-IoT terminal can carry the first data in an RRC message #a and then send the RRC message #a to the access network device. The access network device can receive the RRC message #a to obtain the first data. The access network device can determine the received data, such as the relationship between the length of the first data and the first length. In this case, if the length of the first data is equal to the first length, it indicates that the data transmission of the A-IoT terminal is complete, and the access network device can send the first data to the first core network element, which will then forward it to the service requester.

[0285] Additionally, in S601-S602 above, if the access network device does not determine the first length, such as if the first core network element indicates whether it adopts the first mode or the second mode by sending mode indication information, then when the access network device receives data from the A-IoT terminal, it can determine whether it will receive data from the A-IoT terminal again within a preset time period thereafter. If it does, it indicates that the data transmission of the A-IoT terminal is not complete; otherwise, it indicates that the data transmission of the A-IoT terminal is complete.

[0286] 2) When it is determined that the second data is received through the first mode, the first device receives the second message and the third message from the second device, such as sending the first address to the second device to receive the second message and the third message returned by the second device according to the first address.

[0287] The first data may include the second data and the third data. For example, the second device can determine the second data and the third data based on the first data, that is, the first data can be segmented to obtain the second data and the third data.

[0288] The second message may include the second data, and the third message may include the third data. The first message in either the second or third message can be the first uplink message used to transmit service data to reduce transmission latency, or the second and third messages can be any two uplink messages used to transmit service data; there are no specific restrictions. Both the second and third messages can be NAS messages, such as NAS message #b and NAS message #c respectively, or both can be RRC messages, such as RRC message #b and RRC message #c respectively.

[0289] For example, the first device is a first core network element, and the second device is an A-IoT terminal.

[0290] When the first core network element determines that the first data will be sent via the second mode, it can obtain the first address from service request #3 and send the first address to the A-IoT terminal through the access network device, as described above. The A-IoT terminal can read the first data from the storage area indicated by the first address and determine the length of the first data, such as the first length. The A-IoT terminal is pre-configured with a length threshold. Based on the first length being greater than the length threshold, the A-IoT terminal can divide the first data into multiple segments to obtain the second and third data. The specific segmentation method is similar to that of the first core network element described above and can be understood by referring to it; it will not be elaborated here.

[0291] When the first data is sent, such as during random access when the A-IoT terminal's device identifier needs to be reported to the network, or after random access is completed, the A-IoT terminal can carry the second data in a NAS message #b and send the NAS message #b to the first core network element through the access network device. The first core network element can receive the NAS message #b to obtain the second data. The first core network element can determine the received data, such as the relationship between the length of the second data and the length of the first data. In this case, if the length of the second data is less than the length of the first data, it indicates that the A-IoT terminal's data transmission is not complete, and the first core network element can continue to receive data from the A-IoT terminal without performing data aggregation.

[0292] After sending NAS message #a, the A-IoT terminal can also include third data in NAS message #c and send NAS message #c to the first core network element through the access network device. The first core network element can receive NAS message #c to obtain the third data. The first core network element can determine the received data, such as the relationship between the sum of the lengths of the second and third data and the first length. In this case, if the sum of the lengths of the second and third data is less than the first length, it indicates that the data transmission of the A-IoT terminal is not complete, and the first core network element can continue to receive data from the A-IoT terminal without performing data aggregation. If the sum of the lengths of the second and third data is equal to the first length, it indicates that the data transmission of the A-IoT terminal is complete, and the first core network element can perform data aggregation. For example, the first core network element can determine the first data based on the second and third data, such as by sequentially concatenating the second, third, or other received data to obtain the first data. Then, the first core network element can send the first data to the service requester, thus realizing the provision of complete data to other entities / network elements on the network side through data aggregation.

[0293] For example, the first device is an access network device, and the second device is an A-IoT terminal.

[0294] If the access network device determines that the first data will be sent via the second mode, it can obtain the first address from service request #4 and send the first address to the A-IoT terminal, as described above. The A-IoT terminal can read the first data from the storage area indicated by the first address and determine the length of the first data, such as the first length. The A-IoT terminal is pre-configured with a length threshold. If the first length is greater than the length threshold, the A-IoT terminal can divide the first data into multiple segments to obtain the second and third data. The specific segmentation method is similar to that of the access network device described above and can be understood by referring to it; it will not be described again here.

[0295] When the first data is sent, such as during random access when the A-IoT terminal's device identifier needs to be reported to the network, or after random access is completed, the A-IoT terminal can carry the second data in an RRC message #b (or carry it in a NAS message and send it to the access network device via RRC message #b), and send the RRC message #b to the access network device. The access network device can receive the RRC message #b to obtain the second data. The access network device can determine the received data, such as the relationship between the length of the second data and the length of the first data. In this case, if the length of the second data is less than the length of the first data, it indicates that the A-IoT terminal's data transmission is not complete, and the access network device can continue to receive data from the A-IoT terminal without performing data aggregation.

[0296] After sending RRC message #a, the A-IoT terminal can also include third data in RRC message #c and send RRC message #c to the access network device. The access network device can receive RRC message #c to obtain the third data. The access network device can determine the received data, such as the relationship between the sum of the lengths of the second and third data and the first length. In this case, if the sum of the lengths of the second and third data is less than the first length, it indicates that the data transmission of the A-IoT terminal is not complete, and the access network device can continue to receive data from the A-IoT terminal without performing data aggregation. If the sum of the lengths of the second and third data is equal to the first length, it indicates that the data transmission of the A-IoT terminal is complete, and the access network device can perform data aggregation. For example, the access network device can determine the first data based on the second and third data, such as by sequentially concatenating the second, third, or other received data to obtain the first data. The access network device can send the first data to the first core network element, which then forwards it to the service requester, thus realizing the provision of complete data to other entities / network elements on the network side through data aggregation.

[0297] It is understandable that in the above S601-S602, if the access network device does not determine the first length, such as the first core network element indicating whether it adopts the first mode or the second mode by sending mode indication information, then when the access network device receives data from the A-IoT terminal, it can determine whether it will receive data from the A-IoT terminal again within the preset time period. If it does, it means that the data transmission of the A-IoT terminal is not completed; otherwise, it means that the data transmission of the A-IoT terminal is completed.

[0298] Optionally, in scenario 2 above, the second device (e.g., an A-IoT terminal) can send the second and third messages by default. For example, after sending the second message, the second device can continue sending the third message without waiting for instructions from the first device, until the first data transmission is complete. Alternatively, the second device can wait for instructions from the first device. For instance, after receiving the first message from the second and third messages, the first device (e.g., an access network device or a first core network element) can send a first instruction message to the second device. The first instruction message can instruct the second device to continue sending data. The first instruction message can be carried in the confirmation message returned by the second device in response to receiving the first message, or it can be carried in a separate message; there are no specific restrictions. Correspondingly, the second device can continue receiving the next message from the second and third messages based on the first instruction message. If the first device needs to send other messages after the second and third messages to carry the remaining portion of the first data transmission, the same principle applies, and will not be elaborated further, until the first data transmission is complete. In other words, whether the second device should continue sending data can be indicated by the first device to avoid data transmission errors and ensure the reliability and stability of data transmission. Alternatively, the first device may carry information indicating the completion of data transmission in the message carrying the last data sent in the first data. The second device can determine the completion of the first data transmission based on this indication information, eliminating the need for the first device to provide the first indication information in every transmitted message, thereby reducing indication overhead.

[0299] It should also be understood that the solutions described in scenario 2 above are merely examples and not intended as limitations. For instance, the first device (such as an access network device or a first core network element) can also determine whether to segment the address and send it to the second device (such as an A-IoT terminal) based on whether the data is segmented. If the data is not segmented, the access network device or the first core network element sends the first address to the A-IoT terminal; otherwise, it sends the addresses corresponding to each segment of data, such as the second address, the third address, etc., to the A-IoT terminal. Correspondingly, the A-IoT terminal does not need to determine whether the data is segmented; it can simply return the data read based on the address in the uplink message to the access network device or the first core network element by default.

[0300] It is also understood that in situation 2 above, if the second device (such as an A-IoT terminal) sends an RRC message or NAS message when reporting the device identifier to the network, the RRC message or NAS message may also contain the device identifier of the second device.

[0301] Alternatively, in case 1 or case 2 above:

[0302] If the first device is a first core network element and the second device is an A-IoT terminal, then when the first core network element determines that the first data is transmitted through the first mode, the first core network element may also send a second instruction message to the access network device; or, when the first core network element determines that the first data is transmitted through the second mode, the first core network element may also send a third instruction message to the access network device.

[0303] The second instruction information can be carried in the N2 message or any other possible message; there are no specific restrictions. The second instruction information can instruct the access network device to continue performing operations on other terminals after forwarding the first message, or in other words, instruct the access network device to continue performing operations on other terminals after forwarding the first message carrying data from the A-IoT terminal. In this case, the access network device can trigger operations on other terminals, such as random access procedures or service procedures, without waiting for subsequent instructions from the core network, thereby reducing latency and improving operational efficiency.

[0304] The third instruction information can be carried in the N2 message or any other possible message, without any specific restrictions. The third instruction information can instruct the access network device, after forwarding the first message in the second and third messages, to perform operations on other terminals according to the instructions of the core network element. Alternatively, it can instruct the access network device, after forwarding the first message carrying data from the A-IoT terminal, to perform operations on other terminals according to the instructions of the core network element. For example, if the first core network element determines that the first data transmission is complete, it can instruct the access network device to continue performing operations on other terminals. This could be done by sending an explicit message to the access network device to clearly instruct it to continue performing operations on other terminals, or by sending a mask used for paging other terminals to the access network device to implicitly instruct it to continue performing operations on other terminals. The specific implementation method is not limited. This avoids the access network device performing operations on other terminals before transmitting the first data, which could lead to the failure of the first data transmission and ensure the reliability of data transmission.

[0305] If the first device is an access network device and the second device is an A-IoT terminal, then when the access network device determines that it is transmitting the first data through the first mode, it can continue to perform operations on other terminals after sending the first message to improve operational efficiency. When the access network device determines that it is transmitting the first data through the second mode, it needs to perform operations on other terminals according to the instructions of the core network after sending the first message of the second and third messages. It can be understood that if the access network device can determine on its own whether the first data transmission is complete, then it can also continue to perform operations on other terminals after determining that the first data transmission is complete, without requiring instructions from the core network.

[0306] Continuing with scenario 3:

[0307] The first device can be an A-IoT terminal, and the second device can be an access network device.

[0308] 1) If it is determined that the second data is to be sent through the first mode, the A-IoT terminal may send the first message to the access network device.

[0309] The first message may include the first data. The first message can be the first uplink message used to transmit service data to improve transmission efficiency, or it can be any uplink message used to transmit service data, such as RRC message #a.

[0310] For example, when the first data is transmitted, such as during random access when the A-IoT terminal's device identifier needs to be reported to the network, or after random access is completed, the A-IoT terminal can carry the first data in an RRC message #a and send the RRC message #a to the access network device. The access network device can receive the RRC message #a to obtain the first data. Optionally, the RRC message #a may contain at least one of the following: a first length, or information indicating the completion of data transmission.

[0311] The access network device can determine that the A-IoT terminal's data transmission is complete based on either the first length being the same as the length of the first data received by the access network device, or based on information indicating data transmission completion. Alternatively, if the RRC message #a does not contain the first length or information indicating data transmission completion, the access network device, upon receiving data (such as the first data) from the A-IoT terminal, can determine whether it receives data from the A-IoT terminal again within a preset time period. If it receives data from the A-IoT terminal again within the preset time period, it indicates that the A-IoT terminal's data transmission is not complete; otherwise, it indicates that the A-IoT terminal's data transmission is complete. In this way, the access network device can send the first data to the first core network element, which then forwards it to the service requester.

[0312] Additionally, once the access network device determines that the data transmission of the A-IoT terminal is complete, it can also trigger operations for other terminals, such as random access procedures.

[0313] 2) If it is determined that the first data is sent through the second mode, the A-IoT terminal can send the second message and the third message to the access network device.

[0314] The first message may include second and third data. The first message in either the second or third message can be the first uplink message used to transmit service data, or the second and third messages can be any two uplink messages used to transmit service data; there are no specific restrictions. The second and third messages can be RRC messages, such as RRC message #b and RRC message #c, respectively.

[0315] For example, in the second mode, the A-IoT terminal can determine the second and third data based on the first data. This can be achieved by segmenting the first data to obtain the second and third data. The specific segmentation method is similar to that of the first core network element mentioned above, and can be understood by referring to it; it will not be elaborated further here. When sending the first data, such as during random access when the A-IoT terminal's device identifier needs to be reported to the network, or after random access is completed, the A-IoT terminal can send multiple RRC messages to the access network device to transmit the first data, such as RRC message #b, RRC message #c, etc. The specific principle is similar to that of the A-IoT terminal in situation 2 above, and can be understood by referring to it; it will not be elaborated further here.

[0316] Optionally, any one of the aforementioned RRC messages may carry a first length, and / or the last of the RRC messages may carry information indicating that data transmission is complete.

[0317] The access network device can determine that the A-IoT terminal's data transmission is complete based on either the first length being the same as the length of the data received by the access network device, or based on information indicating data transmission completion. Alternatively, if the aforementioned RRC message does not contain the first length or information indicating data transmission completion, the access network device, upon receiving data from the A-IoT terminal, can determine whether it receives data from the A-IoT terminal again within a preset time period. If so, it indicates that the A-IoT terminal's data transmission is not complete; otherwise, it indicates that the A-IoT terminal's data transmission is complete. Thus, the access network device can aggregate the received data to obtain first data, send the first data to the first core network element, and the first core network element forwards it to the service requester.

[0318] Optionally, in the process of scenario 3 above, the first device (such as an A-IoT terminal) can send the second and third messages by default. For example, after sending the second message, the first device can continue sending the third message by default until the first data transmission is complete. Alternatively, the first device can also indicate the transmission of messages. For example, after sending the first message in the second and third messages, the first device can send a fourth indication message to the second device (such as an access network device or a first core network element). The fourth indication message can instruct the first device to continue sending data. That is, whether the second device should continue to wait for receiving data can be indicated by the first device to ensure the stability and reliability of data transmission. In this case, if the first device needs to send other messages after the second and third messages to carry the part of the first data that has not yet been sent, the same principle applies, and will not be elaborated further, until the first data transmission is complete.

[0319] It should be understood that the RRC message described above is an example and can be replaced with other types of messages without limitation. For example, a message sent from an AIoT terminal to a reader can be called a D2R message (Device to Reader, D2R), and a message sent from a reader to an AIoT terminal can be called an R2D message (Reader to Device, R2D).

[0320] It should also be understood that in the above S601-S603, the access network device can also be considered as a reader, or a reader in other device forms, or the access network device can also be replaced by a terminal device, such as a terminal that supports reader function.

[0321] In summary, when the length or volume of the first data differs, the first data can be transmitted using different modes. For example, if the first length is relatively short, the first device can transmit the first data using a first mode, such as through a first message, to ensure efficient data transmission. If the first length is relatively long, the first device can transmit the first data using a second mode, such as through a second and a third message, to avoid transmission failure due to the first message not being able to transmit all the first data, thus ensuring the reliability of data transmission.

[0322] The above combination Figure 7 The workflow of the communication method provided in the embodiments of this application is described below. Figure 2 The specific process of the communication method provided in the embodiments of this application is described in detail.

[0323] Figure 7 Flowchart of the communication method provided in the embodiments of this application Figure 7 .like Figure 6As shown, the process involves AF (such as the service requester), NEF network element, UDM / UDR network element (such as the second core network element), A-IoTMF network element (such as the first core network element), reader (such as access network equipment or terminal equipment that supports reader function), and A-IoT terminal.

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

[0325] S700, UDM / UDR network element pre-configured length threshold.

[0326] The length threshold can be referenced above. Figure 3 The relevant information about the medium length threshold will not be repeated here.

[0327] It should be understood that S700 is optional, and the length threshold can also be dynamically determined.

[0328] Optionally, in the S700, the UDM / UDR network element can also be pre-configured with at least one of the above lengths (including the first length), such as information at the service requester, service, or terminal / device granularity. For details, please refer to the relevant introduction of the above at least one length, which will not be repeated here.

[0329] The data length of an A-IoT terminal can be the same as the data length of an A-IoT device, such as the first length of the first data mentioned above. For details, please refer to the relevant introduction of the first length mentioned above, which will not be repeated here.

[0330] S701, AF sends a service request to the NEF network element.

[0331] For write scenarios / write operations, a business request (such as business request #1 above) may include at least one of the following: first data, the identifier of the business requester, the business type (write operation), the device identifier (specifically, it may be a device identifier prefix), the data length, or the first address. For details, please refer to the relevant introduction of business request #1 above, which will not be repeated here.

[0332] For read scenarios / read operations, a business request (such as business request #3 above) may include at least one of the following: first data, the identifier of the business requester, the business type (read operation), the device identifier, the data length, or the first address. For details, please refer to the relevant introduction of business request #3 above, which will not be repeated here.

[0333] S702, the NEF network element sends a service request to the A-IoTMF network element.

[0334] The service request in S702 can be the same message as the service request in S701, or they can be different messages without restriction. If they are different messages, the service request in S702 can also contain the content of the service request in S701. That is, the NEF network element obtains the content of the service request in S701 and then carries it into the service request in S702.

[0335] In one implementation, the AF can also directly send service requests to the AIoTMF (e.g., when the AF is trusted).

[0336] S703, the A-IoTMF network element determines whether the first data needs to be transmitted in segments.

[0337] The A-IoTMF network element can determine the first length, such as by determining the first length based on the first address or first data in the service request, or by obtaining the first length from the UDM / UDR network element. The A-IoTMF network element can determine whether the first data needs to be transmitted in segments based on whether the first length exceeds a length threshold, such as whether to send the first data in segments or receive the first data in segments. This corresponds to the first mode and the second mode mentioned above. For details, please refer to the relevant introductions to the first and second modes, which will not be elaborated upon here.

[0338] It is understandable that, for write scenarios / write operations, if the first data does not need to be sent in segments, then S704-S706 are executed; if the first data needs to be sent in segments, then S707-S710 are executed. For read scenarios / read operations, if the first data does not need to be received or sent, then S711-S713 are executed; if the first data needs to be received in segments, then S714-S718 are executed.

[0339] S704, the A-IoTMF network element sends an N2 message to the reader.

[0340] In S704, the N2 message may include at least one of the following: a device identifier prefix, a service type (write operation), or a second indication information. The second indication information can instruct the reader to continue performing operations on other terminals after forwarding the first message carrying data from the A-IoT terminal. For details, please refer to the relevant introduction of the second indication information above, which will not be repeated here.

[0341] S705a, the reader sends a selection message or a paging message.

[0342] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0343] S705b, A-IoT terminals perform random access.

[0344] A-IoT terminals can perform random access based on selection messages or paging messages.

[0345] During the random access process, the A-IoT terminal can report its complete device identifier, such as the identifier assigned by the EPC or operator. The A-IoTMF network element obtains the complete device identifier, confirms that the A-IoT terminal has successfully accessed the network, and continues to execute S706.

[0346] S706, the A-IoTMF network element sends a DL NAS message to the A-IoT terminal.

[0347] In S706, DL NAS messages can include the first data, i.e., without segmentation.

[0348] The A-IoT terminal can write the received first data to the storage area. Optionally, the DL NAS message can also carry an address indicating the storage area, such as a first address. The A-IoT terminal can write the first data to the corresponding storage area based on the received first address. For details, please refer to the above introduction on the first address, which will not be repeated here. Alternatively, the DL NAS message can also omit the first address, allowing the A-IoT terminal to decide where to write the received data, or to write it to a default location (such as a predefined or pre-configured location). It can be understood that when the A-IoTMF network element does not send the first data in segments, the reader can, by default, perform operations for other terminals after forwarding the DL NAS message in S707 to the A-IoT terminal, such as sending other terminal selection messages or paging messages.

[0349] S707, the A-IoTMF network element sends an N2 message to the reader.

[0350] In S707, the N2 message may include at least one of the following: device identifier prefix, service type (write operation), or third instruction information. The third instruction information can instruct the reader to perform operations on other terminals according to the instructions of the core network element after forwarding the first message carrying the data of the A-IoT terminal. For details, please refer to the relevant introduction of the third instruction information above, which will not be repeated here.

[0351] S708a, the reader sends a selection message or a paging message.

[0352] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0353] S708b, A-IoT terminals perform random access.

[0354] A-IoT terminals can perform random access based on selection messages or paging messages.

[0355] During the random access process, the A-IoT terminal can report its complete device identifier, such as the identifier assigned by the EPC or operator. The A-IoTMF network element obtains the complete device identifier, confirms that the A-IoT terminal has successfully accessed the network, and continues to execute S709.

[0356] S709, the A-IoTMF network element sends DL NAS message #1 to the A-IoT terminal.

[0357] DL NAS message #1 may include second data. The second data is a segment of the first data, i.e., it is sent in segments. For details, please refer to the relevant introduction of the second data above, which will not be repeated here.

[0358] S710, the A-IoTMF network element sends DL NAS message #2 to the A-IoT terminal.

[0359] DL NAS message #2 may include third data. The third data is another segment of the first data; for details, please refer to the above introduction on third data, which will not be repeated here.

[0360] In S709-S710, the A-IoT terminal can write the received second and third data into the storage area. Optionally, the aforementioned DL NAS message can also carry an address indicating the storage area. For example, DL NAS message #1 carries a first address, and DL NAS message #2 carries a third address, i.e., the segmented addresses. The A-IoT terminal can write the second and third data into the corresponding storage area according to the received addresses. For details, please refer to the relevant introductions to the first, second, and third addresses above, which will not be repeated here. Alternatively, the aforementioned DL NAS message may not carry an address indicating the storage area, and the A-IoT terminal can decide where to write the received data.

[0361] It is understandable that the first data segmentation can also include the fourth data, fifth data, etc., and the principle is similar, which can be referred to for understanding, and will not be elaborated further. In addition, when the A-IoTMF network element sends the first data in segments, after the reader forwards the DL NAS message #1 in S708 to the A-IoT terminal, it needs to wait for instructions from the network. For example, after S709-S710, after the A-IoTMF network element has finished sending the first data, the A-IoTMF network element can instruct the reader to perform operations for other terminals.

[0362] S711, the A-IoTMF network element sends an N2 message to the reader.

[0363] In S711, the N2 message may include at least one of the following: device identifier prefix, service type (write operation), or second indication information. For details of the second indication information, please refer to the relevant introduction of the second indication information above, which will not be repeated here.

[0364] S711a, the reader sends a selection message or a paging message.

[0365] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0366] S711b, A-IoT terminals perform random access.

[0367] A-IoT terminals can perform random access based on selection messages or paging messages.

[0368] S712, the A-IoT terminal sends a UL NAS message to the A-IoTMF network element.

[0369] In S712, UL NAS messages can include initial data, i.e., without segmentation. Optionally, UL NAS messages can also include the complete device identifier of the A-IoT terminal, and UL NAS messages can also be sent after the A-IoTMF network element reports the EPC.

[0370] The A-IoT terminal can read the first data from the storage area. Optionally, the A-IoTMF network element indicates the address of the storage area, such as the first address, which may be sent to the A-IoT terminal by the reader in the N2 message carrying S711, or sent to the A-IoT terminal via a read command. This allows the A-IoT terminal to read the first data from the storage area based on the first address. For details on the first address, please refer to the above description; it will not be repeated here. Alternatively, the A-IoTMF network element may not indicate the first address, and the A-IoT terminal may know the data storage location in advance (e.g., through protocol pre-definition or pre-configuration). It can be understood that if the A-IoTMF network element does not receive the first data in segments, the reader may, after forwarding the UL NAS message in S712 to the A-IoTMF network element, perform operations for other terminals by default, such as sending other terminal selection messages or paging messages.

[0371] S713, the A-IoTMF network element sends the first data to the AF.

[0372] The A-IoTMF network element can determine the completion of data transmission, such as when the sum of the lengths of the received data is equal to the first length, indicating that the first data has been received. The AF can send the first data to the AF (e.g., via NEF), as detailed in the relevant introduction of S603 above, which will not be repeated here.

[0373] S714, the A-IoTMF network element sends an N2 message to the reader.

[0374] In S714, the N2 message may include at least one of the following: device identifier prefix, service type (write operation), or third indication information. The third indication information can be found in the above description and will not be repeated here.

[0375] S715a, the reader sends a selection message or a paging message.

[0376] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0377] S715b, A-IoT terminals perform random access.

[0378] A-IoT terminals can perform random access based on selection messages or paging messages.

[0379] S716, the A-IoT terminal sends UL NAS message #1 to the A-IoTMF network element.

[0380] UL NAS message #1 may include second data. The second data is a segment of the first data, i.e., it is sent in segments. For details, please refer to the relevant introduction of the second data above, which will not be repeated here. Optionally, UL NAS message #1 may also include the complete device identifier of the A-IoT terminal, such as EPC, or UL NAS message #1 may also be sent after the A-IoT terminal reports the EPC.

[0381] S717, the A-IoT terminal sends UL NAS message #2 to the A-IoTMF network element.

[0382] UL NAS message #2 may include third data. The third data is another segment of the first data; details can be found in the above description of the third data, which will not be repeated here. UL NAS message #2 can be sent by the A-IoT terminal by default, such as sending UL NAS message #1 followed by sending UL NAS message #2 by default. Alternatively, it can be sent according to the instructions of the A-IoTMF network element, such as the first instruction information mentioned above. For example, if the A-IoTMF network element receives UL NAS message #1 and instructs the A-IoT terminal to continue transmission, the A-IoT terminal will send UL NAS message #2 according to its instruction. Details can also be found in the above description of S603, which will not be repeated here.

[0383] In S716-S717, the A-IoT terminal can read second and third data from the storage area. Optionally, the A-IoTMF network element indicates the address of the storage area, such as a first address, or a second and third address, as in the N2 message carrying S711, sent by the reader to the A-IoT terminal, or sent to the A-IoT terminal via a read command, so that the A-IoT terminal can read the second and third data from the storage area according to the received address. For details, please refer to the relevant introduction of the first, second, and third addresses above, which will not be repeated here. Alternatively, the A-IoTMF network element may not indicate an address, and the A-IoT terminal may know the location of the data storage in advance (e.g., according to protocol pre-definition or pre-configuration).

[0384] It is understandable that the first data segmentation can also include the fourth data, fifth data, etc., and the principle is similar, which can be referred to for understanding, and will not be elaborated further. In addition, when the A-IoTMF network element sends the first data in segments, after the reader forwards the UL NAS message #1 in S715 to A-IoTMF, it needs to wait for network instructions, such as after S716-S717. If the A-IoTMF network element has received the first data, the A-IoTMF network element can instruct the reader to perform operations for other terminals.

[0385] S718, the A-IoTMF network element sends the first data to the AF.

[0386] The A-IoTMF network element can determine that data transmission is complete. If the sum of the lengths of the received segmented data is the first length, the A-IoTMF network element will aggregate the received segmented data to obtain the first data and send the first data to the AF (e.g., via NEF). For details, please refer to the relevant introduction of S603 above, which will not be repeated here.

[0387] Figure 8 Flowchart of the communication method provided in the embodiments of this application Figure 8 .like Figure 9 As shown, the process involves AF (such as the service requester), NEF network element, UDM / UDR network element (such as the second core network element), A-IoTMF network element (such as the first core network element), reader (such as access network equipment or terminal equipment that supports reader function), and A-IoT terminal.

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

[0389] S800, UDM / UDR network element pre-configured length threshold.

[0390] S801, AF sends a service request to the NEF network element.

[0391] S802, the NEF network element sends a service request to the A-IoTMF network element.

[0392] The descriptions of S800-S802 can be referenced from the above descriptions of S700-S702, and will not be repeated here.

[0393] S803, the A-IoTMF network element sends an N2 message to the reader.

[0394] In S803, the N2 message may include a business request. For example, for a write scenario / write operation, the business request (such as business request #2 above) may include at least one of the following: first data, the identifier of the business requester, the business type (write operation), the device identifier (specifically, it may be a device identifier prefix), the data length, the first address, or the length threshold. For details, please refer to the relevant introduction of business request #2 above, which will not be repeated here. For a read scenario / read operation, the business request (such as business request #4 above) may include at least one of the following: first data, the identifier of the business requester, the business type (read operation), the device identifier, the data length, the first address, or the length threshold. For details, please refer to the relevant introduction of business request #4 above, which will not be repeated here.

[0395] S804, the reader determines whether the first data needs to be transmitted in segments.

[0396] The reader can determine the first length, such as by determining the first length based on the first address or first data in the service request, or by obtaining the first length from the UDM / UDR network element. The reader can determine whether the first data needs to be transmitted in segments based on whether the first length exceeds a length threshold, such as whether to send the first data in segments or receive the first data in segments. This corresponds to the first mode and the second mode mentioned above. For details, please refer to the relevant introductions to the first and second modes, which will not be elaborated upon here.

[0397] Alternatively, whether the first data needs to be transmitted in segments can still be determined by the A-IoTMF network element, indicating whether the reader should use the first mode or the second mode, such as through the N2 message of S803.

[0398] It is understandable that, for write scenarios / write operations, if the first data does not need to be sent in segments, then S804a-S805 are executed; if the first data needs to be sent in segments, then S806a-S808 are executed. For read scenarios / read operations, if the first data does not need to be received or sent, then S809a-S812 are executed; if the first data needs to be received in segments, then S813a-S817 are executed.

[0399] S804a, the reader sends a selection message or a paging message.

[0400] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0401] S804b, A-IoT terminals perform random access.

[0402] A-IoT terminals can perform random access based on selection messages or paging messages.

[0403] During the random access process, the A-IoT terminal can report its complete device identifier, such as the identifier assigned by the EPC or operator. The A-IoTMF network element obtains the complete device identifier, confirms that the A-IoT terminal has successfully accessed the network, and continues to execute S805.

[0404] S805, the reader sends an RRC message to the A-IoT terminal.

[0405] In S805, RRC messages can include the first data, i.e., without segmentation.

[0406] The A-IoT terminal can write the received first data into the storage area. Optionally, the RRC message can also carry an address indicating the storage area, such as a first address. The A-IoT terminal can write the first data into the corresponding storage area based on the received first address. For details, please refer to the above introduction on the first address, which will not be repeated here. Alternatively, the RRC message can also omit the first address, allowing the A-IoT terminal to decide where to write the received data, or to write it to a default location (such as a predefined or pre-configured location). It can be understood that when the A-IoTMF network element does not send the first data in segments, the reader can, after forwarding the RRC message in S805 to the A-IoT terminal, perform operations for other terminals by default, such as sending other terminal selection messages or paging messages.

[0407] S806a, the reader sends a selection message or a paging message.

[0408] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0409] S806b, A-IoT terminals perform random access.

[0410] A-IoT terminals can perform random access based on selection messages or paging messages.

[0411] During the random access process, the A-IoT terminal can report its complete device identifier, such as the identifier assigned by the EPC or operator. The A-IoTMF network element obtains the complete device identifier, confirms that the A-IoT terminal has successfully accessed the network, and continues to execute S807.

[0412] S807, the reader sends RRC message #1 to the A-IoT terminal.

[0413] RRC message #1 may include second data. The second data is a segment of the first data, i.e., it is sent in segments. For details, please refer to the relevant introduction of the second data above, which will not be repeated here.

[0414] S808, the reader sends RRC message #2 to the A-IoT terminal.

[0415] RRC message #2 may include third data. The third data is another segment of the first data; for details, please refer to the above introduction on third data, which will not be repeated here.

[0416] In S807-S808, the A-IoT terminal can write the received second and third data into the storage area. Optionally, the aforementioned RRC message can also carry an address indicating the storage area. For example, RRC message #1 carries a first address, or RRC message #1 carries a second address, and RRC message #2 carries a third address, i.e., the segmented addresses. The A-IoT terminal can write the second and third data into the corresponding storage area according to the received address. For details, please refer to the relevant introductions to the first, second, and third addresses above, which will not be repeated here. Alternatively, the aforementioned RRC message may not carry an address indicating the storage area, and the A-IoT terminal can decide where to write the received data.

[0417] It is understandable that the first data segmentation can also include the fourth data, fifth data, etc., and the principle is similar, which can be referred to for understanding, and will not be elaborated further. In addition, when the reader sends the first data in segments, after sending the RRC message #1 in S808 to the A-IoT terminal, the reader cannot continue to perform operations on other terminals. It needs to continue to perform operations on other terminals after sending the first data, such as S807-S808.

[0418] S809a, the reader sends a selection message or a paging message.

[0419] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0420] S809b, A-IoT terminals perform random access.

[0421] A-IoT terminals can perform random access based on selection messages or paging messages.

[0422] S810, the A-IoT terminal sends an RRC message to the reader.

[0423] In S812, the RRC message may include initial data, i.e., without segmentation. Optionally, the RRC message may also include the complete device identifier of the A-IoT terminal, such as EPC, or the RRC message may be sent after the A-IoT terminal reports the EPC.

[0424] The A-IoT terminal can read the first data from the storage area. Optionally, the reader indicates the address of the storage area, such as a first address. This can be done through a separate message, such as a read command, sent to the A-IoT terminal, so that the A-IoT terminal can read the first data from the storage area based on the first address. For details on the first address, please refer to the above description; it will not be repeated here. Alternatively, the reader may not indicate the first address, and the A-IoT terminal may know the data storage location in advance (e.g., through protocol pre-definition or pre-configuration). It can be understood that if the reader does not receive the first data in segments, after receiving the data in S810, the reader will by default perform operations for other terminals, such as sending other terminal selection messages or paging messages.

[0425] S811, the reader sends the first data to the A-IoTMF network element.

[0426] S812, the A-IoTMF network element sends the first data to the AF.

[0427] The reader can determine that data transmission is complete, such as when the sum of the lengths of the received data is equal to the first length, i.e., the first data has been received, and then sends the first data to the A-IoTMF network element. The AF can send the first data to the AF (e.g., via NEF), as detailed in the relevant introduction of S603 above, which will not be repeated here.

[0428] S813a, the reader sends a selection message or a paging message.

[0429] Select a message or paging message that carries at least one of the following: device identifier prefix, or service type (write operation).

[0430] S813b, A-IoT terminals perform random access.

[0431] A-IoT terminals can perform random access based on selection messages or paging messages.

[0432] S814, the A-IoT terminal sends RRC message #1 to the reader.

[0433] RRC message #1 may include second data. The second data is a segment of the first data, i.e., it is sent in segments. For details, please refer to the relevant introduction of the second data above, which will not be repeated here. Optionally, RRC message #1 may also include the complete device identifier of the A-IoT terminal, such as EPC, or RRC message #1 may also be sent after the A-IoT terminal reports the EPC.

[0434] S815, the A-IoT terminal sends RRC message #2 to the reader.

[0435] RRC message #2 may include third data. The third data is another segment of the first data; details can be found in the above description of the third data, which will not be repeated here. RRC message #2 can be sent by default by the A-IoT terminal, such as sending RRC message #1 and then immediately continuing with RRC message #2. Alternatively, it can be sent according to the reader's instructions. For example, if the reader receives RRC message #1 and instructs the A-IoT terminal to continue transmission, the A-IoT terminal will send RRC message #2 accordingly. Details can also be found in the above description of S603, which will not be repeated here.

[0436] In S814-S815, the A-IoT terminal can read second and third data from the storage area. Optionally, the reader can indicate the address of the storage area to the terminal, such as a first address, or a second and third address. Specifically, this can be done by sending a read command to the A-IoT terminal, so that the A-IoT terminal can read the second and third data from the storage area according to the received address. For details on the first, second, and third addresses, please refer to the relevant introductions above, which will not be repeated here. Alternatively, the reader may not indicate an address, and the A-IoT terminal may know the location of the data storage in advance (e.g., through protocol predefinition or preconfiguration).

[0437] It is understandable that the first data segmentation can also include the fourth data, fifth data, etc., and the principle is similar, which can be referred to for understanding, and will not be elaborated further. In addition, when the reader receives the first data in segments, after receiving the RRC message #1 in S814 to the A-IoT terminal, the reader cannot continue to perform operations on other terminals. It needs to continue to perform operations on other terminals after receiving the first data, such as S814-S815.

[0438] S816, the reader sends the first data to the A-IoTMF network element.

[0439] S817, the A-IoTMF network element sends the first data to the AF.

[0440] The reader can determine that data transmission is complete, such as when the sum of the lengths of the received segmented data is equal to the first length. The reader then aggregates the received segmented data to obtain the first data and sends the first data to the A-IoTMF network element. The A-IoTMF network element can send the first data to the AF (e.g., via NEF), as detailed in the relevant description of S603 above, which will not be repeated here. Figure 9 Flowchart of the communication method provided in the embodiments of this application Figure 9 .like Figure 10 As shown, the process involves AF (such as the service requester), NEF network element, UDM / UDR network element (such as the second core network element), A-IoTMF network element (such as the first core network element), reader (such as access network equipment or terminal equipment that supports reader function), and A-IoT terminal.

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

[0442] S900a, UDM / UDR network element pre-configured length threshold.

[0443] The S900a can also refer to the relevant introduction of the S700 mentioned above, and will not be repeated here.

[0444] S900b, A-IoT terminal pre-configured length threshold.

[0445] The length threshold can also be referenced in the above introduction. S900b is optional. For example, the A-IoT terminal can also obtain the length threshold through the following S904.

[0446] S901, AF sends a service request to the NEF network element.

[0447] S902, the NEF network element sends a service request to the A-IoTMF network element.

[0448] For S901-S902, the relevant introductions of S701-S702 mentioned above can be referenced, and will not be repeated here.

[0449] S903, the A-IoTMF network element sends an N2 message to the reader.

[0450] In S903, N2 messages may include service requests. For example, for a read scenario / read operation, a service request (such as the service request #4 mentioned above) may include at least one of the following: first data, the identifier of the service requester, the service type (read operation), the device identifier, the data length, and the first address or length threshold. For details, please refer to the relevant introduction of the service request #4 mentioned above, which will not be repeated here.

[0451] S904a, the reader sends a selection message or a paging message.

[0452] The selected message or paging message carries at least one of the following: device identifier prefix, or service type (write operation), and length threshold. This length threshold can be determined by the reader based on the link status, or obtained from the UDM / UDR network element / A-IoTMF network element.

[0453] S904b, A-IoT terminals perform random access.

[0454] A-IoT terminals can perform random access based on selection messages or paging messages.

[0455] S905, the A-IoT terminal determines whether the first data needs to be transmitted in segments.

[0456] The A-IoT terminal can receive a read command from the reader. This read command can be carried in the service request and transmitted to the A-IoT terminal along with the N2 message and the selection message or paging message during the random access process, or it can be sent to the A-IoT terminal after successful random access. Based on the read command, the A-IoT terminal can retrieve the first data from the storage area corresponding to the first address and determine the first length. The A-IoT terminal can determine whether the first data needs to be transmitted in segments based on whether the first length exceeds a length threshold, such as whether to send or receive the first data in segments. This corresponds to the first mode and the second mode mentioned above. For details on the first mode and the second mode, please refer to the relevant descriptions; they will not be repeated here.

[0457] If the A-IoT terminal does not need to send the first data in segments, then execute S906-S909 below. If the A-IoT terminal needs to send the first data in segments, then execute S909-S908 below.

[0458] S906, the A-IoT terminal sends an RRC message to the reader.

[0459] In S906, the RRC message may include the first data, i.e., without segmentation. Optionally, if the read command is sent to the A-IoT terminal during random access, the RRC message may also include the complete device identifier of the A-IoT terminal, such as EPC, i.e., data fast transmission. Alternatively, if the read command is sent to the A-IoT terminal after successful random access, the RRC message may also be sent after the A-IoT terminal reports the EPC.

[0460] S907, the reader sends the first data to the A-IoTMF network element.

[0461] S908, the A-IoTMF network element sends the first data to the AF.

[0462] The reader can determine that data transmission is complete, such as when the sum of the lengths of the received data is equal to the first length, i.e., the first data has been received, and then sends the first data to the A-IoTMF network element. The AF can send the first data to the AF (e.g., via NEF), as detailed in the relevant introduction of S603 above, which will not be repeated here.

[0463] S909, the A-IoT terminal sends RRC message #1 to the reader.

[0464] RRC message #1 may include second data. The second data is a segment of the first data, i.e., it is sent in segments. For details, please refer to the relevant introduction of the second data above, which will not be repeated here. Optionally, similar to S906, RRC message #1 may also include the complete device identifier of the A-IoT terminal, such as EPC, or RRC message #1 may also be sent after the A-IoT terminal reports the EPC.

[0465] S910, the A-IoT terminal sends RRC message #2 to the reader.

[0466] RRC message #2 may include third data. The third data is another segment of the first data; details can be found in the above description of the third data, which will not be repeated here. RRC message #2 can be sent by default by the A-IoT terminal, such as sending RRC message #1 and then immediately continuing with RRC message #2. Alternatively, it can be sent according to the reader's instructions. For example, if the reader receives RRC message #1 and instructs the A-IoT terminal to continue transmission, the A-IoT terminal will send RRC message #2 accordingly. Details can also be found in the above description of S603, which will not be repeated here.

[0467] Optionally, after sending RRC#1, the A-IoT terminal can first send an indication to the reader, such as the fourth indication information mentioned above, to indicate that the data transmission has not yet ended, and then send RRC#2. Or, the A-IoT terminal can also carry an indication in the RRC message containing the last segment of data to indicate that the data transmission is complete. For details, please refer to the relevant introduction of S603 above, which will not be repeated here.

[0468] It's understandable that the first data segment can also include a fourth data segment, a fifth data segment, etc., and the principle is similar, so it can be understood without further explanation. Furthermore, the reader needs to determine the completion of the first data transmission based on the instructions of the A-IoT terminal, or independently, before continuing to perform operations on other terminals.

[0469] S911, the reader sends the first data to the A-IoTMF network element.

[0470] S912, the A-IoTMF network element sends the first data to the AF.

[0471] The reader can determine that data transmission is complete, such as when the sum of the lengths of the received segmented data is equal to the first length. The reader then aggregates the received segmented data to obtain the first data and sends the first data to the A-IoTMF network element. The A-IoTMF network element can send the first data to the AF (e.g., via NEF), as detailed in the relevant description of S603 above, which will not be repeated here.

[0472] Figure 10 This is a schematic diagram of the structure of the communication device provided in the embodiments of this application. Figure 10 For example, such as Figures 6-9 As shown, the communication device 1000 includes a transceiver module 1002 and a processing module 1001. For ease of explanation, Figures 6-9 Only the main components of the communication device are shown.

[0473] The communication device 1000 can be applied to the above. Figures 6-9 The communication method is used to implement the corresponding functions. For example, the transceiver module 1002 can be used to implement the above. Figure 10 The sending and receiving functions in the communication method can be implemented by the processing module 1001. Figure 10 The communication methods include functions other than sending and receiving.

[0474] Optionally, the transceiver module 1002 may include a transmitting module ( Figure 10 (not shown in the image) and receiving module ( Figures 5-8 (Not shown in the diagram). The transmitting module implements the transmitting function of the communication device 1000, and the receiving module implements the receiving function of the communication device 1000.

[0475] Optionally, the communication device 1000 may also include a storage module. Figure 11 (Not shown in the image), the storage module stores programs or instructions. When the processing module 1001 executes the program or instructions, the communication device 1000 can perform the aforementioned... Figure 2 The functions in the method shown.

[0476] It is understood that the communication device 1000 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.

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

[0478] Figure 11 Schematic diagram of the communication device provided in the embodiments of this application Figure 11For example, the communication device can be a terminal, or a chip (system) or other component or assembly that can be set in the terminal. Figures 6-9 As shown, the communication device 1100 may include a processor 1101. Optionally, the communication device 1100 may also include a memory 1102 and / or a transceiver 1103. The processor 1101 is coupled to the memory 1102 and the transceiver 1103, for example, they can be connected via a communication bus.

[0479] The following is combined with Figure 11 A detailed description of each component of the communication device 1100 is provided below:

[0480] The processor 1101 is the control center of the communication device 1100. It can be a single processor or a collective term for multiple processing elements. For example, the processor 1101 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).

[0481] Optionally, the processor 1101 can perform various functions of the communication device 1100 by running or executing software programs stored in the memory 1102 and calling data stored in the memory 1102, such as performing the above-mentioned functions. Figure 11 The communication method shown.

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

[0483] In a specific implementation, as one example, the communication device 1100 may also include multiple processors, for example... Figure 11 The processors 1101 and 1104 shown are illustrated. 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).

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

[0485] Optionally, the memory 1102 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 1102 may be integrated with the processor 1101 or may exist independently, and may be connected via the interface circuit of the communication device 1100. Figure 11 (Not shown in the image) is coupled to processor 1101, and this embodiment of the application does not specifically limit this.

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

[0487] Optionally, transceiver 1103 may include a receiver and a transmitter. Figure 11 (Not shown separately). The receiver is used to implement the receiving function, and the transmitter is used to implement the transmitting function.

[0488] Optionally, the transceiver 1103 can be integrated with the processor 1101, or it can exist independently and be connected via the interface circuit of the communication device 1100. ​ (Not shown in the image) is coupled to processor 1101, and this embodiment of the application does not specifically limit this.

[0489] Understandable, ​The structure of the communication device 1100 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.

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

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

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

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

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

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

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

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

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

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

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

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

[0502] Those skilled in the art will clearly 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.

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

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

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

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

[0507] 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 device, the method includes: Determine a first length, where the first length is the length of the first data; Based on the first length, determine whether to transmit the first data via a first mode or a second mode; If it is determined that the first data will be transmitted via the first mode, the first data will be transmitted via a first message; or... If it is determined that the first data is transmitted via the second mode, the first data is transmitted via the second message and the third message.

2. The method according to claim 1, characterized in that, Determining the first length includes: Receive the first data; The first length is determined based on the first data.

3. The method according to claim 2, characterized in that, The receiving of the first data includes: A first service request is received, the first service request including the first data, and the first service request is used to request that the first data be written to the second device.

4. The method according to claim 2 or 3, characterized in that, If it is determined that the first data will be transmitted via the first mode, the first data will be transmitted via a first message, including: If it is determined that the first data is to be sent via the first mode, the first message is sent to the second device, the first message including the first data.

5. The method according to claim 2 or 3, characterized in that, If it is determined that the first data is to be transmitted via the second mode, the first data is transmitted via a second message and a third message, including: If it is determined that the first data is sent via the second mode, the second message and the third message are sent to the second device, the second message including the second data, the third message including the third data, and the first data including the second data and the third data.

6. The method according to any one of claims 2-5, characterized in that, The method further includes: Based on the first data, the second data and the third data are determined.

7. The method according to any one of claims 2-6, characterized in that, The method further includes: Send a first address to the second device, the first address indicating the storage area where the first data is stored; or... Send a second address and a third address to the second device, the second address indicating the area where the second data is stored, and the third address indicating the area where the third data is stored.

8. The method according to claim 1, characterized in that, Determining the first length includes: The first length is obtained from the third device; or, Receive a first address, the first address indicating the area where the first data is stored; The first length is determined based on the first address.

9. The method according to claim 8, characterized in that, Obtaining the first length from the third device includes: Receive a second service request, the second service request being used to request to read the first data from the second device; The first length is obtained from the third device according to the second service request.

10. The method according to claim 9, characterized in that, The receiving first address includes: A second service request is received, the second service request including the first address, the second service request being used to request reading the first data from the second device.

11. The method according to any one of claims 8-10, characterized in that, If it is determined that the first data will be transmitted via the first mode, the first data will be transmitted via a first message, including: If it is determined that the first data is received via the first mode, the first message from the second device is received, the first message including the first data.

12. The method according to any one of claims 8-10, characterized in that, If it is determined that the first data is to be transmitted via the second mode, the first data is transmitted via a second message and a third message, including: If it is determined that the first data is received through the second mode, the second message and the third message are received from the second device, the second message including the second data, the third message including the third data, and the first data including the second data and the third data.

13. The method according to claim 11 or 12, characterized in that, After receiving the second message and the first message of the third message, the method further includes: A first instruction message is sent to the second device, which instructs the second device to continue sending data.

14. The method according to any one of claims 8-13, characterized in that, The method further includes: The first data is determined based on the second data and the third data.

15. The method according to any one of claims 8-14, characterized in that, The method further includes: Send the first address to the second device.

16. The method according to any one of claims 2-15, characterized in that, The first device is a core network element, and the second device is a terminal device. When it is determined that the first data is transmitted through the first mode, the access network device is used to forward the first message. The method further includes: Send a second indication message to the access network device, the second indication message indicating that the access network device can continue to perform operations on other terminals after forwarding the first message; or, The first device is the access network equipment, the second device is a terminal device, and the method further includes: After sending the first message, continue performing operations on other terminals.

17. The method according to any one of claims 2-15, characterized in that, The first device is a core network element, and the second device is a terminal device. When it is determined that the first data is transmitted via the second mode, the access network device is used to forward the second message and the third message. The method further includes: Send a third instruction message to the access network device, the third instruction message instructing the access network device to perform operations on other terminals according to the instructions of the core network element after forwarding the second message and the first message in the third message; or, The first device is the access network equipment, the second device is a terminal device, and the method further includes: After sending the second message and the first message of the third message, operations for other terminals need to be performed according to the instructions of the core network.

18. The method according to claim 7, characterized in that, The receiving first address includes: A command is received, the command including the first address, the command instructing the reading of the first data from the first device.

19. The method according to claim 18, characterized in that, If it is determined that the first data will be transmitted via the first mode, the first data will be transmitted via a first message, including: If it is determined that the first data is to be sent via the first mode, the first message is sent to the second device, the first message including the first data.

20. The method according to claim 19, characterized in that, If it is determined that the first data is to be transmitted via the second mode, the first data is transmitted via a second message and a third message, including: If it is determined that the first data is sent via the second mode, the second message and the third message are sent to the second device, the second message including the second data, the third message including the third data, and the first data including the second data and the third data.

21. The method according to claim 20, characterized in that, After sending the second message and the first message of the third message to the second device, the method further includes: A fourth instruction message is sent to the second device, which instructs the first device to continue sending data.

22. The method according to any one of claims 18-21, characterized in that, The method further includes: Based on the first data, the second data and the third data are determined.

23. The method according to any one of claims 18-22, characterized in that, The method further includes: Based on the first address, the first data is obtained from the first region.

24. The method according to any one of claims 18-23, characterized in that, The method further includes: The first length is sent to the second device.

25. The method according to any one of claims 1-24, characterized in that: If it is determined that the first data is transmitted via the first mode, then the first message is the first message used to transmit service data; or... If it is determined that the first data is transmitted through the second mode, the first message in the second message or the third message is the first message used to transmit service data.

26. The method according to any one of claims 1-25, characterized in that, The step of determining whether to transmit the first data via a first mode or a second mode based on the first length includes: If the first length is less than or equal to the length threshold, then it is determined that the first data will be transmitted via the first mode; or, If the first length is greater than the length threshold, then it is determined that the first data will be transmitted through the second mode.

27. The method according to claim 26, characterized in that, The method further includes: The length threshold is obtained from a third device, or the length threshold is determined based on the quality of the link used to carry the first data.

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

29. The communication device according to claim 26, characterized in that, The communication device includes a chip.

30. 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 as described in any one of claims 1-27 to be implemented.

31. 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-27 to be implemented.

Images