inside 3GPP and IETF Standardization work

The 3GPP (3rd Generation Partnership Project, created late 90's) is in charge of the development of standards for the various generations of mobile networks, from 3G to 5G, and its specifications use a large part of the IETF standards. The 3GPP is organized in 3 main domains or TSGs (Technical Specification Groups): Radio Access Networks (RAN), Service and Systems Aspects (SA), Core Networks and Terminals (CT). New Specifications, or new versions of a number of Specifications, are produced just after the quarterly plenary meetings for each domain. The 3GPP produces Word documents and afterwards, each Organizational Partner (there are 7 ones from Europe, North America and Asia) can produce a PDF version, especially the ETSI version. As a result, we are necessarily outside, and in front of the 3GPP Standardization space made up of individual documents, organized in series. Ideally, there should be a single HTML standardization space, with accurate references to sections within specifications, instead of references to documents. The best we can do is to create a frontal space in front of the 3GPP site, made up of descriptors for each technical specification or report. In the end, you will have to get and read each 3GPP document you are interested in. The way the 3GPP produces TS (Technical Specifications) and TR (Technical Reports) impacts the creation of this frontal space. 3GPP plenary meetings (one for each TSG) are organized at the end of each quarter. Afterwards, a number of 3GPP documents are released in Word format during the first month of the following quarter (as a ZIP file possibly with additional annexes for data). Then, the ETSI publishes a PDF version, much more useful for a reader. However, the PDF is a closed environment by itself, isolated from the other 3GPP documents. Due to the workload for the ETSI, when the whole set of PDFs is published the next plenary meetings are upcoming, or have already started, bringing new versions. For a better overview of the contents of a specification or report, we reproduce the Table of Contents (ToC). A particularity of 3GPP standards development is that the original section numbers in a document are preserved. It can be extended, but a deleted section will appear as 'Void' and a section inserted between sections with consecutive numbers will be suffixed with a letter. We have taken advantage of this for highlighting the number of the 3GPP Release number at which a section, and by the way a topic, has been taken into account during the evolution of a document. Up to now, we had provided through the ToC, a direct access to the PDF on the 3GPP site. This is being deconstructed since it loads the ETSI Hosting server for a limited interest, all in all. Furthermore we neeed to wait, sometimes several weeks, for the availability of the PDF to update this ToC. The frontal Space built in front of the 3GPP standardization space will be gradually improved and reworked. However, this will take some time.

 

The IETF (Internet Engineering Task Force) is the organization that specified the first Internet protocols in the 70's and 80's and that has continuously developed, since then, fundamental protocols in various domains, for the evolution of the Internet. The standardization work of the IETF is reflected by documents called RFCs, numbered chronogically and published gradually (the "RFC" well-known acronym stands for 'Request For Comments' but has just a historical meaning). By reproducing and re-styling all the RFCs on this site (as it is done by some other sites in their own way, besides the IETF iself) we build a single consistent space inside Tech-invite, with internal links. Only a few links towards the genuine IETF space are needed for official information about working groups or current drafts. There is no versioning for RFCs. Once it is published, in text format, an RFC can be updated (by one or more subsequent RFCs) and there can be Errata for this RFC. Eventually, an RFC may be obsoleted (and replaced) by another RFC. An RFC refers to many other RFCs, and more accurately to sections or figures or tables within this very RFC or other RFCs. One of the advantages of the RFCs by Tech-invite is the color of RFC numbers, which enables you immediately to know whether the RFC referred to, has been obsoleted or not. Besides RFCs on this site are grouped in the working group that produced them or, as this is the case for individual RFCs (about one third of published RFCs) in a virtual group. The IETF RFC Standardization space on this site so far has been supplemented with flow examples and a consolidated ABNF grammar for SIP, the protocol at the origin of this site. SIP is used by 3GPP IMS. Potentially, much more could be done, for other topics. An improvement to the restyling of RFCs would be to point out which parts within an 'active' RFC are replaced due to errata and/or updates. This was done for RFC 3261 (SIP) and has been removed, but it will be redone differently. In the near future, the IETF will publish RFCs in a new format enabling in particular to insert images, since ASCII characters for drawings is a restricting mode. However, this will apply only to new RFCs. When this happens, we will manage to keep a consistent environment for all the RFCs.