1 / 29

All you always wanted to know about 3GPP … but were too afraid to ask.

All you always wanted to know about 3GPP … but were too afraid to ask. The 3GPP Seminar. The 3GPP Seminar Module 10. Drafting and maintaining the Technical Specifications. Drafting and maintaining the technical specifications.

iniko
Download Presentation

All you always wanted to know about 3GPP … but were too afraid to ask.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. All you always wanted to know about 3GPP …but were too afraid to ask. The 3GPP Seminar

  2. The 3GPP SeminarModule 10 • Drafting and maintaining the Technical Specifications

  3. Drafting and maintaining the technical specifications The work items result in new technical specifications, or enhancements to existing ones …

  4. The drafting process (1) A named individual – the “rapporteur” - is identified for each spec. It is the rapporteur’s responsibility to initiate the drafting of the spec, and to maintain it throughout the drafting process. scribble scribble scribble scribble Spec numbers are allocated by the Support Team.

  5. The drafting process (2) The rapporteur issues the specification as version 0.0.0 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). Release 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. Technical 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. Editorial field

  6. The drafting process (3) The initial draft is discussed in the working group. v0.0.0 And a new draft is produced, bearing technical changes. v0.1.0

  7. v0.1.0 v0.2.0 v0.3.0 v0.8.0 v1.0.0 The drafting process (3) … The process is iterative, until … … the working group is happy with the draft. Draft 1.0.0 is presented for information to the plenary TSG (Technical Body).

  8. v1.0.0 v1.1.0 v1.2.0 v1.5.0 v2.0.0 The drafting process (4) … The document returns to the working group, and drafting continues until … … the working group believes the draft to be stable enough to come under formal “change control”. Draft 2.0.0 is presented for approval to the plenary TSG (Technical Body).

  9. v2.0.0 v2.1.0 v2.2.0 v3.0.0 v2.3.0 The drafting process (5) … If the TSG does not approve the draft, it may return to the working group for further refinement. This is exceptional. When the draft is approved to come under change control, it is upgraded to version 3.0.0 (assuming Release 1999 – see later).

  10. Change control (1) The “system” is composed of a coherent set of related specifications. 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.

  11. v3.0.0 Change control (2) Consider an individual standard … If the responsible working group wishes to make a change to it, however small, … … 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. http://www.3gpp.org/specs/CR.htm

  12. CR 4 rev 1 to 23.456 CR 4 rev 2 to 23.456 Change control (3) Several iterations of a CR may be required until the WG is happy with it. 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 4to 23.456

  13. CR 4 rev 2 to 23.456 CR 5 rev 1 to 23.456 CR 6 to 23.456 Change control (4) 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 TDoc is created, with a cover page introducing each individual CR. 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). * In practice, by the Secretary of the WG responsible for the spec.

  14. CR 4 rev 2 to 23.456 CR 5 rev 1 to 23.456 v3.0.0 v3.1.0 Change control (5) The Support Team (MCC) incorporates the approved CRs into the base specification …

  15. v3.1.0 v3.2.0 v3.3.0 Change control (6) … 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.

  16. Change control (7) • 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. Change control (8) 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, the functionality of Release 1999 became stable. The Release was “frozen”. Once frozen, no more functionality may be added to a Release (or, therefore, to its component specifications). Only essential corrections are permitted.

  18. Feature 1 spec Feature 2 spec Feature 3 spec Change control (9) It is now possible to add further functionality in carefully designed features forming part of a new “Release”.

  19. v3.3.0 Change control (10) … it is possible to raise Change Requests to each specification to include the new functionality.

  20. v3.3.0 v4.0.0 v4.1.0 Change control (11) … The addition of the new features to the system implies an upgrade to the next “Release” of the entire system specification.

  21. v0.0.0v1.0.0  2.0.0  v4.0.0 Change control (12) New functionality may equally result in an entirely new specification rather than a change to an existing one.

  22. Change control (13) 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.

  23. Change control (14) A disadvantage of the “release” approach … Note that maintaining several parallel releases of the same specification implies very well defined procedures and highly disciplined handling !! Release 1999 Release 4 An error discovered here … … may require not one CR but two to fix it … … because the same error may have been inherited from the earlier Release!

  24. Change control (15) A change control system along the lines described enabled the GSM specifications to undergo five controlled releases before the creation of 3GPP, and has allowed a smooth transition from second generation digital mobile communications to third generation and beyond, re-using as many of the basic elements as possible. This mechanism requires meticulous project planning and control…

  25. Withdrawing obsolete specs (1) Usually, an individual version of a spec may be withdrawn after its production only if it is replaced with a revised version. For example, a new version of 23.456 v9.3.0 is produced after meeting SA#50. It is immediately noticed that one CR was incorrectly implemented. A new version 9.3.1 is produced straight away to correct the fault, and version 9.3.0 is withdrawn. Version 9.3.0 will never be transposed into a publication of the OPs. However … Version 9.3.0 will remain in the archive directory on the 3GPP server for ever.

  26. Withdrawing obsolete specs (2) Consider now that a new version of 23.456, v9.4.0, is produced after SA#50. Version 9.3.0 is not withdrawn, but remains in the meeting directory pertaining to SA#50. It also remains in the archive directory. But it is obviously superseded by v9.4.0 at SA#51. No maintenance will be done on v9.3.0 once 9.4.0 becomes available.

  27. So where do I find the 3GPP Technical Specifications? Short answer: on the 3GPP file server. http://www.3gpp.org/specs/specs.htm

  28. So where do I find the 3GPP Technical Specifications? Longer answer: on the 3GPP file server. The following directories are maintained: Meeting-related directoriesHold all specs current as a result of implementing the approvals at the corresponding SA plenary meeting. LatestHolds the latest version of each spec currently under change control. Latest draftsHolds the latest version of each draft spec (i.e. those not yet under change control). ArchiveHolds every version of every spec, including stopped / withdrawn ones.

  29. For more information visit http://www.3gpp.org Or contact john.meredith@etsi.org

More Related