In any complex engineering venture, it is necessary to plan the project, to monitor its progress, and to be able to determine whether it is being completed on schedule and within budget. In many ways, the concepts and constraints which apply to an engineering project can also be applied to system standardization activity.
Any project needs to have its goals defined. It is then possible to analyse the steps needed to achieve each goal, starting from the status quo.
It will often be desirable to first produce a feasibility report, which is to be undertaken in the context of a Study Item.
A feasibility study may include commercial as well as technical considerations. This analysis will naturally lead to defining the new features which it is wished to add to the existing system.
A feature should be more or less self-contained - that is, each feature can be viewed as an optional extra, which can be added or not as a function of market demand. Network operators and equipment manufacturers can decide using commercial considerations whether or not to implement a feature. The description of a feature need not be technically precise, but should represent a concept which can be understood at a "service" level. It should answer the question: what do I get for my money?
A feature should normally embody an improved service to the customer and / or increased revenue generation potential to the supplier.
This being the case, most features would be the responsibility of TSG-SA WG1. The ensemble of the features of a particular release of the system represents the difference between that release and the previous release.
A feature can be considered as a high-level goal for project management purposes. But most features will be quite complex, and will need to be broken down into simpler elements or building blocks for the purpose of specifying precise functionality.
Work on a study item or feature may be carried out by multiple working groups spanning one or more TSGs. In the case of multi-TSG study items and features, all such TSGs should be shown in the work plan as being responsible for the study item or feature; this should be refined as soon as possible into an identification of the individual working groups responsible. To allow work to progress, the Work Item Descriptions (see clause 6.1) may be approved by one TSG before formal contribution has been received by other involved TSGs and WGs, which should review the Work Item Description in a timely manner, and provide their own input as soon as possible.
A building block shall be defined in technical terms, and its description will require an understanding of the architecture of the overall system. A building block should generally be restricted to a single physical or logical entity or a single protocol such as "terminal" or "call control". Building blocks may be "re-usable" - that is, a single building block may be common to two or more features. This implies a generic or object-oriented approach. A building block should normally be the responsibility of a single TSG.
In the case of very simple features, a single building block may suffice, in which case the feature and its building block are synonymous.
To implement a building block it will generally be necessary further to subdivide the functionality into smaller tasks, each representing a closely specified and easily comprehended activity. Such work tasks may not only be divided by technical content, but potentially by phase. So, for example, it is necessary fully to define service aspects (one or more work tasks) before considering functional information flows (one or more work tasks) which in turn will be followed by detailed protocol specification (one or more work tasks).
It is at this lowest hierarchical level of breakdown that estimations of work content and thus time scales can be calculated. From the estimated schedules of all work tasks which comprise a building block, and from their inter-dependences, can be derived the overall schedule for the "parent" building block. From the schedules of all component building blocks, the time-to-completion of the parent feature can be estimated. A work task will almost certainly be the responsibility of a single Working Group.
The output of a work task shall be:
One or more new Technical Specifications (or Reports); and / or
Change Requests to existing TSs / TRs.
Features, building blocks and work tasks are the three specific types of "Work Item".
In the case of very simple building blocks, a single work task may suffice, in which case the building block and its work task are synonymous.
All Work Items, whatever their class (feature, building block or work task) require:
A precise definition of content ("scope");
An estimated schedule, with milestones to track progress if possible; (in the case of building blocks and features, the schedule can be derived from those of the component work tasks);
A named person to act as rapporteur (in effect, the manager of the Work Item);
At least four Member Organizations supporting the Work Item and willing to offer active participation in its realization.
The possible modifications of the specifications are basically of different natures:
Error corrections: modifications which correct overlooked errors or inconsistencies in the specifications.
Enhancements: modifications that enhance the system, e.g. by new services or features, or by improving performance or decreasing costs.
Modifications of the correction category (i.e. Category F) are ongoing maintenance tasks and are handled with CRs bearing the code of the Work Item that was used to introduce the affected feature, for the original Release in which it was introduced. Corresponding mirror CRs (i.e. Category A) may be produced for subsequent releases as applicable, using the same Work Item code. See also clause 6.2 covering the case where such a CR is not introduced into the TS or TR at the Release with which that Work Item is associated.
Modifications of the enhancement category (i.e. Category B or C) are handled within the concept of Work Items or as "technical enhancements". (See clause 6.2.) Note that prior approval of the WID by the TSG is needed before any substantial work is launched. If that work can be completed within one TSG cycle, the new WID may be approved at the same TSG meeting at which the enhancement CRs are presented. See clause 6.1 for the creation of Work Items.
When new or enhanced functionality of the 3GPP system is considered desirable an Individual Member of 3GPP (or group thereof) may make a proposal by submitting a Work Item Description (WID) sheet to the relevant TSG or TSG WG:
For new services, features or functions, the TSG responsible for Services and System Aspects is the relevant TSG. This TSG shall assign prime and, if necessary, secondary responsible TSGs for the corresponding Work Items.
For pure performance enhancements, other TSG WGs may be responsible.
The relevant TSG WG should study and refine the WID before passing it on to the TSG for adoption.
No substantial work shall commence in a TSG WG prior to a decision of the responsible TSG.
The actual WIDs to be used and guidance on how to apply them shall be distributed by the Support Team.
The TSG shall not approve a Work Item unless the WID has been properly filled in to the extent possible.
The Support Team shall maintain a database of Work Items, and make it available on the 3GPP file server and portal.
A Work Item normally implies the creation of new specification and Change Requests to existing specifications.
Modifications of the standard could in principle be of two different types:
New services/features/functions that in general affect several specifications and involve several TSGs / WGs;
Technical enhancements or improvements that affect one or a small number of specifications and involve a single or a few Groups only.
Modifications of the latter type may be submitted to the Working Group(s) and then to the TSG directly as a Change Request without prior presentation/agreement of a WI Description sheet. Such CRs shall instead refer to the pseudo Work Item 'Technical Enhancements and Improvements'. The CRs relating to this type of modification shall be tagged with the work item code TEI<x> where <x> represents the Release number: e.g. for Release 16, the code would be "TEI16".
TEI Work Item codes shall not be used where an appropriate Work Item code exists.
TEI Work Item codes should not be used for the definition of new services/features/functions (i.e. Category B CRs).
TEI Work Item codes should not be used alone for functional modification of existing services/features/functions (i.e. Category C CRs).
Nevertheless, if a feature is functionally modified by a Category C CR using a TEI<x> Work Item code, the code(s) for the Work Item(s) which introduced that feature shall be used, plus the appropriate TEI<x> code for the first Release in which the CR is introduced.
it is clear that the modification(s) can be completed within one TSG cycle, and
the normal stage 1, 2, 3 sequence of CRs does not require one additional meeting cycle in each affected TSG,
then a TEI code may be used. TEI codes shall not be used where the development of modification(s) and interactions with other WGs are likely to prolong the outcome for a period of time greater than this; in such cases, a new specific Work Item shall be created instead.
For smaller features that are handled with Category B and/or Category C CRs within one TSG cycle, a provisional Work Item code shall be used before the CR(s) and the companion WID are submitted for approval to the TSG.
Notwithstanding the provisions of clause 4.10.2, TEI<x> is also to be used in a Category F and any related Category A CR(s) which add to or modify TR/TS content introduced in a Release prior to <x> and where no appropriate Release <x> Work Item exists. In this case the code(s) for the Work Item(s) which introduced the relevant TR/TS content shall be used, plus the appropriate TEI<x> code for the first Release in which the CR is introduced. The same TEI<x> shall be used in all mirror (i.e. Category A) CRs.
TR/TS content is introduced into TS 23.456 under the Release 13 Work Item ABCD by means of a Rel-13 CR. Much later, an error is identified in the TR/TS content introduced by that Rel-13 CR which of course appears in the current Release 13 version of 23.456.
According to the provisions of clause 4.10.0, a category F CR would be introduced into the current Release 13 version tagged with Work Item ABCD, together with category A (mirror) CRs to the Release 14, 15, etc versions of 23.456, each also tagged with code ABCD.
However, it is felt that the seriousness of the error does not warrant taking the correction all the way back to Release 13, and so the category F CR is instead written to the current Release 15 version of 23.456. This is tagged with the Work Item codes ABCD and TEI15. Category A CRs are written to the Release 16, etc versions of 23.456, and these are also tagged with Work Item codes ABCD and TEI15.
The use of a TEI Work Item code alone should be avoided whenever possible, and any use of a TEI Work Item code should be considered very carefully.
For the other types of modification, the provisions of subclause 6.3 apply.
An early task when elaborating a Work Item is to identify the tasks related to the WI and to allocate them to the TSGs and TSG Sub-Groups.
In most cases the tasks from a WI can be split immediately into the following areas:
System/Architectural requirements and implications
The responsibility of the service requirements can usually be allocated immediately at the creation/adoption of the WI. Occasionally another Group may be given responsibility for the service requirements. In any case, however, it should be a single group and one that reports directly to the TSG.
System/Architectural requirements and implications:
In addition, the responsibility for system/architectural requirements should be allocated immediately, even though the implications and requirements normally will be seen only after the study on service/system requirements have been initiated. The responsibility for the system/architectural requirements shall be given to a single body to guarantee the consistency of the adopted solution.
The choice of group should not pre-determine the technical choices and in many cases, the responsibility for system and architectural requirement study needs a widening of the competency and a readiness to look at a variety of technical aspects. This can be obtained either by drawing the attraction of the suitable experts (e.g., by setting special meetings or clear meeting dates) or by the organization of joint meetings.
TSG SA shall maintain the overall consistency of the system architecture despite the numerous modifications due to various Work Items. TSG SA, shall ensure the co-ordination of the development of general architecture concepts and their applications to individual Work Items, and should thus also draw attention and expertise from other Groups.
The responsibility for the elaboration of the protocol specifications cannot, in most cases, be allocated at the early stages since it depends on the technical implementation choices and hence on the results of the study of the service/system requirements as well as on the architectural conclusions.
The identification of new protocols to be specified and/or existing protocols to be enhanced shall be derived from the system/architectural requirements. In general, modifications of existing protocols shall be done by the TSG WG in charge of the protocol in question, whilst the responsibility for development of new protocols shall be allocated by the TSG based on proposals from the TSG WG on system/architecture. Then, whether the actual work is done in the TSG WG itself or in an ad hoc subgroup thereof is at the discretion of that TSG WG.
Every Work Item shall have a rapporteur. The rapporteur should be selected from regular attendees of the primary responsible Group and shall be selected from supporting companies. The role of the rapporteur is to:
Monitor the progress of the work in all WGs for the WI.
Report to the responsible WG and produce a report to the WG plenary on progress.
Provide feedback to allow the work plan to be updated.
An initial time plan should be set up at an early point. As a basis, the time plan should include at least the following points:
Presentation for principle agreement of the service requirements;
Presentation for principle agreement of the architectural/system implications and requirements;
Presentation for information of the drafts of all needed deliverables,
Presentation for approval of all needed deliverables.
The time plan shall include realistically achievable dates for each step.
The WI Status List shall also contain information about existing and planned permanent and semi-permanent documents related to the WI, e.g. future specifications as well as interim/temporary requirements "specifications", including the responsible Group, the rapporteur, the state of the documents, expected completion dates, etc.
Before the substantial work on a Work Item starts, the WI shall be examined in the light of its technical and commercial dependency with respect to the existing specifications as well as with respect to other Work Items. Aspects that shall be considered and settled at an early stage are:
Required versus acceptable time scales;
Whether the WI has an impact on User Equipment or not;
Whether the WI has an architectural impact or not;
To which degree the WI needs to specify (and hence how much can be left "open", to speed up the work);
Whether the WI can be technically and/or commercially combined/grouped with other WIs;
Unless the above aspects are sorted out at the beginning of (or prior to) the work, the risk of getting inefficient and non-optimal specifications increases and the control of the work becomes difficult and unmanageable.
The SI will be realized as a new Technical Report ("feasibility study report").
The WI will be realized as new specifications and/or amendments to existing specifications; the exact structure lies with the individual TSG Sub-Groups and the TSG. Typically, a new feature may result in at least three completely new specifications (stages 1, 2 and 3) but may also cause amendments to the major protocol specifications.
This task, allocated and controlled according to the provisions above, consists in describing in details the aim of the Work Item, as seen by those for which a service is provided, e.g. end users, operators, service providers, etc.
In many cases it is desirable that, prior to the actual service requirements specification being produced, an initial combined service and system/architectural requirements and considerations document is produced, involving both service oriented and implementation expertise. In particular when an ad hoc task force is charged with performing a study on a certain WI (aspect) such a starting point document should be produced and then used as a basis for the TSG SGs when carrying out the detailed work on service requirements/descriptions and technical realization specifications. Such setting-the-basis documents should generally be kept for some time after the actual work on the detailed specifications has progressed to a mature level (mainly for the purpose of easing the understanding and to shorten the interaction and negotiation period between service requirements and system/architectural and technical restrictions).
Such 'setting-the-basis' document can also be used to describe the project management of a Work Item (to collect all prepared but not yet approved CRs related to the WI in question).
It may be appropriate to perform the above work in the context of a Study Item, prior to embarking on concrete specification work.
These cover both the overall architectural and interface specific detailed specifications. The architectural implications and requirements need to be identified at a very early stage, for the purpose of knowing which parts of the standard (and hence of the system) are affected by a WI, and for the purpose of supporting the identification of cross-WI similarities (and hence more overall efficient solutions).
The overall co-ordination of the architectural/system requirements is with a single group as stated above, whilst the ensuing detailed protocol definitions and specifications may be distributed over several groups (according to their scope).
The responsible TSG may decide that a particular Work Item is a candidate for "early implementation". If a feature is a candidate for early implementation this shall be indicated in the 3GPP work plan.
Where a feature is a candidate for early implementation the deliverables shall include an early implementation Technical Report. The Technical Report shall give guidance on how to perform early implementation of a Work Item. This report shall not define any new technical requirements. It is there to help implementers identify which parts of the specifications are relevant to the Work Item and how they should be handled when early implementation is performed.
The early implementation Technical Report shall be identified in the list of impacted documents in the WID. The early implementation Technical Report is part of the same release as the feature to which is relates.
Where a single early implementation feature consists of several Work Items then the number of different TRs should be minimised. The aim shall be for a single report to be written for the appropriate highest level Work Item (typically the feature level). However, flexibility should be left to take account of different ways Work Items may be structured
Work on the early implementation Technical Report shall begin with the identification of the requirements for early implementation.
The contents of the early implementation Technical Report shall be developed in parallel to the overall progress on standardisation of the Work Item. The responsible Working Groups shall keep the report up to date - particularly the clauses "specification impacts" and "Early Implementation Status" which must be completed before finalisation of the WI and maintained if they are subsequently impacted by any essential corrections.
If a Feature cannot be completed by the freeze date for a Release, two options are available:
If the functionality covered by the late-running work item is considered by the TSG not to be vital to the overall Feature, it may be abandoned, or form part of a later Release. It may be necessary to raise CRs to remove modifications from specifications which have already been implemented, so as not to leave unworking stubs of functionality and to ensure that stages 1, 2 and 3 are harmonized.
If the foreseen likely overrun is thought to be only a matter of a few months - generally no more than two TSG plenary meeting cycles - the responsible WG may raise an "exception sheet" to request a delay in completion until the next or next-but-one TSG meeting. In this case, the responsible WG undertakes to give high priority to completing the work within that time frame, while recognizing that progress can only be made on the basis of contributions to the work.
In the first case, where the delayed work is moved to a later Release, the responsible WG shall make appropriate changes to the 3GPP work plan.
In the second case, the exception sheet should contain enough information to enable the TSG to make a reasoned assessment of the case, and to accept or reject the proposal.
This is a draft Work Item which has not yet been approved by a TSG
The Work Item may appear in the work plan. If it is included then the "level of approval" shall be blank (no approval) or set to "WG" for Working Group approval.
Work in Progress
This Work Item has been approved by a TSG. Work on the Work Item is in progress in the relevant Working Groups
The Work Item shall appear in the work plan. The "level of approval" shall be "TSG". The "%complete" indication shall be less than 100%.
This Work Item has been approved by a TSG. Work on the Work Item has been completed and the Work Item is frozen. Only essential changes are permitted using this Work Item code.
The Work Item shall appear in the work plan. The "%complete" indication shall be "100%".
Work on this Work Item has been stopped without the Work Item being completed. No further changes are permitted using this Work Item code. Existing changes approved using this Work Item code remain in the specifications unless CRs are provided to remove them.
The Work Plan shall record the TSG meeting at which a Work Item was stopped. (Previous practice was to delete the Work Item completely from the Work Plan.)
The model described below can be thought of as a reference model for structuring the work. It is not the intention to rigorously enforce the usage of the model on all ongoing work, but merely to use it as the common reference model across the TSGs and to structure future work.
The description below uses TSG SA as an illustration; it can easily be extended to apply to any TSG (or combination of TSGs).
TSG SA is, through SA1, responsible for defining the features and services required in the 3GPP specifications. SA1 is responsible of producing the stage 1 descriptions (requirements) for the relevant features and passing them to SA2. SA1 may also forward their considerations on possible architecture and implementation to SA2, but is not responsible for this part of the work.
SA2 should then define the architecture for the features and the system, and then divide the features into building blocks based on the architectural decisions made in SA2. SA2 shall then forward the building blocks to the relevant TSGs for the detailed work. These proposals shall be reviewed and discussed in an interactive way together with TSGs/WGs, until a common understanding of the required work is reached. During the detailed the work of the TSGs and their Working Groups, SA2 shall be kept informed about the progress.
The TSGs and their WGs treat the building block as one or several dedicated work tasks. Typical output of a work task is new specification(s), updated specification(s), technical report(s) or the conclusion that the necessary support is already provided in the existing specifications.
SA2's role is in co-operation with the TSGs and their WGs to identify if synergy can be obtained by using some of the building blocks for more than one feature. Part of SA2's task is to verify that all required work for a full system specification of the features relevant will take place within 3GPP without overlap between groups. In order for SA2 to be successful, this has to be done in co-operation with other TSGs/WGs.
The following guidelines are proposed for project scheduling. SA1 sets a target, SA2 performs a first technical review and comments on the target. SA2 indicates target for time schedule together with allocation of the defined building blocks. The TSGs and their WGs comment back on these targets. SA2 tries if necessary to align the new target amongst the involved parties. SA1 and SA are kept informed of the overall schedule.
It is the task of TSG SA, SA1 and SA2 to ensure early involvement of SA3 to ensure that the potential security requirements, service requirements and the architectural requirements are aligned and communicated to the TSGs and their WGs.
In order for TSGs CT, GERAN and RAN and their subgroups to plan and perform their horizontal tasks on conformance testing and mobile station capabilities, SA2 should invite those TSGs to evaluate the potential impact of a new feature. If work on horizontal tasks is required, this should be included in the overall work plan.