Detection of link failure between CU and du

Abstract

There is provided a method performed by a distributed unit (DU) of a base station, the method comprising: detecting a failure 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 failure, the message being indicative of the failure; and sending the message to a control plane (CP) entity.

Description

[0001] DETECTION OF LINK FAILURE BETWEEN CU AND DU

[0002] TECHNICAL FIELD

[0003] Various example embodiments relate generally to detection of a link failure.

[0004] BACKGROUND

[0005] It may happen that a communication link between fails. It is then important to detect and report such failure early and efficiently.

[0006] BRIEF DESCRIPTION

[0007] According to some aspects, there is provided the subject matter of the independent claims. Some further aspects are defined in the dependent claims. The embodiments that do not fall under the scope of the claims are to be interpreted as examples useful for understanding the disclosure.

[0008] LIST OF THE DRAWINGS

[0009] In the following, the invention will be described in greater detail with reference to the embodiments and the accompanying drawings, in which

[0010] Figures 1 and 2 present network examples to which one or more embodiments are applicable;

[0011] Figures 3 and 4 show methods according to some embodiments;

[0012] Figures 5 and 6 show signaling flow diagrams according to some embodiments;

[0013] Figures 7, 8 and 9 show methods according to some embodiments;

[0014] Figures 10, 11 and 12 show signaling flow diagrams according to some embodiments;

[0015] Figure 13 illustrates an apparatus, according to some embodiments.

[0016] DESCRIPTION OF EMBODIMENTS

[0017] The following embodiments are exemplary. Although the specification may refer to “an”, “one”, or “some” embodiment's] in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment's], or that a particular feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments. Further, when a particular feature, structure, or characteristic is described in connection of an embodiment, it is within the knowledge of one skilled in the art to apply such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described. It shall be understood that although the terms “first,” “second” and the like may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another.

[0018] For the purposes of the present disclosure, the phrases “at least one of A or B”, “at least one of A and B”, and “A and / or B” means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase “A, B, and / or C” means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C).

[0019] Embodiments described may be implemented in a communication network, such as any of the following radio access technologies (RATs): Worldwide Interoperability for Micro-wave Access (WiMAX), Global System for Mobile communications (GSM, 2G), GSM EDGE radio access Network (GERAN), General Packet Radio Service (GRPS), Universal Mobile Telecommunication 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 called NR), or any future RAT such as 6G. Moreover, communication within the communication network may utilize any proper wireless communication technology, comprising 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 (M1M0), Orthogonal Frequency Division Multiple (OFDM), and / or Discrete Fourier Transform spread OFDM (DFT-s-OFDM).

[0020] As used herein, the term “network device” or “network node” refers to a node in a communication network via which user equipment may access the network and / or which is capable of controlling radio communication and managing radio resources within a cell. The network node or network device may be referred to as a base station (BS), an access point (AP) or an access node. The network device may be, depending on the applied technology, for example, a node B (NodeB or NB), an evolved NodeB (eNodeB or eNB), an NR NB (also referred to as a gNB), a Remote Radio Unit (RRU), a radio head (RH), a remote radio head (RRH), a relay, an Integrated Access and Backhaul (1AB) node, a low power node, a non-terrestrial network (NTN) or non-ground network device such as a satellite network device, a low earth orbit (LEO) satellite and a geosynchronous earth orbit (GEO) satellite, or an aircraft network device.

[0021] Moreover, in connection of split radio access network (RAN), the network device may refer to a centralised unit (CU) of a base station and / or a distributed unit (DU) of a base station. An interface between CU and DU may be referred to as an Fl interface in NR. In the split RAN architecture, node operations may be carried out, at least partly, in the central / centralized unit, CU, (e.g. server, host or node) operationally coupled to the DU, (e.g. a radio head / node). One CU may control one or more DUs, acting at least as transmit / receive (Tx / Rx) nodes. In some embodiments, the DUs may comprise e.g. a radio link control (RLC), medium access control (MAC) layer and a physical (PHY) layer, whereas the CU may comprise the layers above RLC layer, such as a packet data convergence protocol (PDCP) layer, a radio resource control (RRC) and an internet protocol (IP) layers. Other functional splits are possible too. In practice, any processing task may be performed in either the CU or the DU and the boundary where the responsibility is shifted between the CU and the DU may depend on the applied implementation.

[0022] The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example, a terminal device may be referred to as a communication device, user equipment (UE), a Subscriber Station (SS), or a Mobile Station (MS). The terminal device may include a mobile phone, a cellular phone, a smart phone, voice over IP (VoIP) phones, wireless local loop phones a tablet, a wearable terminal device, a personal digital assistant (PDA), portable computers, desktop computer, image capture terminal devices such as digital cameras, gaming terminal devices, music storage and playback appliances, vehicle-mounted wireless terminal devices, USB dongles, an Internet of Things (loT) device, a watch or other wearable, a head-mounted display (HMD), a vehicle, a drone, a medical device and applications (e.g., remote surgery), an industrial device and applications (e.g., a robot and / or other wireless devices operating in an industrial and / or an automated processing chain contexts), a consumer electronics device, a device operating on commercial and / or industrial wireless networks, and the like.

[0023] A term “resource”, as used herein, may refer to radio resources in time domain, in frequency domain, in space domain, and / or in code domain. Some examples of resources include e.g. a physical resource block (PRB), a radio frame, a subframe, a time slot, a subband, a frequency region, a sub-carrier, a beam, etc. The term “transmission” and / or “reception” may refer to wirelessly transmitting and / or receiving via a wireless propagation channel on radio resources.

[0024] Figure 1 illustrates an example of a communication network to which examples disclosed herein may be applied. The communication network or a cellular communication network may comprise 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, e.g., a macro cell, a micro cell, femto, or a pico cell, for example. The cell may define a coverage area or a service area of the corresponding access node.

[0025] The network node 110 may provide a user equipment (UE) 120 (one or more UEs) with wireless access to the communication network. The wireless access may comprise downlink (DL) communication from the network node to the UE 120 and uplink (UL) communication from the UE 120 to the network node. Examples of uplink channels comprise physical uplink control channel (PUCCH) for transmitting control information and physical uplink shared channel (PUSCH) for transmitting data towards the network. Examples of downlink channels comprise physical downlink control channel (PDCCH) for transmitting control information and physical downlink shared channel (PDSCH) for transmitting data towards the user equipment.

[0026] There may be a plurality of UEs 120, 122 in the system. Each of them may be served by the same or by different control nodes 110, 112. The UEs 120, 122 may communicate with each other, in case device-to-device (D2D) communication interface is established between them via a so-called sidelink (SL). Such D2D communications may be referred to as machine-to-machine, peer-to-peer (P2P) communications, or vehicle-to-vehicle (V2V), for example.

[0027] In the case of multiple network nodes in the communication network, the network nodes may be connected to each other via an interface. LTE specifications call such an interface as X2 interface. An interface between an LTE node and a 5G node, or between two 5G nodes may be called Xn interface.

[0028] The network nodes 110 and 112 may be further connected via another interface to a core network 116 of the communication network. The LTE specifications specify the core network as an evolved packet core (EPC), and the core network may comprise e.g. a mobility management entity (MME) and a gateway node. The MME may handle mobility of terminal devices in a tracking area encompassing a plurality of cells and handle signalling connections between the terminal devices and the core network. The gateway node may handle data routing in the core network and to / from the terminal devices. The 5G specifications specify the core network as a 5G core (5GC). The 5G core may comprise e.g. an access and mobility management function (AMF) and a user plane function / gateway (UPF) and other functions. The AMF may handle termination of non-access stratum (NAS) signalling, NAS ciphering & integrity protection, registration management, connection management, mobility management, access authentication and authorization, security context management. The UPF node may support packet routing and forwarding, packet inspection and quality of service (QoS) handling, for example.

[0029] Figure 2 shows an embodiment for distributed RAN architecture where one gNB (e.g. gNB 110) may be at least logically split into a centralised unit (CU) 200 of a base station 110 and a distributed unit (DU) 206 of a base station 110. An interface between CU 200 and DU 206 may be referred to as an Fl interface in NR. The CU 200 may be further divided into a control part (CP) entity 202 of the CU 200 and a user plane (UP) entity 204 of the CU 200. The interface or communication link between the DU 206 and the CU 200 may be called Fl interface, which may similarly be split into control (C) and user (U) planes. The interface or communication link between the CU CP 202 and the CU UP 204 may be called El interface.

[0030] 3GPP has designed in release 18 the feature of resource sharing across multicast and broadcast service (MBS) sessions during RAN sharing. The feature allows the same MBS to be delivered via multiple operators' CN participating in the network sharing to a shared NG-RAN, and the shared NG-RAN nodes may broadcast the MBS data only once for resource efficiency. This feature is envisaged to only apply to broadcast MBS sessions, and not to multicast MBS sessions.

[0031] The feature in connection of RAN sharing has two deployment options. In one deployment option, called “MOCN variant”, both the CU and the DU are shared. In this case there is only one Fl-U tunnel (tunnel for user plane data between DU and CU) per multicast radio bearer (MRB) between the shared user plane (UP) entity of the CU (also called CU UP or gNB-CU UP) and the shared DU (also called gNB-DU). In another deployment option, called “Multiple cell-lD 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 there can be one or more Fl-U tunnels per MRB between the gNB-DU and the one or more CU UPs.

[0032] 3GPP has decided that for the multiple cell ID variant, the gNB-DU will decide how many Fl-U tunnels per MRB it wants to setup. This means that the gNB- DU receives one broadcast session setup request message from the CU CP #X of each PLMN #X and indicates in the broadcast session setup response whether it accepts to setup an Fl-U tunnel with the corresponding CU UP of the CU of PLMN #X. For example, in case of sharing with PLMN1, PLMN2, PLMN3 the gNB-DU could decide to setup the Fl-U tunnels with CU UP #1 upon request from CU CP #1 (for PLMN 1), but not with CU UP #2 upon request from CU CP 2 (for PLMN2) and not with CU UP #3 upon request from CU CP #3 (for PLMN3). Further, 3GPP has decided that a gNB-DU can newly trigger a request for F1U tunnel setup to cover the Fl-U failure case. Taking the example above when gNB-DU has only setup the Fl-U tunnel with CU UP #1 and this Fl-U tunnel fails after a while, the gNB-DU can thus send the new F1AP Broadcast Transport Resource Request message to CU CP #2 for example. Upon receiving the F1AP Broadcast Transport Resource Request message, the CU CP #2 can trigger an F1AP Broadcast setup modification request towards gNB-DU to setup the Fl-U tunnel between CU UP #2 and gNB-DU.

[0033] Current solutions are not enough at DU and CU UP to realize the agreed behaviour for failure handling. More specifically:

[0034] • In case of MBS Fl-U failure detection at DU:

[0035] ■ There is currently no way for a gNB-DU to signal the Fl-U tunnel failure to the CU CP with which it had earlier setup this F1U tunnel without requesting this CU CP for a complete broadcast session release. This situation can apply to scenarios without RAN sharing and also to a case with RAN sharing if the gNB-DU signals an Fl-U failure with CU UP #X to the CU CP #X of the PLMN #X with which it had this Fl-U tunnel earlier setup instead of signalling to another CU CP #Y of another PLMN #Y.

[0036] ■ Even if gNB-DU would be able to inform the CU CP with which it had earlier setup this F1U tunnel, this CU CP would not know if the gNB-DU expects from it to restore the Fl-U tunnel itself or does not expect this restoration from it because for example the gNB-DU intends to request the CU CP of another PLMN to setup another Fl-U tunnel with the CU UP of another PLMN.

[0037] ■ There is currently no way for a CU CP to request a CU UP to allocate a new Fl-U tunnel Uplink TLA (transport layer address) using a modification of an existing MBS El context between CU CP and CU UP.

[0038] • In case of MBS Fl-U failure detection at CU UP:

[0039] ■ There is currently no way for a CU UP to signal to a CU CP that it has detected that the Fl-U tunnel it had earlier setup between with a gNB-DU has failed and for the CU CP to get CU UP to allocate a new Fl-U tunnel Uplink TLA (transport layer address) or to instead notify the gNB-DU for further decision and action. Without such way, if one F1U tunnel fails, another one cannot be created towards the same or a different PLMN.

[0040] To at least partially tackle these problems, there is proposed a solution for efficient detection and reporting of a Fl-U link failure, where the Fl-U communication link is between DU and CU UP. In one embodiment, the detection is performed by the DU and informed towards the CU CP of the failed F1U link / tunnel (i.e. to the same PLMN). In another embodiment, the detection is performed by the DU and informed towards a different CU CP than the CU CP of the failed F1U tunnel (i.e. to different PLMN). In yet one embodiment, the detection is performed by the CU UP.

[0041] The Fl-U link between the CU UP and the DU that has failed in the embodiments presented herein may be associated with (e.g. may carry data of) at least one MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session. It is noted that F1U tunnel has both DL TNL Information and UL TNL information, such as TE1D.

[0042] Let us first consider the embodiment with Fl-U failure detection at DU and notification towards the CU CP of the failed F1U tunnel / link (same PLMN).

[0043] Figure 3 depicts an example method that may be performed by a DU, such as the DU 206 of Figure 2, for example. The method may be computer-implemented. As shown in Figure 3 the DU may, in step 300, detect a failure in a link between the DU and a CU UP (such as the CU UP 204) of the base station (such as of the gNB 110). The DU may detect the failure in various manners, such as using test signals or detecting lack of response / messaging over the link. In step 302, the DU may generate a message based on the detected failure, the message being indicative of the failure. There are various options on what is the message and what is the content of the message, as will be described later. In step 304, the DU may send the message to a control plane (CP) entity, such as to the CU CP 202 or to another gNB’s CU CP.

[0044] From the point of view of the recipient of the message, Figure 4 depicts an example method that may be performed by a CU CP, such as the CU CP 202 of Figure 2 or by another CU CP, such as a CU CP of gNB 112, for example. The method may be computer-implemented. As shown in Figure 4, the CU CP may, in step 400, receive, from the DU 206 of the gNB 110, a message indicative of a failure of a link between the DU and a CU UP. In step 402, the CU CP then determines whether to trigger an establishment of a new link for the DU (i.e. to replace the failed one in order to restore the communication link) or to inform the CU UP about the failed link. The triggering may be advantageous option so that communication may continue in a smoother way. However, it is not always a feasible option and then the other option of informing may be in order. It is noted that in this option the communication may likewise continue at a later point in time because the CU UP might then trigger a process to restore the MBS session.

[0045] Let us look at these embodiments in more details with signaling flow diagrams of Figures 5 and 6.

[0046] Figure 5 depict the option with Fl-U failure detection at DU (also called gNB-DU) and notification towards the CU CP (also called gNB-CU CP) of the failed F1U tunnel (i.e. of the same PLMN).

[0047] In Figure 5, step 500, there is an ongoing transmission of the MBS broadcast session over N3mb and F1U. The Figure does not depict, for reasons of simplicity, MB-UPF entity of PLMN 1 with which the MBS session is ongoing. DU and CU-UP also belong to PLMN 1. The DU may have earlier established the link between the DU and the CU UP, together with the CU CP.

[0048] In step 502-504, the gNB-DU detects F1U failure with the CU UP. The F1U path was setup earlier by the CU CP. For detecting the link failure, the gNB-DU may e.g. generate one or more echo request messages 502 over the F1U path. Upon detecting that there is no answer to the echo request(s), the DU detects the link failure in step 504.

[0049] In step 506A (alternative to 506B), upon detecting that Fl-U failed, the DU sends an F1AP Broadcast Transport Resource Request message to gNB-CU CP with which it had earlier setup this tunnel.

[0050] In another embodiment, as shown with reference numeral 506B, upon detecting that Fl-U failed, the DU sends an F1AP Broadcast Context Notification Indication message to gNB-CU CP with which it had earlier setup this tunnel.

[0051] In an embodiment, the message (either the one of step 506A or 506B, or some other message) comprises an explicit Fl-U failure indicator indicating the failure of the link. The failure indication may be an explicit indication, such as a bit reserved for indicating the failure.

[0052] In an embodiment, the message (either the one of step 506A or 506B, or some other message) comprises an action indicator indicating if the receiving CU CP should try to restore the F1U tunnel itself or should not (for example because gNB-DU intends to use another Fl-U tunnel with the CU UP of another PLMN). That is, the DU may generate an information element (i.e. the action indicator) indicating whether or not the CP entity should attempt to restore the failed link between the DU and the CU UP. The DU may then include the information element in the message. The action of step 402 of Figure 4 may be based on the action indicator (or on lack of receiving it), for example.

[0053] In case (see case 1 in the Figure) the action indicator indicates to attempt restoring the link or as a default action based on receiving the message (either the one of step 506A or 506B, or some other message) from the gNB-DU, the CU CP may, in step 508 decide to restore the Fl-U tunnel between these entities, e.g. replace the old, failed link by a new link between the DU and the CU UP.

[0054] The restoration may comprise e.g. in step 510 the CU CP sending a request, such as an E1AP BC Bearer Context Modification Request message, to CU UP. This message includes a request for the CU UP to allocate Fl-U TNL Info at the CU (i.e. UL transport network layer address at the CU UP). This new tunnel info may be relevant for all involved MRBs that suffered from the failed link.

[0055] In step 512, upon receiving request message, the CU UP allocates the Fl- U TNL Info at CU (i.e. UL transport network layer address at the CU UP) for all involved MRB IDs, as per CU CP’s request. The CU UP sends the allocated TNL address to the CU CP.

[0056] Upon receiving from the CU UP a response (such as an E1AP BC Bearer Context Modification Response message) in step 512 containing the Fl-U TNL Info allocated by the CU UP, the CU CP triggers a modification procedure, such as Fl broadcast context modification procedure to update the gNB-DU with the newly allocated Fl-U TNL Info at CU UP for the involved MRBs. The procedure may comprise sending an Fl broadcast context modification request to the DU including the new tunnel info. Consequently, the DU receives a new TNL address, and can apply the new TNL address for a new link with the UP entity to replace the failed link. The DU may respond to the request to the CU CP.

[0057] In this manner, case 1 provides means for the CU CP to efficiently restore, e.g. establish, the link between the DU and the CU UP.

[0058] Case 2 in Figure 5 relates to a situation where the action indicator indicates not to restore the link, or to a situation where there is no action indicator included in the message of either of steps 506A or 506B, or case 2 can be a default action by the CU CP when receiving the message of either of steps 506A or 506B.

[0059] Case 2 comprises in step 516 the CU CP deciding not try restoring the Fl-U tunnel (i.e. not to try to replace the old one by a 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 including an indication that the Fl-U tunnel (also called link) has failed and / or is no longer used. For example, the CU CP may send to the relevant CU UP a “shared Fl-U not setup / used” or “Fl-U failed” indicator to inform the CU UP that the F1U tunnel is no longer used (for example in case the action indicator did not ask to restore the context). In an embodiment, the CU UP may itself then request a setup of a new link to replace the failed link.

[0060] In an embodiment, the DU may decide to apply another existing link for communication of data that was supposed to be communicated via the failed link, the other link being between the DU and a CU UP of another base station. This may be advantageous option in case such other link exists and the data (e.g. MRB) can be communicated via another BS, which may be the case in RAN sharing, for example.

[0061] In an embodiment, the DU may itself request a setup of a new link to replace the failed link, the new link being towards the CU UP with which the previous link failed or towards a CU UP of another base station (e.g. in case of RAN sharing)-

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

[0063] As said, Figure 5 depicted the scenario where the indication of the failure in either of steps 506A or 506B is sent to the CU CP of the same CU with which the link failed. However, the DU may advantageously in some scenarios send such indication to a CU CP of another base station (i.e. of another PLMN / RAN). The other base station may be e.g. gNB 112 of Figure 1. Sending to another base station may be possible in case of RAN sharing, for example, where the DU is shared between different PMLMs / RANs / CUs.

[0064] A signaling flow diagram showing an embodiment where the DU informs another BS’s CU CP is shown in Figure 6. Steps 500-504 of Figure 6 are the same as in Figure 5.

[0065] In step 600 of Figure 6, upon detecting that Fl-U failed with CU UP1 (CU UP 204 in Figure), the gNB-DU decides to request the CU CP #2 of a different shared PLMN #2 to setup an alternative Fl-U tunnel via CU UP #2 (of PLMN #2). The gNB- DU may send e.g. the F1AP Broadcast Transport Resource Request message to gNB- CU CP #2. This message may optionally include an explicit Fl-U failure indicator. The failure indication may be an explicit indication, such as a bit reserved for indicating the failure.

[0066] In step 602, upon receiving the message notifying the failure from the gNB-DU in step 600, the CU CP #2 sends to the CU UP #2 a request message, such as E1AP BC Bearer Context Modification Request message. This message may include a request for the CU UP #2 to allocate Fl-U TNL Info at CU #2 (UL transport network layer address at the CU UP #2). This request may be relevant for all involved MRB IDs.

[0067] In step 604, the CU UP #2 allocates, as per request, the new tunnel info and sends a response to the request to the CU CP #2, the response including the new tunnel info.

[0068] Then, upon receiving from the CU UP #2 the response, such as an E1AP BC Bearer Context Modification Response message, containing the Fl-U TNL Info allocated by the CU UP #2, the CU CP #2 triggers a modification procedure, such as an Fl broadcast context modification request 606, to update the gNB-DU with the newly allocated Fl-U TNL Info at CU #2 for the involved MRBs. In this manner the DU and the CU #2 (more specifically CU UP #2) may start communicating based on the newly allocated Fl-U tunnel info.

[0069] Figures 3 to 6 concentrated on embodiments where the DU (e.g., DU 206) made the failure detection and consequent notification. Now, let us take a look at embodiments where the CU UP makes the failure detection and consequent notification.

[0070] Figure 7 depicts an example method that may be performed by a CU UP, such as the CU UP 204 of Figure 2, for example. The method may be computer-implemented. As shown in Figure 7 the CU UP may, in step 700, detect a failure in a link between a DU (such as the DU 206) and the CU UP of the base station (such as of the gNB 110). The CU UP may detect the failure in various manners, such as using test signals or detecting lack of response / messaging over the link. In step 702, the CU UP may generate a message based on the detected failure, the message being indicative of the failure. There are various options on what is the content of the message, as will be described later. In step 704, the CU UP may send the message to a control plane (CP) entity, such as to the CU CP 202.

[0071] From the point of view of the recipient of the message, Figure 8 depicts an example method that may be performed by a CU CP, such as the CU CP 202 of Figure 2. The method may be computer-implemented. As shown in Figure 8, the CU CP may, in step 800, receive, from the CU UP 204 of the gNB 110, a message, the message being indicative of a failure of a link between a DU and the CU UP. In step 802, the CU CP then determines whether to trigger an establishment of a new link for the CU UP or to inform the DU about the failed link. The triggering may be advantageous option so that communication may continue in smoother way. However, it is not always a feasible option and then the other option of informing may be in order. It is noted that in this option the communication may likewise continue at a later point in time because the DU might then trigger a process to restore the MBS session.

[0072] From the point of view of the DU, Figure 9 depicts an example method that may be performed by a DU, such as the DU 206 of Figure 2. The method may be computer-implemented. This embodiment provides for DU in step 900 receiving a failure indication of a link between the DU and a CU UP. In step 902, the DU requests a setup of a new link to replace the failed link, the new link being towards the CU UP or towards a CU UP of another base station.

[0073] Let us look at these embodiments in more details with signaling flow diagrams of Figures 10 and 11.

[0074] In Figure 10, step 1000, there is an ongoing transmission of the MBS broadcast session over N3mb and F1U. The figure does not depict, for reasons of simplicity, MB-UPF entity of PLMN with which the MBS session is ongoing. DU and CU-UP also belong to the same PLMN. The CU UP may have earlier established the link between the DU and the CU UP, together with the CU CP.

[0075] In steps 1002-1004, the CU UP detects F1U failure. The F1U path was setup earlier by the CU CP. For detecting the link failure, the CU UP may e.g. generate one or more echo request messages 1002 over the F1U path. Upon detecting that there is no answer to the echo request(s) from the DU, the CU UP detects the link failure in step 1004.

[0076] In step 1006, upon detecting that Fl-U failed, the CU UP generates a message based on the detected failure, the message being indicative of the failure, and sends the message to the CU CP. For example, the CU UP sends an El BC Bearer Context Modification Required message. This message in this embodiment includes a new Fl-U TNL Info at CU (e.g. UL transport network layer address at CU UP), possibly for all MRB IDs involved. That is, the CU UP may generate the TNL address for a new link between the DU and the CU UP (upon detecting the failure in step 1004), and include the TNL address in the message of step 1006.

[0077] In an embodiment, the message of step 1006 also comprises a failure indication indicating the failure of the link. The failure indication may be an explicit indication, such as a bit reserved for indicating the failure. In an embodiment, the CU UP generates a second information element indicating the cause of the failure, and includes the second information element in the message of step 1006.

[0078] The CU CP receives the message and determines whether to trigger an establishment of a new link for the CU UP (i.e. between the CU UP and DU) or inform the DU about the failed link. Upon receiving the message, which includes the Fl-U TNL Info, the CU CP in step 1008 triggers a modification procedure, such as an Fl broadcast context modification procedure, to update the DU with the newly allocated Fl-U TNL Info. This procedure may comprise a request and a corresponding response from the DU. Thus, the triggering of the establishment of a new link for the CU UP comprises transmitting the TNL address to the DU.

[0079] Figure 11 shows one more embodiment related to the CU UP detection and notification. Steps 1000-1004 of Figure 11 are the same as in Figure 10.

[0080] In step 1100, upon detecting that Fl-U failed, the CU UP generates and sends a message indicative of the failure to the CU CP. However, in this embodiment of Figure 11, the message (e.g. an El BC Bearer Context Modification Required message, or any other E1AP (also called El) message) does not include the new TNL info but includes the failure indicator (such as the explicit indication of failure).

[0081] In step 1102, upon receiving the message with the indication of F1U failure, the CU CP sends a request to the CU UP to allocate the new Fl-U tunnel info at CU (e.g. UL transport network layer address at CU UP) for all involved MRB IDs. The request may be e.g. El BC Bearer Context Modification Request message.

[0082] Step 1104 comprises the CU UP allocating the new Fl-U tunnel info (as requested), and responding to the CU CP, the response including the allocated Fl- U link info. The response may be a E1AP BC Bearer Context Modification Response message containing the Fl-U TNL Info.

[0083] In step 1106, the CU CP having received the response from the CU UP, the CU CP triggers a modification procedure, e.g. by sending an Fl broadcast context modification request to the DU to update the DU with the newly allocated Fl- U TNL Info (e.g. the TNL address) at CU for the involved MRBs. The DU responds to the request with acknowledgement.

[0084] Figure 12 shows one more embodiment related to the CU UP detection and notification. Steps 1000-1004 and step 1100 of Figure 12 are the same as in Figure 11.

[0085] In step 1200 of Figure 12, upon receiving the failure indication (e.g. El BC Bearer Context Modification Required message, or any other E1AP message indicating the failure), the CU CP sends a notification (e.g. Fl notification indication) to DU, which contains an indication that the Fl-U has failed or is no longer working.

[0086] In step 1202, the DU then may e.g. request a setup of a new Fl-U link to replace the failed link. In an embodiment, the new link is towards the CU UP with which the previous, now failed, link was operative. The request may be performed then as proposed in Figure 5 (see e.g. steps 506A / 506B - 514). In another embodiment, the establishment of the new link is towards a UP entity of a CU of another base station (in case of RAN sharing, for example). The request may be performed then as proposed in Figure 6 (see e.g. steps 600-606).

[0087] As shown with several embodiments above, there is proposed an efficient procedure for enabling detection of Fl-U failure. Further, owing to the presented embodiments, there are proposed efficient ways to re-establish a link to replace the failed link. This helps in communication throughput, for example. Some of the above embodiments are especially beneficial for RAN sharing scenario.

[0088] It is noted that when the DU sends the message indicative of the link failure to another PLMN, then the receiving CU CP may not have any ongoing Fl-U link yet and therefore the request to setup one from the DU can be considered as a new request to set up a link.

[0089] However, if the DU is not in multiple cell-lD case, e.g. in non-RAN sharing (or MOCN RAN sharing), the DU cannot setup a new F1U towards CU CP 2 or CU CP 3 and there is no other way for DU but getting a new Fl-U setup from the CU CP 1, with which the DU originally established the connection. In case where the DU (or CU UP) sends the message indicative of the failure to the CU CP of the same PLMN (i.e. to the same CU CP of PLMN 1 which had earlier set up the failed link), the CU CP may consider such request as an error message or at least as an abnormal situation to receive yet again a request to establish an Fl-U. For such abnormal situation, it is unclear which type of message / notification the DU (or CU UP) should send to the CU CP. As explained in above embodiments one option is reusing the F1AP broadcast transport setup request message for replacement of the link due to the failure, the message possibly including a new indicator notifying the receiving CU CP that this request is not a mistake but due to the original Fl-U had failed (e.g. the explicit failure indication, as proposed in some of the above embodiments). As another option, the detecting unit may use a newly introduced F1AP Broadcast Context Notification Indication, wherein the DU triggers a new procedure including an IE to inform that F1U failed. The CU CP then can trigger F1AP Broadcast Context Modification Request message to update the UL address. As yet one option, as also disclosed earlier, the DU may decide not to react upon no echo response. Instead, the DU may decide to rely on CU UP to detect the F1U failure because CU UP also sends Echo Request messages. When CU UP detects the F1U failure, it sends an El notification to CU CP to report the F1U failure such an sending an El BC bearer context modification required. CU UP could include necessary UL TEID in this message so that the CU CP can directly send the F1AP Broadcast context modification request to the gNB-DU including the new Fl-U TNL Information at CU.

[0090] It is noted also that the above embodiments do not rely and do not use a query to confirm current status from the CU CP, as this would reduce efficiency of the proposed procedures. Furthermore, to avoid affecting the efficiency, the embodiments do not rely nor apply migration of context to another cluster over El. That is, the same CU UP is used (by the E1AP Modification procedure) because the CU UP may have already the required context.

[0091] It is noted that the names of the messages / signaling between different entities in above embodiments are merely given as examples, and other messages / signaling conveying the required information are applicable for implementing the embodiments.

[0092] An embodiment, as shown in Figure 13, provides an apparatus 10 comprising 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 at least to carry out any one of the above-described processes. In an example, the at least one memory and the computer program code (software), are configured, with the at least one processor, to cause the apparatus to carry out any one of the above-described processes. The control circuitry 12 may comprise relevant circuitry / ies for performing the functions, according to any of the embodiments.

[0093] The memory may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, flash memory, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The memory may comprise a database for storing data.

[0094] In an embodiment, the apparatus 10 is or is comprised in a DU, such as the DU 206. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of Figure 3 or of Figure 9, for example.

[0095] In another embodiment, the apparatus 10 is or is comprised in a CU UP, such as the CU UP 204. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of Figure 7, for example.

[0096] In another embodiment, the apparatus 10 is or is comprised in a CU CP, such as the CU CP 202. The apparatus may be caused to execute some of the functionalities of the above described processes, such as the steps of Figure 4 or of Figure 8, for example.

[0097] The apparatus may further comprise a radio interface (TRX) 16 comprising hardware and / or software for realizing communication connectivity according to one or more communication protocols. The TRX may provide the apparatus with communication capabilities to a user equipment and / or to other entities of the base station, for example.

[0098] The apparatus may also comprise a user interface 18 comprising, for example, at least one keypad, a microphone, a touch display, a display, a speaker, etc. The user interface may be used to control the apparatus by the user.

[0099] As used in this application, the term ‘circuitry’ refers to all of the following: (a) hardware-only circuit implementations, such as implementations in only analog and / or digital circuitry, and (b) combinations of circuits and soft- ware (and / or firmware), such as (as applicable): (i) a combination of processor(s) or (ii) portions of processor(s) / software including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus to perform various functions, and (c) circuits, such as a microprocessor(s) or a portion of a micropro- cessor(s), that require software or firmware for operation, even if the software or firmware is not physically present. This definition of ‘circuitry’ applies to all uses of this term in this application. As a further example, as used in this application, the term ‘circuitry’ would also cover an implementation of merely a processor (or multiple processors) or a portion of a processor and its (or their) accompanying software and / or firmware. The term ‘circuitry’ would also cover, for example and if applicable to the particular element, a baseband integrated circuit or applications processor integrated circuit for a mobile phone or a similar integrated circuit in a server, a cellular network device, or another network device.

[0100] In an embodiment, at least some of the processes described may be carried out by an apparatus comprising corresponding means for carrying out at least some of the described processes. Some example means for carrying out the processes may include at least one of the following: detector, processor (including dual-core and multiple-core processors), digital signal processor, controller, receiver, transmitter, encoder, decoder, memory, RAM, ROM, software, firmware, display, user interface, display circuitry, user interface circuitry, user interface software, display software, circuit, antenna, antenna circuitry, and circuitry.

[0101] A term non-transitory, as used herein, is a limitation of the medium itself [i.e. tangible, not a signal) as opposed to a limitation on data storage persistency (e.g. RAM vs. ROM).

[0102] As used herein the term “means” is to be construed in singular form, i.e. referring to a single element, or in plural form, i.e. referring to a combination of single elements. Therefore, terminology “means for [performing A, B, C]”, is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C. Further, terminology “means for performing A, means for performing B, means for performing C” is to be interpreted to cover an apparatus in which there is only one means for performing A, B and C, or where there are separate means for performing A, B and C, or partially or fully overlapping means for performing A, B, C.

[0103] The techniques and methods described herein may be implemented by various means. For example, these techniques may be implemented in hardware [one or more devices), firmware [one or more devices), software [one or more modules), or combinations thereof. For a hardware implementation, the apparatuses) of embodiments may be implemented within one or more applicationspecific integrated circuits [ASICs), digital signal processors [DSPs), digital signal processing devices [DSPDs), programmable logic devices [PLDs), field programmable gate arrays [FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. For firmware or software, the implementation can be carried out through modules of at least one chip set [e.g. procedures, functions, and so on) that perform the functions described herein. The software codes may be stored in a memory unit and executed by processors. The memory unit may be implemented within the processor or externally to the processor. In the latter case, it can be communicatively coupled to the processor via various means, as is known in the art. Additionally, the components of the systems described herein may be rearranged and / or complemented by additional components in order to facilitate the achievements of the various aspects, etc., described with regard thereto, and they are not limited to the precise configurations set forth in the given figures, as will be appreciated by one skilled in the art. Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described may be carried out by executing at least one portion of a computer program comprising corresponding instructions. The computer program may be in source code form, object code form, or in some intermediate form, and it may be stored in some sort of carrier, which may be any entity or device capable of carrying the program. For example, the computer program may be stored on a computer program distribution medium readable by a computer or a processor. The computer program medium may be, for example but not limited to, a record medium, computer memory, read-only memory, electrical carrier signal, telecommunications signal, and software distribution package, for example. The computer program medium may be a non-transitory medium. Coding of software for carrying out the embodiments as shown and described is well within the scope of a person of ordinary skill in the art.

[0104] Following is a list of some aspects regarding a first set of embodiments. According to a first aspect, there is provided a method performed by a distributed unit (DU) of a base station, the method comprising: detecting a failure 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 failure, the message being indicative of the failure; and sending the message to a control plane (CP) entity.

[0105] Various embodiments of the first aspect may comprise at least one feature from the following bulleted list:

[0106] • wherein the message is an F1AP Broadcast Transport Resource Request message.

[0107] • wherein the message is an F1AP Notification message.

[0108] • wherein the failure indication is sent to a CP entity of the CU of the base station.

[0109] • wherein the failure indication is sent to a CP entity of a CU of another base station.

[0110] • wherein the message comprises a failure indication indicating the failure of the link.

[0111] • generate an information element indicating whether or not the CP entity should attempt to restore the failed link between the DU and the UP entity; and include the information element in the message.

[0112] • receive a new transport network layer (TNL) address; and apply the new TNL address for a new link with the UP entity to replace the failed link.

[0113] • request a setup of a new link to replace the failed link, the new link being towards the UP entity of the CU of the base station, or towards a UP entity of a CU of another base station.

[0114] • generate a second information element indicating the cause of the failure; and include the second information element in the message.

[0115] • wherein the failed link between the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

[0116] According to a second aspect, there is provided a method 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 indicative of a failure of a link between the DU and a user plane (UP) entity; and determining whether to trigger an establishment of a new link for the DU or to inform the UP entity about the failed link.

[0117] Various embodiments of the second aspect may comprise at least one feature from the following bulleted list:

[0118] • wherein the message is an F1AP Broadcast Transport Resource Request message.

[0119] • wherein the message is an F1AP Notification message.

[0120] • wherein the failed link is between the DU and the UP entity of the CU of the base station.

[0121] • wherein the failed link is between the DU and the UP entity of a CU of another base station.

[0122] • wherein the message comprises a failure indication indicating the failure of the link.

[0123] • wherein the message comprises an information element indicating whether or not the CP entity should attempt to restore the failed link between the DU and the UP entity, and wherein the determining whether to trigger or to inform is based on the information element.

[0124] • wherein the triggering comprises: requesting a 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 transmitting the TNL address to the DU. • wherein at least one of the following: 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 transmitted to the DU in an Fl Broadcast Bearer Context Modification Request message.

[0125] • wherein informing the UP entity about the failed link comprises: sending an E1AP BC Bearer Context Modification Request including an indication that the existing link between the UP entity and the DU is not used or no longer used.

[0126] • wherein the failed link be-tween the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

[0127] According to a third aspect, there is provided a distributed unit (DU) of a base station, 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 at least to: detect a failure 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 failure, the message being indicative of the failure; and send the message to a control plane (CP) entity. Various embodiments of the third aspect may comprise at least one feature from the bulleted list under the first aspect.

[0128] According to a fourth aspect, there is provided a control plane (CP) entity of a central unit (CU) of a base station, 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 at least to: receive, from a distributed unit (DU) of the base station, a message indicative of a failure of a link between the DU and a user plane (UP) entity; and determine whether to trigger an establishment of a new link for the DU or to inform the UP entity about the failed link. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the second aspect.

[0129] According to a fifth aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect.

[0130] According to a sixth aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the second aspect.

[0131] According to a seventh aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the first aspect.

[0132] According to an eight aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the second aspect.

[0133] According to a ninth aspect, there is provided an apparatus, comprising means for performing the method according to the first aspect, and / or means configured to cause the apparatus to perform the method according to the first aspect.

[0134] According to a tenth aspect, there is provided an apparatus, comprising means for performing the method according to the second aspect, and / or means configured to cause the apparatus to perform the method according to the second aspect.

[0135] Following is a list of some aspects regarding a second set of embodiments.

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

[0137] Various embodiments of the eleventh aspect may comprise at least one feature from the following bulleted list:

[0138] • wherein the message is an E1AP Broad-cast Bearer Context Modification Required message.

[0139] • wherein the message com-prises a failure indication indicating the failure of the link.

[0140] • allocate a transport network layer (TNL) address for a new link be-tween the DU and the UP entity; and include the TNL address in the message.

[0141] • receive, from the CP entity of the CU, a request to allocate a transport network layer (TNL) address for a new link between the DU and the UP entity; allocate the TNL address for the new link; and transmit an indication of the TNL address to the CP entity of the CU. • generate a second information element indicating the cause of the failure; and include the second information element in the message.

[0142] • wherein the failed link be-tween the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

[0143] According to a twelfth aspect, there is provided a method 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 indicative of a failure of a link between a distributed unit (DU) of the base station and the UP entity; determining whether to trigger an establishment of a new link for the DU or to inform the DU about the failed link. Various embodiments of the twelfth aspect may comprise at least one feature from the following bulleted list:

[0144] • wherein the message comprises a failure indication indicating the failure of the link.

[0145] • wherein the message com-prises a transport network layer (TNL) address for a new link between the DU and the UP entity, and the triggering comprises transmitting the TNL address to the DU.

[0146] • wherein the triggering com-prises: requesting the UP entity to allocate a transport network layer (TNL) ad-dress for the new link, receiving information indicating the TNL address from the UP entity; and transmitting the TNL address to the DU.

[0147] • wherein at least one of the following applies: 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 transmitted to the DU in an Fl Broad-cast Bearer Context Modification Request message.

[0148] • wherein the failed link be-tween the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

[0149] According to a thirteenth aspect, there is provided a method performed by a distributed unit (DU) of a base station, the method comprising: receiving, from a central unit (CU) of the base station, a failure indication of a link between the DU and a user plane (UP) entity of CU; requesting a setup of a new link to replace the failed link, the new link being towards the UP entity of the CU or towards a UP entity of a CU of another base station. Various embodiments of the thirteenth aspect may comprise at least one feature from the following bulleted list:

[0150] • wherein the failure indication is received from the control plane (CP) of the central unit of the base station.

[0151] • wherein the failed link between the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

[0152] According to a fourteenth aspect, there is provided a user plane (UP) entity of a central unit (CU) of a base station, 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 at least to: detect a failure in a link between a distributed unit (DU) of the base station and the UP entity; generate a message based on the detected failure, the message being indicative of the failure; and send the message to a control plane (CP) entity of the CU. Various embodiments of the fourteenth aspect may comprise at least one feature from the bulleted list under the eleventh aspect.

[0153] According to a fifteenth aspect, there is provided a control plane (CP) entity of a central unit (CU) of a base station, 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 at least to: receive, from a user plane (UP) entity of the CU, a message indicative of a failure of a link between a distributed unit (DU) of the base station and the UP entity; determine whether to trigger an establishment of a new link for the DU or to inform the DU about the failed link. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the twelfth aspect.

[0154] According to a sixteenth aspect, there is provided a distributed unit (DU) of a base station, 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 at least to: receive, from a central unit (CU) of the base station, a failure indication of a link between the DU and a user plane (UP) entity of CU; request a setup of a new link to replace the failed link, the new link being towards the UP entity of the CU or towards a UP entity of a CU of another base station. Various embodiments of the fourth aspect may comprise at least one feature from the bulleted list under the thirteenth aspect.

[0155] According to a seventieth aspect, there is provided a computer program product embodied on a distribution medium and comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the eleventh, twelfth or thirteenth aspect.

[0156] According to an eighteenth aspect, there is provided a computer program product comprising program instructions which, when executed by an apparatus, cause the apparatus to carry out the method according to the eleventh, twelfth or thirteenth aspect.

[0157] According to a nineteenth aspect, there is provided an apparatus, comprising means for performing the method according to the eleventh, twelfth or thirteenth aspect, and / or means configured to cause the apparatus to perform the method according to the eleventh, twelfth or thirteenth aspect. Even though the invention has been described above with reference to an example according to the accompanying drawings, it is clear that the invention is not restricted 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 they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.

Claims

CLAIMS1. A distributed unit (DU) of a base station, 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 at least to: detect a failure 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 failure, the message being indicative of the failure; and send the message to a control plane (CP) entity.

2. The DU of claim 1, wherein the message is an F1AP Broadcast Transport Resource Request message.

3. The DU of claim 1, wherein the message is an F1AP Notification message.

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

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

6. The DU of any of claims 1 to 5, wherein the message comprises a failure indication indicating the failure of the link.

7. The DU of any of claims 1 to 6, wherein the instructions, when executed by the at least one processor, further cause the DU to: generate an information element indicating whether or not the CP entity should attempt to restore the failed link between the DU and the UP entity; and include the information element in the message.

8. The DU of any of claims 1 to 7, wherein the instructions, when executed by the at least one processor, further cause the DU to: receive a new transport network layer (TNL) address; and apply the new TNL address for a new link with the UP entity to replacethe failed link.

9. The DU of any of claims 1 to 8, wherein the instructions, when executed by the at least one processor, further cause the DU to: request a setup of a new link to replace the failed link, the new link being towards the UP entity of the CU of the base station, or towards a UP entity of a CU of another base station.

10. The DU of any of claims 1 to 9, wherein the instructions, when executed by the at least one processor, further cause the DU to: generate a second information element indicating the cause of the failure; and include the second information element in the message.

11. The DU of any of claims 1 to 10, wherein the failed link between the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

12. A control plane (CP) entity of a central unit (CU) of a base station, 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 at least to: receive, from a distributed unit (DU) of the base station, a message indicative of a failure of a link between the DU and a user plane (UP) entity; and determine whether to trigger an establishment of a new link for the DU or to inform the UP entity about the failed link.

13. The CP entity of claim 12, wherein the message is an F1AP Broadcast Transport Resource Request message.

14. The CP entity of claim 12, wherein the message is an F1AP Notification message.

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

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

17. The CP entity of any of claims 12 to 16, wherein the message comprises a failure indication indicating the failure of the link.

18. The CP entity of any of claims 12 to 17, wherein the message comprises an information element indicating whether or not the CP entity should attempt to restore the failed link between the DU and the UP entity, and wherein the determining whether to trigger or to inform is based on the information element.

19. The CP entity of any of claims 12 to 18, wherein the triggering comprises: requesting a 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 transmitting the TNL address to the DU.

20. The CP entity of claim 19, wherein at least one of the following: 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 transmitted to the DU in an Fl Broadcast Bearer Context Modification Request message.

21. The CP entity of any of claims 12 to 18, wherein informing the UP entity about the failed link comprises: sending an E1AP BC Bearer Context Modification Request including an indication that the existing link between the UP entity and the DU is not used or no longer used.

22. The CP entity of any of claims 12 to 21, wherein the failed link between the CU and the DU is associated with a MBS (Multicast Broadcast Service) Radio Bearer (MRB) of an MBS Session.

23. A method performed by a distributed unit (DU) of a base station, the method comprising: detecting a failure 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 failure, the message being indicative of the failure; and sending the message to a 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: receiving, from a distributed unit (DU) of the base station, a message indicative of a failure of a link between the DU and a user plane (UP) entity; and determining whether to trigger an establishment of a new link for the DU or to inform the UP entity about the failed link.

25. A computer program product embodied on a distribution medium readable by a computer and comprising program instructions which, when the program is executed by an apparatus, cause the apparatus to carry out the method according to claim 23 or according to claim 24.

26. A computer program product comprising program instructions which, when the program is executed by an apparatus, cause the apparatus to carry out the method according to claim 23 or according to claim 24.

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

Images