A method of network diagnosis in a telecommunications network, a server and a computer program

GB2642470APending Publication Date: 2026-01-14VODAFONE PROCUREMENT CO SARL
View PDF 4 Cites 0 Cited by

Patent Information

Application Number
GB2024009958
Authority / Receiving Office
GB · GB
Patent Type
Applications
Current Assignee / Owner
Filing Date
2024-07-09
Publication Date
2026-01-14

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

A method to diagnose issues in a telecommunications network. A diagnosis may be initiated by a periodic timer, 1101, or by an alarm, 1102. At 1103 / 1104, a diagnosis procedure is triggered on a network
Need to check novelty before this filing date? Find Prior Art

Description

Field of the invention

[0001] The present invention relates to monitoring and diagnosing issues in a telecommunications network. In particular, the invention relates to testing connections between network nodes, based on the specific network hardware involved. Glossary loT - Internet of Things ICP - Internet Content Provider IP - Internet Protocol PSTN - Public Switched Telephone Network PBX - Private Branch Exchange MCU - Multi Control Unit O-DU - Open Distributed Unit O-CU - Open Central Unit O-RU - Open Radio Unit PHY - Physical Layer (L1) MAC - Medium Access Control (L2) RLC - Radio Link Control (L2) PDCP - Packet Data Convergence Protocol (L3) RRC - Radio Resource Control (L3) SDAP - Service Data Adaptation Protocol BF - Beamforming D to A - Digital to Analogue IFFT - Inverse Fast Fourier Transform RE - Resource Element PDSCH - Physical Downlink Shared Channel RAN - Radio Access Network O-RAN - Open RAN Alliance SMO - Service Management and Orchestration RIC - RAN Intelligent Controller Near-RT RIC - Non-Real-Time RAN Intelligent Controller Non-RT RIC - Near-Real-Time RAN Intelligent Controller O-eNB - Open Evolved Node B O-CU-CP - Open Central Unit Control Plane O-CU-UP - Open Central Unit User Plane CUS-Plane - Control User Synchronization Plane M-Plane - Management Plane MME - Mobility Management Entity SGW (or S-GW) - Serving Gateway PGW (or P-GW) - Packet Data Network Gateway RRU - Remote Radio Unit vRAN - Virtual RAN CU - Centralized Unit DU - Distributed Unit BSS - Business Support System. OSS - Operations Support System 5GC - 5G Core Network IMS - IP Multimedia Subsystem HTTP - Hypertext Transfer Protocol JSON - JavaScript Object Notation NSSF - Network Slice Selection Function AUSF - Authentication Server Function UDM - Unified Data Management NEF - Network Exposure Function NRF -Network Repository Function AMF - Access and Mobility Management Function SMF - Session Management Function PCF - Policy Control Function AF - Application Function UPF - User Plane Function DN - Data Network NG-RAN - Next Generation RAN NR-mm - New Radio millimetre wave N3IWF - Non-3GPP Interworking Function RO - Regional Office HQ - Headquarters LAN - Local Area Network DMZ - De-Militarized Zone CO - Central Office BB - Broadband Routers BR - Branch Routers SDN - Software Defined Network MEC - Multi-access Edge Computing CloT - Cellular Internet of Things C-SGN - CloT Serving Gateway Node SCEF - Service Capability Exposure Function EPS - Evolved Packet System EPC - Evolved Packet Core eSIM - embedded Subscriber Identity Module IPSec - Internet Protocol Security loT - Internet of Things C-Plane - Control Plane U- Plane - User Plane OS - Operating System API - Application Programming Interface SW - Software HW - Hardware OSI - Open Systems Interconnection Al - Artificial Intelligence UE - User Equipment BS - Base Station ABS - Advanced Base Station BTS - Base Transceiver Station BSS - Basic Service Set ESS - Extended Service Set AP - Access Point NB - Node B (Radio Base Station Receiver) eNB - Evolved Node B gNB - Next-Generation Node B TRP - Transmission and Reception Point PS - Processing Server TE - Terminal Equipment MS - Mobile Station MT - Mobile Terminal LIT - User Terminal SS - Subscriber Station PDA - Personal Digital Assistant CDMA - Code Division Multiple Access FDMA - Frequency Division Multiple Access TDMA - Time Division Multiple Access OFDMA - Orthogonal Frequency Division Multiple Access SC-FDMA - Single Carrier Frequency Division Multiple Access MC-FDMA - Multicarrier Frequency Division Multiple Access UTRA - Universal Terrestrial Radio Access GSM - Global System for Mobile Communications (2G) GSMA - GSM Association GPRS - General Packet Radio Service EDGE - Enhanced Data Rates for GSM Evolution IEEE - Institute of Electrical and Electronics Engineers E-UTRA-Evolved UTRA UMTS - Universal Mobile Telecommunications System (3G) E-UMTS - Evolved UMTS 3GPP - 3rd Generation Partnership Project DL - Downlink UL-Uplink LTE - Long Term Evolution (4G) LTE-A - LTE-Advanced NR - New Radio (5G) FDD - Frequency Division Duplex TDD - Time Division Duplex CRS - Cell-specific Reference Signal CSI-RS - Channel State Information Reference Signal FPGA - Field-Programmable-Gate-Array ASIC - Application-Specific-lntegrated-Circuit DSP - Digital-Signal-Processor CD-ROM - Compact Disc Read-Only Memory DVD-ROM - Digital Versatile Disc Read-Only Memory ROM - Read-Only Memory RAM - Random-Access Memory EEPROM - Electrically Erasable Programmable Read-Only Memory EPROM - Erasable Programmable Read-Only Memory Background

[0002] When network faults occur in a telecommunications network, the fault is detected and an alarm / ticket is raised to flag the fault. The telecommunications network could be running over a Mobile Network, Fixed Access network, Fibre network, Satellite network or any combination of these defined configurations. Due to the broad range of different network technologies employed in telecommunications network, a variety of different faults are possible. The telecommunications network is operated by a service provider to provide connectivity between two endpoints or nodes, including loT devices.

[0003] Prior art methods for identifying network faults involve raising an alarm and logging a Fault Ticket. It is beyond the scope of prior art fault identification systems to perform diagnosis of the fault and identification of the cause of the problem. Tickets are raised for human network engineers to investigate. No clear and detailed root-cause of the problem is provided on the ticket. Diagnosis of the problem is completely left to the technical human experts’ understanding, expertise, experience, and interpretation to plan the next steps to address the fault.

[0004] US7933212B2 describes methods and apparatus to diagnose enhanced interior gateway routing protocol problems in networks by automatically performing one or more tests of one or more routers of the network in response to a submitted trouble ticket.

[0005] US2012078565A1 describes reflective maintenance records for a network. Test results are mirrored from different testing applications to a centralized testing database.

[0006] US2010214932A1 describes analyzing Layer 3 network performance between a network and its Intelligent Route Service Control Point architecture to identify problems without having to disrupt customer service.

[0007] None of the existing methods are able to identify faults in any Layer from 2 through 7 of the OSI model and raise an alarm / ticket that includes clear diagnostic information identifying the cause of the problem. Summary

[0008] A method of issue diagnosis in a telecommunications network comprising a plurality of network nodes is provided. The method comprises triggering an issue diagnosis procedure on a network connection between two network nodes in the telecommunications network. The method further comprises querying a network equipment database to identify network equipment associated with the network connection. The method further comprises performing one or more diagnostic tests on the network connection, wherein the one or more diagnostic tests are based on the identified network equipment. The method further comprises generating a report comprising results from the one or more diagnostic tests.

[0009] Most of the prior art solutions deployed by network operators to log network faults perform no pre-diagnosis and do not provide specific and accurate diagnostics and log data to identify the cause of the fault within the network. In contrast, the proposed methods provide detailed diagnostics with the ticket.

[0010] The proposed issue diagnosis procedure may be triggered automatically on detection of the fault. Therefore, real-time diagnosis and log data may be provided that is more relevant to the network fault. In contrast, a human network engineer attempting to reproduce the issue at a later stage may be unable to exactly replicate the network conditions that caused the fault to arise.

[0011] Prior art solutions generally only flag the presence of an issue but rely on human input to diagnose the issue and plan for a resolution. In contrast, the proposed methods may perform issue diagnosis to identify and isolate problem in more detail, in order to plan for a resolution.

[0012] Moreover, prior art approaches to fault resolution may be dependent on a definition of a service level agreement between the network operator and the customer. Some issues may therefore not be addressed if the network engineers cannot justify the time required to investigate minor issues with little to no impact on the customer’s service level agreement (irrespective of any understanding of the root cause of the fault). In contrast, the proposed methods may enable issue diagnosis to be performed automatically, so that even minor issues (that may otherwise go ignored) may be addressed.

[0013] Prior art methods are dependent on the skill of the human engineer. Therefore, some tickets may be handled more effectively than others, due the differing levels of proficiency of the engineers in performing fault diagnosis. In contrast, the proposed methods provide advanced diagnostic techniques that may be applied to every ticket, so that detailed diagnostic information is provided with each ticket, without relying on the capabilities of human engineers. This may improve the overall issue resolution rate and quality.

[0014] Where this document refers to a “network node”, this may be understood to include endpoint devices connected to the network, as well as intermediary devices such as routers, load balancers, gateways, modems, access points, multiplexers, modulators, firewalls, session border controllers, and the like.

[0015] Where this document uses the term “network connection”, this may be understood to refer to a connection between nodes in a general sense, without specifically referring to any one particular layer of the OSI model. In contrast, where this document used the term, “network link”, this may be understood to refer to an L3 connection between logical nodes (such as an IP connection).

[0016] Likewise, where this document uses the term “node”, this may be understood to refer generally to nodes at any layer of the OSI model. In contrast, the term “logical node” may be understood to refer to an L3 node.

[0017] The one or more diagnostic tests may be selected based on the identified network equipment.

[0018] The one or more diagnostic tests may be selected from a plurality of possible diagnostic tests.

[0019] In this document, the term “telecommunications network” may be understood to refer to the network as a whole. The telecommunications network may comprise a plurality of sub-networks conforming to different network standards. For example, a telecommunications network may comprise one or more of: a mobile network (which may also be referred to as a cellular network and may comprise a radio access network), a fixed access network (which may be a fibre network), a transport network, and a satellite network.

[0020] “Issue diagnosis” may include fault diagnosis. Moreover, issue diagnosis may be performed even if there is no fault. Issue diagnosis may be performed periodically to determine whether a fault is present (but could discern that there is no fault).

[0021] “Issue diagnosis” may refer to diagnosis of networking issues () and / or diagnosing problems at the application layers (i.e., layers 6 and 7).

[0022] Performing one or more diagnostic tests on the network connection may comprise performing a plurality of diagnostic tests, wherein one or more of the diagnostic tests is selected based on a result of a preceding diagnostic test of the plurality of diagnostic tests.

[0023] In other words, the diagnostic tests may be performed in the manner of a state machine or “rule engine”.

[0024] The diagnostic tests may be based on the identified network equipment.

[0025] Moreover, the rules defining the order of the tests (and defining which tests are performed based on the outcome of previous tests) may be based on the network equipment. In other words, the rule engine may operate differently depending on the particular network equipment.

[0026] Performing one or more diagnostic tests on the network connection may comprises testing a logical link between the two network nodes by sending a test message via the logical link using an L3 protocol.

[0027] The network connection may comprise a plurality of logical nodes. Each logical node may be adjacent to at least one other logical node. Performing one or more diagnostic tests on the network connection may further comprise, for each pair adjacent of logical nodes in the plurality of logical nodes, sending a test message between the adjacent nodes using an L2 protocol.

[0028] The logical link may comprise the plurality of logical nodes.

[0029] The L2 test may be performed in the event that the test of the logical link (the L3 connection) does not identify a fault.

[0030] Performing one or more diagnostic tests on the network connection may further comprise testing the network connection by sending a test message between the two network nodes using an L4 protocol, L5 protocol, L6 protocol and / or L7 protocol.

[0031] Performing one or more diagnostic tests on the network connection may further comprise running one or more logical commands on application software running on the identified network equipment.

[0032] An outcome of the logical commands on the application software may be used to identify and isolate application errors and software / telecommunication outages (i.e., faults at the L6 and L7 layers).

[0033] The L4 test may be performed in the event that the test of the logical node pairs (the L2 connection) does not identify a fault.

[0034] If the L4 test does not identify a fault, an L5 test may be performed, and so on, up to L7.

[0035] Identifying the network equipment associated with the network connection may comprise determining one or more of: a Common Language Information Services, CLEI, code of the network equipment, one or more network identifiers of the network equipment, a manufacturer of the network equipment, a brand of the network equipment, and a model of the network equipment.

[0036] Identifying the network equipment associated with the network connection may comprise detecting an identifier (e.g. serial number) of the network equipment and looking up further details (e.g., manufacturer, brand and / or model) in a database.

[0037] Each of the one or more diagnostic tests may be selected from a plurality of different options, wherein each of the plurality of different options is associated with a particular CLEI code, manufacturer, brand, or model, and wherein the diagnostic test is selected based on the determined CLEI code, manufacturer, brand, or model of the identified network equipment.

[0038] Each of the plurality of different options may be different / unique.

[0039] The report may further comprise an outcome selected from a plurality of possible outcomes. The method may further comprise selecting one of the plurality of possible outcomes, based on the results from the one or more diagnostic tests.

[0040] Selecting one of the plurality of possible outcomes may comprise classifying a network performance of the telecommunications network using a machine learning model.

[0041] The plurality of possible outcomes may be associated with a particular CLEI code, manufacturer, brand, or model of the identified network equipment.

[0042] The list of possible outcomes may be specific to each network equipment.

[0043] The set of rules executed by the rule-engine between two end points of the network may be specific to the network equipment and may also be associated with a list of possible outcomes.

[0044] Triggering the issue diagnosis procedure may be based on one or more of: identification of a fault between the two network nodes; and a periodic timer.

[0045] A fault may be identified between the two network nodes and / or in the network connection.

[0046] Identification of a fault may comprise one or more of: detecting an Internet Protocol, IP, addressing error, detecting an application error, detecting a fragmentation error, detecting a flow control error, detecting a Cyclic Redundancy Check, CRC, failure, and detecting a hardware addressing error.

[0047] An application error may be referred to as an “outage”. Application errors may be detected in L6 or L7 of the OSI model.

[0048] The telecommunications network may comprise one or more of: a mobile network, a fixed access network, a fibre network, and a satellite network.

[0049] A server configured to perform any of the methods described above is also provided.

[0050] A computer program comprising instructions that, when executed on a processor, cause the processor to perform any of the methods described above is also provided. Brief description of the drawings

[0051] Fig. 1. illustrates an example telecommunications network.

[0052] Fig. 2 illustrates some of the protocols in use at different Layers in Open RAN architecture.

[0053] Fig 3. illustrates the interaction of different components in an Open RAN mobile network.

[0054] Fig. 4 illustrates differences between 4G and 5G network architecture.

[0055] Fig. 5 illustrates APIs and interfaces of network functions in a mobile network.

[0056] Fig. 6 illustrates interaction between different network functions in a mobile network.

[0057] Fig. 7 illustrates a Fixed Access network according to a specific example.

[0058] Fig. 8 illustrates a Satellite network according to a specific example.

[0059] Fig. 9 illustrates data flow in a telecommunications network comprising different network architectures.

[0060] Fig. 10 illustrates an OSI model according to some examples.

[0061] Fig. 11 illustrates a schematic flow diagram according to a specific example.

[0062] Fig. 12. illustrates a specific example of rule engine logic.

[0063] Fig. 13. illustrates another specific example of rule engine logic. Detailed description

[0064] An example telecommunications network is illustrated in Fig. 1. As shown in Fig. 1, a telecommunications network may comprise several different sub-networks, the subnetworks may conform to a number of different network architecture standards, depending on the requirements of the telecommunications network operator and their customers. The proposed methods of issue diagnosis may therefore be applied to a range of different network architectures.

[0065] The network illustrated in Fig. 1 comprises a Mobile Network, Fixed Access network, Fibre network, and a Satellite network

[0066] To perform issue diagnosis on the telecommunications network, methods of issue diagnosis are proposed (as well as a server configured to perform the methods, which may be referred to as a “rule engine”). The proposed methods perform automatic diagnosis between two nodes (which may include end points) within the telecommunications network.

[0067] Diagnosis may be performed in real-time. In other words, the diagnostic tests may be performed when the issue is ongoing, rather than after the fact. This means that the network conditions for the diagnostic tests are the same as the network conditions when the fault was produced, and the results of the diagnostic tests may therefore be more relevant.

[0068] Issue diagnosis may be performed periodically, as well as when an alarm is triggered.

[0069] Once automatic issue diagnosis is complete, the proposed system generates a report comprising the results from the diagnostic tests. The report may be referred to as a “ticket” and may comprise an outcome, which may also be referred to as a “diagnosis conclusion code”. The report may therefore provide a clear identification of a cause of the fault in the network, with details of pre-diagnosis performed on the known network environment and its equipments.

[0070] The rule engine may also be synchronised with a network equipment database. The network equipment database may maintain a register of all known network components (using a unique CLEI code) within the defined telecommunications network. When issue diagnosis is triggered, the proposed system may query the network equipment database, determine the network equipment details, and perform a set of diagnostic tests (which may be referred to as “commands”). The specific diagnostic tests performed may be based on based on rules specific to the network architecture and equipment. The commands are run to check the status of the nodes and connections and collect relevant information, as defined in the rules.

[0071] If the rule engine identifies a fault during the execution of its commands, it will log a ticket, which may comprise a diagnosis conclusion code. The diagnosis conclusion code may be unique to the set of rules executed by the rule-engine between the two nodes of the network (and specific to each network equipment). The proposed solution can be used for existing network architecture and for future network architectures, including Open-RAN 5G, 6G and beyond, including mobile loT architecture for both business and consumer. Example network architectures are illustrated in Figures 1 to 6.

[0072] Different examples of Mobile Network architecture are illustrated in Figs. 2 to 6.

[0073] Fig. 2 illustrates some of the protocols in use at different Layers in Open RAN architecture.

[0074] Fig 3. illustrates the interaction of different components in an Open RAN mobile network.

[0075] Fig. 4 illustrates some differences between 4G and 5G network architecture and highlights network components that are proprietary and network components that are open.

[0076] Fig. 5 illustrates APIs and interfaces of network functions in a mobile network.

[0077] Fig. 6 illustrates interaction between different network functions in a mobile network.

[0078] Fig. 7 illustrates a Fixed Access network, which is a Fibre network in the specific example shown.

[0079] Fig. 8 illustrates a Satellite network, which is used to provide connectivity for loT devices in the specific example illustrated.

[0080] Fig. 9 illustrates data flow in a telecommunications network comprising different network architectures.

[0081] Fig. 10 illustrates an OSI model according to some examples.

[0082] An example of the proposed solution is described with reference to the general flow diagram illustrated in Fig. 11, which provides a functional working overview of the specific example. As described previously, the proposed methods are suitable for checking for issues, identifying issues, and diagnosing issues in Layers 2 to 7 of the OSI model. In this way, the proposed solution provides an improved method for network fault diagnosis in a telecommunications network. As described elsewhere, the telecommunications network may comprise mobile network, fixed access network, fibre network, satellite network, or any combination of these defined configurations by the service provider, between two endpoints or nodes (including loT devices).

[0083] Referring to Fig. 11, issue diagnosis may be triggered automatically at step 1101 (e.g., by a periodic timer), or may be triggered by an alarm at step 1102. Either trigger is received at step 1103 and leads to triggering an issue diagnosis procedure at step 1104. A network equipment database is queried at step 1105. A rule engine may be queried at step 1106. As part of the issue diagnosis procedure, one or more diagnostic tests are performed (based on the identified network equipment). Based on a result of each diagnostic test, the system determines at step 1107 whether the issue diagnosis procedure is complete. If no, the issue diagnosis procedure is continued. If yes, a report is generated at step 1108 comprising results from the one or more diagnostic tests.

[0084] A specific example of rule engine logic is illustrated in Fig. 12. The rule engine will initially run one or more commands based on the identified network equipment at Layer 3 of the OSI model. Then, if the Layer 3 commands identify no faults, one or more further commands are run at Layer 2 level of the OSI model.

[0085] In some examples, the rule engine may run commands on every adjacent pair of network nodes between the two network nodes, based on network knowledge, until the connection between each known adjacent pair of network nodes (network equipment or element) between the two nodes has been tested.

[0086] The following steps may be performed in the issue diagnosis procedure for layers 2 and 3: 1201 Trigger received. 1202 Initiate rule engine. 1203 Identify the network architecture. 1204 Query database to identify the network equipments associated with the network. 1205 Run layer 3 command on the network equipment. 1206 Decision: If not ok (i.e., fault identified), proceed to 1210. If ok (i.e., no fault identified), proceed to 1220. 1210 Log diagnose conclusion code. 1220 Run further command on layer 3. 1221 Decision: If not ok, proceed to 1230. If ok, proceed to 1240. 1230 Log diagnose conclusion code. 1240 Run further command on layer 2. 1241 Decision: If not ok, proceed to 1250. If ok, proceed to 1260. 1250 Log diagnose conclusion code. 1260 Run further command on layer 2. 1261 Log diagnose conclusion code.

[0087] The rule engine logic can also be extended, as illustrated in the specific example shown in Fig. 13, to run specific commands based on network knowledge, including running commands on each Layer of the OSI model from Layer 4 until Layer 7. These layers are generally software driven.

[0088] The following additional steps may be performed in the issue diagnosis procedure for layers 4 until 7: 1301 Trigger received. 1302 Initiate rule engine. 1303 Identify the network architecture. 1304 Query database to identify the network equipments associated with the network. 1305 Run layer 4 command on the network equipment. 1306 Decision: If not ok, proceed to 1310. If ok, proceed to 1320. 1310 Log diagnose conclusion code. 1320 Run further command until layer 7. 1321 Log diagnose conclusion code.

[0089] Data or information flows from the application layer (Layer 7) down to presentation (Layer 6) and session information (Layer 5). Then, depending on the Layer 4 transport protocol, it further flows down. Layer 4 divides the data into packets to make data transmission more manageable. Each data packet comprises sender and receiver addresses, added at the network and data link layers (Layers 3 and 2). Finally, the data is sent down the physical layer (Layer 1) as a digital signal made up of a series of ones and zeroes.

[0090] Layer 2 is the Data Link Layer for hardware addressing. It plays a critical role and is responsible for the following key tasks: 1. Hardware addressing: Layer 2 uses unique device identifiers called MAC (Media Access Control) addresses. These are permanent hardware addresses added to devices by vendors when they are manufactured. 2. Forwarding data: With source and destination MAC addresses added to each packet, the network knows the hardware address of the receiving device. If the receiver is within the same VLAN, a network switch can intelligently Layer-2 switch the data out the correct port on its way to the end device. 3. Error Detection: To ensure the integrity of data transmission, Layer 2 employs error detection mechanisms, such as CRC (Cyclic Redundancy Check), which can identify and correct errors in the transmitted data. 4. Flow Control: Layer 2 manages the flow of data between devices by controlling the rate at which frames are sent and received. This prevents slower devices from being overwhelmed by faster devices on the network.

[0091] Layer 3 is the Network Layer for logical addressing. This enables much larger scale communication with following essential tasks: 1. Logical Addressing: Layer 3 uses IP (Internet Protocol) addresses to uniquely identify devices. These are logical addresses, and addressing schemes are set up to maximize the network topology and ensure secure and efficient data transfer. 2. Forwarding data: IP addresses are used to determine the most efficient path for data to travel between source and destination devices. Network switches intelligently Layer-3 switch data (also known as routing) between VLANs, or to a router at the edge of the LAN to be sent out across the internet. 3. Fragmentation and Reassembly: Layer 3 can fragment and reassemble packets when necessary to accommodate different network technologies with varying maximum transmission unit (MTU) sizes.

[0092] The proposed solution provides an issue diagnosis procedure that makes use of rules that are specific to the particular network equipments involved. The proposed methods perform automatic diagnosis between the two nodes of the network. The issue diagnosis procedure is specific to each network equipment across the different network architectures (e.g., Mobile Network, Fixed Access network, Transport network, Satellite network, or any combination of these defined configurations).

[0093] The outcome of the issue diagnosis procedure is a report (or “ticket”). The report may comprise an outcome (or “conclusion code”). The outcome may be unique to particular set of rules executed by the rule engine between the two nodes, and specific to each network equipment. The outcome may provide pre-diagnosis to indicate at what point the fault was identified (i.e., in which Layer).

[0094] The issue diagnosis procedure may further comprise querying a database based on a CLEI code to identify individual network equipment within the network.

[0095] The proposed solution may improve the level of diagnostic information available when identifying and investigating network faults (by running tests and providing results). The proposed solution may improve the quality of diagnostic information available when identifying and investigating network faults (by running tests automatically in real time so that the tests are performed during the same network conditions as those during which the fault occurred). The proposed solution may improve efficiency for resolving network faults across large telecommunications networks. The proposed solution may reduce the time take taken to resolve a network fault, by automatically performing issue diagnosis and providing a report with an outcome when the issue is first raised. The proposed solution may improve customer QoS by resolving issues quickly.

[0096] As described above, the proposed solution provides a unique rule engine that is specific to the network equipment and generates a report (that may also comprise an outcome). The rule engine logic may comprise one or more diagnostic tests to be run on the network connection, in the form of a sequence of steps.

[0097] The network equipment may be identified by building a database query on a unique CLEI code. An outcome (“diagnose conclusion code summary”) may be provided in the given context of the network environment, as defined between the two nodes (or endpoints).

[0098] The rule engine may autonomously execute or may execute when triggered. The rule engine may run a set of commands to identify the fault or report the status of network as a diagnose conclusion code.

[0099] The proposed solution may query a database of network equipment for the entire network architecture, with a unique CLEI code (CLEI Codes are globally unique, 10-character alphanumeric intelligent codes that identify equipment in a structured naming format).

[0100] Although specific embodiments have been described above, the skilled person will understand that various modifications and variations are possible. For example, whilst the disclosure is described in relation to existing network architecture, it will be understood that changes to the architecture (and / or nomenclature) are possible, but the present disclosure may still be applicable in this case. Also, combinations of any specific features shown with reference to one embodiment or with reference to multiple embodiments are also provided, even if that combination has not been explicitly detailed herein.

[0101] Where this application refers to a server, for instance, this may actually be a pair of servers (primary and failover), for redundancy.

[0102] Where this application refers to a “network entity”, the skilled person would understand that the network entity may actually be provided by a plurality of servers that are geographically distributed.

[0103] An Open Radio Access Network as described above may be used to provide a cellular network serving one or more User Equipments, UEs. Examples of the UE include various fixed and mobile devices that transmit and receive user data and / or various kinds of control information to and from a base station. The UE may be referred to as a terminal equipment (TE), a mobile station (MS), a mobile terminal (MT), a user terminal (UT), a subscriber station (SS), a wireless device, a personal digital assistant (PDA), a wireless modem, a handheld device, etc.

[0104] Whilst the above examples are described in relation to specific radio access networks (e.g., 4G and 5G radio access networks), these methods, techniques, apparatuses, and systems may be applied to a variety of wireless multiple access systems. Examples of multiple access systems include CDMA, FDMA, TDMA, OFDMA, SC-FDMA, and MC-FDMA. CDMA may be embodied through radio technology such as UTRA or CDMA2000. TDMA may be embodied through radio technology such as GSM, GPRS, or EDGE. OFDMA may be embodied through radio technology such as IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, or E-UTRA. UTRA is a part of a UMTS. 3GPP LTE is a part of E-UMTS using E-UTRA. 3GPP LTE employs OFDMA in DL and SC-FDMA in UL. LTE-A is an evolved version of 3GPP LTE. 3GPP NR employs OFDMA for both downlink and uplink and can operate in both FDD and TDD. For convenience of description, it is assumed that the present invention is applied to 3GPP NR. However, the technical features of the present invention are not limited thereto. For example, although the following detailed description is given based on a mobile communication system corresponding to a 3GPP NR system, aspects of the present invention that are not specific to 3GPP NR are applicable to other mobile communication systems. Moreover, the technical features of the present invention may be applied to future iterations of multiple access systems defined in 3GPP standards, such as (but not limited to) 6G.

[0105] The examples may be carried out on any suitable data processing device, such as a personal computer, laptop, mobile telephone, server, virtual machine, and the like. The above description of the systems and methods has been simplified for purposes of discussion, and is intended to provide a specific example to illustrate the invention. Different types of systems and methods may be used, as will be appreciated by the skilled person. It will be appreciated that the boundaries between logic blocks are merely illustrative and that alternative embodiments may merge logic blocks or elements, or may impose an alternate decomposition of functionality upon various logic blocks or elements.

[0106] It will be appreciated that the above-mentioned functionality may be implemented as one or more corresponding modules as hardware and / or software. For example, the above-mentioned functionality may be implemented as one or more software components for execution by a processor of the system. Alternatively, the above-mentioned functionality may be implemented as hardware, such as on one or more FPGAs, and / or one or more ASICs, and / or one or more DSPs, and / or other hardware arrangements. Method steps implemented in flowcharts contained herein, or as described above, may each be implemented by corresponding respective modules. Moreover, multiple method steps implemented in flowcharts contained herein, or as described above, may be implemented together by a single module.

[0107] Any of the methods described herein may be implemented as computer software or a “computer program”. The computer program may be configured to control a network entity (e.g., a server or group of servers) to perform any method according to the disclosure. A network entity (e.g., a server or group of servers) within a cellular network may also be provided, configured to operate in accordance with certain methods disclosed herein. For example, the network entity may include a processor and at least one communication interface, particularly comprising one or both of a transmitter and receiver.

[0108] A storage medium and a transmission medium carrying the computer program are also provided. The computer program may comprise one or more instructions, or code, that, when executed by a computer, causes the methods described to be performed. A computer program may be a sequence of instructions designed for execution on a computer system, and may include a subroutine, a function, a procedure, a module, an object method, an object implementation, an executable application, an applet, a servlet, source code, object code, a shared library, a dynamic linked library, and / or other sequences of instructions designed for execution on a computer system. The storage medium may be a magnetic disc (such as a hard drive or a floppy disc), an optical disc (such as a CD-ROM, a DVD-ROM, or a Blu-ray disc), or a memory (such as a ROM, a RAM, EPROM, EEPROM, Flash memory or a portable / removable memory device), etc. The transmission medium may be a communications signal, a data broadcast, a communications link between two or more computers, etc.

[0109] Each feature disclosed in this specification, unless stated otherwise, may be replaced by alternative features serving the same, equivalent, or similar purpose. Thus, unless stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

[0110] As used herein, including in the claims, unless the context indicates otherwise, singular forms of the terms herein are to be construed as including the plural form and vice versa. For instance, unless the context indicates otherwise, a singular reference herein including in the claims, such as "a" or "an" (such as a UE, a network entity, a server or a cell) means "one or more” (for instance one or more UEs, one or more network entities, one or more servers, or one or more cells). Throughout the description and claims of this disclosure, the words "comprise", "including", "having" and "contain" and variations of the words, for example "comprising" and "comprises" or similar, mean "including", and are not intended to (and do not) exclude other components.

[0111] The use of any and all examples, or exemplary language ("for instance", "such as", "for example" and like language) provided herein, is intended merely to better illustrate the invention, and does not indicate a limitation on the scope of the invention unless otherwise claimed. No language in the specification should be construed as indicating any nonclaimed element as essential to the practice of the invention.

[0112] Any steps described in this specification may be performed in any order or simultaneously unless stated or the context requires otherwise. Moreover, where a step is described as being performed after a step, this does not preclude intervening steps being performed.

[0113] All of the aspects and / or features disclosed in this specification may be combined in any combination, except combinations where at least some of such features and / or steps are mutually exclusive. As described herein, there may be particular combinations of aspects that are of further benefit, such the aspects of determining a set of compensation parameters and applying a set of compensation parameters to measurements. In particular, the preferred features of the invention are applicable to all aspects of the invention and may be used in any combination. Likewise, features described in non-essential combinations may be used separately (not in combination).

[0114] A method of manufacturing and / or operating any of the devices disclosed herein is also provided. The method may comprise steps of providing each of the features disclosed and / or configuring or using the respective feature for its stated function.

Claims

1. A method of issue diagnosis in a telecommunications network comprising a plurality of network nodes, the method comprising:triggering an issue diagnosis procedure on a network connection between two network nodes in the telecommunications network;querying a network equipment database to identify network equipment associated with the network connection;performing one or more diagnostic tests on the network connection, wherein the one or more diagnostic tests are based on the identified network equipment; and generating a report comprising results from the one or more diagnostic tests.

2. The method of claim 1, wherein performing one or more diagnostic tests on the network connection comprises performing a plurality of diagnostic tests, wherein one or more of the diagnostic tests is selected based on a result of a preceding diagnostic test of the plurality of diagnostic tests.

3. The method of claim 1 or claim 2, wherein performing one or more diagnostic tests on the network connection comprises:testing a logical link between the two network nodes by sending a test message via the logical link using an L3 protocol.

4. The method of any preceding claim, wherein the network connection comprises a plurality of logical nodes, and wherein each logical node is adjacent to at least one other logical node, wherein performing one or more diagnostic tests on the network connection further comprises:for each pair adjacent of logical nodes in the plurality of logical nodes, sending a test message between the adjacent nodes using an L2 protocol.

5. The method of any preceding claim, wherein performing one or more diagnostic tests on the network connection further comprises:testing the network connection by sending a test message between the two network nodes using an L4 protocol, L5 protocol, L6 protocol and / or L7 protocol; and / orrunning one or more logical commands on application software running on the identified network equipment.

6. The method of any preceding claim, wherein identifying the network equipment associated with the network connection comprises determining one or more of:a Common Language Information Services, CLEI, code of the network equipment, one or more network identifiers of the network equipment, a manufacturer of the network equipment, a brand of the network equipment, and a model of the network equipment.

7. The method of claim 6, wherein each of the one or more diagnostic tests is selected from a plurality of different options, wherein each of the plurality of different options is associated with a particular CLEI code, manufacturer, brand, or model, and wherein the diagnostic test is selected based on the determined CLEI code, manufacturer, brand, or model of the identified network equipment.

8. The method of any preceding claim, wherein the report further comprises an outcome selected from a plurality of possible outcomes, wherein the method further comprises:selecting one of the plurality of possible outcomes, based on the results from the one or more diagnostic tests.

9. The method of claim 8, wherein selecting one of the plurality of possible outcomes comprises classifying a network performance of the telecommunications network using a machine learning model.

10. The method of claim 9 or claim 10, when dependent on claim 6, wherein the plurality of possible outcomes is associated with a particular CLEI code, manufacturer, brand, or model of the identified network equipment.

11. The method of any preceding claim, wherein triggering the issue diagnosis procedure is based on one or more of:identification of a fault between the two network nodes; and a periodic timer.

12. The method of claim 11, wherein identification of a fault comprises one or more of:detecting an Internet Protocol, IP, addressing error,detecting an application error;detecting a fragmentation error,detecting a flow control error,5 detecting a Cyclic Redundancy Check, CRC, failure, anddetecting a hardware addressing error.

13. The method of any preceding claim, wherein the telecommunications network comprises one or more of:10 a mobile network,a fixed access network,a fibre network, anda satellite network.15 14. A server configured to perform the method of any preceding claim.

15. A computer program comprising instructions that, when executed on a processor, cause the processor to perform the method of any of claims 1 to 13.

Citation Information

Patent Citations

  • Method and apparatus for automating hub and spoke internet protocol virtual private network trouble diagnostics

    US20090219823A1

  • Methods and apparatus to diagnose enhanced interior gateway routing protocol problems in networks

    US20100085879A1

  • Intelligent grid communications network management systems and methods

    US20150171629A1

  • Method and system for distributed multi-cloud diagnostics

    US20210377338A1