Method for optimizing the distribution of multicast content within a communication network implementing a plurality of network slices.

Abstract

Method for optimizing the distribution of multicast content within a communication network implementing a plurality of network slices. The invention relates to a method for optimizing the distribution of multicast content within a communication network implementing a plurality of network slices, comprising: - the reception (11), from a terminal, of a signaling message representing a request to join said terminal to a multicast group associated with the distribution of said multicast stream, said message comprising a multicast address identifying said multicast group, and a network slice identifier representing a preferred candidate network slice chosen by said terminal for the routing of said multicast stream;- obtaining (12) an identifier of a target network slice for the routing of said multicast stream, based on said candidate network slice identifier and data representative of a current state of said communication network; - connecting (13) said terminal to a distribution tree of said multicast stream deployed in said target network slice. Abbreviated figure: Figure 1;

Description

Title of the invention: Method for optimizing the broadcasting of multicast content within a communication network implementing a plurality of network slices. Technical field

[0001] The field of the invention is that of communications within at least one communication network, and in particular that of value-added IP services. More specifically, the invention relates to the implementation of content distribution services using a multicast transmission mode, in a communication network within which network slices are deployed. Prior art

[0002] The broadcasting of the same content to multiple users is a service commonly offered and implemented via current communication networks, for example in the context of the retransmission of cultural or sporting events (retransmission of a concert in a metaverse, retransmission of a live football match, etc.). On a technical level, the engineering of such broadcasting services is generally based on a transmission mode called "multicast" (sometimes also referred to as "multicasting" or "group broadcasting"). This mode is in fact particularly suited to group communication schemes, such as the broadcasting of content to several users (receivers), or the implementation of videoconferencing type services between several users where each participant is in turn source or receiver.In Internet Protocol (IP) networks, multicast transmission relies on the calculation, establishment, and maintenance of distribution trees by a dynamic routing protocol, such as the Protocol Independent Multicast (PIM) protocol (RFC7761). A primary objective of implementing such distribution trees is to optimize network resources based on a deterministic data replication method.

[0003] Certain recent communication networks, in particular fifth generation mobile networks (5G), also offer the possibility for the operators who operate them to create and deploy different network slices on the same physical infrastructure.

[0004] A network slice can be defined as a partition of the network, such as a virtual private network (VPN) deployed on a fixed infrastructure, mobile infrastructure, or a combination of both.

[0005] The characteristics of a network slice are essentially expressed in terms of capacity (i.e. bandwidth), quality of service (e.g. latency or one-way transit time), security (e.g. preservation of the confidentiality of information transmitted within the slice), traffic isolation or availability. Thus, an operator has the possibility of configuring a plurality of network slices within a communication network; a slice or a group of slices being for example dedicated to the provision of particular services and / or to satisfying particular technical requirements, so that the traffic characteristic of these services can benefit from the best routing conditions.

[0006] Conventionally, traffic that may be routed within a network slice is subject to authorization (also called access control) to use the paths established within the slice in question. Such authorization is typically based on the application of traffic classification rules, generally applied by a network access point within which the network slices are deployed. Such an access point is a node located at the edge of the network, for example deployed in front of client access or used to connect a network to other neighboring networks. For example, this access point may be located at the connection interface of a gateway (for example a packet gateway, or "Packet Gateway" in English, for the most recent generations - 4G, 5G - of mobile networks) which provides access to the Internet network.Such an access point may also be located at the connection interface of a mobile terminal (or “User Equipment” or UE in English) to the radio access network (or “Radio Access Network” or RAN in English), in particular so as to optimize the use of radio resources depending on the type of network slice and the profile of the traffic that it is likely to carry.

[0007] In this context, the 3GPP organization has defined different types of network slices, with specific characteristics, including in particular:

[0008] - a first type of network slices allowing a wide mobile service to be offered enhanced band (“Enhanced Mobile BroadBand” or eMBB in English);

[0009] - a second type of network slices allowing a service to be offered within the framework of a (massive) deployment of the Internet of Things (mloT); and

[0010] - a third type of network slices allowing to offer a communication service Ultra Reliable Low Latency Communications (URLLC).

[0011] The choice to design and deploy a given type of network slice is conditioned by the nature of the traffic characteristic of the applications or services used or subscribed to by a user. For example, a so-called “immersive” service which uses augmented or virtual reality techniques is generally very demanding in terms of latency and reliability of data exchanges: the use of URLLC type slices is therefore preferred for such an immersive service.

[0012] To access content broadcast in multicast on a communication network implementing network slices, a receiver (mobile terminal, personal computer, television set) must be able to connect to one or more network slices, which on the one hand host the distribution tree along which the traffic will be routed from the source to all the receivers, and on the other hand have characteristics reflecting those of the broadcast service(s). For example, a network slice will be designed and sized (in terms of bandwidth, one-way transit time, etc.) to route traffic encoded by the source in high definition (HD), another slice to route traffic encoded by the source in standard definition (SD), etc.

[0013] The variety of such “multicast” slices must not only be able to be signaled to the receivers, whatever their nature, whatever their means of access to one or other of these slices and whether these receivers are in motion or not. It must also make it possible to switch the broadcast traffic from one slice to another according to several considerations such as a possible congestion phenomenon, the access capacities of the receivers to one or other of the slices, the nature of the broadcast service to which a receiver has subscribed, etc. Such considerations make it possible in particular to dynamically adjust the traffic classification rules which govern the access of the receivers to one or other of these slices.

[0014] However, while tools - such as multicast group subscription protocols, dynamic multicast routing protocols, etc. - exist to facilitate the implementation of broadcast services based on the multicast transmission mode supported by IP networks, there is, however, no way to simply manage traffic classification rules allowing access to "multicast" slots in a context of emerging 5G mobile networks, in particular. The implementation of such classification rules therefore currently involves complex network configurations, with a substantial risk of errors during the configuration operations in question.

[0015] There is therefore a need for a technique for optimizing the distribution of multicast content within a communication network in which several network slices are deployed. Summary of the invention

[0016] The present invention provides a solution aimed at remedying certain drawbacks of the prior art. According to one aspect, the present invention relates to a method for optimizing the broadcasting of multicast content within a communication network implementing a plurality of network slices. According to the general principle of the proposed invention, such a method comprises:

[0017] - the reception, from a terminal connected to said network, of a message of signaling representing a request for membership of said terminal to a multicast group associated with the broadcasting of said multicast stream, said signaling message comprising a multicast address identifying said multicast group, and a network slice identifier representing a network slice preferred by said terminal for the routing of said multicast stream, called candidate network slice;

[0018] - obtaining an identifier of a target network slice for routing said multicast stream, based on said candidate network slice identifier and data representative of a current state of said communication network;

[0019] - connecting said terminal to a distribution tree of said multicast stream deployed in said target network slice.

[0020] In this way, the routing of content broadcast according to the multicast transmission mode within a communication network implementing network slices is optimized, in the sense that the invention provides the possibility for source and / or receiver terminals to transmit to the network, depending on their characteristics and / or technical capabilities and / or a local context, preferences concerning a slice to be favored for the routing of a multicast stream, while reserving the possibility for the network to take the decision to route the multicast stream on another slice, in particular depending on its current state, if it considers that another slice presents better conditions for routing said multicast stream.

[0021] In a particular embodiment, said candidate network slice identifier is encoded in said multicast address and / or included in a free data field of said signaling message.

[0022] In this way, it is possible to transparently and cleverly use conventional multicast signaling exchanges to inform the network of a network slice to be favored for routing a multicast stream.

[0023] According to a particular characteristic, said multicast group address is an IPv6 address, and said candidate network slice identifier is encoded within the “ff2” field of said IPv6 address.

[0024] In this way, we have a way to transparently encode a network slice identifier (or network slice type) into an IPv6 address.

[0025] According to a particular characteristic, said multicast group address is an IPv4 address, and in that said encoding of the candidate network slice identifier is implemented by the selection of a specific multicast group address within the IPv4 space “239.0.0.0 / 10”.

[0026] In this way, we have a way to transparently encode a network slice identifier (or network slice type) in an IPv4 multicast address.

[0027] In a particular embodiment, said free data field of said signaling message further comprises information representative of a multicast stream coding supported by said terminal.

[0028] In this way, additional discriminating data is available making it possible to select a distribution tree to be used within the target network slice, in the case where several distribution trees, each associated with the routing of the multicast stream according to a particular encoding, are hosted within this slice.

[0029] In a particular embodiment, said signaling message is a “Report” type message according to the IGMP signaling protocol (Internet Group Management Protocol, RFC 3376) or the MLD signaling protocol (Multicast Listener Discovery, RFC 3810), and said free data field is the “Auxiliary Data” auxiliary data field defined in said IGMP signaling protocol or a dedicated field for said MLD signaling protocol.

[0030] In this way, compatibility with the IGMP and MLD multicast signaling protocols widely used for implementing multicast broadcast services in an IP network is guaranteed.

[0031] In a particular embodiment, said connection of said terminal to a distribution tree of said multicast flow deployed in said target network slice takes into account said information representative of a multicast flow coding supported by said terminal, when such information is present in said free data field of said signaling message.

[0032] In a particular embodiment, said reception of a signaling message representative of a request for membership of said terminal to the multicast group associated with the broadcasting of said multicast stream follows the transmission of a signaling request message comprising a list of multicast groups known to the network, said list comprising at least said multicast group associated with the broadcasting of said multicast stream, identified by said multicast address, a network slice identifier being encoded in said multicast address and / or included in a free data field of said signaling request message.

[0033] In this way, conventional multicast signaling exchanges are used transparently and cleverly to inform a terminal of the network slices available in the communication network for routing a multicast stream.

[0034] In a particular embodiment, the connection of said terminal to a distribution tree of said multicast flow deployed in said target network slice comprises transmitting a transplant request message to said distribution tree according to a dynamic routing protocol, said transplant request message comprising an identifier of said target network slice.

[0035] In this way, the dynamic routing protocol used to connect the terminal to a distribution tree takes into account a target network slice to be used for routing the multicast flow.

[0036] According to a particular characteristic, said graft request message further comprises data representing an encoding of said multicast stream or representing an absence of encoding information of said multicast stream.

[0037] In this way, the dynamic routing protocol used to connect the terminal to a distribution tree takes into account additional data concerning the encoding of the multicast stream in order to identify the distribution tree to be used to route the multicast stream, in particular in the case where several distribution trees are hosted in the target network slice,

[0038] According to a particular characteristic, said dynamic routing protocol is the PIM protocol (Protocol Independent Multicast (Sparse Mode), RFC 7761) and said graft request message is a “JOIN” type message according to said PIM protocol, said message being adapted to include a field comprising said identifier of said target network slice and said data representative of an encoding of said multicast flow, when said data representative of an encoding of said multicast flow is available.

[0039] In this way, the proposed invention is based on an adaptation of a recognized and widely used dynamic routing protocol for the implementation of multicast broadcasting services on an IP network.

[0040] In a particular embodiment, said method comprises, prior to said reception of a signaling message of the “Report” type, when said terminal is a source of broadcasting of said multicast stream:

[0041] - receiving, from said source terminal, a subscription request to an optimized broadcast service, comprising data identifying said source terminal and data representative of technical capabilities supported by said source terminal;

[0042] - the transmission, to said source terminal, of a confirmation message subscription, comprising at least one association between a multicast address usable by said source terminal for the broadcasting of said multicast stream and a network slice identifier determined as being suitable for the broadcasting of said multicast stream on said communication network, based on said data representative of technical capabilities supported by said source terminal.

[0043] In this way, a preliminary step of subscribing to the broadcasting service optimized can be initiated by a source terminal upstream of the broadcast of any content, allowing for example the source terminal to obtain relevant and targeted technical information on the resources available within the communication network, in particular information on the network slices which are of particular interest to this source terminal, because selected on the basis of technical characteristics and capacities associated with this source terminal and the underlying service.

[0044] According to a particular characteristic of this embodiment, said association is implemented by encoding, in said multicast address usable by said source terminal for the broadcasting of said multicast stream, said network slice identifier determined as being suitable for the broadcasting of said multicast stream.

[0045] In this way, a multicast address as such makes it possible to define both a multicast group and a network slice, for routing a multicast flow within the communication network.

[0046] According to another aspect, the invention relates to a method for joining a terminal to a multicast group associated with the broadcasting of a multicast stream within a communication network implementing network slices, said method being implemented at said terminal, said method comprising:

[0047] - obtaining, from a message received from said network, at least one network slice identifier available for routing a multicast stream;

[0048] - the transmission, to said network, of a signaling message represented indicating a request for membership of said terminal to said multicast group, said signaling message comprising a network slice identifier representative of a network slice preferred by said terminal for routing said multicast stream, called candidate network slice, selected from said at least one network slice identifier available for said routing.

[0049] In this way, a source or receiver terminal is able to select by itself a network slice optimized for the routing of a multicast stream, depending for example on its own technical capabilities (e.g. encoding or decoding).

[0050] In a particular embodiment:

[0051] - said at least one available network slice identifier is extracted by said terminal of at least one multicast address included in said received message, within which it is encoded; and / or

[0052] - said at least one candidate network slice identifier is encoded by said terminal within at least one multicast address identifying said multicast group, transmitted in said signaling message.

[0053] In this way, the terminal is fully compatible with the new struc- multicast address generation according to the invention, whether when it is a question of extracting a network slice identifier encoded in such an address, or of constructing a multicast address encoding such information.

[0054] According to another aspect, the invention relates to a router entity capable of implementing the method for optimizing the broadcasting of a multicast stream described above. Such an entity may of course have the various characteristics relating to the optimization method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this entity are the same as those of the optimization method and are not detailed further.

[0055] According to another aspect, the invention relates to a terminal (source or receiver) capable of implementing the method of joining a multicast group described above. Such a terminal may of course have the various characteristics relating to the joining method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this entity are the same as those of the joining method and are not detailed further.

[0056] According to another aspect, the proposed invention also relates to a computer program product downloadable from a communication network and / or stored on a computer-readable medium and / or executable by a microprocessor, comprising program code instructions for the execution of at least one of the methods as described previously in any of its embodiments, when this method is executed on a computer.

[0057] The proposed invention also relates to a computer-readable recording medium on which is recorded a computer program comprising program code instructions for executing the steps of the methods as described above, in any of their embodiments.

[0058] Such a recording medium may be any entity or device capable of storing the program. For example, 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 USB key or a hard disk.

[0059] On the other hand, such a 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 or by other means, so that the computer program contained therein is remotely executable. The program according to the invention may in particular be downloaded over a network, for example the Internet.

[0060] The different embodiments mentioned above can be combined with each other for implementing the invention. Figures

[0061] Other characteristics and advantages of the invention will appear more clearly on reading the following description of a particular embodiment, given as a simple illustrative and non-limiting example, and the appended drawings, among which:

[0062] [Fig.l] schematically presents the different steps of a method for optimizing the broadcasting of multicast content within a communication network implementing a plurality of network slices, in a particular embodiment of the proposed invention;

[0063] [Fig.2] schematically illustrates the implementation of dedicated network slices for the routing of multicast flows according to particular encodings, in a particular embodiment of the proposed invention;

[0064] [Fig.3] illustrates an example of a mechanism for subscribing a source to an optimized multicast stream broadcasting service, in a particular embodiment of the proposed invention;

[0065] [Fig.4] describes an example of a particular IPv4 address formalism, in a particular embodiment of the proposed invention;

[0066] [Fig.5] describes an example of a particular IPv6 address formalism, in a particular embodiment of the proposed invention;

[0067] [Fig.6] illustrates an example of formalism of an IGMP signaling message of type “Query”, in a particular embodiment of the proposed invention;

[0068] [Fig.7] illustrates an example of formalism of an IGMP signaling message of type “Report”, in a particular embodiment of the proposed invention;

[0069] [Fig.8] illustrates an example of formalism of an “Auxiliary Data” attribute of an IGMP signaling message of “Query” or “Report” type, in a particular embodiment of the proposed invention;

[0070] [Fig.9] illustrates an example of formalism of a “far” PIM type message, in a particular embodiment of the proposed invention;

[0071] [Fig.10] illustrates an example of formalism of a new attribute of a “far” PIM type message, in a particular embodiment of the proposed invention;

[0072] [Fig. 11] schematically presents the different stages of a method for joining a terminal to a multicast group associated with the broadcasting of a multicast stream within a communication network implementing network slices, in a particular embodiment of the proposed invention;

[0073] [Fig. 12] describes a simplified architecture of the different entities for the implementation of the proposed invention. Detailed description of the invention

[0074] 1, General principle - method implemented on the network side

[0075] The invention described below makes it possible to overcome some of the aforementioned drawbacks.

[0076] The proposed mechanism makes it possible in particular to manage in an optimized manner the routing of multicast contents within a communication network implementing network slices. To this end, according to the general principle of the invention and as detailed below, various adaptations of the protocols for subscribing a terminal (source or receiver) to a multicast group and of the dynamic multicast routing protocols for a multicast stream routed within a network are proposed, as well as a particular structuring of the multicast addresses.

[0077] It should be noted that the present invention can be implemented independently:

[0078] - the nature of the content broadcast by the sources;

[0079] - encoding capabilities possibly associated with the broadcasting of such content;

[0080] - access capabilities of the receiving terminals to the networks which support said multicast network slices;

[0081] - the nature of these networks (which may be fixed and / or mobile);

[0082] - engineering choices made with regard to design, deployment and the exploitation of multicast network slices.

[0083] In all the figures of this document, elements and steps of the same nature are designated by the same numerical reference.

[0084] In the following, the term “network slice” must be understood as being able to relate not only to a particular network slice, but also to a type of network slice. Thus, although the general principle of the invention and its various embodiments are hereinafter generally described and claimed as relating to “network slices”, they apply equally and indifferently when a “type of network slice” is considered, rather than a particular network slice (a “network slice identifier” must then be understood as “a network slice type identifier”, etc.).

[0085] According to a first aspect, the present invention relates to a method for optimizing the broadcasting of a multicast stream within a communication network implementing network slices. Such a method, illustrated by [Fig.l], is implemented by a router device (more simply called a router hereinafter) of the communication network, typically located at the edge of the network (and which can be qualified as such as access routers, or border routers).

[0086] In a step 11, such a router receives, from a terminal connected to the network, a signaling message representing a request for this terminal to join a multicast group associated with the broadcasting of a multicast stream, this signaling message conventionally comprising a multicast address identifying said multicast group. According to the usual terminology of multicast signaling protocols, such a signaling message is referred to as a “Report” type message. (i.e. of the “Report” type, in French), this aspect being detailed later in this document. Such a signaling message can be sent by a source terminal broadcasting the multicast stream or by a receiver terminal to announce that it wishes to receive (or continue to receive) the multicast stream in question. According to the general principle of the present invention, this signaling message comprises a network slice identifier (or a network slice type identifier), representative of a candidate network slice (respectively of a candidate network slice type) favored by said terminal for routing the multicast stream within the communication network.When the terminal is a source, the network is thus notified of a wish of this terminal to use a particular slice (respectively a particular type of slice) of the network to transmit the emitted multicast stream, for example because this terminal is aware of the existence of a slice (respectively of a type of network slice) that it considers appropriate for such a transmission. For example, an SRC source terminal capable of encoding the same multicast content in different definitions (SD, HD, 4k, 8k, etc.) is thus able to select a network slice optimized for the transmission of the stream encoded in SD, another network slice for the transmission of the stream encoded in 8k, etc., as illustrated by [Fig.2].Similarly, when the terminal is a receiver, the network is thus notified of a wish of this terminal to connect to a particular slice of the network for the reception of the stream, for reasons which may for example be identical to those mentioned previously (for example, depending on its decoding capabilities).

[0087] In a step 12, the router obtains a target network slice identifier for routing the multicast flow, based on the candidate network slice identifier (or candidate network slice type) received in step 11 and data representative of a current state of said communication network.

[0088] More particularly, in relation to this step 12, the network determines whether the candidate network slice (or type of network slice) as identified in a signaling message received from a terminal is indeed an optimal network slice for routing the multicast stream, taking into account in particular a current state of the network resources (for example according to information relating to the availability or unavailability of certain network slices at the time of reception of this signaling message).

[0089] Such a determination may be made by the router responsible for processing the “Report” message, or, alternatively, by a communication network control device (more simply called a controller or network controller in this document), for example upon request from the router, on the basis of data received from various control devices deployed within the network (e.g. software probes). The data representative of a current state of the communication network include, for example, data indicating the unavailability or congestion of certain slices, excessively long latency times measured on certain slices, excessively long unidirectional transit times, excessively high data loss rates, etc., which constitute all indicators likely to encourage a switch from one slice to another (in particular if these indicators deteriorate over time, for example). For example, an increasing number of receivers may cause traffic overload in the access network, which may cause processing slowdowns that may degrade the quality of the broadcast service as perceived by the user (e.g., pixelation, frozen image, or black screen).

[0090] Thus, although having received from a terminal a wish to use a particular network slice for the broadcasting and / or reception of the multicast stream, a network device can evaluate - for example on the basis of various indicators, and / or when a predetermined level of quality of service is not reached for the candidate slice - that this choice is not the most appropriate or the most optimal, and take the decision to route the multicast stream on another slice, called the target slice. In one embodiment, when this is possible (i.e. if such a slice exists), the target network slice chosen by the network is a slice satisfying at least the technical requirements of the candidate slice (for example in terms of latency or reliability of data exchanges), so as not to degrade the performance and / or the quality of the broadcasting service compared to the candidate slice initially selected by a terminal.

[0091] In a particular embodiment, step 12 may be associated with a complementary step of traffic classification, in which a network device (for example a border router) may, on the basis of criteria such as presented previously or other criteria, decide to classify the traffic by an appropriate marking, or classification criterion, different from the identifier of the target slice.

[0092] In a step 13, the router connects the terminal to a distribution tree of said multicast flow deployed in the target network slice determined in step 12 (which may be either the candidate slice, or another slice, depending on the result of this step 12), for routing the multicast flow. Such a connection step is based on the use of a dynamic multicast routing protocol adapted to take into account a network slice identifier and a possible classification criterion, as detailed later in this document.

[0093] In other words, the general principle of the present invention is based on:

[0094] - an adaptation of a signaling protocol used by a terminal for subscribing to a multicast group, consisting of allowing the terminal to request the use of a particular slice, called a candidate slice, for the broadcasting or recovery of the multicast stream associated with the multicast group (step 11 of [Fig.l]);

[0095] - a decision by a network element (typically an access router or a controller), in order to determine whether or not the candidate slice is suitable, depending on a current state of the communication network, for routing the multicast stream from or to the terminal in question, and, if not, a determination and selection of another network slice guaranteeing optimized broadcasting, called the target slice (step 12 of [Fig.l]);

[0096] - an adaptation of a dynamic multicast routing protocol, so as to make possible to direct the multicast flow to the target slice, or even to the most appropriate distribution tree within this slice if several trees are deployed there (step 13 of [Fig.l]).

[0097] This general principle having been explained, we now turn to different embodiments of the present invention, in particular with regard to the signaling and routing aspects (steps 11 and 13). 2. Signaling

[0098] As described above, a first aspect of the proposed technique relates to adaptations of the signaling mechanisms. In this context, different embodiments are presented below for:

[0099] - on the one hand inform a terminal of the network's capabilities to convey a flow multicast, this so that the terminal can determine the slice (or type of slice) that it wishes to prioritize (i.e. the candidate slice), possibly based on its own technical capabilities (e.g. encoding or decoding capabilities) and / or a current local context (occasional unavailability of certain interfaces of the terminal, for example), to broadcast or receive a multicast stream;

[0100] - on the other hand, once this candidate slice has been determined, transmit this in network training.

[0101] 2.1, Informing a terminal of the network slices deployed in the network

[0102] Two mechanisms (which can possibly be implemented in a complementary manner) are proposed to signal to terminals wishing to broadcast or access a multicast stream the variety of network slices available in the network for this purpose, as well as the technical capacities associated with them, where applicable.

[0103] 2.1.1. First mechanism: subscription upstream of signaling

[0104] A first mechanism takes the form of a subscription phase to the optimized multicast stream broadcasting service according to the proposed invention, implemented upstream of the conventional signaling operations by which a terminal manifests its intention to join a multicast group. Such a subscription phase, illustrated by [Fig. 3], concerns an SRC source terminal wishing to broadcast multicast content via the communication network implementing network slices, according to the example of [Fig. 2]. In such a particular embodiment, the The network's ability to implement optimized broadcasting according to the present invention is, for example, exposed by the network by means of a dedicated application programming interface (API). According to a particular characteristic, a dynamic negotiation protocol such as the CPNP protocol (Connectivity Provisioning Negotiation Protocol, RFC8921) is used to expose such an interface, the network hosting a CPNP server while the source terminal (typically an application server) embeds a CPNP client. This example is, however, non-limiting, and other protocols such as, for example, the RESTCONF protocol (RFC8040) can also be used to expose this API.

[0105] The SRC source wishing to subscribe to the optimized broadcasting service transmits, by means of the dedicated API described above, an SBSC subscription request, comprising at least one source identifier, typically an IP address (possibly associated with a port number) at which the SRC source for broadcasting multicast content can be contacted. According to a particular characteristic, the SBSC subscription request also comprises data representative of encoding capabilities (e.g. SD, HD, 4k, or 8k) supported by the source.

[0106] Upon receipt of an SBSC subscription request, a network element such as a controller identifies, based on the information transmitted in the subscription request, at least one network slice deployed within it and suitable for routing multicast streams emitted by the source. If necessary, a new slice may be created for this purpose. The decision to instantiate a new slice depends on a policy local to the network operator.

[0107] In response to the subscription request, the network sends to the source an ACK_SBSC message confirming the successful subscription to the service, and a list (i.e. at least one) of multicast addresses that can be used by the source to broadcast content, each multicast address being associated with a particular network slice implemented on the communication network. Data representative of technical characteristics associated with each slice (or type of slice) are also communicated to the SRC source. For example, the network informs a source or a receiver of the existence within it of network slices dedicated to the delivery of SD, HD, 4k, 8k, etc. content.

[0108] In this way, the source terminal has, by means of such a subscription phase, a first mechanism allowing it to have knowledge of the network slices available within the network to broadcast a multicast stream, as well as their technical characteristics and the associated multicast addresses.

[0109] 2.1.2. Second mechanism: adaptation of signaling messages of the type “ Query »

[0110] A second mechanism is based on an adaptation of the signaling operations by which a terminal manifests its intention to join a multicast group.

[0111] It is recalled in this respect that conventionally in the context of a multicast transmission mode, signaling messages are exchanged between the network and the terminals (source and / or receiver) which wish to join a multicast group, and that different signaling protocols exist for this purpose, such as for example the IGMP protocol ("Internet Group Management Protocol", RFC3376) in the context of an IPv4 environment, or the MLD protocol ("Multicast Listener Discovery", RFC3810) in the context of an IPv6 environment. These existing signaling protocols are based on similar operating principles: a requesting device from the communication network, typically a router, sends "Query" type messages at regular frequency to the receivers connected to the network (via a multicast address available for this purpose, for example the address 224.0.0.1 in the case of IGMP signaling), which receivers can form "Report" type messages in response to join a particular group, and thus indicate that they wish to receive the multicast stream associated with this group. A "Report" type message explicitly provides the reachability information of the source or receiver (typically an IP address) as well as the multicast group address(es) to which the source broadcasts the content or to which the receiver wishes to access.

[0112] Thus, as an alternative or complementary manner to the first subscription mechanism presented previously, it is notably proposed to enrich the “Query” type messages conventionally sent to the terminals connected to the communication network, so that these signaling messages include, in addition to the conventional information representative of the multicast groups known to the requesting router (“IGMP / MLD Querier” in English), additional data representative of the network slices available for accessing the multicast flows, possibly supplemented by information on the technical capabilities of these slices.

[0113] It should be noted that the second mechanism which has just been described (adaptation of the “Query” type signaling messages) can be used to communicate such information relating to the slots available in a communication network both to a broadcast source for the transmission of multicast streams and to a receiving terminal wishing to subscribe to them.

[0114] According to the proposed technique, such data are transmitted according to a particular formalism, described later in point 2.3 of this document.

[0115] 2.2, Inform the network of the candidate slice preferred by a terminal

[0116] The mechanisms allowing the network to inform a terminal of the slots dis available for routing a multicast stream having been presented, another problem relates to the way in which a terminal indicates in return to the communication network the network slice that it wishes to use in a privileged manner to broadcast or receive a multicast stream.

[0117] It is proposed, according to the general principle of the present invention, to transmit this information within a signaling message of the “Report” type transmitted by the terminal to the requesting router (“IGMP / MLD Querier”), by adopting here also the particular formalism mentioned previously and defined below.

[0118] 2.3. Proposed formalism for the integration of information identifying slices networks within signaling messages

[0119] Two alternative or complementary solutions are described below, in various particular embodiments of the present invention, in order to enrich signaling messages of the “Query” or “Report” type with information relating to the network slices available in the communication network (for “Query” type messages) or with information relating to the network slices selected by a terminal to broadcast or access a multicast stream (for “Report” type messages).

[0120] As shown below, these solutions have the particular advantage of maintaining a certain compatibility with existing multicast signaling protocols, in particular the IGMP and MLD protocols widely used for setting up multicast broadcast services on an IP / MPLS network.

[0121] A first solution consists in using multicast group addresses of a particular format to transmit transparently at the protocol level information identifying available and / or to be used network slices. This approach makes it possible to associate a multicast address with a network slice (or with a type of network slice) in an algorithmic manner, thus allowing the different elements (sources, receivers, routers, controllers) to extract information characteristic of the associated network slice. More particularly, it is proposed according to this first solution to create an association between a multicast address and a network slice identifier (or a type of network slice), by cleverly encoding this network slice identifier (or type of slice) directly in the multicast address in question. In this way, it is not necessary to modify the way in which the signaling messages are constructed (i.e.their format). In the following, the description uses an example implementation of the invention which is based on the use of a network slice identifier but the procedure also applies when a slice type is used.

[0122] For example, according to a particular characteristic and as illustrated in relation to [Fig.4], when the multicast group address is an IPv4 address, it is proposed to select a specific multicast group address within the IPv4 239.0.0.0 / 10 space in order to encode a particular slice identifier S_ID, such a format then relying on the use of multicast addresses with extended administrative scope as documented in the RFC2365 standard.

[0123] According to another particular characteristic and as illustrated by [Fig.5], when the multicast group address is an IPv6 address, it is proposed to encode the slice identifier within a particular field of this address, e.g. in all or part of the 4 bits of the “ff2” field of said IPv6 address (bits 17 to 20) as defined in the RFC7371 standard. Note that in this context, other fields of the IPv6 address (typically the “fffl”, “plen” and “network prefix” fields) can also be used to determine the address of rendezvous points (“Rendezvous Point” or RP in English) hosted within a network slice identified by the identifier carried in the “fff2” field of this new IPv6 multicast address format.This last aspect refers to the case where multicast engineering is based on the calculation, establishment and maintenance of distribution trees whose root is an RP (several RPs can be hosted within a network slice), according to an engineering typical of an ASM mode ("Any Source Multicast") often chosen for the deployment of videoconferencing services or any other broadcasting service characterized by a source / receiver heuristic. On the contrary, the engineering of "general public" broadcasting services (television program broadcasting services for example) is typical of the SSM mode ("Source Specifies Multicast") which leads to the deployment of trees whose root is the broadcasting source ("Shortest Path Tree" or SPT) itself, a case that the format of [Fig.5] also allows to cover, for example by setting the "plen" and "network prefix" fields to zero.

[0124] In this way, the identifier of a network slice for routing a multicast stream is directly encoded in the multicast group address associated with this content. The construction and availability of such addresses may for example have been communicated by the communication network to the terminals likely to use them by means of one or other of the two mechanisms previously described (subscription or adaptation of the “Query” type signaling messages).

[0125] This first solution lends itself well to communication networks configured such that each available multicast network slice implements a single multicast distribution tree. Indeed, as recalled in relation to the prior art, a communication network organized in slices may comprise a plurality of network slices capable of routing the same multicast content, for example, in the case of routing a video stream, a network slice designed and sized (in terms of bandwidth, one-way transit time, etc.) to route traffic encoded in 4K, another network slice designed and sized (in terms of bandwidth, one-way transit time, etc.) to carry traffic encoded in high definition (HD), yet another to carry traffic encoded in standard definition (SD), etc. In this case, each network slice hosts its own multicast content distribution tree. However, it is also possible, depending on the design choices and / or configuration of the network, for the same network slice to host several distribution trees for the same multicast content. For example, a distribution tree used to carry content encoded in 4K and another distribution tree used to carry content encoded in high definition can be deployed within the same slice of the communications network.It may then be useful to have additional criteria, in addition to a network slice identifier, so that the network is able to identify a particular distribution tree to use within a slice for broadcasting the multicast stream.

[0126] Furthermore, the first solution described above raises the question of the ability of certain terminals to be able to identify a particular multicast address formatted according to this invention and to be able to thus extract a slice identifier from it. Although, in one embodiment of the proposed invention, it is provided that the source or receiver terminals are adapted to take into account such a new format, it is appropriate to ensure a certain compatibility with terminals which do not have means enabling them to detect such a particular format.

[0127] Also, a second solution, alternative or complementary to the first, consists of using a free data field of the signaling messages (of the “Query” and / or “Report” type) to transmit more explicitly the slice identifier (or slice type) associated with a multicast stream and, where appropriate, to accompany this information with additional data, typically data representative of an encoding of the multicast stream.

[0128] According to the particular embodiments of the proposed invention, such an adaptation can be implemented:

[0129] - in “Query” type signaling messages, when it is for example (i) to inform a source terminal of the existence within the communication network of slots dedicated to the routing of multicast streams according to particular encodings; or (ii) to inform a receiving terminal which would not have the capacity to identify that a multicast address transmitted in such a message is defined according to a particular formalism (i.e. that it contains a network slot identifier associated with the broadcasting of the multicast stream) of the network slots available for the reception of a multicast stream;

[0130] - in “Report” type signaling messages, when it is for example to communicate to the network additional information enabling it to identify, among several distribution trees deployed on the same slice, the one to use to route the multicast stream.

[0131] Figures 6, 7 and 8 illustrate the implementation of this second solution in the context of signaling messages according to the IGMP signaling protocol, and more particularly the use of the auxiliary data field “Auxiliary Data” defined in this protocol to convey such information (an implementation according to a similar principle can also be implemented in the context of signaling messages according to the MLD protocol). More particularly:

[0132] - [Fig.6] shows the format of an IGMP message of type “Query” where the field of auxiliary data “Auxiliary Data” is visible;

[0133] - [Fig.7] shows the format of an IGMP message of type “Report” where the field of auxiliary data “Auxiliary Data” is visible;

[0134] - [Fig.8] shows how the auxiliary data field can be more particu be formatted to include information relating to a network slice identifier SID (for "Slice Identifier", in English) and to a possible associated encoding ENCOD_TYPE (including for example data representative of a particular encoding - SD, HD, 4k, 8k, etc. - of the multicast stream, or data representative of an absence of encoding information of said multicast stream for example when the ENCOD_TYPE attribute is set to the value zero). 3. Routing

[0135] At the end of steps 11 and 12 as presented in relation to [Fig.l], the router which implements the method has identified the target network slice to which it must connect the terminal for optimized routing of the multicast flow. To carry out such a connection in practice, it is proposed according to the present invention to adapt the routing protocol of the multicast flow. More particularly, it is proposed to adapt the transplant request messages to a distribution tree conventionally defined according to such a protocol in order to add information making it possible to identify the network slice (or the type of slice) in which the targeted distribution tree is hosted. A transplant request message, generally referred to as a “far” type message, aims to connect a terminal to the distribution tree responsible for routing the traffic corresponding to the multicast flow in question.Such a graft then allows, for example, a receiving terminal to receive the selected content. Thus, according to a particular characteristic of the proposed invention, the identifier of the target network slice as obtained in step 12 is added to the graft request message. Insofar as the same network slice is also likely to host several distribution trees (for example, a tree for SD broadcasting and another for HD broadcasting), it is also proposed, according to another particular characteristic of the proposed invention, to add, in addition to the target network slice identifier, at least one useful discriminating data item in the . case where knowledge of a target network slice would not be sufficient to uniquely identify a distribution tree for the optimized broadcasting of the multicast stream. Such discriminating data may for example take the form of data representative of a particular encoding of said multicast stream or representative of an absence of encoding information of said multicast stream. In a complementary manner, according to a particular characteristic, a classification criterion such as presented previously in relation to [Fig.l] may also be added in the graft request message, and be for example encoded in a multicast group address included in this message or inserted in a particular field of this message.Via the dynamic routing protocol, such a classification criterion is thus propagated to the routers responsible for routing the multicast flow, which can, if necessary, depending on this criterion and on the basis of other possible criteria, implement various processing operations including, for example, operations to switch the routing of the multicast flow to other slices.

[0136] In a particular embodiment, the routing protocol is the PIM protocol (“Protocol Independent Multicast”, RFC7761), and the graft request message takes the form of a “far” PIM type message whose general format is illustrated by [Fig.9]j This message includes a new MSLICE attribute identifying in particular the network slice hosting the distribution tree to which the router wishes to graft itself. According to a particular characteristic illustrated by [Fig. 10], this new attribute is encoded according to a Type / Length / Value (TLV, RFC5384) formalism, the SID field (for “Slice Identifier”, in English) comprising the identifier of the target network slice and the ENCOD_TYPE field possibly comprising data representative of a particular encoding (SD, HD, 4k, 8k, etc.) of the multicast stream, or data representing an absence of encoding information of said multicast stream (for example when the ENCOD_TYPE attribute is set to the value zero (“0”)), according to characteristics already presented previously. The grafting procedure to the distribution tree identified by such a “far” PIM message is then carried out according to the classic mechanism of the PIM-SM protocol (“PIM Sparse Mode”). 4. Process implemented on the terminal side

[0137] According to another aspect, the invention also relates to a method for joining a terminal to a multicast group associated with the broadcasting of a multicast stream within a communication network implementing network slices. Such a method, illustrated by [Fig. 11] in a particular embodiment, is implemented by a terminal connected to the network, this terminal wishing to broadcast (source terminal) or receive (receiver terminal) the multicast stream.

[0138] In a step 111, the terminal obtains, from a message received from the network, at least one network slice identifier available for routing a multicast stream. As described previously for the broadcast optimization method implemented on the network side, such a message may, for example, take the form of a “Query” type signaling message (i.e., “Request” type, in French), or a message confirming the terminal’s subscription to an optimized multicast stream broadcast service offered by the network.

[0139] In a step 112, the terminal transmits to the network a signaling message (typically a “Report” type signaling message) representative of a request to join the multicast group associated with the broadcasting of the multicast stream, this signaling message comprising a network slice identifier representative of a network slice preferred by the terminal for the routing of said multicast stream, called a candidate network slice, selected from the network slice identifiers available for said routing obtained in step 111. Such a selection of a candidate slice may in particular be carried out as a function of technical characteristics of the terminal (such as for example its capabilities for encoding and / or decoding a multicast stream), or even a current state of said terminal (for example the unavailability or congestion of some of its network interfaces).

[0140] According to a particular characteristic of the invention, the terminal which implements the membership method is a terminal adapted to support the new particular multicast address format presented previously in the context of the description of the broadcast optimization method implemented on the network side, according to which a network slice identifier can be encoded directly in a multicast address. When the terminal (source or receiver) is thus configured, in a particular embodiment of the invention:

[0141] - at least one network slice identifier available for routing a flow multicast is extracted by the terminal from at least one multicast address included in the message received from the network in step 111, within which it is encoded; and / or

[0142] - at least one candidate network slice identifier is encoded by the terminal at within at least one multicast address identifying said multicast group, transmitted in said signaling message sent to the network in step 112. 5. Devices

[0143] Finally, in relation to [Fig. 12], we present the simplified structures of an entity, for example a router of a communication network or a source or receiver terminal, according to at least one embodiment described above.

[0144] As illustrated by [Fig. 12], such an entity comprises at least one memory 121 comprising a buffer memory, at least one processing unit 122, equipped by example of a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 123, implementing steps of at least one method according to at least one embodiment of the invention.

[0145] At initialization, the code instructions of the computer program 123 are for example loaded into a RAM memory before being executed by the processor of the processing unit 122.

[0146] If the entity is a network entity (for example a router) of the communication network implementing network slices, the processor of the processing unit 122 implements steps of the method for optimizing the broadcasting of a multicast stream within said network as described previously, according to the instructions of the computer program 123, to:

[0147] - receive, from a terminal connected to said network, a signal message representative of a request for membership of said terminal to a multicast group associated with the broadcasting of said multicast stream, said signaling message comprising a multicast address identifying said multicast group, and a network slice identifier representative of a network slice preferred by said terminal for the routing of said multicast stream, called candidate network slice;

[0148] - obtain an identifier of a target network slice for routing said flow multicast, based on said candidate network slice identifier and data representative of a current state of said communication network;

[0149] - connecting said terminal to a distribution tree of said multicast stream deployed in said target network slice.

[0150] If the entity is a terminal connected to said communication network, typically a source terminal wishing to broadcast a multicast stream or a receiver terminal wishing to receive it, the processor of the processing unit 122 implements steps of the method of joining a multicast group described previously, according to the instructions of the computer program 123, to:

[0151] - obtaining, from a message received from said network, at least one network slice identifier available for routing a multicast stream;

[0152] - transmit, to said network, a representative signaling message of a request for membership of said terminal to said multicast group, said signaling message comprising a network slice identifier representative of a network slice preferred by said terminal for the routing of said multicast flow, called candidate network slice, selected from said at least one network slice identifier available for said routing.

Claims

Claims

1. Method for optimizing the broadcasting of a multicast stream within a communication network implementing network slices, said method being characterized in that it comprises: - receiving (11), from a terminal connected to said network, a signaling message representative of a request for membership of said terminal to a multicast group associated with the broadcasting of said multicast stream, said signaling message comprising a multicast address identifying said multicast group, and a network slice identifier representative of a network slice favored by said terminal for the routing of said multicast stream, called candidate network slice; - obtaining (12) an identifier of a target network slice for the routing of said multicast stream, as a function of said candidate network slice identifier and data representative of a current state of said communication network;- the connection (13) of said terminal to a distribution tree of said multicast flow deployed in said target network slice.;

2. Method according to claim 1, characterized in that said candidate network slice identifier is encoded in said multicast address and / or included in a free data field of said signaling message.

3. Method according to claim 2, characterized in that said multicast group address is an IPv6 address, and in that the candidate network slice identifier is encoded within the ff2 field of said IPv6 address.

4. A method according to claim 2, characterized in that said multicast group address is an IPv4 address, and in that said encoding of the candidate network slice identifier is implemented by selecting a specific multicast group address within the IPv4 space 239.0.0.0 / 10.

5. Method according to claim 2, characterized in that said signaling message is a message of type "Report" according to the IGMP signaling protocol or the MLD signaling protocol, and in that said free data field is the auxiliary data field "Auxiliary Data" defined in said IGMP signaling protocol or said MLD signaling protocol.

6. Method according to claim 1, characterized in that said reception of a signaling message representative of a request for membership of said terminal to the multicast group associated with the broadcasting of said multicast stream follows the transmission of a signaling request message comprising a list of multicast groups known to the network, said list comprising at least said multicast group associated with the broadcasting of said multicast stream, identified by said multicast address, a network slice identifier being encoded in said multicast address and / or included in a free data field of said signaling request message.

7. Method according to claim 1, characterized in that the connection of said terminal to a distribution tree of said multicast flow deployed in said target network slice comprises the transmission of a graft request message to said distribution tree according to a dynamic routing protocol, said graft request message comprising an identifier of said target network slice.

8. Method according to claim 7, characterized in that said dynamic routing protocol is the PIM protocol and in that said graft request message is a JOIN type message according to said PIM protocol, said message being adapted to include a field comprising said identifier of said target network slice and data representative of an encoding of said multicast flow or an absence of encoding information of said multicast flow.

9. Method according to claim 1, characterized in that it comprises, prior to said reception of a signaling message of the “Report” type, when said terminal is a source for broadcasting said multicast stream: - the reception, from said source terminal, of a request for subscription to an optimized broadcasting service, comprising identification data of said source terminal and data representative of technical capabilities supported by said source terminal; - the transmission, to said source terminal, of a subscription confirmation message, comprising at least one association between a multicast address usable by said source terminal for broadcasting said multicast stream and a network slice identifier determined as being suitable for broadcasting said multicast stream on said communication network, as a function of said data representative of technical capabilities supported by said source terminal.

10. Method according to claim 9, characterized in that said association is implemented by encoding, within said multicast address usable by said source terminal for the broadcasting of said multicast stream, said network slice identifier determined as being suitable for the broadcasting of said multicast stream.

11. Method for joining a terminal to a multicast group associated with the broadcasting of a multicast stream within a communication network implementing network slices, said method being implemented at said terminal, said method being characterized in that it comprises: - obtaining (111), from a message received from said network, at least one network slice identifier available for routing a multicast stream; - transmitting (112), to said network, a signaling message representative of a request for said terminal to join said multicast group, said signaling message comprising a network slice identifier representative of a network slice preferred by said terminal for routing said multicast stream, called candidate network slice, selected from said at least one network slice identifier available for said routing.

12. Membership method according to claim 11, characterized in that: - said at least one available network slice identifier is extracted by said terminal from at least one multicast address included in said received message; and / or - said at least one candidate network slice identifier is encoded by said terminal within at least one multicast address identifying said multicast group, transmitted in said signaling message.

13. Network entity for optimizing the broadcasting of a multicast stream within a communication network implementing network slices, comprising at least one processor configured to: - receive, from a terminal connected to said network, a signaling message representative of a request for membership of said terminal to a multicast group associated with the broadcasting of said multicast stream, said signaling message comprising a multicast address identifying said multicast group, and a network slice identifier representative of a network slice preferred by said terminal for the routing of said multicast stream, called a candidate network slice - obtaining an identifier of a target network slice for routing said multicast flow, based on said candidate network slice identifier and data representative of a current state of said communication network; - connecting said terminal to a distribution tree of said multicast flow deployed in said target network slice.

14. Terminal capable of adhering to a multicast group associated with the broadcasting of a multicast stream within a communication network implementing network slices, comprising at least one processor configured to: - obtaining, from a message received from said network, at least one network slice identifier available for routing a multicast stream; - transmitting, to said network, a signaling message representing a request for said terminal to join said multicast group, said signaling message comprising a network slice identifier representing a network slice preferred by said terminal for routing said multicast stream, called candidate network slice, selected from said at least one network slice identifier available for said routing.

15. Computer program comprising instructions for implementing a method according to any one of claims 1 to 10 when this program is executed by a processor.

Images