WO2017125149A1

WO2017125149A1 - Switching between encrypted unicast and encrypted multicast in a content distribution network

Info

Publication number: WO2017125149A1
Application number: PCT/EP2016/051122
Authority: WO
Inventors: Beatriz Grafulla-González; Ali El Essaili; Tomas Frankkila
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-01-20
Filing date: 2016-01-20
Publication date: 2017-07-27

Abstract

In a content distribution network (CDN), it is often advantageous to switch encrypted unicast sessions to encrypted multicast sessions. In such a scenario the exchange of keys often causes a problem. The solution lies in a concerted action during the switching action in that form that once the unicast edge redirects communication devices to a multicast edge, the multicast edge obtains the required encryption keys from a key handling node. The disclosure further details the method performed by such a key handling node, as well as the one performed by the unicast edge.

Description

SWITCHING BETWEEN ENCRYPTED UNICAST AND ENCRYPTED MULTICAST IN A

CONTENT DISTRIBUTION NETWORK

TECHNICAL FIELD

The invention relates to content distribution in a network, and in particular to switching between encrypted unicast and encrypted multicast transmission in a content distribution network.

BACKGROUND

Content Distribution/Delivery Networks (CDNs) are widely deployed to place media content closer to the end-user. A CDN includes origin servers, multiple distributed edge servers (or replica servers), and a Request Redirector, RR. The serving edge server for an end-user, or client, is typically determined by the RR based on e.g. proximity to the user, server load, and content availability at edge servers. Herein, edge servers will also be referred to as "edge nodes" or "edges".

Traditionally, content in CDNs is served to clients by unicast transmission. In other words, the client makes contact with an edge to request the desired content, and the edge then serves the client with the requested content by means of unicast. This is illustrated in figure 1 , were a client 101 requests (1 ) content from an edge node 102. In case the edge node 102 does not already host the requested content, the edge node 102 requests (2) the content from a central server 103, typically denoted "origin". The origin 103 delivers (3) the requested content to the edge node 102, which provides it (4) to the client 101 . However, providing media content to a plurality of users by unicast transmission is resource demanding. Therefore, in order to increase the efficiency of media transmission, multicast can be used (instead of unicast) when a large number of users are interested in consuming the same content. That is, content delivery by multicast has been considered for increasing the cost efficiency inside CDNs.

A current trend in data transmission is an increased use of encrypted traffic. Companies like e.g. Netflix have already announced their intention to encrypt their traffic. In the case of CDNs, encrypted traffic could occur between different entities:

• in the "first" mile - between the content provider and the ingestion point at the origin; · in the "middle" mile - between the origin and the caches and/or edges within the

CDN;

• in the "last" mile - between the edge and the client/end-users. Traffic may be encrypted according to different schemes, of which so-called symmetric key encryption and public key encryption are the two main schemes. In symmetric key encryption (cf. figure 2, upper alternative), a message is encrypted and decrypted with the same key, which is therefore deployed by both the sender and the receiver. The main advantage of symmetric key encryption deals with fast performance; whereas the main drawbacks are that the key needs to be stored securely and that a secured channel is needed to transfer the key. In public key encryption, on the other hand (cf. figure 2, lower alternative), a message is encrypted with a public key; whereas the message is decrypted with a different, private key. The private/public key pair is generated by a client who wants to receive an encrypted message. The client, having generated the pair, sends the public key to an intended sender of the encrypted message, so that it can use the key for encrypting the message. The main advantage of public key encryption is that stealing the public key does not enable to decrypt a message encrypted with the public key. Therefore, a public key can be sent through a non-secured channel. The main drawbacks of public key encryption are that the private key still needs to be stored securely and that the performance is worse than for the symmetric key scheme. Without losing generality, the description of the inventive solution herein mainly focuses on the public key encryption scheme.

Secure multicast communications have been considered in prior art, e.g. in the US patents US8458462B1 and US8218772B2. The document US8458462B1 describes a method for verifying the characteristics of an end-device which is requesting to join a multicast group, whereas the document US8218772B2 describes a method for establishing a secure multicast channel between a service provider and terminal such as a set-up box.

However, there is a need for improved solutions in regard of security in CDNs. SUMMARY

It is desired to achieve improved solutions in regard of security of data communications in CDNs. This is achieved by embodiments described herein, and according to the appended set of claims. Embodiments herein relate to the performance of a switch between unicast and multicast transmission in CDNs, given that the traffic is encrypted. In other words, embodiments herein provide a mechanism to dynamically serve client requests by unicast and multicast encrypted transmissions, depending on relevant parameters during a streaming session. The proposed approach allows a CDN provider to switch in a flexible and dynamic way between encrypted unicast and encrypted multicast transmissions to improve the scalability and cost efficiency, while considering the particularities of encrypted traffic.

According to a first aspect, a method is provided, which is to be performed by a Key Handling node. The provided method is for supporting switching between encrypted unicast and encrypted multicast in a CDN. The method comprises receiving a request, from an edge node in the CDN, for an encryption key associated with a Communication Device, CD, requesting content/data from the edge node. The method further comprises: when not having access to the requested encryption key obtaining the requested encryption key from the CD or from a provider of the requested content. The method further comprises providing the requested encryption key to the edge node.

According to a second aspect, a method is provided, which is to be performed by an edge node operable in a CDN. The edge node is operable to serve CDs by unicast. The provided method is for switching between encrypted unicast and encrypted multicast. The method comprises receiving requests for the same content/data from a plurality of CDs. The method further comprises: when not having access to one or more encryption keys for the plurality of CDs: obtaining the one or more encryption keys for the CDs from a Key Handling node associated with the CDN. The method further comprises: when a criterion for switching CDs from unicast to multicast is met: redirecting at least part of the plurality of CDs to multicast. According to a third aspect, a method is provided, which is to be performed by an

arrangement in a CDN. The arrangement comprises an edge node, UC edge, which is operable to serve CDs by unicast; an edge node, MC edge, operable to serve CDs by multicast. The CDN is further associated with a Key Handling node for storing and providing encryption keys to edge nodes. The method is for switching between encrypted unicast and encrypted multicast, and comprises that the UC edge receives requests from a plurality of

CDs for the same content/data. The UC edge obtains one or more encryption keys for the plurality of CDs from the Key Handling node. The UC edge further redirects at least part of the plurality of CDs to multicast, when a criterion for switching CDs from unicast to multicast is met. The method further comprises that the MC edge receives requests from a number of the redirected CDs for the content/data; and that the MC edge, obtains one or more encryption keys for the number of redirected CDs from the Key Handling node, when not having access to one or more encryption keys for the number of redirected CDs.

According to a fourth aspect, a Key Handling node is provided, which is operable to be associated with a CDN. The Key Handling node is configured to receive a request, from an edge node in the CDN, for an encryption key associated with a CD requesting content/data from the edge node; and further configured to obtain the requested encryption key from the CD or from a provider of the requested content, when not having access to the requested encryption key. The Key Handling node is further configured to provide the requested encryption key to the edge node.

According to a fifth aspect, an edge node is provided, which is operable, in a CDN, to serve CDs by unicast. The edge node is configured to receive requests for the same content/data from a plurality of CDs; and further to obtain one or more encryption keys for the CDs from a Key Handling node associated with the CDN, when not having access to the one or more encryption keys for the plurality of CDs. The edge node is further configured to redirect at least part of the plurality of CDs to multicast when a criterion for switching CDs from unicast to multicast is met.

According to a sixth aspect, a computer program is provided, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to the first, second or third aspect.

According to a seventh aspect, a carrier is provided, containing the computer program of the sixth aspect.

BRIEF DESCRIPTION OF DRAWINGS

The foregoing and other objects, features, and advantages of the technology disclosed herein will be apparent from the following more particular description of embodiments as illustrated in the accompanying drawings. The drawings are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the technology disclosed herein.

Figure 1 is a schematic diagram of a CDN according to the prior art. Figure 2 is a schematic diagram different types of encryption keys, according to the prior art.

Figure 3 is a schematic diagram illustrating unicast in a CDN comprising a Request

Redirector.

Figure 4 is a schematic diagram illustrating multicast in a CDN comprising a Request Redirector. Figure 5 is a flow chart illustrating a method performed by a Key Handling node according to an exemplifying embodiment. Figure 6 is a flow chart illustrating a method performed by an edge node according to an exemplifying embodiment.

Figure 7 is a schematic diagram illustrating unicast in a CDN comprising a Request

Redirector and Key Handling node, where different public keys are used for clients. Figure 8 is a schematic diagram illustrating unicast in a CDN comprising a Request

Redirector and Key Handling node, where a common public key is used for clients.

Figure 9 is a schematic diagram illustrating multicast in a CDN comprising a Request Redirector and Key Handling node, where different public keys are used for clients.

Figure 10 is a schematic diagram illustrating multicast in a CDN comprising a Request Redirector and Key Handling node, where a common public key is used for clients.

Figure 11 is a signaling diagram illustrating signaling during a switch from UC to MC in case of a combined UC/MC edge node.

Figures 12a-13b are signaling diagrams illustrating signaling during switches from UC to MC where the UC edge node and MC edge node are separate nodes. Figures 14a-c are schematic block diagrams illustrating different implementations of a Key Handling node according to exemplifying embodiments.

Figures 15a-c are schematic block diagrams illustrating different implementations of an edge node according to exemplifying embodiments.

DETAILED DESCRIPTION

Embodiments of the solution are founded on the assumption that it should be possible to switch, dynamically, between unicast and multicast delivery of encrypted content in a CDN.

In a possible scenario, CDNs comprise a Request Redirector, RR, which determines an appropriate serving edge for clients requesting content via unicast or multicast. The RR may determine or select the appropriate edge based on, e.g., the number of clients, the load on one or more edge servers, and/or on the likelihood of fulfilling a Service Level Agreement, SLA. The function of such an RR is exemplified in figures 3 and 4. In the CDN, content is stored preferably at the edge, and by default it is stored at the origin.

Figure 3 illustrates a unicast scenario, where a client 301 requests (1 ) unicast content from a CDN. The request (1 ) from the client 301 is directed to a RR 302, having knowledge about edge nodes providing unicast and multicast. The RR 302 selects an appropriate edge node 303 for the client 301 , and redirects (2) the client 301 to the selected edge node 303. This could also be described as that the RR 302 indicates a suitable edge node to the client 301. The client 301 then requests (3) the content again, but now from the edge node 303, indicated by the RR 302. The edge node 303 either has local access to the requested content, or, in its turn requests (4) the content from the so-called origin or origin server 304, a central server providing content to edge nodes. The origin 304 provides the requested content to the edge node 303, which then delivers (6) it by unicast to the client 301.

Figure 4 illustrates a multicast scenario, where a plurality of clients 401 , 405 request (1 , 1 ') multicast content from a CDN. The requests (1 , 1 ') from the clients are directed to a RR 402. The RR 402 selects an appropriate edge node 403 for the clients, and redirects (2, 2') the clients to the selected edge node 403. The clients then request (3, 3') the content from the edge node 403, indicated by the RR 402. The edge node 403 requests (4) and receives (5) the requested content from the origin 404, when not having access to it locally. The edge node 402 then delivers (6) the requested content to the clients 401 , 405 by multicast. It is desired that switching between unicast and multicast for one or more CDs should be possible during a streaming session, e.g. due to changes in demand for the content or due to an edge server reaching its maximum serving capacity or to meet the SLA for the transmitted content. Such switching is assumed to be triggered by an edge server and the decision on the best serving edge for a CD after a switch may be performed by the RR. According to one aspect, in order to manage the security within such a CDN, a Key

Handler (KH), or Public Key Handler (PKH), is introduced herein. As the name indicates, the KH is configured to handle encryption keys in a CDN, and making the keys available for the different entities and enabling encryption e.g. between an edge node and a client, between the origin and an edge node, or between caches. As previously stated, encrypted traffic may occur between different entities within a CDN, i.e. in the first, the middle and last miles. In this document, without losing generality, it will mainly be focused on the last mile.

The embodiments will be described in a context of a CDN comprising a plurality of edge nodes, an origin, a Request Redirector (RR) and a Key Handle (KH). The edge nodes may support only one of, or both of unicast (UC) and multicast (MC). That is, an edge node may be a combined UC/MC edge, a UC-only edge or an MC-only edge. The RR is a node which, as the name suggests, may receive e.g. initial requests for content and determine or select an appropriate edge for serving a requesting client, and directing the client to the determined edge. The RR may select an appropriate edge node based on e.g. the currently served number of clients, the load on the edge, and/or the likelihood of fulfilling a Service Level Agreement (SLA).

The herein suggested KH could be considered as a key server, where the public keys of all the clients connecting to the CDN are stored. These keys are then used to encrypt the streams sent to the clients. The client public keys can be the same for all the clients or, they can be different for each client, as will be exemplified further below. A "client" is below also represented by a Communication Device, CD, which is a device which is operable to interact with a CDN for obtaining content.

An exemplifying method embodiment, as seen from the perspective of a KH node, is illustrated in figure 5. That is, the method illustrated in figure 5 is to be performed by a KH node. The method is for supporting switching between encrypted unicast and encrypted multicast in a CDN. The KH node may be assumed to be comprised in the CDN, or at least to be associated with the CDN. For example, one KH node could serve multiple CDNs, to which it was associated. The exemplifying method illustrated in figure 5 comprises receiving 501 a request, from an edge node in the CDN, for an encryption key. The requested encryption key is associated with a CD, which requests content/data from the edge node. The KH node then determines 502 whether it has the requested key available, or not. This may also be described as that it determines 502 if it already has access to the key or not. When the KH node does not already have access to the requested encryption key, the KH obtains 503 the requested encryption key. The key is obtained either from the CD requesting data from the edge node, or, from a provider of the requested content, i.e. the content provider. The method further comprises providing 504 the requested encryption key to the edge node.

The method in figure 5 is described in relation to one request for one key, but obviously, the KH node could receive multiple requests for one or more encryption keys related to different

CDs. The KH node could also receive requests from a plurality of different edge nodes. A requested key may be a public encryption key associated with one CD, or in case of common public keys, with a plurality of CDs. When receiving 501 the request for a key from an edge node, they key may already be available, e.g. stored, in the KH node. For example, the key for the CD in question may have been obtained in association with an earlier request from another edge node. When the key is not available in the KH node, it will need to be obtained, e.g. retrieved. Whether the key is obtained from a/the CD with which it is associated, or from the content provider depends e.g. on whether the public keys are the same for many CDs, or whether each CD is associated with a separate public key. In case a common public key is used for a plurality of CDs, this key will probably be obtained from the content provider, which will be further described below. The encryption key may be stored in the KH node, e.g. for a certain time, for the case when the key is requested again, e.g. by another edge node.

An exemplifying method embodiment, as seen from the perspective of an edge node, is illustrated in figure 6. That is, the method illustrated in figure 6 is to be performed by an edge node. The edge node is operable in a CDN, to serve CDs (at least) by unicast. The method is for switching between encrypted unicast and encrypted multicast. The method illustrated in figure 6 comprises receiving 601 requests for the same content/data from a plurality of CDs. In order to set up secure unicast sessions for the plurality of CDs, the edge node needs one or more encryption keys associated with the plurality of CDs. The edge node then

determines 602 whether it has the one or more encryption keys readily available, i.e. already has access to the keys, or not. When not already having access to the one or more encryption keys for the plurality of CDs, the edge node obtains 603 the one or more encryption keys from a Key Handling node associated with the CDN. Further, when a criterion for switching CDs from unicast to multicast is met 604, the edge node redirects 605 at least part of the plurality of CDs to multicast from unicast.

The plurality of CDs comprises at least two CDs and at could at most comprise all redirected CDs. The respective number of CDs should justify the cost efficiency and gains for a content provider, respectively the possibility to meet the SLA for the CDs. In other words, the

"plurality of CDs" does not necessarily comprise all CDs requesting the same content from the edge node. The edge node may obtain requests for the same content by more than this plurality of CDs. That is, the plurality of CDs may be e.g. any two or more CDs amongst all CDs having requested the same content (within a certain time period). In case a common public encryption key is used for the plurality of CDs, only one key needs to be obtained 603 from the KH node if not already in store, i.e. the common public encryption key. In case of different public encryption keys for the plurality of CDs, the public encryption keys not already in store will need to be obtained 603.

That a criterion for switching between unicast and multicast is met refers to that such a criterion is fulfilled. For example, an observed or measured value may reach, exceed or fall below a threshold value, depending on how the criterion is formulated. The criterion for switching CDs from unicast to multicast may be related e.g. to a threshold value in regard of a number of requests for the same content/data; to a threshold value in regard of a load on the edge node; and/or to a threshold value in regard of a fulfillment of a Service Level Agreement, SLA. These different parameters and/or others used for a criterion may e.g. be monitored by the edge node. For example, the number of requests for the same content/data could be counted, e.g. within a certain time period. Such a time period could e.g. be selected such that it would be relevant to redirect the "requesters" to the same multicast session.

The CDs may be redirected in different ways depending e.g. whether the edge node is a UC- only edge node, or if it is a combined UC/MC edge node. In case the edge node is a combined edge node, the CDs may be redirected to a multicast session provided by the edge node itself. This is described further below, and illustrated e.g. in figure 1 1 .

Alternatively, the CDs could be redirected to another edge node operable to serve CDs by multicast. This is illustrated e.g. in figures 13a and 13b. The CDs may be redirected to an MC edge node based on information provided by a Request Redirector, RR, or via a RR. This is illustrated e.g. in figures 12a and 12b.

Below, further explanation and description of procedures for encrypted unicast and encrypted multicast, and switching between the two will be given. The following sections are organized as follows:

In a section "Key Handling" it is described, with reference to figures 7 and 8, how "pure" unicast and multicast transmissions, i.e. without consideration of a switch, would work in an encrypted way in an exemplifying CDN. These procedures may take place e.g. at the beginning of a unicast or multicast session. These examples serve as illustration, but also as guidance/reference on how unicast and multicast are initialized in cases when a switch between unicast and multicast is performed. For each case, it is differentiated between whether the public keys are the same or different for each client.

In a section "Switching procedures", the switch between encrypted unicast and encrypted multicast transmissions in the last mile is described. Several cases have been identified depending on how the switching is performed, namely: whether the edge node supports both UC/MC, whether the UC edge redirects the client to a Request Redirector, and whether the UC edge asks a Request Redirector for a new edge node to serve the client; and further depending on whether the public keys are the same or different for all users.

Key handling

The following cases illustrate the initialization of unicast and multicast transmissions when the client public keys are either different or the same. These cases can be regarded as a reference when the unicast/multicast switch is performed (cf. section "Switching

procedures"). Unicast transmission where the public key is different for every client:

Figure 7 illustrates a scenario with unicast transmission and different public keys for different clients. Public and private keys may be assumed to be generated by the clients, and to be different for each client. In figure 7, a client 701 requests (1 ) content/data from the CDN by a request to an RR 702. The RR 702 redirects (2) the client to a suitable edge node 703, based on certain criteria and information about the CDN, as previously mentioned. The client 701 requests (3) the content/data from the edge node 703 indicated by the RR 702. The request (3) is in this case related to UC, and the edge node 703 may be a UC-only edge node, or, it could be a combined UC/MC edge node. The edge node 703 receives the request (3) from the client 701 . In order to establish a secure link to the client 701 , the edge node needs access to an encryption key for the client 701. The edge node 703 determines whether it already has access to a public key for the client 701 or not. When not, the edge node 703 requests (4) a public key for the client 701 from a KH 704. The KH determines whether it already has access to the requested public key or not. When not, the KH 704 requests (5) a public key from the client 701. The client 701 provides (6) a public key to the KH, which delivers (7) it to the edge node 703. The edge node 703 now has access to a public key for the client 701 , and may provide (8) the requested content/data to the client 701 in an encrypted way. In case the edge node 703 does not have the requested content/data stored locally, it may retrieve it from the origin 705. The KH 704 may store the public key for future use, i.e. for further communications between the CDN and the client 701 . The stored public key may be associated with an expiring date or time, such that it must be requested (and/or generated) again after a certain time. Alternatively, the public key may be deleted after each session.

Unicast transmission where the public key is the same for every client

Figure 8 illustrates a scenario with unicast transmission and the same public key for different clients. The procedure for requesting content/data and the redirection is the same here, as what is described above for figure 7. However, in regard of the handling of encryption keys, there is a difference in regard to the procedure illustrated in figure 7. The public key is provided to the client e.g. by the content provider together with a private key generator. The client then generates the private key from the public key provided by the content provider.

Since the public key is the same for many or all the clients and the content provider is the one delivering it, this public key can be obtained, by the KH 804, from the content provider 806 directly, instead of from a client. The public key may then be stored in the KH 804 for future use, and may have an expiring date/time, etc. Multicast transmission where the public key is different for each client

Figure 9 illustrates a scenario with multicast, where each client 901 has a different public key. The main difference here, as compared to the unicast cases described above, relates to how the stream is encrypted (MC instead of UC). In an MC session, the same stream is sent to all the clients 901 belonging to the multicast session. When each client 901 has a different public key, one possible solution is to concatenate the encryptions of the stream with the different keys. One obvious drawback is that this solution does not scale, which is the main aim when deploying multicast. Another possible solution is to use a symmetric encryption. A symmetric key may be generated e.g. by the KH 904 and be provided to the edge node 903. The edge node 903 then encrypts the stream using the symmetric key, resulting in one only encrypted stream. However, each client needs access to the symmetric key in a secure manner. To solve this, the edge 903 may encrypt the symmetric key with the respective public keys for each client, and add the encrypted symmetric key to the stream. The client 901 then receives the encrypted stream and the encrypted symmetric key. The client 901 may then decrypt the symmetric key with its private key, and may finally decrypt the stream with the obtained symmetric key. Possible drawbacks are performance and also non- scalability. However, at least it scales better than the concatenated encryption with public keys. This problem is known in the literature as "broadcast encryption" and its particular solution is out of scope of this invention. Multicast transmission where the public key is the same for different clients

This case, shown in figure 10, has a similar process as the unicast case where the public keys are the same (described above). Since the public key is the same for all the clients and the content provider is the one delivering it, this public key can be obtained from the content provider directly. The public key may then be stored in the KH. Note that this generic public key can be the same as for the unicast transmission, or, it can be different. In this latter case, there would be two different generic keys: one for unicast transmission and one for multicast transmission.

Switching procedures

Below, different embodiments where a switch between UC and MC takes place will be described. Different cases have been identified depending on the following aspects:

How the switching is performed, namely whether:

-the edge supports both UC and MC,

-the UC edge redirects the client to the request redirector, or -the UC edge requests a new edge to serve the client from the request redirector;

Whether the public keys are the same or different for clients.

The embodiments below only describe switching from UC to MC. However, switching from MC to UC is also a possible scenario, which is considered to be disclosed herein, and to be derivable from the UC-to-MC examples given herein.

The reference cases described in the previous section (Key handling) may be used as guidance/reference on how unicast and multicast are initialized when the switch is performed. Switching between encrypted UC and encrypted MC when the edge supports both UC and MC

Figure 1 1 shows a signaling scheme for a switch between encrypted UC and encrypted MC in a CDN scenario comprising a set of N clients 1 101 :1 -1 101 :N (two explicitly shown), an RR 1 102, a KH 1 103 and an edge node 1 104 being a combined UC/MC edge node, i.e.

supporting both UC and MC. The signaling scheme starts with that the N clients are served by the edge node 1 104 by unicast. The clients send requests for (the same) content/data to the edge node, the requests being denoted "GET segment" in figure 1 1 . The edge node 1 104 provides the requested content/data via encrypted UC, the delivery being denoted

"Encrypted segment" in figure 1 1 . When a criterion for switching from UC to MC is met (fulfilled) 1 105, this triggers the edge node to initiate a switch 1 106 from UC to MC for the N clients, or at least some of them. Such a criterion may be configured e.g. as a threshold value in regard of the number of clients requesting the same data within a short period of time, as indicated in figure 1 1 . Assuming that the same public keys are to be used for UC and MC; when a switch from UC to MC is triggered, the public keys of the clients

(irrespective of whether they are the same or different for all clients) are already available at the edge 1 104, since these keys have already been obtained in order to provide the UC session. Therefore, the edge does not need to request them again from the KH 1 103 (earlier requests not shown in figure 1 1 ).

When the keys are different for the different clients, one of the "broadcast encryption" solutions is used to deliver the stream of the MC session. When the public key is the same for the different clients, the common public key is used to encrypt the multicast stream. Figure 1 1 shows the switching sequence, where client 1 101 :1 is the first client requesting the content and client 1 101 :N is the Nth client requesting the content. Switching when the UC edge redirects the client request to the request redirector

In this scenario, illustrated in figure 12a, the clients, 1201 :1 -1201 :N are switched to a second edge node 1205 when being switched from UC to MC. This may be the case e.g. when the edge node 1204 is a UC-only edge node, which is not configured for providing content by MC. In other words, the CDN may, for example, comprise separate UC edges and MC edges. As illustrated in figure 12a, the clients request content/data from the UC edge 1204. When one of the switching criteria is met 1206, i.e. fulfilled, or triggered, the UC edge 1204 here redirects 1207 the clients to the Request Redirector 1202, which provides the clients with information about an MC edge node 1205. That is, the RR 1202 indicates which MC edge that is to be used by the clients for MC. In this case, the encryption keys may need to be obtained (retrieved) both by the UC edge 1204 and by the MC edge 1205 (if not already being stored in the respective edge). The public key or keys may thus be obtained from the KH 1203 both by the UC edge and by the MC edge. Alternatively, the public key or keys could be transferred from the UC edge 1204 to the MC edge 1205. Figure 12a shows signaling related to the example where the public keys are different for different clients and are obtained from the KH 1203.

In the case where the public key is the same for all the clients, the MC edge 1205 only needs to request the public key from the KH 1203 when the first client joins the MC session. The MC edge does not need to request the public key again when subsequent clients join the MC session (since the key is the same for all clients). Figure 12b shows signaling related to this case.

Switching when the UC edge requests a new edge to serve the client from the request redirector

In this example, it is also assumed that UC and MC are provided by different edge nodes, i.e. by UC edge nodes and MC edge nodes, respectively. A signaling scheme is illustrated in figure 13a. The clients 1301 :1 -1301 :N request content/data from the UC edge 1304. When one of the switching criteria is met 1306, the UC edge 1304 retrieves information from an RR 1302 about an MC edge 1305 to serve the clients. The UC edge node 1304 then redirects the clients to the MC edge in question (if such a node is indeed indicated by the RR 1302). The public keys of the clients may also here be requested from the KH 1303 by the edges, or alternatively be transferred from the UC edge to the MC edge. Figure 13a shows signaling related to the example where the public keys are different for different clients, and are obtained from the KH 1303. When the public key is the same for all clients, the MC edge 1305 only needs to request it once, when the first client joins the MC session, as previously described. Figure 13b shows signaling related to the case where the public key is the same for all clients.

The method embodiments and techniques described above may be implemented in a CDN, e.g. in network nodes such as Key Handling nodes and edge nodes. The methods could be implemented in a distributed manner, e.g. a plurality of nodes or entities could each perform a part of the actions e.g. at different locations in the network. For example, one or more embodiments could be implemented in a so-called cloud solution. In other words, the functionality associated e.g. with a KH node or an edge node need not necessarily be comprised in one physical unit.

An exemplifying embodiment of a KH node is illustrated in a general manner in figure 14a. The KH node 1400 is configured to perform at least one of the method embodiments described above, e.g. with reference to figures 5, 1 1 , 12a-b and 13a-b. The KH node 1400 is associated with the same technical features, objects and advantages as the previously described method embodiments. The KH node will be described in brief in order to avoid unnecessary repetition.

The KH node may be implemented and/or described as follows:

The KH node 1400 comprises processing circuitry 1401 , and one or more communication interfaces 1402. The KH node is operable to be part of, or to be associated with a CDN. The processing circuitry may be composed of one or more parts which may be comprised in one or more entities in a network, but is here illustrated as one entity.

The processing circuitry 1401 is configured to cause the KH node 1400 to receive a request, from an edge node in the CDN, for an encryption key associated with a Communication Device, CD, requesting content/data from the edge node. The processing circuitry 1401 is further configured to cause the KH node 1400 to: when not already having access to the requested encryption key: obtain the requested encryption key from the CD or from a provider of the requested content, i.e. the content provider. The processing circuitry 1401 is further configured to cause the KH node 1400 to provide the requested encryption key to the edge node. The one or more communication interfaces 1402, which may also be denoted e.g. Input/Output (I/O) interfaces, may include an interface for obtaining signals and information from one or more other entities.

The processing circuitry 1401 could, as illustrated in figure 14b, comprise one or more processing means, such as a processor 1403, and a memory 1404 for storing or holding instructions. The memory would then comprise instructions, e.g. in form of a computer program 1405, which when executed by the one or more processing means 1403 causes the network node or arrangement 1400 to perform the actions described above. The processing circuitry 1401 may, be composed of one or more parts and be comprised in, or distributed over, one or more nodes in the communication network, but is here illustrated as one entity.

An alternative implementation of the processing circuitry 1401 is shown in figure 14c. The processing circuitry comprises a receiving unit 1406, configured to cause the KH node to receive a request, from an edge node in the CDN, for an encryption key associated with a CD requesting content/data from the edge node. The processing circuitry further comprises an obtaining unit 1407, configured to cause the KH node to: when not already having access to the requested encryption key: obtain the requested encryption key from the CD or from a provider of the requested content. The processing circuitry further comprises a providing unit 1408, configured to cause the KH node to provide the requested encryption key to the edge node. The processing circuitry may further comprise a determining unit 1409, configured to cause the KH node to determine whether the KH node has local access to the requested key or not. The KH nodes described above could be configured for the different method embodiments described herein.

An exemplifying embodiment of an edge node is illustrated in a general manner in figure 15a. The edge node 1500 is configured to perform at least one of the method embodiments described above, e.g. with reference to figures 6, 1 1 , 12a-b and 13a-b. The edge node 1500 is associated with the same technical features, objects and advantages as the previously described method embodiments. The edge node will be described in brief in order to avoid unnecessary repetition.

The edge node may be implemented and/or described as follows: The edge node 1500 comprises processing circuitry 1501 , and one or more communication interfaces 1502. The edge node is operable to be part of, or to be associated with a CDN. The processing circuitry may be composed of one or more parts which may be comprised in one or more entities in a network, but is here illustrated as one entity.

The processing circuitry 1501 is configured to cause the edge node 1500 to receive requests for the same content/data from a plurality of CDs. The processing circuitry 1501 is further configured to cause the edge node 1500 to: when not already having access to one or more encryption keys for the plurality of CDs: obtain the one or more encryption keys for the CDs from a Key Handling node associated with the CDN. The processing circuitry 1501 is further configured to cause the edge node 1500 to: when a criterion for switching CDs from unicast to multicast is met: redirect at least part of the plurality of CDs to multicast. The one or more communication interfaces 1502, which may also be denoted e.g. Input/Output (I/O) interfaces, may include an interface for obtaining signals and information from one or more other entities. The processing circuitry 1501 could, as illustrated in figure 15b, comprise one or more processing means, such as a processor 1503, and a memory 1504 for storing or holding instructions. The memory would then comprise instructions, e.g. in form of a computer program 1505, which when executed by the one or more processing means 903 causes the network node or arrangement 1500 to perform the actions described above. The processing circuitry 1501 may, be composed of one or more parts and be comprised in, or distributed over, one or more nodes in the communication network, but is here illustrated as one entity.

An alternative implementation of the processing circuitry 1501 is shown in figure 15c. The processing circuitry comprises a receiving unit 1506, configured to cause the edge node to receive requests for the same content/data from a plurality of CDs. The processing circuitry further comprises an obtaining unit 1507, configured to cause the edge node to: when not already having access to one or more encryption keys for the plurality of CDs: obtain the one or more encryption keys for the CDs from a Key Handling node associated with the CDN. The processing circuitry further comprises a redirecting unit 1508, configured to cause the edge node to when a criterion for switching CDs from unicast to multicast is met: redirect at least part of the plurality of CDs to multicast. The processing circuitry may further comprise a determining unit 1509, configured to cause the edge node to determine whether the edge node has local access to encryption keys, and/or whether a criterion for switching between unicast and multicast is fulfilled. The edge nodes described above could be configured for the different method embodiments described herein. The steps, functions, procedures, modules, units and/or blocks described herein may be implemented in hardware using any conventional technology, such as discrete circuit or integrated circuit technology, including both general-purpose electronic circuitry and application-specific circuitry.

Particular examples include one or more suitably configured digital signal processors and other known electronic circuits, e.g. discrete logic gates interconnected to perform a specialized function, or Application Specific Integrated Circuits (ASICs).

At least some of the steps, functions, procedures, modules, units and/or blocks described above may be implemented in software, such as a computer program, for execution by suitable processing circuitry including one or more processing units. The software could be carried by a carrier, such as an electronic signal, an optical signal, a radio signal, or a computer readable storage medium before and/or during the use of the computer program e.g. in one or more nodes of the communication network. The processing circuitry described above may be implemented in a so-called cloud solution, referring to that the implementation may be distributed, and may be referred to e.g. as being located in a so-called virtual node or a virtual machine.

The flow diagram or diagrams presented herein may be regarded as a computer flow diagram or diagrams, when performed by one or more processors. A corresponding arrangement or apparatus may be defined as a group of function modules, where each step performed by a processor corresponds to a function module. In this case, the function modules are implemented as one or more computer programs running on one or more processors.

Examples of processing circuitry includes, but is not limited to, one or more microprocessors, one or more Digital Signal Processors, DSPs, one or more Central Processing Units, CPUs, and/or any suitable programmable logic circuitry such as one or more Field Programmable Gate Arrays, FPGAs, or one or more Programmable Logic Controllers, PLCs. That is, the units or modules in the arrangements in the communication network described above could be implemented by a combination of analog and digital circuits in one or more locations, and/or one or more processors configured with software and/or firmware, e.g. stored in a memory. One or more of these processors, as well as the other digital hardware, may be included in a single application-specific integrated circuitry, ASIC, or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip, SoC.

It should also be understood that it may be possible to re-use the general processing capabilities of any conventional device or unit in which the proposed technology is implemented. It may also be possible to re-use existing software, e.g. by reprogramming of the existing software or by adding new software components.

The embodiments described above are merely given as examples, and it should be understood that the proposed technology is not limited thereto. It will be understood by those skilled in the art that various modifications, combinations and changes may be made to the embodiments without departing from the present scope. In particular, different part solutions in the different embodiments can be combined in other configurations, where technically possible. When using the word "comprise" or "comprising" it shall be interpreted as non- limiting, i.e. meaning "consist at least of".

It should also be noted that in some alternate implementations, the functions/acts noted in the blocks may occur out of the order noted in the flowcharts. For example, two blocks shown in succession may in fact be executed substantially concurrently or the blocks may sometimes be executed in the reverse order, depending upon the functionality/acts involved. Moreover, the functionality of a given block of the flowcharts and/or block diagrams may be separated into multiple blocks and/or the functionality of two or more blocks of the flowcharts and/or block diagrams may be at least partially integrated. Finally, other blocks may be added/inserted between the blocks that are illustrated, and/or blocks/operations may be omitted without departing from the scope of inventive concepts.

It is to be understood that the choice of interacting units, as well as the naming of the units within this disclosure are only for exemplifying purpose, and nodes suitable to execute any of the methods described above may be configured in a plurality of alternative ways in order to be able to execute the suggested procedure actions.

It should also be noted that the units described in this disclosure are to be regarded as logical entities and not with necessity as separate physical entities.

ABBREVIATIONS

CD Communication Device

CDN Content Delivery/Distributed Network

KH Key Handler

MC Multicast

PKH Public Key Handler

RR Request Redirector

UC Unicast

Claims

A method performed by an arrangement in a Content Distribution Network, CDN; the arrangement comprising a unicast edge node, UC edge (1 104, 1204, 1304, 1500), operable to serve Communication Devices, CDs (1 101 : 1 -N, 1201 :1 -N, 1301 :1 -N), by unicast (UC); a multicast edge node, MC edge (1 104, 1205, 1305, 1500), operable to serve CDs by multicast (MC); the CDN further being associated with a Key Handling node (1 103, 1203, 1303, 1400) for storing and providing encryption keys to edge nodes; the method being for switching between encrypted unicast and encrypted multicast, and comprising:

-the UC edge receiving (601 ) requests from a plurality of CDs for the same content/data;

-the UC edge obtaining (602) one or more encryption keys for the plurality of CDs from the Key Handling node; for encrypting the requested content/data to be provided by unicast to the plurality of CDs: and

when a criterion for switching CDs from unicast to multicast is met (604): -the UC edge redirecting (605, 1 106, 1207) at least part of the plurality of CDs to multicast;

-the MC edge receiving (607) requests from a number of the of redirected CDs for the content/data;

-the MC edge, when not having access to one or more encryption keys for the number of redirected CDs: obtaining (1208) one or more encryption keys for the number of redirected CDs from the Key Handling node, for encrypting the requested content/data to be provided by multicast to the at number of redirected CD.

A method performed by a Key Handling node (1 103, 1203, 1303, 1400), the method being for supporting switching between encrypted unicast and encrypted multicast in a Content Distribution Network, CDN, and comprising:

-receiving (501 ) a request, from an edge node in the CDN, for an encryption key associated with a Communication Device, CD, requesting content/data from the edge node;

when not having access to the requested encryption key:

-obtaining (503) the requested encryption key from the CD or from a provider of the requested content, i.e. the content provider;

-providing (504) the requested encryption key to the edge node.

3. The method according to claim 2, wherein the encryption key is a public encryption key.

4. The method according to claim 2 or 3, wherein the encryption key is obtained from the content provider when being a common encryption key associated with a plurality of CDs.

5. The method according to any of claims 2-4, further comprising:

-storing the obtained encryption key.

6. A method performed by an edge node (1 104, 1204, 1304, 1500) in a Content

Distribution Network, CDN, the edge node being operable to serve Communication Devices, CDs, by unicast; the method being for switching between encrypted unicast and encrypted multicast, and comprising:

-receiving (601 ) requests for the same content/data from a plurality of Communication Devices, CDs; and:

when not having access (602) to one or more encryption keys for the plurality of CDs:

-obtaining (603) the one or more encryption keys for the CDs from a Key Handling node associated with the CDN; and:

when a criterion for switching CDs from unicast to multicast is met (604, 1 105, 1206):

-redirecting (605, 1 106, 1207) at least part of the plurality of CDs to multicast.

7. The method according to claim 6, wherein the at least part of the plurality of CDs are redirected to a multicast session provided by the edge node.

8. The method according to claim 6, wherein the at least part of the plurality of CDs are redirected to another edge node operable to serve the CDs by multicast.

9. The method according to claim 6, wherein the at least part of the plurality of CDs are redirected to a Request Redirector, for further redirection to another edge node operable to serve the CDs by multicast.

10. Method according to any of claims 6-9, wherein the criterion for switching CDs from unicast to multicast is related to at least one of: -a threshold value in regard of a number of requests for the same content/data;

-a threshold value in regard of a load on the edge node;

-a threshold value in regard of a fulfillment of a Service Level Agreement, SLA.

1 1. A Key Handling node (1 103, 1203, 1303, 1400) operable to be associated with a Content Distribution Network, CDN, the Key Handling node being configured to:

-receive a request, from an edge node in the CDN, for an encryption key associated with a Communication Device, CD, requesting content/data from the edge node; and to:

when not having access to the requested encryption key:

-obtain the requested encryption key from the CD or from a provider of the requested content, i.e. the content provider; and to:

-provide the requested encryption key to the edge node.

12. The Key Handling node according to claim 1 1 , wherein the encryption key is a

public encryption key.

13. The Key Handling node according to claim 1 1 or 12, wherein the encryption key is obtained from the content provider when being a common encryption key associated with a plurality of CDs.

14. The Key Handling node according to any of claims 1 1 -13, being configured to:

-store the obtained encryption key.

15. An edge node (1 104, 1204, 1304, 1500) operable, in a Content Distribution

Network, CDN, to serve Communication Devices, CDs, by unicast; the edge node being configured to:

-receive requests for the same content/data from a plurality of CDs; and to: when not having access to one or more encryption keys for the plurality of CDs:

-obtain the one or more encryption keys for the CDs from a Key Handling node associated with the CDN; and to:

when a criterion for switching CDs from unicast to multicast is met: -redirect at least part of the plurality of CDs to multicast.

16. The edge node according to claim 15, wherein the at least part of the plurality of CDs are redirected to a multicast session provided by the edge node.

17. The edge node according to claim 15, wherein the at least part of the plurality of CDs are redirected to another edge node operable to serve the CDs by multicast.

18. The edge node according to claim 15, wherein the at least part of the plurality of CDs are redirected to a Request Redirector, for further redirection to another edge node operable to serve the CDs by multicast.

19. The edge node according to any of claims 15-18, wherein the criterion for switching from unicast to multicast is related to at least one of:

-a threshold value in regard of a number of requests for the same content/data;

-a threshold value in regard of a load on the edge node;

20. Computer program (1405, 1505), comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of claims 1 -10.

21. A carrier containing the computer program of the preceding claim, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.