A base station heterogeneous computing resource cooperative scheduling method and system for edge intelligent algorithm center

Abstract

The application discloses a base station heterogeneous computing resource cooperative scheduling method and system for an edge intelligent algorithm center, relates to the field of computing resource cooperative scheduling, and aims at the problem that asynchronous state records cannot prove that heterogeneous resources are available at the same time, discovers candidates by state records, and verifies resource generations, current capacities and time limits and establishes conditional occupation by an agent actually controlling resources in the same round; after complete confirmation and submission, the resources are used in the stage of starting readiness, unified validity and execution enabling door control tasks, the task is not executed and the resources are released when a link is incomplete, so that partial conditional occupation is avoided as a basis for task execution, and the task is executed when necessary resources are incomplete.

Description

Technical Field

[0001] This invention relates to the field of collaborative scheduling of computing resources, and specifically to a method and system for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers. Background Technology

[0002] Edge computing centers typically aggregate processors, accelerators, device memory, and data transmission resources to handle the computing tasks generated by base station services. Different resources can be controlled by different nodes or devices. Each control entity generates a status record according to its own sampling period or resource events and sends the status record to the management side via the network. Due to the influence of sampling windows, message transmission latency, message order, and changes in device operating instances, multiple status records received by the management side at similar times may not correspond to the same state where resources are available simultaneously.

[0003] If the management side directly combines and displays available status records separately, and starts tasks requiring the coordinated execution of multiple heterogeneous resources accordingly, some resources may already be in use by other tasks when they are actually occupied, or the status records may still point to the running instance before the device was reset. This could lead to situations where some resources are occupied while others are rejected, tasks wait beyond the data validity boundary, or startup information only takes effect at some resources. Therefore, while using asynchronous status records to discover candidate resources, the entity actually controlling each necessary resource needs to verify the current status, and allow task execution only after all necessary resources have formed consistent and valid startup conditions. Summary of the Invention

[0004] To address the shortcomings of existing technologies, this invention proposes a collaborative scheduling method and system for heterogeneous computing resources of base stations for edge intelligent computing centers. This solves the problem that the joint availability judgment based on asynchronous state records cannot reflect the simultaneous availability of heterogeneous resources, leading to partial or incomplete task startup.

[0005] To achieve the above objectives, the present invention provides the following technical solution: a method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers, comprising: The base station computation task is analyzed to form the minimum resource combination and the latest start time. Based on the asynchronous state record with resource generation, a candidate combination covering the combination is formed and a round identifier is generated. The resource agent corresponding to the candidate combination verifies the resource generation, current freezeable capacity, and occupation deadline based on the same round of conditions for the occupation request. If the verification is successful, the share is frozen and a confirmation receipt is returned. The collaborative scheduling unit excludes old generation confirmation receipts and forms a joint confirmation result when the remaining receipts match the corresponding requests and cover the minimum resource combination. Based on this, the task startup control unit sends a submission command, and after obtaining successful submission receipts for all necessary resources, sends a startup preparation command. After obtaining all valid startup ready receipts, it generates and sends a unified activation token that binds the current round and the startup deadline boundary. Once the resource agent verification token is approved, the share will be changed to an activity preparation state that prohibits the use of tasks and an effective confirmation will be returned. The task initiation control unit opens a single execution enable gate at the task execution entry point only when the minimum resource combination is covered by the valid confirmation in the same round, the initiation deadline boundary has not been reached, and the activity preparation status of each necessary resource is valid, allowing the task to use resources. When the resource generation changes after the conditional occupancy is established but before the task is executed, the resource proxy invalidates the conditional occupancy of the old generation and releases the share. If a verification failure, timeout, or activity preparation failure occurs before task execution, keep the execution enable gate closed, terminate the current round, and safely release resources.

[0006] Furthermore, a collaborative scheduling system for heterogeneous computing resources of base stations for edge intelligent computing centers is proposed to implement the aforementioned collaborative scheduling method for heterogeneous computing resources of base stations for edge intelligent computing centers, including: The task resource parsing unit is used to parse the base station computing task and form the minimum resource combination and the latest start time. The collaborative scheduling unit is used to form a candidate combination that covers the lowest resource combination based on the asynchronous state record with resource generation, generate a round identifier and send a conditional occupancy request for the same round, exclude old generation confirmation receipts, form a joint confirmation result when the remaining receipts match the corresponding request and cover the lowest resource combination, and terminate the current round and send a cancellation command when the confirmation fails or timeout occurs. The resource proxy is used to verify the resource generation, current freezeable capacity, and occupation deadline. After verification, it freezes the share and returns a confirmation receipt. After receiving the submission instruction, it changes the valid conditional occupation to the submitted, pending start status and returns a submission success receipt. After verifying the start preparation instruction, it returns a start ready receipt. After verifying the unified effective token, it changes the share to the activity preparation status of prohibiting task use and returns an effective confirmation. When the resource generation changes after the conditional occupation is established but before the task is executed, it invalidates the old generation conditional occupation and releases the share. The task startup control unit is used to send a submission command based on the joint confirmation result, send a startup preparation command after obtaining successful submission receipts for all necessary resources, and generate and send a unified validity token binding the current round and the startup deadline boundary after obtaining all valid startup ready receipts. The single execution enable gate of the task execution entry point is opened only when the valid validity confirmation in the same round covers the minimum combination of resources, the startup deadline boundary is not reached, and the activity preparation status of each necessary resource is valid. If the verification fails, times out, or the activity preparation status becomes invalid during the above startup process, the execution enable gate is kept closed, the current round is terminated, and the resource agent is controlled to safely release resources.

[0007] Compared with existing technologies, it has the following advantages: This invention uses asynchronously generated state records for candidate resource discovery. The resource agent, which actually controls the necessary resources, verifies the resource generation, current freezeable capacity, and time limit within the same round before establishing conditional occupancy. Only when the confirmation covering the minimum resource combination is complete and all necessary resources have been submitted can subsequent startup control continue. This prevents state records from different sampling intervals or different running instances from being directly used as the basis for simultaneous resource availability. If a resource generation changes after conditional occupancy is established but before task execution, the old generation conditional occupancy becomes invalid, and the old generation confirmation receipt is excluded from joint confirmation, preventing the confirmation of an old running instance from being mistakenly used as the basis for valid resource occupancy in the current round.

[0008] This invention sets a single execution enable gate at the task execution entry point after startup preparation and unified activation. Each resource agent first converts the resources to an active preparation state that prohibits task use. Only after the task startup control unit obtains confirmation of the activation of all necessary resources is the task phase allowed to use the resources. If the confirmation receipt, successful submission receipt, startup ready receipt, or activation confirmation does not cover all necessary resources in the corresponding phase, the execution enable gate remains closed, and the resources are removed by revocation, release, or expiration to avoid the task starting to execute when the activation instruction is partially delivered. Attached Figure Description

[0009] Figure 1 This is a schematic diagram of the method flow of the present invention.

[0010] Figure 2 This is a schematic diagram of the system framework of the present invention. Detailed Implementation

[0011] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0012] like Figure 1 As shown, this embodiment provides a method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers. Figure 2 As shown, the edge computing center includes a task access unit, a task resource parsing unit, a collaborative scheduling unit, a task startup control unit, and resource agents that control heterogeneous resources. Heterogeneous resources may include central processing units, graphics processing units, neural network processors, programmable logic devices, device memory, storage queues, inter-node links, hardware codecs, or runtime licenses. Resource agents are deployed in nodes, device controllers, or runtime control programs capable of reading the current state of resources and actually freezing and releasing resource shares. Resource agents must have actual control over local shares.

[0013] Step 1: Analyze the base station computing task to determine the minimum resource combination and the latest start time.

[0014] The task access unit receives base station computing tasks submitted by the base station or the base station service system. Task input includes at least a task identifier, input data location, data validity deadline or service completion boundary, execution stage, deployment version, and resource requirements for each execution stage. Resource requirements include resource type, minimum capacity, device capabilities, access relationships, and usage stage. The task access unit checks the field format, capacity unit, data location, and time boundaries, and sends tasks that pass the checks to the task resource parsing unit. If fields are missing, capacity units are uncertain, execution stage relationships are contradictory, input data is unreachable, or the task has exceeded the service boundary at the time of receipt, the task access unit generates an unschedulable reason and terminates the current processing, no longer reading status records or requesting resources.

[0015] The task resource parsing unit obtains the execution chain record corresponding to the current deployment version. The execution chain record at least provides the input, output, necessary capabilities, resource dependencies, data access relationships between stages (hereinafter referred to as access edges), upper bounds of preparation and execution durations for each execution stage. The task resource parsing unit parses resource requirements according to the execution stage sequence and performs a deletion check for each resource requirement. After deleting a resource requirement, the task resource parsing unit re-verifies whether the first stage can obtain startup input, whether the necessary capabilities and resource dependencies of each stage are still covered, and whether the output of the current stage can reach the subsequent stage along the access edges. It also accumulates the upper bounds of preparation and execution durations for each stage in the remaining execution path after deletion, and compares the completion time corresponding to the accumulated result with the effective cutoff of input data or the business completion boundary. The task resource parsing unit deletes a resource requirement only if all stages can still be started, the outputs of each stage can still be read by the subsequent stages, and the remaining execution path does not exceed the applicable boundary; if any of these conditions are not met, the resource requirement is retained.

[0016] The task resource parsing unit generates a minimum resource combination through the aforementioned deletion checks. The minimum resource combination consists of necessary resource entries, each entry recording the resource type, minimum capacity, capability requirements, access relationship with input data or previous stage output, and usage stage. The same minimum resource combination is used for both candidate filtering and subsequent receipt integrity checks. If the task resource parsing unit cannot generate a complete minimum resource combination, it outputs a parsing failure result, and the task does not proceed to resource allocation.

[0017] The task resource analysis unit also determines the latest start time of the task. When the business logic directly specifies the latest start boundary, that boundary should be used; simultaneously, the effective cutoff time for input data should also be provided. and the deadline for business completion When, calculate according to the following formula: ; , These are the conservative preparation and execution times for the current deployment version, derived from deployment acceptance records, runtime configurations, or existing performance profiles of the version's execution chain. These times are determined before the start of this scheduling and remain unchanged. All three times use the same time base, and both times and durations are in seconds. If only one applicable deadline exists, the two durations mentioned above are subtracted from that deadline; if there are no finite boundaries, or the calculated... The task will not enter automatic scheduling if it is no later than the current time. Used to set the occupancy period and verification start time.

[0018] Step 2: Organize asynchronous state records, form candidate combinations, and generate round identifiers.

[0019] Each resource agent generates a status record according to its own sampling period or local resource events. The status record includes at least the resource identifier, resource type, location, available capacity, capabilities, access relationship, sampling sequence number, resource generation, generation time, and agent address. The sampling sequence number monotonically increases within the same resource identifier and generation, used to identify the order of records. The resource generation is used to distinguish different running instances corresponding to the same resource identifier. When a device is reset, a driver is reloaded, a logical resource is rebuilt, or a resource agent loses persistent state, the resource agent first changes the resource generation before generating a new status record, ensuring that the old generation record can no longer represent the new running instance.

[0020] The collaborative scheduling unit receives status records asynchronously sent by different resource agents and organizes the records using resource identifiers and resource generations as indexes. When a new status record is received for the same resource within the same resource generation, if the sampling sequence number of the new record is greater than that of an already saved record, the saved record is updated with the new record; if the sampling sequence number of the new record is less than that of the already saved record, the saved record is not updated. If two records have the same resource identifier, resource generation, and sampling sequence number but different capacity, capability, or access relationship, the collaborative scheduling unit marks the corresponding records as conflicting and does not use the conflicting content to form candidates. Status records are only used to discover resources that may meet the requirements and are not used as proof that multiple resources are available at the same time.

[0021] The sampling sequence number is only used for comparing the order of status records within the same resource identifier and the same resource generation. For different resource generations corresponding to the same resource identifier, the sampling sequence number is not used to compare the newness of the records. The resource generation is used to distinguish different running instances. After the resource agent changes the resource generation, the status record corresponding to the old resource generation no longer represents the current running instance. Subsequent candidate formation and condition occupancy are based on the status record corresponding to the current resource generation and the current verification result of the resource agent.

[0022] The coordinated scheduling unit matches the resource type, minimum capacity, capability conditions, and access relationships in the minimum resource combination item by item, forming a candidate combination of resources that can cover all necessary resource items. Each candidate combination also retains the resource identifier, resource generation, sampling sequence number, and resource agent address for use by conditional occupancy requests. When multiple candidate combinations exist, the request order can be determined based on resource location, input data residence location, inter-stage transmission path, planned load, or energy consumption. This ordering only determines which candidate combination to try first; it does not change the minimum resource combination, nor can it replace the resource agent's verification of the current generation and current capacity.

[0023] The collaborative scheduling unit maintains the candidate order that has not yet been attempted for this task. If no candidate exists that covers the minimum resource combination, the collaborative scheduling unit waits for the resource agent to provide a new conflict-free state record and re-forms candidates based on the new record. During the waiting period, it continuously verifies the latest start time and the conservative time required for completion conditions, confirmation, submission, startup preparation, effectiveness confirmation, and execution enablement. When the latest start time arrives, or when the remaining time is insufficient to complete the above control process, the collaborative scheduling unit outputs an unschedulable result and terminates the current scheduling. The unschedulable result records the actual reasons for the occurrence, such as missing candidates, resource agent rejection, resource generation changes, insufficient capacity, or unmet access relationships, for the task submitter to determine subsequent processing.

[0024] The collaborative scheduling unit selects a candidate combination from the untried candidate sequences and generates a unique allocation round identifier for this occupancy attempt. The round identifier corresponds to both a task and a candidate combination and is not reused with other occupancy attempts for that task. The collaborative scheduling unit sets the conditional occupancy deadline based on the latest start time. The occupancy deadline must not be later than the latest start time, and a conservative time limit is allowed between the two for receipt verification, submission processing, and start control. The occupancy deadline is written to the request using a unified time base adopted by the collaborative scheduling unit. When using local monotonic timing by resource agents, the request also carries a finite occupancy duration corresponding to the occupancy deadline. Each resource agent converts this to its local lease expiration point upon receiving the request. The resource agent performs local expiration control based on the local lease expiration point, confirming that the occupancy deadline in the receipt is still consistent with the corresponding request. Regardless of the method used, resource agents can only maintain conditional occupancy within finite boundaries. The unified time base is used by the collaborative scheduling unit to uniformly compare the latest start time, occupancy deadline, and start cutoff boundary. When using local monotonic timing for resource agents, each resource agent does not need to synchronize with other resource agents in absolute time. The local monotonic clock is only used to determine the local lease expiration point based on the limited occupancy duration and to perform local expiration control. The management side still uses the time represented by the unified time base in the request and receipt for cross-resource comparison.

[0025] Step 3: Send a conditional occupancy request and verify the current resource status.

[0026] The coordinated scheduling unit sends conditional occupancy requests to each resource agent in the candidate combination. Each request includes at least a task identifier, round identifier, target resource identifier, resource generation in the candidate record, requested capacity, occupancy deadline, and latest start time. When a resource agent controls multiple necessary resources within the same control domain, the request can carry multiple resource entries. The resource agent verifies and freezes the requested capacity corresponding to each resource entry one by one in the same ordered processing process, and the receipt shows the processing result of each resource entry.

[0027] The resource broker places conditional occupancy requests and events that change local capacity or resource generation into the same ordered processing channel. Events that change capacity or generation include activity allocation establishment and release, conditional occupancy establishment and cancellation in other rounds, device reset, driver reload, and logical resource reconstruction. The resource broker processes occupancy requests according to the processing order determined by this ordered processing channel, avoiding the use of capacity or generation that has expired before the request arrives. For example, the processing order can be determined according to the order in which events enter the ordered processing channel, or the resource broker can assign locally monotonically increasing event numbers to events entering the ordered processing channel and process them sequentially according to the event numbers; regardless of the method used, a single serial processing order is maintained for the same resource.

[0028] When processing a resource allocation request, the resource agent sequentially verifies the request fields, allocation expiration time, resource ownership, and resource generation. If the request fields are complete, the allocation period has not expired, the target resource is controlled by this agent, and the requested generation is the same as the current generation, the agent continues to verify the freezeable capacity.

[0029] Specifically, This indicates the total capacity that currently running instances can participate in scheduling. This indicates the capacity that has already been allocated to the activity; both of these values ​​originate from the local resource metering interface. This indicates the capacity that has not been withdrawn, expired, or released in other rounds and is still retained, including capacity corresponding to valid conditions, committed, pending, and activity-ready states, derived from the local round status table. Currently freezeable capacity. Calculate using the following formula: ; The requested capacity is denoted as , Not less than Upon successful verification, the capacity is confirmed. All capacities mentioned above are measured using the same resource unit, and each resource type is calculated and verified separately. If the source of the capacity is unknown, the unit cannot be converted, or the deduction result cannot be determined, the resource agent will reject the request.

[0030] After all verifications are successful, the resource agent establishes a conditional occupancy record using the round identifier, freezes the resource share corresponding to the request, and returns a confirmation receipt. The conditional occupancy record must at least store the task identifier, round identifier, resource identifier, resource generation, frozen capacity, occupancy deadline, and current status. Resource shares reserved for conditional occupancy and its subsequent submitted, pending, and activity-ready states cannot be allocated to other tasks until they are revoked, expired, or released. The confirmation receipt carries the task identifier, round identifier, resource identifier, resource generation, frozen capacity, and occupancy deadline, with each field matching the corresponding conditional occupancy request, for integrity verification by the collaborative scheduling unit. If any verification condition is not met, the resource agent does not freeze the capacity and returns a rejection receipt containing the corresponding resource entry and the reason for rejection.

[0031] When the same round identifier and the same request content arrive again, the resource broker reads the local round status table and returns the existing processing result, without repeatedly freezing or deducting capacity. If the task identifier, resource identifier, resource generation, requested capacity, or occupancy deadline corresponding to the same round identifier is inconsistent with the existing request, the resource broker returns conflicting round content and does not use the later content to modify the existing occupancy conditions. When requests from different rounds contend for the same capacity, the request that completes a valid freeze first in the resource broker's local ordered processing channel takes precedence, and subsequent requests are re-verified based on the current freezeable capacity after deducting the existing unreleased reserved capacity.

[0032] Step 4: Verify and confirm the receipt and generate a joint confirmation result.

[0033] The collaborative scheduling unit collects the acknowledgments for the current round based on the minimum resource combination as the verification benchmark. For each necessary resource in the minimum resource combination, the collaborative scheduling unit checks whether exactly one acknowledgment has been received, and checks whether the task identifier, round identifier, resource identifier, resource generation, frozen capacity, and occupation deadline are consistent with the corresponding occupation request. When all acknowledgment acknowledgments collectively cover the minimum resource combination, and the acknowledgment fields for each necessary resource are consistent, the generation is consistent, the capacity is met, and the resource has not expired, the collaborative scheduling unit forms a joint acknowledgment result. The joint acknowledgment result records the task identifier, round identifier, confirmed necessary resource entries, and common valid boundaries.

[0034] Let R represent the set of indices of all necessary resource items in the minimum resource combination, and r be the index of one of the resource items. This indicates the cutoff time that matches the verification request in the corresponding confirmation receipt. After adopting the same time base and unifying all times to seconds, a common valid cutoff time is established. Determine using the following formula: ; The earliest deadline, jointly defined by the resource occupancy period and the latest start time of the task in this round, serves as the start deadline boundary. When using local monotonic timing for resource agents, the collaborative scheduling unit still compares the occupancy deadlines expressed on the same time base in the request and confirmation receipts. Each resource agent executes local expiration control based on the local lease deadline calculated from the corresponding finite occupancy duration. The task start control unit sends a submission command based on the joint confirmation result; both the submission and start processes are predicated on the formation of this result.

[0035] Step 5: Complete resource submission and startup preparation.

[0036] After obtaining the joint confirmation result, the task initiation control unit sends a commit instruction for the same round to all relevant resource agents before the start deadline is reached. The commit instruction includes at least the task identifier, round identifier, necessary resource entries, and start deadline. When using local monotonic timing, the commit instruction also carries the remaining valid start time determined by the task initiation control unit based on the start deadline. Upon receiving the commit instruction, the resource agent checks whether the corresponding condition occupancy exists, whether the resource generation matches the condition occupancy record, whether the frozen share is still valid, and whether the task identifier, round identifier, and the necessary resource entries corresponding to this agent match the local condition occupancy record and the corresponding request. It also checks that the start deadline is not later than the occupancy deadline of the corresponding condition occupancy. If all checks pass, the resource agent changes the corresponding condition occupancy to a committed, pending start state, saves the task identifier, round identifier, necessary resource entries, and start deadline in the local pending start record, and returns a commit success receipt. If any check fails, the resource agent does not change the condition occupancy state and returns a rejection result.

[0037] When using absolute time to represent the start deadline boundary, the resource agent saves the absolute time carried in the commit instruction. When using local monotonic timed leases, the resource agent determines the local deadline point based on the remaining valid duration of the local lease occupied by the original conditions and the remaining valid duration of the start instruction carried in the commit instruction, ensuring that this deadline point is no later than the deadline point of the local lease occupied by the original conditions. The resource agent starts local timing when it enters the committed, pending start state. If a valid start activation instruction is not received by the local deadline point, the resource agent records the round as expired, rejects subsequent starts, releases the pending start share, and forms a release record. Subsequently, when the resource agent determines whether the current time has reached the start deadline boundary, it uses the start deadline boundary for absolute timed leases and the aforementioned local deadline point for local monotonic timed leases.

[0038] The task initiation control unit verifies the successful submission receipts corresponding to the minimum resource combination item by item. Only when the successful submission receipts collectively cover all necessary resources, and all receipts correspond to the same task, the same round, and the same start deadline, does the task initiation control unit send a start preparation instruction to all necessary resource agents. Each start preparation instruction carries the same task identifier, round identifier, necessary resource entries, and start deadline. Upon receiving the start preparation instruction, the resource agent checks whether its local status is submitted and pending initiation, whether the round, necessary resource entries, and start deadline match the local pending initiation record, and whether the current time is still before the start deadline. If the checks pass, the resource agent returns a start-ready receipt and continues to maintain the submitted and pending initiation status without executing the task; if the checks fail, the resource agent returns a start-ready rejection.

[0039] Step 6: Generate a unified activation token and establish an activity preparation state.

[0040] The task startup control unit collects startup readiness receipts based on the minimum resource combination. Only when all necessary resources are obtained before the startup deadline, and all startup readiness receipts for the same round, with identical content and not expired, does the task startup control unit generate a unique unified activation token. The unified activation token is bound to the task identifier, round identifier, necessary resource entries, and startup deadline, and corresponds to the startup preparation results for this round and the local pending startup records of each resource agent. The unified activation token is used only for one unified activation within this round. The task startup control unit loads the unified activation token into the startup activation command and sends a startup activation command with identical content to all necessary resource agents.

[0041] Upon receiving the activation command, the resource agent checks that its local status is still "Submitted, Pending Activation," and verifies that the task identifier, round identifier, necessary resource entries, and activation deadline match the local pending activation record. It also checks that the unified activation token corresponds to the activation preparation result for this round. If all checks pass and the command arrives before the activation deadline, the resource agent converts the corresponding share to the activity-ready state. The activity-ready state indicates that the resource has been reserved for this round, but it cannot be used during the task phase. The resource agent then returns an activation confirmation, which includes at least the task identifier, round identifier, resource identifier, resource generation, activation deadline, and activation token digest. Each field must match the local pending activation record and the received unified activation token.

[0042] Step 7: Verify the effective conditions and control the single execution enable gate.

[0043] The task initiation control unit aggregates effective confirmations according to the minimum resource combination and verifies whether each effective confirmation belongs to the same round, whether they jointly cover the minimum resource combination, and whether they are consistent with the corresponding local pending initiation records. The task initiation control unit only opens the single execution enable gate located at the task runtime environment entry point when it has obtained all valid effective confirmations for the same round, the current time is still earlier than the start deadline, and the activity preparation status of all necessary resources has not expired, been revoked, or released. After obtaining execution permission for this round through this entry point, the task runtime environment begins the first execution phase and allows each phase to use the resources already reserved for this round according to the phase dependencies in the execution chain, enabling the corresponding resources to enter activity allocation.

[0044] The execution enable gate is set at the unified entry point of the task runtime environment and is centrally controlled by the task startup control unit. The task phase obtains execution permission for this round through this entry point. Resource agents are only responsible for local resource state transitions and acknowledgments; they cannot trigger a task phase independently simply by receiving a unified activation token. If some resource agents receive the activation command early, the corresponding resources are still in an active ready state until the unified entry point meets all enabling conditions, at which point the task will begin execution.

[0045] If any necessary resource returns an effectiveness rejection, lacks an effectiveness confirmation, or has timed out, the start deadline has been reached, or the activity preparation state of any necessary resource has expired, been revoked, or released, the execution enable gate remains closed. The task start control unit terminates the current round and sends release instructions to resource agents that have entered the activity preparation state and revocation instructions to resource agents that are still in the submitted, pending start state. Resources in the activity preparation state have not yet been used for task execution, and resource agents release the corresponding share directly upon receiving the release instruction; resources still in the pending start state are released upon receiving the revocation instruction, and are automatically released at the start deadline if the revocation instruction has not yet arrived. If the release or revocation instruction is unreachable, the resource agent continues to reject late start effectiveness instructions according to the local deadline and deduplication records.

[0046] If any necessary resource returns a start-ready rejection, or if the task start control unit fails to obtain all start-ready receipts before the start deadline, the task start control unit must not generate a unified activation token, the execution enable gate must remain closed, and a single round of cancellation instructions must be sent to all submitted, pending resource agents. Upon receiving the cancellation instruction, the resource agent releases its pending start share. If the cancellation instruction is unreachable, the resource agent automatically releases its share upon reaching the start deadline. If duplicate start-preparation or start-effective instructions carry the same round and content, the resource agent returns the existing result without repeating the status change; if the start deadline, necessary resource entries, or unified activation tokens corresponding to the same round are inconsistent, the resource agent rejects the subsequent instruction.

[0047] Step 8: Execute the task and release resources and recover from anomalies.

[0048] Once the execution enable gate is opened, the task runtime environment uses resources bound to the current round and in an active allocation state according to the execution phase. Output generated in the previous phase is written to the accessible location determined by the minimum resource combination, and the subsequent phase reads this output through the corresponding access relationship. When the task completes normally or the task startup control unit explicitly terminates the task, the task startup control unit sends a release command with the same round identifier to each resource agent. The resource agent releases the active allocation and updates its local capacity, then forms a new status record with the current sampling sequence number and resource generation, for subsequent tasks to discover candidate resources. The release completion receipt, task end record, and new status record are used together to verify that the current round has exited.

[0049] The resource agent binds the local task process, runtime context, or verifiable execution instance identifier to the round identifier. Upon detecting normal termination, failed termination, or termination by a local security policy, the resource agent releases the activity share for this round, retains queryable end and release records, and generates a new status record; the resource agent can perform the above actions based on the local termination event.

[0050] For resources that cannot provide local termination events, a renewal period and a maximum duration boundary can be set for activity allocation. The task runtime environment provides renewal information consistent with the task and round on a periodic basis. When renewal is missing and the maximum duration boundary is reached, the resource agent terminates or isolates the task according to the resource's safe termination rules, confirms that the original execution instance has stopped using the corresponding share, and then releases the share for subsequent allocation.

[0051] In a typical implementation path, the base station submits a time-sensitive image analysis task. The execution chain corresponding to the deployment version includes preprocessing, inter-stage transmission, and inference. The task resource parsing unit forms a minimum resource combination based on the input-output relationship of each stage. This combination includes processing resources for preprocessing, device memory for storing stage data, transmission resources for transferring intermediate data, and a share of the neural network processor for inference. Processing resources and device memory are controlled by a first resource agent, the share of the neural network processor is controlled by a second resource agent, and transmission resources are controlled by a network resource agent.

[0052] Three resource agents asynchronously generate status records. After the collaborative scheduling unit organizes the records, it forms candidate combinations based on resource type, capacity, equipment capability, and the reachability relationship between preprocessing output and inference input, and generates a new round identifier for each candidate combination. Upon receiving a conditional occupancy request, each resource agent verifies the resource generation, current freezeable capacity, and occupancy deadline in its local ordered processing channel. If the verification is successful, the corresponding share is frozen and confirmation is returned. The collaborative scheduling unit obtains all valid confirmation receipts that jointly cover the lowest resource combination and whose fields are consistent with the request, forms a joint confirmation result, determines the common valid boundary as the start deadline boundary, and then hands over the joint confirmation result to the task start control unit.

[0053] The task initiation control unit sends a commit command carrying the start deadline boundary to the three resource agents. The agents verify local condition occupancy and command fields according to the aforementioned rules. Upon successful verification, they save the pending start record, enter the committed / pending start state, and return a commit success receipt. After all commit success receipts collectively cover the minimum resource combination, the task initiation control unit sends a start preparation command for the same round and the same deadline boundary.

[0054] After verifying the pending launch status and instruction content, the three agents return a launch ready receipt, at which point the task has not yet been executed. The task launch control unit collects all launch ready receipts covering the minimum resource combination before the launch deadline, generates a unified activation token binding the task identifier, round identifier, necessary resource entries, and launch deadline, and then sends a launch activation instruction carrying the token to the three agents.

[0055] After the three resource agents verify that the unified activation token matches the local pending startup record, they convert the corresponding resources to an active ready state and return an activation confirmation containing the task identifier, round identifier, resource identifier, resource generation, startup deadline boundary, and activation token digest. At this point, processing resources, device memory, transmission resources, and neural network processor shares are all reserved for this round, but these resources cannot be used during preprocessing, transmission, and inference phases. After the task startup control unit obtains all valid activation confirmations for the same round for the minimum shared resource combination, it reconfirms that the current time is still earlier than the startup deadline boundary and that the active ready state of each necessary resource is still valid. Subsequently, it opens a single execution enable gate at the task runtime environment entry point. If the startup deadline boundary has been reached or any active ready state has expired, the task startup control unit keeps the execution enable gate closed and terminates the current round.

[0056] After the task runtime environment obtains the execution license for this round, the first resource agent provides processing resources and device memory to the preprocessing stage, which reads the input data and forms intermediate data. The network resource agent provides a transmission share to the inter-stage transfer, passing the intermediate data to the inference node. The second resource agent provides a neural network processor share to the inference stage, which reads the intermediate data and forms the task result. After the task result is sent back to the result receiving location specified by the task, each resource agent releases its resource share according to the same round. In this example, the asynchronous state record is responsible for discovering candidate resources, the resource agents are responsible for verifying and retaining the current share, and the unified execution entry point aggregates the valid states of all necessary resources into a single task execution license.

[0057] Rejection or missing receipts may occur during the resource application process. If the collaborative scheduling unit receives a rejection receipt before forming a joint confirmation result, or fails to obtain confirmation receipt for a necessary resource before the common valid boundary, a joint confirmation result cannot be formed in this round. The collaborative scheduling unit sends a cancellation instruction for the same round to the resource agents that have already been confirmed. The resource agents release the conditional occupancy according to the round identifier and record the cancellation status. If the cancellation instruction fails to arrive due to communication interruption, the conditional occupancy automatically expires at the occupancy deadline, and the resource agent releases the frozen share.

[0058] Once the conditional occupancy for the current round has been revoked, or the unreachable resource proxy has expired and been released, the coordinated scheduling unit retrieves the next candidate from the untried candidate sequence. If the current time is still earlier than the latest start time, and the remaining time is sufficient to complete conditional occupancy, confirmation, submission, startup preparation, effectiveness confirmation, and execution enablement, the coordinated scheduling unit creates a new round identifier for the next candidate and continues to try. If the untried candidates are empty, the coordinated scheduling unit waits for a new conflict-free state record and re-forms candidates. When the latest start time arrives or the remaining time is insufficient to complete the full control process, the coordinated scheduling unit outputs an unschedulable result and ends the current scheduling, without retaining any occupancy that cannot be executed within the boundary.

[0059] After candidate records are formed but before conditional occupancy requests are processed, device resets, driver reloads, or logical resource reconstructions may change the resource generation. The resource broker checks the requested generation against the current generation and returns a rejection result indicating a generation inconsistency. The coordinated scheduling unit terminates the current round and cancels any established conditional occupancy accordingly; old state records in the cache and partial acknowledgments for other resources cannot overwrite this rejection. If rescheduling is required, candidates are formed based on the new generation state records, and a new round identifier is created.

[0060] When a resource generation changes after a conditional occupancy is established but before task execution, the resource agent invalidates the old generation's conditional occupancy and releases the corresponding share. The collaborative scheduling unit does not include subsequent old generation confirmation receipts in the joint confirmation result. When a resource enters the activity preparation state or a device failure occurs after activity allocation, the resource agent enters an execution failure state and terminates or isolates the corresponding execution instance according to local safe termination rules, then releases shares that can be safely released. The task startup control unit records this round as an execution failure. Subsequent recovery requires re-acquiring the new status records of each resource and creating a new round; conditional occupancy, submission results, startup readiness receipts, unified activation tokens, or activation confirmations from before the failure cannot be reused.

[0061] After the joint confirmation is formed, if any resource agent refuses to submit, or if the task initiation control unit fails to obtain a successful submission receipt covering all necessary resources before the initiation deadline, the task initiation control unit will not send an initiation preparation command, will keep the execution enable gate closed, and will send a cancellation command to resource agents that have already submitted or are still in a conditionally occupied state. Resource agents that have submitted and are awaiting initiation will release their shares upon receiving the cancellation command. If cancellation is unreachable, the share will be automatically released upon reaching the initiation deadline. Resource agents in the submitted and awaiting initiation state may not execute tasks before release.

[0062] Submit, start preparation, start activation, cancellation, and release instructions are processed idempotently according to round identifier and instruction content. Duplicate instructions with the same content in the same round return the existing result, and the capacity and running status remain unchanged; instructions in the same round but with different content are rejected.

[0063] For rounds that have been cancelled or expired, a deduplicated record will be retained, at least up to the latest start time of the task. Late submissions, start preparations, or start activation instructions will return a cancelled or expired result based on this record, the corresponding share will remain in the released state, and the round will remain terminated.

[0064] After the collaborative scheduling unit restarts, it first queries the local round status of each resource agent according to the task identifier and round identifier, and then verifies the logs saved by the management side with the agent's current record. The verification content includes task identifier, round identifier, resource identifier, resource generation, frozen capacity, and occupancy deadline. All items must be consistent with the corresponding query conditions and the agent's local occupancy records.

[0065] If all returned statuses collectively cover the minimum resource combination, field verification passes, all statuses are valid, and the task has not exceeded the latest start time, the collaborative scheduling unit re-forms a joint confirmation result and continues to submit. If fields are inconsistent, necessary resources are not covered, statuses are invalid, or the task has exceeded the latest start time, the resumption of submission stops, and existing conditional occupancy is released by a resource agent that can be contacted.

[0066] For rounds that have been committed but cannot be restored to a complete commit relationship or a complete start-up ready relationship, and for rounds that have entered the activity preparation state but cannot be restored to a complete effective confirmation relationship, the execution enable gate remains closed, and each resource agent releases its share after the start deadline is reached.

[0067] Two tasks in different rounds may overlap in acquiring some resources. For example, the first round freezes processing resources, and the second round freezes the neural network processor share, while neither round can acquire the other necessary resource. In this case, neither round can start with partial confirmation. The collaborative scheduling unit can choose to continue one round and cancel the other round according to the pre-configured task priority, latest start time, or round order; or it can exit both rounds after the waiting time reaches the occupancy deadline. The selected round must still complete the aforementioned joint confirmation, submission, start-ready, and effective confirmation in sequence, and open the execution enable gate before the start deadline, provided that all activity preparation states are valid, before the task can use the corresponding resources.

[0068] During execution, each resource agent saves records of resource occupancy establishment and release, resource generation changes, round status, and stage receipts. The task runtime environment saves execution enable gate status, resource usage records for each task stage, and task completion records. These records are associated within the same round, allowing traceability of whether the task had confirmation, submission, startup readiness, and effectiveness confirmation covering all necessary resources before using resources. Rejection, conflict, missing receipts, communication interruption, or generation change corresponding to gate closure, cancellation, and expiration release records are used to trace the reasons for non-execution or exit of the current round.

[0069] The above embodiments are only used to illustrate the technical methods of the present invention and are not intended to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical methods of the present invention without departing from the spirit and scope of the technical methods of the present invention.

Claims

1. A method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers, characterized in that, include: The base station computation task is analyzed to form the minimum resource combination and the latest start time. Based on the asynchronous state record with resource generation, a candidate combination covering the combination is formed and a round identifier is generated. The resource agent corresponding to the candidate combination verifies the resource generation, current freezeable capacity, and occupation deadline based on the same round of conditions for the occupation request. If the verification is successful, the share is frozen and a confirmation receipt is returned. The collaborative scheduling unit excludes old generation confirmation receipts and forms a joint confirmation result when the remaining receipts match the corresponding requests and cover the minimum resource combination. Based on this, the task startup control unit sends a submission command, and after obtaining successful submission receipts for all necessary resources, sends a startup preparation command. After obtaining all valid startup ready receipts, it generates and sends a unified activation token that binds the current round and the startup deadline boundary. Once the resource agent verification token is approved, the share will be changed to an activity preparation state that prohibits the use of tasks and an effective confirmation will be returned. The task initiation control unit opens a single execution enable gate at the task execution entry point only when the minimum resource combination is covered by the valid confirmation in the same round, the initiation deadline boundary has not been reached, and the activity preparation status of each necessary resource is valid, allowing the task to use resources. When the resource generation changes after the conditional occupancy is established but before the task is executed, the resource proxy invalidates the conditional occupancy of the old generation and releases the share. If a verification failure, timeout, or activity preparation failure occurs before task execution, keep the execution enable gate closed, terminate the current round, and safely release resources.

2. The method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, The minimum resource combination and the latest start time are determined, including: Obtain the execution chain record of the current deployment version. The execution chain record provides the input, output, necessary capabilities, resource dependencies, access edges, upper bound of preparation time, and upper bound of execution time for each stage. Delete resource requirements one by one, check inputs and outputs, necessary capabilities, resource dependencies and access edges in the order of stages, and add the upper bound of the preparation and execution time of the remaining path. Delete only when each stage can still be started, the output can still be read by the subsequent stage, and the remaining path does not exceed the effective cutoff of input data or the boundary of business completion. Take the earliest of the valid cutoff time for input data and the cutoff time for business completion, and subtract the conservative preparation time and conservative execution time in sequence to obtain the latest start time.

3. The method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, Status record updates include: The resource agent changes the resource generation and forms a new state record when the device is reset, the driver is overloaded, the logical resource is rebuilt, or the persistent state is lost. Within the same resource generation of the same resource, the collaborative scheduling unit retains the state record with the largest sampling sequence number and no content conflict. Out-of-order records with sampling sequence numbers smaller than the already saved state records shall not overwrite the already saved state records, and state records with the same sampling sequence number but conflicting content shall be excluded.

4. The method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, Freezeable capacity verification includes: The resource broker places conditional occupancy requests and events that change local capacity or resource generation in the same ordered processing channel. It obtains the total capacity and active allocated capacity of the currently running instance from the local resource metering interface, and obtains other capacities that have not been revoked, expired, or released and are still retained by other rounds from the local round status table. If the capacity involved in the deduction and comparison belongs to the same resource and has the same unit, the frozen resource share will be not less than the requested capacity after deducting the activity-allocated capacity and other capacities that have not been revoked, expired, or released and are still retained by other rounds from the total capacity. The request will be rejected if the source of any capacity is unknown or the unit cannot be converted.

5. A method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, Receipt verification and duplicate request processing include: The collaborative scheduling unit verifies that the task identifier, round identifier, resource identifier, resource generation, frozen capacity, and occupation deadline in the confirmation receipt are all consistent with the corresponding occupation request. If all of these are consistent with the corresponding conditions, the confirmation receipt is determined to match the corresponding request. When a resource agent receives a duplicate conditional occupancy request with the same round identifier and request content, it returns the existing processing result in the local round status table without freezing the resource share again. If the task identifier, resource identifier, resource generation, requested capacity, or occupation deadline corresponding to the same round identifier are inconsistent, the returned round content will conflict and the existing conditional occupation will be rejected when the content is modified later.

6. The method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, Rescheduling after a change in resource generation includes: Candidate combinations are formed based on the status records of the new resource generation, and new round identifiers are generated.

7. The method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, Startup deadline control and token verification, including: The common valid boundary in the joint confirmation results is the earliest of the occupancy deadline and the latest start time, and it serves as the start deadline boundary. The unified activation token is bound to the task identifier, round identifier, necessary resource items and start deadline boundary, and corresponds to the start preparation results of this round and the local pending start record of the resource agent; After the resource agent verifies the above correspondence and approves it, the share will be transferred to the activity preparation state; The resource agent maintains this boundary in the committed, pending, and activity-ready states and does not allow tasks to use resources. If the task execution has not started by the start deadline, the agent rejects subsequent startups and releases the resource share.

8. A method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, Candidate failure handling includes: If the current candidate fails and is withdrawn or released upon expiration, and if it is still earlier than the latest start time and there is enough time remaining to complete the condition occupancy, confirmation, submission and start, the cooperative scheduling unit selects the next candidate in the order of candidates that have not yet been tried. If there are no candidates, wait for a new conflict-free state record. If the latest start time arrives or the remaining time is insufficient, output an unschedulable result and end the current scheduling.

9. A method for collaborative scheduling of heterogeneous computing resources of base stations for edge intelligent computing centers according to claim 1, characterized in that, The state is restored after the reboot, including: After the collaborative scheduling unit restarts, it queries the local round status of each resource agent according to the task identifier and round identifier; The task identifier, round identifier, resource identifier, resource generation, frozen capacity, and occupation deadline in each returned status are consistent with the corresponding query conditions and the local conditions of the resource agent. When all returned statuses jointly cover the minimum resource combination, are not invalid, and the task has not exceeded the latest start time, a joint confirmation result is formed again and the submission continues. If any condition is not met, the commit is not resumed, and the queried condition holdings are released.

10. A base station heterogeneous computing resource collaborative scheduling system for edge computing centers, used to implement the base station heterogeneous computing resource collaborative scheduling method for edge computing centers as described in any one of claims 1 to 9, characterized in that, include: The task resource parsing unit is used to parse the base station computing task and form the minimum resource combination and the latest start time. The collaborative scheduling unit is used to form a candidate combination that covers the lowest resource combination based on the asynchronous state record with resource generation, generate a round identifier and send a conditional occupancy request for the same round, exclude old generation confirmation receipts, form a joint confirmation result when the remaining receipts match the corresponding request and cover the lowest resource combination, and terminate the current round and send a cancellation command when the confirmation fails or timeout occurs. The resource proxy is used to verify the resource generation, current freezeable capacity, and occupation deadline. After verification, it freezes the share and returns a confirmation receipt. After receiving the submission instruction, it changes the valid conditional occupation to the submitted, pending start status and returns a submission success receipt. After verifying the start preparation instruction, it returns a start ready receipt. After verifying the unified effective token, it changes the share to the activity preparation status of prohibiting task use and returns an effective confirmation. When the resource generation changes after the conditional occupation is established but before the task is executed, it invalidates the old generation conditional occupation and releases the share. The task startup control unit is used to send a submission command based on the joint confirmation result, send a startup preparation command after obtaining successful submission receipts for all necessary resources, and generate and send a unified validity token binding the current round and the startup deadline boundary after obtaining all valid startup ready receipts. The single execution enable gate of the task execution entry point is opened only when the valid validity confirmation in the same round covers the minimum combination of resources, the startup deadline boundary is not reached, and the activity preparation status of each necessary resource is valid. If the verification fails, times out, or the activity preparation status becomes invalid during the above startup process, the execution enable gate is kept closed, the current round is terminated, and the resource agent is controlled to safely release resources.

Images