920 likes | 936 Views
WPM is an application program used by ETSI to track all technical work conducted by ETSI technical bodies, including partnership projects such as 3GPP. This presentation provides an overview of the WPM application and its features.
E N D
Work Programme Management WPM What’s behind the icon?
WPM is an application programme running on the ETSI corporate network. It provides access to the ETSI central database used for tracking all technical work conducted by ETSI technical bodies – including partnership projects such as 3GPP. A simplified, read-only, version of WPM is available via the web for external browsing: http://webapp.etsi.org/WorkProgram/Expert/QueryForm.asp This presentation deals with the ETSI-internal application and is intended primarily for the benefit of MCC personnel.
WPM uses ETSI nomenclature which differs in some respects from 3GPP nomenclature, and this can lead to confusion … WPM term Work Item project : : : 3GPP term specification / spec work item You have been warned!
On opening WPM, you are confronted with the “Work Item Select”window.
There are three tabs with a variety of fields you can use to select the Work Item records of interest.
Tab 1: fields related to the identity and ownership of the items • Reference id • Deliverable type / number • Responsible committee / working group
Tab 2: sundry fields • Title • STF • Current state (drafting, in Public Enquiry, published, etc.) • EC mandate
Tab 3: relational fields and rapporteur • Keywords (AND combination possible) • Projects (AND combination possible) • Rapporteur (editor) name
In addition, it is possible to distinguish between “active” and “stopped” items. • “Active” includes completed items (published deliverables) – even those which have been withdrawn. It is not restricted only to items which are still being worked on.
For 3GPP work, WPM holds two types of records … The first is the “generic” record. There is one record per spec per Release. The second is the “deliverable-specific” record. There is one record per spec version published by ETSI.
Consider first the GENERIC records … These have the deliverable type “3TS” or “3TR”, depending on whether the underlying 3GPP document is a Technical Specification or a Technical Report.
For example, take 3GTS 22.002. Record for Release 1999 (version 3.y.z) Record for Release 4 (version 4.y.z)
Release 1999 record has Reference ending in “v3”. Release 4 record has Reference ending in “v4”. D = original document R = revision (i.e. subsequent release) TS or TR The spec number Working Group
1st line of title is always “3rd Generation Partnership Project”. 2nd line of title is always the full name of the responsible TSG. 4th line of title is the technical part of the title of the spec (only). 3rd line of title is the technical part of the title of the spec, followed by the Release identity in parentheses. Scope field should bear a technical description of the work to be performed – or if not available, just a copy of the working title.
When a new version in the same Release of the spec is produced – normally by the approval of a Change Request …
Open the record for update. 2. Choose “user-specified milestone” procedure. 3. Select the last line of the schedule. 4. Insert new milestone.
4. Enter the milestone name in the form “TSG#n” or, for GERAN, “GERAN#n”where “n” is the meeting number. In the case of the “usual” meeting arrangement whereby TSGs RAN, T and CN meet concurrently, followed by TSG SA the following week, the date entered should be, for all specs regardless of “ownership”, the day after the end of the SA meeting. 5. Enter the new version number of the spec. 6. Enter as target date the day after the last day of the meeting which approved the CR.
7. Check that the rapporteur’s name is correct.Verify it by comparing it with that shown in the MCC database.
8. When the spec has been made available in the Specs area of the 3GPP file server (and not until!), enter the date this was achieved.The difference between the target date and the achieved date is used for statistical performance checking.
When a version corresponding to a new Release of a spec is first created, it is necessary to create a new record. (Remember, one record per spec per Release.) 1. Open the existing record for the previous Release.
5. Check that the WG is correct.If it is not, you need to change it in the previous Release(s) record(s) too! 8. Do not copy comments. 6. Schedule setting = “default”. 4. Change the last digit to correspond to the version number for this Release. 7. VERY IMPORTANT!Select option “Revision”. 2. Change D to R if necessary. 3. Document type should be already correct.
9. Other fields should be OK.Duplicate! 10. And confirm.
13. Edit the title to show the correct Release. 12. Enter spec number.(Gets lost during the copying process for some unknown reason.)
16. Select surplus milestones in schedule ... 18. Confirm. 17. … and delete them.
21. Save. 20. Add a remark: “Record created”.
The remaining procedures are as for updating an existing record …
22. Enter the milestone name in the form “TSG#n” or, for GERAN, “GERAN#n”where “n” is the meeting number. 24. Enter as target date the day after the last day of the meeting which approved the CR. 23. Enter the new version number of the spec.
26. When the spec has been made available in the Specs area of the 3GPP file server enter the date this was achieved.
For 3GPP work, WPM holds two types of records … The second is the “deliverable-specific” record. There is one record per spec version published by ETSI.
Consider now the DELIVERABLE-SPECIFIC records … These have the deliverable type “TS” or “TR”, depending on whether the underlying 3GPP document is published as an ETSI Technical Specification or an ETSI Technical Report.
Click “Duplicate” to create a new WI record based on the present one.
Deliverable class: “R” indicates a revision of an existing item. Only use “D” for a brand new deliverable document (spec).
Deliverable type: will probably be same as previous: TS = Technical SpecificationTR = Technical Report
Serial number: use existing value modified according to these rules:
If moving to a new year’s release, increment the number at the end. This shows the major version number. Here we see 03.46 v7.x.x i.e. release 1998. Change this to 8 for a release 1999 spec i.e. 03.46 v8.x.x . Rule 1 0346Q7 0346Q8
If providing an update to an existing release, add a suffix R1. If there is already a suffix R1, change it to R2. (Or change R2 to R3, etc..) Here we see 03.46 v7.0.0 (say) being changed to 7.1.0 (say). Rule 2 0346Q7 0346Q7R1
Leave the creation date as the current date unless there is some very good reason to change it.