The change control cycle Or Where little 3GPP specifications come

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

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 2

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 3

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

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

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 6

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

The version number Editorial field x.y.z 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. 17 May 2002 John M Meredith ETSI-MCC 8

The version number Technical field x.y.z 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. 17 May 2002 John M Meredith ETSI-MCC 9

The version number Release field x.y.z 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). 17 May 2002 John M Meredith ETSI-MCC 10

The version number Evolution of the version number of a specification 17 May 2002 v0.0.0 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 John M Meredith ETSI-MCC 11

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

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

The drafting process 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 1.0.0. 17 May 2002 John M Meredith ETSI-MCC 14

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

The drafting process 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 21.801. There is seldom opportunity to do this later on! v1.0.0 17 May 2002 John M Meredith ETSI-MCC 16

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

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

The drafting process 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 2.0.0. 17 May 2002 John M Meredith ETSI-MCC 19

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

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

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

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

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

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 25

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

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 27

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 28

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. v3.0.0 Several iterations of a CR may be required until the WG is happy with it. 17 May 2002 John M Meredith ETSI-MCC 29

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

Change Control 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. CR 4 rev 2 to 23.456 17 May 2002 CR 5 rev 1 to 23.456 John M Meredith ETSI-MCC CR 6 to 23.456 * In practice, by the Secretary of the WG responsible for the spec. 31

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

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

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

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 v3.1.0 35

Change Control v3.1.0 v3.2.0 v3.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. 17 May 2002 John M Meredith ETSI-MCC 36

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 37

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 38

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

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 40

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 41

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 42

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.0 v3.4.0 17 May 2002 John M Meredith ETSI-MCC 43

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

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

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 46

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

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 2.0.0 17 May 2002 v4.0.0 John M Meredith ETSI-MCC 48

Release 1999 Release 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 49

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

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

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

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 v3.3.1 v4.1.1 v3.4.0 v4.2.0 Release 1999 frozen Correction to Release Correction 1999 to Release 1999 Upgrade to next Release Refinement of features Essential corrections v5.0.0 v3.5.0 v4.3.0 v5.1.0 v5.2.0 17 May 2002 John M Meredith ETSI-MCC Note that maintaining several parallel releases of the same specification implies very well defined procedures and highly disciplined handling !! 53

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 54

end 17 May 2002 John M Meredith ETSI-MCC 55