Detection of link faults between CU and DU

Abstract

A method is provided performed by a distributed unit (DU) of a base station, the method comprising: detecting a fault in a link between the DU and a user plane (UP) entity of a central unit (CU) of the base station; generating a message indicating the fault based on the detected fault; and sending the message to a control plane (CP) entity.

Description

Technical Field

[0001] The various example implementations generally involve the detection of link failures. Background Technology

[0002] Communication links may fail. Therefore, it is crucial to detect and report such failures as early and efficiently as possible. Summary of the Invention

[0003] The subject matter of the independent claims is provided according to several aspects. Further aspects are defined in the dependent claims. Embodiments that do not fall within the scope of the claims should be interpreted as examples that aid in understanding this disclosure. Attached Figure Description

[0004] In the following description, the invention will be described in more detail with reference to embodiments and accompanying drawings, wherein: Figure 1 and Figure 2 One or more network examples applicable to the embodiments are presented; Figure 3 and Figure 4 Methods according to some embodiments are shown; Figure 5 and Figure 6 A signaling flowchart according to some embodiments is shown; Figure 7 , Figure 8 and Figure 9 Methods according to some embodiments are shown; Figure 10 , Figure 11 and Figure 12 A signaling flowchart according to some embodiments is shown; Figure 13 An apparatus according to some embodiments is shown. Detailed Implementation

[0005] The following embodiments are exemplary. Although the specification may refer to "a," "an," or "some" embodiments in several places in the text, this does not necessarily mean that every reference refers to the same embodiment, or that a particular feature applies only to a single embodiment. Individual features of different embodiments may also be combined to provide other embodiments. Furthermore, when a particular feature, structure, or characteristic is described in connection with an embodiment, whether explicitly described or not, its application in combination with other embodiments is within the scope of knowledge of those skilled in the art. It should be understood that although terms such as "first," "second," etc., may be used herein to describe various elements, these elements should not be limited to these terms. These terms are used only to distinguish one element from another.

[0006] For the purposes of this disclosure, the phrases "at least one of A or B", "at least one of A and B", and "A and / or B" refer to (A), (B), or (A and B). For the purposes of this disclosure, the phrases "A, B, and / or C" refer to (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0007] The described embodiments can be implemented in a communication network, such as in any of the following radio access technologies (RATs): Global Microwave Access Interoperability (WiMAX), Global System for Mobile Communications (GSM, 2G), GSM EDGE Radio Access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunications System (UMTS, 3G) based on Basic Wideband Code Division Multiple Access (W-CDMA), High-Speed ​​Packet Access (HSPA), Long Term Evolution (LTE), LTE-Advanced and Enhanced LTE (eLTE), 5G (also known as NR), or any future RAT such as 6G. Furthermore, communication within the communication network can utilize any suitable wireless communication technology, including but not limited to: Code Division Multiple Access (CDMA), Frequency Division Multiple Access (FDMA), Time Division Multiple Access (TDMA), Frequency Division Duplex (FDD), Time Division Duplex (TDD), Multiple-Input Multiple-Output (MIMO), Orthogonal Frequency Division Multiplexing (OFDM), and / or Discrete Fourier Transform Extended OFDM (DFT-s-OFDM).

[0008] As used herein, the term "network device" or "network node" refers to a node in a communication network through which user equipment can access the network, and / or through which the node can control radio communications within the cell and manage radio resources. A network node or network device may be referred to as a base station (BS), access point (AP), or access node. Depending on the technology applied, a network device may be, for example: a Node B (NodeB or NB), an evolved Node B (eNodeB or eNB), an NR NB (also known as a gNB), a Remote Radio Unit (RRU), a Radio Head (RH), a Remote Radio Head (RRH), a relay, an Integrated Access and Backhaul (IAB) node, a low-power node, a non-terrestrial network (NTN) or non-terrestrial network equipment (such as satellite network equipment, low Earth orbit (LEO) satellites, geostationary orbit (GEO) satellites), or a spacecraft network device.

[0009] Furthermore, regarding split radio access networks (RANs), network equipment can refer to a centralized unit (CU) and / or a distributed unit (DU) of a base station. The interface between the CU and DU can be referred to as the F1 interface in NR. In a split RAN architecture, node operations can be performed at least partially in a central / centralized unit (CU) (e.g., a server, host, or node) that is operationally coupled to a DU (e.g., a radio head / node). A CU can control one or more DUs, which at least act as transmit / receive (Tx / Rx) nodes. In some embodiments, a DU may include, for example, a Radio Link Control (RLC) layer, a Media Access Control (MAC) layer, and a Physical (PHY) layer, while a CU may include layers above the RLC layer, such as a Packet Data Convergence Protocol (PDCP) layer, a Radio Resource Control (RRC) layer, and an Internet Protocol (IP) layer. Other functional divisions are also possible. In practice, any processing task can be performed in a CU or a DU, and the boundaries of the transfer of responsibilities between the CU and DU can depend on the implementation applied.

[0010] The term "terminal device" refers to any terminal device capable of wireless communication. For example, a terminal device may be referred to as a communication device, user equipment (UE), subscriber station (SS), or mobile station (MS). Terminal devices can include mobile phones, cellular phones, smartphones, Voice over IP (VoIP) phones, wireless local loop phones, tablets, wearable terminal devices, personal digital assistants (PDAs), portable computers, desktop computers, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback devices, in-vehicle wireless terminal devices, USB dongles, Internet of Things (IoT) devices, watches or other wearable devices, head-mounted displays (HMDs), vehicles, drones, medical devices and applications (e.g., remote surgery), industrial equipment and applications (e.g., robots and / or other wireless devices operating in industrial and / or automated processing chain environments), consumer electronics devices, devices operating on commercial and / or industrial wireless networks, etc.

[0011] As used herein, the term "resource" can refer to radio resources in the time domain, frequency domain, spatial domain, and / or code domain. Some examples of resources include, for example, physical resource blocks (PRBs), radio frames, subframes, time slots, subbands, frequency regions, subcarriers, beams, etc. The terms "transmit" and / or "receive" can refer to wireless transmission and / or reception on radio resources via a radio propagation channel.

[0012] Figure 1Examples of communication networks to which the examples disclosed herein may be applied are shown. A communication network or cellular communication network may include a network node 110 providing one or more cells (such as cell 100) and a network node 112 providing one or more other cells (such as cell 102). Each cell may be, for example, a macrocell, microcell, femtocell, or picocell. A cell may define the coverage area or service area of ​​a corresponding access node.

[0013] Network node 110 can provide user equipment (UE) 120 (one or more UEs) with radio access to a communication network. Radio access may include downlink (DL) communication from the network node to UE 120 and uplink (UL) communication from UE 120 to the network node. Examples of uplink channels include a Physical Uplink Control Channel (PUCCH) for transmitting control information and a Physical Uplink Shared Channel (PUSCH) for transmitting data to the network. Examples of downlink channels include a Physical Downlink Control Channel (PDCCH) for transmitting control information and a Physical Downlink Shared Channel (PDSCH) for transmitting data to the user equipment.

[0014] Multiple UEs 120 and 122 can exist in the system. Each UE can be served by the same or different control nodes 110 and 112. UEs 120 and 122 can communicate with each other when a device-to-device (D2D) communication interface is established between them via a so-called side link (SL). This D2D communication can be referred to as, for example, machine-to-machine communication, point-to-point (P2P) communication, or vehicle-to-vehicle (V2V) communication.

[0015] In a communication network with multiple network nodes, these nodes can connect to each other via interfaces. The LTE specification refers to this interface as the X2 interface. The interface between an LTE node and a 5G node, or between two 5G nodes, can be called the Xn interface.

[0016] Network nodes 110 and 112 can be further connected to the core network 116 of the communication network via another interface. The LTE specification designates the core network as an Evolved Packet Core (EPC), and the core network may include, for example, a Mobility Management Entity (MME) and gateway nodes. The MME can handle the mobility of terminal devices in a tracking area covering multiple cells and handle signaling connections between the terminal devices and the core network. Gateway nodes can handle data routing within the core network and data routing to / from terminal devices. The 5G specification designates the core network as a 5G Core (5GC). The 5G Core may include, for example, Access and Mobility Management Functions (AMF), User Plane Functions / Gateways (UPF), and other functions. The AMF can handle the termination of Non-Access Stratum (NAS) signaling, NAS encryption and integrity protection, registration management, connection management, mobility management, access authentication and authorization, and security context management. UPF nodes can support, for example, packet routing and forwarding, packet inspection, and Quality of Service (QoS) processing.

[0017] Figure 2 An embodiment of a distributed RAN architecture is illustrated, in which a gNB (e.g., gNB 110) can be logically split into at least a centralized unit (CU) 200 and a distributed unit (DU) 206 of base station 110. The interface between CU 200 and DU 206 can be referred to as an F1 interface in NR. CU 200 can be further divided into a control part (CP) entity 202 and a user plane (UP) entity 204 of CU 200. The interface or communication link between DU 206 and CU 200 can be referred to as an F1 interface, which can be similarly split into control (C) and user (U) planes. The interface or communication link between CU CP 202 and CU UP 204 can be referred to as an E1 interface.

[0018] In Release 18, 3GPP designed a feature for resource sharing across multicast and broadcast service (MBS) sessions during RAN sharing. This feature allows the same MBS to be delivered to the shared NG-RAN via CNs of multiple operators participating in network sharing, and the shared NG-RAN nodes can broadcast MBS data only once to improve resource utilization. This feature is intended to apply only to broadcast MBS sessions and not to multicast MBS sessions.

[0019] This feature related to RAN sharing has two deployment options. In one deployment option called the “MOCN variant,” both the CU and DU are shared. In this case, between the shared user plane (UP) entity of the CU (also known as CU UP or gNB-CU UP) and the shared DU (also known as gNB-DU), there is only one F1-U tunnel (the tunnel used for user plane data between the DU and CU) for each multicast radio bearer (MRB). In another deployment option called the “multi-cell ID variant,” the gNB-DU is shared, but the CU is not shared (each Public Land Mobile Network (PLMN) #X sharing the RAN has its own CU #X). In this case, between the gNB-DU and one or more CU UPs, there can be one or more F1-U tunnels for each MRB.

[0020] 3GPP has determined that, for multiple cell ID variants, the gNB-DU will decide how many F1-U tunnels it wishes to establish for each MRB. This means that the gNB-DU receives a broadcast session establishment request message from the CU CP #X of each PLMN #X and indicates in the broadcast session establishment response whether it accepts the establishment of an F1-U tunnel with the corresponding CU UP of that PLMN #X. For example, in the case of sharing with PLMN1, PLMN2, and PLMN3, the gNB-DU may decide that: it should establish an F1-U tunnel with CU UP #1 according to the request of CU CP #1 of (PLMN1), but should not establish an F1-U tunnel with CU UP #2 according to the request of CU CP #2 of (PLMN2), nor should it establish an F1-U tunnel with CU UP #3 according to the request of CU CP #3 of (PLMN3).

[0021] Furthermore, 3GPP has decided that the gNB-DU can trigger a new F1U tunnel establishment request to address F1U failure situations. Continuing with the example above, if the gNB-DU has only established an F1U tunnel with CU UP #1 and that F1U tunnel fails after a period of time, the gNB-DU can, for example, send a new F1AP broadcast transport resource request message to CU CP #2. Upon receiving this F1AP broadcast transport resource request message, CU CP #2 can trigger an F1AP broadcast establishment modification request to the gNB-DU to establish an F1U tunnel between CU UP #2 and the gNB-DU.

[0022] The current solution is insufficient to implement the agreed-upon fault handling behavior at both the DU and CU UP. More specifically: In the event that an MBS F1-U fault is detected at DU: Currently, the gNB-DU cannot signal an F1-U tunnel failure to a CU CP without requesting a complete release of the broadcast session from the CU CP with which it previously established an F1-U tunnel. This situation applies to scenarios without RAN sharing, as well as scenarios with RAN sharing, where the gNB-DU signals the F1-U failure with CU UP #X to CU CP #X of PLMN #X with which it previously established an F1-U tunnel, instead of signaling it to another CU CP #Y of another PLMN #Y.

[0023] Even if gNB-DU is able to notify the CU CP with which it previously established the F1-U tunnel, the CU CP will not know whether gNB-DU expects it to restore the F1-U tunnel itself or not (for example, because gNB-DU intends to request the CU CP of another PLMN to establish another F1-U tunnel with the CU UP of another PLMN).

[0024] Currently, CU CP cannot request CU UP to allocate a new F1-U tunnel uplink TLA (transport layer address) by modifying the existing MBS E1 context between CU CP and CU UP.

[0025] In the event that an MBS F1-U fault is detected at CU UP: Currently, the CU UP cannot signal to the CU CP that it has detected a failure in a previously established F1-U tunnel between itself and the gNB-DU, and the CU CP cannot have the CU UP assign a new F1-U tunnel uplink TLA (Transport Layer Address) or, alternatively, notify the gNB-DU for further decisions and actions. Without this approach, if an F1U tunnel fails, it is impossible to create another tunnel to the same or a different PLMN.

[0026] To at least partially address these issues, a solution for efficiently detecting and reporting F1-U link failures is proposed, where the F1-U communication link is between a DU and a CU UP. In one embodiment, the DU performs the detection and notifies the CU CP of the failed F1U link / tunnel (i.e., to the same PLMN). In another embodiment, the DU performs the detection and notifies the CU CP of a different CU CP than the failed F1U tunnel (i.e., to a different PLMN). In yet another embodiment, the detection is performed by the CU UP.

[0027] In the embodiments presented herein, a failed F1-U link between the CU UP and DU can be associated with at least one MBS (Multicast Broadcast Service) radio bearer (MRB) of an MBS session (e.g., it can carry its data). It should be noted that the F1U tunnel has both DL TNL information and UL TNL information, such as TEID.

[0028] First, consider an implementation where an F1-U fault is detected at the DU and the CU CP (same PLMN) of the F1U tunnel / link that has failed is notified.

[0029] Figure 3 It shows that it can be generated by DU (e.g., such as Figure 2 The example method executed by DU 206. This method can be implemented by a computer. Figure 3 As shown, in step 300, the DU can detect a fault in the link between the base station (such as gNB 110) and its CU UP (such as CU UP 204). The DU can detect faults in various ways, such as using test signals or detecting a lack of response / message on the link. In step 302, the DU can generate a message based on the detected fault, indicating the fault. There are several options regarding what the message is and what its content is, as will be described below. In step 304, the DU can send the message to a control plane (CP) entity, such as to CU CP 202 or to the CU CP of another gNB.

[0030] From the receiver's perspective, Figure 4 It shows that it can be generated by CU CP (such as Figure 2 Example methods, either by CU CP 202 or by another CU CP (such as CU CP gNB 112). This method can be implemented by a computer. Figure 4 As shown, in step 400, the CU CP can receive a message from DU 206 of gNB 110 indicating a failure of the link between the DU and CU UP. In step 402, the CU CP then determines whether to trigger the establishment of a new link for the DU (i.e., replace the failed link to restore communication) or to notify the CU UP of the failed link. This triggering can be an advantageous option, allowing communication to continue more smoothly. However, this is not always a viable option, and other notification options may be appropriate. It should be noted that under this option, communication can similarly continue at a later point in time, as the CU UP may subsequently trigger the process of restoring the MBS session.

[0031] The following is combined with Figure 5 and Figure 6 These embodiments are described in more detail with signaling flowcharts.

[0032] Figure 5 The option is shown to detect an F1-U fault at the DU (also known as gNB-DU) and notify the CU CP (also known as gNB-CU CP) of the F1U tunnel (i.e., the same PLMN) where the fault occurred.

[0033] exist Figure 5 In step 500, there is an ongoing MBS broadcast session being transmitted over N3mb and F1U. For simplicity, the MB-UPF entity of PLMN 1 through which the MBS session is taking place is not shown in the diagram. DU and CU-UP also belong to PLMN 1. DU may have previously established a link between DU and CU UP together with CU CP.

[0034] In steps 502-504, the gNB-DU detects a F1U failure with the CU UP. The F1U path was previously established by the CU CP. To detect a link failure, the gNB-DU may, for example, generate one or more echo request messages 502 on the F1U path. Once no response is received to the echo request, the DU detects a link failure in step 504.

[0035] In step 506A (an alternative to 506B), once a fault is detected in F1-U, DU sends an F1AP broadcast transmission resource request message to the gNB-CU CP with which it previously established the tunnel.

[0036] In another embodiment, as indicated by reference numeral 506B, once an F1-U failure is detected, the DU sends an F1AP broadcast context notification indication message to the gNB-CU CP with which it previously established the tunnel.

[0037] In an embodiment, the message (the message from step 506A or step 506B, or some other message) includes an explicit F1-U fault indicator that indicates a link failure. The fault indicator can be an explicit indicator, such as bits reserved for indicating a fault.

[0038] In an embodiment, the message (the message of step 506A or step 506B, or some other message) includes an action indicator that indicates whether the receiving CU CP should attempt to restore the F1U tunnel itself or should not attempt it (e.g., because the gNB-DU intends to use another F1-U tunnel with the CU UP of another PLMN). That is, the DU can generate information elements (i.e., the action indicator) indicating whether the CP entity should attempt to restore the failed link between the DU and the CU UP. The DU can subsequently include the information elements in the message. Figure 4The action in step 402 can be based, for example, on an action indicator (or on the absence of the action indicator).

[0039] In the event that the action indicator indicates an attempt to restore the link or as a default action based on a message received from the gNB-DU (the message in step 506A or step 506B or some other message) (see Case 1 in the figure), the CU CP may decide in step 508 to restore the F1-U tunnel between these entities, for example, by replacing the old faulty link with a new link between the DU and the CU UP.

[0040] The recovery may include, for example, in step 510, the CU CP sending a request to the CU UP, such as an E1AP BC bearer context modification request message. This message includes a request for the CU UP to allocate F1-U TNL information at the CU (i.e., the UL transport network layer address at the CU UP). This new tunnel information may be associated with all relevant MRBs affected by the failed link.

[0041] In step 512, upon receiving the request message, CU UP allocates F1-U TNL information (i.e., the UL transport network layer address at CU UP) to all relevant MRBIDs according to the request of CU CP. CU UP then sends the allocated TNL address to CU CP.

[0042] Upon receiving a response (such as an E1AP BC bearer context modification request message) containing the F1-U TNL information assigned by the CU UP in step 512 from the CU UP, the CU CP triggers a modification process (such as an F1 broadcast context modification process) to update the gNB-DU with the newly assigned F1-U TNL information for the relevant MRB at the CU UP. This process may include sending an F1 broadcast context modification request to the DU containing the new tunnel information. The DU then receives the new TNL address and can use it for a new link with the UP entity to replace a failed link. The DU may respond to the request to the CU CP.

[0043] In this way, Case 1 provides CU CP with an efficient means of restoring (e.g., establishing) the link between DU and CU UP.

[0044] Figure 5 Case 2 involves a situation where the action indicator indicates that the link is not restored, or a situation where the action indicator is not included in the message of step 506A or step 506B, or Case 2 may be the default action of CU CP when it receives the message of step 506A or step 506B.

[0045] Scenario 2 includes a scenario where, in step 516, the CU CP decides not to attempt to restore the F1-U tunnel (i.e., not to attempt to replace the old tunnel with the new one). In step 518, the CU CP then sends a notification (such as an E1AP BC bearer context modification request message) to the CU UP, which includes an indication that the F1-U tunnel (also referred to as a link) has failed and / or is no longer in use. For example, the CU CP may send a “Shared F1-U not established / not used” or “F1-U failed” indicator to the relevant CU UP to notify the CU UP that the F1U tunnel is no longer in use (e.g., in cases where the action indicator does not request context restoration). In an embodiment, the CU UP may then request the establishment of a new link to replace the failed link on its own.

[0046] In an embodiment, the DU may decide to use another existing link to transmit data that would otherwise be transmitted via the failed link, which is the link between the DU and the CU UP of another base station. This can be an advantageous option when such an alternative link exists and data (e.g., MRB) can be transmitted via another BS (e.g., in the case of RAN sharing).

[0047] In an embodiment, the DU may request the establishment of a new link to replace the faulty link, which is directed toward the CU UP where the previous link failed or toward the CU UP of another base station (e.g., in the case of RAN sharing).

[0048] In one embodiment, the DU generates a second information element indicating the cause of the link failure. The DU may then include the second information element in a message (the message of step 506A or step 506B).

[0049] As mentioned above, Figure 5 The illustration shows a scenario where a fault indication from step 506A or 506B is sent to the CU CP of the same CU where the link failure occurred. However, the DU can advantageously send this indication to the CU CP of another base station (i.e., another PLMN / RAN) in some scenarios. The other base station could be, for example, Figure 1 gNB 112. For example, in the case of RAN sharing (where DU is shared between different PMLM / RAN / CU), it is possible to send to another base station.

[0050] Figure 6 A signaling flowchart of an embodiment of a DU notifying another BS of a CU CP is shown. Figure 6 Steps 500-504 and Figure 5 same.

[0051] exist Figure 6In step 600, once an F1-U failure is detected with CU UP1 (CU UP 204 in the figure), the gNB-DU decides to request a different CU CP #2 of the shared PLMN #2 to establish an alternative F1-U tunnel via CU UP #2 (of PLMN #2). The gNB-DU may send, for example, an F1AP broadcast transmission resource request message to the gNB-CU CP #2. This message may optionally include an explicit F1-U failure indicator. The failure indicator may be an explicit indicator, such as bits reserved for indicating a failure.

[0052] In step 602, upon receiving the fault notification message from gNB-DU in step 600, CU CP #2 sends a request message to CU UP #2, such as an E1AP BC bearer context modification request message. This message may include a request for CU UP #2 to allocate F1-U TNL information (UL transport network layer address at CU UP #2) at CU #2. This request may be related to all relevant MRB IDs.

[0053] In step 604, CU UP #2 allocates new tunnel information according to the request and sends a response to CU CP #2, which includes the new tunnel information.

[0054] Subsequently, upon receiving a response (such as an E1AP BC bearer context modification response message) containing F1-U TNL information allocated by CU UP #2 from CU UP #2, CU CP #2 triggers a modification process (such as F1 broadcast context modification request 606) to update gNB-DU with the newly allocated F1-U TNL information for the relevant MRB at CU #2. In this way, DU and CU #2 (more specifically CU UP #2) can begin communication based on the newly allocated F1-U tunnel information.

[0055] Figures 3 to 6 This section focuses on embodiments of fault detection and follow-up notification for DUs (e.g., DU 206). Now, embodiments of fault detection and follow-up notification for CU UPs are described.

[0056] Figure 7 This shows, for example, that can be generated by CU UP (such as Figure 2 The example method executed by CU UP 204. This method can be implemented by a computer. Figure 7As shown, in step 700, the CU UP can detect a fault in the link between the DU (such as DU 206) and the CU UP of the base station (such as gNB 110). The CU UP can detect faults in various ways, such as using test signals or detecting a lack of response / message on the link. In step 702, the CU UP can generate a message based on the detected fault, indicating the fault. There are several options regarding the content of the message, as will be described below. In step 704, the CU UP can send the message to a control plane (CP) entity, such as CU CP 202.

[0057] From the message recipient's perspective, Figure 8 It shows that it can be generated by CU CP (such as Figure 2 Example method executed by CU CP 202. This method can be implemented by a computer. Figure 8 As shown, in step 800, the CU CP can receive a message from CU UP 204 of gNB 110 indicating a failure of the link between the DU and the CU UP. In step 802, the CU CP then determines whether to trigger the establishment of a new link for the CU UP or to notify the DU of the failed link. Triggering this notification can be an advantageous option, allowing communication to continue more smoothly. However, this is not always a viable option, and other notification options may be appropriate. It should be noted that under this option, communication can similarly continue at a later point in time, as the DU may subsequently trigger a process to restore the MBS session.

[0058] From DU's perspective, Figure 9 It shows that it can be generated by DU (such as Figure 2 An example method performed by DU 206. This method can be implemented by a computer. This embodiment provides: In step 900, the DU receives an indication of a link failure between the DU and the CU UP. In step 902, the DU requests the establishment of a new link to replace the failed link, the new link being directed toward the CU UP or toward the CU UP of another base station.

[0059] The following is combined with Figure 10 and Figure 11 These embodiments are described in more detail with signaling flowcharts.

[0060] exist Figure 10 In step 1000, there is an ongoing MBS broadcast session being transmitted over N3mb and F1U. For simplicity, the MB-UPF entity of the PLMN through which the MBS session is taking place is not shown in the diagram. DU and CU-UP also belong to the same PLMN. CU UP may have previously established a link between DU and CU UP together with CU CP.

[0061] In steps 1002-1004, the CU UP detects an F1U failure. The F1U path was previously established by the CU CP. To detect a link failure, the CU UP may, for example, generate one or more echo request messages 1002 on the F1U path. Once no response to the echo request is detected from the DU, the CU UP detects a link failure in step 1004.

[0062] In step 1006, once an F1-U fault is detected, the CU UP generates a message indicating the fault and sends it to the CU CP. For example, the CU UP sends an E1 BC bearer context modification request message. In this embodiment, the message includes new F1-U TNL information at the CU (e.g., the UL transport network layer address at the CU UP), possibly for all relevant MRB IDs. That is, the CU UP (once the fault is detected in step 1004) can generate a TNL address for the new link between the DU and the CU UP and include that TNL address in the message of step 1006.

[0063] In an embodiment, the message in step 1006 also includes a fault indication indicating a link failure. This fault indication can be an explicit indication, such as bits reserved for indicating a fault.

[0064] In an embodiment, CU UP generates a second information element indicating the cause of the fault and includes the second information element in the message of step 1006.

[0065] The CU CP receives the message and determines whether to trigger the establishment of a new link for the CU UP (i.e., the link between the CU UP and the DU) or to notify the DU of the failed link. Upon receiving the message including F1-U TNL information, the CU CP triggers a modification process (such as an F1 broadcast context modification process) in step 1008 to update the DU with the newly assigned F1-U TNL information. This process may include a request and a corresponding response from the DU. Therefore, triggering the establishment of a new link for the CU UP involves sending the TNL address to the DU.

[0066] Figure 11 Another embodiment related to CU UP detection and notification is shown. Figure 11 Steps 1000-1004 and Figure 10 same.

[0067] In step 1100, once a fault is detected in F1-U, CU UP generates and sends a message indicating the fault to CU CP. However, in Figure 11In this embodiment, the message (e.g., an E1 BC bearer context modification request message or any other E1AP (also known as E1) message) does not include new TNL information, but instead includes fault indicators (such as explicit indications of faults).

[0068] In step 1102, upon receiving a message indicating an F1U fault, the CU CP sends a request to the CU UP to allocate new F1-U tunnel information (e.g., the UL transport network layer address at the CU UP) for all involved MRB IDs. This request may be, for example, an E1 BC bearer context modification request message.

[0069] Step 1104 includes the CU UP (upon request) allocating new F1-U tunnel information and responding to the CU CP, the response including the allocated F1-U link information. This response may be an E1AP BC bearer context modification response message containing F1-U TNL information.

[0070] In step 1106, the CU CP has received a response from the CU UP, and the CU CP triggers a modification process, for example by sending an F1 broadcast context modification request to the DU to update the DU with the newly assigned F1-U TNL information (e.g., TNL address) for the relevant MRB at the CU. The DU responds to the request with an acknowledgment.

[0071] Figure 12 Another embodiment related to CU UP detection and notification is shown. Figure 12 Steps 1000-1004 and step 1100 are related to Figure 11 same.

[0072] exist Figure 12 In step 1200, once a fault indication is received (e.g., an E1 BC bearer context modification request message or any other E1AP message indicating a fault), the CU CP sends a notification to the DU (e.g., an F1 notification indication) containing an indication that the F1-U has failed or is no longer working.

[0073] In step 1202, the DU can then, for example, request the establishment of a new F1-U link to replace the failed link. In an embodiment, the new link is directed toward the CU UP corresponding to the previously active (now failed) link. In this case, it can be done as follows: Figure 5 The request is executed as proposed (see, for example, steps 506A / 506B-514). In another embodiment, the establishment of the new link is directed toward the UP entity of the CU of another base station (e.g., in the case of RAN sharing). In this case, it can be done as follows Figure 6 The request is executed as proposed (see, for example, steps 600-606).

[0074] As illustrated in the above embodiments, an efficient process for detecting F1-U faults is proposed. Furthermore, due to the presented embodiments, an efficient method for re-establishing links to replace faulty links is proposed. This contributes to, for example, communication throughput. Some of the above embodiments are particularly beneficial for RAN-shared scenarios.

[0075] It should be noted that when the DU sends a message indicating a link failure to another PLMN, the receiving CU CP may not yet have any ongoing F1-U links. Therefore, a request from the DU to establish a link can be regarded as a new request to establish a link.

[0076] However, if the DU is not in a multi-cell ID situation (e.g., in a non-RAN shared (or MOCN RAN shared) situation), the DU cannot establish a new F1U towards CU CP 2 or CU CP 3, and the DU has no other method than to obtain a new F1-U establishment from CU CP 1 with which the DU previously established a connection. If the DU (or CU UP) sends a fault indication message to the CU CP of the same PLMN (i.e., the same CU CP of PLMN1 with which the previously failed link was established), the CU CP can treat such a request as an error message, or at least as an anomalous situation of receiving another request to establish an F1-U. It is unclear what type of message / notification the DU (or CU UP) should send to the CU CP in such an anomalous situation. As explained in the above embodiments, one option is to reuse the F1AP broadcast transmission of the establishment request message to replace the link that failed due to the fault. This message may include a new indicator to notify the receiving CU CP that the request is not an error but due to a failure of the original F1-U (e.g., an explicit fault indication as presented in some of the above embodiments). As an alternative, the detection unit can use the newly introduced F1AP broadcast context notification indication, where the DU triggers a new procedure including an IE to notify the F1U of a fault. The CU CP can then trigger an F1AP broadcast context modification request message to update the UL address. Alternatively, as previously disclosed, the DU can decide not to react to the echo response. Instead, the DU can decide to rely on the CU UP to detect the F1U fault, since the CU UP also sends an echo request message. When the CU UP detects an F1U fault, it sends an E1 notification to the CU CP to report the F1U fault, such as sending an E1 BC bearer context modification request. The CU UP can include the necessary UL TEID in this message, allowing the CU CP to directly send an F1AP broadcast context modification request to the gNB-DU, including the new F1-U TNL information at the CU.

[0077] It should also be noted that the above embodiments do not rely on or use queries to confirm the current state with the CU CP, as this would reduce the efficiency of the proposed process. Furthermore, to avoid impacting efficiency, the embodiments do not rely on or apply migrating the context to another cluster via E1. That is, the (E1AP modification process) uses the same CU UP, as the CU UP may already have the required context.

[0078] It should be noted that the names of messages / signaling between different entities in the above embodiments are given only as examples, and other messages / signaling that transmit the required information are also applicable to the implementation embodiments.

[0079] like Figure 13 As shown, an embodiment provides an apparatus 10 including a control circuitry (CTRL) 12 (such as at least one processor) and at least one memory 14 storing instructions that, when executed by the at least one processor, cause the apparatus to perform at least one of the processes described above. In the example, at least one memory and computer program code (software) are configured with at least one processor to cause the apparatus to perform any of the processes described above. The control circuitry 12 may include associated circuitry(s) for performing functions according to any embodiment.

[0080] Memory can be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic storage devices and systems, optical storage devices and systems, fixed memory, and removable memory. Memory may include databases for storing data.

[0081] In embodiments, device 10 is a DU (such as DU 206) or is included within a DU. This device can be made to perform some functions of the processes described above, such as... Figure 3 or Figure 9 The steps.

[0082] In another embodiment, device 10 is a CU UP (such as CU UP 204) or is included in a CU UP. This device can be made to perform some of the functions described above, such as... Figure 7 The steps.

[0083] In another embodiment, device 10 is a CU CP (such as CU CP 202) or is included in a CU CP. This device can be made to perform some of the functions described above, such as... Figure 4 or Figure 8 The steps.

[0084] The device may also include a radio interface (TRX) 16, which includes hardware and / or software for establishing a communication connection according to one or more communication protocols. The TRX, for example, can provide the device with the ability to communicate with user equipment and / or other entities at the base station.

[0085] The device may also include a user interface 18, which includes, for example, at least one keyboard, microphone, touch display, display, speaker, etc. The user interface can be used by a user to control the device.

[0086] As used in this application, the term "circuit" refers to all of the following: (a) a circuit implementation that is purely hardware, such as an implementation in analog and / or digital circuits only; and (b) a combination of circuits and software (and / or firmware), such as (as the case may be): (i) a combination of (one or more) processors, or (ii) a portion of (one or more) processors / software, including (one or more) digital signal processors, software, and (one or more) memories, which work together to enable a device to perform various functions; and (c) a circuit that requires software or firmware to operate, such as (one or more) microprocessors or portions thereof, even if the software or firmware is not physically present. This definition of the term "circuit" applies to all uses of the term in this application. As a further example, as used in this application, the term "circuit" will also cover an implementation of a processor (or processors) or a portion thereof and its associated software and / or firmware. For example, and if applicable to a particular element, the term "circuit" will also cover a baseband integrated circuit or an application processor integrated circuit for a mobile phone, or a similar integrated circuit in a server, cellular network device, or other network device.

[0087] In the embodiments, at least some of the described processes can be performed by means including corresponding components for performing the at least some of the described processes. Some example components for performing these processes may include at least one of the following: a detector, a processor (including dual-core and multi-core processors), a digital signal processor, a controller, a receiver, a transmitter, an encoder, a decoder, a memory, RAM, ROM, software, firmware, a display, a user interface, display circuitry, user interface circuitry, user interface software, display software, circuitry, an antenna, antenna circuitry, and a circuit system.

[0088] The term “non-transient” as used in this article refers to the limitation on the medium itself (i.e., tangible, not signaling), rather than the limitation on the persistence of data storage (e.g., RAM versus ROM).

[0089] In this document, the term "means" should be interpreted in the singular, referring to a single element, or in the plural, referring to a combination of multiple single elements. Therefore, the term "means for [performing A, B, C]" should be interpreted to cover an apparatus in which there is only one mean for performing A, B, and C, or there are separate means for performing A, B, and C, or there are partially overlapping or completely overlapping means for performing A, B, and C. Furthermore, the terms "means for performing A, means for performing B, means for performing C" should be interpreted to cover an apparatus in which there is only one mean for performing A, B, and C, or there are separate means for performing A, B, and C, or there are partially overlapping or completely overlapping means for performing A, B, and C.

[0090] The techniques and methods described herein can be implemented by various means. For example, these techniques can be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or a combination thereof. For hardware implementation, the means(s) of the embodiments can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, it can be implemented by modules (e.g., procedures, functions, etc.) of at least one chipset that perform the functions described herein. Software code can be stored in memory cells and executed by a processor. Memory cells can be implemented inside or outside the processor. In the latter case, the memory cells can be communicatively coupled to the processor via various means known in the art. Furthermore, the components of the systems described herein can be rearranged and / or supplemented by additional components to facilitate the implementation of various aspects associated therewith, and as those skilled in the art will understand, they are not limited to the precise configurations illustrated in the given figures.

[0091] The described embodiments can also be performed as a computer process defined by a computer program or parts thereof. Embodiments of the described methods can be performed by executing at least a portion of a computer program including corresponding instructions. The computer program can be in source code form, object code form, or some intermediate form, and can be stored on some medium, which can be any entity or device capable of carrying the program. For example, the computer program can be stored on a computer or processor-readable computer program distribution medium. The computer program medium can be, for example, but not limited to, recording media, computer memory, read-only memory, electrical carrier signals, telecommunication signals, and software distribution packages. The computer program medium can be a non-transitory medium. The coding of the software used to perform the illustrated and described embodiments is within the capabilities of those skilled in the art.

[0092] The following is a list of some aspects related to the first set of embodiments.

[0093] According to a first aspect, a method is provided performed by a distributed unit (DU) of a base station, the method comprising: detecting a fault in a link between the DU and a user plane (UP) entity of a central unit (CU) of the base station; generating a message based on the detected fault, the message indicating the fault; and sending the message to a control plane (CP) entity.

[0094] Various embodiments of the first aspect may include at least one feature from the following list: The message in question is an F1AP broadcast transmission resource request message.

[0095] The message in question is an F1AP notification message.

[0096] The fault indication is sent to the CP entity of the CU of the base station.

[0097] Among them, the fault indication is sent to the CP entity of the CU of another base station.

[0098] The message includes a fault indication indicating the fault in the link.

[0099] Generate an information element indicating whether the CP entity should attempt to restore the faulty link between the DU and UP entities; and include the information element in the message.

[0100] Receive the new Transport Network Layer (TNL) address; and apply the new TNL address to the new link with the UP entity to replace the faulty link.

[0101] A request is made to establish a new link to replace the faulty link, the new link being directed toward the UP entity of the CU of the base station, or toward the UP entity of the CU of another base station.

[0102] Generate a second information element indicating the cause of the fault; and include the second information element in the message.

[0103] The faulty link between the CU and the DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

[0104] According to a second aspect, a method is provided performed by a control plane (CP) entity of a central unit (CU) of a base station, the method comprising: receiving from a distributed unit (DU) of the base station a message indicating a failure of a link between the DU and a user plane (UP) entity; and determining whether to trigger the establishment of a new link for the DU or to notify the UP entity of the failed link.

[0105] Various embodiments of the second aspect may include at least one feature from the following list: The message in question is an F1AP broadcast transmission resource request message.

[0106] The message in question is an F1AP notification message.

[0107] The faulty link is between the DU and the UP entity of the CU of the base station.

[0108] The faulty link is between the DU and the UP entity of the CU of another base station.

[0109] The message includes a fault indication indicating the fault in the link.

[0110] The message includes an information element instructing the CP entity whether it should attempt to restore the faulty link between the DU and UP entities, and the determination of whether to trigger or notify is based on the information element.

[0111] The triggering includes: requesting the UP entity to allocate a transport network layer (TNL) address for the new link, receiving information indicating the TNL address from the UP entity, and sending the TNL address to the DU.

[0112] Wherein, at least one of the following conditions is met: the request is sent in an E1AP BC bearer context modification request message, the information is received in an E1AP BC bearer context modification response message, or the TNL address is sent to the DU in an F1 broadcast bearer context modification request message.

[0113] Notifying the UP entity of a faulty link includes sending an E1AP BC bearer context modification request, wherein the E1AP BC bearer context modification request includes an indication that the existing link between the UP entity and the DU is not in use or is no longer in use.

[0114] The faulty link between CU and DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

[0115] According to a third aspect, a distributed unit (DU) for a base station is provided, the DU comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the DU to at least: detect a fault in a link between the DU and a user plane (UP) entity of a central unit (CU) of the base station; generate a message based on the detected fault, the message indicating the fault; and send the message to a control plane (CP) entity. Various embodiments of the third aspect may include at least one feature from the list under the first aspect.

[0116] According to a fourth aspect, a control plane (CP) entity for a central unit (CU) of a base station is provided, the CP entity comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the CP entity to at least: receive from the distributed unit (DU) of the base station a message indicating a link failure between the DU and a user plane (UP) entity; and determine whether to trigger the establishment of a new link for the DU or to notify the UP entity of the failed link. Various embodiments of the fourth aspect may include at least one feature from the list under the second aspect.

[0117] According to a fifth aspect, a computer program product implemented on a distribution medium is provided, including program instructions that, when executed by a device, cause the device to perform the method according to the first aspect.

[0118] According to a sixth aspect, a computer program product implemented on a distribution medium is provided, including program instructions that, when executed by a device, cause the device to perform the method according to the second aspect.

[0119] According to a seventh aspect, a computer program product is provided, including program instructions that, when executed by a device, cause the device to perform the method according to the first aspect.

[0120] According to the eighth aspect, a computer program product is provided, including program instructions that, when executed by a device, cause the device to perform the method according to the second aspect.

[0121] According to a ninth aspect, an apparatus is provided, including components for performing the method according to a first aspect, and / or components configured to cause the apparatus to perform the method according to a first aspect.

[0122] According to a tenth aspect, an apparatus is provided, including components for performing the method according to a second aspect, and / or components configured to cause the apparatus to perform the method according to a second aspect.

[0123] The following is a list of some aspects related to the second set of embodiments.

[0124] According to the eleventh aspect, a method is provided performed by a user plane (UP) entity of a central unit (CU) of a base station, the method comprising: detecting a fault in a link between a distributed unit (DU) of the base station and the UP entity; generating a message based on the detected fault, the message indicating the fault; and sending the message to a control plane (CP) entity of the CU.

[0125] Various embodiments of the eleventh aspect may include at least one feature from the following list: The message in question is an E1AP broadcast bearer context modification request message.

[0126] The message includes a fault indication indicating the fault in the link.

[0127] Assign a Transport Network Layer (TNL) address to the new link between the DU and UP entities; and include that TNL address in the message.

[0128] The CP entity of the CU receives a request to allocate a Transport Network Layer (TNL) address for a new link between the DU and UP entities; allocates a TNL address for the new link; and sends an indication of the TNL address to the CP entity of the CU.

[0129] Generate a second information element indicating the cause of the fault; and include the second information element in the message.

[0130] The faulty link between CU and DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

[0131] According to a twelfth aspect, a method is provided performed by a control plane (CP) entity of a central unit (CU) of a base station, the method comprising: receiving from a user plane (UP) entity of the CU a message indicating a link failure between a distributed unit (DU) of the base station and the UP entity; determining whether to trigger the establishment of a new link for the DU or to notify the DU of the failed link. Various embodiments of the twelfth aspect may include at least one feature from the following list: The message includes a fault indication indicating the fault in the link.

[0132] The message includes a Transport Network Layer (TNL) address for a new link between the DU and UP entities, and the trigger sends the TNL address to the DU.

[0133] The triggering includes: requesting the UP entity to allocate a transport network layer (TNL) address for the new link, receiving information indicating the TNL address from the UP entity, and sending the TNL address to the DU.

[0134] Wherein, at least one of the following conditions is met: the request is sent in an E1AP BC bearer context modification request message, the information is received in an E1AP BC bearer context modification response message, or the TNL address is sent to the DU in an F1 broadcast bearer context modification request message.

[0135] The faulty link between CU and DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

[0136] According to a thirteenth aspect, a method is provided performed by a distributed unit (DU) of a base station, the method comprising: receiving from a central unit (CU) of the base station a fault indication of a link between the DU and a user plane (UP) entity of the CU; requesting the establishment of a new link to replace the faulty link, the new link being directed toward the UP entity of the CU or toward the UP entity of a CU of another base station. Various embodiments of the thirteenth aspect may include at least one feature from the following list: The fault indication is received from the control plane (CP) of the central unit of the base station.

[0137] The faulty link between CU and DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

[0138] According to the fourteenth aspect, a user plane (UP) entity of a central unit (CU) of a base station is provided, the UP entity comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the UP entity to at least: detect a fault in a link between the distributed unit (DU) of the base station and the UP entity; generate a message based on the detected fault, the message indicating the fault; and send the message to a control plane (CP) entity of the CU. Various embodiments of the fourteenth aspect may include at least one feature listed under the eleventh aspect.

[0139] According to the fifteenth aspect, a control plane (CP) entity for a central unit (CU) of a base station is provided, the CP entity comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the CP entity to at least: receive from a user plane (UP) entity of the CU a message indicating a link failure between a distributed unit (DU) of the base station and the UP entity; and determine whether to trigger the establishment of a new link for the DU or to notify the DU of the failed link. Various embodiments of the fourth aspect may include at least one feature listed under the twelfth aspect.

[0140] According to the sixteenth aspect, a distributed unit (DU) for a base station is provided, the DU comprising: at least one processor; and at least one memory storing instructions that, when executed by the at least one processor, cause the DU to at least: receive from the central unit (CU) of the base station a fault indication of a link between the DU and a user plane (UP) entity of the CU; and request the establishment of a new link to replace the faulty link, the new link being directed toward the UP entity of the CU or toward the UP entity of a CU of another base station. Various embodiments of the fourth aspect may include at least one feature listed under the thirteenth aspect.

[0141] According to the seventeenth aspect, a computer program product implemented on a distribution medium is provided, including program instructions that, when executed by a device, cause the device to perform the method according to the eleventh, twelfth, or thirteenth aspects.

[0142] According to the eighteenth aspect, a computer program product is provided, including program instructions that, when executed by a device, cause the device to perform the method according to the eleventh, twelfth, or thirteenth aspect.

[0143] According to the nineteenth aspect, an apparatus is provided, including components for performing the method according to the eleventh, twelfth, or thirteenth aspects, and / or components configured to cause the apparatus to perform the method according to the eleventh, twelfth, or thirteenth aspects.

[0144] Although the invention has been described above with reference to examples in the accompanying drawings, it is clear that the invention is not limited thereto, but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly, and are intended to illustrate rather than limit the embodiments. It will be apparent to those skilled in the art that the concepts of the invention can be implemented in various ways as technology has evolved. Furthermore, it will be clear to those skilled in the art that the described embodiments can, but must not, be combined with other embodiments in various ways.

Claims

1. A distributed unit (DU) for a base station, the DU comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the DU to at least execute: Detect faults in the link between the DU and the user plane (UP) entity of the central unit (CU) of the base station; A message is generated based on the detected fault, and the message indicates the fault; as well as Send the message to the control plane (CP) entity.

2. The DU according to claim 1, wherein, The message is an F1AP broadcast transmission resource request message.

3. The DU according to claim 1, wherein, The message is an F1AP notification message.

4. The DU according to any one of claims 1 to 3, wherein, The fault indication is sent to the CP entity of the CU of the base station.

5. The DU according to any one of claims 1 to 3, wherein, The fault indication is sent to the CP entity of the CU of another base station.

6. The DU according to any one of claims 1 to 5, wherein, The message includes a fault indication indicating the fault in the link.

7. The DU according to any one of claims 1 to 6, wherein, When the instruction is executed by the at least one processor, it also causes the DU to execute: Generate information elements indicating whether the CP entity should attempt to restore the faulty link between the DU and UP entities; and The information elements are included in the message.

8. The DU according to any one of claims 1 to 7, wherein, When the instruction is executed by the at least one processor, it also causes the DU to execute: Receive the new Transport Network Layer (TNL) address; and Apply the new TNL address to the new link with the UP entity to replace the faulty link.

9. The DU according to any one of claims 1 to 8, wherein, When the instruction is executed by the at least one processor, it also causes the DU to execute: A request is made to establish a new link to replace the faulty link, the new link being directed toward the UP entity of the CU of the base station, or toward the UP entity of the CU of another base station.

10. The DU according to any one of claims 1 to 9, wherein, When the instruction is executed by the at least one processor, it also causes the DU to execute: Generate a second information element indicating the cause of the fault; and Include the second information element in the message.

11. The DU according to any one of claims 1 to 10, wherein, The faulty link between the CU and the DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

12. A control plane (CP) entity for a central unit (CU) of a base station, the CP entity comprising: At least one processor; as well as At least one memory storing instructions that, when executed by the at least one processor, cause the CP entity to perform at least the following: Receive a message from the distributed unit (DU) of the base station indicating a link failure between the DU and the user plane (UP) entity; and Determine whether to trigger the establishment of a new link for the DU or to notify the UP entity of the faulty link.

13. The CP entity according to claim 12, wherein, The message is an F1AP broadcast transmission resource request message.

14. The CP entity according to claim 12, wherein, The message is an F1AP notification message.

15. The CP entity according to any one of claims 12 to 14, wherein, The faulty link is between the DU and the UP entity of the CU of the base station.

16. The CP entity according to any one of claims 12 to 14, wherein, The faulty link is between the DU and the UP entity of the CU of another base station.

17. The CP entity according to any one of claims 12 to 16, wherein, The message includes a fault indication indicating the fault in the link.

18. The CP entity according to any one of claims 12 to 17, wherein, The message includes information elements instructing the CP entity whether it should attempt to restore the faulty link between the DU and UP entities, and wherein the determination of whether to trigger or notify is based on the information elements.

19. The CP entity according to any one of claims 12 to 18, wherein, The triggering includes: requesting the UP entity to allocate a transport network layer (TNL) address for the new link, receiving information indicating the TNL address from the UP entity, and sending the TNL address to the DU.

20. The CP entity according to claim 19, wherein, The following conditions must be met: the request is sent in an E1AP BC bearer context modification request message, the information is received in an E1AP BC bearer context modification response message, or the TNL address is sent to the DU in an F1 broadcast bearer context modification request message.

21. The CP entity according to any one of claims 12 to 18, wherein, Notifying the UP entity of a faulty link includes sending an E1AP BC bearer context modification request, the E1AP BC bearer context modification request including an indication that the existing link between the UP entity and the DU is not in use or is no longer in use.

22. The CP entity according to any one of claims 12 to 21, wherein, The faulty link between the CU and DU is associated with the MBS radio bearer (MRB) of the MBS (Multicast Broadcast Service) session.

23. A method performed by a distributed unit (DU) of a base station, the method comprising: Detect faults in the link between the DU and the user plane (UP) entity of the central unit (CU) of the base station; A message is generated based on the detected fault, indicating the fault; as well as Send the message to the control plane (CP) entity.

24. A method performed by a control plane (CP) entity of a central unit (CU) of a base station, the method comprising: Receive a message from the distributed unit (DU) of the base station indicating a link failure between the DU and the user plane (UP) entity; as well as Determine whether to trigger the establishment of a new link for the DU or to notify the UP entity of the faulty link.

25. A computer program product implemented on a computer-readable distribution medium, comprising program instructions that, when executed by a device, cause the device to perform the method according to claim 23 or 24.

26. A computer program product comprising program instructions that, when executed by a device, cause the device to perform the method according to claim 23 or 24.

27. An apparatus comprising components for performing the method according to claim 23 or 24.

Images