Method for determining a set of multicast streams that a receiver terminal is authorized to access

Method for determining a set of multicast streams which a receiving terminal is authorized to access.

0001The 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.

Prior art

0002The 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 known as "<i>multicast</i> ". 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 IP networks ("<i>Internet Protocol</i>"), the multicast transmission mode is based on the calculation, establishment and maintenance of distribution trees by a dynamic routing protocol, such as the PIM protocol ("<i>Protocol Independent Multicast</i> ", RFC7761). A main objective of implementing such broadcast trees is to optimize network resources according to a deterministic data replication mode.

0003Communication networks, particularly fifth-generation (5G) mobile networks, also offer the operators who operate them the ability to manage authorizations (also known as access control) relating to the routing of traffic on the network. Such authorizations are typically based on the application of traffic classification rules, generally applied by a network access point. 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 can 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 according to the profile of the traffic that it is likely to carry.

0004In this context, the policy for routing content broadcast in multicast on a communications network is based in particular on the authorization of the receiving terminals to access said content. For example, if the communications network implements network slices, it must be able to determine the access capabilities of the receivers to one or other of the slices, depending for example on the nature of the broadcasting service to which a receiver has subscribed. Such considerations make it possible to dynamically adjust with an adequate level of granularity (receiver, content) the traffic classification rules which govern the access or not of receivers to one or other of these slices, and ultimately, to said content.

0005However, the implementation and maintenance (e.g. in the event of changes to the access rights of a terminal or a user) of such classification rules currently involves complex network configurations, with a substantial risk of errors during the configuration operations in question.

0006There is therefore a need for a technique for simplifying the management of access authorizations of receiving terminals to multicast content broadcast within a communications network, and more particularly the obtaining of such authorization information by the network.

0007The present invention proposes a solution aimed at remedying certain drawbacks of the prior art. According to one aspect, the present invention relates to a method for determining a set of multicast streams to which a receiving terminal is authorized to access, from among a plurality of multicast streams broadcast by a content service on a communications network. According to the general principle of the proposed invention, such a method comprises, at the level of a router device of said communication network:

0008- the reception, from said receiving terminal, of a first signaling message comprising a resolution key, called an alias, usable by said router equipment to determine said set;

0009- implementing a procedure for resolving said alias, comprising obtaining, as a function of said alias, information from among (i) information representing an authorization of said receiving terminal to access at least one multicast stream of said plurality of multicast streams, comprising at least one multicast group address, called authorized multicast address, of at least one multicast group associated with the broadcasting of said at least one multicast stream; or (ii) information representative of a lack of authorization of said receiving terminal to access any of said multicast streams of said plurality of multicast streams.

0010In this way, the communications network has means for quickly and simply identifying whether or not a receiving terminal is authorized to access all or part of the multicast streams broadcast by a content service, and is thus, for example, able to implement differentiated processing, for example applying classification rules, based on this information.

0011In a particular embodiment, said resolution procedure is implemented entirely within said router equipment.

0012In this way, alias resolution can be implemented locally, and therefore more quickly, without the intervention of third-party equipment.

0013In another particular embodiment, said resolution procedure is implemented in conjunction with third-party equipment, said obtaining comprising:

0014<b>-</b> the transmission, to said third-party equipment, of a request for resolution of said alias, including said alias.

0015<b>-</b> the receipt, from said third-party equipment, of said information representing an authorization or an absence of authorization.

0016According to a particular characteristic, said third-party equipment belongs to the group comprising:

0017- equipment for controlling said communications network;

0018- a domain name system (DNS) server within said communications network;

0019- equipment associated with said content service.

0020In this way, it is not necessary to propagate the information allowing the resolution of an alias, that is to say the information of correspondences between aliases and associated authorized multicast addresses, to a large number of router devices of a communication network: the router devices can thus rely on third-party devices better adapted or better optimized for such resolution operations.

0021In a particular embodiment, said alias has the format of a domain name, comprising one or more hierarchical levels.

0022In this way, third-party equipment used for alias resolution operations can, in particular, take the form of existing equipment already deployed on the communications network and specialized for this purpose, such as domain name system servers for example.

0023According to a particular characteristic, one or more hierarchically higher levels of said hierarchical levels of said alias, forming a sub-alias called parent alias of said alias, uniquely identify said content service.

0024In this way, the content service can be identified directly from the alias.

0025In a particular embodiment, said parent alias is used to identify said content service to which to transmit a resolution request for said alias, when said resolution procedure is configured to be implemented in conjunction with equipment associated with said content service.

0026In this way, the communication network is able to route any resolution requests concerning child aliases to the authoritative server of the parent alias.

0027In a particular embodiment, said procedure for resolving said alias comprises a step of searching for said alias within a list of aliases marked as having already been resolved, and, in the event of the presence of said alias in said list, the delivery of information representative of a lack of authorization of said receiving terminal to access any one of said multicast streams of said plurality of multicast streams.

0028In this way, this technique makes it possible to set up access restrictions to certain multicast flows, when it is detected that the same alias is potentially shared between several receiving terminals.

0029In a particular embodiment, said reception of said signaling message follows the transmission of a first signaling request message sent by said router equipment to a set of receiving terminals connected to said communications network.

0030In this way, what can be compared to classic multicast signaling exchange mechanisms are used in a transparent and clever way to obtain from the receiving terminals connected to the communication network the aliases that can be used to identify the multicast streams that these terminals are authorized to access.

0031According to a particular characteristic, said first signaling request message comprises at least one identifier of said content service.

0032In this way, only receiving terminals that subscribe to a particular content service can be targeted for the signaling request.

0033According to a particular characteristic, said resolution procedure is implemented within equipment selected based on said identifier of said content service.

0034In this way, the equipment responsible for resolving an alias is easily identified, depending on the content service in question.

0035In a particular embodiment, said determination method further comprises, when the procedure for resolving said alias delivers information representative of an authorization of said receiving terminal to access at least one multicast stream of said plurality of multicast streams:

0036<b>-</b> the transmission, to said receiving terminal, of a second signaling request message comprising said at least one authorized multicast address;

0037<b>-</b> receiving, from said receiving terminal, a second signaling message representing a request for subscription from said receiving terminal to at least one multicast group associated with at least one of said at least one authorized multicast address.

0038In this way, after obtaining the multicast streams to which a receiving terminal is authorized to access via the communication network, more conventional signaling exchanges can be implemented in order to allow the receiving terminal to indicate the multicast streams to which it wishes to subscribe, and thus to initiate the process allowing said receiving terminal to receive the selected streams.

0039According to a particular characteristic, said signaling request and signaling messages are messages respectively of the “Query” and “Report” type according to a suitable IGMP signaling protocol or a suitable MLD signaling protocol.

0040In this way, the implementation of the present technique in the existing ecosystem is simplified, as a certain compatibility with the IGMP and MLD multicast signaling protocols widely used for the implementation of multicast broadcast services in an IP network is ensured.

0041According to a particular characteristic, said communication network implements network slices, and said reception of the second signaling message allows the implementation of differentiated processing based on at least one slice identifier encoded in a multicast address and/or included in a free data field of said second signaling message.

0042In this way, the present technique allows in particular the facilitated application of classification rules within the communication network.

0043According to another aspect, the invention relates to a method for subscribing a receiver terminal to at least one multicast group associated with the broadcasting of a multicast stream within a communication network, said method being implemented by said receiver terminal and comprising:

0044- receiving, from a router device of said communication network, a first signaling request message, comprising at least one identifier of a content service;

0045- the transmission, to said router equipment, of a first signaling message, comprising at least one resolution key, called alias, selected by said receiving terminal as a function of said content service identifier;

0046- receiving, from said router equipment, a second signaling request message, comprising at least one multicast address, called authorized multicast address, of at least one multicast group associated with the broadcasting by said content service of at least one multicast stream that said receiver terminal is authorized to access;

0047- the transmission, to said router equipment, of a second signaling message representing a request for subscription from said terminal to at least one multicast group associated with at least one of said at least one authorized multicast address.

0048According to another aspect, the invention relates to a router equipment for determining a set of multicast streams to which a receiver terminal is authorized to access, from among a plurality of multicast streams broadcast by a content service via a communication network, said router equipment comprising at least one processor configured to:

0049- receive, from said receiving terminal, a first signaling message comprising a resolution key, called an alias, usable by said router equipment to determine said set;

0050- implement a procedure for resolving said alias, including obtaining, based on said alias, information from among:

0051-- information representing an authorization of said receiving terminal to access at least one multicast stream of said plurality of multicast streams, comprising at least one multicast address, called authorized multicast address, of at least one multicast group associated with the broadcasting of said at least one multicast stream; or

0052-- information representing a lack of authorization of said receiving terminal to access any of said multicast streams of said plurality of multicast streams.

0053Such router equipment may of course have the various characteristics relating to the determination method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this equipment are the same as those of the determination method and are not detailed further.

0054According to another aspect, the invention relates to a receiver terminal capable of subscribing to one or at least one multicast group associated with the broadcasting of a multicast stream within a communication network, said receiver terminal comprising at least one processor configured to:

0055- receive, from a router device of said communication network, a first signaling request message, comprising at least one content service identifier;

0056- transmit, to said router equipment, a first signaling message, comprising at least one resolution key, called alias, selected by said receiving terminal as a function of said content service identifier;

0057- receive, from said router equipment, a second signaling request message, comprising at least one multicast group address, called authorized multicast address, of at least one multicast group associated with the broadcasting by said content service of at least one multicast stream that said receiving terminal is authorized to access

0058- transmit, to said router equipment, a second signaling message representing a request for subscription from said terminal to at least one multicast group associated with at least one of said at least one authorized multicast address.

0059Such a terminal may of course present the various characteristics relating to the subscription method according to the invention, which may be combined or considered in isolation. Thus, the characteristics and advantages of this terminal are the same as those of the subscription method and are not detailed further.

0060According 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.

0061The 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.

0062Such a recording medium may be any entity or device capable of storing the program. For example, the medium may include a storage medium, such as a ROM, for example a CD-ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a USB flash drive or a hard disk.

0063On 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.

0064The various embodiments mentioned above can be combined with each other to implement the invention.

Figures

0065Other 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:

0066<figref idref="f0001" num="1" /> schematically presents the different steps of a method for determining a set of multicast streams to which a receiving terminal is authorized to access, in a particular embodiment of the proposed invention;

0067<figref idref="f0002" num="2" /> presents a sequence diagram illustrating the exchanges of signaling messages between a communication network and a receiving terminal, in a particular embodiment of the proposed technique;

0068<figref idref="f0003" num="3" /> illustrates an example of formalism of an adapted IGMP signaling message of type “Query”, in a particular embodiment of the proposed invention;

0069<figref idref="f0004" num="4" /> illustrates an example of formalism of an adapted IGMP signaling message of type “Report”, in a particular embodiment of the proposed invention;

0070<figref idref="f0005" num="5" /> illustrates an example of a mechanism for subscribing a source to a simplified management service for access authorizations to multicast streams, in a particular embodiment of the proposed invention;

0071<figref idref="f0006" num="6" /> schematically presents the different stages of a method of subscribing a receiving terminal to a multicast group associated with the broadcasting of a multicast stream within a communication network, in a particular embodiment of the proposed invention;

0072<figref idref="f0007" num="7" /> describes a simplified architecture of a router equipment for implementing the proposed invention.

Detailed description of the invention

0073<b>1. </b><b>General principle – process implemented on the network side</b>

0074The invention described below makes it possible to overcome some of the aforementioned drawbacks.

0075The proposed technique makes it possible to manage in a simplified manner the verification of the authorizations of a terminal, called the receiving terminal, to access multicast content within a communication network. To this end, according to the general principle of the invention and as detailed below, various adaptations of the protocols for subscribing a receiving terminal to a multicast group are proposed, including in particular the implementation of mechanisms allowing the discovery and determination, by the network, of multicast streams to which a device is authorized to access. The invention is called AMUSE (for “Alias-based Multicast Service Enhanced”, in English).

0076According to a first aspect, the present invention relates to a method for identifying a set of multicast streams to which a receiving terminal is authorized to access, from among a plurality of multicast streams broadcast by a content service (typically a content broadcasting service) via a communication network. Such a set may possibly be empty, if it is determined at the end of the process that the receiving terminal in question is not authorized to access any of the multicast streams broadcast by the content service. The content service comprises one or more content servers delivering multicast streams, and possibly additional equipment requested to provide other functions associated with the broadcasting service (dedicated resolution server, application server for implementing negotiation phases with the network, for example to subscribe to a simplified authorization management service according to the present technique, etc.), as presented later. The method according to the present technique, illustrated by the<figref idref="f0001" num="1" />, is implemented by a router-type 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 an access router, or border router).

0077In a step 11, such a router receives, according to a reception procedure called RCP, from a receiving terminal connected to the network, a signaling message comprising at least one resolution key, also called AL alias in the context of this document. As detailed below, such an AL alias, which typically takes the form of textual data, is information that can be used by the router to determine the multicast streams to which the receiving terminal is possibly authorized to access. According to a particular characteristic, the signaling message received by the router follows a signaling request message previously sent by the router to a set of receiving terminals connected to the communications network and likely to be candidates for receiving multicast streams. In a particular embodiment, such a signaling request message comprises for example a content service identifier (one or more content servers that can act as a broadcast source for the same content) capable of broadcasting multicast streams on the communication network, on the basis of which the receiving terminal can choose the alias to be transmitted to the network, when such a terminal stores multiple aliases (e.g. different aliases related to different services to which it has subscribed and provided by different content providers.

0078In a step 12, the alias AL received by the router in step 11 is subject to a RES resolution procedure carried out or at least initialized by the router. More particularly, this alias is used by the router as a resolution key to obtain, if necessary, within a so-called authorization data structure, a set of multicast group addresses to which the receiving terminal has the right to access. In other words, such an authorization data structure (e.g., a database) comprises entries associating aliases with one or more multicast group addresses. Other additional information may also be associated with an alias in the authorization data structure, such as, for example, a service identifier associated with the alias, a validity period of the alias, information representative of a current validity of the alias, etc. If the alias presented by a receiving terminal in step 11 is present in the authorization data structure and is associated with multicast group addresses for a given service, then the receiving terminal is<i>a priori</i> authorized to access the multicast streams associated with these multicast group addresses (subject to any additional conditions for accessing the corresponding multicast streams, for example a check of the absence of multiple uses of the same alias by different receiving terminals as presented later in the document, are also verified). If, on the other hand, the alias presented by a receiving terminal in step 11 is not present for this service in the authorization data structure, or if it is present but it is not associated with any multicast group address or if it is associated with another service, then the receiving terminal is not authorized to access any multicast stream on the basis of the alias presented. The alias resolution procedure delivers, at the end of step 12, information IH, representing an authorization or an absence of authorization of the receiving terminal to access all or part of the multicast streams broadcast by a content source. According to different embodiments described below, the alias resolution procedure can be implemented entirely within the router, or jointly with third-party equipment.

0079In a first particular embodiment, the resolution of the alias is performed locally, i.e. entirely by the router that received the alias from the receiving terminal. In such an embodiment, the authorization data structure (or at least a copy of such a data structure) is available locally, within the router itself. The resolution is then immediate and does not require any additional resolution time.

0080In other particular embodiments, the resolution of the alias is implemented in conjunction with a third-party device, different from the router device that received the alias from the receiving terminal. In such an embodiment, the authorization data structure is generally not available within the router itself, so the router requests a third-party device that has access to this data structure. To this end, the router sends to the third-party equipment a resolution request comprising the alias obtained in step 11, and it receives in return authorization information from the third-party equipment, once the latter has carried out the resolution of the alias via a consultation of the authorization data structure.

0081The third-party equipment may, for example, be a communications network control equipment (more simply called a network controller in the remainder of this document). In certain embodiments, in particular in connection with a particular alias format detailed below, the third-party equipment may also be a domain name system server (or DNS servers, "<i>Domain Name System</i> » in English), or content service, equipment associated with the content service (for example a content service associated with this service, or a dedicated resolution server deployed for this service) which provides the multicast streams for which we wish to verify the possible authorizations of a receiving terminal.

0082As detailed below, the router has been previously configured, for example during a subscription phase to the simplified authorization management service, with the resolution mode to be implemented (local resolution or via third-party equipment, and in connection with which third-party equipment if applicable). When the router is configured to request third-party equipment for alias resolution, the configuration parameters provided to the router include the information necessary for the router to contact the third-party equipment, possibly including information for performing mutual authentication with the third-party equipment. One or more third-party equipment may be configured within a single router. Additionally, a router can be provided with dedicated or separate devices per service. In this case, the router selects which third-party device to contact based on the target service.

0083In all cases, at the end of the alias resolution procedure by the router, whether it was implemented entirely by the router or in conjunction with third-party equipment, the router obtains authorization information, which can be:

0084- information representing an authorization of the receiving terminal to access at least one multicast stream broadcast by the content service via the communication network, in which case the authorization information received includes the multicast group address(es) associated with the broadcast of the multicast stream(s) that the receiving terminal is authorized to receive (such multicast group addresses are then referred to as authorized multicast group addresses);

0085- information representing a lack of authorization of the receiving terminal to access any of the multicast streams broadcast by the content service on the communications network.

0086In a particular embodiment, when the information obtained by the router at the end of step 12 is representative of an authorization of the receiving terminal to access at least one multicast stream broadcast by the content service via the communication network, and the router therefore has knowledge at this stage of at least one multicast group address associated with said stream, and possibly, of the unicast addresses of the sources involved in the broadcasting of requested content, new signaling messages are exchanged between the router (i.e. the network) and the receiving terminal to allow the receiving terminal to join one of these groups. Such an exchange is based, for example, on signaling protocols designed for this purpose, possibly adapted in the context of the present technique, 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. It should be remembered that these existing signaling protocols are based on similar operating principles: a device requesting communication from the communication network, typically a router, regularly sends “Query” type messages to 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, in French) to subscribe to a particular group listed in the "Query" message, and thus indicate that they wish to receive the multicast stream associated with this group. A "Report" type message explicitly provides the receiver's reachability information (typically an IP address) as well as the multicast group address(es) that the receiver wishes to access. The use of conventional IGMP/MLD messages as previously described, however, does not allow the implementation of the present technique, at least not without adaptation, if only because additional message exchanges for obtaining and resolving the alias, not provided for in these protocols, are required. Such operations can be performed by means of dedicated messages. However, for the purposes of simplifying integration into the existing ecosystem, in an implementation example described below in connection with the<figref idref="f0002" num="2" />, in a particular embodiment, an implementation is proposed based on adjustments and extensions to existing IGMP/MLD messages.

0087More particularly, in a step 21, a requesting device from the communications network, typically a router R, sends messages at regular frequency which can be likened to “Query” type messages to the receivers connected to the network (via a multicast group address available for this purpose, for example the address 224.0.0.1 in the case of IGMP signaling). Like a conventional "Query" message, such a message constitutes a first signaling request message. However, unlike a conventional "Query" message, it does not identify any multicast group, and therefore does not include any explicit multicast group address. An example of a first signaling request message in one embodiment of the present technique is illustrated by<figref idref="f0003" num="3" />. According to a particular characteristic, such a message may optionally include a service identifier.

0088In response to this first signaling request message, a receiving terminal TR transmits to the requesting equipment R, in a step 22, a message which can be likened to a first signaling message of the “Report” type. This message explicitly provides the reachability information of the receiving terminal TR (typically an IP address). It further comprises at least one alias, possibly selected by the receiving terminal TR based on the service identifier, when such an identifier is included in the previously received signaling request message. Such a signaling message is of course only transmitted if at least one alias is associated with the receiving terminal (and, in addition, where applicable, with the target service identified in the signaling request message).

0089Upon receipt of the signaling message comprising at least one alias, the requesting equipment R proceeds in a step 23 to resolve this alias, according to the methods already described previously (for example locally or via third-party equipment, depending on the previously established configuration of the router R). If applicable, at the end of this alias resolution procedure, the requesting equipment has at least one multicast group address of at least one multicast group associated with the alias obtained in step 22.

0090In a step 24, the requesting equipment R then sends to the receiving terminal a second signaling request message, which can also be compared to a classic “Query” type message, in that it contains a list of addresses of multicast groups to which the receiving terminal can subscribe. However, this message differs from a conventional “Query” message in that it is adapted to target a particular receiving terminal (the receiving terminal which responded in step 22 to the first signaling request message), and in that it only includes the addresses of the multicast groups to which this receiving terminal is authorized to access, obtained in step 23. These multicast group addresses are optionally accompanied by the corresponding alias as conveyed in this second signaling request message.

0091In response to this second signaling request message, the receiving terminal TR transmits to the requesting equipment R, in a step 25, a message which can be compared to a classic “Report” type message. This message includes the addresses of the multicast groups to which the receiving terminal TR wishes to subscribe, among those listed in the second signaling request message. An example of such a signaling message in one embodiment of the present technique is illustrated by<figref idref="f0004" num="4" />. Note that in the case of use of a communication network implementing network slices, such a message can be sent at the end of a phase of connection of the receiving terminal to a network slice. For example, the terminal extracts an identifier of the slice encoded in a multicast group address received in the second signaling request message sent in step 24 after resolution of the alias. Several scenarios can then arise. If the connection to the identified slice is already effective, the receiving terminal adds the corresponding multicast group address to the list of addresses to be sent in the “Report” message sent in step 25. If the connection to the identified slice is not yet effective, and in the absence of contrary instructions obtained by the receiving terminal, the latter connects to the slice in question and, once the connection is established, it adds the corresponding multicast group address to the list of addresses to be sent in the “Report” message sent in step 25. The receiving terminal is then able to receive the multicast stream routed along an ad hoc distribution tree deployed in the slice to which it has connected. In the event of an inability to establish a connection to the identified slice, the receiving terminal excludes the corresponding multicast group address from the list of multicast addresses to be sent in the message in the “Report” message sent in step 25.

0092Thus the receiving terminal can only access the multicast streams to which it is authorized to access, the addresses of the multicast groups to which it is not authorized to subscribe are never communicated to it.

0093We are now interested in an embodiment of the present technique, in which the alias presents a particular formalism. More particularly, in this particular embodiment, the alias is constructed on a format similar to a domain name (see for example RFC 1035), comprising one or more hierarchical levels. It is thus for example formed of a "label" or a concatenation of several labels separated by the same separator (typically the character<i>point</i> ".") and ordered according to a predefined hierarchical structure. An alias can for example have a format of the type "&lt;<i>alias-grandson</i>&gt;.&lt;<i>alias-son</i>&gt;.&lt;<i>parent-alias</i>&gt; » (according to an example with three hierarchical levels, given for purely illustrative and non-limiting purposes).

0094Such an alias format is interesting for several reasons.

0095First, it allows for the clever use of Domain Name System servers (or DNS servers,<i>Domain Name System</i> » in English) to resolve aliases. In other words, we exploit the ability of these servers to return IP addresses based on a domain name, but for a different use than the common use of determining an IP address of a server to contact from a domain name, for example, included in a URL (Universal Resource Locator, or "URL").<i>Uniform Resource Locator</i> » in English). Thus, in the context of the present technique, these DNS servers are used as third-party equipment to be contacted by a router for the resolution of aliases formatted as domain names, and return on the basis of these aliases the addresses of multicast groups identifying multicast streams to which receiving terminals are authorized to access. In addition, the use of such a structure also makes it possible to present the alias in the security certificates associated with a receiving terminal. This relies on an architecture and mechanisms already existing and optimized for the resolution of aliases, which makes it possible to simplify the implementation of the present technique and to achieve savings in terms of costs and development and/or deployment time for example.

0096Second, the hierarchical structure of an alias in the format of a domain name can be exploited to provide even more flexibility to the alias resolution mechanism according to the present technique. For example, in a particular embodiment, one or more hierarchically higher levels of the alias, forming a sub-alias called a parent alias within the alias, can be used to uniquely identify a content service. Such a feature allows, for example, a router configured to request alias resolutions from third-party equipment (e.g., a server operated by a content service provider, a dedicated resolution server of a content service provider, a server involved in providing the content service) to identify, based on the parent alias, to which equipment (e.g. operated by a content service provider) it should actually forward its resolution request. Thus, such a router will know, for example, that it should request:

0097- the content service<i>sc1</i> if he receives an alias "<i>encoding3.content1.sc1 »</i> Or "<i>content14.sc1 »</i>(because the common parent alias of these aliases is "<i>sc1 »</i>) <i>;</i>

0098- the content service<i>sc2</i> if he receives an alias<i>content1.sc2</i> Or<i>sc2</i>(because the common parent alias of these aliases is "<i>sc2 »</i>) <i>;</i>

0099- the content service<i>sc3</i> if he receives an alias "<i>content1.sc3</i> " Or "<i>encoding2.content2.sc3 »</i> Or "<i>receiver44.sc3 »</i>(because the common parent alias of these aliases is "<i>sc3 »</i>) <i>;</i>

0100- etc.

0101The preceding examples are of course given for purely illustrative and non-limiting purposes.

0102For the purposes of these exchanges for resolution purposes, the router may in particular have and maintain an addressing table matching parent aliases and IP addresses allowing contact with associated content servers.

2. Subscription to the service

0103We present, in relation to the<figref idref="f0005" num="5" />, a subscription phase to the service for managing access authorizations to multicast flows according to the proposed technique, implemented upstream of the signaling operations previously presented by which a receiving terminal indicates its intention to join a multicast group. This subscription phase is implemented by a piece of equipment of a content service (called a source) SRC which has the capacity to broadcast them according to the multicast transmission mode via the communication network. Such a source can for example be a content server of the content service, a resolution server associated with this service, or even equipment dedicated to this service. In a particular embodiment, the network's ability to support management of access authorizations to multicast streams according to the present invention is for example exposed by the network by means of an application programming interface ("<i>Application</i><i>Programming</i><i> Interface</i> » in English, or dedicated API). Depending on a particular characteristic, a dynamic negotiation protocol such as the CPNP protocol (“<i>Connectivity Provisioning</i><i>Negotiation</i><i> Protocol</i> ", RFC8921) is used to expose such an interface, the network hosting a CPNP server while a content service device (typically an application server) embeds a CPNP client. This example is however not limiting, and other protocols such as for example the RESTCONF protocol (RFC8040) can also be used to expose this API.

0104The SRC content service wishing to subscribe to the access authorization management service transmits, by means of the dedicated API described above, an SBSC subscription request, comprising at least one source identifier, for example an IP address (possibly associated with a port number) at which the SRC content service capable of broadcasting multicast content can be contacted, or an identifier extracted from a certificate presented to this content service in a request to establish a security association (TLS (“Transport Layer Security”, in English), DTLS (“Datagram Transport Layer Security”, in English), etc.). According to a particular feature, the SBSC subscription request also includes data relating to aliases already generated, or that the content service is configured to generate such aliases within the framework of the present technique. Thus, by way of example and according to a particular characteristic, the messages exchanged with the network within the framework of a subscription request include at least one generic alias, corresponding to a parent alias as previously presented (for example “sc1”) associated with the SRC content service. As part of the subscription mechanism, the network is asked to associate this parent alias and/or child domain names of this parent alias (typically, to use the previous example, any domain name in the format "<i>*.sc1 »</i>, e.g. "<i>content7.sc1 »</i>, « <i>encoding1.content3.sc1 »</i>, « <i>receiver45.sc1</i> ") to one or more multicast group addresses used by the network for broadcasting content using the multicast transmission mode, depending on the desired authorizations. The parent alias also makes it possible to identify the third-party server to use for alias resolution. For example, during resolution, the communication network is able to route any resolution requests concerning child aliases to the authoritative server of the parent alias. To do this, a router device only needs to locally maintain the identity of a server associated with a parent alias, and does not need to maintain specific entries per child alias.

0105According to a particular feature, the SBSC subscription request also includes data relating to a desired alias resolution mode. An “ALIAS_RESOLUTION_MODE” parameter can, for example, be used for this purpose. Thus, for example:

0106- if “ALIAS_RESOLUTIONS_MODE == LOCAL”, then it is the router that receives the alias that takes care of the resolution itself;

0107- if "ALIAS_RESOLUTIONS_MODE == DNS", then the DNS domain name system is used for alias resolution;

0108- if "ALIAS_RESOLUTION_MODE == SC", then all resolution requests for a child alias of a parent alias must be relayed to the SRC content service. In the latter case, optionally, an “ALIAS_RESOLVER” parameter may also be communicated to the network where appropriate, to indicate the IP address(es) of additional equipment (typically resolution servers) associated with the content service, when the latter does not perform the resolution itself.

0109To complete the subscription process for the multicast stream access authorization management process, several iterations of information exchanges between the content service that initiated the request for said subscription and the network may be necessary. In response to the request to subscribe to said process, once all the exchanges have been finalized, a network element, such as a network controller, sends an ACK_SBSC message to the content service confirming the correct subscription to the process for managing access authorizations to multicast streams.

0110<b>3. </b><b>Alias ​​Diversity - Communicating Aliases to the Receiving Terminal</b>

0111We are now interested in the process of generating aliases, and their communication to the receiving terminal.

0112As presented previously, an alias is a resolution key that can be used to identify, in a so-called authorization data structure, addresses of multicast groups to which a device that is aware of the alias – typically a receiving terminal – is authorized to access.

0113In the context of this technique, it should be noted that aliases can be associated with different entities, depending on the intended purpose. For example, depending on the intended use, it is possible to have different types of aliases, such as:

0114- aliases associated with receiving terminals: the alias is then, for example, used to retrieve a plurality of multicast group addresses allowing access to a set of content – ​​typically a catalog of content offered by a content provider – which the receiving terminal holding the alias is authorized to access;

0115- aliases associated with one or more contents: the alias is then, for example, used to retrieve a plurality of multicast group addresses associated with the same content available in several encodings (SD, HD, 4K, etc.) which the receiving terminal holding the alias is authorized to access;

0116- aliases associated with content in a particular encoding: the alias is then, for example, used to retrieve a multicast group address associated with content in a given encoding which the receiving terminal holding the alias is authorized to access;

0117- in the case of a communication network implementing network slices, aliases associated with a network slice used to receive multicast content: the alias is then, for example, used to retrieve a multicast group address associated with content which the receiving terminal holding the alias is authorized to access, together with additional information (for example encoded in the multicast address) relating to a network slice to be used to receive the content in question;

0118- aliases associated with service classes used in the communication network to receive multicast content;

0119- etc.

0120In other words, aliases are not necessarily all associated with the same type of information, but all have in common the ability to allow a particular receiving terminal to identify one or more multicast group addresses (i.e. associated with one or more multicast contents) to which a receiving terminal is authorized to access.

0121Aliases can be made available to a receiving terminal in several ways.

0122In a particular embodiment, an alias is transmitted by a content service that generated it to a receiving terminal via an encrypted transmission established on a communication network. It can for example be obtained by the receiving terminal by means of a dedicated application installed on this receiving terminal, or by a connection to a dedicated server via a browser or any other application installed on this terminal. In another embodiment, an alias may be displayed on a dedicated HTTP page accessible to a user after authentication, in order to be entered directly by the user in a dedicated application of the receiving terminal. In other particular embodiments, an alias (in particular an alias associated with a receiver terminal) may have been stored in a memory of the receiver terminal upon manufacture of this terminal such as a TV decoder or a Set-Top Box (STB), where applicable, or at least before its marketing.

0123In a particular embodiment, the generation of aliases by a content service is carried out in such a way as to guarantee a uniqueness of alias per receiver likely to be authorized to access all or part of the broadcast content. In other words, the content service generates a unique alias per receiver. Such a mode is advantageous in that it allows, on the one hand, to simplify the operations of authorizing access to content of a content service, and on the other hand to facilitate the implementation of traffic classification rules at the edge of the network and to avoid the sharing of the same identifier between several terminals. Thus, the detection of duplicate aliases during the resolution procedure can be considered as an anomaly in a particular embodiment of the proposed technique. The authorization to access multicast streams can then, for example, be delivered to only one receiving terminal among those which present the same alias (for example to the receiving terminal which presents the alias for the first time). Alternatively, the content distribution service may, for example, be refused to all receiving terminals that have the same alias, without distinction, and access to multicast streams is then refused to all of said terminals. According to a particular characteristic, in order to implement the restrictions relating to duplicate aliases previously mentioned, the procedure for resolving an alias comprises a step of searching for said alias within a list of aliases marked as having already been resolved, and, in the event of the presence of said alias in said list, the delivery of information representing a lack of authorization of the receiving terminal having presented the alias to access any of the multicast streams broadcast by the content service with which the alias is associated. Depending on the embodiment implemented, the uniqueness of the alias can be implemented at the level of a content service considered (the alias is then unique per service, but the same alias is likely to be used in connection with several distinct content provider services), or be universal (an alias is then assumed to be globally unique, including in a context where receiving terminals are authorized to access content broadcast by separate content providers).

0124It should be noted that in the context of this technique, the multicast group addresses associated with an alias may in some cases change depending on various parameters. For example, when the communication network implements network slices, and the multicast group addresses are constructed in such a way as to encode within them particular network slices to be used for routing traffic (a multicast group address then being in fact associated with a network slice), it may prove interesting in certain situations – for example depending on data representative of a current state of the communication network, received from various control devices deployed within the network – to modify the multicast group address(es) associated with an alias in such a way as to allow traffic to be switched to a different network slice than that associated with the multicast group address(es) initially associated with the alias in the authorization data structure. Data representative of a current state of the communication network includes, 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 as many indicators likely to encourage a redirection of multicast traffic from one slice to another (in particular if these indicators deteriorate over time). Thus, depending on the results of the resolution of an alias and the traffic routing conditions within the different slices, a redirection of traffic to another network slice can be automatically implemented. Such redirection can be performed at the initiative of the communication network (typically by a controller in charge of allocating and managing network resources, or by a router device based on information transmitted by the controller in order to enable it to select the slice to which to direct the multicast traffic). Alternatively, the redirection of multicast traffic can also be performed at the initiative of the content service. In this case, a server associated with this service informs the network (e.g. via an API) of a new multicast group address to be used for a given alias. A network controller can then identify the entities (router devices and receiving terminals) involved in subscribing to the corresponding multicast group and in routing the corresponding multicast traffic, and inform these entities of the change in the multicast group address. In this context, a "Query" type signaling message including the new group address is sent by the requesting routers (i.e., routers that include the IGMP Querier or MLD Querier function) to the receiving terminals concerned. Upon receipt of this message, the receiving terminals in question respond to the requesting equipment with a "Report" type message, according to the methods previously described in relation to the<figref idref="f0002" num="2" />, when they wish to continue receiving the corresponding content. It should be noted that in the event of a decision to redirect traffic, additional mechanisms according to a dynamic routing protocol are also implemented, in order to allow the connection of the receiving terminal to an ad hoc distribution tree.

4. Process implemented on the terminal side

0125According to another aspect, the invention also relates to a method for subscribing a receiving terminal to at least one multicast group associated with the broadcasting of a multicast stream within a communication network implementing network slices. Such a method, illustrated by the<figref idref="f0006" num="6" /> in a particular embodiment, is implemented by a receiving terminal connected to the communications network.

0126In a step 61, the receiving terminal receives a first signaling request message from the network, typically from a router device. As described previously in relation to the method implemented on the network side, such a message may for example take the form of a “Query” type signaling message adapted for the needs of the present technique. This first signaling request message includes, in a particular embodiment, a service identifier (here, content broadcasting service).

0127Upon receipt of this message, and possibly on the basis of the service identifier included therein, the receiving terminal determines, for example within a data structure stored in a memory of this terminal, at least one alias intended to be used as a resolution key by the network to determine whether or not the receiving terminal is authorized to access multicast streams associated with said service identifier, and where appropriate, the multicast groups that the receiving terminal is authorized to access.

0128In a step 62, in response to the first signaling request message, the receiving terminal transmits to the router equipment a first signaling message, comprising said alias. As described previously in relation to the method implemented by the network, such a message may for example take the form of a signaling message of the “Report” type (i.e. of the “Rapport” type, in French) adapted for the needs of the present technique

0129In a step 63, the receiving terminal receives a second signaling request message from the communication network, after the latter has resolved the alias. This second signaling request message, which may also, for example, take the form of a “Query” type signaling message (i.e. of type "Request", in French) adapted for the needs of the present technique, comprises at least one multicast group address, called authorized multicast address, identifying at least one multicast group associated with the broadcasting by a content service (and where applicable, the content broadcasting service identified by the identifier received in step 61) of at least one multicast stream to which the receiving terminal is authorized to access.

0130In a step 64, in response to the second signaling request message, the receiving terminal transmits to the router equipment a second signaling message representative of a subscription request from the receiving terminal to at least one multicast group associated with at least one of said at least one authorized multicast group address.

5. Devices

0131Finally, we present, in relation to the<figref idref="f0007" num="7" /> simplified structures of an entity, for example a router device of a communication network or a receiving terminal, according to at least one embodiment described above.

0132As illustrated by the<figref idref="f0007" num="7" />, such an entity comprises at least one memory 71 comprising a buffer memory, at least one processing unit 72, equipped for example with a programmable computing machine or a dedicated computing machine, for example a processor P, and controlled by the computer program 73, implementing steps of at least one method according to at least one embodiment of the invention.

0133Upon initialization, the code instructions of the computer program 73 are for example loaded into a RAM memory before being executed by the processor of the processing unit 72.

0134If the entity is a router device of the communication network, the processor of the processing unit 72 implements steps of the method for determining a set of multicast streams to which a receiving terminal is authorized to access from among a plurality of multicast streams broadcast by a content service via the communication network, as described previously, according to the instructions of the computer program 73, for:

0135- receive, from said receiving terminal, a first signaling message comprising a resolution key, called an alias, usable by said router equipment to determine said set;

0136- implementing a procedure for resolving said alias, comprising obtaining, as a function of said alias, information from among: (i) information representing an authorization of said receiving terminal to access at least one multicast stream of said plurality of multicast streams, comprising at least one multicast group address, called authorized multicast address, of at least one multicast group associated with the broadcasting of said at least one multicast stream; or (ii) information representing a lack of authorization of said receiving terminal to access any one (or at least one) of said multicast streams of said plurality of multicast streams.

0137If the entity is a receiving terminal wishing to receive a multicast stream, the processor of the processing unit 72 implements steps of the method of subscribing to a multicast group described previously, according to the instructions of the computer program 73, to:

0138- receive, from a router device of said communication network, a first signaling request message, comprising at least one content service identifier;

0139- transmit, to said router equipment, a first signaling message, comprising at least one resolution key, called alias, selected by said receiving terminal as a function of said content service identifier;

0140- receive, from said router equipment, a second signaling request message, comprising at least one multicast group address, called authorized multicast address, of at least one multicast group associated with the broadcasting by said content service of at least one multicast stream that said receiving terminal is authorized to access

0141- transmit, to said router equipment, a second signaling message representing a request for subscription from said terminal to at least one multicast group associated with at least one of said at least one authorized multicast address.