 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 272: Mobile Broadcast Service API for Handheld Terminals
The following has been updated from the original request: 2012.08.22: The following section has been updated. 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
TCK: 2012.08.21: North Sixty-One has become the co-Maintenance Lead. Maintenance Lead: Kimmo Löytänä E-Mail Address: jsr272 Telephone Number: - Fax Number: -
Original Java Specification Request (JSR)
Identification |
Request |
Contributions
Section 1. Identification Submitting Member: Motorola Name of Contact Person: Ivan Wong E-Mail Address: ivan.wong@motorola.com Telephone Number: +1 408 541 6747 Fax Number: +1 408 541 6508 Specification Lead: Antti Rantalahti & Ivan Wong E-Mail Address: antti.rantalahti@nokia.com & ivan.wong@motorola.com Telephone Number: +358 7180 36705 & +1 408 541 6747 Fax Number: +358 71870 37133 & +1 408 541 6508 Initial Expert Group Membership: Nokia Supporting this JSR: Nokia Section 2: Request
2.1 Please describe the proposed Specification:The proposed specification specifies an Optional Package API for client Java applications for interactive broadcasting purposes for mobile terminals. The API enables the Java applications to receive, exploit, and interact (via the interactive channel, for example wireless cellular link) with content received over a digital broadcast link. The API is targeted for CLDC/MIDP based mobile terminals.
Some aspects of this specification may rely on existing J2ME APIs. The existing APIs may be used and this JSR will define necessary extension APIs to the specific challenge presented by mobile digital broadcasting.
o Service search and discovery o Service & content access and consumption o Reception and consumption scheduling and timing o Service subscription, purchasing and 2. Managing the applications delivered via the broadcasting stream containing o Receiving and management of Java applications o Application parametrization
The proposed specification will not define a complete end-to-end platform. In addition, the implementations will need a number of formats and protocols which will not form part of the specification itself.
- Extract specific pieces of information / perform some queries on the service guide information once it has been downloaded on the terminal (e.g.: fetch all broadcast services of a given type within a given timeframe; fetch all the TV programs corresponding to a given genre, etc.). - Support for 'zapping' (i.e. fast browsing) channels, to provide quick discovery of all available services.
Service & Content Access and Consumption:
- Access to AV broadcasting stream to allow viewing of the programme by using MMAPI (JSR-135). - Access to subtitles, tickers, and image and hypertext data which can be delivered via broadcast. - Access to parameters that indicate the current ability of a terminal device to receive a selected broadcast service. These parameters include: network information, signal strength, error rate, terminal profile information and its version. - Manage the lifecycle of a service.
Reception / Consumption Scheduling and Timing:
- Parameterize the platform implementation to perform storing / recording when a timer expires (e.g.: when the program is on air, a 'PVR-like' platform service is automatically launched and subsequently stopped when the recording is completed).
Service Subscription, Purchase and Interaction:
At application management level, the API provides following functionality:
Broadcast delivers applications and other data in addition to media content. The API allows receiving and running of those applications. It will be specified how the the wanted and not-wanted applications and the security is handled and what is the application life cycle. 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)The API is targeted for J2ME. The API requires MMAPI 1.1 and is targeted for CLDC/MIDP based platforms although it will be usable with CDC as well. 2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.The target platform is CLDC / MIDP but since the required platform is MMAPI, which is not bound to any specific configuration or profile, the proposed API can be used both in CDC and CLDC configurations. 2.4 Should this JSR be voted on by both Executive Committees?No 2.5 What need of the Java community will be addressed by the proposed specification?This set of APIs allows development of device independent broadcast applications which are either delivered within the broadcast channel itself or acquired by other means. Those applications can provide interactive services related to the service (programme) binding the services and applications to together. Examples about such services are voting and purchasing applications. 2.6 Why isn't this need met by existing specifications?There is no framework addressing the specific needs of digital broadcast services such as digital TV. Further, none of the existing APIs, which are suitable for CLDC/MIDP do not provide proposed functionality. While MMAPI includes broadcast radio concepts (radio locator specification), and AMMS (JSR-234, Advanced Multimedia Supplements) provides more finer grained tuner control APIs, these do not provide sufficient coverage for the digital broadcast TV domain. For example, the concept of ?channel? is different in digital television and therefore the existing APIs cannot be used as such.
Further, the MIDP/CLDC does not provide the required level of application management and service management. I.e., access and management of the applications delivered by the broadcaster is not specified in any of the existing CLDC/MIDP APIs. 2.7 Please give a short description of the underlying technology or technologies:Receiving the digital broadcast content and services (for example digital television) requires specialized hardware, but from Java perspective the media it provides fits well into MMAPI framework. The proposed API will utilize the multimedia framework of MMAPI to initialise and view the services. AMMS can be used (not mandatory) to lay graphics on top of the video. Generic Connection Framework is used for interactive services. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.broadcast 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?The device implementing the API must have hardware to receive the digital broadcast 2.10 Are there any security issues that cannot be addressed by the current security model?Management, storage, and execution of the applications and content delivered via the broadcast present security issues which may or may not be covered by the existing security model(s). This specification will address and resolve those issues either by proving that the current security model(s) are sufficient or by defining new means to guarantee the required security. 2.11 Are there any internationalization or localization issues?None 2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?No 2.13 Please describe the anticipated schedule for the development of this specification.Early Draft Review: Q3/2005 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.E-mail, teleconference/video conference, and periodic face-to-face discussions as needed and as appropriate. 2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.Initially, the purpose is to publish complete drafts only on stages required by the process and get feedback about them from the community. 2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.Both RI and TCK will be delivered as stand-alone packages. 2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).No previous versions and new version will be stand-alone 2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.These terms only represent the initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by Nokia at its sole discretion. Section 3: Contributions
3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.MMAPI 1.1 specification: http://jcp.org/jsr/detail?id=135 3.2 Explanation of how these items might be used as a starting point for the work.The proposed API builds on top of MMAPI 1.1. Overlays on top video from AMMS is very usable but no mandatory with this API.
As described above, the specification will not make any such protocols an essential requirement however EG participants are expected to have the features of this protocol in mind when designing the corresponding parts of this specification. It is not believed at this time that any of the Java APIs defined as part of MHP in non-JCP namespaces address requirements of this specification and hence it is not proposed to include any of those APIs in this specification. |
