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 spec Feature 2 spec Feature 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 0.0.0

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.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.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.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.1v0.0.2v0.1.0v0.1.1v0.2.0v0.3.0v1.0.0v1.1.0v1.2.0v2.0.0v3.0.0v3.1.0v3.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.0And a new draft is produced, bearing technical changes.

17 May 2002 John M Meredith ETSI-MCC 13

v0.1.0 v0.2.0 v0.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 1.0.0.

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 1.0.0.

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 rules3GPP TR 21.801.

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 1.0.0 is presented for information to the plenary TSG (Technical Body).

The drafting process

17 May 2002 John M Meredith ETSI-MCC 18

v1.0.0 v1.1.0 v1.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 2.0.0.

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 2.0.0.

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 rules3GPP TR 21.801.

The drafting process

17 May 2002 John M Meredith ETSI-MCC 22

v2.0.0

Draft 2.0.0 is presented for approval to the plenary TSG (Technical Body).

The drafting process

17 May 2002 John M Meredith ETSI-MCC 23

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.

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 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.

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 23.456 may be twice revised during the course of discussions in the WG before it is agreed.

Change Control

CR 4to 23.456

CR 4 rev 1 to 23.456

CR 4 rev 2 to 23.456

17 May 2002 John M Meredith ETSI-MCC 31

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.

17 May 2002 John M Meredith ETSI-MCC 32

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.

17 May 2002 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 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 23.456

CR 5 rev 1 to 23.456

Change ControlThe Support Team (MCC) incorporates the approved CRs into the base specification …

v3.0.0 v3.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.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.

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.0

v3.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 spec Feature 2 spec Feature 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 spec Feature 2 spec Feature 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.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.

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.0v1.0.0 2.0.0 v4.0.0

17 May 2002 John M Meredith ETSI-MCC 49

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 50

A disadvantage of the “release” approach …

Release 1999 Release 4

An error discovered here …

17 May 2002 John M Meredith ETSI-MCC 51

Release 3 Release 4

… may require not one CR but two to fix it …

17 May 2002 John M Meredith ETSI-MCC 52

Release 3 Release 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.0v2.0.0v3.0.0v3.1.0v3.2.0v3.3.0

v4.0.0v4.1.0v4.1.1v3.3.1v4.2.0v3.4.0

v5.0.0v5.1.0v4.3.0v3.5.0v5.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 1999Correction 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