WO2024119884A1 - Procédé de détection de service, procédé de génération de données, procédé d'envoi de données, dispositif électronique et support de stockage - Google Patents

Procédé de détection de service, procédé de génération de données, procédé d'envoi de données, dispositif électronique et support de stockage Download PDF

Info

Publication number
WO2024119884A1
WO2024119884A1 PCT/CN2023/113789 CN2023113789W WO2024119884A1 WO 2024119884 A1 WO2024119884 A1 WO 2024119884A1 CN 2023113789 W CN2023113789 W CN 2023113789W WO 2024119884 A1 WO2024119884 A1 WO 2024119884A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
node
information
real
sent
Prior art date
Application number
PCT/CN2023/113789
Other languages
English (en)
Chinese (zh)
Inventor
李和松
段威
何辉
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2024119884A1 publication Critical patent/WO2024119884A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W24/00—Supervisory, monitoring or testing arrangements
    • H04W24/10—Scheduling measurement reports ; Arrangements for measurement reports

Definitions

  • the present application relates to the field of communication technology, and in particular to a service perception method, a data generation method and a sending method, an electronic device, and a storage medium.
  • the embodiments of the present application provide a service perception method, a data generation method and a sending method, an electronic device, and a storage medium, which are intended to improve network service perception capabilities and enhance network feasibility.
  • an embodiment of the present application provides a service perception method, including:
  • the service health information is sent to the first node on the network side, and the flow real-time information is sent to the second node on the service side, so that the network side and the service side perform two-way information exchange based on the service health information and the flow real-time information.
  • the embodiment of the present application further provides a service perception method, including:
  • the service health information is sent by the fourth node to the first node on the network side.
  • the embodiment of the present application further provides a service perception method, including:
  • the real-time traffic information is sent by the fourth node to the second node on the service side.
  • the present application also provides a data generation method, including:
  • an embodiment of the present application further provides a data sending method, comprising:
  • the service-aware network identifier is sent to the first node on the network side through a third node on the network side, so that the first node generates a routing forwarding table according to the service-aware network identifier, wherein the routing forwarding table corresponds to the service-aware network identifier.
  • an embodiment of the present application further provides a data sending method, including:
  • the service-aware network identifier is sent to the terminal and the fifth node on the service side, so that the terminal sends a first data message carrying the service-aware network identifier, and the fifth node performs service call chain tracking and analysis according to the service-aware network identifier.
  • an embodiment of the present application further provides a data sending method, including:
  • an embodiment of the present application also provides an electronic device, comprising: at least one processor; at least one memory for storing at least one program; when at least one of the programs is executed by at least one of the processors, it implements the service perception method as described above, or implements the data generation method as described above, or implements the data sending method as described above.
  • an embodiment of the present application also provides a computer-readable storage medium, which stores a program executable by a processor, and the program executable by the processor is used to implement the service perception method as described above, or to implement the data generation method as described above, or to implement the data sending method as described above when executed by the processor.
  • the network side and the service side perform two-way information exchange based on the service health information and the real-time traffic information, so as to achieve further improvement of network service perception capability and network feasibility in the scenario of multiple resource pools deployed for the same service through two-way information exchange, and to perform intelligent scheduling of user access service traffic based on network quality and service health, thereby improving the intelligence level of network services and facilitating the expansion of application scenarios of network services.
  • user-level granularity performance detection and call chain tracking can be achieved, so as to improve the refined diagnostic capability from the network side to the service side.
  • FIG1 is a schematic diagram of a cloud network service system in the related art
  • FIG2 is a schematic diagram of an implementation environment for executing a service awareness method or/and a data generation method or/and a data transmission method provided by an embodiment of the present application;
  • FIG3 is a flow chart of step S1000 provided in one embodiment of the present application.
  • FIG4 is a flow chart of a data sending method provided by an embodiment of the present application.
  • FIG5 is a flow chart of step S3000 in FIG4 ;
  • FIG6 is a flow chart of a data sending method provided by another embodiment of the present application.
  • FIG7 is a flow chart of step S4000 in FIG6 ;
  • FIG8 is a flow chart of step S7000 provided in one embodiment of the present application.
  • FIG9 is a schematic diagram of generating and distributing SAN-IDs according to an embodiment of the present application.
  • FIG10 is a schematic diagram of a SAN-ID encapsulation format provided by an embodiment of the present application.
  • FIG11 is a flow chart of a service perception method provided by an embodiment of the present application.
  • FIG12 is a flow chart of obtaining service health information in a service perception method provided in one embodiment of the present application.
  • FIG13 is a flow chart of a service awareness method provided by another embodiment of the present application.
  • FIG14 is a flow chart of step S13000 in FIG13 ;
  • FIG. 15 is a flowchart of steps S15000 to S16000 provided in one embodiment of the present application.
  • FIG16 is a flow chart of a service perception method provided by an embodiment of the present application.
  • FIG17 is a schematic diagram of service perception performed on a network side and a service side according to an embodiment of the present application
  • FIG18 is an overall execution flow chart of a service perception method, a data generation method, and a data transmission method provided by an embodiment of the present application;
  • FIG. 19 is a schematic diagram of an electronic device provided according to an embodiment of the present application.
  • the words “further”, “exemplarily” or “optionally” are used to indicate examples, illustrations or descriptions, and should not be interpreted as being more preferred or more advantageous than other embodiments or designs.
  • the use of the words “further”, “exemplarily” or “optionally” is intended to present related concepts in a specific way.
  • the network operator includes a business orchestrator, a network controller and network equipment connected in sequence.
  • the service operator internally configures the service client and each service instance.
  • Each service instance corresponds to each resource pool in the cloud resource pool operator.
  • the service operator is set at the Software-as-a-Service (SaaS) layer
  • the cloud resource pool operator is set at the SaaS layer and the Infrastructure-as-a-Service (IaaS) layer. Due to the differences between the cloud and network sides and management restrictions, the network operator, service operator and cloud resource pool operator are usually independently operated and maintained by the three parties.
  • the present application provides a service perception method, a data generation method and a sending method, an electronic device, and a storage medium.
  • the service perception method of one embodiment includes: sending service health information to a first node on the network side, and sending real-time traffic information to a second node on the service side, so that the network side and the service side perform two-way information exchange based on the service health information and the real-time traffic information.
  • the data sending method of one embodiment includes: receiving a service-aware network identifier sent by a seventh node on the network side, the service-aware network identifier being generated by the seventh node; sending a service-aware network identifier to a terminal and a fifth node on the service side, so that the terminal sends a first data packet carrying the service-aware network identifier, and so that the fifth node performs service call chain tracking and analysis based on the service-aware network identifier.
  • the network side and the service side perform two-way information exchange based on the service health information and the real-time traffic information, so as to achieve the scenario of multiple resource pools of the same service deployed through two-way information exchange. Further improve the network service perception capability, enhance the network feasibility, and be able to intelligently schedule user access service traffic based on network quality and service health, improve the intelligence level of network services, and help expand the application scenarios of network services.
  • user-level granularity performance detection and call chain tracking can be achieved, so as to improve the refined diagnostic capabilities from the network side to the service side.
  • FIG. 2 is a schematic diagram of an implementation environment for executing a service awareness method and/or a data generation method and/or a data sending method provided by an embodiment of the present application.
  • the implementation environment includes a network side 100 and a service side 200.
  • the network side 100 has the ability to communicate unidirectionally with the service side 200
  • the service side 200 also has the ability to communicate unidirectionally with the network side 100.
  • intelligent scheduling of user access service traffic can be achieved, as well as performance detection and fault diagnosis from the network side 100 to the service side 200.
  • the network side 100 may be an operator network side 100, and the network applied by the operator network side 100 may be a network of various types and conditions, such as but not limited to 5G network, 6G network and other networks, etc.
  • the service type of the service side 200 may be various, such as but not limited to cloud service, terminal service, etc., and the present embodiment is Unrestricted.
  • the specific architecture of the network side 100 may be set accordingly according to the specific application scenario, which is not limited here.
  • the network side 100 includes but is not limited to:
  • the service orchestrator 110 may be a network service application system of an operator, may communicate with multiple subsystems, may reach a service level agreement (SLA) with a service provider on the service side 200, may technically generate a service awareness network identifier (SAN-ID) and core parameters of a service awareness network (SAN), and may convert related information into network policies;
  • SLA service level agreement
  • SAN-ID service awareness network identifier
  • SAN service awareness network
  • the network controller 120 is connected to the service orchestrator 110 and is capable of opening and monitoring the actual services of the operator network, converting the service orchestration requirements into specific policy configurations of network element devices, and also has functions such as centralized path calculation and controlling the behavior of the network computing perception module 140;
  • the SAN gateway 130 is connected to the network controller 120 and refers to the ingress router and egress router of the operator's bearer network. It can be upgraded according to the needs of the SAN itself. It is a core network device for realizing traffic forwarding and perception routing. It identifies the SAN-ID in the user traffic from the terminal and performs corresponding forwarding actions.
  • the terminal is the initiator of the user access traffic of the end-side subsystem. Regardless of the type of the terminal, it has the authority and ability to access the service. The ability and method of accessing the service can be controlled by itself. There is no limitation here. In this embodiment, the SAN-ID can be carried in the user access traffic according to the needs of service operation.
  • the computing network perception module 140 is connected to the network controller 120 and the SAN gateway 130 respectively. As a core component of this embodiment, it is connected to the service side 200 for service perception and partial network capability opening. It belongs to the category of the network side 100 in the management and maintenance interface. Its deployment location and form are relatively flexible and not restricted. Considering the differences in the design of the service side 200, the computing network perception module 140 can be but is not limited to adopting a cloud-native architecture design, and can perform flexible interface adaptation and function upgrades, etc.
  • the specific architecture of the service side 200 may be set accordingly according to a specific application scenario, which is not limited here.
  • the service side 200 includes but is not limited to:
  • the service operation system 210 is connected to the service orchestrator 110 and is used to implement daily operations of multiple services with the same operating entity. In this embodiment, it can be but not limited to being used to implement docking with the service orchestrator 110 on the network side 100 to complete negotiation registration of services;
  • the service monitoring system 220 is connected to the computing network perception module 140 and is used to implement monitoring and operation of the service side 200, provide the ability to monitor and diagnose services in depth, and provide an API interface to obtain real-time monitoring indicators and historical monitoring indicators related to user services.
  • the service gateway 230 is connected to the SAN gateway 130 and the service operation system 210 respectively, and is the entry point for users to access services. In this embodiment, it can be but not limited to the SAN-ID used to resolve user traffic;
  • Microservice 240 is used to complete specific user access requests.
  • the specific technology and specific device form used by the terminal of the end-side subsystem are not limited.
  • the terminal can be called an access terminal, a user unit, a user station, a mobile station, a mobile station, a remote station, a remote terminal, a mobile device, a user terminal, a wireless electronic device, a user agent, or a user device.
  • the terminal can be a cellular phone, a cordless phone, a Session Initiation Protocol (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a mobile phone with wireless communication function, or a wireless communication device.
  • Handheld devices, computing devices or other processing devices connected to a wireless modem, vehicle-mounted devices, wearable devices, 5G networks or terminal devices in future 5G or higher networks, etc., are not specifically limited in this embodiment.
  • FIG. 2 does not constitute a limitation on the embodiments of the present application, and may include more or fewer components than shown in the figure, or a combination of certain components, or a different arrangement of components.
  • An embodiment of the present application provides a data generation method, which can be, but is not limited to, applied to a seventh node on the network side.
  • the type of the seventh node is not limited.
  • the seventh node can be, but is not limited to, a service orchestrator on the network side in the implementation environment shown in FIG. 2.
  • the seventh node will be used as a service orchestrator for the following embodiment description, but this should not be used as a limitation of this embodiment.
  • the data generation method may include, but is not limited to, step S1000.
  • Step S1000 Generate SAN-ID.
  • the service orchestrator In this step, the service orchestrator generates a SAN-ID so as to send the generated SAN-ID to the outside in subsequent steps.
  • step S1000 which includes but is not limited to steps S1100 to S1200 .
  • Step S1100 receiving a service registration request sent by a sixth node on the service side, and verifying the service registration request, wherein the service registration request carries a service registration parameter;
  • Step S1200 When the service registration request is successfully verified, a SAN-ID is generated according to the service registration parameters, wherein the SAN-ID corresponds to the service registration request.
  • the business orchestrator receives the service registration request sent by the sixth node on the service side and verifies the service registration request to determine whether the service registration request meets the relevant registration requirements, and generates a SAN-ID according to the service registration parameters carried in the service registration request when the verification of the service registration request is successful. That is to say, the generation of the SAN-ID needs to be verified and validated, and is associated with the service registration parameters carried in the service registration request. Therefore, the SAN-ID can well represent the actual situation of the user accessing the service, so as to facilitate the subsequent steps in further using the SAN-ID to generate logs of the user accessing the service and track and analyze the call chain.
  • the type of the sixth node is not limited, for example, it may be, but is not limited to, a service operation system on the service side in the implementation environment shown in FIG. 2 .
  • the source of the service registration request is not limited, for example, it may be sent by the terminal to the sixth node, or generated by the sixth node in response to a notification signal from the terminal.
  • the service registration parameters include at least one of the following:
  • the service pointing information can be but not limited to the location information, IP address information, port number information, etc. corresponding to the service;
  • the service monitoring indicators can be but not limited to predetermined service health information, which represents the actual health status of the user service;
  • the service scheduling information can be but not limited to user scheduling SLA requirement information, which includes but is not limited to network quality requirement information (one-way or two-way, which can be delay, jitter and packet loss), service health requirement information and scheduling priority policy information;
  • the query method information for service real-time information can be but not limited to authorization information, Uniform Resource Locator (URL), etc.
  • FIG4 is a flow chart of a data transmission method provided by an embodiment of the present application, and the data generation method can be, but is not limited to, applied to the seventh node on the network side, and the seventh node can be, but is not limited to, a service orchestrator on the network side in the implementation environment shown in FIG2 .
  • the data transmission method can include, but is not limited to, steps S2000 to S3000.
  • Step S2000 Sending the SAN-ID to the sixth node on the service side, so that the sixth node sends the SAN-ID to the terminal and the fifth node on the service side;
  • Step S3000 Sending a SAN-ID to a first node on the network side through a third node on the network side, so that the first node generates a routing forwarding table according to the SAN-ID, wherein the routing forwarding table corresponds to the SAN-ID.
  • the business orchestrator sends the SAN-ID to the service operation system, so that the service operation system can send the SAN-ID to the terminal and the fifth node on the service side.
  • it sends the SAN-ID to the first node on the network side through the third node on the network side, so that the first node generates a routing table according to the SAN-ID.
  • the routing table can be used for intelligent routing of data packets sent by the terminal. That is to say, the SAN-ID is sent through two lines respectively, and the distribution process is independent, so that the nodes on each line can perform corresponding operations according to the SAN-ID to improve the user service quality.
  • the types of the third node on the network side, the fifth node on the service side, and the first node on the network side are not limited.
  • the third node may be, but is not limited to, a network controller on the network side in the implementation environment shown in FIG. 2
  • the first node may be, but is not limited to, a SAN gateway on the network side in the implementation environment shown in FIG. 2
  • the fifth node may be, but is not limited to, a service gateway on the service side in the implementation environment shown in FIG. 2 .
  • SAN-ID is an SLA protocol for user traffic between the service side and the network side. It is not strongly bound to any IP address and location information. Instead, the service side actively initiates service registration to the network side for the purpose of providing differentiated service quality assurance to different types of terminals. The network side then generates and feeds back to the service operation system.
  • the SAN-ID distribution on the network side is mainly to implement the delivery of service SLA policies
  • the SAN-ID distribution on the service side is mainly to complete the configuration of terminals and service gateways.
  • the distribution processes are independent of each other. Compared with the strong correlation between the ID and the service IP reachability information involved in the related art, most of which use a network-side DNS-like mechanism to implement the distribution of the ID to the terminal.
  • the SAN-ID in this embodiment is not bound to the actual service IP address, and the distribution to the terminal is completed by the service operation system through the interaction between the client and the control layer of the service side or a static configuration file, and does not rely on any system or module on the network side.
  • the external service IP address of the same service is allocated by the network side.
  • Users with and without SAN-ID can access the same service, but the service quality is completely different.
  • the user traffic carrying the SAN-ID can be better tracked, analyzed and processed by each node on the network side and the service side, thereby improving the service quality of the user traffic carrying the SAN-ID.
  • Improve the intelligence level of network services improve the intelligence level of network services.
  • step S2000 is further described, and step S2000 includes but is not limited to step S2100.
  • Step S2100 When the received service registration request is verified, the SAN-ID is sent to a sixth node on the service side, wherein the service registration request is sent by the sixth node.
  • the SAN-ID is sent to the sixth node on the service side to indicate the correspondence between the SAN-ID and the verified service registration request. That is, by sending the SAN-ID to the service operation system, the service operation system can confirm that the service registration request has been verified in this case.
  • step S3000 As shown in FIG. 5 , an embodiment of the present application further illustrates step S3000 , where step S3000 includes but is not limited to step S3100 .
  • Step S3100 Sending the SAN-ID and the first communication policy to the third node on the network side, so that the third node converts the first communication policy into a second communication policy adapted to the first node, and sends the SAN-ID and the second communication policy to the first node.
  • the network controller converts the first communication strategy into a second communication strategy adapted to the SAN gateway, and then the network controller sends the SAN-ID and the second communication strategy to the SAN gateway, so that the SAN gateway performs intelligent routing for the terminal according to the SAN-ID and the second communication strategy, so that the terminal can realize reliable forwarding of data packets carrying the SAN-ID.
  • the specific content of the first communication strategy and the second communication strategy, and the method of strategy conversion can be set accordingly according to the actual scenario, which is not limited here.
  • it can be the SLA strategy shown in Figure 4, and an embodiment will be given later for specific explanation.
  • Figure 6 is a flow chart of a data transmission method provided by another embodiment of the present application, and the data generation method can be but is not limited to being applied to the sixth node on the network side.
  • the data transmission method can include but is not limited to steps S4000 to S5000.
  • Step S4000 receiving a SAN-ID sent by a seventh node on the network side, where the SAN-ID is generated by the seventh node;
  • Step S5000 Sending the SAN-ID to the terminal and the fifth node on the service side, so that the terminal sends a first data message carrying the SAN-ID, and the fifth node performs service call chain tracking and analysis according to the SAN-ID.
  • the SAN-ID can be sent to the terminal and the service gateway, so that the terminal sends a first data packet carrying the SAN-ID, and the service gateway can perform service call chain tracking and analysis based on the SAN-ID when receiving the first data packet.
  • User-level granularity performance detection and call chain tracking can be achieved, so as to enhance the refined diagnostic capabilities from the network side to the service side.
  • the service gateway can identify the SAN-ID in the user's first data packet, and use the SAN-ID for processes such as log generation of user access to services and tracking and analysis of call chains.
  • the service monitoring system can provide service call chain analysis capabilities with SAN granularity and coverage of bearer network link information, providing end-to-end capability support for performance optimization and troubleshooting of user services.
  • step S4000 also includes but is not limited to step S6000.
  • Step S6000 Send a service registration request carrying service registration parameters to the seventh node on the network side, so that the seventh node verifies the service registration request, and when the seventh node successfully verifies the service registration request, the seventh node generates a SAN-ID according to the service registration parameters, wherein the SAN-ID corresponds to the service registration request.
  • a service registration request is sent to the service choreographer so that the service choreographer can process the service registration request.
  • a check is performed to determine whether the service registration request meets the relevant registration requirements, and if the service registration request is successfully checked, a SAN-ID is generated according to the service registration parameters carried in the service registration request. In other words, the generation of the SAN-ID needs to be verified and checked, and is associated with the service registration parameters carried in the service registration request. Therefore, the SAN-ID can well represent the actual situation of the user accessing the service, so as to facilitate the subsequent steps of further generating logs of user accessing the service and tracking and analyzing the call chain through the SAN-ID.
  • step S4000 which includes but is not limited to step S4100 .
  • Step S4100 When the seventh node verifies that the service registration request has been passed, receive the SAN-ID sent by the seventh node.
  • the business orchestrator sends the SAN-ID to the service operation system only when the received service registration request is verified, indicating the correspondence between the SAN-ID and the verified service registration request. That is, by receiving the SAN-ID sent by the service operation system, it can be confirmed that the business orchestrator has verified the service registration request in this case.
  • Another embodiment of the present application also provides a flowchart of a data transmission method, which can be applied to, but not limited to, a third node on the network side, and the third node can be, but not limited to, a network controller on the network side in the implementation environment shown in Figure 2.
  • the data transmission method can include, but is not limited to, step S7000.
  • Step S7000 receiving a SAN-ID sent by a seventh node on the network side, and sending the SAN-ID to a first node on the network side, so that the first node generates a routing table according to the SAN-ID, wherein the SAN-ID is generated by the seventh node.
  • the SAN-ID can be sent to the SAN gateway, so that the SAN gateway generates a routing table according to the SAN-ID, so as to select a routing path for the terminal based on this routing table in subsequent steps.
  • step S7000 which includes but is not limited to steps S7100 to S7300 .
  • Step S7100 receiving the SAN-ID and the first communication strategy sent by the seventh node on the network side;
  • Step S7200 converting the first communication strategy into a second communication strategy adapted to the first node
  • Step S7300 Send the SAN-ID and the second communication policy to the first node, so that the first node generates a routing forwarding table according to the SAN-ID and the second communication policy.
  • the first communication strategy can be converted into a second communication strategy adapted to the SAN gateway, and then the SAN-ID and the second communication strategy are sent to the SAN gateway, so that the SAN gateway performs intelligent routing for the terminal according to the SAN-ID and the second communication strategy, so that the terminal can realize reliable forwarding of data packets carrying the SAN-ID.
  • the data sending method further includes but is not limited to step S8000.
  • Step S8000 Send the third communication strategy to the fourth node on the network side, so that the fourth node performs service health monitoring on the target traffic according to the third communication strategy, and the target traffic corresponds to the SAN-ID.
  • the third communication strategy is sent to the fourth node on the network side, so that the fourth node performs service health monitoring on the target traffic according to the third communication strategy, thereby realizing user-level granularity performance detection and call chain tracking based on SAN-ID, so as to enhance the refined diagnostic capability from the network side to the service side.
  • the type of the fourth node is not limited, for example, it can be but not limited to the implementation environment shown in FIG.
  • the computing network perception module on the network side; the third communication strategy can be set or generated according to the specific application scenario, and this embodiment does not limit it.
  • SAN-ID is a kind of SLA requirement that represents the cloud service side to the network side, and is also a distinguisher for users to access cloud service traffic.
  • the generation of SAN-ID is negotiated between the cloud service operator and the operator. This negotiation can be carried out in an offline out-of-band manner or can be completed automatically through interface docking.
  • the cloud service operator initiates a service registration request to the operator's business orchestration system through the service operation system. After a certain identity verification, the service operation system will pass the necessary commercial and technical parameters to the operator's business orchestration system.
  • the operator's business orchestrator responds to accept or reject the registration based on the network's own service level. Once the service registration is accepted, the business orchestrator will generate a SAN-ID based on it and associate it with the local traffic engineering measurement, and return the SAN-ID to the service operation system to complete the SAN-ID generation process.
  • the SAN-ID distribution process will be carried out on the network side and the cloud service side respectively.
  • the service orchestrator sends the generated SAN-ID and the associated traffic engineering policy to the network controller, which then sends it to the ingress PE and egress PE of the SAN gateway to generate the corresponding traffic control policy, and informs the computing network perception module to start monitoring the real-time health of the service.
  • the cloud service operation system After receiving the SAN-ID, the cloud service operation system will pass the relevant information to the user-side terminal and the service gateway.
  • the terminal When initiating traffic, the terminal will carry the SAN-ID according to the IPv6 extension header.
  • the traffic will perform intelligent routing based on service health and network quality according to the resolved SAN-ID, and at the service gateway, the service call chain will be tracked according to the SAN-ID.
  • SAN-ID there is no restriction on the encapsulation format of SAN-ID in the data message, and it can be multiple.
  • it can be used as the segment routing header (SRH) of SAN, or as the option of the destination option header DOH extension header of IPv6.
  • Figure 11 is a flow chart of a service awareness method provided by an embodiment of the present application, and the service awareness method can be but is not limited to being applied to the fourth node on the network side.
  • the service awareness method can include but is not limited to step S9000.
  • Step S9000 Send service health information to the first node on the network side, and send traffic real-time information to the second node on the service side, so that the network side and the service side perform two-way information exchange based on the service health information and traffic real-time information.
  • the network side and the service side perform two-way information exchange based on the service health information and the real-time traffic information, so as to facilitate the deployment of multiple resource pools for the same service through two-way information exchange. Further enhance the network service perception capability, strengthen the network feasibility, and be able to intelligently schedule user access service traffic based on network quality and service health, thereby improving the intelligence level of network services and helping to expand the application scenarios of network services.
  • the type of the second node is not limited, for example, it can be but not limited to a service monitoring system on the service side in the implementation environment shown in FIG. 2 .
  • the real-time traffic information includes at least one of the following:
  • service health information is obtained based on the following steps S10000 to S12000:
  • S10000 receiving service real-time indicator information and service historical indicator information sent by the second node, wherein the service historical indicator information is a historical benchmark value corresponding to the service real-time indicator information;
  • S11000 Modeling based on service real-time indicator information and service historical indicator information to generate a service scheduling model
  • this step by receiving the service real-time indicator information and the service historical indicator information, the current operating status and historical operating status of the user service can be clearly known.
  • modeling can be performed based on the service real-time indicator information and the service historical indicator information to generate a service scheduling model, that is, an associated service scheduling model is constructed through modeling to calculate the service health information through the service scheduling model. It can be determined that the obtained service health information is related to the service real-time indicator information and the service historical indicator information, and can better characterize the application status of the user service with high accuracy.
  • the service real-time indicator information includes at least one of the following:
  • the service real-time indicator information includes the average completion time of service requests and the average round-trip delay of the service
  • the difference between the average round-trip delay of the service and the average completion time of the service requests is related to the first transmission delay
  • the first transmission delay is dynamically adjusted as the service real-time indicator information is updated, wherein the first transmission delay is the transmission delay for sending service health information to the first node.
  • the service health information is specifically the service health index, which is the service health index that the computing network perception module notifies the network side after modeling:
  • the computing network perception module obtains the following two types of information from the service monitoring system based on the URL and authorization information provided during service registration: key real-time indicators of the service and historical benchmark values of key real-time indicators of the service.
  • the service monitoring indicators used in this embodiment are mainly service operation performance detection indicators.
  • Such real-time indicators are usually not available from the resource pool level.
  • the resource layer indicators such as CPU/memory utilization, etc.
  • they can better describe the specific operation status of the service and have more guiding significance at the scheduling level.
  • they include the following key service indicators: the proportion of slow service requests; the number of service errors; the average completion time of service requests; the average round-trip delay of the service, etc.
  • the core difference from related technologies is that this embodiment requires the cloud service operator to not only provide an entry for obtaining real-time indicators, but also provide the computing network perception module with the historical benchmark values of each core real-time indicator based on historical operating experience.
  • the value is above the benchmark value, it means that the current service status is deteriorating.
  • the network side needs to carry out intelligent scheduling of user traffic.
  • the computing network perception module models the service health based on the above real-time indicators and historical benchmark values, and calculates the health score value according to different scheduling models.
  • the health score is in the range of [0,100]. The higher the score, the better the actual operating status of the service and the higher the scheduling priority on the network side.
  • the processing logic of latency in this embodiment is also essentially different from that of related technologies.
  • the access latency requirement proposed during service registration is an end-to-end indicator, while the actual network transmission latency is determined by the difference between the average round-trip latency of the user and the average completion time of the user request, and is dynamically adjusted according to the update of real-time indicators. In other words, the network transmission latency will directly affect the results of intelligent routing on the network side.
  • the real-time traffic information is obtained based on the following steps:
  • real-time traffic information sent by the first node is received, wherein the real-time traffic information is sent by the first node according to the received service-aware network identifier, and the real-time traffic information corresponds to the SAN-ID.
  • the computing network perception module is connected to the network controller through the management plane, and establishes a dynamic control plane protocol with the SAN gateway through the distributed control plane. Based on this dual connection, the computing network perception module can obtain the actual forwarding path and network quality of user traffic in the network in real time with SAN-ID as the granularity, and expose it to the service monitoring system with a controlled access API under the premise of ensuring the real-time and security of the information, so as to make up for the monitoring blind spots of the service monitoring system on the network side, and has important value in performance fault diagnosis from the service side to the network side.
  • it is usually recommended to obtain relevant information by simply connecting to the management plane, and the real-time and security of the information cannot be guaranteed.
  • Figure 13 is a flow chart of a service awareness method provided by another embodiment of the present application, and the service awareness method can be but is not limited to being applied to a second node on the network side.
  • the service awareness method can include but is not limited to step S13000.
  • Step S13000 Receive real-time traffic information sent by the fourth node on the network side, so that the network side and the service side perform two-way information exchange based on service health information and real-time traffic information; wherein the service health information is sent by the fourth node to the first node on the network side.
  • this step by receiving the real-time traffic information sent by the fourth node on the network side, it is possible to conduct two-way information exchange with the network side based on the pre-acquired service health information and real-time traffic information, so as to facilitate the deployment of multiple resource pools for the same service through two-way information exchange. Further improve the network service perception capability, enhance the network feasibility, and be able to intelligently schedule user access service traffic based on network quality and service health, thereby improving the intelligence level of network services and helping to expand the application scenarios of network services.
  • the service perception method further includes but is not limited to step S14000.
  • Step S14000 sending the service real-time indicator information and the service historical indicator information to the fourth node, so that the fourth node performs modeling according to the service real-time indicator information and the service historical indicator information, generates a service scheduling model, and obtains service health information through calculation of the service scheduling model;
  • the service historical indicator information is the historical benchmark value corresponding to the service real-time indicator information.
  • the computing network perception module can clearly know the current and historical operation status of the user service.
  • modeling can be carried out based on the service real-time indicator information and the service historical indicator information to generate a service scheduling model, that is, to build an associated service scheduling model through modeling.
  • the service health information can be calculated through the service scheduling model. It can be determined that the obtained service health information is related to the service real-time indicator information and the service historical indicator information, which can better characterize the application status of user services with high accuracy.
  • step S13000 which includes but is not limited to steps S13100 to S13200 .
  • Step S13100 receiving a first data message carrying a SAN-ID sent by a fifth node on the service side;
  • Step S13200 When an abnormality is detected in the first data message, receive real-time traffic information sent by a fourth node on the network side.
  • the first data packet by receiving the first data packet carrying the SAN-ID sent by the service gateway, the first data packet can be detected. If it is detected that the first data packet is abnormal, it means that the first data packet needs to be scheduled and adjusted. Therefore, by receiving the real-time traffic information sent by the fourth node on the network side, the service call chain is tracked and analyzed according to the real-time traffic information, so as to realize performance fault diagnosis from the service side to the network side.
  • the service perception method further includes but is not limited to steps S15000 to S16000.
  • Step S15000 receiving service call analysis information sent by the fifth node, where the service call analysis information is obtained by the fifth node performing service call chain tracking and analysis on the first data message;
  • Step S16000 monitor and analyze the first data packet according to the service call analysis information and the real-time traffic information to obtain a monitoring and analysis result for the first data packet.
  • the first data packet is monitored and analyzed according to the service call analysis information and the real-time traffic information, and the monitoring and analysis result of the first data packet is obtained, so that it can be determined whether there is a problem with the first data packet based on the monitoring and analysis result, so as to adjust and modify the first data packet when it is determined that there is a problem with the first data packet.
  • Figure 16 is a flow chart of a service awareness method provided by an embodiment of the present application, and the service awareness method can be but is not limited to being applied to a third node on the network side.
  • the service awareness method can include but is not limited to step S17000.
  • Step S17000 Receive service health information sent by the fourth node on the network side, so that the network side and the service side perform two-way information exchange based on the service health information and real-time traffic information; wherein the real-time traffic information is sent from the fourth node to the second node on the service side.
  • this step by receiving the service health information sent by the fourth node on the network side, it is possible to perform two-way information exchange with the service side based on the service health information and the pre-acquired real-time traffic information, so as to realize the scenario of multiple resource pools for the same service through two-way information exchange, further improve the network service perception capability, enhance the network feasibility, and be able to perform intelligent scheduling of user access service traffic according to network quality and service health, thereby improving the intelligent level of network services. It is conducive to expanding the application scenarios of network services.
  • the service perception method further includes but is not limited to step S18000.
  • Step S18000 When a control plane protocol is established with the fourth node through a distributed control plane, and the fourth node is connected to the third node on the network side through a management plane, real-time traffic information is sent to the fourth node according to the received service-aware network identifier, wherein the real-time traffic information corresponds to the SAN-ID.
  • the computing network perception module is connected to the network controller through the management plane, and establishes a dynamic control plane protocol with the SAN gateway through the distributed control plane. Based on this dual connection, the computing network perception module can obtain the actual forwarding path and network quality of user traffic in the network in real time with SAN-ID as the granularity, and expose it to the service monitoring system with a controlled access API under the premise of ensuring the real-time and security of the information, so as to make up for the monitoring blind spots of the service monitoring system on the network side, and has important value in performance fault diagnosis from the service side to the network side.
  • it is usually recommended to obtain relevant information by simply connecting to the management plane, and the real-time and security of the information cannot be guaranteed.
  • the service perception method further includes but is not limited to steps S19000 to S20000.
  • Step S19000 receiving a first data message carrying a SAN-ID sent by a terminal
  • Step S20000 Send the first data message to the fifth node on the service side, so that the fifth node performs service call chain tracking and analysis on the first data message to obtain service call analysis information.
  • the first data message can be sent to the service gateway, so that the service gateway performs service call chain tracking and analysis on the first data message to obtain service call analysis information, ensuring that the service gateway can provide service call analysis information to the service monitoring system.
  • the acquisition of real-time health indicator information of services is completed by the computing network perception module calling the API of the service monitoring system.
  • the API and entry and corresponding authorization are completed when the service is registered.
  • the computing network perception module is directly controlled by the network controller or business orchestrator, and can be deployed on the cloud infrastructure (including but not limited to containers, virtual machines, physical machines or gateway devices, etc.), or it can be deployed independently in the network resource pool.
  • This component implements two core functions:
  • the egress gateway receives the service IP and the service health index after aggregation modeling sent by the computing network perception module through the control plane protocol, and then transmits it to the ingress gateway on the network side (i.e., the Ingress PE shown in Figure 17) through the control plane protocol.
  • the ingress gateway on the network side uses the local intelligence to calculate the service health index based on the route reachability and service health index.
  • a traffic forwarding table or a routing forwarding table for a specific SAN-ID can be generated by using a routing algorithm or by utilizing the centralized routing calculation capability of a network controller.
  • the service access traffic sent from the user side carries the SAN-ID in the data message through the IPv6 extension header.
  • the forwarding plane will resolve the SAN-ID and perform corresponding message forwarding based on the SAN-ID.
  • the plug-in supports the resolution of the SAN-ID and uses the SAN-ID as a parameter for access logs and service call chain information, providing the service monitoring system with SAN-ID granular performance monitoring capabilities.
  • FIG. 18 shows an overall execution flow chart of a service perception method, a data generation method, and a data sending method according to an embodiment of the present application.
  • the overall process may be performed, but is not limited to, according to the following steps:
  • Step 1 The service operator initiates service registration with the operator based on the need to optimize user access.
  • the registration process can be completed through offline negotiation or automatically by the cloud service operation system and the operator's business orchestrator through the service registration template and protocol defined by the operator.
  • the specific protocol design details can be relatively flexible.
  • Step 2 The operator's business orchestration verifies the service registration request initiated by the service operator in terms of business and technology. If the verification passes, it generates a SAN-ID according to its own preset rules and maps and associates the service's SLA requirements with network capabilities.
  • Step 3 The operator chooses to accept or reject the service registration based on the internal decision logic. If the service registration is accepted, the operator returns the SAN-ID and the authorization and URL for obtaining the traffic path monitoring information to the service operation system;
  • Step 4 The operator's service orchestrator maps the SAN-ID to an existing or newly added network policy model according to the service registration requirements, and sends the generated policy to the network controller;
  • Step 5 The operator's network controller converts the policy into a model based on the location information of the service registration, and sends it to the specific SAN gateway and computing network perception module to control the network forwarding and service perception behavior of the specific SAN-ID traffic;
  • Step 6 The service operation system sends the SAN-ID to the terminal side (through software upgrade or dynamic sending) and the service gateway.
  • the terminal carries the SAN-ID in the service access message.
  • the service gateway has the ability to identify the specific SAN-ID. This step can be performed synchronously after the registration is successful.
  • Step 7 The computing network perception module monitors the entry and authorization information of the real-time indicators obtained during the registration process, and periodically polls the service monitoring system for health indicators according to the predefined strategy.
  • the computing network perception module can also subscribe to specific service monitoring events based on its own evaluation model of service health.
  • Specific real-time indicators include the following two types of information: key real-time indicators of services, historical benchmark values of key service indicators;
  • Step 8 Based on a full understanding of the service scheduling requirements, the computing network perception module performs a certain convergence modeling on the original service monitoring indicators to form a small number of comprehensive indicators that can stably reflect the service quality level.
  • the health score is used.
  • the specific modeling method is as follows:
  • Health score f(percentage of slow service requests; number of service errors; average service request completion time; average service round-trip delay);
  • the health score is in the range of [0,100]. The larger the value, the better the service operation status and the higher the service scheduling priority.
  • the computing network perception module has the ability to update and upgrade the model online through the controller, and this embodiment is also applicable to such a scenario;
  • Step 9 The computing network perception module notifies the modeled service health indicators, IP addresses and other information to the resource pool outlet. PE, and update according to the established policy.
  • the update notification is carried out through the control plane protocol between the computing network perception module and the gateway.
  • the control plane protocol can be an extension of an existing protocol (such as BGP) or a new control protocol defined for SAN in other ways. There is no specific restriction here.
  • Step 10 After receiving the information notification/update from the computing network perception module, the egress PE further notifies the ingress PE of information such as IP routing and service health through the control plane protocol between gateways.
  • the control plane protocol here is not specifically limited.
  • Step 11 After receiving the information routing and service status update, the ingress PE can carry out joint intelligent routing based on the network demand and service health. The impact of the network status and service status on the routing result is determined by the specific intelligent routing algorithm. If the intelligent routing strategy is too complicated, a request for centralized routing can be sent to the network controller. The network controller has global information, supports complex path calculation processes, and can return the routing results to the ingress PE. Of course, if the network device can perform intelligent routing by itself, it does not need to rely on the capabilities of the network controller.
  • Step 12 Based on the network policy issued for the SAN-ID in the early stage and the path recalculation result after the service status is updated, a traffic forwarding table is finally generated and sent to the forwarding plane;
  • Step 13 The terminal user initiates a service access request, carries the SAN-ID field in the IPv6 message, and the data packet is forwarded to the ingress PE through the network;
  • Step 14 After receiving the user traffic, the ingress PE parses the packet header to obtain the SAN-ID, queries the forwarding table based on the SAN-ID, and performs traffic forwarding.
  • Step 15 User traffic is finally forwarded to the service gateway through normal routing
  • Step 16 The service gateway parses the user traffic to obtain the SAN-ID, performs business log and call chain analysis on the user traffic carrying the SAN-ID, and then the service monitoring system can achieve performance analysis results at the SAN-ID granularity.
  • Step 17 When an abnormal event occurs in a specific SAN-ID traffic, the service monitoring system can call the API interface provided by the computing network perception module to obtain the forwarding path and quality indicators of the traffic on the network side, thereby providing a more complete performance diagnosis view.
  • this embodiment can not only respect the technical and management boundaries, but also, under the premise of inheriting the existing network, cloud service management, operation and maintenance, and operation mode, it can greatly improve the network's service perception capabilities and cloud service monitoring and diagnosis levels through local function upgrades and system docking, avoiding fierce management and disruptive innovation at the technical level, and has strong feasibility, adaptability to different scenarios, and scalability. Utilizing the technical solution of this embodiment, the rapid implementation of the service-aware network in the existing network environment can be accelerated.
  • an embodiment of the present application also discloses an electronic device 300, including: at least one processor 310; at least one memory 320, for storing at least one program; when the at least one program is executed by at least one processor 310, it implements the service perception method as in any of the previous embodiments, or implements the signal data generation method as in any of the previous embodiments, or implements the signal data sending method as in any of the previous embodiments.
  • an embodiment of the present application also discloses a computer-readable storage medium, which stores computer-executable instructions, and the computer-executable instructions are used to execute a service perception method such as any of the previous embodiments, or to execute a signal data generation method such as any of the previous embodiments, or to execute a signal data sending method such as any of the previous embodiments.
  • one embodiment of the present application also discloses a computer program product, including a computer program or a computer instruction.
  • the computer program or computer instructions are stored in a computer-readable storage medium
  • the processor of the computer device reads the computer program or computer instructions from the computer-readable storage medium
  • the processor executes the computer program or computer instructions, so that the computer device executes the service perception method as in any of the previous embodiments, or executes the signal data generation method as in any of the previous embodiments, or executes the signal data sending method as in any of the previous embodiments.
  • the division between the functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed by several physical components in cooperation.
  • Some physical components or all physical components may be implemented as software executed by a processor, such as a central processing unit, a digital signal processor or a microprocessor, or implemented as hardware, or implemented as an integrated circuit, such as an application-specific integrated circuit.
  • a processor such as a central processing unit, a digital signal processor or a microprocessor
  • Such software may be distributed on a computer-readable medium, which may include a computer storage medium (or non-transitory medium) and a communication medium (or temporary medium).
  • computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules or other data).
  • Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer.
  • communication media typically embodies computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and may include any information delivery media.
  • a component can be, but is not limited to, a process running on a processor, a processor, an object, an executable file, an execution thread, a program, or a computer.
  • applications running on a computing device and a computing device can be components.
  • One or more components may reside in a process or an execution thread, and a component may be located on a computer or distributed between two or more computers.
  • these components may be executed from various computer-readable media having various data structures stored thereon.
  • Components may communicate, for example, through local or remote processes based on signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, or a network, such as the Internet interacting with other systems through signals).
  • signals having one or more data packets (e.g., data from two components interacting with another component between a local system, a distributed system, or a network, such as the Internet interacting with other systems through signals).

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

La présente demande concerne un procédé de détection de service, un procédé de génération de données, un procédé d'envoi de données, un dispositif électronique et un support de stockage. Le procédé de détection de service consiste à : envoyer des informations de santé de service à un premier nœud côté réseau, et envoyer des informations de trafic en temps réel à un second nœud d'un côté service, de telle sorte que le côté réseau effectue un échange d'informations bidirectionnel avec le côté service selon les informations de santé de service et les informations de trafic en temps réel.
PCT/CN2023/113789 2022-12-08 2023-08-18 Procédé de détection de service, procédé de génération de données, procédé d'envoi de données, dispositif électronique et support de stockage WO2024119884A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202211573575.3A CN118175576A (zh) 2022-12-08 2022-12-08 服务感知方法、数据生成方法及发送方法、电子设备、存储介质
CN202211573575.3 2022-12-08

Publications (1)

Publication Number Publication Date
WO2024119884A1 true WO2024119884A1 (fr) 2024-06-13

Family

ID=91357263

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2023/113789 WO2024119884A1 (fr) 2022-12-08 2023-08-18 Procédé de détection de service, procédé de génération de données, procédé d'envoi de données, dispositif électronique et support de stockage

Country Status (2)

Country Link
CN (1) CN118175576A (fr)
WO (1) WO2024119884A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108259367A (zh) * 2018-01-11 2018-07-06 重庆邮电大学 一种基于软件定义网络的服务感知的流策略定制方法
US20200153740A1 (en) * 2012-06-06 2020-05-14 The Trustees Of Columbia University In The City Of New York Unified networking system and device for heterogeneous mobile environments

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20200153740A1 (en) * 2012-06-06 2020-05-14 The Trustees Of Columbia University In The City Of New York Unified networking system and device for heterogeneous mobile environments
CN108259367A (zh) * 2018-01-11 2018-07-06 重庆邮电大学 一种基于软件定义网络的服务感知的流策略定制方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
F. ZHOU D. YUAN ZTE CORPORATION D. YANG BEIJING JIAOTONG UNIVERSITY: "Computing Segment for Service Routing in SAN draft-zhou-intarea-computing-segment-san-01; draft-zhou-intarea-computing-segment-san-01.txt", COMPUTING SEGMENT FOR SERVICE ROUTING IN SAN DRAFT-ZHOU-INTAREA-COMPUTING-SEGMENT-SAN-01; DRAFT-ZHOU-INTAREA-COMPUTING-SEGMENT-SAN-01.TXT; INTERNET-DRAFT: INTAREA, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, no. 01, 24 October 2022 (2022-10-24), Internet Society (ISOC) 4, rue des Falaises CH- 1205 Geneva, Switzerland, pages 1 - 11, XP015156379 *

Also Published As

Publication number Publication date
CN118175576A (zh) 2024-06-11

Similar Documents

Publication Publication Date Title
US20200221347A1 (en) Method and system for managing utilization of slices in a virtual network function environment
US11864019B2 (en) Time-sensitive networking communication method and apparatus
CN105765921B (zh) 用于利用软件定义网络功能进行diameter路由的方法、系统和设备
KR101868070B1 (ko) 서비스 계층 사우스바운드 인터페이스 및 서비스 품질
CN110035401B (zh) 一种默认服务质量QoS控制方法及设备
CN109792621A (zh) 用于评估聚合的连接的网络性能的方法和系统
WO2019214810A1 (fr) Intégration transparente aidée par gestion et orchestration de réseau 3gpp en réseau industriel basé sur un tsn
WO2022184094A1 (fr) Système de réseau pour traiter une puissance de hachage, ainsi que procédé de traitement de service et nœud d'élément de réseau de puissance de hachage
WO2018057192A1 (fr) Techniques d'utilisation d'un en-tête de service de réseau afin de surveiller la qualité de service
US11165672B2 (en) Application performance management integration with network assurance
EP3099011B1 (fr) Entité de service de gestion d'interfaces, entité fonctionnelle de services et procédé de gestion d'éléments de réseau
US20190182104A1 (en) Method and device for processing communication path
WO2021139696A1 (fr) Procédé, appareil, et système d'envoi d'informations de rapport
CN104348743A (zh) 一种全网均衡负载的方法及装置
WO2015149491A1 (fr) Dispositif, procédé et système de traitement de ressource de réseau
JP2016511451A (ja) ネットワーク機能を開くためのシステムおよび方法、ならびに関連するネットワーク要素
WO2020135429A1 (fr) Procédé et appareil d'analyse de trafic, procédé et appareil de détection du trafic
WO2016109970A1 (fr) Entité de réseau et procédé de gestion de politique de service
CN109787799B (zh) 一种服务质量QoS控制方法及设备
US10511494B2 (en) Network control method and apparatus
WO2024119884A1 (fr) Procédé de détection de service, procédé de génération de données, procédé d'envoi de données, dispositif électronique et support de stockage
CN115941678A (zh) 云边缘协同服务链部署方法及装置
CN115474079A (zh) 媒体流迁移方法、装置、电子设备及存储介质
WO2023057794A1 (fr) Procédé d'alignement de qualité de service dans un réseau mobile et nuage périphérique
AU2020379793C1 (en) Communication method, apparatus and system