All About 3GPP: Releases, Specifications, and Project Management

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

2. The 3GPP SeminarModule 7 • The Work Plan

3. 3GPP Releases (1) Specifications are grouped into “Releases” A mobile system can be constructed based on the set of all specifications which comprise a given Release. A Release differs from the previous Release by having added functionality introduced as a result of ongoing standardization work. http://www.3gpp.org/specs/releases.htm

4. 3GPP Releases (2) A 3GPP system definition consists of all the technical specifications of a given “Release”. Together, these specifications define a set of features provided by the system.

5. Release N 3GPP Releases (3) A new Release consists of the features of the old Release augmented with additional features of the new Release: Feature X Feature Y Release N+1 Feature Z

6. Feature 1 spec Feature 2 spec Feature 3 spec Project Management (1) Traditional systems analysis* and project management techniques break the idea down into progressively more manageable elements. Until it is possible to identify individual component specifications. * This analysis phase may well require the preparation of a feasibility study TR.

7. Feature 1 spec Project Management (2) To be adopted onto the work programme of 3GPP, each feature must have the support of at least four 3GPP individual member organizations, which agree to contribute actively to the development of the necessary technical specifications. A Work Item Description (WID) is prepared using a standard form, and is approved by the TSG. A named individual – the “rapporteur” - is identified for each feature and, where necessary, for each component subtask of the feature. It is the rapporteur’s responsibility to monitor work, and, for example, to hold extra ad hoc meetings to ensure progress is made. He will also prepare a short report on the feature to each TSG meeting, and will maintain the WID, presenting any changes to the TSG for approval.

8. Feature 1 spec Study TR Project Management (3) Most “features” are too complex to be handled as a whole, so each is broken down into a number component tasks (“building blocks”). Each of these components is managed independently, with the feature rapporteur coordinating progress.

9. Feature 1 spec Study TR Project Management (4) Even building blocks may be too complicated to manage as a whole, and further functional decomposition to smaller “work tasks” is possible. } work items Study Items, Features, building blocks and work tasks are generically known as “work items”.

10. Release N A new Release consists of the features of the old Release augmented with additional features of the new Release: Feature X Feature Y Release N+1 Feature Z

11. Release N Some features may not be ready in time to be included in the new Release, and are held over till a later Release: Feature X Feature Y Feature Z To Release N+2

12. Some features may be sufficiently self-contained that they may be specified entirely in a new set of Specifications; if these can be completed ahead of schedule, then such features are flagged “early implementation” and can be commercially exploited prior to the completion of the Release as a whole.

13. Release N An “early implementation” feature can be built into equipment which is otherwise conformant with the previous Release: Feature X Feature Y Release N+1 Feature Z EI Implement in Release N equipment

14. “Early implementation” features are about as rare as hens’ teeth. Feature Z EI Implement in Release N equipment

15. Release N Occasionally it is convenient to consider a feature to be independent of any particular Release … Feature X Feature Y Feature AA Release N+1 Feature Z

16. In practice, such Specifications are often included only in the currently open Release …

17. … but rigorously, they should be retro-fitted to all previous Releases to which they apply:

18. A “Feature” is defined by its “Work Item Description” sheet. It is manifested by a set of new technical specifications and changes to existing specifications.

19. Remember that a Feature is defined as: "new or substantially enhanced functionality which represents added value to the existing system" [3GPP TR 21.900]. This definition presumes that Features are defined in a commercial, non-technical way. Thus even senior management may see at a glance the commercial and financial implications of adding, or not adding, a feature to the system.

20. A Feature can be broken down into “building blocks”, which can in turn be broken down into “work tasks”. In fact, the functional decomposition of a Feature into lower level tasks is rather ad hoc, and depends on the complexity of each individual Feature. As the level of break-down increases, the lower levels will be defined in progressively more technical terms. The number of levels of decomposition should be sufficient to allow reasonably accurate estimation and progress tracking of the work. The number of levels should be restricted by this aspect, and not continued to artificially deep nesting simply because further breakdown is possible; it is only necessary to go into sufficient detail to allow a reasonably accurate degree of project management.

21. The standardization activity is typically arranged into the well-known three stages. Defines the service aspects of a feature (or part thereof) from the end-user's point of view. Stage 1 Defines the logical functionality and information flows amongst the functional entities involved in providing the service. Stage 2 Specifies any necessary functionality of physical entities (equipment) and the detailed protocols of the signalling between them. Stage 3

22. For complex Features, stage 1 may be preceded by a feasibility study ("stage 0") to analyse the market and potential technical difficulties of a given service or approach. The results are generally captured in 3GPP-internal reports forming the foundation for subsequent concrete standardization work. The term “study item” is frequently used for the feasibility study stage, and “work item” used only for the concrete specification activity. However, the term “work item” officially covers all types. Study item WIs may be completed in one Release but the concrete specification work conducted in the following Release.

23. Stage 1 specifications are normally produced by TSG SA1, and stage 2 specifications by SA2, though the stage 2 may need specialist knowledge from other TSGs' working groups.

24. A separate stage 3 specification will be required for each protocol concerned with providing the service, which may well impact the whole equipment chain from User Equipment, through the Radio Access Network, to the Core Network, and on to network management interfaces, and to fixed networks. The service may require new codecs and new security measures. Depending on the nature of the Feature, it may only be necessary to change existing specifications rather than to create completely new ones. This is particularly so at stage 3, where the service has to co-exist with all other services. However, this will vary from case to case.

25. Feature Y Feature X Feature Z Stage 1 Stage 1 Stage 1 Stage 2 Stage 2 Stage 2 Stage 3 Stage 3 Stage 3 Each feature has the three stages. Stage 1 usually requires the production of new TSs. Stage 2 can normally be reflected by change requests to existing architecture specs. Stage 3 may also require new TSs but may simply be implemented by a number of change requests to existing protocol TSs.

26. Further stages not originally envisaged by CCITT are the development of Operations and Maintenance (O&M) specifications (mainly within SA5) and of Test specifications. Whilst O&M specs can be developed more or less at the same time as the stage 3 protocols, it is usually prudent to wait until the protocols are fairly stable (i.e. field tested) before embarking on detailed test specifications. Thus whilst the O&M specs may be only six months behind the stages 3, the test specs follow a year or more later.

27. Feature X Stage 1 Stage 2 Stage 3 Development of the TSs and CRs needed to implement each feature starts with stage 1, progresses to stage 2, and concludes with stage 3.

28. Feature X Stage 1 Stage 2 Stage 3 In practice, there is feedback from stage 2 to stage 1 and from stage 3 to stage 2 (and even from stage 3 to stage 1), so the real progress is more like this:

29. Feature Y Feature X Feature Z Stage 1 Stage 1 Stage 1 Stage 2 Stage 2 Stage 2 Stage 3 Stage 3 Stage 3 Overall progress is estimated and monitored by the sum of the individual features.

30. For good technical and commercial reasons, a “freeze” date is set for each Release. At the point of freezing a Release, the list of features to be included in the Release has already been fixed, and any features under development which cannot be completed within an agreed time frame are postponed to a later Release. A feature is “completed” when all its component specifications are stable enough to be published by the SDOs and implemented by equipment manufacturers and network operators. Prior to “freezing”, the following milestones must have been achieved:

31. Prior to “freezing”, the following milestones must have been achieved: • The features to be included in the Release will have been determined. (And any features which are to be delayed to a later Release will have been identified.) • For each feature, the stage 1 specifications must have been completed. • In addition, the stage 2 specifications should have been completed, or very nearly so. • Further, the stage 3 specifications should have been completed, or are planned to be completed within a fairly short time span.

32. Feature Y Feature X Feature Z Stage 1 Stage 1 Stage 1 Stage 2 Stage 2 Stage 2 Stage 3 Stage 3 Stage 3 Release frozen

33. The justification for these requirements is that • It must be declared which features are provided by the new Release (and which are not). • It must be clear what benefits each new feature will bring to users (i.e. the stage 1 specs must be stable). • It must be clear that the feature can be implemented with no fundamental obstacle (i.e. the stage 2 specs must be reasonably stable). • The protocols needed to implement the features must be available, or at least it must be clear when they will be available (i.e. the stage 3 specs must be reasonably well developed and a definite target date envisaged for them to be considered stable enough to implement with acceptable commercial risk).

34. At the moment of freezing the Release, all outstanding issues for each feature must be identified, and target dates set for their resolution. All specs should be planned to be stable within a reasonably short time – say six months (two plenary meetings) at the most.

35. Feature X Feature Y Feature Y Feature X Feature Z Stage 1 Stage 1 Stage 1 Release N Stage 2 Stage 2 Stage 2 Feature Z Stage 3 Stage 3 Stage 3 In summary: Release N+1 frozen Outstanding issues identified and lead time to “completion” planned. All specs available, under change control, and stable.

36. Feature Y Feature X Feature Z Stage 1 Stage 1 Stage 1 Stage 2 Stage 2 Stage 2 Stage 3 Stage 3 Stage 3 An “exception sheet” will be prepared (by its rapporteur or the responsible WG chairman) for each Feature which cannot be completed on time: Release N+1 frozen Exception

37. Feature Y Feature X Feature Z Stage 1 Stage 1 Stage 1 Stage 2 Stage 2 Stage 2 Stage 3 Stage 3 Stage 3 This slightly dilutes the concept of “freezing”, but has been found to be useful in practice. Release N+1 frozen Exception

38. Feature Y Feature X Feature Z Stage 1 specs frozen Stage 2 specs frozen Stage 3 specs frozen Stage 1 Stage 1 Stage 1 Stage 2 Stage 2 Stage 2 Stage 3 Stage 3 Stage 3 For the last few Releases, it has been found desirable to explicitly freeze each stage in turn.

39. Active project management

40. Active project management 3G Release 99 contained more or less the same functionality as GSM R99, but of course using the new UTRA radio access network technology (W-CDMA). The 3GPP work plan can be consulted at: http://www.3gpp.org/ftp/Information/WORK_PLAN/

41. Release 4

42. Release 5

43. Release 6

44. Take a closer look at the project management techniques …

45. Take a closer look at the project management techniques …

47. The work plan is reviewed at every TSG SA meeting …

49. Every Feature (top level functional enhancement) is examined in sufficient detail to ensure that • Its definition is (still) correct, and that • It is making adequate progress according to plan.

50. Its Work Item Definition sheet is updated if necessary and re-issued as a TSG meeting document. This is the document which will be referred to in the next issue of the Work Plan. The Work Item Definition sheets are re-issued after each TSG SA meeting. You can find them at http://www.3gpp.org/ftp/Information/WI_Sheet .