Publish/Subscribe Application Format

Publish/Subscribe (PubSub) is an established communication paradigm where senders do not communicate information directly to the intended receivers but rely instead on a service that mediates the relationship between senders and receivers. Specifically senders (called Publishers) post information to and receivers (called Subscribers) declare their interest in specific information to a Service. Here the mediator service is called Match Service Provider (MSP).

It should be noted that “Publisher” is not necessarily a user who distributes media to end users and “Subscriber” is not necessarily synonymous with end user or consumer. Indeed Publisher may represent a user who has created a media item and wants to make it available to publishers and Subscriber may represent a publisher who is looking for media to be distributed. Therefore Publisher could very well be a creator who announces the availability of his latest work and Subscriber could be a publisher who is looking for new works to publish.

A typical steps of a Publish/Subscribe workflow in a media distribution context are given in the table below, where “Resource” is the media item that is announced (i.e. published) by Publisher and will be eventually consumed by a Consumer.

Note that steps 2 and 3 may also happen in reverse order, i.e. a Subscriber can look for information before the information is actually published. In other words there is no specified order for Publications and Subscriptions to be made.

Publish/Subscribe Application Format (PSAF) allows parties of the PubSub communication model to support functionalities that are specific to publication, search and consumption of media content (Resource). The PubSub communication parties are:

1. Publishers
   1. Create and store Resource Information (RI) on a publicly accessible location (e.g. an Information Centric Network)
   2. Create and send Publications Information (PI to Match Service Providers (MSP)
2. Subscribers create and send Subscriptions Information (SI) to Match Service Providers (MSP)
3. Match Service Providers (MSP)
   1. Perform matches of Subscriptions with Publications
   2. When a Match has been found send Notification Information (NI) to users listed in PIs and SIs
4. Consumers
   1. Receive Notification Information (NI)
   2. Access the Resource present in or referenced by the Resource Information (RI).

The PSAF standard specifies RI, PI, SI and NI in such a way that typical multimedia communication requirements can be supported. A non-exhaustive list of such requirements is

• Publisher shall be able to
  • Describe the Resource for cinsumption purposes
  • Define the contract that will bind the Publisher and a Consumer
  • Request a device to report use of the Resource
  • Describe the Resource for distribution purposes
  • Define the contract that will bind the Publisher and a Match Service Provider (MSP) of a match involving the Publication
  • Request the MSP to notify/not to notify a list of users
• Subscriber shall be able to
  • Query the Resource
  • Define the contract that will bind the Subscriber and a Match Service Provider (MSP)
  • Request the MSP to notify/not to notify a list of users of a match involving the Subscription

PSAF does not specify the protocols used to carry these payloads.

The Publish/Subscribe communication paradigm, adapted to creation, publication and retrieval of media content, is represented by the workflow and figure below (the numbers in the list refer to the same numbers in the figure)

Publisher Stores Resource (1) Creates RI Stores RI (2) Creates PI Publishes PI (3) Subscriber Creates SI Subscribes SI (4) Match Service Provider Finds Match between SI and PI (5) Notifies Publisher and Subscriber (6) Consumer Retrieves RI (7) Retrieves and plays Resource (8)

Figure 1 – A graphical representation of PubSub for multimedia

NB: Consumer is the user receiving NIs. It may or may not coincide with Subscriber or Publisher.

CEDEO has developed the main contributions t the PSAF standard and implemented PSAF in the context of the European FP7 project GreenICN, where it has developed WimICN, a video distribution platform for ICN depicted by Figure 1.

Figure 2 – The WimTV service platform

WimICN supports two forms of video services: on demand and live. The latter takes two forms: a normal live event and a scheduled event that is a combination of on demand videos and live events. Video upload and live event/scheduled program creation are performed by WimTV (the white blocks in the figure above), while PubSub, and the put/get of MPD and segments to/from ICN are performed by the other GreenICN system components (the light blue boxes in the figure above). User devices are mobile handsets running the WimCom (ccnx) and WimPeer (publication-subscription-consumption) on Android.

Of particular note is the ICN Gateway which operates in two modes

1. When a Publisher selects one of the videos that he has previously ingested to ICN from his private area (called WimBox), the Segmenter creates DASH MPD and segments and sends them to the ICN Gateway for storage to ICN. The PubSub Application receives the MPD on the Publisher’s ICN PubSub channel and creates RI and PI using other metadata provided by Publisher.
2. When a Publisher selects one of the live or scheduled programs that he has previously created from his private list, WimTV sends the Publisher information regarding the live event or scheduled programs. The PubSub Application creates RI and PI using other metadata provided by Publisher.