Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.150  Word version:  18.0.0

Top   Top   Up   Prev   Next
0…   5…   5.3…   5.4…   6…   A…   A.2   A.3   A.4… 
5.4 Optimized reception initiation of a syndicated feed  5.4.1 Introduction  5.4.2 Optimized reception initiation triggered by the UE  5.4.3 External triggered optimized reception initiation  5.5 Reception Termination  5.6 Content Reception  5.7 SFR profile of DCD  5.7.1 Procedure  5.7.2 Metadata 
...

 

5.4  Optimized reception initiation of a syndicated feed  p. 14

5.4.1  Introduction  p. 14

The sections below specify the methods for initiating the optimised reception of feeds, whether the initiation is triggered by an external component,by the SFR enabled Feed Reader, or by the SFR server.

5.4.2  Optimized reception initiation triggered by the UE  p. 14

The reception initiation for optimized reception procedure may be triggered when a UE subscribes to a syndicated feed. A UE subscribes to a syndicated feed, when it is interested in the content updates provided in this syndicated feed.
The SFR enabled Feed Reader registers with the SFR server to enable optimized reception of syndicated feed updates and its enclosures and attachments (e.g. images). The "activation for syndicated feed reception" procedure (clause 5.3) shall be executed at least once before the reception initiation procedure.
The SFR server may need to establish a relation with the Syndicated Feed Provider to become aware about new content. If the Syndicated Feed Provider is a DCD Content Provider, then the SFR server should use procedures as defined in section 7.2.1 of [5] for the OMA CPR interface. In a scenario whereby the syndicated feed provider is not a "DCD Content Provider" and does not support the OMA-CPR interface, the SFR server retrieves the content from the syndicated feed provider via an HTTP GET request and inserts the relevant metadata in the feed both for optimised handling of enclosures and for optimised delivery.
Copy of original 3GPP image for 3GPP TS 26.150, Fig. 6: Reception Initiation triggered by the UE
Figure 6: Reception Initiation triggered by the UE
(⇒ copy of original 3GPP image)
Up
The Reception Initiation procedure (see Figure 6) uses a subset of the OMA DCD Channel Subscription Procedure (see section 7.1.3.7 of [5]).
Information Elements of the ChannelSubscriptionRequest message:
  • Session-ID: Mandatory in OMA DCD and SFR.
  • Message-ID: Mandatory in OMA DCD and SFR.
  • Delivery-personalization-Metadata: Conditional in OMA DCD and SFR. Delivery-personalization-metadata contains at least the Channel-ID. In SFR the Channel-ID shall take the value of the feed address. The relevant subset of delivery personalization metadata for SFR is defined in clause 5.7.
  • Channel-ID: Conditional in OMA DCD and SFR.
  • Subscription-ID Conditional in OMA DCD and SFR (issued upon subscription personalization).
Information Elements of the ChannelSubscriptionResponse message:
  • Session-ID: Mandatory in OMA DCD and SFR.
  • Message-ID: Mandatory in OMA DCD and SFR.
  • Channel-Metadata (delivery-preference-metadata): Optional in OMA DCD and SFR. If delivery-preference-metadata is return, the feed address is provided as the value of the channel-id. Relevant subset of the delivery-preference metadata for SFR is defined in clause 5.7.
The delivery over MBMS might be done via the DCD OMA-BCAST adaptation specification or as an MBMS direct adaptation specification as described in clause 5.6.
Up

5.4.3  External triggered optimized reception initiation  p. 15

The user discovers a feed via other means (e.g. from an operator's web portal) and subscribes the UE externally (e.g. using a PC) for optimized syndicated feed reception. The user provides the relevant information (e.g. MSISDN) to receive the syndicated feed on its UE.
Copy of original 3GPP image for 3GPP TS 26.150, Fig. 7: Reception Initiation triggered by an external device
Figure 7: Reception Initiation triggered by an external device
(⇒ copy of original 3GPP image)
Up
If an external device triggers the Reception Initiation through the SFR server, a subset of the OMA DCD Channel Subscription Notification Procedure (see section 7.1.3.9 of [5]) is used (see Figure 7).
Information Elements of the ChannelSubscriptionNotification message:
  • Session-ID: Mandatory in OMA DCD and SFR.
  • Message-ID: Mandatory in OMA DCD and SFR.
  • Application -ID: Mandatory in OMA DCD and SFR.
  • Subscription-ID Conditional in OMA DCD and SFR (if issued upon subscription personalization).
  • Channel-Metadata: General-channel-metadata are mandatory, delivery-preference-metadata are conditional. Relevant subset of the channel metadata defined in clause 5.7.
Information Elements of the ChannelSubscriptionNotificationResponse message:
  • Session-ID: Mandatory in OMA DCD and SFR.
  • Message-ID: Mandatory in OMA DCD and SFR.
  • Channel-Metadata (delivery-personalization-metadata): Mandatory in OMA DCD and SFR. The relevant subset of the delivery-personalization-metadata is defined in clause 5.7.
Up

5.5  Reception Termination  p. 16

Reception termination corresponds to the procedure, when a UE decides to discontinue optimized reception of syndicated feed updates.
Copy of original 3GPP image for 3GPP TS 26.150, Fig. 8: Reception Termination
Figure 8: Reception Termination
(⇒ copy of original 3GPP image)
Up
The Reception Termination procedure (see Figure 8) uses a subset of the OMA DCD Channel Unsubscription Procedure (see section 7.1.3.8 of [5]).
Information Elements of the ChannelUnsubscriptionRequest message:
  • Session-ID: Mandatory in OMA DCD and SFR.
  • Message-ID: Mandatory in OMA DCD and SFR.
  • Channel-ID: Mandatory in OMA DCD and SFR...
Information Elements of the ChannelUnsubscriptionResponse message:
  • Session-ID: Mandatory in OMA DCD and SFR.
  • Message-ID: Mandatory in OMA DCD and SFR.
Up

5.6  Content Reception  p. 17

The SFR enabled Feed Reader uses the "Push" interface for optimized reception. The "Push" interface uses the DCD-2 interface and related procedures. Note that DCD-2 transactions are partly built on DCD-1 transactions:
  • Content Update Push procedure: ContentUpdate Push message and optionally ContentDeliveryConfirmation message
  • Content Update Notification procedure: ContentUpdateNotification message, ContentUpdateRequest message, ContentUpdateResponse message and optionally ContentDeliveryConfirmation message.
The DCD-2 interface binds to:
  • OMA-PUSH as specified in [5]. SFR enabled Feed Reader shall support OTA-WSP notifications and may support other OMA-Push features. The SFR server shall use OTA-WSP for the content update push procedure and the Content Update Notification procedure for larger transmissions. The SFR server may support other OMA-Push features.
  • MBMS delivery if supported:
    • Via DCD adaptation to BCAST. This is optional to support for both the SFR server and SFR enabled Feed Reader.
    • Via MBMS direct adaptation specification for DCD procedures as follow:
      • When MBMS is supported, the SFR enabled Feed Reader and the SFR server shall support the mbms-access-info parameters in the DCD-2-broadcast-profile element as described in clause 5.9
      • Via OTA-PTM (if supported)
The SFR enabled Feed Reader may use the "Pull" interface for optimized reception. This can be used when the content provider specify that the content can be retrieved in "pull" as per the content network-preference metadata. The "Pull" interface uses a sub-set of DCD-1 interface that corresponds to the Content Update procedure, wich is widely aligned with the Content Update Notification procedure of the "Push" interface. The Content Update procedure consists of the ContentUpdateRequest, ContentUpdateResponse and optionally the ContentUpdateConfirmation messages.request, ContentUpdate response and ContentUpdateConfirmation as specified in clause 7.1.1.1.
Other DCD procedures (e.g. Content Submission procedure) specified for the DCD-1 interface may be supported by some implementations but are not required for SFR enabled Feed Readers and SFR servers 1.0.
Up

5.7  SFR profile of DCD  p. 18

5.7.1  Procedure  p. 18

The SFR profile defines the set of DCD procedures that an SFR enabled Feed Reader and an SFR server supports:
SFR enabled Feed Reader and an SFR server shall support the following DCD procedures:
Other DCD procedures may be supported but are not required for this specification:
  • Content Submission
  • Usage tracking report
  • Channel Subscription Update
  • Content Repair
  • Contextual Information Update
  • Channel Metadata update
  • All procedures between DCD client and DCD enabled Client Application
  • All procedures between DCD servers and DCD content providers
Up

5.7.2  Metadata  p. 18

5.7.2.1  Application Profile Metadata  p. 18

The SFR enabled Feed Reader and the SFR server shall support the following subset of DCD application profile metadata as specified in section 8.1.2 of [5]:
  • "application-profile" element with the following attributes:
    • "application-id"
    • "dcd-channel-selection-metadata" element

5.7.2.2  Channel Selection Metadata  p. 19

The SFR enabled Feed Reader and the SFR server shall support all Channel Selection metadata as specified in section 8.2.2.1.1 of [5].

5.7.2.3  Delivery Personalisation Metadata  p. 19

Channel Delivery personalisation metadata listed below, as specified in section 8.2.2.1.2 of [5], with specific values for particular parameters. The Channel delivery personalization metadata is always sent from client to server:
  • "channel-id" attribute: either RSS URL or value of "atom:id"
  • "content-availability-notification" attribute: The SFR enabled Feed Reader should set this to"true"
  • "delivery-when-roaming" attribute: default False
"dcd-2-broadcast-profile" element with the following additional sub-parameters (Mbms-access-info and usd-description) to support the direct binding to MBMS:
dcd-2-broadcast-profileE20..1A set of parameters that define how the DCD Client receives content via the DCD-2 interface for specific transports (note: WAP Push requires no special configuration).
Contains the following attributes:
cell-broadcast-message-id
Contains the following sub-elements:
bcast-access-info mbms-acess-info
StructureDC
Mbms-access-infoE30..1MBMS specific connection details for file delivery session over which the SFR Enabled feed Reader should expect DCD-2 interface data to be delivered via MBMS
Contains the following sub-elements:
Sdp-description
StructureDS, DC
usd-descriptionA1URI to the MBMS User Service Description FragmentStringDS, DC
Up

5.7.2.4  General Channel Metadata  p. 19

The SFR enabled Feed Reader and the SFR server shall support the following DCD general channel metadata as specified in section 8.2.2.2.1 of [5] with the following values. The general channel metadata is provided from the SFR server to the SFR enabled Feed Reader:
  • DCD Channel-ID: SFR server or SFR Feed provider shall use the DCD Channel ID for identification of the RSS feed. The value of Channel ID shall be identical to the RSS feed URL. In the case of Atom feed, the DCD Channel ID shall take the value of the "atom:id" element.
  • DCD Content-type: This metadata parameter is provided by SFR server and used by SFR enabled Feed Reader to filter available syndicated feeds in the channel guide. It is used at channel/feed discovery stage to enable the SFR server to match application preferences and available feeds and to create a subset of channels/feeds that correspond to the preferences of installed SFR enabled applications. This subset is returned to device during channel discovery and the SFR client enables subscription to the particular feeds. The DCD content-type corresponds to the rss category or atom:category fields.
  • DCD Mime-type: This metadata parameter is provided to indicate needed mime type support to correctly receive the syndicated feed. This parameter is used at channel/feed discovery stage e.g. filtering relevant channels and content for the UE:
    • By SFR enabled Feed Reader to announce capabilities (i.e. supported mime-types).
    • By SFR server to announce types of syndicated feeds and of media content included in the enclosures of the syndicated feeds in the channel. RFC 4281 shall be used to indicate the mime-type.
The SFR enabled Feed Reader and the SFR server may support the following DCD general channel metadata, as specified in section 8.2.2.2.1 of [5], that corresponds to some ATOM or RSS feed metadata. If these DCD metadata are supported, the value of equivalent parameters in ATOM or RSS shall be used as values for the corresponding DCD metadata:
  • DCD Channel-name: This DCD channel metadata corresponds to the RSS Channel Title and/or to the ATOM Feed.title parameter.
  • DCD Updated: This DCD channel metadata corresponds to the RSS channel lastbuildDate and/or to the ATOM feed.updated parameter.
  • DCD channel-description: This DCD channel metadata corresponds to the RSS channel description and/or to the ATOM feed.subtitle parameter.
  • DCD genre: This DCD channel metadata corresponds to the RSS channel category and/or to the ATOM feed.category.
  • DCD channel-icon: This DCD channel metadata corresponds to the RSS channel image and/or to the ATOM feed.icon/ feed.logo. The DCD Channel-icon provides a mime-type attribute that is not available in ATOM and RSS.
Other general channel metadata as described in [5] and not listed above may be supported but are not required for SFR.
Up

5.7.2.5  Delivery preference metadata  p. 20

The delivery preference metadata listed below, as specified in section 8.2.2.2.3 of [5], with specific values for particular parameters, shall be supported. Delivery preference metadata are provided either by feed provider or SFR server:
  • "channel-id" attribute: either RSS URL or value of "atom:id"
  • "dcd-interface":
    • "DCD-2/point-to-point": OMA-Push with point-to-point bearers
    • "DCD-2/Broadcast": Content delivery with MBMS Download delivery method in case of direct MBMS binding
    • "DCD-1/HTTP(S)": Content reception using unicast UMTS bearer services
  • "dcd-2-broadcast-profile" with the additional element "Mbms-access-info" define in clause 5.7.2.3.
Up

5.7.2.6  Content Metadata  p. 20

Content Metadata are provided by the feed provider. In SFR, content metadata are RSS and ATOM metadata and may consist of DCD Content metadata. The SFR server can update or add some DCD metadata to the content metadata received from the feed provider.
If the syndicated feed provider uses the DCD content metadata, or if the SFR server extends the feed metadata with DCD metadata, then the following shall apply:
The SFR enabled Feed Reader and the SFR server shall support the DCD content metadata as specified in section 8.3.2 of [5] and with the particular limitations described below:
  • DCD mime-type: This parameter shall be used by SFR to indicate the expected mime-type of the content item and of the enclosure in the item. RFC 4281 shall be used to indicate the mime-type.
  • DCD replace-content-id: this parameter shall be used by SFR to indicate which content item shall be replaced by the content item for which a content-id (RSS item guid and/or ATOM feed.entry.id) is provided in the same message.
The SFR enabled Feed Reader and the SFR server may support the following DCD content metadata as specified in section 8.3.2 of [5] that corresponds to some ATOM or RSS entry metadata. If these DCD metadata are supported, the value of equivalent parameters in ATOM or RSS shall be used as values for the corresponding DCD metadata:
  • DCD content-id: This DCD content metadata corresponds to the RSS item guid and/or to the ATOM feed.entry.id parameter.
  • DCD content-name: This DCD content metadata corresponds to the RSS item title and/or to the ATOM feed.entry.title parameter.
  • DCD content-update: This DCD content metadata corresponds to the ATOM feed.entry.updated parameter. There is no equivalent parameter in RSS.
Up

5.7.2.7  Other DCD Metadata  p. 21

Other DCD metadata may be supported but are not required for SFR v1.0:

Up   Top   ToC