Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 272: Mobile Broadcast Service API for Handheld Terminals

Updates to the Original JSR

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.

- Available free of charge to qualified not-for-profit organizations and individuals in accordance with the JSPA, solely for developing and testing their own implementations and not allowing to test any third party or commercial for-profit implementations.
- The TCK is licensed, in line with the MSA licensing principles, with a flat fee of USD 50 000 for a license term of 3 years. This includes all maintenance updates and releases, if any. The license will be worldwide, non-exclusive and will be granted on an AS IS basis without any warranties or indemnities given and with the exclusion of all indirect and consequential damages. Major new releases, from new follower JSR, are subject to a separate license fee.
- The license grant will be for a term of not less than three (3) years.
- A license allowing licensees to test implementations on behalf of third parties as a free or for-fee commercial service under certain conditions shall be available. This right may result in a higher license fee.

2012.08.21: North Sixty-One has become the co-Maintenance Lead.

Maintenance Lead: Kimmo Löytänä

E-Mail Address:

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:

Telephone Number: +1 408 541 6747

Fax Number: +1 408 541 6508

Specification Lead: Antti Rantalahti & Ivan Wong

E-Mail Address: &

Telephone Number: +358 7180 36705 & +1 408 541 6747

Fax Number: +358 71870 37133 & +1 408 541 6508

Initial Expert Group Membership:


Supporting this JSR:


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.
Scope of the proposal
The scope of the proposal can be dividided into two topic areas

    1. Managing the interactive broadcasting services containing
    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.
For example, formats for service guide information and protocols for delivery of service guide information, for delivery of Java applications via digital broadcast links and for signalling the properties of Java applications delivered as part of digital broadcast links. No such formats or protocols will be an essential part of this specification. These formats and protocols may be implementation specific or may be specified by other organisations and processes.
In either case, implementations will need a mapping from the APIs defined in this specification to those protocols and formats. It is not currently intended to include any such mapping in this specification but this possibility is not completely excluded.
Detailed API requirements
Following are more detailed requirements for the proposed API.
At service management level, the API provides following functionality:
Service Search and Discovery:
This set of APIs triggers the retrieval of the service guide information, which indicates the list of broadcast services and how to consume them (schedules, free or pay content, etc.). As such, this API allows clients to:

    - Access to service guide information, which contains the data about the available services including schedules, service descriptions and access to them. If this information is not already available locally, this operation implies tuning of the broadcast reception module to receive the full service guide information or updated portions of it.
    - 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:
This set of APIs makes the broadcasted content available at an application level, whether this content is on-air or locally stored. As such, this set of API allows clients to:

    - Retrieve the broadcasted contents/services (A/V stream, files, etc.). If these contents/services are not already available locally, this operation implies tuning of the reception module to consume the broadcasted contents/services.
    - 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:
This set of API allows clients to:

    - Plan the consumption of a given service (e.g.: a user wants to record a TV program that is to be broadcast 3 hours from now)
    - 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:
The proposed specification specifies a framework for user identification, service purchasing and provisioning. It also allows service interaction by utilizing the existing J2ME APIs. This specification will not specify new APIs for payment.

At application management level, the API provides following functionality:
- Receiving and management of Java applications delivered via broadcast.

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.
- Application parameterisation support

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?


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.
Some of these needs are met by JavaTV (particularly Service Search and Discovery and Receiving and management of Java applications delivered via broadcast) however JavaTV cannot be used as-is due to dependencies on java.awt, and which are not in CLDC.
JSR-242, "OnRamp to OCAP" addresses some issues with interactive broadcasting and CLDC however where this focusses on compatibility with CDC and requires the use of java.awt (not lcdui) and of JMF (not MMAPI).

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.)


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?


2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.13 Please describe the anticipated schedule for the development of this specification.

Early Draft Review: Q3/2005
Public Review: Q1/2006
Final specification: Q3/2006

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.
During the time preceding the EDR the community page is used to provide information about the API in the level which describes the functional features and the main architecture for fulfill them. People joining the observer list can also be informed about the topics in the API design if they feel interest for it.
In EDR and PR the overview of the API will be used to provide additional information about the design decisions and their reasoning together with possible request about comments for some specific area in the API. That same additional information will be available from the community page as well.

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.
We will license to all interested parties. Independent implementations will be allowed - TCK and RI will be licensed separately.
For the TCK we will charge a single one-time fee of max US $50,000 and an annual maintenance fee, max US $20,000 for a term of four years. The TCK will include both the binary environment and the source code for the test suite. The maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to an additional single one-time fee.
Using the TCK for testing of implementations on behalf of third parties will be allowed, though, be subject to a higher fee, which is capped at the sum of license fees due in accordance with license fees as described above in this section, if the third parties would have directly licensed the TCK from Nokia.
For the RI in source code form we will charge a one-time access fee, and an annual maintenance fee.
Maintenance covers bug fixes, updates and new releases necessary due to specification changes, and when made generally available by the specification lead.
The binary license is free of charge.

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:
AMMS specification:
JavaTV specification:
TVAnytime metadata specification, ETSI TS 102 822-3-1 V1.2.1 (2004-09) from IETF "draft-ietf-mmusic-img-framework-08.txt" DVB Multimedia Home Platform (MHP), ETSI ES 201 812 V1.1.1 (2003-12) from
3GPP TS 26.346 "MBMS Protocols and Codecs" v1.5.0 from
3GPP TS 22.146 "Technical Specification Group Services and System Aspects; Multimedia BroadCast/Multicast Service" v6.6.0 from
OMA BCAST Service Guide (Draft v1.0) from

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.
The experts group will evaluate if parts of Java TV or other existing Java APIs could provide the target functionality for this JSR and if reasonable subsets of those APIs can be created. The EG will give re-use of existing APIs (or appropriate subsets) preference over invention of new duplicative APIs for the same function.
TVAnytime and MMUSIC are well known publicly available formats for service guide information.
OMA BCAST Service Guide will specify, once ready, the service guide for broadcast services.
MBMS 'Technical Specification Group Services and System Aspects' contains the core requirements for Multicast and Broadcast Services, which are sufficient to provide a complete service.
MBMS Protocols and Codecs specify speech, audio, video and multimedia codecs in both circuit switched and packet switched networks.
As described above, the specification will not make any such format an essential requirement however EG participants are expected to have the capabilities and features of these formats in mind when designing the corresponding parts of this specification.
The MHP specification includes protocols for delivery of Java applications as part of broadcasts and for signalling the properties of Java applications delivered as part of broadcasts.

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.
Should the requirements for this specification change during the work of the EG such that aspects of those APIs become relevant, the possibility of negotiating with the owners of those APIs is not excluded