Method, apparatus and internet of things device for data communication

Abstract

The application discloses a data communication method, device and Internet of Things equipment, and belongs to the technical field of Internet of Things. The method is applied to a communication module of the Internet of Things equipment, the Internet of Things equipment comprises the communication module and a user identity identification integrated card, and the method comprises the following steps: generating a self-defined APDU control message of the user identity identification integrated card, the self-defined APDU control message carries a self-defined control parameter, and the self-defined control parameter is used for instructing a control chip to execute corresponding operation; and the self-defined APDU control message is sent to the control chip. The data communication method provided in the application embodiment realizes unified control of the user identity identification integrated card in different Internet of Things equipment by using the APDU control message which is commonly used in the Internet of Things equipment and carrying specific control information in the control parameter of the APDU control message.

Description

[0001] This application is a divisional application of Chinese patent application No. 202110347162.2, filed on March 31, 2021, entitled "Method, Apparatus and Internet of Things Device for Data Communication". Technical Field

[0002] This application relates to the field of Internet of Things (IoT) device technology, specifically to data communication methods, apparatus, and IoT devices. Background Technology

[0003] Currently, the signal integrity rate of single-operator base stations in China is generally only 99.75%. Coupled with reasons such as fiber optic cable being cut or core network failures, the reliability of a single-operator network at the same site will be even lower, failing to meet the high reliability required for IoT applications.

[0004] To address the aforementioned issues, a user identification integrated card (SIM card) has been provided in related technologies. This SIM card can be applied in IoT devices. The SIM card integrates a control chip and multiple different types of SIM cards (Subscriber Identification Modules). The control chip is used to switch the current SIM card in the IoT device. Thus, when the communication status of the current SIM card is abnormal, the control chip can switch to other SIM cards with normal communication status, thereby achieving network optimization and network backup, and solving the high reliability requirements of IoT applications.

[0005] However, IoT devices are diverse and their hardware and software vary greatly. A key issue is how to achieve unified control of user identification integrated cards across different IoT devices. Summary of the Invention

[0006] This application provides a data communication method, apparatus, and IoT device, enabling unified control over the switching of user identification integrated cards across different IoT devices. The technical solution is as follows:

[0007] On one hand, a data communication method is provided, which is applied in the communication module of an Internet of Things (IoT) device. The IoT device includes the communication module and a User Identity Authentication (UISA) card. The UISA card includes a control chip and multiple User Identity Authentication (UISA) cards. The method includes:

[0008] Generate a custom APDU (Application Protocol Data Unit) control message for the user identification integrated card. The custom APDU control message carries custom control parameters, which are used to instruct the control chip to perform the corresponding operation.

[0009] Send the custom APDU control message to the control chip.

[0010] On the one hand, another data communication method is provided, which is applied to the control chip of a user identification integrated card in an Internet of Things (IoT) device. The IoT device includes a communication module and the user identification integrated card, which includes the control chip and multiple user identification cards. The method includes:

[0011] Receive APDU control messages sent by the communication module;

[0012] When it is determined that the control parameters carried by the APDU control message belong to a custom control parameter set, the APDU control message is intercepted and the operation corresponding to the control parameters is executed.

[0013] On one hand, a data communication device is provided, the device being located in the communication module of an Internet of Things (IoT) device, the IoT device including the communication module and a User Identity Authentication (UISA) card, the UISA card including a control chip and multiple UISA cards, the device comprising:

[0014] The generation module is used to generate a custom APDU control message for the user identification integrated card. The custom APDU control message carries custom control parameters, which are used to instruct the control chip to perform corresponding operations.

[0015] The sending module is used to send the custom APDU control message to the control chip.

[0016] In one possible implementation, the custom control parameters are used to instruct the control chip to switch the current user identification card of the IoT device; or,

[0017] The custom control parameters are used to instruct the control chip to perform a priority selection operation on the user identity card that is activated each time the IoT device is powered on.

[0018] In one possible implementation, the custom control parameters include custom control type parameters and custom control specific parameters. The custom control type parameters are used to indicate the type of operation performed by the control chip, and the custom control specific parameters are used to indicate the user identification card corresponding to the operation performed by the control chip.

[0019] In one possible implementation, the generation module is configured to:

[0020] Generate custom control instructions for the user identification integrated card. The custom control instructions include a standard control type part and a custom control parameter part. The standard control type part conforms to the 3GPP (3rd Generation Partnership Project) protocol standard, and the custom control parameter part carries the custom control parameters.

[0021] The custom control command is converted into the custom APDU control message.

[0022] In one possible implementation, the generation module is configured to:

[0023] The device receives custom control commands sent by the MCU (Micro Control Unit) in the IoT device. The custom control commands include a standard control type part and a custom control parameter part. The standard control type part conforms to the 3GPP protocol standard, and the custom control parameter part carries the custom control parameters.

[0024] The custom control command is converted into the custom APDU control message.

[0025] In one possible implementation, the custom control command belongs to one or more of the CSIM, CLCK, and CSCA commands in AT commands.

[0026] On the one hand, another data communication device is provided, the device being located in the control chip of the user identification integrated card of an Internet of Things (IoT) device, the IoT device including a communication module and the user identification integrated card, the user identification integrated card including the control chip and multiple user identification cards, the device comprising:

[0027] The receiving module is used to receive APDU control messages sent by the communication module;

[0028] The execution module is used to intercept the APDU control message and execute the operation corresponding to the control parameters when it is determined that the control parameters carried by the APDU control message belong to a custom control parameter set.

[0029] In one possible implementation, the execution module is configured to:

[0030] Perform a switching operation on the current user identification card of the IoT device; or,

[0031] Priority selection is performed on the user identification card activated when the IoT device is powered on.

[0032] In one possible implementation, the device further includes a transmitting module for:

[0033] When it is determined that the control parameters carried by the APDU control message do not belong to the custom control parameter set, the APDU control message is sent to the current user identity card among the multiple user identity cards.

[0034] In one possible implementation, the APDU control message is an ICCID (Integrated Circuit Card Identity) query message;

[0035] The receiving module is also used to receive the ICCID sent by the current user identification card;

[0036] The execution module is further configured to modify the target feature bit of the ICCID, and the modified ICCID is used to indicate that the current user identification card is integrated into the user identification integrated card;

[0037] The sending module is also used to send the modified ICCID to the communication module.

[0038] On the one hand, an Internet of Things (IoT) device is provided, the IoT device including a communication module and a user identity recognition integrated card, the user identity recognition integrated card including a control chip and multiple user identity recognition cards;

[0039] The communication module is used to generate a custom APDU control message for the user identification integrated card. The custom APDU control message carries custom control parameters, which are used to instruct the control chip to perform corresponding operations; and to send the custom APDU control message to the control chip.

[0040] The control chip is used to receive APDU control messages sent by the communication module; when it is determined that the control parameters carried by the APDU control message belong to a custom control parameter set, the chip intercepts the APDU control message and executes the operation corresponding to the control parameters.

[0041] The custom control parameters belong to the custom control parameter set.

[0042] On one hand, a computer-readable storage medium is provided that stores at least one computer program, which is loaded and executed by a processor to implement a method of data communication as described in any of the possible implementations above.

[0043] On one hand, a computer program product or computer program is provided, the computer program product or computer program comprising one or more lines of program code stored in a computer-readable storage medium. One or more processors of an Internet of Things (IoT) device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the IoT device to perform the data communication method of any of the above possible embodiments.

[0044] The beneficial effects of the technical solutions provided in this application include at least the following:

[0045] The data communication method provided in this application carries specific control information in the control parameters of a custom APDU control message, and uses the custom APDU control message to control the User Identity Module (UIM). Since the APDU format control message conforms to the internal communication mechanisms of various IoT devices, the custom APDU control message can be transmitted normally in various IoT devices without requiring modifications to standard communication modules and UIMs. This method achieves unified control over UIM switching across different IoT devices. Attached Figure Description

[0046] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0047] Figure 1 This is a schematic diagram of the structure of an Internet of Things (IoT) device provided in an embodiment of this application;

[0048] Figure 2 This is a flowchart illustrating a data communication method provided in an embodiment of this application;

[0049] Figure 3 This is an interactive schematic diagram of a data communication method provided in an embodiment of this application;

[0050] Figure 4This is an interactive schematic diagram of a data communication method provided in an embodiment of this application;

[0051] Figure 5 This is an interactive schematic diagram of a data communication method provided in an embodiment of this application;

[0052] Figure 6 This is a flowchart illustrating a data communication method provided in an embodiment of this application;

[0053] Figure 7 This is an interactive schematic diagram of a data communication method provided in an embodiment of this application;

[0054] Figure 8 This is an interactive schematic diagram of a data communication method provided in an embodiment of this application;

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

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

[0057] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0058] This application relates to the Internet of Things (IoT) technology field within the cloud technology field. Therefore, before introducing the embodiments of this application, some basic concepts in the cloud technology field will be introduced first, which will be described below.

[0059] Cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. It encompasses network technologies, information technologies, integration technologies, management platform technologies, and application technologies based on cloud computing business models. These technologies can form resource pools, allowing for on-demand, flexible, and convenient use. Cloud computing technology will become a crucial support in the cloud technology field. Backend services of technical network systems require substantial computing and storage resources, such as those for video websites, image websites, and many portal websites. With the rapid development and application of the internet industry, every item may have its own identification mark in the future, requiring data to be transmitted to backend systems for logical processing. Data at different levels will be processed separately, and various industry data will require robust system support, all of which can be achieved through cloud computing.

[0060] The Internet of Things (IoT) refers to the use of various information sensors, RFID technology, GPS, infrared sensors, laser scanners, and other devices and technologies to collect real-time data on any object or process that needs to be observed, connected, or interacted with. This data includes information on sound, light, heat, electricity, mechanics, chemistry, biology, location, and other parameters. Through various possible network access methods, it achieves ubiquitous connectivity between things and between things and people, enabling intelligent perception, identification, and management of objects and processes. The IoT is an information carrier based on the internet and traditional telecommunications networks, enabling all independently addressable ordinary physical objects to form an interconnected network.

[0061] Cloud IoT aims to connect the information sensed and commands received by traditional IoT sensing devices to the Internet, truly achieving networking. It also enables massive data storage and computation through cloud computing technology. Due to the nature of IoT, which involves connecting things to each other and sensing the current operating status of each "object" in real time, a large amount of data information is generated in this process. How to aggregate this information and how to sift out useful information from the massive amount of data to support decision-making for future development have become key issues affecting the development of IoT. As a result, IoT cloud based on cloud computing and cloud storage technology has become a powerful support for IoT technology and applications.

[0062] Figure 1 This is a schematic diagram of the structure of an Internet of Things (IoT) device provided in an embodiment of this application. See also... Figure 1 The IoT device includes an MCU (Micro Control Unit) 100, a communication module 200, and a user identity integrated card 300. The user identity integrated card 300 includes a control chip 301, a first user identity card 302, a second user identity card 303, and a third user identity card 304. These three user identity cards can be user identity cards from the three major telecom operators. The micro control unit 100 is electrically connected to the communication module 200, and the communication module 200 is electrically connected to the control chip 301 in the user identity integrated card 300. The control chip 301 is electrically connected to the first user identity card 302, the second user identity card 303, and the third user identity card 304, respectively.

[0063] The microcontroller unit 100 serves as the control center for the IoT device. The communication module 200 supports 2G / 3G / 4G / 5G; it can be a stand-alone packaged communication module or a cellular network baseband form factor within an IoT SoC (System on Chip) solution. The user identity cards (UICs) in the integrated user identity card 300 can be any physical form of UIC as defined by the GSMA (Global System for Mobile Communications Assembly), including standard / micro / nano and 5×6 SMT (Surface Mount Technology) surface mount cards.

[0064] Figure 1 The IoT devices shown, thanks to the introduction of user identification integrated cards (UICs), can achieve network optimization and backup, meeting the high reliability requirements of IoT applications. At the same time, some new control mechanisms are also introduced. However, given the wide variety of IoT devices and their significant differences in hardware and software, a key issue is how to achieve unified control of UICs across these diverse devices.

[0065] Figure 2 This application provides a data communication method that can be applied to the communication module of an Internet of Things (IoT) device. The method includes:

[0066] 201. Generate custom APDU (Application Protocol Data Unit) control messages for the user identification integrated card. The custom APDU control messages carry custom control parameters, which are used to instruct the control chip to perform the corresponding operations.

[0067] The interface between the communication module and the user identification card is a 7816 interface. The 7816 interface is a smart card interface that conforms to ISO (International Organization for Standardization) / IEC (International Electrotechnical Commission) 7816-4 and can directly transmit various read and write commands between the communication module and the user identification card through APDU.

[0068] Custom APDU control messages refer to APDU control messages that are newly added due to the introduction of User Identity Module (UIM). The opposite concept is standard APDU control messages, which are APDU control messages unrelated to the introduction of UIM; these APDU control messages may have existed before the introduction of UIM.

[0069] Custom APDU control messages are received by the control chip in the user identification integrated card, while standard APDU control messages are received by the user identification card, which can exist independently or be integrated into the user identification integrated card.

[0070] Both custom APDU control messages and standard APDU control messages conform to the 7816 interface specification, thus enabling normal transmission between the communication module and the control chip. The formats of custom and standard APDU control messages are identical; the only difference lies in the control parameters they carry. Standard APDU control messages carry standard control parameters, while custom APDU control messages carry custom control parameters.

[0071] For example, a standard APDU control message used to lock a user identity card will carry the user identity card's PIN (Personal Identification Number) as a standard control parameter. Conversely, a custom APDU control message can be identical to the standard APDU control message in most parts, except for the section containing the PIN, which carries the custom control parameter. The fields in the custom APDU control message that carry the custom control parameter are the same as the fields containing the PIN in the standard APDU control message.

[0072] For example, a standard APDU control message used to modify the SMS service center number corresponding to a user's identity card will carry the SMS service center number as a control parameter. Conversely, a custom APDU control message can be identical to the standard APDU control message in all other respects, except that it carries the custom control parameter in the section containing the SMS service center number. The fields of the custom control parameter carried in the custom APDU control message are the same as the field containing the SMS service center number in the standard APDU control message.

[0073] As can be seen, the method provided in this application establishes a private communication control mechanism between the communication module and the control chip by reusing the 7816 interface between the communication module and the user identity card and modifying the standard APDU control messages, thereby realizing the control of the user identity integrated card in a unified manner on different software and hardware platforms.

[0074] In some instances, the operations indicated by custom control parameters include at least the following two:

[0075] One method is to instruct the control chip to switch the current user identification card of the IoT device, and the other is to instruct the control chip to prioritize the user identification card that is enabled each time the IoT device is powered on.

[0076] The current user identification card refers to the user identification card enabled by the IoT device.

[0077] In some instances, custom control parameters include custom control type parameters and custom control specific parameters. Custom control type parameters are used to indicate the type of operation performed by the control chip, while custom control specific parameters are used to indicate the user identification card corresponding to the operation performed by the control chip.

[0078] In some instances, the APDU control messages generated by the communication module can be converted from custom control instructions (e.g., AT commands). These custom control instructions can be generated by the communication module itself, or they can be generated by the MCU and then sent to the communication module. The following sections will describe these two scenarios respectively:

[0079] In some instances, custom control commands are generated by the communication module. The communication module first generates custom control commands for the User Identity Module (BIMM), which include a standard control type portion and a custom control parameter portion. The standard control type portion conforms to the 3GPP (3rd Generation Partnership Project) protocol standard, and the custom control parameter portion carries custom control parameters. The communication module then converts the custom control commands into custom APDU control messages.

[0080] Among them, the custom control commands conform to the 3GPP protocol standard, so they can pass the format check of the communication module and be converted into custom APDU control messages normally.

[0081] The concept opposite to custom control instructions is standard control instructions. Custom control instructions and standard control instructions can have the same format. The only difference is that custom control instructions carry custom control parameters, while standard control instructions carry standard control parameters.

[0082] For cases where the communication module generates custom control commands, such as Figure 3 As shown, an SDK (Software Development Kit) can be integrated into the communication module. The SDK serves as the control center for the User Identification Integrated Card (UIC) and is a new software development kit added for the introduction of the UIC. First, the SDK generates custom control commands, and then sends these custom control commands to the AT command processing module in the communication module. The AT command processing module then checks the format of the custom control commands. If the format check passes, the custom control commands are converted into custom APDU control messages.

[0083] The interface between the SDK and the AT command processing module is generally an AT interface. The AT interface conforms to a series of standards such as ETSI (European Telecommunications Standards Institute) TS127007 / 3GPP TS27.007, enabling the transmission of various read and write commands between the SDK and the AT command processing module through predefined AT commands. Therefore, both custom control commands and standard control commands can be AT commands.

[0084] In some embodiments, the custom control command may also be generated by the MCU and sent to the communication module. The communication module receives the custom control command sent by the MCU in the IoT device. This custom control command includes a standard control type portion and a custom control parameter portion. The standard control type portion conforms to the 3GPP protocol standard, and the custom control parameter portion carries custom control parameters. Then, the custom control command is converted into a custom APDU control message.

[0085] The generation of custom control instructions by the MCU can be divided into two categories: MCU self-generation and external device invocation of the MCU for generation. These two cases will be explained below:

[0086] like Figure 4 As shown, the MCU has an SDK installed (SDK related instructions can be found above). The SDK generates custom control commands and sends them to the communication module. After receiving the custom control commands, the communication module checks their format. If the format check passes, the custom control commands are then converted into custom APDU control messages.

[0087] For some IoT devices using closed systems, since SDKs cannot be integrated into the communication module or MCU, custom control commands can be generated by external devices calling the IoT device's private API (Application Programming Interface). For example... Figure 5 As shown, the external device sends custom control parameters to the MCU via an open API interface. The MCU generates custom control commands based on the custom control parameters and then sends them to the communication module. After receiving the custom control commands, the communication module performs a format check. If the format check passes, it converts them into custom APDU control messages.

[0088] It should be noted that the above-mentioned custom control commands can belong to AT commands. For example, they can belong to one or more of the CSIM, CLCK, and CSCA commands in AT commands.

[0089] Below, referring to Tables 1 and 2, we will introduce custom control instructions using CSIM, CLCK, and CSCA instructions as examples:

[0090] Table 1 uses the current user identification card switching command as an example to explain the custom control command. The table shows the specifications followed by the AT command and the specifications followed by the APDU control message generated after the AT command is converted.

[0091] Table 1

[0092]

[0093] (1) CSIM control commands:

[0094] The structure of the CSIM control command is: AT+CSIM = "Protocol Definition Parameters", "Custom Control Parameters".

[0095] AT+CSIM="Protocol Definition Parameters" indicates the standard control type portion of the control command, which conforms to the 3GPP protocol standard. The protocol definition parameters are all fields specified in 3GPP TS27.007; values ​​can be taken according to the protocol specifications, as long as they pass the format check of the communication module.

[0096] The custom control parameters section carries custom control parameters, which include at least two parts: a custom control type parameter and a custom control specific parameter. The custom control type parameter indicates the type of operation performed by the control chip, while the custom control specific parameter indicates the user identification card corresponding to the operation performed by the control chip. Here, the custom control parameter indicates which user identification card in the integrated user identification card will be switched to.

[0097] For example, in AT+CSIM="8", "FFFF8802", 8 is a parameter required by the 3GPP protocol standard, indicating that the control parameters have a total of 8 bits. The FFFF in the custom control parameter section has no practical meaning and is a reserved bit. 88 is a custom control type parameter, indicating that this control command is a current user identity card (BIC) switching command. 01, 02, and 03 are custom control specific parameters, representing the first, second, and third user identity cards, respectively. For example, 8801 indicates switching the first user identity card to the current user identity card of the IoT device.

[0098] (2) CLCK control command:

[0099] The structure of the CLCK control command is: AT+CLCK="Protocol Definition Parameter 1", "Protocol Definition Parameter 2", "Custom Control Parameter".

[0100] AT+CLCK="Protocol Definition Parameter 1" and "Protocol Definition Parameter 2" represent the standard control type portion of the control command, which conforms to the 3GPP protocol standard. Both Protocol Definition Parameter 1 and Protocol Definition Parameter 2 are fields specified in 3GPP TS27.007, and their values ​​can be taken according to the protocol specifications, as long as they pass the communication module format check.

[0101] The custom control parameters section carries custom control parameters, which include at least two parts: a custom control type parameter and a custom control specific parameter. The custom control type parameter indicates the type of operation performed by the control chip, while the custom control specific parameter indicates the user identification card corresponding to the operation performed by the control chip. Here, the custom control parameter indicates which user identification card in the integrated user identification card will be switched to.

[0102] For example, in AT+CLCK="SC",1",8802", "SC" and "1" are fields specified in 3GPP TS27.007. In the custom control parameter section, 88 is a custom control type parameter, indicating that the control command is a current user identity card (UID) switching command. 01, 02, and 03 are custom control specific parameters, representing the first UID, second UID, and third UID, respectively. For example, 8802 indicates switching the second UID to the current UID of the IoT device.

[0103] It should be noted that the standard AT+CLCK control command is used to instruct the locking or unlocking of a user identification card. The standard AT+CLCK command is: AT+CLCK="Protocol Definition Parameter 1", "Protocol Definition Parameter 2", "PIN Code", while the custom AT+CLCK command is: AT+CLCK="Protocol Definition Parameter 1", "Protocol Definition Parameter 2", "Custom Control Parameter". Therefore, the only difference between the custom AT+CLCK command and the standard AT+CLCK command is that the "PIN Code" is replaced with the "Custom Control Parameter". The operation indicated by the standard AT+CLCK command is specified by AT+CLCK="Protocol Definition Parameter 1", "Protocol Definition Parameter 2", where "PIN Code" represents the password required for the operation. The operation indicated by the custom AT+CLCK command is specified only by the "Custom Control Parameter" section. The remaining parts of the custom AT+CLCK command, as long as they are formatted correctly, will not affect the indicated operation.

[0104] It should also be noted that since the custom AT+CLCK command differs from the standard AT+CLCK command only in the control parameters it carries, if the custom APDU control message converted from the custom AT+CLCK command is sent to the user identification card, it will be mistakenly identified by the user identification card as an unlock or lock command. However, due to the incorrect PIN code it carries, the user identification card may report an error or even be locked. Therefore, the sending of custom APDU control messages to the user identification card should be avoided.

[0105] (3) CSCA control commands:

[0106] The structure of the CSCA control command is: AT+CSCA = "Custom control parameters", "Protocol defined parameters".

[0107] AT+CSCA and "Protocol Definition Parameters" constitute the standard control type portion of the CSCA control command, which conforms to the 3GPP protocol standard. The "Protocol Definition Parameters" are fields specified in 3GPP TS27.005; values ​​can be taken according to the protocol specifications, provided they pass the communication module format check.

[0108] The custom control parameters section carries custom control parameters, which include at least two parts: a custom control type parameter and a custom control specific parameter. The custom control type parameter indicates the type of operation performed by the control chip, while the custom control specific parameter indicates the user identification card corresponding to the operation performed by the control chip. Here, the custom control parameter indicates which user identification card to switch the current user identification card to.

[0109] For example, in AT+CSCA="8802"145, 145 is a field specified in 3GPP TS27.005. In the custom control parameter section, 88 is a custom control type parameter, indicating that this control command is a current user identity card (UID) switching command. 01, 02, and 03 are custom control specific parameters, representing the first UID, second UID, and third UID, respectively. For example, 8803 indicates switching the third UID to the current UID of the IoT device.

[0110] It should be noted that the standard AT+CSCA command is used to modify the SMS service center number corresponding to the user's identification card. The standard AT+CSCA command is: AT+CSCA="SMS service center number", "protocol definition parameter", while the custom AT+CSCA command is: AT+CSCA="custom control parameter", "protocol definition parameter". Therefore, the only difference between the custom AT+CSCA command and the standard AT+CSCA command is that the "SMS service center number" is replaced with "custom control parameter". The operation indicated by the standard AT+CSCA command is given by both AT+CSCA and the "protocol definition parameter" part, where "SMS service center number" represents the SMS service center number required for the operation. The operation indicated by the custom AT+CSCA command is given only by the "custom control parameter" part. The remaining parts of the custom AT+CSCA command, as long as their format is compliant, will not affect the indicated operation.

[0111] It should also be noted that since the only difference between the custom AT+CSCA command and the standard AT+CSCA command is the control parameters they carry, if the custom APDU control message converted from the custom AT+CSCA command is sent to the user identification card, it will be mistakenly identified by the user identification card as a command to modify the SMS service center number. However, because the SMS service center number carried is incorrect, the user identification card may report an error or even be locked. Therefore, the sending of custom APDU control messages to the user identification card should be avoided.

[0112] Table 2 uses the power-on priority switching command as an example to illustrate the custom control command:

[0113] Table 2

[0114]

[0115] For details regarding CSIM control commands, CLCK control commands, and CSCA control commands, please refer to the above text; they will not be repeated here.

[0116] For example, 9902, 9902, and 9903 indicate that the first, second, and third user identification cards are switched to the user identification cards that are prioritized for use each time the IoT device is powered on, respectively. 9904 indicates that the user identification card that was used before the last power outage of the IoT device is switched to the user identification card that is prioritized for use each time the IoT device is powered on.

[0117] It should be noted that for IoT devices that do not integrate an SDK internally, but instead rely on external devices to call the IoT device's private API interfaces, some possible code examples are provided below.

[0118] like Figure 5 As shown, the MCU communicates with the communication module through an internal interface. The MCU communicates with external devices through an open interface. This open interface is typically an API (Application Programming Interface) used by the terminal manufacturer to provide functionality to external users. It usually uses a REST (Resource Representational State) API, which consists of a REST operation identifier, a resource URL, and authentication parameters, with a typical format as follows:

[0119] REST operation identifiers: GET (GET indicates a query), PUT (PUT indicates editing / modification).

[0120] Resource URL: https: / / 192.168.XX / resource1 / resource2 /

[0121] Authentication parameters: This is generally a string composed of the username, password, and device authentication key, encrypted using an encryption algorithm. This field is optional.

[0122] Since IoT devices in closed systems generally only support enabling or disabling the PIN function, once enabled, the IoT device will normally prompt for a PIN code upon power-on; otherwise, service will be denied. Essentially, this involves calling the CLCK command in AT commands, but the terminal manufacturer implements a REST encapsulation of the AT command, preventing external programs from directly calling it. This application's embodiment utilizes this function's communication mechanism, using this communication channel to control the user identification integrated card.

[0123] The terminal REST API custom parameters and host IP parameters are defined by the terminal manufacturer, and the implementation methods vary from manufacturer to manufacturer, but the main structure of the REST interface is as follows:

[0124] API query example:

[0125] curl-X GET https: / / (terminal device host IP) / (terminal custom resource path) / (operation type: Query ICCID) / (query parameters)-H(authentication parameters)

[0126] Execute API example: (curl -X PUT https: / / (terminal device host IP) / (terminal custom resource path) / (operation type: enable PIN) / (activation password) -H(authentication parameters))

[0127] When the external device in this embodiment calls the AT commands inside the IoT device, it can modify the "activation password" in the execution API to a custom control parameter. Thus, in the generated custom AT command, the part originally carrying the "activation password" is replaced with the "custom control parameter". Since it essentially calls the CLCK command within the AT commands, the relevant explanation of the generated AT command can be found in the explanation of the AT+CLCK command above. Table 3 shows several possible code examples.

[0128] Table 3

[0129]

[0130] It should also be noted that, in addition to generating custom APDU control messages, the communication module can also generate standard APDU control messages, such as ICCID query messages.

[0131] ICCID query messages can be converted from ICCID query commands, for example, from AT commands. The following is an example of an ICCID query command.

[0132] Table 4

[0133]

[0134] Table 5 shows a specific code example for cases where external devices call the AT+CCID commands inside IoT devices.

[0135] Table 5

[0136]

[0137] 202. Send a custom APDU control message to the control chip.

[0138] After generating a custom APDU control message, you can send the custom APDU control message to the control chip.

[0139] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0140] The data communication method provided in this application carries specific control information in the control parameters of a custom APDU control message, and uses the custom APDU control message to control the User Identity Module (UIM). Since the APDU format control message conforms to the internal communication mechanisms of various IoT devices, the custom APDU control message can be transmitted normally in various IoT devices without requiring modifications to standard communication modules and UIMs. This method achieves unified control of the UIM in different IoT devices.

[0141] The aforementioned data communication method achieves unified control of the User Identity Registry (UIG) card through custom APDU control messages. However, because the custom APDU control messages carry different control parameters than standard APDU control messages, the UIG user identification card cannot recognize these custom APDU control messages. If custom APDU control messages are forcibly sent to the UIG user identification card, the UIG user identification card may display abnormal errors or even be locked. Therefore, it is necessary to avoid sending custom APDU control messages to the UIG user identification card.

[0142] Figure 6 This application provides a data communication method that can be applied to the control chip of a user identification integrated card (PIN card) in an IoT device. This method avoids sending custom APDU control messages to the PIN card. The method includes:

[0143] 601. Receive APDU control messages sent by the communication module.

[0144] The APDU control messages sent by the communication module include the aforementioned custom APDU control messages and standard APDU control messages.

[0145] Please refer to the above content for explanations of custom APDU control messages and standard APDU control messages, which will not be repeated here.

[0146] 602. When it is determined that the control parameters carried by the APDU control message belong to a custom control parameter set, intercept the APDU control message and execute the operation corresponding to the control parameters.

[0147] The aforementioned custom control parameters belong to a custom control parameter set. The control parameters included in this set are used to instruct the control chip to perform corresponding operations. This custom control parameter set can be stored in the control chip.

[0148] After receiving the APDU control message, the control chip compares the control parameters carried in the APDU control message with the control parameters in the user-defined control parameter set. For example... Figure 7 As shown, when it is determined that the control parameters carried by the APDU control message belong to a set of custom control parameters, it indicates that the APDU control message is a custom APDU control message. Because custom APDU control messages cannot be recognized by the user identification card (UIC), they cannot be sent to the UIC to avoid abnormal errors or even locking of the UIC. Therefore, the control chip intercepts the custom APDU control message and executes the operation indicated by the custom control parameters carried in the custom APDU control message.

[0149] In some instances, the control chip may perform operations such as switching the current user identification card of an IoT device, or prioritizing the user identification card that is enabled when the IoT device is powered on.

[0150] For example, if the custom control parameter is 8801, where 88 is a custom control type parameter indicating a current user identification card switching operation, and 01 represents the first user identification card, then the control chip will perform the operation of switching the first user identification card to the current user identification card of the IoT device.

[0151] For another example, if the custom control parameter is 9902, where 99 is a custom control type parameter indicating the priority selection operation of the user identification card when the IoT device powers on, and 02 represents the second user identification card, then the control chip will perform the operation of switching the second user identification card to the user identification card that is prioritized for use each time the IoT device powers on.

[0152] like Figure 7As shown, when it is determined that the control parameters carried by the APDU control message do not belong to the custom control parameter set, it indicates that the APDU control message is a standard APDU control message. In this case, the control chip sends the APDU control message to the current user identity card (such as the second user identity card) among multiple user identity cards to ensure normal interactive control within the IoT device.

[0153] Additionally, during the use of IoT devices, users may replace the integrated user identity card (UIC) with a regular UIC. In this case, if the communication module still sends custom APDU control messages, the UIC may malfunction and even become locked because it does not recognize these custom APDU control messages.

[0154] To avoid the aforementioned situation, the communication module can generate an ICCID query message and send it to the User Identity Authentication Card (UICID) each time the IoT device is powered on. Please refer to the above text for an explanation of how the communication module generates the ICCID query message; it will not be repeated here.

[0155] like Figure 8 As shown, if the IoT device uses a User Identity Registry (UIR) card, the control chip receives an ICCID query message. Since the ICCID query message is a standard APDU control message, the control chip forwards the ICCID query message to the current User Identity Registry card in the UIR card. The current User Identity Registry card recognizes the ICCID query message and sends the corresponding ICCID to the control chip. The control chip receives the ICCID and modifies the target feature bits of the ICCID. The modified ICCID is a non-standard ICCID used to indicate that the current User Identity Registry card is integrated into the UIR card. Afterward, the control chip sends the modified ICCID to the communication module.

[0156] For example, such as Figure 8 As shown, the target feature bit can be the first bit of the ICCID.

[0157] For example, if the standard ICCID is 89865678901234567879, then changing the first digit to 9 will give 99865678901234567879. Furthermore, this modification will not affect the normal ICCID lookup within the IoT device, because the lookup primarily uses the last 18 digits of the ICCID. Therefore, modifying only the first digit will not affect the normal ICCID lookup within the IoT device.

[0158] If the IoT device uses a regular user identity card, the user identity card directly receives the ICCID query message and returns the corresponding ICCID to the communication module.

[0159] After receiving the returned ICCID, the communication module judges it. If it is determined that the received ICCID is a standard ICCID, it means that a regular user identity card is inserted in the IoT device. In this case, no custom APDU control message will be generated and sent to avoid abnormal error reports from the user identity card.

[0160] If it is determined that the received ICCID is not a standard ICCID, it means that the IoT device has inserted a User Identity Detection Card (UIC). In this case, a custom APDU control message can be generated according to actual needs and sent to the UIC.

[0161] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0162] The data communication method provided in this application embodiment identifies the control parameters carried in the received APDU control message and intercepts the APDU control message when it is determined that the control parameters belong to a custom control parameter set. This can prevent the custom APDU control message from being sent to the user identity card in the user identity integrated card, thus avoiding abnormal error reports or even being locked by the user identity card.

[0163] Figure 9 This is a schematic diagram of a data communication device provided in an embodiment of this application. The device is located in the communication module of an Internet of Things (IoT) device and includes:

[0164] The generation module 901 is used to generate custom APDU control messages for the user identification integrated card. The custom APDU control messages carry custom control parameters, which are used to instruct the control chip to perform corresponding operations.

[0165] The sending module 902 is used to send custom APDU control messages to the control chip.

[0166] The data communication apparatus provided in this application embodiment carries specific control information in the control parameters carried in a custom APDU control message, and uses the custom APDU control message to control the User Identity Module (UIM). Since the APDU format control message conforms to the internal communication mechanisms of various IoT devices, the custom APDU control message can be transmitted normally in various IoT devices without requiring modifications to standard communication modules and UIMs. This method achieves unified control of the UIM in different IoT devices.

[0167] In one possible implementation, custom control parameters are used to instruct the control chip to switch the current user identification card of the IoT device; or,

[0168] Custom control parameters are used to instruct the control chip to prioritize the user identification card that is enabled each time the IoT device is powered on.

[0169] In one possible implementation, the custom control parameters include custom control type parameters and custom control specific parameters. The custom control type parameters are used to indicate the type of operation performed by the control chip, and the custom control specific parameters are used to indicate the user identification card corresponding to the operation performed by the control chip.

[0170] In one possible implementation, the generation module 901 is used for:

[0171] Generate custom control instructions for the user identification integrated card. The custom control instructions include a standard control type part and a custom control parameter part. The standard control type part conforms to the 3GPP protocol standard, and the custom control parameter part carries custom control parameters.

[0172] Convert custom control commands into custom APDU control messages.

[0173] In one possible implementation, the generation module 901 is used for:

[0174] Receive custom control commands sent by the MCU in the IoT device. The custom control commands include a standard control type part and a custom control parameter part. The standard control type part conforms to the 3GPP protocol standard, and the custom control parameter part carries custom control parameters.

[0175] Convert custom control commands into custom APDU control messages.

[0176] In one possible implementation, the custom control command belongs to one or more of the CSIM, CLCK, and CSCA commands in the AT commands.

[0177] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0178] It should be noted that the data communication apparatus provided in the above embodiments is only illustrated by the division of the above functional modules during data communication. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the IoT device can be divided into different functional modules to complete all or part of the functions described above. In addition, the data communication apparatus provided in the above embodiments and the first data communication method embodiment described above belong to the same concept, and the specific implementation process can be found in the data communication method embodiment, which will not be repeated here.

[0179] Figure 10 This is a schematic diagram of another data communication device provided in an embodiment of this application. The device is located in the control chip of the user identification integrated card of an Internet of Things (IoT) device, and includes:

[0180] The receiving module 1001 is used to receive APDU control messages sent by the communication module;

[0181] The execution module 1002 is used to intercept the APDU control message and execute the operation corresponding to the control parameters when it is determined that the control parameters carried by the APDU control message belong to a custom control parameter set.

[0182] The data communication apparatus provided in this application embodiment identifies the control parameters carried in the received APDU control message and intercepts the APDU control message when it is determined that the control parameters belong to a custom control parameter set. This can prevent the custom APDU control message from being sent to the user identity card in the user identity integrated card, thus avoiding abnormal error reports or even being locked by the user identity card.

[0183] In one possible implementation, execution module 1002 is used for:

[0184] Perform a switch operation on the current user identification card of the IoT device; or,

[0185] Prioritize the user identification card that is activated when the IoT device is powered on.

[0186] In one possible implementation, the apparatus further includes a transmitting module for:

[0187] When it is determined that the control parameters carried by the APDU control message do not belong to the custom control parameter set, the APDU control message is sent to the current user identity card among multiple user identity cards.

[0188] In one possible implementation, the APDU control message is an ICCID query message;

[0189] The receiving module 1001 is also used to receive the ICCID sent by the current user's identity card;

[0190] The execution module 1002 is also used to modify the target feature bit of the ICCID, and the modified ICCID is used to indicate that the current user identification card is integrated into the user identification integrated card;

[0191] The sending module is also used to send the modified ICCID to the communication module.

[0192] All of the above-mentioned optional technical solutions can be combined in any way to form optional embodiments of this disclosure, and will not be described in detail here.

[0193] It should be noted that the data communication apparatus provided in the above embodiments is only illustrated by the division of the above functional modules during data communication. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the IoT device can be divided into different functional modules to complete all or part of the functions described above. In addition, the data communication apparatus provided in the above embodiments and the second data communication method embodiment described above belong to the same concept, and the specific implementation process can be found in the data communication method embodiment, which will not be repeated here.

[0194] This application also provides an Internet of Things (IoT) device, such as... Figure 1 As shown, the IoT device includes a communication module 200 and a user identity integrated card 300, the user identity integrated card 300 including a control chip 301 and multiple user identity cards. In some instances, the IoT device also includes a microcontroller unit 100.

[0195] The communication module 200 is used to generate custom APDU control messages for the user identification integrated card 300. The custom APDU control messages carry custom control parameters, which are used to instruct the control chip to perform corresponding operations; and to send custom APDU control messages to the control chip 301.

[0196] The control chip 301 is used to receive APDU control messages sent by the communication module 200; when it is determined that the control parameters carried in the APDU control message belong to a custom control parameter set, the control chip intercepts the APDU control message and executes the operation corresponding to the control parameters. The custom control parameters belong to a custom control parameter set.

[0197] The IoT device provided in this application embodiment carries specific control information in the control parameters carried in a custom APDU control message, and uses the custom APDU control message to control the User Identity Module (UIM). Since the APDU format control message conforms to the internal communication mechanisms of various IoT devices, the custom APDU control message can be transmitted normally in various IoT devices without requiring modifications to the standard communication module and UIM. This method achieves unified control of the UIM across different IoT devices.

[0198] Furthermore, by identifying the control parameters carried in the received APDU control message through the control chip 301, and intercepting the APDU control message when it is determined that the control parameters belong to the custom control parameter set, the custom APDU control message can be prevented from being sent to the user identity card in the user identity integrated card 300, thus preventing the user identity card from reporting abnormal errors or even being locked.

[0199] In an exemplary embodiment, a computer-readable storage medium is also provided, such as a memory including at least one computer program, which can be executed by a processor in an Internet of Things (IoT) device to perform the data communication methods described in the various embodiments above. For example, the computer-readable storage medium includes ROM (Read-Only Memory), RAM (Random-Access Memory), CD-ROM (Compact Disc Read-Only Memory), magnetic tape, floppy disk, and optical data storage devices, etc.

[0200] In an exemplary embodiment, a computer program product or computer program is also provided, including one or more lines of program code stored in a computer-readable storage medium. One or more processors of an Internet of Things (IoT) device are capable of reading the one or more lines of program code from the computer-readable storage medium, and the one or more processors execute the one or more lines of program code, enabling the IoT device to perform the data communication method described in the above embodiments.

[0201] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. Optionally, the program is stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0202] The above description is merely an optional embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A user identification integrated card, characterized in that, The user identification integrated card is used in IoT devices. The user identification integrated card includes a control chip and multiple user identification cards. The control chip is used for: Receive Application Protocol Data Unit (APDU) control messages; When it is determined that the control parameters carried by the APDU control message belong to a custom control parameter set, the APDU control message is intercepted and the operation corresponding to the control parameters is executed. When it is determined that the control parameters carried by the APDU control message do not belong to the custom control parameter set, the APDU control message is sent to the current user identity card among the multiple user identity cards.

2. The user identification integrated card according to claim 1, characterized in that, The operation corresponding to the control parameters is to switch the current user identification card of the IoT device; or to select the priority of the user identification card enabled when the IoT device is powered on.

3. The user identification integrated card according to claim 1 or 2, characterized in that, The APDU control message is an Integrated Circuit Card Identification Code (ICCID) query message. After sending the APDU control message to the current user identification card among the plurality of user identification cards, the control chip is further configured to: Receive the ICCID sent by the current user identification card; Modify the target feature bit of the ICCID; the modified ICCID is used to indicate that the current user identification card is integrated into the user identification integrated card. The modified ICCID is sent to the communication module in the IoT device.

4. The user identification integrated card according to claim 3, characterized in that, The target feature bit is the first bit of the ICCID.

5. A method for data communication, characterized in that, The method is applied to a microcontroller unit (MCU) in an IoT device, the IoT device further including a communication module and a user identity recognition (BIV) integrated card, the BIV integrated card including a control chip and multiple BIV cards, the method comprising: Generate custom control instructions for the user identification integrated card, wherein the custom control instructions include a standard control type part and a custom control parameter part. The standard control type part conforms to the 3GPP protocol standard, and the custom control parameter part carries custom control parameters, which are used to instruct the control chip to perform corresponding operations. The custom control command is sent to the communication module, so that the communication module converts the custom control command into a custom application protocol data unit (APDU) control message and sends the custom APDU control message to the control chip, wherein the custom APDU control message carries the custom control parameters.

6. The method according to claim 5, characterized in that, The control chip performs the following operations: switching the current user identification card of the IoT device; or prioritizing the user identification card activated when the IoT device is powered on.

7. The method according to claim 5 or 6, characterized in that, The custom control parameters include custom control type parameters and custom control specific parameters. The custom control type parameters are used to indicate the type of operation performed by the control chip, and the custom control specific parameters are used to indicate the user identification card corresponding to the operation performed by the control chip.

8. The method according to claim 5 or 6, characterized in that, The custom control command belongs to one or more of the CSIM, CLCK, and CSCA commands in the AT commands.

9. A method for data communication, characterized in that, The method is used to communicate with the control chip of the user identification integrated card of an Internet of Things (IoT) device, and the method includes: The system sends a message to the IoT device through the application programming interface (API), and the message carries custom control parameters, which are used to instruct the control chip to perform corresponding operations. The message is used to invoke a custom control command of the IoT device. The custom control command includes a standard control type part and a custom control parameter part. The standard control type part conforms to the 3GPP protocol standard, and the custom control parameter part carries the custom control parameters. The message then causes the IoT device to convert the custom control command into a custom application protocol data unit (APDU) control message and send the custom APDU control message to the control chip. The custom APDU control message carries the custom control parameters.

10. The method according to claim 9, characterized in that, The API interface is a REST API interface.

11. The method according to claim 9 or 10, characterized in that, The message is for activating the PIN function of the user identification card, and the part of the message that carries the activation password carries the custom control parameters.

12. The method according to claim 9 or 10, characterized in that, The custom control command is an AT command.

13. The method according to claim 12, characterized in that, The custom control command is the CLCK command in the AT commands.

Images