An emergency scenario pre-tightening message scheduling optimization method based on load sensing

Abstract

The application relates to the field of 5G communication, and discloses an emergency scene pre-tight message scheduling optimization method based on load sensing, which comprises the following methods: scheduling priority is dynamically modified according to whether the pre-tight message load is busy, and a pre-tight message scheduling period is dynamically modified; the pre-tight message scheduling condition is detected; whether the pre-tight message is stuck is detected; the base station dynamically modifies the priority and the scheduling period; in the case of trying not to affect the normal operation state of the cell and energy consumption, the pre-tight message scheduling efficiency of a high-load emergency scene is greatly optimized, and the probability of the emergence of the situation that a newly-added early warning message cannot be scheduled for a long time is greatly reduced.

Description

Technical Field

[0001] This application belongs to the field of 5G communication transmission technology, and in particular relates to an emergency scenario pre-tightening message scheduling optimization method based on load awareness. Background Technology

[0002] In 5G communication, emergency messages are sent from the RRC (Radio Resource Control) layer to the MAC (Medium Access Control) layer via F1 messages, and then the MAC layer performs the corresponding scheduling.

[0003] Because emergency messages such as ETWS (Earthquake and Tsunami Warning System) and CMAS (Commercial Mobile Alert Service Detection Reference Signal) are subject to concurrency and fragmentation.

[0004] In busy scheduling scenarios where multiple pre-emptive messages need to be sent, vendors typically allow users to configure the SI scheduling period. Regardless of the current pre-emptive message load or channel quality, if the SI scheduling period is statically fixed, in current technology, one OtherSI message might schedule a segment of a pre-emptive message. This could lead to newly added pre-emptive messages being delayed for tens of seconds, which contradicts the design intent of early warning messages. Furthermore, if the previous pre-emptive message scheduling fails repeatedly, or if multiple pre-emptive messages have already been broadcast multiple times but haven't reached the maximum broadcast count, they might be stuck before a new pre-emptive message can be scheduled. Summary of the Invention

[0005] This application provides a load-aware emergency scenario pre-emptive message scheduling optimization method, which aims to address the technical problems raised in the background.

[0006] The technical solution adopted in this invention is:

[0007] Firstly, this application provides a load-aware emergency scenario pre-emptive message scheduling optimization method. In 5G pre-emptive message scheduling, emergency messages are sent from the RRC layer to the MAC layer via F1 messages, and then the MAC layer performs corresponding scheduling. Pre-emptive messages need to be concurrent and fragmented, and the pre-emptive messages are scheduled through OtherSI. The calculation process is optimized by adding the following parameters, including but not limited to the retransmission count RPMC, minimum broadcast count PMBC, maximum retransmission failure count MRPT, scheduling count PMSC, cooling period PMCP, load scheduling count PMTC, and total time threshold for periodic scheduling PMST. The scheduling process uses the number of fragments as the smallest statistical unit, including the following steps:

[0008] S1. Check if the number of pre-tightening messages required for the current cell has reached PMTC;

[0009] S2. Estimate the total time required to broadcast all current pre-tightening messages once, and determine if it exceeds PMST. If so, start a new round of optimization.

[0010] S3. If the RPMC of any pre-tightening message is greater than MRPT and greater than PMBC* priority index, then after extending the PMCP of the pre-tightening message, continue to estimate the total time required to broadcast all current pre-tightening messages once, and determine whether it is greater than PMST.

[0011] S4. If it is greater than PMST, extend the scheduling period PMCP of the remaining pre-tightened messages whose PMSC is greater than PMBC*priority index, and continue to estimate the total time required to broadcast all current pre-tightened messages once, and observe whether it is greater than PMST.

[0012] S5. If it continues to be greater than PMST, extend the scheduling period PMCP of the remaining pre-tightening messages whose PMSC is greater than PMBC index, and continue to estimate the total time required to broadcast all current pre-tightening messages once, and observe whether it is greater than PMST.

[0013] S6. If it is greater than PMST, extend the scheduling period PMCP of the remaining pre-tightening messages with PMSC not equal to 0, and continue to estimate the total time required to broadcast all current pre-tightening messages once, and observe whether it is greater than PMST.

[0014] S7. If it is still greater than PMST, recalculate the priority of the remaining pre-tightened messages according to the RPMC size, and perform the next scheduling task with the new priority;

[0015] S8. Once the scheduling is normal, i.e., when it is less than PMST, the OtherSI periodic configuration will be automatically switched.

[0016] S9. In the above process, if there is a situation where all pre-tightening messages need to have PMCP added, then all messages will not have PMCP added, and the process will directly proceed to step 6.

[0017] In step S3, the priority index is determined as the scheduling priority, and the pre-tightening message scheduling cycle is dynamically modified according to whether the pre-tightening message load is busy.

[0018] In step S1, when the load is found to be too high, the OtherSI cycle configuration will be automatically switched.

[0019] Secondly, this application provides a computer program that implements the method described in the first aspect.

[0020] The beneficial effects of this application's embodiments compared to existing technologies are: it provides a favorable guarantee in scenarios where pre-emergency message scheduling is busy and new pre-emergency messages cannot be scheduled for a long time. Without affecting the normal operation of the cell and energy consumption, it significantly optimizes the scheduling efficiency of pre-emergency messages in high-load emergency scenarios, greatly reducing the probability of new early warning messages failing to be scheduled for a long time. Attached Figure Description

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

[0022] Figure 1 This is a flowchart provided in an embodiment of this application. Detailed Implementation

[0023] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0024] In 5G pre-emptive message scheduling, all pre-emptive messages are scheduled through OtherSI.

[0025] New parameter:

[0026] Retransmissions of pretension messages (RPMC)

[0027] Pretension messages minimum broadcast count (PMBC)

[0028] Maximum retransmissions pretensionthreshold (MRPT)

[0029] Pretension messages schedule count threshold (PMSC)

[0030] Pretension messages cooling period (PMCP)

[0031] Pretension messages total count (PMTC)

[0032] Pretension messages total cycle scheduletime threshold (PMST)

[0033] This application provides a load-aware emergency scenario pre-emptive message scheduling optimization method. In 5G pre-emptive message scheduling, emergency messages are sent from the RRC layer to the MAC layer via F1 messages, and then the MAC layer performs corresponding scheduling. Pre-emptive messages need to be concurrent and fragmented, and the pre-emptive messages are scheduled through OtherSI. The calculation process is optimized by adding the following parameters, including but not limited to the retransmission count (RPMC), minimum broadcast count (PMBC), maximum retransmission failure count (MRPT), scheduling count (PMSC), cooling period (PMCP), load scheduling count (PMTC), and total periodic scheduling time threshold (PMST). The scheduling process uses the number of fragments as the smallest statistical unit, including the following steps:

[0034] S1. Check if the number of pre-tightening messages required for the current cell has reached PMTC;

[0035] S2. Estimate the total time required to broadcast all current pre-tightening messages once, and determine if it exceeds PMST. If so, start a new round of optimization.

[0036] S3. If the RPMC of any pre-tightening message is greater than MRPT and greater than PMBC* priority index, then after extending the PMCP of the pre-tightening message, continue to estimate the total time required to broadcast all current pre-tightening messages once, and determine whether it is greater than PMST.

[0037] S4. If it is greater than PMST, extend the scheduling period PMCP of the remaining pre-tightened messages whose PMSC is greater than PMBC*priority index, and continue to estimate the total time required to broadcast all current pre-tightened messages once, and observe whether it is greater than PMST.

[0038] S5. If it continues to be greater than PMST, extend the scheduling period PMCP of the remaining pre-tightening messages whose PMSC is greater than PMBC index, and continue to estimate the total time required to broadcast all current pre-tightening messages once, and observe whether it is greater than PMST.

[0039] S6. If it is greater than PMST, extend the scheduling period PMCP of the remaining pre-tightening messages with PMSC not equal to 0, and continue to estimate the total time required to broadcast all current pre-tightening messages once, and observe whether it is greater than PMST.

[0040] The PMBC index can be defined based on the base station's historical data. Steps S4, S5, and S6 correspond to a backup scheduling that discards a portion of the pre-tightened message. For example, PMBC can be set to x=5, and the priority index can be set to y=5. S4 represents the logical relationship between PMSC > xy, S5 represents PMSC > x, and S6 represents PMSC > 0.

[0041] S7. If it is still greater than PMST, recalculate the priority of the remaining pre-tightened messages according to the RPMC size, and perform the next scheduling task with the new priority;

[0042] S8. Once the scheduling is normal, i.e., when it is less than PMST, the OtherSI periodic configuration will be automatically switched.

[0043] S9. In the above process, if there is a situation where all pre-tightening messages need to have PMCP added, then all messages will not have PMCP added, and the process will directly proceed to step 6.

[0044] In step S3, the priority index is determined as the scheduling priority, and the pre-tightening message scheduling cycle is dynamically modified according to whether the pre-tightening message load is busy.

[0045] In step S1, when the load is found to be too high, the OtherSI cycle configuration will be automatically switched.

[0046] Example 1

[0047] The base station is configured with one cell, and the SI period for this cell is set to 640ms.

[0048] Set PMBC to 5, MRPT to 4, PMCP to 30s, PMTC to 120, and PMST to 3s.

[0049] In the current scenario, 20 ETWS messages, each with 64 fragments, are being sent in parallel.

[0050] Of these, 15 messages had been broadcast more than 50 times, but the maximum retransmission limit had not yet been reached. The broadcast failure rate for 3 messages was almost 80%, and only two were actually added pre-emptive messages.

[0051] A new scheduling algorithm is used for optimization.

[0052] The base station will first modify the OtherSI period to 320ms, then schedule 5 times according to the 2 new pre-tightening messages, and then schedule sequentially according to the broadcast failure rate priority.

[0053] This method ensures the successful broadcast of every pre-tightened message even in extreme situations where scheduling is limited, preventing some pre-tightened messages from being delayed in scheduling.

[0054] It should be noted that the information interaction and execution process between the above-mentioned devices / units are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0055] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0056] This application also provides a network device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0057] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0058] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / terminal device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0059] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0060] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

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

[0062] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0063] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A load-aware emergency scenario pre-emptive message scheduling optimization method, wherein in 5G pre-emptive message scheduling, emergency messages are sent from the RRC layer to the MAC layer via F1 messages, and then the MAC layer performs corresponding scheduling. Pre-emptive messages need to be concurrent and fragmented, and the pre-emptive messages are scheduled through OtherSI; the calculation process is optimized by adding the following parameters, including but not limited to the pre-emptive message retransmission count RPMC, the pre-emptive message minimum broadcast count PMBC, the pre-emptive message maximum retransmission failure count MRPT, the pre-emptive message scheduling count PMSC, the pre-emptive message cooling period PMCP, the pre-emptive message load scheduling count PMTC, and the pre-emptive message periodic scheduling total time threshold PMST; the number of fragments is used as the smallest statistical unit in the scheduling process, characterized in that, Includes the following steps: S1. Check if the number of pre-tightening messages required for the current cell has reached PMTC; S2. Estimate the total time required to broadcast all current pre-tightening messages once, and determine if it exceeds PMST. If so, start a new round of optimization. S3. If the RPMC of any pre-tightening message is greater than MRPT and greater than PMBC* priority index, then after extending the PMCP of the pre-tightening message, continue to estimate the total time required to broadcast all current pre-tightening messages once, and determine whether it is greater than PMST. S4. If it is greater than PMST, extend the scheduling period PMCP of the remaining pre-tightened messages whose PMSC is greater than PMBC*priority index, and continue to estimate the total time required to broadcast all current pre-tightened messages once, and observe whether it is greater than PMST. S5. If it continues to be greater than PMST, extend the scheduling period PMCP of the remaining pre-tightening messages whose PMSC is greater than the PMBC index, and continue to estimate the total time required to broadcast all current pre-tightening messages once, and observe whether it is greater than PMST. S6. If it is still greater than PMST, extend the scheduling period PMCP of the remaining pre-tightening messages with PMSC not equal to 0, and continue to estimate the total time required to broadcast all current pre-tightening messages once, and observe whether it is greater than PMST. S7. If it is still greater than PMST, recalculate the priority of the remaining pre-tightened messages according to the RPMC size, and perform the next scheduling task with the new priority; S8. Once the scheduling is normal, i.e., when it is less than PMST, the OtherSI periodic configuration will be automatically switched. S9. In the above process, if there is a situation where all pre-tightening messages need to have PMCP added, then all messages will not have PMCP added, and the process will directly proceed to step 6.

2. The emergency scenario pre-emptive message scheduling optimization method based on load awareness as described in claim 1, characterized in that, In step S3, the priority index is determined as the scheduling priority, and the pre-tightening message scheduling cycle is dynamically modified according to whether the pre-tightening message load is busy.

3. The emergency scenario pre-emptive message scheduling optimization method based on load awareness as described in claim 1, characterized in that, In step S1, when the load is found to be too high, the OtherSI cycle configuration will be automatically switched.

Images