Communication method, communication system and communication device

Abstract

The invention provides a communication method, a communication system and communication equipment. The communication method comprises the following steps: in response to a cross-domain service request from a user interaction entrance, checking intra-domain resources according to the cross-domain service request; when the intra-domain resources meet the cross-domain service request, a socket connection request is initiated to a second service core network corresponding to the called terminal, and the socket connection request carries self-defined service parameters; a service acceptance message returned by the second service core network through the socket connection is responded, a service acceptance notification is sent to the user interaction entrance, and the service acceptance message indicates that after the second service core network checks intra-domain resources of the second service core network according to the cross-domain service request, the intra-domain resources of the second service core network are sent to the user interaction entrance; determining that intra-domain resources of the second service core network meet the cross-domain service request; and configuring the first user access equipment and the first service gateway according to the custom service parameters. According to the embodiment of the invention, the resource negotiation efficiency of the cross-domain service can be improved.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of communication, and in particular, to a communication method, a communication system and a communication device. BACKGROUND

[0002] In the scenario of fixed network cross-domain transmission, resource coordination and reservation between multiple domains often need to use HTTP protocol (based on request-response mode) for one-way communication from sub-controllers in different domains to a global controller, in order to realize the provision and acquisition of resource information in each domain.

[0003] Under this mode, each sub-controller needs to expose the resource information in the domain to the global controller, and periodically poll the global controller to obtain the resource information of other domains, in order to determine whether the resources of other domains can support inter-domain communication of a certain period and a certain service, or negotiate whether other domains can reserve resources for a certain service in the future. This not only may lead to privacy information leakage, but also has the following problems: if the polling time interval is small, a large number of invalid polling will be generated, causing resource waste; if the polling time interval is large, the real-time performance of inter-domain resource coordination will be poor, and the resource information between two domains cannot be synchronized in time, causing communication failure.

[0004] In addition, in the complex scenario of a surge in cross-domain traffic demand and a complete inter-domain negotiation process that may involve multiple interactions, the frequent HTTP requests sent by each sub-controller to the global controller will cause significant performance problems. A large number of HTTP connection establishment, request / response processing and possible TLS handshake will cause a significant increase in server overhead, performance bottlenecks and increased end-to-end delay. This performance degradation directly affects the reliability of the negotiation process, and thus threatens the stable operation of the service and the guarantee of SLA (Service Level Agreement).

[0005] Finally, the existing inter-domain negotiation can only provide service-level guarantee, i.e., resource negotiation based on a certain service, which cannot adapt to different needs of each user.

[0006] It should be noted that the information disclosed in the above background section is only used to strengthen the understanding of the background of the present disclosure, and therefore can include information that does not constitute prior art known to those of ordinary skill in the art. SUMMARY

[0007] The purpose of the present disclosure is to provide a communication method, a communication system and a communication device, which can solve the problems of low efficiency, large resource overhead, high risk of privacy information leakage and the like in inter-domain negotiation.

[0008] According to a first aspect of the embodiments of the present disclosure, a communication method is provided, which is executed by a first service core network connected with a user interaction portal, a first user access device and a first service gateway, and includes the following steps. In response to a cross-domain service request from the user interaction portal, domain-in resource is checked according to the cross-domain service request. The cross-domain service request includes self-defined service parameters, and the self-defined service parameters include user information of a calling terminal, user information of a called terminal, connection bandwidth, service start time and connection duration. When the domain-in resource meets the cross-domain service request, a socket connection request is initiated to a second service core network corresponding to the called terminal. The socket connection request carries the self-defined service parameters. In response to a service acceptance message returned by the second service core network through the socket connection, a service acceptance notification is sent to the user interaction portal. The service acceptance notification includes a session identifier of a session corresponding to the cross-domain service request. The service acceptance message indicates that the second service core network determines that the domain-in resource of the second service core network meets the cross-domain service request and the calling terminal is a legal user after checking the domain-in resource of the second service core network according to the cross-domain service request. The first user access device and the first service gateway are configured according to the self-defined service parameters to support the session corresponding to the cross-domain service request between the service start time and a service end time. The service end time is determined according to the service start time and the connection duration, or is determined according to a session end instruction from the user interaction portal.

[0009] According to a second aspect of the embodiments of the present disclosure, a communication method is provided, which is executed by a second service core network connected with a second user access device and a second service gateway. The method includes the following steps. In response to a socket connection request from a first service core network, a socket connection between the first service core network and the second service core network is established. Self-defined service parameters carried by the socket connection request are acquired. The self-defined service parameters include user information of a calling terminal, user information of a called terminal, connection bandwidth, service start time and connection duration. After determining that the user of the calling terminal is a legal user, domain-in resource is checked according to the self-defined service parameters. When the domain-in resource meets the cross-domain service request, a service acceptance message is sent to the first service core network through the socket connection. The first user access device and the second service gateway are configured according to the self-defined service parameters to support the session corresponding to the cross-domain service request between the service start time and a service end time. The service end time is determined according to the service start time and the connection duration, or is determined according to a session end instruction from the first service core network.

[0010] According to a third aspect of the present disclosure, a communication system is provided, comprising a first service core network, a first user interaction portal, a first user access device, a first service gateway, and a second service core network, a second user interaction portal, a second user access device, a second service gateway, wherein the first service core network is connected with the first user interaction portal, the first user access device, and the first service gateway, the second service core network is connected with the second user interaction portal, the second user access device, and the second service gateway, the first service core network and the second service core network are in bidirectional communication through socket connection, the first service core network is configured to perform the communication method according to any one of the preceding method embodiments, and the second service core network is configured to perform the communication method according to any one of the preceding method embodiments.

[0011] According to a fourth aspect of the present disclosure, a communication device is provided, comprising a memory and a processor coupled to the memory, wherein the processor is configured to perform the communication method according to any one of the preceding method embodiments based on instructions stored in the memory.

[0012] According to a fifth aspect of the present disclosure, a computer readable storage medium is provided, which stores a program, and the program is executed by a processor to implement the communication method according to any one of the preceding method embodiments.

[0013] According to a sixth aspect of the present disclosure, a computer program product is provided, comprising a computer program, wherein the computer program is executed by a processor to implement the steps of the method according to any one of the preceding method embodiments.

[0014] The embodiments of the present disclosure can make the service core network and the user interaction interface in bidirectional communication, and the service core network can perform in-domain resource checking based on the cross-domain service request provided by the user interaction interface, and directly implement socket communication with the second service core network corresponding to the cross-domain service request, so that the second service core network performs in-domain resource checking based on the cross-domain service request, which can make the service core networks of each domain efficiently and privately implement inter-domain resource negotiation without exposing resource information to the outside, and can provide fine-grained user-level service guarantee for users, thereby optimizing user experience. In addition, since the service core networks use socket connection for bidirectional communication, a large number of polling is not required, which can greatly save communication resource consumption and improve the real-time performance of information transmission.

[0015] It should be understood that the foregoing general description and the following detailed description are only exemplary and explanatory, and cannot limit the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0016] The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, further serve to explain the principles of the present disclosure. It is apparent that the drawing in the following description merely show some of the embodiments of the present disclosure and, to one of ordinary skill in the art, other drawings can be obtained from these drawings without any creative work.

[0017] Figure 1 is a schematic diagram of a communication system in an exemplary embodiment of the present disclosure.

[0018] Figure 2 is a flowchart of a communication method in an exemplary embodiment of the present disclosure.

[0019] Figure 3 is an interaction schematic diagram of a communication method in an exemplary embodiment of the present disclosure.

[0020] Figure 4 is a sub-flowchart of step S4 in an exemplary embodiment of the present disclosure.

[0021] Figure 5 is an interaction schematic diagram of intra-domain configuration in step S4 in an exemplary embodiment of the present disclosure.

[0022] Figure 6 is a sub-flowchart of step S4 in an exemplary embodiment of the present disclosure.

[0023] Figure 7 is a sub-flowchart of step S4 in an exemplary embodiment of the present disclosure.

[0024] Figure 8 is an interaction schematic diagram corresponding to the service end time in an exemplary embodiment of the present disclosure.

[0025] Figure 9 is a flowchart of a communication method executed by a second service core network in an exemplary embodiment of the present disclosure.

[0026] Figure 10 is a sub-flowchart of step S95 in an exemplary embodiment of the present disclosure.

[0027] Figure 11 is a block diagram of a communication device in an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION

[0028] Example implementations will now be described more fully with reference to the accompanying drawings. Example implementations can be implemented in any

[0029] In addition, the accompanying drawings which are included to provide a further understanding of the disclosure and are incorporated in and constitute a part of this application illustrate embodiments of the present disclosure and together with the description serve to explain the principles of the present disclosure. In the drawings:

[0030] Reference will now be made in detail to the example implementations, which are illustrated in the accompanying drawings.

[0031] Figure 1 is a schematic diagram of a communication system in an example embodiment of the present disclosure.

[0032] Referring to Figure 1 , the communication system 100 can include a first service core network 11, a first user interaction portal 12, a first user access device 13, a first service gateway 14, and a second service core network 21, a second user interaction portal 22, a second user access device 23, a second service gateway 24.

[0033] The first service core network 11 is connected with the first user interaction portal 12, the first user access device 13, and the first service gateway 14, and the second service core network 21 is connected with the second user interaction portal 22, the second user access device 23, and the second service gateway 24. The first service core network 11 and the second service core network 21 are connected through a Web socket for bidirectional communication.

[0034] The first service core network 11, the first user interaction portal 12, the first user access device 13, and the first service gateway 14 are located in the first domain 1, and the second service core network 21, the second user interaction portal 22, the second user access device 23, and the second service gateway 24 are located in the second domain 2. The first domain 1 and the second domain 2 are different domains.

[0035] That is, the first service core network 11, the first user interaction portal 12, the first user access device 13, and the first service gateway 14 are the service core network, the user interaction portal, the user access device, and the service gateway of the first domain 1, and the second service core network 21, the second user interaction portal 22, the second user access device 23, and the second service gateway 24 are the service core network, the user interaction portal, the user access device, and the service gateway of the second domain 2.

[0036] The first service gateway 14 and the second service gateway 24 are connected through an IP network.

[0037] Figure 1 For the convenience of explaining the principle, only two domains are shown, and in actual application, multiple domains exist, and each domain has a corresponding service core network, user interaction portal, user access device, and service gateway.

[0038] In the embodiment of the present disclosure, the service core network and the user interaction portal in the same domain, for example, the first service core network 11 and the first user interaction portal 12, and the second service core network 21 and the second user interaction portal 22, are connected through a socket to realize bidirectional communication.

[0039] The service core networks in different domains, for example, the first service core network 11 and the second service core network 21, are connected through a socket (Web socket) to realize bidirectional communication.

[0040] The socket (Web socket) connection is a network protocol that realizes full-duplex communication on a single TCP connection, which allows real-time bidirectional data transmission between a client and a server without establishing a connection through a frequent request-response mode like the HTTP protocol. This connection mode reduces the overhead of frequently establishing a connection and can continuously transmit data in one connection, providing reliable underlying support for real-time collaboration of cross-domain services.

[0041] In the embodiment of the present disclosure, the socket connection related functions are implanted in the user interaction portal and the service core network, thereby realizing bidirectional communication between the service core networks and between the service core network and the user interaction portal. Since the socket is used to realize bidirectional communication between the service core networks and between the service core network and the user interaction portal, the efficiency of cross-domain service negotiation and execution can be significantly improved.

[0042] Next, each part of the communication system 100 is described in detail.

[0043] The user interaction portal is an interface or platform for information exchange between the user and the service core network in the communication system, and is a direct operation portal for the user to initiate a cross-domain service request, configure service parameters, and obtain service status feedback. As a logical function, the user interaction portal can be set on the user equipment (UE) in the form of program code.

[0044] In Figure 1 In order to facilitate the explanation of the principle, only two user interaction portals are shown in the actual application, a service core network can connect multiple user interaction portals, and user interaction portals in different domains only communicate with the service core network in the domain.

[0045] The service core network (SCN) is a core node responsible for service logic processing, resource scheduling, cross-domain collaboration, and service lifecycle management. Each domain corresponds to an independent service core network, that is, all user access devices, service gateways, user interaction portals, and other resources and service operations within a domain are uniformly managed and controlled by the domain-specific service core network (SCN). For example, the first domain 1 is responsible for the first service core network 11, and the second domain 2 is responsible for the second service core network 21. The domain and the service core network form a one-to-one correspondence relationship.

[0046] The user access device (UAD) is a bridge for user equipment (such as computers, mobile phones, and other terminals) to access the network in the domain, and is mainly used to realize the physical or logical connection between the user terminal (UE) and the network in the domain, and to undertake basic network access control, data forwarding, and other functions. It is the first network node of the user data entering the transmission path in the domain, and the implementation forms include but are not limited to routers, switches, wireless access points (APs), etc. A domain usually contains multiple user access devices to meet the access needs of different users or different areas in the domain (for example, different areas in the same domain may deploy independent user access devices).

[0047] The service gateway (SG) is a key device responsible for service policy execution and traffic control in the domain, and is mainly used to dynamically adjust the bandwidth resources of user services (through remote user dial-up authentication system authorization to change policies, etc.), implement security access control, forward and adapt cross-domain service traffic, etc. It is a core node for guaranteeing the quality of service (QoS). The number of service gateways in a domain is determined according to the size of the domain, and one or more (when multiple, a redundant or load balancing architecture is usually formed to ensure service continuity) can be deployed.

[0048] The user access device (UAD) in the same domain establishes a data transmission connection with one or more service gateways (SG) according to the service partition, load balancing strategy or redundancy design. The user service data received by the user access device is forwarded to the corresponding service gateway through the data transmission connection, and is further processed by the service gateway before being transmitted to the cross-domain link or other nodes in the domain.

[0049] In the communication system 100, each user access device is connected to at least one user equipment (UE), at least one service gateway and the service core network (SCN) in the domain.

[0050] Through the connection with the service core network, the user access device receives the interface configuration (such as enabling / disabling the wide area network interface) and routing instructions issued by the SCN, and feeds back the configuration execution result to the SCN.

[0051] Through the connection with the user terminal, the user access device provides a network access port for the user terminal, and when the user terminal generates service data, it guides these data into the transmission channel (such as the wide area network interface set by the SCN) pre-configured in the domain. In this process, the user access device ensures that the path and interface state of data transmission meet the service requirements according to the instructions issued by the SCN.

[0052] In the embodiments of the present disclosure, the user interaction portal provided on the user equipment (UE) enables the user to understand the service state through the bidirectional communication with the service core network, and obtains the network state information through the user access device.

[0053] Next, the communication method executed by the service core network (first service core network 11, second service core network 12) in the communication system 100 is introduced, and the operation of the communication system 100 is further explained.

[0054] For the convenience of explanation, in the following, the communication network element / device of the calling end (communication initiating end, also called A end) is referred to as the first, such as the first user terminal, the first user interaction portal, the first user access device, the first service core network, the first service gateway, the first domain; the communication network element / device of the called end (communication receiving end, also called Z end) is referred to as the second, such as the second user terminal, the second user interaction portal, the second user access device, the second service core network, the second service gateway, the second domain.

[0055] It can be understood that since the roles of the calling terminal and the called terminal are only temporary roles, any user terminal or user interactive portal can become the calling terminal or the called terminal. Therefore, in the embodiments of the present disclosure, the labels of "first" and "second" are only temporary, and any device, such as a service core network, can act as a first service core network at one time and as a second service core network at another time. Even when a service core network simultaneously assumes the roles of calling and called of different user interactive portals connected thereto, the service core network can be a first service core network or a second service core network at different times, depending on whether it executes the communication method performed by the first service core network (calling terminal) or the communication method performed by the second service core network (called terminal).

[0056] Figure 2 is a flowchart of a communication method in the exemplary embodiments of the present disclosure.

[0057] Reference Figure 2 The communication method 200 can include:

[0058] Step S1, in response to a cross-domain service request from the user interactive portal, verifying in-domain resources according to the cross-domain service request, the cross-domain service request including custom service parameters, the custom service parameters including user information of a calling terminal, user information of a called terminal, a connection bandwidth, a service start time, and a connection duration;

[0059] Step S2, when the in-domain resources meet the cross-domain service request, initiating a socket connection request to a second service core network corresponding to the called terminal, the socket connection request carrying the custom service parameters;

[0060] Step S3, in response to a service acceptance message returned by the second service core network through socket connection, sending a service acceptance notification to the user interactive portal, the service acceptance notification including a session identifier of a session corresponding to the cross-domain service request, the service acceptance message indicating that the second service core network determines that in-domain resources of the second service core network meet the cross-domain service request and the calling terminal is a legal user after verifying the in-domain resources of the second service core network according to the cross-domain service request;

[0061] Step S4, configuring the first user access device and the first service gateway according to the custom service parameters to support a session corresponding to the cross-domain service request between the service start time and a service end time, the service end time being determined according to the service start time and the connection duration, or being determined according to a session end instruction from the user interactive portal.

[0062] This embodiment of the disclosure establishes bidirectional communication between the service core network and the user interaction interface. The service core network can perform intra-domain resource verification based on cross-domain service requests provided by the user interaction interface, and directly establish socket communication with the second service core network corresponding to the cross-domain service request. This allows the second service core network to perform intra-domain resource verification based on the cross-domain service request, enabling efficient and private inter-domain resource negotiation without exposing resource information. It also provides users with fine-grained, user-level service guarantees, thereby optimizing the user experience. Furthermore, since bidirectional communication between service core networks uses socket connections, extensive polling is unnecessary, significantly saving communication resources and improving the real-time performance of information transmission.

[0063] The steps of the communication method 100 will now be described in detail.

[0064] In step S1, in response to the cross-domain service request from the user interaction entry, the resources within the domain are checked according to the cross-domain service request. The cross-domain service request includes custom service parameters, which include the user information of the calling party, the user information of the called party, the connection bandwidth, the service start time, and the connection duration.

[0065] In this embodiment of the disclosure, the calling user can access the user interaction interface (such as...) on the user terminal. Figure 1 The first user interaction entry 12) allows users to input specific business requirements, flexibly select custom business parameters, specify the called party, the service time (start time + service duration) for cross-domain communication, bandwidth size, and service type (such as high-definition video transmission, real-time data interaction, etc.), and then forward the cross-domain service request carrying these parameters to the corresponding first business core network 11. Furthermore, the cross-domain service request carries information about the calling party (e.g., the calling party's user identifier) ​​and the called party (e.g., the called party's user identifier).

[0066] When the first user interaction entry 12 receives a cross-domain business request initiated by a user (including parameters such as custom bandwidth and service time), it can transmit the request to the first business core network 11 in real time through a socket connection with the first business core network 11, thus avoiding the delay in the request-response mode of the traditional HTTP protocol.

[0067] After the first service core network 11 receives the cross-domain service request, when it is found that the cross-domain service request corresponds to a cross-domain service, first, the in-domain resource checking is performed according to the cross-domain service request, to determine whether the interface state of the first user access device 13 is available at the service time (determined according to the start service time + service duration), whether the first service gateway 14 can allocate a connection bandwidth sufficient to meet the service demand at the time, whether the load of the in-domain transmission link is within the threshold range, and the like.

[0068] Since the in-domain resource does not need to be exposed to the core controller in this process, the risk of privacy leakage can be greatly reduced, and since the process is performed locally in the service core network, information transmission is not required, and the efficiency is extremely high.

[0069] After the in-domain resource checking is performed, whether the requirement is met or not, the resource checking result can be directly reported to the first user interaction portal 12, so that the user can learn the in-domain resource checking result in a timely manner. In some embodiments, the first user interaction portal 12 can also be notified when the checking result of the second service core network 21 is obtained and it is finally determined whether the service demand can be met.

[0070] In an example embodiment, the first service core network 21 can send the notification information to the first user interaction portal 12 in the form of a socket notification (Web socket notice).

[0071] In step S2, when the in-domain resource meets the cross-domain service request, a socket connection request is initiated to the second service core network corresponding to the called terminal, and the socket connection request carries the self-defined service parameter.

[0072] In the embodiments of the present disclosure, the service core networks can be directly and bidirectionally communicated through the socket connection. The first service core network and the second service core network can exchange the resource checking result, the interface configuration state, the routing issuing progress, and the like in real time through the socket connection, so that through the direct and bidirectional negotiation, the time delay of the traditional dependence on the core controller is avoided, and the efficiency and security of the information negotiation are greatly improved.

[0073] After the first service core network 11 checks the in-domain resource, it is determined that the in-domain resource meets the requirement corresponding to the cross-domain service request, then a socket connection request is initiated to the second service core network 21 corresponding to the called terminal according to the IP and port of the called terminal in the cross-domain service request, and the self-defined service parameter corresponding to the cross-domain service request is carried in the socket connection request, so that the second service core network 21 performs the in-domain resource checking according to the self-defined service parameter, to determine whether the in-domain resource (i.e., the resource of the second domain 2) meets the requirement corresponding to the cross-domain service request.

[0074] At step S3, a service acceptance notification is sent to the user interactive portal in response to a service acceptance message returned from the second service core network through the socket connection, the service acceptance notification including a session identifier of a session corresponding to the cross-domain service request, the service acceptance message indicating that the second service core network determines that the resources within the domain of the second service core network satisfy the cross-domain service request after checking the resources within the domain of the second service core network according to the cross-domain service request, and the calling terminal is a legal user.

[0075] In an exemplary embodiment, the first service core network 11 also returns a service rejection notification to the user interactive portal in response to a service rejection message returned from the second service core network through the socket connection.

[0076] Figure 3 is an interaction schematic diagram of a communication method in an exemplary embodiment of the present disclosure.

[0077] Reference Figure 3 In an exemplary embodiment, the first service core network 11 sends a socket connection request to the second service core network 21, and carries the custom service parameter.

[0078] After the second service core network 21 receives the socket connection request, the custom service parameter is obtained, and a socket connection is established according to the communication rule of the socket connection. The specific connection establishment process is, for example:

[0079] The first service core network 11 sends a WebSocket handshake request to the second service core network 21, and the request includes a cross-domain service request, a service identifier, a protocol version, a connection key, and the like;

[0080] The second service core network 21 first obtains the custom service parameter, and then verifies the legality of the service identifier in the request and the compatibility of the protocol version. If the verification is passed, a response key is generated and a handshake response is returned, and the response includes a confirmation of the request key and connection parameters (such as a maximum message length, a compression algorithm, and the like);

[0081] After the first service core network 11 checks that the response key is consistent with the local calculation result, it is confirmed that the handshake is successful, and the upgrade from the HTTP protocol to the WebSocket protocol is completed by both parties;

[0082] After the connection is established, the first service core network 11 and the second service core network 21 respectively send a connection ready notification to each other, confirming that the bidirectional data transmission can be started, and thus the establishment of the socket connection is completed.

[0083] Next, the second service core network 21 checks the legality of the user of the calling terminal according to the self-defined service parameter, for example, checks the legality of the user through the user identifier of the calling terminal user. If it is determined that the calling terminal user is a legal user, then next, the inter-domain resource check is carried out, and the check method is consistent with the method of the first service core network 21 for inter-domain resource check. If it is determined that the calling terminal user is an illegal user, then the service rejection message is directly returned to the first service core network 11 through the socket connection. In this way, when the Z terminal (the second service core network 21) completes the user legality verification, the result can be immediately synchronized to the A terminal (the first service core network 21) through the Websocket, without the A terminal repeatedly initiating the query, which greatly improves the efficiency of cross-domain negotiation.

[0084] In addition, if the second service core network 21 determines that the inter-domain resource meets the demand corresponding to the cross-domain service request after the inter-domain resource check, then the service acceptance message is directly returned to the first service core network 11 through the socket connection; if the second service core network 21 determines that the inter-domain resource does not meet the demand corresponding to the cross-domain service request, then the service rejection message is directly returned to the first service core network 11 through the socket connection.

[0085] In summary, if the first service core network 11 receives the service acceptance message from the second service core network 21, it means that the service demand of the cross-domain service can be met, and the configuration preparation for the cross-domain service is started, for example, a session identifier (SID) is first generated for the cross-domain service, and the session identifier is fed back to the first user interaction portal 12 together with the service acceptance message in real time, so that the user can timely know the service dynamics.

[0086] If the first service core network 11 receives the service rejection message from the second service core network 21, then the service rejection message is directly fed back to the first user interaction portal 12, so that the user can timely obtain the service exception state. Through the bidirectional real-time transmission of the verification result, the first service core network 11 can receive and synchronize to the first user interaction portal 12 without waiting for polling, which greatly shortens the abnormal response time.

[0087] This bidirectional communication mechanism does not need the sub-controller to frequently send requests to the global controller, reduces the redundant overhead of connection establishment and data transmission, and reduces the server performance pressure. When the cross-domain service traffic surges, it can more efficiently complete the multi-round interactive negotiation, guarantee the stability of the whole process from the request initiation, resource confirmation to connection establishment, and provide technical support for the achievement of SLA (service level agreement).

[0088] It should be noted that the process of reviewing custom parameters and establishing socket connections in the second service core network 21 can be performed in parallel. This is as long as the socket connection establishment is completed before the second service core network 21 sends a service acceptance message or a service rejection message.

[0089] In addition to directly feeding back service consent or rejection messages to the first user interaction entry 12 as described above, in some embodiments, the second service core network 21 and the first service core network 11 can also negotiate and adjust the resource requirements of the cross-domain service request through communication with the first user interaction entry 12 when the resources within either of their domains do not meet the resource requirements of the cross-domain service request, and determine the final resources.

[0090] For example, during the business negotiation process, the first user interaction entry 12 can receive resource status information (such as available bandwidth range, estimated service startup time, etc.) returned by the second business core network 21 and / or the first business core network 11, and support users to adjust and reconfirm the custom parameters in cross-domain business requests, forming a closed-loop interaction.

[0091] and Figure 3 Unlike the embodiments shown, this negotiation process involves multiple interactions and communications between the first user interaction entry 12, the first business core network 11, and the second business core network 21.

[0092] For example, a user initiates a cross-domain service request through the first user interaction portal 12, with a connection bandwidth of 100Mbps, a service start time of the current time (or within a short period), and a service duration of 2 hours. After checking the resources in its domain, the first service core network 11 finds that the first service gateway 14 can currently only provide 80Mbps bandwidth, and then pushes this information to the first user interaction portal 12 via WebSocket. At the same time, the first service core network 11 synchronizes the cross-domain service request to the second service core network 21. After checking, the second service core network 21 finds that its domain's service gateway supports a maximum bandwidth of 90Mbps, and the service time needs to be shortened to 1.5 hours to match resource scheduling. It then feeds back this result to the first service core network 11 in real time via a WebSocket connection, and the first service core network 11 forwards it to the first user interaction portal 12 via a WebSocket connection.

[0093] After viewing the resource limitations reported by both ends through the first user interaction portal 12, the user adjusts the connection bandwidth to 80Mbps and the service time to 1.5 hours in the custom parameters, and resubmits the cross-domain service request. The first service core network 11 and the second service core network 21 verify again to confirm that the resources in this domain meet the adjusted parameters. Finally, the agreed result is fed back to the user through the first user interaction portal 12, completing the resource confirmation for the cross-domain service request.

[0094] Or, the user initiates a cross-domain service request with bandwidth 50Mbps and service time 3 hours through the first user interaction portal 12. The first service core network 11 checks the resource of the domain and finds that the interface state of the first user access device 13 is normal, the first service gateway 14 can currently allocate bandwidth 60Mbps (satisfying the demand of 50Mbps), and the load of the intra-domain link is within the threshold, and the check is successful.

[0095] The first service core network 11 synchronizes the request to the second service core network 21 through the Web Socket connection, and the second service core network 21 checks and finds that the intra-domain service gateway can currently only provide bandwidth 30Mbps (insufficient for 50Mbps) and the service time can support at most 2 hours (shorter than 3 hours), and the resource is not satisfied.

[0096] At this time, the second service core network 21 feeds back the resource limit (maximum 30Mbps and maximum 2 hours) to the first service core network 11, which is then pushed to the first user interaction portal 12. The user adjusts the parameters to bandwidth 30Mbps and service time 2 hours through the portal and resubmits, and the second service core network 21 checks and passes, and the resources of both parties are confirmed to complete the negotiation.

[0097] Or, the user initiates a cross-domain service request with bandwidth 80Mbps and service time 4 hours through the first user interaction portal 12. The first service core network 11 checks the resource of the domain and finds that the current bandwidth of the first service gateway 14 is only 60Mbps (insufficient for 80Mbps), and the load of the intra-domain link has reached the threshold, which cannot support 4 hours of continuous transmission, and the resource is not satisfied. The first service core network 11 pushes the resource limit (maximum 60Mbps and maximum 3 hours) of itself to the first user interaction portal 12. The user adjusts the parameters to bandwidth 60Mbps and service time 3 hours, resubmits, and the first service core network 11 checks and passes, and then transmits the custom parameters of the cross-domain service request to the second service core network 21 for secondary check.

[0098] The above negotiation process is only an example. In practice, the first user interaction portal 12, the first service core network 11, and the second service core network 21 can realize multiple efficient interactive communications through the connection between the first user interaction portal 12 and the first service core network 11 and the connection between the first service core network 11 and the second service core network 21, so that the cross-domain service request proposed by the user can be efficiently dynamically adapted according to the actual resource status in the domains of both parties. This avoids directly terminating the service due to insufficient resources in a single domain, and also eliminates the need for the user to manually and repeatedly try different parameter combinations. Through this multi-round negotiation mechanism, the finally determined service resource parameters can not only match the resource bearing capacity in the domains of both parties, but also can best meet the core needs of the user, achieving a balance between resource constraints and service needs and improving the success rate of cross-domain services and user experience.

[0099] After the resource negotiation is successful, the first service core network 11 and the second service core network 21 start to respectively configure the resources in their respective domains to support the cross-domain service.

[0100] At step S4, the first user access device and the first service gateway are configured according to the custom service parameters to support the session corresponding to the cross-domain service request between the service start time and the service end time, and the service end time is determined according to the service start time and the connection duration or according to a session end instruction from the user interaction portal.

[0101] The first service core network 11 and the second service core network 21 configure the resources in the domains. From the time point of view, it can be divided into a first phase of configuring immediately after the negotiation is successful, a second phase of configuring before and after the service start time, and a third phase of configuring at the service end time. From the device point of view, it can be divided into configuring the user access device and configuring the service gateway.

[0102] Figure 4 is a subflowchart of step S4 in the example embodiment of the present disclosure.

[0103] Reference Figure 4 In the example embodiment, step S4 can include:

[0104] Step S41, in response to the service acceptance message, determining a second static route of a second user access device of the called end, and sending the second static route to the first user access device;

[0105] Step S42, before the service start time, enabling a wide area network interface of the first user access device;

[0106] Step S43, at the service start time, sending a bandwidth adjustment instruction to the first service gateway according to the connection bandwidth; ​

[0107] Step S44, at the service end time, sending a static route deletion instruction to the first user access device, and closing the wide area network interface of the first user access device.

[0108] Figure 5 is an interaction schematic diagram configured in the step S4 in the example embodiment of the present disclosure.

[0109] Reference Figure 4 and Figure 5 understand Figure 4 the embodiments shown in the drawings.

[0110] In the embodiment of the present disclosure, the second service core network 21 can carry the second static route of the second user access device of the called end in the service acceptance message.

[0111] Therefore, in the first stage of configuration immediately after the negotiation is successful, the first service core network 11 can send the second static route to the first user access device 13, so that the first user access device 13 can accurately forward the data to the second user access device 23 of the called end through the first service gateway 14, the cross-domain private link and the second service gateway 24 of the opposite end according to the guidance of the second static route when receiving the service data of the user equipment of the calling end. This process ensures the pre-fixing of the data transmission path of the calling end, avoids the delay or loss caused by uncertain routing when the data is transmitted between domains, and enables the first user access device to directly perform data forwarding operation according to the preset route without additional routing calculation, thereby improving the efficiency and stability of cross-domain communication.

[0112] In addition, since the socket connection between the first service core network 21 and the second service core network 22 is still in an effective state after the second service core network 21 sends the service acceptance message, the first service core network 11 can also respond to the service acceptance message and send the first static route of the first user access device 13 to the second service core network 21 through the socket connection, so that the second service core network 21 sends the first static route to the second user access device 23, thereby realizing the pre-configuration of the routes of both parties.

[0113] After the first service core network 21 and the second service core network 22 complete the static route distribution, they can respectively send an execution feedback message to each other through the socket connection, so that the other party determines that the route distribution has been completed.

[0114] At this time, since the subsequent first service core network 21 and the second service core network 22 respectively control the resource configuration in the respective domains, resource negotiation is not required, and the two parties can end the Web Socket connection to reduce unnecessary network connection occupation, reduce the resource overhead (such as memory occupation and thread consumption) of the server for connection maintenance, and avoid security risks (such as unauthorized access risks) that may be caused by idle connections.

[0115] The manner of ending the Web Socket connection is, for example, that the first service core network 11 sends a connection termination request to the second service core network 21 after confirming that the first user access device has successfully received and applied the second static route and that the second service core network 21 has sent a route distribution success message (sent in the form of Web Socket Notice); the second service core network 21 returns a confirmation response after completing the distribution of the corresponding second static route to the second user access device 23, receiving the route distribution success message (sent in the form of Web Socket Notice) from the first service core network 11, and receiving the connection termination request; and the two parties close their respective Web Socket connection ports and release the resources occupied by the connection after receiving the confirmation information.

[0116] In some embodiments, if the service start time point is close to the current time point, the Web Socket connection between the first service core network 21 and the second service core network 22 can also not be closed, and a person skilled in the art can decide whether to close the Web Socket connection according to actual needs.

[0117] Before the service start time, the first service core network 11 can enable the WAN interface (wide area network interface) of the first user access device 13 in the domain at any time according to the secondary dialing account and password, the service type, the service gateway address, and the local identifier (Local SID) of the user access device, to ensure that the service data of the calling end user device can be successfully transmitted through the activated WAN interface at the service start time. Specifically, the interface is authenticated through the secondary dialing account and password, a corresponding transmission strategy (such as QoS priority) is matched in combination with the service type, and a precise forwarding path is established based on the service gateway address and the Local SID of the user access device, so that the WAN interface of the first user access device 13 is in a ready state before the service starts, avoiding service delay or interruption caused by an inactive interface.

[0118] Similarly, the second service core network 21 can also enable the second user access device 23 at any time before the service start time.

[0119] Continuing to refer to Figure 4 and Figure 5At the service start time, the first service core network 11 and the second service core network 21 can respectively issue bandwidth adjustment instructions to the corresponding first service gateway 14 and the second service gateway 24, to dynamically adjust the resource allocation parameters of the service gateways, and ensure that the cross-domain service is executed according to the negotiation result.

[0120] Specifically, the form of the bandwidth adjustment instruction is, for example, a COA (Change of Authorization) policy, which can contain key parameters such as the bandwidth upper limit required by the service, the traffic priority label, and the session timeout time. For example, the COA policy issued by the first service core network 11 to the first service gateway 14 can explicitly adjust the bandwidth allocated to the cross-domain service to 80 Mbps as determined by negotiation, and mark the traffic priority as "high"; the COA policy issued by the second service core network 21 to the second service gateway 24 synchronously configures the corresponding bandwidth and priority, and sets the session duration to be consistent with the service time.

[0121] Through this real-time authorization change, the service gateway can complete resource switching at the moment of service start, avoiding both the waste caused by pre-occupying resources and the insufficiency of resources at the start of the service. At the same time, the issuance of the COA policy does not need to interrupt existing connections, and can take effect dynamically during the session duration, providing support for flexible scheduling of cross-domain services. When the service is close to the end, the core network can also gradually recover resources through the COA policy, realizing efficient recycling of resources.

[0122] After the first service core network 11 completes the configuration of the first user access device 13 and the first service gateway 14, it can send a service configuration success message to the first user interaction portal 12, to realize real-time sharing of information. This service configuration success message can correspond to each configuration step (for example, one is sent after the configuration of the first user access device 13, and another is sent after the configuration of the first service gateway 14), or it can be sent only after all configurations are completed.

[0123] In addition, if the socket connection between the first service core network 11 and the second service core network 12 is not closed, the service configuration success message of the second service core network 21 can also be synchronized to the first user interaction portal 12 through the socket connection. The service configuration success message of the second service core network 21 can also correspond to each configuration step or be sent only after all configurations are completed.

[0124] Continuing to refer to Figure 5After sending the service configuration success message, the first service core network 11 does not immediately exit, but continues to supervise the following network establishment process and obtain feedback information through the management connection with the first service gateway 14: verifying whether the first service gateway 14 has correctly loaded the COA strategy, confirming that the bandwidth allocation, priority label and other parameters are consistent with the configuration instructions, and receiving the configuration effectiveness feedback returned by the first service gateway 14; monitoring the link connectivity between the first user access device 13 and the first service gateway 14, and confirming that the data forwarding path is unblocked by periodically sending heartbeat messages; synchronously receiving state synchronization information of the second service core network 21, confirming the configuration effectiveness of the second service gateway 24 and the bidirectional communication state (such as whether the packet loss rate and the delay are within the threshold) of the cross-domain link; checking the session state of the first user device and the first user access device 13, and confirming that the UE has completed access authentication and that the network information between the first service core network 11 and the second service core network 12 at the WAN interface is synchronized and activated.

[0125] In this process, the state synchronization information between the first service core network 11 and the second service core network 12 can be realized by re-establishing a socket connection, or by other communication methods.

[0126] After all the above links are verified, and the first service gateway 14, the second service gateway 24 and the cross-domain link continue to run stably (usually need to maintain a preset time length of no abnormal state), the first service core network 11 determines that the network has been successfully established, at which time the active supervision process is exited, and passive monitoring is performed through the state message periodically reported by the gateway, and the intervention mechanism is triggered only when link interruption, resource overrun and other abnormalities occur.

[0127] In an exemplary embodiment, after the first service core network 11 determines that the network has been successfully established, a session identifier (SID) is generated for the session, and connection information (including the user identification of the calling end and the called end, the service gateway address, the static routing path, the bandwidth parameter and the session validity period, etc.) is recorded, and a network connection success message is sent to the first user interactive interface 12, and the session ID is carried in the network connection success message.

[0128] The session ID serves as a unique identifier for cross-domain services, and can be used for state query, resource adjustment and session termination in subsequent service processes - for example, when the user initiates a service suspension request through the first user interactive interface 12, the session ID needs to be carried, the first service core network 11 locates the corresponding session record based on the session ID, and then cooperates with the second service core network 21 to execute the suspension logic; at the same time, the two core networks can also associate and aggregate the billing data based on the session ID, to ensure the traceability of the whole service life cycle.

[0129] After receiving the network connection success message, the first user equipment can start the cross-domain service according to the service request. For example, the service data (such as high-definition video stream, real-time interaction data, etc.) generated by the first user equipment is first sent to the first user access equipment 13 through the local connection; the first user access equipment 13 forwards the data to the first service gateway 14 in the local domain according to the preset second static route and interface configuration; the first service gateway 14 marks (such as adding a priority label) and controls the bandwidth of the data according to the COA strategy, and then transmits the data to the second service gateway 24 through the cross-domain special link (or an encrypted channel through the Internet); the second service gateway 24 receives the data, checks and forwards the data according to the policy configured in the domain, and transmits the data to the second user access equipment 23; the second user access equipment 23 finally pushes the data to the second user equipment, completing a one-way data transmission. If it is a two-way interactive service (such as video conference), the response data generated by the second user equipment is transmitted along the reverse path: through the second user access equipment 23, the second service gateway 24, the cross-domain link, the first service gateway 14, the first user access equipment 13, and finally fed back to the first user equipment, forming a complete cross-domain data flow circulation loop.

[0130] With reference to Figure 4 and Figure 5 , the configuration of the service core network to the devices in the domain also includes the configuration at the service end time. In the first domain 1, at the service end time, the first service core network 11 sends a static route deletion instruction to the first user access equipment 13 to close the wide area network interface of the first user access equipment 13; the second service core network 21 sends a static route deletion instruction to the second user access equipment 23 to close the wide area network interface of the second user access equipment 23. Thus, the service core network A and Z at both ends issues a static route deletion to the user access equipment in the respective domain, and disables the corresponding WAN interface, completing the disassembly of the connection.

[0131] Since the service core network needs to manage multiple terminal devices and thus manage multiple cross-domain services, in order to enable the service core network to complete the configuration of each cross-domain service in time, the example embodiment of the present disclosure sets to use a preset message queue to manage the operation of the service core network corresponding to each cross-domain service, so that the service core network can poll the preset message queue, take out the message corresponding to the current time point, and complete the device configuration of the cross-domain service according to the content recorded in the message.

[0132] Figure 6 is a subflowchart of step S4 in the example embodiment of the present disclosure.

[0133] With reference to Figure 6 , in the example embodiment, step S4 can include:

[0134] Step S45, determining the service end time according to the service start time and the connection duration;

[0135] Step S46, writing an execution message corresponding to the cross-domain service request in the preset message queue, the execution message including the service end time, a session identifier of a session corresponding to the cross-domain service request, and configuration information for configuring the first user access device at the service end time;

[0136] Step S47, polling the preset message queue, and when the service end time in the execution message at the head node of the preset message queue corresponds to the current time, consuming the execution message to configure the first user access device corresponding to the session identifier according to the configuration information.

[0137] The preset message queue can also be referred to as a delay queue, and is used to store operation instructions to be executed by a service core network at a specific time point in the future for all cross-domain services. For example, in the preset message queue of the first service core network 11, a message in the form of "session ID-service end time-send static route deletion instruction and wide area network interface shutdown instruction to the first user access device x" can be stored for each cross-domain service, so that the first service core network 11 can check whether the service end time at the head node of the preset message queue is the current time point in real time by polling the preset message queue. If so, the message is taken out and the session ID and operation instruction in the message are parsed to locate the first user access device x. Subsequently, the first service core network 11 sends a static route deletion instruction to the first user access device x to clear the previously configured second static route pointing to the opposite end to avoid invalid routes occupying device storage resources, and simultaneously sends a wide area network interface shutdown instruction to disable the interface to terminate the data transmission channel. After the operation is completed, the first service core network 11 removes the message from the queue, completes message consumption, and updates the state of the cross-domain service in the local session record to "terminated", and simultaneously synchronizes the operation result to the second service core network 21 to ensure that the corresponding resource release operation is performed by the opposite side to ensure that the resources in both domains are timely recovered. If the service end time at the head node of the preset message queue is not the current time point, the first service core network 11 does not process the message, continues to maintain the polling state, and waits for the next check time point to make a judgment.

[0138] The second service core network 21 also processes in the same way, and sets a preset message queue corresponding to the second service core network 21. Each service core network can maintain one or more preset message queues corresponding thereto.

[0139] In addition, in addition to adding a message corresponding to the service in the preset message queue after the service time starts, the first service core network 11 can also generate a service start time corresponding message (the message form is, for example, "session ID-service start time-bandwidth adjustment instruction sent to the first service gateway y") after receiving the service acceptance message from the second service core network 21, so as to ensure that when the service start time arrives, the first service gateway y can be configured through the message of the preset message queue corresponding to the session ID, so that the first service gateway y can complete resource adjustment in a timely manner according to the negotiated bandwidth parameter, avoid that the service start is blocked due to temporary configuration delay, and at the same time, through the time sorting mechanism of the preset message queue, the start configuration operation of multiple cross-domain services is executed in time sequence in order, so as to prevent resource scheduling conflicts.

[0140] Through this mechanism, the service core network does not need to maintain a timer for each cross-domain service, but only needs to process all to-be-executed operations in time sequence through unified polling of the delay queue, which not only reduces the scheduling complexity when multiple services are concurrent, but also ensures the time accuracy of operation execution. For example, when the service end time of a cross-domain service arrives, the delay queue will automatically push the corresponding execution message to the processing node, and after the first service core network 11 consumes the message, the WAN interface of the first user access device 13 can be disabled according to the configuration information, and the first service gateway 14 is notified to release the related bandwidth resource, so as to complete the closed-loop management of the service session.

[0141] In addition to completing the configuration according to the service end time point in the service request, in some embodiments, the user is also allowed to send a session end instruction through the first user interactive portal 12 to reset the end time of the session, that is, the service end time, so that the first service core network 11 completes the configuration according to the updated service end time to realize connection removal.

[0142] Figure 7 is a subflowchart of step S4 in the example embodiment of the present disclosure.

[0143] Reference Figure 7 In the example embodiment, step S4 can further include:

[0144] Step S71, in response to a session end instruction from the user interactive portal, determining a session identifier and a specified service end time corresponding to the session identifier;

[0145] Step S72, searching for an execution message corresponding to the session identifier in the preset message queue, and updating the service end time recorded in the execution message corresponding to the session identifier to the specified service end time;

[0146] Step S73, the second service core network is sent a session end instruction according to the session identifier and the specified service end time.

[0147] Figure 8 is an interaction schematic diagram corresponding to the service end time in the exemplary embodiments of the present disclosure.

[0148] Reference is made to Figure 7 and Figure 8 .

[0149] In the exemplary embodiments, when each service core network sets a preset message queue to manage the operation corresponding to the service end time, upon receiving the session end instruction sent by the user through the first user interaction entry 12, the first service core network 11 determines the session identifier in the session end instruction and the specified service end time corresponding to the session identifier, and then retrieves the original execution message corresponding to the session identifier (i.e., the message recording the original service end time) in the local preset message queue, updates the service end time field in the message to the specified service end time, and re-adjusts the sorting position of the message in the queue according to the new time (for example, if the specified service end time is earlier than the original time, the message is moved to the queue position corresponding to the time node).

[0150] After completing the local message update, the first service core network 11 re-establishes the socket connection with the second service core network 21, and sends a session end instruction carrying the session identifier and the specified service end time through the socket connection. After receiving the instruction, the second service core network 21 performs the same operation logic as the first service core network 11: locates the execution message corresponding to the session in its own preset message queue, updates the service end time and adjusts the queue sorting.

[0151] When the preset message queue is polled to the updated specified service end time, the two core networks respectively consume the corresponding execution messages, and synchronously perform resource release operations (such as deleting static routes, closing wide area network interfaces, reclaiming bandwidth, etc.) on the user access devices and service gateways in their respective domains, to ensure that the cross-domain service is terminated at the time point specified by the user, and to realize flexible control of the session end.

[0152] This mechanism allows the user to terminate the service in advance or delay the termination according to the actual needs, and through the dynamic update capability of the message queue, it ensures that the time adjustment instruction can be executed in time, and the operations of the two core networks remain consistent, avoiding resource waste or connection abnormalities caused by unilateral termination.

[0153] In the example embodiment, the socket connection between the first service core network 11 and the second service core network 21 can also be maintained all the time before the cross-domain service ends. Thus, before or during the cross-domain service, if the service core networks of both parties find that the in-domain resources are abnormal, for example, the actual available bandwidth of the first service gateway 14 suddenly drops below 60% of the negotiated value, or the wide area network interface of the second user access device 23 frequently disconnects (for example, 3 or more times of disconnection within 5 minutes), the socket connection can be used to send resource abnormality notification to the other party in real time, carrying the abnormality type, the affected range, and the current resource data (such as the real-time bandwidth value and the interface disconnection timestamp).

[0154] After receiving the notification, the core network of the other party can trigger a cooperative processing mechanism according to the abnormality degree: if it is a slight abnormality (such as temporary fluctuation of the bandwidth but still higher than the minimum requirement of the service), a “continuous monitoring” response is fed back through the socket connection, and both parties keep high-frequency synchronization of the resource state; if the abnormality has affected the normal operation of the service (such as the bandwidth being lower than the threshold value to cause the data packet loss rate to exceed 10%), a dynamic adjustment process is started—the first service core network 11 can send a temporary bandwidth adjustment request to the second service core network 21 through the connection, negotiate whether to reduce the service rate to match the current resource; if the negotiation is consistent, both parties update the COA strategy of the service gateway synchronously, and inform the user of the adjustment result through the user interaction interface; if an agreement cannot be reached (such as no redundant resources in the domain of the other party), it is decided to terminate the service in advance, and the time point of releasing the resources is synchronized through the socket connection, so as to avoid data transmission confusion caused by unilateral operation.

[0155] The continuous socket connection provides a low-delay channel for real-time cooperative processing of resource abnormalities, and compared with re-establishing the connection, it can respond to the burst condition faster, reduce the service interruption time or data loss, and improve the stability and fault tolerance of the cross-domain service.

[0156] Figure 9 is a flowchart of a communication method executed by the second service core network in the example embodiment of the present disclosure.

[0157] Reference Figure 9 In the example embodiment, the communication method 900 executed by the second service core network 21 in the system 100 shown in FIG. 1 can include the following steps. Figure 1

[0158] Step S91, in response to the socket connection request from the first service core network, establishing a socket connection between the first service core network and the second service core network;

[0159] Step S92, obtaining the custom service parameters carried in the socket connection request, the custom service parameters including the user information of the calling end, the user information of the called end, the connection bandwidth, the service start time, and the connection duration; ​

[0160] Step S93, after determining that the user of the calling terminal is a legal user, checking the intra-domain resource according to the self-defined service parameter;

[0161] Step S94, when the intra-domain resource meets the cross-domain service request, sending a service acceptance message to the first service core network through the socket connection;

[0162] Step S95, configuring the second user access device and the second service gateway according to the self-defined service parameter, supporting the session corresponding to the cross-domain service request between the service start time and the service end time, the service end time being determined according to the service start time and the connection duration, or being determined according to the session end instruction from the first service core network.

[0163] Reference Figure 9 From the above description, the second service core network 21 is the service core network of the called terminal.

[0164] In steps S91 and S92, after receiving the socket connection request from the first service core network 14, the second service core network 21 as the service core network of the called terminal acquires the self-defined service parameter and establishes the socket connection establishment according to the communication rules of the socket connection. The specific connection establishment process is, for example:

[0165] The first service core network 11 sends a WebSocket handshake request to the second service core network 21, the request containing the cross-domain service request, the service identifier, the protocol version, the connection key and the like;

[0166] The second service core network 21 first acquires the self-defined service parameter, then verifies the legality of the service identifier and the compatibility of the protocol version in the request, and if the verification is passed, generates a response key and returns a handshake response, the response containing the confirmation of the request key and the connection parameters (such as the maximum message length, the compression algorithm and the like);

[0167] After the first service core network 11 checks that the response key is consistent with the local calculation result, it confirms that the handshake is successful, and the upgrade from the HTTP protocol to the WebSocket protocol is completed by both parties;

[0168] After the connection is established, the first service core network 11 and the second service core network 21 respectively send a connection ready notification to each other, confirming that the bidirectional data transmission can be started, and thus the establishment of the socket connection is completed.

[0169] Next, in step S93, the second service core network 21 checks the legality of the user of the calling terminal according to the self-defined service parameter, for example, checks the legality of the user through the user identifier of the user of the calling terminal. If it is determined that the user of the calling terminal is a legal user, then next, the inter-domain resource checking is performed, and the checking manner is consistent with the manner of performing the inter-domain resource checking by the first service core network 21. If it is determined that the user of the calling terminal is an illegal user, then the service rejection message is directly returned to the first service core network 11 through the socket connection. In this way, when the Z terminal (the second service core network 21) completes the user legality verification, the result can be immediately synchronized to the A terminal (the first service core network 21) through the Websocket, without the A terminal repeatedly initiating the query, and the efficiency of the cross-domain negotiation is greatly improved.

[0170] In step S94, if the second service core network 21 determines that the inter-domain resource meets the demand corresponding to the cross-domain service request after the inter-domain resource checking, then the service acceptance message is directly returned to the first service core network 11 through the socket connection. If the second service core network 21 determines that the inter-domain resource does not meet the demand corresponding to the cross-domain service request, then the service rejection message is directly returned to the first service core network 11 through the socket connection.

[0171] In step S95, the second user access device and the second service gateway are configured according to the self-defined service parameter.

[0172] Figure 10 FIG. 10 is a sub-flowchart of step S95 in the example embodiment of the present disclosure.

[0173] Reference Figure 10 In the example embodiment, step S95 can include:

[0174] Step S951, a first static route of a first user access device of a calling terminal sent by a first service core network is acquired, and the first static route is sent to a second user access device.

[0175] Step S952, before a service start time, a wide area network interface of the second user access device is enabled.

[0176] Step S953, at the service start time, a bandwidth adjustment instruction is sent to a second service gateway according to a connection bandwidth.

[0177] Step S954, at a service end time, a static route deletion instruction is sent to the second user access device, and the wide area network interface of the second user access device is closed.

[0178] The second service core network 24 configures the second user access device 23 and the second service gateway 24 in the domain in the same way as the first service core network 14 configures the first user access device 13 and the first service gateway 14 in the domain, which has been described in the related description of step S4 of the communication method 200 performed by the first service core network 14 above.

[0179] Thus, in the embodiments of the present disclosure, the service core network is used to receive user demand, intra-domain management, and cross-domain negotiation. The calling side service core network (the first service core network 14) and the called side service core network (the second service core network 24) act as peers to perform equal resource negotiation through a Web Socket connection. After the negotiation is successful, the service core networks respectively issue intra-domain configurations to the user access devices and service gateways in the domain, so as to guide the user traffic into the corresponding VPN to realize user-level service guarantee. The key nodes in the service execution process (such as resource reservation success, connection establishment completion, service interruption warning, etc.) are pushed in real time through the socket connection between the service core network and the user interaction entrance, and the user interaction entrance shows the user in a visual form (such as a pop-up window, a progress bar, a status label, etc.), so as to ensure that the user can master the service dynamics in real time.

[0180] In summary, the embodiments of the present disclosure provide flexible user-level service guarantee for user self-service by using a negotiation method to obtain resource negotiation and service guarantee results in the east-west direction (cross-domain) between different domains, and then configuring the domain in the north-south direction (intra-domain), which can solve the problems of the current cross-domain negotiation resource bottleneck between multiple domains, the privacy leakage risk, the low negotiation efficiency, and the policy sovereignty conflict of the traditional scheme relying on a global controller.

[0181] It should be noted that although several modules or units of devices for action execution are mentioned in the foregoing detailed description, such a division is not mandatory. In fact, according to the embodiments of the present disclosure, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided into multiple modules or units for embodiment.

[0182] In the example embodiments of the present disclosure, a communication device capable of implementing the above method is also provided.

[0183] Those skilled in the art can understand that the various aspects of the present disclosure can be implemented as a system, a method or a program product. Therefore, the various aspects of the present disclosure can be embodied as a complete hardware embodiment, a complete software embodiment (including firmware, microcode, etc.), or an embodiment combining hardware and software aspects, which can be collectively referred to as "circuitry", "module" or "system" here.

[0184] The communication device 1100 will be described below with reference to Figure 11 1100 according to this embodiment of the present application. Figure 11 The communication device 1100 shown is merely an example, and should not be taken as limiting the functionality or use of embodiments of the present application.

[0185] As Figure 11 indicated, the communication device 1100 can be used to implement the functions of any communication device in the communication system 100, and the functions of the communication device 1100 at least include being able to perform the communication method 200 and / or the communication method 900, i.e., the communication device 1100 can serve as a service core network of a calling terminal, as a service core network of a called terminal, and can also serve as a service core network of a calling terminal in one cross-domain service and as a service core network of a called terminal in another cross-domain service.

[0186] In exemplary embodiments, the components of the communication device 1100 can include, but are not limited to, at least one processor 1110, at least one memory 1120, and a bus 1130 connecting different system components, including the memory 1120 and the processor 1110.

[0187] The memory stores program codes which can be executed by the processor 1110, so that the processor 1110 performs the steps described in the above “Exemplary Methods” section according to various exemplary embodiments of the present application. For example, the processor 1110 can perform the method as shown in the embodiments of the present disclosure.

[0188] The memory 1120 can include a readable medium in the form of volatile memory, such as a random access memory (RAM) 11201 and / or a cache memory 11202, and can further include a read-only memory (ROM) 11203.

[0189] The memory 1120 can further include program / utilities 11204 having a set of (at least one) program modules 11205, which include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination of which can include implementation of a network environment.

[0190] The bus 1130 can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor or local bus using any of a variety of bus structures.

[0191] The communication device 1100 can also communicate with one or more external devices 1200 such as a keyboard or pointing device, a Bluetooth device, etc.; one or more devices that enable a user to interact with the communication device 1100; and / or one or more devices (e.g. routers, modems, etc.) that enable the communication device 1100 to communicate with one or more other computing devices. Such communication can occur via Input / Output (I / O) interface 1150. Still yet, the communication device 1100 can communicate with one or more networks, such as a local area network (LAN), a wide area network (WAN), and / or the Internet, through network adapter 1160. As depicted, network adapter 1160 communicates with the other components of the communication device 1100 via bus 1130. It should be appreciated that although not shown, other hardware and / or software modules could be used in conjunction with the communication device 1100. Such as, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archival storage systems, etc.

[0192] Through the above description of the embodiments, those skilled in the art can easily understand that the example embodiments described herein can be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solutions according to the embodiments of the present disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (which can be a CD-ROM, a U disk, a mobile hard disk, etc.) or a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, a terminal device, or a network device, etc.) to perform the methods according to the embodiments of the present disclosure.

[0193] In the example embodiments of the present disclosure, a computer readable storage medium is also provided, which stores a program product capable of implementing the above-mentioned method of the present disclosure. In some possible embodiments, various aspects of the present disclosure can also be implemented in the form of a program product, which includes program codes for causing a terminal device to perform the steps described in the above-mentioned "example method" section according to various example embodiments of the present disclosure when the program product is run on the terminal device.

[0194] The program product for implementing the above-mentioned method according to the embodiments of the present disclosure can adopt a portable compact disc read-only memory (CD-ROM) and include program codes, and can be run on a terminal device, such as a personal computer. However, the program product of the present disclosure is not limited to this, and in this document, the readable storage medium can be any tangible medium containing or storing a program, which can be used or combined with an instruction execution system, device or apparatus.

[0195] The program product can employ any combination of one or more computer-readable media. The computer-readable media can be a computer-readable storage medium or a computer-readable signal medium. The computer-readable storage medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the computer-readable storage medium include the following: an electrical connection having one or more wires, a portable disc, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0196] The computer-readable signal medium can include a computer-readable storage medium that is propagated as a carrier wave. The computer-readable signal medium can further be any computer-readable medium that is not a storage medium. The computer-readable signal medium can be a computer-readable storage medium that is a propagated signal on a computer-readable storage medium.

[0197] The program code embodied on the computer-readable media can be transmitted using any appropriate medium, including but not limited to wireless, wired, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

[0198] The program code can be executed by one or more programmable processors, which can be implemented in one or more computer systems. In this context, a computer system generally includes a plurality of these programmable processors, which work in concert to perform a task. Additionally, the program code can be downloaded from an external source, including the internet, through a computer network, or through a broadcast medium.

[0199] Furthermore, the above-described diagrams are merely schematic illustrations of the processes included in the method according to the exemplary embodiments of the present application, and are not intended to be limiting. It is readily understood that the processes shown in the above-described diagrams do not indicate or limit the time sequence of the processes. In addition, it is readily understood that the processes can be executed synchronously or asynchronously, for example, in a plurality of modules.

[0200] Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the features disclosed herein. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.

Claims

1. A communication method, characterized in that, Executed by the first service core network, which is connected to the user interaction entry point, the first user access device, and the first service gateway, including: In response to a cross-domain service request from the user interaction entry, the resources within the domain are checked according to the cross-domain service request. The cross-domain service request includes custom service parameters, which include the user information of the calling party, the user information of the called party, the connection bandwidth, the service start time, and the connection duration. When the resources within the domain satisfy the cross-domain service request, a socket connection request is initiated to the second service core network corresponding to the called party, and the socket connection request carries the custom service parameters. In response to a service acceptance message returned from the second service core network via a socket connection, a service acceptance notification is sent to the user interaction entry. The service acceptance notification includes a session identifier for the session corresponding to the cross-domain service request. The service acceptance message indicates that after the second service core network checks its intra-domain resources according to the cross-domain service request, it determines that the intra-domain resources of the second service core network satisfy the cross-domain service request, and that the calling party is a legitimate user. Configure the first user access device and the first service gateway according to the custom service parameters to support the session corresponding to the cross-domain service request between the service start time and the service end time. The service end time is determined according to the service start time and the connection duration, or according to the session end instruction from the user interaction entry.

2. The communication method as described in claim 1, characterized in that, Also includes: In response to the service rejection message returned from the second service core network through the socket connection, a service rejection notification is returned to the user interaction entry.

3. The communication method as described in claim 1 or 2, characterized in that, The first service core network and the first user interaction portal communicate bidirectionally through a socket connection.

4. The communication method as described in claim 1, characterized in that, Configuring the first user access device and the first service gateway according to the custom service parameters includes: In response to the service acceptance message, determine the second static route of the second user access device of the called end, and send the second static route to the first user access device; Before the service start time, enable the WAN interface of the first user access device; At the service start time, a bandwidth adjustment instruction is sent to the first service gateway based on the connection bandwidth; At the service end time, a static route deletion command is sent to the first user access device to close the wide area network interface of the first user access device.

5. The communication method as described in claim 4, characterized in that, Also includes: In response to the service acceptance message, the system sends the first static route of the first user access device to the second service core network via a socket connection.

6. The communication method as described in claim 4, characterized in that, Configuring the first user access device and the first service gateway according to the custom service parameters includes: The service end time is determined based on the service start time and the connection duration. Write the execution message corresponding to the cross-domain service request into a preset message queue. The execution message includes the service end time, the session identifier of the session corresponding to the cross-domain service request, and the configuration information for configuring the first user access device at the service end time. The preset message queue is polled, and when the service end time in the execution message at the head node of the preset message queue corresponds to the current time, the execution message is consumed to configure the first user access device corresponding to the session identifier according to the configuration information.

7. The communication method as described in claim 6, characterized in that, Configuring the first user access device and the first service gateway according to the custom service parameters further includes: In response to the session termination instruction from the user interaction entry, determine the session identifier and the specified service termination time corresponding to the session identifier; Search for the execution message corresponding to the session identifier in the preset message queue, and update the service end time recorded in the execution message corresponding to the session identifier to the specified service end time; A session termination instruction is sent to the second service core network based on the session identifier and the specified service end time.

8. A communication method, characterized in that, The method is executed by a second service core network, which connects to a second user access device and a second service gateway. The method includes: In response to a socket connection request from the first service core network, establish a socket connection between the first service core network and the second service core network; Obtain the custom service parameters carried in the socket connection request. The custom service parameters include the user information of the calling party, the user information of the called party, the connection bandwidth, the service start time, and the connection duration. After determining that the calling user is a legitimate user, the domain resources are checked according to the custom service parameters; When the resources within the domain satisfy the cross-domain service request, a service acceptance message is sent to the first service core network through the socket connection. Configure the second user access device and the second service gateway according to the custom service parameters, and support the session corresponding to the cross-domain service request between the service start time and the service end time. The service end time is determined according to the service start time and the connection duration, or according to the session end instruction from the first service core network.

9. The communication method as described in claim 8, characterized in that, Configuring the second user access device and the second service gateway according to the custom service parameters includes: Obtain the first static route of the first user access device of the calling party sent by the first service core network, and send the first static route to the second user access device; Before the service start time, enable the WAN interface of the second user access device; At the service start time, a bandwidth adjustment instruction is sent to the second service gateway based on the connection bandwidth; At the service end time, a static route deletion command is sent to the second user access device to close the wide area network interface of the second user access device.

10. A communication system, characterized in that, include: The system comprises a first service core network, a first user interaction portal, a first user access device, a first service gateway, and a second service core network, a second user interaction portal, a second user access device, and a second service gateway, wherein... The first service core network is connected to the first user interaction portal, the first user access device, and the first service gateway. The second service core network is connected to the second user interaction portal, the second user access device, and the second service gateway. The first service core network and the second service core network communicate bidirectionally through a socket connection. The first service core network is used to execute the communication method as described in any one of claims 1-7, and the second service core network is used to execute the communication method as described in claim 8 or 9.

11. A communication device, characterized in that, include: Memory; as well as A processor coupled to the memory, the processor being configured to execute the communication method as described in any one of claims 1-7, and / or, the communication method as described in claim 8 or 9, based on instructions stored in the memory.

Images