WO2020192938A1 - Entité de réseau et procédé de prise en charge de détection de défaillance de réseau - Google Patents

Entité de réseau et procédé de prise en charge de détection de défaillance de réseau Download PDF

Info

Publication number
WO2020192938A1
WO2020192938A1 PCT/EP2019/057954 EP2019057954W WO2020192938A1 WO 2020192938 A1 WO2020192938 A1 WO 2020192938A1 EP 2019057954 W EP2019057954 W EP 2019057954W WO 2020192938 A1 WO2020192938 A1 WO 2020192938A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
network entity
network
indication message
irregularity
Prior art date
Application number
PCT/EP2019/057954
Other languages
English (en)
Inventor
Ömer BULAKCI
Serkan AYAZ
Panagiotis SPAPIS
Chan Zhou
Josef Eichinger
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to PCT/EP2019/057954 priority Critical patent/WO2020192938A1/fr
Publication of WO2020192938A1 publication Critical patent/WO2020192938A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/02—Capturing of monitoring data
    • H04L43/028—Capturing of monitoring data by filtering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/04—Arrangements for maintaining operational condition
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/08—Testing, supervising or monitoring using real traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H04W4/44—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P] for communication between vehicles and infrastructures, e.g. vehicle-to-cloud [V2C] or vehicle-to-home [V2H]

Definitions

  • the present disclosure relates to the field of wireless communication networks.
  • the disclosure specifically proposes a network entity, a method and a computer program for supporting network fault detection.
  • next generation of mobile and wireless communications namely, the fifth generation (5G)
  • 5G fifth generation
  • eMBB enhanced mobile broadband
  • URLLC ultra-reliable low latency communications
  • mMTC massive machine-type communications
  • enhanced Vehicular to everything can be seen as a special 5G service type, which includes both safety and non-safety services, e.g., according to 3GPP TS 22.186 - Service requirements for enhanced V2X scenarios.
  • One of the key requirements for eV2X services is the critical latency (e.g., 3-10ms) and the reliability (e.g., 99.999% and higher).
  • Further requirements are, for example, key performance indicators (KPIs), which may need to be adapted on demand, due to new application requests, for instance, Level of Automation (LoA) change, dynamic group-UE formations, or network changes (network congestion to core network and/or access network entities, mode of transmission / operation change).
  • KPIs key performance indicators
  • Next Generation Radio access networks need to support V2X /URLLC services for user plane (UP), control plane (CP) or both, in order to ensure that the reliability and coverage requirements are met.
  • UP user plane
  • CP control plane
  • a faulty cell can be caused by an access node that is no longer properly functioning, however, has not generated any fault detection trigger at an operation and maintenance (OAM) domain.
  • OAM operation and maintenance
  • Such fault can occur due to different reasons: e.g. hardware (HW), software (SW), or firmware (FW) issues.
  • a fault can also occur at different levels, e.g., a total failure where an entire cell may stop functioning properly, or only a partial failure where some component carriers/part of the protocol stack may stop functioning properly.
  • NFs network functions
  • E2E end-to-end
  • Another example could be detecting a faulty cell by means of offline post-processing checks made through, e.g., Call Detailed Record.
  • the MNO would have to collect vast amount of data and would have to then delete the data after a recovery, and may have to repeat the process.
  • Such a solution may not be optimal, since it would be too slow in detection.
  • embodiments of the present invention aim to provide a network entity 100 and method for supporting network fault detection.
  • An object is thereby to provide ultra-high availability and ultra-high resilience, e.g., for V2X and/or URLLC services, and fault detection as early as possible, in order to reduce safety issues and impact on mission-critical services caused by faulty cells or other fault may occur in the network.
  • a first aspect of the invention provides a network entity for supporting network fault detection, wherein the network entity is configured to: monitor expected traffic from at least one terminal device; and provide an indication message to a fault management entity and/or to a recovery entity, when determining an irregularity in the expected traffic within a predetermined time interval.
  • a failure or fault can be detected as soon as possible, in order to enable the ultra-reliability and low latency of e.g. a V2X/URLLC service.
  • the predetermined time interval can be adjusted during the runtime or can be pre-configured, e.g., via a fault management entity.
  • the predetermined time interval may be set or adjusted by the network entity, as well, or jointly by fault management and the network entity.
  • the fault management may provide policies for the time interval and the network entity can determine the time interval, e.g., based on the monitored statistics or obtained statistics.
  • the statistics may be obtained from a data analytics function, wherein the data analytics function can be a network data analytics function (NWDAF) in a core network (CN), or a management data analytics function (MDAF) in a management layer, or a data analytics function in the RAN.
  • the fault management entity may be part of the management layer or part of management and orchestration layer, which may operate on long-timescale statistics and may cooperate with the recovery entity for recovery solutions, where these recovery solutions can be of long-timescale.
  • the network entity can be a node, e.g., a physical node or virtual node in the network, or a network function, e.g., implemented as a virtual network function (VNF) or a physical network function (PNF).
  • VNF virtual network function
  • PNF physical network function
  • a VNF implementation may have the advantage that the network entity may be deployed or instantiated at different parts of the network, e.g., in a central unit (CU) of RAN, or in a management layer.
  • the indication message includes at least one of: an irregularity report; and a fault detection trigger.
  • the irregularity report may be provided to the fault management entity and/or the fault detection trigger may be provided to the recovery entity.
  • the network e.g. RAN
  • the network can react fast to a fault or failure in the network, e.g. by determining which specific entity shall react to the failure.
  • the irregularity report can be utilized by the fault management entity to generate a fault detection trigger that can be then provided to the recovery entity.
  • the fault management entity may receive one or more irregularity reports from one or more network entities.
  • the one or more irregularity reports can be utilized to detect a fault and to generate a fault detection trigger.
  • the network entity is further configured to: determine the irregularity, when the expected traffic is not received within the predetermined time interval.
  • the network entity can accordingly determine the irregularity, if the fault or failure can be recognized by the network entity, and can therefore support a faster recovery.
  • the time interval may depend on the service type, e.g., an URLLC service may have shorter time interval compared to an eMBB service.
  • the indication message includes a reliability level regarding the determination of the irregularity.
  • the fault management entity can determine how likely it is that there is a fault or failure in the network.
  • the recovery unit may determine the need of the execution of the recovery based on the reliability level. If the reliability level is high, i.e., there is likely a fault, the recovery entity may perform the recovery immediately after receiving the indication message.
  • the network entity is further configured to: provide the indication message to the recovery entity, when the reliability level is above a pre selected threshold.
  • the network entity may only provide the indication message to the recovery entity, when the reliability level is above the pre-selected threshold can make the fault detection in the network (e.g. RAN) more efficient, since only more reliably detected faults or failures are reported.
  • the reliability level and the threshold/thresholds can be implemented in different ways such that the notion of being above or below a threshold may result in the same action.
  • the threshold or thresholds may be implemented in the form of ranges, e.g., between a minimum and maximum value.
  • the network entity is further configured to: determine the reliability level and/or the pre-selected threshold based on at least one conditions of: a number of the at least one monitored terminal device and a number of monitored applications generating the expected traffic thereof
  • Applications that are generating traffic patterns can be characterized more deterministically and/or devices that can generate more characteristic signaling, for example, static sensors generating keep-alive signals, can be used to determine the reliability level and/or the preselected threshold, in order to make the fault detection more efficient or reliable. This is due to the fact that only highly likely faults or failures will be determined and need to be addressed.
  • the at least one terminal device to be monitored can be selected based on the signaling or traffic generated. During the runtime different devices or applications can be monitored. For instance, if the irregularity is monitored at the terminal devices with more characteristic signaling and/or the irregularity is monitored at more than one terminal device, the reliability level of fault detection can be increased.
  • the expected traffic includes at least one of an application level signaling and a network-level signaling.
  • the application level signaling includes at least one of a: keep-alive signal, Cooperative Awareness Message (CAM), tele-operated driving (ToD) signal, and
  • the network-level signaling includes at least one of event-based signaling and periodic signaling.
  • the event-based signal is a location reporting triggered by an area event and/or a motion event of one or more terminal devices.
  • the network entity can detect different kinds of faults or failures under different situations.
  • the ToD is also known as remote driving.
  • the application level signaling can be at least one of a signaling generated for a service, e.g., ToD.
  • Such application-level signaling can be selected based on the criterion how well the signaling can be characterized, e.g., in terms of periodicity.
  • the network entity is further configured to : register with the recovery entity and/or with another network entity, in order to cooperate in monitoring the expected traffic and/or in order to obtain configuration information indicating how to monitor, what to monitor and/or when to provide the indication message.
  • the registration between the network entity and recovery entity and/or another network entity can enable the network entity to monitor different types of expected traffic in the network. It can also share the indication message with the recovery entity and/or the another network entity, or can provide early notification, e.g. in case of mission critical services.
  • the configuration of the network entity may be obtained from another network entity.
  • the another network entity can be of the same type of the network entity, can be an agent of the network entity (e.g. the network entity is a Detection Function (DF) and the another network entity is a DF agent), or a fault management entity.
  • DF Detection Function
  • the another network entity may be implemented in another RAN access node, where the network entity and another network entity may communicated via the inter-access node interface, e.g., Xn interface or intra-access node interface, e.g., FI interfaces, as specified by 3GPP.
  • inter-access node interface e.g., Xn interface
  • intra-access node interface e.g., FI interfaces
  • the network entity is further configured to: send the indication message also to the another network entity.
  • the network entity is configured to be configured by the fault management entity.
  • the network entity is further configured to: transmit a notification to the at least one terminal device, said notification indicating the determined irregularity.
  • Such an indication message can be provided to another network entity or entities based on the registration.
  • the at least one terminal device can have access to, e.g., V2X and/or URLLC services such that the indication message can be used to avoid service interruption.
  • the network entity is further configured to: send the indication message to another network entity, for providing a second indication message by the another network entity to the fault management entity and/or to the recovery entity.
  • indication messages can be forward or a new indication message including the fault information and/or irregularity information can be generated to the fault management entity as more flexible for network entity.
  • the network entity is further configured to perform at least one of: receive location information and/or traffic information provided by a location management unit, concerning the at least one terminal device, and monitor the expected traffic based on the location information and/or the traffic information.
  • the facilitation of the location management unit makes the fault detection more efficient.
  • the location management unit can be in the form of a location management function (LMF) and/or Location Management component (LMC) and/or Distributed LMF.
  • LMF location management function
  • LMC Location Management component
  • Distributed LMF Distributed LMF
  • the network entity is a RAN entity, in particular implemented in or as a Central Unit, Distributed Unit, or User Equipment, or the network entity is a CN entity, the network entity is a Management or Orchestration entity, or the network entity is implemented in an application server or implemented as an application entity.
  • the network entity When the network entity is implemented as a network function, the network entity can be implemented in different parts of the network, e.g., at a cluster head user equipment (UE) in a group communication.
  • UE cluster head user equipment
  • a second aspect of the present invention provides a method for supporting network fault detection, comprising: monitoring expected traffic from at least one terminal device; and providing an indication message to a fault management entity and/or to a recovery entity, when determining an irregularity in the expected traffic within a predetermined time interval.
  • the method may be developed according to the features of the various implementation forms of the network entity of the first aspect described above.
  • a third aspect of the present invention provides a computer program comprising a program code for carrying out, when implemented on a processor, the method according to the above mentioned method.
  • FIG. 1 illustrates a network entity according to an embodiment of the invention.
  • FIG. 2 shows a diagram illustrating network entities according to embodiments of the invention, which are Detection Functions (DFs) implemented at different domains and in different network elements in the 5GS.
  • FIG. 3 shows schematically an example of a regular operation in a cell, in accordance with at least one embodiment of the invention.
  • FIG. 4 shows schematically an example of DF operation, when an irregularity is found and an associated trigger is sent to a FM entity, in accordance with at least one embodiment of the invention.
  • FIG. 5 shows a message sequence chart illustrating how a DF can be operated in a 5GS, in accordance with at least one embodiment of the invention.
  • FIG. 6 illustrates utilization of application- level expected V2X/URLLC traffic to detect a fault in a 5GS, in accordance with at least one embodiment of the invention.
  • FIG. 7 illustrates utilization of application- level expected V2X/URLLC traffic to detect a fault in a 5GS, where FallBackNotification messages are used, in accordance with at least one embodiment of the invention.
  • FIG. 8 illustrates utilization of application- level expected V2X/URLLC traffic to detect a fault in a 5GS, where network exposure mechanisms are utilized along with the involvement of the application server, in accordance with at least one embodiment of the invention.
  • FIG. 9 illustrates utilization of network-level expected signalling to detect a fault in a
  • FIG. 10 illustrates utilization of network-level expected signaling to detect a fault in a
  • FIG. 11 shows a message sequence chart illustrating DF configuration by an FM entity, in accordance with at least one embodiment of the invention.
  • FIG. 12 shows a message sequence chart illustrating DF registration with NFs, in accordance with at least one embodiment of the invention.
  • FIG. 13 shows a message sequence chart illustrating DF registration with NFs in case of distributed implementations and via DF-R, in accordance with at least one embodiment of the invention.
  • FIG. 14 is a block diagram of a method according to an embodiment of the invention.
  • FIG. 1 shows a network entity 100 according to an embodiment of the invention.
  • the network entity 100 is configured to support network fault detection.
  • the network entity 100 is thus also referred to in this document as“Detection Function (DF)”.
  • the network entity 100 may be implemented in a network node of e.g. a RAN network, e.g. in a base station.
  • the network entity 100 may also be implemented in a mobile terminal, a vehicle, a sensor, a cluster head UE, a central unit (CU), a distributed unit (DU), an (edge) User Plane Function (UPF) and/or an application server in the network.
  • a network node e.g. a RAN network
  • DU central unit
  • UPF User Plane Function
  • the network entity 100 is configured to monitor expected traffic 101 from at least one terminal device 102.
  • the terminal device 102 may be a UE or mobile device, and/or may be a vehicle or sensor.
  • the expected traffic 101 may include at least one of an application level signaling and a network-level signaling.
  • the application level signaling may include at least one of a keep-alive signal, a CAM, a ToD signal, and a HD Local Map signal.
  • the network- level signaling may include at least one of an event-based signaling and a periodic signaling.
  • the network entity 100 is further configured to provide an indication message 103 to a fault management entity 104 and/or to a recovery entity 105, when determining an irregularity in the expected traffic 101 within a predetermined time interval. That is, the network entity 100 may monitor the expected traffic 101, determine whether the expected traffic 101 shows an irregularity, and generates and sends the notification message 103 if detecting an irregularity.
  • FIG. 2 shows network entities 100 according to embodiments of the invention, which base on the network entity 100 shown in FIG. 1.
  • the network entities 100 are referred to as“Fault DFs” (i.e. each network entity 100 implements a DF, i.e. the DFs are also labelled with reference sign 100 in the following).
  • the DFs 100 are configured to discover irregularities in the network traffic.
  • the traffic may pertain to the different parts of the network.
  • a DF at the DU can monitor the traffic between the DU and the UE(s), while a DF at the CU can additionally monitor the traffic on the FI interface.
  • the network traffic that can be monitored by a DF can also depend on the implementation location.
  • a DF at the application server may more easily monitor the application- level signaling.
  • a DF 100 may generate and send an indication message 103, which may include irregularity reporting and/or a fault detection trigger.
  • the indication message 103 may be transmitted to trigger an Agile Recovery Mechanisms in the RAN, i.e. may be provided to a recovery entity 105.
  • the DFs 100 may be configured by a central DF 100 or may be configured by a FM entity 104.
  • a DF 100 can analyze patterns in/of the expected traffic 101. Thereby, repeated traffic patterns may be taken as the expected traffic 101, such as keep-alive signals, tele- operated driving (ToD) signals, HD Local Map signals and/or Cooperative Awareness Messages (CAMs). This provides a good means of traffic“expectation”, since such signals are typically transmitted periodically. If the expected traffic 101 does not arrive for a pre determined time interval At, the DF 100 can trigger the indication message 103. The indication message 103 may include a reliability level regarding the determination of the irregularity in the expected traffic 101.
  • the DF 100 can analyze user plane (U-Plane, aka UP) data flows as wells as control plane (C-plane, aka CP) signaling.
  • the DF 100 may also interact with a Header Compression function (ROHC) at a Packet Data Convergence Protocol (PDCP), e.g., a Type of Service (ToS) field.
  • PDCP Packet Data Convergence Protocol
  • the DF 100 can be implemented as a standalone RAN function, or can be implemented as a part of an existing RAN functionality, e.g. a radio resource control (RRC), radio resource management (RRM), or self-organizing network (SON) extension.
  • FIG. 2 shows multiple DFs 100, which are implemented at different network elements (terminal device 102, DU, CU, UPF, Application Server), and can each monitor expected traffic 101 to be utilized for the failure detection.
  • the expected traffic 101 can include different types of signals for different DFs 100. Due to low- latency requirements, DFs 100 may be preferred to be located close to the edges of the network.
  • a DF 100 providing an indication message 103 can be triggered by a lack of application-level expected signaling, e.g. lack of a keep-alive signal or CAM in a geographical area.
  • a DF 100 providing an indication message 103 can be triggered by a lack of expected network-level signaling, e.g. lack of a positioning reporting.
  • a DF 100 providing an indication message 103 can be triggered by a lack of expected event-based network signaling, e.g. multiple radio link failures (RLFs), in a geographical area.
  • RLFs radio link failures
  • keep-alive signals of vehicles, Vehicle Sensors, UEs, and/or of internet of things (IoT) devices can be utilized, in order to detect failures/faults/faulty cells or nodes on-time.
  • Keep-alive signals also referred to as“heart beats” of terminal devices 102
  • applications of the terminal devices 102 e.g., smartphone always-on applications & IoT applications
  • Each terminal device 102 may further have several applications with different keep-alive signal characteristics.
  • the terminal devices 102 can be of UE type, which can be in the order of tens, or can be machines, which can be in the order of thousands. Some of these terminal devices 102 may also be static devices, e.g., sensors or semi-dynamic devices, e.g., a V2X UE or a drone. It can be expected that machines generate more predictable keep-alive signals to report their status.
  • the DF 100 can generate the indication message 103, when one or more of the keep-alive signals stop fully in a given cell for a given time interval At, and may communicate, as the indication message 103, specifically an irregularity/anomaly report and/or a fault detection trigger to the FM entity 104 and/or to the recovery entity 105.
  • the recovery entity 105 may operate more functions than just recovering a fault.
  • the recovery entity 105 may be an entity that is able to operate any function that facilitates fault detection or recovery, for example, providing a network function of registration, network exposure, and/or location management etc. Therefore, the recovery entity 105 can also considered as a failure detection assisting entity.
  • FIG. 3 illustrates a regular operation in a cell, when there are exemplarily a UE1 and a plurality of IoT/Sensors (i.e. terminal devices 102) in the cell.
  • the terminal devices 102 are served by a base station (gNBl).
  • FIG. 4 illustrates exemplarily, how the detection of a fault occurs in the same cell as shown in FIG. 3, namely when keep-alive signals stop for the time interval At (without a stop detection request from edge equipments or an initiative detection stop by the gNBl).
  • the predetermined time interval At provides a degree of freedom to adapt to different characteristics of different keep-alive signals. At can in particular depend on the application type, or can be pre-determined by the FM entity 104 depending on the existing applications.
  • IAT packet inter-arrival time
  • the IAT can be obtained, e.g., via traffic traces from real network.
  • the DF 100 may determine that for the given interval At time interval, the keep-alive signals from a single UE, or multiple UEs, or all UEs (and from a single or from multiple applications), and/or the keep-alive signals from one or more machines (e.g. IoT/Sensors) in a cell are not received anymore. This implies that with a high probability this cell is a faulty cell, i.e., it is highly unlikely that the expected keep-alive signals stop in the cell for any other reason than a fault.
  • the DF 100 may in this case inform the FM entity 104, or any other management node or function, such that necessary measures can be taken on-time.
  • an Agile Recovery Mechanism e.g. configured by the FM entity 104, may take the necessary measures to mitigate the faulty cell condition, e.g., perform Fail-safe Protocol Configuration (e.g., activating a duplicate protocol stack as of PHY or MAC layer to generate the same or similar RF signals), Resetting the Cell (Deactivate & Activate the cell), or Extending the cell coverage areas of the neighboring cell & resetting the cell.
  • Fail-safe Protocol Configuration e.g., activating a duplicate protocol stack as of PHY or MAC layer to generate the same or similar RF signals
  • Resetting the Cell Deactivate & Activate the cell
  • FIG. 5 shows a message sequence chart (MSC) illustrating how a DF 100 (network entity 100) can be operated in a 5GS.
  • UEs such as mobile phones, or one or more vehicles (i.e. generally terminal devices 102) may end (application level) keep-alive signals to a 5G base station (gNB) or to a road side unit (RSU).
  • the DF 100 is in FIG. 5 implemented exemplarily in/by the gNB or RSU, analyzes the expected traffic 101, and can discover an irregularity by monitoring in particular whether the keep-alive signals stop fully in a given cell for the predetermined time interval At. If such an irregularity is discovered, and optionally the fault likelihood or the reliability level is additionally very high, a fault detection trigger (i.e.
  • an indication message 103) can be triggered e.g. to an Agile Recovery function implemented by the recovery entity 105.
  • the reliability level may be analyzed by the DF 100, for instance, by determining whether the detection reliability is above a pre-selected threshold value (ThX), which threshold may depend on the network deployment, access node type, services/applications that are supported, and/or statistics collected. For example, the reliability level and the threshold may be determined on the basis of a percentage or number of irregularity devices in the whole of the terminal devices 102, or on the bases of a percentage or number of irregularity applications generating the expected traffic 101.
  • ThX pre-selected threshold value
  • the DF 100 may make use of network context, for example, via self- learning algorithms that can interface with data analytics such as MDAF as in the management layer and NWDAF as in the core network (CN). These data analytics functions are to some extent specified by 3GPP.
  • a data analytics function can also be implemented in the RAN, e.g., at a central unit (CU), such that the DF 100 may interface with such a data analytics function in RAN.
  • the DF 100 can be implemented inside a data analytics function, e.g., as one of the features of a data analytics function.
  • the indication message 103 is sent by the DF 100 to the recovery entity 103 (exemplarily implemented by a Failsafe Node configurator (FNC)) and a RAN Recovery Mechanism is triggered.
  • the FNC can e.g. activate a protocol stack, which can overtake the operation of the failed part of the protocol stack. For instance, by way of providing a failsafe protocol configuration to the DF 100, and then performing an agile fault recovery, e.g. failsafe protocol execution.
  • the DF 100 may send an event notification to an operation administration management (OAM) domain, which may implement the FM entity 104, so that the FM entity 104 is informed about the above actions.
  • the event notification may comprise event statistics, which may include a type of the event and the time interval, the recovery mechanism, and the current status.
  • the indication message 103 may be provided by the DF 100 to the FM entity 104 together with event information, even when the fault likelihood is small, i.e. the determined reliability level is below the threshold.
  • the FM entity 104 may then analyze the event information, and may determine whether a recovery mechanism should still be taken, and what type of recovery mechanism should be taken.
  • the first alternative in which the indication message 103 is provided to the recovery entity 105, given that the detection reliability level is above the pre selected threshold, has the advantage that the fault recovery mechanisms can be performed with less delay.
  • the second alternative has the advantage that a recovery mechanism is only performed if the FM entity decides that this is necessary.
  • FIG. 6 illustrates further embodiments of the network entity 100, which build on the network entity 100 shown in FIG. 1.
  • V2X/URLLC traffic 101 such as CAM signals or V2X/URLLC related semi-persistent scheduling (SPS) signals
  • SPS semi-persistent scheduling
  • CAM signals are typically transmitted periodically, and the transmission rate may be/change, e.g., between 100 ms to 1000 ms.
  • Two exemplary cases (“Case 1” and“Case 2”) are considered in FIG. 6, in which cases CAM signals or V2X/URLLC related SPS signals are utilized to detect a fault.
  • a central unit (CU) of a gNB can set a SPS based on an UEAssistantcelnformation signal (UE assistance information) in a Radio Resource Control (RRC) message.
  • RRC Radio Resource Control
  • the message sequence chart (shown in the upper right of FIG. 6) is an example how the network, e.g. gNB, gets the UE assistance information from a UE.
  • an indication message 103 can be generated by a DF agent 100 in a Distributed Unit (DU).
  • a DF agent 100 may be a network entity 100 that functions as an agent to the DF 100. That is, the DF agent 100 may be configured to perform the same functions than the DF 100, and may report and/or may be registered with the DF 100.
  • a DF 100 in in a gNB-type RSU may determine that the reception of CAM messages has stopped.
  • an indication message 103 e.g. a fault detection trigger and/or irregularity report, can be generated by the DF 100.
  • a gNB may be disaggregated, which means that it may be split into CU and one or more distributed units (DUs).
  • a DF agent 100 may be implemented in a DU, and a DF agent 100 may be implemented in a RSUs.
  • the DF agents 100 may generate irregularity reports, wherein a central DF 100 (here at the CU) or DF agent 100 (e.g. at the RSU) may trigger an alarm (indication message 103) on the failure to the FM entity 104.
  • the indication message 103 can include information on the event, e.g., time stamp, reliability level, type of the event, where or at which node the event occurred.
  • the indication message 103 may be directly or indirectly sent to the FM entity 104.
  • a cluster head (CH) of UEs (here mobile terminals (MTs)) has a DF agent 100, which may also generate an indication message 103, and e.g. send it to a DF agent 100 in a DU or RSU. If a DF 100 or the FM entity 104 receives multiple indication messages 103, it may combine the information received to decide on a fault. Here, combining may imply a joint consideration.
  • DF agents 100 may be configured by a central DF 100 or by the FM entity 104.
  • terminal devices 102 may provide a FallBackNotification (fall back notification) message to a neighboring access node, or DU, or a master cell group (MCG) or secondary cell group (SCG) in case of multi-connectivity, when the terminal devices 102 stop getting SPS grants on the Uu interface and they fall back to NR mode 2.
  • the FallBackNotification may provide details on the event, for example, a time stamp and cell ID where the event happened.
  • the FallBackNotification(s) may be used by a DF agent 100 or DF 100 at the DU, in order to generate an indication message 103.
  • the content and/or the number of the FallBackNotification messages can indicate, e.g. a type of the fault and a reliability level of a fault existence. For example, the increased number of FallBackNotifications can imply a higher chance of fault.
  • the DU may be implemented in the form of a road-side unit (RSU). This scheme may also apply to non-disaggregated access nodes, such as gNBs, where the FallBackNotification(s) can be sent to a neighboring gNB.
  • RSU road-side unit
  • two Mobile Terminals (MTs) 102 which may also be in a multi-connectivity mode, stop getting SPS grants from a DU1 on the Uu interface. Accordingly, they may fall back on a NR mode 2, and transmit the FallBackNotification messages to a DU2, which implements a DF agent 100.
  • the DF agent 100 of DU2 e.g., if the number of FallBackNotifications is high, may determine that a reliability level is high, and may transmit an indication message 103 (irregularity report and/or fault detection trigger), which may include the multiple FallBackNotifications, to the gNB-CU which implements another DF 100, which can be of the form of a central DF.
  • the DF 100 at the gNB-CU may trigger another indication message 103 (irregularity report and/or fault detection trigger), indicating that the DU1 failed and e.g., information on the event, to the FM entity 104.
  • another indication message 103 (irregularity report and/or fault detection trigger), indicating that the DU1 failed and e.g., information on the event, to the FM entity 104.
  • a V2X Application Server implementing a DF 100
  • it may trigger an indication message 103.
  • the application server may not know what the cause of the fault (or the network topology) is.
  • the application server may send an APP DF Trigger / Irregularity Report Message to a Network Exposure Function/Service Capability Exposure Function/Exposure Governance management Function (NEF/SCEF/EGMF), and the exposure function(s) can forward this or generate a new indication message 103 comprising the fault information to OAM and/or per domain FM entity 104.
  • the FM entity 104 can initiate a healing trigger and interact, such as via probes and report requests, with the involved network sub-nets to identify where the exact failure is (e.g. which gNB, RSU, etc.).
  • the FM entity 104 can send FM analytics for the particular domain, which has the failure (e.g.
  • RAN management data analytics function
  • MDAF management data analytics function
  • CN core network
  • CP/UP control plane/user plane
  • multiple application servers may report about the irregularity messages, e.g., about the keep alive signal, then the network can know there is a problem.
  • network-level expected traffic 101 can be utilized to detect failures/faults/faulty cells or nodes in the network, e.g., 5GS.
  • One such example is the periodic and triggered location reporting.
  • 3GPP TR23.731 sets the requirement on Periodic and Triggered Focation Reporting, where different triggers are outlined, such as Area event (UE entering, leaving or remaining with the area) and Motion event (UE moving by more than a threshold straight line distance from a previous location).
  • the DF 100 can coordinate with a location management unit, e.g., location management function/ location management component (FMF/FMC), to predict a fault via, for example, lack of Periodic Focation Reporting, trajectory estimate, or Predicted Focation Reporting, such as, considering the velocity of the MT along with Motion Event, in other words, predicted Focation Reporting in a pre-determined time at a predicted range of location, and the pre-determined time is based on the velocity of the MT along with Motion Event.
  • a location management unit e.g., location management function/ location management component (FMF/FMC)
  • FMF/FMC location management function/ location management component
  • the DF 100 can register for the notification of the location reporting and/or trajectory estimate, for configuration information indicating how to monitor, what to monitor and/or when to provide the indication message 103.
  • the service registration can be made between DF 100 and location management function (FMF) and/or a local FMF (FFMF) in the RAN (also may be referred to as location management component, LMC).
  • FMF location management function
  • FFMF local FMF
  • LMC location management component
  • LMF in the CN and LMC in RAN may also coordinate.
  • MTs 102 can register for location service (LCS) periodic- triggered event at LMF and/or LMC.
  • LMF and/or LMC can predict an area event after a time interval (in FIG.
  • 9 tl-tO which may indicate a At time difference) considering a predicted trajectory of the MTs 102, e.g., based on the velocity, speed, initial location, and/or location history.
  • DF 100 and/or a location management entity can determine that a location reporting trigger has not been initiated by the MTs considering the predicted trajectory of the MTs 102.
  • Such a notice can imply a fault and can trigger an irregularity report and/or fault detection trigger (indication message 103). This can be sent to an FM entity 104.
  • the number of MTs 102 that are not sending such location request(s) can be an indication for the reliability level of the failure, in other words, a threshold can be set for determine that how many of such notice is a highly likely fault in the network needs to initiate recovery. This can be also a group MTs 102 performing group communications.
  • FIG. 10 A further embodiment is illustrated in FIG. 10, and uses Radio Link Failures (RLFs) for checking a lack of (network-level) expected traffic 101.
  • RLFs Radio Link Failures
  • Multi-connectivity is a solution, e.g., to enable the Zero-Handover Interruption Time requirement set by IMT-2020.
  • MT(s) 102 can connect to multiple DUs that are served by the same or different CU(s).
  • the collection of the RLFs of a DU can be utilized to detect a failure and, for example, to determine which specific DU has caused the RLF.
  • a DU failure can result in multiple path switches to other DU(s) in case of multi-connectivity.
  • a DF 100 implemented in the CU can analyze this information to generate an indication message 103 (irregularity report and/or fault detection trigger). Such information can be shared with the FM entity 104, as illustrated in FIG. 10.
  • the indication message 103 can comprise type(s) of irregularity, detection reliability level, and detection granularity (such as DU or interface). If more than one CU serves the DUs, the DFs 100 or DF agents 100 may coordinate over an inter-access node interface, e.g., Xn interface. DFs 100 in different CUs may communicate over Xn interface.
  • the DF 100 here implemented in the CU, generates an irregularity report, i.e. indication message 103, to the FM entity 104.
  • the DF 100 can be configured by the FM entity 104, which may be located in an OAM. The configuration mechanism of this embodiment is shown in FIG. 11 in an MSC.
  • the DF 100 analyzes the expected traffic 101 and may discover an irregularity.
  • the traffic analysis can include interaction between DF and a location management unit.
  • an irregularity report (indication message 103) can be triggered to the FM entity 104.
  • the FM entity 104 can configure the DF 100, for example, based on slice requirements, and such a configuration can include sensitivity comprising the reliability level. According to the sensitivity, the DF 100 and/or DF agent 100 may generate a fault detection trigger and/or send an irregularity report, periodic or event based, slice-based configuration (for example, a slice type of URLLC or V2X may require more strict failure detection), and whether the DF 100 and/or DF agent 100 shall first inform the FM entity 104, or can inform the failure recovery mechanisms.
  • the FM entity 104 can trigger the Agile Fault Recovery, e.g., by triggering a self- organizing network (SON) function.
  • SON self- organizing network
  • the DF 100 and/or DF agent 100 may interact with other NFs and/or network elements (such as UEs 102 and access nodes). This can be, for example, based on a service offered as in a case of service based architecture (SB A).
  • SB A service based architecture
  • An embodiment of service request and registration among a DF 100 and NFs is shown in FIG. 12.
  • the DF 100 is shown as a standalone function for simplicity but as shown previously it may be collocated with other nodes (e.g., gNB/RSU, 5GC).
  • Other NFs and/or network elements may register for traffic analysis.
  • the DF 100 can send a traffic analysis subscription request, which can be followed by a response, such as ACK (Acknowledge signal), NACK (Not Acknowledge signal), and Configuration Update for adapting new state of the network in time.
  • the traffic analysis subscription request may comprise Traffic Analysis Type, Time Granularity of Reporting, Area of reporting, Type of reporting, e.g., event-based, UE IDs to be analyzed. This can enable the DF to observe different types of the traffic in the 5GS.
  • an irregularity report or fault detection trigger can be shared with the registered NFs and/or network elements. Further, early notification can be sent to at least one of the UEs 02, preferably registered UEs 102, for notification indicating the determined irregularity, e.g., with the mission critical services and over non-failed radio interfaces.
  • the non-failed radio interface can be a radio interface of a neighboring access node.
  • the early notification which indicates the determined irregularity, may be transmitted to the registered UEs 102 when the indication message 103 is generated to the FM entity 104 and/or the recovery entity 105, so that the UE 102 can make early emergency action, such as reset, self-recovery, fall back to NR mode 2, fall back to unlicensed access, or stop.
  • the DF registration may be performed by a DF registration function (marked as DF-R) device, for example, in distributed implementations.
  • DF-R DF registration function
  • the DF-R can send a traffic analysis subscription request, which can be followed by a response, such as ACK, NACK, and Configuration Update.
  • the traffic analysis subscription request may comprise Traffic Analysis Type, Time Granularity of Reporting, Area of reporting, Type of reporting, e.g., event-based, UE IDs to be analyzed.
  • the DF-R is implemented for the registration to the UEs gNB/RSU, 5GC (here exemplarily FMF), and OAM (FM).
  • the registration for 5GC is for detection of event-based predicted traffic by FMF.
  • DF and/or FMF can determine that a location reporting trigger has not been initiated by the UEs 102 considering the predicted trajectory of the UEs 102. Such a notice can imply a fault detection trigger and be sent to the FM entity 104.
  • FIG. 14 shows block diagram of a method 1400 for supporting network fault detection.
  • the method 1400 comprises: a step 1401 of monitoring expected traffic 101 from at least one terminal device 102; and a step 1402 of providing an indication message 103 to a fault management (FM) entity 104 and/or to a recovery entity 105, when determining an irregularity in the expected traffic 101 within a predetermined time interval.
  • the method 1400 can be carried out by the network entity/DF 100 or DF agent 100 described above.
  • embodiments of the invention provide a network entity 100, method and computer program for supporting network fault detection, so that the network can benefit from the improvement of the low latency and high reliability.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Mining & Analysis (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne la détection de défaillance dans un réseau. En particulier, l'invention concerne une entité de réseau, un procédé et un programme informatique pour prendre en charge une telle détection de défaillance de réseau. L'entité de réseau est configurée pour surveiller un trafic attendu à partir d'au moins un dispositif terminal, et pour fournir un message d'indication à une entité de gestion de défaut et/ou à une entité de récupération, lors de la détermination d'une irrégularité dans le trafic attendu dans un intervalle de temps prédéterminé. Ainsi, le réseau peut bénéficier d'améliorations pour une latence plus faible et de fiabilité supérieure.
PCT/EP2019/057954 2019-03-28 2019-03-28 Entité de réseau et procédé de prise en charge de détection de défaillance de réseau WO2020192938A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/057954 WO2020192938A1 (fr) 2019-03-28 2019-03-28 Entité de réseau et procédé de prise en charge de détection de défaillance de réseau

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2019/057954 WO2020192938A1 (fr) 2019-03-28 2019-03-28 Entité de réseau et procédé de prise en charge de détection de défaillance de réseau

Publications (1)

Publication Number Publication Date
WO2020192938A1 true WO2020192938A1 (fr) 2020-10-01

Family

ID=65995740

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2019/057954 WO2020192938A1 (fr) 2019-03-28 2019-03-28 Entité de réseau et procédé de prise en charge de détection de défaillance de réseau

Country Status (1)

Country Link
WO (1) WO2020192938A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113190370A (zh) * 2021-05-08 2021-07-30 京东数字科技控股股份有限公司 一种应用的应急响应方法及装置
CN115460635A (zh) * 2021-06-08 2022-12-09 中国移动通信集团重庆有限公司 故障检测方法、装置、设备及计算机存储介质
US11902804B2 (en) 2022-01-04 2024-02-13 Cisco Technology, Inc. Fault triage and management with restricted third-party access to a tenant network

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140201353A1 (en) * 2013-01-16 2014-07-17 Hewlett-Packard Development Company, L.P. Connectivity notification
US20160134503A1 (en) * 2014-11-07 2016-05-12 Arbor Networks, Inc. Performance enhancements for finding top traffic patterns
WO2017072356A1 (fr) * 2015-10-29 2017-05-04 Opt/Net Consulting B.V. Détection d'anomalie dans un flux de données

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140201353A1 (en) * 2013-01-16 2014-07-17 Hewlett-Packard Development Company, L.P. Connectivity notification
US20160134503A1 (en) * 2014-11-07 2016-05-12 Arbor Networks, Inc. Performance enhancements for finding top traffic patterns
WO2017072356A1 (fr) * 2015-10-29 2017-05-04 Opt/Net Consulting B.V. Détection d'anomalie dans un flux de données

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
HUAWEI ET AL: "Proposal for monitoring events", vol. SA WG6, no. Osaka, Japan; 20180521 - 20180525, 28 May 2018 (2018-05-28), XP051544898, Retrieved from the Internet <URL:http://www.3gpp.org/ftp/tsg%5Fsa/WG6%5FMissionCritical/TSGS6%5F024%5FOsaka/docs/S6%2D180883%2Ezip> [retrieved on 20180528] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113190370A (zh) * 2021-05-08 2021-07-30 京东数字科技控股股份有限公司 一种应用的应急响应方法及装置
CN115460635A (zh) * 2021-06-08 2022-12-09 中国移动通信集团重庆有限公司 故障检测方法、装置、设备及计算机存储介质
US11902804B2 (en) 2022-01-04 2024-02-13 Cisco Technology, Inc. Fault triage and management with restricted third-party access to a tenant network

Similar Documents

Publication Publication Date Title
US11943663B2 (en) Device and method for providing a quality of service function
US11323341B2 (en) Methods and apparatus for capturing and/or using packets to facilitate fault detection
CN112188533B (zh) 一种网络性能的上报方法及装置
US10367565B2 (en) Communications methods and apparatus using multiple beams
US11252007B2 (en) Methods and apparatus for supporting use of multiple beams for communications purposes
US9351188B2 (en) Wireless base station device, wireless system, and failure detection method
WO2020192938A1 (fr) Entité de réseau et procédé de prise en charge de détection de défaillance de réseau
CN109996216B (zh) 订阅请求处理方法、网络实体及能力开放平台
US20210273890A1 (en) Devices and methods for time sensitive communication in a communication network
US20210385646A1 (en) End to end troubleshooting of mobility services
WO2020052775A1 (fr) Dispositif et procédé pour la fourniture d&#39;une fonction de qualité de service
EP4018608A1 (fr) Procédé de commande de la disponibilité de communication dans un système cyber-physique
WO2022150156A1 (fr) Opérations de carte de blocage
CN111919463B (zh) 用于呼叫建立失败控制的方法和装置
CN113169763B (zh) 用于5g通信网络中服务连续性的设备和方法
EP4189940A1 (fr) Mécanisme de commande pour améliorer la fiabilité de communication

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19714636

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19714636

Country of ref document: EP

Kind code of ref document: A1