4 System description

26.1503GPPProtocols and codecsRelease 17Syndicated Feed Reception (SFR) within 3GPP environmentsTS

4.1 Functional overview

The following diagram (see Figure 1) illustrates the overall system for syndicated feed reception (SFR). The system is subdivided into an SFR enabled Feed Reader, a SFR server and Syndicated Feed Provider.

SFR enabled Feed Readers are clients, which provide all the functionality to parse, process and (opt.) present syndicated feeds. The SFR enabled Feed Reader can interact with any legacy syndicated feed server (e.g. RSS or Atom) using HTTP. Additionally, those clients are also able to optimize the syndicated feed reception and/or optimize the handling of enclosures as defined in this specification. SFR enabled Feed Readers may support one or more syndicated feed formats such as RSS or Atom. From an implementation/deployment perspective, the SFR enabled Feed Reader can be shared by multiple ATOM/RSS-based applications or could be incorporated as a part of such an application.

SFR enabled Feed Readers, which include "optimized reception" of feed updates and/or enclosures support interactions with SFR servers.

SFR servers offer the SFR enabled Feed Reader with functions to optimize the reception of feed updates, attached media and enclosures. SFR servers interact with one or more syndicated feed servers. The interaction protocols and procedures of SFR server with Syndicated feed servers are out of scope of this specification. The SFR server is a profiled OMA DCD server dedicated to optimize syndicated feed delivery.

Syndicated feed providers are legacy functions, which use HTTP to offer their syndicated feeds.

Figure 1: Overall SFR System

The SFR enabled Feed Reader interacts with the SFR server in order to get an optimized reception of syndicated feeds using the "Admin" reference point. The SFR server provides the SFR enabled Feed Reader with feed content using OMA Push or MBMS download delivery using the "Push" reference point. The "Pull" reference point is used, when the SFR enabled Feed Reader pull content from the SFR server. The "Admin", "Push" and "Pull" reference points are realized using a subset of the OMA DCD-3, DCD-2 and DCD-1 reference points [5].

The "Admin" transactions between SFR enabled Feed Reader and SFR server re-use a subset of the OMA DCD-3 transactions. The "Push" procedures between SFR server and SFR enabled Feed Reader re-use the OMA DCD-2 transactions (see section 5.6) and extend them to cover MBMS delivery via direct binding. The "Pull" Interface to the SFR Server corresponds to "DCD-1". The "Pull" procedures between SFR server and SFR enabled Feed Reader re-use a subset of OMA DCD-1 transactions (See section 5.6). The SFR enabled Feed Reader implements a profile of the DCD client and supports some of the DCD Enabled Client Application (DECA) functionalities.

The "Poll" interface to the syndicated feed provider (dashed line) corresponds to the stateless pull of legacy syndicated feed readers using HTTP. The "Poll" interface is not in scope of this specification.

The profiling of DCD [5] is defined in section 5.7.

4.2 Operations overview

Syndicated Feed Reader, which want to use "optimized reception" as defined in this specification must first activate and register with the SFR server to establish a session and then initiate the optimized reception of desired Syndicated Feeds (i.e. also called channels).

The SFR server provides the SFR enabled Feed Reader with a session-id as value of the Session-ID field in the activation response message that corresponds toa successful activation. This session-id is used during all later transactions. One or more syndicated feed reception channels may be added to or removed from the session at any point in time.

The SFR enabled Feed Reader use the Syndicated Feed URI (content address) of the syndicated feed to initiate the optimized reception. The SFR Server shall use the content address of the syndicated feed as value for the Channel-ID field. The Channel-ID value is used to identify specific syndicated feeds during later transactions. The Channel-ID value is present at any syndicated feed related transaction.

The session is persistent, even if the UE is switched-off. However, all or some channels can be suspended. The UE may suspend some or all syndicated feeds when roaming in foreign networks by sending a channel suspend request to the SFR server. The SFR enabled Feed Reader may also indicate as part of the channel subscription procedure that while roaming, content delivery shall automatically be suspended. In that case and upon detection that the UE is roaming, the SFR server shall suspend the delivery.

Each transaction on the "Admin", "Push" and "Pull" reference point is uniquely identified by a transaction-identifier, which is provided with the value of the Message-ID field. The value of the Message-ID field is composed of a unique transaction-id identifier followed by two numeric characters for message index within the transaction. The transaction identifier is the same for all related messages of a transaction within a session.

The SFR enabled Feed Reader can find e.g. the response to a certain request message based on the transaction-identifier. All messages belonging to the same transaction shall use the same transaction identifier value in the Message-ID field.

Example of message-id:

Transaction id= 01178AC32

Message id = 01178AC3200 for the first message, and message id = 01178AC3201 for the second message.