2. The change control cycle Or Where little 3GPP specifications come from … Move to next slide.

3. 02 December 2015 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. Move to next slide.

4. 02 December 2015 John M Meredith ETSI-MCC 3 This presentation shows its current use within 3GPP. Note: Some of the hyperlinks within this presentation are only accessible to Support Team members with access to the MCC intranet. Please do NOT report broken link errors! Move to next slide.

5. 02 December 2015 John M Meredith ETSI-MCC 4 First there was the brilliant idea … … then came the outline of a system specification, in very general terms. Move to next slide.

6. 02 December 2015 John M Meredith ETSI-MCC 5 Feature 1 specFeature 2 specFeature 3 spec Traditional systems analysis and project management techniques break the idea down into progressively more manageable elements. Move to next slide.

7. 02 December 2015 John M Meredith ETSI-MCC 6 Until it is possible to identify individual component specifications. Move to next slide.

8. 02 December 2015 John M Meredith ETSI-MCC 7 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). (Click here for more details on the number allocation process.) (Click here for more details on the number allocation process.) Move to next slide.

9. 02 December 2015 John M Meredith ETSI-MCC 8 The rapporteur issues the specification as version 0.0.0 Release field Technical field Editorial field Move to next slide.

10. 02 December 2015 John M Meredith ETSI-MCC 9 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 Move to next slide.

11. 02 December 2015 John M Meredith ETSI-MCC 10 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 Move to next slide.

12. 02 December 2015 John M Meredith ETSI-MCC 11 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 Move to next slide.

13. 02 December 2015 John M Meredith ETSI-MCC 12 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 Move to next slide.

14. 02 December 2015 John M Meredith ETSI-MCC 13 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. Move to next slide.

15. 02 December 2015 John M Meredith ETSI-MCC 14 v0.1.0v0.2.0v0.3.0 … The process is iterative, until … The drafting process Move to next slide.

16. 02 December 2015 John M Meredith ETSI-MCC 15 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. The drafting process Move to next slide.

17. 02 December 2015 John M Meredith ETSI-MCC 16 v0.8.0 The drafting process When the draft is “ready”, it is upgraded to version 1.0.0. v1.0.0 Note that v1.0.0 is technically identical to the previous 0.y.z document. Move to next slide.

18. 02 December 2015 John M Meredith ETSI-MCC 17 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 21.801. (The latest version of 21.801 can be found via the most recent specs status list.) (The latest version of 21.801 can be found via the most recent specs status list.) There is seldom opportunity to do this later on! The drafting process Move to next slide.

19. 02 December 2015 John M Meredith ETSI-MCC 18 v1.0.0 Draft 1.0.0 is presented for information to the plenary TSG (Technical Body). The drafting process Move to next slide.

20. 02 December 2015 John M Meredith ETSI-MCC 19 v1.0.0v1.1.0v1.2.0 … The document returns to the working group, and drafting continues until … The drafting process Move to next slide.

21. 02 December 2015 John M Meredith ETSI-MCC 20 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. The drafting process Move to next slide.

22. 02 December 2015 John M Meredith ETSI-MCC 21 v1.5.0 The drafting process When the draft is “ready”, it is upgraded to version 2.0.0. v2.0.0 Note that v2.0.0 is technically identical to the previous 1.y.z document. Move to next slide.

23. 02 December 2015 John M Meredith ETSI-MCC 22 v2.0.0 If necessary, the Support Team should again clean up the draft to ensure that abides by the drafting rules 3GPP TR 21.801. (The latest version of 21.801 can be found via the most recent specs status list.) (The latest version of 21.801 can be found via the most recent specs status list.) The drafting process Move to next slide.

24. 02 December 2015 John M Meredith ETSI-MCC 23 v2.0.0 Draft 2.0.0 is presented for approval to the plenary TSG (Technical Body). The drafting process Move to next slide.

25. 02 December 2015 John M Meredith ETSI-MCC 24 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 Move to next slide.

26. 02 December 2015 John M Meredith ETSI-MCC 25 v2.3.0 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). v3.0.0 Note that v3.0.0 is technically identical to the previous 2.y.z document. Move to next slide.

27. 02 December 2015 John M Meredith ETSI-MCC 26 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”. Move to next slide.

28. 02 December 2015 John M Meredith ETSI-MCC 27 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 Move to next slide.

29. 02 December 2015 John M Meredith ETSI-MCC 28 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. Move to next slide.

30. 02 December 2015 John M Meredith ETSI-MCC 29 Change Control Consider an individual standard … v3.0.0 If the responsible working group wishes to make a change to it, however small, … Move to next slide.

31. 02 December 2015 John M Meredith ETSI-MCC 30 v3.0.0 Change Control … the working group must raise a Change Request. The CR consists of a cover page (here) … (here) … 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. Move to next slide.

32. 02 December 2015 John M Meredith ETSI-MCC 31 For example, a CR to TS 23.456 may be twice revised during the course of discussions in the WG before it is agreed. Change Control CR 4 to 23.456 CR 4 rev 1 to 23.456 CR 4 rev 2 to 23.456 Move to next slide.

33. 02 December 2015 John M Meredith ETSI-MCC 32 Change Control CR 4 rev 2 to 23.456 CR 5 rev 1 to 23.456 CR 6 to 23.456 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. Move to next slide.

34. 02 December 2015 John M Meredith ETSI-MCC 33 CR 4 rev 2 to 23.456 CR 5 rev 1 to 23.456 CR 6 to 23.456 Change Control The CRs are presented to the plenary TSG for approval. Presentation is the responsibility of the WG Chairman, assisted by the Secretary. Move to next slide.

35. 02 December 2015 John M Meredith ETSI-MCC 34 CR 4 rev 2 to 23.456 CR 5 rev 1 to 23.456 CR 6 to 23.456 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). Move to next slide.

36. 02 December 2015 John M Meredith ETSI-MCC 35 CR 4 rev 2 to 23.456 CR 5 rev 1 to 23.456 Change Control The Support Team (MCC) incorporates the approved CRs into the base specification … v3.0.0v3.1.0 Move to next slide.

37. 02 December 2015 John M Meredith ETSI-MCC 36 v3.1.0 Change Control The new specification version is then made available on the file server - for delegates to propose more changes! (Support experts, click here for how to transfer a spec to the Specifications Manager.) (Support experts, click here for how to transfer a spec to the Specifications Manager.) Move to next slide.

38. 02 December 2015 John M Meredith ETSI-MCC 37 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 Move to next slide.

39. 02 December 2015 John M Meredith ETSI-MCC 38 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. Move to next slide.

40. 02 December 2015 John M Meredith ETSI-MCC 39 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. Move to next slide.

41. 02 December 2015 John M Meredith ETSI-MCC 40 CRs are registered in a database maintained by the Support Team. Change Control Move to next slide.

42. 02 December 2015 John M Meredith ETSI-MCC 41 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”. Move to next slide.

43. 02 December 2015 John M Meredith ETSI-MCC 42 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. Move to next slide.

44. 02 December 2015 John M Meredith ETSI-MCC 43 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. (Click here to see the production process at ETSI.) (Click here to see the production process at ETSI.) Move to next slide.

45. 02 December 2015 John M Meredith ETSI-MCC 44 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.1.0 Move to next slide.

46. 02 December 2015 John M Meredith ETSI-MCC 45 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 Move to next slide.

47. 02 December 2015 John M Meredith ETSI-MCC 46 Change Control Using established methods of functional decomposition of the features into smaller elements... Feature 1 specFeature 2 specFeature 3 spec Move to next slide.

48. 02 December 2015 John M Meredith ETSI-MCC 47 Change Control … it is possible to raise Change Requests to each specification to include the new functionality. v3.3.0 Move to next slide.

49. 02 December 2015 John M Meredith ETSI-MCC 48 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 Move to next slide.

50. 02 December 2015 John M Meredith ETSI-MCC 49 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  v4.0.0 Move to next slide.

51. 02 December 2015 John M Meredith ETSI-MCC 50 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. Move to next slide.

52. 02 December 2015 John M Meredith ETSI-MCC 51 A disadvantage of the “release” approach … Release 1999Release 4 An error discovered here … Move to next slide.

53. 02 December 2015 John M Meredith ETSI-MCC 52 Release 3Release 4 … may require not one CR but two to fix it … Move to next slide.

54. 02 December 2015 John M Meredith ETSI-MCC 53 Release 3Release 4 … because the same error may have been inherited from the earlier Release! Move to next slide.

55. 02 December 2015 John M Meredith ETSI-MCC 54 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 Move to next slide.

56. 02 December 2015 John M Meredith ETSI-MCC 55 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. Move to next slide.

57. 02 December 2015 John M Meredith ETSI-MCC 56 end