CN118042482A - Communication method, electronic device, communication system, medium, chip, and program product - Google Patents

Abstract

Embodiments of the present application relate to a communication method, an electronic device, a communication system, a computer-readable storage medium, a chip, and a computer program product. The communication method comprises the following steps: the first network element receives path query information from the second network element, wherein the path query information is used for determining a service flow end-to-end path of the terminal equipment; and the first network element sends a service report to the second network element, wherein the service report comprises a service flow end-to-end path, and the service flow end-to-end path is associated with the path query information. In this way, the traffic flow end-to-end path is provided in the service report, thereby facilitating evaluation of the particular SLA quality of the traffic flow.

Description

Communication method, electronic device, communication system, medium, chip, and program product

Technical Field

The present disclosure relates to the field of communications, and more particularly, to a communication method, an electronic device, a communication system, a computer-readable storage medium, a chip, and a computer program product.

Background

In a mobile network, an operator is mainly responsible for network construction and daily operation and maintenance management as a network communication service provider. The operation and maintenance management of the network includes operation and maintenance management functions in terms of configuration management (configuration management, CM), performance management (performance management, PM), and Fault Management (FM) of the network. The operator can provide the network as a service to the user, and allocate and reallocate resources according to the user demand, so as to ensure that the bearing service can reach the service level agreement (SERVICE LEVEL AGREEMENT, SLA) requirement.

In some scenarios, such as the fifth generation (5th generation,5G) toB scenario, the quality of service of 5GtoB may directly impact the productivity and production safety of enterprise users. Measurement and monitoring of the specific SLA quality of a traffic flow is critical to ensuring efficient production and security of enterprise users. The 5GtoB service is usually completed by the 5G application terminal, the base station, the bearer network, the core network and the application server together. The currently provided network element performance indicators are not sufficient for evaluating the specific SLA quality of the traffic flow.

Disclosure of Invention

To facilitate evaluation of a particular SLA quality of a traffic flow, embodiments of the present disclosure provide a communication method, an electronic device, a communication system, a computer-readable storage medium, a chip, and a computer program product.

In a first aspect, a method of communication is provided. The method comprises the following steps: the first network element receives path query information from the second network element, wherein the path query information is used for determining a service flow end-to-end path of the terminal equipment; and the first network element sends a service report to the second network element, wherein the service report comprises a service flow end-to-end path, and the service flow end-to-end path is associated with the path query information. In this way, the traffic flow end-to-end path is provided in the service report, thereby facilitating evaluation of the particular SLA quality of the traffic flow.

In some embodiments of the first aspect, the service associated with the service report includes a service level agreement SLA provisioning intent. The method further comprises the steps of: the method comprises the steps that a first network element determines a current performance value of an SLA guarantee intention; and based on the current performance value of the SLA guarantee intention, the first network element determines an achievement state of the SLA guarantee intention, the achievement state including achievement or non-achievement. The sending of the service report to the second network element comprises: if the achievement status of the SLA guarantee intention is not achieved, the first network element sends a service report to the second network element. In this way, it is possible to support acquisition of traffic flow end-to-end paths when SLA provisioning intent is not achieved, which facilitates SLA failure analysis and failure localization/localization in intent-based services. In addition, the service producer can autonomously judge the achievement state of the SLA guarantee intention, and provide a service consumer with a service flow end-to-end path when the SLA guarantee intention is not achieved, which can reduce the resource overhead required for SLA monitoring.

In some embodiments of the first aspect, the method further comprises: the first network element receives a first message from the second network element, the first message indicating that an achievement status of the SLA assurance intent is determined by the first network element and if the achievement status of the SLA assurance intent is not achieved, sending a service report by the first network element to the second network element. In this way, such configurable reporting operations increase flexibility, facilitating adaptability to different needs.

In some embodiments of the first aspect, sending the service report to the second network element comprises: in response to receiving the second message from the second network element, the first network element sends a service report to the second network element. The second message is used for indicating the first network element to perform SLA fault analysis. The service report also includes at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred. In this way, the first network element is able to perform failure analysis in the presence of SLA failures, thereby helping to delimit and locate the failures.

In some embodiments of the first aspect, the SLA fault analysis indication comprises at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred. In this way, implementation of SLA failure analysis can be facilitated.

In some embodiments of the first aspect, the traffic flow end-to-end path comprises at least one of the following nodes: a base station connected to the terminal device; a transmission device connected to a base station connected to the terminal device; transmission equipment connected with the user plane function network element UPF; UPF; and a server connected to the UPF. In this way, information about path nodes can be provided in the service report to facilitate SLA assessment.

In some embodiments of the first aspect, the service report further includes an SLA indicator. The SLA index includes at least one of: an end-to-end performance index of a service flow associated with the terminal device between the terminal device and the server; wireless side performance index of service flow between terminal equipment and base station; a transmission side performance index of the service flow between the transmission equipment connected with the base station and the transmission equipment connected with the UPF; and core network side performance index of the service flow between the UPF and the server. In this way, segment performance indicators between nodes can be provided in a service report to facilitate evaluation of a particular SLA quality of a traffic flow.

In some embodiments of the first aspect, the path query information includes at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located. In this way, the traffic end-to-end path can be conveniently acquired.

In a second aspect, a communication method is provided, and advantageous effects may be seen in the description of the first aspect, which is not repeated here. The method comprises the following steps: the second network element sends path inquiry information to the first network element, wherein the path inquiry information is used for determining the end-to-end path of the service flow of the terminal equipment; and the second network element receives a service report from the first network element, the service report including a traffic flow end-to-end path, the traffic flow end-to-end path being associated with the path query information.

In some embodiments of the second aspect, the service associated with the service report includes a service level agreement SLA assurance intent. Receiving a service report from a first network element comprises: if the achievement status of the SLA assurance intent is not achieved, the second network element receives a service report from the first network element.

In some embodiments of the second aspect, the method further comprises: the second network element sends a first message to the first network element. The first message is used to indicate a determination by the first network element of an achievement status of the SLA assurance intent and if the achievement status of the SLA assurance intent is not achieved, sending, by the first network element, a service report to the second network element.

In some embodiments of the second aspect, the method further comprises: the second network element sends a second message to the first network element. The second message is used for indicating the first network element to perform SLA fault analysis. The service report is received based on the second message, the service report further including at least one of an identification of a failed device on the end-to-end path of the traffic flow for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred.

In some embodiments of the second aspect, the SLA fault analysis indication comprises at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

In some embodiments of the second aspect, the traffic flow end-to-end path comprises at least one of the following nodes: a base station connected to the terminal device; a transmission device connected to a base station connected to the terminal device; transmission equipment connected with the user plane function network element UPF; UPF; and a server connected to the UPF.

In some embodiments of the second aspect, the service report further includes an SLA indicator. The SLA index includes at least one of: an end-to-end performance index of a service flow associated with the terminal device between the terminal device and the server; wireless side performance index of service flow between terminal equipment and base station; a transmission side performance index of the service flow between the transmission equipment connected with the base station and the transmission equipment connected with the UPF; and core network side performance index of the service flow between the UPF and the server.

In some embodiments of the second aspect, the path query information includes at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

In a third aspect, a communication method is provided, and advantageous effects may be seen in the description of the first aspect, which is not repeated here. The method comprises the following steps: the second network element sends path inquiry information to the first network element, wherein the path inquiry information is used for determining the end-to-end path of the service flow of the terminal equipment; the first network element receives path query information from the second network element; the first network element sends a service report to the second network element, wherein the service report comprises a service flow end-to-end path, and the service flow end-to-end path is associated with path query information; and the second network element receives the service report from the first network element.

In some embodiments of the third aspect, the service associated with the service report includes a service level agreement SLA provisioning intent. The method further comprises the steps of: the method comprises the steps that a first network element determines a current performance value of an SLA guarantee intention; and based on the current performance value of the SLA guarantee intention, the first network element determines an achievement state of the SLA guarantee intention, the achievement state including achievement or non-achievement. If the achievement status of the SLA assurance intent is not achieved, the first network element sends a service report to the second network element and the second network element receives the service report from the first network element.

In some embodiments of the third aspect, the method further comprises: the second network element sends a first message to the first network element, wherein the first message is used for indicating that the first network element determines the achievement state of the SLA guarantee intention and if the achievement state of the SLA guarantee intention is not achieved, the first network element sends a service report to the second network element; and the first network element receives the first message from the second network element.

In some embodiments of the third aspect, the method further comprises: the second network element sends a second message to the first network element, wherein the second message is used for indicating the first network element to perform SLA fault analysis. In response to receiving the second message from the second network element, the first network element sends a service report to the second network element, wherein the service report further includes at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred.

In some embodiments of the third aspect, the SLA fault analysis indication comprises at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

In some embodiments of the third aspect, the traffic flow end-to-end path comprises at least one of the following nodes: a base station connected to the terminal device; a transmission device connected to a base station connected to the terminal device; transmission equipment connected with the user plane function network element UPF; UPF; and a server connected to the UPF.

In some embodiments of the third aspect, the service report further includes an SLA indicator comprising at least one of: an end-to-end performance index of a service flow associated with the terminal device between the terminal device and the server; wireless side performance index of service flow between terminal equipment and base station; a transmission side performance index of the service flow between the transmission equipment connected with the base station and the transmission equipment connected with the UPF; and core network side performance index of the service flow between the UPF and the server.

In some embodiments of the third aspect, the path query information includes at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

In a fourth aspect, an electronic device is provided. The electronic device comprises a multi-core processor and a memory having stored thereon instructions to be executed by the multi-core processor, which when executed by the multi-core processor cause the electronic device to implement a method according to any one of the possible implementations of the first aspect described above.

In a fifth aspect, an electronic device is provided. The electronic device comprises a multi-core processor and a memory having stored thereon instructions to be executed by the multi-core processor, which when executed by the multi-core processor cause the electronic device to implement a method according to any one of the possible implementations of the second aspect described above.

In a sixth aspect, a communication system is provided. The communication system comprises a first network element and a second network element and is configured to implement the method according to any one of the possible implementations of the third aspect described above with the first network element and the second network element.

In a seventh aspect, a computer readable storage medium is provided. The computer readable storage medium has stored thereon a computer program which, when executed by a processor, implements a method according to any one of the possible implementations of the first, second or third aspects described above.

In a seventh aspect, a chip is provided. The chip comprises processing circuitry configured to perform the method according to any one of the possible implementations of the first, second or third aspects described above.

In an eighth aspect, a computer program product is provided. The computer program product is tangibly stored on a computer-readable medium and comprises computer-executable instructions which, when executed, cause an apparatus to implement a method according to any one of the possible implementations of the first, second or third aspects described above.

Drawings

Features, advantages, and other aspects of various implementations of the present description will become apparent with reference to the following detailed description when taken in conjunction with the accompanying drawings. Several implementations of the present specification are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings:

Fig. 1 illustrates a schematic block diagram of a communication system in which embodiments of the present description may be implemented;

FIGS. 2A and 2B illustrate schematic block diagrams of an intent-based drive management service communication system in which embodiments of the present description may be implemented;

FIG. 3 illustrates a schematic block diagram of a communication system based on management data analysis services in which embodiments of the present specification may be implemented;

FIG. 4 illustrates an interactive signaling diagram of a communication process according to some embodiments of the present description;

FIG. 5A illustrates an interactive signaling diagram of a communication process according to an example implementation of some embodiments of the present description;

FIG. 5B illustrates an interactive signaling diagram of a process of obtaining terminal traffic flow topology information according to some embodiments of the present description;

FIG. 5C illustrates an interactive signaling diagram of a communication process to perform failure analysis according to some embodiments of the present description;

FIGS. 6A-6E illustrate interactive signaling diagrams of a communication process according to example implementations of some embodiments of the present description;

fig. 7 illustrates a flow chart implemented at a first network element according to some embodiments of the present description;

fig. 8 illustrates a flow chart implemented at a second network element according to some embodiments of the present description;

Fig. 9 illustrates a flow chart implemented at a communication system in accordance with some embodiments of the present description;

FIG. 10 illustrates a schematic block diagram of a communication device according to some embodiments of the present application;

FIG. 11 shows a schematic block diagram of a communication device according to further embodiments of the present application;

Fig. 12 shows a schematic block diagram of a communication device according to further embodiments of the present application; and

Fig. 13 shows a simplified block diagram of an example device suitable for implementing embodiments of the present description.

In the various drawings, the same or similar reference numbers represent the same or similar elements.

Detailed Description

Embodiments of the present specification will be described in more detail below with reference to the accompanying drawings. While certain embodiments of the present description have been shown in the accompanying drawings, it is to be understood that the present description may be embodied in various forms and should not be construed as limited to the embodiments set forth herein, but rather are provided to provide a more thorough and complete understanding of the present description. It should be understood that the drawings and examples of the present specification are for illustrative purposes only and are not intended to limit the scope of the present specification.

In the description of the embodiments of the present specification, the term "comprising" and its similar terms should be understood as open-ended, i.e. "including, but not limited to. The term "based on" should be understood as "based at least in part on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". In the embodiment of the application, for a technical feature, the technical features of the technical feature are distinguished by a first, a second, a third and the like, and the technical features described by the first, the second and the third are not in sequence or in sequence. Other explicit and implicit definitions are also possible below.

Embodiments of the present disclosure may be implemented in accordance with any suitable communication protocol, including, but not limited to, third generation (3rd Generation,3G), fourth generation (4G), fifth generation (5G), and future communication protocols (e.g., sixth generation (6G)), cellular communication protocols such as, for example, institute of Electrical and Electronics Engineers (IEEE) 802.11, wireless local area network communication protocols such as, for example, institute of electrical and electronics engineers (ELECTRICAL AND Electronics Engineers), third generation partnership project (3rd generation partnership project,3GPP), and/or any other protocol now known or later developed.

The technical solutions of the embodiments of the present disclosure are applied to communication systems following any suitable communication protocol, such as: general Packet Radio Service (GPRS), global system for mobile communications (Global System for Mobile Communications, GSM), enhanced data rates for GSM evolution (ENHANCED DATA RATE for GSM Evolution, EDGE), universal mobile telecommunications system (Universal Mobile Telecommunications Service, UMTS), long term evolution (Long Term Evolution, LTE) system, wideband code Division multiple access system (Wideband Code Division Multiple Access, WCDMA), code Division multiple access 2000 system (Code Division Multiple Access, CDMA 2000), time Division-Synchronization Code Division Multiple Access, TD-SCDMA), frequency Division duplex (Frequency Division Duplex, FDD) system, time Division duplex (Time Division Duplex, TDD), fifth generation (5G) system (e.g., new Radio, NR)) and the like. The technical solution provided by the present application may also be applied to end-to-end (E2E), device-to-device (D2D) communication, vehicle-to-everything (V2X) communication, machine-to-machine (machine to machine, M2M) communication, machine type communication (MACHINE TYPE communication, MTC), and internet of things (internet of things, ioT) communication systems or other communication systems.

For purposes of illustration, embodiments of the present disclosure are described below in the context of a 5G communication system. However, it should be understood that embodiments of the present disclosure are not limited to this communication system, but may be applied to any communication system where similar problems exist, such as a Wireless Local Area Network (WLAN), a wired communication system, or other communication systems developed in the future, and the like.

The term "terminal device" as used in this specification is any terminal device that can communicate with a network device or with each other either wired or wireless. A terminal device may sometimes be referred to as a User Equipment (UE), an application terminal, an access terminal, a subscriber unit, a subscriber station, a mobile station, a remote terminal, a mobile device, a user terminal, a wireless communication device, a user agent, or a user equipment. Currently, examples of some terminal devices are: a mobile phone, a tablet, a laptop, a palmtop, a mobile internet device (mobile INTERNET DEVICE, MID), a wearable device, a Virtual Reality (VR) device, an augmented reality (augmented reality, AR) device, a wireless terminal in industrial control (industrial control), a wireless terminal in unmanned-drive (self-drive), a wireless terminal in teleoperation (remote medical surgery), a wireless terminal in smart grid (SMART GRID), a wireless terminal in transportation security (transportation safety), a wireless terminal in smart city (SMART CITY), a wireless terminal in smart home (smart home), a cellular phone, a cordless phone, a session initiation protocol (session initiation protocol, SIP) phone, a wireless local loop (wireless local loop, WLL) station, a personal digital assistant (personal DIGITAL ASSISTANT, PDA), a handheld device with wireless communication function, a computing device or other processing device connected to a wireless modem, a wearable device, a terminal device in a 5G network, or a terminal in a future evolved terrestrial communication network (public land mobile network), and the like, without limiting the application. By way of example, but not limitation, in embodiments of the present application, the terminal device may also be a terminal device in an IoT system, where IoT is an important component of future information technology development, and its main technical feature is to connect the article to a network through a communication technology, so as to implement man-machine interconnection, and an intelligent network for the interconnection of the article. It will be appreciated that the terminal device in the embodiment of the present application may be a terminal for implementing a certain application, for example, a terminal with a camera function, another terminal capable of performing data transmission, and so on. In the embodiment of the present application, the device for implementing the function of the terminal device may be the terminal device, or may be a device capable of supporting the terminal device to implement the function, for example, a chip system or a chip, and the device may be installed in the terminal device. In the embodiment of the application, the chip system can be composed of chips, and can also comprise chips and other discrete devices.

The term "network device" as used in this specification is an entity or node that may be used for communication with a terminal device, e.g. an access network device. The access network device may be an apparatus deployed in a radio access network to provide wireless communication functionality for mobile terminals, and may be, for example, a radio access network (Radio Access Network, RAN) network device. The access network device may include various types of base stations. The base station is used for providing wireless access service for the terminal equipment. Specifically, each base station corresponds to a service coverage area, and terminal devices entering the service coverage area can communicate with the base station through wireless signals, so as to receive wireless access services provided by the base station. There may be an overlap between service coverage areas of base stations, and a terminal device in the overlapping area may receive wireless signals from multiple base stations, so that multiple base stations may serve the terminal device at the same time. Depending on the size of the service coverage area provided, the access network device may include Macro base stations providing Macro cells (Macro cells), micro base stations providing micro cells (Pico cells), pico base stations providing Pico cells, and Femto base stations providing Femto cells (Femto cells). The access network devices may also include various forms of relay stations, access points, remote Radio units (Remote Radio Unit, RRU), radio Heads (RH), remote Radio heads (Remote Radio Head, RRH), and so on. In systems employing different radio access technologies, the names of access network devices may vary, e.g., in long term evolution (Long Term Evolution, LTE) networks referred to as evolved nodebs (enbs or enodebs), in 3G networks as Nodebs (NB), in 5G networks as G nodebs (gNB) or NR nodebs (NR NB), etc. In some scenarios, the access network device may contain a Centralized Unit (CU) and/or a Distributed Unit (DU). The CUs and DUs may be placed in different places, for example: DU is far-pulled, placed in the area of high traffic, CU is placed in the central machine room. Or the CU and DU may be placed in the same room. The CU and DU may also be different components under one shelf. For convenience of description, in the subsequent embodiments of the present disclosure, the above devices for providing wireless communication functions for mobile terminals are collectively referred to as network devices, and embodiments of the present disclosure are not specifically limited.

As an example, in the present specification, the core network device (or referred to as core network element) may include, but is not limited to, any of the following: a network slice selection function (network slice selection function, NSSF), an authentication server function (authentication server function, AUSF), a unified data management (unified DATA MANAGEMENT, UDM), a network opening function (network exposure function, NEF), a network storage function (NF repository function, NRF), a policy control function (policy control function, PCF), an application function (application function, AF), an access and mobility management function (ACCESS AND mobility management function, AMF), a session management function (session management function, SMF), a user plane function (user plane function, UPF), a network data analysis function (network DATA ANALYTICS function, NWDAF). As an example, AMF is mainly used for access control, mobility management, registration and deregistration functions. For example, in an embodiment of the present application, the AMF may be responsible for authentication and mobility management functions of the terminal device. UPF is mainly used for receiving and forwarding user plane data. For example, the UPF may receive user plane data from a server and send the user plane data to a terminal device. The UPF may also receive user plane data from the terminal device and forward to the server.

By way of example, in this specification, a server may represent a computer system that may provide certain services to other devices. For example, a video service server may provide video services (e.g., play video); the control service server may send control commands to the terminal device, etc.

As an example, in this specification, a transport network (transport network, TN) device is the underlying network device that provides network connectivity between RAN network devices and core network devices. In this specification, "transmission device", "TN device" and "carrier network device" may be used interchangeably.

The service level agreement SLA is defined between a service provider and a user for ensuring the performance and reliability of a service under a certain cost, and if the service violates an agreement standard, a quick response is required to avoid destroying the SLA. The standard organizations such as 3GPP have already defined for SLA definitions in 5GtoB networks, where the key indicators of most concern include packet loss rate, latency, user rate, etc.

As mentioned above, the quality of service of 5GtoB directly affects the efficiency and safety of enterprise production. For some network services provided by operators to enterprise users, operators and enterprise users desire to be able to perceive and monitor specific service metrics of traffic flows. Current SLAs refer only to an indicator of end-to-end traffic flow from a terminal to an application server. However, the index of the single domain or single network element object cannot embody the SLA quality of the end-to-end service flow, so that the evaluation of the performance index of the service is difficult, and the fault delimitation and positioning are difficult when faults occur.

In order to solve the above-described problems, embodiments of the present disclosure provide a communication method. In the method, the first network element determines the end-to-end path of the service flow of the terminal equipment based on the path query information from the second network element, thereby facilitating service performance index evaluation and post-fault delimitation positioning.

Fig. 1 illustrates a schematic block diagram of a communication system 100 in which embodiments of the present description may be implemented.

In some embodiments, as shown in fig. 1, communication system 100 may include a first network element 110 and a second network element 120. In some embodiments, the first network element 110 may be a communication service producer and the second network element 120 may be a communication service consumer. In some embodiments, the first network element 110 may be a network element management system (ELEMENT MANAGEMENT SYSTEM, EMS) and the second network element 120 may be a Network Management System (NMS) MANAGEMENT SYSTEM. The first network element 110 and the second network element 120 may communicate with each other. The first network element 110 and the second network element 120 may be implemented in hardware, software, or a combination of hardware and software. It should be understood that the number of components shown in fig. 1 and their connections are given for illustrative purposes and are not meant to be limiting. Communication system 100 may include any suitable number of devices and networks suitable for implementing embodiments of the present description.

The definition of the conventional northbound interface (INTERFACE NORTH, itf-N) adopts the modes of network resource full-scale modeling and network object full-scale management. The NMS directly performs augmentation, deletion and examination on all management objects in the south through CM, PM, FM and other types of operations. Therefore, the management and operation and maintenance thresholds of operators are improved, the differentiated realization of equipment manufacturers is also exposed, and the intercommunication of different manufacturers is difficult to realize. In order to reduce the management complexity of the network infrastructure and improve the operation and maintenance efficiency in a multi-provider scenario, an intention-driven management service (INTENT DRIVEN MANAGEMENT SERVICE, IDMS) is proposed. In IDMS, NMS does not manage network resource management (network resource management, NRM) directly, but only keeps the intention model, and only delivers vendor-independent (vendor-agnostic) intention expression on the northbound interface, thus shielding differentiated details on the device vendor implementation. The intention adopts declarative expression, namely only describes what to do (do what) and does not involve what to do (how to do), and the intention expression can be completed only by having basic conceptual knowledge in the wireless field, so that the operation and maintenance threshold is reduced. When the EMS receives the intention, it is necessary to translate the demand on the network and the specific execution operation and execution according to the network state to achieve the intention.

Fig. 2A shows a schematic block diagram of an IDMS-based communication system 200 in which embodiments of the present specification may be implemented. As shown in fig. 2A, communication system 200 may include an intent-driven management service producer (i.e., IDMS producer) 210 and an intent-driven management service consumer (i.e., IDMS consumer) 220. In the intent-driven closed-loop process flow of communication system 200, IDMS consumer 220 issues an intent to IDMS producer 210 by invoking an IDMS interface. IDMS producer 210, upon receipt of the intent, translates the intent into a specific enforcement policy for delivery to managed entity 230 (e.g., network infrastructure). Managed entity 230 may be physical and/or virtual. It is understood that communication system 200, IDMS producer 210, and IDMS consumer 220 are each one specific implementation of communication system 100, first network element 110, and second network element 120, respectively, of fig. 1.

Fig. 2B illustrates a traffic scenario of the communication system 200 of fig. 2A. In the traffic scenario under 5GtoB, terminal device-1, terminal device-2, terminal devices-3, … …, terminal device-M may connect to base station-1, base station-2, … …, base station-N to obtain wireless network services. Examples of terminal devices may include, but are not limited to, a camera device capable of providing video monitoring backhaul services, a programmable controller (programmable logic controller, PLC) device capable of providing access and data transfer functions for remote control instruction traffic, and the like. For the description of each network element in fig. 2B, reference is made to the foregoing description, and details are not repeated here. It should be understood that the number of devices shown in fig. 2B and their connections are given for illustrative purposes and are not meant to be limiting.

IDMS producer 210 may continually monitor the network status of managed entity 230 and continually adjust network management operations to meet the needs expressed by the intent. IDMS producer 210 may feedback some information to IDMS consumer 220, such as the intended execution state (i.e., the current performance value of the desired objective). IDMS consumer 220 may evaluate the execution status of the intent and determine whether the intent needs to be updated based on feedback from IDMS producer 210.

However, the existing intention information model only supports reporting of performance value information of a corresponding expected target, and it is difficult to ensure execution of fault delimitation positioning and achievement of SLA guarantee intention. Hereinafter, communication methods based on the IDMS architecture according to some embodiments of the present disclosure will be described in detail with reference to fig. 5A to 6D, by which an existing intention information model may be enhanced, and 5GtoB terminal traffic flow path acquisition may be implemented, thereby ensuring execution of fault delimitation positioning and achievement of SLA guarantee intention.

It is to be understood that embodiments of the present application are not limited to IDMS architectures, but may also be applied to non-intent based architectures. Fig. 3 illustrates a schematic block diagram of a management data analysis service (MANAGEMENT DATA ANALYTICS SERVICE, MDAS) -based communication system 300 in which embodiments of the present description may be implemented. As shown in fig. 3, the communication system 300 may include a management data analysis service consumer (i.e., MDAS consumer) 320 and a management data analysis service producer (i.e., MDAS producer) 310. The MDAS producer 310 may be an external interface to the management data analysis function 350. The management data analysis function 350 is a logical functional entity that implements an analysis function through the internal management data analysis 340 and provides MDAS to the MDAS consumer 320 through an external interface.

It is understood that the communication system 300, the MDAS producer 310, and the MDAS consumer 320 are one specific implementation of the communication system 100, the first network element 110, and the second network element 120, respectively, in fig. 1. Hereinafter, a communication method based on MDAS architecture according to some embodiments of the present disclosure will be described in detail with reference to fig. 6E, by which an MDAS consumer can be enabled to acquire a terminal traffic flow path, ensuring SLA problem analysis is achieved.

Fig. 4 illustrates an interactive signaling diagram of a communication process 400 according to some embodiments of the present description. For clarity of discussion, the communication process 400 will be discussed in connection with fig. 1.

In the communication process 400, the second network element 120 of the communication system 100 sends (402) path query information 404 to the first network element 110 of the communication system 100, where the path query information 404 is used to determine a traffic flow end-to-end path of the terminal device. Accordingly, the first network element 110 receives (406) path query information 404 from the second network element 120. In some embodiments, the terminal device may be associated with a service that the second network element 120 requests the first network element 110 to create. It should be appreciated that the second network element 120 may send the creation request for creating the service and the path query information 404 simultaneously to the first network element 110. Alternatively, the second network element 120 may send the creation request for creating the service and the path query information 404 to the first network element 110 at different times.

The first network element 110 sends 408 a service report 410 to the second network element 120, the service report 410 comprising a traffic flow end-to-end path, the traffic flow end-to-end path being associated with the path query information 404. Accordingly, the second network element 120 receives (412) a service report 410 from the first network element 110. In some embodiments, the service report 410 may be associated with a service that the second network element 120 requests the first network element 110 to create. In some embodiments, the service report 410 may also include feedback information for the service created by the first network element 110. The second network element may perform a specific index analysis based on the obtained traffic flow end-to-end path.

In some embodiments, the services associated with the service report 410 may include SLA provisioning intent. In this case, the first network element 110 and the second network element 120 may be implemented as an IDMS producer 210 and an IDMS consumer 220 under an IDMS architecture as shown in fig. 2A and 2B, respectively.

In some embodiments, the first network element 110 may determine a current performance value of the SLA provisioning intent and determine an achievement status of the SLA provisioning intent based on the current performance value of the SLA provisioning intent. The achievement status of the SLA assurance intent may include achieved or not achieved. If it is determined that the SLA provisioning intent is not achieved, the first network element 110 can send a service report 410 to the second network element 120. In other words, the first network element 110 may autonomously determine the achievement status of the SLA guarantee intention, and report the traffic flow end-to-end path only when the SLA guarantee intention is not achieved, and when the SLA guarantee intention is achieved, the first network element 110 may not report the traffic flow end-to-end path. In this way, the resource overhead required for reporting paths may be reduced.

In some embodiments, the second network element 120 can send a first message to the first network element 110 indicating that the achieved status of the SLA assurance intent was determined by the first network element 110 and if the achieved status of the SLA assurance intent was not achieved, a service report 410 is sent by the first network element 110 to the second network element 120. Accordingly, the first network element 110 may receive the first message from the second network element 120, and perform an operation of autonomously determining the intention-to-reach state and reporting the path based on the first message. In this way, the operation of autonomously judging the intention to reach the state and reporting the path can be configurably performed, and the flexibility of the system operation is improved.

In some embodiments, the first network element 110 may send the current execution state of the SLA provisioning intent to the second network element 120. The second network element 120 may determine an achievement state of the SLA provisioning intent based on the current execution state of the SLA provisioning intent. If it is determined that the SLA provisioning intent is not achieved, the second network element 120 may send a reporting directive to the first network element 110. The first network element 110 may send a service report 410 to the second network element 120 in response to receiving the reporting directive. In this way, the second network element can determine whether to acquire the end-to-end path of the service flow according to the actual scene. Similarly, the first network element 110 may perform the above-described reporting operation based on the message received from the second network element 120, i.e., continuously send the current execution state of the SLA provisioning intention to the second network element 120, and report the traffic flow end-to-end path in response to an instruction from the second network element 120.

In some embodiments, the second network element 120 may send a second message to the first network element 110, where the second message is used to instruct the first network element 110 to perform SLA failure analysis. In response to receiving the second message from the second network element 120, the first network element 110 can send a service report 410 to the second network element 120, the service report 410 can further include at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred. In this way, the first network element is able to perform failure analysis in the presence of SLA failures, thereby helping to delimit and locate the failures. It will be appreciated that the first network element 110 and the second network element 120 may be implemented as an IDMS producer 210 and an IDMS consumer 220 under the IDMS architecture as shown in fig. 2A and 2B, respectively, or as an MDAS producer 310 and an MDAS consumer 320 under the IDMS architecture as shown in fig. 3, respectively.

In some embodiments, the SLA fault analysis indication may comprise at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred. In this way, the first network element can easily perform SLA failure analysis.

In some embodiments, the first network element 110 may determine a traffic flow end-to-end path and measure a corresponding service indicator, and buffer the traffic flow end-to-end path and the measured service indicator for a period of time. If the failure analysis instruction is received within the buffering time, the first network element 110 may perform failure analysis based on the stored historical data, so that the efficiency and accuracy of the failure analysis may be improved.

In some embodiments, the second network element 120 may determine whether a failure exists based on the service execution status received from the first network element and send a failure analysis indication when it is determined that a failure exists. Alternatively or additionally, the second network element 120 may send the failure analysis indication according to user requirements, system operating status, etc.

In some embodiments, the traffic flow end-to-end path may include a base station connected to the terminal device, a transmission device connected to the UPF, a server connected to the UPF, other nodes, and any combination of these nodes. In this way, the second network element can learn information about the path nodes, facilitating SLA assessment.

In some embodiments, the service report 410 may also include SLA indicators, which may include end-to-end performance indicators of traffic flows associated with the terminal device between the terminal device and the server, wireless-side performance indicators of traffic flows between the terminal device and the base station, transmission-side performance indicators of traffic flows between the transmission device connected to the base station and the transmission device connected to the UPF, and core network-side performance indicators of traffic flows between the UPF and the server, other performance indicators, and any combination of these performance indicators. In this way, the second network element can learn the segment performance index between the nodes, thereby facilitating the assessment of the specific SLA quality of the traffic flow.

In some embodiments, the path query information 404 may include a terminal identification of the terminal device, terminal area information in which the terminal device is located, other terminal information, and any combination of these different terminal information. In this way, the first network element may conveniently obtain the traffic flow end-to-end path.

Referring now to fig. 5A, a communication process 500 according to an example implementation of some embodiments of the present description is described by way of example. The communication process 500 may be considered a specific example of the communication process 400. For clarity of discussion, the communication process 500 will be discussed in connection with fig. 2A.

In communication process 500, IDMS consumer 220 sends an intent creation request 502 to IDMS producer 210. The intent creation request 502 may include SLA provisioning intent and terminal traffic end-to-end path query related information. It will be appreciated that the terminal traffic end-to-end path query related information may be sent and received simultaneously with the SLA provisioning intent, or may be sent and received separately at different times. The terminal traffic flow end-to-end path query related information may include terminal area information and/or a terminal international mobile subscriber identity (international mobile subscriber identity, IMSI). The terminal area information may include area information such as geographical location, cell list, etc. The terminal area information may be used to determine the base stations that need to be queried with which the terminal devices associated with the SLA provisioning intent communicate. The terminal IMSI is a terminal identification for indicating a certain terminal.

In some embodiments, the end-to-end path query related information of the terminal traffic flow may further include a flow control policy. For example, the flow control policy may indicate that the achievement status of the SLA provisioning intent is autonomously judged by the IDMS producer 210, and the terminal traffic flow topology information is only reported when the SLA provisioning intent is not achieved, whereas the IDMS producer 210 does not report the terminal traffic flow topology information when the SLA provisioning intent is achieved. As another example, the flow control policy may instruct IDMS producer 210 to report the current execution state of the SLA provisioning intent and report terminal traffic flow topology information based on the reporting indication from IDMS consumer 220. In the context of this specification, "terminal traffic topology information", "traffic end-to-end path", "traffic topology information", "terminal topology information" and the like may be used interchangeably.

In some embodiments, the end-to-end path query related information of the terminal traffic flow may further include a buffering time. For example, IDMS producer 210 may cache terminal traffic flow topology information after it is determined at the server. When the topology information of the terminal service flow is cached for more than the caching time, the cached data can be deleted.

Upon receipt of the intent creation request 502 sent by the IDMS consumer 220, the IDMS producer 210 may calculate terminal traffic flow topology information based on the relevant information carried by the intent creation request 502. The terminal traffic flow topology information may include information of a base station, a transmission device, a UPF, and a server for transmitting traffic flows of the terminal device. In some embodiments, IDMS producer 210 may also calculate SLA key indicators. The SLA key indicators may include packet loss rate, delay, user rate, etc.

IDMS producer 210 may send intent report 506 to IDMS consumer 220 via an intent reporting function, and intent report 506 may include an intent execution case. The SLA provisioning intent execution case may include a current performance value of the specified desired objective, e.g., the current performance value corresponding to the downstream latency objective (DLLATENCYTARGET) is downstream latency (DLLATENCY). In some embodiments, intent report 506 may also include terminal identification and terminal traffic flow topology information. In some embodiments, intent report 506 may also include current performance values for SLA key indicators corresponding to terminal traffic flow topology information. For example, the end-to-end path of the terminal traffic flow and the end-to-end performance index of the traffic flow associated with the terminal device between the terminal device and the server may be represented as ：{"Topo":{"UE":{"IMSI":"4600018616002233","Name":"F1-3-1-video11"},"gNodeB":{"IP":"10.200.32.2","Name":"L2-Test"},"TN":[{"Index":"0","Name":"L2-UPE-2PTN980"},{"Index":"1","Nam e":"L5-NPE-7900E-32"}],"UPF":{"IP":"192.5.130.4"},"DN":{"IP":"192.3.24.101"}},"Indicators":{"packet loss ratio":"0.1％","latency":"23ms","user experienced data rate":{"UL":"180Mbps","DL":"25Mbps"}}}, where Topo represents topology path information; "UE" { "IMSI": "4600018616002233", and "Name": "F1-3-1-video11" } are terminal equipment information, including terminal equipment identification and terminal equipment Name; "gNodeB" { "IP": "10.200.32.2" } "and" Name ":" L2-Test "}" are information of a base station connected to a terminal device, including the IP address of the base station and the Name of the base station; "TN" [ { "Index": "0", "Name": "L2-UPE-2PTN980" }, { "Index": "1", "Name": "L5-NPE-7900E-32" } ] is a list of transmission devices, containing indexes and names of transmission devices connected to a base station and transmission devices connected to a UPF, indicating transmission devices connected to the base station when the Index "takes 0, and indicating transmission devices connected to a UPF when the Index" takes 1; "UPF": { "IP": "192.5.130.4" } is UPF information, containing the IP address of the UPF; "DN": { "IP": "192.3.24.101" } is server information, containing the IP address of the server; "Indicators" represent performance metrics on the topology path; "packet loss ratio": "0.1%" means that the packet loss rate from the terminal device to the server is 0.1%; "latency" 23ms is the end-to-end delay from the terminal device to the server is 23ms; "user experienced data rate" { "UL": "180Mbps", "DL": "25Mbps" } means the user rate on the path from the terminal device to the server, the uplink rate is 180Mbps, and the downlink rate is 25Mbps. Intent report 506 may also include performance metrics between any two nodes on the traffic flow's end-to-end path. For example, the performance index of the traffic flow associated with the terminal device between the terminal device and the base station connected to the terminal device may be represented as ：{"Topo":{"UE":{"IMSI":"4600018616002233","Name":"F1-3-1-video11"},"gNodeB":{"IP":"10.200.32.2","Name":"L2-Test"}},"Indicators":{"packet loss ratio":"0.1％","latency":"22ms","user experienced data rate":{"UL":"180Mbps","DL":"25Mbps"}}}, where the topology path information contains terminal device information and information of the base station connected to the terminal device, the performance index representing the performance index of the traffic flow between the terminal device and the base station connected to the terminal device.

At 508, IDMS consumer 220 may determine whether the SLA provisioning intent is achieved based on the intent execution. If IDMS consumer 220 determines that the SLA-assurance intent is not achieved, IDMS consumer 220 may generate a failure analysis intent and send failure analysis intent 510 to IDMS producer 210. Failure analysis intent 510 may include the terminal identification of the failed terminal device and the time of failure occurrence. In some embodiments, IDMS consumer 220 may determine a type of failure, such as packet loss or latency, based on the terminal traffic flow topology information and SLA key indicators included in intent report 506.

IDMS producer 210 may perform failure analysis 512 based on the failure analysis intent and feedback intent report 514 to IDMS consumer 220. The intent report 514 may include the terminal identification of the failed terminal device, fault information, and fault type. The failure information may reflect the root cause of the failure, such as the particular node that failed on the end-to-end path, i.e., the failed device identity. For example, if IDMS producer 210 determines that the root cause of the failure is a RAN-side present delay, then the type of failure in intent report 514 may include a RAN-side delay and the failure information may include a device identification of the base station to which the terminal device is connected.

IDMS producer 210 may obtain terminal traffic flow topology information in various ways. Referring now to fig. 5B, an interactive signaling diagram of a process of acquiring terminal traffic flow topology information according to some embodiments of the present description is described as an example. For clarity of discussion, process 504A in fig. 5B will be discussed in connection with fig. 2B.

In process 504A shown in fig. 5B, IDMS producer 210 may query (516) base station 520 in the area for base station IP and a corresponding AMF UE NGAP ID list based on the parameter terminal area information. Base stations 520 within the area indicated by the terminal area information may return 518 the base station IP and a corresponding AMF UE NGAP ID list to the IDMS producer 210. The IDMS producer 210 may query 522 the AMF 550 for the AMF UE NGAP ID corresponding to the terminal device according to the parameter terminal IMSI. The AMF 550 may return 524 an AMF UE NGAP ID corresponding to the terminal device to the IDMS producer 210. Because AMF UE NGAP ID is globally unique in the base station and AMF, the resource object identified based on AMF UE NGAP ID on the base station and the resource object identified based on AMF UE NGAP ID on the AMF are the same terminal resource object, so that one terminal device can be uniquely identified in the terminal resource of the base station, and the base station through which the service flow of the terminal device flows can be determined. The IDMS producer 210 may determine which base station the terminal device is connected to based on the AMF UE NGAP ID list corresponding to the base station 520 and the AMF UE NGAP ID corresponding to the terminal device. Based on the same IMSI, the UPF through which the traffic flow of the terminal device flows may be determined. For example, IDMS producer 210 may query 526 UPF 540 for terminal access server information UPF N3 IP based on the parameter terminal IMSI. UPF 540 may return 528 terminal access server information UPF N3 IP to IDMS producer 210. IDMS producer 210 may also query (532) TN 530 for hop-by-hop TN devices traversed by the terminal device access server based on the determined base station IP and UPF N3 IP. TN 530 may return 534 TN topology query results to IDMS producer 210. For example, IDMS producer 210 may determine the bearer network element to which the base station is connected via its next hop (NextHop) IP information and may obtain the intra-bearer hop-by-hop topology path via a follow-up detection technique.

IDMS producer 210 may perform fault analysis in various ways. Referring now to fig. 5C, an interactive signaling diagram of a process 512 for performing fault analysis according to some embodiments of the present description is described as an example. For clarity of discussion, process 512 in FIG. 5C will be discussed in connection with FIG. 2B.

In process 512, at 536, IDMS producer 210 may perform a dyeing policy configuration and issue, which may include a terminal identification, terminal topology information, and a dyeing policy. Based on the configured staining strategy, IDMS producer 210 may send a dimension measurement task configuration segment by segment for the terminal traffic flow path and receive a dimension measurement task report.

At 538, IDMS producer 210 may send a dimension task configuration to base station 520 that may include dimension task identification, dye identification, PDCP packet loss, air interface delay, measurement time, reporting period, and reporting mode. The base station in process 512 may be a base station on the terminal traffic flow path, i.e., a base station connected to the terminal device. At 542, IDMS producer 210 may receive a dimension task report from base station 520, which may include a dimension task identification, dimension data, and data statistics start and end times.

At 544, IDMS producer 210 may send a dimension task configuration to TN (i.e., carrier network) 530, which may include dimension task identification, dye identification, carrier network packet loss, carrier network latency, measurement time, reporting period, and reporting mode. At 546, IDMS producer 210 may receive a dimension task report from TN 530, which may include dimension task identification, dimension data, data statistics start and end times.

At 548, IDMS producer 210 may send a dimension task configuration to UPF 540, which may include dimension task identification, dye identification, GTPU packet loss, N3 interface latency, measurement time, reporting period, and reporting mode. At 550, IDMS producer 210 may receive a dimension task report from UPF 540, which may include dimension task identification, dimension data, data statistics start and end times.

IDMS producer 210 may identify, from the dimension data, the identity and fault type of the failed device that has an SLA fault on the traffic flow end-to-end path of the terminal device. For example, the IDMS producer 210 may determine whether a packet loss, delay, or rate problem occurs from the terminal device to the base station according to the maintenance task report obtained from the base station 520, and if the problem occurs, the fault information includes the identity of the base station device that has failed, and the fault type includes RAN-side delay or RAN-side packet loss or RAN-side low rate. Similarly, IDMS producer 210 may determine whether there is a failure on the transmission side and the core network side, and if so, the corresponding failed device identity and failure type, based on the dimension task reports obtained from TN 530 and UPF 540, respectively.

Fig. 6A-6E illustrate interactive signaling diagrams of communication procedures according to example implementations of some embodiments of the present description. The communication processes 600-1 through 600-5 shown in fig. 6A through 6E may be considered as one specific example of the communication process 400. For clarity of discussion, communication processes 600-1 through 600-4 will be discussed in connection with FIG. 2A, and communication process 600-5 will be discussed in connection with FIG. 3.

In the process 600-1 shown in fig. 6A, IDMS consumer 220 may send an SLA assurance intent creation request 602 to IDMS producer 210, which SLA assurance intent creation request 602 may include an SLA assurance intent, terminal area information, and/or terminal IMSI. SLA provisioning intent may include provisioning business, provisioning object, and provisioning time. The terminal area information may include area information, such as geographical location, cell list, etc., for determining base stations that need to be queried.

At 604, after receiving the SLA provisioning intent creation request sent by the IDMS consumer 220, as well as the terminal area information and the terminal IMSI carried by the SLA provisioning intent creation request, the IDMS producer 210 may obtain a terminal traffic flow end-to-end path. Acquisition of the end-to-end path of the terminal traffic flow may be performed by a process 504A shown in fig. 5B. In some embodiments, IDMS producer 210 may also calculate SLA key metrics based on the end-to-end path of the terminal traffic stream at 606. Because AMF UE NGAP ID is globally unique in the base station and AMF, the resource object identified based on AMF UE NGAP ID on the base station and the resource object identified based on AMF UE NGAP ID on the AMF are the same terminal resource object, so that one terminal device can be uniquely identified in the terminal resource of the base station. Based on the same IMSI, the UPF through which the traffic flow of the terminal device flows may also be determined. Based on the NextHop IP information of the base station, the bearing network element connected with the base station can be determined, and the hop-by-hop topology path inside the bearing network can be obtained through the stream following detection technology. The calculation of the SLA key indicator may be performed simultaneously with the acquisition of the end-to-end path of the terminal traffic flow.

IDMS producer 210 may report SLA provisioning intent execution, terminal identification, and terminal traffic flow topology information via intent report 608. In some embodiments, IDMS producer 210 may also report the current performance value of the SLA key indicator corresponding to the terminal traffic flow topology information through an intent report.

In process 600-1, by adding terminal area information and/or terminal identification when creating an SLA provisioning intent, an IDMS producer may query base stations within a specified area for terminal topology information based on the information. By adding the terminal identification and the terminal service flow topology information in the content which is intended to be reported, an IDMS consumer can acquire the end-to-end path of the terminal service flow, thereby being beneficial to evaluating the concrete SLA quality of the service flow.

As another example, in process 600-2 shown in fig. 6B, IDMS consumer 220 may send an SLA assurance intent creation request 610 to IDMS producer 210, which SLA assurance intent creation request 610 may include an SLA assurance intent, terminal area information, and/or a terminal IMSI and flow control policy. SLA provisioning intent may include provisioning business, provisioning object, and provisioning time. The terminal area information may include area information, such as geographical location, cell list, etc., for determining base stations that need to be queried. The SLA assurance intent creation request may also include an acquire terminal traffic flow path switch to indicate whether the IDMS producer is to perform acquisition of the terminal traffic flow path. In an embodiment of process 600-2, the flow control policy may instruct IDMS producer 210 to report the current execution state of the SLA provisioning intent and report terminal traffic flow topology information based on the reporting indication from IDMS consumer 220.

IDMS producer 210 may feed back SLA assurance intent enforcement to IDMS consumer 220 via intent report 612. The SLA provisioning intent execution scenario may include designating a current performance value of a desired objective, e.g., a performance value corresponding to a downstream latency objective (DLLATENCYTARGET) as downstream latency (DLLATENCY).

At 614, IDMS consumer 220 may evaluate achievement of the SLA provisioning intent based on information fed back by IDMS producer 210. At 616, when the SLA intent is not achieved, such as when IDMS producer 210 determines that there is an unachieved condition of a delay, transmission, etc. of the SLA provisioning service or a failure is detected, IDMS consumer 220 may feed back relevant information to IDMS producer 210. IDMS consumer 220 may feedback that the SLA provisioning intent was not achieved or failure information was detected.

At 618, IDMS producer 210 may obtain the end-to-end path of the terminal traffic stream and complete the topology path and key index calculations after receiving feedback from IDMS consumer 220. Acquisition of the end-to-end path of the terminal traffic flow may be performed by a process 504A shown in fig. 5B. In some embodiments, IDMS producer 210 may calculate SLA key metrics based on the end-to-end path of the terminal traffic stream at 620. Because AMF UE NGAP ID is globally unique in the base station and AMF, the resource object identified based on AMF UE NGAP ID on the base station and the resource object identified based on AMF UE NGAP ID on the AMF are the same terminal resource object, so that one terminal device can be uniquely identified in the terminal resource of the base station. Based on the same IMSI, the UPF through which the traffic flow of the terminal device flows may also be determined. Based on the NextHop IP information of the base station, the bearing network element connected with the base station can be determined, and the hop-by-hop topology path inside the bearing network can be obtained through the stream following detection technology. The calculation of the SLA key indicator may be performed simultaneously with the acquisition of the end-to-end path of the terminal traffic flow.

IDMS producer 210 may report the terminal identification and terminal traffic flow topology information via intent report 622. In some embodiments, IDMS producer 210 may also report the current performance value of the SLA key indicator corresponding to the terminal traffic flow topology information through an intent report.

In process 600-2, the IDMS producer may perform reporting of terminal topology information based on the information by adding terminal area information and/or terminal identification and flow control policies when creating SLA provisioning intent. For example, the flow control policy may indicate that the achievement status of the SLA guarantee intent is autonomously judged by the IDMS producer, and the terminal traffic flow topology information is reported only when the SLA guarantee intent is not achieved, whereas the IDMS producer does not report the terminal traffic flow topology information when the SLA guarantee intent is achieved. Or the flow control policy may instruct the IDMS producer to report the current execution state of the SLA provisioning intent and report the terminal traffic flow topology information based on the reporting instruction from the IDMS consumer. The configurable reporting operation improves flexibility and facilitates adaptively meeting different requirements.

In process 600-3 shown in fig. 6C, IDMS consumer 220 may send an SLA assurance intent creation request 624 to IDMS producer 210, which SLA assurance intent creation request 624 may include SLA assurance intent, terminal area information, and/or terminal IMSI, and cache time. SLA provisioning intent may include provisioning business, provisioning object, and provisioning time. The terminal area information may include area information, such as geographical location, cell list, etc., for determining base stations that need to be queried. The buffering time indicates a local buffering time of the terminal topology information acquired by the IDMS producer 210, and the buffering time may default to 7 days, for example, and support customization.

At 626, upon receiving the SLA provisioning intent creation request sent by IDMS consumer 220, along with the terminal area information and the terminal IMSI carried, IDMS producer 210 may obtain a terminal traffic flow end-to-end path. Acquisition of the end-to-end path of the terminal traffic flow may be performed by a process 504A shown in fig. 5B. In some embodiments, at 628, IDMS producer 210 may calculate SLA key metrics based on the end-to-end path of the terminal traffic flow. The calculation of the SLA key indicator may be performed simultaneously with the acquisition of the end-to-end path of the terminal traffic flow. The terminal topology information and/or SLA key indicators may be stored by the DMS producer 210 for the indicated buffering time. The terminal topology information and/or SLA key indicators are stored for a predetermined buffering time and then deleted.

IDMS producer 210 may feed back SLA assurance intent enforcement to IDMS consumer 220 via intent report 630. The SLA assurance intent execution case may include a current performance value specifying a desired goal. At 632, IDMS consumer 220 may evaluate achievement of the SLA provisioning intent based on information fed back by IDMS producer 210. When an SLA intent is not achieved, such as when IDMS producer 210 determines that an SLA provisioning service is present with a delay, transmission, etc. or detects a failure, IDMS consumer 220 may generate a failure analysis intent that is used to instruct IDMS producer 210 to perform a failure analysis, such as failure delimitation/localization of an end-to-end path.

IDMS consumer 220 sends failure analysis intent 634, which may include failure type, failure object, and failure time, to IDMS producer 210. The fault type may indicate that the SLA provisioning intent did not reach or some fault was detected, such as packet loss, latency, rate, etc. The fault object may include a terminal identification (e.g., terminal IMSI) and corresponding traffic flow topology information. The failure time may include a detected failure occurrence time.

At 636, IDMS producer 210 may determine relevant terminal topology information in the stored historical data based on the fault object and the time of failure in the issued fault analysis intent. At 638, IDMS producer 210 may perform fault analysis based on the relevant terminal topology information. Failure analysis may be performed by process 512 shown in fig. 5C.

IDMS producer 210 may feed back failure analysis results to IDMS consumer 220 via intent report 640. The failure analysis results may include terminal identification, terminal traffic topology information, failure device identification, and failure type. The fault type in the fault analysis result is that a detailed certain section has a fault, such as RAN side delay or UPF side delay.

In process 600-3, the IDMS producer may obtain terminal traffic flow topology information and store it for a period of time by adding terminal area information and/or terminal identification and buffering time when creating the SLA provisioning intent. When end-to-end fault delimiting/locating is needed, the IDMS producer can acquire the terminal topology information at the moment of fault occurrence from the server cache data, thereby ensuring the achievement of SLA guarantee intention and the execution of fault delimiting/locating, which is particularly beneficial to the situation that the fault cannot be reproduced. In other words, based on the buffering time information, the IDMS producer may store the terminal topology information in the server after acquiring it, and can inquire about the terminal topology information for a period of time before and after the occurrence time of the failure when the IDMS consumer needs to make the fault delimitation.

In process 600-4 shown in fig. 6D, IDMS consumer 220 may send failure analysis intent 642, which may include a failure type, a failure object, and a failure time, to IDMS producer 210. The fault type may indicate that the SLA provisioning intent did not reach or some fault was detected, such as packet loss, latency, rate, etc. The fault object may include a terminal identification (e.g., a terminal IMSI). The failure time may include a detected failure occurrence time.

At 644, IDMS producer 210 may obtain a terminal traffic flow end-to-end path upon receiving the failure analysis intent sent by IDMS consumer 220 and the carried terminal IMSI. Acquisition of the end-to-end path of the terminal traffic flow may be performed by a process 504A shown in fig. 5B. At 646, IDMS producer 210 may calculate SLA key metrics based on the end-to-end path of the terminal traffic flow. Because AMF UE NGAP ID is globally unique in the base station and AMF, the resource object identified based on AMF UE NGAP ID on the base station and the resource object identified based on AMF UE NGAP ID on the AMF are the same terminal resource object, so that one terminal device can be uniquely identified in the terminal resource of the base station. Based on the same IMSI, the UPF through which the traffic flow of the terminal device flows may also be determined. Based on the NextHop IP information of the base station, the bearing network element connected with the base station can be determined, and the hop-by-hop topology path inside the bearing network can be obtained through the stream following detection technology. The calculation of the SLA key indicator may be performed simultaneously with the acquisition of the end-to-end path of the terminal traffic flow.

Then, at 648, IDMS producer 210 may perform a failure analysis based on the determined terminal topology information. Failure analysis may be performed by process 512 shown in fig. 5C. IDMS producer 210 may feed back failure analysis results to IDMS consumer 220 via intent report 650. The failure analysis results may include terminal identification, terminal traffic topology information, failure device identification, and failure type. The fault type in the fault analysis result is that a detailed certain section has a fault, such as RAN side delay or UPF side delay.

In process 600-4, the IDMS consumer may actively issue a failure analysis intent to instruct the IDMS producer to obtain an end-to-end path of a terminal traffic flow when detecting that a certain terminal fails or when receiving a customer failure complaint, and perform failure analysis on the path, which is a key action of performing failure delimitation/positioning in the case that the intent is not yet achieved, so as to ensure that the intent execution is completely consistent with the customer's real intent. For example, in the event that an IDMS consumer detects a failure of a particular terminal device, or receives customer complaints, etc., a fault delimitation/localization analysis of the specified terminal device is required, this embodiment provides an effective way to support achievement of the intent.

Although the above embodiments are all performed with respect to an IDMS architecture, embodiments of the present disclosure are not limited thereto. Fig. 6E illustrates a communication process 600-5 that may be implemented in an MDAS-based communication system. In process 600-5, the MDAS consumer 320 may send a request 652 to create an MDA analysis report control instance to the MDAS producer 310 to request an analysis report for SLA problem analysis. The request 652 to create the MDA analysis report control instance may include an analysis identity (valued SLA assurance problem analysis), a reporting mode (valued flow reporting/file reporting), and an analysis configuration, which may include an analysis area, an analysis time, an analysis terminal identity (e.g., terminal IMSI).

At 654, after receiving the SLA problem analysis request, the MDAS producer 310 may obtain a terminal traffic flow end-to-end path based on analyzing a terminal identity (e.g., a terminal IMSI). The MDAS producer 310 may obtain the terminal traffic end-to-end path in a similar manner to the process 504A shown in fig. 5B. For example, the MDAS producer 310 may obtain, from the AMF, an AMF UE NGAP ID corresponding to the terminal device and a base station IP corresponding to the AMF UE NGAP ID according to the terminal IMSI, obtain, from the UPF, terminal access server information UPF N3 IP according to the terminal IMSI, and query, from the TN, a hop-by-hop TN device through which the terminal access server passes according to the base station IP and the UPF N3 IP.

At 656, the MDAS producer 310 may calculate SLA key indicators. Because AMF UE NGAP ID is globally unique in the base station and AMF, the resource object identified based on AMF UE NGAP ID on the base station and the resource object identified based on AMF UE NGAP ID on the AMF are the same terminal resource object, so that one terminal device can be uniquely identified in the terminal resource of the base station. Based on the same IMSI, the UPF through which the traffic flow of the terminal device flows may also be determined. Based on the NextHop IP information of the base station, the bearing network element connected with the base station can be determined, and the hop-by-hop topology path inside the bearing network can be obtained through the stream following detection technology. The calculation of the SLA key indicator may be performed simultaneously with the acquisition of the end-to-end path of the terminal traffic flow.

Subsequently, at 658, the MDAS producer 310 may perform SLA problem analysis based on the determined terminal topology information. The MDAS producer 310 may perform SLA problem analysis in a similar manner to the process 512 shown in FIG. 5C. For example, the MDAS producer 310 may perform dyeing policy configuration and issue, and the dyeing policy configuration may include a terminal identification, terminal topology information, and a dyeing policy. Based on the configured staining strategy, the MDAS producer 310 may send the dimension measurement task configuration segment by segment for the terminal traffic flow path and receive the dimension measurement task report. The MDAS producer 310 may determine the SLA problem based on the dimension data. For example, the MDAS producer 310 may determine, according to the dimension data obtained from the base station connected to the terminal device, whether the terminal to the base station has a problem of packet loss, delay, etc., and if the problem occurs, the fault information is the identity of the base station device that has a fault, where the problem is basically due to the delay on the RAN side or the packet loss on the RAN side. Similarly, the MDAS producer 310 may determine whether there is a failure on the transmission side and the core network side according to the maintenance task reports obtained from the TN and UPF on the end-to-end path of the terminal traffic flow, and if there is a failure, determine the corresponding failed device identity and failure type.

At 660, the MDAS producer 310 may report the terminal identification, terminal traffic flow topology information, failed device identification, and SLA problem root cause according to the flow reporting/file indication. The terminal identity may comprise a terminal IMSI for indicating a certain terminal device. The terminal traffic topology information may include terminal traffic end-to-end paths and SLA key indicator values (optional). The end-to-end path of the terminal traffic flow may include a base station, a transmission device, a UPF, a server, and the like. The SLA key indexes comprise packet loss rate, time delay, user rate and the like. For example, the terminal traffic topology information may include a terminal traffic end-to-end path and an end-to-end performance index of traffic associated with the terminal device between the terminal device and the server, e.g., denoted ：{Topo<"gnodeb":{"ip":"10.200.32.2","name":"L2-Test"},"tn":[{"index":0,"name":"L2-UPE-2PTN980"},{"index":1,"name":"L5-NPE-27900E-32"}],"upf":{"ip":"192.5.130.4"},"dn":{"ip":"19.3.24.101"}>,Indicators<"packet loss ratio":{0.1％},"latency":{23ms},"user experienced data rate":{"UL":180Mbps,"DL":25Mbps}>}, where gnodeb is base station information, including base station IP and base station name; tn is a transmission device list, which contains the positions and names of the transmission devices connected with the base station and the transmission devices connected with the UPF, when "index" takes 0 to represent the transmission devices connected with the base station, takes 1 to represent the transmission devices connected with the UPF; UPF is UPF information, including UPF N3 IP; dn is server information and includes server IP. The failed device identity may correspond to information about a particular node in the topology information that caused the SLA problem. The root cause of the SLA problem may include the location and type of the problem, such as RAN-side latency.

In process 600-5, in an MDAS-based architecture, an MDAS producer may query a core network for terminal topology information based on this information by adding terminal identification to be analyzed when creating an SLA problem analysis. By adding terminal identification and terminal topology information in the MDAS report content, MDAS consumers can acquire terminal service flow paths, and the achievement of SLA problem analysis is ensured. The terminal service flow path acquisition indication, the terminal identification and the terminal topology information reporting function are effective supplements to the achievement of SLA problem analysis.

Fig. 7 illustrates a flow chart of a method 700 for reporting traffic flow end-to-end paths according to some embodiments of the present description. In one possible implementation, the method 700 may be implemented by the first network element 110 of the communication system 100. In other possible implementations, the method 700 may also be implemented by other electronic devices independent of the communication system 100. As an example, the method 700 will be described hereinafter as being implemented by the first network element 110 in the communication system 100.

At step 720, the first network element 110 receives path query information from the second network element 120, the path query information being used to determine a traffic flow end-to-end path of the terminal device. At step 740, the first network element 110 sends a service report to the second network element 120, the service report including a traffic flow end-to-end path, the traffic flow end-to-end path being associated with the path query information. In this way, the traffic flow end-to-end path is provided in the service report, thereby facilitating evaluation of the particular SLA quality of the traffic flow.

In some embodiments, the service associated with the service report may include a service level agreement SLA assurance intent. The method may further comprise: the first network element 110 determines a current performance value of the SLA provisioning intent; and based on the current performance value of the SLA provisioning intent, the first network element 110 determines an achievement status of the SLA provisioning intent, which may include achievement or non-achievement. Sending the service report to the second network element 120 may include: if the achievement status of the SLA assurance intent is not achieved, the first network element 110 sends a service report to the second network element 120. In this way, it is possible to support acquisition of traffic flow end-to-end paths when SLA provisioning intent is not achieved, which facilitates SLA failure analysis and failure localization/localization in intent-based services. In addition, the service producer can autonomously judge the achievement state of the SLA guarantee intention, and provide a service consumer with a service flow end-to-end path when the SLA guarantee intention is not achieved, which can reduce the resource overhead required for SLA monitoring.

In some embodiments, the method may further comprise: the first network element 110 receives a first message from the second network element 120 indicating that the achieved status of the SLA assurance intent is determined by the first network element 110 and if the achieved status of the SLA assurance intent is not achieved, a service report is sent by the first network element 110 to the second network element 120. In this way, such configurable reporting operations increase flexibility, facilitating adaptability to different needs.

In some embodiments, sending the service report to the second network element 120 may include: in response to receiving the second message from the second network element 120, the first network element 110 sends a service report to the second network element 120. The second message is used to instruct the first network element 110 to perform SLA failure analysis. The service report may also include at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred. In this way, the first network element 110 is able to perform failure analysis in the presence of SLA failures, thereby helping to delimit and locate the failures.

In some embodiments, the SLA fault analysis indication may comprise at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred. In this way, implementation of SLA failure analysis can be facilitated.

In some embodiments, the traffic flow end-to-end path may include at least one of the following nodes: a base station connected to the terminal device; a transmission device connected to a base station connected to the terminal device; a transmission device connected to the UPF; UPF; and a server connected to the UPF. In this way, information about path nodes can be provided in the service report to facilitate SLA assessment.

In some embodiments, the service report may also include SLA indicators. The SLA index may include at least one of: an end-to-end performance index of a service flow associated with the terminal device between the terminal device and the server; wireless side performance index of service flow between terminal equipment and base station; a transmission side performance index of the service flow between the transmission equipment connected with the base station and the transmission equipment connected with the UPF; and core network side performance index of the service flow between the UPF and the server. In this way, segment performance indicators between nodes can be provided in a service report to facilitate evaluation of a particular SLA quality of a traffic flow.

In some embodiments, the path query information may include at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located. In this way, the traffic end-to-end path can be conveniently acquired.

Fig. 8 illustrates a flow chart of a method 800 for acquiring a traffic flow end-to-end path according to some embodiments of the present description. In one possible implementation, the method 800 may be implemented by the second network element 120 of the communication system 100. In other possible implementations, the method 800 may also be implemented by other electronic devices independent of the communication system 100. As an example, the method 800 will be described hereinafter as being implemented by the second network element 120 in the communication system 100.

At step 820, the second network element 120 sends path query information to the first network element 110, the path query information being used to determine a traffic flow end-to-end path of the terminal device. At step 840, the second network element 120 receives a service report from the first network element 110, the service report including a traffic flow end-to-end path, the traffic flow end-to-end path being associated with path query information. In this way, the traffic flow end-to-end path is provided in the service report, thereby facilitating evaluation of the particular SLA quality of the traffic flow.

In some embodiments, the service associated with the service report may include a service level agreement SLA assurance intent. Receiving a service report from the first network element 110 may include: if the achievement status of the SLA assurance intent is not achieved, the second network element 120 receives a service report from the first network element 110.

In some embodiments, the method may further comprise: the second network element 120 sends a first message to the first network element 110. The first message is used to indicate a determination by the first network element 110 of an achievement status of the SLA assurance intent and to send a service report by the first network element 110 to the second network element 120 if the achievement status of the SLA assurance intent is not achieved.

In some embodiments, the method may further comprise: the second network element 120 sends a second message to the first network element 110. The second message is used to instruct the first network element 110 to perform SLA failure analysis. The service report is received based on the second message, and the service report may further include at least one of an identification of a failed device on the end-to-end path of the traffic flow for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred.

In some embodiments, the SLA fault analysis indication may comprise at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

In some embodiments, the traffic flow end-to-end path may include at least one of the following nodes: a base station connected to the terminal device; a transmission device connected to a base station connected to the terminal device; a transmission device connected to the UPF; UPF; and a server connected to the UPF.

In some embodiments, the service report may also include SLA indicators. The SLA index may include at least one of: an end-to-end performance index of a service flow associated with the terminal device between the terminal device and the server; wireless side performance index of service flow between terminal equipment and base station; a transmission side performance index of the service flow between the transmission equipment connected with the base station and the transmission equipment connected with the UPF; and core network side performance index of the service flow between the UPF and the server.

In some embodiments, the path query information may include at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

Fig. 9 illustrates a flow chart of a method 900 for acquiring a traffic flow end-to-end path according to some embodiments of the present description. In one possible implementation, the method 900 may be implemented by the communication system 100. In other possible implementations, the method 900 may also be implemented by other electronic devices independent of the communication system 100. By way of example, method 900 will be described below as being implemented by communication system 100.

At step 920, the second network element 120 of the communication system 100 sends path query information to the first network element 110 of the communication system 100, the path query information being used to determine a traffic flow end-to-end path of the terminal device. At step 940, the first network element 110 receives path query information from the second network element 120. At step 960, the first network element 110 sends a service report to the second network element 120, the service report including a traffic flow end-to-end path, the traffic flow end-to-end path being associated with the path query information. At step 980, the second network element 120 receives a service report from the first network element 110. In this way, the traffic flow end-to-end path is provided in the service report, thereby facilitating evaluation of the particular SLA quality of the traffic flow.

In some embodiments, the method may further comprise: the second network element 120 sends a first message to the first network element 110, the first message indicating that the achieved state of the SLA assurance intent is determined by the first network element 110 and if the achieved state of the SLA assurance intent is not achieved, sending a service report to the second network element 120 by the first network element 110; and the first network element 110 receives the first message from the second network element 120.

In some embodiments, the method may further comprise: the second network element 120 sends a second message to the first network element 110, where the second message is used to instruct the first network element 110 to perform SLA fault analysis. In response to receiving the second message from the second network element 120, the first network element 110 sends a service report to the second network element 120, wherein the service report may further include at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of SLA failure, and a time at which the SLA failure occurred.

In some embodiments, the SLA fault analysis indication may comprise at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

In some embodiments, the traffic flow end-to-end path may include at least one of the following nodes: a base station connected to the terminal device; a transmission device connected to a base station connected to the terminal device; a transmission device connected to the UPF; UPF; and a server connected to the UPF.

In some embodiments, the service report may also include SLA indicators, which may include at least one of: an end-to-end performance index of a service flow associated with the terminal device between the terminal device and the server; wireless side performance index of service flow between terminal equipment and base station; a transmission side performance index of the service flow between the transmission equipment connected with the base station and the transmission equipment connected with the UPF; and core network side performance index of the service flow between the UPF and the server.

In some embodiments, the path query information may include at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

Fig. 10 illustrates a schematic block diagram of a first communication device 1000 in accordance with some embodiments of the application. The first communications apparatus 1000 may be implemented as a device or chip in a device, as the scope of the application is not limited in this respect. The communications apparatus 1000 can include a plurality of modules for performing corresponding steps in the method 700 as discussed in fig. 7. The communication device 1000 may be implemented as the first network element 110 as shown in fig. 1 or as a part of the first network element 110.

As shown in fig. 10, the communication device 1000 includes a receiving module 1010 and a transmitting module 1020. In some embodiments, the communications apparatus 1000 can also include a processing module 1030. The receiving module 1010 is configured to receive data, the transmitting module 1020 is configured to transmit data, and the processing module 1030 is configured to process data. For example, the receiving module 1010 is configured to receive path query information. In some embodiments, the receiving module 1010 is further configured to receive the first message. The sending module 1020 is configured to send a service report. The processing module 1030 is configured to determine a current performance value of the SLA assurance intent and determine an achievement status of the SLA assurance intent based on the current performance value of the SLA assurance intent. Details are described with reference to fig. 4, and are not described here.

Fig. 11 shows a schematic block diagram of a second communication device 1100 according to further embodiments of the application. The second communications apparatus 1100 may be implemented as a device or chip in a device, as the scope of the application is not limited in this respect. The communications apparatus 1100 can include a plurality of modules for performing corresponding steps in the method 800 as discussed in fig. 8. The communication device 1100 may be implemented as the second network element 120 or as a part of the second network element 120 as shown in fig. 1.

As shown in fig. 11, the communication apparatus 1100 includes a transmitting module 1110 and a receiving module 1120. In some embodiments, the communications apparatus 1100 can also include a processing module 1030. The transmitting module 1110 is used for transmitting data, the receiving module 1120 is used for receiving data, and the processing module 1130 is used for processing data. For example, the sending module 1110 is configured to send path query information. In some embodiments, the sending module 1110 is further configured to send the first message. In some embodiments, the sending module 1110 is further configured to send a second message. The receiving module 1120 is configured to receive a service report. In some embodiments, processing module 1130 is used to determine the achievement status of the SLA assurance intent. Details are described with reference to fig. 4, and are not described here.

Fig. 12 shows a schematic block diagram of a third communication device 1200 according to further embodiments of the application. Third communication apparatus 1200 may be implemented as a device or as a chip in a device, as the scope of the application is not limited in this respect. The communications apparatus 1200 can include a plurality of modules for performing corresponding steps in the method 900 as discussed in fig. 9. The communication apparatus 1200 may be implemented as the communication system 100 as shown in fig. 1 or as part of the communication system 100.

As shown in fig. 12, the communication apparatus 1200 includes a transmission module 1210 and a reception module 1220. In some embodiments, the communications apparatus 1200 can also include a processing module 1230. The transmitting module 1210 is used for transmitting data, the receiving module 1220 is used for receiving data, and the processing module 1230 is used for processing data. For example, the transmitting module 1210 is configured to transmit path query information, a service report, a first message, and a second message. The receiving module 1220 is configured to receive path query information, a service report, a first message, and a second message. The processing module 1230 is used to determine a current performance value of the SLA assurance intent and determine an achievement status of the SLA assurance intent based on the current performance value of the SLA assurance intent. Details are described with reference to fig. 4, and are not described here.

Fig. 13 is a simplified block diagram of an example device 1300 suitable for implementing embodiments of the present description. The apparatus 1300 may be used to implement the first network element 110, the second network element 120, or the communication system 100 as shown in fig. 1. As shown, the device 1300 includes one or more processors 1310, one or more memories 1320 coupled to the processors 1310, and a communication module 1340 coupled to the processors 1310. In some embodiments, memory 1320 and processor 1310 may be integrated.

The communication module 1340 may be used for two-way communication. The communication module 1340 may include a transmitter 1341 for transmitting data and a receiver 1342 for receiving data. When the apparatus 1300 is used to implement the first network element 110 as shown in fig. 1, the transmitter 1341 is used to implement the function of the transmitting module 1020 as shown in fig. 10, and the receiver 1342 is used to implement the function of the receiving module 1010 as shown in fig. 10. When the apparatus 1300 is used to implement the second network element 120 as shown in fig. 1, the transmitter 1341 is used to implement the function of the transmitting module 1110 as shown in fig. 11, and the receiver 1342 is used to implement the function of the receiving module 1120 as shown in fig. 11. When the apparatus 1300 is used to implement the communication system 100 as shown in fig. 1, the transmitter 1341 is used to implement the function of the transmitting module 1210 as shown in fig. 12, and the receiver 1342 is used to implement the function of the receiving module 1220 as shown in fig. 12.

The processor 1310 may be of any type suitable to the local technology network and may include, but is not limited to, at least one of the following: one or more of a general purpose computer, a special purpose computer, a microcontroller, a digital signal Processor (DIGITAL SIGNAL Processor, DSP), or a controller-based multi-core controller architecture. The device 1300 may have multiple processors, such as application specific integrated circuit chips, that are temporally slaved to a clock that is synchronized to the master processor.

Memory 1320 may include one or more non-volatile memories and one or more volatile memories. Examples of non-volatile memory include, but are not limited to, at least one of: read-Only Memory (ROM) 1324, erasable programmable Read-Only Memory (Erasable Programmable Read Only Memory, EPROM), flash Memory, hard disk, compact Disc (CD), digital video Disc (DIGITAL VERSATILE DISC, DVD), or other magnetic and/or optical storage. Examples of volatile memory include, but are not limited to, at least one of: random access memory (Random Access Memory, RAM) 1322, or other volatile memory that does not last for the duration of the power outage.

The computer program 1330 includes computer-executable instructions that are executed by an associated processor 1310. Program 1330 may be stored in ROM 1320. Processor 1310 may perform any suitable actions and processes by loading program 1330 into RAM 1320.

Embodiments of the present description may be implemented by means of program 1330 such that device 1300 may perform any of the processes as discussed with reference to fig. 4-9. Embodiments of the present description may also be implemented in hardware or by a combination of software and hardware.

In some embodiments, program 1330 may be tangibly embodied in a computer-readable medium, which may be included in device 1300 (such as in memory 1320) or other storage device accessible by device 1300. Program 1330 may be loaded from a computer-readable medium into RAM 1322 for execution. The computer readable medium may include any type of tangible, non-volatile memory, such as ROM, EPROM, flash memory, hard disk, CD, DVD, etc.

In general, the various embodiments of the specification may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device. While various aspects of the embodiments of this specification are illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

The present specification also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product comprises computer executable instructions, such as instructions included in program modules, which are executed in a device on a real or virtual processor of a target to perform the processes/methods as described above with reference to fig. 4-9. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform particular tasks or implement particular abstract data types. In various embodiments, the functionality of the program modules may be combined or split between program modules as desired. Machine-executable instructions for program modules may be executed within local or distributed devices. In distributed devices, program modules may be located in both local and remote memory storage media.

Computer program code for carrying out methods of the present description may be written in one or more programming languages. These computer program code may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the computer or other programmable data processing apparatus, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the computer, partly on the computer, as a stand-alone software package, partly on the computer and partly on a remote computer or entirely on the remote computer or server.

In the context of this specification, computer program code or related data may be carried by any suitable carrier to enable an apparatus, device or processor to perform the various processes and operations described above. Examples of carriers include signals, computer readable media, and the like. Examples of signals may include electrical, optical, radio, acoustical or other form of propagated signals, such as carrier waves, infrared signals, etc.

A computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More detailed examples of a computer-readable storage medium include an electrical connection with one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical storage device, a magnetic storage device, or any suitable combination thereof.

Furthermore, although the operations of the methods of the present description are depicted in the drawings in a particular order, this is not required to or suggested that these operations must be performed in this particular order or that all of the illustrated operations must be performed in order to achieve desirable results. Rather, the steps depicted in the flowcharts may change the order of execution. Additionally or alternatively, certain steps may be omitted, multiple steps combined into one step to perform, and/or one step decomposed into multiple steps to perform. It should also be noted that features and functions of two or more devices according to the present description may be embodied in one device. Conversely, the features and functions of one device described above may be further divided into multiple devices to be embodied.

The implementations of the present specification have been described above, the foregoing description is exemplary, not exhaustive, and not limited to the implementations disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the illustrated implementations. The terminology used herein was chosen in order to best explain the principles of each implementation, the practical application, or the improvement of technology in the marketplace, or to enable others of ordinary skill in the art to understand each implementation disclosed herein.

Claims (30)

1. A method of communication, comprising:

The method comprises the steps that a first network element receives path query information from a second network element, wherein the path query information is used for determining a service flow end-to-end path of terminal equipment; and

The first network element sends a service report to the second network element, wherein the service report comprises the service flow end-to-end path, and the service flow end-to-end path is associated with the path query information.

2. The method of claim 1, wherein the service associated with the service report includes a service level agreement SLA assurance intent, the method further comprising:

the first network element determines the current performance value of the SLA guarantee intention; and

Based on the current performance value of the SLA provisioning intent, the first network element determines an achievement status of the SLA provisioning intent, the achievement status including achieved or not achieved,

Wherein sending the service report to the second network element comprises: if the achievement status of the SLA assurance intent is not achieved, the first network element sends the service report to the second network element.

3. The method of claim 2, further comprising:

The first network element receives a first message from the second network element, the first message indicating that an achievement status of the SLA assurance intent is determined by the first network element and if the achievement status of the SLA assurance intent is not achieved, the service report is sent by the first network element to the second network element.

4. The method of claim 1, wherein sending the service report to the second network element comprises:

In response to receiving a second message from the second network element, the first network element sends the service report to the second network element, wherein the second message is used to instruct the first network element to perform an SLA failure analysis, and the service report further includes at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of the SLA failure, and a time at which the SLA failure occurred.

5. The method of claim 4, wherein the SLA fault analysis indication comprises at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

6. The method of any of claims 1 to 5, wherein the traffic flow end-to-end path comprises at least one of the following nodes:

A base station connected to the terminal device;

a transmission device connected to a base station connected to the terminal device;

transmission equipment connected with the user plane function network element UPF;

UPF; and

A server connected to the UPF.

7. The method of claim 6, wherein the service report further comprises SLA indicators comprising at least one of:

An end-to-end performance index of a traffic flow associated with the terminal device between the terminal device and the server;

a wireless side performance index of the service flow between the terminal equipment and the base station;

a transmission side performance index of the service flow between a transmission device connected with the base station and a transmission device connected with the UPF; and

And the performance index of the service flow at the core network side between the UPF and the server.

8. The method according to any one of claims 1 to 5 and 7, wherein the path query information includes at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

9. A method of communication, comprising:

The second network element sends path inquiry information to the first network element, wherein the path inquiry information is used for determining the end-to-end path of the service flow of the terminal equipment; and

The second network element receives a service report from the first network element, the service report including the traffic flow end-to-end path, the traffic flow end-to-end path being associated with the path query information.

10. The method of claim 9, wherein the service associated with the service report includes a service level agreement SLA assurance intent, wherein receiving the service report from the first network element comprises:

if the achievement status of the SLA assurance intent is not achieved, the second network element receives the service report from the first network element.

11. The method of claim 10, further comprising:

The second network element sends a first message to the first network element, the first message being used to indicate that the achievement status of the SLA assurance intent is determined by the first network element and if the achievement status of the SLA assurance intent is not achieved, the service report is sent by the first network element to the second network element.

12. The method of claim 9, further comprising:

The second network element sends a second message to the first network element, wherein the second message is used for indicating the first network element to perform SLA fault analysis,

Wherein the service report is received based on the second message, the service report further comprising at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of the SLA failure, and a time at which the SLA failure occurred.

13. The method of claim 12, wherein the SLA fault analysis indication comprises at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

14. The method of any of claims 9 to 13, wherein the traffic flow end-to-end path comprises at least one of the following nodes:

A base station connected to the terminal device;

A transmission device connected to a base station connected to the terminal device; and

Transmission equipment connected with the user plane function network element UPF;

UPF; and

A server connected to the UPF.

15. The method of claim 14, wherein the service report further comprises SLA indicators comprising at least one of:

An end-to-end performance index of a traffic flow associated with the terminal device between the terminal device and the server;

a wireless side performance index of the service flow between the terminal equipment and the base station;

a transmission side performance index of the service flow between a transmission device connected with the base station and a transmission device connected with the UPF; and

And the performance index of the service flow at the core network side between the UPF and the server.

16. The method according to any one of claims 9 to 13 and 15, wherein the path query information comprises at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

17. A method of communication, comprising:

the second network element sends path inquiry information to the first network element, wherein the path inquiry information is used for determining the end-to-end path of the service flow of the terminal equipment;

The first network element receives the path query information from the second network element;

The first network element sends a service report to the second network element, wherein the service report comprises the service flow end-to-end path, and the service flow end-to-end path is associated with the path query information; and

The second network element receives the service report from the first network element.

18. The method of claim 17, wherein the service associated with the service report includes a service level agreement SLA assurance intent, the method further comprising:

the first network element determines the current performance value of the SLA guarantee intention; and

Based on the current performance value of the SLA provisioning intent, the first network element determines an achievement status of the SLA provisioning intent, the achievement status including achieved or not achieved,

Wherein if the achievement status of the SLA assurance intent is not achieved, the first network element sends the service report to the second network element and the second network element receives the service report from the first network element.

19. The method of claim 18, further comprising:

The second network element sending a first message to the first network element, the first message being for indicating that the achievement status of the SLA assurance intent is determined by the first network element and sending the service report to the second network element by the first network element if the achievement status of the SLA assurance intent is not achieved; and

The first network element receives the first message from the second network element.

20. The method of claim 17, further comprising:

The second network element sends a second message to the first network element, wherein the second message is used for indicating the first network element to perform SLA fault analysis;

Wherein in response to receiving the second message from the second network element, the first network element sends the service report to the second network element, wherein the service report further includes at least one of an identification of a failed device on the traffic flow end-to-end path for which an SLA failure exists, a type of the SLA failure, and a time at which the SLA failure occurred.

21. The method of claim 20, wherein the SLA fault analysis indication comprises at least one of a terminal identity of the terminal device and a time at which the SLA fault occurred.

22. The method of any of claims 17 to 21, wherein the traffic flow end-to-end path comprises at least one of the following nodes:

A base station connected to the terminal device;

a transmission device connected to a base station connected to the terminal device;

transmission equipment connected with the user plane function network element UPF;

UPF; and

A server connected to the UPF.

23. The method of claim 22, wherein the service report further comprises SLA indicators comprising at least one of:

An end-to-end performance index of a traffic flow associated with the terminal device between the terminal device and the server;

a wireless side performance index of the service flow between the terminal equipment and the base station;

a transmission side performance index of the service flow between a transmission device connected with the base station and a transmission device connected with the UPF; and

And the performance index of the service flow at the core network side between the UPF and the server.

24. The method according to any one of claims 17 to 21 and 23, wherein the path query information comprises at least one of a terminal identification of the terminal device and terminal area information in which the terminal device is located.

25. An electronic device comprising a multi-core processor and a memory having instructions stored thereon that, when executed by the multi-core processor, cause the electronic device to implement the method of any of claims 1-8.

26. An electronic device comprising a multi-core processor and a memory having instructions stored thereon that, when executed by the multi-core processor, cause the electronic device to implement the method of any of claims 9-16.

27. A communication system comprising a first network element and a second network element, the communication system being configured to implement the method of any of claims 17 to 24 with the first network element and the second network element.

28. A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements the method according to any of claims 1 to 24.

29. A chip comprising processing circuitry configured to perform the method of any one of claims 1 to 24.

30. A computer program product tangibly stored on a computer-readable medium and comprising computer-executable instructions that, when executed, cause an apparatus to implement the method of any one of claims 1 to 24.