WO2017125150A1

WO2017125150A1 - Switching between unicast and multicast in a content delivery network

Info

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

Abstract

Network nodes and methods therein are provided for supporting switching and for switching between unicast and multicast delivery of content in a Content Distribution Network (CDN). A method to be performed by an edge node operating in the CDN is provided, which method comprises: receiving requests for the same content/data from a plurality of Communication Devices (CDs); and further comprising: when a criterion for switching CDs from unicast to multicast is met: redirecting at least part of the plurality of CDs to multicast, either via a Request Redirector (RR), or based on information obtained from the RR.

Description

SWITCHING BETWEEN UNICAST AND MULTICAST IN A CONTENT DELIVERY

NETWORK

TECHNICAL FIELD

The invention relates to content distribution in a network, and in particular to switching between unicast and multicast transmission in a Content Delivery Network (CDN).

BACKGROUND

Content Delivery (or Distribution) 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.

In order to further improve the providing of content to clients in CDNs. there is a need for improved solutions in regard of the providing of content to the clients, for example, solutions related to handling of the type of transmission used for the content delivery.

SUMMARY

It is desired to achieve improved solutions in regard 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. In other words, embodiments herein provide a mechanism to dynamically switch between serving client requests by unicast and multicast 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 unicast and multicast transmissions to improve the scalability and cost efficiency.

According to a first aspect, a method is provided, which is to be performed by an edge node in a CDN. The edge node is operable to serve Communication Devices, CDs, by unicast, in the CDN. The method is suitable for switching between unicast and multicast. The method comprises receiving requests for the same content/data from a plurality of CDs; and further, when a criterion for switching CDs from unicast to multicast is met: redirecting at least part of the plurality of CDs to multicast, either via a Request Redirector, RR, or based on information obtained from the RR. According to a second aspect, a method is provided, which is to be performed by a Request Redirector, RR. The method is suitable for supporting switching between unicast and multicast in a CDN. The method comprises receiving a request, from an edge node, UC edge, being operable to serve CDs by unicast in the CDN, the request being for a target edge node, MC edge, being operable to serve CDs by multicast, the request being related to redirection of a number of CDs served by the UC edge. The method further comprises providing information about a determined target MC edge to the UC edge.

According to a third aspect, a method is provided, which is to be performed by a

Communication Device, CD. The method is suitable for supporting switching between unicast and multicast in a CDN. The method comprises: when being served content/data by unicast from an edge node in the CDN: receiving an indication, from the edge node of either a target edge node or a Request Redirector, RR. The method further comprises requesting remaining content/data from the indicated target edge node or RR.

According to a fourth aspect, an edge node is provided, which is operable, in a CDN, to serve CDs by unicast. The edge node is configured to perform the method of the first aspect. According to a fifth aspect, a Request Redirector, RR, is provided, which is operable in a CDN. The RR is configured to perform the method of the second aspect.

According to a sixth aspect, a Communication Device, CD, is provided, which is operable in a CDN. The CD is configured to perform the method of the third aspect.

According to a seventh 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 an eight aspect, a carrier is provided, containing the computer program of the seventh 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 illustrating unicast in a CDN comprising a Request

Redirector.

Figure 3 is a schematic diagram illustrating multicast in a CDN comprising a Request Redirector.

Figures 4a-4c are flow charts illustrating a method performed by an edge node according to exemplifying embodiments.

Figure 5 is a flow chart illustrating a method performed by a Request Redirector according to an exemplifying embodiment.

Figure 6 is a flow chart illustrating a method performed by a communication device according to an exemplifying embodiment. Figure 7-8 are signaling diagrams illustrating signaling during switches of clients (CDs) from UC to MC where the UC edge node and MC edge node are separate nodes.

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

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

Figures 11 a-c are schematic block diagrams illustrating different implementations of a Request Redirector according to exemplifying embodiments.

Figures 12a-c are schematic block diagrams illustrating different implementations of a communication device 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 content in a CDN.

The deployment of multicast and unicast transmission depending on some requirement is mentioned in the published patent applications US20140282777A1 , and EP 2785006 A1. In the document US20140282777A1 , a client requests content from an unspecified network. The network determines whether a multicast session already exists, and if so, the client joins the multicast session. If not, the network checks whether a new multicast session should be created. If not, the client receives data as unicast. Once the transmission mode is setup, the media delivery type is kept during the session. In the document EP2785006A1 , a method for unicast-to-multicast switching is described. The switching relates to a prediction of future demand for the content.

However, there is a need for improved solutions in regard of switching between unicast and multicast in CDNs. Below, embodiments related to such switching will be disclosed. In a possible scenario, a CDN comprises 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 2 and 3. In the CDN, content is stored preferably at the edge, and by default it is stored at the origin.

Figure 2 illustrates a unicast scenario, where a client 201 requests (1 ) unicast content from a CDN. The request (1 ) from the client 201 is directed to a RR 202, having knowledge about edge nodes providing unicast and multicast. The RR 202 selects an appropriate edge node 203 for the client 201 , and redirects (2) the client 201 to the selected edge node 203. This could also be described as that the RR 202 indicates a suitable edge node to the client 201.

The client 201 then requests (3) the content again, but now from the edge node 203, indicated by the RR 202. The edge node 203 either has local access to the requested content, or, in its turn requests (4) the content from the so-called origin or origin server 204, a central server providing content to edge nodes. The origin 204 provides the requested content to the edge node 203, which then delivers (6) it by unicast to the client 201.

Figure 3 illustrates a multicast scenario, where a plurality of clients 301 , 305 request (1 , 1 ') multicast content from a CDN. The requests (1 , 1 ') from the clients are directed to a RR 302. The RR 302 selects an appropriate edge node 303 for the clients, and redirects (2, 2') the clients to the selected edge node 303. The clients then request (3, 3') the content from the edge node 303, indicated by the RR 302. The edge node 303 requests (4) and receives (5) the requested content from the origin 304, when not having access to it locally. The edge node 302 then delivers (6) the requested content to the clients 301 , 305 by multicast.

If assuming a HyperText Transfer Protocol (HTTP) scenario, a client, in form of a

Communication Device, CD, may send an HTTP request for content to an RR. The RR then decides to redirect the client HTTP requests to a unicast (UC) edge or a multicast (MC) edge based on multiple criteria including, but not limited to: the CDN edge load, SLA fulfillment and/or the number of requests for the same content. The RR is assumed to have up-to-date knowledge about the load on the different unicast and multicast edges. Expressed differently, a client sends an HTTP request to retrieve a manifest file from the RR. The RR decides to select a UC/MC edge node/server based on the above criteria and replies e.g. with the IP address of the selected unicast edge or a multicast group IP address of the selected multicast edge, respectively.

In case the edge node selected by the RR is a unicast edge (UC Edge), the client uses the returned IP address to request the manifest file and the media segments from the unicast edge. In case the edge node selected by the RR is a multicast edge (MC Edge), the client sends an IGMP (Internet Group Management Protocol) request to the multicast group IP address returned by the RR. The client receives an IGMP reply and requests the manifest file and media segments. The client should support both unicast and multicast modes to be able to receive data transmitted using unicast and multicast from the unicast and multicast edges. Without loss of generality, it is herein assumed that the client/CD supports HTTP over UDP transmission, e.g. using File Delivery over Unidirectional Transport (FLUTE) and uses an HTTP server in the client device to provide the media segments to the media player at the client. In case of multicast, a client might register to single or multiple multicast groups to retrieve e.g. adaptive bit-rate (ABR) content.

The embodiments will be described in a context of a CDN comprising a plurality of edge nodes, an origin and a Request Redirector (RR). The edge nodes may support only one of, or both of, unicast (UC) and multicast (MC) transmission of content/data. 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 then direct the client to the determined/selected edge. Herein, a dynamic switching from unicast to multicast (and vice versa) during a streaming session is considered. An edge server may issue a redirection of a CD, or client, based on dynamic changes e.g. in the number of requests during the session, such as when more users are requesting the same content. A redirection may also be issued based on the edge load, e.g. when a unicast edge is overloaded by the client requests and switching of some clients to an MC edge is more appropriate. In other words, it is desired that switching between unicast and multicast for one or more CDs, or clients, 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 an RR. Different possible realizations are described below, and illustrated e.g. in figures 7-9. The realizations are described for HTTP- based redirection, but other redirection mechanisms can be applied, such as DNS-based redirection. Please note that similar procedures can also be used for switching from multicast to unicast edges.

An exemplifying method embodiment, as seen from the perspective of an edge node, is illustrated in figure 4a. That is, the method illustrated in figure 4a 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 unicast and multicast. The method illustrated in figure 4a comprises receiving 401 requests for the same content/data from a plurality of CDs. When a criterion for switching CDs from unicast to multicast is met 402, the edge node redirects 403 at least part of the plurality of CDs to multicast, either via an RR node, or based on information obtained from the RR node.

A more elaborate version of the embodiment of figure 4a is illustrated in figure 4b. Actions 401 and 402 are similar to the ones in figure 4a, and the action 403 (dashed outline) is represented by the actions 404-406. In figure 4b, the edge node requests 404, or sends 404 a request, to an RR, for information about an MC edge, a target MC edge, to which a number of CDs could be redirected for obtaining the content via an MC transmission. The edge node receives 406 information about an MC edge from the RR. For example, an indication or identifier of an MC edge node, such as an IP-address, may be received from the RR. The edge node then redirects at least part of the plurality of CDs to multicast, i.e. to the MC edge node, based on the information obtained from the RR. The redirection may comprise that the edge node indicates the MC edge node to the CDs e.g. by sending the IP-address, and also indicates, explicitly or implicitly, that a switch to MC should be made. An additional alternative version of the embodiment of figure 4a is illustrated in figure 4c. Actions 401 and 402 are similar to the ones in figure 4a, and the action 403 (dashed outline) is represented by the action 407. In figure 4c, when a criterion for switching CDs from unicast to multicast is met 402, the edge node redirects a number of CDs from UC to MC via an RR. The redirection may comprise that the edge node provides an IP-address of the RR to the CDs to be redirected, with an explicit or implicit indication of that a switch to MC is to take place. In this case, the edge node does not request information about a target MC edge node from the RR, as in figure 4b, but redirects a number of CDs to multicast via the RR, e.g. indicates the RR to the CDs and indicates that the CDs should switch to multicast. An exemplifying method embodiment, as seen from the perspective of an RR node, is illustrated in figure 5. That is, the method illustrated in figure 5 is to be performed by an RR node. The method is for supporting switching between unicast and multicast in a CDN. The method could also be used correspondingly for switching between multicast and unicast, mutatis mutandis. The RR node may be assumed to be comprised in the CDN, or at least to be associated with the CDN. For example, one RR node could possibly serve multiple CDNs. The exemplifying method illustrated in figure 5 comprises receiving 501 a request, from an edge node in the CDN providing content by UC transmission to CDs, for information about an MC edge. The RR node then determines 502 an MC edge node, based on information about the CDN, which (edge) could serve a number of CDs by multicast. The method further comprises providing 503 the requested information to the requesting edge node. As previously mentioned, the information about the MC edge node may comprise an IP-address associated with the MC edge node.

An exemplifying method embodiment, as seen from the perspective of a Communication Device, CD, node, is illustrated in figure 6. That is, the method illustrated in figure 6 is to be performed by a CD. The method is for supporting switching between unicast and multicast in a CDN. The method could also be used correspondingly for switching from multicast and unicast, mutatis mutandis.

The method comprises: when being served 601 content/data by unicast from an UC edge node in the CDN: receiving 602 an indication, from the edge node, of a switch to multicast, and further of either a target edge node or a Request Redirector, RR. The method further comprises requesting 603 the remaining content/data from the indicated target edge node or RR. For a CD, "switching to multicast" may comprise requesting the desired content from the RR and indicating that it is a multicast transmission that is requested. The redirected CDs request the content in question from the RR and are provided with information about an MC edge node (by the RR) in response to the request. The CDs may then request the content from the MC edge node according to the information. Alternatively, "switching to multicast" may comprise requesting the desired content from an MC edge indicated by the UC edge, and indicating explicitly or implicitly, that it is a multicast transmission that is requested. In this case, redirected CDs request the content from an MC edge node indicated by the UC edge node.

The number of redirected CDs comprises at least two CDs and could at most comprise all CDs served the same content by unicast by the edge node. The number of redirected CDs should justify the cost efficiency and gains for a content provider, and/or the possibility to meet the SLA for the CDs. In other words, the "redirected CDs" do not necessarily comprise all CDs requesting, or being provided with the same content from the edge node. The edge node may obtain requests for the same content by more CDs than what are redirected to multicast. That is, the number of CDs that are redirected may be e.g. any two or more CDs amongst all CDs having requested the same content.

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.

As indicated above, 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. The CDs could be redirected from an UC edge node to another edge node operable to serve CDs by multicast. This is illustrated e.g. in figures 7 and 8. The CDs may be redirected to an MC edge node based on information provided by an RR, which is illustrated in figure 7, or, be redirected via a RR, which is illustrated in figure 8. 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 9.

Below, further explanation and description of procedures for switching between unicast and multicast will be given. 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 CD/client to/via a Request Redirector, RR, and whether the UC edge asks a Request Redirector for a new edge node to serve the client.

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.

Switching when the UC edge redirects the client request to the Request Redirector

Figure 7 shows a signaling scheme for a switch between UC and MC in a CDN scenario comprising a set of N clients 701 :1 -701 :N (two explicitly shown), an RR 702, an UC edge node 703 and an MC edge node 704. The UC edge node 703 being at least operable to provide content to clients, or CDs, by unicast transmission, and the MC edge node 704 being at least operable to provide content to clients by multicast transmission. The signaling scheme starts with that the N clients are served 705 by the UC edge node 703 by unicast. The clients send requests for (the same) content/data to the UC edge node 703, the requests being denoted "GET segment" in figure 7. The UC edge node 703 provides the requested content/data via UC, the delivery being denoted "Segment" in figure 7. When a criterion for switching from UC to MC is met (fulfilled) 706, this triggers the UC edge node 703 to initiate a switch 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 period of time, or by as a load threshold, as indicated in figure 7. In the scenario illustrated in figure 7, the clients, 701 :1 -701 :N are switched from a first edge node 703 to a second edge node 704 when being switched from UC to MC. This may be the case e.g. when the edge node 703 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. This could be expressed as that when a criterion is met 706, i.e. fulfilled, or triggered, the UC edge 703 redirects the clients, e.g. a part of the clients, to multicast.

The UC edge 703 indicates 707, to the clients, that they may or shall turn to the Request Redirector 702 for information about further service. The indication also comprises an indication, explicit or implicit, of that the client should switch to multicast. The clients request 708 content from the RR 702, which will provide 709 the clients with information about an MC edge node 704. The indicated MC edge node 704 may be referred to as a target MC edge node. That is, the RR 702 indicates which MC edge that is to be used by the clients for MC. Figure 7 shows the switching sequence, where client 701 :1 is the first client requesting the content and client 701 :N is the Nth client requesting the content. The case above may also be described as that the UC edge 703 redirects the clients to the RR 702. The clients then request content/segments from the RR 702. The RR 702 decides to redirect the clients to an MC edge 704. The RR may consider similar criteria as at a session setup to decide if the client should be directed to an MC edge, and in that case, to which MC edge it should be directed. The client may then establish a connection with the MC edge node (indicated as "IGMP join" in figure 7) and start requesting segments from the MC edge node.

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

Figure 8 also shows a signaling scheme for a switch between UC and MC in a CDN scenario comprising a set of N clients 801 : 1 -801 :N (two explicitly shown), an RR 802, an UC edge node 803 and an MC edge node 804. The UC edge node 803 being at least operable to provide content to clients, or CDs, by unicast transmission, and the MC edge node 804 being at least operable to provide content to clients by multicast transmission. The clients 801 :1 - 801 :N request and receive 805 content/data from the UC edge 803. When at least one switching criterion is met 806, the UC edge 803 retrieves 807 information from an RR 802 about an MC edge 804 to serve the clients. The UC edge node 803 then redirects the clients to the MC edge 804 in question (if such a node is indeed indicated by the RR 802). For example, the RR may return the IP address of the MC edge 804 to the UC edge 803, and the clients in question may be redirected. The clients may establish a connection with the MC edge node 804 ("IGMP join" in figure 8) and start requesting segments from the MC edge node 804.

Switching when edge node is a combined UC/MC edge node

Figure 9 shows a signaling scheme for a switch between UC and MC in a CDN scenario comprising a set of N clients 901 : 1 -901 :N (two explicitly shown), an RR 902, and an edge node 903 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 903 by unicast. The clients send requests for (the same) content/data to the edge node, the requests being denoted "GET segment" in figure 9. The edge node 903 provides the requested content/data via UC, the delivery being denoted "Segment" in figure 9. When a criterion for switching from

UC to MC is met (fulfilled) 904, this triggers the edge node 903 to initiate a switch from UC to MC for the N clients, or at least some of them. Such a criterion may be configured e.g. as described above. The edge node 903 receiving the client requests here decides to start a multicast transmission based on the fulfillment of one or more criteria including e.g. the number of requests it is receiving. The edge node 903 terminates the ongoing unicast transmissions and starts a multicast streaming session with the clients. This may be performed without retrieving information from an RR 902 node or via an RR node, as in the previous examples. However, in the previous examples (figure 7-8) it would be possible that the clients were redirected to the same edge node as the one providing the UC, given that this edge node was operable to provide MC transmission.

The method embodiments and techniques described above may be implemented in a CDN, e.g. in network nodes such as RR 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 an RR node or an edge node need not necessarily be comprised in one physical unit.

An exemplifying embodiment of an edge node is illustrated in a general manner in figure 10a. The edge node 1000 is configured to perform at least one of the method embodiments described above, e.g. with reference to figures 4a-4c and 7-8. The edge node 1000 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 1000 comprises processing circuitry 1001 , and one or more communication interfaces 1002. 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 1001 is configured to cause the edge node 1000 to receive requests for the same content/data from a plurality of CDs. The processing circuitry 1001 is further configured to cause the edge node 1000 to: when a criterion for switching CDs from unicast to multicast is met: redirecting at least part of the plurality of CDs to multicast, either via a Request Redirector, RR, or based on information obtained from the RR. The one or more communication interfaces 1002, 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 1001 could, as illustrated in figure 10b, comprise one or more processing means, such as a processor 1003, and a memory 1004 for storing or holding instructions. The memory would then comprise instructions, e.g. in form of a computer program 1005, which when executed by the one or more processing means causes the network node or arrangement 1000 to perform the actions described above. The processing circuitry 1001 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 1001 is shown in figure 10c. The processing circuitry comprises a receiving unit 1006, configured to cause the edge node to receive requests for the same content/data from a plurality of CDs. The processing circuitry further comprises a redirecting unit 1007, 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 either via a Request Redirector, RR, or based on information obtained from the RR. The processing circuitry may further comprise a determining unit 1008, configured to cause the edge node to determine 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.

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

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

The RR node 1 100 comprises processing circuitry 1 101 , and one or more communication interfaces 1 102. The RR 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 1 101 is configured to cause the RR node 1 100 to: receive a request, from an edge node, UC edge, being operable to serve CDs by unicast in the CDN, the request being for a target edge node, MC edge, being operable to serve CDs by multicast. The request is related to redirection of a number of CDs served by the UC edge to the target

MC edge. The processing circuitry 1 101 is further configured to cause the RR node 1 100 to provide information about a determined target MC edge to the UC edge. The one or more communication interfaces 1 102, 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 1 101 could, as illustrated in figure 1 1 b, comprise one or more processing means, such as a processor 1 103, and a memory 1 104 for storing or holding instructions. The memory would then comprise instructions, e.g. in form of a computer program 1 105, which when executed by the one or more processing means 1 103 causes the network node or arrangement 1 100 to perform the actions described above. The processing circuitry 1 101 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 1 101 is shown in figure 1 1 c. The processing circuitry comprises a receiving unit 1 106, configured to cause the RR node to receive a request, for a target MC edge, from a UC edge in the CDN, the request being related to redirection of a number of CDs served by the UC edge. The processing circuitry further comprises a providing unit 1 107, configured to cause the RR node to provide information about a determined target MC edge to the UC edge. The processing circuitry may further comprise a determining unit 1 108, configured to cause the RR node to determine or select a target MC edge node which is capable of serving a number of CDs by multicast. The target MC edge node may be determined or selected, e.g. from a set of MC edge nodes in the CDN. The RR nodes described above could be configured for the different method embodiments described herein.

An exemplifying embodiment of a Communication Device, CD, is illustrated in a general manner in figure 12a. The CD 1200 is configured to perform at least one of the method embodiments described above, e.g. with reference to figures 6 and 7-8. The CD 1200 is associated with the same technical features, objects and advantages as the previously described method embodiments. The CD will be described in brief in order to avoid unnecessary repetition.

The CD may be implemented and/or described as follows:

The CD 1200 comprises processing circuitry 1201 , and one or more communication interfaces 1202. The CD is operable in 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 1201 is configured to cause the CD 1200 to: when being served content/data by unicast from an edge node in the CDN: receive an indication, from the edge node of either a target edge node or a Request Redirector, RR, and possibly of a switch to multicast; and to: request remaining content/data from the indicated target edge node or RR. The one or more communication interfaces 1202, 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 1201 could, as illustrated in figure 12b, comprise one or more processing means, such as a processor 1203, and a memory 1204 for storing or holding instructions. The memory would then comprise instructions, e.g. in form of a computer program 1205, which when executed by the one or more processing means 1203 causes the network node or arrangement 1200 to perform the actions described above. The processing circuitry 1201 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 1201 is shown in figure 12c. The processing circuitry comprises a receiving unit 1206, configured to cause the CD to: when being served content/data by unicast from an edge node in the CDN: receive an indication, from the edge node, of either a target edge node or of a RR, and possibly of a switch to multicast. The processing circuitry further comprises a requesting unit 1207, configured to cause the CD to request remaining content/data from the indicated target edge node or RR. The CDs 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

MC Multicast

RR Request Redirector

UC Unicast

Claims

1 . A method performed by an arrangement in a Content Delivery Network, CDN; the arrangement comprising a unicast edge node, UC edge, operable to serve Communication Devices, CDs, by unicast (UC); a multicast edge node, MC edge, operable to serve CDs by multicast (MC); the CDN further comprising a Request

Redirector, RR; the method being for switching between unicast and multicast, and comprising:

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

when a criterion for switching CDs from unicast to multicast is met (402, 706, 806, 904):

-the UC edge redirecting (403) at least part of the plurality of CDs to a target MC edge, either via the RR or based on information obtained from the RR; -the MC edge receiving requests from at least a number of the redirected CDs for the content/data;

-the MC edge, providing the requested content/data by multicast to at least part of the number of redirected CDs.

2. A method performed by an edge node (1000) in a Content Delivery Network, CDN, the edge node being operable to serve Communication Devices, CDs, (1200) by unicast; the method being for switching between unicast and multicast, and comprising:

-receiving (401 ) requests for the same content/data from a plurality of CDs; and:

when a criterion for switching CDs from unicast to multicast is met: -redirecting (403) at least part of the plurality of CDs to multicast, either via a Request Redirector, RR, or based on information obtained from the RR.

3. The method according to claim 2, wherein the redirecting comprises:

-requesting (404), from the RR, information about a target edge node being operable to serve CDs by multicast; and

-indicating (406) the information about the target edge node to the at least part of the plurality of CDs.

4. The method according to claim 2, wherein the redirecting comprises:

-indicating (407) the RR to the at least part of the plurality of CDs.

Method according to any of claims 2-4, wherein the redirecting (403) further comprises indicating, explicitly or implicitly, a switch to multicast to the at least part of the plurality of CDs.

Method according to any of claims 2-5, 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.

A method performed by a Request Redirector, RR the method being for supporting switching between unicast and multicast in a Content Delivery Network, CDN, and comprising:

-receiving (501 ) a request, from an edge node, UC edge, being operable to serve Communication Devices, CDs, by unicast in the CDN, the request being for a target edge node, MC edge, being operable to serve CDs by multicast, the request being related to redirection of a number of CDs served by the UC edge; and:

-providing (503) information about a determined target MC edge to the UC edge.

The method according to claim 7, further comprising:

-determining (502) a target MC edge from a set of edge nodes in the CDN in response to the received request.

A method to be performed by a Communication Device, CD, the method being for supporting switching between unicast and multicast in a Content Delivery Network, CDN, the method comprising: when being served (601 ) content/data by unicast from an edge node in the CDN:

-receiving (602) an indication, from the edge node, of either a target edge node or a Request Redirector, RR; and:

-requesting (603) remaining content/data from the indicated target edge node or RR.

10. The method according to claim 9, further comprising:

-receiving an explicit or implicit indication, from the edge node, of a switch to multicast.

1 1. An edge node (1000) operable in a Content Delivery Network, CDN, the edge node being operable to serve Communication Devices, CDs, by unicast; the edge node being for switching between unicast and multicast, and being configured to:

-receive requests for the same content/data from a plurality of CDs; and:

when a criterion for switching CDs from unicast to multicast is met, to: -redirect at least part of the plurality of CDs to multicast, either via a Request Redirector, RR, or based on information obtained from the RR.

12. The edge node according to claim 1 1 , wherein the redirecting comprises to:

-request, from the RR, information about a target edge node being operable to serve CDs by multicast; and to:

-indicate the information about the target edge node to the at least part of the plurality of CDs.

13. The edge node according to claim 1 1 , wherein the redirecting comprises to:

-indicate the RR to the at least part of the plurality of CDs.

14. The edge node according to any of claims 1 1 -13, wherein the redirecting further comprises to indicate, explicitly or implicitly, a switch to multicast to the at least part of the plurality of CDs.

15. The edge node according to any of claims 1 1 -14, 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;

16. A Request Redirector, RR, (1 100) for supporting switching between unicast and multicast in a Content Delivery Network, CDN, the RR being configured to:

-receive a request, from an edge node, UC edge, being operable to serve CDs by unicast in the CDN, the request being for a target edge node, MC edge, being operable to serve CDs by multicast, the request being related to redirection of a number of CDs served by the UC edge; and to

-provide information about a determined target MC edge to the UC edge.

17. The RR according to claim 16, being configured to: -determine a target MC edge from a set of edge nodes in the CDN in response to the receiving of a request.

18. A Communication Device, CD (1200), for supporting switching between unicast and multicast in a Content Delivery Network, CDN, the CD being configured to: when being served content/data by unicast from an edge node in the CDN: -receive an indication, from the edge node, of a switch to multicast, and further of either a target edge node or of a Request Redirector, RR; and further to: -request remaining content/data from the indicated target edge node or RR.

19. The CD according to claim 16, being further configured to:

-receive an explicit or implicit indication, from the edge node, of a switch to multicast.

20. Computer program (1005, 1 105, 1205), 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.