The change control cycle Or Where little 3GPP specifications come from …

17 May 2002 John M Meredith ETSI-MCC 2 Who goes there? This presentation is based on the Change Control mechanism originally devised by CEPT GSM, adopted and improved by ETSI SMG, and now in use by the Technical Specification Groups of 3GPP. It has also been adopted and adapted to varying degrees by other Technical Bodies within ETSI.

17 May 2002 John M Meredith ETSI-MCC 3 First there was the brilliant idea … … then came the outline of a system specification, in very general terms.

17 May 2002 John M Meredith ETSI-MCC 4 Feature 1 specFeature 2 specFeature 3 spec Traditional systems analysis and project management techniques break the idea down into progressively more manageable elements.

17 May 2002 John M Meredith ETSI-MCC 5 Until it is possible to identify individual component specifications.

17 May 2002 John M Meredith ETSI-MCC 6 A specification starts its life in much the same way as any other … scribble scribble scribble scribble Based on discussions in the working group, a rapporteur volunteers to produce an initial draft. He uses the standard document skeleton and Word © template. He obtains the number from the Support Team (MCC).

17 May 2002 John M Meredith ETSI-MCC 7 The rapporteur issues the specification as version Release field Technical field Editorial field

17 May 2002 John M Meredith ETSI-MCC 8 Editorial field The Editorial field of the version number is incremented each time an editorial change is made to the document. It is reset to zero every time the Technical field is updated. The version number x.y.zx.y.z

17 May 2002 John M Meredith ETSI-MCC 9 Technical field The Technical field of the version number is incremented each time a technical change is made to the document. It is reset to zero every time the Release field is updated. The version number x.y.zx.y.z

17 May 2002 John M Meredith ETSI-MCC 10 Release field The Release field of the version number is incremented each time major new functionality is made to the system (rather than to the individual document). The version number x.y.zx.y.z

17 May 2002 John M Meredith ETSI-MCC 11 v0.0.0 The version number Evolution of the version number of a specification… v0.0.1 v0.0.2 v0.1.0 v0.1.1 v0.2.0 v0.3.0 v1.0.0 v1.1.0 v1.2.0 v2.0.0 v3.0.0 v3.1.0 v3.2.0

17 May 2002 John M Meredith ETSI-MCC 12 The drafting process The initial draft is discussed in the working group. v0.0.0 v0.1.0 And a new draft is produced, bearing technical changes.

17 May 2002 John M Meredith ETSI-MCC 13 v0.1.0v0.2.0v0.3.0 … The process is iterative, until … The drafting process

17 May 2002 John M Meredith ETSI-MCC 14 v0.8.0 … the working group is happy with the draft. Note that the draft may not be complete, merely acceptable to be aired in a wider forum. As a guideline, the draft should be at least 50% complete to be raised to version The drafting process

17 May 2002 John M Meredith ETSI-MCC 15 v0.8.0 The drafting process When the draft is “ready”, it is upgraded to version v1.0.0 Note that v1.0.0 is technically identical to the previous 0.y.z document.

17 May 2002 John M Meredith ETSI-MCC 16 v1.0.0 It is at this stage that the Support Team (MCC assisted by ETSI SMS-EDM) should clean up the draft to ensure that it is laid out correctly and abides by the drafting rules 3GPP TR There is seldom opportunity to do this later on! The drafting process

17 May 2002 John M Meredith ETSI-MCC 17 v1.0.0 Draft is presented for information to the plenary TSG (Technical Body). The drafting process

17 May 2002 John M Meredith ETSI-MCC 18 v1.0.0v1.1.0v1.2.0 … The document returns to the working group, and drafting continues until … The drafting process

17 May 2002 John M Meredith ETSI-MCC 19 v1.5.0 … the working group believes the draft to be stable enough to come under formal “change control”. Note that the draft may still not be complete, merely ready to come under formal change control. As a guideline, the draft should be at least 80% complete to be raised to version The drafting process

17 May 2002 John M Meredith ETSI-MCC 20 v1.5.0 The drafting process When the draft is “ready”, it is upgraded to version v2.0.0 Note that v2.0.0 is technically identical to the previous 1.y.z document.

17 May 2002 John M Meredith ETSI-MCC 21 v2.0.0 If necessary, the Support Team should again clean up the draft to ensure that abides by the drafting rules 3GPP TR The drafting process

17 May 2002 John M Meredith ETSI-MCC 22 v2.0.0 Draft is presented for approval to the plenary TSG (Technical Body). The drafting process

17 May 2002 John M Meredith ETSI-MCC 23 v2.0.0v2.1.0v2.2.0 … If the TSG does not approve the draft, it may return to the working group for further refinement. This is exceptional. The drafting process

17 May 2002 John M Meredith ETSI-MCC 24 v2.3.0 The drafting process When the draft is approved to come under change control, it is upgraded to version (assuming Release 1999 – see later). v3.0.0 Note that v3.0.0 is technically identical to the previous 2.y.z document.

17 May 2002 John M Meredith ETSI-MCC 25 Change Control The “system” is composed of a coherent set of related specifications. For technical and commercial reasons, it may be desirable to divide the standardization process into a number of discrete phases or “Releases”.

17 May 2002 John M Meredith ETSI-MCC 26 Once a specification has come under change control, the working group and the rapporteur no longer have the right to update the specification. Change Control

17 May 2002 John M Meredith ETSI-MCC 27 Change Control But it is still possible to develop the standard further, to add the missing parts, and to correct errors and omissions as the overall system becomes better defined.

17 May 2002 John M Meredith ETSI-MCC 28 Change Control Consider an individual standard … v3.0.0 If the responsible working group wishes to make a change to it, however small, …

17 May 2002 John M Meredith ETSI-MCC 29 v3.0.0 Change Control … the working group must raise a Change Request. The CR consists of a cover page … … and an extract from the specification under consideration showing, using revision marks, all additions and deletions. Several iterations of a CR may be required until the WG is happy with it.

17 May 2002 John M Meredith ETSI-MCC 30 For example, a CR to TS may be twice revised during the course of discussions in the WG before it is agreed. Change Control CR 4 to CR 4 rev 1 to CR 4 rev 2 to

17 May 2002 John M Meredith ETSI-MCC 31 Change Control CR 4 rev 2 to CR 5 rev 1 to CR 6 to All CRs against a given specification (or a given work item) are gathered together by the Support Team * prior to each TSG plenary. A single temp doc is created, with a cover page introducing each individual CR. * In practice, by the Secretary of the WG responsible for the spec.

17 May 2002 John M Meredith ETSI-MCC 32 CR 4 rev 2 to CR 5 rev 1 to CR 6 to Change Control The CRs are presented to the plenary TSG for approval. Presentation is the responsibility of the WG Chairman, assisted by the Secretary.

17 May 2002 John M Meredith ETSI-MCC 33 CR 4 rev 2 to CR 5 rev 1 to CR 6 to Change Control The TSG examines each CR and approves or rejects each. Some CRs may be reworked during the TSG meeting and re- presented (with a new revision number).

17 May 2002 John M Meredith ETSI-MCC 34 CR 4 rev 2 to CR 5 rev 1 to Change Control The Support Team (MCC) incorporates the approved CRs into the base specification … v3.0.0v3.1.0

17 May 2002 John M Meredith ETSI-MCC 35 v3.1.0 Change Control The new specification version is then made available on the file server - for delegates to propose more changes!

17 May 2002 John M Meredith ETSI-MCC 36 v3.1.0v3.2.0v3.3.0 … The controlled revision of specifications can continue in the same manner, with CRs being produced and approved. CRs allow full traceability of the changes wrought on a document since its original approval. Change Control

17 May 2002 John M Meredith ETSI-MCC 37 Change Control A complete set of specifications including the approved CRs is made available on the file server after each plenary meeting. Equipment supply contracts will typically require equipment designed to a particular set of specifications – e.g. the set resulting from the June 2000 plenary meeting.

17 May 2002 John M Meredith ETSI-MCC 38 Change Control Using the Change Control mechanism described, it is always possible to: See the differences from one version of a spec to the next. If necessary, back-track by de-implementing Change Requests which prove to be flawed. Know exactly what set of specifications a system is to be built to.

17 May 2002 John M Meredith ETSI-MCC 39 CRs are registered in a database maintained by the Support Team. Change Control

17 May 2002 John M Meredith ETSI-MCC 40 Change Control The initial “system” is composed of a coherent set of related standards. All these standards have version numbers of the form 3.y.z and are known as Release1999. Eventually, Release 1999 became stable. The specifications were “frozen”.

17 May 2002 John M Meredith ETSI-MCC 41 Change Control Once frozen, no more functionality may be added to a specification. Only essential corrections are permitted. It is accepted that test specifications and O&M specifications may not be frozen until some time – perhaps one year – after the base requirements specifications are frozen.

17 May 2002 John M Meredith ETSI-MCC 42 At this point, the specifications can be published by the 3GPP Partner Organizations which are SDOs (Standards Development Organizations). v3.3.0 For rapidity of production and maintenance, ETSI publishes the 3GPP documents as ETSI TSs and ETSI TRs as appropriate.

17 May 2002 John M Meredith ETSI-MCC 43 Warning: once a release is frozen, and SDO deliverables are produced, any change to the base specification will entail the production of an equivalent replacement SDO deliverable. v3.3.0v3.4.0

17 May 2002 John M Meredith ETSI-MCC 44 Change Control It is now possible to add further functionality in carefully designed features forming part of a new “Release”. Feature 1 specFeature 2 specFeature 3 spec

17 May 2002 John M Meredith ETSI-MCC 45 Change Control Using established methods of functional decomposition of the features into smaller elements... Feature 1 specFeature 2 specFeature 3 spec

17 May 2002 John M Meredith ETSI-MCC 46 Change Control … it is possible to raise Change Requests to each specification to include the new functionality. v3.3.0

17 May 2002 John M Meredith ETSI-MCC 47 v3.3.0v4.0.0v4.1.0 … The addition of the new features to the system implies an upgrade to the next “Release” of the entire system specification. Change Control

17 May 2002 John M Meredith ETSI-MCC 48 Change Control New functionality may equally result in an entirely new specification rather than a change to an existing one. v0.0.0  v1.0.0   v4.0.0

17 May 2002 John M Meredith ETSI-MCC 49 Release 1999Release 4 The result, in due course, is two complete sets of specifications: one for each Release. Implementors (operators and equipment vendors) can choose which Release to build their systems to. Generally, newer Releases will be richer in features, but less tried and tested.

17 May 2002 John M Meredith ETSI-MCC 50 A disadvantage of the “release” approach … Release 1999Release 4 An error discovered here …

17 May 2002 John M Meredith ETSI-MCC 51 Release 3Release 4 … may require not one CR but two to fix it …

17 May 2002 John M Meredith ETSI-MCC 52 Release 3Release 4 … because the same error may have been inherited from the earlier Release!

17 May 2002 John M Meredith ETSI-MCC 53 The version number evolution for parallel evolution of releases v1.2.0 v2.0.0 v3.0.0 v3.1.0 v3.2.0 v3.3.0 v4.0.0 v4.1.0 v4.1.1v3.3.1 v4.2.0v3.4.0 v5.0.0 v5.1.0v4.3.0v3.5.0 v5.2.0 Note that maintaining several parallel releases of the same specification implies very well defined procedures and highly disciplined handling !! Release 1999 frozen Correction to Release 1999 Upgrade to next Release Refinement of features Essential corrections

17 May 2002 John M Meredith ETSI-MCC 54 A change control system along the lines described has enabled the GSM specifications to have undergone six controlled releases over six years, and has allowed a smooth transition from GSM (second generation digital mobile communications) to UMTS (third generation), re-using as many of the basic elements as possible. Further Releases of the UMTS specification are now under way within 3GPP, and the GSM platform continues to run in parallel.

17 May 2002 John M Meredith ETSI-MCC 55 end