All you always wanted to know about 3GPP - PowerPoint PPT Presentation

About This Presentation
Title:

All you always wanted to know about 3GPP

Description:

... version is, go to http://www.3gpp.org/Specification-Numbering and look it up ! ... Tick 'yes' box if any other specifications are affected by this change. ... – PowerPoint PPT presentation

Number of Views:78
Avg rating:3.0/5.0
Slides: 26
Provided by: johnmme
Learn more at: https://www.3gpp.org
Category:
Tags: 3gpp | always | do | know | like | look | ticks | wanted | what

less

Transcript and Presenter's Notes

Title: All you always wanted to know about 3GPP


1

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

2
The 3GPP SeminarModule 12
  • Change Requests

3
CHANGE REQUEST
  • Once a 3GPP specification has come under change
    control, the Working Group and/or the
    specification official rapporteur
  • no longer have the right to update the
    specification !

4
CHANGE REQUEST
  • But it is still possible to develop the standard
    further, to add the missing parts, and to correct
    errors and/or omissions as the overall system
    becomes better defined.

If the responsible Working Group wishes to make a
change to the specification
the working group must raise a Change Request.
5
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 ... And the WG finally
agrees upon the CR.
6
CHANGE REQUEST
The CR front page
7
CHANGE REQUEST
  • There are 22 comments on the front page !
  • For HELP on using this form look at the pop-up
    text over the ?H1 symbols. Comprehensive
    instructions on how to use this form can be found
    at http//www.3gpp.org/specs/CR.htm.  H1 For
    help on how to fill out a field, place the mouse
    pointer over the special symbol closest to the
    field in question.
  • Here are some examples
  • Document numbers are allocated by the Working
    Group Secretary.
  • Use the format of document number specified by
    the 3GPP Working Procedures, e.g. S4-090789.
  • Spec Number enter the specification number in
    this box, e.g. 31.102.
  • Do not prefix the number with anything . i.e. do
    not use "TS", "GSM" or "3GPP" etc.

8
CHANGE REQUEST
  • CR Num enter the CR number here.
  • This number is allocated by the 3GPP Support Team
    (MCC) it consists of four digits, padded with
    leading zeros if necessary, e.g. 0007.
  • rev enter the revision number of the CR here,
    e.g. 1.
  • If it is the first version of the CR, use a "-".
  • Current version x.y.z enter the version of the
    specification here. This number is the version of
    the specification to which the CR was written and
    (normally) to which it will be applied if it is
    approved, e.g. 8.7.0.
  • Make sure that the latest version of the
    specification (of the relevant release) is used
    when creating the CR.
  • If unsure what the latest version is, go to
    http//www.3gpp.org/Specification-Numbering and
    look it up !

9
CHANGE REQUEST
  • Proposed change affects Mark one or more of the
    boxes with an X)
  • ?UICC apps? SIM / USIM / ISIM applications H1
  • ME H2
  • Radio Access NetworkCore Network H1
  • SIM / USIM / ISIM applications H2
  • Title enter a concise description of the
    subject matter of the CR. It should be no longer
    than one line, but if this is not possible, do
    not enter hard new-line characters. Do not use
    redundant information such as "Change Request
    number xxx to 3GPP TS xx.xxx (Release x)".
  • Source to WG One or more organizations (ALL
    must be 3GPP Individual Members) which drafted
    the CR and are presenting it to the Working
    Group, e.g. NOKIA Corporation, Telefon AB LM
    Ericsson, Research in Motion UK Limited.

10
CHANGE REQUEST
  • Source to TSG for CRs agreed at Working Group
    level, the identity of the WG. Use the format
    "xn" where x "C" for TSG CT, "R" for TSG RAN,
    "S" for TSG SA, "G" for TSG GERAN n digit
    identifying the Working Group for CRs drafted
    during the TSG meeting itself, use "P (Plenary)".
    Examples "C4", "R5", "S4, GP".
  • Work item code enter the acronym for the work
    item which is applicable to the change request.
  • This field is mandatory (for Release 4 and
    later). A list of work item acronyms can be found
    in the 3GPP work plan. See http//www.3gpp.org/wo
    rk-plan and, specifically for the WI code list,
    http//www.3gpp.org/ftp/Specs/html-info/WI-List.h
    tm.
  • Examples GPRS, MIMO, TEI8.

11
CHANGE REQUEST
  • Date Enter the date on which the CR was last
    revised. Format to be interpretable by English
    version of MS Windows applications, e.g.
    19/08/2009.
  • Category Enter a single letter corresponding to
    the most appropriate category listed , e.g. F.
    For more detailed help on interpreting these
    categories, see Technical Report 21.900 "TSG
    working methods".
  • Use one of the following categoriesF
    (correction)A (corresponds to a correction in
    an earlier release ie a mirror CR)B
    (addition of new functionality)C (modification
    of existing functionality)D (pure editorial,
    having no technical impact)
  • Release Use one of the following
    releasesR99 (Release 1999)Rel-4 (Release
    4)Rel-5 (Release 5)Rel-6 (Release
    6)Rel-7 (Release 7)Rel-8 (Release
    8)Rel-9 (Release 9)Rel-10 (Release 10)
  • All earlier Releases are closed no maintenance
    is carried out on those Releases specs.

12
CHANGE REQUEST
  • Reason for change enter text which explains why
    the change is necessary.
  • Summary of change enter text which describes
    the most important components of the change, i.e.
    How the change is made.
  • Consequences if not approved enter here the
    consequences if this CR were to be rejected. It
    is mandatory to complete this section only if the
    CR is of category "F" (i.e. correction), though
    it is useful for other categories.
  • Clauses affected enter the number of each
    clause which contains changes. Be as specific
    as possible (i. e. list each sub-clause, not just
    the umbrella clause), e.g. 5.7.1, new Annex X.

13
CHANGE REQUEST
  • Other specs affected
  • ? Other core specifications
  • ? Test specifications
  • ? OM Specifications
  • Tick "yes" box if any other specifications are
    affected by this change. Else tick "no". You
    MUST fill in one or the other.
  •  List here the specifications which are affected
    or the CRs which are linked.
  • Other comments ?
  • Enter any other information which may be needed
    by the group being requested to approve the CR.
    This could include special conditions for its
    approval which are not listed anywhere else above.

14
CHANGE REQUEST
  • For example, a CR to TS 23.456 may be revised
    twice during the course of discussions in the WG
    before it is agreed the wording Revision of
    Tdoc S2-09xxxx should appear under the (new)
    Tdoc number of the revised CR.

CR 4to 23.456
15
CHANGE REQUEST
  • Prior to each TSG plenary, all CRs against a
    given specification, or a given work item, are
    gathered together by the Secretary of the WG
    responsible for the spec. In case, the Secretary
    cleans the front page, e.g. accepts all revision
    marks, and checks that the fields are correctly
    filled in.
  • A single Tdoc is created, with a cover page
    introducing each individual CR (it is suggested
    to group no more than 20 CRs per Tdoc).

16
CHANGE REQUEST
  • The CRs are presented to the plenary TSG for
    approval.
  • Presentation is the responsibility of the WG
    Chairman, assisted by the Secretary (if attending
    the Plenary).

17
CHANGE REQUEST
  • The TSG examines each CR and approves (or
    rejects, or postpones) each. Some CRs may be
    revised during the TSG meeting and re-presented
    (with a new revision number). A CR may be
    withdrawn as well.

18
CHANGE CONTROL
  • The Support Team (MCC) incorporates the approved
    CRs into the base specification

19
CHANGE CONTROL
  • The new specification version is then made
    available on the file server - for delegates to
    propose more changes!

20
CHANGE CONTROL
Established practice allows MCC a set period of
time for all revised specs to be made available
following approval of CRs.
Specs controlled by TSGs RAN have one week more
Specs controlled by TSGs GERAN, CT and SA to be
available at the end of the week following the SA
meeting
21
CHANGE CONTROL
Established practice allows MCC a set period of
time for all revised specs to be made available
following approval of CRs.
A further weeks grace is allowed for
particularly complex updates or ambiguous CRs
where consultation between MCC and rapporteur may
be required.
22
CHANGE CONTROL
Established practice allows MCC a set period of
time for all revised specs to be made available
following approval of CRs.
CT, RAN and SA WGs respect a no-meetings period
of one week before and after plenary periods.
But can and do meet during the remaining weeks.
23
CHANGE CONTROL
Established practice allows MCC a set period of
time for all revised specs to be made available
following approval of CRs.
Which may significantly advance the
spec-availability deadline !
24
(No Transcript)
25
CHANGE CONTROL
MCC provides regular updates on CR
implementation to each TSG SA meeting.
Write a Comment
User Comments (0)
About PowerShow.com