Deployment of a gateway in a communication system

Abstract

The invention relates to a control unit suitable for operating on a communication system comprising a first entity (1) and a second entity (2), the control unit being configured to activate (13), on request and / or depending on a criterion, a gateway (4) with a view to a communication between the first entity and second entity, the gateway being configured to allow processing, by a processing module (5), of the communication through the gateway.

Description

Deployment of a gateway in a communication system

[0001] This disclosure falls within the domain of communication systems. More specifically, it concerns a control unit adapted to operate on such a system, as well as a corresponding method, computer program, recording medium, and communication terminal.

[0002] The state of the art includes various approaches for managing communications between entities within a communication system. These include solutions based on predefined routing mechanisms, centralized communication control architectures, and mesh architectures.

[0003] However, these known approaches have several limitations.

[0004] They often impose exchanges based on static or semi-static configurations, which complicates the integration of new functions, slows down deployments, or constrains updates to communication paths. Furthermore, in many cases, they are highly dependent on the system topology, limiting their adaptability to various application contexts.

[0005] The US2004 / 205219 A1 document describes a hierarchical proxy server architecture in a multimedia broadcast network where a Proxy Network Coordinator (PNC) orchestrates the hierarchy. This document discloses a redirection and temporary storage method in which the redirected data stream remains unchanged, but it does not provide a solution for functional and dynamic processing of communications.

[0006] In this context, there is a continuing need for a solution enabling flexible and dynamic activation of communications between entities within a communication system, regardless of the underlying architecture. Summary

[0007] This disclosure improves the situation.

[0008] It is proposed, according to one aspect, a control unit adapted to intervene on a functional processing of an active communication between a first entity and a second entity, the control unit being configured to, on request and / or according to a criterion, activate a gateway for the active communication between the first entity and the second entity, and to control the functional processing, by a processing module associated with the gateway, of the active communication through the gateway.

[0009] According to another aspect, it is proposed an execution unit configured to activate, on an instruction received from a control unit, a gateway for active communication between a first entity and a second entity, and to, during this activation, execute by a processing module associated with the gateway a functional processing of the active communication through the gateway.

[0010] .

[0011] According to another aspect, a process is proposed implemented by a suitable control unit to intervene on a functional processing of an active communication between a first entity and a second entity, the process comprising, on request and / or according to a criterion, an activation of a gateway for the active communication between the first entity and the second entity, and a control of the functional processing, by a processing module associated with the gateway, of the active communication through the gateway.

[0012]

[0013] According to another aspect, a process implemented by an execution unit is proposed, the process comprising: activating, on an instruction received from a control unit, a gateway for active communication between a first entity and a second entity, and for the purpose of this activation, executing by a processing module associated with the gateway, a functional processing of the active communication through the gateway.

[0014] This control unit, execution unit, and these processes offer several technical advantages. In particular, unlike existing solutions requiring static configurations, the control unit and execution unit allow for on-demand gateway activation, thus improving network resource utilization. More specifically, by activating the communication gateway only when necessary, the control unit can help improve communication flow management and reduce bottlenecks in the communication system. Gateway activation by the control unit enables differentiated or specific processing of communications through the gateway. Indeed, gateway activation can involve adding or updating the configuration of a processing module to allow for differentiated or specific handling of communications.Gateway activation can therefore be associated with, control, or include the configuration of a processing module. The processing module may or may not be part of the gateway itself, or it may be co-located with the gateway, for example, in a virtual machine. Ultimately, activation allows for the application or control of specific processing to a communication, either through a configuration of the processing module performed during gateway activation or by sending an instruction to a processing module to apply or modify processing to an active communication.

[0015] Furthermore, gateway activation can be performed on any type of execution entity, without any specific network structure constraints.

[0016] Furthermore, thanks to the processing module, code can be executed dynamically in order, for example, to manage aspects of active communication such as routing, filtering, data transformation or quality of service management.

[0017] According to another aspect, a control unit is proposed that is suitable for operating on a communication system comprising a first entity and a second entity, the first entity being managed by a service management system in a cloud computing environment, the control unit being configured to allow the provision of a service by means of an activation, on request and / or according to a criterion, of a gateway for communication between the first entity and the second entity, the gateway being configured to allow processing, by a processing module, of the communication through the gateway.

[0018] According to another aspect, it is proposed an execution unit configured to activate, on an instruction received from a control unit, a gateway for communication between a first entity managed by a service management system in a cloud computing environment and a second entity, the gateway being configured to allow processing, by a processing module, of the communication through the gateway.

[0019] According to another aspect, a method is proposed implemented by a control unit adapted to operate on a communication system comprising a first entity and a second entity, the first entity being managed by a service management system in a cloud computing environment, the method comprising an activation, on request and / or according to a criterion, of a gateway for communication between the first entity and the second entity, the gateway being configured to allow processing, by a processing module, of the communication through the gateway, thus enabling the provision of a service.

[0020] According to another aspect, a process implemented by an execution unit is proposed, the process comprising: activating, on an instruction received from a control unit, a gateway for communication between a first entity managed by a service management system in a cloud computing environment and a second entity, the gateway being configured to allow processing, by a processing module, of the communication through the gateway.

[0021] In addition to the technical advantages already listed, this control unit, this execution unit and these processes allow, through the activation of the gateway, to facilitate the execution and dynamic interconnection of the service concerned.

[0022] Furthermore, the conditional nature of gateway activation allows for the consideration of requests and / or criteria specific to managing a cloud computing environment. For example, conditional gateway activation can help prevent scenarios that overload the cloud computing environment's infrastructure, thereby providing better management of communications involving one or more services managed by the service management system.

[0023] In another aspect, a computer program is proposed that includes instructions for implementing all or part of a process as defined herein when executed by a processor. In another aspect, a non-transient, computer-readable recording medium is proposed on which such a program is recorded.

[0024] According to another aspect, a communication system is proposed comprising a control unit and an execution unit as defined herein.

[0025] According to another aspect, a communication terminal is proposed comprising a control unit as defined herein.

[0026] According to another aspect, a communication terminal is proposed comprising a communication interface with a control unit and / or with an execution unit as defined herein, the communication interface being configured to transmit and / or receive a gateway activation request and / or a gateway activation criterion to the control unit.

[0027] The features described in the following paragraphs may optionally be implemented independently of each other or in combination with each other.

[0028] In one example, code execution is implemented in a sandbox environment.

[0029] In one example, gateway activation includes distributing executable code and running the distributed code in a sandbox environment.

[0030] In one example, the executable code includes instructions relating to the processing of communication between the first entity and the second entity through the gateway.

[0031] In one example, the executable code includes instructions relating to the integration of a third entity as a connection point in a communication between the first entity and the second entity through the gateway.

[0032] In one example, the control unit is configured to switch, on request and / or according to a criterion, the gateway between: a first mode where the gateway is enabled for communication between the first entity and the second entity, and a second mode where the gateway is disabled for communication between the first entity and the second entity.

[0033] In one example, in the second mode, the gateway allows communication between the first entity and a third entity.

[0034] In one example, a rule is applied to communication through the gateway.

[0035] In one example, the second entity is managed by a second service management system in a second cloud computing environment.

[0036] The term "second" is used here for the purpose of distinction: with respect to the service management system managing the first entity (which is a "first" service management system), and with respect to the cloud computing environment in which the "first" service management system operates (this environment being a "first" cloud computing environment).

[0037] The first service management system and the second service management system can be distinct or the same, and the first cloud computing environment and the second cloud computing environment can be distinct or the same.

[0038] In one example, the processing module includes a web server capable of distributing executable code designed to be downloaded and executed on an execution unit.

[0039] In one example, the processing includes checking a data transmission condition between the first entity and the second entity.

[0040] In one example, the processing includes, when the transmission condition is not met, a rejection or a redirection of the data.

[0041] Other features, details, and advantages will become apparent upon reading the detailed description below and analyzing the attached drawings, on which: Fig. 1

[0042] shows a flowchart of a gateway activation process between a first communicating entity and a second communicating entity according to an example of implementation of the proposed technique. Fig. 2 Fig. 3

[0043] and demonstrate an architecture of a communication system according to an example of the implementation of the proposed technique. Fig. 4

[0044] illustrates a connection scenario between two communicating entities via a gateway according to an example of implementation of the proposed technique. Fig. 5

[0045] shows a computer system according to an example of the implementation of the proposed technique.

[0046] In the description and drawings, identical reference numbers denote identical items or items with similar functions.

[0047] This disclosure relates to a technique for managing communication between entities within a communication system.

[0048] To ensure a better understanding of the proposed technique, certain concepts specific to the field of communication systems are defined below.

[0049] A communication system refers to a set of interconnected entities that enable the exchange of data. Such a system can include various types of entities, such as terminal devices (e.g., user equipment such as mobile terminals, computer equipment, or local network access equipment also called boxes, servers, connected objects), network infrastructures (e.g., routers, switches, gateways), as well as management and control elements (e.g., command units, service orchestrators).

[0050] A control unit is a software and / or hardware component designed to generate and transmit instructions. A control unit suitable for operating on such a communication system is one capable of transmitting commands to the various entities within the system, including gateways, terminal devices, and network infrastructure. This interaction can be direct or indirect. An example of indirect interaction is interaction with a service management system, particularly in a cloud computing environment, to coordinate the implementation of communications and the allocation of communication system resources.

[0051] A gateway is a software and / or hardware component that enables communication between at least two entities in the communication system.

[0052] Communications between entities within a communication system can be classified into several types, depending on the number of entities involved and the direction of the associated data flow, which is routed between them. Unicast communication is communication where the data flow is transmitted between a single source and a single destination. Multicast communication is communication where the data flow is transmitted between a single source and a limited group of recipient entities. Broadcast communication is communication where the data flow is transmitted from a source to all entities in a given network. Anycast communication is communication where the data flow is transmitted from a source to a group of entities, but only entities receiving the data flow respond.Communication can be unidirectional, when data flows only in one direction (for example, the broadcasting of a signal), or conversely bidirectional, when data flows in both directions, allowing interactive exchange between communicating entities.

[0053] Managing a communication can involve various aspects such as latency, quality of service (QoS), quality of experience corresponding to a quality perceived by a user, communication security, communication confidentiality, communication system resilience, etc.

[0054] Active communication through the gateway refers to an ongoing exchange of data between at least two entities of the communications system via the gateway.

[0055] A gateway can include various processing modules. In this context, a processing module is a hardware and / or software component of the gateway adapted to execute specific code to process active communications between communicating entities.

[0056] Processing an active communication may, for example, include one or more of the following aspects: analysis of exchanged data, conversion of communication protocols, filtering of content and / or data streams, securing the communication, for example by encryption of exchanged data, compression of exchanged data, validation of exchanged data, transformation of the format of exchanged data, dynamic routing of the communication by modifying exchanged data during the communication, verification of a transmission condition, for example authentication and / or authorization, etc.

[0057] This processing, which can be described as active or functional, aims to intervene in an active communication in order to analyze it, secure it, or, among other things, transform it. This processing thus enables better administration, improved security, enhanced routing of the communication being processed, and even protocol adaptation of the communication implementation. It therefore involves intervening in a communication, for example, by modifying one or more data streams to address a problem that has arisen or to update and potentially improve the communication. Dynamic routing of the communication can, for example, consist of modifying a quality of service field of a data point.Functional processing can thus correspond to a modification of one or more data packets associated with the communication, enabling the resolution of an identified problem or the improvement of the communication implementation. For example, activating the gateway is accompanied by the application of functional processing aimed at modifying the data routing condition of a communication by a processing module. This processing module therefore modifies a data routing condition of the active communication—that is, the communication currently in progress—following the gateway activation.

[0058] This processing can, for example, be implemented in real time or near real time, and in this case it is called active processing.

[0059] The proposed technique has numerous potential applications, including telecommunications networks, cloud infrastructure, the Internet of Things (IoT), industrial systems, and distributed service networks. It can be implemented in mobile and fixed communication architectures, including cellular, mesh, and satellite networks, as well as private and virtualized networks. It is therefore applicable to microservices systems, containerized service networks, and distributed application management systems. It is also relevant for critical communication systems, such as industrial networks (Industry 4.0), intelligent transportation infrastructures (ITS), and connected healthcare networks. Finally, it is applicable to distributed artificial intelligence and machine learning systems.

[0060] Among the possible areas of application, this document details a scenario where the communication system is integrated into a cloud computing environment.

[0061] Such a scenario is appropriate, for example, in the case where the communication system is cellular.

[0062] A cellular communication system refers to a mobile telecommunications network in which coverage is provided by cells managed by base stations. Known cellular communication system technologies include LTE, 5G, and 6G, as well as systems based on future xG standards. In a cellular communication system, the RAN (Radio Access Network) refers to all the equipment that provides radio access. Several known RAN architectures exist, including Open RAN, vRAN, and Cloud RAN.

[0063] Open RAN, or "disaggregated RAN," is an open architecture where the interfaces between devices are standardized. Virtualized RAN (vRAN) is a virtualized architecture where certain network functions are executed in software on generic servers. Cloud RAN is an architecture where radio functions are centralized in a cloud, with the exception of radio stations (such as Remote Radio Heads (RRHs)) which are deployed in a distributed manner to provide radio coverage to devices connecting to the RAN.

[0064] These architectures are not mutually exclusive and can be combined according to operational needs. For example, a Cloud RAN can integrate Open RAN components to promote interoperability and use virtualized elements (vRAN) to optimize the management of IT and network resources.

[0065] In the scenario under consideration, at least one of the first and second entities is managed by a service management system.

[0066] The term "service" is used in this document broadly to encompass a service in the strict sense, one or more microservices, or even a complete application. An "application" is defined as a set of software functionalities or macro-functions that address a specific need. An application can be composed of one or more services or microservices that work together to provide the overall functionality. It is important to note that the distinction between a "service," a "microservice," and a "macro-function" is primarily based on the scale and functional breakdown of an application's software architecture. A service is a self-contained functional unit that can cover a wide range of functionalities and can either form part of a larger application or be used by multiple applications.A microservice is smaller and is generally responsible for a specific functionality of an application. A macro-function refers to a functional entity that groups several sub-functions, allowing for an abstraction of the services offered within the system. In the context of a cellular mobile communication system, the RAN (Radio Access Network) can be treated as a macro-function that groups the various radio and network processing layers and the different sub-functions that compose the RAN, such as the RRH (Radio Radio Frequency) and BBU (Baseband Unit) sub-functions.

[0067] The term "service system" refers, in the context of this document, to a physical and / or software medium that enables communication and the sharing of resources and services within a communication network. This system may refer to a communication infrastructure or one or more of its sub-components, including data processing and storage systems, servers and networks, data centers, cloud systems, communication equipment, etc. This system may also concern a communication infrastructure within a specific organization, such as an internal network of computers and servers, or a broader infrastructure, such as a communication network or a cloud. The proposed technique is applicable to any type of service system and any type of network architecture.

[0068] A service system comprises a set of resources that can be reserved for the operation of one or more services. This set of resources can include resources of various types, including computation time at the level of one or more processors, memory locations on one or more memory devices, or usage slots, expressed for example in time and / or frequency, on one or more communication channels.

[0069] A service system can be extended across multiple sites and benefit from the efficiency of a multi-site architecture. Such architectures are well-established and enhance robustness and resource management across the entire service system. Distributed edge architectures represent a further evolution that is particularly relevant for telecommunications systems such as Cloud-RAN, where they are currently being deployed.

[0070] Cloud computing environments rely on one or more service systems as defined above.

[0071] In cloud computing environments, the basic hosting unit is often called a "container." These containers are lightweight software units that encapsulate code and all its dependencies, allowing a service to run reliably from one computing environment to another.

[0072] A service management system is a system responsible for managing a microservices architecture. For example, Open RAN, vRAN, and Cloud RAN architectures rely on cloud-native orchestration solutions like Kubernetes. Kubernetes, or K8s, is a well-known and frequently used service management system that facilitates the deployment, scaling, and management of containerized services and / or virtual network functions.

[0073] In the Kubernetes architecture, containers are grouped into "pods," which are the basic unit representing a service deployment. Several pods can be grouped into a "node," which represents a server. The definition of a "node" in Kubernetes corresponds to that of a "node" in the NUMA system. These nodes are then grouped into "clusters," which are sets of servers that work together and can be considered a single system.

[0074] In the context of Kubernetes, a cluster consists of a group of "Masters" and Nodes. Masters are the components of the Kubernetes cluster that provide the control interface or control plane for the cluster, and that manage pod scheduling, failure detection and handling, and the deployment of new application versions. Nodes, on the other hand, are the servers that run the applications and provide the runtime environment for the containers.

[0075] To manage network communications between containers of an application deployed on a Kubernetes cluster, auxiliary containers, known as "sidecar proxies," are attached to each primary application container. Sidecar proxies are responsible for intercepting and managing network communications. Each sidecar proxy acts as an intermediary between the primary container to which it is attached and the rest of the network. To enhance security, sidecar proxies can include features such as request and response validation, permission and identity management, and monitoring.

[0076] ISTIO is an example of an open-source service mesh, commonly used by networking and security operators for running distributed microservices-based applications, and which provides a uniform way to connect, manage, and secure these microservices using sidecar proxies.

[0077] ISTIOD is a central driver for ISTIO, serving as a control point for configuring sidecar proxies. It is designed to manage routing rules, communication and operations policies between services, and service configurations. ISTIOD intervenes in event detection by enforcing management policies and monitoring communications between microservices.

[0078] Existing approaches to communication management within a communication system have several limitations. They do not always allow for dynamic, on-demand communication between different system entities. Furthermore, they often impose rigid configurations on the exchanges, making it difficult to integrate new functions or services and to adapt the infrastructure to evolving contexts, such as the need for enhanced functionality or increased capacity. Finally, they are highly dependent on the underlying topology, which limits their applicability to certain specific use cases, such as telecommunications networks or distributed cloud systems.

[0079] In response to these limitations, the technique proposed in this disclosure introduces a generic mechanism enabling the dynamic activation of communications between entities within a communication system, regardless of the specific nature and organization of these entities.

[0080] The proposed technique is based on a control unit capable of activating a communication gateway between two entities of the communication system, the activation of the gateway being accompanied by the execution, by a processing module, of a specific code allowing the processing of an active communication between these two entities.

[0081] This generic mechanism applies to a wide variety of communication systems, whether they are service networks, cloud infrastructures, or any other environment benefiting from the implementation of dynamic and flexible communications.

[0082] A particularly relevant use case concerns communication systems based on distributed cloud infrastructures, where communicating entities are managed by a service management system.

[0083] Indeed, modern cloud architectures are increasingly distributed, integrating several layers such as the central cloud, fog computing, edge computing, and far edge. In these architectures, managing communications between services becomes a critical issue, particularly to ensure seamless interconnection of the various macro-functions of a network or distributed IT system and to dynamically adapt interactions between services based on network conditions, workloads, and orchestration policies.

[0084] In such a use case, where at least one of the first and second entities is managed by a service management system in a cloud computing environment, the control unit is configured to allow the execution of a service via the proposed generic mechanism, by means of: activating the communication gateway between the first and second entities, and executing code by the processing module once the dynamic gateway is activated.

[0085] In this context, the proposed technique makes it possible to establish, on demand, communications between different workloads, thus facilitating the orchestration and dynamic interconnection of distributed services.

[0086] An example of implementing the proposed technique relies on the use of ISTIOD. This implementation example is particularly well-suited to environments using ISTIOD for service mesh orchestration.

[0087] In this example, the communication gateway orchestration can be implemented via ISTIOD. ISTIOD allows the processing module to control the deployment and execution of specific code elements in the form of extensions (plugins). These extensions also benefit from information provided by the orchestrator, facilitating the dynamic management of active communications by the gateway.

[0088] In this case, the gateway is instantiated as a microservice within ISTIO. Such instantiation allows for flexible deployment tailored to the needs of distributed applications, granular and secure management of interactions between services, and interoperability with Kubernetes environments and orchestrated service meshes.

[0089] The orchestration of the communication gateway via ISTIOD allows in particular the execution of specific code offering one or more of the following functions: reading and modifying the headers of communication packets, rewriting addresses, for example URL addresses, blocking and filtering single or multi-criteria, advanced authentication, notably via JWT (JSON Web Token), etc.

[0090] Another example of implementing the proposed technique involves using an execution unit (e.g., a virtual machine) as the host of a communication gateway (e.g., acting as a web, HTTP, or local server) between communicating entities, with the execution unit encapsulating a WebAssembly object (WASM). This implementation example is particularly well-suited for those wishing to deploy services on the fly, without necessarily relying on an ISTIO environment.

[0091] WebAssembly (WASM) is an instructional language designed to execute code quickly and securely across various platforms. It works equally well in a web browser, on a server, an embedded system, or in a cloud environment. WebAssembly is designed to be portable, meaning that the same program can run on multiple architectures without modification. It offers near-native performance thanks to optimized execution. Its runtime environment is sandboxed, ensuring code isolation and protecting the host system from unauthorized access. It can be used with several programming languages, such as C, C++, and Rust, and integrates easily with other technologies, including JavaScript.

[0092] Originally designed to accelerate web applications, WebAssembly is now used in other areas, such as running cloud services, edge computing, and embedded systems. Its speed and security make it an efficient solution for running code in a portable and reliable way.

[0093] In the implementation example considered, the use of WebAssembly in the gateway makes it possible to orchestrate the activation and reconfiguration of interactions between communicating entities and to execute specific processing on active communications efficiently and securely.

[0094] These processes can include: filtering a communication to analyze and select the data to be transmitted according to defined criteria, modifying the packets of a communication, for example by rewriting the headers or translating the data formats between different entities, applying security policies, such as authentication and authorization of communication flows, for example a communication flow can be transmitted if transmission conditions (authentication and / or authorization in particular) are met and the transmission flow can be rejected or redirected when the transmission conditions are not met, compression or encryption of the data exchanged, intelligent routing of communications, by dynamically adapting the transmission paths according to the network load or the priorities of the service, etc.

[0095] The processing module integrated into the gateway can be configured to adapt, in real time, active communication management according to the execution context.

[0096] This ability to dynamically apply processing rules can, for example: modify the priorities of a communication in case of network congestion, apply access control strategies to allow or restrict certain communications according to the communicating entities concerned, adjust transmission delays and quality of service according to the requirements of one or more running applications, etc.

[0097] In addition to the dynamic processing applied to the active communication, the gateway can also be configured to integrate a third entity into the active communication in a flexible and secure manner. This integration can be triggered on demand or based on defined criteria, allowing a new entity to be added as a temporary or permanent connection point.

[0098] Integrating a third entity can address several use cases.

[0099] In a virtualized telecommunications network management scenario, a third entity can be integrated to act as an additional network function, performing a specific role (for example, an additional routing function, an auditing function, or a latency optimizer). In a distributed cloud context, an external entity can be added to a service mesh to enhance system resilience or provide localized processing of data flows.

[0100] In a scenario where the third entity belongs to the same service mesh as, for example, the first entity, in a traditional architecture, the third entity would normally communicate with the first entity via the internal mechanisms of the service mesh. However, by dynamically integrating the third entity into active communication via the gateway, rather than integrating and having it interact through the service mesh, several advantages can be achieved. Specifically, if the service mesh imposes constraints such as complex routing rules due to its internal policies, direct integration of the third entity via the gateway can enable more efficient communication, independent of these constraints. This type of integration can also incorporate security capabilities inherent to this type of integration.

[0101] In general, integrating a third party can facilitate the interconnection of heterogeneous systems. This interconnection can involve infrastructures using different communication protocols that would not normally be compatible. In this context, the third party is integrated via the gateway and can act, for example, as an adaptation or translation point. It can, for instance, perform dynamic protocol conversion, aggregate data from multiple sources before transmitting it to a target entity, analyze and filter data routed through the gateway, and so on. A specific use case example is the integration of a multi-protocol gateway enabling communication between an industrial private network using specific protocols and a cloud service operating with standard protocols.Another example of a use case is the dynamic addition of an interconnection service in a cloud service mesh, where the gateway external to the clusters acts as a relay between these clusters running on different architectures (e.g., a Kubernetes cluster and an independent virtualized infrastructure).

[0102] In the implementation example considered, the execution unit containing the WASM code can be pre-deployed, and gateway activation can be triggered dynamically based on system needs. This activation can, for example, be based on an activation request or the application of an activation criterion. Once activated, the gateway enables flexible communication between communicating entities, with remote and on-demand activation. The processing module, once the gateway is activated, handles the communication between the communicating entities through the gateway.

[0103] Such an implementation is particularly well-suited for environments where distributed macro-functions need to interact dynamically, such as in distributed cloud architectures. A typical example is an Open RAN deployment, where it is desirable for RUs (Radio Units), DUs (Distributed Units), and CUs (Centralized Units) to be adaptively interconnected. In such environments, the gateway facilitates the establishment and adjustment of active communications between distributed services and, more specifically, between distinct RUs, DUs, and CUs.

[0104] In all the implementations described above, the gateway can operate in two ways. It can be permanent, meaning that once activated, it remains in place to ensure communication between the communicating entities. Conversely, it can be ephemeral, meaning it is activated and deactivated automatically. This activation or deactivation can also be valid for a specific function of the gateway. For example, the gateway can be scalable, and a particular function of the gateway can be activated as needed, notably based on criteria such as those described below.

[0105] When the gateway is ephemeral, its activation and deactivation can be controlled by the command unit. This action is called gateway failover and can be triggered based on a specific request or one or more criteria.

[0106] These criteria may include: the state of the service or supported macro-function, for example if the load on a domain becomes excessive, if a network failure impacts system performance or if a domain, entity or cluster is functionally evolving, the frequency of service repositioning, especially when RU, DU or CU units are moved over time, an economic parameter, when the activation of a gateway depends on an operating cost deemed acceptable.

[0107] The gateway can operate in several modes, defined according to the entities between which communication is established.

[0108] In the first mode, the gateway is activated to allow communication between the first entity and the second entity.

[0109] In a second mode, the gateway is disabled for communication between the first entity and the second entity.

[0110] The switch between these modes corresponds to the following operations: the transition from the second mode to the first mode corresponds to the activation of the gateway, allowing communication to be established between the first and second entities, and the transition from the first mode to the second mode corresponds to the deactivation of the gateway, thus interrupting communication between the first and second entities.

[0111] The proposed technique also allows for the management of more than two communicating entities. For example, it can be provided that in the second mode, the gateway is deactivated for all communications, with no entity being connected via the gateway, and a third mode can be provided, in which the gateway is activated, but to establish not a communication between the first entity and a second entity, but another communication, for example between the first entity (or the second entity) and a third entity.

[0112] The routing of communications through the gateway can be defined in advance or adjusted dynamically according to the needs of the communication system. It can be based on fixed or variable parameters, for example, adapted in real time according to the availability of service providers, network load, or other operational criteria.

[0113] A complementary approach to gateway failover, which can be used both independently and in conjunction with it, relies on the use of an intra-service routing mechanism to dynamically manage communication routing within the communication system. This approach allows for the organization of traffic flow without systematically requiring an intermediate proxy.

[0114] Reference is now made to the, which represents an example of a flowchart of a gateway activation process in a cloud computing environment between a first communicating entity 1 and a second communicating entity 2, according to one aspect of the proposed technique.

[0115] An illustrative example of a corresponding use case is the deployment of an Open vRAN function in the form of service meshes, where different components, for example radio units (RU), distributed units (DU) and / or centralized units (CU), as examples of communicating entities 1, 2 are hosted on several distributed cloud infrastructures.

[0116] The implementation of this process is organized into logical modules, each defined by a specific function: a module 11 for defining a communication gateway activation rule, a module 12 for verifying a condition for applying the activation rule, a module 13 for activating a communication gateway, a module 14 for executing a service, a module 15 for verifying the establishment of communication between the communicating entities, a module 16 for updating the topology of the communication system, and a module 17 for updating the routing within the communication system.

[0117] This list of modules is indicative and provided for example purposes only.

[0118] Module 11 is responsible for establishing one or more gateway activation rules. These rules define the conditions under which the gateway can be activated to enable communication between the first communicating entity 1 and the second communicating entity 2. These rules may relate, but are not limited to, the communicating entities 1 and 2, the routing between them, the security measures to be implemented, the communication context (regional, national, international), the type of customer (residential / business) for whom communication is potentially established, and the environment (fixed, mobile, mixed). Module 11 transmits the defined rule(s) to Module 12, along with any parameters necessary for their application, such as the identifiers of the communicating entities and / or the criteria to be verified.This verification may include, for example, the assessment of available resources, including the capacity of cloud infrastructures to support communication, and / or the status of communicating entities, ensuring that they are operational and capable of exchanging data and / or compliance with security and orchestration policies.

[0119] Module 12 checks whether the conditions defined by Module 11 are met to activate the gateway. If the conditions are met, Module 12 sends Module 13 a gateway activation instruction containing the information necessary for its deployment (e.g., target location, required configuration). If the conditions are not met, the process can be paused or default behavior can be applied.

[0120] Module 13 is responsible for the actual deployment of the gateway in the cloud environment. Its operation involves several steps.

[0121] Module 13 manages, for example: the placement of the gateway in one or more suitable locations (e.g. in a centralized cloud, in edge computing, or on a private site), and / or the activation of the gateway, and / or the configuration of gateway connection parameters to establish a link between the communicating entities 1, 2.

[0122] Once activated, the gateway is ready to enable communication between entities 1 and 2. Module 13 transmits an activation confirmation and the associated network parameters to module 14, such as the network addresses of entities 1 and / or 2, and possibly the port numbers authorized for this communication. The network parameters depend on the types of communication between the entities and may, alternatively or in addition, correspond to MAC addresses for frames, VLAN numbers in virtual local area networks, or, among other things, label identifiers in the case of a virtual private network.

[0123] Module 14 manages the execution of a service or macro-function that leverages active communication between communicating entities through the gateway.

[0124] This execution may include: the activation of microservices necessary for the exchange of data associated with the activated communication of the gateway between the communicating entities, and / or the launching of specific applications using the gateway to function correctly, and / or the application of one or more processing steps by the processing module on the active communication through the gateway.

[0125] Module 14 informs module 15 that the service(s) using the gateway have been launched and initiates the verification of communication between the communicating entities.

[0126] In parallel, module 14 can also return execution information to module 11, allowing activation rules to be dynamically adapted based on observed needs. For example, if service execution reveals network overload, the rules can be updated to avoid activating too many gateways simultaneously.

[0127] Module 15 verifies whether communication between the first and second entities has been successfully established. This verification can, for example, be implemented by checking the service execution.

[0128] Two scenarios are possible.

[0129] When communication is successfully established (for example, when the service is running correctly), module 15 detects that the communicating entities can indeed exchange data via the gateway. Module 15 then informs module 16 that communication is active and that the system topology should be updated accordingly.

[0130] When communication cannot be established (for example when the service is not running correctly), module 15 can apply default behavior, for example by redirecting traffic differently and / or by signaling an alert and / or by retrying the activation of the gateway with a different configuration than that implemented when activated by logical module 13 or even 14.

[0131] If the failure to establish communication between the communicating entities through the gateway is definitive, then module 15 can, for example, inform module 16 that this communication is inactive, or refrain from informing module 16. The process can then either end here, or be restarted with other conditions defined by module 11.

[0132] When communication between communicating entities is validated and when module 16 is informed, module 16 updates the network topology to reflect the new active connection.

[0133] This includes recording the new connection between entities in the management system databases and notifying control managers (e.g., Kubernetes, Istio) to adapt the organization of services and take this new interconnection into account.

[0134] Module 16 then transmits these updates to module 17 so that the service routing rules can be adjusted accordingly.

[0135] Module 17 adjusts the routing rules so that communication between communicating entities functions appropriately.

[0136] This update may include reconfiguring communication paths in the network, adjusting traffic according to service load and priorities, integrating new connections into overall system management, etc.

[0137] At the end of this step, the process is complete, and communication between the communicating entities is fully operational.

[0138] Reference is now made to Figures 2 and 3, which illustrate a possible example of a communication system architecture suitable, in particular, for implementing the process illustrated in Figure 1. In Figure 2, the architecture is represented from the perspective of a communication system operator.

[0139] The communication system includes a plurality of entities, including in particular a first entity 1 hosted in a first Kubernetes cluster 10 and a second entity 2 hosted, for example, in a second Kubernetes cluster 20. Entities 1 and 2 of the respective clusters 10 and 20 can exchange data within their own cluster, but they cannot communicate directly with entities hosted in other clusters without an intermediate gateway.

[0140] Other implementations are possible. For example, the first entity 1 and the second entity 2 can be hosted in the same Kubernetes cluster. Alternatively, the first entity 1 can be hosted in a Kubernetes 10 cluster, and the second entity 2 can be any entity in the communication system (router, terminal, etc.) and does not necessarily need to be hosted in a Kubernetes cluster.

[0141] The communication system further includes a Web server 6 which contains, and is capable of distributing, WASM executable code 7 designed to be downloaded and executed on an execution unit (in this case a virtual machine 3), as a trusted server, which, once the code has been executed, serves as a communication gateway 4 which manages the routing of data between the communicating entities 1, 2.

[0142] WASM code may include instructions for data transfer and specific processing rules, such as traffic filtering, data encryption or flow regulation to be applied to communications between communicating entities 1, 2.

[0143] In this case, the execution of the WASM 7 code by the virtual machine results in the implementation, by the virtual machine, of a processing module 5 configured to apply these specific processing.

[0144] This means that when gateway 4 receives data from a communicating entity 1 or 2, processing module 5 applies specific rules to this data, for example by compressing it, applying encryption, or checking its validity, and then the processed data is transmitted by the gateway to the other communicating entity.

[0145] Gateway 4 can be configured ephemerally, meaning that it can be activated only when communication between communicating entities 1, 2 is required, and then deactivated to free up resources of the virtual machine or more generally of gateway 4.

[0146] In the, the architecture, for example of type ISTIO, is represented from the point of view of the services implemented in the service meshes 10, 20 hosting the communicating entities 1, 2 and highlights the integration mechanisms of the communication gateway in the environment of the service meshes.

[0147] Each service mesh (or cluster) operates independently and applies its own routing and traffic management rules. By default, ISTIO service meshes do not allow direct communication between entities belonging to separate meshes, which justifies the instantiation of gateway 4 to enable this communication.

[0148] For ISTIO service meshes to recognize the gateway as a valid external connection point, a specific gateway configuration is applied. An "External ServiceEntry" object is assigned to the gateway for each service mesh. This means that, from the perspective of each service mesh, the gateway appears as an accessible external destination, even if it is dynamically instantiated.

[0149] This configuration allows traffic between communicating entities 1 and 2 via gateway 4, bypassing the default restrictions of ISTIO service meshes, and managing communication in a controlled manner, by applying a first set of one or more specific rules (e.g., filtering, encryption, request transformation) on a communication from communicating entity 1 to communicating entity 2 and / or by applying a second set (identical or different from the first set) of one or more specific rules on a communication from communicating entity 2 to communicating entity 1.

[0150] In each service mesh, incoming and outgoing communications pass through an entry and / or exit point, or entry / exit point. When a communication from communicating entity 1 must pass through gateway 4, the data from communicating entity 1 is first sent to an entry / exit point 21 of the service mesh 10, which then redirects it to gateway 4. Similarly, after passing through gateway 4, the data is reintroduced into the second service mesh 20 via an entry / exit point 22, before being transmitted to the second communicating entity 2. Thus, communication between the communicating entities remains compliant with the flow management principles of the service meshes, while allowing for controlled and secure exchange between the two separate meshes.

[0151] Reference is now made to the, which illustrates an example of a connection scenario between communicating entities 1, 2 via a gateway 4.

[0152] In this example, the first communicating entity 1 is hosted in a first service mesh 10, corresponding to a Distributed Unit (DU) of a virtualized telecommunications network. The communicating entity 2 is hosted in a second service mesh 20, corresponding to a Centralized Unit (CU) of the virtualized telecommunications network. Initially, these two meshes are not connected to each other and have no direct link.

[0153] Gateway 4 enables communication between these two entities, ensuring specific processing of the transmitted data.

[0154] Gateway 4 runs on a virtual machine 3, which hosts a web server accessible by a trusted third party. When this trusted third party connects, embedded WASM code is executed locally on virtual machine 3. This WASM code allows for the dynamic configuration of the gateway and the activation of its functionalities. A cascading mechanism for the WASM code can be used: thus, a WASM instance can itself become a web server, hosting another WASM object for the same trusted third party or for a different trusted third party, like Russian nesting dolls.

[0155] In the example of the gateway 4, it does not simply transfer data between communicating entities 1 and 2. It applies a multi-step processing, ensured by three cascading processing modules: an analysis module 51, a verification module 52 and a decision module 53.

[0156] Analysis module 51 examines the headers of packets received from communicating entity 1. It can extract various useful information in the form of metadata, including, for example, routing information and elements for assessing packet validity. In the example above, the analysis module is assumed to extract a digital signature from the headers of packets received from communicating entity 1.

[0157] The verification module 52 checks one or more transmission conditions; for example, the verification module verifies the authenticity of packets by checking their digital signature. This ensures that the received data has not been altered and that it originates from the communicating entity 1 as the legitimate source.

[0158] The decision module 53 makes a decision on the fate of the packets based on the result of the verification of the transmission condition(s), for example based on the result of the signature verification.

[0159] Two possibilities can for example be envisaged: a transmission to the communicating entity 2 when the transmission conditions are met, in this case when the signature is correctly extracted by the analysis module and validated by the verification module, and a rejection or a redirection of the packet when the transmission conditions are not met.

[0160] This example illustrates how one or more processing modules 51, 52, 53 make it possible to ensure strict and secure control of the data exchanged between the communicating entities 1, 2.

[0161] The described mechanism can be generalized to any data transmission between two communicating entities, regardless of the data format or underlying communication mode. Rather than operating solely at the packet level, it can be applied to transmission units of varying sizes, such as frames, continuous data streams, or structured message blocks. Furthermore, this approach is not limited to packet-based communications. It can be adapted to communication systems using other paradigms, such as connection-oriented transmissions, message-mode exchanges, or streaming data streams. In this context, the processing modules operate on the data at different levels of abstraction and according to the specific characteristics of the underlying protocol.The analysis module 51 can extract metadata from headers, as well as from other data structure elements, such as session information, flow identifiers, or cryptographic hashes. The verification module 52 can then ensure the integrity and authenticity of the data by applying controls adapted to the type of transmission (e.g., checking a digital signature, validating a certificate, verifying a session identifier). Finally, the decision module 53 can determine whether the data should be transmitted, blocked, or redirected based on appropriate security and / or compliance criteria.

[0162] The proposed technique can be implemented in a control unit in the form of a single computer device or in the form of a system comprising a plurality of computer devices, each fulfilling specific functions.

[0163] Such a device 30 includes, as illustrated in the figure, the following elements: a processor 31 or processing unit, a memory 32 storing instructions in the form of a computer program, and a communication interface 33.

[0164] Any suitable hardware and / or software may be used for the practical implementation of said device. Generally, although aspects of the proposed technique may be described in this document as a process, device, system, procedure, method, or technique, it should be noted that the proposed technique may also encompass computer memory that can be connected to a processor, which may be connected to a communication interface. This memory stores instructions that, when executed by such a processor, enable the implementation of the processes, devices, systems, procedures, methods, or techniques described in this document.

[0165] The proposed technique can be implemented in different types of systems and devices, depending on the specific needs of a communication environment.

[0166] In one example implementation, the control unit can be directly integrated into a communication terminal. This terminal can be, for example: a user device (UE) in a mobile network (smartphone, tablet, laptop, connected object), a gateway such as a box, a router or infrastructure equipment in a distributed network, or an IoT device operating in a cloud environment or at the network edge.

[0167] In this implementation, the communication terminal plays a central role in managing the gateway, dynamically enabling or disabling it as needed. It can be configured to detect specific conditions that trigger gateway activation (e.g., a change in network topology, a request from a remote service, a load variation). In this implementation, the processing module 5 is executed directly by the terminal, allowing for local adaptation of communications without requiring external infrastructure.

[0168] Advantages of this implementation example include increased terminal autonomy, which decides and executes the activation and processing rules for communication itself, as well as reduced latency, since communication management does not depend on a centralized server.

[0169] In another embodiment, the communication terminal does not directly contain the control unit, but it is configured to interact with a remote control unit. To do this, the terminal includes a communication interface that allows it to send a gateway activation request and / or a gateway activation criterion to an external control unit. This request can be manual (triggered by a user or an application) or automatic (e.g., detection of an inter-mesh communication requirement). In this embodiment, the communication terminal acts as a trigger: it does not directly manage the gateway, but transmits requests to a control unit, which then controls the gateway activation and the implementation of the processing module.

[0170] In this example implementation, the control unit can be hosted on a cloud server, a virtual machine, or a network controller, and it can manage multiple terminals simultaneously.

[0171] Advantages of this implementation example include centralized and orchestrated control unit management, as well as improved compatibility with multi-entity systems, where multiple terminals may require gateway activation without themselves owning the control unit.

[0172] In another implementation example, the command unit is distributed across several entities within the communication system. One part of the command unit can be executed within a local entity (e.g., a terminal, an edge server), enabling rapid decision-making regarding gateway activation. A second part can be hosted on a centralized orchestrator (e.g., a network controller, a Kubernetes server, a service mesh manager), which coordinates all the distributed command units.

[0173] In this implementation example, several entities contribute to the management of the gateway, depending on their position in the network. The terminal can make an initial local decision, and global orchestration is managed by a centralized infrastructure to ensure consistency across the entire system.

[0174] Advantages of this implementation include those inherent to rapid local activation and those inherent to centralized management. Furthermore, the resilience of the control unit is improved because local entities can continue to operate even if the central entity fails.

[0175] Similar to the control unit, the execution unit can be implemented in different types of devices within the communication system.

[0176] In one embodiment, the execution unit can be integrated directly into a communication terminal. Such a terminal can thus host the gateway 4 and / or the processing module 5.

[0177] In another example of implementation, the execution unit can be hosted in a virtual machine or server.

[0178] In another example of implementation, the execution unit is distributed among several devices within the communication system.

Claims

Control unit adapted to intervene on a functional processing of an active communication between a first entity (1) and a second entity (2), the control unit being configured to, on request and / or according to a criterion, activate (13), a gateway (4) for the active communication between the first entity and the second entity, and to control the functional processing, by a processing module (5) associated with the gateway, of the active communication through the gateway. Control unit according to claim 1, wherein the activation of the gateway includes issuing an instruction for the purpose of distributing executable code and executing the distributed code in a sandbox environment. Control unit according to claim 2, wherein the executable code includes instructions relating to the processing of a communication between the first entity and the second entity through the gateway. Control unit according to claim 2 or 3, wherein the executable code includes instructions relating to the integration of a third entity as a connection point in a communication between the first entity and the second entity through the gateway. Control unit according to any one of claims 1 to 4, configured to switch, on request and / or according to a criterion, the gateway between: a first mode where the gateway is activated for active communication between the first entity and the second entity, and a second mode where the gateway is deactivated for active communication between the first entity and the second entity. Control unit according to claim 5, wherein, in the second mode, the gateway enables communication between the first entity and a third entity. Control unit according to any one of claims 1 to 6, wherein the processing includes checking a data transmission condition between the first entity and the second entity. Control unit according to claim 7, wherein the processing includes, when the transmission condition is not met, a rejection or a redirection of the data. Execution unit configured to activate (13), on an instruction received from a control unit, a gateway (4) for active communication between a first entity and a second entity, and to, upon this activation, execute by a processing module (5) associated with the gateway a functional processing of the active communication through the gateway. A method implemented by a suitable control unit to intervene on a functional processing of an active communication between a first entity (1) and a second entity (2), the method comprising, on request and / or according to a criterion, an activation (13) of a gateway (4) for the active communication between the first entity and the second entity, and a control of the functional processing, by a processing module (5) associated with the gateway, of the active communication through the gateway. A method implemented by an execution unit, the method comprising: activating (13), on an instruction received from a control unit, a gateway (4) for active communication between a first entity and a second entity, and for the purpose of this activation, executing by a processing module associated with the gateway, a functional processing (5) of the active communication through the gateway. Computer program comprising instructions for implementing the method according to claim 10 or 11 when this program is executed by a processor. Communication terminal comprising a control unit according to any one of claims 1 to 8 and / or an execution unit according to claim 9. Communication terminal comprising: a communication interface with a control unit according to any one of claims 1 to 8 and / or with an execution unit according to claim 9, the communication interface being configured to transmit and / or receive a gateway activation request and / or a gateway activation criterion.

Images