ࡱ > /
bjbj j1gj1g @ [ 0. 0. . . . . . . 8 / 5 L . 49 .C ( VC VC nC W " +f | j @ $ Z . p V | W p p 0. 0. VC nC d x x x p 0. l VC . nC x p x x B . , w VC > r j f y , ` v V s ( w 6 V 4 $ . l V =n x 1o o l l l Gv l l l p p p p l l l l l l l l l X , : 3GPP TSG SA WG5 Meeting #141-e S5-221059
E-meeting, 17-26 January 2022 revision of S5-216250
Source: Nokia, Nokia Shanghai Bell
Title: SA5 Working Procedures (Version 17.6.0)
Document for: Approval
Agenda Item: 5.1 - Administrative issues at SA5 level
Contents
TOC \o "1-3" \h \z \u HYPERLINK \l "_Toc84325670" 1 Scope PAGEREF _Toc84325670 \h 3
HYPERLINK \l "_Toc84325671" 2 3GU PAGEREF _Toc84325671 \h 3
HYPERLINK \l "_Toc84325672" 3 Deadlines for contributions to a meeting PAGEREF _Toc84325672 \h 3
HYPERLINK \l "_Toc84325673" 4 Revisions of contributions before the meeting PAGEREF _Toc84325673 \h 3
HYPERLINK \l "_Toc84325674" 5 Revisions of contributions during the meeting PAGEREF _Toc84325674 \h 4
HYPERLINK \l "_Toc84325675" 6 Late contributions PAGEREF _Toc84325675 \h 4
HYPERLINK \l "_Toc84325676" 7 Templates for contributions PAGEREF _Toc84325676 \h 4
HYPERLINK \l "_Toc84325677" 8 SA5 email lists PAGEREF _Toc84325677 \h 5
HYPERLINK \l "_Toc84325678" 9 SA5 email threads for post-meeting email discussion/approval PAGEREF _Toc84325678 \h 5
HYPERLINK \l "_Toc84325679" 10 Post-meeting email approvals PAGEREF _Toc84325679 \h 5
HYPERLINK \l "_Toc84325680" 11 LS handling in SA5 PAGEREF _Toc84325680 \h 6
HYPERLINK \l "_Toc84325681" 12 DraftCRs PAGEREF _Toc84325681 \h 6
HYPERLINK \l "_Toc84325682" 13 CR handling PAGEREF _Toc84325682 \h 10
HYPERLINK \l "_Toc84325683" 14 Process for management of draft TS/TRs PAGEREF _Toc84325683 \h 10
HYPERLINK \l "_Toc84325684" 15 CR and pCR naming rules PAGEREF _Toc84325684 \h 10
HYPERLINK \l "_Toc84325685" 16 WID management PAGEREF _Toc84325685 \h 11
HYPERLINK \l "_Toc84325686" 17 Management of IS-SS version link (applies to pre-5G IRP TSs) PAGEREF _Toc84325686 \h 11
HYPERLINK \l "_Toc84325687" 18 Allocation of specification numbers PAGEREF _Toc84325687 \h 11
HYPERLINK \l "_Toc84325688" 19 Interactions with EditHelp PAGEREF _Toc84325688 \h 11
HYPERLINK \l "_Toc84325689" 20 Guidelines for 28-series TS structure PAGEREF _Toc84325689 \h 12
HYPERLINK \l "_Toc84325690" 21 Work plan structure and Work Item codes used in CRs PAGEREF _Toc84325690 \h 12
HYPERLINK \l "_Toc84325691" 22 E-meetings PAGEREF _Toc84325691 \h 13
HYPERLINK \l "_Toc84325692" 23 3GPP Forge process for SA5 PAGEREF _Toc84325692 \h 13
HYPERLINK \l "_Toc84325693" 23.1 Introduction PAGEREF _Toc84325693 \h 13
HYPERLINK \l "_Toc84325694" 23.2 Stage 3 Solution sets PAGEREF _Toc84325694 \h 13
HYPERLINK \l "_Toc84325695" 23.3 Roles in the 3GPP Forge process PAGEREF _Toc84325695 \h 13
HYPERLINK \l "_Toc84325696" 23.4 3GPP Forge process for CR PAGEREF _Toc84325696 \h 14
HYPERLINK \l "_Toc84325697" 23.5 YANG corrections by Code Moderator PAGEREF _Toc84325697 \h 17
HYPERLINK \l "_Toc84325698" 23.6 Notification when ready PAGEREF _Toc84325698 \h 17
HYPERLINK \l "_Toc84325699" 23.7 Branching strategy (void) PAGEREF _Toc84325699 \h 17
HYPERLINK \l "_Toc84325700" 23.8 Clean-up policy PAGEREF _Toc84325700 \h 17
HYPERLINK \l "_Toc84325701" 23.9 DraftCR Forge process PAGEREF _Toc84325701 \h 17
HYPERLINK \l "_Toc84325702" 24 Stage 2 / Stage 3 alignment principle PAGEREF _Toc84325702 \h 17
HYPERLINK \l "_Toc84325703" ANNEX: Useful Links PAGEREF _Toc84325703 \h 18
1 Scope
This document describes the working procedures in SA5. This is a complement to the 3GPP working procedures, and in any case of an inconsistency between the two sets of procedures, the 3GPP working procedures always take precedence.
Throughout this document the following abbreviations are sometimes used: CH which stands for Charging and OAM which stands for OAM&P (Operations, Administration, Maintenance and Provisioning).
2 3GU
3GPP MCC (Mobile Competence Centre) maintains an advanced administrative tool named 3GPP Ultimate Portal (3GU) which is used to manage all meeting contributions (allocation of Tdoc numbers, uploading, revisions, CR numbers etc.), specifications, meetings and work plan.
The following link takes you to a full description of 3GUs capabilities and how to use it: HYPERLINK "https://www.3gpp.org/3gu" https://www.3gpp.org/3gu.
3 Deadlines for contributions to a meeting
The normal deadline for Tdoc number reservation for all contributions is Friday 16:00 GMT, the week before the meeting. After this deadline, MCC shall generate the meeting document list and allocate Tdoc numbers manually.
The normal document submission deadline for CH and OAM contributions is Friday 23:59 GMT, 10 days before the meeting.
The normal document submission deadline for SA5 plenary contributions is Monday 23:59 GMT, the week before the meeting.
Late contributions or contributions modified after the submission deadline may not be dealt with during this meeting. See clause 6.
Exceptions to the normal deadlines may be announced by the chair, and the chair normally sends out an email to the SA5 email list announcing the deadlines before every meeting.
4 Revisions of contributions before the meeting
As an alternative to creating a new contribution, on the pop-up window, you can choose to revise an existing contribution. How to do that in 3GU, see HYPERLINK "https://protect2.fireeye.com/url?k=197550fa-45a15853-19751061-865b3b1e120b-61d2ae6d273e3bac&q=1&u=https%3A%2F%2Fwww.3gpp.org%2F3gu" https://www.3gpp.org/3gu.
Note that the original contribution need not be a contribution to the same meeting but could be from any previous meeting of the group - or indeed, from any other 3GPP group, as long as 3GU can identify it.
Note that if you choose to revise a contribution from a previous meeting, you have to take care that the decision on the original contribution was not final. For example, if the original contribution was a CR, then its status would ideally have been "postponed", allowing decision in a later meeting.
In any case, it is not permitted to revise at working group level a contribution which has already been definitively concluded at TSG level: that is, already bears a TSG status of "approved" or "rejected". In such a case, a new contribution (with new CR number, if applicable) must be created, not a revision of the original.
Revisions created after the deadline may be considered as late contributions. See clause 6.
In case of addition of co-signing companies after the submission deadline, it is recommended not to revise the document already uploaded on the 3GPP server otherwise it will become a late contribution (see clause 6). The update of the source company in 3GU can only be done before document upload, or otherwise it can be done manually by MCC during the SA5 meeting.
5 Revisions of contributions during the meeting
Document revisions may be created during the meeting by using a new Tdoc number. To obtain a new Tdoc number during the meeting delegates must contact the MCC secretary. Changes should be clearly indicated on the revised document and a version with revision marks should be provided.
Cases where document revisions may be needed are when there has been offline discussion that can help reaching agreement, when an error is identified in the contribution or following discussion in a formal session.
When the revised contribution is to be re-discussed during the second round of discussion of documents, delegates should upload the revision in the Drafts folder contained in the Inbox of the meeting server using the following file naming convention: S5-12xyzwdN Tdoc title.doc (no zip file) where S5-12xyzw is the Tdoc number and N is the number of version of the draft. For the first version of the draft, N shall be equal to 1.
If the draft document is agreed or noted with no changes, the delegate shall change the name of the document to S5-12xyzw Tdoc title.doc, zip it to S5-12xyzw.zip, and shall upload the zip file up to the Inbox folder. The MCC secretary will then move the document to the Docs folder.
If the document requires more modifications, the delegate shall produce an update, increment the version of the draft and place the update in the Drafts folder (this step may be repeated as needed). At the end of the round of discussions (whether the document is agreed or not), the delegate shall change the name of the latest version of the draft document to S5-12xyzw Tdoc title.doc, zip it to S5-12xyzw.zip, and shall upload the zip file up to the Inbox folder. The MCC secretary will then move the document to the Docs folder.
For documents which are updated during the meeting but do not need a second round of discussion, it shall be possible to directly produce the final Tdoc S5-12xyzw Tdoc title.doc, zip it to S5-12xyzw.zip, and upload the zip file up to the Inbox folder. The MCC secretary will then move the document to the Docs folder.
Delegates should send an availability notification to the respective email list as soon as the revised contribution has been uploaded to the meeting server. It is not needed to attach the contribution to the notification e-mail. The notification email should indicate the title of the contribution (not only the Tdoc number) and the nature of the change.
Note: For e-meetings, handling of revisions is described in the e-meeting process (see clause 22).
6 Late contributions
The contributions modified or submitted after the deadline are treated as late contributions. The following basic principles apply:
Late contributions will only be addressed exceptionally.
Default = not addressed.
Delegates can raise (before or during the meeting) if they believe a late contribution has exceptional reasons for being addressed. The chair can then propose, and the group needs to agree, whether to address the contribution or not.
If a late contribution is to be treated, it should be put at the end of the sequence list for the work item.
Of special importance is the following note from the 3GPP legal declaration: Timely submission of WID/SID proposals in advance of WG meetings is important to allow for full and fair consideration of such matters.
Note: For e-meetings, the late contribution policy is described in the e-meeting process (see clause 22).
7 Templates for contributions
Templates for contributions are available under the respective meeting directory e.g. for 3GPPSA5#127: HYPERLINK "ftp://ftp.3gpp.org/TSG_SA/WG5_TM/TSGS5_127/Templates/" ftp://ftp.3gpp.org/TSG_SA/WG5_TM/TSGS5_127/Templates/
In addition, all 3GPP templates can be downloaded from a common folder on the 3GPP FTP server:
HYPERLINK "https://protect2.fireeye.com/url?k=a809a74f-f4ddabbe-a809e7d4-864685b2085c-d906dd4ab7bbfa59&q=1&u=https%3A%2F%2Fwww.3gpp.org%2Fftp%2FInformation%2FAll_Templates%2F" https://www.3gpp.org/ftp/Information/All_Templates/.Please make sure you use the latest templates for your contributions (CR, pseudo CR, Tdoc, WID, LS, TS, TR, etc.).
Please also make sure you use the latest TS/TR versions for your contributions, notably for CRs.
Contributions which do not satisfy minimal quality requirements may be discarded or handled with lower priority in order not to penalize good quality contributions.
8 SA5 email lists
SA5 has currently 3 active email lists (a.k.a. exploders):
HYPERLINK "mailto:3GPP_TSG_SA_WG5@LIST.ETSI.ORG"3GPP_TSG_SA_WG5@LIST.ETSI.ORG SA5 general issues
HYPERLINK "mailto:3GPP_TSG_SA_WG5_Charging@LIST.ETSI.ORG" 3GPP_TSG_SA_WG5_Charging@LIST.ETSI.ORG Charging issues
HYPERLINK "mailto:3GPP_TSG_SA_WG5_OAM@LIST.ETSI.ORG" 3GPP_TSG_SA_WG5_OAM@LIST.ETSI.ORG OAM issues
Those delegates who already have an EOL username and password should use the list management application to register HYPERLINK "http://webapp.etsi.org/TBMembershipList/home.asp" http://webapp.etsi.org/TBMembershipList/home.asp.
It is possible to apply for an EOL account at: HYPERLINK "http://webapp.etsi.org/createaccount/" http://webapp.etsi.org/createaccount/.
If you have any problems subscribing to the lists, please send an email to the MCC secretary or to the SA5 chair.
The following lists are not used anymore but archives are still available at HYPERLINK "http://list.etsi.org/archives/" http://list.etsi.org/archives/:
HYPERLINK "http://list.3gpp.org/3gpp_tsg_sa_wg5_swga.html"3GPP_TSG_SA_WG5_SWGA
HYPERLINK "http://list.3gpp.org/3gpp_tsg_sa_wg5_swgb.html" 3GPP_TSG_SA_WG5_SWGB
HYPERLINK "http://list.3gpp.org/3gpp_tsg_sa_wg5_swgc.html" 3GPP_TSG_SA_WG5_SWGC
HYPERLINK "http://list.3gpp.org/3gpp_tsg_sa_wg5_swgd.html" 3GPP_TSG_SA_WG5_SWGD
9 SA5 email threads for post-meeting email discussion/approval
In order to identify post-meeting email threads (i.e. not e-meeting threads), a thread identifier should be used for email approvals or email discussions on SA5 exploders. All emails within a thread should start with the same thread identifier to allow traceability.
For documents identified by a Tdoc number, the Tdoc number should be used as thread identifier. In case a group of documents is discussed or approved by email as a package, the Tdoc number of the primary document can be used, the primary document being the root document e.g. a CR on Requirements in a set of CRs.
In case no Tdoc number is available, a specific tag should be defined for the thread identifier.
The email subject should include the thread identifier, preferably preceded by the SA5 meeting number.
Here are some examples of recommended email subjects:
- [SA5#101] S5-153285 Email approval of pCR 28.682 Addition of xxx
- [SA5#102] S5-154286 Email approval of CR 32.102 Modification of yyy
- [SA5#103] S5-155287 Email discussion on WID Study of zzz
- [SA5#104] S5-156288 Email approval of draft TR 32.849 V1.4.0
10 Post-meeting email approvals
Any post-SA5 meeting OAM/Charging email approvals have to be confirmed by the SA5 closing plenary.
All documents from SA5-level agenda items (i.e. normally 5.x) for email approval shall be submitted to the general SA5 exploder. The moderator of all email approvals on the SA5 exploder is the SA5 chair. All documents from OAM- and Charging agenda items for email approval shall be submitted to the respective OAM/CH exploder, even if they are for SA5 level approval (like CRs and WID/SIDs).The moderator of all OAM- and Charging-level email approvals is appointed by the SA5 chair.
The time window for all email approvals agreed by the SA5 plenary to be held, with some exceptions, opens immediately when the SA5 meeting is closed and ends on the first Friday after the SA5 meeting, 23:59 GMT. Thus, all documents for email approval should normally be sent out latest by EOB the first working day after the SA5 meeting. Exceptions to this rule typically apply for latest draft TS/TRs which have to include pCR(s) under email approval.
Extensions of the normal deadline may also be decided by the chair or the moderator of the email approval, e.g. when comments or updates have been made close to the deadline or when it is judged that more discussion can help to reach an agreement.
All email approvals including their deadlines and conclusions will be listed in the Post SA5#xyz Email approval status document sent out after every meeting.
Only exceptions to the normal deadlines will be announced by the chair or the moderator of the email approval, and the author sending out the document under email approval shall not state anything about the deadline to avoid the risk for inconsistent information.
Documents sent for email approval shall use the following file naming convention: S5-18xyzwdN
.doc where S5-18xyzw is the Tdoc number and N is the version number of the draft. A zip file S5-18xyzwdN.zip shall be produced and sent to the exploder by the author of the document under email approval as soon as possible after the email approval window has opened. Note that the thread identifier is independent of the version N and should always be S5-18xyzw. For the first version of the draft, N shall be equal to 1. If the document requires modifications during the email approval, the author shall increment the version of the draft (this step may be repeated as needed).
At the end of the email approval (whether the document is agreed or not), the moderator sends an email declaring the conclusion, and subsequently the author shall change the name of the latest version of the draft document to S5-18xyzw Tdoc title.doc, zip it to S5-18xyzw.zip, and submit it as the final version to the exploder. The MCC secretary will then upload it to the 3GPP folder.
11 LS handling in SA5
As soon as received, new input LSs for the upcoming SA5 meeting are registered by MCC in 3GU and published on the following page: HYPERLINK "https://www.3gpp.org/Liaisons/Incoming_LSs/S5-meeting.htm" https://www.3gpp.org/Liaisons/Incoming_LSs/S5-meeting.htm. When there is an ad hoc meeting before the next SA5 plenary meeting, new input LSs may be registered for this ad hoc meeting if there is a corresponding agenda item.
All resubmitted LSs from previous meeting will be registered by MCC for the upcoming meeting in the same way as new LSs i.e. with a new Tdoc number. The title in 3GU will clearly show that this is a resubmitted LS. The allocation of all LSs (new and resubmitted) to the correct agenda item is prepared by the SA5 leadership and reviewed during the SA5 opening plenary session.
The output LSs sent inside 3GPP may be approved at OAM/CH level while all other LSs are to be approved by SA5 plenary. Output LS are distributed by the MCC secretary as soon as possible after the meeting via the 3GPP Liaison officer. A summary list of all output LSs from the meeting is sent to the SA5 exploder by the MCC secretary as soon as possible after the meeting.
12 DraftCRs
DraftCRs may be used when there are changes potentially impacting several parts of an existing TS and when the time needed to do those changes is expected to be more than one or two meetings. This has a lot of advantages even if it introduces a bit more work:
For features that result in many updates in one or more TSs that need several meetings to be completed, we can work entirely with draftCRs until all related content is carefully checked for quality and consistency and considered stable, and then submit one or more big CR for all changes. Thus, we dont publish incomplete or inconsistent TSs in the middle of the release (such as one TS referring to another which is not yet published in the current working release, e.g. Rel-17 for a Rel-17 WI). Another reason is that with current release CRs we will create new current release versions of all specs and force everybody to create mirrors for corrections in the previous release. The workload increases unnecessarily.
To avoid the DraftCRs becoming too complex and difficult to maintain, DraftCRs should be converted to CRs when they become very large or complex, and it is recommended to use DraftCRs mainly for new (added) clauses/subclauses because it makes it easier to maintain the baseline.
It is up to each company to decide whether they want to propose an (input to) DraftCR or a real CR to modify or add new features in a TS, and it is (as always) a group decision if the contribution is agreed or needs to be converted to another type.
The following text describes the process for DraftCRs.
DraftCRs are like draft specs (TS/TRs).
Input to draftCRs is like a pCR but with document type other and using a CR cover page (but with no CR#), and we call them Input to DraftCR not to confuse them with pCRs for draft TS/TRs. You specify in the Other comments on the cover page for which DraftCR you are giving input (e.g. This is input to the Rel-17 28.541 DraftCR for ).
The initial version of the DraftCR is created at the SA5 meeting to which the first Input to DraftCR has been approved for a particular work item and TS. Further updates shall be based on the latest agreed version of the DraftCR (baseline) using Input to DraftCR contributions (doc type: other). If more than one work item/feature trigger updates to the same TS, there should be one DraftCR for each work item. If there are two quite separate topics in the same WI, then one DraftCR per topic (and TS) could also be created. The title of the DraftCR should then be like Rel-17 28.5xx DraftCR for .
New changes compared with the DraftCR baseline should be clearly identified in the input contributions. For this purpose, new revision marks in input contributions should use a different author signature than the revision marks already present in the DraftCR. The input contributions and the DraftCR shall only include the changed clauses of the TS.
After the meeting, the approved Input to DraftCR contributions (*) are merged in the first or revised DraftCR by the work item rapporteur and then the DraftCR is sent for email approval. The post-meeting update shall keep track of all the changes compared with the TS baseline but does not necessarily need to distinguish the various authors of the changes. A list of the Tdoc numbers of the successive versions of the DraftCR and the agreed input contributions shall be added in the cover page of the DraftCR (in Reason for Change), and shall be removed when converting the DraftCR to a formal CR.
(*) If only one Input to DraftCR contribution was approved the first time the DraftCR is created, no email approval is needed the DraftCR can be produced and approved directly based on the approved contribution. Note however that the DraftCR needs a new Tdoc number, as the document type (DraftCR) and cover page is different.
The DraftCR needs to be updated to be aligned with the latest TS baseline if the latter has changed before the next upcoming SA5 meeting due to some SA-approved CR(s). In that case, a new dedicated email review (no need for email approval) of the updated DraftCR shall be started right after the CR implementation and finished before 3GU is opened for the next SA5 meeting. This updated DraftCR should be announced on the relevant OAM/CH email exploder; most important is to have it ready and announced when 3GU is opened so that new inputs to the DraftCR can be produced based on the correct baseline. Then the DraftCR should also be submitted as a contribution to the meeting for easier tracking. We propose to name the updated DraftCR as DraftCR for - TS xy.abc, for example DraftCR for EMA5SLA - TS 28.540.
An approved DraftCR means that the group has agreed with the current content of the draft. It is still possible to change its content with a new written contribution, but just like for a draft TS/TR it needs to be well justified.
Once the final DraftCR is considered stable and is approved, the rapporteur or author takes out a new tdoc number of type CR and assigns a formal CR number. Another reason for doing this conversion could also be if the DraftCR has become very large and difficult to maintain. The content of the CR is identical to the DraftCR (keeping in mind that changes on changes are not allowed), but the cover page shall look like a normal CR summarising all changes etc., and not refer to any earlier input tdocs to the DraftCR (however the Other comments should mention that the CR is produced from the approved DraftCR S5-xyzabc). The conversion from DraftCR to CR shall be done without rediscussing the technical contents of the CR, as this is already agreed on SA5 level. It is recommended that this is done latest at the last-but-one SA5 meeting before the target date of the work item, to have some margins to correct any errors found. Then, the usual CR approval process will apply: agreement during SA5 closing plenary (or by email approval if needed), and submission to SA for approval.
A dedicated document will be produced by the SA5 leadership during every SA5 meeting to track all the DraftCRs, their input contributions and status.
Finally, there is also a 3GPP Forge process requirement for DraftCRs see clause 23.9.
Example cover sheets
Input to DraftCR cover sheet EXAMPLE (Note: doc. type in 3GU = other, no CR number, title = normal CR title and see Other comments):
3GPP TSG- DOCPROPERTY TSG/WGRef \* MERGEFORMAT SA5 Meeting # DOCPROPERTY MtgSeq \* MERGEFORMAT 133 DOCPROPERTY MtgTitle \* MERGEFORMAT -e DOCPROPERTY Tdoc# \* MERGEFORMAT S5-205abc
DOCPROPERTY Location \* MERGEFORMAT Online, DOCPROPERTY Country \* MERGEFORMAT , DOCPROPERTY StartDate \* MERGEFORMAT 12th Oct 2020 - DOCPROPERTY EndDate \* MERGEFORMAT 21st Oct 2020
CR-Form-v12.1CHANGE REQUEST DOCPROPERTY Spec# \* MERGEFORMAT 28.541CR DOCPROPERTY Revision \* MERGEFORMAT -rev DOCPROPERTY Revision \* MERGEFORMAT -Current version: DOCPROPERTY Version \* MERGEFORMAT 17.0.0For HYPERLINK "http://www.3gpp.org/3G_Specs/CRs.htm" \l "_blank" HELP on using this form: comprehensive instructions can be found at HYPERLINK "http://www.3gpp.org/Change-Requests" http://www.3gpp.org/Change-Requests.
Proposed change affects:UICC appsMERadio Access NetworkCore NetworkX
Title: DOCPROPERTY CrTitle \* MERGEFORMAT GST ConfigurationSource to WG:ABCSource to TSG:S5 DOCPROPERTY SourceIfTsg \* MERGEFORMAT Work item code: DOCPROPERTY RelatedWis \* MERGEFORMAT EMA5SLADate: DOCPROPERTY ResDate \* MERGEFORMAT 2020-10-01Category: DOCPROPERTY Cat \* MERGEFORMAT CRelease: DOCPROPERTY Release \* MERGEFORMAT Rel-17Use one of the following categories:F (correction)A (mirror corresponding to a change in an earlier release)B (addition of feature), C (functional modification of feature)D (editorial modification)
Detailed explanations of the above categories canbe found in 3GPP HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/21900.htm" TR 21.900.Use one of the following releases:Rel-8 (Release 8)Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11)Rel-15 (Release 15)Rel-16 (Release 16)Rel-17 (Release 17)Rel-18 (Release 18)Reason for change:Section L.2 says: Some of the information in 5GC SliceProfile and NG-RAN SliceProfile is translated to configurable parameters of network function for the control plane SLA support purpose. This need to be further extended with respect to identifying GST attributes that will be translated into configurable parameter
Summary of change:Existing ANNEX is extended to include crucial aspect of GST management.Consequences if not approved:In-complete GST management solution.Clauses affected:LYNOther specs Other core specifications TS/TR ... CR ... affected: Test specificationsTS/TR ... CR ... (show related CRs) O&M SpecificationsTS/TR ... CR ... Other comments:This is input to the Rel-17 28.541 DraftCR for DOCPROPERTY RelatedWis \* MERGEFORMAT EMA5SLAThis CR's revision history:
DraftCR cover sheet EXAMPLE (Note: doc. type in 3GU = draftCR, no CR number, and title = DraftCR):
3GPP TSG- DOCPROPERTY TSG/WGRef \* MERGEFORMAT SA5 Meeting # DOCPROPERTY MtgSeq \* MERGEFORMAT 134e DOCPROPERTY MtgTitle \* MERGEFORMAT DOCPROPERTY Tdoc# \* MERGEFORMAT S5-206def
16-25 November 2020, E-meeting
CR-Form-v12.0CHANGE REQUEST DOCPROPERTY Spec# \* MERGEFORMAT 28.552CR-rev-Current version: DOCPROPERTY Version \* MERGEFORMAT 17.0.0For HYPERLINK "http://www.3gpp.org/3G_Specs/CRs.htm" \l "_blank" HELP on using this form: comprehensive instructions can be found at HYPERLINK "http://www.3gpp.org/Change-Requests" http://www.3gpp.org/Change-Requests.
Proposed change affects:UICC appsMERadio Access NetworkxCore Networkx
Title: DraftCR for WI ePM_KPI_5GSource to WG:ABCSource to TSG:S5 DOCPROPERTY SourceIfTsg \* MERGEFORMAT Work item code:ePM_KPI_5GDate:2020-11-26Category: DOCPROPERTY Cat \* MERGEFORMAT BRelease:Rel-17Use one of the following categories:F (correction)A (mirror corresponding to a change in an earlier release)B (addition of feature), C (functional modification of feature)D (editorial modification)
Detailed explanations of the above categories canbe found in 3GPP HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/21900.htm" TR 21.900.Use one of the following releases:Rel-8 (Release 8)Rel-9 (Release 9)Rel-10 (Release 10)Rel-11 (Release 11)Rel-12 (Release 12)Rel-13 (Release 13)Rel-14 (Release 14)Rel-15 (Release 15)Rel-16 (Release 16)
Rel-17 (Release 17)Reason for change:This DraftCR incorporates the following agreed contributions under WI ePM_KPI_5G:
1. From DraftCR DOCPROPERTY Tdoc# \* MERGEFORMAT S5-205abc:
- S5-205xx1;
- S5-205xx2;
- S5-205xx3;
- S5-205xx4;
- S5-205xx5.
2. From DraftCR S5-206def:
- S5-206xx1
- S5-206xx2
The detailed reasons for change can be found in these contributions.
Summary of change:Add Intra/Inter-frequency Handover related measurements;
Add the measurements related to NIDD configuration on NEF.
Add the measurements related to NIDD service on NEF.
Add the measurements related to AF traffic influence on NEF.
Add the measurements related to external parameter provisioning on NEF.Consequences if not approved:The measurement of handover-related indicators is incomplete.
The performance of NIDD configuration cannot be monitored.
The performance of NIDD service cannot be monitored.
The performance of AF traffic influence cannot be monitored.
The performance of external parameter provisioning cannot be monitored.Clauses affected:2, 3.3, 5.1.1.6.a (new), 5.9.a (new), 5.9.b (new), 5.9.c (new), 5.9.d (new), A.17, A.a (new), A.b (new), A.c (new)YNOther specsx Other core specifications TS/TR ... CR ... affected:x Test specificationsTS/TR ... CR ... (show related CRs)x O&M SpecificationsTS/TR ... CR ... Other comments:This CR's revision history:
13 CR handling
The guidelines for the creation of Change Requests - CRs - can be found in the 3GPP Technical Specification Group Working Methods (TS 21.900) clause 4.6.
How to create CR contributions in 3GU including CR cover page and CR number allocation: See HYPERLINK "https://protect2.fireeye.com/url?k=197550fa-45a15853-19751061-865b3b1e120b-61d2ae6d273e3bac&q=1&u=https%3A%2F%2Fwww.3gpp.org%2F3gu" https://www.3gpp.org/3gu.
During the meeting the delegate must ask for the CR number directly to the MCC secretary.
Note: For a CR which has mirror(s), the mirror(s) must have the same WI code and be allocated to the same SA5 meeting agenda item as the original CR.
14 Process for management of draft TS/TRs
SA5 has a dedicated process for management of draft TS/TRs and related pCRs (pseudo CRs) before first approval of the TS/TR. This is described in a separate document; see the Process for management of draft TSs/TRs uploaded at every SA5 meeting under agenda item Administrative issues at SA5 level.
15 CR and pCR naming rules
CR naming rule: Rel-N CR .
This rule applies to the CR title in 3GU, to the CR file name, and (regarding the title only) to the CR title in the CR cover page, which shall all be aligned.
Example:
3GU title: Rel-12 CR 32.425 Addition of energy saving measurements
File name: S5-13abcd Rel-12 CR 32.425 Addition of energy saving measurements (zip file = S5-13abcd)
CR title on the CR cover page: Addition of energy saving measurements
In case of modification, the consistency between the title in 3GU/document list, the CR file name and the CR title on the CR cover page shall be maintained.
pCR naming rule: pCR
Example: pCR 28.813 Add measurement assumption for energy consumption
16 WID management
To start a new work/study item, a new WID/SID needs to be agreed by SA5 and then approved by the TSG SA plenary. Make sure to use the latest WID template in the Templates folder available for each meeting.
Only major changes of the WID/SID, such as modified Scope/Objective or Deliverables, shall cause a revised WID to be agreed by SA5 and sent to SA for approval. Change of expected completion date shall not be recorded in an updated WID/SID; this is done directly in the meeting reports and 3GPP Work Plan.
After completion of the work/study item, the 3GPP Work Plan manager will request the rapporteur(s) to provide a WI summary (a template for that is also found in the Templates folder).
17 Management of IS-SS version link (applies to pre-5G IRP TSs)
The process for updating the link from Solution Set (SS) to Information Service (IS), located in the Scope clause of all SA5 IRP (Integration Reference Point) specifications, is described as follows according to the various possible scenarios.
ScenarioProcessCR technical change on ISCR technical change on SSUpdate IS versionUpdate SS versionUpdate link from SS to ISCR technical change on ISNo technical change on SS Update IS versionUpdate link from SS to ISCR technical change on SSNo technical change on ISUpdate SS versionIf two SS versions point to same IS version, the latest SS version appliesCR editorial change on ISNo change on SSUpdate IS versionNo update on link from SS to IS
This process is applicable within one Release (a Rel-X SS cannot point to a Rel-Y IS).
At the end of each Release, CRs have to be produced to update the link from Solution Set to Information Service in case the Solution Set specification has not been updated during that Release.
18 Allocation of specification numbers
New TS/TR specification numbers for SA-approved WID/SIDs shall not appear in any SA5 documents (WIDs etc.) until they have been formally allocated by MCC (i.e. created in the TS database).
A new specification number can only be requested officially when the corresponding WID has been approved at TSG level. However, it is possible for the SA5 chair to send an unofficial request offline to MCC in advance of the TSG (SA) approval to start preparing for the TS allocation.
The SA5 chair shall request the allocation of new specification number(s) from MCC following the recommendation from the leadership, based on the SA5-agreed allocation of specification number ranges in clause 20 (below) of these SA5 working procedures.
19 Interactions with EditHelp
All draft specifications (TS, TR) should be submitted by the specification rapporteur to ETSIs EditHelp office to check for compliance with the 3GPP Drafting Rules, via email (edithelp@etsi.org) with the MCC technical officer in copy before submission to TSG SA for approval. Editorial corrections due to feedback from EditHelp are taken care of by MCC producing a version x.y.n of the draft specification.
The feedback from EditHelp shall also, in case on non-editorial errors found, trigger the creation of pCRs by the specification rapporteur to correct such errors. In order to be able to produce and approve such pCRs before TS/TR approval, each draft specification should be sent to EditHelp at the latest after the last but one SA5 meeting before the target TSG SA meeting.
In case this cannot be done and the draft specification is sent to SA without time to prepare the pCRs (e.g. sent for information and approval to the same SA plenary and there is no other SA5 meeting before the next SA plenary), it is the responsibility of the rapporteur to implement EditHelp's recommended changes in CRs to be prepared for the next SA5 meeting (or as soon as possible after the specification was published). Preferably, all TS/TRs sent for approval to SA should also be sent to EditHelp for a final quality check, even if EditHelp had checked it before.
It is the responsibility of the SA5 chair to check the work item progress on a regular basis with the specification Rapporteurs and determine the most appropriate time to send the draft specification to EditHelp.
If it is considered needed, a specification may also be sent to EditHelp before sending it to TSG SA for information. In that case, the same process will apply, allowing the production in due time of pCRs based on the feedback from EditHelp.
20 Guidelines for 28-series TS structure
The following list comprises a recommended high-level structure for the 28-series TSs:
28.0xx: Used for High-level/Concepts/Methodology specifications (note: 28.020 and 28.062 taken by other WG)
28.1xx: Used for 5G and future specifications
28.2xx: Used for Charging specifications
28.3xx: Used for pre-5G Interface IRP specifications
28.4xx: Used for Measurement & Trace Data definitions
28.5xx: Used for 5G specifications
28.6xx: Used for pre-5G NRM IRPs
28.7xx: Used for pre-5G NRM IRPs
28.8xx: Used for 3GPP-internal TRs
28.9xx: Used for 3GPP-external TRs
21 Work plan structure and Work Item codes used in CRs
SA5 has two categories of Work Items:
Work Items (usually Building Blocks) related to a 3GPP Feature from another group (RAN, SA2, etc.). In that case the SA5 Building Block is created under the appropriate Feature in the 3GPP Work Plan. This is only possible if the SA5 Building Block and the Feature from the other group pertain to the same 3GPP Release.
Work Items (usually Features) which are not related to another 3GPP Feature or are related to another 3GPP Feature but not in the same Release. Those Features are created in the 3GPP Work Plan as stand-alone Features.
This implies the following for the Work Item (WI) codes used in CRs:
From Rel-15 onwards, the WI codes CHx and OAMx (where x represents the ongoing Release) will not be created in the 3GPP Work Plan and shall not be used any more for CRs.
The WI code TEIx shall be used for CRs when there is no applicable past or existing WI code (or when the past WI code was CHx or OAMx).
The original WI code shall be used for CRs when the correction is done from the original Release onwards.
The WI code TEIx combined with the original WI code shall be used for CRs when there is a past WI code but the CR addresses only the current Release. See HYPERLINK "http://www.3gpp.org/wiki/index.php?title=2.%20A%20note%20on%20Work%20Item%20codes%20used%20on%20CRs&lang=en" 3GPP Wiki.
Additionally, it is recommended that any addition or enhancement of a feature (Category B CRs) should be done with a WID. This implies that TEIx should mainly be used for Category D or F CRs.
22 E-meetings
An e-meeting may replace an ordinary f2f meeting if some circumstances prevent many delegates from travelling to the meeting. The SA5 process for how the e-meeting shall be conducted is described in a separate document named e.g. SA5-xxxe E-Meeting Process.
23 3GPP Forge process for SA5
23.1 Introduction
3GPP MCC together with ETSI has developed a Gitlab-based set of online tools to create, share, collect, validate and publish machine readable content in a collaborative way, named 3GPP Forge, with the goal to accelerate the development processes and enhance the quality of delivered content.
The SA5 Forge repository start page is HYPERLINK "https://forge.3gpp.org/rep/sa5" https://forge.3gpp.org/rep/sa5
The SA5 Forge repository is entitled SA5 Management & Orchestration and Charging i.e. it covers both OAM and CH branches.
Note: The Forge process and related repository branches for CH related to TS 32.291 are yet TBD. When included, the clauses below should be restructured according to OAM/CH and general topics.
23.1.1 Important action-timeline table for Forge activities
ActionAction OwnerTimelineNnotesThe stage 3 code must be in Forge and validated by ForgeCR authorInitial change:
Contribution submission deadline
Final change:
Stage 3 change shall be implemented in Forge and validated before agreeing in SA5 meetingCopy commit SHA (example: "7f73c7e7", at least first 8 characters of the full SHA) as proofs into cover page.Send merge request from CR branch to integration branchCR authorTime Window of sending merge request:
Start: Wwhen CR is agreed in SA5 meeting
End: 3 working days after window startConsequence: Iif the CR author missed the merge request, the contributionCR shall be removed from the list of agreed listCRs.When the merge request shall be addressedCcode moderatorIdeally after the SA plenary,
Or before the SA plenary, like, after SA5 level agreement
6 working days after approval at SA5 level,
and 5 working days ahead of SA plenary meetingIthe ier,like.g.If it is done before the SA plenary, the following applies: merged CR might being removeding due to change in the SA plenary meeting.
Note: CR in the above table includes CR and pCR. Exception: When the pCR is for a draft TS not being sent for approval to SA, only the steps before SA apply.
23.2 Stage 3 Solution sets
The following solution sets are captured and verified in 3GPP Forge ( HYPERLINK "https://forge.3gpp.org/rep/sa5" https://forge.3gpp.org/rep/sa5) for the management services:
YAML
YANG
XML (For PM/Trace File schema) (Note: XML is not maintained in Forge at present)
23.3 Roles in the 3GPP Forge process
There are three different roles related to this activity, and they coordinate with each other to achieve the goal.
Contribution author
Code Moderator
Code Master
The following persons are assigned as Code Moderator for relevant stage 3 specifications:
TS 28.541
Sean Sun/Ruiyue Xu (YAML)
Balzs Lengyel (YANG)
TS 28.623
Sean Sun/Olaf Pollakowski (YAML)
Balzs Lengyel (YANG)
TS 28.532
Sean Sun/Anatoly Andrianov / Olaf Pollakowski /Xuruiyue (YAML)
(any volunteer?) (PM file format XML)
TS 28.550
Yizhi Yao (YAML)
TS 28.536
Jan Groenendijk (YAML)
TS 32.423
(any volunteer?) (Trace file format XML)
TS 32.291
(any volunteer?) (YAML)
23.4 3GPP Forge process for CR
Note 1: The process is applied to contribution which would impact stage 3 code (YAML and YANG are maintained in Forge at present).
Note 2: Forge process for draftCR is FFS
Step 0 - Preparing for an SA5 meeting
Contribution author prepares contribution, including stage 3 code with detailed line-by-line MS Word change marks, in tDoc.
Note 1: Contribution author doesn't need to change the OpenAPI header information in YAML file. Code moderator will change it accordingly in integration branch.
openapi: 3.0.1
info:
title: Slice NRM
version: 16.8.0
description: >-
OAS 3.0.1 specification of the Slice NRM
@ 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.
externalDocs:
description: 3GPP TS 28.541 V16.8.0; 5G NRM, Slice NRM
url: http://www.3gpp.org/ftp/Specs/archive/28_series/28.541/
paths: {}
components:
schemas:
Contribution author creates CR branch from latest commit of corresponding release branch in 3GPP Forge, and copy the changed code from tDoc to the CR branch
Note 1: the branch name of Rel16 is Rel-16, the branch name of Rel17 is Rel17-Draft
Note 2: suppose the latest commit of the release branch reflects the codes agreed in last SA meeting. therefore alternatively, author can also create CR branch based on the Tag for last SA meeting.
Note 3: the naming rule of the branch is: TS number_Release number_CR number_tDoc title, and the spaces in tDoc title replaced with _, e.g. 28.541_Rel16_CR0444_fix_containment_relationship_for_EP_Transport_IOC
Note 4: Iif the change of CR includes both YANG and YAML, two CR branches are needed, one for YANG and one for YAML. In this case, _YAML or _YANG is to be added to the end of corresponding branch name, e.g. 28.541_Rel16_CR0444_fix_containment_relationship_for_EP_Transport_IOC_YAML
Contribution author commits the code in Forge and check the report of the commit to make sure the code is compiled successfully
Note 1: Forge validates the code automatically as part of the commit
Note 2: Addition checks for YANG:
- The author MUST correct any errors in his YANG code reported by YANG validation (equivalent to [pyang strict checks).
- The author SHOULD correct all errors and warnings reported by YANG LINT (equivalent to pyang 3gpp checks) in any YANG files he updates
Note 3: If commit report shows failure, contribution author should fix the compiling error and validate again until get successfully commit report.
Contribution author submits contribution to a meeting. Author provides CR branch link in the contribution for the stage 3 source code in Forge, which can be used for verification and later for code merging.
If one contribution author has multiple contributions impacting stage 3 code, the contribution author should solve potential conflicts before submitting the stage 3 code.
There may be many related contributions. Its recommended that the contribution authors take the offline initiative before the meeting in case there is a potential conflict in multiple contributions from different contributors.
Step 1 Consideration of the contribution at the SA5 meeting
All technical CRs, with change mark in tDoc content and Forge CR branch link in cover page, are reviewed in SA5 meeting independently
Its recommended that the contribution authors (from same or different companies) merge the related contributions which may be potentially in conflict as much as possible during the meeting. (i.e. author needs to ensure there is no conflict)
Code moderator creates integration branch before or during SA5 meeting
,SName, e.g. Integration_Rel16_SA5_136_YANG or Integration_Rel16_SA5_136_YAML. If there is more than one SA5 meeting between two SA meetings, create one integration branch for all meetings, and add meeting numbers in the name of the branch, e.g. Integration_Rel16_SA5_135_136_YANG, or for each SA5 meeting create one integration branch just like in a normal SA5 meeting.
Note 1: The stage 2 and 3 CRs can be finally agreed in SA5 if:
It contains a Forge link for CR branch.
The latest commit on the CR branch passes code validation.
Note 2: the stage 2 definition for a feature would be removed from the specification before freezing of the release if theres no corresponding stage 3 to satisfy the release criteria.
Step 1a: Integration branch announcement
Code Master or SA5 leader announces the readiness of the latest integration branch to SA5. Also remind all CR authors to create merge requests from the CR branch to the integration branch. The content of the integration branch announcement could have the format like below:
The code moderators have now created the following four Forge integration branches for this meeting:
Integration_Rel16_SA5_138_YANG: For Rel16 YANG codes
Integration_Rel17_SA5_138_YANG: For Rel17 YANG codes
Integration_Rel16_SA5_138_YAML: For Rel16 YAML/OpenAPI codes
Integration_Rel17_SA5_138_YAML: For Rel17 YAML/OpenAPI codes
Step 2: Code cross check after SA5 meeting and before SA meeting
All agreed technical CRs are submitted to SA independently
Code author submit merge request (MR) after the CR being agreed (no review issue, no validation error)
Note 1: The source of the MR is CR branch, and the target of the MR is the corresponding integration branch announced in each SA5 meeting.
Note 2: Merge request SHOULD NOT include the delete after merge option. The branches might be kept for 6-12 months for reference.
The Code Moderator, with appropriate assistance from the relevant Contribution authors, is responsible for taking care of overall code checking, (e.g. merged all CRs in a integration branch and make sure theres no compilation error on the merged code), especially conflict checking, before the SA plenary. In case of errors being found during the checking process, the code moderator or corresponding contribution author (depends on the error type, complexity, and severity) shall provide contributions to SA plenary for the error correction as company contribution(s). . This check needs to be done after each SA5 meeting.
Note 1: conflicts in code must be resolved before the CR approval at the SA plenary... otherwise all conflicting CRs must be withdrawn/not pursued.
Note 2: Code moderator solves conflict on integration branch, for example:
git fetch origin
git checkout -b "CR12345-branch" "origin/CR12345-branch "
git fetch origin
git checkout "origin/Integration-rel16-SA5-136"
git merge --no-ff " CR12345-branch"
git push origin " Integration-rel16-SA5-136"
For Open API, Code moderator update Open API header to reflect correct version of the TS
All contribution authors are informed to check codes in integration branch to make sure their changes are covered
Note: All merge requests for agreed CRs should be submitted 10 working days before CR submission deadline of the coming SA meeting
Step 3: Agreement of the contributions, after the SA meeting
If all CRs are approved in SA meeting, Code Master copies changed codes from Forge integration branch to the corresponding annexes of TSs. The code master will always copy a full code file avoiding a line-by-line changing of the code.
If there're some CRs rejected in SA meeting, Code Moderator supports Code Master to replace the original integration branch with new integration branch (e.g. backup and delete the original one and create new one with same name), and merge codes of all agreed CRs to the new created integration branch. After that, Code Master copies codes from the Forge integration branch to the corresponding annexes of TSs. The code master will always copy a full code file avoiding a line-by-line changing of the code.
Note: alternatively, with support of Forge expert, code moderator may remove the codes of reject CRs from the original integration branch.
Code Moderator submits MR to merges code from integration branch to corresponding release branch
Note: Rebase locally may be needed to solve potential conflict. Some examples are listed below.
Example 1: rebase release branch to integration branch
git fetch origin
git checkout "origin/Rel-16"
git checkout -b "Integration-rel16-SA5-136" "origin/Integration-rel16-SA5-136"
git rebase -i "origin/Rel-16" "Integration-rel16-SA5-136"
git push -f origin "Integration-rel16-SA5-136"
Example 2: solve conflict on release branch, for example:
git fetch origin
git checkout "Integration-rel16-SA5-136"
git checkout -b "origin/Rel-16" "origin/Rel-16"
git merge --no-ff "Integration-rel16-SA5-136"
git push origin "Rel-16"
Example 3: solve conflict in new branch mainly to mitigate impact between YAML/YANG
1) Create a completely new branch based on the latest release branch.
2) Pull it to a local tracking branch and switch to it
3) Delete ALL impacted and useless YAML/YANG files from new branch
4) Copy ALL impacted YAML/YANG files from integration branch to the new branch
5) Commit, push
6) Create MR to merge the new branch to release branch
Code Master takes care of the merge requests, ensures that commits are squashed, and the original branch should be kept for several months.
Code moderator checks and confirms the consistency of the codes in TS and release branches. If there're different, with support of code moderator, code master fixes the issue in either TS (if it's caused by copy-paste Forge code to TS) or Forge release branch (if it's caused by code merge to release branch)
Code Master creates a Tag on the latest commit of release branches to reflect codes agreed in SA meeting
Note: the naming rule of the tag branch is: Tag_Release No_SA_Meeting No, e.g. Tag_Rel16_SA91, Tag_Rel17_SA91
Code Master or SA5 leader announces the readiness of latest release branch and Tag for the SA meeting.
Code Master remove all CR branches of the previous SA5 meetings.
Note 1: Integration branches could be clean up periodically or after each SA meeting.
Note 2: Suggest branch owner deleting test branches if they are not used anymore. Code master may clean up the Forge branches periodically. The branch owner should inform code master or make notes in top level readme file if they want to persist some branches.
23.5 YANG corrections by Code Moderator
The YANG Code Moderator should check and correct errors for YANG code extracted from the TS document after SA meeting, and ask the MCC to incorporate these error corrections in the TS with a new TS iteration (z) of the version Vx.y.z. The following errors should be incorporate in the TS document without a new CR document:
Add missing curly braces
Add missing semicolons
Add missing quotes
Remove quotes inside quoted YANG arguments, e.g. This is a description of term xxx, as they break a single quoted argument into two quoted and one unquoted argument.
Remove unused import statements
Add missing import statements
Correct misspelled YANG module names in import statements
Correct misspelled prefixes within import statements
Remove extra space from quoted arguments
Rearrange revision statements according to the date
Add contact statement according to TS 32.160
Remove space at the end of line according to TS 32.160
Break lines longer than 80 chars into multiple lines
23.6 Notification when ready
When the merge requests are merged into the release branch, upon agreement of the code master and the code moderators, the code master shall notify the leaders about the readiness of the release branches. The leaders should announce the Forge branch or tag that should be used as a baseline for further work. OpenApi and YANG baselines may be announce separately or at the same time.
Code Master or SA5 leader announces the readiness of latest release branch to the team. When all the approved contents in the previous SA plenary meeting are merged to the release branch, the release branch is ready as baseline branch for new content to the next SA5 meeting.
Note: This announcement is similar to the Tdoc reservation announcement like Tdoc reservation for SA5#140e is now open.
The content of the release branch announcement could have the format like below:
The Forge Release branches are ready. You can now create CR branches and commit your stage 3 code for the next SA5 meeting in Forge.
Release branch for Release 16 is: Rel-16
Release branch for Release 17 is: Rel17-draft
23.7 Branching strategy (void)
23.8 Clean-up policy
After every half year branches related to previous meetings and any private branches not changed in six months will be deleted unless the owner indicates in the top level readme file of the branch that it is still needed. Branches should not be preserved for more than 18 months.
23.9 DraftCR Forge process
Forge process for DraftCR is FFS
24 Stage 2 / Stage 3 alignment principle
Supported stage 3 SS types:
The supported stage 3 SS types are YAML and YANG for Management service component A and component B.
The supported stage 3 SS types are one of the 3 types (ASN.1 or GPB or XML) for Management service component C.
Mapping information of stage 2 and stage 3 management capabilities for each 3GPP release:
For every stage 2 management capability, it must be accompanied by one or more corresponding stage 3 definition(s) for at least one of the 3 existing SS types (YAML , YANG and XML).
A living document (one tdoc per Work Item) shall be created to document the level of supported stage 3 SS types for each Stage 2 capability in every applicable stage 2 TS (e.g. 28.532, 28.541, 28.535). Documenting this is the responsibility of the Work Item rapporteur, with the coordination with the related stage 2 contributing companies. The table is recommened to be updated after each SA plenary, taking the input from the published TS(s) after CR implementation.
Here is an example of how to describe the supported SS types in the living document for a Model driven FMControl management capability:
Rel-17 Model driven FMControl management capabilityStage 2RestFul (YAML)YANGComponent ACRUD Operation (see TS 28.532 section 11.1 Provisioning Management Service)TS 28.532
(https://forge.3gpp.org/rep/sa5/MnS/blob/Rel17-draft/OpenAPI/provMnS.yaml)TS 28.532 section 12.1.3 YANG/Netconf-based solution setComponent BGeneric NRM (FMControl NRM Fragment) (see TS 28.622 section 4.3.26)TS 28.623 (https://forge.3gpp.org/rep/sa5/MnS/blob/Rel17-draft/OpenAPI/genericNrm.yaml)TS 28.623 (https://forge.3gpp.org/rep/sa5/MnS/blob/Rel17-draft/yang-models/_3gpp-common-fm.yang)
ANNEX: Useful Links
3GPP Portal HYPERLINK "https://portal.3gpp.org/" https://portal.3gpp.org/ 3GPP Specifications home page HYPERLINK "http://www.3gpp.org/Specifications" http://www.3gpp.org/Specifications 3GPP Specifications HYPERLINK "http://www.3gpp.org/ftp/Specs/" http://www.3gpp.org/ftp/Specs/3GPP Specification latest updates HYPERLINK "http://www.3gpp.org/ftp/Specs/latest/" http://www.3gpp.org/ftp/Specs/latest/3GPP Specification status HYPERLINK "http://www.3gpp.org/ftp/Information/Databases/Spec_Status/" http://www.3gpp.org/ftp/Information/Databases/Spec_Status/3GPP Specification latest drafts HYPERLINK "http://www.3gpp.org/ftp/Specs/Latest-drafts/" http://www.3gpp.org/ftp/Specs/Latest-drafts/ 3GPP Change request database
3GPP TSG Working Methods HYPERLINK "http://www.3gpp.org/ftp/Information/Databases/Change_Request/" http://www.3gpp.org/ftp/Information/Databases/Change_Request/
HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/21900.htm" http://www.3gpp.org/ftp/Specs/html-info/21900.htm 3GPP Work plan HYPERLINK "http://www.3gpp.org/ftp/Information/WORK_PLAN/" http://www.3gpp.org/ftp/Information/WORK_PLAN/ 3GPP Meeting calendar HYPERLINK "http://webapp.etsi.org/meetingcalendar/QueryForm.asp" http://webapp.etsi.org/meetingcalendar/QueryForm.aspDelegate contact information (*)HYPERLINK "http://webapp.etsi.org/teldir/TelDirectory.asp"http://webapp.etsi.org/teldir/TelDirectory.aspUpdate contact information (*) HYPERLINK "http://webapp.etsi.org/teldir/PersonalInfo.asp" http://webapp.etsi.org/teldir/PersonalInfo.asp Email list management (*) HYPERLINK "http://webapp.etsi.org/TBMembershipList/home.asp" http://webapp.etsi.org/TBMembershipList/home.asp Info for meetings in ETSI HYPERLINK "http://www.etsi.org/about/getting-to-etsi" http://www.etsi.org/about/getting-to-etsi SA5 Home page HYPERLINK "http://www.3gpp.org/SA5" http://www.3gpp.org/SA5 SA5 Specification list HYPERLINK "http://www.3gpp.org/ftp/Specs/html-info/TSG-WG--S5.htm" http://www.3gpp.org/ftp/Specs/html-info/TSG-WG--S5.htm SA5 DocumentsHYPERLINK "http://www.3gpp.org/ftp/TSG_SA/WG5_TM/"http://www.3gpp.org/ftp/TSG_SA/WG5_TM/SA5 Guidelines HYPERLINK "http://www.3gpp.org/ftp/tsg_sa/WG5_TM/Guidelines/" http://www.3gpp.org/ftp/tsg_sa/WG5_TM/Guidelines/ Archives of SA5 email list HYPERLINK "http://list.etsi.org/3gpp_tsg_sa_wg5.html" http://list.etsi.org/3gpp_tsg_sa_wg5.html Archives of CH SWG email list HYPERLINK "http://list.etsi.org/3gpp_tsg_sa_wg5_charging.html" http://list.etsi.org/3gpp_tsg_sa_wg5_charging.html Archives of OAM SWG email list HYPERLINK "http://list.etsi.org/3gpp_tsg_sa_wg5_oam.html" http://list.etsi.org/3gpp_tsg_sa_wg5_oam.html (*): EOL account required
SA5 Working Procedures
PAGE 1/ NUMPAGES 24
Step2:use filer to find your branch
Step3: Click Merge Request
Step 1:click Branches
4 5 9 B D M N Y Z ӽ~hhRB2 h
hZ 5CJ OJ QJ ^J h
h?\ 5CJ OJ QJ ^J +h1/) h1/) 5CJ OJ QJ ^J aJ nHtH+h
h%1Y 5CJ OJ QJ ^J aJ nHtH+h
hh 5CJ OJ QJ ^J aJ nHtH+h
h?\ 5CJ OJ QJ ^J aJ nHtH%hEJd 5CJ OJ QJ ^J aJ nHtH+h
hZG 5CJ OJ QJ ^J aJ nHtH+h
hZ 5CJ OJ QJ ^J aJ nHtH+h
hk 5CJ OJ QJ ^J aJ nHtH N 8 9 : C U
5 :
o
$a$gdXJx L
% gd5\J
&d P gdy
gdy
x $d N gdy gd gd<