All%20you%20always%20wanted%20to%20know%20about%203GPP%20

1

The 3GPP Seminar

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

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
rapporteurs 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
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
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
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
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
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
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
Change control (5)
The Support Team (MCC) incorporates the approved
CRs into the base specification
15
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
Change control (9)
It is now possible to add further functionality
in carefully designed features forming part of a
new Release.
19
Change control (10)
it is possible to raise Change Requests to each
specification to include the new functionality.
20
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
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 SA50. 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 SA50. Version 9.3.0 is
not withdrawn, but remains in the meeting
directory pertaining to SA50. It also remains in
the archive directory. But it is obviously
superseded by v9.4.0 at SA51. 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_at_etsi.org