Skip to main content

A New Approach to Publishing and Caching Video

A Content Delivery Network offers a new approach to digital media delivery that allows Communication Service Providers to control the flow of content throughout the delivery cycle and ensure a consistently superior quality of experience (QoE) on any screen. In this first of a two-part series, we introduce the architecture and design considerations of a Content Delivery Network (CDN) and provide an overview of the publishing/storage and caching processes. Part 2 is a primer on the delivery, management and control functions. There is growing consumer appetite for online video from content providers such as Hulu, Netflix, BBC or CANAL+. Because these third parties have built their own relationships with the end user, they earn any incremental revenue, which threatens to shut out and marginalize Communication Service Providers (CSPs). As video traffic continues to grow at a startling pace, this becomes even more untenable. This is driving CSPs to broaden their core business from merely providing Internet connectivity to including content as well. CDNs offer an alternative, enabling CSPs to transform into “entertainment providers” and meet consumer demand for premium online content.

What is a Content Delivery Network?

A CDN is a system of caches containing copies of data. This data is distributed at various points in a network, which maximizes the bandwidth required to access the data from clients throughout the network. A client accesses a copy of the data nearest to the client, as opposed to all clients accessing the same central server. This avoids bottlenecks near that server. Content types include web objects, downloadable objects (media files, software, and documents), applications and real-time media streams. At the highest level, all CDNs look alike and have a high-level model similar to the one shown in Figure 1.

Design considerations

A communication service provider’s CDN design requirements differ from Internet web-caching services in the following ways:

  • Availability – system architecture without single points of failure, in service software updates and/or infrastructure extensions
  • Operation – Because the quality and speed of delivery depends on the distance between the CDN server and the consumer, delivery caches need to be distributed in close proximity to end users.
  • Performance – high-definition streaming video requires sustained high throughput and low latency
  • Resilience – ability to mitigate congestion issues and resume interrupted downloads
  • Security – integrity and security measures to protect digital rights and prevent piracy
  • Efficiency – intelligent content replication based on dynamic demand and content popularity

These six principles should be the main considerations of any CDN architecture.

CDN components

Most CDN architectures are constructed from a number of key components (Figure 2):

  • Delivery nodes: The primary purpose is delivery of data to consumers. It contains caches each running one or more delivery applications; these tend to be deployed as close to the edge (near the consumers) as possible.
  • Storage nodes: The primary purpose is providing data to caches. These can be deployed in a hierarchical model to allow tiered caching and protection to any origin servers. These nodes can also be used where prepublishing of content is required rather than content being acquired on demand from origin servers.
  • Origin nodes: These are the master sources for content and can be deployed within the CSP’s network or more commonly within a content owner’s infrastructure. A number of origins will be provided for scale and resilience.
  • Control node: The primary purpose is to host the management, routing and monitoring components of a CDN. This is typically the integration point into any Operation Support Systems (OSS)/Business Support Systems (BSS) and Network Operations Centers (NOCs).

CDN process and functions

The operation of a CDN is reliant on a number of processes and functions that can be categorized as:

  • Publishing/Storage – CSP management of content and publishing processes
  • Caching – replication and content caching within the CDN
  • Delivery – physical delivery of content to subscriber devices
  • Management and control – management, monitoring and control of the CDN

Publishing/Storage The process of acquiring content or publishing/ingesting content into a CDN should support a number of models:

  • Pre-ingest: Content is uploaded to CDN storage nodes before it is first requested by a consumer. The content can then be tested or prepared before being made available to subscribers.
  • Acquire on demand: This method would acquire the content from an on- or off-network origin storage device when first requested by a consumer, typically using a reverse proxy method. The content would subsequently be cached by the CDN.
  • Live: Ingest of live streams from a publishing point

Authorization and registration This is the process that allows a content owner to authorize the CDN to deliver content. It is typically performed by the creation of a new content object with associated metadata describing the delivery information of the object (availability date/time, expiry time, authentication parameters, delivery protocols allowed). A CDN should provide both graphical user interfaces and programmatic interfaces to allow the management and registration of object metadata. Ingest Where content is to be prepublished to a CDN, a number of standard technologies should be supported to allow integration with content management systems. The most common methods to ingest content are:

  • FTP (File Transfer Protocol)
  • Third-party upload accelerators such as Aspera
  • Batch control scripts used to trigger publishing jobs
  • Programmatic Hypertext Transfer Protocol (HTTP) Rest and WebService interfaces

Store Scalable storage solutions are required to replicate ingested content within the CSP’s CDN. The storage solution needs to be secure and highly available by supporting redundant storage devices/media. Storage must be configurable so specific content can reside on different sets of storage devices to conform to any distribution rights. Storage should be able to work as content origins, hierarchical storage to support delivery devices, and shield storage to protect content origins from overload. Availability After publishing and registration of content is complete, a successful availability notification must be provided back to the content owner so the content can be made available within any delivery portal. These interfaces are typically programmatic in nature but can also include automated e mail notification mechanisms. Caching process Caching within the CDN provides the means to replicate and store content effectively on edge and storage devices, without having to reacquire this content from multiple sources. Acquisition Acquisition is the mechanism where an edge cache has to acquire content from a CDN storage node or origin server to deliver this content. The acquisition process must support various authentication methods with the content origin as well as identify the most relevant and cost-effective source for the content. As with any delivery process, the applicable content geo-blocking rules must be observed when acquiring content. Replication These are the means of physically acquiring or replicating content across distributed caching devices. It is typical for CDNs to use multiple replication techniques based on content types. For example, the replication of adaptive streams which actually are comprised of thousands of very small segment files (.ts files) would be very different from the replication of a large multi-GB high-definition media file. Methods for chunking and simultaneous distribution of a large media file from multiple piece caches can provide a very efficient replication strategy and reduce network costs. Ensuring that content is replicated from the nearest sources is another important consideration. A content source on an existing delivery device within the same rack or location would be preferable to going to the content origin server, which could be in a different network. Support for hierarchical caching is also advised. This allows edge caches to request content from more centralized ‘shield’ caches to help protect storage vaults or content origins from request storms from edge caches when highly anticipated new content is made available.


To run an effective CDN it is essential to co-host caching functions on the delivery devices. The aim of caching is to reduce network traffic to a minimum. This is achieved by delivering content from caches as close to the requesting consumer as possible but also by ensuring the delivery device has effectively cached the content from previous requests. A number of approaches or caching algorithms are used to achieve this. Two of the most commonly used are:

  • Last Recently Used (LRU) – adds new content to cache when requested and removes last recently used content when the cache fills
  • Least Frequently Used (LFU) – counts how often an item is needed. Those that are used least often are discarded first.

Considerations on cache dimensioning and cache effectiveness:

  • Cache dimensioning and effectiveness will drive the business model to a great extent.
  • Cache dimensioning is determined by storage capacity and streaming capacity.
  • Cache effectiveness is a function of the popularity curve (see Figure 3). As the popularity curve flattens so does cache effectiveness.
  • Cache effectiveness increases as memory increases, but so do costs. Transport costs are traded for the cost of the cache (times number of locations).
  • Modeling shows that the optimal solutions vary from multiple caches with small memory to one cache with large memory.
  • Tiered caching strategy caters best to cache effectiveness, capacity efficiency and flexibility.
  • A small number of titles will dominate usage (red bars in Figure 3). The quality of service (QoS) associated with these titles is vital to maintain a good customer experience.

Transform network for content delivery

We’ve now addressed some of the design considerations and functions for CSPs deploying a CDN. The second article in this series "Optimize Delivery to Meet Demand for "Video Everywhere"" will cover design, management and control. To learn more about the technical challenges associated with distribution of large media assets over web protocols such as HTTP and IP visit Velocix Digital Media Delivery Platform or Alcatel-Lucent Multiscreen Video Platform. To learn more about the technical challenges and trends for service providers looking to deploy CDNs, read our article Video Distribution in the Digital Lifestyle Era. To contact the author or request additional information, please send an e-mail to:

Richard Gibbs

About Richard Gibbs

Job Title : Vice President Worldwide Technical and Business Consulting, Velocix, an Alcatel-Lucent company.
Richard Gibbs joined Velocix from Tribold where he held the role of Vice President of Worldwide Sales Consulting. In this role he helped deliver initial key customer accounts and supported the development of Tribold’s new product portfolio management software. Prior to Tribold he held the role of Chief Technology Officer, EMEA for Epiphany, and has also held various senior managerial roles at Siebel Systems and other Customer Relationship Management (CRM) solution providers.

Article tags