GB2558879A

GB2558879A - Method and apparatus for container-based virtualisation

Info

Publication number: GB2558879A
Application number: GB1700073.8A
Authority: GB
Inventors: Poupon David; Gaumont David; Taibi Noureddine; Danis Thierry; Bouhadjar Yazid Tayeb; Ekra Hugues
Original assignee: Cisco Technology Inc
Current assignee: Cisco Technology Inc
Priority date: 2017-01-04
Filing date: 2017-01-04
Publication date: 2018-07-25
Also published as: GB201700073D0

Abstract

Method for container-based virtualization on a server 200 is provided comprising simultaneously operating a host operating system (OS) and a plurality of guest operating system instances 250a,b. Each guest OS instance operates within a separate container on the host OS. Guest OSs comprise a hardware abstraction layer and are designed for mobile devices, e.g. Android (RTM).Operation of the containers can be managed by Docker software (RTM). Each guest OS has one service operated by a single, global service manager 260 via identifiers for registered services in the guest OSs. The guest OSs generate video output streams captured in a virtual frame buffer using a graphic processor of the host OS. Uses comprise media service providers for set-top boxes with limited capabilities for graphics processing, implementing processing such as cloud rendering.

Description

(71) Applicant(s):

CISCO TECHNOLOGY, INC.

(Incorporated in USA - California)

170 West Tasman Drive, San Jose, CA 95134, United States of America (56) Documents Cited:

EP 2879337 A1 WO 2016/197069 A1 CN 103593225 B US 20150150003 A1 US 20110050712 A1

EP 2723093 A1 WO 2015/088374 A1 US 20160330277 A1 US 20130104124 A1 (58) Field of Search:

(72) Inventor(s):

David Poupon David Gaumont Noureddine Taibi Thierry Danis Tayeb Bouhadjar Yazid Hugues Ekra (74) Agent and/or Address for Service:

Kilburn & Strode LLP

Lacon London, 84 Theobalds Road, London, Greater London, WC1X 8NL, United Kingdom

Other: EPODOC, WPI (54) Title of the Invention: Method and apparatus for container-based virtualisation Abstract Title: Container based virtualisation for servers with graphic processors (57) Method for container-based virtualization on a server 200 is provided comprising simultaneously operating a host operating system (OS) and a plurality of guest operating system instances 250a,b. Each guest OS instance operates within a separate container on the host OS. Guest OSs comprise a hardware abstraction layer and are designed for mobile devices, e.g. Android (RTM).Operation of the containers can be managed by Docker software (RTM). Each guest OS has one service operated by a single, global service manager 260 via identifiers for registered services in the guest OSs. The guest OSs generate video output streams captured in a virtual frame buffer using a graphic processor of the host OS. Uses comprise media service providers for set-top boxes with limited capabilities for graphics processing, implementing processing such as cloud rendering.

θ Instance 250a

registergroup

Instance 250b

id2	id1	id4 id3
		Binder

Kernel

Service manager 260

Rendering server 200

Fig. 7

1/8

Fig. 1

2/8

Client device 100

Fig. 2

3/8


	Central processing unit 212

	Integrated graphics processor 214

	Hardware video encoder/decoder 216

Processor

210

Network interface

240

Memory

220

Rendering server

Fig. 3

4/8

Fig. 4

5/8

Fig. 5

6/8

Client device

100

Signalling server

400

Rendering server

200

Content provider

300

602

New instance “345” running application X available

606 <Multicast video stream (channel Y)

610

->

Client looking for application X (channel Y)

614 <Open WebRTC session IVP345_1 with instance 345

618

->

Open WebRTC session IVP345_1 with client

622

WebRTC offer to client I 626 _

Accept WebRTC offer

Fig. 6A

7/8

Fig. 6B

8/8

CD

Instance

250a

θ Instance 250b

id2	id1	id4 id3
		Binder

_________ — — — — — — — — — — — — — — — — — — — — j

Kernel

Service manager 260

Rendering server 200

Fig. 7

Application No. GB1700073.8

RTM

Date :15 June 2017

Intellectual

Property

Office

The following terms are registered trade marks and should be read as such wherever they occur in this document:

Android

Linux

OpenGL

Java

Dalvik

Docker

Raspberry PI

Intellectual Property Office is an operating name of the Patent Office www.gov.uk/ipo

METHOD AND APPARATUS FOR CONTAINER-BASED VIRTUALISATION

Field [1] The present disclosure relates generally to a method and apparatus for container-based virtualisation.

Background [2] Many media service providers provide client devices, such as set-top boxes, to their customers for consuming media content in their homes. These client devices may have limited processing capabilities, particularly for graphics processing.

[3] As a result, service providers may wish to reduce the graphics processing that is performed on the client devices, and to instead perform more processing on a remote server.

Such an approach may be known as 'cloud rendering' .

Brief description of the drawings [4] Examples of the present disclosure will now be explained with reference to the accompanying drawings in which:

Fig. 1 the methods is a block diagram of a system for implementing described herein;

Fig. 2 the methods is a block diagram of a described herein;

client device for use with

Fig. 3 is a block diagram of a with the methods described herein;

rendering server for use

Fig. described is a flowchart illustrating steps of a method herein;

Fig. 5 is a block diagram illustrating the use of a signalling server as part of a method described herein;

Figs. 6A and 6B are sequence diagrams illustrating communication flows between devices implementing a method described herein; and

Fig. 7 is a block diagram of a service management approach for use as part of the method described herein.

[5] Throughout the description and the drawings, like reference numerals refer to like parts.

Description of example embodiments

Overview [6] A method for container-based virtualisation on a server is described herein. The method comprises simultaneously operating a host operating system and a plurality of guest operating system instances. Each guest operating system instance operates within a separate container on the host operating system.

Example embodiments [7] Fig. 1 is a block diagram of a cloud rendering system.

The system comprises a plurality of client devices (or 'clients') 100a, 100b, etc. As one example, these client devices may be set-top boxes (STBs).

[8] In order to reduce expenditure, service providers may wish to minimise the cost and maximise the lifetime of STBs. As a result, at least part of these service providers' stock of deployed STBs may have severely constrained processing capabilities. In particular, the STBs may be ill-equipped to render the complex graphical user interfaces that customers have come to expect when interacting with modern electronic devices .

[9] Such rendering can, however, be offloaded onto a remote server. Accordingly, the system further comprises at least one rendering server 200 (or 'cloud rendering server', 'cloud server', 'host server', 'server'), which may be arranged to perform the method of any of the examples described herein.

The rendering server 200 can augment the client devices' rendering capabilities by rendering video streams, and transmitting the rendered video streams to the client devices 100. The client devices 100 then merely need to receive and decode the video streams, and do not necessarily need to perform any complex graphics processing.

[10] The video streams that are transmitted to the client devices 100 may be formed by overlaying a user interface on a video stream received from a content provider 300 (eg, content providers 300a and 300b in Fig. 1). This video stream may, eg, comprise a film, and may have been multicast by the content provider 300.

[11] The client devices 100, rendering server 200, and/or content providers 300, communicate via a communications network or networks. These communications network(s) may, eg, be the Internet, or may be a service provider's private network.

[12] The client devices 100 are each arranged to receive a respective video stream from the rendering server 200. Fig. 2 shows a block diagram of an exemplary client device 100. The client device 100 comprises a processor 110 arranged to execute computer-readable instructions as may be provided to the client device 100 via one or more of a memory 120, a network interface 140, or an input interface 150.

[13] The memory 120, for example a random access memory (RAM), is arranged to be able to retrieve, store, and provide to the processor 110, instructions and data that have been stored in the memory 120. The network interface 140 is arranged to enable the processor 110 to communicate with a communications network, such as the Internet. The input interface 150 is arranged to receive user inputs provided via, eg, a remote control. The processor 110 is further coupled to a display adapter 130, which is in turn coupled to a display device (not shown) upon which video content may be displayed. The client device 100 may also comprise a graphics processor (not shown), which may be arranged to decode a video stream received from the rendering server 200.

[14] The rendering server 200 hosts rendering sessions for each of the client devices 100. Fig. 3 shows a block diagram of an exemplary rendering server 200. The rendering server 200 comprises a processor 210 arranged to execute computerreadable instructions as may be provided to the rendering server 200 via one or more of a memory 220 or a network interface 240.

[15] The memory 220, for example a random access memory, is arranged to be able to retrieve, store, and provide to the processor 210, instructions and data that have been stored in the memory 220. The network interface 240 is arranged to enable the processor 210 to communicate with a communications network, such as the Internet.

[16] The processor 210, which may, as one example, be an Intel Xeon E3 processor, comprises a central processing unit (CPU) 212. Furthermore, the processor 210 may comprise one or more of an integrated graphics processor (IGP) 214, a discrete graphics processor/card (not shown), or a hardware video encoder/decoder 216. The IGP 214 and/or the discrete graphics processor assist the CPU with rendering operations. The hardware video encoder/decoder 216 is arranged to encode and/or decode video streams. The hardware video encoder/decoder 216 may be able to do so more quickly than the CPU 212.

[17] In order to enable the hosting of many simultaneous rendering sessions on a single rendering server 200, a virtualisation approach is used. In this approach, the rendering server 200 simultaneously operates a host operating system and a plurality of guest operating systems instances, where each guest operating system instance operates within a separate container on the host operating system.

[18] Each instance is for, or dedicated to, a respective one of the client devices 100. Each instance generates a data output stream, eg, a video output stream, for the respective one of the client devices 100. By using containers, each instance is isolated from the other instances, thereby enabling improved security and resource allocation.

[19] Unlike conventional software containers, the containers described herein are not limited to including one or more applications, but may also include a hardware abstraction layer, which explains why guest operating system instances are said to operate within the containers.

[20] Depending on processor availability, the guest operating system instances may be distributed across multiple processors of the rendering server 200, or may all operate on a single processor 210 of the rendering server 200. In one example, each guest operating system instance operates entirely on a single respective processor, thereby optimising the end-to-end pipeline and reducing latency.

[21] The operation of the containers may be managed using the Docker software developed by Docker, Inc. of San Francisco,

US. The guest operating system instances may operate an operating system designed specifically for mobile devices, such as Android, while the host operating system may be any operating system suitable for servers and/or desktop computers, such as a distribution or flavour of Linux (eg,

Ubuntu). By matching the host and guest operating systems, improved compatibility between the host operating system and the guest operating system instances may be achieved.

[22] When, for example, the guest operating system is Android, the guest operating system instances may access the IGP 214 and/or the discrete graphics processor of the processor 210 using the Open Graphics Library (openGL), and may access the hardware video encoder/decoder 216 using the Open Media Acceleration (OpenMAX) Application Programming Interface (API) or the libVA API.

[23] The guest operating system instances may be run with all, root, or special privileges, in order to provide the guest operating system instances with more access to the rendering server 200 hardware than they would otherwise have.

[24] Fig. 4 shows a flowchart of the steps of a method of cloud rendering. These steps are performed for each client device within the corresponding container.

[25] At step S405, the rendering server 200 receives an input video stream. The input video stream may be received in a multicast transmission from one of the content providers 300, eg, when the stream comprises a live television programme, or may be received in a unicast transmission from one of the content providers 300, eg, when the stream comprises video-ondemand (VOD) content.

[26] At step S410, the rendering server 200 forms a video buffer by decoding the received input video stream. This decoding may be performed by the hardware video encoder/decoder 216 for improved efficiency.

[27] At step S415, an application is run. The application may, for example, be a HyperText Markup Language (HTML) application, or an Android application. By allowing any of these types of applications to be run, a service provider may provide a large selection of applications to their customers.

[28] At step S420, an output of the application is used to form a graphics buffer. The graphics buffer may, eg, comprise a user interface.

[29] At step S425, the graphics and video buffers are mixed in order to form a data output stream. As one possibility, the graphics buffer may comprise a user interface which is at least partially transparent, and the mixing may comprise overlaying the graphics buffer on the video buffer.

[30] At step S430, the data output stream is encoded. This encoding may be performed according to any video compression standard, such as H.264, H.265, VP8, or VP9. The method of encoding may be chosen according to the client device 100's decoding capabilities.

[31] At step S435, the data output stream may optionally be encrypted. This encryption prevents eavesdropping by network nodes through which the stream passes, which may cause privacy issues, and prevents unauthorised copying of the video stream in transit, which may be a particular concern when the video stream includes high value content such as films.

[32] At step S440, the encoded data output stream (or the encrypted and encoded data output stream, if encryption is used) is transmitted to the respective client device 100.

[33] While the client device 100 is receiving a data output stream, the client device 100 may send signalling to the rendering server 200. As one possibility, the signalling may comprise a command to control video stream playback. For example, a user may activate a 'pause' button on their remote control or user interface.

[34] Since the data output stream is dedicated to a single client device 100, it may be transmitted in a unicast transmission. However, to reduce resource usage on the rendering server 200, the client device 100 may determine that unicast transmission is no longer required (eg, because the user interface is no longer visible), close the session(s) with the rendering server 200, and tune to the same media content being transmitted via multicast to various clients. Conversely, the client device 100 may determine that unicast transmission is now required (eg, because the user interface has been triggered); cease to receive the data output stream in a multicast transmission; and instead request a new session with the rendering server 200, thereby causing the data output stream to once again be transmitted to the respective client device 100 in a unicast transmission.

[35] In some examples, the establishment and operation of cloud rendering sessions is coordinated by a signalling server 400, as illustrated in Fig. 5. The client devices 100, rendering server 200, and signalling server 400 may be arranged to communicate with each other using the Web RealTime Communication (WebRTC) standard, which enables real-time, low-latency communication over peer-to-peer connections. In particular, WebRTC provides low latency & encrypted video streaming.

[36] Exemplary communications between the client device 100, rendering server 200, content provider 300, and signalling server 400 are illustrated in the sequence diagram of Figs. 6A and 6B.

[37] In particular, the rendering server 200 transmits an advertisement message 602 to the signalling server 400 to inform the signalling server 400 that a new instance running a particular application is available. In this example, message

602 indicates that instance 345 running application X is available .

[38] At this stage, the client device 100 is receiving a multicast or unicast video stream 606 directly from the content provider 300. In this example, the client device is receiving channel Y as a multicast transmission.

[39] The client device 100 sends a solicitation message 610 to the signalling server 400 to indicate that it is looking for a particular application. The solicitation message 610 may also indicate that the client device wishes the application to play a given content (or piece of content), such as a given channel, or a given VOD content. In this example, the solicitation message 610 indicates that the client device 100 is looking for application X, and wishes application X to be tuned to channel Y. The solicitation message 610 may be sent in response to a user input being received by the client device 100, eg, a user pressing a button on a remote control that triggers the appearance of playback controls.

[40] In response to the solicitation message 610, the signalling server 400 determines which instance or instances are capable of running the particular application, are currently available, and/or are well suited to playing the reguested content. In one example, multiple rendering servers are available, each rendering server 200 operating one or more guest operating system instances, and the signalling server 400 determines which of those instances are capable of running the particular application, are currently available, and/or are well suited to playing the requested content. A guest operating system instance on a particular rendering server 200 may be well suited to playing the request content if another guest operating system instance on that same rendering server 200 is already receiving the content that the client device wishes to receive, ie, if that other guest operating system instance is already tuned to same multicast stream. If no suitable instance is currently available, a new instance may be started (or launched) on the rendering server 200 - for example by instigation of the signalling server 400. The signalling server 400 then assigns one of those instances to the client device 100, sends the client device 100 a first session opening message 614 to open a WebRTC session with one of the determined instances, and sends the rendering server 200 a second session opening message 618 to open a WebRTC session with the client device 100. In this example, the signalling server 400 initiates the opening of a WebRTC session between instance 345 and the client device 100.

[41] In response to the second session opening message 618, the rendering server sends a WebRTC offer message 622 to the client device 100, which the client device 100 accepts by sending a WebRTC accept message 626 to the rendering server 200. As a result, a video stream and data WebRTC connection 630 are then established between the client device 100 and the rendering server 200.

[42] The rendering server 200 receives an input video stream 634 from a content provider 300. In this example, the input video stream corresponds to channel Y, and is received in a multicast video transmission.

[43] Following the establishment of the video stream and data connection 630, the client device 100 tunes (638) to a unicast video stream transmitted from the rendering server 200.

[44] The rendering server 200 transmits a unicast video stream 642 to the client device 100. In this example, the stream corresponds to application X, which is tuned to channel Y.

[45] User inputs 646 may be sent from the client device 100 to the rendering server 200, having optionally previously been encrypted by the client device 100. The rendering server 200 sends the user inputs 646, in a feedback message 650, to the application currently being rendered for the client device 100. As an example, a user may press a button on an input device, such as a remote control, to change the channel currently being displayed. The application X may then briefly display a message indicating that the channel has been changed. As another example, a user may press a button on the input device to pause the content that is currently being sent in the video stream. The application X may then display playback controls which indicate a current position in a video that the user is watching. The system and method described herein enable the data output stream that is transmitted to the client device 100 to adapt/react quickly (ie, with low latency) to user inputs 646, thereby avoiding any noticeable lag following a user input 646.

[46] In response to the feedback message 650, the application running on the rendering server 200 sends a unicast video stream 654 which takes into account the user inputs 646. For example, it may have an updated user experience.

[47] Some operating systems which may be used as guest operating systems may, if not otherwise modified, be configured so as to rely on exclusive access to the hardware of the rendering server 200. As a result, they may not function properly when operated in containers. As one example, the following describes a service management approach for the Android operating system.

[48] A kernel of the operating system comprises a binder driver, which facilitates interprocess communication by creating communication channels between processes, each channel being identified by a handle identifier. The Android framework provides libraries (C++ and Java) to encapsulate communications with the binder driver; one of the functions of these libraries is to perform caching for efficiency reasons.

[49] Processes running on the operating system may communicate with services of the operating system by referring to these services by name, rather than by referring to the corresponding handle identifier. A service manager process then maintains a table of association between service names and handle identifiers, ie, a list of pairs where each pair comprises a service name and a handle identifier. When a service starts, it sends, via the binder driver, a request to the service manager process to register a new service name with the handle identifier that has been attributed to the service by the binder driver. Subsequently, when a process wishes to send a message to a service, the process queries the service manager process to determine which handle identifier is associated with that service, and then sends its message to that handle identifier.

[50] The service manager process registers as the service_ctx process with the binder driver. A chicken-and-egg problem arises: processes cannot communicate with the service manager without knowing its handle identifier, and processes cannot determine the handle identifier for a process without using the service manager. The service_ctx process is therefore assigned a special, hard-coded handle.

[51] The binder driver is only able to register a single service_ctx process at any one time. Accordingly, it is not able to support services running in multiple simultaneous guest operating system instances.

[52] As one approach to address this issue, Fig. 7 illustrates a service management system suitable for use with multiple simultaneous guest operating system instances. The system relies on the fact that all processes started within a particular guest operating system instance are children of a single (init) process and thus, can be identified as belonging to the same instance.

[53] At least one service operates in each of the guest operating system instances, and the system comprises a single, global service manager 260 for these services. This service manager 260 is responsible for handling service registration and service lookup requests (or 'transactions' ) from all of the guest operating system instances, while ensuring that each of these requests is contained within the corresponding container. The service manager 260 does so by maintaining a list of triplets for each service, rather than a list of pairs. The triplets comprise a service name, a handle identifier, and an instance identifier. The service manager 260 operates on the host operating system, outside the containers, allowing it to communicate with both guest operating system instances 250a and 250b. The service manager 260 is started before these instances are launched.

[54] In addition, the system comprises a service registration process registergroup operating in each of the guest operating system instances. The service registration processes communicate with the service manager 260 to make the service manager 260 aware of each of the guest operating system instances 250a and 250b. The service registration process registergroup is started directly by init, ie, init is the direct parent process of registergroup, rather than being started indirectly by init, eg, via an encapsulated shell.

[55] When a guest operating system instance is launched, the service registration process in that instance registers with the service manager 260 by sending a registration request (a registergroup request) to the service manager 260. The service manager 260 determines a parent process of the service registration process, and stores an identifier for that parent process. The parent process for which the identifier is determined is the init process. However, as will be appreciated by the skilled person, a first process may not be a direct child of a second process, but may instead be an indirect child; for example, for Java applications that are started by a zygote process (Android Dalvik virtual machine). It may therefore be necessary to walk up (or determine) the parents of the service registration process in order to determine the identifier for the parent init process.

[56] Once each of the guest operating system instances has been registered, the services in each of the guest operating system instances can in turn be registered. The mechanism for such a registration is set out below for a single service.

[57] A process operating in one of the guest operating system instances sends a registration request for a given service to the service manager 260. The service manager 260 then determines in which of the guest operating system instances the process is operating. The service manager 260 then stores an association between an identifier for the given service and an identifier for the guest operating system instance in which the process is operating.

[58] More specifically, the service manager 260 determines a parent process of the process from which the registration request was received by determining an identifier for the parent init process of the process from which the registration request was received. The service manager 260 then stores a triplet comprising the name of the given service, the handle identifier for the given service, and the instance identifier for the guest operating system instance in which the process is operating.

[59] Once services have been registered, service lookup requests can be processed. A process operating in one of the guest operating system instances sends a lookup request for an identifier of a given service to the service manager 260. The service manager 260 then determines in which of the guest operating system instances the process is operating. The service manager 260 then determines an identifier, the identifier being for the given service operating in the guest operating system instance in which the process is operating.

[60] More specifically, the service manager 260 sends a lookup request comprising the name of the given service. The service manager 260 then determines a parent (init) process of the process from which the lookup request was received. The service manager 260 then searches for a triplet comprising the name of the given service and the instance identifier for the guest operating system instance in which the process that initiated the lookup request is operating. Once that triplet has been identified, the service manager 260 returns the handle identifier for that triplet to the process that initiated the lookup request. The service manager 260 thereby constrains the lookup request to the guest operating system instance of the process that initiated the lookup request.

[61] Once the process that initiated the lookup request has received the handle identifier for the given service, that process is able to communicate with the given service using that identifier.

[62] In order to send the data output streams for each of the guest operating system instances to the respective client devices 100, the data output streams are generated and captured.

[63] In one example, the rendering server 200 activates a virtual framebuffer for each of the guest operating system instances, and passes an identifier for each of the virtual framebuffers to the corresponding guest operating system instance. A framebuffer is a portion of memory that contains a current video frame or frames. When this portion of memory forms part of the main processor memory, rather than the memory of a graphics processor (eg, an IGP, or a discrete graphics card), the framebuffer is said to be 'virtual'. When a virtual framebuffer is used, the rendering is said to be 'soft', ie, it is performed in software rather than by dedicated hardware.

[64] In another example, the rendering server 200 may use dedicated hardware for rendering, eg, a discrete graphics card or an IGP. When the guest operating system is an Android operating system, in addition to the service registration processes registergroup, a surfaceflinger process operates in each guest operating system instance (as shown in Fig. 7) .

The surfaceflinger process is responsible for composing surfaces from each of the applications running in a particular guest operating system instance. Each application is rendered to an offscreen surface (a texture). Each surface is placed into a queue that is composed by surfaceflinger. The composition is drawn finally into a framebuffer (a video hardware output). To allocate these two types of surfaces (texture and framebuffer), surfaceflinger uses a hardware abstraction layer (HAL) named Gralloc. When surfaceflinger starts, Gralloc allocates a framebuffer for the rendering and a texture for each application. In one example, instead of allocating a framebuffer, Gralloc allocates a texture. The texture is identified by an identifier, thereby allowing the surfaceflinger rendering to be checked (or reviewed, monitored, transmitted) outside the container. Thus, each Android instance draws its graphic composition in an offscreen texture .

[65] It will be appreciated by the skilled person that although the host operating system and guest operating system instances operate simultaneously, in practice, a processor may only be able to execute a single instruction at a time. The term simultaneously is therefore intended to indicate that processes are pending in both the host operating system and the guest operating system instances at the same time.

[66] Although, in the above examples, the client devices are STBs, the client devices could be any electronic device having circuitry for receiving data output streams. For example, the client devices could be Raspberry Pi devices, tablets, laptops, smartphones, etc., or could be display devices, such as so-called smart TVs.

[67] Although, in the above examples, the guest operating system instances operate the same operating system, they may instead operate different operating systems, or different distributions, versions or flavours of the same operating system.

[68] As will be understood by a skilled person, the method described herein does not require all of the steps of Fig. 4 to be performed. As one example, if the application is not an application for use with an input video stream (eg, if it is a game, or a business/enterprise application), then steps S405 and S410 may be omitted, and step S425 may comprise generating a data output stream (only) from the graphics buffer. As another example, step S435 may be omitted if encryption is not required. Furthermore, the steps of Fig. 4 need not be performed in the listed order. As one example, the data output stream could be encrypted before it is encoded, ie, steps S430 and S435 could be swapped. Moreover, multiple applications may be run simultaneously within each container; for example, each application may occupy a different area of the video output stream. In this case, steps S415 and S420 may be performed for each application, and step S425 may comprise mixing the video buffer and the graphics buffers for each application.

[69] For ease of explanation, the steps of Fig. 4 have been indicated as being performed seguentially. However, as the skilled person would understand, these steps may be performed continuously, in parallel and/or in real-time. As one example, while a first frame of the data output stream is being transmitted, a second frame of the data output stream may be being encrypted. As another example, while a first frame of the data output stream is being encrypted, a second frame of the data output stream may be being encoded.

[70] Although, in the above disclosure, the method has been set out for video streams, the skilled person will understand that many elements of the method described herein apply egually to other types of data streams (or bitstreams), such as text streams, audio streams, numerical data streams, or alphanumerical data streams. For example, even if the data streams were not video streams, each guest operating system instance could generate a data output stream (step S425), and that data output stream could be optionally encoded (step S430), optionally encrypted (step S435), and transmitted to a client device (step S440).

[71] Furthermore, it should be understood that, in the present disclosure, the term 'video' may not necessarily exclusively denote a series of moving visual images or a series of image frames, but may instead or additionally denote a series of instructions for causing images and/or user interface elements to be displayed. For example, a video stream may comprise a user experience (UX) stream, a stream of openGL instructions, or a stream of X Window System (or Xll), Virtual Network Computing (VNC), or Remote Desktop Protocol (RDP) instructions/packets.

[72] In one example, the approach described herein is an operating-system-level virtualisation method for running multiple, isolated Linux systems (or containers) on a host (or control host) using a single Linux kernel. In another example, the guest operating system instances operate using a single, shared kernel of the host operating system. In yet another example, the host operating system comprises a kernel, and the guest operating system instances share the kernel of the host operating system.

[73] An effect of the present disclosure is the provision of a method, system and apparatus that achieve low-latency cloud rendering.

[74] An effect of the present disclosure is the provision of a method that is highly scalable and cost-effective.

[75] An effect of the present disclosure is the provision of a modern user experience to legacy devices with very limited processing and graphics power.

[76] An effect of the present disclosure is the provision of a platform that supports another ecosystem without requiring applications or the related operating system(s) to be ported to the client device.

[77] An effect of the present disclosure is the provision of a method, system and apparatus that reduce device fragmentation, by executing a virtualised client rather than requiring applications to be developed for each client device.

[78] An effect of the present disclosure is the provision of a method, system and apparatus that enable service providers to quickly develop and deploy ephemeral applications targeting various types of clients (eg, applications designed for a specific event).

[79] An effect of the present disclosure is the provision of a platform that allows enterprise applications to be run in the cloud, rather than on client devices, thereby offering improved security.

[80] It should be understood that, in the present disclosure, the verb 'to operate' may be used to mean 'to execute' or 'to run' .

[81] Those skilled in the art will recognise that a wide variety of modifications, alterations, and combinations can be made with respect to the above described examples without departing from the scope of the disclosed concepts, and that such modifications, alterations, and combinations are to be viewed as being within the ambit of the disclosed concepts.

[82] Those skilled in the art will also recognise that the scope of the invention is not limited by the examples described herein, but is instead defined by the appended claims .

[83] The approaches described herein may be embodied on a computer-readable medium, which may be a non-transitory computer-readable medium. The computer-readable medium carries computer-readable instructions arranged for execution upon a processor so as to make the processor carry out any or all of the methods described herein.

[84] The term computer-readable medium as used herein refers to any medium that stores data and/or instructions for causing a processor to operate in a specific manner. Such storage medium may comprise non-volatile media and/or volatile media. Non-volatile media may include, for example, optical or magnetic disks. Volatile media may include dynamic memory. Exemplary forms of storage medium include, a floppy disk, a flexible disk, a hard disk, a solid state drive, a magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with one or more patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, NVRAM, and any other memory chip or cartridge.

[85] A method for container-based virtualisation on a server is provided. The method comprises simultaneously operating a host operating system and a plurality of guest operating system instances. Each guest operating system instance operates within a separate container on the host operating system.

[86] Optionally, one or more of the guest operating system instances comprises a hardware abstraction layer.

[87] Optionally, one or more of the guest operating system instances operates a respective operating system designed specifically for mobile devices.

[88] Optionally, each respective operating system designed specifically for mobile devices is a respective Android operating system.

[89] Optionally, each respective operating system designed specifically for mobile devices comprises a respective Bionic C library.

[90] Optionally, each respective operating system designed specifically for mobile devices comprises a respective Android Java Virtual Machine (JVM).

[91] Optionally, each respective operating system designed specifically for mobile devices comprises a respective surfaceflinger process.

[92] Optionally, each of the guest operating system instances has at least one service operating therein, and the method further comprises operating a single, global service manager for the services of the guest operating system instances.

[93] Optionally, operating the global service manager comprises: receiving, from a process operating in one of the plurality of guest operating system instances, a lookup request for an identifier of a given service; determining in which of the plurality of guest operating system instances the process is operating; and determining an identifier, the identifier being for the given service operating in the guest operating system instance in which the process is operating.

[94] Optionally, the method further comprises communicating with the given service using the determined identifier.

[95] Optionally, determining in which of the plurality of guest operating system instances the process is operating comprises determining a parent process of the process from which the lookup request is received.

[96] Optionally, operating the global service manager comprises: receiving, from a process operating in one of the plurality of guest operating system instances, a registration request for a given service; determining in which of the plurality of guest operating system instances the process is operating; and storing an association between an identifier for the given service and an identifier for the guest operating system instance in which the process is operating.

[97] Optionally, determining in which of the plurality of guest operating system instances the process is operating comprises determining a parent process of the process from which the registration request is received.

[98] Optionally, operating the global service manager comprises: receiving a registration request from a service registration process in one of the plurality of guest operating system instances; determining a parent process of the service registration process; and storing an identifier for the parent process of the service registration process.

[99] Optionally, a service registration process operates in each of the plurality of guest operating system instances.

[100] Optionally, the server comprises a plurality of processors, and wherein all of the guest operating system instances operate on a single one of the plurality of processors .

[101] Optionally, each guest operating system instance is for a respective one of a plurality of client devices, each guest operating system instance generates a data output stream, and the method further comprises: encoding each of the data output streams; and transmitting each of the encoded data output streams to the respective one of the plurality of client devices.

[102] Optionally, the data output streams are video output streams .

[103] Optionally, the method further comprises capturing the data output streams from each of the guest operating system instances using a virtual framebuffer.

[104] Optionally, the host server comprises at least one graphics processor, and each guest operating system instance generates the data output stream using the at least one graphics processor.

[105] Optionally, the method further comprises capturing the data output streams from each of the guest operating system instances using a plurality of texture buffers.

[106] Optionally, the encoding is performed using a hardware video encoder.

[107] Optionally, operating the plurality of guest operating system instances comprises performing the following steps within each container running an application; forming a graphics buffer from an output of the application; and generating the video output stream based on the graphics buffer .

[108]

Language,

Optionally, the application is a HyperText Markup HTML, application.

[109] Optionally, the application is an Android application.

[110] Optionally, the graphics buffer comprises a user interface .

[111] Optionally, operating the plurality of guest operating system instances further comprises performing the following steps within each container: receiving an input video stream; and forming a video buffer by decoding the received input video stream, and generating the video output stream comprises mixing the video and the graphics buffers.

[112] hardware

Optionally, the decoding is performed using a video decoder.

[113] that are comprises

Optionally, the graphics buffer comprises portions at least partially transparent and the mixing overlaying the graphics buffer on the video buffer.

[114] multicast

Optionally, the transmission.

input video stream is received in a [115] Optionally, the unicast transmission.

input video stream is received in a [116] Optionally, the method further comprises encrypting each of the encoded data output streams before transmitting each of the encoded data output streams to the respective one of the client devices.

[117] Optionally, the encoded data output streams are transmitted in unicast transmissions.

[118] Optionally, the method further comprises, for a single guest operating system instance: in response to the respective one of the plurality of client devices determining that unicast transmission is no longer reguired, ceasing to transmit the encoded data output stream for the single guest operating system instance.

[119] Optionally, the method further comprises, for a single guest operating system instance: in response to receiving a message from the respective one of the plurality of client devices indicating that unicast transmission is no longer reguired, ceasing to transmit the encoded data output stream for the single guest operating system instance.

[120] Optionally, the method further comprises, for a single client device: determining that unicast transmission is no longer reguired; ceasing to receive the encoded data output stream for the single guest operating system instance in a unicast transmission; causing the encoded data output stream for the single guest operating system instance to be terminated; and switching to a direct stream from a content provider .

[121] Optionally, the method further comprises, for a single client: determining that unicast transmission is no longer reguired; ceasing to receive the encoded data output stream for the single guest operating system instance in a unicast transmission; causing the encoded data output stream for the single guest operating system instance to be terminated; and causing the client to receive the output stream in a multicast transmission.

[122] Optionally, the method further comprises the client device: determining that unicast transmission is no longer reguired; ceasing to receive the encoded data output stream from the server; optionally, causing the encoded data output stream from the server to be terminated; and switching to a direct stream from a content provider server.

[123] Optionally, the direct stream is delivered by one of a multicast, broadcast or unicast transmission.

[124] Optionally, the method further comprises receiving signalling from at least one of the plurality of client devices .

[125] Optionally, the signalling comprises a command to control video stream playback.

[126] Optionally, the signalling comprises a command to navigate within a user interface.

[127] Optionally, the command is based on one or more of a keyboard, mouse, or touch input.

[128] Optionally, the establishment of a session is in accordance with a Web Real-Time Communication, WebRTC, standard.

[129] Optionally, the signalling is in accordance with a Web Real-Time Communication, WebRTC, standard.

[130] There is provided a server arranged to perform any of the methods described herein.

[131] There is provided a system comprising a server arranged to perform any of the methods described herein; and at least one of the plurality of client devices, the at least one of the plurality of client devices being arranged to receive the respective at least one of the encoded data output streams from the server.

[132] Optionally, the at least one of the plurality of client devices is a set-top box or a display device.

[133] There is provided a non-transitory computer-readable medium carrying computer-readable instructions which, when executed by a processor, cause the processor to carry out any of the methods described herein.

Claims

1. A method for container-based virtualisation on a server, the method comprising simultaneously operating a host operating system and a plurality of guest operating system instances, each guest operating system instance operating within a separate container on the host operating system.

2. The method of claim 1, wherein one or more of the guest operating system instances comprises a hardware abstraction layer .

3. The method of any preceding claim, wherein one or more of the guest operating system instances operates a respective operating system designed specifically for mobile devices.

4. The method of claim 3, wherein each respective operating system designed specifically for mobile devices is a respective Android operating system.

5. The method of any preceding claim, wherein each of the guest operating system instances has at least one service operating therein, and wherein the method further comprises:

operating a single, global service manager for the services of the guest operating system instances.

6. The method of claim 5, wherein operating the global service manager comprises:

receiving, from a process operating in one of the plurality of guest operating system instances, a lookup request for an identifier of a given service;

determining in which of the plurality of guest operating system instances the process is operating; and determining an identifier, the identifier being for the given service operating in the guest operating system instance in which the process is operating.

7. The method of claim 6, further comprising communicating with the given service using the determined identifier.

8. The method of any of claims 6 to 7, wherein determining in which of the plurality of guest operating system instances the process is operating comprises determining a parent process of the process from which the lookup request is received.

9. The method of any of claims 5 to 8, wherein operating the global service manager comprises:

receiving, from a process operating in one of the plurality of guest operating system instances, a registration request for a given service;

determining in which of the plurality of guest operating system instances the process is operating; and storing an association between an identifier for the given service and an identifier for the guest operating system instance in which the process is operating.

10. The method of claim 9, wherein determining in which of the plurality of guest operating system instances the process is operating comprises determining a parent process of the process from which the registration request is received

11. The method of any of claims 5 to 10, wherein operating the global service manager comprises:

receiving a registration request from a service registration process in one of the plurality of guest operating system instances;

determining a parent process of the service registration process; and storing an identifier for the parent process of the service registration process.

12. The method of any preceding claim, wherein a service registration process operates in each of the plurality of guest operating system instances.

13. The method of any preceding claim, wherein the server comprises a plurality of processors, and wherein all of the guest operating system instances operate on a single one of the plurality of processors.

14. The method of any preceding claim, wherein each guest operating system instance is for a respective one of a plurality of client devices, each guest operating system instance generates a data output stream, and the method further comprises:

encoding each of the data output streams; and transmitting each of the encoded data output streams to the respective one of the plurality of client devices.

15. The method of claim 14, wherein the data output streams are video output streams.

16. The method of claim 15, further comprising:

capturing the data output streams from each of the guest operating system instances using a virtual framebuffer.

17. The method of claim 15, wherein the host server comprises at least one graphics processor, and wherein each guest operating system instance generates the data output stream using the at least one graphics processor.

18. The method of claim 17, the method further comprising capturing the data output streams from each of the guest operating system instances using a plurality of texture buffers .

19. The method of any of claims 15 to 18, wherein the encoding is performed using a hardware video encoder.

20. The method of any of claims 15 to 19, wherein operating the plurality of guest operating system instances comprises performing the following steps within each container:

running an application;

forming a graphics buffer from an output of the application; and generating the video output stream based on the graphics buffer .

21. The method of claim 20, wherein the application is a HyperText Markup Language, HTML, application.

22. The method of claim 20, wherein the application is an Android application.

23. The method of any of claims 20 to 22, wherein the graphics buffer comprises a user interface.

24. The method of any of claims 20 to 23, wherein operating the plurality of guest operating system instances further comprises performing the following steps within each container :

receiving an input video stream; and forming a video buffer by decoding the received input video stream, and wherein generating the video output stream comprises mixing the video and the graphics buffers.

25. The method of claim 24, wherein the decoding is performed using a hardware video decoder.

26. The method of any of claims 24 to 25, wherein the graphics buffer comprises portions that are at least partially transparent and the mixing comprises overlaying the graphics buffer on the video buffer.

27. The method of any of claims 24 to 26, wherein the input video stream is received in a multicast transmission.

28. The method of any of claims 24 to 26, wherein the input video stream is received in a unicast transmission.

29. The method of any of claims 14 to 28, further comprising encrypting each of the encoded data output streams before transmitting each of the encoded data output streams to the respective one of the client devices.

30. The method of any of claims 14 to 29, wherein the encoded data output streams are transmitted in unicast transmissions.

31. The method of claim 30, further comprising, for a single guest operating system instance: in response to the respective one of the plurality of client devices determining that unicast transmission is no longer required, ceasing to transmit the encoded data output stream for the single guest operating system instance.

32. The method of claim 30, further comprising, for a single guest operating system instance: in response to receiving a message from the respective one of the plurality of client devices indicating that unicast transmission is no longer required, ceasing to transmit the encoded data output stream for the single guest operating system instance.

33. The method of any of claims 14 to 32, further comprising:

receiving signalling from at least one of the plurality of client devices.

34. The method of claim 33, wherein the signalling comprises a command to control video stream playback.

35. The method of any of claims 33 to 34, wherein the signalling is in accordance with a Web Real-Time

Communication, WebRTC, standard.

36. A server arranged to perform the method of any of claims 1 to 35 .

37. A system comprising:

the server of claim 36; and at least one of the plurality of client devices, the at least one of the plurality of client devices being arranged to receive the respective at least one of the encoded data output streams from the server.

38. The system of claim 37, wherein the at least one of the plurality of client devices is a set-top box or a display device .

39. A non-transitory computer-readable medium carrying computer-readable instructions which, when executed by a processor, cause the processor to carry out the method of any of claims 1 to 35.

Intellectual

Property

Office

Application No: Claims searched:

GB 1700073.8 1-39