Methods for handling errors in radio link control, communication equipment, computer-readable storage media, and base stations.

Abstract

The invention relates to a method for handling errors in radio link control, communication apparatus, and computer-readable storage media, and relates to the communication domain, to ensure that the distributed unit (DU) correctly performs layer 2 (L2) processing in a centralized unit (CU) - DU architecture. Specifically, the notification method includes: the CU sends a first message to the DU, where the first message includes the identity (ID) of the data radio bearer (DRB) on which the change in carrier type occurs and an indication that the DU performs L2 processing; or the first message includes the ID of the first DRB and a second indication that the change in carrier type occurs. The CU receives a second message sent by the DU, where the second message includes the cell group configuration of the L2 processing.

Description

A notification method, apparatus and communication system

[0001] This application claims priority to Chinese Patent Application No. 201810914051.3, filed with the State Intellectual Property Office of China on August 10, 2018, entitled "A Notification Method, Apparatus and Base Station", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of communications, and more particularly to a notification method, apparatus, and communication system. Background Technology

[0003] With the rapid development of communication technology, mobile communication has entered the 5th generation (5G) era. For 5G, the two-tier access network architecture based on centralized unit-distributed unit (CU-DU) has been widely accepted in the industry. This network architecture, combined with wireless cloudification, constitutes the two fundamental elements of the 5G cloud radio access network (C-RAN). Therefore, the CU-DU architecture is the foundation for C-RAN research.

[0004] Currently, the 5G radio access network (RAN) architecture considers base stations to be deployed independently using CUs (Cubic Control Units) and DUs (Digital Units) to better meet the needs of various scenarios and applications. A base station can include one CU and one or more DUs. The CU-DU partitioning method of a base station is not visible to the outside world. When the base station adopts a CU-DU architecture, the protocol layers are divided. The radio link control (RLC) layer, media access control (MAC) layer, and physical layer (PHY) layer are handled by the DU, while the CU is responsible for the radio resource control (RRC) layer, service data adaptation protocol (SDAP) layer, and packet data convergence protocol (PDCP) layer. The CU and DU perform relevant configurations for their respective protocol layers.

[0005] In network applications, situations requiring Layer 2 (L2) processing (such as bearer type switching or RLC failure) occur frequently. In the CU-DU architecture, how the DU learns about these L2 processing needs and configures the RLC and MAC layers accordingly becomes a pressing issue.

[0006] Summary of the Invention

[0007] This application provides a notification method, apparatus, and communication system to ensure accurate L2 processing of the DU in a CU-DU architecture.

[0008] To achieve the above objectives, the embodiments of this application adopt the following technical solutions:

[0009] In a first aspect, this application provides a notification method applied to a CU in a CU-DU architecture. The method may include: the CU sending a first message to the DU, the first message including the identity (ID) of a first data radio bearer (DRB) undergoing bearer type switching and first indication information instructing the DU to perform L2 processing; or, the first message including the ID of the first DRB and second indication information indicating that bearer type switching has occurred. The CU receives a second message sent by the DU, the second message including cell group configuration for L2 processing.

[0010] The notification method provided in this application allows the CU to notify the DU of the ID of the first DRB where a bearer type switch has occurred and a first indication of the DU's L2 processing plan; alternatively, the CU may notify the DU of the ID of the first DRB and notify the DU of the bearer type switch via a second indication. This enables the DU to know the DRB ID where the bearer type switch has occurred and the L2 processing plan; or, enables the DU to know which DRBs have undergone bearer type switches, facilitating the DU to perform the accurate corresponding L2 processing for L2 configuration adapted to changes in the user equipment communication link.

[0011] Bearer type change is a network operation that switches bearers according to business needs in a network that supports multiple bearer types.

[0012] The first instruction information is used to indicate the specific scheme for L2 processing executed by the DU in the CU decision. The type and content of this instruction information can be configured according to actual needs, and this application does not impose specific limitations on it. For example, the first instruction information can be the name information of the L2 processing, that is, the name of each L2 processing scheme can be defined, and the scheme name can be used as the first instruction information; or, the first instruction information can be the content information of the L2 processing, that is, the content of the L2 processing scheme can also be used as the first instruction information; or, the first instruction information can be the identification information of the L2 processing, and the identification of each L2 processing scheme can be configured, and the identification can be used as the first instruction information. Of course, any information that can be used to indicate the specific scheme of L2 processing can be used as the first instruction information.

[0013] The second indication information is used to notify the DU that a bearer type change has occurred. The form and content of this second indication information can be configured according to actual needs, and this application does not impose specific limitations on it. For example, the second indication information can be the name information of the network operation of bearer type change, that is, using fields such as "bearer type change," "key change," or "bearer type change with key change" as the second indication information; or, the second indication information can be the representation information of the network operation of bearer type change, that is, defining a network identifier for this network operation in the network to uniquely indicate that a bearer type change has occurred, and using this network identifier as the first indication information, etc. Any information that can be used to indicate that a network operation of bearer type change has occurred can be used as the second indication information.

[0014] It should be noted that the first DRB can be at least one DRB. The same L2 processing or different L2 processing may be performed on each first DRB. This application describes a specific scheme using the processing of one first DRB as an example; other methods will not be elaborated upon further.

[0015] In conjunction with the first aspect, in one possible implementation, this application provides several specific schemes for performing L2 processing. Performing L2 processing may specifically include: MAC reset and RLC re-establishment; or, changing the logical channel identifier (LCID) and RLC re-establishment; or, MAC reset by reconfiguration with synchronization and RLC re-establishment; or, changing the LCID and releasing and adding RLC bearers. Specifically, MAC synchronization reconfiguration can be understood as implementing MAC reset through synchronization reconfiguration.

[0016] Optionally, the specific scheme for L2 handling can be found in Table A-1 of the 3rd generation partnership project (3GPP) protocol, which is named L2handling for bearer type change with and without security key change. It will not be elaborated here.

[0017] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first message may further include a master cell group (MCG) indication, which indicates that the base station in the CU-DU architecture is the master node (MN) in the dual-connectivity architecture. In this case, the DU performing L2 processing may include: MAC reset and RLC re-establishment; or, changing the LCID and RLC re-establishment.

[0018] The MCG indicator can be the MCG string itself, or other pre-configured characters or bits. For example, the MCG / SCG indicator may contain an enumerated value of MCG, or the MCG / SCG indicator = 0 indicates MCG. This application does not impose any specific limitations on this.

[0019] It should be noted that the dual connectivity structure in this paper can be an evolved universal mobile telecommunications system terrestrial radio access network (E-UTRAN) and new radio (NR) dual connectivity (E-UTRAN-NR dual connectivity, EN-DC) architecture, or a multi-radio access type dual connectivity (MR-DC) architecture, or NR-DC i.e. new radio dual connectivity, or Long Term Evolution (LTE) DC i.e. LTE dual connectivity, or other dual connectivity architectures. This application does not specifically limit this.

[0020] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first message may further include a secondary cell group (SCG) indication, which indicates that the base station in the CU-DU architecture plays the role of a secondary node (SN) in the dual-connectivity architecture. In this case, the DU performing L2 processing may include: MAC synchronization reconfiguration and RLC re-establishment; or, changing the LCID and releasing and adding RLC bearers.

[0021] The SCG indicator can be the SCG string itself, or other pre-configured characters or bits. For example, the MCG / SCG indicator may contain an enumeration value of SCG, or the MCG / SCG indicator = 1 indicates SCG. This application does not impose any specific limitations on this.

[0022] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first message may further include: the ID of a second DRB, which is used to replace the ID of the first DRB. When the bearer type is switched and the DRB ID needs to be changed, the first message replaces the ID of the first DRB by including the ID of the second DRB.

[0023] It should be noted that when switching bearer types, the bearer identifier after the switch can be the same as the bearer identifier before the switch. In this case, the ID of the second DRB may not be included in the first message.

[0024] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first message may include, but is not limited to: a UE context modification request message, or an F1 interface message, or a W1 interface message. Of course, the type of the first message can be selected according to actual needs, and this application does not impose specific limitations on it.

[0025] Optionally, the first message can be a CU-DU interface message, that is, a message transmitted on the interface between the CU and the DU. When the network standard of the CU-DU architecture is different, the interface message can also be defined with different names, which are not specifically limited in this application. For example, F1 interface message refers to the general term for messages transmitted on the interface between the CU and the DU in a new radio (NR) network. In an LTE network, the interface between the CU and the DU in a CU-DU architecture base station can be defined as the W1 interface, and the messages transmitted on the W1 interface are called W1 messages.

[0026] The UE context modification request message is an F1 interface message. Of course, the first message can be other types of F1 messages, and this application does not specifically limit it.

[0027] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the second message may include: a response message to the UE context modification request message.

[0028] In one possible implementation, if the first message is a request message of a request-response mechanism, then the second message can be a response message to the first message; if the first message is a message of a non-request-response mechanism, then the second message is a separate message. This application does not specifically limit the type of the second message.

[0029] For example, the second message is a UE context modification response message.

[0030] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first field of the UE context modification request message includes the ID of the first DRB and first indication information; or, the first field of the UE context modification request message includes the ID of the first DRB and second indication information. Here, the first field can be any field in the UE context modification request message, and this application does not specifically limit it.

[0031] It should be noted that the ID of the first DRB and the first indication information, or the ID of the first DRB and the second indication information, can be directly included in the first message at the same level as the fields, or they can be included in a field of the first message. This application does not impose specific limitations on this.

[0032] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first field may include the DRB modification list field of the first DRB.

[0033] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, the first field may include a newly added field, the name of which can be configured according to actual needs, and this application does not impose specific limitations on it.

[0034] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, if the first message includes the ID of the first DRB and the first indication information, the notification method provided by the first aspect of this application may further include: a scheme for CU decision-making and L2 processing. In practical applications, the algorithm of the decision-making L2 processing scheme can be selected according to actual needs, and this application does not impose specific limitations on it.

[0035] In conjunction with the first aspect or any of the above possible implementations, in another possible implementation, after the CU receives the second message sent by the DU, the notification method provided in this application may further include: the CU sending an RRC reconfiguration message including cell group configuration to the user equipment (UE), so that the UE performs corresponding L2 processing according to the cell group configuration including L2 processing, thereby ensuring the consistency of network communication.

[0036] In another possible implementation, the notification method provided in this application can be implemented through the user plane (UP). In this implementation, the first message includes the tunnel endpoint identifier (TEID) corresponding to the first DRB ID and first indication information; or, the first message includes the TEID corresponding to the first DRB ID and second indication information. Alternatively, the first message includes the interface transport layer address corresponding to the first DRB ID and first indication information; or, the first message includes the interface transport layer address corresponding to the first DRB ID and second indication information. Alternatively, the first message includes the TEID corresponding to the first DRB ID, the interface transport layer address, and first indication information; or, the first message includes the TEID corresponding to the first DRB ID, the interface transport layer address, and second indication information. Specific implementations can be found in the control plane implementation described above, and will not be elaborated further here. In this case, the first message may include a downlink protocol data unit (PDU).

[0037] Secondly, this application provides another notification method, which is applied to a DU in a CU-DU architecture. The method may include: the DU receiving a first message from the CU, the first message including the ID of a first DRB in which a bearer type switch has occurred and first indication information instructing the DU to perform L2 processing; or, the first message including the ID of the first DRB and second indication information instructing the DU to perform L2 processing; the DU performing L2 processing; the DU sending a second message to the CU, the second message including the cell group configuration for L2 processing.

[0038] The notification method provided in this application allows the DU to obtain the ID of the first DRB that has undergone a bearer type switch and first indication information for performing L2 processing from the CU; or, the DU to obtain the ID of the first DRB and second indication information for the bearer type switch. This enables the DU to know the DRB ID that has undergone a bearer type switch and the L2 processing scheme; or, enables the DU to know which DRBs have undergone bearer type switches, facilitating the DU to perform the accurate corresponding L2 processing for L2 configuration adapted to changes in the user equipment communication link.

[0039] In conjunction with the second aspect, in one possible implementation, if the first message includes the ID of the first DRB and the second indication information, the DU performs L2 processing, which specifically includes: the DU making a decision and performing L2 processing. In practical applications, the algorithm for the L2 processing decision can be selected according to actual needs, and this application does not impose specific limitations on it.

[0040] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, this application provides several specific schemes for performing L2 processing. Performing L2 processing may specifically include: MAC reset and RLC re-establishment; or, changing the LCID and RLC re-establishment; or, MAC reset by reconfiguration with synchronization and RLC re-establishment; or, changing the LCID and releasing and adding the RLC bearer. Specifically, MAC synchronization reconfiguration can be understood as implementing MAC reset through synchronization reconfiguration.

[0041] Optionally, the specific scheme for L2 processing can be found in Table A-1 of TS37.340 in the 3GPP protocol, which will not be elaborated here.

[0042] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the first message may further include an MCG indication used to indicate that the CU-DU is the MN role in a dual-connectivity architecture. In this case, the DU performing L2 processing may include: MAC reset and RLC re-establishment; or, changing the LCID and RLC re-establishment.

[0043] The MCG indicator can be the MCG string itself, or other pre-configured characters or bits. For example, the MCG / SCG indicator may contain an enumerated value of MCG, or the MCG / SCG indicator = 0 indicates MCG. This application does not impose any specific limitations on this.

[0044] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the first message may further include an SCG indication used to indicate that the CU-DU is in the SN role in a dual-connectivity architecture. In this case, the DU performing L2 processing may include: MAC synchronization reconfiguration and RLC re-establishment; or, changing the LCID and releasing and adding RLC bearers.

[0045] The SCG indicator can be the SCG string itself, or other pre-configured characters or bits. For example, the MCG / SCG indicator may contain an enumeration value of SCG, or the MCG / SCG indicator = 1 indicates SCG. This application does not impose any specific limitations on this.

[0046] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the first message may further include: the ID of the second DRB, which is used to replace the identifier of the first DRB. When the bearer type is switched and the DRB ID needs to be changed, the first message replaces the first DRB ID by including the ID of the second DRB. The notification method provided in the second aspect of this application may further include: the DU performing L2 processing on the first DRB and / or the second DRB.

[0047] The DU performing L2 processing on the first DRB and / or the second DRB refers to a series of operations within the L2 processing performed by the DU. The operation target can be one or both of the first and second DRBs. For example, if the L2 processing performed by the DU is the release and addition of an RLC bearer, then a release operation is performed on the first DRB, and an addition operation is performed on the second DRB. The DU performing L2 processing on the first DRB and / or the second DRB means that when performing L2 processing, the DU associates all configurations related to the first DRB with the second DRB. When performing a change of LCID, the DU associates the changed LCID with the second DRB identifier. Furthermore, the DU also associates the F1 interface user plane tunnel associated with the first DRB identifier with the second DRB identifier.

[0048] It should be noted that when switching bearer types, the ID of the new bearer can be the same as the ID of the old bearer. In this case, the ID of the second DRB may not be included in the first message.

[0049] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the first message may include, but is not limited to: a UE context modification request message, or an F1 interface message, or a W1 interface message. Of course, the type of the first message can be selected according to actual needs, and this application does not impose specific limitations on it.

[0050] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the second message may include: a response message to the UE context modification request message.

[0051] In one possible implementation, if the first message is a request-response mechanism message, then the second message can be a response message to the first message; if the first message is not a request-response mechanism message, then the second message is a separate message. This application does not specifically limit the type of the second message.

[0052] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the first field of the UE context modification request message includes the ID of the first DRB and first indication information; or, the first field of the UE context modification request message includes the ID of the first DRB and second indication information. Here, the first field can be any field in the UE context modification request message, and this application does not specifically limit it.

[0053] It should be noted that the ID of the first DRB and the first indication information, or the ID of the first DRB and the second indication information, can be directly included in the first message at the same level as the fields, or they can be included in a field of the first message. This application does not impose specific limitations on this.

[0054] In conjunction with the second aspect or any of the above possible implementations, in another possible implementation, the first field may include the DRB modification list field of the first DRB.

[0055] In another possible implementation of the second aspect, the notification method provided in this application can be implemented using UP. In this implementation, the first message includes the interface TEID corresponding to the first DRB ID and first indication information; or, the first message includes the TEID corresponding to the first DRB ID and second indication information; or, the first message includes the interface transport layer address corresponding to the first DRB ID and first indication information; or, the first message includes the interface transport layer address corresponding to the first DRB ID and second indication information; or, the first message includes the TEID corresponding to the first DRB ID, the interface transport layer address, and first indication information; or, the first message includes the TEID corresponding to the first DRB ID, the interface transport layer address, and second indication information. Specific implementations can be found in the above-described control plane implementations, which will not be elaborated upon here. In this case, the first message may include a downlink PDU.

[0056] It should be noted that the notification methods provided in the first and second aspects are the same method described from the perspective of CU and DU in the CU-DU architecture, and their specific implementations can be referenced from each other.

[0057] Thirdly, this application provides another notification method, which is applied to a DU in a CU-DU architecture. The method may include: the DU receiving a third message from the CU, the third message including an LCID indicating an RLC failure and indication information instructing the DU to perform L2 processing; or, the third message including an LCID indicating an RLC failure; the DU performing L2 processing; and the DU sending a fourth message to the CU, the fourth message including cell group configuration for L2 processing.

[0058] The notification method provided in this application allows the DU to obtain the LCID of the RLC failure and the instruction information instructing the DU to perform L2 processing from the CU; or, the DU obtains the LCID of the RLC failure from the CU to determine that an RLC failure has occurred. This enables the DU to know the LCID of the RLC failure and the L2 processing plan; or, enables the DU to know which LCIDs have experienced RLC failure, facilitating the DU to perform the accurate corresponding L2 processing for L2 configuration adapted to changes in the user equipment communication link.

[0059] RLC failure occurs when all serving cells associated with an RLC do not include the primary cell (PCell) or the primary secondary cell (PSCell) but only the secondary cell (SCell), and the RLC retransmission reaches the maximum number of times.

[0060] Optionally, RLC failure can occur in a dual-connectivity network or in a single-connectivity network performing carrier aggregation (CA), and this application does not specifically limit this.

[0061] The instruction information instructing the DU to perform L2 processing is used to indicate the specific plan for the DU to perform L2 processing in the event of an RLC failure, as determined by the CU's decision. The type and content of this instruction information can be configured according to actual needs, and this application does not impose specific limitations on it. For example, the instruction information can be the name information of the L2 processing, that is, the name of each L2 processing plan can be defined and used as the instruction information; or, the instruction information can be the content information of the L2 processing, that is, the content of the L2 processing plan can also be used as the instruction information; or, the instruction information can be the identification information of the L2 processing, that is, the identifier of each L2 processing plan can be configured and used as the instruction information. Of course, any information that can be used to indicate a specific plan for L2 processing can be used as instruction information to instruct the DU to perform L2 processing.

[0062] In conjunction with the third aspect, in one possible implementation, the indication information may include any of the following indications: whether to retain duplicate PDCPs; whether to delete duplicate PDCPs; whether to delete LCIDs; and whether to retain LCIDs. Of course, depending on the L2 processing scheme, the specific content of the indication information can be configured according to actual needs, and this application does not impose specific limitations on it.

[0063] Among them, PDCP duplication, or PDCP duplication mechanism, is to copy the PDCP PDU twice and then transmit it through two RLC entities.

[0064] In conjunction with the third aspect or any of the above possible implementations, in another possible implementation, if the third message only includes the LCID of RLC failure, the DU performs L2 processing, which may specifically include: the DU making a decision and performing L2 processing. In practical applications, the algorithm for the L2 processing decision can be selected according to actual needs, and this application does not impose specific limitations on it.

[0065] In conjunction with the third aspect or any of the above possible implementations, in another possible implementation, performing L2 processing includes at least one of the following schemes: deleting SCells corresponding to LCIDs that have failed RLC, deleting LCIDs that have failed RLC, deactivating PDCP duplicates, retaining PDCP duplicates, deleting PDCP duplicates, and re-establishing RLC. Of course, the scheme for performing L2 processing can also be configured according to actual needs, and this application does not impose specific limitations on it.

[0066] In conjunction with the third aspect or any of the above possible implementations, in another possible implementation, the third message may include, but is not limited to: a UE context modification request message, or an F1 interface message, or a W1 interface message. Of course, the type of the third message can be selected according to actual needs, and this application does not impose specific limitations on it.

[0067] Optionally, the first message can be a CU-DU interface message, that is, a message transmitted on the interface between the CU and DU. When the network standard of the CU-DU architecture is different, the interface message can also be defined with different names, which are not specifically limited in this application. For example, F1 interface message refers to the general term for messages transmitted on the interface between the CU and DU in the NR network. In the LTE network, the interface between the CU and DU in the CU-DU architecture base station can be defined as the W1 interface, and the messages transmitted on the W1 interface are called W1 messages.

[0068] The UE context modification request message is an F1 interface message. Of course, the third message can be other types of F1 messages, and this application does not specifically limit it.

[0069] In combination with the third aspect or any of the above possible implementations, in another possible implementation, the fourth message may include: a response message to the UE context modification request message.

[0070] In one possible implementation, if the third message is a request message of a request-response mechanism, then the fourth message can be a response message to the third message; if the third message is a message of a non-request-response mechanism, then the fourth message is a separate message. This application does not specifically limit the type of the fourth message.

[0071] It should be noted that the LCID of the RLC failure and the indication information, or the LCID of the RLC failure, can be directly included in the third message at the same level as the fields, or it can be included in a field of the third message. This application does not impose specific limitations on this.

[0072] In conjunction with the third aspect or any of the above possible implementations, in another possible implementation, the LCID with RLC failure list field in the UE context modification request message includes the LCIDs that have failed RLC and indication information instructing the DU to perform L2 processing; or, the LCID with RLC failure list field in the UE context modification request message includes the LCIDs that have failed RLC. Of course, other fields in the UE context modification request message may also include the LCIDs that have failed RLC and indication information instructing the DU to perform L2 processing, or simply the LCIDs that have failed RLC; this application embodiment does not specifically limit this.

[0073] In another possible implementation, the notification method provided in this application can be implemented via UP. In this implementation, the third message includes the TEID and / or interface transport layer address corresponding to the LCID that caused the RLC failure, an RLC failure indication, and indication information instructing the DU to perform L2 processing; or, the third message includes the TEID and / or interface transport layer address corresponding to the LCID that caused the RLC failure, and indication information instructing the DU to perform L2 processing; or, the third message includes the TEID and / or interface transport layer address corresponding to the LCID that caused the RLC failure, and an RLC failure indication. Specific implementations can be found in the control plane implementations described above, and will not be elaborated upon here. In this case, the third message may include a downlink PDU.

[0074] Fourthly, this application provides another notification method, characterized in that the method is applied to a CU in a CU-DU architecture, and the method may include: the CU sending a third message to the DU, the third message including an LCID indicating an RLC failure and indication information instructing the DU to perform L2 processing, or the third message including an LCID indicating an RLC failure; the CU receiving a fourth message sent by the DU, the fourth message including cell group configuration for L2 processing.

[0075] The notification method provided in this application allows the CU to notify the DU of the LCID indicating an RLC failure and an instruction to the DU to perform L2 processing; alternatively, the CU can notify the DU of the LCID indicating an RLC failure. This allows the DU to know the LCID indicating an RLC failure and the corresponding L2 processing plan; or, by knowing that an RLC failure has occurred, the DU can execute the appropriate L2 processing to adapt to changes in the terminal device's communication link.

[0076] It should be noted that the notification method provided in the fourth aspect and the notification method provided in the third aspect above are the same method described from the perspective of CU and DU in the CU-DU architecture, and their specific implementations can be referenced from each other.

[0077] The instructions and RLC failures have already been described in detail in the third part, and will not be repeated here.

[0078] In conjunction with the fourth aspect, in one possible implementation, the indication information may include any of the following indications: whether to retain duplicate PDCPs; whether to delete duplicate PDCPs; whether to delete LCIDs; and whether to retain LCIDs. Of course, depending on the L2 processing scheme, the specific content of the indication information can be configured according to actual needs, and this application does not impose specific limitations on it.

[0079] In conjunction with the fourth aspect or any of the above possible implementations, in another possible implementation, performing L2 processing includes at least one of the following schemes: deleting SCells corresponding to LCIDs that have failed in RLC, deleting LCIDs that have failed in RLC, deactivating PDCP duplicates, retaining PDCP duplicates, deleting PDCP duplicates, and re-establishing RLC. Of course, the scheme for performing L2 processing can also be configured according to actual needs, and this application does not impose specific limitations on it.

[0080] In conjunction with the fourth aspect or any of the above possible implementations, in another possible implementation, the third message may include, but is not limited to: a UE context modification request message, an F1 interface message, or a W1 interface message. Of course, the type of the third message can be selected according to actual needs, and this application does not impose specific limitations on it.

[0081] In combination with the fourth aspect or any of the above possible implementations, in another possible implementation, the fourth message may include: a response message to the UE context modification request message.

[0082] In one possible implementation, if the third message is a request message of a request-response mechanism, then the fourth message can be a response message to the third message; if the third message is a message of a non-request-response mechanism, then the fourth message is a separate message. This application does not specifically limit the type of the fourth message.

[0083] In conjunction with the fourth aspect or any of the above possible implementations, in another possible implementation, the LCID with RLC failure list field in the UE context modification request message includes the LCIDs that have failed RLC and indication information instructing the DU to perform L2 processing; or, the LCID with RLC failure list field in the UE context modification request message includes the LCIDs that have failed RLC. Of course, other fields in the UE context modification request message may also include the LCIDs that have failed RLC and indication information instructing the DU to perform L2 processing, or the LCIDs that have failed RLC; this application embodiment does not specifically limit this.

[0084] In conjunction with the fourth aspect or any of the above possible implementations, in another possible implementation, if the third message includes the LCID indicating RLC failure and indication information, the notification method provided in the fourth aspect of this application may further include: a CU decision-making L2 processing scheme. In practical applications, the algorithm for the decision-making L2 processing scheme can be selected according to actual needs, and this application does not impose specific limitations on it.

[0085] In conjunction with the fourth aspect or any of the above possible implementations, in another possible implementation, after the CU receives the fourth message sent by the DU, the notification method provided in this application may further include: the CU sending an RRC reconfiguration message including the cell group configuration to the UE, so that the UE performs corresponding L2 processing according to the cell group configuration of L2 processing, thereby ensuring the consistency of network communication.

[0086] In another possible implementation, the notification method provided in this application can be implemented via UP. In this implementation, the third message includes the TEID and / or interface transport layer address corresponding to the LCID that caused the RLC failure, an RLC failure indication, and indication information instructing the DU to perform L2 processing; or, the third message includes the TEID and / or interface transport layer address corresponding to the LCID that caused the RLC failure, and indication information instructing the DU to perform L2 processing; or, the third message includes the TEID and / or interface transport layer address corresponding to the LCID that caused the RLC failure, and an RLC failure indication. Specific implementations can be found in the control plane implementations described above, and will not be elaborated upon here. In this case, the third message may include a downlink PDU.

[0087] It should be noted that the notification method provided in this application can be executed by the CU / DU, or by a functional unit or chip in the CU / DU, and this application does not make any specific limitations on it.

[0088] Fifthly, this application provides a communication device deployed in a CU-DU architecture. The device may include a transmitting unit and a receiving unit. The transmitting unit is configured to transmit a first message to the DU, the first message including the ID of a first DRB where a bearer type switch has occurred and first indication information instructing the DU to perform L2 processing; or, the first message including the ID of the first DRB and second indication information instructing the DU to perform L2 processing. The receiving unit is configured to receive a second message transmitted by the DU, the second message including cell group configuration for L2 processing.

[0089] The communication device provided in this application notifies the DU of the ID of the first DRB that has undergone a bearer type switch and the first indication information of the DU's L2 processing scheme; or, the communication device notifies the DU of the ID of the first DRB and notifies the DU of the bearer type switch that a bearer type switch has occurred through the second indication information. In this way, the DU knows the DRB ID that has undergone a bearer type switch and the L2 processing scheme; or, the DU knows which DRBs have undergone a bearer type switch, so that the DU can perform the corresponding L2 processing accurately to adapt to the changes in the communication link of the terminal device.

[0090] In conjunction with the fifth aspect, in one possible implementation, performing L2 processing may include: MAC reset and RLC re-establishment; or, changing LCID and RLC re-establishment; or, MAC synchronization reconfiguration and RLC re-establishment; or, changing LCID and RLC bearer release and addition.

[0091] In conjunction with the fifth aspect or any of the above possible implementations, in another possible implementation, the first message may also include an MCG instruction, and the execution of L2 processing may specifically include: MAC reset and RLC re-establishment; or, changing LCID and RLC re-establishment.

[0092] In conjunction with the fifth aspect or any of the above possible implementations, in another possible implementation, the first message may also include an SCG instruction, and the execution of L2 processing may specifically include: MAC synchronization reconfiguration and RLC re-establishment; or, changing the LCID and releasing and adding RLC bearers.

[0093] In conjunction with the fifth aspect or any of the above possible implementations, in another possible implementation, the first message may further include: the ID of the second DRB, which is used to replace the ID of the first DRB.

[0094] It should be noted that the communication device provided in the fifth aspect is used to execute the notification method provided in the first aspect. Its specific implementation can be referred to the implementation in the first aspect, and will not be repeated here.

[0095] Sixthly, this application provides another communication device deployed in a DU within a CU-DU architecture. The device may include a receiving unit, a processing unit, and a transmitting unit. The receiving unit is configured to receive a first message from the CU, the first message including the ID of a first DRB where a bearer type handover has occurred and first indication information instructing the DU to perform L2 processing; or, the first message including the ID of the first DRB and second indication information instructing the DU to perform L2 processing. The processing unit is configured to perform L2 processing. The transmitting unit is configured to send a second message to the CU, the second message including cell group configuration for L2 processing.

[0096] The communication device provided in this application obtains the ID of the first DRB that has undergone a bearer type switch and first indication information for performing L2 processing from the CU; or, the communication device obtains the ID of the first DRB from the CU and obtains second indication information that a bearer type switch has occurred. This allows the communication device to know the DRB ID that has undergone a bearer type switch and the L2 processing scheme, or to know which DRBs have undergone bearer type switches, facilitating the deployment of the communication device's DU to perform the accurately corresponding L2 processing for L2 configuration adapted to changes in the communication link of the terminal device.

[0097] In conjunction with the sixth aspect, in one possible implementation, if the first message includes the ID of the first DRB and the second indication information, the processing unit can specifically be used to: make a decision and execute L2 processing.

[0098] In conjunction with the sixth aspect or any of the above possible implementations, in another possible implementation, performing L2 processing includes: MAC reset and RLC re-establishment; or, changing LCID and RLC re-establishment; or, MAC synchronization reconfiguration and RLC re-establishment; or, changing LCID and RLC bearer release and addition.

[0099] In conjunction with the sixth aspect or any of the above possible implementations, in another possible implementation, the first message may also include an MCG instruction to perform L2 processing including: MAC reset and RLC re-establishment; or, changing LCID and RLC re-establishment.

[0100] In conjunction with the sixth aspect or any of the above possible implementations, in another possible implementation, the first message may also include an SCG instruction to perform L2 processing including: MAC synchronization reconfiguration and RLC re-establishment; or, changing the LCID and releasing and adding the RLC bearer.

[0101] In conjunction with the sixth aspect or any of the above possible implementations, in another possible implementation, the first message may further include: the ID of the second DRB, the ID of the second DRB being used to replace the ID of the first DRB; the processing unit is further configured to perform L2 processing on the first DRB and / or the second DRB.

[0102] It should be noted that the communication device provided in the sixth aspect is used to execute the notification method provided in the second aspect. Its specific implementation can be referred to the implementation in the second aspect, and will not be elaborated here.

[0103] In a seventh aspect, this application provides another communication device deployed in a DU applied to a CU-DU architecture. The device may include: a receiving unit, a processing unit, and a transmitting unit. The transmitting unit is configured to receive a third message from the CU, the third message including an LCID indicating an RLC failure and indication information instructing the DU to perform L2 processing; or, the third message includes an LCID indicating an RLC failure. The processing unit is configured to perform L2 processing. The transmitting unit is configured to send a fourth message to the CU, the fourth message including cell group configuration for L2 processing.

[0104] The communication device provided in this application obtains from the CU the LCID of the RLC failure and the instruction information instructing the DU to perform L2 processing; or, the communication device determines that an RLC failure has occurred by obtaining the LCID of the RLC failure from the CU. This allows the communication device to know the LCID of the RLC failure and the L2 processing scheme; or, it allows the communication device to know which LCIDs have caused RLC failures, facilitating the deployment of the DU of the communication device to perform the accurate corresponding L2 processing, thereby adapting to changes in the communication link of the terminal device.

[0105] In conjunction with the seventh aspect, in one possible implementation, if the third message includes an LCID indicating an RLC failure, the processing unit is specifically used to: make a decision and perform L2 processing.

[0106] In conjunction with the seventh aspect or any of the above possible implementations, in another possible implementation, the instruction information instructing the DU to perform L2 processing may include any of the following instructions: whether to retain duplicate PDCPs; whether to delete duplicate PDCPs; whether to delete the LCID; and whether to retain the LCID.

[0107] In conjunction with the seventh aspect or any of the above possible implementations, in another possible implementation, the scheme for performing L2 processing includes at least one of the following schemes: deleting SCells corresponding to LCIDs that have failed in RLC, deleting LCIDs that have failed in RLC, deactivating PDCP duplicates, retaining PDCP duplicates, deleting PDCP duplicates, and re-establishing RLC.

[0108] It should be noted that the communication device provided in the seventh aspect is used to execute the notification method provided in the third aspect. Its specific implementation can be referred to the implementation in the third aspect, and will not be elaborated here.

[0109] Eighthly, this application provides another communication device deployed in a CU-DU architecture, which may include a transmitting unit and a receiving unit. The transmitting unit is used to transmit a third message to the DU, the third message including an LCID indicating an RLC failure and indication information instructing the DU to perform L2 processing; or, the third message includes an LCID indicating an RLC failure. The receiving unit is used to receive the fourth message transmitted by the DU, the fourth message including cell group configuration for L2 processing.

[0110] The communication device provided in this application notifies the DU of the LCID indicating an RLC failure and an instruction to the DU to perform L2 processing; or, the communication device notifies the DU of the LCID indicating an RLC failure. This allows the DU to know the LCID indicating an RLC failure and the L2 processing plan, or to know that an RLC failure has occurred via the LCID, facilitating the DU to perform the accurate corresponding L2 processing for L2 configuration adapted to changes in the terminal device's communication link.

[0111] In conjunction with the eighth aspect, in one possible implementation, the instruction information instructing the DU to perform L2 processing may include any of the following instructions: whether to retain duplicate PDCPs; whether to delete duplicate PDCPs; whether to delete the LCID; and whether to retain the LCID.

[0112] In conjunction with the eighth aspect or any of the above possible implementations, in another possible implementation, performing L2 processing includes at least one of the following schemes: deleting the secondary cell group SCells corresponding to the LCID that has failed in RLC, deleting the LCID that has failed in RLC, deactivating duplicate PDCPs, retaining duplicate PDCPs, deleting duplicate PDCPs, and re-establishing RLC.

[0113] It should be noted that the communication device provided in the eighth aspect is used to execute the notification method provided in the fourth aspect. Its specific implementation can be referred to the implementation in the fourth aspect, and will not be elaborated here.

[0114] Ninthly, embodiments of this application provide a communication device that can implement the functions of the CU in the method examples of the first or second aspect described above. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0115] In conjunction with the ninth aspect, in one possible implementation, the communication device includes a processor and a transceiver, the processor being configured to support the communication device in performing the corresponding functions described in the above methods. The transceiver is used to support communication between the communication device and other devices. The communication device may also include a memory coupled to the processor, which stores necessary program instructions and data for the communication device.

[0116] In a tenth aspect, embodiments of this application provide a CU, including a communication device that implements the functions of the CU in the method examples of the first or second aspect described above.

[0117] Eleventhly, embodiments of this application provide a communication device that can implement the function of DU in the above-described method examples of the first or second aspect. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the above-described functions.

[0118] In conjunction with the eleventh aspect, in one possible implementation, the communication device includes a processor and a transceiver, the processor being configured to support the communication device in performing the corresponding functions described in the above methods. The transceiver is used to support communication between the communication device and other devices. The communication device may also include a memory coupled to the processor, which stores necessary program instructions and data for the communication device.

[0119] In a twelfth aspect, embodiments of this application provide a DU, including a communication device that implements the function of the DU in the method examples of the first or second aspect described above.

[0120] In a thirteenth aspect, embodiments of this application provide a communication system including the CU described in the tenth aspect above and the DU described in the twelfth aspect above.

[0121] In a fourteenth aspect, embodiments of this application provide a communication device that can implement the functions of the CU in the method examples of the third or fourth aspect described above. These functions can be implemented in hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0122] In conjunction with aspect fourteen, in one possible implementation, the communication device includes a processor and a transceiver, the processor being configured to support the communication device in performing the corresponding functions described in the above methods. The transceiver is used to support communication between the communication device and other devices. The communication device may also include a memory coupled to the processor, which stores necessary program instructions and data for the communication device.

[0123] In a fifteenth aspect, embodiments of this application provide a CU, including a communication device that implements the functions of the CU in the method examples of the third or fourth aspect described above.

[0124] In a sixteenth aspect, embodiments of this application provide a communication device that can implement the function of DU in the method examples of the third or fourth aspect described above. This function can be implemented by hardware or by hardware executing corresponding software. The hardware or software includes one or more modules corresponding to the aforementioned functions.

[0125] In conjunction with the sixteenth aspect, in one possible implementation, the communication device includes a processor and a transceiver, the processor being configured to support the communication device in performing the corresponding functions described in the above methods. The transceiver is used to support communication between the communication device and other devices. The communication device may also include a memory coupled to the processor, which stores necessary program instructions and data for the communication device.

[0126] In a seventeenth aspect, embodiments of this application provide a DU, including a communication device that implements the function of the DU in the method examples of the third or fourth aspect described above.

[0127] In an eighteenth aspect, embodiments of this application provide a communication system including the CU described in the fifteenth aspect above and the DU described in the seventeenth aspect above.

[0128] In a nineteenth aspect, embodiments of this application provide a computer storage medium for storing computer software instructions used for the above-described method examples, which includes programs designed to execute the first to fourth aspects described above.

[0129] In a twentieth aspect, embodiments of this application provide a computer program product that, when run on a computer, causes the computer to execute the programs designed in the first to fourth aspects described above.

[0130] The solutions provided in aspects nine through twentieth above are used to implement the notification methods provided in aspects one through four above, and therefore can achieve the same beneficial effects as aspects one through four, which will not be elaborated here. Attached Figure Description

[0131] Figure 1 is a schematic diagram of a CU-DU architecture provided by the prior art;

[0132] Figure 2 is a schematic diagram of the architecture of a dual-connectivity wireless communication system provided by the prior art;

[0133] Figure 3 is a schematic diagram of the various bearer types supported by the MR-DC architecture;

[0134] Figure 4 is a schematic diagram of a CU provided in an embodiment of this application;

[0135] Figure 5 is a schematic diagram of the structure of a DU provided in an embodiment of this application;

[0136] Figure 6 is a flowchart illustrating a notification method provided in an embodiment of this application;

[0137] Figure 7 is a flowchart illustrating another notification method provided in an embodiment of this application;

[0138] Figure 8 is a flowchart illustrating another notification method provided in an embodiment of this application;

[0139] Figure 9 is a flowchart illustrating another notification method provided in an embodiment of this application;

[0140] Figure 10 is a schematic diagram of the structure of a communication device provided in an embodiment of this application;

[0141] Figure 11 is a schematic diagram of another communication device provided in an embodiment of this application;

[0142] Figure 12 is a schematic diagram of another communication device provided in an embodiment of this application;

[0143] Figure 13 is a schematic diagram of another communication device provided in an embodiment of this application;

[0144] Figure 14 is a schematic diagram of the structure of another communication device provided in an embodiment of this application. Detailed Implementation

[0145] The 5G RAN architecture proposes a CU-DU architecture, which separates the protocol layers. The RLC / MAC / PHY layers are handled by the DU, while the CU handles RRC / SDAP / PDCP. Currently, there is no solution for how the CU can notify the DU to perform accurate L2 processing (MAC and RLC layer configuration) when a bearer type switch or RLC failure occurs. Therefore, this application proposes a notification method to ensure accurate L2 processing by the DU in the CU-DU architecture. The basic principle is: the CU decides on the L2 processing plan and instructs the DU to execute the L2 processing according to the CU's decision; or, the CU notifies the DU of the bearer type switch or RLC failure, allowing the DU to decide and execute the L2 processing itself, thus ensuring accurate L2 processing.

[0146] To more clearly describe the implementation process of the solution provided in this application, the application scenario of the solution in this application will be described first.

[0147] In LTE and / or NR radio systems, a UE can connect to two or more base stations simultaneously. Taking connecting to two base stations as an example, the two base stations can use the same radio access technology, such as both being LTE base stations or both being NR base stations; or they can use different radio access technologies, such as one being an LTE base station and the other an NR base station. The base station that the UE initially connects to is called the primary station / MN. Then, the primary station instructs the UE to connect to the secondary station / SN. This method is commonly referred to as dual connectivity (DC). Dual connectivity technology utilizes the radio resources of two base stations to provide services to users, making it easier to meet users' capacity and coverage requirements.

[0148] 3GPP Release 10 introduced LTE-A carrier aggregation technology, enabling the combined use of frequency bands across different systems, frequency bands, and bandwidths to leverage greater bandwidth for improved system performance. In carrier aggregation, multiple carriers are primarily aggregated at the MAC layer, with multiple component carriers sharing MAC resources. The MAC layer needs to support cross-carrier scheduling. Typically, one carrier corresponds to one cell. In dual connectivity mode, if carrier aggregation is performed on the primary site, the cell the UE first accesses on the primary site is called the PCell, and other cells are called SCells. If carrier aggregation is performed on the secondary site, the cell the UE first accesses on the secondary site is called the PSCell, and other cells are similarly called secondary cells.

[0149] If the link latency between base stations is high, the performance of carrier aggregation will be affected. Therefore, dual connectivity technology was proposed. In dual connectivity technology, to avoid latency and synchronization requirements in the MAC layer scheduling process, data is segmented and merged at the PDCP layer, and then the user data stream is simultaneously transmitted to the user through multiple base stations. The two network nodes in dual connectivity have different roles. As the radio-side anchor point of the UE, the master station provides the UE with the only control plane connection to the core network. The secondary station only provides the UE with additional radio resources for the transmission of user data and signaling. In dual connectivity technology, the serving cell group controlled by the MN is called the master cell group (MCG), and the serving cell group controlled by the SN is called the secondary cell group (SCG).

[0150] In dual connectivity, data plane radio bearers can be categorized into three types based on their air interface resource usage: MCG bearers, SCG bearers, and split bearers. Air interface resources specifically refer to RLC / MAC / PHY layer resources. When only MN / MCG side air interface resources are used, it is called an MCG bearer; when only SN / SCG side air interface resources are used, it is called an SCG bearer; and when both MN / MCG and SN / SCG side air interface resources are used, it is called a split bearer.

[0151] The radio bearer is the data transmission channel between the UE and the base station. It is a collective term for a series of entities and configurations allocated by the base station to the UE, and is established when an RRC connection is established. Radio bearers are divided into signaling radio bearers (SRBs) and DRBs based on their content. SRBs carry control plane signaling data and are the actual transmission channel for system signaling messages, while DRBs carry user plane data and are the actual transmission channel for user data.

[0152] A logical channel is a data transmission channel provided by the MAC layer, and the identifier assigned to a logical channel is called an LCID. Generally, one DRB / SRB is associated with one RLC entity and one LCID. When a DRB / SRB performs a Split operation (which can be understood as becoming a Split bearer), one DRB / SRB is associated with two RLC entities and two LCIDs. When a DRB / SRB performs PDCP duplication, one DRB / SRB is associated with two RLC entities and two LCIDs. The only difference between DRB / SRB Split and PDCP duplication operations is whether the PDCP protocol data unit (PDU) is copied. That is, during a Split operation, the PDCP PDU is not copied; PDCP PDUs with different sequence numbers are transmitted through two separate channels, i.e., two RLC entities. During PDCP duplication, the PDCP PDU is copied; PDCP PDUs with the same sequence number are transmitted through two separate channels. In the RRC reconfiguration message, each LCID has a corresponding ServedRadioBearer, which is used to notify the UE of the mapping relationship between the LCID and the DRB / SRB ID.

[0153] When DRB / SRB performs PDCP duplication, one DRB is associated with two RLC entities and two LCIDs, and the standard requires that different LCIDs be scheduled on different serving cells. In the RRC reconfiguration message, the LogicalChannelConfig contains the allowedServingCells field corresponding to the LCID. From this, the UE can obtain the mapping between the LCID and the serving cell.

[0154] Based on the requirements of the 5G system for the access network architecture, the 5G access network logical architecture clearly divides the access network into CU and DU logical nodes, which together form the gNB base station. As shown in Figure 1, the CU is a centralized node that connects to the core network via the NG interface. Within the access network, it can control and coordinate multiple cells, including higher-level protocol stack control and data functions. The DU is a distributed node that implements radio frequency processing functions and baseband processing functions such as RLC, MAC, and PHY. The CU and DU are connected via the F1 interface.

[0155] The notification method provided in this application for bearer type switching is applied to a dual-connectivity wireless communication system architecture as shown in Figure 2. As shown in Figure 2, this wireless communication system architecture includes a base station 201 in a first network, a base station 202 in a second network, and a UE 203. The UE 203 uses the radio resources of base stations 201 and 202 to simultaneously acquire data from both the first and second networks. Base station 201 or base station 202 is configured in a CU-DU architecture as shown in Figure 1. Base station 201 or base station 202 can act as either a MN or a SN.

[0156] For example, in the dual-connectivity wireless communication system architecture shown in Figure 2, the first network can be an LTE network and the second network can be a 5G network, referred to as EN-DC. The first and second networks in the dual-connectivity wireless communication system architecture shown in Figure 2 can be two networks with different wireless access technologies, for example, the first network is an NR network and the second network is an LTE network, referred to as MR-DC; or they can be two networks with the same wireless access technology. The first and second networks in the dual-connectivity wireless communication system architecture shown in Figure 2 can be networks with the same wireless access technology, for example, both are 5G networks, referred to as NR-DC; for example, both are LTE networks, referred to as LTE dual-connectivity. The embodiments of this application do not specifically limit the type of network used in the solution.

[0157] The notification method provided in this application for RLC failure can be applied to the dual-connectivity wireless communication system architecture shown in Figure 2. It can also be applied to wireless communication system architectures performing carrier aggregation; however, this application does not specifically limit its application in this regard.

[0158] The aforementioned wireless access technologies refer to the access methods used in various communication systems. The technical solutions of this application's embodiments may include various wireless access technologies, such as: Global System for Mobile Communication (GSM) access technology, Code Division Multiple Access (CDMA) access technology, Wideband Code Division Multiple Access (WCDMA) access technology, General Packet Radio Service (GPRS) access technology, LTE access technology, LTE Frequency Division Duplex (FDD) access technology, LTE Time Division Duplex (TDD) access technology, Universal Mobile Telecommunication System (UMTS) access technology, Worldwide Interoperability for Microwave Access (WiMAX) communication access technology, 5th Generation (5G) systems, or NR access technologies, etc. This application does not specifically limit the type of wireless access technology used in the solution.

[0159] The UE described in this application refers to part or all of the mobile communication device used by the user. For example, the UE can be a mobile phone, tablet computer, laptop computer, ultra-mobile personal computer (UMPC), netbook, personal digital assistant (PDA), e-book reader, mobile TV, wearable device, personal computer (PC), etc. Terminal devices may have different names in different communication systems. This application does not specifically limit the type of terminal device.

[0160] It should be noted that Figure 2 is merely an illustration of a dual-connectivity wireless communication system architecture. The types and number of devices included in this wireless communication system architecture can be configured according to actual needs, and Figure 2 is not a specific limitation on this content.

[0161] TS37.340V15.2.0 in the 3GPP RAN 2 discussion defines several bearer types supported under MR-DC. Figure 3 illustrates the various bearer types supported by the MR-DC architecture. As shown in Figure 3, the various bearer types supported under MR-DC can include:

[0162] The MCG bearer terminated in MN;

[0163] The SCG bearer terminated in MN;

[0164] The split bearer terminated in MN;

[0165] The MCG bearer terminated in SN;

[0166] The SCG bearer terminated on the SN (SN terminated SCG bearer);

[0167] The split bearer terminated in SN.

[0168] Among them, MCG bearer refers to a bearer that only involves air interface resources on the MCG side, and air interface resources mainly refer to resources including RLC / MAC / PHY layers. SCG bearer refers to a bearer that only involves air interface resources on the SCG side, and the data plane radio bearer is only served by the SN. Split bearer refers to a bearer that involves both air interface resources on the MCG and SCG sides, and the data plane radio bearer is served by both the MN and SN. MN / SN termination refers to the PDCP entity being terminated at the MN or SN. Depending on the actual network conditions (which may be service conditions, link conditions, or radio resource conditions), switching between multiple bearer types is possible; this network operation is called bearer type switching.

[0169] For example, a DRB might initially only use MCG air interface resources. Later, the CU might find that the SN signal is strong and decide to switch the MCG bearer to a Split bearer. Alternatively, if the CU finds that the SN load is low, it might decide to switch the MCG bearer to an SCG bearer. Of course, in practical applications, there are many scenarios where bearer type switching occurs, which will not be listed here.

[0170] Before describing the specific implementation of the notification method provided in this application, the names involved in the embodiments of this application are explained as follows.

[0171] Bearer type change is a network operation that switches bearers according to business needs in a network that supports multiple bearer types.

[0172] RLC failure occurs when all serving cells associated with an RLC do not include PCells / PSCells, but only SCells, and the maximum number of RLC retransmissions is reached. The main causes of RLC failure may include poor signal strength of the RLC entity or the SCell associated with the LCID, or improper configuration. When a UE detects an RLC failure, it needs to notify the base station, for example, by informing the base station via an RRC message which LCIDs have experienced RLC failure. Specifically, in dual-connectivity mode, the UE also needs to indicate whether the LCIDs belonging to the MCG or SCG have experienced RLC failure. For example, the RRC message reported by the UE includes a list of LCIDs that have experienced RLC failure, containing the LCIDs themselves. Optionally, each LCID also carries an MCG / SCG indication. In the CU-DU architecture, since the CU is responsible for the RRC module, only the CU is aware of RLC failures.

[0173] The terms "first" and "second," etc., used in the specification and claims of this application are used to distinguish different objects, not to describe a specific order of objects. For example, "first instruction information" and "second instruction information," etc., are used to distinguish different instruction information, not to describe a specific order of information.

[0174] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a specific manner to facilitate understanding.

[0175] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0176] On one hand, this application provides a CU. Figure 4 shows a CU 40 related to various embodiments of this application. The CU 40 can be the CU in a base station using a CU-DU architecture in the dual-connectivity wireless communication system architecture shown in Figure 1. As shown in Figure 4, the CU 40 may include: a processor 401, a memory 402, and a transceiver 403.

[0177] The following section, with reference to Figure 4, provides a detailed description of each component of CU 40:

[0178] The memory 402 may be volatile memory, such as random-access memory (RAM); or non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); or a combination of the above types of memory, used to store program code that can implement the method of this application and configuration files.

[0179] The processor 401 is the control center of the CU 40. It can be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs). The processor 401 can perform various functions of the CU 40 by running or executing software programs and / or modules stored in the memory 402, and by calling data stored in the memory 402.

[0180] Transceiver 403 is used by CU 40 to interact with other units. For example, transceiver 403 can be a transceiver antenna or a communication port of CU 40.

[0181] In one possible implementation, processor 401 performs the following functions by running or executing software programs and / or modules stored in memory 402, and by calling data stored in memory 402:

[0182] The transceiver 403 sends a first message to the DU, the first message including the ID of the first DRB where a bearer type switch has occurred and a first indication information instructing the DU to perform L2 processing; or, the first message includes the ID of the first DRB and a second indication information instructing the DU to perform L2 processing; the transceiver 403 receives a second message sent by the DU, the second message including the cell group configuration for L2 processing.

[0183] In one possible implementation, processor 401 performs the following functions by running or executing software programs and / or modules stored in memory 402, and by calling data stored in memory 402:

[0184] The transceiver 403 sends a third message to the DU, the third message including the LCID of the RLC failure and the instruction information instructing the DU to perform L2 processing; or, the third message includes the LCID of the RLC failure; the transceiver receives a fourth message sent by the DU, the fourth message including the cell group configuration for L2 processing.

[0185] On the other hand, embodiments of this application provide a DU. Figure 5 shows a DU 50 related to various embodiments of this application. DU 50 can be a DU in a base station configured with a CU-DU architecture in the dual-connectivity wireless communication system architecture shown in Figure 1. As shown in Figure 5, DU 50 may include: a processor 501, a memory 502, and a transceiver 503.

[0186] The following section, with reference to Figure 5, provides a detailed description of each component of the DU 50:

[0187] The memory 502 may be volatile memory, such as RAM; or non-volatile memory, such as ROM, flash memory, HDD or SSD; or a combination of the above types of memory, used to store program code that can implement the method of this application, and configuration files.

[0188] The processor 501 is the control center of the DU 50. It can be a CPU, an ASIC, or one or more integrated circuits configured to implement the embodiments of this application, such as one or more DSPs, or one or more FPGAs. The processor 501 can perform various functions of the DU 50 by running or executing software programs and / or modules stored in the memory 502, and by calling data stored in the memory 502.

[0189] Transceiver 503 is used for DU 50 to interact with other units. For example, transceiver 503 can be a transceiver antenna or a communication port of DU 50.

[0190] In one possible implementation, processor 501 performs the following functions by running or executing software programs and / or modules stored in memory 502, and by calling data stored in memory 502:

[0191] The transceiver 503 receives a first message from the CU, the first message including the ID of the first DRB where a bearer type switch has occurred and a first indication information indicating the DU to perform L2 processing; or, the first message includes the ID of the first DRB and a second indication information indicating that a bearer type switch has occurred; performs L2 processing; and sends a second message to the CU via the transceiver 503, the second message including the cell group configuration for L2 processing.

[0192] In another possible implementation, processor 501 performs the following functions by running or executing software programs and / or modules stored in memory 502, and by calling data stored in memory 502:

[0193] The transceiver 503 receives a third message from the CU, the third message including the LCID of the RLC failure and an instruction to the DU to perform L2 processing; or, the third message includes the LCID of the RLC failure; performs L2 processing; and sends a fourth message to the CU via the transceiver 503, the fourth message including the cell group configuration of the L2 processing.

[0194] Furthermore, embodiments of this application provide a notification method applied to the communication process between the CU and DU during a bearer type switch in a CU-DU architecture. The operation performed by the CU / DU described in this application can be understood as being performed by the CU / DU itself, or by a functional unit or chip within the CU / DU. This application does not specifically limit this interpretation; the following description only refers to the CU / DU performing an operation. The functional unit or chip within the CU / DU that executes the notification method provided in this application can be referred to as the communication device in this application.

[0195] As shown in Figure 6, the notification method provided in this application embodiment may include:

[0196] S601, the CU sends a first message to the DU. The first message includes the ID of the first DRB where a bearer type switch has occurred and a first indication information instructing the DU to perform L2 processing. Alternatively, the first message includes the ID of the first DRB and a second indication information instructing the DU to perform a bearer type switch.

[0197] It should be noted that there can be at least one first DRB where a bearer type switch occurs, and this application embodiment does not specifically limit the number of DRBs where a bearer type switch occurs. The process of this application scheme is the same for each DRB where a bearer type switch occurs.

[0198] S601 is executed when the CU determines that a bearer type switch has occurred.

[0199] Optionally, when the CU-DU architecture is applied to the SN in a dual-connectivity network, the CU receives an indication from the MN, which may include the latest network configuration information. Based on this indication, the CU determines that a bearer type change has occurred. For example, by comparing the changes in the EN-DC resource configuration field received before and after, the CU learns that a bearer type change has occurred, and which specific DRBs have undergone the bearer type change. The DRB that has undergone a bearer type change can be at least one DRB. For instance, the first time the CU receives the EN-DC resource configuration indicating that the PDCP entity of the DRB is on the MN, occupying only the MCG-side air interface resources. The second time the CU receives the EN-DC resource configuration indicating that the PDCP entity of the DRB is on the MN, occupying both the MCG-side and SCG-side air interface resources, the CU learns that the DRB has switched from an MCG bearer to a split bearer, but the security key has not changed.

[0200] Optionally, when the CU-DU architecture is applied to the MN in a dual-connectivity network, the CU automatically determines which DRBs undergo bearer type switching based on changes in the terminal device's communication link. At least one DRB can undergo bearer type change. For example, a DRB might initially only use MCG air interface resources; later, if the CU finds the SN signal is strong, it might decide to switch the MCG bearer to a split bearer. Or, if the CU finds the SN load is low, it might decide to switch the MCG bearer to an SCG bearer. This is merely an illustrative example and does not constitute a specific limitation on the scheme where the CU automatically decides to switch bearer types based on changes in the terminal device's communication link.

[0201] It should be noted that the notification method provided in this application embodiment is applied after the CU determines that a bearer type switch has occurred. The process by which the CU determines that a bearer type switch has occurred is not limited and will not be described in detail here.

[0202] Specifically, the content of the first message in S601 includes the following two cases:

[0203] The first situation and the first message include the ID of the first DRB where a bearer type switch occurs and the first instruction information instructing the DU to perform L2 processing.

[0204] In the first case, the CU determines the specific L2 processing operation to be performed by the DU when a bearer type switch occurs, and instructs the DU to perform the specific L2 processing operation through the first indication information.

[0205] In the first case, as shown in FIG7, before S601, the notification method provided in the embodiments of this application may further include S601a.

[0206] S601a and CU determine the L2 processing scheme for DU.

[0207] Optionally, the CU can determine the specific L2 processing operation to be performed by the DU when a bearer type switch occurs from the set of L2 processing schemes. The set of L2 processing schemes can be at least two predefined L2 processing schemes. It should be noted that the specific content of the L2 processing scheme set can be configured according to actual needs, and this embodiment does not impose specific limitations on it.

[0208] It should be noted that when executing the notification method provided in this application, if there is S601a, then the first case is executed in S601, and the second case is not involved.

[0209] Optionally, in one possible implementation, performing L2 processing may include: MAC reset and RLC re-establishment; or, changing the LCID and RLC re-establishment; or, MAC reset by reconfiguration with sync and RLC re-establishment; or, changing the LCID and RLC bearer release and add. Of course, performing L2 processing may include other specific L2 processing operations; this is merely an example description and not a specific limitation on the content.

[0210] It should be noted that the phrase "performing L2 processing" in this article can be understood as: the specific operations involved in performing L2 processing, which will not be explained in detail below.

[0211] Optionally, in one possible implementation, the first message may also include an MCG indication, which indicates that the base station in the CU-DU architecture is in the MN role in dual connectivity; or, when the DU learns by other means that it is currently in the MN role (i.e., the first message does not contain an explicit MCG indication), performing L2 processing may include: MAC reset and RLC re-establishment; or, changing the LCID and RLC re-establishment.

[0212] The MCG indicator can be the MCG string itself, or other pre-configured characters or bits. For example, the MCG / SCG indicator may contain the enumerated value MCG, or MCG / SCG indicator = 1 indicates MCG. This application does not impose specific limitations on this. MCG / SCG indicator = 1 means that the "MCG / SCG indicator" bit is set to 1.

[0213] Optionally, in one possible implementation, the first message may also include an SCG indication, which is used to indicate that the base station of the CU-DU architecture is in the SN role in the dual-connectivity architecture; or, when the DU learns by other means that it is currently in the SN role (i.e., the first message does not contain an explicit SCG indication), performing L2 processing may include: MAC synchronization reconfiguration and RLC re-establishment; or, changing the LCID and releasing and adding RLC bearers.

[0214] The SCG indicator can be the SCG string itself, or other pre-configured characters or bits. For example, the MCG / SCG indicator may contain the enumerated value SCG, or MCG / SCG indicator = 0 indicates SCG. This application does not impose specific limitations on this. MCG / SCG indicator = 0 means that the "MCG / SCG indicator" bit is set to 0.

[0215] In one possible implementation, the set of L2 processing schemes can be Table A-1 defined in 3GPP TS 37.340 v15.2.0 or R2-1810953, named L2 handling for bearer type change with and without security key change, and the content of L2 processing for DU is shown in Table 1.

[0216] Table 1

[0217]

[0218]

[0219] Here, "with key change" refers to a security key update. For example, when the node hosting the PDCP entity changes, or when the PDCP entity itself changes (e.g., switching from MN to SN) or vice versa, a security key update is required. Taking a switch from one MCG bearer to another, accompanied by a security key update, as an example, one possibility is that the PDCP carried by the MCG initially resided in MN and occupied MCG-side air interface resources. Later, this PDCP carried by the MCG switched to SN, but still occupied MCG-side air interface resources. Another possibility is that the PDCP carried by the MCG initially resided in SN and occupied MCG-side air interface resources. Later, this PDCP carried by the MCG switched to MN, but still occupied MCG-side air interface resources.

[0220] Table 1 provides the corresponding L2 processing schemes when switching from a bearer type in a row to a bearer type in a column, accompanied by a security key update. For example, when switching from a Split bearer to an SCG bearer, referring to the third row and fourth column of Table 1, the L2 processing scheme for this bearer type switch is as follows: the PDCP layer performs a Re-establish, the MCG RLC layer performs a Re-establish and release, the MCG MAC layer performs a reconfigure, the SCG RLC layer performs L2 processing as per Note 2, and the SCG MAC layer performs L2 processing as per Note 2.

[0221] The first instruction information is used to indicate the specific scheme for L2 processing executed by the DU in the CU decision. The type and content of this instruction information can be configured according to actual needs, and this application does not impose specific limitations on it. For example, the first instruction information can be the name information of the L2 processing, that is, the name of each L2 processing scheme can be defined, and the scheme name can be used as the first instruction information; or, the first instruction information can be the content information of the L2 processing, that is, the content of the L2 processing scheme can also be used as the first instruction information; or, the first instruction information can be the identification information of the L2 processing, and the identification of each L2 processing scheme can be configured, and the identification can be used as the first instruction information. Of course, any information that can be used to indicate the specific scheme of L2 processing can be used as the first instruction information.

[0222] For example, taking the content shown in Table 1 as an example, assuming that DU belongs to SCG, its L2 processing can include "MAC reset by reconfiguration with sync + RLC re-establishment" or "change of LCID + RLC bearer release and add". The first instruction information can be implemented in the following ways:

[0223] First implementation: The content of the proposed solution is used as the first guiding information.

[0224] The first instruction is to use "MAC reset by reconfiguration with sync+RLC re-establishment" or "change of LCID+RLC bearer release and add" as the instruction information, that is, to use the specific content of the scheme as the instruction information.

[0225] It should be noted that when using the content of the plan as the first instruction information, it can be the complete content of the plan, a part of the plan, or a simplified version of the plan. Any content information that can clearly indicate the plan can be used as the first instruction information.

[0226] Second implementation: Use the scheme name as the first instruction information.

[0227] Define "MAC reset by reconfiguration with sync+RLC re-establishment" as Scheme A, and define "change of LCID+RLC bearer release and add" as Scheme B. Use either "Scheme A" or "Scheme B" as the first instruction.

[0228] The third implementation: using the scheme identifier as the first indication information.

[0229] The first instruction information is represented by 1 bit. 0 indicates "MAC reset by reconfiguration with sync+RLC re-establishment" and 1 indicates "change of LCID+RLC bearer release and add". 0 / 1 is used as the first instruction information.

[0230] Fourthly, for schemes that can use implicit indication, the implicit representation content is used as the first indication information.

[0231] For example, in the case of "change of LCID+RLC bearer release and add", the CU releases and adds the DRB through the DRB to be released list field and DRB to be added list field in the UE context modification request message. This is equivalent to notifying the DU to release and add the RLC, thus achieving the purpose of notification.

[0232] The second scenario, the first message includes the ID of the first DRB and a second indication message indicating that a bearer type switch has occurred.

[0233] The second indication information is used to notify the DU that a bearer type change has occurred. The form and content of this second indication information can be configured according to actual needs, and this application does not impose specific limitations on it. For example, the second indication information can be the name of the bearer type change network operation, such as "bearer type change," "key change," or "bearer type change with key change." Alternatively, the second indication information can be the representation information of the bearer type change network operation, that is, defining a network identifier for this type of operation in the network to uniquely indicate that a bearer type change has occurred, and using this network identifier as the first indication information, etc. Any information that can be used to indicate that a bearer type change network operation has occurred can be used as the second indication information.

[0234] In the second scenario, the CU indicates to the DU that at least one DRB has undergone a bearer type switch. The DU then performs the specific L2 processing operation, which is determined and executed independently upon receiving the first message. Specifically, the DU can decide from the set of L2 processing schemes to determine the specific L2 processing operation to be performed when a bearer type switch occurs, and then execute the corresponding L2 processing.

[0235] It should be noted that the specific operations of L2 processing after DU receives the first message in the second case, as well as the content of L2 processing in the second case, are the same as those described in the first case. Only the executing entity of the decision is different. The details have been explained in detail in the first case above, and will not be repeated here.

[0236] Optionally, when switching bearer types, the ID of the DRB where the bearer type switch occurs may or may not be changed; this embodiment does not specifically limit this. When the ID of the DRB where the bearer type switch occurs is changed during the bearer type switch, the first message may further include: the ID of the second DRB, which is used to replace the ID of the first DRB to instruct the DU to perform the corresponding L2 processing for the first DRB and / or the second DRB.

[0237] The first message is the CU-DU interface message. Currently, in NR networks, the CU-DU interface message is defined as an F1 message. Of course, the CU-DU interface message can also have other names, and different names can be defined for the interface message when the network standard of the CU-DU architecture is different. This application does not impose specific limitations. For example, in LTE networks, the interface between CU-DUs in a CU-DU architecture base station can be defined as the W1 interface, and the message transmitted on the W1 interface is called a W1 message. For example, the first message can be a W1 message.

[0238] Optionally, the first message can be an existing CU-DU interface message, or it can be a newly defined message specifically used to notify the DU to perform L2 processing when the bearer type changes. This embodiment of the application does not specifically limit this. For example, the first message can be a UE context modification request message, or a new first message can be defined. For example, the newly defined first message can be a bearer type change notification message. Optionally, the first message includes the ID of the first DRB and the first indication information, or the ID of the first DRB and the second indication information, which can be directly included in the first message as fields within the first message.

[0239] Optionally, the ID of the first DRB and the first indication information, or the ID of the first DRB and the second indication information, included in the first message may be contained in the first field of the first message. The first field can be any field in the first message.

[0240] Optionally, when the first message is an existing message, the first field can be an existing field in the existing message or a newly defined field. This application embodiment does not specifically limit this.

[0241] For example, when the first message is a UE context modification request message, the first field in the UE context modification request message includes the ID of the first DRB and first indication information; or, the first field in the UE context modification request message includes the ID of the first DRB and second indication information. This first field can be an existing field in the UE context modification request message or a newly defined field; this application embodiment does not specifically limit it.

[0242] For example, when the first message is a UE context modification request message, the first field may include the DRB to be modified List field of the first DRB.

[0243] For example, when the first message is a UE context modification request message, the first field is the DRB to Be Modified List field of the first DRB, and the content of this field can be:

[0244] DRB to be modified list

[0245] DRB to be modified item IEs

[0246] >>First DRB ID

[0247] >>First instruction message (e.g., MAC reset / MAC reset reconfiguration with sync / RLC reestablish / change of LCID / RLC release and add) or second instruction message (e.g., bearer type change / key change / bearer type change with key change).

[0248] Further optionally, if the first DRB is associated with more than one RLC entity (or LCID), the first message may also include the LCID in the first DRB where the bearer type switch has occurred, so that the DU can perform L2 processing on the RLC entity or logical channel corresponding to the LCID.

[0249] S602, DU receives the first message from CU.

[0250] The first message may include the ID of the first DRB where a bearer type switch has occurred and a first indication information indicating the DU to perform L2 processing; or the first message may include the ID of the first DRB and a second indication information indicating that a bearer type switch has occurred.

[0251] It should be noted that the first message received by DU from CU in S602 is the same as the first message sent by CU in S601. The first message has already been described in detail in S601, so it will not be repeated here.

[0252] S603 and DU perform L2 processing.

[0253] Specifically, the processing methods in S603 differ depending on the two scenarios of the first message in S601.

[0254] Optionally, corresponding to the first case in S601, in S603, the DU performs L2 processing according to the instruction of the first instruction information. Corresponding to the second case in S601, in S603, the DU makes a decision and performs L2 processing.

[0255] Here, DU decision refers to DU determining the specific operation to perform L2 processing based on the network state. The possible schemes for its specific operation have been described in detail in the first case of S601, and will not be repeated here.

[0256] For example, based on the content of Table 1, when the CU-DU architecture is applied to the SN, the DU receives the first message and knows that one of the following four situations has occurred: 1) Split->Split with key change; 2) Split->SCG with key change; 3) SCG->Split with key change; 4) SCG->SCG with key change. Then, the DU executes one of the following L2 processes according to the instruction of the first instruction information, or executes one of the following L2 processes according to the decision of the second instruction information: 1) MAC reset reconfiguration with sync+RLC re-establishment; 2) change of LCID+RLC bearer release and add.

[0257] The phrase "Split->Split with key change" indicates a switch from a split bearer to a split bearer accompanied by a security key update. For example, changing the PDCP anchor point from MN to SN, or vice versa. A change in the PDCP anchor point leads to a security key update.

[0258] For example, based on the content of Table 1, when the CU-DU architecture is applied to the MN, the DU receives the first message and knows that one of the following situations has occurred: 1) MCG->MCG with key change; 2) MCG->Split with key change; 3) Split->MCG with key change; 4) Split->Split with key change. Then, the DU executes one of the following L2 processes according to the instruction of the first instruction information, or decides to execute one of the following L2 processes according to the second instruction information: 1) MAC reset + RLC re-establishment; 2) change of LCID + RLC re-establishment.

[0259] It should be noted that this application will not elaborate on the process of DU performing L2 processing, i.e. configuring the RLC and MAC layers, but can refer to existing mechanisms.

[0260] For example, the specific actions for RLC re-establishment by a DU can be found in 3GPP TS 36.322v15.1.0 or TS38.322v15.2.0, with different actions depending on the mode. For instance, during RLC re-establishment, for RLC entities in transparent mode (TM), all RLC service data units (SDUs) will be deleted. For RLC release+add scenarios, a new LCID also needs to be configured.

[0261] Optionally, when the first message also includes the ID of the second DRB, the DU also needs to perform L2 processing on the first DRB and / or the second DRB.

[0262] The DU performing L2 processing on the first DRB and / or the second DRB refers to a series of operations within the L2 processing performed by the DU. The operation target can be one or both of the first and second DRBs. For example, if the L2 processing performed by the DU is the release and addition of an RLC bearer, then a release operation is performed on the first DRB, and an addition operation is performed on the second DRB. The DU performing L2 processing on the first DRB and / or the second DRB means that when performing L2 processing, the DU associates all configurations related to the first DRB with the second DRB. When performing a change of LCID, the DU associates the changed LCID with the second DRB identifier. Furthermore, the DU also associates the F1 interface user plane tunnel associated with the first DRB identifier with the second DRB identifier.

[0263] S604, DU sends a second message to CU, the second message including the cell group configuration for L2 processing.

[0264] Specifically, when the DU performs L2 processing, it needs to configure the RLC and MAC layers. The specific content of this configuration includes the cell group configuration (CellGroupConfig) for L2 processing. This cell group configuration information needs to be sent to the UE via the CU so that the UE can perform the same configuration. For example, the DU sends the CellGroupConfig to the CU via a UE context modification response message or by initiating a UE context modification required message.

[0265] It should be noted that the DU can first generate a cell group configuration including L2 processing and then perform L2 processing, or perform L2 processing first and then generate a cell group configuration including L2 processing, or perform both simultaneously. This application embodiment does not specifically limit this.

[0266] For example, CellGroupConfig can contain RLC-config, RLC-bearer config, MAC-cellgroupconfig, LCID, etc. RLC-config contains the re-establishRlc field, while RLC-bearerConfig contains LCID replacement indication information.

[0267] The LCID replacement indication information can be implemented implicitly. For example, originally LCID = 1, the corresponding DRB ID = 1. Now LCID = 5 (used to replace LCID = 1), the corresponding DRB ID = 1. The UE can know that the LCID has changed by comparing the changes before and after. The LCID replacement indication information can also be implemented by adding a new IE, for example, by including a new LCID field in the RLC-bearerconfig. This application embodiment does not specifically limit this.

[0268] For example, if the DU performs L2 processing as MAC reset by reconfiguration with sync + RLC re-establishment, CellGroupConfig can also include reconfiguration with sync, such as the Reconfiguration with sync field. When performing change of LCID, the DU will generate a new LCID and bind it to the first DRB ID. The binding relationship between the LCID and the DRB is reflected in the served radio bearer field in the RLC-bearer configuration. When performing change of LCID, and the CU indicates the ID of the second DRB, the DU will generate an LCID and associate the new LCID with the ID of the second DRB. When performing RLC re-establishment, the cell group configuration information generated by the DU may include the re-establishRlc field. When performing RLC release and addition, the cell group configuration information generated by the DU may include the RLC-bearer to release list and the RLC-bearer to add mod list. Therefore, the DU sends a second message to the CU to send the cell group configuration to the UE through the CU.

[0269] Optionally, if the first message is a request message in a request-response mechanism, then the second message can be a response message to the first message; if the first message is not a message in a request-response mechanism, then the second message is a separate message. This application does not specifically limit the type of the second message.

[0270] For example, the second message can be a response message to the UE context modification request message, referred to as the UE context modification response message.

[0271] S605, CU receives the second message sent by DU.

[0272] The second message includes the cell group configuration for L2 processing.

[0273] It should be noted that the second message received by the CU from the DU in S605 is the same as the second message sent by the DU in S604. The second message has already been described in detail in S604, so it will not be repeated here.

[0274] Furthermore, as shown in FIG7, after S605, the notification method provided in this application embodiment may also include S606.

[0275] S606 and CU send an RRC reconfiguration message to the UE. The RRC reconfiguration message includes the cell group configuration.

[0276] Specifically, after receiving the second message in S605, the CU adds the relevant configurations of its own L2 processing (such as PDCP layer configuration) and the cell group configuration in the second message to the RRC reconfiguration message and sends them to the UE so that the UE can perform the same configuration. The specific process will not be described in detail.

[0277] The notification method provided in this application allows the CU to notify the DU of the ID of the first DRB where a bearer type switch has occurred and a first indication of the DU's L2 processing plan; alternatively, the CU may notify the DU of the ID of the first DRB and notify the DU of the bearer type switch via a second indication. This enables the DU to know which DRBs have undergone bearer type switching and the L2 processing plan, or to know which DRBs have undergone bearer type switching, facilitating the DU to perform the accurate corresponding L2 processing for L2 configuration adapted to changes in the terminal device's communication link.

[0278] It should be noted that the above implementation is a control plane-based notification from the CU to the DU, that is, a notification from the CU to the DU is achieved through control plane messages via the F1 interface. In another possible implementation, the notification method provided in this application can be implemented through the user plane, that is, the notification is achieved by sending data packets carrying information through the user plane tunnel of the F1 interface.

[0279] Specifically, the user plane tunnel between the CU and DU is at the DRB or LCID granularity. For example, when the CU and DU perform PDCP repetition based on carrier aggregation, two user plane tunnels will be established between the CU and DU for one DRB. For example, the CU includes the DRB ID and the corresponding CU-side transport layer information in the UE context setup / modification request message. The transport layer information may include the TEID (identification identifier assigned to the tunnel) and / or the transport layer address. The DU includes the DRB ID and the corresponding DU-side transport layer information in the response message. The CU-side TEID and the DU-side TEID can uniquely identify a user plane tunnel, that is, uniquely identify a DRB / LCID. In this implementation, the first message includes the TEID corresponding to the first DRB ID and the first indication information, or the first message includes the TEID corresponding to the first DRB ID and the second indication information. The specific implementation can be referred to the specific implementation of the control plane mentioned above, and will not be repeated here. In this case, the first message may be included in the downlink PDU. For example, the control field of the downlink PDU includes the interface TEID corresponding to the first DRB ID and first indication information, or the TEID corresponding to the first DRB ID and second indication information. Optionally, the CU-side transport layer address and the DU-side transport layer address can uniquely identify a user plane tunnel, that is, uniquely identify a DRB / LCID. Then the first message may include the interface transport layer address corresponding to the DRB ID.

[0280] The PDCP duplication mechanism involves copying the PDCP PDU twice and then transmitting it through two RLC entities. PDCP duplication can be applied to both SRB and DRB.

[0281] When the CU sends downlink data packets to the DU, it includes a TEID in the packet header. When the packet header includes the first indication information, the binding relationship between the tunnel endpoint address TEID and the DRB / LCID determines which DRB / LCID requires which L2 processing. When the packet header includes the second indication information, the binding relationship between the tunnel endpoint address and the DRB / LCID determines which DRB / LCID is undergoing bearer type switching.

[0282] Furthermore, embodiments of this application provide a notification method applied to the communication process between the CU and DU when an RLC failure occurs in a CU-DU architecture. An operation performed by the CU / DU described in this application can be understood as being performed by the CU / DU itself, or by a functional unit or chip within the CU / DU. Embodiments of this application do not specifically limit this; the following description only refers to the CU / DU performing an operation. The functional unit or chip within the CU / DU that executes the notification method provided in this application can be referred to as the communication device in this application.

[0283] As shown in Figure 8, the notification method provided in this application embodiment may include:

[0284] S801, CU sends a third message to DU, the third message including the LCID of the RLC failure and the instruction information instructing DU to perform L2 processing; or, the third message includes the LCID of the RLC failure.

[0285] It should be noted that there can be at least one LCID that experiences RLC failure, and this application embodiment does not specifically limit the number of LCIDs that experience RLC failure. The process of this application scheme is the same for each LCID that experiences RLC failure.

[0286] S801 is executed when the CU determines that an RLC failure has occurred. The CU can determine the RLC failure based on information reported by the UE. For example, the CU can determine which LCIDs have failed RLC based on the LCIDs contained in the RRC message reported by the UE. The base station or CU can also determine whether the RLC failure occurred in the MCG or SCG based on the MCG / SCG indication reported by the UE. When the base station in the CU-DU architecture acts as the MN, the CU can also inform the secondary SN which LCIDs have failed RLC through inter-base station interfaces such as the Xn / X2 interface. For example, the Xn / X2 interface message may contain a list of LCIDs that have failed RLC.

[0287] It should be noted that the notification method provided in this application embodiment is applied after the CU determines that an RLC failure has occurred. The process by which the CU determines that an RLC failure has occurred is not limited and will not be described in detail here.

[0288] Specifically, the content of the third message in S801 includes the following two situations:

[0289] Case 1: The third message includes the LCID indicating an RLC failure and an instruction to the DU to perform L2 processing.

[0290] In Case 1, when the CU determines that an RLC failure has occurred, the DU performs the specific L2 processing operation and instructs the DU to perform the specific L2 processing operation through the instruction information.

[0291] In case 1, as shown in FIG9, before S801, the notification method provided in this application embodiment may further include S801a.

[0292] S801a and CU determine the L2 processing scheme for DU.

[0293] Optionally, the CU can determine the specific L2 processing operation to be performed by the DU when an RLC failure occurs, based on the set of L2 processing schemes. The set of L2 processing schemes can be at least two predefined L2 processing schemes. It should be noted that the specific content of the L2 processing scheme set can be configured according to actual needs, and this embodiment does not impose specific limitations on it.

[0294] It should be noted that when executing the notification method provided in this application, if there is S801a, then S801 executes case 1 and does not involve case 2.

[0295] Optionally, in one possible implementation, when an RLC failure occurs, performing L2 processing may include at least one of the following schemes: deleting the SCells corresponding to the LCID that failed in the RLC, deleting the LCID that failed in the RLC, deactivating PDCP duplication, retaining PDCP duplication, deleting PDCP duplication, and re-establishing the RLC. Of course, performing L2 processing when an RLC failure occurs may include other specific operations of L2 processing; this is merely an example description and not a specific limitation on this content. Specifically, deactivating PDCP duplication means that the resource mapping relationship of the schema is retained but not enabled, i.e., the PDCP PDU replication operation is not performed; retaining PDCP duplication means maintaining the resource mapping relationship of the schema, i.e., continuing to perform the PDCP PDU replication operation; deleting PDCP duplication means deleting the resource mapping relationship of the schema, for example, deleting an RLC entity and an LCID associated with a DRB / SRB, retaining only one RLC entity and one LCID.

[0296] When a DRB / SRB performs PDCP duplication, one DRB is associated with two RLC entities and two LCIDs, and the standard requires that different LCIDs be scheduled on different serving cells. In the RRC reconfiguration message, the logical channel configuration field contains the allowedservingcells field corresponding to the LCID. Thus, the UE can obtain the correspondence between the LCID and the serving cell. When all serving cells associated with an LCID are SCells, and the RLC retransmission count exceeds the maximum, the LCID has experienced RLC failure. For a DRB, deactivating PDCP duplication can be done by notifying the UE via the MAC control field whether to activate or deactivate PDCP duplication. In this case, one DRB still corresponds to two RLC entities and two LCIDs. Retaining PDCP duplication means retaining the two RLC entities and two LCIDs associated with one DRB. Deleting PDCP duplication means that one DRB changes from corresponding to two RLC entities and two LCIDs to corresponding to only one RLC entity and one LCID. For an SRB, deactivating PDCP duplication can be done by the CU informing the DU that PDCP PDU duplication is no longer necessary. For example, the CU can notify the DU that it does not need to copy the PDCP PDU by setting the execute duplication field contained in the F1 interface message downlink RRC message transfer to false.

[0297] For example, when L2 processing involves deleting PDCP duplication, it is also necessary to delete the LCID that caused RLC failure. Optionally, for cases where DRB performs PDCP duplication, CU can decide whether to delete one of the F1-U tunnels associated with the DRB corresponding to the LCID. For example, CU can first obtain the mapping relationship between DRB ID and LCID through the CellGroupConfig previously fed back by DU. Then, CU finds the corresponding DRB ID based on the LCID that caused RLC failure reported by UE and the mapping relationship between DRB ID and LCID. CU can modify the UE context request, in which the DRB contains only one transport layer information, namely a TEID and / or a transport layer address. Upon receiving this message, DU can know that CU has decided to delete one of the F1-U tunnels associated with the DRB, i.e., delete PDCP duplication. Accordingly, DU generates a new CellGroupConfig, in which the DRB is associated with only one LCID, i.e., the LCID associated with the DRB that caused RLC failure has been deleted. For cases where SRB performs PDCP duplication, CU can notify DU to delete one of the RLC entities and LCIDs corresponding to the SRB. For example, the CU instructs the DU to delete an RLC entity associated with the corresponding SRB by setting the duplication indication in the SRB to be modified list field of the UE context modification request message to false. Accordingly, the DU will also delete the LCID associated with that RLC entity and generate a new CellGroupConfig. The SRB is associated with only one LCID; that is, the LCID associated with the SRB that experienced RLC failure has been deleted.

[0298] The instruction information, which instructs the DU to perform L2 processing, is used to instruct the CU on the specific operation of L2 processing performed by the DU. The type and content of this instruction information can be configured according to actual needs, and this application does not impose specific limitations on it. For example, the first instruction information can be the name information of the L2 processing, that is, the name of each L2 processing scheme can be defined and used as the instruction information; or, the instruction information can be the content information of the L2 processing, that is, the content of the L2 processing scheme can also be used as the instruction information; or, the instruction information can be the identification information of the L2 processing, that is, the identifier of each L2 processing scheme can be configured and used as the instruction information. Of course, any information that can be used to instruct a specific L2 processing scheme can be used as instruction information, and this application embodiment does not impose specific limitations on it.

[0299] Optionally, the instruction information instructing the DU to perform L2 processing may include any of the following instructions: whether to retain duplicate PDCPs; whether to delete duplicate PDCPs; whether to delete LCIDs that have failed RLC; whether to retain LCIDs that have failed RLC; whether to retain duplicate PDCPs; whether to delete duplicate PDCPs; whether to delete LCIDs that have failed RLC; and whether to retain LCIDs that have failed RLC. It should be noted that the content of the instruction information here is merely illustrative and not a limitation on the content of the instruction information.

[0300] The "Whether to retain PDCP duplicates" indicator is used to indicate whether to retain or delete PDCP duplicates. When the "Whether to retain PDCP duplicates" indicator is set to "Yes", it indicates that PDCP duplicates should be retained. When the "Whether to retain PDCP duplicates" indicator is set to "No", it indicates that PDCP duplicates should be deleted.

[0301] The "Whether to delete PDCP duplicates" indicator is used to indicate whether to retain or delete PDCP duplicates. When the value of "Whether to delete PDCP duplicates" is "yes", it indicates that PDCP duplicates should be deleted. When the value of "Whether to delete PDCP duplicates" is "no", it indicates that PDCP duplicates should be retained.

[0302] For example, a PDCP duplicativity field can be added to the third message from CU to DU. This field is an enumeration type with two values: `kept` and `not kept`, indicating that PDCP duplications are kept and not kept, respectively. Alternatively, this field can be an integer with two values: 0 and 1, also indicating that PDCP duplications are kept and not kept, respectively. It should be noted that the position of the PDCP duplicativity field in the third message is not restricted.

[0303] The indication of whether to delete LCIDs that have failed RLC is used to indicate whether to delete LCIDs or not. When the value of "whether to delete LCIDs that have failed RLC" is yes, it indicates that LCIDs should be deleted. When the value of "whether to delete LCIDs that have failed RLC" is no, it indicates that LCIDs should not be deleted.

[0304] The indication of whether to retain LCIDs that have failed in RLC is used to indicate whether to delete LCIDs or not. When the value of "whether to retain LCIDs that have failed in RLC" is yes, it indicates that LCIDs should not be deleted. When the value of "whether to retain LCIDs that have failed in RLC" is no, it indicates that LCIDs should be deleted.

[0305] Similarly, for example, add a "removal of LCID" field. This field is an enumeration type with two values: true and false, representing deleting the LCID and keeping the LCID, respectively. Alternatively, this field could be an integer with two values: 0 and 1, representing deleting the LCID and keeping the LCID, respectively.

[0306] Optionally, the instruction information can be a required option, with different values ​​indicating different content; or, the instruction information can be an optional option, with its presence or absence indicating different content.

[0307] Case 2: The third message only includes the LCID of the RLC failure.

[0308] In scenario 2, the CU indicates to the DU which LCIDs have experienced RLC failures. The DU then performs the specific L2 processing operations, making its own decisions and executing them upon receiving the third message.

[0309] It should be noted that the specific operations of L2 processing after DU receives the third message in Case 2, and the content of L2 processing in Case 2 are the same as those described in Case 1, except that the executing entity of the decision is different. The details have been explained in detail in Case 1 above, and will not be repeated here.

[0310] The third message is the CU-DU interface message. Currently, in NR networks, the CU-DU interface message is defined as an F1 message. Of course, the CU-DU interface message can also have other names. When the network standard of the CU-DU architecture is different, the interface message can also be defined with different names, which is not specifically limited in this application. For example, in LTE networks, the interface between CU-DUs in a CU-DU architecture base station can be defined as a W1 interface, and the message transmitted on the W1 interface is called a W1 message. For example, the third message can be a W1 message.

[0311] Optionally, the third message can be an existing CU-DU interface message, or it can be a newly defined message specifically for notifying the DU to perform L2 processing when RLC fails. This application embodiment does not specifically limit this.

[0312] In one possible implementation, when the third message is an existing CU-DU interface message, the third message can be a UE context modification request message. When the third message is a newly defined F1 interface message or W1 interface message, the third message can be an RLC failure notification message.

[0313] Optionally, the LCID of the RLC failure and the instruction information instructing the DU to perform L2 processing may be included in the third message. Alternatively, the LCID of the RLC failure may be directly included in the third message as a field in the third message.

[0314] Optionally, the LCID indicating the RLC failure and the instruction information instructing the DU to perform L2 processing may be included in the third message; alternatively, the LCID indicating the RLC failure may be included in the second field of the third message. The second field can be any field in the third message.

[0315] Optionally, when the third message is an existing message, the second field can be an existing field in the existing message or a newly defined field. This application embodiment does not specifically limit this.

[0316] For example, when the third message is a UE context modification request message, the second field in the UE context modification request message includes the LCID of the RLC failure and indication information instructing the DU to perform L2 processing, or the LCID of the RLC failure. This second field can be an existing field in the UE context modification request message or a newly defined field; this application embodiment does not specifically limit it in this way.

[0317] For example, when the third message is a UE context modification request message, the second field may include a newly defined LCID with RLC failure list field.

[0318] For example, when the third message is a UE context modification request message, the first field is a newly defined list of LCIDs for failed RLCs, and the content of this field can be:

[0319] LCID with RLC failure list

[0320] >LCID with RLC failure list IEs

[0321] >>LCID

[0322] >>PDCP duplication / removal of LCID / keep PDCP duplication / remove PDCP duplication / keep LCID / remove LCID (optional).

[0323] This field contains the LCIDs of the RLC failures. Optionally, it may also contain an indication of whether to retain PDCP duplication, or whether to remove LCIDs, or whether to keep PDCP duplication, or whether to remove LCIDs, or whether to remove LCIDs.

[0324] For example, when the third message is a UE context modification request message, the second field is the DRB to Be Modified List field of the DRB corresponding to the LCID where the RLC failure occurred. The content of this field can be:

[0325] DRB to be modified List

[0326] DRB to be modified Item IEs

[0327] >>DRB ID

[0328] >>RLC failure or LCID with RLC failure

[0329] >>PDCP duplication / removal of LCID / keep PDCP duplication / remove PDCP duplication / keep LCID / remove LCID (optional).

[0330] It should be noted that when the second field is the DRB to Be Modified List field of the DRB corresponding to the LCID that experienced RLC failure, the prerequisite is that the CU can know the mapping relationship between the DRB ID and the LCID, find the corresponding DRB ID based on the LCID, and add an RLC failure indication. When the message contains an RLC failure indication, the DU needs to find the corresponding LCID based on the mapping relationship between the DRB ID and the LCID to know that the LCID experienced an RLC failure. When the message contains "LCID with RLC failure," the DU can directly know which LCID experienced an RLC failure.

[0331] For example, when the third message is a UE context modification request message, the second field is the SRB to Be Modified List field of the SRB corresponding to the LCID where the RLC failure occurred. The content of this field can be:

[0332] SRB to be modified List

[0333] >SRB to be modified Item IEs

[0334] >>SRB ID

[0335] >>RLC failure or LCID with RLC failure

[0336] >>PDCP duplication / removal of LCID / keep PDCP duplication / remove PDCP duplication / keep LCID / remove LCID (optional).

[0337] It should be noted that when the second field is the SRB to Be Modified List field for the SRB corresponding to the LCID that experienced RLC failure, the CU must know the mapping relationship between the SRB ID and the LCID, find the corresponding SRB ID based on the LCID, and add an RLC failure indication. When the message contains an RLC failure indication, the DU needs to find the corresponding LCID based on the mapping relationship between the SRB ID and the LCID to know that the LCID experienced an RLC failure. When the message contains "LCID with RLC failure," the DU can directly know which LCID experienced an RLC failure.

[0338] For example, when the third message is a UE context modification request message, and the L2 processing involves deleting the SCells corresponding to the LCIDs that have experienced RLC failures, the second field can be the secondary cell removal list (SCells to be removed list) from the UE context modification request message. For instance, the CU obtains the mapping relationship between LCIDs and secondary cells by reading the cell group configuration provided by the DU, such as by reading the allowedservingcell field corresponding to the LCID. The CU finds the corresponding secondary cell based on the LCID, and adds the secondary cell removal list, containing the SCells corresponding to the LCIDs that have experienced RLC failures, to the UE context modification request message.

[0339] Further optionally, the third message may also include a new SCell provided by the CU to replace the SCell corresponding to the LCID where the RLC failure occurred.

[0340] For example, a new SCell can be provided through an existing SCell to be added list field. Of course, it can also be provided in other ways, and this application embodiment does not specifically limit this.

[0341] S802, DU receives the third message from CU.

[0342] The third message may include the LCID indicating that an RLC failure has occurred and an instruction to the DU to perform L2 processing; or, the third message may include the LCID indicating that an RLC failure has occurred.

[0343] It should be noted that the third message received by DU from CU in S802 is the same as the third message sent by CU in S801. The third message has already been described in detail in S801, so it will not be repeated here.

[0344] S803 and DU perform L2 processing.

[0345] Specifically, the processing methods in S803 differ depending on the two scenarios of the third message in S801.

[0346] Optionally, corresponding to case 1 in S801, the DU in S803 performs L2 processing according to the instruction information. Corresponding to case 2 in S801, the DU in S803 makes a decision and performs L2 processing.

[0347] Here, DU decision refers to DU determining the specific operation to perform L2 processing based on the network state. The possible schemes for its specific operation have been described in detail in Case 1 of S801, and will not be repeated here.

[0348] Further optional, corresponding to case 2 in S801, after the DU makes a decision and executes L2 processing in S803, it also needs to notify the CU of the content of its L2 processing.

[0349] For example, suppose the L2 processing involves the DU deleting the SCells corresponding to LCIDs that experienced RLC failures. This means the CU learns which LCIDs experienced RLC failures through a third message, implying that the DU needs to delete the SCells corresponding to these failed LCIDs. Furthermore, the DU can also decide whether to retain PDCP duplicates. The DU informs the CU of its decision, for example, by sending a notification message. This notification message may contain an instruction to delete PDCP duplicates, or an instruction to retain PDCP duplicates, or an instruction to retain PDCP duplicates. Alternatively, the DU can only notify the CU when it decides to delete PDCP duplicates. This notification message may contain an instruction to delete PDCP duplicates, or an instruction to retain PDCP duplicates. This allows the CU to delete the configuration information related to PDCP duplicates in the PDCP configuration. Alternatively, the DU can also decide whether to delete LCIDs that experienced RLC failures. When the DU decides whether to delete an LCID that experienced an RLC failure, or decides to delete an LCID that experienced an RLC failure, it informs the CU of the decision. The notification method is similar to informing the CU whether to delete PDCP duplicates, and will not be elaborated here.

[0350] It should be noted that this application will not elaborate on the process of DU performing L2 processing, i.e. configuring the RLC and MAC layers, but can refer to existing mechanisms.

[0351] Further optionally, when the DU performs L2 processing and deletes the SCell, SCell allocation is also required. One possible implementation is to reallocate the existing SCell, and another is to reallocate the existing SCell along with the new SCell provided by the CU. This application does not specifically limit this approach.

[0352] Further optionally, the third message may also include a new SCell provided by the CU to replace the SCell corresponding to the LCID where the RLC failure occurred.

[0353] For example, suppose DRB1 corresponds to LCID1 and LCID2, where the RLC corresponding to LCID2 has experienced an RLC failure. Suppose the new SCells provided by CU are 6 and 7, and DU performs SCell allocation as shown in Table 2.

[0354] Table 2

[0355]

[0356] S804, DU sends a fourth message to CU, which includes the cell group configuration for L2 processing.

[0357] Specifically, the DU performs L2 processing, configuring the RLC and MAC layers. The specific content of this configuration is the CellGroupConfig, which needs to be sent to the UE via the CU so that the UE can perform the same configuration. Therefore, the DU sends a second message to the CU to transmit the CellGroupConfig to the UE via the CU.

[0358] Optionally, if the third message is a request message of a request-response mechanism, then the fourth message can be a response message to the third message; if the third message is a message of a non-request-response mechanism, then the fourth message is a separate message. This application does not specifically limit the type of the fourth message.

[0359] For example, the fourth message may include a response message to the UE context modification request message.

[0360] S805 and CU receive the fourth message sent by DU.

[0361] The fourth message includes the cell group configuration for L2 processing.

[0362] It should be noted that the fourth message received by the CU from the DU in S805 is the same as the fourth message sent by the DU in S804. The fourth message has already been described in detail in S804, so it will not be repeated here.

[0363] Furthermore, as shown in FIG9, after S805, the notification method provided in this application embodiment may also include S806.

[0364] S806 and CU send an RRC reconfiguration message to the UE. The RRC reconfiguration message includes the cell group configuration.

[0365] Specifically, after receiving the fourth message in S805, the CU adds the relevant configurations of its own L2 processing (such as PDCP layer configuration) and the cell group configuration in the fourth message to the RRC reconfiguration message and sends them to the UE so that the UE can perform the same configuration. The specific process will not be elaborated here.

[0366] The notification method provided in this application allows the DU to obtain from the CU the LCID of the RLC failure and the indication information for the L2 processing scheme; or, the DU to obtain from the CU the LCID of the RLC failure and determine that an RLC failure has occurred. This enables the DU to know the LCID of the RLC failure and the L2 processing scheme; or, enables the DU to know which LCIDs have experienced RLC failure, facilitating the DU to perform the accurate corresponding L2 processing for L2 configuration adapted to changes in the terminal device's communication link.

[0367] It should be noted that the above implementation is a notification from the CU to the DU from the control plane. In another possible implementation, the notification method provided in this application can be implemented through the UP.

[0368] Specifically, the user plane tunnel between the CU and DU is at the DRB granularity or LCID granularity. For example, when the CU and DU perform PDCP repetition based on carrier aggregation, two F1-U tunnels will be established between the CU and DU for one DRB. For example, the CU includes the DRB ID and the corresponding CU-side transport layer information in the UE context setup / modification request message. The transport layer information may include the TEID and / or transport layer address. The DU includes the DRB ID and the corresponding DU-side TEID in the response message. The CU-side TEID and DU TEID can uniquely identify a user plane tunnel, that is, uniquely identify a DRB / LCID. Optionally, if the CU-side transport layer address and DU-side transport layer address can uniquely identify a user plane tunnel, that is, uniquely identify a DRB / LCID, then the third message may include the transport layer address corresponding to the DRB ID. In this implementation, the third message includes the TEID corresponding to the LCID that experienced RLC failure, an RLC failure indication, and an instruction to the DU to perform L2 processing; or, the third message includes the TEID corresponding to the LCID that experienced RLC failure and an instruction to the DU to perform L2 processing; or, the third message includes the TEID corresponding to the LCID that experienced RLC failure and an RLC failure indication. The specific implementation can be found in the control plane implementation described above, and will not be elaborated further here. When the CU sends a downlink data packet to the DU, it will carry the TEID in the packet header. When the packet header carries an RLC failure indication, the binding relationship between the tunnel endpoint address and the LCID determines which LCID experienced the RLC failure. When the packet header carries both an RLC failure indication and an instruction to the DU to perform L2 processing, the binding relationship between the tunnel endpoint address and the LCID determines which LCID experienced the RLC failure and what type of L2 processing needs to be performed. When the packet header carries an instruction to the DU to perform L2 processing, the binding relationship between the tunnel endpoint address and the LCID determines which LCID needs to perform what type of L2 processing.

[0369] The above mainly describes the solution provided by the embodiments of this application from the perspective of the working process of CU and DU. It is understood that, in order to achieve the above functions, CU and DU include corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware 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.

[0370] It should be noted that the functional part of the CU or DU that performs the notification method provided in this application is called a communication device. It can be understood that the communication device can be part or all of the CU or DU. In other words, the communication device can be equivalent to the CU or DU, or the communication device can also be deployed in the CU or DU to support the CU or DU in performing the notification method provided in this application.

[0371] This application embodiment can divide the CU and DU into functional modules according to the above method example. For example, each function can be divided into a separate functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or software functional modules. It should be noted that the module division in this application embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods. When the communication device is part or all of the CU or DU, dividing the CU or DU into functional modules is equivalent to dividing the communication device into functional modules; or, when the communication device is part or all of the CU or DU, dividing the communication device into functional modules is equivalent to dividing the CU or DU into functional modules.

[0372] Figure 10 illustrates a possible structural diagram of the communication device in the CU involved in the above embodiments, where each functional module is divided according to its corresponding function. The communication device 100 may include a transmitting unit 1001 and a receiving unit 1002. The transmitting unit 1001 is used to execute processes S601 and S606 in Figure 6 or 7, or processes S801 and S806 in Figure 8 or 9; the receiving unit 1002 is used to execute process S605 in Figure 6 or 7, or process S805 in Figure 8 or 9. All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0373] Furthermore, as shown in FIG11, the communication device 100 may further include a processing unit 1003. The processing unit 1003 is used to execute process S601a in FIG6 or FIG7, or to execute process S801a in FIG8 or FIG9.

[0374] In the case of using an integrated unit, FIG12 shows a possible structural schematic diagram of the communication device in the CU involved in the above embodiments. The communication device 120 may include: a processing module 1201 and a communication module 1202. The processing module 1201 is used to control and manage the operation of the communication device 120. For example, the processing module 1201 is used to support the communication device 120 in executing processes S601, S605, and S606 in FIG6 or 7, or in executing processes S801, S805, and S806 in FIG8 or 9, through the communication unit 1202; the processing module 1201 is also used to support the communication device 120 in executing process S601a in FIG6 or 7, or in executing process S801a in FIG8 or 9. The communication device 120 may also include a storage module 1203 for storing the program code and data of the communication device 120.

[0375] When the communication device 120 is deployed within the CU, the processing module 1201 can be the processor 401 in the physical structure of the CU 40 shown in FIG. 4, and can be a processor or controller. For example, it can be a CPU, general-purpose processor, DSP, ASIC, FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor 1201 can also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of DSP and microprocessor, etc. The communication module 1202 can be the transceiver 403 in the physical structure of the CU 40 shown in FIG. 4. The communication module 1202 can be a communication port, or it can be a transceiver, transceiver circuit, or communication interface, etc. Alternatively, the aforementioned communication interface can achieve communication with other devices through the aforementioned transceiver components. The aforementioned transceiver components can be implemented by antennas and / or radio frequency devices. The storage module 1203 can be the memory 402 in the physical structure of the CU 40 shown in FIG. 4.

[0376] When the processing module 1201 is a processor, the communication module 1202 is a transceiver, and the storage module 1203 is a memory, the communication device 120 involved in FIG12 of this application embodiment can be part or all of the CU 40 shown in FIG4.

[0377] As mentioned above, the communication device 100 or communication device 120 provided in the embodiments of this application can be used to implement the function of CU in the methods implemented in the various embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the various embodiments of this application.

[0378] Figure 13 illustrates a possible structural diagram of the communication device in the DU involved in the above embodiments, where each functional module is divided according to its corresponding function. The communication device 130 may include: a receiving unit 1301, a processing unit 1302, and a transmitting unit 1303. The receiving unit 1301 is used to execute process S602 in Figure 6 or Figure 7, or process S802 in Figure 8 or Figure 9; the processing unit 1302 is used to execute process S603 in Figure 6 or Figure 7, or process S803 in Figure 8 or Figure 9; the transmitting unit 1303 is used to execute process S604 in Figure 6 or Figure 7, or process S804 in Figure 8 or Figure 9. All relevant content of each step involved in the above method embodiments can be referenced from the functional description of the corresponding functional module, and will not be repeated here.

[0379] In the case of using an integrated unit, FIG14 shows a possible structural schematic diagram of the communication device in the DU involved in the above embodiments. The communication device 140 may include: a processing module 1401 and a communication module 1402. The processing module 1401 is used to control and manage the operation of the communication device 140. For example, the processing module 1401 is used to support the communication device 140 in executing processes S602 and S604 in FIG6 or 7, or processes S802 and S804 in FIG8 or 9, through the communication unit 1402; the processing module 1401 is also used to support the communication device 140 in executing process S603 in FIG6 or 7, or process S803 in FIG8 or 9. The communication device 140 may also include a storage module 1403 for storing the program code and data of the communication device 140.

[0380] When the communication device 140 is deployed within the DU, the processing module 1401 can be the processor 501 in the physical structure of the DU 50 shown in FIG. 5, and can be a processor or controller. For example, it can be a CPU, general-purpose processor, DSP, ASIC, FPGA, or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It can implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. The processor 1401 can also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of DSP and microprocessor, etc. The communication module 1402 can be the transceiver 503 in the physical structure of the DU 50 shown in FIG. 5. The communication module 1402 can be a communication port, or it can be a transceiver, transceiver circuit, or communication interface, etc. Alternatively, the aforementioned communication interface can achieve communication with other devices through the aforementioned transceiver components. The aforementioned transceiver components can be implemented by antennas and / or radio frequency devices. The storage module 1403 can be the memory 502 in the physical structure of the DU 50 shown in FIG. 5.

[0381] When the processing module 1401 is a processor, the communication module 1402 is a transceiver, and the storage module 1403 is a memory, the communication device 140 involved in FIG14 of this application embodiment can be part or all of the DU 50 shown in FIG5.

[0382] As mentioned above, the communication device 130 or communication device 140 provided in the embodiments of this application can be used to implement the function of DU in the methods implemented in the various embodiments of this application. For ease of explanation, only the parts related to the embodiments of this application are shown. For specific technical details not disclosed, please refer to the various embodiments of this application.

[0383] In another aspect, embodiments of this application provide a communication system, including the CU described in any of the above bearer type switching embodiments, and the DU described in any of the above bearer type switching embodiments.

[0384] In another aspect, embodiments of this application provide a communication system including the CU described in any of the above RLC failure embodiments and the DU described in any of the above RLC failure embodiments.

[0385] The steps of the methods or algorithms described in this application can be implemented in hardware or by a processor executing software instructions. The software instructions can consist of corresponding software modules, which can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, portable hard disks, read-only optical discs (CD-ROMs), or any other form of storage medium known in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and storage medium can reside in an ASIC. Alternatively, the ASIC can reside in a core network interface device. Of course, the processor and storage medium can also exist as discrete components in the core network interface device. Alternatively, the memory can be coupled to the processor; for example, the memory can exist independently and be connected to the processor via a bus. The memory can also be integrated with the processor. The memory can be used to store application code that executes the technical solutions provided in the embodiments of this application, and its execution is controlled by the processor. The processor is used to execute application code stored in memory, thereby implementing the technical solutions provided in the embodiments of this application.

[0386] This application provides another chip system, which includes a processor for implementing the technical methods of the communication device of the present invention. In one possible design, the chip system further includes a memory for storing necessary program instructions and / or data of the communication device of the present invention. In another possible design, the chip system further includes a memory for the processor to call application code stored in the memory. This chip system may be composed of one or more chips, or may include chips and other discrete devices; this application does not specifically limit this.

[0387] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0388] Those skilled in the art will recognize that, in one or more of the examples above, the functions described in this application can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or code on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein communication media include any medium that facilitates the transmission of a computer program from one place to another. Storage media can be any available medium accessible to a general-purpose or special-purpose computer. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, apparatuses, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0389] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of 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, indirect coupling or communication connection between devices or units, and may be electrical or other forms.

[0390] 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.

[0391] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can be physically included separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0392] The integrated units implemented as software functional units described above can be stored in a computer-readable storage medium. These software functional units, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute some steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0393] Finally, it should be noted that the above 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.

Claims

1. A notification method, characterized in that, The method, applied to the CU in a centralized unit (CU)-distributed unit (DU) architecture, includes: The CU sends a first message to the DU, the first message including the identifier ID of the first data radio bearer (DRB) to which bearer type switching has occurred and a first indication information instructing the DU to perform L2 processing; or, the first message includes the ID of the first DRB and a second indication information instructing the DU to perform bearer type switching. The CU receives a second message sent by the DU, the second message including cell group configuration for L2 processing.

2. The notification method according to claim 1, characterized in that, The execution of L2 processing includes: Media Access Control (MAC) reset and Radio Link Control (RLC) re-establishment; or, Change the Logical Channel Identifier (LCID) and re-establish RLC; or, MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

3. The notification method according to claim 1 or 2, characterized in that, The first message also includes a primary cell group (MCG) indication, and the execution of L2 processing includes: MAC reset and RLC re-establishment; or, Change LCID and re-establish RLC.

4. The notification method according to claim 1 or 2, characterized in that, The first message also includes a secondary cell group (SCG) indication, and the execution of L2 processing includes: MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

5. The notification method according to any one of claims 1-4, characterized in that, The first message also includes: The ID of the second DRB is used to replace the ID of the first DRB.

6. A notification method, characterized in that, The method, applied to the DU in a centralized unit (CU)-distributed unit (DU) architecture, includes: The DU receives a first message from the CU, the first message including the identifier ID of the first data radio bearer (DRB) to which bearer type switching has occurred and a first indication information instructing the DU to perform L2 processing; or, the first message includes the ID of the first DRB and a second indication information instructing the DU to perform bearer type switching. The DU performs L2 processing; The DU sends a second message to the CU, the second message including the cell group configuration for L2 processing.

7. The notification method according to claim 6, characterized in that, If the first message includes the ID of the first DRB and the second indication information, the DU performs L2 processing, including: The DU makes decisions and performs L2 processing.

8. The notification method according to claim 6 or 7, characterized in that, The scheme for performing L2 processing includes: Media Access Control (MAC) reset and Radio Link Control (RLC) re-establishment; or, Change the Logical Channel Identifier (LCID) and re-establish RLC; or, MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

9. The notification method according to any one of claims 6-8, characterized in that, The first message also includes a primary cell group (MCG) indication, and the scheme for performing L2 processing includes: MAC reset and RLC re-establishment; or, Change LCID and re-establish RLC.

10. The notification method according to any one of claims 6-8, characterized in that, The first message also includes a secondary cell group (SCG) indication, and the scheme for performing L2 processing includes: MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

11. The notification method according to any one of claims 6-10, characterized in that, The first message also includes: the ID of the second DRB, which is used to replace the ID of the first DRB; The method further includes: the DU performing L2 processing on the first DRB and / or the second DRB.

12. The notification method according to any one of claims 1-11, characterized in that, The first message is a User Equipment (UE) Context Modification Request message.

13. The notification method according to any one of claims 1-12, characterized in that, The second indication information is a bearer type switch.

14. The notification method according to any one of claims 1-13, characterized in that, The second message is a UE context modification response message.

15. A communication device, characterized in that, The CU, deployed in a centralized unit (CU)-distributed unit (DU) architecture, includes: The transmitting unit is configured to send a first message to the DU, the first message including the identifier ID of the first data radio bearer (DRB) to which bearer type switching has occurred and first indication information instructing the DU to perform L2 processing; or, the first message includes the ID of the first DRB and second indication information instructing the DU to perform bearer type switching. A receiving unit is configured to receive a second message sent by the DU, the second message including cell group configuration processed by L2.

16. The communication device according to claim 15, characterized in that, The execution of L2 processing includes: Media Access Control (MAC) reset and Radio Link Control (RLC) re-establishment; or, Change the Logical Channel Identifier (LCID) and re-establish RLC; or, MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

17. The communication device according to claim 15 or 16, characterized in that, The first message also includes a primary cell group (MCG) indication, and the execution of L2 processing includes: MAC reset and RLC re-establishment; or, Change the Logical Channel Identifier (LCID) and re-establish the RLC.

18. The communication device according to claim 15 or 16, characterized in that, The first message also includes a secondary cell group (SCG) indication, and the execution of L2 processing includes: MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

19. The communication device according to any one of claims 15-18, characterized in that, The first message also includes: The ID of the second DRB is used to replace the ID of the first DRB.

20. A communication device, characterized in that, The DU, deployed in a centralized unit (CU)-distributed unit (DU) architecture, includes: A receiving unit is configured to receive a first message from the CU, the first message including an identifier ID of a first data radio bearer (DRB) to which a bearer type switch has occurred and a first indication information indicating a scheme for the DU to perform L2 processing; or, the first message including the ID of the first DRB and a second indication information indicating that a bearer type switch has occurred. Processing unit, used to perform L2 processing; A sending unit is configured to send a second message to the CU, the second message including the cell group configuration for L2 processing.

21. The communication device according to claim 20, characterized in that, If the first message includes the ID of the first DRB and the second indication information, the processing unit is specifically used to: make a decision and perform L2 processing.

22. The communication device according to claim 20 or 21, characterized in that, The execution of L2 processing includes: Media Access Control (MAC) reset and Radio Link Control (RLC) re-establishment; or, Change the Logical Channel Identifier (LCID) and re-establish RLC; or, MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

23. The communication device according to any one of claims 20-22, characterized in that, The first message also includes a primary cell group (MCG) indication, and the execution of L2 processing includes: MAC reset and RLC re-establishment; or, Change the Logical Channel Identifier (LCID) and re-establish the RLC.

24. The communication apparatus according to any one of claims 20-22, characterized in that, The first message also includes a secondary cell group (SCG) indication, and the execution of L2 processing includes: MAC synchronization reconfiguration and RLC re-establishment; or, Change LCID and release and add RLC bearers.

25. The communication device according to any one of claims 20-24, characterized in that, The first message also includes: the ID of the second DRB, which is used to replace the ID of the first DRB; The processing unit is further configured to perform L2 processing on the first DRB and / or the second DRB.

26. The communication device according to any one of claims 15-25, characterized in that, The first message is a UE context modification request message.

27. The communication device according to any one of claims 15-26, characterized in that, The second indication information is a bearer type switch.

28. The communication device according to any one of claims 15-27, characterized in that, The second message is a UE context modification response message.

29. A communication device, characterized in that, The device includes a processor, a memory, and instructions stored in the memory and executable on the processor, wherein when the instructions are executed, the device performs the notification method as described in any one of claims 1 to 5.

30. A communication device, characterized in that, The device includes a processor, a memory, and instructions stored in the memory and executable on the processor, wherein when the instructions are executed, the device performs the notification method as described in any one of claims 6 to 11.

31. A lumped unit CU, characterized in that, Includes the communication device as described in claim 29.

32. A distributed unit DU, characterized in that, Includes the communication device as described in claim 30.

33. A communication system, characterized in that, It includes the centralized unit CU as described in claim 31 and the distributed unit DU as described in claim 32.

34. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the notification method as described in any one of claims 1 to 5, or the method as described in any one of claims 6 to 11.

35. A computer program product, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the notification method as described in any one of claims 1 to 5, or to perform the method as described in any one of claims 6 to 11.

Images