Proposals Overview P2200D1 Joseph Meza SanDisk. Notice/Release/Patent P&P Notice: This document has...

Proposals OverviewP2200D1

Joseph Meza

SanDisk

Notice/Release/Patent P&P• Notice: This document has been prepared to assist the IEEE P2200 working group. It is offered

as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend, or withdraw material contained herein.

• Release: The contributor grants a free, irrevocable license to The Institute of Electrical and Electronics Engineers, Inc. (“IEEE”), a corporation with offices at 445 Hoes Lane, Piscataway, NJ 08855-1331, to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by the IEEE P2200 working group.

• Patent Policy and Procedures: The contributor is familiar with the IEEE Patent Policy and Procedures <http://standards.ieee.org/guides/bylaws/sect6-7.html#6>, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the IEEE of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the chair of the IEEE P2200 working group <[email protected]> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE P2200 working group. If you have questions, contact the IEEE Patent Committee Administrator at <[email protected]>.

2Insert Date hereInsert Title here

mailto:[email protected]

Proposals Overview

Date: 2011-1-19

Author(s):

Name Company Address Phone email

Joe Meza SanDisk601 McCarthy Blvd

Milpitas, CA +408-801-1000 [email protected]

Yehuda Hahn SanDisk8 Atir Yeda, Kfar Saba,

Israel+972-9-764-6730 [email protected]

IEEE P2200Draft Standard Protocol for Stream Management

in Media Client Devices



HQME Proposals

• Part 1: Behavioral Specification• Overview, Use Cases, Describes a Reference Architecture

• Part 2: Request Manager• Deferred Transfer Request, Lifecycle, submitting and

managing requests

• Part 3: Virtual Storage Device• Defines Interface and behavior of a VSD

• Part 4: Access Control• Describes Base Security Model, Permissions

• Part 5: Capacity Management• VSD Extension Feature for autonomously optimizing storage

• Part 6: Legacy Transition• Interoperability with non-HQME clients and servers


Reference Architecture


Part 2: Request Manager

QueueRequest– Properties– Policies

• Rules

Request Manager Interface– Submit QueueRequests– Manage active QueueRequests– Query request queue


QueueRequest

What stream is to be transferred – this contains a minimum set of metadata describing the content to be transferred and provides a set of optional metadata to further describe the content to be transferred.

Where is the stream to be transferred to and from – describing the locations in URI format of the source and destination from and to where the content is to be transferred.

When and how the stream is to be transferred – additional parameters constrain the transfer by defining a set of rules or Policy that define the criteria required in order to perform the transfer. The policy may, for example, set a specific time or use of a specific network interface (i.e. Wi-Fi Only).


QueueRequest Continued

What, Where assigned as Properties:• REQPROP_SOURCE_URI

• REQPROP_STORE_NAME

• REQPROP_TYPE

• REQPROP_TOTAL_LENGTH

• REQPROP_TITLE (Display Title)

• REQPROP_DESCRIPTION

• REQPROP_ PROGRESSIVE (Immediacy)

• REQPROP_EXPIRATION_DATE

• REQPROP_PERMISSIONS_xxxx (Various Permissions)

When assigned as Policies:

A policy consists of a set of constraints on a particular QueueRequest. While all of these constraints are met, a QueueRequest may be executed.


Polcies (set of Rules)

Network. This defines the networks that may be used, such as 3G and Wi-Fi.

Schedule. This defines the hours in which the QueueRequest may be executed. The QueueRequest will not be executed except during the hours listed in the constraint.

Maximum size. The maximum total size of the transferred object; may vary according to the network type and schedule. For example, the maximum size may be unlimited for Wi-Fi, 5MB during peak-use period and 10MB for off-peak over 3G.

Battery power. A QueueRequest may be limited to execution only when the device battery has at a certain minimum charge.


Polcies (set of Rules) Continued

Charging status. A QueueRequest may be limited to execution only when the device is being charged

Device network activity status. A QueueRequest May be limited to execution only when the device is has no other network activity or has network activity below a certain threshold.

Expiration. A QueueRequest may only be valid for a certain period of time, after which it is no longer valid.

Virtual Storage Device. A QueueRequest may be limited to execution only when a certain VSD is available. (For example, a QueueRequest may be constrained to execute only if a secure VSD is online and can accept the stream.)

10

Rules defined as Properties

RULE_CHARGING_STATE

RULE_POWER_LEVEL

RULE_CONNECTION_TYPE

RULE_FREE_SPACE

RULE_MAX_SIZE

RULE_PRIORITY

RULE_TIME

RULE_DAY_OF_WEEK

RULE_BANDWIDTH_LIMIT

RULE_DAY_OF_WEEK

RULE_FUNCTIONGROUPS (Required VSD Features)

11

Example Policies

1. Execute deferred Transfer only when the device is connected via WiFi and when the Power level is greater than 30 percent:

RULE_POWER_LEVEL = 30

RULE_CONNECTION_TYPE = “WLAN”

2. Execute deferred Transfer only on weekdays after 7:00PM

RULE_DAY_OF_WEEK = “MON TUE WED THU FRI”

RULE_TIME = “19:00”

12

Request ManagerrequestCount( ) - retrieve the number of queued requests

getRequestIds( ) – retrieve a list of requestIds in the queue

getRequest() - retrieve a specific QueueRequest from queue

submitRequest() – submit a new QueueRequest

cancelRequest() – cancel a previously submitted QueueRequest

suspendRequest( ) – suspend a previously submitted QueueRequest

resumeRequest( ) - resume a suspended QueueRequest

getProgress( ) – get the current progress of a QueueRequest

getState( ) – get the state of a QueueRequest (suspended, active, etc.)

getPriority( ) – get the priority of a particular QueueRequest

setPriority( ) - set the priority for a particular QueueRquest

setPolicy( ) – set the policy for a request or group of requests

13

Querying a QueueRequestIn addition to a QueueRequest’s properties, the following

information can be retrieved:

REQPROP_REQUEST_ID

REQPROP_REQUEST_STATE

REQPROP_LAST_MODIFICATION_DATE

REQPROP_CURRENT_BYTES_TRANSFERED

14

Part 3: Virtual Storage Device

Virtual Storage Device– Properties– FunctionGroups

Enumerating VSDs– StorageManager

• Interface• Events

Accessing Content on VSDs– ContentObjects

• Properties• Methods


Virtual Storage Device

A Virtual Storage Device (VSD) is a logical representation of a physical storage medium capable of storing and maintaining content which is transferred using a deferred transfer request (QueueRequest). The physical storage medium represented by a VSD can be internal, embedded storage of a device or removable storage, either internal or external.

FunctionGroups enable an Extensible Architecture

A VSD may implement a number of optional defined features. Features are expressed via Function Groups, which are defined sets of functions and properties. A VSD may be queried to determine the FunctionGroups supported by the VSD.

16

VSD Concepts

Multiple VSDs may be present in a given device.

VSDs implement one or more FunctionGroups

VSDs offer a level of abstraction to the physical storage

The data associated with a QueueRequest is stored on a VSD

Applications can enumerate the available VSDs

Applications can enumerate the content on a particular VSD

Applications can submit a QueueRequest requiring the use of a particular VSD with a particular FunctionGroup

17

Enumerating VSDs

StorageManager Interface

VSDCount( ) – retrieve the number of VSDs on the client

getStorageIds( ) – get storage IDs for VSDs on the client

getStore( ) – retrieve VSD object

getCapabilities( ) – retrieve FunctionGroup info for a particular VSD

StorageManager Events

vsdAdded, vsdRemoved, vsdModified, vsdReadComplete, vsdWriteComplete

18

VSD Properties and Methods

Properties

VS_FN_GROUPS

VS_TOTAL_CAPACITY

VS_AVAILABLE_CAPACITY

VS_OBJECT_COUNT

Methods

allObjects( ), getObject( )

getProperty( ), setProperty( ), removeProperty( )

issueCommand( ), getCommandStatus( )

19

ConentObject

A ContentObject provides an interface to retrieve data associated with a QueueRequest and its associated properties

Set of Mandatory Properties:

S_STORE_NAME, S_STORE_SIZE, S_SOURCEURI

S_ORIGIN, S_LOCKED, S_TYPE

Set of Optional Properties (non-exhastive List)

S_TITLE, S_DESCRIPTION, S_ALBUM, S_ARTIST, S_GENRE

S_TRACK_NUMBER, S_DISK_NUMBER, S_COPYRIGHT, S_DIRECTOR

S_PRODUCER, S_PUBLISHER, S_COMPOSER, S_ENCODER, S_BITRATE

S_THUMBNAIL, S_RATING, S_URLINFO, S_LYRICS, S_TV_NETWORK

Zero or more Vendor defined Properties

VEND_XXXX_XXXX

20

ContentObject

Access to ContentObject Properties:

getProperty( ), setProperty( ), removeProperty( )

Access to ContentObject data:

size(), open( ), close(), read_async( ), read( ), write_async( ), write( ), lseek( ), tell(),

Access to ContentObject as a Stream:

getStream() – returns URL of locally streamed content

21

Part 4: Access Control







Part 5: Capacity Management







Part 6: Legacy Transition

Key Concepts

ProtocolHandler Interface– Interfacing non-Compliant Servers


Identifying a compliant Client

HTTP/1.1 Specification chapter 14 defines fields for a HTTP compliant header. One of the standard header fields defined in section 14.43 defines a User-agent header field, which provides information regarding the client generating the HTTP request. This standard defines a User-Agent string to be used by all clients compliant with this standard.

25

Proposals Overview P2200D1 Joseph Meza SanDisk. Notice/Release/Patent P&P Notice: This document has...

Documents

Transcript of Proposals Overview P2200D1 Joseph Meza SanDisk. Notice/Release/Patent P&P Notice: This document has...