UMB AIS Document Structure

Ravi Patwardhan, Qualcomm

ravindra@qualcomm.com

QUALCOMM Incorporated 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. QUALCOMM Incorporated 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 QUALCOMM Incorporated 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 QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

December 2007 2

Proposed Structure

Either create addendum or create new documentAddendum – Bug fixesNew document – New Features

New protocol types, or new protocol subtypes

Never create “Revision” of a documentOverview document common across all

UMB documents

December 2007 3

Document Numbering

UMB AIS documents are created as parts of C.S0084. e.g. C.S0084-001 is UMB Physical Layer

3 Digit part number allows up to 1000 parts Continue to use new part numbers for new

documents Numbering structure for part numbering can be

created for ease of finding documents. E.g. Parts 010-019: New physical layer documents Parts 020-029: New MAC layer documents Parts 030-039: New RLL documents And so on…

December 2007 4

Overview document

Current Overview document (000) has 2 distinct parts Text common to all parts (e.g. Architecture, Common data

structures and procedures etc.) Assigned numbers (e.g. Protocol Type, Protocol Subtype,

IPSI, PSI etc.) Split overview documents in to 2 documents

Text common to all parts remain as part 000 Create only addendums as needed

Assigned numbers to be in new document (part 999) Exception: Create Revisions for this document as needed. Never

create addendums for this document Similar to C.R1001 document used for 1x/HRPD

December 2007 5

Overview (cont…)

Assigned number document (part 999)Updated periodically to list all assigned

numbersE.g. Include new IPSI, PSI, ProtocolType and

ProtocolSubtype as necessaryGood place to link all documents

Add listing of C.S0084 partsAs new parts are defined, the list gets updated

December 2007 6

Advantage of proposed structure

Each protocol (Type, Subtype) pair is defined only in one place Following issues related to “Revisions” are avoided

When revision is created, text for (Type, Subtype) pair is defined at multiple places. E.g. If x=(Type, Subtype) defined in Rev 0, then x is specified in Rev 0, Rev A, Rev B etc.

When any bug is found, needs to be corrected at multiple places

Creates more work Typically all versions are not open for edit at same time. So

creates inconsistent text, and may create confusion Need to carefully track bugs fixed in one revision, and fix

them in other revisions at appropriate time. This is very tedious, time consuming and error prone task.

December 2007 7

Advantages (cont…)

Document structure reflects design philosophyEach Protocol Type can evolve

independentlyNot necessary to enhance multiple Protocol

Types in group. Instead based on new features, required Protocol Types can be enhanced.

December 2007 8

Evolution in 3GPP2 AIS

Design Concept in 3GPP2 AIS has evolved over time 1x – Set of features bundled as “Protocol Revision”

Difficult for operator to “pick and choose” features HRPD – Each Protocol Type evolves independently. AN and

AT negotiate in-use subtypes Negotiations always starts from Rev 0 Valid combinations of subtypes not defined in specification

UMB – IPSI/PSI Each PSI defines a valid subtype combination

PSI list in UMB provides list of all valid subtype combinations Enable starting negotiation from multiple start points.

Protocol subtypes not negotiated. Personality is always based on one of the PSI defined in UMB.

December 2007 9

Evolution in 3GPP2 AIS (Cont…)

Evolution in document structure 1x – New features defined as new revision

Some features were defined in separate document (SMS, OTASP, Position Location etc.)

HRPD – New features defined either as new document or as new revision

New document used for new Protocol Types or subtypes New revision used when multiple Protocols were updated

Next step: UMB Learn from 1x, HRPD experience

Create new document for new features Create Addendum for bug-fixes