WO2025125478A1 - Procédés de supervision, de gestion d'un service, de gestion d'un accès à une tranche réseau et d'accès à un service, et dispositifs configurés pour mettre en oeuvre ces procédés - Google Patents

Procédés de supervision, de gestion d'un service, de gestion d'un accès à une tranche réseau et d'accès à un service, et dispositifs configurés pour mettre en oeuvre ces procédés Download PDF

Info

Publication number
WO2025125478A1
WO2025125478A1 PCT/EP2024/086006 EP2024086006W WO2025125478A1 WO 2025125478 A1 WO2025125478 A1 WO 2025125478A1 EP 2024086006 W EP2024086006 W EP 2024086006W WO 2025125478 A1 WO2025125478 A1 WO 2025125478A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
network
application server
access
communication device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
PCT/EP2024/086006
Other languages
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Publication of WO2025125478A1 publication Critical patent/WO2025125478A1/fr
Pending legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements

Definitions

  • the invention belongs to the general field of telecommunications.
  • the invention proposes a mechanism aimed at facilitating the achievement of this objective by network operators and service providers.
  • the invention more particularly proposes a disruptive approach advocating collaboration between all or some of the actors involved in the provision of a service via a network, namely between the communication device(s) accessing the service, the service infrastructure and the network.
  • the invention introduces coordination between the network, the service infrastructure and the communication devices to jointly contribute to controlling or even reducing the environmental and/or energy impact attributed to a service.
  • the invention proposes a method of supervision by a network controller of a network comprising: a step of estimating at least one indicator representative of an environmental and/or energy impact attributed to a service provided via the network; if said at least one estimated indicator does not meet a given compliance criterion, a step of notifying an application server associated with the service of this non-compliance with said compliance criterion by said at least one indicator.
  • the invention relates to a network controller of a network comprising: an estimation module, configured to estimate at least one indicator representative of an environmental and/or energy impact attributed to a service provided via the network; and a notification module, activated if said at least one estimated indicator does not meet a given conformity criterion, and configured to notify an application server associated with the service of the non-compliance with said conformity criterion by said at least one indicator.
  • the invention applies to any type of indicator as long as it is able to provide information on the environmental and/or energy impact attributed to a service.
  • This may be, for example, a carbon footprint, a flow indicator such as a measurement of a contribution to the greenhouse effect, energy consumption, energy supply cost, etc.
  • the invention proposes a method for managing a service provided via at least one network by an application server associated with said service, this method comprising: a step of receiving, from a network controller of said network, a notification of non-compliance with a given conformity criterion by at least one indicator, estimated by the network controller, representative of an environmental and/or energy impact attributed to said service; and a step of triggering at least one measure for managing said environmental and/or energy impact, said management measure relating to all or part of the traffic relating to said service.
  • the invention relates to an application server configured to manage a service provided via at least one network
  • said application server comprising: a reception module, configured to receive from a network controller of said network, a notification of a non-compliance with a given conformity criterion by at least one indicator, estimated by the network controller, representative of an environmental and/or energy impact attributed to said service; and a trigger module, configured to trigger at least one management measure of said environmental and/or energy impact, said management measure relating to all or part of the traffic relating to said service.
  • the invention relates to a method for accessing, by a communication device, a service provided via a network, this method comprising: a step of sending a request for access to the service to an application server associated with said service; and a step of receiving a notification from the application server informing said communication device of an application to the traffic relating to said service coming from or going to said communication device of at least one measure for managing an environmental and/or energy impact attributed to the service, following a notification, received by said application server from a network controller of the network, of a non-compliance with a given conformity criterion by at least one indicator representative of said environmental and/or energy impact estimated by the network controller.
  • the invention relates to a communication device comprising: a sending module, configured to send to an application server associated with a service provided via a network, a request for access to said service; and a receiving module, configured to receive a notification from the application server informing said communication device of an application to the traffic relating to said service coming from or going to said communication device of at least one measure for managing an environmental and/or energy impact attributed to the service, following a notification, received by said application server from a network controller of the network, of a non-compliance with a given conformity criterion by at least one indicator, estimated by the network controller, representative of said environmental and/or energy impact.
  • the invention relates to a method for managing, by an entity of a network, access to a network slice supported by the network, said method comprising: a step of receiving, from a communication device, a request for access to a given network slice supported by the network, said network slice being shared between several communication devices accessing a service provided via the network, following a notification received by an application server associated with said service from a network controller of the network of a non-compliance with a given conformity criterion by at least one indicator, estimated by the network controller, representative of an environmental and/or energy impact attributed to the service; a step of verifying, with the application server associated with said service, that said communication device is authorized to access said shared given network slice; and where appropriate, a step of triggering a connection of said communication device to said shared given network slice.
  • the invention relates to an entity of a network, configured to manage access to a network slice supported by the network, said entity comprising: a reception module, configured to receive from a communication device, a request for access to a given network slice supported by the network, this network slice being shared between several communication devices accessing a service provided via the network, following a notification, received by an application server associated with said service from a network controller of the network, of a non-compliance with a given conformity criterion by at least one indicator, estimated by the network controller, representative of said environmental and/or energy impact attributed to the service; a verification module, configured to verify with the application server associated with said service, that said communication device is authorized to access said shared given network slice; and a trigger module activated if necessary and configured to trigger a connection of said communication device to said shared given network slice.
  • a reception module configured to receive from a communication device, a request for access to a given network slice supported by the network, this network slice being shared between several communication devices accessing a service provided via
  • the invention also relates to a system comprising at least one network controller and one entity of a network, an application server associated with a service provided via this network, and at least one communication device, in accordance with the invention.
  • a controller network of a network through which a service is provided monitors at least one indicator representative of the environmental and/or energy impact attributed to the service, for example the carbon footprint attributed to this service. If the indicator(s) in question do not meet a given compliance criterion (for example, they do not comply with reference values defined for this service, typically expected, desired or authorized values for this service), an application server associated with the service is informed so that one or more adjustment actions are triggered ⁇ ). Such adjustment actions constitute measures for managing the environmental and/or energy impact attributed to the service; they aim, for example, to limit, or even neutralize, this environmental and/or energy impact attributed to the service.
  • the notification of the application server may result, for example, from a subscription of the application server to the network controller so that the application server is informed by the network controller of various events relating to the environmental/energy impact of the service (for example, the carbon footprint attributed to the service exceeds a given threshold).
  • the management measure(s) may be triggered, for example, by the application server or by the network controller itself in a coordinated manner with the application server.
  • the estimation step of the supervision method comprises a reception from at least one probe deployed in the network of at least one piece of information reflecting an environmental and/or energy impact of at least one communication relating to said service established from or to a server involved in a provision of said service.
  • the compliance criterion(s) to which the estimated indicators are compared may take different forms depending on the indicators considered and the desired goal (preventive or curative measure following a degradation of the service).
  • a compliance criterion may be the crossing of a critical threshold (minimum or maximum depending on the indicator considered) not to be exceeded or an intermediate threshold (for example a percentage of the critical threshold) before reaching such a critical threshold in order to trigger one or more preventive actions to anticipate a degradation of the service.
  • Another criterion may be the evolution of the indicator over time.
  • management measures that can be triggered in response to the detected non-compliance. These management measures aim for example to set up a collaboration between the network, the service infrastructure and/or the communication devices in order to limit or neutralize the environmental and/or energy impact attributed to the service and thus ensure that the traffic from and/or to the communication devices can be routed in the best conditions for digital sobriety.
  • management measure leading to an agglomeration of several service platforms in particular to reduce their number
  • resulting in a modification of the conformity criterion considered for the service for example by an increase in the authorized quota for the carbon footprint of the service, or a postponement of this quota).
  • said at least one management measure can be chosen from at least: a use of an encoding of the data relating to said service having a lower contribution to the environmental and/or energy impact attributed to said service than a current encoding; a restriction of access to said service via said network; a (temporal) scheduling of access to said service by several communication devices; a shared use of at least one given resource of the network by several communication devices during access to said service by said communication devices; and a marking of traffic relating to said service to store it in at least one queue.
  • these management measures can be chosen and/or configured according to the estimated values of the indicators considered, which makes it possible to act in a dynamic, targeted and adapted manner. They can be applied to all or part of the traffic associated with the service.
  • the management method implemented by the application server comprises: a step of receiving a request for access to the service from a communication device; if said communication device is concerned by a said management measure, a step of applying this management measure to the traffic relating to the service coming from or going to said communication device.
  • One of the management measures that can be considered is programmable scheduling, making it possible to organize access to the service over time by a plurality of communication devices.
  • the management method implemented by the application server comprises, following a request for access to the service by at least one communication device, a step of selecting, for said at least one communication device, a time slot allocated to said plurality of communication devices for access to the service.
  • the application server determines when each communication device requesting access to the service will actually access the service, and thus be able to transmit or receive data relating to this service.
  • Several communication devices having requested access to the service in a given time interval may be allocated the same time slot to access the service.
  • a communication device may have its access to the service delayed depending on the scheduling that has been done of the use of a resource to provide the service, that is, time slots that have been allocated for this service provision. Note that we are interested here in the organization of access to the service by users of communication devices (for example, access to streaming video content), and not strictly speaking in the scheduling of data packets associated with a user on network resources.
  • Such programmable scheduling of access to the service has a preferred application when the communication devices share the same resource to access a service, that is to say in a context where instead of providing the service to a communication device via a dedicated resource, this resource is shared to provide the service to several communication devices.
  • the shared use of resources by several communication devices combined with programmable scheduling contributes not only to better managing the environmental and/or energy impact of the network, but also to improving the use of network resources as well as the efficiency of the traffic routing policy implemented in the network.
  • Such an approach makes it possible to take into account energy and environmental budgets per service and per user.
  • This promising approach can also be applied in different contexts: communications between data centers, dynamic management of flows (or workflows) of a company, adjustment of resources allowing access to services and event content with an adequate level of quality, etc.
  • the supervision method further comprises: a step of receiving, from the application server, a notification of shared use by several communication devices of at least one given resource of the network during access to said service by the communication devices; and a step of configuring at least one entity of the network to allow this shared use.
  • Such a network entity is, for example, a network edge node that is configured with new classification rules to take into account the shared use of resources.
  • Different network resources can be shared in the context of the invention.
  • a streaming video service it is possible to envisage using a multicast tree deployed in the network (or even in a slice supported by the network) to send the same video content to several communication devices via the network.
  • a multicast tree deployed in the network or even in a slice supported by the network
  • said at least one shared resource comprises a given network slice supported by the network and said notification received from the application server comprises information representative of a scheduling of access to the service by communication devices via said network slice.
  • This embodiment therefore proposes, in order to limit the environmental and/or energy impact- service management, to use in a shared manner by a plurality of communication devices one (or more) network slice(s) supported by the network for access to the service, access to the network slice in question being organized according to a particular schedule duly chosen by the application server.
  • a network slice can be defined as a virtual private network (VPN) deployed on a fixed or mobile network infrastructure or both, and aimed at ensuring a set of specific performances. It can be seen as a logical network offering connectivity to its users and having its own characteristics in terms of capacity (bandwidth), quality of service (latency, throughput, unidirectional transit time, jitter (or inter-packet delay variation, etc.) and security (for example, preserving the confidentiality of information transmitted within a virtual private network through the use of encryption techniques).
  • bandwidth bandwidth
  • quality of service latency, throughput, unidirectional transit time, jitter (or inter-packet delay variation, etc.
  • security for example, preserving the confidentiality of information transmitted within a virtual private network through the use of encryption techniques.
  • This embodiment can be easily implemented via collaboration with the network controller and/or the communication devices.
  • the management method implemented by the application server may comprise at least one step from: a step of notifying said network controller of the shared use of said given network slice by said communication devices according to said determined scheduling; and a step of notifying said communication devices of said given network slice to be used in a shared manner by said communication devices when accessing the service and said determined scheduling which must be applied.
  • the method may comprise: a step of sending to a network entity, a request for access to said shared given network slice; and following the connection of said communication device to said shared given network slice, a step of accessing said service via said shared given network slice.
  • the management method implemented by the application server may comprise a step of receiving from a network entity a request to verify that a communication device is authorized to access said given network slice.
  • the network controller if after having notified the application server, the network controller detects that no measure for managing the environmental and/or energy impact attributed to the service has been implemented by the application server, it can trigger such management measures itself.
  • the supervision method comprises, in the absence at the end of a determined period of triggering of at least one environmental and/or energy impact management measure by the application server following its notification, a step of activating in said network, for all or part of the traffic relating to said service, at least one processing in response to non-compliance with the conformity criterion by the indicator representative of the environmental and/or energy impact attributed to said service.
  • Such processing may include, for example, a switch of all or part of the traffic relating to said service passing via the network to a network slice providing a degraded level of service compared to an expected level of service for said service, for example a quality level best suited to the conditions of access to the service, also called “Best effort” in English.
  • the supervision, management and access methods are implemented by a computer.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a network controller of a network in accordance with the invention and comprising instructions adapted to the implementation of a supervision method as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in an application server in accordance with the invention and comprising instructions adapted to the implementation of a method for managing a service as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in an entity of a network in accordance with the invention and comprising instructions adapted to the implementation of a method for managing access to a network slice as described above.
  • the invention also relates to a computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a communication device in accordance with the invention and comprising instructions adapted to the implementation of a method of accessing a service as described above.
  • Each of these programs may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable form.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of a computer program as mentioned above.
  • the information or recording medium may be any entity or device capable of storing the programs.
  • the medium may comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording means, for example a hard drive, or flash memory.
  • the information or recording medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio link, by wireless optical link or by other means.
  • the program according to the invention can in particular be downloaded from an Internet type network.
  • the information or recording medium may be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the methods of managing access, managing a service, access and supervision according to the invention.
  • Figure 1 represents, in its environment, a system in accordance with the invention, in a particular embodiment
  • Figure 2 schematically represents the hardware architecture of a computer capable of hosting a network controller, an application server, a management entity or a communication device according to the invention belonging to the system of Figure 1;
  • Figure 3 represents in the form of a flowchart, the main steps of a supervision method according to the invention as it is implemented by the network controller of the system of Figure 1, in a particular embodiment;
  • Figure 4 represents in the form of a flowchart, the main steps of a method for managing access to a service according to the invention as it is implemented by the application server of the system of Figure 1, in a particular embodiment;
  • Figure 5 represents in the form of a flowchart, the main steps of a network slice management method according to the invention as implemented by the management entity of the system of Figure 1, in a particular embodiment;
  • Figure 6 represents in the form of a flowchart, the main steps of a method of accessing a service according to the invention as it is implemented by a communication device of the system of Figure 1 in a particular embodiment;
  • Figure 7 represents an example of the format of a COSI NUSJDP option that can be used within the framework of the invention.
  • Figure 1 represents, in its environment, a system 1 according to the invention, in a particular embodiment, the system 1 being configured to implement a collaborative mechanism aimed at controlling (managing), and possibly reducing (or even neutralize) the environmental and/or energy impact of a service S provided via a NW communication network.
  • the communication network NW supports a plurality of network slices SL1, SL2,..., SLK, where K denotes an integer greater than 1, which can be used to aggregate traffic relating to one or more services (i.e. sent to or received from one or more services).
  • Each network slice may involve one or more service functions (or "Service Functions” in English), also called network functions (or "Network Functions” in English).
  • service/network functions are for example base station functions or gNB (for "gNodeB” in English), user plane functions or UPF (for "User Plane Function” in English), traffic marking, classification and scheduling functions, etc.
  • the same service/network function may be provided by one or more service instances (or "Service Function Instances” in English) or network function instances.
  • Service Function Chains (SFCs) can be set up to facilitate the routing of traffic of different types and with different profiles for the purposes of the implementation (i.e. engineering and deployment) of a network slice or within a network slice.
  • the NW network is for example a 5G mobile network as defined by the 3GPR I standards. It can be segmented into several distinct (sub-) networks (also referred to as “network segments”) making up as many distinct domains.
  • the NW network can be composed of a radio access network (or RAN for “Radio Access Network” in English), a core network (or CN for “Core Network” in English) and a transport network (or TN for “Transport Network” in English) ensuring connectivity within and between the core network and the radio access network.
  • Each of the domains supports network slices whose engineering and operation are characteristic of the domain. For example, a slice deployed on a 5G mobile core network uses traffic processing and operating functions characteristic of a 5G mobile core network.
  • Network slices supported by the NW network may extend over one or more domains (and thus be made up of several “local” network slices deployed in the different domains; this is referred to as “multi-domain” network slices or “stitched slices” or “hierarchical slices” in English).
  • multi-domain network slices or “stitched slices” or “hierarchical slices” in English The way of designing and deploying network slices to offer services is known per se and is not described in detail here.
  • the system 1 is configured to control the environmental and/or energy impact of a service S provided via the NW network.
  • it comprises, in the embodiment described here, at least: a network controller 2 of the NW network and a network slice management entity 3 of the NW network, in accordance with the invention; an application server 4 (or AS for “Application Server” in English), associated with the service S, in accordance with the invention; and at least one communication device 5, in accordance with the invention, connected to the network NW and capable of accessing the service S via the network NW.
  • the invention applies to any type of service S (streaming video, virtual or augmented reality, videoconferencing, etc.).
  • the service S is a streaming video service provided by a service provider separate from the operator of the network NW
  • the application server 4 is a remote server located outside the network NW.
  • the application server 4 associated with the service S is not necessarily the server that strictly speaking provides the service S; it can be any application server or service instance belonging to the service infrastructure providing the service S.
  • the provider of the service S is a service provider based on network slices or SSP (for “Slice Service Provider” in English).
  • the communication device 5 negotiated, when subscribing to the service S with the SSP, the network slice(s) that it is likely to use to send or receive traffic associated with the service S via the network NW.
  • the type of each network slice was also negotiated between the communication device 5 and the network NW, in a manner known per se.
  • the communication device 5 is a user equipment (or UE for “User Equipment” in English) such as a smartphone, a laptop, a digital tablet, etc.
  • UE User Equipment
  • the invention easily applies to other communication devices 5, fixed or mobile, software or hardware, etc., such as for example a service instance, a home gateway or CPE (for “Customer Premises Equipment” in English).
  • the network controller 2, the management entity 3, the application server 4 and the communication device 5 each have the hardware architecture of a computer 6 as illustrated in FIG. 2.
  • This hardware architecture notably comprises a processor PROC, a random access memory MEM, a read only memory ROM, a non-volatile memory NVM, and communication means COM.
  • the non-volatile memory NVM constitutes a recording medium in accordance with the invention, readable by the processor PROC and on which a program in accordance with the invention is recorded.
  • This program noted PROG-2 when the hardware architecture of the computer 6 is that of a network controller according to the invention such as the network controller 2, is recorded in the non-volatile memory NVM and comprises instructions defining the main steps of a supervision method according to the invention. It more specifically defines the functional modules of the network controller 2 (represented in FIG. 1), which rely on and/or control all or part of the PROC, MEM, ROM, NVM, and COM elements of the computer 6 mentioned previously.
  • These functional modules comprise, in the example of the service S: an estimation module 2A, configured to estimate at least one indicator I ND representative of an environmental and/or energy impact attributed to the service S provided via the network NW; and a notification module 2B, activated if said at least one indicator I ND estimated if said at least one estimated indicator does not meet a given CRI T conformity criterion (different criteria can be considered depending on the indicators considered), and configured to notify the application server 4 associated with the service S of this non-compliance.
  • an estimation module 2A configured to estimate at least one indicator I ND representative of an environmental and/or energy impact attributed to the service S provided via the network NW
  • a notification module 2B activated if said at least one indicator I ND estimated if said at least one estimated indicator does not meet a given CRI T conformity criterion (different criteria can be considered depending on the indicators considered), and configured to notify the application server 4 associated with the service S of this non-compliance.
  • the network controller 2 also comprises the following functional modules, defined by the computer program PROG-2: a trigger module 2C, configured here to itself trigger a management measure for the environmental and/or energy impact attributed to the service (also called an “adjustment action”), and more precisely a default adjustment action ACT-DER in the absence of triggering by the application server 4 of such a management measure following the notification received from the notification module 2B indicating the non-compliance by the indicator I ND of the criterion CRI T.
  • This default adjustment action ACT-DEF is a processing triggered in response to the non-compliance with the criterion CRI T and which aims for example to reduce or neutralize the environmental and/or energy impact attributed to the service.
  • ACT-DEF An example of a default adjustment action ACT-DEF is given for illustrative purposes later; and a 2D module for configuring entities of the network NW to enable the implementation of management measures (by default or triggered by the application server 4) of the environmental and/or energy impact of the service S in the network.
  • ACT-DEF An example of a default adjustment action ACT-DEF is given for illustrative purposes later; and a 2D module for configuring entities of the network NW to enable the implementation of management measures (by default or triggered by the application server 4) of the environmental and/or energy impact of the service S in the network.
  • the program according to the invention recorded in the non-volatile memory NVM of the computer 6 is the program PROG-4 which comprises instructions defining the main steps of a method for managing a service according to the invention.
  • This program PROG-4 defines the functional modules of the application server 4 (represented in FIG. 1), which rely on and/or control all or part of the PROC, MEM, ROM, NVM, and COM elements of the computer 6 mentioned previously.
  • These functional modules comprise, in the example of the service S: a reception module 4A, configured to receive, if necessary, from the network controller 2, a notification of non-compliance with the conformity criterion CRI T by said at least one indicator I ND; and a trigger module 4B, configured to trigger at least one ACT management measure of the environmental and/or energy impact attributed to the service S, this ACT management measure relating to all or part of the traffic relating to the service S.
  • Examples of ACT management measures that can be triggered include: o use of an encoding of the data relating to the service S having a lower contribution to the environmental and/or energy impact attributed to the service S than an encoding commonly used by the communication devices accessing this service S and/or by the application server providing the service S; o restriction of access to the service S via the NW network; o scheduling of access to the service S by several communication devices; o shared use of at least one given resource of the NW network by several communication devices when accessing the service S by these communication devices; o marking of traffic relating to the service to store it in at least one queue; o etc.
  • shared use of a resource we are referring here to a mode in which this resource is not exclusively dedicated to providing the service to a communication device but is used to provide this service simultaneously to several communication devices which wish to access the service in a given interval. This contrasts here with a mode in which the resource in question is used, following a request for access to the service by a communication device, exclusively for the flow of traffic of this service to this communication device (the resource is dedicated to this communication device), independently of the other communication devices wishing to access the same service.
  • a multicast transmission mode illustrates a shared use of a resource to transmit a data stream, as opposed to a unicast transmission mode dedicated to a given user.
  • management measures can of course be envisaged as a variant, typically measures to limit or neutralize the environmental and/or energy impact attributed to the service S.
  • a management measure can consist of modifying the CRI T conformity criterion considered (if this criterion is a quota to be respected, it is possible, for example, to increase this quota or to postpone it).
  • the trigger module 4B can trigger a combination of the aforementioned management measures, as described in more detail later.
  • a shared use of a network slice supported by the network NW is considered combined with a scheduling mechanism (called programmable) organizing this shared use between the communication devices concerned.
  • the application server 4 also comprises the following functional modules, defined by the computer program PROG-4: a notification module 4C, configured to notify (i.e. inform) the network controller 2 and/or the communication devices accessing the service of the management measure(s) triggered by its trigger module 4B; a verification module 4D, configured to perform various checks upon request from an entity of the network NW (for example from the management entity 3); and a provision module 4E, configured to provide the service S via the network NW to the communication devices (including the communication device 5) connected to this network NW.
  • a notification module 4C configured to notify (i.e. inform) the network controller 2 and/or the communication devices accessing the service of the management measure(s) triggered by its trigger module 4B
  • a verification module 4D configured to perform various checks upon request from an entity of the network NW (for example from the management entity 3)
  • a provision module 4E configured to provide the service S via the network NW to the communication devices (including the communication device 5) connected to this network NW.
  • Wing et al published by the I ETE and entitled “Port Control Protocol (PCP)”, April 2013, is particularly advantageous because it helps to save the energy consumption of the devices that use it by allowing them to avoid sending “keep-alive” messages (for example the consumption of the batteries of such devices if necessary), and avoids unnecessarily using network resources.
  • modules 4A, 4C and 4D of the application server 4 rely on or can be integrated into this PCR server
  • modules 4A to 4E of the application server 4 are described in more detail later with reference to FIG. 4 describing the main steps of a method for managing a service according to the invention.
  • the implementation by the application server 4 of certain measures for managing the environmental and/or energy impact attributed to the service S relies on the management entity 3 of the network NW.
  • the hardware architecture of the computer 6 is that of a management entity in accordance with the invention such as the management entity 3
  • the program in accordance with the invention recorded in the non-volatile memory NVM of the computer 6 is the program PROG-3 which comprises instructions defining the main steps of a method for managing access to a network slice according to the invention.
  • This PROG-3 program defines the functional modules of the management entity 3 (represented in FIG.
  • a reception module 3A configured to receive from a communication device such as the communication device 5, a request for access to a given network slice among the network slices SL1, ..., SLK supported by the network NW, this network slice noted SLopt being shared between several communication devices accessing the service S provided via the network NW in order to adjust the environmental and/or energy impact attributed to the service S following a notification, received by the application server 4 of the network controller 2, of a non-compliance with the CRIT conformity criterion by said at least one indicator I ND representative of the environmental and/or energy impact attributed to the service S; a verification module 3B, configured to verify with the application server 4 associated with the service S, that said communication device in question is authorized to access the shared SLopt network slice; and a trigger module 3C activated where appropriate and configured to trigger
  • modules 3A to 3C of the management entity 3 are described in more detail later with reference to FIG. 5 describing the main steps of a method for managing access to a network slice according to the invention.
  • the program according to the invention recorded in the non-volatile memory NVM of the computer 6 is the program PROG-5 which comprises instructions defining the main steps of a method of accessing a service according to the invention.
  • This program PROG-5 defines the functional modules of the communication device 5 (represented on the figure 1), which rely on and/or control all or part of the PROC, MEM, ROM, NVM, and COM elements of the computer 6 mentioned previously.
  • These functional modules comprise, in the example of the service S: a sending module 5A, configured to send to the application server 4 a request for access to the service S; and a receiving module 5B, configured to receive a notification from the application server 4 informing the communication device 5 of an application to the traffic relating to the service S coming from or going to the communication device 5 of at least one management measure of an environmental and/or energy impact attributed to the service S, this management measure following a notification received by the application server 4 from the network controller 2 indicating to it the non-compliance by said at least one indicator I ND of the conformity criterion CRI T.
  • modules 5A and 5B of the communication device 5 are described in more detail later with reference to FIG. 6 describing the main steps of a method of accessing a service according to the invention.
  • figure 3 represents the main steps of a supervision method according to the invention as they are implemented by the network controller 2
  • figure 4 represents the main steps of a method for managing a service according to the invention as they are implemented by the application server 4
  • figure 5 represents the main steps of a method for managing access to a network slice according to the invention as they are implemented by the management entity 3
  • figure 6 represents the main steps of a method access to a service according to the invention as implemented by the communication device 5, in a particular embodiment.
  • the invention can of course be considered in other contexts, as mentioned above, and can be applied to control the energy impact of the service S, or its environmental impact and its energy impact. No limitation is attached to the nature or number of indicators making it possible to measure this impact. Thus, in addition to the carbon footprint, one can consider as indicators, an energy consumption, an energy supply cost, a traffic volume indicator, an environmental indicator (for example the temperature of network equipment), a description of one or more energy sources used (for example, batteries, a nuclear power plant, an inverter), a deployment sustainability factor (or DSF for “Deployment Sustainability Factor” in English), etc.
  • the network controller 2 and the application server 4 dynamically negotiate the implementation of the COSI NUS procedure for the service S and the network NW, for example via a dedicated application programming interface or API (for “Application Programming Interface” in English), called here COSI NUS API.
  • COSI NUS API a dedicated application programming interface or API (for “Application Programming Interface” in English), called here COSI NUS API.
  • the network controller 2 and the application server 4 use, for example, the dynamic negotiation protocol CPNP (for “Connectivity Provisioning Negotiation Protocol”), described in the document RFC 8921 by M.
  • CPNP for “Connectivity Provisioning Negotiation Protocol”
  • the application server 4 sends in particular to the network controller 2, via the COSI NUS API, a subscription message to be able to benefit from the COSI NUS procedure for the service S.
  • This subscription message contains at least one IP address (and possibly a port number, a domain name, etc.) making it possible to contact (and thus notify) the application server 4.
  • this IP address (and where appropriate the port number) can be coded in a “Contact_Locator” field of a PCR subscription message.
  • the network controller 2 accepts the subscription of the application server 4 and sends it via the COSI NUS API an identifier, for example noted AS4_id, allocated by the NW network (for example by the network controller 2) making it possible to identify the application server 4 unambiguously (i.e. unambiguously) at the level of the NW network during the COSI NUS procedure.
  • the network controller 2 also provides the application server 4 here with a range of IP addresses (IPv4 and/or IPv6) or prefixes of the NW network intended to be used by the communication devices when they access the service S.
  • the identifier AS4_id is generated by the application server 4 itself and provided to the network controller 2 in its subscription message.
  • the application server 4 should implement a procedure to ensure that the identifier AS4_id is globally unique on the plurality of networks (including the network NW) via which the service S is likely to be provided.
  • the AS4_id identifier may be generated by a third-party entity (for example, the IANA or “Internet Assigned Numbers Authority”) and provided by this third-party entity to the network controller 2 and/or to the AS application server 4.
  • a third-party entity for example, the IANA or “Internet Assigned Numbers Authority”
  • the information exchanged between the network controller 2 and the application server 4 during the negotiation/subscription phase is recorded by the latter, for example for the network controller 2 in a table named AS_COSI NUS_SUBSCRI - BERS stored in the NW network (so as to be accessible by network entities participating in the COSI NUS procedure such as in particular the management entity 3), and for the application server 4 in a table named NTW_COSI NUS_SUB ⁇ RI PTIONS, stored locally in its NVM memory.
  • this negotiation/subscription phase between the network controller 2 and the application server 4 can be repeated between the network controller 2 and other application servers associated for example with services other than the service S, and/or between the application server 4 and other network controllers of networks other than the network NW via which the service S is likely to be provided.
  • AS_COSI- NUS_SUB ⁇ RI BERS table maintained by the network controller 2 groups together all the information exchanged with the application servers (including the application server 4) having subscribed to the COSI NUS procedure with the network controller 2 for the services with which they are associated and which are provided via the NW network
  • the NTW COSI- NUS_SUBSCRI PTI ONS table maintained by the application server 4 groups together all the information exchanged with the network controllers of the networks (including the network controller 2 of the NW network) with which the application server 4 has subscribed to the COSI NUS procedure for the service S.
  • the network operator NW (via the network controller 2 or another network entity) sets up or configures filters (making it possible to identify the traffic associated with the service S) and probes deployed in the network NW to collect information reflecting the environmental and/or energy impact of the service S.
  • the filters relate, for example, to IP addresses of the different service instances of the application server 4 involved in providing the service S; these IP addresses are, for example, communicated by the application server 4 to the network controller 2 during the negotiation/subscription phase.
  • the information collected by the probes deployed in the network NW reflects the carbon consumption of all communications established from or to the service instances of the application server(s) involved in providing the service S.
  • the application server 4 although being associated with the service S, is not necessarily directly involved in providing it. However, for the sake of simplification here, it is assumed that the application server 4 not only manages access to the service S but also provides it and is the only application service involved in this provision.
  • the information reflecting the environmental and/or energy impact of the service S collected in particular by the probes and in application of the filters provided is communicated to the network controller 2 (step E20), which then aggregates them to estimate at least one indicator I ND representative of the environmental and/or energy impact of the service S (step E30).
  • the network controller 2 can use, for example, to obtain this information from the probes, a protocol known as NETCONF or I PFIX.
  • the obtaining and aggregation by the network controller 2 (via its estimation module 2A) of the information collected by the probes reflecting the environmental and/or energy impact of the service S can take place continuously or quasi-continuously, or at regular frequency, etc.
  • the network controller 2 estimates as indicator I ND the carbon footprint attributed to the service S.
  • the network controller 2 uses for this purpose, for example, the known method called LCA (for “Life-Cycle Assessment” in English) or a simplified LCA method as described for example in the article by M. Ficher et al. entitled “Assessing the carbon footprint of the data transmission on a backbone network”, 24th Conference on Innovation in Clouds, Internet and Networks ( I Cl N 2021 ), 2021 .
  • the network controller 2 can estimate a plurality of indicators I ND reflecting as a whole the environmental and/or energy impact of the service S (for example an indicator I ND(1) representing the carbon footprint of the service S and an indicator I ND(2) representing its energy consumption).
  • the network controller 2 (for example here via its estimation module 2A) then determines whether the estimated indicator I ND meets a given conformity criterion (criterion CRI T here), i.e. predetermined or predefined (test step E40). For example, the network controller 2 compares the indicator I ND with a threshold value defined for this indicator I ND and for the service S and examines whether or not the indicator I ND has crossed this threshold value.
  • network controller 2 examines whether the carbon footprint has exceeded a certain threshold corresponding to the maximum value that the network NW (i.e. the network operator) accepts (or wishes or authorizes) for this carbon footprint for service S.
  • This maximum value may correspond in particular to a quota of the network's carbon footprint that it has allocated to service S and that service S must not exceed.
  • the CRI T compliance criterion is the carbon footprint exceeding the threshold/quota in question.
  • the network controller 2 via its notification module 2B, notifies the application server 4 (and more particularly its PCP server) of the non-compliance with the conformity criterion by the I ND indicator, in other words in the example of the carbon footprint, of the carbon footprint exceeding the quota allocated by the network NW to the service S (step E50).
  • the network controller 2 obtains the information to contact the application server 4 (and more particularly its PCP server) by consulting the AS_COSI NUS_SUB ⁇ RI BERS table.
  • the notification sent by the network controller 2 to the application server 4 also indicates to the application server 4 that a measure to manage the environmental and/or energy impact of the service S (i.e. its carbon footprint here) is required.
  • the network controller 2 also sends intermediate notifications to the application server 4 each time the indicator I ND crosses various intermediate thresholds (for example 50% of the allocated quota to service S, then 75% of this quota).
  • the application server 4 triggers, via its trigger module 4B, at least one management measure ACT of the environmental and/or energy impact attributed to the service S (i.e. here its carbon footprint) (step F30).
  • the management measure(s) may relate to all or part of the traffic relating to the service S exchanged via the network NW. It may in particular be a limitation measure or a neutralization measure of the environmental and/or energy impact attributed to the service S, or any other management measure aimed at controlling the environmental and/or energy impact attributed to the service S.
  • the management measure ACT triggered by the application server 4 is a programmable scheduling mechanism. This mechanism is based on a shared use of one (or more) given resource(s) ⁇ ) of the network NW by several communication devices during access to the service S by these communication devices and on a temporal scheduling of the communication devices in question to access the shared resource(s). Other examples of management measures that can be envisaged have been described previously.
  • the resource that is shared is a dedicated network slice SLopt supported by the network NW, within which the video streams are broadcast according to a multicast transmission mode by virtue of determined time slots (this is referred to as scheduled multicast broadcasting or “slot-based multicast” in English).
  • a transmission mode advantageously makes it possible to send the same video content to several communication devices simultaneously during determined time slots, for example fixed slots of 1 min, 5 min, 15 min, etc.
  • This scheduled multicast data broadcasting mode is more efficient in terms of environmental and/or energy impact than an immediate unicast data transmission mode within which the same content is duplicated for each communication device.
  • the application server 4 by means of its trigger module 4B, thus selects for each video content to be broadcast offered by the service S, identified by an identifier called contentjd here, one or more time slots or slots (each being identified by an identifier called slotjd here) that it allocates to the transmission of data relating to this video content on the shared network slice SLopt.
  • This or these slotjd time slots associated with a video content contentjd are then allocated to the (distributed between the) communication devices that wish to access the video content in question via the service S, several communication devices requesting access to the video content during a given time interval being able to be allocated the same slotjd time slot to access the content, and thus access the content simultaneously.
  • the sharing of the SLopt network slice therefore results here in a simultaneous use of this network slice by several communication devices. This amounts to determining the time ordering according to which the communication devices in question will access the Set service, more particularly the contentjd video content, using the SLopt network slice.
  • the application server 4 notifies the network controller 2, via its notification module 4C (and possibly via an API provided for this purpose), of the management measure(s) ACT that it has triggered to control (to reduce for example) the environmental and/or energy impact attributed to the service S (step F40).
  • the application server 4 thus informs the network controller 2 of the shared use of the network slice SLopt by a plurality of communication devices accessing the service S and of the scheduling decided for this shared use by sending it an ACTI VATE(SLopt, SCHEDULE) message, SCHEDULE designating information representative of said scheduling and more particularly of the associations between contentjd and slotjd.
  • a validity period may be associated with the management measure and transmitted in the ACTI VATE message, for example, the time for the I ND indicator assigned to the service S to become compliant or to be reset for the application server 4 and/or the service S).
  • the network controller 2 configures at least one entity of the network to support this management measure (step E70). More particularly, in the example envisaged here, during the step E70, the 2D configuration module of the network controller 2 configures the edge nodes (or BR for "Border Routers" in English) of the network NW with updated traffic classification rules so that the data packets relating to the service S and received from the application server 4 or intended for the application server 4 are associated with the network slice SLopt.
  • the contentjd identifier associated with each data stream (video content stream in the example considered here) transporting data packets relating to the service S received from the application server 4 transmitted according to a multicast transmission mode on the network slice SLopt is shared with the network controller 2 and the edge nodes BR configured by the latter so that they are able to identify the streams concerned.
  • the network controller 2 confirms the taking into account of the management measure notified by the application server 4, and the configuration of the edge nodes BR of the network NW to allow the implementation of this management measure (step E80). Therefore, following the reception of this confirmation (step F50), the application server 4 can proceed to the provision of the service S via its provision module 4E, and more particularly, in the example envisaged here, to the scheduled broadcasting of the stream(s) of a video content contentjd in multicast mode to the network slice SLopt, according to the SCHEDULE scheduling decided by the application server 4 during step F30 (step F60).
  • a multicast distribution tree deployed in the SLopt network slice for each association between a contentjd identifier and one or more slotjd identifiers in the SCHEDULE schedule is then used in the NW network to route the data to the communication devices connected to the NW network having subscribed to the corresponding multicast group(s).
  • the network controller 2 if at the end of a determined period of time, noted here Tmax, the network controller 2 is not notified (i.e. informed) by the application server 4 of the triggering of a measure for managing the environmental and/or energy impact attributed to the service S (response no to the test step E60), it activates in the network NW a processing for all or part of the traffic relating to the service S in response to non-compliance with the CRI T conformity criterion by the I ND indicator (step E90). This processing aims, for example, to reduce or neutralize the environmental and/or energy impact attributed to the service S.
  • the 2D trigger module embedded in the network controller 2 triggers for this purpose a default management measure ACT-DEF consisting of switching all or part of the traffic relating to the service S and transiting via the NW network to a network slice noted SL-LBE determined from among the network slices SL1, . . SLK supported by the NW network, the network slice SL-LBE providing a degraded level of service compared to an expected level of service for the service S.
  • ACT-DEF consisting of switching all or part of the traffic relating to the service S and transiting via the NW network to a network slice noted SL-LBE determined from among the network slices SL1, . . SLK supported by the NW network, the network slice SL-LBE providing a degraded level of service compared to an expected level of service for the service S.
  • Such a degraded level of service is, for example, a level of quality of service best suited to the conditions of access to the service, also more commonly referred to as “Best effort” in English, or a level of service lower than this level of service “Best Effort” also referred to as LBE for “Lower than Best Effort” in English.
  • the activation step E90 is accompanied by a configuration by the network controller 2, via its 2D configuration module, of the edge nodes BR of the NW network (and more particularly of the access network) with updated traffic classification rules so that the traffic relating to the service S is associated with this SL-LBE network slice (step E100).
  • This configuration of the edge nodes BR can be done directly or indirectly via a controller.
  • the updated classification rules are also communicated to the communication devices accessing the service S.
  • the network controller 2 can also, via its notification module 2C, inform the application server 4 that the traffic relating to the service S will therefore be reclassified at the input of the network NW to be directed (routed) to the network slice SL-LBE (step E110).
  • the network controller 2 detects that the indicator I ND representative of the environmental and/or energy impact meets the conformity criterion CRI T (for example, following the triggering of the management measure ACT-DER the environmental and/or energy impact attributed to the service S has decreased, or the indicator I ND has been reset), the network controller 2 cancels the processing activated by default by its module 2D during step E90 (in other words, the default management measure ACT-DEF). In the example considered here, this translates into reinstalling the network slices usually used to access service S (and configuring the BR edge nodes accordingly).
  • processing operations may be activated by the network controller 2 in the absence of a measure for managing the environmental and/or energy impact attributed to the service S triggered by the application server 4.
  • the network controller may activate a re-marking of the traffic relating to the service S to store it in another queue, a clipping (“rate limit” in English) or a rejection of all or part of the data packets relating to the service S, a redirection of the data packets relating to the service S to a captive portal, etc.
  • step G10 the discovery of at least one management entity 3 of network slices supported by the network NW likely to be involved in the COSI NUS procedure and in particular in certain management measures taken to reduce (or even neutralize) the environmental and/or energy impact attributed to the service S, typically here its carbon footprint.
  • One or more management entities 3 may be present in the NW network for the implementation of the COSI NUS procedure (also called here “COSI NUS relays”). For the sake of simplification, however, a single management entity 3 of network slices in accordance with the invention in the NW network is considered here, i.e. a single COSI NUS relay.
  • Discovery step G10 can be implemented in different ways.
  • the management entity 3 can be configured at the level of the communication device 5 by the NW network (i.e. by its operator).
  • the NW network provides the communication device 5 with at least one IP address and a port number associated with the management entity 3 of network slices and allowing it to be reached.
  • the network can also provide the communication device 5 with an authentication identifier (or ADN for “Authentication Domain Name” in English) associated with the management entity 3 to allow it to authenticate itself with the latter.
  • This configuration by the NW network can be done using a dedicated protocol, such as for example the DHCP protocol (for “Dynamic Host Configuration Protocol” in English), or via a router advertisement message or RA (for “Router Advertisement” in English), etc.
  • a dedicated protocol such as for example the DHCP protocol (for “Dynamic Host Configuration Protocol” in English), or via a router advertisement message or RA (for “Router Advertisement” in English), etc.
  • the communication device 5 can use an anycast or multicast address to send a discovery message of the network slice management entities 3 operating in the network NW.
  • the management entity 3 then responds to the discovery message by sending, for example, an IP address and a port number (and, where appropriate, an authentication identifier) as described in the first variant.
  • the communication device 5 can use a domain name reserved for special use or SUDN (for “Special-Use Domain Names), as described in the document RFC 6761 by S. Cheshire et al. published by the I ETF and entitled “Special-Use Domain Names”, February 2013, and request domain name resolutions associated with this reserved domain name in order to obtain resource records (or RR for “Resource Record” in English) of type SVBC of the management entities 3, as described in the document I ETF RFC 9460 published by B. Schwartz et al. entitled “Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC)”, November 2023.
  • SUDN for “Special-Use Domain Names”
  • the SVCB RR record of a management entity 3 in accordance with the invention comprises a “SvcParam” parameter defined for the purposes of the invention and named here COSI NUS, indicating the support of the COSI NUS procedure by the management entity 3 in question.
  • the SVCB RR may also comprise a list of types and/or identifiers of network slices managed by the management entity 3.
  • the application server 4 proceeds as described below for the communication devices connected to the NW network and accessing the service S via the NW network.
  • the communication device 5 sends, via its sending module 5Ad, an access request REQ-S to the service S to the application server 4 (step G20), and more particularly in the illustrative example of a streaming video service S envisaged here, a request for streaming access to a video content CONT.
  • the request REQ-S is sent by the communication device 5 via a network slice to which it is connected, for example here the network slice SL1.
  • the access request REQ-S comprises a source IP address provided to the communication device 5 by the network NW and which is in the range of IP addresses provided by the network controller 2 when the application server 4 subscribes to the COSI NUS procedure (step E10/F10 described previously).
  • the application server 4 extracts the source IP address of the access request REQ-S and checks whether this address I P corresponds to a range of addresses I P recorded in the table NTW CO- SI NUSJSUBSCRI PTIONS maintained by the application server 4. It also checks whether a notification of non-conformity of an indicator representative of the environmental and/or energy impact attributed to the service S has been received from the network controller 2 of the network NW (test step F62).
  • the application server 4 does not find any entry in the NTW COSINUS SUBSCRI PTI ONS table or if no notification has been received from the controller 2 of the NW network for the service S (response no to the test step F62), then the access request REQ- S to the service S, then the data packets exchanged as part of the access to the service S (to or from the communication device 5), are processed by the NW network and by the application server 4 in a conventional manner, that is to say by using a network slice among the network slices SL1, ..., SLK supported by the NW network to which the communication device 5 is connected and which is adapted to the service S in a manner known per se, for example the network slice SL1 (step F63).
  • a notification was received during step F20 from the network controller 2 of the network NW and a management measure ACT of the environmental and/or energy impact attributed to the service S was triggered by the application server 4 at step F30, in response to this notification.
  • the application server 4 finds an entry in the table NTW_COSI NUS_SUBSCRI P- TI ONS and a notification of non-compliance of the environmental and/or energy impact has been received (yes response to the test step F62), which is the case in the example considered here, then the management measure ACT triggered by the application server 4 is applied to the traffic relating to the service S exchanged with this communication device 5 (i.e. to the traffic sent by the communication device 5 and to the traffic intended for the communication device 5 as part of its access to the service S).
  • the traffic relating to the service S associated with the communication device 5 and in particular the video content CONT is conveyed via the shared network slice SLopt and its provision to the communication devices using the network slice SLopt in a shared manner is organized according to the SCHEDULE schedule determined by the application server 4, that is to say during the time slot identified by slotjd associated with the identifier contentjd corresponding to the video content CONT (step F64).
  • the application server 4 therefore selects for the communication device 5 the time slot identified by slotjd to allow it to access the content CONT.
  • the application server 4 notifies (i.e. informs) via its notification module 4C the communication device 5 of the management measure ACT triggered and applied to the traffic relating to the service S concerning it, i.e. sent to the communication device 5 or coming from it.
  • the notification module 4C sends a message of notification to the communication device 5 informing it of the use of the shared network slice SLopt during access by the communication device 5 to the service S and of the slotjd time slot allocated for the transmission of the contentjd content on the network slice SLopt (step F65).
  • This notification message here includes, in addition to an identifier of the shared network slice SLopt, an indication that the video content CONT to which the communication device 5 wishes to access in streaming is for example not immediately broadcast on the shared network slice SLopt in response to the access request REQ-S to the service S, but at a given deadline corresponding to the identifier slotjd (for example, 30s, 1 min, 3 min).
  • a static SCHEDULE scheduling determined by the application server 4 and notified to the controller 2 during step F40 upstream of the actual access to the service S has been envisaged.
  • this does not exclude this scheduling from evolving over time (and therefore the application server 4 from sending several messages to the controller 2 reflecting this evolution), in particular as a function of the access requests received by the application server 4 from communication devices.
  • the application server 4 dynamically determines, as a function of the access requests to the service S received from communication devices during, for example, a determined time interval, the SCHEDULE scheduling that it plans to apply for access to the service S by the communication devices in question, via the SLopt network slice.
  • the communication device 5 confirms the reception (step G30) and the taking into account of the notification message (step G40).
  • the application server 4 Upon receipt of this confirmation, the application server 4 adds, in a local cache located for example in its non-volatile memory NVM, the communication device 5 to a list of communication devices receiving the CONT video content broadcast on the shared network slice SLopt, and obtains an identifier noted I D5 for the communication device 5.
  • this identifier I D5 is generated for the communication device 5 by the application server 4 randomly, for example by a module (or a service instance) responsible for managing the connections of all the communication devices to the application server 4.
  • a module or a service instance
  • the application server 4 sends to the communication device 5 its own identifier AS4Jd, the identifier I D5 generated for the communication device 5 as well as the identifier slotjd indicating the time slot allocated to the communication device 5 for the transmission according to a multicast transmission mode of the traffic relating to the service S concerning it and the identifier contentjd associated with the video content CONT (step F66).
  • the application server 4 also creates a context associated with the communication device 5 in its local cache, in which it stores the identifiers I D5, slotjd and contentjd.
  • the application server 4 proceeds in an identical manner with the other communication devices wishing to access the same CONT content as the communication device 5 and concerned by the ACT management measure.
  • the communication device 5 Following receipt of these identifiers by the communication device 5 (step G50), the latter sends an access request REQ-SLopt to the shared network slice SLopt to the management entity 3 (COSI NUS relay) of the network slices supported by the NW network (and in particular of the SLopt network slice), discovered during the discovery step G10 (step G60).
  • the discovery step G10 can be implemented by the communication device 5 following the step G50 of receiving the identifiers provided by the application server 4 or at any time before this reception step.
  • the REQ-SLopt access request to the shared SLopt network slice takes the form of a subscription request to the multicast group whose multicast distribution tree is associated with the slotjd and contentjd identifiers and deployed within this network slice. It is assumed that the multicast group address corresponding to the deployment of the distribution tree has been previously broadcast by the management entity 3.
  • the access request sent by the communication device 5 comprises the different identifiers provided by the application server 4 to the communication device 5 (ID5, AS4_id, slotjd and contentjd).
  • the subscription request sent is an “MLD Report” message of the MLD protocol (for “Multicast Listener Group” in English), modified for the purposes of the invention to include in particular the aforementioned identifiers, when the NW network uses the IPv6 protocol.
  • MLD protocol for “Multicast Listener Group” in English
  • IGMP message for “Internet Group Management Protocol” in English
  • the request for access to the shared network slice SLopt takes the form of a classic “MLD Report” subscription request to the multicast distribution tree and is accompanied by a message conforming to the ICMPv6 protocol (for “Internet Control Message Protocol version 6” in English), conveying the different identifiers provided by the application server 4 to the communication device 5 (ID5, AS4Jd, slotjd and contentjd).
  • the purpose of the ICMPv6 message is to trigger the sending of an “MLD Query” message by management entity 3.
  • This MLD message is typically sent by the router to which the device under the control of management entity 3 is connected.
  • the management entity 3 receives the REQ-SLopt request from the communication device 5 via its reception module 3A (step H10).
  • the management entity 3 extracts the identifiers I D5, AS4Jd, slotjd and contentjd contained in the REQ-SLopt request and carries out various checks on the basis of these identifiers (step H20).
  • the management entity 3 consults the AS_COSI N US SUBSCRI BERS table stored in the network NW and determines whether an entry in the table is associated with the identifier AS4Jd.
  • the management entity 3 retrieves from the AS_COSI NUS SUBSCRI BERS table the information enabling it to contact the application server 4 (IP address and, if applicable, port number, in particular of the PCP server used by the application server 4, provided by the latter in the “Contact_Locator” field during the preliminary negotiation/subscription phase with the network controller 2).
  • the management entity 3 verifies, via its verification module 3B, with the PCP server of the application server 4 using the information obtained, that the communication device 5 is indeed authorized (entitled) to access the SLopt network slice.
  • the verification module 3B of the management entity 3 sends for this purpose a PCP request to the PCP server of the application server 4 including an option called here COSI NUSJDR defined for the needs of the invention, containing here the identifiers I D5, AS4Jd, slotjd and contentjd.
  • Figure 7 illustrates an example of format for such an option, the option code (TBA for “To Be Assigned” in English) being provided by 1'1 ANA in a standardization context.
  • the PCP server of the application server 4 (and more particularly the verification module 4D integrated in the PCP server) checks whether a context corresponding to the identifiers I D5, slotjd and contentjd received in the PCP request is maintained in the local cache of the application server 4 (step F67). If no context corresponding to the identifiers I D5, slotjd and contentjd is maintained by the application server 4, then an error message is sent by the verification module 4D of the application server 4 to the management entity 3 indicating to it that the communication device 5 is not authorized to use the shared network slice SLopt. The management entity 3, via its verification module 3B, rejects the REQ-SLopt request from the communication device 5. It may possibly also inform a dedicated platform.
  • the management entity 3 Upon receipt of this positive response, the management entity 3 accepts the REQ-SLopt request (and thus the request to subscribe to the multicast distribution tree associated with the shared SLopt network slice) (step H30), and triggers, via its trigger module 3C, the connection of the communication device 5 to the shared SLopt network slice (step H40).
  • the connection of the communication device 5 to the shared network slice SLopt is triggered by the management entity 3, i.e. at the initiative of the NW network.
  • the connection request of the communication device 5 can be made to the appropriate entity of the NW network managing the SLopt network slice (for example the management entity 3 or another management entity of the SLopt network slice) before or simultaneously with the sending of its subscription request to the multicast distribution tree associated with the shared network slice SLopt.
  • the communication device 5 accesses the service S via the shared network slice SLopt (step G90). More specifically in the example of a video streaming service envisaged here, the video content identified by the identifier contentjd is transmitted to the communication device 5 by the provisioning module 4E of the application server 4 via the shared network slice SLopt during the time slot identified by the identifier slotjd (step F68 in FIG. 5). The time slot identified by slotjd is thus used to simultaneously deliver the video content CONT to several communication devices (including the communication device 5) via the network slice SLopt.
  • the ACT management measure can be implemented sustainably or be deactivated following detection by the controller 2 that the indicator I ND representative of the environmental and/or energy impact attributed to the service S has become compliant with the criterion CRI T.

Landscapes

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

Abstract

Le procédé de supervision par un contrôleur réseau (2) d'un réseau (NW) comprend : - une étape d'estimation d'au moins un indicateur représentatif d'un impact environnemental et/ou énergétique imputé à un service fourni via ledit réseau; et - si ledit au moins un indicateur ne respecte pas un critère de conformité donné, une étape de notification d'un serveur d'application (4) associé au service du non-respect par ledit indicateur dudit critère de conformité.

Description

Description
Titre de l’invention : Procédés de supervision, de gestion d’un service, de gestion d’un accès à une tranche réseau et d’accès à un service, et dispositifs configurés pour mettre en oeuvre ces procédés
Technique antérieure
[0001 ] L’invention appartient au domaine général des télécommunications.
[0002] Elle concerne plus particulièrement un mécanisme de gestion des engagements environnementaux et énergétiques d’un réseau de communication.
[0003] Les services de communication en général, et ceux accessibles via des infrastructures de réseaux fixes ou mobiles en particulier, présentent une empreinte carbone importante et largement documentée depuis des années, notamment pour les réseaux de communication reposant sur des infrastructures cloud. Avec le réchauffement climatique, la plupart des entreprises et notamment les opérateurs de réseaux et les fournisseurs de service, sont aujourd’hui sensibles aux problématiques de responsabilité sociale d’entreprise (ou RSE), et certaines entreprises se sont d’ores et déjà fixé des objectifs de neutralité carbone et/ou de diminution de leur consommation d’énergie.
[0004] Cette sensibilité à l’impact du déploiement de services de communication sur l’empreinte carbone et/ou la consommation énergétique s’est récemment accentuée avec l’émergence de nouvelles infrastructures réseau telles que les réseaux mobiles 5G, mais également avec la maturité atteinte par certaines techniques telles que les techniques favorisant l’adoption de services dits « immersifs « comme des techniques de réalités virtuelle ou augmentée. Le déploiement d’infrastructures cloud dans un contexte de transformation des réseaux vers l’intégration de techniques logicielles de virtualisation voire d’automatisation participe également à l’augmentation de l’empreinte carbone et les coûts énergétiques liés à l’évolution globale de l’écosystème des télécommunications et des services de communications numériques.
[0005] Minimiser voire neutraliser l’empreinte carbone et/ou ses coûts énergétiques est donc devenu un enjeu majeur dans la plupart des secteurs de l’industrie, et plus particulièrement pour les opérateurs de réseaux et les fournisseurs de service.
[0006] L’invention propose un mécanisme visant à faciliter l’atteinte de cet objectif par les opérateurs de réseaux et les fournisseurs de service.
Exposé de l’invention
[0007] L’invention propose plus particulièrement une approche disruptive prônant une collaboration entre tout ou partie des acteurs impliqués lors de la fourniture d’un service via un réseau, à savoir entre le ou les dispositif(s) de communication accédant au service, l’infrastructure de service et le réseau. Autrement dit, en lieu et place d’actions individuelles mises en oeuvre de façon indépendante par chacun de ces acteurs, l’invention introduit une coordination entre réseau, infrastructure de service et dispositifs de communication pour contribuer conjointement à une maîtrise voire à une réduction de l’impact environnemental et/ou énergétique imputé à un service.
[0008] A cet effet, selon un premier aspect, l’invention propose un procédé de supervision par un contrôleur réseau d’un réseau comprenant : une étape d’estimation d’au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via le réseau ; si ledit au moins un indicateur estimé ne respecte pas un critère de conformité donné, une étape de notification d’un serveur d’application associé au service de ce non-respect dudit critère de conformité par ledit au moins un indicateur.
[0009] Corrélativement, l’invention vise un contrôleur réseau d’un réseau comprenant : un module d’estimation, configuré pour estimer au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via le réseau ; et un module de notification, activé si ledit au moins un indicateur estimé ne respecte pas un critère de conformité donné, et configuré pour notifier un serveur d’application associé au service du non-respect dudit critère de conformité par ledit au moins un indicateur.
[0010] L’invention s’applique à tout type d’indicateur dès lors qu’il est en mesure de fournir des informations sur l’impact environnemental et/ou énergétique imputé à un service. I l peut s’agir par exemple d’une empreinte carbone, d’un indicateur de flux telle qu’une mesure d’une contribution à l’effet de serre, d’une consommation d’énergie, d’un coût d’approvisionnement de l’énergie, etc.
[001 1 ] Selon un deuxième aspect, l’invention propose un procédé de gestion d’un service fourni via au moins un réseau par un serveur d’application associé audit service, ce procédé comprenant : une étape de réception, en provenance d’un contrôleur réseau dudit réseau, d’une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et une étape de déclenchement d’au moins une mesure de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service.
[0012] Corrélativement, l’invention concerne un serveur d’application configuré pour gérer un service fourni via au moins un réseau, ledit serveur d’application comprenant : un module de réception, configuré pour recevoir en provenance d’un contrôleur réseau dudit réseau, une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et un module de déclenchement, configuré pour déclencher au moins une mesure de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service.
[0013] Selon un troisième aspect, l’invention vise un procédé d’accès, par un dispositif de communication, à un service fourni via un réseau, ce procédé comprenant : une étape d’envoi d’une demande d’accès au service à un serveur d’application associé audit service ; et une étape de réception d’une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur représentatif dudit impact environnemental et/ou énergétique estimé par le contrôleur réseau. [0014] Corrélativement, l’invention concerne un dispositif de communication comprenant : un module d’envoi, configuré pour envoyer à un serveur d’application associé à un service fourni via un réseau, une demande d’accès audit service ; et un module de réception, configuré pour recevoir une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique.
[0015] Selon un quatrième aspect, l’invention concerne un procédé de gestion, par une entité d’un réseau, d’un accès à une tranche réseau supportée par le réseau, ledit procédé comprenant : une étape de réception, en provenance d’un dispositif de communication, d’une demande d’accès à une tranche réseau donnée supportée par le réseau, ladite tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau, suite à une notification reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé au service; une étape de vérification, auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et le cas échéant, une étape de déclenchement d’un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée.
[0016] Corrélativement, l’invention vise une entité d’un réseau, configurée pour gérer un accès à une tranche réseau supportée par le réseau, ladite entité comprenant : un module de réception, configuré pour recevoir en provenance d’un dispositif de communication, une demande d’accès à une tranche réseau donnée supportée par le réseau, cette tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau , suite à une notification, reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique imputé au service ; un module de vérification, configuré pour vérifier auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et un module de déclenchement activé le cas échéant et configuré pour déclencher un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée.
[0017] L’invention vise aussi un système comprenant au moins un contrôleur réseau et une entité d’un réseau, un serveur d’application associé à un service fourni via ce réseau, et au moins un dispositif de communication, conformes à l’invention.
[0018] Conformément au mécanisme de collaboration proposé par l’invention, un contrôleur réseau d’un réseau via lequel est fourni un service surveille au moins un indicateur représentatif de l’impact environnemental et/ou énergétique imputé(s) au service, par exemple l’empreinte carbone imputée à ce service. S le ou les indicateurs en question ne respectent pas un critère de conformité donné (par exemple, ils ne sont pas conformes à des valeurs de référence définies pour ce service, typiquement des valeurs attendues, souhaitées ou autorisées pour ce service), un serveur d’application associé au service en est informé pour qu’une ou des actions d’ajustement soi(en)t déclenchée^). De telles actions d’ajustement constituent des mesures de gestion de l’impact environnemental et/ou énergétique imputé au service ; elles visent, par exemple, à limiter, voire à neutraliser, cet impact environnemental et/ou énergétique imputé au service. La notification du serveur d’application peut résulter par exemple d’une souscription du serveur d’application auprès du contrôleur réseau pour que le serveur d’application soit informé par le contrôleur réseau de divers événements relatifs à l’impact environnement/énergétique du service (par exemple, l’empreinte carbone imputée au service dépasse un seuil donné). La ou les mesures de gestion peuvent être déclenchées par exemple par le serveur d’application ou par le contrôleur réseau lui-même de façon coordonnée avec le serveur d’application.
[0019] Aucune hypothèse n’est faite quant à la fréquence ou sur la façon dont est réalisée l’estimation du ou des indicateurs. Une telle estimation peut être réalisée ponctuellement, de façon continue ou quasi-continue (par exemple, sur une fenêtre glissante), à une fréquence régulière (par exemple, quotidienne, hebdomadaire, mensuelle), etc. Elle peut s’appuyer sur la mise en place de filtres dans le réseau et/ou sur des remontées faites par des sondes déployées à divers endroits du réseau et qui permettent de collecter des informations sur les diverses communications associées à un ou plusieurs services. Le réseau peut notamment utiliser les protocoles NETCONF ou I PFIX, connus en soi, à cet effet.
[0020] Ainsi, par exemple, dans un mode particulier de réalisation, l’étape d’estimation du procédé de supervision comprend une réception en provenance d’au moins une sonde déployée dans le réseau d’au moins une information reflétant un impact environnemental et/ou énergétique d’au moins une communication relative audit service établie depuis ou vers un serveur impliqué dans une fourniture dudit service.
[0021 ] Par ailleurs, le(s) critère(s) de conformité auxquels sont comparés les indicateurs estimés peuvent prendre différentes formes selon les indicateurs considérés et le but recherché (mesure préventive ou curative suite à une dégradation du service). Par exemple, un tel critère de conformité peut être le franchissement d’un seuil critique (minimum ou maximum selon l’indicateur considéré) à ne pas dépasser ou d’un seuil intermédiaire (par exemple un pourcentage du seuil critique) avant d’atteindre un tel seuil critique afin de déclencher une ou plusieurs actions préventives permettant d’anticiper une dégradation du service. Un autre critère peut être l’évolution de l’indicateur dans le temps.
[0022] Aucune limitation n’est attachée à la nature des mesures de gestion pouvant être déclenchées en réponse à la non-conformité détectée. Ces mesures de gestion visent par exemple à mettre en place une collaboration entre le réseau, l’infrastructure de service et/ou les dispositifs de communication afin de limiter ou de neutraliser l’impact environnemental et/ou énergétique imputé au service et ainsi s’assurer que le trafic en provenance et/ou à destination des dispositifs de communication puisse être acheminé dans les meilleures conditions de sobriété numérique. On peut également envisager une mesure de gestion conduisant à une agglomération de plusieurs plateformes de service (notamment pour en réduire le nombre) et résultant en une modification du critère de conformité considéré pour le service (par exemple en une augmentation du quota autorisé pour l’empreinte carbone du service, ou un report de ce quota).
[0023] Ainsi, dans un mode particulier de réalisation, ladite au moins une mesure de gestion peut être choisie parmi au moins : une utilisation d’un encodage des données relatives audit service ayant une contribution à l’impact environnemental et/ou énergétique imputé audit service plus faible qu’un encodage courant ; une restriction d’un accès audit service via ledit réseau ; un ordonnancement (temporel) d’un accès audit service par plusieurs dispositifs de communication ; une utilisation mutualisée d’au moins une ressource donnée du réseau par plusieurs dispositifs de communication lors d’un accès audit service par lesdits dispositifs de communication ; et un marquage d’un trafic relatif audit service pour le stocker dans au moins une file d’attente.
[0024] Bien entendu, d’autres mesures de gestion peuvent être envisagées en variante.
[0025] Avantageusement, ces mesures de gestion peuvent être choisies et/ou paramétrées en fonction des valeurs estimées des indicateurs considérés, ce qui permet d’agir de façon dynamique, ciblée et adaptée. Elles peuvent être appliquées à tout ou partie du trafic associé au service.
[0026] Ainsi, dans un mode particulier de réalisation, le procédé de gestion mis en oeuvre par le serveur d’application comprend : une étape de réception d’une demande d’accès au service en provenance d’un dispositif de communication ; si ledit dispositif de communication est concerné par une dite mesure de gestion, une étape d’application de cette mesure de gestion au trafic relatif au service en provenance ou à destination dudit dispositif de communication.
[0027] L’une des mesures de gestion pouvant être envisagée est un ordonnancement programmable (ou « programmable scheduling » en anglais) permettant d’organiser dans le temps l’accès au service par une pluralité de dispositifs de communication.
[0028] Ainsi, dans un mode particulier de réalisation, lorsque ladite au moins une mesure de gestion comprend un ordonnancement d’un accès audit service par une pluralité de dispositifs de communication, le procédé de gestion mis en oeuvre par le serveur d’application comprend suite à une demande d’accès au service par au moins un dispositif de communication, une étape de sélection pour ledit au moins un dispositif de communication, d’un créneau temporel alloué à ladite pluralité de dispositifs de communication pour l’accès au service.
[0029] En d’autres termes, le serveur d’application détermine à quel moment chaque dispositif de communication demandant à accéder au service va effectivement accéder au service, et ainsi pouvoir émettre ou recevoir des données relatives à ce service. Plusieurs dispositifs de communication ayant demandé à accéder au service dans un intervalle de temps donné peuvent se voir allouer le même créneau temporel pour accéder au service. Ainsi, un dispositif de communication peut voir son accès au service retardé en fonction de la programmation qui a été faite de l’utilisation d’une ressource pour fournir le service, c’est-à-dire des créneaux temporels qui ont été alloués pour cette fourniture de service. On note qu’on s’intéresse ici à l’organisation de l’accès au service par les utilisateurs des dispositifs de communication (par exemple l’accès à un contenu vidéo diffusé en streaming), et non à proprement parler à l’ordonnancement des paquets de données associés à un utilisateur sur les ressources du réseau.
[0030] Un tel ordonnancement programmable de l’accès au service a une application privilégiée lorsque les dispositifs de communication se partagent une même ressource pour accéder à un service, c’est-à-dire dans un contexte où au lieu de fournir le service à un dispositif de communication via une ressource dédiée, cette ressource est mutualisée pour fournir le service à plusieurs dispositifs de communication. L’utilisation mutualisée de ressources par plusieurs dispositifs de communication combinée à un ordonnancement programmable contribue non seulement à mieux gérer l’impact environnemental et/ou énergétique du réseau, mais également à améliorer l’usage des ressources du réseau ainsi que l’efficacité de la politique d’acheminement de trafic mise en oeuvre dans le réseau. Une telle approche permet de tenir compte des budgets énergétiques et environnementaux par service et par utilisateur. Cette approche prometteuse peut en outre s’appliquer dans différents contextes : communications entre centres de données (ou « data centers » en anglais), gestion dynamique des flux (ou « workflows » en anglais) d’une entreprise, ajustement des ressources permettant l’accès à des services et contenus événementiels avec un niveau de qualité adéquat, etc.
[0031 ] Une utilisation mutualisée des ressources peut être aisément mise en place en s’appuyant sur le contrôleur réseau du réseau. Ainsi, dans un mode particulier de réalisation, le procédé de supervision comprend en outre : une étape de réception, en provenance du serveur d’application, d’une notification d’une utilisation mutualisée par plusieurs dispositifs de communication d’au moins une ressource donnée du réseau lors d’un accès audit service par les dispositifs de communication ; et une étape de configuration d’au moins une entité du réseau pour permettre cette utilisation mutualisée.
[0032] Une telle entité du réseau est par exemple un nœud de périphérie du réseau que l’on vient configurer avec de nouvelles règles de classification pour tenir compte de l’utilisation mutualisée de ressources.
[0033] Différentes ressources du réseau peuvent être mutualisées dans le contexte de l’invention. Par exemple, dans le contexte d’un service de vidéo en flux (ou « streaming video » en anglais), on peut envisager d’utiliser une arborescence multicast déployée dans le réseau (voire dans une tranche supportée par le réseau) pour envoyer un même contenu vidéo à plusieurs dispositifs de communication via le réseau. Selon un autre exemple, on peut envisager que plusieurs dispositifs de communication utilisent une même tranche réseau supportée par le réseau pour accéder au service, typiquement une tranche réseau dédiée à une telle utilisation mutualisée.
[0034] Ainsi, dans un mode particulier de réalisation, ladite au moins une ressource mutualisée comprend une tranche réseau donnée supportée par le réseau et ladite notification reçue du serveur d’application comprend une information représentative d’un ordonnancement d’un accès au service par des dispositifs de communication via ladite tranche réseau.
[0035] Ce mode de réalisation propose donc, pour limiter l’impact environnemental et/ou éner- gétique du service, d’utiliser de façon partagée par une pluralité de dispositifs de communication une (ou plusieurs) tranche(s) réseau supportée(s) par le réseau pour l’accès au service, l’accès à la tranche réseau en question étant organisé selon un ordonnancement particulier dûment choisi par le serveur d’application.
[0036] L’invention a ainsi une application privilégiée mais non limitative dans le contexte des réseaux supportant des tranches réseau (ou « network slices » en anglais) , tels qu’un réseau 5G. De façon connue en soi, une tranche réseau peut être définie comme un réseau privé virtuel (RPV ou VPN pour « Virtual Private Network » en anglais) déployé sur une infrastructure réseau fixe ou mobile ou les deux, et visant à assurer un ensemble de performances spécifiques. Elle peut être vue comme un réseau logique offrant une connectivité à ses utilisateurs et ayant ses propres caractéristiques en termes de capacité (bande passante), de qualité de service (latence, débit, temps de transit unidirectionnel, gigue (ou variation du délai inter-paquets, « inter-packet delay variation » en anglais, etc.) et de sécurité (par exemple, préservation de la confidentialité des informations transmises au sein d’un réseau privé virtuel moyennant l’utilisation de techniques de chiffrement).
[0037] Ce mode de réalisation peut être aisément mis en oeuvre via une collaboration avec le contrôleur réseau et/ou les dispositifs de communication.
[0038] Ainsi, dans un mode particulier de réalisation, le procédé de gestion mis en oeuvre par le serveur d’application peut comprendre au moins une étape parmi : une étape de notification dudit contrôleur réseau de l’utilisation mutualisée de ladite tranche réseau donnée par lesdits dispositifs de communication selon ledit ordonnancement déterminé ; et une étape de notification desdits dispositifs de communication de ladite tranche réseau donnée à utiliser de façon mutualisée par lesdits dispositifs de communication lors d’un accès au service et dudit ordonnancement déterminé qui doit être appliqué.
[0039] Corrélativement, pour un dispositif de communication, dans un mode de réalisation dans lequel ladite au moins une mesure de gestion comprend une utilisation mutualisée selon un ordonnancement déterminé, lors d’un accès audit service, d’une tranche réseau donnée supportée par ledit réseau par plusieurs dispositifs de communication dont ledit dispositif de communication en question, le procédé peut comprendre : une étape d’envoi à une entité du réseau, d’une demande d’accès à ladite tranche réseau donnée mutualisée ; et suite au raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée, une étape d’accès audit service via ladite tranche réseau donnée mutualisée.
[0040] En outre, préalablement à l’utilisation d’une tranche réseau mutualisée par un dispositif de communication, un contrôle peut être mis en place auprès du serveur d’application par l’entité du réseau chargée de gérer l’accès à cette tranche réseau. Ainsi, dans un mode particulier de réalisation, le procédé de gestion mis en oeuvre par le serveur d’application peut comprendre une étape de réception en provenance d’une entité du réseau d’une demande de vérification qu’un dispositif de communication est autorisé à accéder à ladite tranche réseau donnée.
[0041 ] Dans un mode de réalisation particulier de l’invention, si après avoir notifié le serveur d’application, le contrôleur réseau détecte qu’aucune mesure de gestion de l’impact environnemental et/ou énergétique imputé au service n’a été mise en oeuvre par le serveur d’application, il peut déclencher lui-même de telles mesures de gestion.
[0042] Par exemple, dans un mode de réalisation, le procédé de supervision comprend en l’absence à l’issue d’une période déterminée d’un déclenchement d’au moins une mesure de gestion de l’impact environnemental et/ou énergétique par le serveur d’application suite à sa notification, une étape d’activation dans ledit réseau, pour tout ou partie du trafic relatif audit service, d’au moins un traitement en réponse au non-respect du critère de conformité par l’indicateur représentatif de l’impact environnemental et/ou énergétique imputé audit service.
[0043] Un tel traitement peut comprendre par exemple un basculement de tout ou partie du trafic relatif audit service transitant via le réseau vers une tranche réseau fournissant un niveau de service dégradé par rapport à un niveau de service attendu pour ledit service, par exemple un niveau de qualité adapté au mieux aux conditions d’accès au service, aussi appelé « Best effort » en anglais.
[0044] Dans un mode particulier de réalisation, les procédés de supervision, de gestion et d’accès sont mis en oeuvre par un ordinateur.
[0045] L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en oeuvre dans un ordinateur ou plus généralement dans un contrôleur réseau d’un réseau conforme à l’invention et comportant des instructions adaptées à la mise en oeuvre d’un procédé de supervision tel que décrit ci-dessus.
[0046] L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en oeuvre dans un ordinateur ou plus généralement dans un serveur d’application conforme à l’invention et comportant des instructions adaptées à la mise en oeuvre d’un procédé de gestion d’un service tel que décrit ci-dessus.
[0047] L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en oeuvre dans un ordinateur ou plus généralement dans une entité d’un réseau conforme à l’invention et comportant des instructions adaptées à la mise en oeuvre d’un procédé de gestion d’un accès à une tranche réseau tel que décrit ci-dessus.
[0048] L’invention vise également un programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en oeuvre dans un ordinateur ou plus généralement dans un dispositif de communication conforme à l’invention et comportant des instructions adaptées à la mise en oeuvre d’un procédé d’accès à un service tel que décrit ci-dessus.
[0049] Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.
[0050] L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions d’un programme d'ordinateur tel que mentionné ci-dessus.
[0051] Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
[0052] D'autre part, le support d'information ou d’enregistrement peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.
[0053] Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type I nternet.
[0054] Alternativement, le support d'information ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution des procédés de gestion d’un accès, de gestion d’un service, d’un accès et de supervision selon l’invention.
[0055] On peut également envisager, dans d'autres modes de réalisation, que les procédés de supervision, de gestion d’un service, de gestion d’un accès à une tranche réseau et d’accès à un service, le contrôleur réseau, le serveur d’application, l’entité du réseau et le dispositif de communication et le système selon l’invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève descript ion des f igures
[0056] D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux figures annexées qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[ Fig. 1 ] la figure 1 représente, dans son environnement, un système conforme à l’invention, dans un mode particulier de réalisation ;
[ Fig. 2] la figure 2 représente schématiquement l’architecture matérielle d’un ordinateur pouvant héberger un contrôleur réseau, un serveur d’application, une entité de gestion ou un dispositif de communication selon l’invention appartenant au système de la figure 1 ;
[ Fig. 3] la figure 3 représente sous forme d’ordinogramme, les principales étapes d’un procédé de supervision selon l’invention tel qu’il est mis en oeuvre par le contrôleur réseau du système de la figure 1 , dans un mode particulier de réalisation ;
[ Fig. 4] la figure 4 représente sous forme d’ordinogramme, les principales étapes d’un procédé de gestion de l’accès à un service selon l’invention tel qu’il est mis en oeuvre par le serveur d’application du système de la figure 1 , dans un mode particulier de réalisation ;
[ Fig. 5] la figure 5 représente sous forme d’ordinogramme, les principales étapes d’un procédé de gestion de tranches réseau selon l’invention tel qu’il est mis en oeuvre par l’entité de gestion du système de la figure 1 , dans un mode particulier de réalisation ;
[ Fig. 6] la figure 6 représente sous forme d’ordinogramme, les principales étapes d’un procédé d’accès à un service selon l’invention tel qu’il est mis en oeuvre par un dispositif de communication du système de la figure 1 dans un mode particulier de réalisation ; et
[ Fig. 7] la figure 7 représente un exemple de format d’une option COSI NUSJDP pouvant être utilisée dans le cadre de l’invention.
Description de l’invent ion
[0057] La f igu re 1 représente, dans son environnement, un système 1 conforme à l’invention, dans un mode particulier de réalisation, le système 1 étant configuré pour mettre en oeuvre un mécanisme collaboratif visant à maîtriser (gérer), et éventuellement réduire (voire neutraliser), l’impact environnemental et/ou énergétique d’un service S fourni via un réseau NW de communication.
[0058] Dans le mode de réalisation envisagé ici, le réseau NW de communication supporte une pluralité de tranches réseau SL1 , SL2,..., SLK, où K désigne un entier supérieur à 1 , pouvant être utilisées pour agréger le trafic relatif à un ou plusieurs services (c’est-à- dire émis à destination ou reçu en provenance d’un ou de plusieurs services). Chaque tranche réseau peut impliquer une ou plusieurs fonctions service (ou « Service Functions » en anglais) , aussi appelées fonctions réseau (ou « Network Functions » en anglais). De telles fonctions service/ réseau sont par exemple des fonctions stations de base ou gNB (pour « gNodeB » en anglais), des fonctions du plan utilisateur ou UPF (pour « User Plane Function » en anglais), des fonctions de marquage, de classification et d’ordonnancement du trafic, etc. Une même fonction service/ réseau peut être fournie par une ou plusieurs instances de service (ou « Service Function I nstances » en anglais) ou instances de fonctions réseau. Des chaînes de service ou SFC (pour « Service Function Chains » en anglais) peuvent être mises en place afin de faciliter l’acheminement de trafics de différentes natures et présentant des profils différents pour les besoins de la réalisation (c’est-à-dire l’ingénierie et le déploiement) d’une tranche réseau ou au sein d’une tranche réseau.
[0059] Le réseau NW est par exemple un réseau mobile 5G tel que défini par les standards 3GPR I I peut être segmenté en plusieurs (sous-) réseaux distincts (on parle également de « segments de réseau ») composant autant de domaines distincts. Par exemple, le réseau NW peut être composé d’un réseau d’accès radio (ou RAN pour « Radio Access Network » en anglais), d’un réseau cœur (ou CN pour « Core Network » en anglais) et d’un réseau de transport (ou TN pour « Transport Network » en anglais) assurant la connectivité au sein et entre le réseau cœur et le réseau d’accès radio. Chacun des domaines supporte des tranches réseau dont l’ingénierie et l’exploitation sont caractéristiques du domaine. Par exemple, une tranche déployée sur un réseau cœur mobile 5G fait appel à des fonctions de traitement de trafic et d’exploitation caractéristiques d’un réseau cœur mobile 5G.
[0060] Aucune hypothèse n’est faite ici quant à la nature ou le nombre de tranches réseau supportées par le réseau NW. Ces tranches réseau peuvent s’étendre sur un ou plusieurs domaines (et être ainsi constituées de plusieurs tranches réseau « locales » déployées dans les différents domaines ; on parle alors de tranches réseau « multi-domaines » ou « stitched slices » ou encore « hierarchical slices » en anglais). La façon de concevoir et de déployer des tranches réseau pour offrir des services est connue en soi et n’est pas décrite en détail ici.
[0061 ] I l convient de noter que ces hypothèses ne sont pas limitatives en soi et l’invention s’applique dans d’autres contextes et notamment à d’autres réseaux (supportant ou non des tranches réseau), tels qu’un réseau reposant sur une architecture SD-WAN (pour « Software- Defined Wide Area Network » en anglais) ou SDN (pour « Software-Defined Network » en anglais) ou encore sur l’utilisation de techniques NFV (pour « Network Functions Virtualization » en anglais) de virtualisation de fonctions réseau, etc.
[0062] Comme évoqué précédemment, le système 1 est configuré pour maîtriser l’impact environnemental et/ou énergétique d’un service S fourni via le réseau NW. A cet effet, il comprend, dans le mode de réalisation décrit ici, au moins : un contrôleur réseau 2 du réseau NW et une entité de gestion de tranches réseau 3 du réseau NW, conformes à l’invention ; un serveur d’application 4 (ou AS pour « Application Server » en anglais), associé au service S, conforme à l’invention ; et au moins un dispositif de communication 5, conforme à l’invention, connecté au réseau NW et susceptible d’accéder au service S via le réseau NW.
[0063] L’invention s’applique à tout type de service S (vidéo en streaming, réalité virtuelle ou augmentée, visio-conférence, etc.). Dans l’exemple de la figure 1 , le service S est un service de vidéo en streaming fourni par un fournisseur de services distinct de l’opérateur du réseau NW, et le serveur d’application 4 est un serveur distant localisé en dehors du réseau NW. Toutefois cette hypothèse n’est pas limitative en soi, et l’invention s’applique quelle que soit la localisation du service. I l convient par ailleurs de noter que le serveur d’application 4 associé au service S n’est pas nécessairement le serveur qui fournit à proprement parler le service S ; il peut s’agir de n’importe quel serveur d’application ou instance de service appartenant à l’infrastructure de service fournissant le service S. Dans l’exemple envisagé ici, le fournisseur du service S est un fournisseur de services reposant sur des tranches réseau ou SSP (pour « Slice Service Provider » en anglais). On suppose que le dispositif de communication 5 a négocié lors de sa souscription au service S auprès du SSP la ou les tranches réseau qu’il est susceptible d’utiliser pour envoyer ou recevoir du trafic associé au service S via le réseau NW. Le type de chaque tranche réseau a par ailleurs été négocié entre le dispositif de communication 5 et le réseau NW, de façon connue en soi.
[0064] Dans l’exemple envisagé ici, le dispositif de communication 5 est un équipement utilisateur (ou UE pour « User Equipment » en anglais) tel qu’un téléphone intelligent (plus communément appelé « smartphone »), un ordinateur portable, une tablette numérique, etc. L’invention s’applique toutefois aisément à d’autres dispositifs de communication 5, fixes ou mobiles, logiciels ou matériels, etc., comme par exemple à une instance de service, une passerelle domestique ou CPE (pour « Customer Premises Equipment » en anglais).
[0065] Dans le mode de réalisation décrit ici, le contrôleur réseau 2, l’entité de gestion 3, le serveur d’application 4 et le dispositif de communication 5 ont chacun l’architecture matérielle d’un ordinateur 6 telle qu’illustrée par la f igu re 2. Cette architecture matérielle comprend notamment un processeur PROC, une mémoire vive MEM, une mémoire morte ROM, une mémoire non volatile NVM, et des moyens COM de communication. La mémoire non volatile NVM constitue un support d’enregistrement conforme à l’invention, lisible par le processeur PROC et sur lequel est enregistré un programme conforme à l’invention.
[0066] Ce programme, noté PROG-2 lorsque l’architecture matérielle de l’ordinateur 6 est celle d’un contrôleur réseau conforme à l’invention tel que le contrôleur réseau 2, est enregistré dans la mémoire non volatile NVM et comporte des instructions définissant les principales étapes d’un procédé de supervision selon l’invention. I l définit plus spécifiquement les modules fonctionnels du contrôleur réseau 2 (représentés sur la figure 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent dans l’exemple du service S : un module 2A d’estimation, configuré pour estimer au moins un indicateur I ND représentatif d’un impact environnemental et/ou énergétique imputé au service S fourni via le réseau NW ; et un module 2B de notification, activé si ledit au moins indicateur I ND estimé si ledit au moins indicateur estimé ne respecte pas un critère CRI T de conformité donné (on peut envisager des critères différents selon les indicateurs considérés), et configuré pour notifier le serveur d’application 4 associé au service Sde ce non-respect. [0067] Dans le mode de réalisation décrit ici, le contrôleur réseau 2 comprend également les modules fonctionnels suivants, définis par le programme d’ordinateur PROG-2 : un module 2C de déclenchement, configuré ici pour déclencher lui-même une mesure de gestion de l’impact environnemental et/ou énergétique imputé au service (aussi appelée « action d’ajustement »), et plus précisément une action d’ajustement par défaut ACT-DER en l’absence de déclenchement par le serveur d’application 4 d’une telle mesure de gestion suite à la notification reçue du module 2B de notification indiquant le non-respect par l’indicateur I ND du critère CRI T. Cette action d’ajustement par défaut ACT-DEF est un traitement déclenché en réponse au non-respect du critère CRI T et qui vise par exemple à réduire ou à neutraliser l’impact environnemental et/ou énergétique imputé au service. Un exemple d’action d’ajustement par défaut ACT-DEF est donné à titre illustratif ultérieurement ; et un module 2D de configuration d’entités du réseau NW pour permettre la mise en oeuvre de mesures de gestion (par défaut ou déclenchées par le serveur d’application 4) de l’impact environnemental et/ou énergétique du service S dans le réseau. [0068] Les fonctions des modules 2A à 2D du contrôleur réseau 2 sont décrites plus en détail ultérieurement en référence à la figure 3 décrivant les principales étapes d’un procédé de supervision selon l’invention.
[0069] Lorsque l’architecture matérielle de l’ordinateur 6 est celle d’un serveur d’application conforme à l’invention tel que le serveur d’application 4, le programme conforme à l’invention enregistré dans la mémoire non volatile NVM de l’ordinateur 6 est le programme PROG-4 qui comporte des instructions définissant les principales étapes d’un procédé de gestion d’un service selon l’invention. Ce programme PROG-4 définit les modules fonctionnels du serveur d’application 4 (représentés sur la figure 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent, dans l’exemple du service S : un module 4A de réception, configuré pour recevoir le cas échéant en provenance du contrôleur réseau 2, une notification d’un non-respect du critère CRI T de conformité par ledit au moins un indicateur I ND ; et un module 4B de déclenchement, configuré pour déclencher au moins une mesure de gestion ACT de l’impact environnemental et/ou énergétique imputé au service S, cette mesure de gestion ACT portant sur tout ou partie du trafic relatif au service S. Des exemples de mesures de gestion ACT pouvant être déclenchées sont notamment : o une utilisation d’un encodage des données relatives au service S ayant une contribution à l’impact environnemental et/ou énergétique imputé au service S plus faible qu’un encodage couramment utilisé par les dispositifs de communication accédant à ce service S et/ou par le serveur d’application fournissant le service S ; o une restriction d’un accès au service S via le réseau NW ; o un ordonnancement d’un accès au service S par plusieurs dispositifs de communication ; o une utilisation mutualisée d’au moins une ressource donnée du réseau NW par plusieurs dispositifs de communication lors d’un accès au service S par ces dispositifs de communication ; o un marquage d’un trafic relatif au service pour le stocker dans au moins une file d’attente ; o etc.
[0070] Par « utilisation mutualisée d’une ressource », il est fait référence ici à un mode dans lequel cette ressource n’est pas exclusivement dédiée à la fourniture du service à un dispositif de communication mais elle est utilisée pour fournir ce service simultanément à plusieurs dispositifs de communication qui souhaitent accéder au service dans un intervalle donné. On s’oppose ainsi ici à un mode dans lequel la ressource en question est utilisée, suite à une demande d’accès au service par un dispositif de communication, exclusivement pour l’écoulement du trafic de ce service vers ce dispositif de communication (la ressource est dédiée à ce dispositif de communication), indépendamment des autres dispositifs de communication souhaitant accéder au même service. Par exemple, un mode de transmission multicast illustre une utilisation mutualisée d’une ressource pour transmettre un flux de données, par opposition à un mode de transmission unicast dédié à un utilisateur donné.
[0071 ] D’autres mesures de gestion (ou actions d’ajustement) peuvent bien entendu être envisagées en variante, typiquement des mesures de limitation ou de neutralisation de l’impact environnemental et/ou énergétique imputé au service S. Par exemple, une mesure de gestion peut consister à modifier le critère CRI T de conformité considéré (si ce critère est un quota à respecter, on peut par exemple augmenter ce quota ou le reporter). Par ailleurs, le module 4B de déclenchement peut déclencher une combinaison des mesures de gestion précitées, comme décrit plus en détail ultérieurement. Typiquement, dans le mode de réalisation décrit ici, on considère une utilisation mutualisée d’une tranche réseau supportée par le réseau NW combinée à un mécanisme d’ordonnancement (dit programmable) organisant cette utilisation mutualisée entre les dispositifs de communication concernés.
[0072] Dans le mode de réalisation décrit ici, le serveur d’application 4 comprend également les modules fonctionnels suivants, définis par le programme d’ordinateur PROG-4 : un module 4C de notification, configuré pour notifier (c’est-à-dire informer) le contrôleur réseau 2 et/ou les dispositifs de communication accédant au service de la ou des mesures de gestion déclenchées par son module 4B de déclenchement ; un module 4D de vérification, configuré pour effectuer divers contrôles sur demande d’une entité du réseau NW (par exemple de l’entité de gestion 3) ; et un module 4E de fourniture, configuré pour fournir le service S via le réseau NW aux dispositifs de communication (dont le dispositif de communication 5) connectés à ce réseau NW.
[0073] Aucune hypothèse n’est faite quant à la façon dont sont organisés les modules 4A à 4E qui viennent d’être décrits. Ces modules peuvent être intégrés dans des instances de service distinctes ou dans une unique instance de service. Ainsi, par exemple, dans le mode de réalisation décrit ici, on suppose que le serveur d’application 4 expose un serveur PCP (pour « Port Control Protocol ») pour interagir avec les dispositifs de communication (dont le dispositif de communication 5) souhaitant accéder au service S, avec le contrôleur réseau 2 et avec les entités du réseau NW et notamment l’entité de gestion 3. De façon connue en soi, le protocole PCR qui est décrit notamment dans le document RFC 6887 de D. Wing et al, édité par l’I ETE et intitulé « Port Control Protocol (PCP) », avril 2013, est particulièrement avantageux car il contribue à économiser la consommation énergétiques des dispositifs qui l’utilisent en leur permettant de s’affranchir de l’envoi de messages « keep-alive » (par exemple la consommation des batteries de tels dispositifs le cas échéant), et évite de solliciter inutilement les ressources du réseau. Typiquement, les modules 4A, 4C et 4D du serveur d’application 4 s’appuient sur ou peuvent être intégrés dans ce serveur PCR
[0074] Les fonctions des modules 4A à 4E du serveur d’application 4 sont décrites plus en détail ultérieurement en référence à la figure 4 décrivant les principales étapes d’un procédé de gestion d’un service selon l’invention.
[0075] Dans le mode de réalisation décrit ici, la mise en oeuvre par le serveur d’application 4 de certaines mesures de gestion de l’impact environnemental et/ou énergétique imputé au service S, comme notamment l’utilisation d’une ressource mutualisée du réseau NW telle qu’une tranche réseau par plusieurs dispositifs de communication et l’ordonnancement de l’accès au service par ces dispositifs de communications, s’appuie sur l’entité de gestion 3 du réseau NW. Lorsque l’architecture matérielle de l’ordinateur 6 est celle d’une entité de gestion conforme à l’invention telle que l’entité de gestion 3, le programme conforme à l’invention enregistré dans la mémoire non volatile NVM de l’ordinateur 6 est le programme PROG-3 qui comporte des instructions définissant les principales étapes d’un procédé de gestion d’un accès à une tranche réseau selon l’invention. Ce programme PROG-3 définit les modules fonctionnels de l’entité de gestion 3 (représentés sur la figure 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent, dans l’exemple du service S : un module 3A de réception, configuré pour recevoir en provenance d’un dispositif de communication tel que le dispositif de communication 5, une demande d’accès à une tranche réseau donnée parmi les tranches réseau SL1 , ..., SLK supportées par le réseau NW, cette tranche réseau notée SLopt étant mutualisée entre plusieurs dispositifs de communication accédant au service S fourni via le réseau NW en vue d’ajuster l’impact environnemental et/ou énergétique imputé au service S suite à une notification, reçue par le serveur d’application 4 du contrôleur réseau 2, d’un non-respect du critère de conformité CRIT par ledit au moins un indicateur I ND représentatif de l’impact environnemental et/ou énergétique imputé au service S ; un module 3B de vérification, configuré pour vérifier auprès du serveur d’application 4 associé au service S, que ledit dispositif de communication en question est autorisé à accéder à la tranche réseau SLopt mutualisée ; et un module 3C de déclenchement activé le cas échéant et configuré pour déclencher un raccordement du dispositif de communication à la tranche réseau SLopt mutualisée.
[0076] Les fonctions des modules 3A à 3C de l’entité de gestion 3 sont décrites plus en détail ultérieurement en référence à la figure 5 décrivant les principales étapes d’un procédé de gestion d’un accès à une tranche réseau selon l’invention.
[0077] Enfin, lorsque l’architecture matérielle de l’ordinateur 6 est celle d’un dispositif de communication conforme à l’invention tel que le dispositif de communication 5, le programme conforme à l’invention enregistré dans la mémoire non volatile NVM de l’ordinateur 6 est le programme PROG-5 qui comporte des instructions définissant les principales étapes d’un procédé d’accès à un service selon l’invention. Ce programme PROG- 5 définit les modules fonctionnels du dispositif de communication 5 (représentés sur la figure 1 ), qui s’appuient et/ou commandent tout ou partie des éléments PROC, MEM, ROM, NVM, et COM de l’ordinateur 6 évoqués précédemment. Ces modules fonctionnels comprennent, dans l’exemple du service S : un module 5A d’envoi, configuré pour envoyer au serveur d’application 4 une demande d’accès au service S ; et un module 5B de réception, configuré pour recevoir une notification en provenance du serveur d’application 4 informant le dispositif de communication 5 d’une application au trafic relatif au service S en provenance ou à destination du dispositif de communication 5 d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service S, cette mesure de gestion faisant suite à une notification reçue par le serveur d’application 4 du contrôleur réseau 2 lui indiquant le non-respect par ledit au moins un indicateur I ND du critère de conformité CRI T.
[0078] Les fonctions des modules 5A et 5B du dispositif de communication 5 sont décrites plus en détail ultérieurement en référence à la figure 6 décrivant les principales étapes d’un procédé d’accès à un service selon l’invention.
[0079] Nous allons maintenant décrire, en référence aux f igures 3 à 6 , les principales étapes mises en oeuvre par les éléments du système 1 (contrôleur réseau 2, serveur d’application 4, entité de gestion 3 et dispositif de communication 5) lors de leur participation au mécanisme de collaboration proposé par l’invention pour maîtriser/gérer l’impact environnemental et/ou énergétique imputé au service S. Plus particulièrement, la f igure 3 représente les principales étapes d’un procédé de supervision selon l’invention telles qu’elles sont mises en oeuvre par le contrôleur réseau 2, la f ig ure 4 représente les principales étapes d’un procédé de gestion d’un service selon l’invention telles qu’elles sont mises en oeuvre par le serveur d’application 4, la f ig ure 5 représente les principales étapes d’un procédé de gestion d’un accès à une tranche réseau selon l’invention telles qu’elles sont mises en oeuvre par l’entité de gestion 3, et la f igure 6 représente les principales étapes d’un procédé d’accès à un service selon l’invention telles qu’elles sont mises en oeuvre par le dispositif de communication 5, dans un mode particulier de réalisation.
[0080] Dans le mode particulier de réalisation décrit ici, on s’intéresse plus particulièrement à l’impact environnemental imputé au service S et notamment à son empreinte carbone (indicateur représentatif de l’impact environnemental imputé au service S au sens de l’invention), lorsque ce service S est fourni via le réseau NW qui supporte une pluralité de tranches réseau. Dans ce contexte, le mécanisme de collaboration proposé par l’invention est appelé ci-après procédure ou service COSI NUS (pour « Carbon Optimized Sliced Networks with scheduled Service Continuity « en anglais).
[0081 ] L’invention peut bien entendu être envisagée dans d’autres contextes, comme évoqué précédemment, et peut s’appliquer pour maîtriser l’impact énergétique du service S, ou son impact environnemental et son impact énergétique. Aucune limitation n’est attachée à la nature ou au nombre d’indicateurs permettant de mesurer cet impact. Ainsi, outre l’empreinte carbone, on peut considérer comme indicateurs, une consommation d’énergie, un coût d’approvisionnement de l’énergie, un indicateur de volumétrie de trafic, un indicateur environnemental (par exemple la température d’un équipement du réseau), une description d’une ou de plusieurs sources d’énergie utilisées (par exemple, des piles, une centrale nucléaire, un onduleur) , un facteur de durabilité d’un déploiement (ou DSF pour « Deployment Sustainability Factor » en anglais), etc.
[0082] Dans le mode de réalisation décrit ici, on suppose que lors d’une phase préliminaire (correspondant aux étapes E10 de la figure 3 et F10 de la figure 4) , le contrôleur réseau 2 et le serveur d’application 4 négocient dynamiquement la mise en oeuvre de la procédure COSI NUS pour le service S et le réseau NW, par exemple via une interface de programmation applicative ou API (pour « Application Programming I nterface » en anglais) dédiée, appelée ici API COSI NUS. Pour exposer et utiliser l’API COSI NUS, le contrôleur réseau 2 et le serveur d’application 4 utilisent par exemple le protocole de négociation dynamique CPNP (pour « Connectivity Provisioning Negotiation Protocol »), décrit dans le document RFC 8921 de M. Boucadair et al., édité par l’I ETF et intitulé « Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP) », octobre 2020. En variante, d’autres protocoles que CPNP peuvent être utilisés, comme par exemple le protocole RESTCONF décrit dans le document I ETF RFC 8040 de A. Bierman et al. intitulé « RESTCONF Protocol », janvier 2017.
[0083] Lors de cette phase de négociation, le serveur d’application 4 envoie notamment au contrôleur réseau 2, via l’API COSI NUS, un message de souscription pour pouvoir bénéficier de la procédure COSI NUS pour le service S. Ce message de souscription contient au moins une adresse I P (et éventuellement un numéro de port, un nom de domaine, etc.) permettant de contacter (et ainsi de notifier) le serveur d’application 4. Dans l’exemple du serveur PCP exposé par le serveur d’application 4, cette adresse I P (et le cas échéant le numéro de port) peut être codée dans un champ « Contact_Locator » d’un message de souscription PCR
[0084] Le contrôleur réseau 2 accepte la souscription du serveur d’application 4 et lui envoie via l’API COSI NUS un identifiant, par exemple noté AS4_id, alloué par le réseau NW (par exemple par le contrôleur réseau 2) permettant d’identifier de façon non ambiguë (c’est-à-dire univoque) au niveau du réseau NW le serveur d’application 4 durant la procédure COSI NUS. Le contrôleur réseau 2 fournit également ici au serveur d’application 4 une plage d’adresses I P (I Pv4 et/ou I Pv6) ou de préfixes du réseau NW destinées à être utilisé(e)s par les dispositifs de communication lorsqu’ils accèdent au service S.
[0085] Dans une variante de réalisation, l’identifiant AS4_id est généré par le serveur d’application 4 lui-même et fourni au contrôleur réseau 2 dans son message de souscription. Dans cette variante, il convient au serveur d’application 4 de mettre en oeuvre une procédure pour s’assurer que l’identifiant AS4_id est globalement unique sur la pluralité de réseaux (dont le réseau NW) via lesquels le service S est susceptible d’être fourni.
[0086] Dans une autre variante encore, l’identifiant AS4_id peut être généré par une entité tierce (par exemple, l’IANA ou « I nternet Assigned Numbers Authority ») et fourni par cette entité tierce au contrôleur réseau 2 et/ou au serveur d’application AS 4.
[0087] Les informations échangées entre le contrôleur réseau 2 et le serveur d’application 4 lors de la phase de négociation/souscription sont enregistrées par ces derniers, par exemple pour le contrôleur réseau 2 dans une table nommée AS_COSI NUS_SUBSCRI - BERS stockée dans le réseau NW (de sorte à être accessible par des entités du réseau participant à la procédure COSI NUS telle que notamment l’entité de gestion 3), et pour le serveur d’application 4 dans une table nommée NTW_COSI NUS_SUBæRI PTIONS, stockée localement dans sa mémoire NVM.
[0088] On note que cette phase de négociation/souscription entre le contrôleur réseau 2 et le serveur d’application 4 peut être répétée entre le contrôleur réseau 2 et d’autres serveurs d’application associés par exemple à d’autres services que le service S, et/ou entre le serveur d’application 4 et d’autres contrôleur réseau d’autres réseaux que le réseau NW via lesquels le service S est susceptible d’être fourni. Ainsi la table AS_COSI- NUS_SUBæRI BERS maintenue par le contrôleur réseau 2 regroupe l’ensemble des informations échangées avec les serveurs d’application (dont le serveur d’application 4) ayant souscrit auprès du contrôleur réseau 2 à la procédure COSI NUS pour les services auxquels ils sont associés et qui sont fournis via le réseau NW, et la table NTW COSI- NUS_SUBSCRI PTI ONS maintenue par le serveur d’application 4 regroupe l’ensemble des informations échangées avec les contrôleur réseau des réseaux (dont le contrôleur réseau 2 du réseau NW) auprès desquels le serveur d’application 4 a souscrit à la procédure COSI NUS pour le service S.
[0089] Pour chaque serveur d’application 4 référencé dans la table AS_COSI NUS_SUBSCRI - BERS, l’opérateur du réseau NW (par l’intermédiaire du contrôleur réseau 2 ou d’une autre entité du réseau) met en place ou configure des filtres (permettant d’identifier le trafic associé au service S) et des sondes déployées dans le réseau NW pour collecter des informations reflétant l’impact environnemental et/ou énergétique du service S. Les filtres portent par exemple sur des adresses I P des différentes instances de service du serveur d’application 4 impliquées dans la fourniture du service S ; ces adresses I P sont par exemple communiquées par le serveur d’application 4 au contrôleur réseau 2 lors de la phase de négociation/ souscription.
[0090] Dans le mode de réalisation décrit ici, les informations collectées par les sondes déployées dans le réseau NW reflètent la consommation carbonée de l’ensemble des communications établies depuis ou vers les instances de service du ou des serveurs d’application impliquées dans la fourniture du service S. On note que le serveur d’application 4, bien qu’étant associé au service S, n’est pas nécessairement directement impliqué dans la fourniture de celui-ci. Toutefois, par souci de simplification ici, on suppose que le serveur d’application 4 non seulement gère l’accès au service S mais également fournit celui-ci et est le seul service d’application impliqué dans cette fourniture.
[0091 ] Dans une variante de réalisation, on peut envisager de collecter des informations reflétant l’impact environnemental et/ou énergétique du service S associé uniquement à certaines communications, par exemple à certains types de trafic, à un groupe d’utilisateurs particuliers, etc.
[0092] Les informations reflétant l’impact environnemental et/ou énergétique du service S collectées notamment par les sondes et en application des filtres fournis sont communiquées au contrôleur réseau 2 (étape E20), qui les agrège ensuite pour estimer au moins un indicateur I ND représentatif de l’impact environnemental et/ou énergétique du service S (étape E30). Le contrôleur réseau 2 peut utiliser par exemple, pour obtenir ces informations auprès des sondes, un protocole connu comme NETCONF ou I PFIX. L’obtention et l’agrégation par le contrôleur réseau 2 (via son module 2A d’estimation) des informations collectées par les sondes reflétant l’impact environnemental et/ou énergétique du service S peuvent avoir lieu de façon continue ou quasi-continue, ou à fréquence régulière, etc.
[0093] Dans l’exemple envisagé ici, comme évoqué précédemment, le contrôleur réseau 2 estime comme indicateur I ND l’empreinte carbone imputée au service S. Le contrôleur réseau 2 utilise par exemple à cet effet la méthode connue dite LCA (pour « Life-Cycle Assessment » en anglais) ou une méthode LCA simplifiée telle que décrite par exemple dans l’article de M. Ficher et al. intitulé « Assessing the carbon footprint of the data transmission on a backbone network », 24th Conference on I nnovation in Clouds, I nternet and Networks ( I Cl N 2021 ), 2021 . [0094] Bien entendu, d’autres indicateurs et d’autres méthodes pour estimer ces indicateurs peuvent être envisagés pour estimer l’impact environnemental et/ou énergétique du service S, comme par exemple une consommation d’énergie dans le réseau NW imputée au service S, un état de batterie, etc. Des exemples de tels indicateurs (ou métriques) sont décrits notamment dans le document de A. Qemm et al. édité par 1’1 ETF et intitulé « Green Networking Metrics », 16 juin 2023. Diverses méthodes pour estimer de tels indicateurs sont décrites notamment dans le document I ETF RFC 7577 de J. Quittek et al, intitulé « Definition of Managed objects for Batterty Monitoring », juillet 2015, dans le document I ETF RFC 7460 de M. Chandramouli et al, intitulé « Monitoring and Control MI B for Rower and Energy », octobre 2015, ou dans le document de l’Opsa Working Group, J. Lindblad et al., intitulé « Rower and Energy Efficiency », 20 octobre 2023.
[0095] Par ailleurs, dans une variante de réalisation, le contrôleur réseau 2 peut estimer une pluralité d’indicateurs I ND reflétant dans leur ensemble l’impact environnemental et/ou énergétique du service S (par exemple un indicateur I ND(1 ) représentant l’empreinte carbone du service S et un indicateur I ND(2) représentant sa consommation d’énergie). [0096] Le contrôleur réseau 2 (par exemple ici via son module 2A d’estimation) détermine ensuite si l’indicateur I ND estimé respecte un critère de conformité donné (critère CRI T ici), c’est-à-dire prédéterminé ou prédéfini (étape test E40). Par exemple, le contrôleur réseau 2 compare l’indicateur I ND avec une valeur seuil définie pour cet indicateur I ND et pour le service S et examine si l’indicateur I ND a franchi ou non cette valeur seuil. Typiquement, dans l’exemple de l’empreinte carbone, le contrôleur réseau 2 examine si celle-ci a dépassé un certain seuil correspondant à la valeur maximale que le réseau NW (c’est-à-dire l’opérateur du réseau) accepte (ou souhaite ou encore autorise) pour cette empreinte carbone pour le service S. Cette valeur maximale peut correspondre notamment à un quota de l’empreinte carbone du réseau que celui-ci a alloué au service S et que le service S ne doit pas dépasser. Ainsi, dans cet exemple illustratif, le critère de conformité CRI T est le dépassement par l’empreinte carbone du seuil/quota en question. Bien entendu, ceci n’est qu’un exemple illustratif et d’autres critères de conformité peuvent être envisagés en fonction des indicateurs considérés (par exemple, le franchissement d’un seuil minimal, une évolution particulière de l’indicateur, etc.).
[0097] S l’indicateur I ND respecte le critère de conformité CRIT (réponse oui à l’étape test E40), les étapes d’obtention E20, d’estimation E30 et de comparaison E40 au critère de conformité CRIT sont réitérées par le contrôleur réseau 2.
[0098] S l’indicateur I ND (ou l’un des indicateurs I ND) ne respecte pas le critère de conformité CRIT (réponse non à l’étape test E40), le contrôleur réseau 2, via son module 2B de notification, notifie le serveur d’application 4 (et plus particulièrement son serveur PCP) du non-respect du critère de conformité par l’indicateur I ND, autrement dit dans l’exemple de l’empreinte carbone, du dépassement par l’empreinte carbone du quota alloué par le réseau NW au service S (étape E50). Le contrôleur réseau 2 obtient les informations pour joindre le serveur d’application 4 (et plus particulièrement son serveur PCP) en consultant la table AS_COSI NUS_SUBæRI BERS. La notification envoyée par le contrôleur réseau 2 au serveur d’application 4 indique par ailleurs ici au serveur d’application 4 qu’une mesure de gestion de l’impact environnemental et/ou énergétique du service S (c’est-à-dire de son empreinte carbone ici) est requise.
[0099] Dans une variante de réalisation, on peut envisager que le contrôleur réseau 2 envoie également des notifications intermédiaires au serveur d’application 4 à chaque fois que l’indicateur I ND franchit divers seuils intermédiaires (par exemple 50% du quota alloué au service S, puis 75% de ce quota).
[0100] En référence à la figure 4, suite à la réception de la notification du contrôleur réseau 2 par le module 4A de réception du serveur d’application 4 (étape F20) , le serveur d’application 4 déclenche, par l’intermédiaire de son module 4Bde déclenchement, au moins une mesure de gestion ACT de l’impact environnement et/ou énergétique imputé au service S (c’est-à-dire ici de son empreinte carbone) (étape F30). La ou les mesures de gestion peuvent porter sur tout ou partie du trafic relatif au service S échangé via le réseau NW. I l peut s’agir notamment d’une mesure de limitation ou d’une mesure de neutralisation de l’impact environnemental et/ou énergétique imputé au service S, ou de toute autre mesure de gestion visant à maîtriser l’impact environnemental et/ou énergétique imputé au service S.
[0101 ] Dans le mode de réalisation décrit ici, la mesure de gestion ACT déclenchée par le serveur d’application 4 est un mécanisme d’ordonnancement programmable. Ce mécanisme s’appuie sur une utilisation mutualisée d’une (ou de plusieurs) ressource(s) donnée^) du réseau NW par plusieurs dispositifs de communication lors d’un accès au service S par ces dispositifs de communication et sur un ordonnancement temporel des dispositifs de communication en question pour accéder à la (ou les) ressource(s) mu- tualisée(s). D’autres exemples de mesures de gestion pouvant être envisagées ont été décrits précédemment.
[0102] Plus spécifiquement, dans l’exemple du service S de vidéo en streaming considéré ici à titre illustratif, la ressource qui est mutualisée est une tranche réseau dédiée SLopt supportée par le réseau NW, au sein de laquelle les flux vidéo sont diffusés selon un mode de transmission multicast en vertu de créneaux temporels déterminés (on parle de diffusion multicast programmée ou « slot-based multicast » en anglais). Un tel mode de transmission permet avantageusement d’envoyer un même contenu vidéo à plusieurs dispositifs de communication simultanément durant des créneaux de temps déterminés, par exemple des créneaux fixes de 1 mn, 5mn, 15mn, etc. Ce mode de diffusion programmée multicast de données est plus efficace en matière d’impact environnemental et/ou énergétique qu’un mode de transmission immédiate unicast des données au sein duquel un même contenu est dupliqué pour chaque dispositif de communication.
[0103] Pour mettre en place ce mode de diffusion programmée, le serveur d’application 4, par le biais de son module 4B de déclenchement, sélectionne ainsi pour chaque contenu vidéo à diffuser offert par le service S, identifié par un identifiant appelé contentjd ici, un ou plusieurs créneaux temporels ou slots (chacun étant identifié par un identifiant appelé slotjd ici) qu’il alloue à la transmission des données relatives à ce contenu vidéo sur la tranche réseau mutualisée SLopt. Ce ou ces créneaux temporels slotjd associés à un contenu vidéo contentjd sont ensuite alloués aux (répartis entre les) dispositifs de communication qui souhaitent accéder via le service S au contenu vidéo en question, plusieurs dispositifs de communication demandant à accéder au contenu vidéo au cours d’un intervalle de temps donné pouvant se voir allouer le même créneau temporel slotjd pour accéder au contenu, et ainsi accéder au contenu de façon simultanée. La mutualisation de la tranche réseau SLopt se traduit donc ici par une utilisation simultanée de cette tranche réseau par plusieurs dispositifs de communication. Ceci revient à déterminer l’ordonnancement temporel selon lequel les dispositifs de communication en question vont accéder au service Set plus particulièrement au contenu vidéo contentjd en utilisant la tranche réseau SLopt. [0104] Puis, le serveur d’application 4 notifie le contrôleur réseau 2, par l’intermédiaire de son module 4C de notification (et via éventuellement une API prévue à cet effet), de la ou des mesures de gestion ACT qu’il a déclenchées pour maîtriser (pour réduire par exemple) l’impact environnemental et/ou énergétique imputé au service S (étape F40) . Dans l’exemple envisagé ici, le serveur d’application 4 informe ainsi le contrôleur réseau 2 de l’utilisation mutualisée de la tranche réseau SLopt par une pluralité de dispositifs de communication accédant au service S et de l’ordonnancement décidé pour cette utilisation mutualisée en lui envoyant un message ACTI VATE( SLopt, SCHEDULE), SCHEDULE désignant une information représentative dudit ordonnancement et plus particulièrement des associations entre contentjd et slotjd. Une durée de validité peut être associée à la mesure de gestion et transmise dans le message ACTI VATE, par exemple, le temps que l’indicateur I ND imputé au service S devienne conforme ou soit réinitialisé pour le serveur d’application 4 et/ou le service S).
[0105] Dans le mode de réalisation décrit ici, suite à la réception de la notification ACTI VATE l’informant du déclenchement d’une mesure (ou de mesures) de gestion par le serveur d’application 4 (réponse oui à l’étape test E60), le contrôleur réseau 2 configure au moins une entité du réseau en support de cette mesure de gestion (étape E70). Plus particulièrement, dans l’exemple envisagé ici, lors de l’étape E70, le module 2D de configuration du contrôleur réseau 2 configure les noeuds de périphérie (ou BR pour « Border Routers » en anglais) du réseau NW avec des règles de classification du trafic mises à jour pour que les paquets de données relatifs au service S et reçus du serveur d’application 4 ou destinés au serveur d’application 4 soient associés à la tranche réseau SLopt. L’identifiant contentjd associé à chaque flux de données (flux de contenu vidéo dans l’exemple envisagé ici) transportant des paquets de données relatifs au service S reçus du serveur d’application 4 émis selon un mode de transmission multicast sur la tranche réseau SLopt est partagé avec le contrôleur réseau 2 et les noeuds de périphérie BR configurés par ce dernier pour qu’ils soient en mesure d’identifier les flux concernés.
[0106] Le contrôleur réseau 2 confirme la prise en compte de la mesure de gestion notifiée par le serveur d’application 4, et la configuration des noeuds de périphérie BR du réseau NW pour permettre la mise en oeuvre de cette mesure de gestion (étape E80). Dès lors, suite à la réception de cette confirmation (étape F50) , le serveur d’application 4 peut procéder à la fourniture du service S via son module 4E de fourniture, et plus particulièrement, dans l’exemple envisagé ici, à la diffusion programmée du ou des flux d’un contenu vidéo contentjd en mode multicast vers la tranche réseau SLopt, selon l’ordonnancement SCHEDULE décidé par le serveur d’application 4 lors de l’étape F30 (étape F60). Un arbre de distribution multicast déployé dans la tranche réseau SLopt pour chaque association entre un identifiant contentjd et un ou plusieurs identifiants slotjd dans l’ordonnancement SCHEDULE est alors utilisé dans le réseau NW pour acheminer les données jusqu’aux dispositifs de communication connectés au réseau NW ayant souscrit au(x) groupe(s) multicast correspondant(s).
[0107] En variante, on peut envisager un arbre de diffusion pour plusieurs contenus différents (c’est-à-dire plusieurs identifiants contentjd).
[0108] Dans le mode de réalisation décrit ici, si à l’issue d’une période de temps déterminée, notée ici Tmax, le contrôleur réseau 2 n’est pas notifié (c’est-à-dire informé) par le serveur d’application 4 du déclenchement d’une mesure de gestion de l’impact environnemental et/ou énergétique imputé au service S (réponse non à l’étape test E60), il active dans le réseau NW un traitement pour tout ou partie du trafic relatif au service S en réponse au non-respect du critère de conformité CRI T par l’indicateur I ND(étape E90) . Ce traitement vise par exemple à réduire ou à neutraliser l’impact environnemental et/ou énergétique imputé au service S. Dans le mode de réalisation décrit ici, le module 2D de déclenchement embarqué dans le contrôleur réseau 2 déclenche à cet effet une mesure de gestion par défaut ACT- DEF consistant à basculer tout ou partie du trafic relatif au service S et transitant via le réseau NW vers une tranche réseau notée SL-LBE déterminée parmi les tranches réseau SL1 , . . SLK supportées par le réseau NW, la tranche réseau SL-LBE fournissant un niveau de service dégradé par rapport à un niveau de service attendu pour le service S. Un tel niveau de service dégradé est par exemple un niveau de qualité de service adapté au mieux aux conditions d’accès au service aussi plus couramment désigné par « Best effort » en anglais ou un niveau de service inférieur à ce niveau de service « Best Effort « aussi désigné LBE pour « Lower than Best Effort » en anglais. Bien entendu, d’autres alternatives peuvent être envisagées. L’étape d’activation E90 s’accompagne d’une configuration par le contrôleur réseau 2, via son module 2D de configuration, des noeuds de périphérie BR du réseau NW (et plus particulièrement du réseau d’accès) avec des règles de classification du trafic mises à jour pour que le trafic relatif au service S soit associé à cette tranche réseau SL-LBE (étape E100). Cette configuration des noeuds de périphérie BR peut se faire directement ou indirectement via un contrôleur. Les règles de classification mises à jour sont également communiquées aux dispositifs de communication accédant au service S.
[0109] Le contrôleur réseau 2 peut par ailleurs, via son module 2C de notification, informer le serveur d’application 4 que le trafic relatif au service S sera dès lors reclassé à l’entrée du réseau NW pour être dirigé (acheminé) vers la tranche réseau SL-LBE (étape E110). [0110] En outre, dans le mode de réalisation décrit ici, dès que le contrôleur réseau 2 détecte que l’indicateur I ND représentatif de l’impact environnemental et/ou énergétique respecte le critère de conformité CRI T (par exemple, suite au déclenchement de la mesure de gestion ACT-DER l’impact environnemental et/ou énergétique imputé au service S a diminué, ou l’indicateur I ND a été réinitialisé), le contrôleur réseau 2 annule le traitement activé par défaut par son module 2D lors de l’étape E90 (autrement dit, la mesure de gestion par défaut ACT-DEF). Dans l’exemple envisagé ici, cela se traduit par la réinstallation des tranches réseau utilisées habituellement pour accéder au service S (et la configuration des noeuds de périphérie BR en conséquence).
[011 1 ] En variante, d’autres traitements peuvent être activés par le contrôleur réseau 2 en l’absence de mesure de gestion de l’impact environnemental et/ou énergétique imputé au service Sdéclenchée par le serveur d’application 4. Par exemple, le contrôleur réseau peut activer un re-marquage du trafic relatif au service S pour le stocker dans une autre file d’attente, un écrêtage (« rate limit » en anglais) ou un rejet de tout ou partie des paquets de données relatifs au service S, une redirection des paquets de données relatifs au service S vers un portail captif, etc.
[0112] Nous allons maintenant, en référence aux figures 4, 5 et 6, illustrer comment le déclenchement d’une ou de plusieurs mesures de gestion ACT de l’impact environnemental et/ou énergétique imputé au service S se traduit au niveau d’un dispositif de communication accédant au service S, et plus particulièrement du dispositif de communication 5. [0113] Dans le mode de réalisation décrit ici, en référence à la figure 6, on suppose en préliminaire que le dispositif de communication 5 procède à la découverte (étape G10) d’au moins une entité de gestion 3 de tranches de réseau supportées par le réseau NW susceptible d’être impliquée dans la procédure COSI NUS et notamment dans certaines mesures de gestion prises pour réduire (voire neutraliser) l’impact environnemental et/ou énergétique imputé au service S, typiquement ici son empreinte carbone. Une ou plusieurs entités de gestion 3 peuvent être présentes dans le réseau NW pour la mise en oeuvre de la procédure COSI NUS (aussi appelées ici « relais COSI NUS »). Par souci de simplification, on considère toutefois ici une seule entité de gestion 3 de tranches réseau conforme à l’invention dans le réseau NW, c’est-à-dire un seul relais COSI NUS.
[01 14] L’étape G10 de découverte peut être mise en oeuvre de différentes façons.
[01 15] Ainsi, dans une première variante de réalisation, l’entité de gestion 3 peut être configurée au niveau du dispositif de communication 5 par le réseau NW (c’est-à-dire par son opérateur). Par exemple, le réseau NW fournit au dispositif de communication 5 au moins une adresse I P et un numéro de port associés à l’entité de gestion 3 de tranches réseau et permettant de la joindre. En variante, le réseau peut également fournir au dispositif de communication 5 un identifiant d’authentification (ou ADN pour « Authentication Domain Name » en anglais) associé à l’entité de gestion 3 pour lui permettre de s’authentifier auprès de cette dernière. Cette configuration par le réseau NW peut se faire en utilisant un protocole dédié, tel que par exemple le protocole DHCP (pour « Dynamic Host Configuration Protocol » en anglais), ou via un message d’annonce de routeur ou RA (pour « Router Advertisement » en anglais), etc.
[01 16] Dans une deuxième variante, le dispositif de communication 5 peut utiliser une adresse anycast ou multicast pour envoyer un message de découverte des entités de gestion de tranches réseau 3 opérant dans le réseau NW. L’entité de gestion 3 répond alors au message de découverte en envoyant par exemple une adresse I P et un numéro de port (et le cas échéant, un identifiant d’authentification) tels que décrits dans la première variante.
[01 17] Dans une troisième variante, le dispositif de communication 5 peut utiliser un nom de domaine réservé pour une utilisation spéciale ou SUDN (pour « Special-Use Domain Names), tel que décrit dans le document RFC 6761 de S. Cheshire et al. édité par l’I ETF et intitulé « Special-Use Domain Names », février 2013, et requérir des résolutions de nom de domaine associées à ce nom de domaine réservé en vue d’obtenir des enregistrements de ressources (ou RR pour « Ressource Record » en anglais) de type SVBC des entités de gestion 3, comme décrit dans le document I ETF RFC 9460 édité par B. Schwartz et al. intitulé « Service binding and parameter specification via the DNS (DNS SVCB and HTTPSSVC) », novembre 2023. On suppose par exemple que l’enregistrement RR SVCB d’une entité de gestion 3 conforme à l’invention comprend un paramètre « SvcParam » défini pour les besoins de l’invention et nommé ici COSI NUS, indiquant le support de la procédure COSI NUS par l’entité de gestion 3 en question. Le RR SVCB peut également comprendre une liste de types et/ou d’identifiants de tranches réseau gérées par l’entité de gestion 3.
[01 18] Suite au déclenchement de la mesure de gestion ACT par le serveur d’application 4 lors de l’étape F30 décrite précédemment, le serveur d’application 4 procède comme décrit ci-après pour les dispositifs de communication connectés au réseau NW et accédant au service S via le réseau NW.
[01 19] On suppose ainsi que le dispositif de communication 5 envoie, via son module 5Ad’envoi, une demande d’accès REQ-S au service S au serveur d’application 4 (étape G20), et plus particulièrement dans l’exemple illustratif d’un service S de vidéo en streaming envisagé ici, une demande d’accès en streaming à un contenu vidéo CONT. La demande REQ-S est envoyée par le dispositif de communication 5 via une tranche réseau à laquelle il est connecté, par exemple ici la tranche réseau SL1 . La demande d’accès REQ- S comprend une adresse I P source fournie au dispositif de communication 5 par le réseau NW et qui se trouve dans la plage d’adresses I P fournie par le contrôleur réseau 2 lors de la souscription du serveur d’application 4 à la procédure COSI NUS (étape E10/F10 décrites précédemment) .
[0120] Suite à la réception de cette demande d’accès REQ-S (étape F61 , figure 4), le serveur d’application 4 extrait l’adresse I P source de la demande d’accès REQ-S et vérifie si cette adresse I Pcorrespond à une plage d’adresses I Pconsignée dans la table NTW CO- SI NUSJSUBSCRI PTIONS maintenue par le serveur d’application 4. I l vérifie par ailleurs si une notification de non-conformité d’un indicateur représentatif de l’impact environnemental et/ou énergétique imputé au service S a été reçue du contrôleur réseau 2 du réseau NW (étape test F62) .
[0121 ] S le serveur d’application 4 ne trouve aucune entrée dans la table NTW COSI- NUS SUBSCRI PTI ONS ou si aucune notification n’a été reçue du contrôleur 2 du réseau NW pour le service S (réponse non à l’étape test F62), alors la demande d’accès REQ- S au service S, puis les paquets de données échangés dans le cadre de l’accès au service S (à destination ou en provenance du dispositif de communication 5), sont traités par le réseau NW et par le serveur d’application 4 de façon conventionnelle, c’est-à-dire en utilisant une tranche réseau parmi les tranches réseau SL1 , ..., SLK supportées par le réseau NW à laquelle le dispositif de communication 5 est connecté et qui est adaptée au service S de façon connue en soi, par exemple la tranche réseau SL1 (étape F63) .
[0122] Dans l’exemple envisagé ici, une notification a été reçue lors de l’étape F20 du contrôleur réseau 2 du réseau NW et une mesure de gestion ACT de l’impact environnemental et/ou énergétique imputé au service S a été déclenchée par le serveur d’application 4 à l’étape F30, en réponse à cette notification.
[0123] S le serveur d’application 4 trouve une entrée dans la table NTW_COSI NUS_SUBSCRI P- TI ONS et une notification de non-conformité de l’impact environnemental et/ou énergétique a été reçue (réponse oui à l’étape test F62), ce qui est le cas dans l’exemple envisagé ici, alors la mesure de gestion ACT déclenchée par le serveur d’application 4 est appliquée au trafic relatif au service S échangé avec ce dispositif de communication 5 (c’est-à-dire au trafic émis par le dispositif de communication 5 et au trafic destiné au dispositif de communication 5 dans le cadre de son accès au service S). Plus particulièrement, dans l’exemple illustratif envisagé ici, le trafic relatif au service S associé au dispositif de communication 5 et notamment le contenu vidéo CONT est véhiculé via la tranche réseau mutualisée SLopt et sa fourniture aux dispositifs de communication utilisant de façon mutualisée la tranche réseau SLopt est organisée selon l’ordonnancement SCHEDULE déterminé par le serveur d’application 4, c’est-à-dire pendant le créneau temporel identifié par slotjd associé à l’identifiant contentjd correspondant au contenu vidéo CONT (étape F64). Le serveur d’application 4 sélectionne donc pour le dispositif de communication 5 le créneau temporel identifié par slotjd pour lui permettre d’accéder au contenu CONT.
[0124] Puis, dans le mode de réalisation décrit ici, le serveur d’application 4 notifie (c’est-à-dire informe) via son module 4Cde notification le dispositif de communication 5 de la mesure de gestion ACT déclenchée et appliquée au trafic relatif au service S le concernant, c’est-à-dire émis à destination du dispositif de communication 5 ou provenant de celui- ci. Dans l’exemple envisagé ici, le module 4C de notification envoie un message de notification au dispositif de communication 5 l’informant de l’utilisation de la tranche réseau mutualisée SLopt lors de l’accès par le dispositif de communication 5 au service S et du créneau temporel slotjd alloué pour la transmission du contenu contentjd sur la tranche réseau SLopt (étape F65) . Ce message de notification comprend ici, outre un identifiant de la tranche réseau mutualisée SLopt, une indication selon laquelle le contenu vidéo CONT auquel le dispositif de communication 5 souhaite accéder en streaming n’est par exemple pas immédiatement diffusé sur la tranche réseau mutualisée SLopt en réponse à la demande d’accès REQ-S au service S, mais à une échéance donnée correspondant à l’identifiant slotjd (par exemple, 30s, 1 mn, 3mn).
[0125] On note que dans le mode de réalisation décrit ici, on a envisagé un ordonnancement statique SCHEDULE déterminé par le serveur d’application 4 et notifié au contrôleur 2 lors de l’étape F40 en amont de l’accès à proprement parler au service S. Toutefois, cela n’exclut pas que cet ordonnancement évolue dans le temps (et donc que le serveur d’application 4 envoie au contrôleur 2 plusieurs messages reflétant cette évolution), notamment en fonction des demandes d’accès reçues par le serveur d’application 4 de dispositifs de communication. Par ailleurs, en variante, on peut envisager que le serveur d’application 4 détermine dynamiquement, en fonction des demandes d’accès au service S reçues de dispositifs de communication au cours par exemple d’un intervalle de temps déterminé, l’ordonnancement SCHEDULE qu’il envisage d’appliquer pour l’accès au service S par les dispositifs de communication en question, via la tranche réseau SLopt.
[0126] Le dispositif de communication 5 confirme la réception (étape G30) et la prise en compte du message de notification (étape G40).
[0127] Sur réception de cette confirmation, le serveur d’application 4 ajoute, dans un cache local se trouvant par exemple dans sa mémoire non volatile NVM, le dispositif de communication 5 à une liste des dispositifs de communication destinataires du contenu vidéo CONT diffusé sur la tranche réseau mutualisée SLopt, et obtient un identifiant noté I D5 pour le dispositif de communication 5. Par exemple, cet identifiant I D5 est généré pour le dispositif de communication 5 par le serveur d’application 4 aléatoirement, par exemple par un module (ou une instance de service) responsable de la gestion des connexions de l’ensemble des dispositifs de communication au serveur d’application 4. En variante, on peut envisager un identifiant généré par connexion ou par session de service pour le dispositif de communication 5 ; cette variante peut être adoptée en fonction de la nature du service, par exemple s’il s’agit d’un service de type transactionnel.
[0128] Le serveur d’application 4 envoie au dispositif de communication 5 son propre identifiant AS4Jd, l’identifiant I D5 généré pour le dispositif de communication 5 ainsi que l’identifiant slotjd indiquant le créneau temporel alloué au dispositif de communication 5 pour la transmission selon un mode de transmission multicast du trafic relatif au service S le concernant et l’identifiant contentjd associé au contenu vidéo CONT (étape F66). Le serveur d’application 4 crée par ailleurs un contexte associé au dispositif de communication 5 dans son cache local, dans lequel il mémorise les identifiants I D5, slotjd et contentjd.
[0129] Le serveur d’application 4 procède de façon identique avec les autres dispositifs de communication souhaitant accéder au même contenu CONT que le dispositif de communication 5 et concernés par la mesure de gestion ACT.
[0130] Suite à la réception de ces identifiants par le dispositif de communication 5 (étape G50), celui-ci envoie une demande d’accès REQ-SLopt à la tranche réseau mutualisée SLopt à l’entité de gestion 3 (relais COSI NUS) des tranches réseau supportées par le réseau NW (et en particulier de la tranche réseau SLopt), découverte lors de l’étape de découverte G10 (étape G60). En variante, l’étape G10 de découverte peut être mise en oeuvre par le dispositif de communication 5 suite à l’étape G50 de réception des identifiants fournis par le serveur d’application 4 ou à tout moment avant cette étape de réception. [0131 ] Dans le mode de réalisation décrit ici, la demande d’accès REQ-SLopt à la tranche réseau mutualisée SLopt prend la forme d’une demande de souscription au groupe multicast dont l’arbre de distribution multicast est associé aux identifiants slotjd et contentjd et déployé au sein de cette tranche réseau. On suppose que l’adresse de groupe multicast correspondant au déploiement de l’arbre de distribution a été diffusée précédemment par l’entité de gestion 3. Dans le mode de réalisation décrit, la demande d’accès envoyée par le dispositif de communication 5 comprend les différents identifiants fournis par le serveur d’application 4 au dispositif de communication 5 (I D5, AS4_id, slotjd et contentjd).
[0132] Dans un mode de réalisation, la demande de souscription envoyée est un message « MLD Report » du protocole MLD (pour « Multicast Listener Group » en anglais), modifié pour les besoins de l’invention pour inclure notamment les identifiants précités, lorsque le réseau NW utilise le protocole I Pv6. Lorsque le réseau NW utilise le protocole I Pv4, il peut s’agir d’un message IGMP (pour « I nternet Group Management Protocol » en anglais). Dans un autre mode de réalisation, la demande d’accès à la tranche réseau mutualisée SLopt prend la forme d’une demande de souscription « MLD Report » classique à l’arbre de distribution multicast et est accompagnée d’un message conforme au protocole ICMPv6 (pour « I nternet Control Message Protocol version 6 » en anglais), véhiculant les différents identifiants fournis par le serveur d’application 4 au dispositif de communication 5 (I D5, AS4Jd, slotjd et contentjd). Le message ICMPv6 a pour but de déclencher l’envoi d’un message « MLD Query » par l’entité de gestion 3. Ce message MLD est envoyé typiquement par le routeur auquel est connecté le dispositif sous contrôle de l’entité de gestion 3.
[0133] En référence à la figure 5, l’entité de gestion 3 reçoit la demande REQ-SLopt du dispositif de communication 5 via son module 3A de réception (étape H10). L’entité de gestion 3 extrait les identifiants I D5, AS4Jd, slotjd et contentjd contenus dans la demande REQ-SLopt et procède à diverses vérifications sur la base de ces identifiants (étape H20). [0134] Plus particulièrement, dans le mode de réalisation décrit ici, l’entité de gestion 3 consulte la table AS_COSI N US SUBSCRI BERS stockée dans le réseau NW et détermine si une entrée de la table est associée à l’identifiant AS4Jd. Le cas échéant, l’entité de gestion 3 récupère dans la table AS_COSI NUS SUBSCRI BERS les informations permettant de joindre le serveur d’application 4 (adresse I P et le cas échéant numéro de port notamment du serveur PCP utilisé par le serveur d’application 4, fournis par ce dernier dans le champ « Contact_Locator » lors de la phase préliminaire de négociation/sous- cription avec le contrôleur réseau 2).
[0135] Puis l’entité de gestion 3 vérifie, via son module 3B de vérification, auprès du serveur PCP du serveur d’application 4 en utilisant les informations obtenues, que le dispositif de communication 5 est bien autorisé (habilité) à accéder à la tranche réseau SLopt. Dans le mode de réalisation décrit ici, le module 3B de vérification de l’entité de gestion 3 envoie à cet effet une requête PCP au serveur PCP du serveur d’application 4 incluant une option appelée ici COSI NUSJDR définie pour les besoins de l’invention, contenant ici les identifiants I D5, AS4Jd, slotjd et contentjd. La f igu re 7 illustre un exemple de format pour une telle option, le code d’option (TBA pour « To Be Assigned » en anglais) étant fourni par 1’1 ANA dans un contexte de standardisation.
[0136] En référence à la figure 4, sur réception de la requête PCP de l’entité de gestion 3, le serveur PCP du serveur d’application 4 (et plus particulièrement le module 4D de vérification intégré dans le serveur PCP) vérifie si un contexte correspondant aux identifiants I D5, slotjd et contentjd reçus dans la requête PCP est maintenu dans le cache local du serveur d’application 4 (étape F67). S aucun contexte correspondant aux identifiants I D5, slotjd et contentjd n’est maintenu par le serveur d’application 4, alors un message d’erreur est envoyé par le module 4D de vérification du serveur d’application 4 à l’entité de gestion 3 lui indiquant que le dispositif de communication 5 n’est pas autorisé à utiliser la tranche réseau mutualisée SLopt. L’entité de gestion 3, par le biais de son module 3B de vérification, rejette la demande REQ-SLopt du dispositif de communication 5. Elle peut éventuellement informer également une plateforme dédiée.
[0137] Au contraire, si un contexte correspondant aux identifiants I D5, slotjd et contentjd est maintenu par le serveur d’application 4, alors une réponse positive confirmant que le dispositif de communication 5 est autorisé à accéder à la tranche réseau mutualisée SLopt est envoyée par le module 4D de vérification à l’entité de gestion 3.
[0138] Sur réception de cette réponse positive, l’entité de gestion 3 accepte la demande REQ- SLopt (et ainsi la demande de souscription à l’arbre de distribution multicast associé à la tranche réseau mutualisée SLopt) (étape H30), et déclenche, via son module 3C de déclenchement, le raccordement du dispositif de communication 5 à la tranche réseau mutualisée SLopt (étape H40).
[0139] Dans ce mode de réalisation, le raccordement du dispositif de communication 5 à la tranche réseau mutualisée SLopt est déclenché par l’entité de gestion 3, c’est-à-dire à l’initiative du réseau NW. En variante, on peut envisager que ce soit le dispositif de communication 5 qui soit à l’initiative de son raccordement à la tranche réseau mutualisée SLopt, la demande de raccordement du dispositif de communication 5 pouvant être faite auprès de l’entité idoine du réseau NW gérant la tranche réseau SLopt (par exemple l’entité de gestion 3 ou une autre entité de gestion de la tranche réseau SLopt) avant ou simultanément à l’envoi de sa demande de souscription à l’arbre de distribution multicast associé à la tranche réseau mutualisée SLopt.
[0140] Suite au raccordement du dispositif de communication 5 à la tranche réseau mutualisée SLopt (étape G70), le dispositif de communication 5 accède au service S via la tranche réseau mutualisée SLopt (étape G90). Plus spécifiquement dans l’exemple d’un service de streaming vidéo envisagé ici, le contenu vidéo identifié par l’identifiant contentjd est transmis au dispositif de communication 5 par le module 4E de fourniture du serveur d’application 4 via la tranche réseau mutualisée SLopt lors du créneau temporel identifié par l’identifiant slotjd (étape F68 sur la figure 5). Le créneau temporel identifié par slotjd est ainsi utilisé pour délivrer simultanément le contenu vidéo CONT à plusieurs dispositifs de communication (incluant le dispositif de communication 5) via la tranche réseau SLopt.
[0141 ] La mesure de gestion ACT peut être mise en oeuvre de façon durable ou être désactivée suite à la détection par le contrôleur 2 que l’indicateur I ND représentatif de l’impact environnemental et/ou énergétique imputé au service S est devenu conforme au critère CRI T.

Claims

Revendications
[Revendication 1] Procédé de supervision par un contrôleur réseau (2) d’un réseau, ledit procédé comprenant : une étape (E30) d’estimation d’au moins un indicateur (I ND) représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via ledit réseau ; et si ledit au moins un indicateur ne respecte pas un critère (CRIT) de conformité donné, une étape (E50) de notification d’un serveur d’application associé au service du non-respect par ledit indicateur dudit critère de conformité.
[ Revendication 2] Procédé de supervision selon la revendication 1 comprenant en outre en l’absence à l’issue d’une période déterminée d’un déclenchement d’au moins une mesure de gestion de l’impact environnemental et/ou énergétique par le serveur d’application suite à sa notification, une étape (E90) d’activation dans ledit réseau, pour tout ou partie du trafic relatif audit service, d’au moins un traitement (ACT-DEF) en réponse au non-respect du critère de conformité.
[ Revendication 3] Procédé de supervision selon la revendication 2 dans lequel ledit au moins un traitement (ACT-DEF) comprend un basculement de tout ou partie du trafic relatif audit service transitant via ledit réseau vers une tranche réseau (SL- LBE) fournissant un niveau de service dégradé par rapport à un niveau de service attendu pour ledit service.
[ Revendication 4] Procédé de supervision selon l’une quelconque des revendications 1 à 3, dans lequel l’étape (E30) d’estimation comprend une réception (E20) en provenance d’au moins une sonde déployée dans le réseau d’au moins une information reflétant un impact environnemental et/ou énergétique d’au moins une communication relative audit service établie depuis ou vers un serveur impliqué dans une fourniture dudit service.
[ Revendication 5] Procédé de supervision selon l’une quelconque des revendications 1 à 4 comprenant en outre : une étape de réception, en provenance du serveur d’application, d’une notification d’une utilisation mutualisée par plusieurs dispositifs de communication d’au moins une ressource donnée (SLopt) du réseau lors d’un accès audit service par lesdits dispositifs de communication ; et une étape (E70) de configuration d’au moins une entité du réseau pour permettre cette utilisation mutualisée.
[ Revendication 6] Procédé de supervision selon la revendication 5 dans lequel ladite au moins une ressource donnée comprend une tranche réseau donnée (SLopt) supportée par ledit réseau et ladite notification reçue du serveur d’application comprend une information représentative d’un ordonnancement (SCHEDULE) d’un accès au service par des dispositifs de communication via ladite tranche réseau.
[ Revendication 7] Procédé de gestion par un serveur d’application (4) d’un service fourni via au moins un réseau, ledit procédé comprenant : une étape (F20) de réception, en provenance d’un contrôleur réseau (2) dudit réseau, d’une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et une étape (F30) de déclenchement d’au moins une mesure (ACT) de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service.
[ Revendication 8] Procédé de gestion selon la revendication 7 dans laquelle ladite au moins une mesure de gestion est choisie parmi au moins : une utilisation d’un encodage des données relatives audit service ayant une contribution à l’impact environnemental et/ou énergétique imputé audit service plus faible qu’un encodage courant ; une restriction d’un accès audit service via ledit réseau ; un ordonnancement d’un accès audit service par une pluralité de dispositifs de communication ; une utilisation mutualisée d’au moins une ressource donnée du réseau par plusieurs dispositifs de communication lors d’un accès audit service par lesdits dispositifs de communication ; un marquage d’un trafic relatif audit service pour le stocker dans au moins une file d’attente.
[ Revendication 9] Procédé de gestion selon la revendication 7 ou 8 comprenant, lorsque ladite au moins une mesure de gestion (ACT) comprend un ordonnancement (SCHEDULE) d’un accès audit service par une pluralité de dispositifs de communication, suite à une demande d’accès au service par au moins un dispositif de communication, une étape de sélection pour ledit au moins un dispositif de communication d’un créneau temporel (slotjd) alloué à ladite pluralité de dispositifs de communication pour l’accès audit service.
[ Revendication 10] Procédé de gestion selon l’une quelconque des revendications 7 à 9 dans lequel ladite au moins une mesure de gestion comprend une utilisation mutualisée par plusieurs dispositifs de communication lors d’un accès audit service, selon un ordonnancement déterminé, d’une tranche réseau (SLopt) donnée supportée par ledit réseau.
[ Revendication 11 ] Procédé de gestion selon la revendication 10 comprenant au moins une étape parmi : une étape (F40) de notification dudit contrôleur réseau de l’utilisation mutualisée de ladite tranche réseau donnée par lesdits dispositifs de communication selon ledit ordonnancement déterminé ; et une étape (F65) de notification desdits dispositifs de communication de ladite tranche réseau donnée à utiliser de façon mutualisée par lesdits dispositifs de communication lors d’un accès au service et dudit ordonnancement déterminé qui doit être appliqué.
[ Revendication 12] Procédé de gestion selon la revendication 10 ou 11 comprenant en outre une étape (F67) de réception en provenance d’une entité (3) du réseau d’une demande de vérification qu’un dispositif de communication (5) est autorisé à accéder à ladite tranche réseau donnée (SLopt) .
[ Revendication 13] Procédé de gestion selon l’une quelconque des revendications 7 à 12 comprenant : une étape (F61 ) de réception d’une demande d’accès au service en provenance d’un dispositif de communication (5) ; si ledit dispositif de communication est concerné par une dite mesure de gestion, une étape d’application (F64) de cette mesure de gestion au trafic relatif au service en provenance ou à destination dudit dispositif de communication.
[ Revendication 14] Procédé de gestion, par une entité (3) d’un réseau, d’un accès à une tranche réseau supportée par le réseau, ledit procédé comprenant : une étape (H10) de réception, en provenance d’un dispositif de communication (5), d’une demande d’accès à une tranche réseau donnée (SLopt) supportée par le réseau, ladite tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau, suite à une notification reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; une étape (H20) de vérification, auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et le cas échéant, une étape (H40) de déclenchement d’un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée.
[ Revendication 15] Procédé d’accès, par un dispositif de communication (5), à un service (S) fourni via un réseau, ledit procédé comprenant : une étape (G20) d’envoi d’une demande d’accès au service à un serveur d’application (4) associé audit service ; une étape (G30) de réception d’une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique.
[ Revendication 16] Procédé d’accès selon la revendication 15 dans lequel ladite au moins une mesure de gestion comprend une utilisation mutualisée selon un ordonnancement déterminé, lors d’un accès audit service, d’une tranche réseau donnée supportée par ledit réseau par plusieurs dispositifs de communication dont ledit dispositif de communication, et ledit procédé comprend : une étape (G60) d’envoi à une entité du réseau, d’une demande d’accès à ladite tranche réseau (SLopt) donnée mutualisée ; et suite au raccordement (G80) dudit dispositif de communication à ladite tranche réseau donnée mutualisée, une étape (G90) d’accès audit service via ladite tranche réseau donnée mutualisée.
[ Revendication 17] Contrôleur réseau (2) d’un réseau comprenant : un module (2A) d’estimation, configuré pour estimer au moins un indicateur représentatif d’un impact environnemental et/ou énergétique imputé à un service fourni via ledit réseau ; et un module (2B) de notification, activé si ledit au moins indicateur estimé ne respecte pas un critère de conformité donné, et configuré pour notifier un serveur d’application associé au service de ce non-respect dudit critère de conformité par ledit au moins un indicateur.
[ Revendication 18] Serveur d’application (4) configuré pour gérer un service fourni via au moins un réseau, ledit serveur d’application comprenant : un module (4A) de réception, configuré pour recevoir en provenance d’un contrôleur réseau dudit réseau, une notification d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; et un module (4B) de déclenchement, configuré pour déclencher au moins une mesure de gestion dudit impact environnemental et/ou énergétique, ladite mesure de gestion portant sur tout ou partie du trafic relatif audit service.
[ Revendication 19] Entité (3) d’un réseau, configurée pour gérer un accès à une tranche réseau supportée par le réseau, ladite entité comprenant : un module (3A) de réception, configuré pour recevoir en provenance d’un dispositif de communication, une demande d’accès à une tranche réseau donnée supportée par le réseau, cette tranche réseau étant mutualisée entre plusieurs dispositifs de communication accédant à un service fourni via le réseau, suite à une notification, reçue par un serveur d’application associé audit service d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif d’un impact environnemental et/ou énergétique imputé audit service ; un module (3B) de vérification, configuré pour vérifier auprès du serveur d’application associé audit service, que ledit dispositif de communication est autorisé à accéder à ladite tranche réseau donnée mutualisée ; et un module (3C) de déclenchement activé le cas échéant et configuré pour déclencher un raccordement dudit dispositif de communication à ladite tranche réseau donnée mutualisée.
[ Revendication 20] Dispositif (5) de communication comprenant : un module (5A) d’envoi, configuré pour envoyer à un serveur d’application associé à un service fourni via un réseau, une demande d’accès audit service ; et un module (5B) de réception, configuré pour recevoir une notification en provenance du serveur d’application informant ledit dispositif de communication d’une application au trafic relatif audit service en provenance ou à destination dudit dispositif de communication d’au moins une mesure de gestion d’un impact environnemental et/ou énergétique imputé au service, suite à une notification, reçue par ledit serveur d’application d’un contrôleur réseau du réseau, d’un non-respect d’un critère de conformité donné par au moins un indicateur, estimé par le contrôleur réseau, représentatif dudit impact environnemental et/ou énergétique.
PCT/EP2024/086006 2023-12-15 2024-12-12 Procédés de supervision, de gestion d'un service, de gestion d'un accès à une tranche réseau et d'accès à un service, et dispositifs configurés pour mettre en oeuvre ces procédés Pending WO2025125478A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FRFR2314310 2023-12-15
FR2314310A FR3157047A1 (fr) 2023-12-15 2023-12-15 Procédés de supervision, de gestion d’un service, de gestion d’un accès à une tranche réseau et d’accès à un service, et dispositifs configurés pour mettre en œuvre ces procédés

Publications (1)

Publication Number Publication Date
WO2025125478A1 true WO2025125478A1 (fr) 2025-06-19

Family

ID=90123182

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2024/086006 Pending WO2025125478A1 (fr) 2023-12-15 2024-12-12 Procédés de supervision, de gestion d'un service, de gestion d'un accès à une tranche réseau et d'accès à un service, et dispositifs configurés pour mettre en oeuvre ces procédés

Country Status (2)

Country Link
FR (1) FR3157047A1 (fr)
WO (1) WO2025125478A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230138727A1 (en) * 2021-10-29 2023-05-04 Kyndryl, Inc. Carbon footprint-based control of cloud resource consumption

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230138727A1 (en) * 2021-10-29 2023-05-04 Kyndryl, Inc. Carbon footprint-based control of cloud resource consumption

Non-Patent Citations (13)

* Cited by examiner, † Cited by third party
Title
A. BIERMAN ET AL., RESTCDNF PROTOCOL, 2017
A. OEMM ET AL., GREEN NETWORKING METRICS, 16 June 2023 (2023-06-16)
D. WING ET AL., PORT CONTROL PROTOCOL (PCP, 2013
GABOR FODOR ET AL: "5G New Radio for Automotive, Rail, and Air Transport", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 21 January 2021 (2021-01-21), XP081865001 *
GROUP, J. LINDBLAD ET AL., POWER AND ENERGY EFFICIENCY, 20 October 2023 (2023-10-20)
HOSSAIN MD SANWAR ET AL: "Towards Energy Efficient Load Balancing for Sustainable Green Wireless Networks Under Optimal Power Supply", IEEE ACCESS, IEEE, USA, vol. 8, 3 November 2020 (2020-11-03), pages 200635 - 200654, XP011820087, DOI: 10.1109/ACCESS.2020.3035447 *
J. QUITTEK ET AL., DEFINITION OF MANAGED OBJECTS FOR BATTERTY MONITORING, 2015
KEMAL DAVASLIOGLU ET AL: "Quantifying Potential Energy Efficiency Gain in Green Cellular Wireless Networks", ARXIV.ORG, CORNELL UNIVERSITY LIBRARY, 201 OLIN LIBRARY CORNELL UNIVERSITY ITHACA, NY 14853, 25 January 2015 (2015-01-25), XP081329599, DOI: 10.1109/COMST.2014.2322951 *
M. BOUCADAIR ET AL., DYNAMIC SERVICE NEGOTIATION: THE CONNECTIVITY PROVISIONING NEGOTIATION PROTOCOL (CPNP, 2020
M. CHANDRAMOULI ET AL., MONITORING AND CONTROL MIB FOR POWER AND ENERGY, 2015
M. FICHER ET AL.: "Assessing the carbon footprint of the data transmission on a backbone network", 2021, 24TH CONFERENCE ON INNOVATION IN COUDS, INTERNET AND NETWORKS
S. CHESHIRE ET AL., SPECIAL-USE DOMAIN NAMES, 2013
SCHWARTZ ET AL., SERVICE BINDING AND PARAMETER SPECIFICATION VIA THE DNS (DNS SVCB AND HTTPSSVC, November 2023 (2023-11-01)

Also Published As

Publication number Publication date
FR3157047A1 (fr) 2025-06-20

Similar Documents

Publication Publication Date Title
FR3067550A1 (fr) Procede de communication quic via des chemins multiples
FR3023108A1 (fr) Procede et dispositif d'orchestration de ressources
EP2359546B1 (fr) Procede de configuration de parametres de gestion de paquets de donnees appartenant a un flux de donnees
EP3284224B1 (fr) Procédé d'émulation dune connexion à chemins multiples
FR3048574A1 (fr) Selection d'une instanciation de tranche de reseau pour la transmission de paquets montants
EP3807760B1 (fr) Procédé d'installation d'une fonction réseau virtualisée
CN116635880A (zh) 核心网域中的可信服务业务处置
EP2883341B1 (fr) Dispositif et procede de mise a disposition de services dans un reseau de communication
EP3682600B1 (fr) Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en oeuvre l'agregation de liens
WO2025125478A1 (fr) Procédés de supervision, de gestion d'un service, de gestion d'un accès à une tranche réseau et d'accès à un service, et dispositifs configurés pour mettre en oeuvre ces procédés
US20240364602A1 (en) Infrastructure for enforcing per-application target service level parameters in multi-domain networks
EP4082232A1 (fr) Procede de configuration d'un equipement utilisateur, equipement utilisateur, et entite de gestion de regles
WO2025078594A1 (fr) Procédés de sélection de tranches réseau adaptées à un service, de gestion d'au moins une tranche réseau et de communication, et entités configurées pour mettre en œuvre ces procédés
WO2023104724A1 (fr) Procédé d'émission d'un flux de données dans un réseau de communications, procédé de traitement d'un flux de données, procédé de contrôle du traitement d'un flux de données, dispositifs, équipement terminal, entité d'exécution, entité de contrôle, système et programmes d'ordinateur correspondants.
WO2025093520A1 (fr) Procédés et dispositifs pour la configuration et l'utilisation d'un réseau supportant des tranches réseau
FR3157769A1 (fr) Procédé d’accès à un service par un dispositif de communication via au moins un réseau de communication
FR3150670A1 (fr) Procédés d’accès à un service, procédé de fourniture de services, procédé de contrôle, procédé de gestion, terminal, instance de service, contrôleur, nœud de bordure et programmes d’ordinateur correspondants.
WO2025125235A1 (fr) Procédé de détermination d'un ensemble de flux multicast auxquels un terminal récepteur est habilité à accéder
FR3053556A1 (fr) Procede et dispositif de gestion d'une session de transmission d'un flux video
WO2024068725A1 (fr) Procédé de gestion du trafic de données entre une entité source et une entité destinataire, entité et programme d'ordinateur correspondants
WO2025078600A1 (fr) Procédés de vérification, de gestion, de contrôle, d'exécution d'une vérification de l'accessibilité d'un équipement, équipement, serveur de contrôle, contrôleur réseau, entité relais et programme d'ordinateur correspondants
FR2973621A1 (fr) Procede de repartition de flux de donnees multicast dans des groupes de diffusion multicast
FR3153206A1 (fr) Procédés, dispositifs et système de contrôle d’une communication dans un réseau
FR2988967A1 (fr) Procede de transmission d'une requete de reconfiguration de session d'un terminal mobile, et procede de transmission d'une information concernant des zones speciales
FR2965132A1 (fr) Procede de configuration de parametres de gestion de paquets de donnees appartenant a un flux de donnees

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 24828066

Country of ref document: EP

Kind code of ref document: A1