6 Work Items and Study Items — how the work is authorised

6.1 Why writing is not allowed to start on its own

3GPP treats standardisation as a project, and says so in plain words: any complex engineering venture has to be planned, monitored and judged against a schedule and a budget, and the same applies to system standardisation §6.0.1.

The practical effect is a gate before the writing. A Working Group may study a proposal and improve it, but the moment of authority belongs to the plenary above it.

6.2 Four sizes of work

The umbrella term is Work Item, and it covers four things of very different size §2, §6.0.2:

• Study Item. An initial study resulting in a Technical Report, typically a feasibility study for additional functionality. If its results are positive, one or more Feature work items may follow. A feasibility study may weigh commercial as well as technical considerations.

• Feature. New or substantially enhanced functionality that represents added value to the existing system. The document's own test for a feature is commercial: it should answer the question "what do I get for my money?", and an operator should be able to decide on market grounds whether to implement it. Most features are the responsibility of SA1.

• Building block. A sub-division of a feature, a coherent set of technical functionality that would generally sit in a single system element. It must be described in technical terms and should normally be one TSG's responsibility.

• Work task. A sub-division of a building block: self-contained, well-scoped and well-scheduled. A work task will almost certainly belong to a single Working Group.

The hierarchy is also where the schedule comes from. Estimates are made at the lowest level, then added up: from the work tasks comes the building block's schedule, and from the building blocks comes the time to completion of the feature §6.0.2.

Where the work is simple, the levels collapse — a feature may have one building block, and a building block may have one work task, and in each case the two are synonymous §6.0.2.

The output of a work task is defined narrowly: one or more new Technical Specifications or Reports, or Change Requests to existing ones, or both §6.0.2.

6.3 What a proposal has to carry

Whatever its class, a work item requires four things, and the fourth is the one that separates a real proposal from an idea.

The other two are a precise definition of content — the scope — and an estimated schedule, with milestones to track progress where possible. For a building block or a feature, the schedule may be derived from the component work tasks §6.0.2.

6.4 How a work item is created

The proposal arrives as a Work Item Description sheet — a WID — submitted by an Individual Member of 3GPP, or a group of them, to the relevant TSG or Working Group §6.1. Which body is relevant depends on what is being proposed:

• for new services, features or functions, the TSG responsible for Services and System Aspects, which then assigns prime and, if necessary, secondary responsible TSGs;

• for pure performance enhancements, other Working Groups may be responsible.

The Working Group studies and refines the description before passing it up for adoption, and the plenary shall not approve a work item unless the description has been properly filled in as far as possible §6.1. The Support Team distributes the templates and the guidance, and maintains a database of work items on the file server and the portal §6.1, §7.2.

A work item normally implies both new specifications and change requests to existing ones §6.1.

In the record on this machine, 11,595 documents are new work item descriptions ^[1], and 5,532 are new study item descriptions ^[2].

6.5 The shortcut for small changes

Not everything deserves a description sheet. Clause 6.2 divides modifications into two kinds: new services, features or functions, which generally affect several documents and several groups; and technical enhancements or improvements, which affect one or a few documents and one or a few groups §6.2.

The second kind may go to the Working Group and then straight to the plenary as change requests, with no description sheet agreed first. Those change requests instead refer to a standing pseudo work item called "Technical Enhancements and Improvements", and are tagged with the code TEI followed by the Release number — TEI16 for Release 16 §6.2.

The document then spends most of the clause fencing the shortcut in §6.2:

• a TEI code shall not be used where an appropriate work item code exists;

• it should not be used to define new services, features or functions, which is to say for category B changes;

• it should not be used alone for a functional modification, which is to say for category C changes — if a feature is modified under a TEI code, the codes of the work items that introduced that feature are used as well;

• it may be used only where the change can be finished within one plenary cycle and the stage 1, 2, 3 sequence does not need an extra cycle in each affected group;

• and the use of a TEI code alone should be avoided wherever possible.

For a small feature handled by category B or C changes inside one cycle, a provisional work item code is used until the change requests and the companion description sheet are put up for approval together §6.2.

There is a companion rule for corrections. Category F changes are ongoing maintenance and carry the code of the work item that introduced the affected feature, for the Release it was introduced in; the category A mirrors use the same code §6.0.3. Where a correction is written against a later Release than the one the content came from and no suitable code exists there, TEI for that Release is added alongside the original code §6.2.

6.6 Who does which part

Once a work item exists, its tasks are split and allocated. Clause 6.3.1 divides them three ways §6.3.1:

• Service requirements. Usually allocated when the work item is adopted, and always to a single group reporting directly to the TSG.

• System and architectural requirements. Also allocated immediately, and given to a single body, so that the adopted solution stays consistent. TSG SA keeps the overall consistency of the system architecture across all the work items pulling at it.

• Protocol specifications. Usually cannot be allocated early, because they depend on the technical choices the architecture work has not yet made. Changes to an existing protocol go to the group that owns that protocol; a new protocol is allocated by the TSG on the architecture group's proposal.

Every work item has a rapporteur, selected from regular attendees of the primary responsible group and from the supporting companies. The role is to monitor progress across every group involved, report to the responsible group, feed the work plan, keep the work item sheet current, and say when the item is finished — with updates to the sheet needing approval by the responsible group §6.3.2.

6.7 Planning, deliverables and the four states

An initial time plan should exist early, and clause 6.4.1 says what it has to contain at a minimum §6.4.1:

• T1. Presentation for principle agreement of the service requirements.

• T2. Presentation for principle agreement of the architectural and system implications and requirements.

• T3. Presentation for information of the drafts of all needed deliverables.

• T4. Presentation for approval of all needed deliverables.

The dates against those steps have to be realistically achievable, and before substantial work starts the item is examined for its dependencies: time scales, whether it affects user equipment, whether it has architectural impact, how much must be specified and how much can be left open, and whether it can be grouped with other work items §6.4.1.

The deliverables follow the type. A Study Item is realised as a new Technical Report — a feasibility study report. A work item is realised as new specifications, amendments to existing ones, or both; a new feature may well produce three entirely new documents, one per stage, as well as amendments to the major protocol specifications §6.4.2.

Progress is recorded in the work plan, and the status may take one of four values §6.5:

Status	What it means
Not TSG approved	a draft work item, not yet approved by a plenary
Work in Progress	approved, under way, below 100% complete
Frozen	approved and completed; only essential changes under this code
Stopped	abandoned before completion; no further changes under this code

"Stopped" leaves what it already changed in place: existing changes approved under the code stay in the specifications unless change requests are written to remove them, and the work plan records the meeting at which the item was stopped §6.5.

What happens when the schedule slips — abandonment, deferral, or an exception sheet asking for one or two more meeting cycles — is in §6.4.5 and is set out in What a Release is, and what freezing one costs.

6.8 Where this leads

The Change Request, field by field is the vehicle a work item's decisions travel in. How a 3GPP meeting decides, and the word it decides in is what happens to that vehicle in the room.