An emergency communication system based on 5G network slicing

Abstract

This invention discloses an emergency communication system based on 5G network slicing, relating to the field of communication technology. It includes: a first analysis module for acquiring task level information and communication request type information uploaded by terminals under multiple access states, and constructing a task scheduling factor group, wherein the task scheduling factor group includes task level values ​​and request type identifiers; a second analysis module for acquiring the current network slice resource occupancy rate and remaining capacity, calculating the resource risk coefficient of each slice based on the occupancy rate and remaining capacity, and forming a slice resource risk set; a scheduling determination module for comparing each item according to the task scheduling factor group and the slice resource risk set; and a task update module for binding requests to all tasks determined to require reassignment and performing slice-priority reassignment. This invention constructs a behavior recognition and anomaly determination mechanism to perform real-time intelligent analysis and automatic marking of key behaviors and emergencies.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and more specifically to an emergency communication system based on 5G network slicing. Background Technology

[0002] With the continuous development and deployment of 5G network slicing technology, emergency communication systems are gradually introducing sliced ​​resource scheduling mechanisms. These mechanisms attempt to achieve hierarchical scheduling and real-time support for communication tasks in different scenarios by constructing dedicated communication channels that match task types. Existing methods can, under conditions of sufficient resources, perform preliminary classification of terminal tasks based on communication request types and execute resource allocation strategies based on static priority rules. This demonstrates a certain degree of service differentiation capability and can meet the communication needs of some critical tasks in routine scenarios.

[0003] However, existing systems generally face two core technical bottlenecks in complex environments such as multi-task concurrency, network resource constraints, and frequent unforeseen events, specifically including: (1) The lack of a dynamic matching mechanism between task level and slice resource status makes it difficult to accurately identify and ensure the communication continuity of high-priority tasks in the event of resource shortage or high incidence of emergencies. (2) The lack of a systematic verification mechanism for the consistency of terminal data access, time synchronization and repeated binding during task scheduling can easily lead to redundant or mismatched binding data, affecting the stable execution of subsequent resource scheduling chains. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides an emergency communication system based on 5G network slicing, the system comprising: The first analysis module S11 is used to obtain task level information and communication request type information uploaded by terminals under multiple access states, and construct a task scheduling factor group, wherein the task scheduling factor group includes task level value and request type identifier. The second analysis module S12 is used to obtain the current network slice resource occupancy rate and remaining capacity, calculate the resource risk coefficient of each slice based on the occupancy rate and remaining capacity, and form a slice resource risk set. The scheduling determination module S13 is used to compare the task scheduling factor group with the slice resource risk set item by item. When the task level value is higher than the preset priority threshold and the slice resource risk coefficient bound to the corresponding request type is higher than the preset resource risk threshold, it is determined that the task binding request needs to be reassigned. The task update module S14 is used to perform a slice-priority reassignment operation on all task binding requests that are determined to need to be reassigned. The operation includes releasing low-level task connections bound to high-risk slices, reallocating available slice resources according to the remaining capacity, and updating the task binding record.

[0005] Furthermore, the steps for constructing the task scheduling factor group are as follows: S111: By parsing the task level information uploaded by terminals under multiple access states, extracting structured entries containing task level values ​​and establishing an index mapping, outputting task level value entries for comparison. S112, Based on the communication request type information uploaded by terminals under multiple access states, extract the structured entries containing request type identifiers and establish an index mapping, and output the request type identifier entries for comparison. S113, Based on the task level value entry and the request type identifier entry, perform a one-to-one index pairing check and remove missing index items to generate a valid combination entry that satisfies the pairing constraints; S114, by writing valid combination entries into a unified record structure and retaining the task level value and request type identifier, a task scheduling factor group containing the task level value and request type identifier is generated.

[0006] Furthermore, the steps for generating a task scheduling factor group that includes task level values ​​and request type identifiers are as follows: S114.1, By comparing the terminal source consistency flags of the task level value entry and the request type identifier entry, the combined rows with inconsistent sources are eliminated; S114.2, Based on the access timestamp of the task level information and the access timestamp of the communication request type information, perform time overlap verification and delete rows with non-overlapping times; S114.3, perform duplicate processing on lines that contain duplicate task level values ​​and request type identifiers; S114.4, based on the valid combination rows after verification, backfill the task level value and request type identifier, and output the refined and verified task scheduling factor group.

[0007] Furthermore, the steps to form a risk set for sliced ​​resources are as follows: S121: By reading the current network slice resource occupancy rate, obtain a record row containing the occupancy rate of each slice and keep the slice identifier consistent to form an occupancy rate record set; S122, Based on the remaining capacity of the current network slice resources, obtain the record rows containing the remaining capacity of each slice and keep the slice identifier consistent to form a set of remaining capacity records; S123, based on the occupancy rate record set and the remaining capacity record set, perform line-by-line calculation under the premise that the slice identifier is consistent, and generate the resource risk coefficient corresponding to each slice; S124, by optimizing the resource risk coefficients corresponding to each slice, writing the optimized resource risk coefficients and slice identifiers into a unified record structure, and combining them to obtain a slice resource risk set containing all slice records.

[0008] Furthermore, the steps to optimize the resource risk coefficients corresponding to each slice are as follows: S124.1, by performing numerical standardization on the occupancy rate and remaining capacity of the same slice at the current time, we obtain standardized values ​​of occupancy rate and remaining capacity that are easy to synthesize and calculate. S124.2, Generate a risk deviation correction factor for each slice based on the standardized values ​​of occupancy rate and remaining capacity; S124.3 calculates the optimized resource risk coefficient for each slice by multiplying the resource risk coefficient with the risk deviation correction factor.

[0009] Furthermore, the steps for determining a task binding request that requires reallocation are as follows: S131, by reading the task level values ​​in the task scheduling factor group and comparing them item by item with the preset priority threshold, the record rows with task level values ​​higher than the preset priority threshold are filtered and a candidate set is formed. S132, based on the request type identifier in the candidate set, retrieve the slice resource risk set and locate the corresponding resource risk coefficient to establish a numerical pair for item-by-item comparison; S133, by comparing the resource risk coefficient with the preset resource risk threshold item by item, the record row that meets the condition of being higher than the preset resource risk threshold is selected as the risk hit item; S134, based on the risk hit item that simultaneously satisfies the task level value being higher than the preset priority threshold and the resource risk coefficient being higher than the preset resource risk threshold, output the task binding request that needs to be reassigned.

[0010] Furthermore, the steps for outputting the task binding request that needs to be reassigned are as follows: S134.1, By comparing the consistency of the slice identifiers of the task scheduling factor group and the slice resource risk set again, the record rows with inconsistent slice identifiers are removed. S134.2, Based on the fixed threshold order of the preset priority threshold and the preset resource risk threshold, execute the secondary judgment process of first the task level value and then the resource risk coefficient, and solidify the judgment order. S134.3, by performing duplicate removal processing on record rows that simultaneously meet both conditions, duplicate rows are merged and the first valid record is retained; S134.4, based on the valid records after deduplication and merging, backfill the output target entries to form a final consistent task binding request that needs to be reassigned.

[0011] Furthermore, the steps for performing slice-first reallocation are as follows: S141, by locating slices in the slice resource risk set whose resource risk coefficient is higher than the preset resource risk threshold, identify the corresponding high-risk slices and establish a list of high-risk slices; S142, Search the task scheduling factor group item by item according to the high-risk slice list, determine the low-level task connections bound to the high-risk slices and form a list to be released; S143, by performing release actions item by item on the release list, reclaim the available slice resources occupied by low-level task connections and record the remaining capacity value after release; S144: Based on the remaining capacity value after release, select available slice resources for each task binding request that needs to be reallocated and complete the reallocation, then update the task binding record.

[0012] Furthermore, the steps to update the task binding record are as follows: S144.1, by reading the request type identifier of each task binding request that needs to be reassigned, select an available slice resource that matches the request type identifier and has sufficient remaining capacity to support it; S144.2, Write a new slice identifier for the corresponding task entry based on the selected available slice resources and complete the binding action, keeping it consistent with the original task level value; S144.3, by establishing one-to-one change entries for the original slice identifier and the new slice identifier in the task binding record, the order of release and allocation is recorded to fix the redistribution order; S144.4, based on the changed entries, complete the writing and perform consistency verification on all affected entries, and output the verified update task binding record.

[0013] Compared with the prior art, the beneficial effects of the present invention are as follows: This invention constructs a multi-dimensional pairing relationship between task scheduling factor groups and slice resource risk sets to achieve dynamic identification of high-priority tasks under resource-scarce environments, thereby improving the system's real-time level perception of incoming tasks and enhancing the accuracy of task resource mapping. Furthermore, this invention optimizes the precision of the scheduling factor data structure by performing source consistency checks, timestamp overlap judgments, and duplicate combination removal between task level values ​​and request type identifiers, thereby improving the traceability and processing stability of task-bound data. Furthermore, this invention achieves efficient screening of tasks requiring reallocation by using a dual threshold joint judgment mechanism based on task level value and resource risk coefficient, thereby improving the depth of risk linkage analysis between task connections and sliced ​​resources, and thus enhancing the timeliness and accuracy of resource reallocation control strategies. Meanwhile, by releasing low-level connections and reconstructing binding records, combined with a log tracking structure that tracks the release and allocation order, this invention achieves orderly control of the task binding change process, thereby improving the stability of dynamic resource scheduling. In summary, this invention constructs a behavior recognition and anomaly determination mechanism to achieve real-time intelligent analysis and automatic labeling of key behaviors and emergencies. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.

[0015] Figure 1 This is a block diagram of an emergency communication system based on 5G network slicing provided in Embodiment 1 of the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, 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, 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.

[0017] Please see Figure 1 As shown, this embodiment discloses an emergency communication system based on 5G network slicing, the system comprising: The first analysis module S11 is used to obtain task level information and communication request type information uploaded by terminals under multiple access states, and construct a task scheduling factor group, wherein the task scheduling factor group includes task level value and request type identifier. Specifically, the steps for constructing task scheduling factor groups are as follows: S111: By parsing the task level information uploaded by terminals under multiple access states, extracting structured entries containing task level values ​​and establishing an index mapping, outputting task level value entries for comparison. In one specific embodiment, task level information uploaded by terminals in multiple access states is collected uniformly through an access gateway. The task level information includes a task level field, a terminal identifier field, an access timestamp field, and other content. It should be noted that: the collected task level field is extracted as a task level value, and each task level information is bound to its terminal identifier field to generate a "task level value - terminal identifier" pair; each "task level value - terminal identifier" pair is a task level value entry.

[0018] S112, Based on the communication request type information uploaded by terminals under multiple access states, extract the structured entries containing request type identifiers and establish an index mapping, and output the request type identifier entries for comparison. In one specific embodiment, communication request type information uploaded by terminals in multiple access states is uniformly obtained through the access gateway. The communication request type information includes a request type field, a terminal identifier field, an access timestamp field, and other contents. It should be noted that: the collected request type field is extracted as a request type identifier, and each communication request type information is bound to its terminal identifier field to generate a "request type identifier - terminal identifier" pair; each "request type identifier - terminal identifier" pair is a request type identifier entry, which is used for subsequent indexing and pairing with task level value entries.

[0019] S113, Based on the task level value entry and the request type identifier entry, perform a one-to-one index pairing check and remove missing index items to generate a valid combination entry that satisfies the pairing constraints; In one specific embodiment, the task level value entries and request type identifier entries are indexed and matched one-to-one based on the terminal identifier field. It should be noted that: when there is a missing terminal identifier in the task level value entry or the request type identifier entry, or when the same terminal identifier corresponds to multiple records, it is judged as a missing index item and removed; when the terminal identifier of a task level value entry and a request type identifier entry are the same, they are combined as a valid combined entry.

[0020] S114, By writing valid combination entries into a unified record structure and retaining the task level value and request type identifier, a task scheduling factor group containing the task level value and request type identifier is generated. In one specific embodiment, the unified record structure is a task scheduling factor table, and each record in the table contains three fields: terminal identifier, task level value, and request type identifier. It should be noted that: a task scheduling factor group is constructed by writing valid combination entries line by line, where each record is formed by pairing a task level value with a request type identifier, which is used for subsequent resource risk assessment and processing.

[0021] Specifically, the steps for generating a task scheduling factor group that includes task level values ​​and request type identifiers are as follows: S114.1, By comparing the terminal source consistency flags of the task level value entry and the request type identifier entry, the combined rows with inconsistent sources are eliminated; In one specific embodiment, the terminal source consistency mark is added by the access gateway when data is accessed, and is used to mark the access source device number of each piece of data; It should be noted that the combined row is only retained if the terminal source consistency flag of the task level value entry and the request type identifier entry are completely consistent; otherwise, it is removed to ensure that the combined row has a single source and the index corresponds accurately. S114.2, Based on the access timestamp of the task level information and the access timestamp of the communication request type information, perform time overlap verification and delete rows with non-overlapping times; In one specific embodiment, the access timestamp adopts a unified millisecond-level standard clock; It should be noted that when the difference between the access timestamp of the task level information and the communication request type information does not exceed the overlap threshold, it is considered as a time-overlapping line; otherwise, it is considered as a time-disoverlapping line and is deleted. Preferably, the overlap threshold can be set to 500 milliseconds to ensure that the task level value and the request type identifier are paired information uploaded by the same terminal within the same access period.

[0022] S114.3, perform duplicate processing on lines that contain duplicate task level values ​​and request type identifiers; Duplicate lines refer to the simultaneous occurrence of completely identical task level values ​​and request type identifier combinations under the same terminal identifier; It should be noted that when duplicate rows exist, only the earliest valid combination is retained, and other rows with the same combination are deleted to prevent duplicate entries from affecting the determination of subsequent scheduling priorities. S114.4, based on the valid combination rows after verification, backfill the task level value and request type identifier, and output the refined and verified task scheduling factor group; A complete record is formed by rewriting the task level value and request type identifier from the valid combination row into the corresponding field of the task scheduling factor table; It should be noted that the task scheduling factor group after refinement and verification only contains the combination of task level values ​​and request type identifiers that are consistent in origin, coincide in time, and have no duplication, which can be directly called by the scheduling determination module S13 to perform subsequent priority determination.

[0023] The second analysis module S12 is used to obtain the current network slice resource occupancy rate and remaining capacity, calculate the resource risk coefficient of each slice based on the occupancy rate and remaining capacity, and form a slice resource risk set. Specifically, the steps to form a risk set for sliced ​​resources are as follows: S121: By reading the current network slice resource occupancy rate, obtain a record row containing the occupancy rate of each slice and keep the slice identifier consistent to form an occupancy rate record set; In one specific embodiment, the network management controller retrieves the occupancy rate field of all registered slices at the current moment and synchronously obtains the corresponding slice identifier field. It should be noted that: the occupancy rate field of each slice at the same time is bound to the slice identifier field to form an "occupancy rate - slice identifier" pair, and then grouped and organized into an occupancy rate record set according to the slice identifier, which is used for subsequent matching and calculation with the remaining capacity record set; S122, Based on the remaining capacity of the current network slice resources, obtain the record rows containing the remaining capacity of each slice and keep the slice identifier consistent to form a set of remaining capacity records; In one specific embodiment, the remaining capacity field of all currently registered slices is obtained synchronously through the network management controller, and the corresponding slice identifier field is read. It should be noted that: the remaining capacity field of each slice is bound to the slice identifier field to form a "remaining capacity-slice identifier" pair, and then the remaining capacity records are grouped and organized according to the slice identifier. S123, based on the occupancy rate record set and the remaining capacity record set, perform line-by-line calculation under the premise that the slice identifier is consistent, and generate the resource risk coefficient corresponding to each slice; In one specific embodiment, the slice identifier is used as the matching index to pair the occupancy record set and the remaining capacity record set one by one; When the slice identifier of a occupancy record row is exactly the same as that of a remaining capacity record row, the resource risk coefficient is calculated. The calculation formula is as follows: In the formula, For the first Resource risk coefficient of strip slices, For the first Slice occupancy rate Standardize the remaining capacity to a value; Standardized values ​​of remaining capacity The calculation formula is: In the formula, For the first The remaining capacity of the slice. , These are the minimum and maximum remaining capacities for all slices; It should be noted that: The coefficient is dimensionless. , , As a unit of capacity, when the occupancy rate is high and the standardized value of the remaining capacity is low, An increase in the value indicates a higher resource risk for the slice. S124, by optimizing the resource risk coefficients corresponding to each slice, writing the optimized resource risk coefficients and slice identifiers into a unified record structure, and combining them to obtain a slice resource risk set containing all slice records; In one specific embodiment, the unified record structure is a slice risk record table, and each record contains a slice identifier and a resource risk coefficient field; It should be noted that a slice resource risk set is constructed by writing the calculated resource risk coefficients and corresponding slice identifiers one by one.

[0024] S124, by optimizing the resource risk coefficients corresponding to each slice, writing the optimized resource risk coefficients and slice identifiers into a unified record structure, and combining them to obtain a slice resource risk set containing all slice records; Specifically, the steps to optimize the resource risk coefficients corresponding to each slice are as follows: S124.1, by performing numerical standardization on the occupancy rate and remaining capacity of the same slice at the current time, we obtain standardized values ​​of occupancy rate and remaining capacity that are easy to synthesize and calculate. The standardized formula for the remaining capacity is as follows: In the formula, For the first Standardized values ​​for the occupancy rate of slices. For the first Slice occupancy rate , These represent the maximum and minimum occupancy rates of all slices, respectively. Furthermore, the formula for generating the normalized value of the remaining capacity references the normalized value of the remaining capacity from step S123. ; S124.2, Generate a risk deviation correction factor for each slice based on the standardized values ​​of occupancy rate and remaining capacity; Represented as: In the formula, For the first Risk bias correction factor for strip slices; It should be noted that when the standardized value of occupancy is significantly higher than the standardized value of remaining capacity, it indicates that the current resources of the slice are heavily occupied and the available capacity for allocation is small. The optimized resource risk coefficient is amplified, reflecting the increased resource tension. When the standardized value of remaining capacity is high, it indicates that there are still many available resources in the slice and the current occupancy level is low. The optimized resource risk coefficient is reduced, reflecting that the risk assessment value tends to be in a safe state.

[0025] S124.3, by multiplying the resource risk coefficient with the risk deviation correction factor, the optimized resource risk coefficient of each slice is obtained; The optimized resource risk coefficient for each slice; The optimized resource risk coefficients are backfilled into the corresponding slice records, and the slice resource risk set containing all slice identifiers and the corrected resource risk coefficients is output.

[0026] The scheduling determination module S13 is used to compare the task scheduling factor group with the slice resource risk set item by item. When the task level value is higher than the preset priority threshold and the slice resource risk coefficient bound to the corresponding request type is higher than the preset resource risk threshold, it is determined that the task binding request needs to be reassigned. Specifically, the steps for determining a task binding request that requires reallocation are as follows: S131, by reading the task level values ​​in the task scheduling factor group and comparing them item by item with the preset priority threshold, the record rows with task level values ​​higher than the preset priority threshold are filtered and a candidate set is formed. In one specific embodiment, the task level value of each record in the task scheduling factor group is read sequentially, compared with a preset priority threshold, and only the record rows that are higher than the threshold are retained. These record rows are then combined into a candidate set. It should be noted that this operation is used to preemptively eliminate low-level tasks, ensuring that subsequent risk assessments focus on tasks that require priority handling.

[0027] S132, based on the request type identifier in the candidate set, retrieve the slice resource risk set and locate the corresponding resource risk coefficient to establish a numerical pair for item-by-item comparison; In a specific embodiment, based on the request type identifier of each record in the candidate set, a record with the same slice identifier is searched in the slice resource risk set, the resource risk coefficient of the record is extracted, and combined with the task level value of the original record to form a set of numerical pairs containing the task level value and the resource risk coefficient. It should be noted that this step ensures that each high-level task record is directly associated with its corresponding resource usage status.

[0028] S133, by comparing the resource risk coefficient with the preset resource risk threshold item by item, the record row that meets the condition of being higher than the preset resource risk threshold is selected as the risk hit item; In one specific embodiment, the set of numerical pairs is traversed, the resource risk coefficient in each record is read, and compared with a preset resource risk threshold. Only records with values ​​higher than the threshold are retained and marked as risk hits. It should be noted that only tasks with high resource risk will continue to be included in the redistribution judgment scope to avoid unnecessary interference with tasks with stable resource status. S134, based on the risk hit item that simultaneously satisfies the task level value being higher than the preset priority threshold and the resource risk coefficient being higher than the preset resource risk threshold, output the task binding request that needs to be reassigned.

[0029] Specifically, the steps for outputting the task binding request that needs to be reassigned are as follows: S134.1, By comparing the consistency of the slice identifiers of the task scheduling factor group and the slice resource risk set again, the record rows with inconsistent slice identifiers are removed. In one specific embodiment, the slice identifiers of the recorded rows in the candidate set and the slice resource risk set are compared, and only the rows in which the slice identifiers of the records on both sides are completely consistent are retained, in order to ensure that the task record and the resource status correspond one-to-one.

[0030] S134.2, Based on the fixed threshold order of the preset priority threshold and the preset resource risk threshold, execute the secondary judgment process of first the task level value and then the resource risk coefficient, and solidify the judgment order. In one specific embodiment, the task level value of each record in the candidate set is determined, and only the record rows with a priority value higher than a preset priority threshold are retained. Then, the resource risk coefficient of these records is determined, and only the record rows with a priority value higher than a preset resource risk threshold are retained, so as to form an intermediate result set that is filtered in order. It should be noted that the priority threshold and resource risk threshold are set based on historical data analysis. S134.3, by performing duplicate removal processing on record rows that simultaneously meet both conditions, duplicate rows are merged and the first valid record is retained; Specifically, by performing a deduplication operation on the record rows using the slice identifier and request type identifier as a combined primary key, duplicate record rows are removed, only the record that appears for the first time is retained, and the remaining records are combined into a valid record set; It should be noted that within a task scheduling factor group, the same request type identifier may be repeatedly associated with multiple task level values. If deduplication is not performed, the reallocation action will be triggered repeatedly. Therefore, the first record must be retained to ensure uniqueness.

[0031] S134.4, based on the valid records after deduplication and merging, backfill the output target entries to form a final consistent task binding request that needs to be reassigned; In one specific embodiment, the task level value, request type identifier and slice identifier in the valid record set are written into a new task binding request table, and a unique reassignment request number is generated for each record. The output is a set of task binding requests that need to be reassigned. It should be noted that by establishing a set of task binding requests for reassignment, it can be ensured that the reassignment record corresponds one-to-one with the original task record, thus avoiding record confusion during multiple reassignments.

[0032] The task update module S14 is used to perform a slice-priority reassignment operation on all task binding requests that are determined to need to be reassigned. The operation includes releasing low-level task connections bound to high-risk slices, reallocating available slice resources according to the remaining capacity, and updating the task binding record.

[0033] Specifically, the steps for performing slice-first reallocation are as follows: S141, by locating slices in the slice resource risk set whose resource risk coefficient is higher than the preset resource risk threshold, identify the corresponding high-risk slices and establish a list of high-risk slices; By traversing all slice record rows in the slice resource risk set, comparing the resource risk coefficient with the preset resource risk threshold one by one, and writing the slice identifiers that are higher than the threshold into the high-risk slice list, a target slice set for release action retrieval is formed. It should be noted that the preset resource risk threshold is derived from the setting result of the aforementioned S134.2 and is a dynamically calculated value; By performing release processing only on entries in the high-risk slice list, the normal connections of non-high-risk slices can be prevented from being released incorrectly; S142, Search the task scheduling factor group item by item according to the high-risk slice list, determine the low-level task connections bound to the high-risk slices and form a list to be released; In one specific embodiment, by matching the slice identifier of each record in the task scheduling factor group with the high-risk slice list item by item, the record entries that are successfully matched and whose task level value is lower than the preset priority threshold are written into the release list as release objects. It should be noted that the preset priority threshold is consistent with the threshold described in S134.2 above; By linking and comparing the task level value with the slice risk level before release, it is possible to avoid releasing critical tasks that are still at a high level. S143, by performing release actions item by item on the release list, reclaim the available slice resources occupied by low-level task connections and record the remaining capacity value after release; By reading the slice identifier of each record in the list to be released, the corresponding occupied resource amount is synchronously subtracted from the slice resource risk set, and the deduction result is updated and written to the remaining capacity value field of the slice record to form an updated set of remaining capacity records; It should be noted that the amount of resources already occupied is calculated by statistically analyzing the bandwidth allocation field of low-level task connections. The updated remaining capacity value after release will directly affect the subsequent reallocation selection of available slices. S144: Based on the remaining capacity value after release, select available slice resources for each task binding request that needs to be reallocated and complete the reallocation, then update the task binding record. In one specific embodiment, by searching the slice identifier in the record set of remaining capacity after release for each task binding request, the slice with remaining capacity greater than the current task's expected usage is filtered out, the successfully matched slice identifier is bound to the task request, and synchronously written to the task binding record. It should be noted that the estimated task load is estimated by analyzing the average bandwidth usage of historical request type identifiers of the same type, in order to avoid insufficient newly allocated slice resources.

[0034] Specifically, the steps to update the task binding record are as follows: S144.1, by reading the request type identifier of each task binding request that needs to be reassigned, select an available slice resource that matches the request type identifier and has sufficient remaining capacity to support it; By jointly matching the request type identifier in the task binding request table with the slice identifier recorded in the remaining capacity record set after release, entries with remaining capacity higher than the expected task usage are selected as allocable resource objects. It should be noted that the above matching method ensures that the newly bound slice meets the requirements in terms of type compatibility and resource capacity.

[0035] S144.2, Write a new slice identifier for the corresponding task entry based on the selected available slice resources and complete the binding action, keeping it consistent with the original task level value; The binding operation is completed by replacing the slice identifier field of the original entry with the selected slice identifier in the task binding request table, while keeping its task level value field unchanged. It should be noted that retaining the task level value is to maintain the continuity of task scheduling priority and avoid priority disorder after reallocation. S144.3, by establishing one-to-one change entries for the original slice identifier and the new slice identifier in the task binding record, the order of release and allocation is recorded to fix the redistribution order; In one specific embodiment, a mapping pair consisting of the original slice identifier and the new slice identifier is written into the change log area of ​​the task binding record table, and the release timestamp and allocation timestamp are recorded at the same time to form a sequentially traceable change entry. It should be noted that both the release timestamp and the allocation timestamp are automatically generated through event triggering to ensure that the order of reallocation actions can be verified. S144.4, Complete the write based on the changed entries and perform consistency verification on all affected entries, and output the verified update task binding record; By comparing the task level value, slice identifier, and request type identifier fields of all entries in the task binding record table, we can verify whether their correspondence with the changed entry records is consistent. After verification, the updated task binding record table is output. It should be noted that consistency verification can prevent discrepancies between task binding records and actual slice allocation status, ensuring the correctness of subsequent scheduling processes.

[0036] 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. An emergency communication system based on 5G network slicing, characterized in that, The system includes: The first analysis module S11 is used to obtain task level information and communication request type information uploaded by terminals under multiple access states, and construct a task scheduling factor group, wherein the task scheduling factor group includes task level value and request type identifier. The second analysis module S12 is used to obtain the current network slice resource occupancy rate and remaining capacity, calculate the resource risk coefficient of each slice based on the occupancy rate and remaining capacity, and form a slice resource risk set. The scheduling determination module S13 is used to compare the task scheduling factor group with the slice resource risk set item by item. When the task level value is higher than the preset priority threshold and the slice resource risk coefficient bound to the corresponding request type is higher than the preset resource risk threshold, it is determined that the task binding request needs to be reassigned. The task update module S14 is used to perform a slice-priority reassignment operation on all task binding requests that are determined to need to be reassigned. The operation includes releasing low-level task connections bound to high-risk slices, reallocating available slice resources according to the remaining capacity, and updating the task binding record.

2. The emergency communication system based on 5G network slicing according to claim 1, characterized in that, The steps to construct a task scheduling factor group are as follows: S111: By parsing the task level information uploaded by terminals under multiple access states, extracting structured entries containing task level values ​​and establishing an index mapping, outputting task level value entries for comparison. S112, Based on the communication request type information uploaded by terminals under multiple access states, extract the structured entries containing request type identifiers and establish an index mapping, and output the request type identifier entries for comparison. S113, Based on the task level value entry and the request type identifier entry, perform a one-to-one index pairing check and remove missing index items to generate a valid combination entry that satisfies the pairing constraints; S114, by writing valid combination entries into a unified record structure and retaining the task level value and request type identifier, a task scheduling factor group containing the task level value and request type identifier is generated.

3. An emergency communication system based on 5G network slicing according to claim 2, characterized in that, The steps to generate a task scheduling factor group that includes task level values ​​and request type identifiers are as follows: S114.1, By comparing the terminal source consistency flags of the task level value entry and the request type identifier entry, the combined rows with inconsistent sources are eliminated; S114.2, Based on the access timestamp of the task level information and the access timestamp of the communication request type information, perform time overlap verification and delete rows with non-overlapping times; S114.3, perform duplicate processing on lines that contain duplicate task level values ​​and request type identifiers; S114.4, based on the valid combination rows after verification, backfill the task level value and request type identifier, and output the refined and verified task scheduling factor group.

4. An emergency communication system based on 5G network slicing according to claim 3, characterized in that, The steps to form a risk set for sliced ​​resources are as follows: S121: By reading the current network slice resource occupancy rate, obtain a record row containing the occupancy rate of each slice and keep the slice identifier consistent to form an occupancy rate record set; S122, Based on the remaining capacity of the current network slice resources, obtain the record rows containing the remaining capacity of each slice and keep the slice identifier consistent to form a set of remaining capacity records; S123, based on the occupancy rate record set and the remaining capacity record set, perform line-by-line calculation under the premise that the slice identifier is consistent, and generate the resource risk coefficient corresponding to each slice; S124, by optimizing the resource risk coefficients corresponding to each slice, writing the optimized resource risk coefficients and slice identifiers into a unified record structure, and combining them to obtain a slice resource risk set containing all slice records.

5. An emergency communication system based on 5G network slicing according to claim 4, characterized in that, The steps to optimize the resource risk coefficients corresponding to each slice are as follows: S124.1, by performing numerical standardization on the occupancy rate and remaining capacity of the same slice at the current time, we obtain standardized values ​​of occupancy rate and remaining capacity that are easy to synthesize and calculate. S124.2, Generate a risk deviation correction factor for each slice based on the standardized values ​​of occupancy rate and remaining capacity; S124.3 calculates the optimized resource risk coefficient for each slice by multiplying the resource risk coefficient with the risk deviation correction factor.

6. An emergency communication system based on 5G network slicing according to claim 5, characterized in that, The steps to determine a task binding request that requires reallocation are as follows: S131, by reading the task level values ​​in the task scheduling factor group and comparing them item by item with the preset priority threshold, the record rows with task level values ​​higher than the preset priority threshold are filtered and a candidate set is formed. S132, based on the request type identifier in the candidate set, retrieve the slice resource risk set and locate the corresponding resource risk coefficient to establish a numerical pair for item-by-item comparison; S133, by comparing the resource risk coefficient with the preset resource risk threshold item by item, the record row that meets the condition of being higher than the preset resource risk threshold is selected as the risk hit item; S134, based on the risk hit item that simultaneously satisfies the task level value being higher than the preset priority threshold and the resource risk coefficient being higher than the preset resource risk threshold, output the task binding request that needs to be reassigned.

7. An emergency communication system based on 5G network slicing according to claim 6, characterized in that, The steps to output the task binding request that needs to be reassigned are as follows: S134.1, By comparing the consistency of the slice identifiers of the task scheduling factor group and the slice resource risk set again, the record rows with inconsistent slice identifiers are removed. S134.2, Based on the fixed threshold order of the preset priority threshold and the preset resource risk threshold, execute the secondary judgment process of first the task level value and then the resource risk coefficient, and solidify the judgment order. S134.3, by performing duplicate removal processing on record rows that simultaneously meet both conditions, duplicate rows are merged and the first valid record is retained; S134.4, based on the valid records after deduplication and merging, backfill the output target entries to form a final consistent task binding request that needs to be reassigned.

8. An emergency communication system based on 5G network slicing according to claim 7, characterized in that, The steps for performing slice-first reallocation are as follows: S141, by locating slices in the slice resource risk set whose resource risk coefficient is higher than the preset resource risk threshold, identify the corresponding high-risk slices and establish a list of high-risk slices; S142, Search the task scheduling factor group item by item according to the high-risk slice list, determine the low-level task connections bound to the high-risk slices and form a list to be released; S143, by performing release actions item by item on the release list, reclaim the available slice resources occupied by low-level task connections and record the remaining capacity value after release; S144: Based on the remaining capacity value after release, select available slice resources for each task binding request that needs to be reallocated and complete the reallocation, then update the task binding record.

9. An emergency communication system based on 5G network slicing according to claim 8, characterized in that, The steps to update the task binding record are as follows: S144.1, by reading the request type identifier of each task binding request that needs to be reassigned, select an available slice resource that matches the request type identifier and has sufficient remaining capacity to support it; S144.2, Write a new slice identifier for the corresponding task entry based on the selected available slice resources and complete the binding action, keeping it consistent with the original task level value; S144.3, by establishing one-to-one change entries for the original slice identifier and the new slice identifier in the task binding record, the order of release and allocation is recorded to fix the redistribution order; S144.4, based on the changed entries, complete the writing and perform consistency verification on all affected entries, and output the verified update task binding record.

Images