A configuration file updating method, device, medium and program product based on a low-power Internet of Things device

Abstract

The present application belongs to the technical field of low-power-consumption Internet of Things, and particularly relates to a configuration file updating method, device, medium and program product based on a low-power-consumption Internet of Things device. The configuration file updating method based on a low-power-consumption Internet of Things device comprises the following steps: acquiring a single-time wake-up available duration of a target Internet of Things device, a predicted transmission efficiency of the target Internet of Things device and a file size of a target configuration file; determining a total updating duration of the target configuration file according to the file size and the predicted transmission efficiency; determining an updating strategy for the target configuration file according to the single-time wake-up available duration and the total updating duration; and performing configuration file updating on the target Internet of Things device according to the updating strategy. The present application solves the technical problem that the existing technology is faced with the problem that a Profile (configuration file) download process and a Modem sleep mechanism are not coordinated, and realizes the minimization of device power consumption while ensuring that configuration file downloading is reliably completed.

Description

Technical Field

[0001] This invention belongs to the technical field of low-power Internet of Things (IoT), and specifically relates to a method, device, medium, and program product for updating configuration files of low-power IoT devices. Background Technology

[0002] In low-power wide-area network (LPWAN) scenarios such as NB-IoT (Narrowband Internet of Things) and LTE-M (Long Term Evolution of Machine-Type Communications), IoT devices typically operate their cellular modems in 3GPP-defined power-saving modes to extend battery life. These modes mainly include two mechanisms: PSM (Power Saving Mode) and eDRX (Extended Discontinuous Reception).

[0003] In PSM mode, after completing mobility management and data transmission, the terminal enters a deep power-saving state where it is not pagingable. It is only briefly awakened to perform a Tracking Area Update (TAU) when the T3412ext timer (TAU cycle, typically several hours to several days) expires. The active time is controlled by the T3324 timer (Active Timer), typically ranging from 10 to 60 seconds. In eDRX mode, the device only listens for paging within the PTW (Paging Time Window) in each eDRX cycle (up to 2.91 hours for NB-IoT) to reduce power consumption. The typical PTW value is 2.56 to 40.96 seconds.

[0004] The GSMA SGP.32 specification defines the eUICC remote configuration architecture for IoT devices, where the IPA (IoT Profile Assistant) is responsible for downloading and managing profiles. Depending on the deployment location of the IPA, SGP.32 defines two implementation models: (1) IPAe (IoT Profile Assistant embedded in eUICC): IPA is embedded in the eUICC security chip and runs inside. It communicates with the modem through the UICC standard interface (ISO 7816 APDU channel) and uses the eUICC hardware security environment to perform profile download and management operations.

[0005] (2) IPAd (IoT Profile Assistant in Device): IPA runs on the application processor (AP) of IoT devices. It communicates with the Modem and eUICC through interfaces provided by the device operating system (such as AT command interface, RIL interface or platform API) and performs profile download and management operations in the device-side software environment.

[0006] The SGP.32 specification explicitly states that "How eIM triggers IPA is out of scope of this specification," and it makes no provisions regarding the coordination between the Profile download process and the Modem power-saving mechanism. In the communication architecture defined by SGP.32, the IPA (whether IPAe or IPAd) communicates with the eIM (IoT eSIM Manager) via a CoAP / DTLS secure channel. The eIM then interacts with SM-DP+ (Subscription Manager Data Preparation) through the ES9+ interface to complete the Profile preparation and download coordination. BPP (Bound Profile Package) data is generated by SM-DP+ and forwarded to the IPA via the eIM. Therefore, the DTLS secure session and CoAP data transmission on the IPA side use the eIM as the direct communication peer. Regardless of whether the IPA adopts the IPAe or IPAd deployment model, it faces the technical problem of incompatibility between the Profile download process and the Modem sleep mechanism. Summary of the Invention

[0007] This application discloses a configuration file update method for low-power IoT devices, comprising: obtaining the single wake-up available duration of the target IoT device, the predicted transmission efficiency of the target IoT device, and the file size of the target configuration file; determining the total update duration of the target configuration file based on the file size and the predicted transmission efficiency; determining an update strategy for the target configuration file based on the single wake-up available duration and the total update duration; and updating the configuration file of the target IoT device according to the update strategy. This method solves the technical problem of incompatibility between the profile download process and the modem sleep mechanism in existing technologies, achieving the goal of minimizing device power consumption while ensuring reliable completion of configuration file download.

[0008] To address the aforementioned technical problems, this application proposes four aspects.

[0009] In a first aspect, this application proposes a configuration file update method based on a low-power Internet of Things (IoT) device, comprising: obtaining the single wake-up available duration of the target IoT device, the predicted transmission efficiency of the target IoT device, and the file size of the target configuration file; determining the total update duration of the target configuration file based on the file size and the predicted transmission efficiency; determining an update strategy for the target configuration file based on the single wake-up available duration and the total update duration; and updating the configuration file of the target IoT device according to the update strategy.

[0010] In some embodiments, determining the total update duration of the target configuration file based on the file size and the predicted transmission efficiency includes: determining the predicted transmission duration of the target configuration file based on the file size and the predicted transmission efficiency; and determining the total update duration based on the predicted transmission duration, the preset installation time, handshake time, and authentication negotiation time for the target IoT device.

[0011] In some embodiments, determining the update strategy for the target configuration file based on the available duration of a single wake-up and the total update duration includes: determining the update strategy as a phased update when the total update duration is greater than or equal to the available duration of a single wake-up; determining the handshake operation and authentication negotiation operation as the first phase of the phased update; determining the installation operation of the target configuration file as the final phase of the phased update; determining the transmission operation of the target configuration file as the data transmission phase of the phased update, wherein the number of data transmission phases is determined based on the predicted transmission duration and the predicted transmission efficiency; determining the start data packet and the end data packet for each data transmission phase based on the number of phases; and generating a phased update plan based on the start data packet and the end data packet for each data transmission phase, as well as the first phase and the final phase.

[0012] In some embodiments, updating the configuration file of the target IoT device according to the update strategy includes: during the data transmission phase, obtaining in real time the execution duration of the current phase, the actual transmission efficiency, and the amount of untransmitted data packets in the current phase; determining the transmission duration based on the actual transmission efficiency and the amount of data; determining the remaining execution duration of the current phase based on the transmission duration and a preset safe termination duration; determining the remaining available duration based on the execution duration and the available duration for a single wake-up; and performing an early safe termination operation when the remaining available duration is less than or equal to the remaining execution duration.

[0013] In some embodiments, performing the early safe termination operation includes: after completing the processing of the current data packet, persistently storing the data packets successfully received in the current stage; wherein the processing of the current data packet involves completing the reception of the current data packet or abandoning the current data packet; and updating the update plan based on the successfully received data packets.

[0014] In some embodiments, the persistent storage of the successfully received data packets in the current stage includes: synchronously persistently storing the DTLS session state information and the successfully received data packets, so that data transmission can be quickly restored based on the DTLS session state information during the next data transmission; wherein, during persistent storage, the DTLS session state information and the successfully received data packets are synchronously persistently stored in the device-side storage and the eUICC data sharing area, so that in the event of a device startup anomaly, the data transmission stage can be restored through the storage results in the device-side storage and the eUICC data sharing area.

[0015] In some embodiments, the method further includes: determining the wake-up interval of the target IoT device based on the current completion status of the update plan; determining the next execution time of the update plan based on the wake-up interval; and executing the update plan based on the next execution time.

[0016] In a second aspect, this application proposes a computer electronic production apparatus, including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of any of the methods described in the first aspect.

[0017] Thirdly, this application proposes a computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0018] Fourthly, this application proposes a computer program product, including a computer program, characterized in that, when executed by a processor, the computer program implements the steps of the method described in any one of the first aspects.

[0019] This application discloses a configuration file update method for low-power IoT devices, comprising: obtaining the single wake-up available duration of the target IoT device, the predicted transmission efficiency of the target IoT device, and the file size of the target configuration file; determining the total update duration of the target configuration file based on the file size and the predicted transmission efficiency; determining an update strategy for the target configuration file based on the single wake-up available duration and the total update duration; and updating the configuration file of the target IoT device according to the update strategy. This method solves the technical problem of incompatibility between the profile download process and the modem sleep mechanism in existing technologies, achieving the goal of minimizing device power consumption while ensuring reliable completion of configuration file download. Attached Figure Description

[0020] One or more embodiments are illustrated by way of example with reference to the accompanying drawings, and these illustrative descriptions do not constitute a limitation on the embodiments.

[0021] Figure 1 A main flowchart of a configuration file update method for low-power IoT devices provided in this application embodiment; Figure 2 A flowchart illustrating a cross-wake-up cycle DTLS session recovery process is provided in this application embodiment; Figure 3 This application provides a flowchart of a normal persistent storage recovery process. Figure 4 This application provides an abnormal startup recovery flowchart. Figure 5 This is a structural block diagram of a computer electronic production equipment provided in an embodiment of this application. Detailed Implementation

[0022] In low-power wide-area network (LPWAN) scenarios such as NB-IoT (Narrowband Internet of Things) and LTE-M (Long Term Evolution of Machine-Type Communications), IoT devices typically operate their cellular modems in 3GPP-defined power-saving modes to extend battery life. These modes mainly include two mechanisms: PSM (Power Saving Mode) and eDRX (Extended Discontinuous Reception).

[0023] In PSM mode, after completing mobility management and data transmission, the terminal enters a deep power-saving state where it is not pagingable. It is only briefly awakened to perform a Tracking Area Update (TAU) when the T3412ext timer (TAU cycle, typically several hours to several days) expires. The active time is controlled by the T3324 timer (Active Timer), typically ranging from 10 to 60 seconds. In eDRX mode, the device only listens for paging within the PTW (Paging Time Window) in each eDRX cycle (up to 2.91 hours for NB-IoT) to reduce power consumption. The typical PTW value is 2.56 to 40.96 seconds.

[0024] The GSMA SGP.32 specification defines the eUICC remote configuration architecture for IoT devices, where the IPA (IoT Profile Assistant) is responsible for downloading and managing profiles. Depending on the deployment location of the IPA, SGP.32 defines two implementation models: (1) IPAe (IoT Profile Assistant embedded in eUICC): IPA is embedded in the eUICC security chip and runs inside. It communicates with the modem through the UICC standard interface (ISO 7816 APDU channel) and uses the eUICC hardware security environment to perform profile download and management operations.

[0025] (2) IPAd (IoT Profile Assistant in Device): IPA runs on the application processor (AP) of IoT devices. It communicates with the Modem and eUICC through interfaces provided by the device operating system (such as AT command interface, RIL interface or platform API) and performs profile download and management operations in the device-side software environment.

[0026] The SGP.32 specification explicitly states that "How eIM triggers IPA is out of scope of this specification," and it makes no provisions regarding the coordination between the Profile download process and the Modem power-saving mechanism. In the communication architecture defined by SGP.32, the IPA (whether IPAe or IPAd) communicates with the eIM (IoT eSIM Manager) via a CoAP / DTLS secure channel. The eIM then interacts with SM-DP+ (Subscription Manager Data Preparation) through the ES9+ interface to complete the Profile preparation and download coordination. BPP (Bound Profile Package) data is generated by SM-DP+ and forwarded to the IPA via the eIM. Therefore, the DTLS secure session and CoAP data transmission on the IPA side use the eIM as the direct communication peer. Regardless of whether the IPA adopts the IPAe or IPAd deployment model, it faces the technical problem of incompatibility between the Profile download process and the Modem sleep mechanism.

[0027] In general, the main reasons for the inconsistencies in existing technologies are: (1) The SGP.32 specification does not define a coordination mechanism between the Profile download process and the Modem sleep mode. In actual deployment, when the eIM triggers the IPA (whether it is IPAe or IPAd) to perform Profile download, if the Modem is in PSM sleep mode, the IPA download request cannot be sent; if the Modem is in the non-listening period of eDRX, the trigger message sent by the network side cannot reach the device. This makes the triggering time of Profile download unpredictable and may result in long waiting times.

[0028] (2) Even when the modem is active, the PSM's Active Timer (T3324) typically lasts only 10 to 60 seconds. A complete profile download process involves multiple stages, including DTLS handshake (2 to 3 RTTs, each RTT can take several seconds in NB-IoT networks), authentication negotiation, BPP transmission (hundreds of KB of data can take tens of seconds to several minutes at low NB-IoT rates), and installation confirmation. These stages often cannot be completed within a single wake-up window. When the Active Timer expires and the modem enters sleep mode, the ongoing DTLS connection is forcibly disconnected, and the intermediate data that has been transmitted may be lost, requiring a restart or a complex recovery process to be performed upon the next wake-up.

[0029] To address the aforementioned technical problems, this invention proposes a configuration file update method based on low-power IoT devices. The following details the implementation of a multi-service provider network sharing system in this embodiment. The implementation details provided below are for ease of understanding and are not essential for implementing this solution.

[0030] Example 1: like Figure 1 As shown, this application provides a configuration file update method based on a low-power Internet of Things (IoT) device. The method is applicable to electronic production equipment, which can be a server, mobile terminal, computer, cloud platform, etc. The data processing functionality of the production equipment provided in this application embodiment can be implemented by the processor of the electronic production equipment calling program code, wherein the program code can be stored in a computer storage medium. The configuration file update method based on a low-power IoT device includes: Step S1: Obtain the single wake-up duration of the target IoT device, the predicted transmission efficiency of the target IoT device, and the file size of the target configuration file.

[0031] After eIM sends a Profile download trigger command to the device, the IPA module first obtains the Modem's current power-saving mode configuration parameters through the corresponding device interface before starting the download process. Depending on the deployment configuration of the IPA module, the method of obtaining these parameters includes: A. Parameter acquisition methods in IPAe deployment mode: Method A1: The IPAe sends a Proactive Command to the Modem via the standard interface (ISO 7816 APDU channel) between the eUICC and the Modem to query the current PSM / eDRX parameters. Specifically, the IPAe can request the Modem to return the current network registration status and timer values ​​via the PROVIDELOCAL INFORMATION command (ETSI TS 102 223).

[0032] Method A2: IPAe uses the Terminal Profile mechanism of UICC to have the Modem actively report PSM / eDRX parameters to the eUICC during power-on initialization, and IPAe reads these parameters from the shared data area of ​​the eUICC.

[0033] Method A3: In scenarios where the device supports the AT command interface, IPAe indirectly obtains the AT+CPSMS and AT+CEDRXS response parameters reported by the Modem through the BIP (Bearer Independent Protocol) channel.

[0034] B. Parameter acquisition methods in IPAd deployment mode: Method B1: The IPAd directly queries the current PSM / eDRX status and timer parameters of the modem through the cellular network management API provided by the device operating system (such as the TelephonyManager interface for Android, or the ofono / ModemManager D-Bus interface for Linux).

[0035] Method B2: The iPad sends the commands AT+CPSMS? (to query PSM parameters) and AT+CEDRXRDP (to query eDRX dynamic parameters) to the modem via the AT command interface to directly obtain the timer parameter values ​​returned by the modem. This method is suitable for embedded Linux / RTOS devices where the iPad directly manages the modem's serial port.

[0036] Method B3: In devices that support modem-specific interfaces such as Qualcomm QMI or MediaTek CCCI, IPAd obtains accurate PSM / eDRX timer status, including real-time information such as timer remaining time, through the corresponding vendor-specific interface.

[0037] Method B4: The iPad listens for power management events and modem status change notifications from the device's operating system (such as Android's BroadcastReceiver listening for ACTION_POWER_SAVE_MODE_CHANGED and...). (CARRIER_SIGNAL_PSM_STATE_CHANGED broadcast), passively receiving PSM / eDRX parameter change information.

[0038] The parameters obtained include: T3324_value: PSM Active Timer value (unit: seconds), indicating the time the Modem remains active after each wake-up; T3412ext_value: TAU periodic timer value (unit: seconds), representing the interval between two TAU wake-ups; eDRX_cycle: eDRX cycle value (unit: seconds), if the device is working in eDRX mode; PTW_value: Paging Time Window value (unit: seconds), duration of the listening window in eDRX mode; Current_mode: Current power saving mode identifier (PSM / eDRX / None).

[0039] Step S2: Determine the total update time of the target configuration file based on the file size and the predicted transmission efficiency.

[0040] In some embodiments, step S2, "determining the total update duration of the target configuration file based on the file size and the predicted transmission efficiency," includes: Step S21: Determine the predicted transmission duration of the target configuration file based on the file size and the predicted transmission efficiency.

[0041] Step S22: Determine the total update duration based on the predicted transmission duration, the preset installation time, handshake time, and authentication negotiation time for the target IoT device.

[0042] The IPA module estimates the total time (TotalTime) required to complete the entire Profile download based on BPP metadata (TotalLength, i.e., the file size of the target configuration file) and network transmission parameters (predicted transmission efficiency). The estimation method is as follows: TotalTime = T_handshake + T_auth + T_transfer + T_install + T_confirm in: T_handshake: DTLS handshake time, estimated as 3×RTT (full handshake) or 1×RTT (Session Resumption). RTT is a typical value based on the characteristics of the NB-IoT network (e.g., NB-IoT uplink RTT is about 2 to 5 seconds). T_auth: The authentication negotiation time between IPA and eIM, estimated as 2×RTT. In the SGP.32 architecture, IPA communicates with eIM through the CoAP / DTLS channel, and eIM then coordinates with SM-DP+ through the ES9+ interface to complete the authentication process. The authentication time perceived by IPA is the interaction time between IPA and eIM. T_transfer: BPP data transmission time (predicted transmission duration), estimated as TotalLength / EffectiveRate, where EffectiveRate (predicted transmission efficiency) is estimated based on the effective transmission rate of NB-IoT (typical value is 1 to 10 KB / s, taking into account protocol overhead and retransmission). T_install: Profile installation time, which is the on-chip processing time, typically 1 to 3 seconds; T_confirm: Installation confirmation notification time, estimated as 1×RTT; In PSM mode: AvailableTime = T3324_value - T_margin, where T_margin is a safety margin used to ensure that the modem completes the current transmission phase before the Active Timer expires.

[0043] The value of T_margin is determined based on the following derivation: T_margin = T_block_max + T_persist + T_close + T_guard in: T_block_max: The maximum time required for a single CoAP Block to complete transmission. In NB-IoT networks, the CoAP Block size is typically 64 bytes or 128 bytes (limited by the NB-IoT MTU). The transmission of a single Block (data packet) includes uplink requests and downlink responses, with a maximum time approximately equal to one RTT plus the data transmission time, typically 2 to 4 seconds in NB-IoT networks. T_block_max takes the upper limit of this value to ensure that the currently transmitting Block has sufficient time to complete.

[0044] T_persist: The time required to persist the download state to storage. In IPAe deployment, the write speed of the eUICC security chip NVM is limited by the ISO 7816 interface rate and the chip's Flash programming time. Writing approximately 200 bytes of state data (including 90 bytes of DTLS session state and approximately 100 bytes of download progress information) typically takes 0.3 to 0.8 seconds. In IPAd deployment, the device-side Flash write speed is generally faster, but this includes the overhead of encryption processing, typically taking 0.1 to 0.5 seconds. T_persist is the larger value of the two values.

[0045] T_close: The time to send a CoAP connection close or pause indication message to eIM, approximately 0.5 RTTs (only sending is required, no confirmation is needed), typically 1 to 2 seconds.

[0046] T_guard: Additional safety margin to absorb fluctuations in the above items, typically 0.5 to 1 second.

[0047] Comprehensive calculation: under the condition of an NB-IoT network (RTT is approximately 3 seconds), T_margin = 4 + 0.8 + 1.5 + 0.7 = 7 seconds (conservative value). When network conditions are good (RTT is approximately 2 seconds), T_margin = 3 + 0.5 + 1 + 0.5 = 5 seconds. Therefore, the typical value range of T_margin is 3 to 7 seconds, and the IPA module can dynamically calculate the T_margin value according to the actual network RTT and storage writing performance, instead of using a fixed value.

[0048] In eDRX mode: AvailableTime = PTW_value - T_margin. The calculation method of T_margin in eDRX mode is the same as that in PSM mode. However, considering that PTW is usually short (2.56 to 40.96 seconds), when PTW is short, the IPA module shall use a more aggressive T_margin value (reduce T_guard) to ensure that the effective transmission time is not excessively compressed. When PTW_value - T_margin < T_block_max (that is, even a single Block cannot be transmitted within this window), the IPA module shall skip this PTW window, and perform transmission in the next PTW or after waiting for switching to PSM mode.

[0049] Step S3: Determine an update strategy for the target configuration file according to the available duration of a single wake-up and the total update duration.

[0050] In some embodiments, step S3 "determining an update strategy for the target configuration file according to the available duration of a single wake-up and the total update duration" includes: Step S31: When the total update duration is greater than or equal to the available duration of a single wake-up, determine that the update strategy is phased update.

[0051] Step S32: Determine the handshake operation and the authentication negotiation operation as the first stage of the phased update.

[0052] Step S33: Determine the installation operation for the target configuration file as the last stage of the phased update.

[0053] Step S34: Determine the transmission operation of the target configuration file as the data transmission stage of the phased update, wherein the number of stages of the data transmission stage is determined according to the predicted transmission duration and the predicted transmission efficiency.

[0054] Step S35: Determine the start data packet and end data packet of each data transmission stage according to the number of stages.

[0055] Step S36: Generate a phased update plan based on the start and end data packets of each data transmission phase, as well as the first phase and the last phase.

[0056] The IPA module compares TotalTime with AvailableTime, the time available for a single wake-up: If TotalTime ≤ AvailableTime, the download can be completed within a single wake-up call, and the IPA module will directly execute the complete download process.

[0057] If TotalTime > AvailableTime, the IPA module will divide the download process into multiple download stages, each of which can be completed within a single wake-up window. The specific stage division strategy is as follows: Stage 1 (Authentication and Connection Establishment Phase): DTLS handshake + authentication negotiation between IPA and eIM. Estimated time = T_handshake + T_auth. If this time exceeds AvailableTime, the IPA module will split the DTLS handshake into two wake-up windows (using the DTLS HelloVerifyRequest mechanism, the ClientHello / HelloVerifyRequest exchange is completed and the cookie is saved in the first window, and the handshake continues in the second window).

[0058] Stages 2 through K (Data Transmission Stages): BPP data is transmitted in chunks. The IPA module calculates the amount of data that can be transmitted in each stage: DataPerStage = (AvailableTime - T_overhead) × EffectiveRate, where T_overhead is the fixed overhead for each stage (including possible DTLS Session Resumption time and CoAP initial request time, typically 3 to 8 seconds). The total number of transmission stages K = ceil(TotalLength / DataPerStage).

[0059] Stage K+1 (Final Stage): Integrity Verification + Profile Installation + Confirmation Notification.

[0060] The IPA module stores the complete update plan (total number of stages, target block range for each stage, and estimated execution time) in the persistent storage area. Specifically: In the IPAe deployment mode, the phase planning information is stored in the NVM (non-volatile memory) of the eUICC security chip and is protected by the eUICC hardware security protection mechanism.

[0061] In the IPAd deployment model, phase planning information is stored in persistent storage on the device side (such as an encrypted database or secure storage area in the Flash file system), and the data integrity and confidentiality are protected by secure storage services provided by the device operating system (such as AndroidKeystore, Linux dm-crypt encrypted partition or Trusted Execution Environment TEE).

[0062] This takes into account that if the time interval between two wake-ups is too long (e.g., T3412ext is set to several days), the DTLSSession on the eIM side may have expired and been cleared. In this case, the IPA module needs to perform a full DTLS handshake. The IPA module has reserved a time margin for this situation in its phase planning: when a Session Resumption failure is detected, the IPA module dynamically adjusts the target throughput of the current stage, subtracting the extra handshake time, to ensure that it can still terminate safely before the Active Timer expires.

[0063] Step S4: Update the configuration file of the target IoT device according to the update strategy.

[0064] In some embodiments, step S4, "updating the configuration file of the target IoT device according to the update strategy," includes: Step S41: During the data transmission phase, obtain in real time the execution time of the current phase, the actual transmission efficiency, and the amount of data packets that have not been transmitted in the current phase.

[0065] Step S42: Determine the transmission duration based on the actual transmission efficiency and the amount of data.

[0066] Step S43: Determine the remaining execution time of the current stage based on the transmission duration and the preset safe termination duration.

[0067] Step S44: Determine the remaining available time based on the executed duration and the available time for a single wake-up.

[0068] Each time the Modem wakes up from PSM sleep, the IPA module reads the current download execution plan and download progress from persistent storage, determines the Stage number to be executed, and begins to execute the operation corresponding to that Stage.

[0069] In the IPAd deployment model, the wake-up triggering mechanism of the IPA module differs from that of IPAe: IPAd registers wake-up callbacks at the expected modem wake-up time by using the device operating system's timer service (such as Android's AlarmManager or Linux's RTCWakeup Timer), ensuring that the IPAd software module can start in a timely manner when the modem active window begins.

[0070] IPAd listens for Modem state change events (such as network registration success notifications and PSM exit notifications). Upon detecting that the Modem has woken up from sleep and the network is available, it immediately loads and downloads the execution plan from persistent storage and continues execution.

[0071] During the data transfer stage, the IPA module synchronously starts an internal timer to continuously monitor the following metrics: ElapsedTime (Execution Duration): The execution time of the current Stage; RemainingTime (Remaining execution time): AvailableTime – ElapsedTime; CurrentRate (Actual Transmission Efficiency): A moving average of the actual transmission rates of the most recent N CoAP Blocks; RemainingBlocks (Amount of untransmitted data packets): The number of untransmitted blocks remaining within the target block range of the current stage; EstimatedTimeToComplete (transmission duration): RemainingBlocks × BlockSize / CurrentRate.

[0072] Step S45: When the remaining available time is less than or equal to the remaining execution time, perform an early safe termination operation.

[0073] In some embodiments, step S45, "when the remaining available time is less than or equal to the remaining execution time, perform an early safe termination operation," includes: Step S451: After completing the processing of the current data packet, the data packets successfully received in the current stage are persistently stored.

[0074] The processing of the current data packet refers to either completing the reception of the current data packet or discarding the current data packet.

[0075] If RemainingTime<EstimatedTimeToComplete + T_safeclose, wherein T_safeclose is the time required for safe termination. The composition of T_safeclose is consistent with the derivation of T_margin in step S102, specifically T_safeclose = T_persist + T_close + T_guard (excluding T_block_max, because no new Block transmission is initiated during safe termination), which has a typical value of 2 to 4 seconds in an NB-IoT network and a typical value of 1 to 2.5 seconds in an LTE-M network.

[0076] When the above condition is satisfied, the IPA module performs an advance safe termination operation: (a) The IPA module stops sending new CoAP Block requests.

[0077] (b) The IPA module waits for the currently transmitting Block to complete reception and processing (or abandons the Block after timeout).

[0078] (c) The IPA module persistently writes the current download status (including the last successfully processed Block Number, hash intermediate state, and DTLS security context digest) into the storage area.

[0079] (d) The IPA module sends a Pause indication message to eIM through CoAP (optional, using CoAP's RST message or a custom pause Option) to notify eIM to suspend BPP data delivery.

[0080] (e) The IPA module updates the download execution plan in the persistent storage, and updates the completed transmission progress record into the plan.

[0081] (f) The IPA module enters a waiting state, and the Modem automatically enters PSM sleep after the Active Timer expires. In the IPAd deployment form, IPAd synchronously registers the timer callback for the next wake-up time point to ensure that the execution can be resumed in time when the Modem wakes up next time.

[0082] For example, in an NB-IoT device, T3324 is set to 30 seconds, network conditions are good (RTT approximately 2 seconds), and T_margin is 5 seconds (T_block_max = 3 seconds + T_persist = 0.5 seconds + T_close = 1 second + T_guard = 0.5 seconds), then AvailableTime is 25 seconds. The corresponding T_safeclose = T_persist + T_close + T_guard = 2 seconds. The BPP size is 100KB, and the current effective network transmission rate is 5KB / s. In a certain transmission stage, the IPA module has transmitted 15KB of data, taking 18 seconds. At this point, RemainingTime = 25 - 18 = 7 seconds, the remaining data corresponding to RemainingBlocks is 5KB, and EstimatedTimeToComplete = 5KB / 5KB / s = 1 second. Since 7 seconds > 1 second + 2 seconds = 3 seconds, the IPA module can continue transmitting. After transmitting the target data for the current stage for 1 second, the IPA module will perform state persistence and connection closure within the remaining 6 seconds and safely enter sleep mode.

[0083] In some embodiments, step S451, "persistently storing the data packets successfully received in the current stage," includes: Step S4511: The DTLS session state information and successfully received data packets are synchronously and persistently stored, so that data transmission can be quickly restored based on the DTLS session state information during the next data transmission.

[0084] Specifically, during persistent storage, the DTLS session state information and successfully received data packets are simultaneously persisted to the device-side storage and the eUICC data sharing area. This allows for recovery of the data transmission phase in the event of a device startup anomaly by utilizing the storage results in the device-side storage and the eUICC data sharing area.

[0085] Step S452: Update the update plan based on the successfully received data packet.

[0086] When persisting the download state, the IPA module simultaneously saves the DTLS session state to persistent storage. The saved DTLS session state information includes: DTLS_Session_ID (32 bytes): Session identifier negotiated with eIM; DTLS_Master_Secret_Derived_Key (32 bytes): The session recovery key derived from the DTLS Master Secret (Note: The Master Secret is not stored directly; instead, a derived key used for Session Resumption is stored to reduce the risk of key leakage). DTLS_Sequence_Number (8 bytes): Current DTLS record layer sequence number; DTLS_Cipher_Suite_ID (2 bytes): Identifier of the currently used cipher suite; Server_Endpoint_Hash (16 bytes): The hash value of the eIM endpoint address, used to verify the consistency of the recovered peer; Depending on the deployment method of the IPA module, the secure storage mechanism for DTLS session state varies: IPAe Deployment: The aforementioned information is stored in the secure NVM area of ​​the eUICC security chip and protected by eUICC's hardware security mechanisms (including physical tamper-proofing and encrypted storage), ensuring that DTLS key materials cannot be extracted from outside the chip. This method provides the highest level of security protection.

[0087] IPAd deployment model: The above information is stored in secure storage on the device side, and the security protection mechanism includes the following layers: Preferred solution: Utilize the device's TEE (Trusted Execution Environment, such as ARM TrustZone) or Secure Element (SE) to store DTLS key materials. IPAd calls the key management service in the secure world through the TEE Client API to ensure that the key materials are not exposed in the ordinary operating system environment.

[0088] Alternative solution: Utilize the key management services provided by the device's operating system (such as Android Keystore or Linux Kernel Keyring) to encrypt and store the DTLS session state, with the encryption key protected by a hardware-supported key storage.

[0089] Basic approach: In resource-constrained RTOS devices, IPAd uses a device-unique key (such as an encryption key derived from the device certificate private key) to encrypt the DTLS session state using AES-GCM and then stores it in the Flash file system.

[0090] When the Modem wakes up from PSM sleep, the IPA module performs the following fast recovery procedure: (a) The IPA module reads DTLS session state information from persistent storage.

[0091] (b) The IPA module verifies whether Server_Endpoint_Hash is consistent with the current target eIM address.

[0092] (c) The IPA module sends a DTLS ClientHello message to the eIM, which carries the saved DTLS_Session_ID and requests an Abbreviated Handshake.

[0093] (d) If eIM accepts Session Resumption (returns ServerHello containing the same Session_ID), both parties can quickly restore the DTLS secure channel using the previously used key materials, requiring only 1 RTT.

[0094] (e) If eIM rejects Session Resumption (returns a new Session_ID or HelloRetryRequest), the IPA module falls back to the full DTLS handshake process.

[0095] Through Session Resumption, DTLS reconnection time is reduced from 6 to 15 seconds (3 RTTs × 2 to 5 seconds / RTT) for a full handshake to 2 to 5 seconds (1 RTT), saving approximately 10 seconds of effective transmission time in a 30-second Active Timer, equivalent to improving single-window transmission efficiency by about 50% (the overall process is as follows). Figure 2 (As shown).

[0096] Steps S1-S452 are illustrated using a complete numerical example in an IPAd deployment configuration: A certain LTE-M smart meter device is deployed in IPAd mode, running an embedded Linux system, with the following configuration: T3324 = 45 seconds (LTE-M devices can usually obtain a longer Active Timer than NB-IoT), T3412ext = 1 hour, network RTT is about 1.5 seconds, device battery capacity is 3600mAh, and the current remaining power is 68%.

[0097] In step S1 (parameter acquisition): The IPAd sends AT+CPSMS? via the AT command interface. The Modem returns "+CPSMS: 1,,,01000011,00100001". The IPAd parses this to obtain T3412ext = 1 hour and T3324 = 45 seconds. The IPAd then synchronously sends AT+CEDRXRDP to confirm that eDRX mode is not currently enabled.

[0098] Corresponding to steps S2-S3 (Dynamic Calculation and Stage Planning of T_margin): IPAd calculates T_margin based on the measured RTT = 1.5 seconds: T_block_max = 1.5 seconds (1 RTT, LTE-M's block transmission efficiency is higher than NB-IoT) + T_persist = 0.3 seconds (encrypted writing to the device-side Flash) + T_close = 0.75 seconds (0.5 × RTT) + T_guard = 0.45 seconds = 3 seconds. Therefore, AvailableTime = 45 - 3 = 42 seconds. The BPP size is 150KB, and the effective transmission rate of LTE-M is approximately 15KB / s. TotalTime = T_handshake(4.5 seconds, 3 × 1.5s RTT) + T_auth(3 seconds, 2 × 1.5s RTT) + T_transfer(10 seconds, 150KB / 15KB / s) + T_install(2 seconds) + T_confirm(1.5 seconds) = 21 seconds. Since TotalTime (21 seconds) ≤ AvailableTime (42 seconds), IPAd determines that the entire download can be completed within a single wake-up window, without needing to split the stage.

[0099] In step S4 (Execution and Monitoring): IPAd requests a Partial WakeLock via the Linux power management interface ( / sys / power / wake_lock) to ensure the CPU remains active. IPAd queries the signal quality using the AT+CESQ command, obtaining RSRP = -95dBm (good), and begins the download. The DTLS handshake phase took 5 seconds (slightly longer than estimated). IPAd dynamically updates RemainingTime and reassesses: remaining available time is 42 - 5 = 37 seconds; the remaining workload (authentication + transmission + installation + confirmation) is estimated at 16.5 seconds. 37 seconds > 16.5 seconds + 2 seconds (T_safeclose), so execution continues. The download completes in 23 seconds. IPAd releases the WakeLock, and the Modem normally enters PSM sleep mode after the remaining 22 seconds of the Active Timer expires.

[0100] If the device's BPP size is 500KB (large profile), then T_transfer = 500 / 15 ≈ 33.3 seconds, TotalTime = 4.5 + 3 + 33.3 + 2 + 1.5 = 44.3 seconds > AvailableTime (42 seconds). Therefore, the IPAd needs to split the download into multiple stages. Stage 1 requires completing the DTLS handshake (4.5 seconds) and authentication negotiation (3 seconds), totaling a fixed overhead of 7.5 seconds. The remaining available time = 42 - 7.5 = 34.5 seconds. Since BPP data transmission only takes 33.3 seconds (500KB ÷ 15KB / s), 34.5 seconds > 33.3 seconds, so Stage 1 can complete all BPP data transmission. However, installation confirmation (3.5 seconds) cannot be completed within the same window (7.5 + 33.3 + 3.5 = 44.3 seconds > 42 seconds). Therefore, Stage 1 completes authentication, connection establishment, and all BPP data transmission (estimated time 40.8 seconds), followed by secure termination. Stage 2 restores the secure channel via DTLS Session Resumption (1.5 seconds) and then performs Profile installation (2 seconds) and confirmation notification (1.5 seconds), totaling approximately 5 seconds, far less than AvailableTime (42 seconds). Therefore, it only needs to be split into two stages to complete the entire download.

[0101] Specifically, during persistent storage, in IPAe deployment mode, the data is written to the resume status area of ​​the eUICC security chip NVM. In IPAd deployment mode, the data is written to the device-side secure storage area, and data integrity is ensured through secure storage services.

[0102] The persistent storage of this application enables recovery of the data transmission phase by storing the results on the device side and in the data sharing area of ​​eUICC when a device startup anomaly occurs.

[0103] Although IPAd operates on the device side, the actual installation and activation of the Profile still requires the eUICC security chip. IPAd collaborates with eUICC in the following ways: (a) The IPAd transmits the downloaded BPP data in segments to the eUICC for processing through the device's eUICC access interface (such as Android's EuiccManager API, or the APDU channel of the eUICC accessed through the PC / SC interface).

[0104] (b) During the download process across wake-up cycles, IPAd is responsible for managing DTLS session recovery and CoAP data transmission, while eUICC is responsible for the secure processing of BPP data and profile installation. At the end of each stage, IPAd ensures that the received BPP data blocks have been successfully delivered and processed and confirmed by eUICC before executing the secure termination procedure.

[0105] (c) IPAd stores copies of download progress information simultaneously in the device-side storage and the shared data area of ​​eUICC, achieving dual persistence protection (see Appendix for detailed procedures of dual persistence writing and exception recovery). Figure 3 and Figure 4 When the device experiences an abnormal reboot, the IPAd can resume download progress from any storage location.

[0106] Specifically, the data structure for dual persistence and the logic for recovery are as follows: Each time IPAd persists its state, it writes the following metadata to the stored download progress data: • Progress_Version (4 bytes): A monotonically increasing version counter, incrementing by 1 with each persistence operation, used to identify the relationship between old and new data. • Progress_Timestamp (8 bytes): Unix timestamp of the persistent operation (accurate to milliseconds), used as an auxiliary check for the version number. • Progress_CRC32 (4 bytes): The CRC32 checksum of the download progress data (excluding the CRC32 field itself), used to check data integrity. • Stage_ID (2 bytes): The currently executing Stage number •Last_Block_Num (4 bytes): The last successfully processed block number. • Hash_Intermediate (32 bytes): Intermediate state of the SHA-256 hash of BPP data During each persistence operation, IPAd first writes the data to the device-side storage (fast write speed and high reliability), and then writes the same data to the eUICC shared data area via APDU (slower write speed but higher security). Both storage locations use a write-alive (WAL) mechanism to ensure the atomicity of each write operation.

[0107] When the device restarts abnormally, IPAd performs the following recovery judgment process: (i) IPAd reads download progress data from the device-side storage and the eUICC shared data area, respectively.

[0108] (ii) IPAd performs CRC32 verification on both sets of data. If the CRC32 verification of one set of data fails (indicating that the data was corrupted due to an abnormal restart during the writing process), the other set of data that passes the CRC32 verification is used as the recovery benchmark.

[0109] (iii) If both data sets pass the CRC32 check, IPAd compares the Progress_Version values ​​of the two data sets. The data with the larger Progress_Version (i.e., the newer one) is used as the recovery benchmark. This is because IPAd's persistence order is to write to the device side first and then to eUICC. If the exception occurs between the two writes, the data stored on the device side may be a newer version than that in eUICC.

[0110] (iv) If the Progress_Version values ​​of the two datasets are the same, IPAd further compares the Progress_Timestamp values ​​and uses the dataset with the newer timestamp. In extreme cases (where both the Version and Timestamp of the two datasets are the same), IPAd can directly use either dataset because their contents are identical.

[0111] (v) If the CRC32 checksum of both data sets fails (indicating that both the device-side storage and eUICC storage were corrupted during the write process, a probability that is extremely low), IPAd rolls back to the last known intact state checkpoint. IPAd creates an additional, non-overwriteable checkpoint snapshot upon completion of each Stage. This snapshot is only written after the Stage is successfully completed and will not be overwritten midway. IPAd recovers from the most recent checkpoint at the cost of losing the transmission progress of the currently incomplete Stage, requiring retransmission of the data already transmitted within that Stage.

[0112] (vi) IPAd reloads the update plan based on the recovered download progress data and continues the subsequent download process from Last_Block_Num + 1.

[0113] In addition, to minimize the possibility of excessively long intervals between wakeups (e.g., T3412ext being set to several days), the eIM-side DTLS Session may expire and be cleared. In some embodiments, the method further includes: Step S4521: Determine the wake-up interval of the target IoT device based on the current completion status of the update plan.

[0114] Step S4522: Determine the next execution time of the update plan based on the wake-up interval duration.

[0115] Step S4523: Execute the update plan according to the next execution time.

[0116] This application dynamically adjusts the Modem's PSM parameters through the IPA module to optimize the wake-up frequency during Profile download. Because this application allows for dynamic adjustment of the PSM parameters, its update plan can also be dynamically updated based on these parameters. Specifically, this application dynamically updates the execution time of the update plan based on the PSM parameters, ensuring timely execution of the plan each time the device wakes up.

[0117] Specifically: Before the end of each wake-up window, the IPA module calculates the recommended T3412ext value based on the following factors: Factor 1: Download progress (CompletionRatio = Data transferred / Total BPP length). Factor 2: Download urgency flag (priority indicator carried by eIM in the download trigger command, such as "Normal" or "Urgent"). Factor 3: Remaining device battery power (if available).

[0118] The recommended calculation logic for the wake-up interval is as follows: If the download emergency flag is "emergency", then Suggested_T3412ext = MinInterval (the shortest allowed interval, typically 60 seconds, to ensure the modem has enough sleep recovery time).

[0119] If the download urgency flag is "normal" and CompletionRatio < 30% (early download stage), then Suggested_T3412ext = ShortInterval (shorter intervals, such as 5 to 10 minutes) to speed up the download startup.

[0120] If the download urgency flag is "normal" and 30% ≤ CompletionRatio < 90% (mid-download), then Suggested_T3412ext = MediumInterval (medium interval, such as 10 to 30 minutes) to balance download speed and power consumption.

[0121] If CompletionRatio ≥ 90% (end of download), then Suggested_T3412ext = ShortInterval (shorter interval) to complete the final part of data transfer and installation confirmation as quickly as possible.

[0122] If the device's remaining battery power is below a threshold (e.g., 10%), the IPA module will increase Suggested_T3412ext to prioritize basic communication functions rather than profile downloads.

[0123] Depending on the deployment method of the IPA module, the method for adjusting the Modem PSM parameters varies: IPAe Deployment Patterns: Method 1: IPAe sends a REFRESH Proactive Command (ETSI TS 102 223) to the Modem, triggering the Modem to reread the EF_PSM_Config file in eUICC (this file has been pre-updated by IPAe to include the Suggested_T3412ext value). The Modem reads the updated configuration and requests the new T3412ext value from the network in the next TAU ​​process.

[0124] Method 2: IPAe can directly set a custom timer through the TIMER MANAGEMENT Proactive Command. When the timer expires, it triggers the ENVELOPE (Timer Expiration) event. In this event, IPAe sends a wake-up instruction to the Modem through the BIP channel.

[0125] IPAd deployment patterns: Method 1: The iPad sends AT+CPSMS=1 directly to the modem via the AT command interface.<Requested_T3412ext> ,<Requested_T3324> The command requests an update to the PSM timer parameters. Upon receiving the command, the modem negotiates the new timer value with the network during the next TAU ​​procedure.

[0126] Method 2: The IPAd requests adjustments to PSM parameters through the device operating system's Modem Management API (such as the vendor extension TelephonyManager interface or CarrierConfigManager interface on the Android platform, or the ModemManager D-Bus interface on the Linux platform).

[0127] Method 3: In devices that support the Qualcomm QMI interface, IPAd can directly set the modem's PSM parameters through the QMI_NAS_SET_POWER_SAVE_MODE message. This method has a faster response time and does not require waiting for the TAU process.

[0128] Method 4: The iPad utilizes the device operating system's RTC Wakeup Timer or AlarmManager to set a precise wake-up timer. When the timer expires, it actively wakes up the modem to establish a network connection via AT commands (such as AT+CFUN=1). This method does not modify the PSM parameters at the network layer but implements wake-up scheduling at the application layer, making it suitable for devices that do not support runtime modification of PSM parameters.

[0129] In addition, the IPAd in this application runs on the device's application processor and can deeply integrate with the device's operating system's power management module: (a) During the Profile download, the IPAd requests a Partial WakeLock from the device power management module (keeping the CPU active but not turning on the screen or other peripherals) to ensure that the application processor does not hibernate due to device-level power saving strategies during the Modem active window, thus preventing the IPA software module from being suspended by the operating system and causing transmission interruption.

[0130] (b) IPAd monitors the power saving mode status of the device's operating system (such as Android's Doze mode or BatterySaver mode). When it detects that the system-level power saving policy may affect the network connection, IPAd dynamically adjusts the download policy: data transmission is performed in the maintenance window of Doze mode, and only state persistence and scheduled updates are performed during the restriction period.

[0131] (c) IPAd queries the device's battery management chip for precise power information (via / sys / class / power_supply / battery node or BatteryManager API), incorporates the real-time power information into the wake-up interval calculation in step S301, and achieves more refined power awareness scheduling than IPAe.

[0132] Moreover, IPAd runs on the device's operating system and can obtain richer network status information than IPAe: (a) IPAd obtains current network connection quality indicators (RSRP, SINR, cell ID, etc.) in real time through the network status interface of the device operating system (such as ConnectivityManager in Android, NetworkManager D-Bus interface in Linux), and dynamically adjusts the estimated value of EffectiveRate accordingly to make the phase planning more accurate.

[0133] (b) When IPAd detects that a device is switching from an NB-IoT cell to an LTE-M or normal LTE cell (e.g., the device is moved to an area with better coverage), IPAd dynamically replans the download phase: Since the transmission rate of LTE-M / LTE is significantly higher than that of NB-IoT, IPAd may merge the remaining data into fewer stages, or determine that the remaining download can be completed in a single wake-up.

[0134] (c) IPAd monitors abnormal events at the network layer (such as RRC connection release, radio link failure, and serving cell change) and executes the safe termination process in advance when a network abnormality is detected, rather than waiting until RemainingTime is insufficient, thereby avoiding wasting the limited wake-up window time during network instability.

[0135] Example 2: Secondly, this application provides a computer electronic production device, such as... Figure 5 As shown, it includes: at least one processor 901; and a memory 200 communicatively connected to the at least one processor 901; wherein the memory 200 stores instructions executable by the at least one processor 901, the instructions being executed by the at least one processor 901 to enable the at least one processor 901 to perform a multi-service provider network sharing method in the above embodiments.

[0136] The memory and processor are connected via a bus, which can include any number of interconnecting buses and bridges, connecting various circuits of one or more processors and memories. The bus can also connect various other circuits, such as peripheral devices, voltage regulators, and power management circuits, which are well known in the art and will not be described further herein. The bus interface provides an interface between the bus and the transceiver. The transceiver can be a single element or multiple elements, such as multiple receivers and transmitters, providing a unit for communicating with various other devices over a transmission medium. Data processed by the processor is transmitted over the wireless medium via an antenna, which further receives data and transmits it to the processor.

[0137] The processor manages the bus and general processing, and also provides various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory is used to store data used by the processor during operation.

[0138] In addition, the computer device may include (but is not limited to) a data bus, an input / output (I / O) bus, a display, and input / output devices (e.g., keyboard, mouse, speakers, etc.).

[0139] The processor can communicate with external devices via the I / O bus through wired or wireless networks.

[0140] In one embodiment, the at least one computer-executable instruction may also be compiled into or comprise a software product / computer program product, wherein one or more computer-executable instructions are executed by a processor to perform the steps of the various functions and / or methods in the embodiments described herein.

[0141] Example 3: Thirdly, this application proposes a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0142] Computer-readable storage media can be implemented by any type of volatile or non-volatile storage device or a combination thereof. Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), flash memory, EPROM memory, EEPROM memory, registers, and computer storage media (e.g., hard disks, floppy disks, solid-state drives, removable disks, CD-ROMs, DVD-ROMs, Blu-ray discs, etc.).

[0143] Computer-readable storage media may also store at least one computer-executable program / instruction, such as computer-readable instructions. Computer-readable storage media include, but are not limited to, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Computer-readable storage media may include, for example, read-only memory (ROM), hard disk, flash memory, etc. For example, a non-transitory computer-readable storage medium may be connected to a computing device such as a computer, and then, when the computing device executes the computer-readable instructions stored on the computer-readable storage medium, the various methods described above can be performed.

[0144] Example 4: Fourthly, this application proposes a computer program product, including a computer program / instructions, characterized in that, when the computer program is executed by a processor, it implements the steps of the method described in any one of the first aspects.

[0145] Those skilled in the art will understand that all or part of the steps in the methods of the above embodiments can be implemented by a program instructing related hardware. This program is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor 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.

[0146] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification does not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential 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. The sequence numbers of the above-described embodiments are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0147] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

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

[0149] In the embodiments provided in this disclosure, it should be understood that the disclosed apparatus and methods can also be implemented in other ways. The apparatus embodiments described above are merely illustrative; for example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0150] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, 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 controller to execute all or part 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 mobile storage devices, ROMs, magnetic disks, or optical disks.

[0151] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein.

[0152] Those skilled in the art will understand that the above embodiments are specific embodiments for implementing this application, and in practical applications, various changes can be made to them in form and detail without departing from the spirit and scope of this application.

Claims

1. A method for updating configuration files based on low-power IoT devices, characterized in that, include: Obtain the single wake-up duration of the target IoT device, the predicted transmission efficiency of the target IoT device, and the file size of the target configuration file; The total update duration of the target configuration file is determined based on the file size and the predicted transmission efficiency. The update strategy for the target configuration file is determined based on the available duration of a single wake-up and the total update duration; The configuration file of the target IoT device is updated according to the update strategy.

2. The method according to claim 1, characterized in that, The step of determining the total update duration of the target configuration file based on the file size and the predicted transmission efficiency includes: The predicted transmission duration of the target configuration file is determined based on the file size and the predicted transmission efficiency. The total update duration is determined based on the predicted transmission duration, the preset installation time, handshake time, and authentication negotiation time for the target IoT device.

3. The method according to claim 2, characterized in that, The step of determining the update strategy for the target configuration file based on the available duration of a single wake-up and the total update duration includes: When the total update duration is greater than or equal to the available duration of a single wake-up, the update strategy is determined to be a phased update. The handshake operation and authentication negotiation operation are identified as the first phase of the phased update. The installation operation of the target configuration file is determined to be the final stage of the phased update; The transmission operation of the target configuration file is determined as a phased data transmission phase, wherein the number of phases of the data transmission phase is determined based on the predicted transmission duration and the predicted transmission efficiency. The start and end data packets for each data transmission phase are determined based on the number of phases. An update plan for phased updates is generated based on the start and end data packets of each data transmission phase, as well as the first phase and the last phase.

4. The method according to claim 3, characterized in that, The step of updating the configuration file of the target IoT device according to the update strategy includes: During the data transmission phase, the execution time of the current phase, the actual transmission efficiency, and the amount of data packets that have not been transmitted in the current phase are obtained in real time. The transmission duration is determined based on the actual transmission efficiency and the amount of data. The remaining execution time of the current stage is determined based on the transmission duration and the preset safe termination duration. The remaining available time is determined based on the executed duration and the available time for a single wake-up; When the remaining available time is less than or equal to the remaining execution time, an early safe termination operation is performed.

5. The method according to claim 4, characterized in that, The execution of the early safe termination operation includes: After processing the current data packet, the data packets successfully received in the current stage are persistently stored. The processing of the current data packet refers to either completing the reception of the current data packet or discarding the current data packet; The update plan is then updated based on the successfully received data packets.

6. The method according to claim 5, characterized in that, The step of persistently storing the data packets successfully received in the current stage includes: The DTLS session state information and successfully received data packets are synchronously and persistently stored, so that data transmission can be quickly resumed based on the DTLS session state information during the next data transmission. Specifically, during persistent storage, the DTLS session state information and successfully received data packets are simultaneously persisted to the device-side storage and the eUICC data sharing area. This allows for recovery of the data transmission phase in the event of a device startup anomaly by utilizing the storage results in the device-side storage and the eUICC data sharing area.

7. The method according to claim 5, characterized in that, The method further includes: The wake-up interval of the target IoT device is determined based on the current completion status of the update plan; The next execution time of the update plan is determined based on the wake-up interval duration; The update plan will be executed according to the next execution time.

8. A computer electronic production equipment, characterized in that, The method includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the method according to any one of claims 1 to 7.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 7.

Images