Method and apparatus for generating a bill for eSIM multi-vendor signal data

Abstract

The application relates to the technical field of communication, in particular to a method and device for generating a bill of eSIM multi-vendor signal data. The method comprises the following steps: obtaining an original data packet of a vendor; activating a corresponding synchronization strategy processor according to the type of a time source identification (TSI) in the original data packet, so as to obtain a coordinated universal time (UTC) benchmark alignment unified timestamp; calculating a positive buffer and a negative buffer based on the obtained network delay jitter and packet loss rate; determining an elastic billing time window according to the unified timestamp, the positive buffer and the negative buffer; aligning multi-vendor original event streams based on the elastic billing time window, and constructing a time-sequenced logical consistent ordered event sequence; and generating a unified bill according to the ordered event sequence and a billing rule set.

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a method and apparatus for generating bills for eSIM multi-vendor signal data. Background Technology

[0002] An embedded subscriber identity module (eSIM) is a virtual SIM card integrated on the device's motherboard, allowing for remote configuration and switching of carrier networks without the need for physical insertion or removal. Compared to traditional SIM cards, its advantages include saving device space and supporting dynamic network switching (such as international roaming and multiple SIM cards on standby).

[0003] eSIM devices often support multiple communication protocols, and the time bases of different protocols are highly heterogeneous. This leads to data timestamp discrepancies between different systems (such as operator billing systems and supplier signal data) due to inconsistencies in time bases.

[0004] Traditional time window algorithms use UTC time as a reference, set a fixed time range, match the timestamps of signal data from each supplier with the window, and perform calibration processing on the data that falls within the window.

[0005] However, traditional time window algorithms struggle to cover the dynamic error accumulation in multi-protocol mixed scenarios. eSIM supports real-time billing on a minute / second basis, and the second-level tolerance of traditional sliding windows is insufficient to meet these requirements; therefore, improvements are urgently needed. Summary of the Invention

[0006] Therefore, it is necessary to provide a method and apparatus for generating billing statements for eSIM multi-vendor signal data that can reduce billing errors in multi-protocol mixed scenarios, in order to address the above-mentioned technical problems.

[0007] Firstly, this application provides a method for generating bills for eSIM multi-vendor signal data, the method comprising:

[0008] Obtain the supplier's raw data packets;

[0009] The corresponding synchronization policy processor is activated based on the type of Time Source Identifier (TSI) in the packet header of the original data packet to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0010] Based on the obtained network latency jitter and packet loss rate, calculate the positive buffer and negative buffer;

[0011] The flexible billing time window is determined based on a unified timestamp, positive buffer, and negative buffer.

[0012] Based on the elastic billing time window, the original event streams of multiple suppliers are aligned to construct an ordered event sequence with consistent temporal logic;

[0013] A unified bill is generated based on an ordered sequence of events and a set of billing rules.

[0014] In one embodiment, the corresponding synchronization policy processor is activated based on the type of Time Source Identifier (TSI) in the packet header of the original data packet to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference, including:

[0015] If the type of Time Source Identifier (TSI) in the header of the original data packet is the device local clock, then verify the device status and network signaling interaction records of the Power Management Unit (PMU) of the eUICC chip in the communication device.

[0016] If the PMU is in a dormant state and the PMU's network signaling interaction record shows no network signaling, then the communication device's local clock is used as a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0017] Otherwise, the consensus time of the blockchain nodes or the non-terrestrial network NTN time issued by the base station will be used as the unified timestamp for Coordinated Universal Time (UTC) alignment.

[0018] In one embodiment, if it is determined that the device state of the power management unit (PMU) of the eUICC chip is in a sleep state, the method further includes:

[0019] Inspect the internal temperature changes of the eUICC chip and analyze the fluctuation patterns of the clock crystal oscillator of the eUICC chip;

[0020] If the temperature changes are stable and the fluctuation pattern is normal, then the eUICC chip's sleep state time is reliable.

[0021] In one embodiment, based on the elastic billing time window, the original event streams from multiple vendors are aligned to construct an ordered sequence of events with consistent timing logic, including:

[0022] When a communication device is detected switching to an eSIM plan, the guard band width is determined based on the orbital type and altitude parameters of the communication satellite during the switching process.

[0023] Within the flexible billing time window, insert a protective band of the specified width;

[0024] Based on the flexible billing time window after inserting the guard band and the original event flow from multiple vendors, construct an ordered event sequence with consistent timing logic.

[0025] Among them, events within the protection band in an ordered event sequence are charged based on the lowest rate.

[0026] In one embodiment, after determining the guard band width based on the orbital type of the communication satellite during the handover process, the method further includes:

[0027] The Doppler frequency shift compensation value is calculated based on satellite orbit parameters, and the clock accuracy of the protection band is dynamically adjusted.

[0028] In one embodiment, if a 5G / 6G network slice handover event is detected, an ordered sequence of events with consistent timing logic is constructed by aligning the original event streams from multiple vendors based on the elastic billing time window, including:

[0029] NSSAI (Network Slice Selection Auxiliary Information) signaling is collected from the Session Management Function (SMF).

[0030] Analyze the target slice type and Service Level Agreement (SLA) priority parameters in the NSSAI change signaling;

[0031] Event weights are set based on SLA priority parameters, where an SLA priority coefficient is defined, and the weight of the slice switching event is set as the product of the weight of the basic communication event and the SLA priority coefficient.

[0032] A directed acyclic graph (DAG) event model is constructed using all events as vertices. The weights of the vertices of the slice switching event are products, the weights of the vertices of the ordinary communication event are the weights of the basic communication event, and the directed edges in the DAG represent the temporal order of the events.

[0033] Perform a weighted topological sort on the DAG to generate an ordered sequence of events.

[0034] In one embodiment, a weighted topological sort is performed on the DAG to generate an ordered sequence of events, including:

[0035] Parse the hierarchical structure in the NSSAI change signaling to obtain the depth value of each slice;

[0036] Based on the depth value of each slice, determine the weight value of the event vertex associated with that slice;

[0037] During the weighted topological sorting process, event vertices with higher weight values ​​are processed first to generate an ordered sequence of events.

[0038] In one embodiment, if a communication device triggers an international roaming time zone switching event, an ordered sequence of events with consistent timing logic is constructed by aligning the original event streams from multiple vendors based on the elastic billing time window, including:

[0039] Obtain the main timeline sequence based on a unified timestamp;

[0040] Parse the time zone identifier TZID and daylight saving time adjustment rules broadcast by the roaming base station to generate a localized timestamp for the auxiliary time axis;

[0041] Based on the relative position of the flexible billing time window to the UTC date change line, the flexible billing time window is split to obtain at least one sub-window:

[0042] Sort the original event streams from multiple vendors by a unified timestamp;

[0043] Iterate through each child window and bind the events within that child window to both the UTC time range label corresponding to the main timeline and the localized calendar date range label corresponding to the secondary timeline.

[0044] Output an ordered sequence of events with double timestamps; the events are ordered according to the time sequence logic of a unified timestamp.

[0045] In one embodiment, the flexible billing time window is split according to its relative position to the UTC date change line to obtain at least one sub-window, including:

[0046] If the flexible billing time window falls within a single UTC date, it remains intact;

[0047] If the flexible billing window spans K UTC date change points, the flexible billing window is split at each date change point; K is a positive integer greater than or equal to 1.

[0048] If the flexible billing time window includes leap seconds published by the International Earth Rotation Service (IERS), a split flexible billing time window is added at the leap second time point to obtain M consecutive sub-windows for output.

[0049] Where M=1, K+1, or K+2 including leap seconds.

[0050] Secondly, this application also provides an eSIM multi-vendor signal data billing device, comprising:

[0051] The acquisition module is used to acquire the supplier's raw data packets;

[0052] The time alignment module is used to activate the corresponding synchronization policy processor according to the type of Time Source Identifier (TSI) in the packet header of the original data packet, so as to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0053] The buffer calculation module is used to calculate positive and negative buffers based on the obtained network latency jitter and packet loss rate.

[0054] The window determination module is used to determine the flexible billing time window based on the unified timestamp, positive buffer, and negative buffer.

[0055] The sequence generation module is used to align the original event streams from multiple vendors based on the elastic billing time window and construct an ordered event sequence with consistent timing logic.

[0056] The billing module is used to generate a unified bill based on an ordered sequence of events and a set of billing rules.

[0057] The aforementioned method and apparatus for generating billing information for eSIM multi-vendor signal data activates corresponding synchronization strategies using Time Source Identifier (TSI), achieving nanosecond-level UTC alignment of multi-protocol data and eliminating time base heterogeneity deviations. Based on network latency jitter and packet loss rate calculations, dynamic buffers (positive / negative) are used to improve traditional second-level tolerance to millisecond-level adaptive adjustment, covering the dynamic error superposition in multi-protocol mixed scenarios. Combining a unified timestamp and dynamic buffer forms a real-time adjustable elastic billing time window, meeting the minute / second-level real-time billing accuracy requirements of eSIM. Aligning multi-vendor event streams based on the elastic window constructs an ordered event sequence, ensuring the correct causal relationship across vendor data and improving billing timing accuracy. Providing traceable billing evidence through a unified timestamp and ordered event chain reduces billing disputes caused by time deviations and supports adaptive expansion in heterogeneous network scenarios. Attached Figure Description

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

[0059] Figure 1 This is a flowchart of a method for generating bills for eSIM multi-vendor signal data in one embodiment;

[0060] Figure 2 A flowchart of the steps for constructing a temporally consistent ordered sequence of events in one embodiment;

[0061] Figure 3 A flowchart for constructing a temporally consistent ordered sequence of events in another embodiment;

[0062] Figure 4 This is a flowchart illustrating how to construct an ordered sequence of events with consistent timing logic by aligning the original event streams from multiple vendors based on an elastic billing time window in one embodiment.

[0063] Figure 5 This is a structural block diagram of a billing device for eSIM multi-vendor signal data in one embodiment. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0065] In one exemplary embodiment, such as Figure 1 As shown, a method for generating eSIM multi-vendor signal data bills is provided, including:

[0066] S101, Obtain the supplier's raw data packet.

[0067] In this context, raw data packets refer to the underlying communication data units sent by various providers, containing service content and packet header control information. A provider refers to an operator or network service provider offering communication services. The goal is to resolve the issue of multi-source data access, standardize the heterogeneous data packet formats from different providers, and provide raw materials for subsequent processing.

[0068] Optionally, a protocol parser can be used to identify the packet formats of different vendors (such as HTTP, MQTT, CoAP). Invalid packets (such as error check packets and duplicate packets) are filtered out, and the payload and header information are extracted. Private header fields from different vendors are mapped to a unified data model for easier subsequent processing.

[0069] S102, activate the corresponding synchronization strategy processor according to the type of Time Source Identifier (TSI) in the packet header of the original data packet, and obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0070] The Time Source Identifier (TSI) in this context refers to the field in the packet header that marks the time source (e.g., device clock, GPS clock). The Synchronization Strategy Processor is the module that selects the time calibration algorithm based on the TSI type. Coordinated Universal Time (UTC) is a globally unified time standard that avoids time zone differences. It eliminates time inconsistencies among multiple vendors, establishes a unified time coordinate system, and resolves the issue of event sequencing across vendors.

[0071] Optionally, obtain a unified timestamp aligned to the Coordinated Universal Time (UTC) reference, including:

[0072] TSI type identification: By parsing the TSI field in the packet header, the type of time source (such as local clock, GPS clock) can be determined.

[0073] Tiered synchronization strategy: When the local clock is reliable (e.g., in sleep mode and with a stable crystal oscillator), the device time is used directly. When the local clock is unreliable, UTC time is synchronized via the NTP protocol, or blockchain consensus time is adopted (tamper-proof).

[0074] Error compensation: Calculate the clock offset (such as the difference between the local clock and UTC) and dynamically adjust the timestamp.

[0075] S103, based on the obtained network latency jitter and packet loss rate, calculate the positive buffer and negative buffer.

[0076] Network latency jitter refers to the fluctuation range of data packet transmission delay. Packet loss rate refers to the proportion of data packets lost during transmission. Positive buffering refers to the maximum reserved delay time to prevent early events from being misjudged. Negative buffering refers to the maximum allowed lead time to prevent late events from being missed. To address network uncertainties, flexible time boundaries are established to ensure that events are not incorrectly filtered.

[0077] Optionally, calculate the positive buffer and negative buffer, including:

[0078] Parameter acquisition: Real-time monitoring of network latency and packet loss rate via ping-pong test or RTCP protocol.

[0079] Statistical modeling: Calculate the jitter range (e.g., latency fluctuation ±20ms) based on historical data within a 95% confidence interval.

[0080] Buffer calculation:

[0081] Positive buffer = average latency + 3 × standard deviation (covering extreme latency).

[0082] Negative buffer = the absolute value of minimum delay (to prevent premature triggering caused by clock slack).

[0083] S104. Determine the flexible billing time window based on the unified timestamp, positive buffer, and negative buffer.

[0084] The elastic billing time window refers to a dynamic time interval centered on a unified timestamp and bounded by positive and negative buffers. It creates adaptive time boundaries to accommodate event timing deviations caused by network fluctuations, thus preventing missed or duplicate billing.

[0085] Optionally, determine the flexible billing time window, including:

[0086] Window creation: Window start time = unified timestamp - negative buffer, window end time = unified timestamp + positive buffer.

[0087] Dynamic adjustment: The window width is expanded in real time according to changes in network quality (such as a sudden increase in packet loss rate).

[0088] Overlap handling: The overlapping parts of adjacent windows are merged using a weighted average algorithm.

[0089] S105 aligns the original event streams from multiple vendors based on the elastic billing time window, and constructs an ordered event sequence with consistent timing logic.

[0090] The multi-vendor raw event stream consists of a set of discrete events (such as connection, disconnection, and traffic changes) sent by each vendor. Consistent timing logic is maintained: events are arranged in the actual order of occurrence, not the order of reception. This addresses the issue of out-of-order events across vendors, establishes a correct causal chain of events, and ensures consistent billing logic.

[0091] Optionally, construct an ordered sequence of events with consistent timing logic, including: time window alignment: map each supplier's events into an elastic window and filter out invalid events outside the window.

[0092] Conflict resolution: Events with the same timestamp are sorted according to business priority (e.g., billing events take precedence over log events). Window edge events are located using bidirectional interpolation to determine their exact position.

[0093] Consistency verification: Verify the rationality of the event sequence through a cause-effect graph (e.g., connecting before disconnecting).

[0094] S106, Generate a unified bill based on the ordered event sequence and the billing rule set.

[0095] Here, the billing rule set refers to the preset billing strategies (such as by traffic, duration, or QoS level). The unified bill refers to a standardized billing report that integrates data from multiple vendors.

[0096] Understandably, this involves transforming ordered events into consumable billable results to achieve cross-vendor billing transparency.

[0097] Optionally, generate a uniform bill, including:

[0098] Rule matching: Associate the corresponding billing rules by event type (such as video call, file download).

[0099] Cost Calculation: Duration-based: Window end time - Window start time. Traffic-based: Accumulated packet size within the window. Hybrid: Combines QoS level and duration-based tiered billing.

[0100] Summary output: Generates multi-dimensional reports by user ID, business type, and time period, and supports multi-currency conversion.

[0101] In an exemplary embodiment, the corresponding synchronization policy processor is activated based on the type of Time Source Identifier (TSI) in the packet header of the original data packet to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference, including:

[0102] Step 1: If the type of Time Source Identifier (TSI) in the packet header of the original data packet is the device local clock, then verify the device status and network signaling interaction records of the Power Management Unit (PMU) of the eUICC chip in the communication device.

[0103] Understandably, when the time source is the device's local clock, its reliability needs to be verified. Local clocks are susceptible to power fluctuations and crystal oscillator drift. By checking the PMU status and network signaling, it can be determined whether the device is in a stable timing environment.

[0104] The Time Source Identifier (TSI) is a field in the packet header that marks the time source (e.g., 0x01 indicates a local clock, 0x02 indicates a GPS clock). The eUICC chip is an embedded general-purpose integrated circuit card that stores SIM card information and has a built-in PMU for power management. The Power Management Unit (PMU) is a hardware module that controls the chip's power consumption and records its sleep / wake-up state.

[0105] Optionally, verify the device status and network signaling interaction records of the power management unit (PMU) of the eUICC chip within the communication device, including:

[0106] Network signaling interaction logs: Control messages between the device and the base station (such as attach requests and location updates).

[0107] TSI type identification: Parse IP packet header extension fields (such as the Hop-by-Hop option in IPv6) and extract the TSI value.

[0108] PMU Status Inquiry: Read the PMU register status bits via the eUICC's SM-DP+ interface (Remote SIM Configuration Protocol):

[0109] Signaling record check: Query the signaling buffer of the baseband processor to count the number of signaling records in the last 30 seconds.

[0110] For example, if an NB-IoT device sends a data packet with TSI=0x01 (local clock), the system checks the sleep bit of the PMU register and finds no signaling record in the baseband buffer, then proceeds to the second step of judgment.

[0111] The second step is to use the local clock of the communication device as a unified timestamp aligned with the Coordinated Universal Time (UTC) reference if the PMU is in a dormant state and the PMU's network signaling interaction record shows no network signaling.

[0112] Understandably, when a device is in sleep mode and has no network interaction, the local clock is least affected by external interference. At this time, its timing result can be directly used as a UTC reference, avoiding the introduction of synchronization delays from external time sources.

[0113] Among them, Sleep mode: A low-power mode in which the device shuts down non-essential components (such as the RF module) and maintains only basic timing functions. No network signaling: No control signaling is sent or received for a continuous time T (e.g., 30 seconds). Uniform timestamp: A standardized time representation based on UTC (e.g., Unix timestamp).

[0114] Optional, hibernation state verification includes: confirming that the PMU hibernation bit is 1 and the CPU utilization is <5%.

[0115] Signaling activity detection includes: Signaling activity = Number of signaling messages / Monitoring duration; if the signaling activity is <0.1 messages / second, it is determined that there is no network signaling.

[0116] Clock reliability verification includes checking the readings of the internal temperature sensor of the eUICC. If the fluctuation is less than ±0.5℃, the temperature is considered stable.

[0117] Calculate the clock crystal oscillator frequency deviation, including: Frequency deviation = |(Measured frequency - Nominal frequency)| / Nominal frequency; if the frequency deviation < 10^-6, the crystal oscillator is considered normal;

[0118] Timestamp generation includes: Uniform timestamp = local clock value + time zone offset - clock cumulative error.

[0119] For example, when a smart meter reports meter reading data in sleep mode, the local clock shows 1696473600 seconds, the time zone offset is +8 hours, and the cumulative clock error is -0.002 seconds. Then, the unified timestamp = 1696473600 + 28800 - 0.002 = 1696502399.998 seconds.

[0120] Third, otherwise, use the consensus time of the blockchain nodes or the non-terrestrial network NTN time issued by the base station as the unified timestamp aligned with the Coordinated Universal Time (UTC) benchmark.

[0121] Understandably, when the local clock is unreliable, external trusted time sources such as blockchain or NTN are introduced to ensure the accuracy and tamper-proof nature of the time reference.

[0122] Among them, blockchain node consensus time: the globally consistent time achieved in the distributed ledger through algorithms such as PBFT / POS. Non-Terrestrial Network (NTN): a communication network provided by satellites or high-altitude platforms, carrying high-precision atomic clocks. UTC benchmark alignment: calibrating external time sources to the UTC time scale.

[0123] Optional blockchain time synchronization includes:

[0124] Connect trusted nodes in the consortium blockchain (such as BSC nodes deployed by operators).

[0125] Get the timestamp field of the most recent block (such as the timestamp field in Ethereum).

[0126] Application network latency compensation: Blockchain time = Node timestamp - Network round-trip latency / 2

[0127] Optional NTN time synchronization includes:

[0128] Parse the TOD (Time of Day) field in satellite signaling.

[0129] Compensation for relativistic effects caused by satellite motion: Δt = -2GM / (rc²) + v² / (2c²);

[0130] Gravitational redshift and motion time dilation: NTN time = satellite time + Δt

[0131] Optional time quality assessment, including: Time source quality score = Weight 1 × Stability + Weight 2 × Real-time performance + Weight 3 × Tamper-proof performance

[0132] The time source with the highest score was selected as the UTC benchmark.

[0133] For example, the local clock of a certain marine buoy device is unreliable. The NTN time obtained through the Beidou satellite is 1696502405.321 seconds. The relativistic effect Δt is calculated to be +0.0003 seconds. After network delay compensation, the UTC reference time is obtained as 1696502405.3213 seconds.

[0134] In an exemplary embodiment, if it is determined that the device state of the power management unit (PMU) of the eUICC chip is in a sleep state, the method further includes: checking the internal temperature change of the eUICC chip and analyzing the fluctuation pattern of the clock crystal oscillator of the eUICC chip; if the temperature change is stable and the fluctuation pattern is normal, then it is determined that the eUICC chip is reliable in the sleep state.

[0135] Understandably, a local clock is theoretically more stable when the device is in sleep mode, but its actual reliability still needs to be verified. Temperature variations and crystal oscillator fluctuations are two key factors affecting clock accuracy, and double verification can ensure the accuracy of timestamps.

[0136] The eUICC chip is an embedded SIM card that integrates a security processor and a clock module. Internal temperature variation refers to the heat fluctuations generated during chip operation, measured in degrees Celsius (°C). Temperature stability refers to the magnitude of temperature changes over a short period, reflecting the stability of the chip's operating environment.

[0137] Optionally, when checking internal temperature changes, the crystal oscillator frequency has a non-linear relationship with temperature (usually a cubic function): f(T) = f0[1 + α1(T-T0) + α2(T-T0)]. 2 +α3(T-T0) 3 ];

[0138] Where: f0: reference frequency (e.g., 32.768kHz) α1, α2, α3: temperature coefficients (typical value: α1≈10) -6 / ℃, α2≈10 -8 / ℃ 2 T0: Calibration temperature point (usually 25℃); when the temperature change exceeds ±5℃, the frequency deviation may reach ±1ppm, corresponding to an error of about 0.086 seconds per day.

[0139] Temperature values ​​are acquired every 500ms using the eUICC's built-in temperature sensor (such as LM75B). N consecutive samples (e.g., N=10) are collected to form a temperature sequence {T1, T2, ..., T...}. 10}. Calculate the temperature standard deviation: σ_T = √[Σ(T) i -mean(T)) 2 If σ_T < 0.5℃, then the temperature is considered stable.

[0140] Among them, clock crystal oscillator: a quartz crystal oscillator that provides a precise frequency reference.

[0141] Fluctuation law: The characteristics of crystal oscillator frequency changing over time are quantified by Allan variance.

[0142] Frequency stability: The long-term stability of the crystal oscillator output frequency, measured in ppm (parts per million).

[0143] Optionally, analyze the clock crystal oscillator fluctuation pattern, including: the crystal oscillator frequency fluctuation contains various noise components (thermal noise, flicker noise, etc.), and Allan variance is a standard method for assessing short-term stability.

[0144] σ_y 2(τ)=(1 / 2)×<[y(t+2τ)-2y(t+τ)+y(t)] 2 >

[0145] Where: y(t): normalized frequency deviation; τ: sampling interval; <>: time average;

[0146] The typical Allan variance of a TCXO crystal oscillator is 10. -10 ~10 -9 The magnitude corresponds to a frequency stability of ±0.001~±0.01ppm.

[0147] The crystal oscillator output is measured using a frequency counter built into the eUICC (such as the TIM input capture of the STM32). M consecutive measurements are taken at 1-second sampling intervals (e.g., M=1000), and the average frequency f_avg is calculated. The frequency deviation sequence δf is then calculated. i =(f i -f0) / f0×10 6 (Unit: ppm); Calculate Allan variance: σ_y 2 (1s)=(1 / 2M)×Σ[(δf i+2 -2δf i+1 +δf i ) 2 If σ_y 2 (1s) <10 -10 If so, the fluctuation is considered normal.

[0148] Conclusion: The time is reliable, and the local clock is used as the UTC reference.

[0149] In one exemplary embodiment, such as Figure 2 As shown, based on the elastic billing time window, the original event streams from multiple vendors are aligned to construct an ordered event sequence with consistent timing logic, including:

[0150] S201, when a communication device is detected switching to an eSIM plan, the guard band width is determined based on the orbital type and altitude parameters of the communication satellite during the switching process.

[0151] Understandably, during eSIM plan switching, changes in satellite orbit type and altitude can cause signal transmission delays and instability, necessitating a protection band to ensure billing accuracy. Flexible billing time window: A dynamically adjustable billing period to adapt to the instability of satellite communication. eSIM plan switching: Automatic switching of communication devices between different operator plans. Protection band width: An additional buffer added within the time window for error tolerance.

[0152] Optionally, the width of the protective strip can be determined, including:

[0153] Detect package switching events and record the time points;

[0154] Obtain the current orbital type (such as LEO, MEO, GEO) and altitude parameters of the communication satellite;

[0155] Calculate the basic protection band width based on a preset mapping table or formula (e.g., LEO satellites require a wider protection band due to their high speed).

[0156] Furthermore, after determining the guard band width based on the orbit type of the communication satellite during the switching process, the method also includes: calculating the Doppler frequency shift compensation value based on the satellite orbit parameters and dynamically adjusting the clock accuracy of the guard band.

[0157] Understandably, the Doppler effect caused by satellite motion can lead to clock skew, requiring dynamic compensation to ensure timing logic consistency. Doppler frequency shift compensation value: used to correct frequency changes caused by satellite motion. Clock accuracy: the precision of the in-band timestamp.

[0158] Optionally, the clock accuracy of the guard band can be dynamically adjusted, including: calculating the Doppler frequency shift based on satellite orbital parameters (velocity, inclination, etc.); converting the frequency shift value to a time compensation amount; and adjusting the clock synchronization accuracy within the guard band (e.g., increasing the clock pulse frequency).

[0159] S202, within the flexible billing time window, insert a protective band of the width of the protective band.

[0160] Understandably, a fault-tolerant interval is created within the elastic billing time window to handle event uncertainties during the handover process. Guard band insertion: Adding a buffer at the edge of the time window.

[0161] Optionally, within the flexible billing time window, insert a protective band of the width of the protective band, including:

[0162] Determine the start and end boundaries of the flexible time window;

[0163] Insert the calculated protective strip widths before and after the window;

[0164] The update time window boundary is the original boundary ± the width of the protection zone.

[0165] S203, based on the flexible billing time window after inserting the guard band and the original event stream from multiple vendors, construct an ordered sequence of events with consistent timing logic.

[0166] Among them, events within the protection band in an ordered event sequence are charged based on the lowest rate.

[0167] Understandably, integrating multi-vendor event streams ensures consistency in timing logic and avoids billing disputes. Multi-vendor raw event streams: unordered event records generated by different operators. Consistent timing logic: events are arranged in the actual order of occurrence. Lowest-price billing strategy: events within the protection band are billed at the lower price.

[0168] Optionally, construct an ordered sequence of events with consistent temporal logic, including:

[0169] Collect all original events from all suppliers within the new time window;

[0170] Events are timestamped and sorted based on the adjusted clock precision.

[0171] Detect and resolve timing conflicts (e.g., use satellite location to verify the order of events);

[0172] Events within the protected zone are marked and the lowest billing rule is applied.

[0173] In one exemplary embodiment, such as Figure 3 As shown, if a 5G / 6G network slice handover event is detected, an ordered sequence of events with consistent timing logic is constructed based on the elastic billing time window and the original event stream from multiple vendors, including:

[0174] S301, collect network slice selection auxiliary information NSSAI change signaling from the session management function SMF.

[0175] Understandably, this step aims to capture key triggering events for network slice switching. Session Management Function (SMF): A control plane network element in the 5G core network responsible for managing user PDU sessions; Network Slice Selection Auxiliary Information (NSSAI): A parameter used to identify the type of network slice required by the user; Change Signalling: Control plane signaling carrying new S-NSSAI information during PDU session modification or establishment.

[0176] S302, parse the target slice type and Service Level Agreement (SLA) priority parameters in the NSSAI change signaling.

[0177] Understandably, the purpose of this step is to extract key attributes from the change signaling used to determine event priority. Target slice type: refers to the SST (Slice / Service Type) and SD (Slice Differentiator) identifiers of the network slice to be accessed; Service Level Agreement (SLA): defines the set of parameters that define the quality of service (such as bandwidth, latency, and reliability) that the slice can provide; SLA priority parameters: specific values ​​in the SLA parameters used to indicate the importance or urgency of the slice's service.

[0178] S303 sets event weights based on SLA priority parameters.

[0179] Here, an SLA priority coefficient is defined, and the weight of the slice switching event is set as the product of the basic communication event weight and the SLA priority coefficient.

[0180] In other implementations, this weight value can also be determined by combining other factors, such as the slice's layer depth value.

[0181] Understandably, this step assigns processing priorities to slice handover events in a quantifiable manner. Event weight: a numerical value reflecting the importance of the event; Baseline communication event weight: a preset baseline weight value for ordinary data packet events (e.g., set to 1.0); SLA priority coefficient: an amplification factor mapped from the SLA priority parameter (e.g., coefficient 5.0 for SLA priority 1; coefficient 3.0 for priority 2). By multiplying these two, slice handover events with higher SLA levels will receive significantly higher weights.

[0182] S304, construct a directed acyclic graph (DAG) event model with all events as vertices.

[0183] In this DAG, the weights of the vertices of the slice switching event are products, the weights of the vertices of the ordinary communication event are the weights of the basic communication event, and the directed edges in the DAG represent the temporal sequence relationship between events.

[0184] Understandably, this step aims to establish a unified model that simultaneously reflects the timing and priority of events within the elastic billing time window. A Directed Acyclic Graph (DAG) is a graph theory model where vertices represent discrete events, directed edges represent causal or temporal dependencies between events, and the graph contains no cycles. In this model, both high-priority slice switching events and ordinary communication events are uniformly treated as vertices, and their order is fixed through directed edges, thus ensuring the temporal logic consistency of the model.

[0185] S305, perform a weighted topological sort on the DAG to generate an ordered sequence of events.

[0186] Understandably, this step is the final solution process for the model, aiming to output a sequence that both conforms to the actual order of occurrence and prioritizes key events. Weighted topological sorting: an algorithm that introduces vertex weights as a priority reference into the standard topological sorting algorithm.

[0187] Optionally, the implementation process includes: First, calculating the in-degree (i.e., the number of preceding events) of each vertex in the DAG; second, adding all vertices with an in-degree of 0 to a max-heap (priority queue), the queue is sorted according to the weight of the vertices, with higher-weight vertices having higher priority; then, performing the following operations in a loop: taking the highest-weight vertex from the queue, adding it to the final ordered event sequence, removing the vertex and all its outgoing edges, and updating the in-degree of its successor vertices; if the in-degree of a successor vertex becomes 0, adding it to the priority queue; repeating this process until the queue is empty, finally generating an ordered event list that strictly follows the temporal logic and prioritizes high-weight events.

[0188] In one exemplary embodiment, such as Figure 4 As shown, if a communication device triggers an international roaming time zone switching event, then based on the elastic billing time window, the original event streams from multiple providers are aligned to construct an ordered event sequence with consistent timing logic, including:

[0189] S401, obtain the main timeline sequence based on the unified timestamp.

[0190] Understandably, obtaining a master timeline sequence based on a unified timestamp aims to establish a globally consistent time benchmark and eliminate the impact of time zone differences on event sequencing. A unified timestamp typically refers to UTC time, a standard time that does not change with geographical location. The master timeline sequence is a continuous timeline based on UTC.

[0191] Optionally, the above steps can be implemented as follows: obtain accurate UTC time from GNSS satellites or a trusted time source; establish a synchronization mechanism between the local clock and UTC (such as the NTP protocol); and assign a uniform UTC timestamp to each captured event.

[0192] S402, parse the time zone identifier TZID and daylight saving time adjustment rules broadcast by the roaming base station, and generate a localized timestamp for the auxiliary time axis.

[0193] Understandably, the purpose of generating localized timestamps on the secondary timeline is to map UTC time to the user's perceived local time, meeting billing and user experience requirements. Time zone identifier (TZID): such as "Asia / Shanghai", defines the time zone offset and daylight saving time rules; Daylight saving time adjustment rules: local time rules regarding the enabling / disabling of daylight saving time; Secondary timeline: a time representation based on the local time zone, used to subsequently bind localized time tags to events.

[0194] Optionally, the above steps can be implemented as follows: extract the TZID from the broadcast message of the roaming base station (e.g., via SIB1 message); parse the time zone offset (e.g., UTC+8) and daylight saving time rule corresponding to the TZID; convert the UTC timestamp to local time and apply daylight saving time adjustment.

[0195] S403, based on the relative position of the flexible billing time window and the UTC date change line, perform window splitting on the flexible billing time window to obtain at least one sub-window.

[0196] Understandably, the purpose of implementing flexible billing time window splitting is to handle billing windows crossing the UTC date line and ensure billing accuracy during time zone changes. The UTC date line is roughly located at the 180° meridian, where dates change; window splitting involves dividing windows that cross the date line into multiple sub-windows to facilitate subsequent binding of corresponding localized calendar date labels to events per sub-window.

[0197] Optionally, the above steps are implemented as follows: determine the UTC start and end boundaries of the flexible billing window; determine whether the window crosses the UTC date change line (i.e., start date ≠ end date); if it crosses, split the window into multiple sub-windows according to the date change line (e.g., UTC day change time 00:00).

[0198] S404 sorts the raw event streams from multiple vendors by a unified timestamp.

[0199] Understandably, sorting event streams by a unified timestamp aims to ensure events are arranged in the actual order of occurrence, avoiding time zone discrepancies. Multi-vendor raw event streams consist of unsorted event records from different operators.

[0200] Optionally, the above steps can be implemented as follows: collect raw event data from all suppliers; sort the events in ascending order based on a unified UTC timestamp; and handle timestamp precision differences (such as nanosecond-level alignment).

[0201] S405, iterate through each child window and bind the events within that child window to both the UTC time range label corresponding to the main timeline and the localized calendar date range label corresponding to the secondary timeline.

[0202] Understandably, the purpose of binding dual time tags is to simultaneously preserve the global time sequence and local calendar representation of events, supporting multi-dimensional queries. UTC time range tags: such as "2025-06-04T12:00:00Z"; local calendar date range: such as "2025-06-05T08:00:00 (Asia / Shanghai)"; these events with dual time tags will constitute the basic data units of the final ordered event sequence.

[0203] Optionally, the above steps can be implemented as follows: traverse the events in each child window; add both UTC and local time stamps to each event; and establish a mapping relationship between the two time stamps (e.g., UTC time → local date).

[0204] S406 outputs an ordered sequence of events with double time labels.

[0205] The event sorting follows the time sequence logic of a unified timestamp.

[0206] Understandably, the purpose of outputting an ordered sequence with dual timestamps is to generate event records that conform to temporal logic and are easy for users to understand. Dual timestamps: The same event has both UTC and local time identifiers.

[0207] Optionally, the above steps can be implemented as follows: construct an event data structure containing dual timestamps; sort all events in ascending order by UTC timestamp; and output a formatted ordered sequence of events (e.g., JSON / CSV format).

[0208] Furthermore, based on the relative position of the flexible billing time window to the UTC date change line, the flexible billing time window is split to obtain at least one sub-window, including:

[0209] Scenario 1: If the flexible billing time window is within a single UTC date, then it remains intact.

[0210] Understandably, keeping windows within a single UTC date intact aims to simplify processing and avoid unnecessary window splitting. UTC date: A 24-hour cycle starting at UTC 00:00:00. UTC date change line: Roughly located at the 180° meridian, where dates change.

[0211] Optionally, the above steps can be implemented as follows: calculate the UTC dates of the start timestamp Tstart and the end timestamp Tend of the elastic billing window; determine whether Tstart and Tend belong to the same UTC date; if they belong to the same date, keep the window intact and do not split it.

[0212] Scenario 2: If the flexible billing time window spans K UTC date change points, split the flexible billing time window at each date change point.

[0213] Where K is a positive integer greater than or equal to 1.

[0214] Understandably, windows spanning multiple dates are divided by date boundaries to ensure that billing cycles align with calendar days. UTC date change point: 00:00:00 UTC daily. Sub-window: Small, consecutive windows formed after the split.

[0215] Optionally, the above steps can be implemented by: determining the UTC date range spanned by the window. Calculate the timestamp for each date change point. ;

[0216] Furthermore, at each date change point, a split window is generated. Sub-windows: Sub-window 1: Sub-window 2: ...child window .

[0217] Case 3: If the flexible billing time window includes the leap second time published by the International Earth Rotation and Reference Systems Service (IERS), add a split flexible billing time window at the leap second time point to obtain M consecutive sub-windows for output.

[0218] Where M=1, K+1, or K+2 including leap seconds.

[0219] Understandably, the purpose of splitting the window to include leap seconds is to handle special adjustments in the time system and ensure billing accuracy. A leap second is an extra second added to keep the difference between Coordinated Universal Time (UTC) and atomic time within 0.9 seconds. IERS (International Earth Rotation and Retirement Service) is responsible for issuing leap second announcements.

[0220] Optionally, the above steps are implemented as follows: Query the leap second table published by IERS to determine whether the window contains a leap second. If it does (e.g., 23:59:60 UTC), add a split window at that time point to generate (K+2 sub-windows (adding a leap second sub-window based on case two), for example: sub-window N: ;N+1 child windows: ;N+2 child windows: .

[0221] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0222] Based on the same inventive concept, this application also provides an eSIM multi-vendor signal data billing generation apparatus for implementing the eSIM multi-vendor signal data billing generation method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more eSIM multi-vendor signal data billing generation apparatus embodiments provided below can be found in the limitations of the eSIM multi-vendor signal data billing generation method described above, and will not be repeated here.

[0223] In one exemplary embodiment, such as Figure 5 As shown, an eSIM multi-vendor signal data billing generation device is provided, comprising:

[0224] Module 11 is used to acquire the supplier's original data packets;

[0225] Time alignment module 12 is used to activate the corresponding synchronization strategy processor according to the type of Time Source Identifier (TSI) in the packet header of the original data packet, so as to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0226] The buffer calculation module 13 is used to calculate the positive buffer and the negative buffer based on the obtained network latency jitter and packet loss rate.

[0227] The window determination module 14 is used to determine the elastic billing time window based on the unified timestamp, positive buffer, and negative buffer.

[0228] Sequence generation module 15 is used to align the original event streams of multiple vendors based on the elastic billing time window and construct an ordered event sequence with consistent timing logic.

[0229] Billing module 16 is used to generate a unified bill based on an ordered sequence of events and a set of billing rules.

[0230] The modules in the aforementioned eSIM multi-vendor signal data billing generation device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the corresponding operations of each module.

[0231] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0232] Obtain the supplier's raw data packets;

[0233] The corresponding synchronization policy processor is activated based on the type of Time Source Identifier (TSI) in the packet header of the original data packet to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0234] Calculate positive and negative buffers based on real-time network quality parameters;

[0235] The flexible billing time window is determined based on a unified timestamp, positive buffer, and negative buffer.

[0236] Based on the flexible billing time window and the original event flow from multiple vendors, construct an ordered event sequence with consistent temporal logic;

[0237] A unified bill is generated based on an ordered sequence of events and a set of billing rules.

[0238] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0239] Obtain the supplier's raw data packets;

[0240] The corresponding synchronization policy processor is activated based on the type of Time Source Identifier (TSI) in the packet header of the original data packet to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0241] Calculate positive and negative buffers based on real-time network quality parameters;

[0242] The flexible billing time window is determined based on a unified timestamp, positive buffer, and negative buffer.

[0243] Based on the flexible billing time window and the original event flow from multiple vendors, construct an ordered event sequence with consistent temporal logic;

[0244] A unified bill is generated based on an ordered sequence of events and a set of billing rules.

[0245] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0246] Obtain the supplier's raw data packets;

[0247] The corresponding synchronization policy processor is activated based on the type of Time Source Identifier (TSI) in the packet header of the original data packet to obtain a unified timestamp aligned with the Coordinated Universal Time (UTC) reference.

[0248] Calculate positive and negative buffers based on real-time network quality parameters;

[0249] The flexible billing time window is determined based on a unified timestamp, positive buffer, and negative buffer.

[0250] Based on the flexible billing time window and the original event flow from multiple vendors, construct an ordered event sequence with consistent temporal logic;

[0251] A unified bill is generated based on an ordered sequence of events and a set of billing rules.

[0252] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0253] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0254] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for generating bills for eSIM multi-vendor signal data, characterized in that, The method comprises: Obtaining the original data packet of the supplier; According to the type of the time source identification TSI in the original data packet header, activate the corresponding synchronization strategy processor, get the coordinated universal time UTC reference alignment unified timestamp; Based on the network delay jitter and packet loss rate obtained, calculate the forward and negative buffering; According to the unified timestamp, forward and negative buffering, determine the elastic billing time window; Based on the elastic billing time window, align the multi-supplier original event stream, and construct a time sequence logic consistent ordered event sequence; According to the ordered event sequence and the billing rule set, generate a unified bill.

2. The eSIM multi-vendor signal data billing generation method of claim 1, wherein, According to the type of the time source identification TSI in the original data packet header, activate the corresponding synchronization strategy processor, get the coordinated universal time UTC reference alignment unified timestamp, comprising: If the type of the time source identification TSI in the original data packet header is the device local clock, verify the device state of the power management unit PMU of the eUICC chip in the communication device and the network signaling interaction record; If the device state of the PMU is in sleep state, and the network signaling interaction record of the PMU is no network signaling, the device local clock of the communication device is used as the coordinated universal time UTC reference alignment unified timestamp; Otherwise, the blockchain node consensus time or the non-terrestrial network NTN time issued by the base station is used as the coordinated universal time UTC reference alignment unified timestamp.

3. The eSIM multi-vendor signal data billing generation method of claim 2, wherein, If it is determined that the device state of the power management unit PMU of the eUICC chip is in sleep state, the bill generation method of the eSIM multi-supplier signal data further comprises: Check the internal temperature change of the eUICC chip, and analyze the fluctuation rule of the clock crystal oscillator of the eUICC chip; If the temperature change is stable and the fluctuation rule is normal, it is determined that the time of the eUICC chip in sleep state is reliable.

4. The eSIM multi-vendor signal data billing generation method of claim 1, wherein, Based on the elastic billing time window, align the multi-supplier original event stream, and construct a time sequence logic consistent ordered event sequence, comprising: In the case of detecting that the communication device switches the eSIM package, determine the protection bandwidth based on the orbit type and altitude parameter of the communication satellite in the switching process; Insert a protection band with the protection bandwidth in the elastic billing time window; According to the elastic billing time window after inserting the protection band and the multi-supplier original event stream, construct a time sequence logic consistent ordered event sequence; Among the ordered event sequence, the events in the protection band adopt the low billing strategy.

5. The eSIM multi-vendor signal data billing generation method of claim 4, wherein, After determining the protection bandwidth based on the orbit type of the communication satellite in the switching process, the bill generation method of the eSIM multi-supplier signal data further comprises: Based on the satellite orbit parameter, calculate the Doppler shift compensation value, and dynamically adjust the clock accuracy of the protection band.

6. The eSIM multi-vendor signal data billing generation method of claim 1, wherein, If a 5G / 6G network slice switching event is detected, based on the elastic billing time window, align the multi-supplier original event stream, and construct a time sequence logic consistent ordered event sequence, comprising: Collect network slice selection assistance information NSSAI change signaling from the session management function SMF; Parsing a target slice type and a service level agreement (SLA) priority parameter in NSSAI change signaling; Setting an event weight based on the SLA priority parameter, wherein a SLA priority coefficient is defined, and a weight of a slice switching event is set as a product of a basic communication event weight and the SLA priority coefficient; Constructing a directed acyclic graph (DAG) event model with all events as vertices, wherein a weight of a slice switching event vertex is the product, and a weight of a common communication event vertex is the basic communication event weight, and a directed edge in the DAG represents a time sequence relationship between events; Performing weighted topological sorting on the DAG to generate an ordered event sequence.

7. The eSIM multi-vendor signal data billing generation method of claim 6, wherein, The performing of the weighted topological sorting on the DAG to generate the ordered event sequence comprises: Parsing a hierarchical structure in the NSSAI change signaling to obtain a depth value of each slice; Determining a weight value of an event vertex associated with the slice according to the depth value of the slice; In the process of performing the weighted topological sorting, a higher-weight event vertex is preferentially processed to generate the ordered event sequence.

8. The eSIM multi-vendor signal data billing generation method of claim 1 or 6, wherein, If an international roaming time zone switching event triggered by a communication device is detected, aligning multi-vendor original event streams based on the elastic billing time window to construct an ordered event sequence with consistent time sequence logic, comprising: Obtaining a main time axis sequence based on the uniform timestamp; Parsing a time zone identifier (TZID) and a daylight saving time adjustment rule broadcast by a base station in a roaming area to generate a secondary time axis localized timestamp; Performing window splitting on the elastic billing time window according to a relative position of the elastic billing time window and a UTC date change line to obtain at least one sub-window; Sorting the multi-vendor original event streams according to the uniform timestamp; Traversing each sub-window, and binding events in the sub-window to a UTC time interval label corresponding to the main time axis and a localized calendar date interval label corresponding to the secondary time axis at the same time; Outputting an ordered event sequence with double time labels; wherein event sorting follows the time sequence logic of the uniform timestamp.

9. The eSIM multi-vendor signal data billing generation method of claim 8, wherein, Performing window splitting on the elastic billing time window according to a relative position of the elastic billing time window and a UTC date change line to obtain at least one sub-window, comprising: If the elastic billing time window is located within a single UTC date, the elastic billing time window is kept intact; If the elastic billing time window spans K UTC date change points, the elastic billing time window is split at each date change point; K is a positive integer greater than or equal to 1; If the elastic billing time window contains a leap second time point published by the International Earth Rotation Service (IERS), the elastic billing time window is additionally split at the leap second time point to obtain M continuous sub-windows as output; Wherein, M = 1, K + 1, or K + 2 including a leap second.

10. An eSIM multi-vendor billing data generation apparatus, characterized by, The apparatus comprises: An acquisition module configured to acquire an original data packet of a vendor; A time alignment module configured to activate a corresponding synchronization strategy processor according to a type of a time source identifier (TSI) in a packet header of the original data packet, and obtain a uniform timestamp aligned with a Coordinated Universal Time (UTC) reference. a buffer calculation module, configured to calculate a positive buffer and a negative buffer based on the obtained network delay jitter and packet loss rate; a window determination module, configured to determine an elastic charging time window according to the uniform timestamp, the positive buffer and the negative buffer; a sequence generation module, configured to align multi-vendor original event streams based on the elastic charging time window, and construct an ordered event sequence with consistent timing logic; a charging module, configured to generate a uniform bill according to the ordered event sequence and a charging rule set.

Images