Conventions

TSG and WG naming conventions

Whilst the full names of Technical Specification Groups and their Working Groups are usually given on the 3GPP web site, they can be somewhat verbose, and it is often convenient to use abbreviated forms.  These forms are defined in the database table committees_local-names, which maps them to the technical body id values used in DS and elsewhere.

While PCG and OP retain their "full" names, TSGs and WGs are generally abbreviated to two characters:

* the first character signifies the TSG:
        R = RAN
        G = GERAN
        T = Terminals (obsolete)
        N = Core Network (obsolete)
        C = Core Network and Terminals
        S = SA

* the second character signifies the WG:
        P = plenary (ie the TSG itself, not a working group)
        1 = working group 1
        2 = working group 2
        ... etc

Note that the original GERAN working goup 3 was closed when it was merged with working groups 4 and 5, and a new working group 3 created.  This is known as G3new, and this value is used for all formal use in the database.

In the database, it is sometimes possible to select the TSG/WG from a drop-down list, but normally it has to be entered by hand.

Dates

The 3GPP database and web site need to accommodate users of many nationalities, and a variety of national date formats are conventionally in use.

Although the database will display dates according to the user's local settings (Windows Control Panel, Regional settings), it is designed to work with ISO recommended dates formatted as yyyy-mm-dd, that is years then months then days, with leading zeros for months and days less than ten.  It is highly recommended that users of the database adopt this convention on their PCs.  Some calculations of time differences may require this format for correct operation.

Spec filenames

The filenames for specs abide by a rigid convention.  The filename consists of the spec number minus the dot after the second digit, followed by a hyphen, followed by three digits representing the version number.  All files are stored compressed since this not only saves storage space and speeds up download time, but also serves to group specs which are comprised of multiple files.  Hence all specs have the file extension ".zip".

Since only one character space is available for each of the three components of the version number, these characters are coded in base 36.  That is to say:

Observe that this system can only cater for version number subfields up to 36, and till now this has not caused a problem, though one or two much-changed specs have come perilously close to bursting this limit.  The alphabetic characters are case-insensitive, but conventionally are rendered in lower case.

If the above convention is violated, the routines which automatically store spec files in the correct folders on the server will go awry, as will the hyperlinks to those specs.

In the case of a few very long specs, it has been found expedient to split the Word file into several shorter files.  This speeds up the editing process, though entails more manual effort in maintaining page number continuity from file to file.  There is no formal naming convention for the component files of such specs, other than that they sort alphanumerically in the correct sequence.  Since all the Word files are contained in a single zip file, their precise names are not important to the database.

Word files should have the extension ".doc". This is necessary for the routines which perform quality assurance tests, parse for titles and references, etc. This means that Word 2003 file format must be used - ie Word 2007 ff format where the file extension is ".docx" cannot be used.

See also the clause below on multi-part specs.  Do not confuse multi-part specs with large specs (single- or multi-part) which comprise more than one Word file.

Multi-part specs

Specs with more than one part have those parts identified by a number following the main spec number, separated by a hyphen.  For example 51.010-1. Where there are more than nine parts, to ensure correct sort order of lists of specs, a leading zero is inserted where necessary to the part number, which then becomes two digits, for example 29.198-08.

A small number of specs have parts with subparts, and the same convention applies: for example 29.998-06-2.

The spec number is a string rather than a number or a set of numbers, and in searches etc the correct leading zero must be entered if the spec is to be correctly identified.  The convention is reflected in the spec document itself, and in its filename.  Thus the filenames for these examples:

Work item codes (acronyms)

The conventions for generating WI codes are given on the 3GPP web site.