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

Description

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

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 broadcasting services using a multicast transmission mode in a communication network.

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 known as "multicast". 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 takes turns being the source or receiver. In Internet Protocol (IP) networks, multicast transmission relies on the computation, 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 deterministic data replication.

[0003] Communication networks, in particular fifth generation (5G) mobile networks, also offer the possibility for operators who operate them to manage authorizations (also called 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.

[0004] In this context, the policy for routing content broadcast in multicast on a communication network is based in particular on the authorization of the receiver terminals to access said content. For example, if the communication 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 broadcast 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.

[0005] However, the implementation and maintenance (e.g. in the event of modifications 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.

[0006] There is therefore a need for a technique making it possible to simplify the management of access authorizations of receiver terminals to multicast content broadcast within a communication network, and more particularly the obtaining of such authorization information by the network.

Summary of the invention

[0007] The 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 communication 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] - receiving, from said receiving terminal, 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 receiver 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.

[0010] In this way, the communication 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.

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

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

[0013] In another particular embodiment, said resolution procedure is implemented jointly with third-party equipment, said obtaining comprising:

[0014] - the transmission, to said third-party equipment, of a request for resolution of said alias, comprising said alias.

[0015] - the reception, from said third-party equipment, of said information representing an authorization or an absence of authorization.

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

[0017] - equipment for controlling said communication network;

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

[0019] - equipment associated with said content service.

[0020] In 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.

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

[0022] In this way, the 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.

[0023] According 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.

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

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

[0026] In this way, the communication network is in particular able to route to the authoritative server of the parent alias any resolution request concerning child aliases.

[0027] In 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.

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

[0029] In 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 communication network.

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

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

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

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

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

[0035] In 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] - the transmission, to said receiving terminal, of a second signaling request message comprising said at least one authorized multicast address;

[0037] - 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.

[0038] In 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.

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

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

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

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

[0043] According 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 representative of a request for subscription of said terminal to at least one multicast group associated with at least one of said at least one authorized multicast address.

[0048] According 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] - implementing a procedure for resolving said alias, comprising obtaining, as a function of said alias, information from among:

[0051] — information representing an authorization of said receiver 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 one of said multicast streams of said plurality of multicast streams.

[0053] Such 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.

[0054] According 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] - transmitting, 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 receiver terminal is authorized to access

[0058] - transmit, to said router equipment, a second signaling message representative of 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.

[0059] Such a terminal may of course have 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.

[0060] 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.

[0061] 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.

[0062] 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.

[0063] 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.

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

Figures

[0065] 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:

[0066] [Fig.l] 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] [Fig.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] [Fig.3] illustrates an example of formalism of an adapted IGMP signaling message of type “Query”, in a particular embodiment of the proposed invention;

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

[0070] [Fig.5] illustrates an example of a mechanism for subscribing a source to a simplified management service for access authorizations to multicast flows, in a particular embodiment of the proposed invention;

[0071] [Fig.6] schematically presents the different steps of a method of subscribing a receiver 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] [Fig.7] describes a simplified architecture of a router equipment for implementing the proposed invention.

Detailed description of the invention

[0073] 1. General principle - method implemented on the network side

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

[0075] The proposed technique in fact makes it possible to manage in a simplified manner the verification of the authorizations of a terminal, called the receiver 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

Enhanced Service”, in English).

[0076] According to a first aspect, the present invention relates to a method for identifying 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 (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 [Fig.l], 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).

[0077] In 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 alias AL 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.

[0078] In a step 12, the alias AL received by the router in step 11 is the subject of 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 a priori 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.

[0079] In a first particular embodiment, the resolution of the alias is carried out locally, that is to say entirely by the router which 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.

[0080] In other particular embodiments, the resolution of the alias is implemented jointly 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 latter requests a third-party device having 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.

[0081] The third-party equipment may, for example, be communication 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, “Domain Name System” in English), or even a 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 check the possible authorizations of a receiving terminal.

[0082] As detailed below, the router has previously been 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.

[0083] In all cases, at the end of the alias resolution procedure by the router, whether it has been implemented entirely by the router or jointly with third- party equipment, the router obtains authorization information, which may 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 comprises 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.

[0086] In 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 [Fig.2], an implementation based on adjustments and extensions to existing IGMP/MLD messages is proposed in a particular embodiment.

[0087] More particularly, in a step 21, a requesting device of the communication network, typically a router R, sends at regular frequency messages which can be assimilated 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 in [Fig. 3]. According to a particular characteristic, such a message may optionally include a service identifier.

[0088] In 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).

[0089] Upon 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.

[0090] In 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.

[0091] In 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 an embodiment of the present technique is illustrated by [Fig. 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 a slice identifier encoded in a multicast group address received in the second signaling request message sent in step 24 after alias resolution. Several scenarios may 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.

[0092] Thus the receiving terminal only has the possibility of having access to the multicast streams to which it is authorized to access, the addresses of the multicast groups to which it does not have the right to subscribe never being communicated to it.

[0093] We are now interested in an embodiment of the present technique, in which the alias has 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 from a "label" or a concatenation of several labels separated by the same separator (typically the dot character ".") and ordered according to a predefined hierarchical structure. An alias can, for example, have a format of the type "<alias-grandson>.<alias-son>.<alias-parent>" (according to an example with three hierarchical levels, given for purely illustrative and non-limiting purposes).

[0094] Such an alias format is interesting for several reasons.

[0095] First, it allows for the clever use of Domain Name System (DNS) servers 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 (Uniform Resource Locator). Thus, within the framework 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.

[0096] Second, 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 sel content service if it receives an alias “encodings.content.sel” or “contentl4.sc 1” (because the parent alias common to these aliases is “sel”);

[0098] - the sc2 content service if it receives an alias contenul.sc2 or sc2 (because the parent alias common to these aliases is “sc2”);

[0099] - the sc3 content service if it receives an alias “contentl.sc3” or “encoding2.content2.sc3” or “receptor44.sc3” (because the parent alias common to these aliases is “sc3”);

[0100] - etc.

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

[0102] For 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 associated content servers to be contacted. 2. Subscription to the service

[0103] We present, in relation to [Fig.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 expresses 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 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 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.

[0104] The SRC content service wishing to subscribe to the access authorization management service transmits, by means of the dedicated API previously described, 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 “sel”) 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 "*.scl", e.g. "content?.sel", "encoding l.content3.sel", "receiver45.scl") 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 identifies the third-party server to use for alias resolution. For example, during resolution, the communications network can route any resolution requests for 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 for each child alias.

[0105] According to a particular characteristic, the SBSC subscription request also includes data relating to a desired alias resolution mode. An “ALIAS_RESOLUTION_MODE” parameter may for example be used for this purpose. Thus, by way of illustration:

[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.

[0109] To complete the subscription process to the method for managing access authorizations to multicast streams, several iterations of information exchanges between the content service at the origin of the request for said subscription and the network may prove 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] 3. Alias ​​Diversity - Communication of Aliases to the Receiving Terminal

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

[0112] As 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.

[0113] In the context of the present technique, it should be noted that aliases can be associated with different entities, depending on the intended purpose. For example, depending on the desired 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 contents - typically a catalog of contents 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.

[0120] In other words, the aliases are not necessarily all associated with the same type of information, but all have in common the capacity 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.

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

[0122] In 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.

[0123] In 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 Talias 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 Talias to access any of the multicast streams broadcast by the content service with which Talias is associated. Depending on the implemented embodiment, the uniqueness of Talias can be implemented at the level of a content service considered (Talias 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).

[0124] It should be noted that in the context of the present technique, the multicast group addresses associated with an alias may in certain cases evolve according to 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 so 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 which 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 [Fig.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

[0125] According to another aspect, the invention also 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 implementing network slices. Such a method, illustrated by [Fig.6] in a particular embodiment, is implemented by a receiver terminal connected to the communication network.

[0126] In 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).

[0127] Upon 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.

[0128] In 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.

[0129] In 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.

[0130] In 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

[0131] Finally, in relation to [Fig.7], we present the 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.

[0132] As illustrated by [Fig.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.

[0133] At 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.

[0134] If 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 receiver 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.

[0137] If 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 receiver 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.