Default bearer dynamic configuration method and device in 5g base station or repeater device multi-qos flow scenario based on service type perception

Abstract

This application discloses a method and apparatus for dynamic configuration of default bearers in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness. The method includes: obtaining QoS flows in the currently established PDU session and determining the corresponding services; if at least one non-GBR service exists, setting the DRB associated with one of the non-GBR services as the default DRB; adding the default DRB to a default DRB candidate pool, which also includes at least one spare silent DRB; configuring the uplink SDAP header of each DRB in the default DRB candidate pool as present; and when a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB, selecting a silent DRB from the default DRB candidate pool as the default DRB. This solves the problem of reconfiguration failure when dynamic QoS flow deletion occurs due to the existing static binding method for default DRBs.

Description

Technical Field

[0001] This application relates to the field of wireless communication technology, and in particular to a method and apparatus for dynamic configuration of default bearer in multi-QOS flow scenarios of 5G base station or repeater equipment based on service type awareness. Background Technology

[0002] In related technologies, the default DRB (Data Radio Bearer) is usually fixed as the DRB corresponding to the first established QoS (Quality of Service) stream, and the existence of SDAP (Service Data Adaptation Protocol) is bound to the default DRB.

[0003] This static binding can lead to reconfiguration failure when dynamic QoS flow deletion occurs (e.g., deleting the QoS flow corresponding to the original default DRB), due to SDAP header configuration conflicts caused by default DRB switching. For example: A UE handover to this cell with voice service has two PDU sessions. The first PDU session has two QoS flows, corresponding to 5QI levels 5QI1 and 5QI5 respectively. 5QI1 is the first QoS flow, so its corresponding DRB is configured as the default DRB, and its corresponding UL SDAP header is configured as "present". The DRB corresponding to 5QI5 is not the default DRB, and its corresponding UL SDAP header is configured as "absent". If the call is disconnected, 5QI1 will be deleted, and 5QI5 will become the default DRB. Simultaneously, the UL SDAP header corresponding to 5QI5 will be forcibly modified to "present". The UE recognizes that the configuration of the UL SDAP header corresponding to 5QI5 is inconsistent with the previous one and reports a reconfiguration failure. Summary of the Invention

[0004] The purpose of this application is to provide a method and apparatus for dynamic configuration of default bearers in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness, in order to solve the problem of reconfiguration failure when dynamic QoS flow is deleted due to the existing static binding method for default DRBs.

[0005] In a first aspect, embodiments of this application provide a method for dynamic configuration of default bearer in a multi-QoS flow scenario of a 5G base station or repeater device based on service type awareness, the method comprising: Obtain the QoS flow in the currently established PDU session and determine the service corresponding to the QoS flow; If there is at least one non-GBR service with a non-guaranteed bit rate, set the DRB associated with one of the non-GBR services as the default DRB. The default DRB is placed into the default DRB candidate pool, which also includes at least one standby silent DRB. Configure the uplink service data adaptation protocol SDAP header of each DRB in the default DRB candidate pool as present; When a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB, a silent DRB is selected from the default DRB candidate pool as the default DRB.

[0006] In some possible embodiments, the method further includes at least one of the following steps: If there is no non-GBR service, configure the uplink SDAP header of all DRBs associated with QoS flows as absent; Set one of the non-GBR service-related DRBs as the default DRB, including: If a non-GBR service exists, the DRB associated with the non-GBR service is set as the default DRB, and a new silent DRB is created in the default DRB candidate pool. If there are multiple non-GBR services, the DRB associated with one of the non-GBR services will be set as the default DRB based on the overall score of DRB priority, and the DRB associated with at least one other non-GBR service will be set as a silent DRB and then put into the default DRB candidate pool.

[0007] In some possible embodiments, the method further includes at least one of the following steps: If the deleted QoS flow is not associated with the default DRB, the default DRB candidate pool remains unchanged; If the deleted QoS flow is associated with the current default DRB, it also includes: Before selecting a silent DRB from the default DRB candidate pool as the default DRB, if it is determined that there is no silent DRB in the default DRB candidate pool, a new silent DRB is created in the default DRB candidate pool, and the UE is instructed to completely clear the previous DRB configuration.

[0008] In some possible embodiments, the method further includes at least one of the following steps: When a QoS flow addition event occurs, if the added QoS flow is a GBR service and a default DRB currently exists, the default DRB candidate pool remains unchanged. When a QoS flow increase event occurs, if the increased QoS flow is a non-GBR service and a default DRB currently exists, the default DRB remains unchanged, and the DRB associated with the increased QoS flow is added to the default DRB candidate pool based on the DRB priority comprehensive score. When a QoS flow addition event occurs, if the added QoS flow is a non-GBR service and there is no default DRB, the DRB associated with the added QoS flow is set as the default DRB and placed in the default DRB candidate pool, and a new silent DRB is created in the default DRB candidate pool.

[0009] In some possible embodiments, the method further includes: In response to the default DRB candidate pool maintenance command, determine the number of DRBs in the current default DRB candidate pool; If the number of DRBs is greater than 1 and not greater than the maximum capacity, then the current default DRB candidate pool remains unchanged. If the number of DRBs is no greater than 1 and there is currently a non-GBR service, a new silent DRB will be created in the default DRB candidate pool; If the number of DRBs exceeds the maximum capacity, based on the priority score of the DRBs, the corresponding number of DRBs will be released until the number of DRBs does not exceed the maximum capacity.

[0010] In some possible embodiments, the priority comprehensive score of the DRB is determined in the following manner: Determine the factor score corresponding to at least one of the following factors in the DRB protocol: standard priority level, service type weight, and link quality. The priority comprehensive score of the DRB is determined based on the factor scores and their corresponding weights.

[0011] In some possible embodiments, the method further includes: When a cell handover occurs, the 5G base station or repeater equipment, acting as the source base station, indicates the default DRB candidate pool context of the target base station's current PDU session through a handover request message. When a cell handover occurs, the 5G base station or repeater device, as the target base station, receives the handover request message and prioritizes inheriting the corresponding default DRB candidate pool configuration according to the instructions of the source base station. If it is determined that the inheritance is not complete, the default DEB candidate pool will be reconfigured.

[0012] Secondly, embodiments of this application provide a device for dynamic configuration of default bearer in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness, the device comprising: The service type determination module is used to obtain the QoS flow in the currently established PDU session and determine the service corresponding to the QoS flow; The default DRB setting module is used to set the DRB associated with one of the non-GBR services as the default DRB if there is at least one non-GBR service with a non-guaranteed bit rate. A default DRB candidate pool configuration module is used to put the default DRB into the default DRB candidate pool, which also includes at least one spare silent DRB. The uplink SDAP header configuration module is used to configure the uplink service data adaptation protocol SDAP header of each DRB in the default DRB candidate pool as present. The default DRB change module is used to select a silent DRB as the default DRB from the default DRB candidate pool when a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB.

[0013] Thirdly, another embodiment of this application also provides a default bearer dynamic configuration device for a multi-QOS flow scenario of a service type-aware 5G base station or repeater, including at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute any of the default bearer dynamic configuration methods for a multi-QOS flow scenario of a service type-aware 5G base station or repeater provided in the embodiments of this application.

[0014] Fourthly, another embodiment of this application also provides a computer storage medium storing a computer program for causing a computer to execute any of the default bearer dynamic configuration methods for multi-QOS stream scenarios of 5G base stations or repeaters based on service type awareness provided in the embodiments of this application.

[0015] The method and apparatus for dynamic configuration of default bearers in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness provided in this application embodiment no longer fixes the DRB associated with the first established QoS flow as the default DRB, but instead sets the non-GBR as the default DRB; at the same time, the base station maintains a default DRB candidate pool and configures the uplink SDAP header in the default DRB candidate pool as present; when a QoS flow deletion event occurs, a default DRB retention detection mechanism is executed. When the deleted QoS flow is associated with the current default DRB, a spare silent DRB is selected from the default DRB candidate pool as the default DRB, thereby avoiding the reconfiguration failure problem caused by the change of uplink SDAP header.

[0016] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments of this application 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.

[0018] Figure 1 A flowchart of a method for dynamic configuration of default bearer in a multi-QOS flow scenario of a 5G base station or repeater device based on service type awareness, provided in an embodiment of this application. Figure 2 A detailed flowchart illustrating the method for dynamic configuration of default bearer in multi-QOS flow scenarios of 5G base station or repeater equipment based on service type awareness, as provided in the embodiments of this application. Figure 3 A schematic diagram of the process for creating a new silent DRB provided for embodiments of this application; Figure 4 This is a schematic diagram illustrating the integration of default DRB candidate configurations in a base station handover scenario according to an embodiment of this application. Figure 5 A diagram of a default bearer dynamic configuration device for a 5G base station or repeater device in a multi-QOS stream scenario based on service type awareness, provided in an embodiment of this application. Figure 6 This application provides another structural diagram of a default bearer dynamic configuration device for 5G base station or repeater equipment in a multi-QOS flow scenario based on service type awareness. Detailed Implementation

[0019] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, more or fewer operation steps may be included in the method based on conventional or non-inventive effort. For steps that do not logically have a necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application. In actual processing or when the control device executes the method, it may be executed sequentially or in parallel according to the method shown in the embodiments or drawings.

[0020] In the 5GS (5th generation System) QoS model, the smallest granularity of QoS management is the QoS flow. A QoS flow can be viewed as an "end-to-end" channel between the UE (User Equipment) and the UPF (User Plane Function). A UE can establish one or more PDU (Protocol Data Unit) sessions. Each PDU session contains one or more QoS flows, which are identified within the same PDU session by QFI (QoS Flow ID). The network can indicate QoS characteristics through standardized 5QI.

[0021] Based on this QoS model, the SDAP entity is introduced in NR. SDAP is a sublayer of the Uu interface L2. The main function of SDAP is to map QoS flows to DRB (Data Radio Bearer) and identify different QoS flows through QFI. From the perspective of gNB, when the gNB receives downlink data (GTP-U (GPRS Tunneling Protocol for the user plane) messages), it first distinguishes different PDU sessions based on the F-TEID (Full Qualified TEID) of GTP-U, then distinguishes different QoS flows based on the QFI carried in the extended header, and finally maps the QoS flows to the DRB for transmission. If multiple QoS flows are mapped to the same DRB, the gNB needs to carry the QFI in the SDAP header to help the UE distinguish between different QoS flows.

[0022] The gNB can configure whether to carry SDAP headers for downlink and uplink using sdap-HeaderDL and sdap-HeaderUL in SDAP Config, respectively. If sdap-HeaderDL or sdap-HeaderUL is the default (absent), the corresponding SDAP Data PDU in the transmission direction only contains the Data Field and no SDAP header. If it is present, the corresponding SDAP Data PDU in the transmission direction contains both SDAP header and Data Field. The most important field in the SDAP header is the QFI. Additionally, the gNB uses the default DRB in SDAP Config to indicate whether the DRB is the default DRB for the PDU session. A PDU session can have at most one default DRB. The default DRB is typically used to transmit user plane data that is not explicitly mapped to a specific QoS flow. Because the default DRB may carry multiple QoS flows, the uplink of the default DRB must be configured with an SDAP header to distinguish different flows using the QFI in the SDAP header. When the DRB is not the default, whether to configure the SDAP header may depend on whether the QoS flow needs to be mapped to a different DRB.

[0023] In view of the problem that the static binding method for the default DRB in the related technology leads to the failure of reconfiguration when the dynamic QoS flow is deleted, the embodiments of this application provide a method and device for dynamic configuration of default bearer in multi-QoS flow scenarios of 5G base station or repeater equipment based on service type awareness.

[0024] Other features and advantages of this application will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the application. The objectives and other advantages of this application may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings.

[0025] The method for searching monitoring nodes in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] See Figure 1 The present application provides a method for dynamic configuration of default bearers in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness. The method includes: Step 101: Obtain the QoS flow in the currently established PDU session and determine the service corresponding to the QoS flow; The embodiments of this application can identify all QoS flows to be activated in the current session and their corresponding QoS feature identifiers (5QI) during the PDU session establishment phase, and determine whether the service corresponding to the QoS flow is a GBR service or a non-GBR service.

[0027] Step 102: If there is at least one non-GBR service with a non-guaranteed bit rate, set the DRB associated with one of the non-GBR services as the default DRB. In this embodiment of the application, for cases where there are non-GBR services with non-guaranteed bit rates, one of the DRBs associated with the non-GBR services is selected as the default DRB according to the corresponding mechanism, instead of statically binding the default DRB bearer to the first QoS flow.

[0028] 5G base station or repeater equipment uses the default DRB in SDAP Config to indicate whether the DRB is the default DRB for a PDU session. A PDU session can have at most one default DRB. The default DRB is typically used to transmit user plane data that is not explicitly mapped to a specific QoS flow. Because the default DRB may carry multiple QoS flows, the default DRB uplink must be configured with an SDAP header to distinguish different flows through the QFI in the SDAP header.

[0029] Step 103: Place the default DRB into the default DRB candidate pool, which also includes at least one spare silent DRB. In this application embodiment, a default DRB candidate pool is maintained in a 5G base station or repeater equipment. The default DRB candidate pool includes a default DRB and at least one backup silent DRB. The backup silent DRB is a DRB associated with other non-GBR services or a newly created DRB. The newly created DRB does not map any QoS flow and is only used as a backup silent DRB. When it is created, the uplink SDAP header is set to present.

[0030] Step 104: Configure the uplink service data adaptation protocol SDAP header of each DRB in the default DRB candidate pool as present. Step 105: When a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB, select a silent DRB from the default DRB candidate pool as the default DRB.

[0031] It should be noted that, based on the above mechanism, the 5G base station or repeater equipment in this application embodiment configures the DRB and indicates the configuration of the default DRB candidate pool to the UE. This includes the default DRB and silent DRB configured in the default DRB candidate pool. During the PDU session, all QoS flows are mapped to the corresponding DRB according to the corresponding mechanism. There is only one default DRB, and an SDAP Header is configured for the default DRB to distinguish different QoS flows through the QFI in the uplink SDAP header.

[0032] The method for dynamic configuration of default bearers in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness provided in this application prioritizes the DRB corresponding to non-GBR type QoS flows as the default DRB, rather than the first established DRB; and maintains a default DRB candidate pool, with the SDAP header of all DRBs in the pool pre-configured as present. This differs from the traditional scheme that uses the first activated QoS flow as the default DRB bearer, and strives to maintain the stability of the default DRB bearer during PDU sessions. When the default DRB bearer changes, it ensures that the SDAP header configuration does not change, solving the reconfiguration failure problem caused by forced SDAP header changes in existing standards, and has better robustness compared to existing solutions.

[0033] The default DRB maintained by the 5G base station or repeater equipment in this application includes the initial default DRB configuration stage when the PDU session is established, the default DRB configuration update stage when the QoS flow changes during the PDU session, and the default DRB configuration maintenance stage.

[0034] During the initial default DRB configuration phase when a PDU session is established, all QoS flows in the PDU session are checked to determine whether non-GBR services exist. Based on the check results, the following three situations apply: 1) There is no non-GBR service. If there is no non-GBR service, configure the uplink SDAP header of all QoS flow-associated DRBs as absent. In this case, no default DRB is set, and no silent DRB is set in the DRB candidate pool, that is, the default DRB candidate pool is empty.

[0035] In this embodiment of the application, for cases where there is no non-GBR service, the SDAP headers of all DRBs are configured on demand, i.e., configured according to QoS flow mapping requirements. The reason for not setting a default DRB is that a dedicated DRB typically carries only a single QoS flow, and the QFI can implicitly infer it through the DRB ID. Therefore, it can be configured not to carry an SDAP header, so there is no change to the SDAP header when the bearer changes.

[0036] 2) There is a non-GBR service.

[0037] If a non-GBR service exists, the DRB associated with the non-GBR service is set as the default DRB, and a new silent DRB is created in the default DRB candidate pool. For an explanation of the newly created silent DRB, please refer to the above embodiment description, which will not be repeated here.

[0038] 3) Multiple non-GBR services exist.

[0039] If there are multiple non-GBR services, the DRB associated with one of the non-GBR services will be set as the default DRB based on the overall score of DRB priority, and the DRB associated with at least one other non-GBR service will be set as a silent DRB and then put into the default DRB candidate pool.

[0040] In this embodiment of the application, the priority comprehensive score of DRB can be determined by setting multiple factors according to the service requirements and signaling quality of DRB, and the different factors are weighted and summed to determine the priority comprehensive score. The DRB with the highest priority comprehensive score is set as the default DRB. According to the priority comprehensive score, at least one DRB is selected as the silent DRB in descending order of priority comprehensive score. The uplink SDAP header of all DRBs in the default DRB candidate pool is configured as present.

[0041] In the default DRB configuration update phase when QoS flow changes during a PDU session, this application mainly includes the default DRB configuration update when a QoS flow deletion event occurs and the default DRB configuration update when a QoS flow addition event occurs.

[0042] Scenario 1: Default DRB configuration update when a QoS flow deletion event occurs.

[0043] In this embodiment of the application, when a QoS flow deletion event occurs, if the deleted QoS flow is not associated with the default DRB, the default DRB candidate pool is maintained unchanged, that is, the existing uplink SDAP header configuration is maintained unchanged.

[0044] If the deleted QoS flow is associated with the current default DRB, it is necessary to determine whether there is a silent DRB in the current default DRB candidate pool. If there is a silent DRB, a silent DRB is selected from the default DRB candidate pool as the default DRB. Specifically, the silent DRB with the highest priority comprehensive score can be selected. If there is no silent DRB in the default DRB candidate pool, a new silent DRB is created in the default DRB candidate pool, and another silent DRB is selected from the default DRB candidate pool as the default DRB. The UE is then instructed to completely clear the previous DRB configuration. Specifically, fullConfig can be used in the RRC reconfiguration message to instruct the UE to completely replace the existing DRB configuration. For an explanation of the created silent DRB, please refer to the above embodiment description, which will not be detailed here.

[0045] Because the protocol does not allow dynamic modification of the SDAP header, when there is no backup silent DRB in the default DRB candidate pool, the RRC reconfiguration message uses fullConfig to instruct the UE to completely replace the existing DRB configuration. In this case, the UE will clear the existing DRB configuration and apply the new DRB configuration indicated by the 5G base station or repeater equipment.

[0046] Scenario 2: Default DRB configuration update when a QoS flow increase event occurs.

[0047] In this application embodiment, when a QoS flow increase event occurs, the main situations are as follows, depending on whether a default DRB already exists and whether the increased QoS flow is a non-GBR service: If a default DRB already exists when a QoS flow addition event occurs, and the added QoS flow is a GBR service, then the default DRB candidate pool remains unchanged. If a default DRB already exists when a QoS flow addition event occurs, and the added QoS flow is a non-GBR service, then the default DRB remains unchanged. Based on the DRB priority score, it is determined whether to add the DRB associated with the added QoS flow to the default DRB candidate pool. Specifically, the implementation of adding it to the default DRB candidate pool can be as follows: if the priority score of the added non-GBR service's corresponding DRB is higher than the priority score of the DRBs in the default DRB candidate pool, then based on the number of DRBs in the current default DRB candidate pool, it is determined whether to delete other DRBs with lower priority scores after adding the added QoS flow's corresponding DRB to the default DRB candidate pool; if the priority score of the added non-GBR service's corresponding DRB is lower than the priority score of the DRBs in the default DRB candidate pool, then based on the number of DRBs in the current default DRB candidate pool, it is determined whether to add the added QoS flow's corresponding DRB to the default DRB candidate pool.

[0048] If a default DRB does not exist when a QoS flow addition event occurs, and the added QoS flow is a non-GBR service, the DRB associated with the added QoS flow is set as the default DRB and placed in the default DRB candidate pool. A new silent DRB is then created in the default DRB candidate pool. The description of the newly created silent DRB is given in the above embodiment and will not be detailed here.

[0049] During the default DRB configuration maintenance phase, this application can maintain the default DRB configuration using the following methods: In response to the default DRB candidate pool maintenance command, determine the number of DRBs in the current default DRB candidate pool; If the number of DRBs is greater than 1 and not greater than the maximum capacity, the current default DRB candidate pool remains unchanged. If the number of DRBs is greater than 1, it means that there is a default DRB and at least one silent DRB in the default DRB candidate pool. The maximum capacity can be set as needed. If the number of DRBs is not greater than 1 and there is currently a non-GBR service, a new silent DRB is created in the default DRB candidate pool. This situation indicates that there is only one default DRB in the default DRB candidate pool. In order to avoid changing the SDAP header configuration when the default DRB is deleted, this embodiment of the application creates a new silent DRB in the default DRB candidate pool. For the description of the newly created silent DRB, please refer to the above embodiment description, which will not be detailed here. If the number of DRBs exceeds the maximum capacity, based on the priority score of the DRBs, the corresponding number of DRBs will be released until the number of DRBs does not exceed the maximum capacity.

[0050] In some possible embodiments, the priority comprehensive score of DRB in this application embodiment is determined in the following manner: Determine the factor score corresponding to at least one of the following factors in the DRB protocol: standard priority level 5QI, service type weight, and link quality. The priority comprehensive score of the DRB is determined based on the factor scores and their corresponding weights.

[0051] This application's embodiments introduce a priority-based comprehensive scoring mechanism based on multiple factors (5QI, service type, link quality) to select and maintain the default DRB candidate pool, making the decision-making process more intelligent and optimized, surpassing simple static rules.

[0052] In this application embodiment, a priority comprehensive score S is calculated for each DRB. The higher the priority comprehensive score S, the higher the corresponding priority, and the more likely it is to be selected as the new default DRB. The priority comprehensive score S rule may be based on, but is not limited to, the following factors: 5QI Priority (P_5qi): Directly uses the standard priority level corresponding to 5QI (defined in 3GPP 23.501), the smaller the value, the higher the priority. In this application embodiment, normalization processing can be performed to obtain the factor score of the corresponding standard priority level 5QI, for example: P_5qi = 1 / (standard priority level); Service type weight (W_type): Assign a weight coefficient to different service types. For example, signaling services (such as IMS (IP Multimedia Subsystem) signaling) have the highest weight, such as a weight of 1.0; interactive services are next, such as a weight of 0.7; and background services have the lowest weight, such as a weight of 0.4.

[0053] Link Quality Score (Q_link): Based on the radio link quality of the UE corresponding to this DRB, such as the average CQI, the higher the quality, the higher the score. For example, Q_link = CQI / 15, where it is assumed that the CQI range is 0-15. The priority score S can be calculated using a formula, for example: S = α P_5qi + β W_type + γ Q_link, where α, β, and γ are configurable weight coefficients that satisfy α+β+γ=1. The network can dynamically adjust these coefficients according to the policy.

[0054] The following is in conjunction with the appendix Figure 2 This application provides a detailed embodiment of the default bearer dynamic configuration method for multi-QOS flow scenarios of 5G base stations or repeaters based on service type awareness, as provided in the embodiments of this application.

[0055] like Figure 2 As shown in the embodiments of this application, the method for dynamic configuration of default bearers in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness specifically includes: Step 200: During the PDU session establishment phase, identify all QoS flows to be activated in the current session and their corresponding QoS feature identifiers (5QI).

[0056] Step 201: Enter the initial default DRB configuration phase, check all QoS flows in the PDU session, and determine whether there is a non-GBR service with non-guaranteed bit rate. If there is a single non-GBR service, proceed to step 202. If there are multiple non-GBR services, proceed to step 204. If there is no non-GBR service, proceed to step 206. Step 202: If a single non-GBR service exists, select the DRB associated with the non-GBR service as the default DRB, and configure the uplink SDAP header of the default DRB as present. Step 203: Add the default DRB to the default DRB candidate pool, and create a standby silent DRB in the default DRB candidate pool. Set the uplink SDAP header configuration of the silent DRB to present, and proceed to step 207. Step 204: If there are multiple non-GBR service flows, select a non-GBR associated DRB from the DRBs corresponding to the multiple non-GBR service flows according to priority and comprehensive scoring, add it to the default DRB candidate pool as the default DRB, and configure the corresponding ULSDAP header as present. Step 205: Based on the priority comprehensive score, configure the UL SDAP header as present for one or more of the remaining non-GBR associated DRBs and add them to the default DRB candidate pool; Proceed to Step 206; Step 206: If there is no non-GBR service, do not set the default DRB. Configure the UL SDAP header of all DRBs as needed, such as according to QoS flow mapping requirements. Step 207: Continuously monitor changes in QoS flow within the PDU session; Step 208: When a change in QoS flow is detected in a PDU session, determine the event type and dynamically maintain the stability of the DRB configuration according to the event type. Specifically, when a QoS flow addition event occurs, execute step 209; when a QoS flow deletion event occurs, execute step 215. Step 209: When a QoS flow deletion event occurs, determine whether the deleted QoS flow is associated with the default DRB. If not, proceed to step 210. If the deleted QoS flow is associated with the default DRB, proceed to step 211. Step 210: If the deleted QoS flow is not associated with the default DRB, keep the existing default DRB unchanged. Step 211: If the deleted QoS flow is associated with the default DRB, delete the default DRB; Step 212: Determine if the default DRB candidate pool is empty. If it is not empty, proceed to step 213. If it is empty, proceed to step 214. Step 213: If the default DRB candidate pool is not empty, select a silent DRB from the default DRB candidate pool as the default DRB and execute the steps. Step 214: If the default DRB candidate pool is empty, urgently create a DRB in the default DRB candidate pool and use that DRB as the default DRB.

[0057] Step 215: If a QoS flow increase event occurs, determine whether the increased QoS flow is a GBR service. If yes, proceed to step 216; otherwise, proceed to step 217. Step 216: Configure the uplink SDAP header as needed, and keep the default DRB candidate pool unchanged; Step 217: If the added QoS flow is a non-GBR service, determine whether a default DRB exists. If no default DRB exists, proceed to step 218; otherwise, proceed to step 219. Step 218: If no default DRB exists, set the DRB associated with the added QoS flow as the default DRB and add it to the default DRB candidate pool, and create a new silent DRB in the default DRB candidate pool, and configure the UL SDAP header as present. Step 219: If a default DRB exists, keep the default DRB unchanged, and determine whether to add the DRB associated with the added QoS flow to the default DRB candidate pool based on the comprehensive score of the DRB priority. Based on the above configuration of the default DRB candidate pool, this embodiment of the application maintains the DRBs in the default DRB candidate pool in response to the default DRB candidate pool maintenance command according to the following implementation method: Default DRB candidate pool sorting: Based on the calculated priority comprehensive score S, all DRBs in the default DRB candidate pool are sorted from high to low. If the number of valid DRBs in the default DRB candidate pool is less than 2 (or the configurable threshold N), then a silent DRB will be created and added to the default DRB candidate pool. When the number of DRBs in the default DRB candidate pool is greater than the maximum capacity (e.g., 5), release the silent DRB with the lowest overall priority score and the longest unused time. Silent DRB creation: When it is necessary to expand the default DRB candidate pool, such as... Figure 3 As shown, the specific process for creating a low-priority silent DRB is as follows: Step 1: gNB sends an N2 Session Update message to SMF, notifying SMF that a silent DRB needs to be established; Step 2: SMF creates a new silent DRB and sends an N2 session update response message Nsmf_PDUSession_Update to gNB; Step 3: The gNB sends an RRC Reconfiguration message to the UE, notifying the UE to add a DRB; Step 4: The UE replies to the gNB with an RRC Reconfiguration Complete message. Step 5: After receiving the RRC reconfiguration complete message, the gNB sends an N2 Session Update Ack response message to the SMF, thereby completing the creation of the DRB.

[0058] The configuration of the newly created DRB in this embodiment is as follows: PDUSessionId: Current session ID SDAP-Config: present (UL / DL) QoS Profile: 5QI=9 (or other lowest priority non-GBR 5QI) `noQosFlowMapping: true` means that no QoS flow is mapped; it is a purely logical entity.

[0059] This application embodiment implements a configuration fixation for the silent DRB candidate pool: the SDAP header configuration (present) of all DRBs in the silent DRB candidate pool is prohibited from being modified to ensure configuration consistency when they are used as alternative default DRBs.

[0060] The reason for creating a new silent DRB in this embodiment is that, since the default DRB candidate pool must be configured as present when it is created, if the number of DRBs in the default DRB candidate pool is insufficient, DRBs outside the pool cannot be added (because the configuration cannot be changed). Therefore, a new DRB can only be created, with UL SDAP configured as present, and added to the default DRB candidate pool.

[0061] In related technologies, creating a new silent DRB requires triggering conditions (such as the presence of a new service flow) and cannot be done arbitrarily. However, this application's embodiment proactively triggers the creation of a new non-GBR-associated DRB when the number of DRBs in the default DRB candidate pool is insufficient. This new DRB can be of low priority, does not map any QoS flows, and serves only as a backup default DRB. During creation, SDAP=present is set, and then it is added to the default DRB candidate pool. Thus, when it is necessary to switch the default DRB, the newly created silent DRB can be used.

[0062] In this embodiment, the silent DRB does not map any actual business data streams; it only occupies logical resources, not physical resources, and its actual data scheduling weight is 0. The cost is far less than the cost of reconfiguration failure caused by SDAP header changes. For scenarios with extremely high resource sensitivity, optimization can be achieved by establishing a cross-session shared silent DRB within the gNB.

[0063] The reason why the UL SDAP header corresponding to the DRB in the default DRB candidate pool is configured as "present" in this embodiment is as follows: According to the protocol, the SDAP header of a non-default DRB can be set to "present" or "absent," depending on whether multiple QoS flows are mapped to that DRB. Therefore, if the DRB only carries one QoS flow, it may not need an SDAP header, but setting it to "present" does not violate the protocol. Therefore, the SDAP header can be set to "present" in advance when creating all possible candidate DRBs. In this way, when switching the default DRB, there is no need to modify the SDAP header configuration, thereby avoiding conflicts. In terms of balancing resources and reliability, by creating a silent DRB that occupies logical resources as a backup, the risk of configuration failure is avoided with minimal resource cost.

[0064] Building upon the above embodiments, the default DRB candidate pool mechanism is further extended to mobility management scenarios, supporting the inheritance of the default DRB candidate pool in cross-cell / base station handover scenarios. This resolves the issue of potential reintroduction of SDAP header conflicts due to configuration resets during handover. In some possible embodiments, when a cell handover occurs, the 5G base station or repeater device, acting as the source base station, indicates the default DRB candidate pool context of the target base station's current PDU session via a handover request message. Upon receiving the handover request message, the 5G base station or repeater device, acting as the target base station, prioritizes inheriting the corresponding default DRB candidate pool configuration according to the source base station's indication. If incomplete inheritance is not achieved, the default DRB candidate pool is reconfigured.

[0065] The following is in conjunction with the appendix Figure 4 This application provides an embodiment that extends the handover scenario from a single-cell scenario to a cross-cell scenario, defining methods for the transfer, inheritance, and optimization of candidate pool contexts, thus forming a specific process for an end-to-end solution, such as... Figure 4 As shown, when a UE initiates a handover from the source base station (Source gNB) to the target base station (Target gNB), the following procedure is executed: Step 400, UE handover process begins; Step 401: Enter the handover preparation phase, the source base station decides to initiate the handover; Step 402: After deciding to initiate a handover, the source base station encapsulates the default DRB candidate pool context in the generated Handover Preparation Information and sends a handover request message (containing DefaultDRBCandidatePoolInfo) to the target base station. Specifically, a new information container can be added, such as named DefaultDRBCandidatePoolInfo, to transmit the default DRB candidate pool context of the current PDU session to the target base station. This information container contains the following information: The current default DRB's DRB ID and its configuration, which includes the fixed SDAP-Config=present; Default DRB candidate pool list: This includes detailed information for each DRB in the default DRB candidate pool, including at least: DRB ID; corresponding QoS Profile (mainly 5QI); comprehensive priority score S (or the raw parameters required to calculate S, such as 5QI, service type, historical link quality, etc.); SDAP-Config is fixed at present.

[0066] Step 403: Enter the handover execution phase. After receiving the handover request message from the source base station, the target base station parses the handover request message and prioritizes inheriting the corresponding default DRB candidate pool configuration according to the instructions of the source base station. That is, the target base station attempts to use the same DRB ID and SDAP configuration as the source base station to build its local default DRB and default DRB candidate pool in order to maintain configuration continuity to the greatest extent.

[0067] Step 404: The target base station determines whether it fully inherits the default DRB candidate pool configuration of the source base station. If not, proceed to step 405; otherwise, proceed to step 406. Step 405: If, due to reasons such as insufficient resources required for 5QI of a candidate DRB, the target base station cannot fully inherit the default DRB candidate pool configuration of the source base station, the target base station can perform localized optimization to reconfigure the default DEB candidate pool. Specifically, the following methods can be used: The target base station recalculates the priority comprehensive score S' of DRBs in the default DRB candidate pool based on the radio resource status and policy of the cell; it reorders the default DRB candidate pool according to the new priority comprehensive score S'; if necessary, it can create new silent DRBs to supplement or replace entries in the default DRB candidate pool according to the silent DRB creation rules provided in the above embodiments.

[0068] Step 406: The target base station directly inherits the default DRB candidate pool configuration of the source base station.

[0069] Step 407: The target base station constructs an RRC reconfiguration message (RRCReconfiguration), which includes the inherited or optimized default DRB and candidate pool configuration. Since the configuration (especially the SDAP header) is consistent with the source side or comes from the preset present DRB in the pool, changes to the SDAP header configuration triggered by handover are avoided, thereby preventing reconfiguration failure.

[0070] Step 408: The target base station sends an RRC reconfiguration message to the UE.

[0071] Step 409: After receiving the RRC reconfiguration message, the UE completes the handover.

[0072] Step 410: After the handover is completed, the target base station continues to monitor and maintain the default DRB candidate pool based on the real-time status of the cell, according to the default DRB candidate pool maintenance policy.

[0073] Based on the same inventive concept, this application also provides a device for dynamic configuration of default bearer in multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness, such as... Figure 5 As shown, the device includes: The service type determination module 501 is used to obtain the QoS flow in the currently established PDU session and determine the service corresponding to the QoS flow; The default DRB setting module 502 is used to set the DRB associated with one of the non-GBR services as the default DRB if there is at least one non-GBR service with a non-guaranteed bit rate. The default DRB candidate pool configuration module 503 is used to put the default DRB into the default DRB candidate pool, which also includes at least one spare silent DRB. The uplink SDAP header configuration module 504 is used to configure the uplink service data adaptation protocol SDAP header of each DRB in the default DRB candidate pool as present. The default DRB change module 505 is used to select a silent DRB as the default DRB from the default DRB candidate pool when a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB.

[0074] After introducing the method and apparatus for dynamic configuration of default bearer in multi-QOS flow scenario of 5G base station or repeater equipment based on service type awareness according to exemplary embodiments of this application, the apparatus for dynamic configuration of default bearer in multi-QOS flow scenario of 5G base station or repeater equipment based on service type awareness according to another exemplary embodiment of this application will be introduced next.

[0075] Those skilled in the art will understand that various aspects of this application can be implemented as a system, method, or program product. Therefore, various aspects of this application can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or a combination of hardware and software implementations, collectively referred to herein as a "circuit," "module," or "system."

[0076] In some possible implementations, the default bearer dynamic configuration apparatus for a service type-aware 5G base station or repeater device in a multi-QoS flow scenario according to this application may include at least one processor and at least one memory. The memory stores program code that, when executed by the processor, causes the processor to perform the steps in the default bearer dynamic configuration method for a service type-aware 5G base station or repeater device in a multi-QoS flow scenario according to various exemplary embodiments of this application described above.

[0077] The following reference Figure 6 This application describes a service type-aware 5G base station or repeater device with a default bearer dynamic configuration device 160 in a multi-QOS flow scenario. Figure 6 The shown default bearer dynamic configuration device 160 for 5G base stations or repeaters with service type awareness in multi-QOS flow scenarios is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0078] like Figure 6 As shown, the default bearer dynamic configuration device 160 for multi-QoS stream scenarios of 5G base stations or repeaters based on service type awareness is manifested in the form of a general electronic device. The components of the default bearer dynamic configuration device 160 for multi-QoS stream scenarios of 5G base stations or repeaters based on service type awareness may include, but are not limited to: at least one processor 161, at least one memory 162, and a bus 163 connecting different system components (including memory 162 and processor 161).

[0079] Bus 163 represents one or more of several bus architectures, including a memory bus or memory controller, peripheral bus, processor, or local bus using any of the various bus architectures.

[0080] The memory 162 may include a readable medium in the form of volatile memory, such as random access memory (RAM) 1621 and / or cache memory 1622, and may further include read-only memory (ROM) 1623.

[0081] The memory 162 may also include a program / utility 1625 having a set (at least one) of program modules 1624, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0082] The default bearer dynamic configuration device 160 for multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness can also communicate with one or more external devices 164 (e.g., keyboards, pointing devices, etc.), one or more devices that enable users to interact with the default bearer dynamic configuration device 160 for multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness, and / or any device (e.g., routers, modems, etc.) that enables the default bearer dynamic configuration device 160 for multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness to communicate with one or more other electronic devices. This communication can be performed through input / output (I / O) interface 165. Furthermore, the default bearer dynamic configuration device 160 for multi-QoS flow scenarios of 5G base stations or repeaters based on service type awareness can also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) through network adapter 166. As shown in the figure, network adapter 166 communicates via bus 163 with other modules of the default bearer dynamic configuration device 160 for multi-QoS stream scenarios of service-type-aware 5G base stations or repeaters. It should be understood that, although not shown in the figure, other hardware and / or software modules can be used in conjunction with the default bearer dynamic configuration device 160 for multi-QoS stream scenarios of service-type-aware 5G base stations or repeaters, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0083] In some possible implementations, various aspects of the default bearer dynamic configuration method in a multi-QoS flow scenario provided in this application can also be implemented in the form of a program product, which includes program code. When the program product is run on a computer device, the program code is used to cause the computer device to perform the steps in the service type-aware 5G base station or repeater device multi-QoS flow dynamic configuration method according to various exemplary embodiments of this application described above.

[0084] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0085] The program product for dynamic configuration of default bearer in multi-QOS flow scenarios of service type-aware 5G base stations or repeater equipment according to the embodiments of this application can adopt a portable compact disk read-only memory (CD-ROM) and include program code, and can run on an electronic device. However, the program product of this application is not limited to this. In this document, the readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0086] A readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying readable program code. This propagated data signal may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting a program for use by or in conjunction with an instruction execution system, apparatus, or device.

[0087] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0088] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's electronic device, partially on the user's device, as a standalone software package, partially on the user's electronic device and partially on a remote electronic device, or entirely on a remote electronic device or server. In cases involving remote electronic devices, the remote electronic device can be connected to the user's electronic device via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external electronic device (e.g., via the Internet using an Internet service provider).

[0089] It should be noted that although several units or sub-units of the device have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of this application, the features and functions of two or more units described above can be embodied in one unit. Conversely, the features and functions of one unit described above can be further divided and embodied by multiple units.

[0090] Furthermore, although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0091] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0092] This application is described with reference to flowchart illustrations and block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block and / or segment of the flowchart illustrations and block diagrams, as well as combinations of blocks and segments in the flowchart illustrations and block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart. Figure 1 One or more processes and boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0093] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and boxes Figure 1 The function specified in one or more boxes.

[0094] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and boxes Figure 1 The steps of the function specified in one or more boxes.

[0095] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0096] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A method for dynamic configuration of default bearer in multi-QoS flow scenarios of 5G base station or repeater equipment based on service type awareness, characterized in that, The method includes: Obtain the QoS flow in the currently established PDU session and determine the service corresponding to the QoS flow; If there is at least one non-GBR service with a non-guaranteed bit rate, set the DRB associated with one of the non-GBR services as the default DRB. The default DRB is placed into the default DRB candidate pool, which also includes at least one standby silent DRB. Configure the uplink service data adaptation protocol SDAP header of each DRB in the default DRB candidate pool as present; When a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB, a silent DRB is selected from the default DRB candidate pool as the default DRB.

2. The method according to claim 1, characterized in that, It also includes at least one of the following steps: If there is no non-GBR service, configure the uplink SDAP header of all DRBs associated with QoS flows as absent; Set one of the non-GBR service-related DRBs as the default DRB, including: If a non-GBR service exists, the DRB associated with the non-GBR service is set as the default DRB, and a new silent DRB is created in the default DRB candidate pool. If there are multiple non-GBR services, the DRB associated with one of the non-GBR services will be set as the default DRB based on the overall score of DRB priority, and the DRB associated with at least one other non-GBR service will be set as a silent DRB and then put into the default DRB candidate pool.

3. The method according to claim 1, characterized in that, It also includes at least one of the following steps: If the deleted QoS flow is not associated with the default DRB, the default DRB candidate pool remains unchanged; If the deleted QoS flow is associated with the current default DRB, it also includes: Before selecting a silent DRB from the default DRB candidate pool as the default DRB, if it is determined that there is no silent DRB in the default DRB candidate pool, a new silent DRB is created in the default DRB candidate pool, and the UE is instructed to completely clear the previous DRB configuration.

4. The method according to claim 1, characterized in that, It also includes at least one of the following steps: When a QoS flow addition event occurs, if the added QoS flow is a GBR service and a default DRB currently exists, the default DRB candidate pool remains unchanged. When a QoS flow increase event occurs, if the increased QoS flow is a non-GBR service and a default DRB currently exists, the default DRB remains unchanged, and the DRB associated with the increased QoS flow is added to the default DRB candidate pool based on the DRB priority comprehensive score. When a QoS flow addition event occurs, if the added QoS flow is a non-GBR service and there is no default DRB, the DRB associated with the added QoS flow is set as the default DRB and placed in the default DRB candidate pool, and a new silent DRB is created in the default DRB candidate pool.

5. The method according to claim 1, characterized in that, Also includes: In response to the default DRB candidate pool maintenance command, determine the number of DRBs in the current default DRB candidate pool; If the number of DRBs is greater than 1 and not greater than the maximum capacity, then the current default DRB candidate pool remains unchanged. If the number of DRBs is no greater than 1 and there is currently a non-GBR service, a new silent DRB will be created in the default DRB candidate pool; If the number of DRBs exceeds the maximum capacity, based on the priority score of the DRBs, the corresponding number of DRBs will be released until the number of DRBs does not exceed the maximum capacity.

6. The method according to claim 2, 4 or 5, characterized in that, The priority score of the DRB is determined in the following way: Determine the factor score corresponding to at least one of the following factors in the DRB protocol: standard priority level, service type weight, and link quality. The priority comprehensive score of the DRB is determined based on the factor scores and their corresponding weights.

7. The method according to claim 1, characterized in that, Also includes: When a cell handover occurs, the 5G base station or repeater equipment, acting as the source base station, indicates the default DRB candidate pool context of the target base station's current PDU session through a handover request message. When a cell handover occurs, the 5G base station or repeater device, as the target base station, receives the handover request message and prioritizes inheriting the corresponding default DRB candidate pool configuration according to the instructions of the source base station. If it is determined that the inheritance is not complete, the default DEB candidate pool will be reconfigured.

8. A device for dynamic configuration of default bearer in multi-QoS flow scenarios of 5G base station or repeater equipment based on service type awareness, characterized in that, The device includes: The service type determination module is used to obtain the QoS flow in the currently established PDU session and determine the service corresponding to the QoS flow; The default DRB setting module is used to set the DRB associated with one of the non-GBR services as the default DRB if there is at least one non-GBR service with a non-guaranteed bit rate. A default DRB candidate pool configuration module is used to put the default DRB into the default DRB candidate pool, which also includes at least one spare silent DRB. The uplink SDAP header configuration module is used to configure the uplink service data adaptation protocol SDAP header of each DRB in the default DRB candidate pool as present. The default DRB change module is used to select a silent DRB as the default DRB from the default DRB candidate pool when a QoS flow deletion event occurs, if the deleted QoS flow is associated with the current default DRB.

9. A device for dynamic configuration of default bearer in multi-QoS flow scenarios of 5G base station or repeater equipment based on service type awareness, characterized in that, The method includes at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method as described in any one of claims 1-7.

10. A computer storage medium, characterized in that, The computer storage medium stores a computer program that enables the computer to perform the method as described in any one of claims 1-7.

Images