TSG-S OMA (Open Mobile Alliance) Ad-Hoc Report Richard Robinson Chair - 3GPP2 TSG-S SC D

Page 1 SC D Contents TSG-S OMA Ad Hoc Creation Benefit-Risk Analysis TSG-S OMA Ad-Hoc Agreements Potential Type of Relationship List of Potential Services and Applications for Collaboration Possible Next Steps

Page 2 SC D Ad-Hoc Creation TSG-S created OMA Ad-Hoc as a result of many drivers: u Individual company requests to move work to OMA u Benefit & Risk assessment needed in order to consider relationship u Processes need to be identified necessary if OMA-3GPP2 established u Need to determine how to respond to recent OMA requests  SC B  Letter from OMA Technical Plenary Chair to TSG-S and TSG-SA on technical cooperation  SC C  correspondence from OMA Requirements WG Chair on potential meeting of requirements WGs from TSG-S, TSG-SA, OMA in San Diego in May 2003 The following pages reflect discussion of the TSG-S OMA Ad-Hoc  Several face-to-face meetings and teleconferences  Thanks to Ad-Hoc Chair Donnie Townsend and Ad-Hoc members

Page 3 SC D Benefits - Relationship with OMA u 3GPP2 might choose to utilize the resources within OMA to create specifications for:  Services  Applications u 3GPP2 might choose to readily adopt OMA specifications u OMA may provide service interoperability between 3GPP2 & 3GPP MMD (3GPP2) IMS (3GPP) OMA Application Similar OSA Gateways

Page 4 SC D Benefits continued Workload resource for 3GPP2 u Depending on the amount of Work Items scheduled for a given 3GPP2 release, it may be advantageous to request application development or adopt OMA specifications Desired 3GPP2 Release Content 100% Capacity of TSGs OMA Capacity

Page 5 SC D Risks - Relationship with OMA As identified by Ad-Hoc: Potential 3GPP2 risks from a relationship with OMA include: u Loss of control over schedule u Solution not as optimized for CDMA networks as would be if developed within 3GPP2 u OMA product not meeting 3GPP2 requirements u Lack of understanding of 3GPP2 requirements by OMA u Loss of control of solution u Solution may be driven by existing legacy solutions

Page 6 SC D TSG-S OMA Ad-Hoc Agreements u 3GPP2 does need to have some type of relationship with OMA although the specifics of that relationship still need to be defined. u Many companies recommend that 3GPP2 must insist on equal priority for 3GPP and 3GPP2 requirements and on equal priority for support of 3GPP and 3GPP2 architectures as two (2) non- negotiable platforms for all OMA processes and procedures. u TSG-S would be authorized to communicate directly with OMA Requirements groups including full authorization to transfer, monitor, and approve requirements development activity to OMA on a case- by-case basis. u In the near-term, 3GPP2 should consider adopting OMA solutions on a case-by-case basis but maintaining control of our own Stage 1 development activities.

Page 7 SC D List of Potential Services & Applications for Collaboration Ad-Hoc members agreed - in all instances, collaboration with, or adoption of, OMA work is on a case-by-case basis Potential work items to collaborate with OMA (i.e., 3GPP2 developed stage 1 - OMA develops stage 2-3) u Immediate Messaging u others Potential OMA work items that 3GPP2 could adopt u Digital Rights Management u Content Download u Device Management

Page 8 SC D Potential 3GPP2-OMA Relationship Considerations Liaison u TSG-S submit service and application requirements and requests to OMA u Consider adoption of OMA standards u Joint meetings as necessary u 3GPP2 interests may also be represented by 3GPP2 members who attend OMA  3GPP2 positions must be representative of approved 3GPP2 documents u Fall back position if OMA product does not meet requirements (3GPP2 may pick up the work with possible schedule impact) u IETF RFC-3131 (3GPP2-IETF Relationship Doc) could be considered as a model to address some of the issues in the relationship

Page 9 SC D Potential 3GPP2 Processes 3GPP2 TSG-S PMT would likely need to develop procedures to execute the relationship u Move existing and new project work to OMA recognizing that 3GPP2 TSGs may also develop part of the service or application in some cases u Develop a means to track work to be developed within OMA  Schedule requirements  Content requirements u Develop the capability to adopt OMA standards on a case-by-case basis

Page 10 SC D Possible Next Steps Develop appropriate agreement with OMA? Authorize TSG-S PMT as Liaison to execute such agreement? Direct TSG-S PMT to develop appropriate processes? u Process to decide which work items to be moved to OMA u Process for requirements (Stage 1) input to OMA u Tracking of schedule and content which meet 3GPP2 needs u Inventory OMA work items for potential adoption u Process for adoption of OMA products