WO2025000362A1

WO2025000362A1 - Supervision on supervision object

Info

Publication number: WO2025000362A1
Application number: PCT/CN2023/103953
Authority: WO
Inventors: Yun Ma; Yuqun Cao; Ning Xu
Original assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Current assignee: Nokia Shanghai Bell Co Ltd; Nokia Solutions and Networks Oy
Priority date: 2023-06-29
Filing date: 2023-06-29
Publication date: 2025-01-02
Anticipated expiration: 2025-12-29

Abstract

Embodiments of the present disclosure relate to supervision on a supervision object. In an aspect, a first device transmits, to a second device, a request message for performing supervision on a supervision object between the first device and the second device. The first device determines a status of the supervision object based on a response message received from the second device or a failure to receive the response message. In this way, a supervision mechanism is provided, e.g., to avoid sleeping cells.

Description

SUPERVISION ON SUPERVISION OBJECT

FIELD

Various example embodiments relate to the field of communications and in particular, to devices, methods, apparatuses, and a computer readable medium for performing supervision on a supervision object.

BACKGROUND

A communication system can be seen as a facility that enables communication sessions between two or more entities such as user terminals, access nodes and/or other nodes by providing carriers between the various entities involved in the communications path. A communication system can be provided for example by means of a communication network and one or more compatible communication devices. The communication sessions may comprise, for example, communication of data for carrying communications such as voice, electronic mail (email) , text message, multimedia and/or content data and so on. Content may be multicast or unicast to communication devices.

The communication system and associated devices typically operate in accordance with a required standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. In the communication system, supervision can be performed on a supervision object, such a path or a flow between devices.

SUMMARY

In general, example embodiments of the present disclosure provide a solution for performing supervision on a supervision object.

In a first aspect, there is provided a first device. The first device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the first device at least to: transmit, to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and determine a status of the supervision object based on a response message received from the second device or a failure to receive the response message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In a second aspect, there is provided a second device. The second device comprises at least one processor and at least one memory storing instructions that, when executed by the at least one processor, cause the second device at least to: receive, from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and transmit, to the first device, a response message of the request message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In a third aspect, there is provided a method. The method comprises: transmitting, at a first device and to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and determining a status of the supervision object based on a response message received from the second device or a failure to receive the response message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In a fourth aspect, there is provided a method. The method comprises: receiving, at a second device and from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and transmitting, to the first device, a response message of the request message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In a fifth aspect, there is provided an apparatus. The apparatus comprises: means for transmitting, at a first device and to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and means for determining a status of the supervision object based on a response message received from the second device or a failure to receive the response message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In a sixth aspect, there is provided an apparatus. The apparatus comprises: means for receiving, at a second device and from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and means for transmitting, to the first device, a response message of the request message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In a seventh aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method according to any one of the above third to fourth aspects.

In an eighth aspect, there is provided a computer program product comprising program instructions for performing at least the method according to any one of the above third to fourth aspects.

In a ninth aspect, there is provided a computer program comprising instructions, which, when executed by an apparatus, cause the apparatus to perform at least the method according to any one of the above third to fourth aspects.

In an tenth aspect, there is provided a first device. The first device comprises: transmitting circuitry configured to transmit, to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and determining circuitry configured to determine a status of the supervision object based on a response message received from the second device or a failure to receive the response message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In an eleventh aspect, there is provided a second device. The second device comprises: receiving circuitry configured to receive, from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and transmitting circuitry configured to transmit, to the first device, a response message of the request message, wherein at least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

It is to be understood that the summary section is not intended to identify key or essential features of embodiments of the present disclosure, nor is it intended to be used to limit the scope of the present disclosure. Other features of the present disclosure will become easily comprehensible through the following description.

BRIEF DESCRIPTION OF THE DRAWINGS

Some example embodiments will now be described with reference to the accompanying drawings, in which:

Fig. 1A illustrates an example communication system in which embodiments of the present disclosure may be implemented;

Fig. 1B illustrates a schematic diagram illustrating fronthaul transport with direct point-to-point (P2P) connections;

Fig. 1C illustrates a schematic diagram illustrating evolved fronthaul transport with layer 2 (L2) time sensitive network (TSN) ;

Fig. 1D illustrates a schematic diagram illustrating evolved fronthaul transport with internet protocol (IP) -aware TSN;

Fig. 1E illustrates a schematic diagram illustrating detection ways for fronthaul transport problems, using enhanced Common Public Radio Interface (eCPRI) as an example;

Fig. 2 illustrates an example signaling chart of an example process according to some embodiments of the present disclosure;

Fig. 3 illustrates a schematic diagram illustrating an eCPRI common header format according to some embodiments of the present disclosure;

Fig. 4 illustrates a schematic diagram illustrating an eCPRI supervision message format according to some embodiments of the present disclosure;

Fig. 5 illustrates a schematic diagram illustrating a Radio over Ethernet (RoE) supervision common frame format according to some embodiments of the present

disclosure;

Fig. 6 illustrates a message sequence diagram for data path supervision according to some embodiments of the present disclosure;

Fig. 7 illustrates a schematic diagram illustrating a method implemented at a first device according to some embodiments of the present disclosure;

Fig. 8 illustrates a schematic diagram illustrating a method implemented at a second device according to some embodiments of the present disclosure;

Fig. 9 illustrates a simplified block diagram of a device that is suitable for implementing embodiments of the present disclosure; and

Fig. 10 illustrates a block diagram of an example computer readable medium in accordance with some embodiments of the present disclosure.

Throughout the drawings, the same or similar reference numerals represent the same or similar element.

DETAILED DESCRIPTION

Principles of the present disclosure will now be described with reference to some example embodiments. It is to be understood that these embodiments are described only for the purpose of illustration and help those skilled in the art to understand and implement the present disclosure, without suggesting any limitation as to the scope of the disclosure. The disclosure described herein can be implemented in various manners other than the ones described below.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

References in the present disclosure to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. 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. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the listed terms.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. As used herein, “at least one of the following: <a list of two or more elements>” and “at least one of <a list of two or more elements>” and similar wording, where the list of two or more elements are joined by “and” or “or” , mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements.

As used in this application, the term “circuitry” may refer to one or more or all of the following:

(a) hardware-only circuit implementations (such as implementations in only analog and/or digital circuitry) and

(b) combinations of hardware circuits and software, such as (as applicable) :

(i) a combination of analog and/or digital hardware circuit (s) with software/firmware and

(ii) any portions of hardware processor (s) with software (including digital signal processor (s) ) , software, and memory (ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and

(c) hardware circuit (s) and or processor (s) , such as a microprocessor (s) or a portion of a microprocessor (s) , that requires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation.

This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware circuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim element, a baseband integrated circuit or processor integrated circuit for a mobile device or a similar integrated circuit in server, a cellular network device, or other computing or network device.

As used herein, the term “communication network” refers to a network following any suitable communication standards, such as Long Term Evolution (LTE) , LTE-Advanced (LTE-A) , Wideband Code Division Multiple Access (WCDMA) , High-Speed Packet Access (HSPA) , Narrow Band Internet of Things (NB-IoT) and so on. Furthermore, the communications between a terminal device and a network device in the communication network may be performed according to any suitable generation communication protocols, including, but not limited to, the first generation (1G) , the second generation (2G) , 2.5G, 2.75G, the third generation (3G) , the fourth generation (4G) , 4.5G, the future fifth generation (5G) communication protocols, and/or any other protocols either currently known or to be developed in the future. Embodiments of the present disclosure may be applied in various communication systems. Given the rapid development in communications, there will of course also be future type communication technologies and systems with which the present disclosure may be embodied. It should not be seen as limiting the scope of the present disclosure to only the aforementioned system.

As used herein, the term “network device” refers to a node in a communication network via which a terminal device accesses the network and receives services therefrom. The network device may refer to a base station (BS) or an access point (AP) , for example, a base transceiver station (BTS) , a node B (NodeB or NB) , an evolved NodeB (eNodeB or eNB) , a NR NB (also referred to as a gNB) , a Radio Unit (RU) , a Centralized Unit (CU) , a Distributed Unit (DU) , a Remote RU (RRU) , a Radio Header (RH) , a Remote Radio Head (RRH) , a relay, a low power node such as a femto, a pico, and so forth, depending on the applied terminology and technology. In the following description, the terms “network device” , “network (NW) , ” “gNB” , “BS” and “BTS” may be used interchangeably.

The term “terminal device” refers to any end device that may be capable of wireless communication. By way of example rather than limitation, a terminal device may also be referred to as a communication device, user equipment (UE) , a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, 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, wireless endpoints, mobile stations, laptop-embedded equipment (LEE) , laptop-mounted equipment (LME) , USB dongles, smart devices, wireless customer-premises equipment (CPE) , 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. In the following description, the terms “terminal device” , “communication device” , “terminal” , “user equipment” and “UE” may be used interchangeably.

In the radio access network (RAN) system, fronthaul may refer to connections between a RU (e.g., open RAN RU (O-RU) ) and a DU (e.g., open RAN DU (O-DU)) . The open RAN is a concept based on interoperability and standardization of RAN elements including a unified interconnection standard for white-box hardware and open source software elements from different vendors. The O-RU may be a logical node hosting a Low physical (PHY) layer and radio frequency (RF) processing based on a lower layer functional split. The O-DU may be a logical node hosting Radio Link Control (RLC) /Media Access Control (MAC) /high PHY layers based on a lower layer functional split.

The fronthaul may include the Control User Synchronization (CUS) plane and the Management (M) plane over low layer split interfaces. The Control Plane (C-Plane) may refer to real-time control between O-DU and O-RU and may not include the In-phase and Quadrature (IQ) sample data (part of the User Plane) . The User Plane (U-Plane) may refer to IQ sample data transferred between the O-DU and the O-RU. The Management Plane (M-Plane) may refer to non-real-time management operations between the O-DU and the O-RU.

Principles and implementations of the present disclosure will be described in detail below with reference to the figures. Fig. 1A illustrates an example communication system 100 in which embodiments of the present disclosure may be implemented. The system 100 includes a device 110 and a device 120. The device 110 may be a RU in 5G, a RRH in 4G or the like. The device 120 may be a DU, such as a virtual DU.

It is to be understood that the number of the devices and their connections are only for the purpose of illustration without suggesting any limitations. The system 100 may include any suitable number of device 110 and device 120 adapted for implementing embodiments of the present disclosure.

Communications in the communication system 100 may be implemented according to any proper communication protocol (s) , comprising, but not limited to, cellular communication protocols, wireless local network communication protocols, and/or any other protocols currently known or to be developed in the future, such as eCPRI protocol or Institute of Electrical and Electronic Engineers (IEEE) 1914 protocol. Moreover, the communication 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 (MIMO) , Orthogonal Frequency Division Multiple (OFDM) , Discrete Fourier Transform spread OFDM (DFT-s-OFDM) and/or any other technologies currently known or to be developed in the future.

The connection between the device 110 and the device 120 may be referred to as fronthaul transport. The fronthaul transport is evolved from P2P connection (as shown in Fig. 1B) to multi-point to multi-point (MP2MP) L2 TSN (as shown in Fig. 1C) and MP2MP IP-aware network via TSN (as shown in Fig. 1D) , and the fronthaul transport network is becoming more and more complicated.

In open RAN, there are some scenarios in which transport issues or software failures only occur for fronthaul C/U-plane but not M-plane, and in this way, it is hard for M-Plane to detect the sleeping cell problem. A sleeping cell is an unlocked cell that is transmitting on the broadcast channel which has no alarms and is unable to set up traffic (packet or voice calls) . For example, as different data paths or software components may be used for fronthaul M-plane and C/U-plane for one specific BTS or one specific BTS cell, it is possible that transport issues or software failures only occur for fronthaul C/U-plane but not M-plane, and then sleeping cell problem happens for such scenarios.

However, for fronthaul C/U-plane service, it is lack of a mature and efficient mechanism to detect sleeping cell caused by transport issues or software failures. For example, open RAN CUS-plane may use either eCPRI protocol or Institute of Electrical and Electronic Engineers (IEEE) 1914.3 protocol as its transport. In eCPRI protocol (e.g., eCPRI v2.0) , currently for fronthaul C/U-plane, one delay measurement message type is provided to estimate the one-way delay between eCPRI ports, but this is not suitable to be used to supervise the fronthaul C/U-plane data path as the purpose is very different.

One-way delay measurement can be used for T12 and T34 measurement separately, but it is not used to trigger data path supervision. And normally delay measurement is handled differently than proposed data path supervision (timestamp added by Ethernet hardware for better delay measurement accuracy, more frequent than data path supervision, implemented by different software components than C/U-plane service providers, and focusing more transport delay than fronthaul service availability, etc. ) . Even if it can be enhanced to supervise L2 (over Ethernet) or L3 (over IP/UDP) data path, it still cannot provide end-to-end (E2E) supervision on application level.

In IEEE protocol (e.g., IEEE 1914.3-2018) , there is no mechanism to supervise C/U-plane data path, especially E2E application layer detection for broken data path. Other possible ways are to use detection and supervision mechanisms on different transport sub-layers (hardware diagnostic, physical link loss of signal (LOS) , Ethernet operations, administration, and maintenance (OAM) loopback message (LBM) , MACSec/IPsec failures, Bidirectional Forwarding Detection (BFD) /Internet Control Messages Protocol (ICMP) supervision, etc. ) and correlate these underlayer transport faults to fronthaul C/U-plane service to avoid sleeping cell problem, but all these means have their drawbacks. Fig. 1E illustrates a schematic diagram illustrating detection ways for fronthaul transport problems, using eCPRI protocol as an example.

For instance, as fronthaul transport and application are running on different layers, and different transport network sub-layers may have different issues. It is more and more difficult and complicated to correlate all these underlayer faults to fronthaul C/U-plane service to avoid sleeping cell.

Even there is no failure on underlayer transport, it is still not enough to determine there is no issue for fronthaul C/U-plane service. For example, Ethernet OAM based supervision cannot identify MACSec or IPSec failure as Ethernet OAM packets could be bypassed most probably for some automatic network topology discovery functionality. Also, BTS C/U-plane software could have its own problem to stop providing related service. It is critical to introduce an efficient way to avoid sleeping cells due to all kinds of transport issues or software failures which may be seen from different operator live networks.

In view of the above discussions and analysis, some embodiments of the present disclosure provide a solution for performing supervision on a supervision object. In the solution, a supervision mechanism to eCPRI and IEEE 1914.3 (either could be used by ORAN fronthaul CUS-plane) are introduced, so that E2E fronthaul C/U-plane data path supervision can be done with a regular interval. Then for any failure detected by this supervision mechanism, recovery actions like alarm raising, data path re-selection, or hanging resource clean-up can be triggered to avoid going into sleeping cell situation.

Fig. 2 illustrates an example signaling chart illustrating an example process 200 according to some embodiments of the present disclosure. The process 200 may involve a first device 201 and a second device 202. The first device 201 may be one of the device 110 or the device 120 as shown in Fig. 1A, and the second device 202 may be the other one of the device 110 or the device 120.

With reference to Fig. 2, the first device 201 transmits 210 a request message 211 to the second device 202. The request message is for performing supervision on a supervision object between the first device 201 and the second device 202. If the second device 202 receives 212 the request message, it transmits 213 a response message 214 of the request message to the first device 201. If the first device 201 receives 215 the response message, it determines 220 a status of the supervision object based on the response message.

In some embodiments, the request message may comprise a first field indicative of an identifier of the supervision. For example, there may be serval request message for different supervisions, and the first field may indicate an identifier to distinguish between the different supervision. In this case, the response message may also comprise the first field that is copied from the request message.

Additionally or alternatively, the request message may comprise a second field indicative of a type of the request message or the response message. For example, the second field may indicate the massage is a request message or a response message. In some embodiments, the second field may indicate that the supervision object is a path or a flow. The response message may also comprise the second field.

Additionally or alternatively, the response message may comprise a third field indicative of status information at the second device related to the supervision. In case that the response message is received at the first device 201, the first device 201 may determine status of the supervision object based on the third field in the response message. In some embodiments, the request message may also comprise the third field indicative of status information at the first device related to the supervision.

However, due to all kinds of transport issues or software failures, the second device 202 may fail to receive the request message or the response message does not reach 215 at the first device 201. If the response message is not received within a configurable interval indicated by a timer, the first device 201 may retransmit 216 the request message to the second device 202. On the second device side, it may retransmit 218 the response message upon it receives 217 the request message.

Still, the response message may do not reach 219 at the first device 201 due to all kinds of transport issues or software failures. If no response message is received for a number of transmissions of the request message, the first device 201 may determine a failure to receive the response message. Then, the first device 201 determines 220 a status of the supervision object based on the failure to receive the response message. For example, the first device 201 may determine the failure of the supervision object. In this case, the first device 201 may report the failure of the supervision object to a target device responsible for recovering the supervision object. For example, if the first device 201 is a DU node, it may report 221 the failure of the supervision object to a RU node to recover the supervision object. Alternatively or in addition, if the first device 201 is a RU node, it may perform 221 at least one recovery operation to recover the supervision object. The recovery operation may comprise alarm raising, data path re-selection, or hanging resource clean-up, etc.

The first device 201 may continue the supervision with a regular interval. For example, the first device 201 may transmit 222 a further request message 223 after a configurable interval. Upon receives 224 the further request message, the second device 202 may retransmit 225 a response message of the further request message. In case that the supervision object has been recovered, the first device 201 may receive 227 the response message. Then, the supervision object (e.g., a path or a flow between the first device 201 and the second device 202) can be marked as recovered and C/U-plane traffic can be carried over recovered the supervision object again.

In some embodiments, the request message and the response message may be eCPRI messages. Fig. 3 illustrates a schematic diagram illustrating an eCPRI common header format according to some embodiments of the present disclosure. This message may be referred to as Message Type #12 for data path supervision. It is noted that the detail Message identifier (ID) is to be reserved from eCPRI and #12 is provided as an example.

This message type can be used when one eCPRI node (e.g., the first device 201) requests to supervise the data path towards another node (e.g., the second device 202) . A request message (in this case, it may be named as “Data Path Supervision” request) sent by an eCPRI node (e.g., the first device 201) triggers data path supervision towards another eCPRI node (e.g., the second device 202) . Upon reception of the request message, the eCPRI node can send a response message (in this case, it may be named as “Data Path Supervision” response) with clear response status. The supervision can be done for one data path towards one specific eCPRI node, or it can be done for one specific flow like physical channel, layer, etc. Data Path Supervision messages can be handed by application software components to provide E2E supervision.

Fig. 4 illustrates a schematic diagram illustrating an eCPRI supervision message format according to some embodiments of the present disclosure. In the case that the request message and the response message are eCPRI messages, the first field in the request message and the response message can be the “Supervision ID” field as shown in Fig. 4. The Supervision ID field can be a 1-byte value used by the sender of the request (e.g., the first device 201) when the response is received to distinguish between different supervisions, i.e., the receiver of the request (e.g., the second device 202) can copy the ID from the request into the response message.

In this case, the second field in the request message and the response message can be the “Action Type” field as shown in Fig. 4. The Action Type field can be a 1-byte value described in following Table 1.

Table 1: Action Type

The third field can be the “Action Status” field as shown in Fig. 4. The Action Status field can be a 1-byte value which indicates the peer side with additional information about the status of its side. For example, in the response message to notify the peer side that the supervised path or flow does not exist, so proper recovery action shall be taken. Details described as following Table 2.

Table 2: Action Status

In case that the supervision object is the flow, the request message and the response message may further comprise an ID of the supervised flow. In some embodiments, the ID of the supervised flow can be a physical channel ID (PC_ID) as shown in Fig. 4. The PC_ID could be used as identifier of a physical channel, a layer, etc., when data path supervision is configured on flow level with Action Type field as Flow Request or Flow Response. How to allocate values to PC_ID can be vendor specific. If supervision is planned for Data Path of U-plane like IQ data, action type shall be Flow Request/Response, and PC_ID shall be filled.

In some embodiments, the ID of the supervised flow can be an ID of real-time control (RTC) data flow, e.g., the RTC_ID as shown in Fig. 4. Similar to PC_ID, how to allocate values to RTC_ID can be vendor specific. If supervision is planned for Data Path of Real Time Control Data, action type shall be Flow Request/Response, and RTC_ID shall be filled.

In some embodiments, the request message and the response message may be RoE messages. Fig. 5 illustrates a schematic diagram illustrating an RoE supervision common frame format according to some embodiments of the present disclosure. This message may be referred to as new subType 00000001b for RoE supervision common frame. It is noted that the detail subType is to be reserved from IEEE 1914.3 and 00000001b is provided as an example.

In the case that the request message and the response message are RoE messages, the first field in the request message and the response message can be the “SupID” field as shown in Fig. 5. The supID field can be a 1-byte value used by the sender of the request (e.g., the first device 201) when the response is received to distinguish between different supervisions, i.e., the receiver of the request (e.g., the second device 202) can copy the ID from the request into the response message.

In this case, the second field in the request message and the response message can be the “opCode” field as shown in Fig. 5. The opCode field can be a 1-byte value described in following Table 3.

Table 3: opCode

The third field can be the “opStatus” field as shown in Fig. 5. The opStatus field can be a 1-byte value which indicates the peer side with additional information about the status of its side. For example, in the response message to notify the peer side that the supervised flow does not exist, so proper recovery action shall be taken. Details described as following Table 4.

Table 4: opStatus

In some embodiments, the request message and the response message may further comprise a fourth field indicating that the supervision object is a flow. The fourth field can be the “flowID” field as shown in Fig. 5. The flowID field may keep the same or similar meaning as specified in IEEE 1914.3. Additionally, a flow indicated by a specific value of the fourth field represents a path between the first device 201 and the second device 202. For example, ALL_ONES flowID (i.e., 11111111b) can be filled to RoE supervision frame to supervise the data path of RoE control packets. It should be understood that ALL_ONES flowID is described as an example without suggesting any limitation as to the scope of the disclosure, and any suitable value can be used to indicate the path between the first device 201 and the second device 202.

The “length” field and the “orderInfo” field as shown in Fig. 5 can keep the same or similar meaning as what specified in IEEE 1914.3. The use of the orderInfo field may not be changed as it indicates the real RoE packet order as before.

Fig. 6 illustrates a message sequence diagram 600 for data path supervision according to some embodiments of the present disclosure. The message sequence diagram 600 can be an example of the process 200 as shown in Fig. 2. The message sequence diagram 600 may involve the first device 201 and the second device 202 as shown in Fig. The first device 201 may be one of the device 110 or the device 120 as shown in Fig. 1A, and the second device 202 may be the other one of the device 110 or the device 120.

With reference to Fig. 6, the first device 201 may initiate Data Path Supervision request 601 in direction from the first device 201 to the second device 202. If it is detailed flow level supervision, PC_ID or RTC_ID shall be provided in the message with Action Type field as Flow Request.

The second device 202 may reply Data Path Supervision request with response message 602 (with Action Status field and PC_ID or RTC_ID if needed for flow level supervision) . The first device 201 may wait Data Path Supervision response with Timer T-Response. For any reason if it cannot receive the response from peer side within the timer interval, it sends the request for N-Retry times (e.g., 601-1 to 601-N) . By default, T-Response can be 1s and N-Retry is 10, and these can be configurable.

If the first device 201 fails to receive the response for all the retries, data path failure 603 can be reported so that recovery actions can be taken to avoid sleeping cell situation due to data path failure. The first device 201 may continue Data Path Supervision 604 with regular interval T-Next. Once Data Path Supervision response 605 is received, at 606, data path can be marked as recovered and C/U-plane traffic can be carried over recovered data path again. T-Next is configurable and in some embodiments can be not often than every 60s for every data path not to increase the traffic load of the data path.

With the message sequence diagram 600, embodiments of the present disclosure provide a fronthaul C/U application supervision mechanism to eCPRI and IEEE 1914.3 (either could be used by ORAN fronthaul CUS-plane) so that E2E fronthaul C/U-plane data path supervision can be done with a regular interval. Then for any failure detected by this supervision mechanism, recovery actions like alarm raising, data path re-selection, or hanging resource clean-up can be triggered to avoid going into sleeping cell situation.

Fig. 7 illustrates a schematic diagram illustrating a method 700 implemented at a first device according to some embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the first device 201 as shown in, e.g., Figs. 2 and 6.

As shown in Fig. 7, at block 710, the first device 201 transmit, to the second device 202, a request message for performing supervision on a supervision object between the first device 201 and the second device 202. At block 720, the first device 201 determines a status of the supervision object based on a response message received from the second device 202 or a failure to receive the response message.

The request message may comprise a first field indicative of an identifier of the supervision. For example, in some embodiments, there may be serval request message for different supervisions, and the first field may indicate an identifier to distinguish between the different supervision. In this case, the response message may also comprise the first field that is copied from the request message.

The request message may comprise a second field indicative of a type of the request message or the response message. For example, the second field may indicate the massage is a request message or a response message. In some embodiments, the second field may indicate that the supervision object is a path or a flow. The response message may also comprise the second field.

The response message may comprise a third field indicative of status information at the second device related to the supervision. In case that the response message is received at the first device 201, the first device 201 may determine the status of the supervision object based on the third field in the response message. In some embodiments, the request message may also comprise the third field indicative of status information at the first device related to the supervision.

In some embodiments, if the first device 201 determines a failure to receive the response message, the first device 201 may determine the failure of the supervision object. In some embodiments, if the response message is not received within a configurable interval indicated by a timer, the first device 201 may retransmit the request message to the second device. In some embodiments, if no response message is received for a number of transmissions of the request message, the first device 201 may determine the failure to receive the response message.

In some embodiments, based on determining the failure of the supervision object, the first device 201 may report the failure to a target device responsible for recovering the supervision object. Alternatively or in addition, the first device 201 may perform at least one recovery operation to recover the supervision object.

In some embodiments, the configurable interval is a first interval, and the first device 201 may transmit a further request message after a second configurable interval. In some embodiments, the response message may comprise the same first field copied from the request message.

In some embodiments, the request message and the response message may be eCPRI messages. In some embodiments, the second field in the request message and the response message further indicates that the supervision object is a path or a flow. In some embodiments, in case the supervision object is the flow, the request message and the response message may further comprise an ID of the supervised flow. In some embodiments, the ID of the supervised flow may comprise a physical channel ID. Alternatively, the ID of the supervised flow may comprise an ID of real-time control data flow.

In some embodiments, the third field in the response message may indicate success of the supervision. Alternatively, the third field in the response message may indicate a supervised path being not configured. Alternatively, the third field in the response message may indicate a supervised flow being not configured.

In some embodiments, the request message and the response message may be RoE messages. In some embodiments, the request message and the response message may further comprise a fourth field indicating that the supervision object is a flow. In some embodiments, a flow indicated by a specific value of the fourth field may represent a path between the first device and the second device.

In some embodiments, the third field in the response message may indicate success of the supervision. Alternatively, the third field in the response message may indicate a supervised flow being not configured.

Fig. 8 illustrates a schematic diagram illustrating a method 800 implemented at a second device according to some embodiments of the present disclosure. For the purpose of discussion, the method 700 will be described from the perspective of the second device 202 as shown in, e.g., Figs. 2 and 6.

As shown in Fig. 8, at block 810, the second device 202 receives, from the first device 201, a request message for performing supervision on a supervision object between the first device 201 and the second device 202. At block 820, the second device 202 transmits, to the first device 201, a response message of the request message.

The response message may comprise a third field indicative of status information at the second device related to the supervision. In case that the response message is received at the first device 201, the first device 201 may determine status of the supervision object based on the third field in the response message. In some embodiments, the request message may also comprise the third field indicative of status information at the first device related to the supervision.

In some embodiments, the second device 202 may receive a retransmission of the request message from the first device 201 after a first configurable interval indicated by a timer. Moreover, the second device 202 may transmit, to the first device 201, a response message of the retransmission of the request message.

In some embodiments, the second device 202 may receive a further request message from the first device after a second configurable interval. Moreover, the second device 202 may transmit, to the first device 201, a response message of the further request message. In some embodiments, the response message may comprise the same first field copied from the request message.

In some embodiments, the third field in the response message may indicate success of the supervision. Alternatively, the third field in the response message may indicate a supervised path being not configured, in case the the supervision object is a path and the path does not exist. Alternatively, the third field in the response message may indicate a supervised flow being not configured, in case the the supervision object is a flow and the flow does not exist.

In some embodiments, the third field in the response message may indicate success of the supervision. Alternatively, the third field in the response message may indicate a supervised flow being not configured, in case the the supervision object is a flow and the flow does not exist.

In some embodiments, an apparatus capable of performing any of the method 700 (for example, the first device 201) may comprise means for performing the respective steps of the method 700. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some embodiments, the apparatus comprises: means for transmitting, at a first device and to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and means for determining a status of the supervision object based on a response message received from the second device or a failure to receive the response message. At least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In some embodiments, the means for determining the status of the supervision object comprises means for: based on receiving the response message from the second device, determining the status of the supervision object based on the third field in the response message; or means for based on determining the failure to receive the response message, determining the failure of the supervision object.

In some embodiments, the apparatus further comprises means for based on determining that the response message is not received within a configurable interval indicated by a timer, retransmitting the request message to the second device.

In some embodiments, the means for determining the failure to receive the response message comprises means for: based on determining that no response message is received for a number of transmissions of the request message, determining the failure to receive the response message.

In some embodiments, the apparatus further comprises means for based on determining the failure of the supervision object, reporting the failure to a target device responsible for recovering the supervision object; or means for performing at least one recovery operation to recover the supervision object.

In some embodiments, the configurable interval is a first interval, and the apparatus further comprises means for transmitting a further request message after a second configurable interval. In some embodiments, the response message may comprise the same first field copied from the request message.

In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 700. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

In some embodiments, an apparatus capable of performing any of the method 800 (for example, the second device 202) may comprise means for performing the respective steps of the method 800. The means may be implemented in any suitable form. For example, the means may be implemented in a circuitry or software module.

In some embodiments, the apparatus comprises: means for receiving, at a second device and from a first device, a request message for performing supervision on a supervision object between the first device and the second device; means for transmitting, to the first device, a response message of the request message. At least one of the request message or the response message comprises at least one of the following: a first field indicative of an identifier of the supervision, a second field indicative of a type of the request message or the response message, or a third field indicative of status information at the first device or the second device related to the supervision.

In some embodiments, the apparatus further comprises means for receiving a retransmission of the request message from the first device after a first configurable interval indicated by a timer; and means for transmitting, to the first device, a response message of the retransmission of the request message.

In some embodiments, the apparatus further comprises means for receiving a further request message from the first device after a second configurable interval; and means for transmitting, to the first device, a response message of the further request message. In some embodiments, the response message may comprise the same first field copied from the request message.

In some embodiments, the apparatus further comprises means for performing other steps in some embodiments of the method 800. In some embodiments, the means comprises at least one processor and at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

Fig. 9 is a simplified block diagram of a device 900 that is suitable for implementing embodiments of the present disclosure. The device 900 may be provided to implement the communication device, for example the first device 201, or the second device 202 as shown in Figs. 2 and 6. As shown, the device 900 includes one or more processors 910, one or more memories 920 coupled to the processor 910, and one or more communication modules 940 coupled to the processor 910.

The communication module 940 is for bidirectional communications. The communication module 940 has at least one antenna to facilitate communication. The communication interface may represent any interface that is necessary for communication with other network elements.

The processor 910 may be of any type suitable to the local technical network and may include one or more of the following: general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples. The device 900 may have multiple processors, such as an application specific integrated circuit chip that is slaved in time to a clock which synchronizes the main processor.

The memory 920 may include one or more non-volatile memories and one or more volatile memories. Examples of the non-volatile memories include, but are not limited to, a Read Only Memory (ROM) 924, an electrically programmable read only memory (EPROM) , a flash memory, a hard disk, a compact disc (CD) , a digital video disk (DVD) , and other magnetic storage and/or optical storage. Examples of the volatile memories include, but are not limited to, a random access memory (RAM) 922 and other volatile memories that will not last in the power-down duration.

A computer program 930 includes computer executable instructions that are executed by the associated processor 910. The program 930 may be stored in the ROM 920. The processor 910 may perform any suitable actions and processing by loading the program 930 into the RAM 920.

The embodiments of the present disclosure may be implemented by means of the program 930 so that the device 900 may perform any process of the disclosure as discussed with reference to Figs. 2 to 8. The embodiments of the present disclosure may also be implemented by hardware or by a combination of software and hardware.

In some embodiments, the program 930 may be tangibly contained in a computer readable medium which may be included in the device 900 (such as in the memory 920) or other storage devices that are accessible by the device 900. The device 900 may load the program 930 from the computer readable medium to the RAM 922 for execution. The computer readable medium may include any types of tangible non-volatile storage, such as ROM, EPROM, a flash memory, a hard disk, CD, DVD, and the like. Fig. 10 shows an example of the computer readable medium 1000 in form of CD or DVD. The computer readable medium has the program 930 stored thereon.

Generally, various embodiments of the present disclosure may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device. While various aspects of embodiments of the present disclosure are illustrated and described as block diagrams, flowcharts, or using some other pictorial representations, it is to be understood that the block, apparatus, system, technique or method described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present disclosure also provides at least one computer program product tangibly stored on a non-transitory computer readable storage medium. The computer program product includes computer-executable instructions, such as those included in program modules, being executed in a device on a target real or virtual processor, to carry out the method 700 or the method 800 as described above with reference to Figs. 7 and 8. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, or the like that perform particular tasks or implement particular abstract data types. The functionality of the program modules may be combined or split between program modules as desired in various embodiments. Machine-executable instructions for program modules may be executed within a local or distributed device. In a distributed device, program modules may be located in both local and remote storage media.

Program code for carrying out methods of the present disclosure may be written in any combination of one or more programming languages. These program codes may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the program codes, when executed by the processor or controller, cause the functions/operations specified in the flowcharts and/or block diagrams to be implemented. The program code may execute entirely on a machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present disclosure, the computer program codes or related data may be carried by any suitable carrier to enable the device, apparatus or processor to perform various processes and operations as described above. Examples of the carrier include a signal, computer readable medium, and the like.

The computer readable medium may be a computer readable signal medium or a computer readable storage medium. A computer readable medium may include but not limited to an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of the computer readable storage medium would include an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM) , a read-only memory (ROM) , an erasable programmable read-only memory (EPROM or Flash memory) , an optical fiber, a portable compact disc read-only memory (CD-ROM) , an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. The 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) .

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the present disclosure, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

Although the present disclosure has been described in languages specific to structural features and/or methodological acts, it is to be understood that the present disclosure defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.

Claims

A first device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the first device at least to:

transmit, to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and

determine a status of the supervision object based on a response message received from the second device or a failure to receive the response message,

wherein at least one of the request message or the response message comprises at least one of the following:

a first field indicative of an identifier of the supervision,

a second field indicative of a type of the request message or the response message, or

a third field indicative of status information at the first device or the second device related to the supervision.
The first device of claim 1, wherein the determination of the status of the supervision object based on the reception of the response message from the second device is indicated by the third field in the response message; and wherein the failure to receive the response message indicates a failure of the supervision object.
The first device of claim 1 or 2, wherein the first device is further caused to:

based on determining that the response message is not received within a configurable interval indicated by a timer, retransmit the request message to the second device.
The first device of any of claims 1-3, wherein the first device is caused to determine the failure to receive the response message based on determining that no response message is received for a number of transmissions of the request message.
The first device of claim 4, wherein the first device is further caused to at least one of the following:

based on determining the failure of the supervision object, report the failure to a target device responsible for recovering the supervision object; or

perform at least one recovery operation to recover the supervision object.
The first device of any of claims 1-5, wherein the configurable interval is a first interval, and the first device is further caused to:

transmit a further request message after a second configurable interval.
The first device of any of claims 1-6, wherein the response message comprises the same first field copied from the request message.
The first device of any of claims 1-7, wherein the request message and the response message are enhanced Common Public Radio Interface (eCPRI) messages.
The first device of claim 8, wherein the second field in the request message and the response message further indicates that the supervision object is a path or a flow.
The first device of claim 9, wherein in case the supervision object is the flow, the request message and the response message further comprise an identifier (ID) of the supervised flow.
The first device of claim 10, wherein the ID of the supervised flow comprises at least one of the following:

a physical channel ID; or

an ID of real-time control data flow.
The first device of any of claims 8-11, wherein the third field in the response message indicates one of the following:

success of the supervision;

a supervised path being not configured; or

a supervised flow being not configured.
The first device of any of claims 1-7, wherein the request message and the response message are Radio over Ethernet (RoE) messages.
The first device of claim 13, wherein the request message and the response message further comprise a fourth field indicating that the supervision object is a flow.
The first device of claim 14, wherein a flow indicated by a specific value of the fourth field represents a path between the first device and the second device.
The first device of any of claims 13-15, wherein the third field in the response message indicates one of the following:

success of the supervision; or

a supervised flow being not configured.
A second device comprising:

at least one processor; and

at least one memory storing instructions that, when executed by the at least one processor, cause the second device at least to:

receive, from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and

transmit, to the first device, a response message of the request message,

wherein at least one of the request message or the response message comprises at least one of the following:

a first field indicative of an identifier of the supervision,

a second field indicative of a type of the request message or the response message, or

a third field indicative of status information at the first device or the second device related to the supervision.
The second device of claim 17, wherein the second device is further caused to:

receive a retransmission of the request message from the first device after a first configurable interval indicated by a timer; and

transmit, to the first device, a response message of the retransmission of the request message.
The second device of claim 17 or 18, wherein the second device is further caused to:

receive a further request message from the first device after a second configurable interval; and

transmit, to the first device, a response message of the further request message.
The second device of any of claims 17-19, wherein the response message comprises the same first field copied from the request message.
The second device of any of claims 17-20, wherein the request message and the response message are enhanced Common Public Radio Interface (eCPRI) messages.
The second device of claim 21, wherein the second field in the request message and the response message further indicates that the supervision object is a path or a flow.
The second device of claim 22, wherein in case that the supervision object is the flow, the request message and the response message further comprise an identifier (ID) of the supervised flow.
The second device of claim 23, wherein the ID of the supervised flow comprises at least one of the following:

a physical channel ID; or

an ID of real-time control data flow.
The second device of any of claims 21-24, wherein the second device is further caused to configure the third field in the response message to indicate one of the following:

success of the supervision;

a supervised path being not configured, in case the the supervision object is a path and the path does not exist; or

a supervised flow being not configured, in case the the supervision object is a flow and the flow does not exist.
The second device of any of claims 17-20, wherein the request message and the response message are Radio over Ethernet (RoE) messages.
The second device of claim 26, wherein the request message and the response message further comprises a fourth field indicating that the supervision object is a flow.
The second device of claim 27, wherein a flow indicated by a specific value of the fourth field represents a path between the first device and the second device.
The second device of any of claims 26-28, wherein the second device is further caused to configure the third field in the response message to indicate one of the following:

success of the supervision; or

a supervised flow being not configured, in case the the supervision object is a flow and the flow does not exist.
A method comprising:

transmitting, at a first device and to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and

determining a status of the supervision object based on a response message received from the second device or a failure to receive the response message,

wherein at least one of the request message or the response message comprises at least one of the following:

a first field indicative of an identifier of the supervision,

a second field indicative of a type of the request message or the response message, or

a third field indicative of status information at the first device or the second device related to the supervision.
A method comprising:

receiving, at a second device and from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and

transmitting, to the first device, a response message of the request message,

wherein at least one of the request message or the response message comprises at least one of the following:

a first field indicative of an identifier of the supervision,

a second field indicative of a type of the request message or the response message, or

a third field indicative of status information at the first device or the second device related to the supervision.
An apparatus comprising:

means for transmitting, at a first device and to a second device, a request message for performing supervision on a supervision object between the first device and the second device; and

means for determining a status of the supervision object based on a response message received from the second device or a failure to receive the response message,

wherein at least one of the request message or the response message comprises at least one of the following:

a first field indicative of an identifier of the supervision,

a second field indicative of a type of the request message or the response message, or

a third field indicative of status information at the first device or the second device related to the supervision.
An apparatus comprising:

means for receiving, at a second device and from a first device, a request message for performing supervision on a supervision object between the first device and the second device; and

means for transmitting, to the first device, a response message of the request message,

wherein at least one of the request message or the response message comprises at least one of the following:

a first field indicative of an identifier of the supervision,

a second field indicative of a type of the request message or the response message, or

a third field indicative of status information at the first device or the second device related to the supervision.
A computer readable medium comprising program instructions that, when executed by an apparatus, cause the apparatus to perform at least one of the methods of claims 30 and 31.