1. 1 7 December 2009 X00-20091207-xxx Subject:Liaison Report from BBF Meeting 2009.11.30, Budapest Date: 7 December 2009 Source: Doug Knisely TSG-X FMOAHG Co-chair, BBF Liaison Contact: dknisely@airvana.com cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Airvana, Inc., grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner's name any Organizational Partner's standards publication even though it may include all or portions of this contribution; and at the Organizational Partner's sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner's standards publication. Airvana, Inc., is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by Airvana, Inc., to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on Airvana, Inc. Airvana, Inc., specifically reserves the right to amend or modify the material contained herein and to any intellectual property of Airvana, Inc.,other than provided in the copyright statement above.

2. 2 Overview Quick summary of SC decisions relative to TSG-X, FMOAHG Feedback from BBF regarding preview MO spreadsheet  High level summary  Specific comments 7 December 2009 X00-20091207-xxx

3. 3 SC Directions Regarding FMO Work Continue with less formal TSG-X BBF BBHome liaison relationship TSG-X will develop liaison working agreement (3GPP SA5 is doing the same) Hold all joint discussions between 3GPP2 and BBF as open calls  Not conducted under working procedures of either organization  Similar to “workshops” with open invitation in the industry announced through both organizations  Implications: » No IPR policies, etc., will be in place » Companies should consider all contributions to be public presentations » Joint calls/meetings would focus primarily on work management and coordination and not technical discussions Technical inputs to BBF will continue to be via member company contributions Document sharing will be negotiated on a case-by-case basis (only a problem when sharing BBF drafts in 3GPP2  In rare cases, may need to work out a private location on 3GPP2 meeting server that does not become part of public website (3GPP SA5’s tentative solution) No action requested from SC or partners at this time 7 December 2009 X00-20091207-xxx

4. 4 General Comments from BBF Presentation BBHome appreciates the preview copy Spent roughly 90 minutes walking through basic structure in BBHome General comments that were addressed satisfactorily:  “Seems to be a lot of new stuff”  “Do we really need all those stats” Several BBHome TR-069/TR-196 experts reviewed the spreadsheet and provided a number of useful comments (see subsequent slides) Previously proposed schedule was reviewed; seems to be concurrence that we are on schedule and the schedule is credible Proposed “public” calls to coordinate schedule, workplan are agreeable Does not seem to be any need for further coordination until January or February Next milestone is to provide first informal preview of XML object ~end of January 7 December 2009 X00-20091207-xxx

5. 5 Issues (None Serious) Coordinate TR-196 Amendment 1 schedule with 3GPP inputs (3GPP is not as far along as 3GPP2 and they have not provided any technical inputs, so BBHome members are concerned) Better training in XML generation; resources and help provided offline Need to identify BBHome (co-)editor for TR-196 Amendment 1 7 December 2009 X00-20091207-xxx

6. 6 Recommendations FYI for TSG-X Remand to FMOAHG for action on specific comments 7 December 2009 X00-20091207-xxx

7. 7 Specific Comments (Relative to X00-20090918-001R1) 31 March 2008 3GPP2 TSG-C WG2

8. 8 Specific Comments from BBF (1) General comment: separate out the new proposed attributes vs. modifications of existing TR-098 or TR-196 attributes General comment: attribute names should begin with a capital letter unless there is a very compelling reason otherwise 17 – ManufacturerOUI – Not recommended to be added to TR-106; recommend moving to cdma2000-specific MO 33 – LeapSecond – Move to FAPService if we really need this 34 – DaylightSavingsUsed – Do we really need this semantically separate from the TR-106 POSIX-compatible base time? If so, move to FAPService 44 – “.FAPService.{i}.Capabilities.cdma2000.” -- How important is it to have the leading lower case “c” in cdma2000? Prefer Cdma2000 or CDMA2000 47 – “.FAPService.{i}.Capabilities.cdma2000.1x.” – Object/Attributes cannot begin with a numeral 7 December 2009 X00-20091207-xxx

9. 9 Specific Comments from BBF (2) 65, 66, etc. – AdminState, OpState – Since these are needed per RF technology, consider obsoleting from the base class (would require 3GPP buy- in) 68 – Daylight – What is relationship to 34? Does this overload 34? 97 – AccessMode – TR-196 base version already defines Open, Closed, and Hybrid. We should either define “Hybrid” for cdma2000, or add a 4 th value for “Signaling Association” if it is really different 104 – IMSI in ACL – IMSI is currently defined as a unique key, but probably won’t be in our ACL (can’t change that retroactively). This may require us to create a separate ACL object rather than just adding to.FAPService.{i}.AccessMgmt.MemberDetail.{i}. 7 December 2009 X00-20091207-xxx

10. 10 Specific Comments from BBF (3) 289 -.FAPService.{i}.CellConfig.cdma2000.1x.BatchPcfPDSN.{i}. -- ACS may not be able to control the value of {i} when it creates the instances. Our description that says “The order of the address is used as part of PDSN selection algorithm, e.g., the first element is considered PDSN number 0. (Refer to A.S0013).” may not be semantically viable. Note that this is not a problem for.FAPService.{i}.CellConfig.cdma2000.1x.PcfPDSN.{i}. since we define a PDSN selection algorithm index field. 641 --.FAPservice.{i}.Transport.SIP.FCS – Consider either re-using TR-104 SIP object (Note: unlikely since the TR-104 object is for a generic SIP VoIP object, not for IMS.) or at least re-using the same attribute names and descriptions when they seem to be identical 643 – OutGoingProxyUri – Should we define a separate URI for the RegistrarServer attribute (which is semantically typical for SIP provisioning) 643 – OutGoingProxyUri – Should we include Transport Protocol attributes for OutGoingProxyUri (and RegistrarServerUri), similar to TR-104 SIP object, even if the transport protocol is fixed for cdma2000 1x FAP usage? 7 December 2009 X00-20091207-xxx

11. 11 Specific Comments from BBF (4) 770 --.FAPService.{i}.LoggingConfig, etc. -- Can we re-use the generic RPC for file upload with a Log, Debug, etc. format? Seems to be semantically equivalent to what we desire. 7 December 2009 X00-20091207-xxx