Batch configuration task grouping scheduling method and device, electronic equipment and storage medium

Abstract

The embodiment of the application aims to provide a batch configuration task grouping scheduling method and device, electronic equipment and storage medium, wherein the method comprises: obtaining a batch configuration task request, wherein the batch configuration task request at least comprises: target equipment corresponding to each configuration task request; grouping the target equipment, determining a trigger time window of each group of target equipment according to the grouping result, and allocating a corresponding trigger time to each target equipment in the group within the trigger time window; generating a trigger instruction including the trigger time for each target equipment in turn, forming a waiting queue of the trigger instruction according to each trigger time window, controlling a token bucket to generate tokens at a target rate and distribute the tokens to the trigger instructions in the waiting queue in turn; and sending the trigger instruction obtaining the token to the corresponding target equipment, so that the target equipment executes the configuration task request corresponding to the target equipment at the trigger time in the trigger instruction. The scheme can improve the success rate and resource utilization of batch configuration of Internet of Things terminals.

Description

Technical Field

[0001] This invention relates to the field of Internet of Things (IoT) communication technology, and in particular to a batch configuration task grouping scheduling method, apparatus, electronic device, and storage medium. Background Technology

[0002] With the rapid growth of IoT terminal scale, remote number configuration based on eSIM (embedded subscriber identification module) has become the mainstream solution in the industry. In large-scale deployment scenarios such as connected vehicles, smart meters, and industrial sensors, operators need to simultaneously trigger profile download tasks for hundreds of thousands or even millions of IoT devices, enabling these devices to obtain and install their respective number configuration files from the SM-DP+ server via the mobile network.

[0003] Currently, the common practice for batch configuration is for the management platform to directly issue trigger commands to each target device according to the task submission order or device list order. However, in this approach, a large number of devices receive the trigger command almost simultaneously and concurrently send download requests to the SM-DP+ server, which can easily lead to a signaling storm in a short period of time. On the one hand, the wireless interface resources of mobile communication networks are limited, and excessive instantaneous concurrency can cause wireless congestion, resulting in lost trigger commands, download timeouts, or authentication failures. On the other hand, the concurrent processing capacity and security authentication resources of the SM-DP+ server are also limited. A sudden surge in requests may exceed its capacity limit, causing service denial or a sharp deterioration in response, ultimately leading to the configuration failure of a large number of devices. Furthermore, the services carried by IoT devices vary significantly in their criticality. Critical services such as vehicle emergency calls and medical monitoring have extremely high requirements for timely configuration, while non-critical services such as environmental monitoring can tolerate longer delays. Existing batch triggering methods mostly adopt a flat processing logic of "first come, first served" without differentiating and scheduling devices according to business level. When the system faces pressure, critical business devices and non-critical business devices are impacted to the same extent, which cannot effectively guarantee the configuration timeliness of high-priority business. Summary of the Invention

[0004] The purpose of this invention is to provide a batch configuration task grouping scheduling method, device, electronic device and storage medium. The method of this embodiment can effectively reduce the risk of wireless congestion and server overload probability, and significantly improve the overall success rate and resource utilization efficiency of batch configuration of large-scale IoT terminals.

[0005] To address the above problems, embodiments of the present invention provide a batch configuration task grouping and scheduling method, the method comprising: A batch configuration task request is obtained, which includes at least: a target device corresponding to each configuration task request; the target devices are grouped, and a trigger time window for each group of target devices is determined according to the grouping result. Within the trigger time window, a corresponding trigger time is allocated to each target device in the group; a trigger instruction including the trigger time is generated for each target device in sequence, and a waiting queue for the trigger instructions is formed according to each trigger time window; a token bucket is controlled to generate tokens at a target rate and distribute them to the trigger instructions in the waiting queue in sequence; the trigger instruction with the obtained token is sent to the corresponding target device so that the target device executes the configuration task request corresponding to the target device at the trigger time in the trigger instruction.

[0006] In addition, the grouping of the target devices as described above includes: performing an initial grouping based on the SLA level of the target devices to obtain a first grouping result; performing a second grouping based on the network access type for each target device in the first grouping result to obtain a second grouping result; performing a third grouping based on the geographical region ID to each target device in the second grouping result to obtain a third grouping result; and performing a fourth grouping based on the PSM cycle for each target device in the third grouping result where the network access type is NB-IoT to obtain the grouping result.

[0007] In addition, determining the trigger time window for each group of target devices based on the grouping results as described above includes: determining a matching trigger rate coefficient based on the network access type corresponding to the grouping results, and obtaining the number of target devices in each group; determining the window length of each group based on the trigger rate coefficient, the number of target devices in each group, and a preset window length calculation formula; calculating the priority score corresponding to each group based on different SLA levels, the network access type, the geographic region ID, and the preset priority coefficient corresponding to the PSM cycle; and determining the trigger time window corresponding to each group based on the priority score corresponding to each group, the preset task base time, the time window length corresponding to each group, and the preset buffer interval.

[0008] In addition, the method described above further includes: for the target devices whose network access type is NB-IoT in the grouping results, determining the wake-up window corresponding to each target device based on the last communication time between each target device and eIM and the complete cycle duration of the target device; when the trigger time of the target device is not within the wake-up window, updating the trigger time to the next wake-up window to obtain the updated trigger time of each target device.

[0009] In addition, for NB-IoT devices with historical communication records, the step of obtaining the update trigger time of each target device as described above further includes: obtaining the communication timestamp of the preset number of communications of each target device, calculating the median of adjacent intervals as the actual wake-up interval; if the deviation between the actual wake-up interval of the target device and the complete cycle duration of the target device is greater than the deviation threshold, then a corrected wake-up window is determined based on the actual wake-up interval, and the trigger time is updated into the corrected wake-up window to obtain the update trigger time.

[0010] In addition, as described above, controlling the token bucket to generate tokens at a target rate includes: using a preset configuration rate as the target rate, controlling the token bucket to generate tokens at the target rate; or, collecting SM-DP+ side load indicators and CoAP ACK packet loss rate, calculating a comprehensive load index based on a preset formula; determining the target rate based on the comprehensive load index, and adjusting the target rate according to preset rules based on changes in the comprehensive load index.

[0011] In addition, as described above, forming a waiting queue for the triggering instructions based on each of the triggering time windows includes: arranging each of the triggering time windows in chronological order; and extracting the triggering instructions corresponding to the target device in each of the triggering time windows in sequence according to the arrangement result to form the waiting queue.

[0012] This invention also proposes a batch configuration task grouping and scheduling device, comprising: The request parsing module is used to obtain batch configuration task requests, which include at least: target devices corresponding to each configuration task request; a device grouping module is used to group the target devices, determine the trigger time window for each group of target devices according to the grouping result, and allocate a corresponding trigger time for each target device in the group within the trigger time window; an instruction issuing module is used to generate a trigger instruction including the trigger time for each target device in sequence, form a waiting queue for the trigger instructions according to each trigger time window, control the token bucket to generate tokens at a target rate and distribute them to the trigger instructions in the waiting queue in sequence; and an IPA interface module is used to send the trigger instruction with the obtained token to the corresponding target device, so that the target device executes the configuration task request corresponding to the target device at the trigger time in the trigger instruction.

[0013] This invention also provides an electronic device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described above.

[0014] This invention also proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method described above.

[0015] The embodiments of the present invention, through method steps, transform large-scale concurrent batch configuration task triggering requests into serialized waves according to scheduling priority and network adaptability. While ensuring timely response to high-priority services, this effectively reduces the risk of wireless signaling congestion and the instantaneous overload pressure on the code management server, significantly improving the overall execution success rate of batch configuration tasks and the efficiency of system resource utilization. Attached Figure Description

[0016] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0017] Figure 1 This is a flowchart illustrating a batch configuration task grouping and scheduling method according to the first embodiment of the present invention. Figure 2 This is a specific flowchart of step 102 in the second embodiment of the present invention; Figure 3 This is a flowchart illustrating a batch configuration task grouping and scheduling method according to the third embodiment of the present invention. Figure 4 This is a specific flowchart of step 103 in the fourth embodiment of the present invention; Figure 5 This is a schematic diagram of the structure of the batch configuration task grouping and scheduling device according to the fifth embodiment of the present invention; Figure 6 This is a schematic diagram of the structure of the electronic device according to the sixth embodiment of the present invention. Detailed Implementation

[0018] To enable those skilled in the art to better understand the technical solutions of this disclosure, and to fully understand and implement the process of how this disclosure applies technical means to solve technical problems and achieve corresponding technical effects, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, not all embodiments. The embodiments of this disclosure and the various features within them can be combined with each other without conflict, and the resulting technical solutions are all within the protection scope of this disclosure. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this disclosure.

[0019] It should be noted that the terms "first," "second," etc., 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. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0020] The first embodiment of this invention relates to a batch configuration task grouping and scheduling method applied to an eSIM IoT Remote Manager (eIM). This method transforms the download triggering process of profiles required by a batch of devices from a sudden surge into an ordered time-series wave, ensuring service priority while avoiding impact on the mobile network and the number management server. Figure 1 As shown, the method in this embodiment specifically includes the following steps 101-103: Step 101: Obtain batch configuration task requests. The batch configuration task requests shall include at least the target device corresponding to each configuration task request.

[0021] Specifically, the process begins by obtaining batch configuration task requests, which must include at least the target devices corresponding to each configuration task request. In actual deployment, operators submit tasks through management interfaces or business support systems. eIM creates batch configuration task instances containing the following key fields: a unique task identifier; a list of target devices, where each device includes: EID (eUICC identifier), IMEI (International Mobile Equipment Identity), networkType (network access type), regionId (geographic region identifier), psmPeriod (PSM period T3412 value, in seconds), t3324 value (active timer T3324 value, in seconds), deviceCategory (device service category), and downloadMode (download mode: direct download / indirect download); the OID of the Profile type to be downloaded; the OID of the Profile type to be downloaded; the target SM-DP+ server address; the Service Level Agreement (SLA) level; and scheduling policy parameters, including the maximum concurrency limit and window interval time. These parameters can be selectively obtained or configured, and this embodiment does not impose specific restrictions on them. It should be noted that before submitting the batch configuration task, the operator has already completed the target device profile order (DownloadOrder / ConfirmOrder) with SM-DP+ through the ES2+ interface. SM-DP+ has prepared the profile to be downloaded for each target EID. eIM does not participate in the profile ordering process; its work begins from triggering the device download.

[0022] eIM obtains a list of target devices by parsing batch configuration task requests. Each target device in the list, in addition to its device identifier, typically carries information such as its corresponding SLA level, network access type, and geographical region identifier. The SLA level reflects the criticality of the service, and can be categorized as critical, standard, and best-effort services. Network access types include CAT-1, LTE-M, and NB-IoT, with different access types differing in bandwidth, latency, and protocol stack capabilities. In this embodiment, the target devices are typically IoT terminals embedded with eUICC (e-UICC). The purpose of the batch configuration task requests in this embodiment is to trigger a large number of target devices to download and install the specified profile from the SM-DP+ server (Subscription Manager Data Preparation+).

[0023] Step 102: Group the target devices, determine the trigger time window for each group of target devices based on the grouping results, and assign a corresponding trigger time to each target device in the group within the trigger time window.

[0024] Specifically, after acquiring the target devices, they are grouped. The purpose of this grouping is to break down the initially large number of mixed target devices into several scheduling units with similar internal characteristics and relatively consistent external processing strategies, according to the differentiated processing logic required for the scheduling process. The basic principle behind this grouping is that different target devices exhibit significant differences in terms of service urgency, network capacity, wireless resource location, and reachability time patterns. If these devices are indiscriminately mixed for scheduling, it is difficult to achieve a balance between efficiency and success rate. Therefore, eIM groups target devices with similar scheduling priority requirements and similar network occupancy characteristics into the same group based on the acquired device attributes, allowing each group to be allocated a unified time window parameter as a whole. The granularity of the grouping can be determined based on the scheduling differences that the actual system focuses on. For example, it can be progressively divided from one or more dimensions such as service priority, network access type, geographical region, and device reachability time characteristics. After grouping, devices within each group are treated equally in terms of scheduling timing, while different groups are assigned different window lengths and order based on their relative priority and resource requirements. This embodiment does not restrict the grouping criteria, as long as the groups are grouped to ensure that all target devices can be processed in differentiated batches.

[0025] After grouping, the trigger time window for each target device in the group is determined based on the grouping results. Within the trigger time window, a corresponding trigger time is allocated to each target device in the group. The process of determining the trigger time window involves distributing the triggering behavior of all devices from a single instant on the timeline into multiple sequentially connected time periods. Each group is assigned a placement order on the global timeline according to its relative priority. The time windows corresponding to higher-priority groups are placed earlier, allowing the trigger commands of critical devices to enter the subsequent transmission process first. Simultaneously, the window length for each group is determined based on the number of devices in the group and the network capabilities corresponding to that group. The principle is that different network types have different signaling processing capabilities and can withstand different concurrency densities. When allocating time window lengths, groups with stronger network capabilities can be given shorter windows to quickly complete large-scale triggering, while groups with weaker network capabilities need to be allocated longer windows to avoid exceeding the load limit that the target network can bear. Within a single time window, the strategy for allocating trigger times to each target device within the group can employ a mechanism of distributing trigger times across the window interval. For example, the trigger times of each device can be randomized or evenly spaced across the entire window length. This embodiment does not restrict the specific allocation method within the group, as long as concentrated concurrency within the window is avoided. Furthermore, for devices with reachability time constraints, the trigger time allocation can be adaptively adjusted to match the device's own reachability time period to increase the probability of successful trigger command reception.

[0026] Step 103: Generate a trigger command including the trigger time for each target device in sequence, form a waiting queue of trigger commands according to each trigger time window, control the token bucket to generate tokens at the target rate and distribute them to the trigger commands in the waiting queue in sequence.

[0027] Specifically, eIM generates a trigger command carrying that trigger time for each target device with an assigned trigger time. All trigger commands are arranged according to the order of their associated time windows, forming a global waiting queue arranged according to a preset scheduling sequence. Commands at the front of the queue correspond to earlier starting time windows, i.e., devices with relatively higher priority. Based on this, this embodiment introduces a token bucket mechanism to control the command transmission rate. The token bucket continuously generates tokens at a preset target rate, and the transmission of a trigger command requires acquiring a token, thereby limiting the output traffic rate below the target rate. In this embodiment, the token bucket generates tokens at the system-configured target rate, and trigger commands in the waiting queue must acquire a token sequentially before they can be sent. Since the order of the waiting queue is consistent with the priority order and window length planning of the time windows, the token bucket can distribute tokens at a basically constant rate, achieving the scheduling effect of high-priority packet commands being dequeued first, and low-rate network packet commands being dequeued gradually over a longer window period. Furthermore, while ensuring the overall transmission rate remains stable and controllable, the target rate can also be adjusted according to the actual transmission situation; this embodiment does not impose specific restrictions on this.

[0028] Step 104: Send the trigger instruction with the obtained token to the corresponding target device so that the target device executes the configuration task request corresponding to the target device at the trigger time in the trigger instruction.

[0029] Specifically, the sending process can be completed by eIM through the communication interface between the device-side agent module and the target device. After receiving the trigger command, the agent module parses the trigger time carried in it. If the current time has not yet reached the trigger time, the command is temporarily stored in the local delay queue to wait. When the system time reaches the specified trigger time, the agent module, on behalf of the target device, actually initiates a Profile download session with the SM-DP+ server to complete the code number configuration.

[0030] Compared with related technologies, this embodiment transforms the large-scale concurrent configuration task triggering requests into serialized waves according to scheduling priority and network adaptability through the above steps. While ensuring timely response to high-priority services, it effectively reduces the risk of wireless signaling congestion and the instantaneous overload pressure on the code number management server, and significantly improves the overall execution success rate of batch configuration tasks and the efficiency of system resource utilization.

[0031] The second embodiment of the present invention relates to a batch configuration task grouping and scheduling method. This embodiment is a refinement of the foregoing embodiment and specifically includes the following contents.

[0032] The grouping of target devices in step 101 specifically includes: The target equipment is initially grouped according to its SLA level to obtain the first grouping result. For each target device in the first grouping result, a second grouping is performed according to the network access type to obtain the second grouping result; For each target device in the second grouping results, it is grouped three times according to its geographical region ID to obtain the third grouping results; For the target devices in each third grouping result of the network access type NB-IoT, the grouping is performed four times according to the PSM cycle to obtain the grouping result.

[0033] Specifically, the grouping dimensions are, in order: SLA level, network access type, geographical region identifier, and power saving mode cycle (PSM cycle) for NB-IoT devices. First, the devices are grouped by SLA level. In this scheme, the SLA level reflects the criticality of the services carried by the device, such as critical services, standard services, and best-effort services. Different SLA levels have different tolerances for trigger latency and resource guarantee requirements. By using SLA level as the first-level grouping dimension, it is ensured that devices with high criticality receive priority scheduling in subsequent window sorting, allowing configuration trigger commands for critical services to be prioritized for transmission in the time sequence.

[0034] On the basis of the above initial grouping, secondary grouping is performed on the target devices in each first grouping result according to the network access type to obtain a second grouping result. The network access type refers to the specific technology adopted by a target device when accessing a mobile communication network, and networks of different access types have essential differences in link bandwidth, signaling bearing capacity, transmission delay, supported communication protocols and other aspects. Examples include NB-IoT, LTE-M and CAT-1, where CAT-1 devices have relatively sufficient bandwidth and can support relatively dense triggering, while NB-IoT devices have extremely low bandwidth, and their triggering process requires a longer time window. By performing secondary grouping according to the network access type, the devices in the same group tend to be consistent in network bearing capacity, so that a window length parameter matching the network characteristics can be independently set for each group, so as to achieve differentiated triggering density control. After the network type grouping is completed, further subdivision is performed according to geographic area identifiers, and devices that share the same site or share wireless resources in the same area are collectively classified into the same group, which facilitates subsequent avoidance of instantaneous congestion on the wireless interface in the area through windowed scheduling. For the NB-IoT device group therein, fourth-level grouping is performed according to the PSM cycle value reported by the devices, where PSM refers to Power Saving Mode. Most of the time, NB-IoT devices are in a deep sleep state with the radio frequency turned off, and only wake up briefly at regular intervals according to the cycle set by the T3412 timer, and the active duration after waking up is determined by the T3324 timer, so grouping can be performed according to T3324. For example, in this embodiment, the devices can be divided into a short cycle group (T3412 ≤ 600 seconds), a medium cycle group (600 seconds < T3412 ≤ 3600 seconds), and a long cycle group (T3412 > 3600 seconds) according to the T3412 timer value. Through this grouping, NB-IoT devices with similar PSM cycles are classified into the same group, which facilitates alignment of the triggering time window with the device wake-up window.

[0035] In an example, as Figure 2 shown, the step of determining the triggering time window for each group of target devices according to the grouping result in step 102 includes: Step 201: Determine a matching triggering rate coefficient according to the network access type corresponding to the grouping result, and obtain the number of target devices in each group.

[0036] Specifically, the triggering rate coefficient is a quantification used to characterize the difference in tolerable command triggering density per unit time for different network access types, and its setting is based on the fact that different network technical standards provide different link bandwidths, control plane signaling processing capabilities and protocol stack overheads. For access types with high data throughput capability and a relatively complete transmission control protocol stack, a higher triggering rate coefficient can be assigned; while for access types oriented to extremely limited bandwidth resources, a lower triggering rate coefficient can be assigned. For example, the triggering rate coefficient k is definedi For Cat-1 devices, set k i =1.0 indicates that its bandwidth is sufficient and it can be triggered at full speed; for LTE-M devices, setting k i =0.6 indicates that its bandwidth is medium, triggering at 60% rate; for NB-IoT devices, setting k i =0.2 indicates that its bandwidth is extremely low and it is triggered at a rate of 20%. By introducing a trigger rate coefficient that matches the network access type, the subsequent window length calculation can be adapted to the actual network carrying capacity.

[0037] Step 202: Determine the window length of each group based on the trigger rate coefficient, the number of target devices in each group, and the preset window length calculation formula.

[0038] Specifically, based on the trigger rate coefficient and the number of devices within a group, the window length for each group is determined according to the trigger rate coefficient, the number of target devices within each group, and the preset window length calculation formula. The preset window length calculation formula is as follows:

[0039] Where, n i R represents the number of target devices in the i-th group. max The maximum concurrent triggering rate configured for the system, k i Let be the trigger rate coefficient for the i-th group.

[0040] Using the above window length calculation formula, groups with stronger network capabilities and higher trigger rate coefficients are allocated shorter window lengths, allowing a large number of devices to be triggered in a shorter time. Conversely, groups with weaker network capabilities and lower trigger rate coefficients have relatively longer window lengths, causing trigger requests to be sent gradually over a longer period, thus avoiding impact on low-bandwidth networks. This inverse relationship between window length and network capability ensures that regardless of the number of devices within a group, its trigger density is always constrained within the safe carrying capacity of that access type.

[0041] Step 203: Calculate the priority score for each group based on the different SLA levels, network access types, geographical area IDs, and preset priority coefficients corresponding to the PSM cycle.

[0042] Specifically, priority scores are calculated for each group based on preset priority coefficients corresponding to different SLA levels, network access types, geographic region IDs, and PSM cycles. The preset priority coefficient for SLA levels reflects the direct impact of service criticality on scheduling priority; the higher the service level, the larger the coefficient. The priority coefficient corresponding to the network access type can be used to further rank different network standards within the same SLA level. For example, it can assign relative priority to more capable networks to expedite scheduling and free up system resources. The coefficient corresponding to the geographic region ID can support operators in assigning differentiated scheduling to different regions. The coefficient corresponding to the PSM cycle can be used to adjust the relative order within NB-IoT groups; for example, groups with shorter cycles can have their scheduling positions adjusted due to frequent wake-ups. By comprehensively calculating the coefficients across these multiple dimensions, such as through weighted summation or multiplication, a priority score representing the urgency of the group's scheduling is obtained. A higher score indicates that the group should be prioritized in the overall scheduling sequence. This embodiment does not limit the specific priority coefficients for different group dimensions or the specific methods used, as long as a score representing the final priority of the grouping result can be calculated.

[0043] Step 204: Determine the trigger time window for each group based on the priority score, preset task base time, time window length, and preset buffer interval for each group.

[0044] Specifically, in this embodiment, the task base time is the time reference point for the entire batch task startup scheduling. It can be the time of task creation confirmation or the start time set by the system. All groups are sorted according to their priority scores, with the group with the highest priority score placed at the front. The start time of its trigger time window is the task base time. The remaining groups are arranged in descending order of priority. The start time of the trigger time window for each subsequent group is calculated by adding the start time of the window of the previous group to the window length of the previous group and a preset buffer interval. The preset buffer interval is a period of idle time reserved between adjacent group windows. It is used to provide network devices and code management servers with a buffer opportunity to process completed trigger requests, avoid the superposition effect of signaling peaks in adjacent windows, and also to provide digestion buffer time for SM-DP+ and the network side. Random jitter prevents the group boundaries of multiple batch tasks from being exactly aligned. The preset buffer interval can be a pre-fixed time or can be calculated using the following method:

[0045] in, For fixed intervals, From 0 to Random fluctuations between them.

[0046] Through the above process, each group is assigned a trigger time window with a clear start and end time. The windows of each group form an ordered but non-overlapping wave sequence on the timeline, providing clear time boundaries for the arrangement of subsequent trigger instructions and token distribution.

[0047] It should also be noted that when operators submit batch tasks for millions of devices, the profiles of some devices may not yet be ready on the SM-DP+ side. Reasons for this include: delays in the operator's ES2+ order batch processing, mismatches between some EIDs and order records in SM-DP+, and insufficient profile inventory. If eIM triggers these devices without verification, the device's initiated two-way authentication will fail on the SM-DP+ side, resulting in a wasted wake-up attempt. Therefore, a pre-verification process can be introduced after the eIM starts the batch configuration task but before the formal group trigger: eIM uses the Profile status query interface provided by the operator's BSS / OSS system to batch query the corresponding Profile order status of each target EID on the SM-DP+ side. This query is completed by calling the BSS / OSS system through the eIM's northbound interface (BSS / OSS then queries SM-DP+ through ES2+), and eIM itself does not directly call the ES2+ interface. The query results are processed in three categories: Profile Ready: The device enters the normal scheduling queue, waiting for group triggering; Profile Not Ready (Pending / Processing status): The device is marked as PENDING_PROFILE and placed in the review queue. eIM re-queries the Profile status of these devices every configurable review period, and once it changes to Released, it is transferred to the normal scheduling queue; Profile Abnormal (Error / NotFound status): The device is marked as PROFILE_ERROR, the reason for the abnormality is recorded, it is not placed in the scheduling queue, and the progress monitoring module reports it to the operator.

[0048] The third embodiment of the present invention relates to a batch configuration task grouping scheduling method. This embodiment provides a new trigger time determination method for target devices in the NB-IoT network access type group in the foregoing embodiments, specifically including the following contents.

[0049] like Figure 3 As shown, this embodiment includes the following steps: Step 301: For target devices with network access type NB-IoT in the grouping results, determine the wake-up window corresponding to each target device based on the last communication time between each target device and eIM and the complete cycle duration of the target device; Step 302: If the trigger time of the target device is not within the wake-up window, update the trigger time to the next wake-up window to obtain the updated trigger time of each target device.

[0050] Specifically, for target devices with NB-IoT network access type in the grouping results, the wake-up window for each target device is first determined based on the last communication time between each target device and eIM, and the complete cycle duration of the target device. The last communication time refers to the timestamp recorded by eIM of the target device's most recent signaling interaction with eIM through the device-side proxy module. This timestamp provides a reference point for estimating the device's subsequent wake-up time. The complete cycle duration refers to the periodic location update or routing area update interval defined by the T3412 timer in the 3GPP standard for NB-IoT devices. This timer determines the interval between two consecutive wake-ups from PSM deep sleep and entry into a reachable state. In actual operation, after each wake-up from PSM, the device maintains a brief active state for listening for paging or transmitting and receiving data. The duration of this active state is determined by parameters such as the T3324 timer, constituting the reachable time interval of the device between adjacent PSM cycles, i.e., the wake-up window. Based on the last communication time and the duration of the complete cycle, the sequence of times the device will enter the wake-up window in the future can be calculated. For example, starting from the last communication time, each complete cycle is a new wake-up time, and an active duration is extended from this starting point to form the wake-up window interval.

[0051] Based on this, it is determined whether the trigger time allocated to the target device in step 102 is within any of the calculated wake-up windows. If the trigger time of the target device falls within the time range of a certain wake-up window, it indicates that the device is in a reachable state when the trigger command arrives at the device-side agent module, and the trigger time does not need to be adjusted and can be retained. Conversely, if the trigger time is not within the wake-up window, it means that the planned trigger time is likely to fall within the device's deep sleep period, at which time the device's radio frequency is turned off and it cannot receive any trigger commands. In this case, this embodiment updates the trigger time to the next wake-up window. The update method can be as follows: in the time sequence of all wake-up windows of the device, select the first wake-up window whose start time is later than the current trigger time, and adjust the trigger time to the start time of the window or a preset position within the window, such as shifting the window start point backward by a random delay, to ensure that the device is in an active and receptive state at that time. Thus, the updated trigger time for each target device in the NB-IoT group is obtained, realizing the adaptation and alignment of the trigger time with the actual reachable window of the device.

[0052] Considering that the actual wake-up cycle of NB-IoT devices may deviate from the nominal full cycle length in real-world operating environments, to further improve the accuracy of wake-up window prediction, a correction mechanism based on actual communication data analysis can be used to determine the update trigger time for NB-IoT devices with historical communication records. Therefore, in another example, if NB-IoT devices have historical records, the method for obtaining the update trigger time of each target device also includes: Obtain the communication timestamps of the preset number of communication times for each target device, and calculate the median of adjacent intervals as the actual wake-up interval; If the deviation between the actual wake-up interval of the target device and the complete cycle duration of the target device is greater than the deviation threshold, then the corrected wake-up window is determined based on the actual wake-up interval, and the trigger time is updated into the corrected wake-up window to obtain the updated trigger time.

[0053] The communication timestamp refers to the time recorded by the eIM when the target device interacts with the eIM through the device-side agent module, such as the time when the device actively reports a notification or responds to a command. The preset number of communications can be set according to actual needs, such as 20 times. The difference between two adjacent communication timestamps is calculated sequentially to obtain a sequence of adjacent communication intervals. The median of this sequence is taken as an estimate of the actual wake-up interval. Alternatively, the Exponentially Weighted Moving Average (EWMA) method can be used instead of the median, as long as this value accurately reflects the interval characteristics dominated by the periodic wake-up of the device by the PSM.

[0054] After obtaining the actual wake-up interval, this value is compared with the complete cycle duration corresponding to the target device. If the deviation between the actual wake-up interval and the complete cycle duration of the target device is greater than a preset deviation threshold, it indicates that the actual wake-up pattern of the device may have deviated significantly due to network drift or other reasons. When the deviation exceeds the threshold, a corrected wake-up window is determined based on the actual wake-up interval. Specifically, the last communication time of the target device is used as a new benchmark reference point, and the actual wake-up interval replaces the original complete cycle duration to recalculate the future wake-up time sequence of the device. The calculation method for each wake-up time is as follows: starting from the last communication time, an actual wake-up interval is added to obtain the next wake-up time, and a corrected wake-up window interval is constructed from this time and combined with the device's active duration parameter. Because this corrected wake-up window is based on the statistical analysis of the device's actual behavior, it is closer to the actual reachable time period of the device than the theoretical window calculated solely based on nominal parameters. Then, the trigger time is updated into the corrected wake-up window. The update method can refer to the aforementioned alignment logic, that is, in the corrected wake-up window sequence of the device, the currently allocated trigger time is adjusted to an appropriate position in the first wake-up window that can cover the time or the one immediately following it, thereby obtaining the updated trigger time for the device.

[0055] Through the above steps, the trigger time allocated to NB-IoT devices is no longer a random time point allocated based on priority ranking, but an attainable time that matches their inherent power-saving wake-up rules. This avoids invalid triggers caused by device sleep, reduces long waits and retries that may be caused by missing the wake-up window, and significantly improves the success rate of NB-IoT device trigger commands being delivered on the first attempt.

[0056] The fourth embodiment of the present invention relates to a batch configuration task grouping and scheduling method. This embodiment is a supplement and refinement to the foregoing embodiments, and specifically includes the following contents.

[0057] Step 103, which involves the control token bucket generating tokens at a target rate, includes: The token bucket generates tokens at the target rate, using a preset configuration rate as the target rate.

[0058] Specifically, in this embodiment, controlling the token bucket to generate tokens at a target rate is the core step in achieving orderly distribution and traffic shaping. The specific method for determining the target rate can be either a fixed rate or an adaptive dynamic rate, or a combination thereof, depending on the system operation and maintenance requirements and the network environment.

[0059] In one implementation, a fixed-rate mode is adopted, where a preset configuration rate is used as the target rate. The token bucket is controlled to generate tokens at this target rate. The capacity of the token bucket can be set as a multiple of the maximum concurrency limit; this embodiment does not impose specific limitations. The preset configuration rate is a fixed value pre-set by the system or carried in the task parameters. Its value is usually determined based on an assessment of the processing capacity limits of the network devices and the code management server. For example, it can be set as the maximum number of trigger commands sent per second allowed by the system to ensure stable operation. In this mode, the token bucket generates tokens uniformly at a constant rate throughout the entire task execution. Trigger commands in the waiting queue consume tokens and are sent sequentially according to a first-in-first-out or priority-based order.

[0060] Or, such as Figure 4 As shown, the control token bucket in step 103 generates tokens at the target rate, which is achieved through the following steps.

[0061] Step 401: Collect SM-DP+ side load metrics and CoAP ACK packet loss rate, and calculate the comprehensive load index based on the preset formula; Step 402: Determine the target rate based on the comprehensive load index, and adjust the target rate according to the changes in the comprehensive load index and preset rules.

[0062] Specifically, in another implementation, to cope with the complex operating environment of real-time fluctuations in network status and server load, this embodiment can also adopt an adaptive dynamic rate mode. The eIM first collects SM-DP+ side load metrics and CoAP ACK packet loss rate. The SM-DP+ side load metrics are quantitative parameters reflecting the current processing pressure of the code data preparation server, and may include monitoring data such as server response latency, concurrent session count, or resource utilization. CoAP, or Constrained Application Protocol, is an application layer protocol designed for resource-constrained devices and low-bandwidth networks. In IoT scenarios, it is widely used for lightweight signaling interaction between devices and servers. The CoAP ACK packet loss rate is the proportion of times the eIM does not receive an acknowledgment response after sending a CoAP request to the target device through the device-side proxy interface within a sliding observation window. This metric directly reflects the congestion level and signal quality of the communication link from the eIM through the mobile network to the terminal device.

[0063] Based on the above-mentioned indicator collection, a comprehensive load index is calculated using a preset formula. This formula takes the SM-DP+ side load index and CoAP ACK packet loss rate as input variables, and performs weighted or fused calculations to obtain a single comprehensive load index, which is used to uniformly measure the overall load level of the current end-to-end signaling link. Then, the target rate is determined based on the comprehensive load index, and the target rate is adjusted according to preset rules based on changes in the comprehensive load index. The basic logic of the adjustment is as follows: when the comprehensive load index is in a low range, it indicates that the current network and servers still have sufficient margin, and the target rate can be gradually increased according to the preset increment step size to speed up token generation, thereby completing batch tasks as soon as possible while ensuring system stability; when the comprehensive load index climbs to a high range, it indicates that the congestion risk has increased, and the target rate needs to be reduced according to the preset reduction factor or reduction step size to reduce token production, and then increased again after the load index recovers.

[0064] In the actual implementation process, the target rate can be adjusted according to the following logic: Phase 1: Slow Start In the initial stage of batch configuration task startup, eIM lacks empirical data on the actual carrying capacity of SM-DP+ and needs to quickly determine its capacity limit. The rules for the slow start phase are as follows: Initial velocity R0 = R max *0.1, where R max This represents the maximum number of concurrent connections. In each control cycle, if the overall load index LoadIndex < 1.0, the rate doubles; R new = min(R current *2, R max ), where R current For the current target rate, R new The updated target rate; The slow-motion phase ends and the normal control phase begins when any of the following occurs: When the overall load index LoadIndex > 1.0 (first overload signal detected), the current rate is recorded as R. ssthresh (Slow start threshold), perform multiplication and subtraction R new =R ssthresh *β, entering the normal control phase.

[0065] R current >R max (System limit reached), directly enter normal control phase.

[0066] Phase Two: Normal Addition After the slow-motion phase ends, the normal control phase begins. When LoadIndex < 1.0, R... new =min(R current +α, R max ), where α=R max *0.05; Phase Three: Multiplication and Subtraction When the overall load index LoadIndex ≥ 1.0, R new =max(R current +β,R min ), where β=0.5, R min =R max *0.05.

[0067] It should be noted that the above process is only an example of the adjustment process and does not constitute any limitation on this solution, as long as the target adjustment rate can be achieved based on the two statistical indicators.

[0068] With the above two optional target rate determination methods, the token bucket can work stably at a preset fixed rate in simple scenarios, and can also adaptively adjust the rate according to real-time load feedback in complex scenarios, thus ensuring the orderly distribution of triggering instructions while taking into account the robustness of the system and scheduling efficiency.

[0069] In another example, a waiting queue for trigger commands is formed based on each trigger time window, including: Arrange the trigger time windows in chronological order; Based on the sorting results, the trigger commands corresponding to the target devices in each trigger time window are extracted sequentially to form a waiting queue.

[0070] Specifically, the trigger time windows are first arranged in chronological order, based on their natural order on the timeline, with windows starting earlier placed first and those starting later placed last. Since the order of the trigger time windows inherently implies differences in grouping priority, arranging windows chronologically is equivalent to sorting them according to scheduling priority from highest to lowest. There may be gaps between adjacent trigger time windows created by preset buffer intervals. The arranged window sequence appears as sequential, non-overlapping waves on the timeline.

[0071] After arranging the trigger time windows, the trigger commands corresponding to the target devices in each trigger time window are extracted sequentially according to the arrangement result, forming a waiting queue. The extraction process is performed window by window according to the arrangement order. For the trigger time window currently being processed, all trigger commands corresponding to the target devices contained within it are extracted and added to the waiting queue in the order of their trigger times within that window. After processing all commands in one window, the process moves to the next arranged time window and repeats the above extraction operation until all trigger commands in all windows are included in the queue. The resulting waiting queue logically exhibits a segmented and ordered characteristic: the front of the queue corresponds to commands in earlier start time windows, the middle of the queue corresponds to commands in middle time windows, and the tail of the queue corresponds to commands in the latest start window; within the same window, commands are arranged in the order of their trigger times. This queue structure allows the subsequent token bucket to naturally follow the timing rule of processing high-priority windows first and low-priority windows later when distributing tokens according to the queue order, and also maintains a reasonable sending rhythm within the same window, providing a unified command sequence that directly interfaces with its rate control mechanism for the orderly distribution of tokens.

[0072] It should also be noted that eIM aggregates task-level (counts of devices in each state, completion percentage, estimated remaining time) and group-level (completion rate, throughput, failure rate) statistics in real time. It proactively issues an alarm when the group failure rate exceeds a threshold. After eIM sends a trigger command to each target device IPA, if the current time is earlier than the trigger time in the command, the IPA places the request in a local delay queue to wait. When the trigger time arrives, the IPA generates a random delay δ within a preset range, waits δ seconds, and then initiates the actual profile download. In direct mode, it connects to the SM-DP+ES9+ interface; in indirect mode, it uses an eIM proxy. When a download fails, the IPA can autonomously retry locally without requesting eIM to reschedule each time, reducing the centralized scheduling pressure on eIM. After each download attempt (whether successful or failed), the IPA sends a result notification to eIM via the ESPPA interface, including download time, success / failure status, and failure reason code, for eIM's target rate control module to collect load metrics.

[0073] The fifth embodiment of the present invention relates to a batch configuration task grouping and scheduling device, such as... Figure 5 As shown, this system includes: The request parsing module 501 is used to obtain batch configuration task requests, which include at least the target device corresponding to each configuration task request. The device grouping module 502 is used to group target devices, determine the trigger time window for each group of target devices based on the grouping results, and assign a corresponding trigger time to each target device in the group within the trigger time window; The instruction issuing module 503 is used to generate a trigger instruction including the trigger time for each target device in sequence, form a waiting queue of trigger instructions according to each trigger time window, control the token bucket to generate tokens at the target rate and distribute them to the trigger instructions in the waiting queue in sequence. The IPA interface module 504 is used to send the trigger command of the obtained token to the corresponding target device, so that the target device executes the configuration task request corresponding to the target device at the trigger time in the trigger command.

[0074] In some examples, the batch configuration task grouping and scheduling device of this embodiment further includes: The trigger time adjustment module is used to determine the wake-up window for each target device with network access type NB-IoT in the grouping results, based on the last communication time between each target device and eIM and the complete cycle duration (T3412) of the target device. If the trigger time of the target device is not within the wake-up window, the trigger time will be updated to the next wake-up window to obtain the updated trigger time of each target device.

[0075] The trigger time adjustment module is also used to obtain the communication timestamp of the preset number of communication times for each target device for NB-IoT devices with historical communication records, and calculate the median of adjacent intervals as the actual wake-up interval. If the deviation between the actual wake-up interval of the target device and the complete cycle duration of the target device is greater than the deviation threshold, then the corrected wake-up window is determined based on the actual wake-up interval, and the trigger time is updated into the corrected wake-up window to obtain the updated trigger time.

[0076] In summary, it is not difficult to see that this embodiment is a device embodiment corresponding to the aforementioned method embodiments. The implementation details described in the above method embodiments are still applicable and effective in this embodiment, and will not be repeated here.

[0077] The sixth embodiment of the present invention relates to an electronic device, such as... Figure 6 As shown, it includes at least one processor 602; and a memory 601 communicatively connected to at least one processor 602; wherein the memory 601 stores instructions executable by at least one processor 602, the instructions being executed by at least one processor 602 to enable at least one processor 602 to perform any of the above method embodiments.

[0078] The memory 601 and processor 602 are connected via a bus, which may include any number of interconnecting buses and bridges. The bus connects various circuits of one or more processors 602 and memory 601 together. 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 therefore will not be described further herein. A 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 processor 602 is transmitted over a wireless medium via an antenna, which further receives data and transmits it to processor 602.

[0079] Processor 602 is responsible for managing the bus and general processing, and can also provide various functions, including timing, peripheral interfaces, voltage regulation, power management, and other control functions. Memory 601 can be used to store data used by processor 602 during operation.

[0080] Another embodiment of the present invention relates to a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements any of the above-described method embodiments.

[0081] Another embodiment of the present invention relates to a computer program product, including computer instructions that, when executed by a processor, implement any of the above-described method embodiments.

[0082] That is, 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 the present invention. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0083] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0084] While the embodiments disclosed herein are as described above, the foregoing content is merely for the purpose of facilitating understanding of this disclosure and is not intended to limit this disclosure. Any person skilled in the art to which this disclosure pertains may make any modifications and changes in form and detail of the implementation without departing from the spirit and scope of this disclosure; however, the scope of patent protection of this disclosure shall still be determined by the scope defined in the appended claims.

Claims

1. A batch configuration task grouping and scheduling method, characterized in that, Applied to an eSIM IoT remote manager, the method includes: Obtain batch configuration task requests, wherein the batch configuration task requests include at least: the target device corresponding to each configuration task request; The target devices are grouped, and a trigger time window for each group of target devices is determined based on the grouping results. Within the trigger time window, a corresponding trigger time is assigned to each target device in the group. A trigger instruction including the trigger time is generated sequentially for each of the target devices, and a waiting queue for the trigger instructions is formed according to each of the trigger time windows. The token bucket is controlled to generate tokens at a target rate and distribute them sequentially to the trigger instructions in the waiting queue. The trigger instruction obtained from the token is sent to the corresponding target device so that the target device executes the configuration task request corresponding to the target device at the trigger time in the trigger instruction.

2. The method according to claim 1, characterized in that, The grouping of the target devices includes: The target devices are initially grouped according to their SLA levels to obtain the first grouping results. For each target device in the first grouping result, a second grouping is performed according to the network access type to obtain the second grouping result; For each target device in the second grouping result, it is grouped three times according to its geographical region ID to obtain the third grouping result; For the target device in each of the third grouping results of the network access type NB-IoT, the grouping is performed four times according to the PSM cycle to obtain the grouping result.

3. The method according to claim 2, characterized in that, The step of determining the trigger time window for each group of target devices based on the grouping results includes: Based on the network access type corresponding to the grouping result, determine the matching trigger rate coefficient and obtain the number of target devices in each group; The window length of each group is determined based on the trigger rate coefficient, the number of target devices in each group, and the preset window length calculation formula. Calculate the priority score for each group based on the different SLA levels, the network access type, the geographic region ID, and the preset priority coefficient corresponding to the PSM cycle. The trigger time window for each group is determined based on the priority score corresponding to each group, the preset task base time, the time window length corresponding to each group, and the preset buffer interval.

4. The method according to claim 3, characterized in that, The method further includes: For the target devices whose network access type is NB-IoT in the grouping results, the wake-up window corresponding to each target device is determined based on the last communication time between each target device and eIM and the complete cycle duration of the target device; When the trigger time of the target device is not within the wake-up window, the trigger time is updated to the next wake-up window to obtain the updated trigger time of each target device.

5. The method according to claim 4, characterized in that, For NB-IoT devices with historical communication records, the step of obtaining the update trigger time of each target device further includes: Obtain the communication timestamps of the preset number of communication times for each target device, and calculate the median of adjacent intervals as the actual wake-up interval; If the deviation between the actual wake-up interval of the target device and the complete cycle duration of the target device is greater than the deviation threshold, then a corrected wake-up window is determined based on the actual wake-up interval, and the trigger time is updated into the corrected wake-up window to obtain the updated trigger time.

6. The method according to claim 1, characterized in that, The control token bucket generates tokens at a target rate, including: Using a preset configuration rate as the target rate, the token bucket is controlled to generate tokens at the target rate; or, Collect SM-DP+ side load metrics and CoAP ACK packet loss rate, and calculate the comprehensive load index based on a preset formula; The target rate is determined based on the comprehensive load index, and the target rate is adjusted according to preset rules based on changes in the comprehensive load index.

7. The method according to claim 3, characterized in that, The step of forming a waiting queue for the trigger instruction according to each of the trigger time windows includes: Arrange the aforementioned trigger time windows in chronological order; Based on the sorting results, the trigger commands corresponding to the target devices in each of the trigger time windows are extracted sequentially to form the waiting queue.

8. A batch configuration task grouping and scheduling device, characterized in that, The device, used in an eSIM IoT remote manager, includes: The request parsing module is used to obtain batch configuration task requests, wherein the batch configuration task requests include at least the target device corresponding to each configuration task request; The device grouping module is used to group the target devices, determine the trigger time window for each group of target devices based on the grouping results, and allocate a corresponding trigger time for each target device in the group within the trigger time window; The instruction issuing module is used to generate a trigger instruction including the trigger time for each target device in sequence, form a waiting queue for the trigger instructions according to each trigger time window, and control the token bucket to generate tokens at a target rate and distribute them to the trigger instructions in the waiting queue in sequence. The IPA interface module is used to send the trigger instruction obtained from the token to the corresponding target device, so that the target device executes the configuration task request corresponding to the target device at the trigger time in the trigger instruction.

9. An electronic device, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the batch configuration task grouping scheduling method as described in any one of claims 1-7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the batch configuration task grouping scheduling method as described in any one of claims 1-7.

Images