 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
 JSRs: Java Specification Requests
JSR 307: Network Mobility and Mobile Data API
JCP version in use: 2.6 Java Specification Participation Agreement version in use: 2.0 Description: This JSR provides API's for initiating and controlling data sessions in a mobile device and providing applications control over wireless network selection. Please direct comments on this JSR to the Spec Lead(s) Team
This JSR has been Dormant The following information has been updated from the original proposal: 2009.05.15: Maintenance Lead: Brian Deuser E-Mail Address: brian.deuser Telephone Number: - Fax Number: - Original Java Specification Request (JSR)
Identification |
Request |
Contributions |
Additional Information
Section 1. Identification Submitting Member: Motorola, Inc. Name of Contact Person: Eric Overtoom E-Mail Address: eric.overtoom Telephone Number: +1 847 523-8865 Fax Number: +1 847 523-4713 Specification Lead: Eric Overtoom, Mike Milikich E-Mail Address: eric.overtoom Telephone Number: +1 847 523-8865, +1 512-996-4216 Fax Number: +1 847 523-4713, +1 512-996-7160 Initial Expert Group Membership: Motorola Supporting this JSR: Motorola Section 2: Request
2.1 Please describe the proposed Specification:This JSR provides two APIs: one to establish packet data sessions with particular attributes such as bandwidth, latency, QoS or destination APN (for GPRS) and another for providing a framework for managing network mobility for mobile platforms and applications on those platforms. Data control and network mobility control are linked together because many use cases for the data capabilities in this JSR also include operations that need information about the available networks (to determine what services to offer to the user).
Mobile Data API Additional APIs in the framework provide for notifications of changes in session attributes, along with mechanisms to change the attributes of an active session. For devices with multiple data transport mechanisms (such as cellular and WLAN), the API provides a means to select a particular transport for the session. As an example of the attributes which may be specific (for a GPRS session), this would include APN, minimum and requested bandwidth, traffic class (conversational, streaming, interactive, background) and latency limits.
Network Mobility API 2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)Java ME. The Java APIs for Mobile Data will be based on the Java ME Connected Limited Device Configuration (CLDC 1.1), or the Java ME Connected Device Configuration (CDC). The target is mobile devices with embedded wireless data communications capabilities. It is expected that this JSR will often be used in conjunction with the Mobile Information Device Profile (MIDP) version 2.0. However, it is intended that the APIs should only depend on standard CLDC 1.1 or CDC 1.1 APIs, and should not require MIDP. This specification will, however, include recommended practices for the implementation of MIDP specific features as they relate to mobility, such as Security. This specification will also include recommended practices for the implementation of the interfaces on CDC 1.1, including Security. 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 the MID Profile on Java ME. 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 JSR will provide standard Java APIs so that mobile and embedded Java applications can be developed that are aware of the capabilities of a mobile data platform and its current data network association, and can change the configuration of a data session in progress. Notifications of changes in capabilities, as well as initial configuration of the session (QoS, APN, route, network) are provided through this API. An example of the need for this API is an application which is designed for a cellular telephone, and which needs to connect to a particular server node within the cellular network. The application needs control over two attributes of this connection - (1) being able to specify the node name (APN) that the session should be opened to, and (2) having the ability to restrict this connection to only operate over the cellular network. Other examples include cases where knowledge of the network and its available bandwidth can be used to enhance the user experience of the application. Another example of the use for this API is in a device which may have multiple different data interfaces - possibly multiple wireless data interfaces (GPRS, WiFi, WiMax) along with occasional wired interfaces (USB to a PC). Today?s platforms provide no means for an application to specify which interface should be used for a connection, yet some destinations cannot be reached through all interfaces, or the cost of using an interface may be prohibitive. This JSR will also provide standard Java APIs so that mobile and embedded Java applications can be developed that are intrinsically aware of and take advantage of the mobile network(s) and capabilities available. Behavior of applications may be different based on the networks which are available ? for example, if operating in a high-speed WLAN environment, an application may be able to support a streaming video telephony service, but this is not well supported in a cellular environment. Other applications may only be able to operate on particular networks ? such as an enterprise sales application which can only operate while the device is attached to the enterprise network. Applications can determine how best to provide an experience to the user based on the networks, network types and network capabilities which are present. 2.6 Why isn't this need met by existing specifications?There are currently no specifications that cover the controlling of data sessions in a mobile device environment. While the Java ME specifications provide for generic data connectivity (Connection, HTTPConnection), this does not describe some of the parameter controls which are specific to the mobile environment, such as requesting and responding to changes in QoS, selecting which APN to attach to or discovery of the capabilities of the underlying network and interface. While many applications are able to operate with the default provisioning that is offered in existing platforms, there are applications (particularly applications involved in streaming or two-way media) which need stricter control over how the session is configured. There also exists little information for use by applications about the cause of the failure to open a connection - there may be no transport available, or the user may not be subscribed to a data service. Since there is no mechanism to request a particular minimum bandwidth, there is also no mechanism available today to provide a notification when the session is going to be dropping below that bandwidth. These can be useful information to allow the application to best serve the user by changing how it operates, or providing meaningful information back to the user. The existing Java ME connection framework, for establishing data connections, does not provide for a means to request a particular session bandwidth, nor are there any provisions to modify session bandwidth or learn of changes in the bandwidth. The APIs defined by this specification would extend the existing connection framework interfaces, as well as CDC socket interfaces, to include the additional QoS request and monitoring capabilities. Some work is being planned in MIDP3 to address static application configurations - specify what an application needs for bandwidth or connection limitations. The proposed JSR is intended to complement the MIDP3 configuration by offering dynamic configuration - for cases where the bandwidth required for a session depends on the content that is being carried in a session, and may not be the same from session to session. MIDP3 may also add some interfaces to allow an application to learn what transports are available, so that an application can discover if conditions may be right to use a default connection. This API provides the notification mechanisms and abilities to specify a session on a particular transport and with a particular QoS configuration. JSR 281 (IMS) is planning to define within their API some controls to establish the QoS required for an IMS session. The proposed JSR will work with the JSR 281 Expert Group to ensure that the API which is developed is consistent between the two JSRs. This proposed JSR and JSR 281 will be able to co-exist on a device, with minimal overlap of implementation - both will be based from the same interface. We feel that there is value in having a separate data session control API, aside from the interfaces being defined in JSR 281, to allow for use in non-IMS/SIP devices and in a wider range of data sessions. There are also currently no specifications that cover the management of mobile network connections or the behavior of devices within the network. This aspect of mobility management was dropped from JSR 253 because the mobility preferences impact more than just voice telephony features (affecting also data and messaging connections). Management of a network preferred list, as well as a network blacklist, may be useful beyond the cellular domain, as there are also network preferences that can be used for wireless LAN and other mobile wireless networks. Some support for controlling the mobility of a device can be found in the existing JTAPI javax.telephony.mobile package. This existing interface also contains some operations which have been incorporated into the JSR253 specification - along with device information. The .mobile package only provides means to obtain the current preferred lists, not to modify that list. There are also no interfaces provided to manage preferences for one transport over another. This proposed mobility JSR seeks to cover this expanded scope. Some of the information (such as current network) can also be obtained through the Device Management API JSR246. Specification and standardization of the entries in the tree for this information is presently ongoing, and will be reused as much as possible. This JSR will define a function based set of interfaces to be used in the absence of a JSR 246 implementation. In cases where JSR246 is implemented, consistent information will be available through both interfaces. This proposal includes several network and transport selection use-cases which were originally within JSR-271 (MIDP3). JSR271 will continue to provide a mechanism for applications to specify a limited set of preferences (such as preferring a particular GPRS APN). The names for these static parameters will be consistent with the use in the new API for dynamically configuring a session with those new parameters, along with additional attributes. 2.7 Please give a short description of the underlying technology or technologies:Mobile devices are increasingly being introduced with the capability to connect to multiple networks for both voice and data services. The following mobile networks and connection types are likely candidates for Java APIs for Mobility implementation.
- CDMA/CDMA 1xRTT/CDMA EV-DO - WiFi (802.11a/b/g/n, both infrastructure and ad-hoc modes, including .11e QoS extensions) - Bluetooth (through the LAN access profile) - WiMAX (802.16e) - Wired data networking (such as through USB or Ethernet)
Likely types of operations:
- Discover the available configurations for a data transport (bandwidth, expected latency) - Provide notifications of changes (positive and negative) in the available bandwidth in a session, as well as notifications of when a session is forcibly closed by the implementation.
Mobility and network selection:
- Get available networks for a transport - Get/set preferred networks for a transport - Get/set preferred transport for a feature/application - Register to a particular network - Activate/deactivate a particular transport This specification may separate the control of a data session, or link to the network, from the establishment of a particular connection or socket which uses that link. Multiple applications may use a single data sessions, if their needs are compatible. This API is intended for fine control of session attributes in a dynamic manner. Static session attributes will be handled through interaction with the MIDP3 expert group. Security permissions will be used to control access to this API, as well as the ability to specify higher quality (and more expensive) sessions. In some situations there are multiple networks available (either multiple cellular systems to select from, or multiple wireless LAN systems to select from), and other times the device may have multiple network connections that it can select from (such as selecting between a cellular or WLAN network for data operations). Particular applications may have preferences for how the device should attach to networks based on the available networks - including not considering particular networks to be valid. Network restrictions may be imposed on a device-wide basis (such as preferring certain cellular networks for roaming) or on an application basis (a particular application prefers to use WLAN, and will seek to get the device onto any WLAN to perform its operations). Some mechanism is provided within the device to select what network should be active. The selection may be modifiable by applications, to better suit the needs of a particular application while it is in use, vs. the general "preference" for the device. Some of the feature-specific preference objects are expected to be instantiated from the API objects for that feature - for example, the JSR253 class javax.microedition.telephony.NetworkStatus would be an instantiation of a general mobility NetworkStatus object defined in this JSR, but the JSR253 object only returns the status of settings and networks related to the telephony features. A similar object may be created for the data features. There is a close relation between the activities in this proposed JSR and those in the existing JSR253 specification (and the work planned in a follow-up JSR). While the two interfaces are largely independent (concerning different aspects of using and controlling the wireless connection) because both are affecting the same connectivity interface there will be some interaction between the expert groups for the telephony and mobility JSRs. 2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)javax.microedition.mobiledata.* 2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?No 2.10 Are there any security issues that cannot be addressed by the current security model?No 2.11 Are there any internationalization or localization issues?No 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.The targeted schedule for the JSR is as follows: 2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.The Expert Group will conduct its work via weekly conference calls, email lists, and web sites. In addition, periodic face-to-face meetings will be held approximately every 6-8 weeks, and phone conferences as needed for special issues that need to be resolved between meetings. Decisions will be made by technical consensus. 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.Transparency plan: 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.An independent RI and TCK will be produced as a part of this JSR with each being licensed separately. 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).N/A 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 are initial commercial terms to be used and remain subject to the execution of final legal agreements covering the subject matter hereof. The RI and TCK will be developed and licensed under an open-source license. The actual license to be used will be determined prior to Early Draft Review. 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.For GSM and UMTS, the ability to control the selection of networks, request a particular network and request a new network are described in 3GPP specifications 22.011 and 23.122. These features include:
- Ability to request phone scan for and register on a new network (with no user interaction). - "Manual mode", where the phone presents the list of available networks and the user must choose which network to register to. - The ability to obtain a list of available networks and display this to the user. Some of these capabilities for use by applications external to the phone are described in 3GPP specification 27.007 ? in particular the commands +CREG (network registration), +COPS (PLMN network selection), +CPOL (preferred list), +CPLS (selection of preferred list) and +COPN (read network names). Earlier drafts of JSR253 also included a set of interfaces related to network selection and availability controls. 3GPP 24.007 - contains GPRS session establishment commands and messages at a high level between the stack and applications, which is a level similar to planned for this JSR. (Additional messages are defined in 24.008, which are the actual messages exchanged with the network.) 3GPP 27.007 - contains existing AT based interfaces for session control ( http://www.3gpp.org) 3.2 Explanation of how these items might be used as a starting point for the work.The existing operations found in phones today will be used as a requirements basis - at least the currently available operations will be made available to Java applications. Operations and functionality which are defined for these network interfaces will be used as a starting point for requirements, and may influence how the API methods are defined. This API is expected to build on the Generic Connection Framework found in JavaME. All MobileData interfaces will derive from either the Connection or Socket objects (based on the class of VM) and add control-plane interfaces only - the data plane interfaces will remain fully compatible with existing interfaces. Section 4: Additional Information (Optional)
4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||
