A Global

The Mobile


Coordinated Vulnerability Disclosure (CVD)

In conjunction with other Standards Development Organizations and related bodies, 3GPP has put in place a mechanism by which individuals or organizations can notify us of suspected or proven vulnerability caused by errors, omissions or ambiguities in our Technical Specifications, particularly those which could give rise to security breaches or loopholes which could compromize components of 3GPP networks, terminal equipment connected to those networks, or to other interworking networks or equipment. 

We take such threats seriously and will do our utmost to resolve any vulnerabilities notified to us so that users of our Technical Specifications can do so with confidence that they do not present opportunities for malicious third parties to discover and exploit any shortcomings in our Specs.

We encourage you, whether as an individual or as a representative of an organization with an interest in the security of telecommunications systems based on 3GPP Specificaitons, to provide as much information on detected vulnerabilities as possible using the on-line form (see below). We will acknowledge all such declarations, and we guarantee that we will send the information to the appropriate 3GPP Group so that the problem can be analysed and resolved in as short a time as feasible. We will notify you when the vulnerability has been eliminated.

You may provide us with your name (real or an alias) and your email address so that we can get back to you with the final answer. We also ask that you give us permission to pass your name and email to the Group or Groups which we identify as that or those most suitable for resolving the vulnerability. Alternatively, you may provide information anonymously, in which case we guarantee not to try to identify you, for example by your IP address.

Unless you make your declaration anonymously, we also ask whether you wish to be publicly identified as the author of the vulnerability report and listed in our hall of fame.

3GPP, and its member organizations, are responsible for the writing and issuing of Technical Specifications, but we are not responsible for proprietary equipment designed, build and tested to those Specifications. Nevertheless, if you declare a vulnerability which is, you believe, the result of a misinterpretation or misimplementation of the provisions of a 3GPP Technical Specification, we would still encourage you to report it. We will notify the manufacturer or network operator and work with them to fix the problem, as well as correcting or clarifying the Specification if need be. We will also cooperate with other standards bodies (IETF, ISO, the 3GPP Organizational Partners, etc), and with related bodies such as - but not limited to - our Market Representation Partners.  Our aim will be to resolve the issue as effectively as possible.

We ask you not to share knowledge of the vulnerability with third parties until 3GPP has resolved it, and of course we ask you not to exploit that vulnerability except inasmuch as this might be necessary to gather sufficient data necessary to report it to us. 

 Click here to be directed to the CVD submission form.

 Note: ETSI has a separate process for their specifications - Click to see the ETSI CVD Process


Page history:

2018-03-28: Initial draft [JMM]
2018-04-02: Correction of typo [JMM]
2018-04-17: Goes live [JMM]
2019-02-06: Minor editorial corrections [JMM]



Withdrawal of Specifications and/or functionality

In accordance with clause 4.9 of 3GPP TR 21.900 (Technical Specification working methods), the table below documents proposals to withdraw 3GPP Technical Specifications and Technical Reports, or functionality specified / described therein, and the eventual outcome of such proposals. Consult the reports of the corresponding TSG meetings for a full description of the treatment of the withdrawal proposals.

Date of proposal

TS/TR (or functionality) to be withdrawn


TSG meeting at which decision will be taken


2020-08-31 TR 24.980 from Rel-17 onwards Justification can be found in C1-205561 TSG CT#89-e  Withdrawal approved.
2020-06-04 Removal of functionality relating to H.263 from 
TS 26.114
TS 26.140
TS 26.234
TS 26.244
TS 26.346

Removal of H.263 codec functionality from all Rel-16 specifications under 3GPP SA4 responsibility. Justification can be found in SA4-200852. The Work Item proposing and justifying the withdrawal of this functionality can be found in SP-200400.

Draft CRs to update/remove references from other specs can be found in:
S4-200853, S4-200854, S4-200855, S4-200856 & S4-200857.

TSG SA#88-e.  Withdrawal approved.
2019-03-18 TS 24.323 from Releases 11, 12 and 13

TSG CT meeting #83 approved in principle the withdrawal of TS 24.323 from Releases 11, 12 and 13. The rationale will be prepared in a special work item currently being drafted by Vodafone. The procedures of TR 21.900 clause 4.9B apply.
The withdrawal WID can be found in CP-191151 to CT#84.

TSG CT#84 Withdrawal approved.


TS 44.118, TS 44.160
from Rel-12 onwards

Specs relate to Iu mode in GERAN, not supported after Rel-11. Note that there are very many references to these specs from other specs, so a very large number of CRs will need to be produced and approved before these specs can be withdrawn.


Withdrawal approved at RAN#88-e


TR 38.900

Frequency range of interest has been extended, and this TS is superseded by TR 38.901. A reference check has been undertaken, and necessary CRs will be raised as appropriate. The FS_NR_newRAT WID will be revised to indicate the withdrawal of 38.900.

Update 2017-04-26: Subsequent discussions indicate that withdrawal is not required, but that the TR will not be promoted to Rel-15. If any references to 38.900 are required from Rel-15 specs, these will have to be explicitly to the latest Rel-14 version.


 No withdrawal




GSM history


Drafting and publication of GSM Specs ...

... in the pre-3GPP era


This article describes how the original GSM Specifications were drafted and published when they were the sole property of ETSI, long before the creation of 3GPP.



Work started on a harmonized European cellular technology in the early 1980s under the auspices of CEPT, carried out in an ad hoc subgroup called Groupe Spécial Mobile - GSM for short. An overview of the early history of GSM can be found in Hillebrand (ed) [1]

ETSI was created in 1988 and gradually all standardization work was transferred from CEPT to ETSI, normally retaining the existing committee structure. CEPT GSM became ETSI Technical Committee (TC) GSM in 1990, and in 1991 the TC was renamed "Special Mobile Group", SMG. The original CEPT GSM had had a dedicated technical secretariat or "Permanent Nucleus", based at the CEPT premises in Paris, and this too eventually transferred to ETSI headquarters in Sophia Antipolis. The Permanent Nucleus was thereafter known as Project Team (PT) 12 or, informally, as PT SMG. ETSI’s Project Teams were later renamed Special Task Forces so PT12 became STF12.

Deliverable types

Following ITU (at that time CCITT and CCIR) nomenclature, CEPT had traditionally published its technical documents as "Recommendations", but ETSI had created new deliverable types "European Telecommunication Standard" and "European Telecommunication Report", and had adopted the general publication document structure of their elder sister European Standards Organizations, CEN and CENELEC. Of course, with TC GSM came the draft CEPT Recommendations it had so far developed, and needless to say these did not conform to the new ETSI document structure. Indeed, having been written as "recommendations" rather than formal standards, the wording of the older documents was often not appropriate for giving precise, unambiguous, technical requirements. TC GSM and later TC SMG delegates often continued to refer to their documents as "Recommendations" long after the transfer to ETSI. This history can be detected to this day in the structure and phrasing of some of the 3GPP Technical Specifications, which still do not conform to the ETSI or 3GPP rules.

The Permanent Nucleus and PT12

In the early (CEPT) days of GSM, the group’s members were technically competent, indeed sometimes extremely expert, in the field of radio and telecoms technologies, but were in some cases quite senior managers who did not have the "spare" time to devote to the detailed development of the GSM Recommendations. For this reason, much of the actual drafting of those documents was performed by the (also highly technically competent) members of the Permanent Nucleus (PN), and drafts of these were reviewed at meetings of the GSM group. At that time, the documents were maintained in paper form (indeed, some of the earliest drafts were hand-written!), and changes were proposed by means of change requests, which reproduced an area of the document showing proposed modifications, again sometimes in manuscript. If the members of GSM agreed the changes, the master document was updated by the relevant PN member, either by retyping individual pages, or by literal cut-and-paste using scissors and glue. By the time of transfer to ETSI, the change request process had become well formalized, with CRs being assigned numbers by the PN and being catalogued in a database.

Permanent and Temporary Documents

Technical Committees of CEPT and later ETSI classified documents discussed at meetings as either Temporary Documents (TDocs, TDs) or Permanent Documents (PDs). As their names imply, PDs were retained indefinitely after their creation, while TDs were, in principle, discarded at the end of the meeting with no master copy being retained unless it was decided to, for example, annex it to the meeting report. The latest drafts of Recommendations would typically be PDs, as would meeting reports recording progress during the meeting. General documents for discussion or presenting technical ideas were usually classified as TDs. The distinction between PDs and TDs was essential bearing in mind that delegates physically could not easily transport all the documents presented at a meeting back home with them since the total might run to several thousand pages. In general, meetings of CEPT GSM and later even of ETSI TC GSM and SMG were hosted by members of CEPT which were of course not only national telecom administrations, but also national postal administrations: at the time, most European countries had a unified "PTT" - the Post, Telegraph and Telephone administration - usually a government department. It became the habit for the host PTT to offer to send delegates’ documents to them by post (at no charge to the delegate) and it is perhaps for this reason that so many TDs from the early days are not entirely lost to posterity.

On the move of work from CEPT to ETSI, the paper archives of CEPT were also transferred. These, though far from complete, are still kept safely at ETSI, together with the archives of ETSI TCs GSM and SMG. In the mid 2000s all the paper archives were scanned to PDF with a view to making them more accessible.

ETSI worked with master documents on paper until the mid-1990s, when a gradual move was started to all-electronic working. The document archive of TC SMG is therefore much more up to date from around 1997 onwards.

Phased development

It was decided early on after the transfer of work to ETSI that the pan-European digital cellular standards could not be developed to completion in one go, and that a phased approach should be adopted. Thus a basic telephony service could be standardized as a "Phase 1", which would be followed by a Phase 2, and so on, each new Phase adding more and more functionality. A set of GSM documents (still essentially in the form of old CEPT Recommendations, though published over a period of a year or two as a mixture of "GSM Technical Specifications" (GTS), ETSs and ETRs) was published to represent the Phase 1 offering.

Subsequently - logically - an expanded set of publications formed the Phase 2 system.

At this point (c.1996) it was realized that, in the fullness of time, the second generation cellular system (GSM) would one day give way to a more performant 3rd generation system. (The ITU was referring to this technology-to-be as the somewhat unwieldy FLMTS - Future Land Mobile Telecommunication System -, while in ETSI this became known, perhaps slightly presumptuously, as UMTS - Universal Mobile Telecommunication System.) For this reason, the next release of the GSM specification set was termed not Phase 3 but "Phase 2+", and this nomenclature was retained for subsequent specification sets, which became known as Releases, finalized more or less annually, as R97, R98 and R99, with the original Phase 2+ being referred to R96.

Version numbers

TC GSM/SMG had adopted a three-field version number system, but ETSI’s publication scheme dealt with "editions". ETSI had also devised a system of making minor additions to a published ETS or ETR in the form of "Addenda", and also of making minor corrections to errors discovered after publication in the form of "Corrigenda". Several versions of GSM specs are published as addenda or corrigenda to original ETSs. The GSM publications were unusual in that, because of the phased approach, the output documents never became fully stable, but were continually revisited, with updates being made to some of the more complex documents at nearly every plenary meeting. This posed a problem for ETSI, whose publication mechanism mirrored the traditional, lengthy bureaucratic process long used by CEN and CENELEC. Because of the national public inquiry, revision, and national vote process, an ETS took a minimum of eight months between TC approval and final publication. By the time a GSM ETS was published, the TC might have already revised it three times, making the ETS already out of date! This incompatibility in working methods was a source of some friction between the "traditional" ETSI community and the GSM community in the early days. Publication of a GTS was quick and dirty (insofar as there were no public inquiry and vote phases), but satisfied the GSM community; on the other hand, the European Commission would not except such unscrutinized publications for use as the technical basis for type approval testing. These problems were eventually overcome more by market forces as the GSM service rapidly became very popular with its users, rather than by resolution within ETSI.

Where, as was the case for most GSM publications, the final document type was to be an ETS, the course of events might be something like this ...

At plenary meeting number N, TC SMG would approve (say) version 3.4.0 as being stable enough to issue as an ETS. This would be transferred to the ETSI Secretariat, which would perform a little cosmetic clean up and issue it for national public inquiry. This version of the document was know as the "first draft" of the ETS. During the course of the public inquiry, TC SMG would continue to work on the document and might hold as many as two more plenary meetings (N+1 and N+2) during the public inquiry; and by the time the comments resulting from the public inquiry were received by the Secretariat, collated, and passed to TC SMG, the latest version of the document might have progressed to (say) 3.6.0. TC SMG then had the potentially difficult job of incorporating remedies to those national comments on the earlier version into the now current version of their document, which would then be raised to version 3.7.0 and sent to the Secretariat which would prepare it for the national vote as a "final draft" of the ETS. At the end of the vote, assuming a positive result (no GSM ETS ever failed the vote stage!) the Secretariat would publish the ETS as edition 1. Meanwhile TC SMG might have further modified its specification to version 3.8.0.

This somewhat confusing situation was somewhat alleviated after Phase 1 by the ETSI-issued ETSs also bearing the three-field SMG version number on the page headers, leaving the reader in no doubt which version of the GSM Spec he was reading. The situation was further improved some years later, when ETSI’s publication regime was brought more in line with CEN’s and CENELC’s, with the published standards changing from "ETS" to "EN" (Europäische Norm) and edition numbers being dropped in favour of a three-field version number based upon that invented for the GSM Recommendations. It is important to note that the ETSI version numbering system was not identical to that devised for GSM because, whilst the GSM version would be incremented each time the document was edited, however small the change, the ETSI ETS retained the same version (a) when it was converted to the ETSI "first draft" ETS for public inquiry, (b) when it was converted from the SMG-updated version incorporating the latest modifications including the public inquiry comments to the "final draft" ETS for national vote, and (c) when it was converted from the "final draft" to the document of the final, published ETS. Thus, in the extreme case where TC SMG made no changes to a document during the public inquiry phase and where no comments were received during the public inquiry (European industry rapidly learnt not to rock the GSM boat and to refrain from any but absolutely vital comments during the public inquiry!), the same version number could appear on four different instances of the document:
  • that tacitly approved by TC SMG after incorporation of the latest approved CRs by PT12,
  • the "sanitized" editorial modification sent out by the ETSI Secretariat as the "first draft" ETS [2] for public inquiry,
  • the editorially revised version sent as the "final draft ETS" for national vote, and finally
  • the again editorially revised version published as the definitive ETS.
Because of this, a certain amount of care has to be taken when discussing a particular version of a GSM Specification. There could be up to four instances of a GSM document identified by the same version number.

Streamlined approval

The situation was improved somewhat by adopting the slightly streamlined ETSI process originally known as the Unique [3] Approval Procedure (UAP), later renamed the One-Step Approval Procedure (OAP), whereby the national public inquiry and vote phases were combined, the EN being published in its original form, with any comments received being fed back to the responsible Technical Committee with a view to issuing a subsequent version.

Later still, use was increasingly made of the even more efficient publication process which involved neither national public inquiry nor vote, but publication immediately after approval by the TC; this process was not permitted for ENs but was restricted to a different deliverable type, the Technical Specification, originally seen as having lesser status than ENs by virtue of this much more restricted publication cycle, but much more appropriate to TC SMG’s working methods. Purely informative material was published in Technical Reports, similarly free from burdensome approval procedures.

By the late 1990s, this regime was used for all GSM publications except those intended for regulatory type approval testing (the 13.-series specs), and on formation of 3GPP in 1998, the same approach was taken, with all 3GPP normative output being of type Technical Specification and informative output being of type Technical Report.

Transfer to 3GPP, closure of ETSI TC SMG

The new collaborative venture 3GPP was formed in 1998 and held its first plenary meetings in December of that year. Initially, change requests were approved twice: by 3GPP and by TC SMG, but gradually, the non-radio GSM specs were transferred to 3GPP ownership and this dual approval vanished.

Finally, the remaining GSM specs relating to radio were transferred to a newly-created 3GPP Technical Specification Group "GERAN" in mid-2000, and TC SMG was closed. Only the EU-regulatory standards were retained within ETSI, and these were transferred from SMG to a newly created Technical Committee, "Mobile Standards Group" (MSG).

ETSI has issued several CDs and DVD sets relating to the development of the GSM system:
  • Reports of all TC GSM and SMG plenary meetings, plus all available contribution documents to SMG plenaries.
  • Development of the SIM card: All available contributions to the GSM SIMEG and later SMG9 working groups.
  • A Technical History of GSM: All available contributions to TC GSM and TC SMG meetings, both plenary and working groups, plus all available draft GSM specifications and published versions up to the end of Release 99.

These are available for purchase to ETSI member organizations.

[1] GSM and UMTS: The Creation of Global Mobile Communication, John Wiley & Sons Ltd, ISBN 0470 84322 5

[2] Or, later, EN

[3] Actually a malapropism for "Unified"

Writing a new Spec

This page is intended to form a beginner's guide to the role of a delegate in 3GPP working groups, in particular those who have elected to be the editor – "rapporteur" in 3GPP parlance – of a Technical Specification or Technical Report. The information offered here is as by way of a supplement to the formal 3GPP drafting rules given in TR 21.801, which you are fervently recommended to read as well.


Congratulations, you have volunteered (or have been volunteered) to be rapporteur for a new TS or TR.  We will refer to TSs and TRs collectively as "Specs", except where there is an important distinction to be made.

Why are you called "rapporteur" rather than "editor"? The word "rapporteur" has been used for a long time in international standardization circles, particularly the ITU. It is a French word meaning literally "reporter", and therein lies the clue: you are required not only to draft the Spec, but also to act as a centre of technical knowledge on it, to whom other 3GPP delegates can pose technical questions and propose modifications. You must also be prepared to respond to questions from the wider community including those uninvolved with 3GPP. And depending on the habits of your working group and TSG, you may also be required to provide regular written status updates on the progress of the draft.

Once a rapporteur, always a rapporteur. You will remain designated as the rapporteur for your Spec for ever and a day unless you tell MCC (for example, your group's Secretary) that you are no longer able to continue in the role because, for example, you are changing roles within your empoyer, or changing company and the new employer will not support you, or you are retiring, taking monastic orders, intending to die, etc. If you are unable to continue as rapporteur, in the first instance ask your employer if there is anybody willing to take over the role from you. Failing that, let your group's Chair know, and he will actively seek a replacement from amongst the active delegates. He can be expected to do this with enthusiasm, because the default, if he cannot find a new rapporteur, is that he has to take on the role himself!

Make sure MCC knows of any change in your contact coordinates (email, telephone, etc) - particularly, of couse, if you change company.

If you change to a company which is not a 3GPP Individual Member, you must relinquish your rapporteurship and may not attend any further 3GPP meetings.

How to start

So, start by downloading the stock TS or TR skeleton document from the 3GPP file server and saving it on your PC. You can download it using either FTP or HTTP

infoDO NOT re-use an existing TS or TR as a starting point - you would run the risk of using an old version or worse, a version polluted with foreign styles or erroneous reformatting.

The Spec templates are in Microsoft Word version 2000 format, i.e. .doc files.

info You may use either the current, .docx, format for Word documents, or the older (pre-2007) .doc format. If you are taking on the rapporteurship from some one else, and the spec is currently in .doc format, it may be wise to leave it so, and raise CRs in .doc format. MCC can provide you with more advice on this.

(There is a reason for retaining the .doc format: the .docx format does not support certain features of the .doc format, in particular the Equation Editor, which is very widely used in 3GPP Specs, especially those from TSG RAN.  We intend to retain the .doc format for Specs for the foreseeable future. For practical hints on editing documents containing old-style equations, follow this link.)

You are not constrained to use Microsoft Word to edit your Spec: you can use any word processor which can handle the .doc(x) format (both reading and saving).

The skeleton Spec file contains all you need to get started, plus quite a lot which you probably won't need in your final spec, but you can delete that later on.  There is also quite a lot of guidance text, rendered in blue. DO read the guidance text and follow its instructions.  When you have done what a particular element of guidance has proposed, you should delete the corresponding blue text.

Cover page logo(s)

You will see that the skeleton Spec provides you with several options for which logos to retain on the cover page. Follow the blue guidance text to decide which lines to delete.

Stock text

You will see that the skeleton Spec already includes a certain amount of stock text in, for example, the Foreword, and in clauses 2 and 3. DO NOT modify this stock text in any way.

Structure of your Spec

DO NOT change the structure of the early part of the Spec skeleton, though the unnumbered Introduction clause is optional and if you think there is no need for an introduction, you can delete it.  Clauses 1 (Scope), 2 (References), and 3 (Definitions) must remain - though you might wish to delete the "symbols" subclause 3.2 if you have none, in which case you should renumber the "abbreviations" subclause to avoid leaving a gap.

This brings us to another apparently minor, though actually important point: 3GPP Specs are divided into clauses, and NOT into sections or chapters. This terminology is important when you are referencing particular places in a Spec, be those places in the same Spec or in other Specs.

Clause 4 of the skeleton Spec contains some useful guidance about the use of the various built-in paragraph and character styles.  DO read this text - before you delete it.  Ultimately, the main body of your new Spec will start at clause 4.

Clauses 4 onwards are up to you. Use them to provide the main contents of the Spec.


DO list every document which is mentioned in the body of your Spec in clause 2 "References". Follow the format of the examples shown in the skeleton document. Any external document can be referenced except:

  • Documents which are not publicly available
    "Publicly available" means that the document can be downloaded or obtained in paper copy from the document's publishers or bookshop. It need not be free of charge, however it shall not be necessary to join an association, club, or other group which has selective membership in order to obtain the document.
  • Documents not in the English language
  • 3GPP-internal TRs, not intended for transposition by the Organizational Partners (usually numbered xx.8xx or 30.xxx or 50.xxx) *
  • 3GPP TDocs *

The * asterisked * conditions are waived if your Spec is itself a 3GPP-internal TR.

It is strongly recommended that references to any non-3GPP document - for example, an ITU Recommendation or an Internet Draft - be to a specific version (i.e. identified by a particular edition or version, or by publication date). Some TSGs insist on this condition.

If you reference a 3GPP Spec which is not included or intended to be included in the same Release as that of your Spec, you must ensure that the reference indicates the Release in which the document can be found.

DO reference a particular 3GPP Spec (or ITU Recommendation, etc.) DO NOT make a generic reference to an entire series of Specs (or Recommendations, etc). Thus reference, say,
as three separate references, rather than a singe reference to
32.40x series.

One of the duties of a rapporteur is to regularly monitor the state of all external documents referenced from his Spec. If any ceases to be available - for example, is withdrawn by its publisher, or goes permanently out of print, or vanishes from a web site - then the reference must be removed or deleted from your Spec by means of a CR. If the reference gave normative provisions essential to the implementation of your Spec, considerable rework might be required.

DO reference other documents; DO NOT copy text from those documents and include it in your Spec. As sure as eggs is eggs, the other document will one day be revised, and the extract which you have copied into your Spec will no longer accord with that revised document.

The only justifiable exception to the do-not-copy rule is where it is known that the external document is not publicly available (according to the definition above). In this case, it is permissible to copy short exerpts into your Spec - although the text may need editorial revision to ensure it abides by the formal drafting rules, and thus not be a verbatim copy. If it is unavoidable to copy lengthy passages or indeed entire documents, then the best approach to this is to include the original document within the zip file of your spec, and to create an annex in your Spec which explicitly "references" that external document by filename, and indicates that the file can be found within this Spec's zip file. When doing such copying and where the source material is not a 3GPP document, always ensure that no violation of copyright conditions are entailed. If in any doubt, consult your MCC Project Manager, who will investigate and if necessary obtain permission to reproduce the text (or figures, etc). Be aware that this might result in a delay in finalization of your Spec, and in the worst case, permission to reproduce may not be forthcoming, in which case your Spec will have to be redrafted to avoid the copied part. 

By convention, once a Spec is under change control, modifying existing reference numbers by inserting or deleting of references is strongly deprecated.

info It is extremely unlikely that any external document which references your Spec will make any mention of its reference list! - nevertheless, if you were to write a CR proposing to insert a new reference (or delete an existing one) and renumber all the references south of that point in the list, it would be necessary to trawl the entire Spec for mentions of those references, and to renumber them all accordingly: a tedious and error-prone activity.

Hence always add a new reference at the end of the existing list, and if a reference becomes obsolete, leave it in the list, but delete the text and replace it with "void": so that, for example

[3] 3GPP TS 32.102: "3G Telecom Management architecture".
[4] 3GPP TS 32.106: "3G Performance Management".
[5] ITU-T Recommendation X.710: "Common management information service definition for CCITT applications".
[6] ITU-T Recommendation X.711: "Common management information protocol specification for CCITT applications".

might become

[3] 3GPP TS 32.102: "3G Telecom Management architecture".
[4] 3GPP TS 32.106: "3G Performance Management".
[5] (void)
[6] ITU-T Recommendation X.711: "Common management information protocol specification for CCITT applications".


It may be desirable to provide a list of further reading material, particularly in a TR. DO NOT include this in the References clause, but rather, DO create a Bibliography (informative) annex and list the material there, using the same layout conventions as in the References clause, except that the list will be unnumbered.


As you will have gathered, level 1 clauses are numbered 1, 2, 3, 4, etc, and are to be rendered in style Heading 1. There is no limit to how many clauses your Spec may have, but avoid both excessively long clauses and too fine a granularity.

Many if not most clauses will have subclauses, and those subclauses may well have further subclauses.  Bigger fleas have smaller fleas upon their backs to bite 'em. And smaller fleas have lesser fleas, and so ad infinitum.  Level two clauses must be rendered in style Heading 2, level 3 in Heading 3, and so on.  You can subdivide a clause down to six levels.  (Notice that only the higher levels are listed in the table of contents, which would otherwise become too unwieldy.)  If absolutely necessary, you can go beyond six levels, but for all clause title lines from six onwards, use style H6 (not Heading 6).

For clause numbers, retain the arabic numeral system for all levels.  Do not insert a full-stop at the end of the clause number, and separate the clause number from its title by exactly one tab character.

Avoid "hanging paragraphs" - that is, the paragraphs rendered in red in the hypothetical example below:

2.3   Information transfer

Various message types may be used to transfer information across the interface. The type used depends on the context of the transfer.

Message sets shall be consistent, with no message types shared amongst two or more sets.

2.3.1    Call establishment messages

These messages shall be exchanged between entities to establish a call blah blah blah.

2.3.2   Information exchange messages

These messages shall be exchanged between entities to exchange information between those entities in a circular and auto-tautological manner blah blah blah.

2.4   Some new topic

Blather blah blah blah.

Reference to the hanging paragraphs is ambiguous: if a reference cites clause 2.3 of the above document, does it mean just the two red paragraphs, or does it mean everything below the header for clause 2.3 and above the header for clause 2.4? Thus the following structure should be used, since it is completely unambigous, since reference to clause 2.3 obviously includes all its subclauses, since its entire content consists of subclauses.

2.3   Information transfer

2.3.0   Introduction

Various message types may be used to transfer information across the interface. The type used depends on the context of the transfer.

Message sets shall be consistent, with no message types shared amongst two or more sets.

2.3.1    Call establishment messages

These messages shall be exchanged between entities to establish a call blah blah blah.

2.3.2   Information exchange messages

These messages shall be exchanged between entities to exchange information between those entities in a circular and auto-tautological manner blah blah blah.

2.4   Some new topic

Blather blah blah blah.


The main body of your Spec will be followed by at least one annex. Annexes are labelled A, B, C, etc. If you want more than 26 annexes, label the next ones AA, AB, AC, etc.

Use annexes to contain supplementary information or details which if included in the main body would make the Spec too turgid to understand on first reading.  Every annex except the change history (see below) MUST be referred to from somewhere within the main body of the Spec.  Such references set the context of the annexes, which would otherwise be floating out of orbit, like uncharted asteroids.

Each annex must be preceded by a hard page break.

Every annex of a TS must be clearly labeled as being either "normative" or "informative".  Try to avoid placing informative text in a normative annex, other than where it is necessary to explain or exemplify a passage of normative content.  Under no circumstances put any normative text in an informative annex.

3GPP TRs which are intended to be "published" by the participating 3GPP Standards Development Organizations can contain no normative text - they are purely informative - so in a TR the template omits the "normative" and "informative" tag on annexes. Note that TSs and TRs use different styles for their annex title lines in order that both are rendered elegantly in the table of contents. Annex title lines in TSs must be in style Heading 8, whilst those in TRs must be in Heading 9.  However, TRs which are designated as internal to 3GPP are often used as temporary placeholders for provisions which will ultimately find themselves moved into normative clauses of TSs; for this reason, the no-normative-text-in-TRs rule is relaxed for internal TRs.  Nevertheless, the intended use should be made clear in the Scope clause of the TR.

See below for more information on normative and informative text.

Note that clause numbers in annexes are to be styled as Heading 1 for A.1, A.2, A.3, etc; Heading 2 for A.1.1, A.1.2, A.1.3, etc; Heading 3 for A.1.1.1, A.1.1.2, A.1.1.3, etc and so on. That is, the annex letter and the dot following it do not count towards the heading level.

Change history

The last annex of your Spec must be entitled "Change history" and must be updated each time you release a new numbered version of the Spec.

During the drafting of a Spec, the text may go through a large number of iterations in the course of a single meeting or even between one meeting and the next.  It might be impractical to update the version number for each and every iteration, and in this case, you must avoid the confusion which could arise where several instances of a Spec might be found, all bearing the same version number, by one or other of the following expedients:

  • removing the cover page and the change history annex from the draft, and providing a TDoc title such as "Revision 3 of TR 36.789 v0.5.1"; or
  • issuing a TDoc in the form of a "text proposal" showing only the updated passages; or
  • issuing a "pseudo-CR" which is similar to a text proposal, but has a CR cover page (though is NOT allocated a CR number).

It is usual to issue a formal new version at or shortly after the end of a working group meeting, when you, the rapporteur, have incorporated all the text changes in all the draft CRs or text proposals agreed during the meeting. When issuing a new version, indicate the date that this version was created (and not the date it was presented to the WG or the date it was distributed by email, etc.).

Figures, tables, notes, examples, equations

Your Spec will probably need to include at least some of these elements - a picture is worth a thousand words - and a common approach is needed throughout your Spec.

Each figure and table must be numbered, with a separate number series used for each. Two approaches to numbering are in common use:

  • continuous numbering from start to finish - i.e. 1, 2, 3, 4, 5, ...
  • clause-based numbering, where each clause or major subclause has its own numbering series, e.g. 4.3-1, 4.3-2, 4.3-3, 6.2-1, 6.2-2, 10.7-1, 10.7-2, ...

You may choose the approach you prefer, but do adopt the same approach for numbering both figures and tables, do not mix the two systems.

Figures have their number and title below the figure; the figure must be in style TH and the caption line containing the number and title in style TF. Tables have their caption lines above the table, in style TH.  The text in the body of tables must use styles TAH (heading rows), TAL / TAC / TAR for left-justified / centered / right-justified text for normal rows, and TAN for notes within the frame of the table.

info How to copy a figure from another document?

A simple copy / paste action is hazardous (figures may be corrupted or lost).

Right-click the figure you want to copy from the source document.

In the destination document, select "Insert" - "Object", and the appropriate graphical tool (e.g. Microsoft® Word Picture).

MS Word opens the graphical software window: select "Edit" | "Paste Special" and choose the required output format.

After closing this window, the figure appears as an object embedded into the Word document, which allows safe further edits.

Notes and examples need not be numbered unless there are more than one note or example in a given (sub)clause, in which case those notes should be numbered 1, 2, 3, ... and the series restarted whenever a new clause number is encountered.

For equations, either of the above numbering mechanisms may be used, but it will generally be found useful to number them so that they may be easily referred to from elsewhere in the Spec, or indeed from external Specs. The equation editor of early versions of Word is not compatible with later versions. To edit a TS or TR containing an equation (e.g. for the purpose of creating a Change Request to it) using MS Word version 2007 or later, it is advisable to convert the file to .docx format, perform the necessary edits, and save the modified file back in .doc format.

A note, introduced with the word "Note" and rendered in the special paragraph style "NO" is a formal construct. DO NOT write normative text in a note: in-line notes are always purely informative. However, notes which are in the frame of a figure (normally below the graphic, but always above the caption line) or of a table may contain normative provisions. Such notes must have an explicit reference from somewhere within the figure or table to place them in context.

Editor's notes (which have a dedicated paragraph style) can be used as reminders of things to be added in the Spec at a later date. There are no rules about numbering editor's notes. In principle, when the Spec is 100% conplete, no editor's notes should remain.

Automatic numbering

During drafting, it is likely that clauses and subclauses will need to be added, deleted, or moved from place to place. You might find it useful to use automatic clause numbering to maintain a sequential series of clause numbers. Similarly for figures, tables, notes, etc, Word provides the {seq} field code to make numbering and cross referencing easier and less error-prone. If you do use automatic numbering - and even more so if you don't - keep the numbering logical, consistent, and sequential throughout the Spec.

At the moment when the Spec is approved by the TSG to come under change control, your MCC Project Manager will freeze the clause numbering, and thereafter it must be maintained manually, thus ensuring that existing clause (and figure, table, ...) numbers remain unchanged from version to version and from Relase to Release. Keeping those numbers constant ensures that references to particular clauses (etc) from other Specs will remain correct even as new clauses etc are added to your Spec.

info In fact, the formal drafting rules of TR 21.801 demand that any reference from a 3GPP Spec to another which cites a precise clause (or figure, or table, etc.) must be to a specific version of that referenced Spec. However, this rule was introduced relatively recently, and there are a number of instances where non-specific references do cite a particular clause. Hence the rule mentioned here, that once under change control, restructuring of a Spec is strongly deprecated.

Bullet points

Use bullet points to present lists. A list is much easier to read and digest than a block of continuous text with items separated by commas. An itemized list should use as bullet characters a dash (hyphen), though where there are sub-items, a different character can be used to make the heirarchical level of the item clear. Use numbered items if you need to refer to individual items of the list from elsewhere in the text. The discussion on automatic numbering above applies equally to numbered list items.

Follow the bullet or number character with a tab to ensure correct alignment of the paragraph.

DO use the appropriate paragraph style: B1 for top level, B2 for second level, etc. These styles will automatically indent items from the left margin an appropriate distance according to their level. DO NOT use Normal style then manually indent.

Language and linguistic style


3GPP Specs are to be written in English. All 3GPP business is conducted in English, so anybody offering themselves as a rapporteur will obviously have at least a fair command of the language.

But which English? Most rapporteurs will be familiar with either British English or American English, and these are the varieties you should aim to use.

info You can find comparisons between British English and American English vocabulary on the web, for example:
but few of the commonly differing words are likely to appear in 3GPP Specs.  There are, however, a number of words which are spelt differently in the two varieties, for exmple
  British: routeing       American: routing
  British: signalling       American: signaling
  British: through       American: thru
and many more.  See, for example,
for a comprehensive, if not necessarily entirely reliable, review of the differences between the languages.

The guidance for a rapporteur is: choose one or the other, and stick to it throughout the entire Spec. This means you may have to adjust text proposals coming from delegates who speak the "other" English before you incorporate them into your document.  It is important that a Spec reads as a uniform document, and not as a collection of contributions having different spellings and linguistic styles.

For further ventilation on the style and vagaries of English, see the ETSI Guide to the use of English.

-ise or -ize ?

A frequent cause of disagreement is the spelling of "-ize" words, such as "standardize". The suffix "-ize" is used to form verbs meaning "bring into some state" specified by the noun or adjective of the stem. Thus "standardize" means to bring into a standard state.

info The suffix "-ize" is derived from the Greek "-izein", which has precisely this meaning. Most British writers educated in the 1960s onwards would use the suffix "-ise": "standardise". Most American writers educated in the 1620s onwards would retain the "-ize" spelling advocated by the Oxford English Dictionary (and, of course, Webster's).  The "-ize" version has the merit of being closer to the original Greek suffix from which it is derived. However, American writers frequently take this too far since many would use "-ize" in verbs and even nouns where the suffix is not related to the above meaning: "compromise" does not mean "bring into a state of comprom" and "revise" does not mean "bring into a state of rev" any more than "advise" means "bring into a state of adv".  Hence for these words, and many more like them, "-ise" is the only logical spelling, deriving in these cases from the past participle of a Latin verb, always spelt with "s". The modern British English writer is spared the thought process of deciding whether to write "-ize" or "-ise" as a function of the etymology of the word by simply using "-ise" for everything, in much the same way as an American English writer would systematically write "-ize" for everything. The most blatant example of the unwarranted "z" in American English is the spelling of "analyze".  Here, the suffix is (or should be) -lyse from the Greek lusis meaning loosening or resolution, and is quite unrelated to "-ize".  The only logical spelling is "analyse".

Omitted articles

Many of the native languages - Finnish, Russian and other Slavic languages, Japanese, Mandarin Chinese, ... - spoken by rapporteurs do not have one or other of the definite article "the" or the indefinite article "a" ("an" before a vowel sound), and these writers may have to rely on their colleagues who are more used to using articles to advise them as to where, in English, they are necessary and when they are not.  Even rapporteurs whose native language does have these articles may find that their usage differs in English.

German punctuation

Actually, this clause relates to all punctuation other than non-standard English punctuation (of which there are at least two schools of thought anyway).  The basic advise is to keep sentences short enough that little or no punctuation (other than the terminal full-stop / period) is needed.  Germans in particular tend to write sentences with very long subjects, and to separate the subject from its verb with a comma.  This is probably a reflection of the need to breath at that point in the sentence, but has the effect of breaking the thought train so that a native English speaker (at least) will probably have to go back to the beginning of the sentence and re-read it mentally omitting that comma.

Example:  Terminal equipment in the powered up but idle state which receives the auto-wake-up command and which is capable of providing visual feedback to the user, shall inform the user of the event.

Curly quotes (Smart quotes)

Disable this feature of your word processor. 3GPP Specs must use "straight" quotes, not the "comma-shaped" characters to which most installations of Word default.

info The rendering of quotation marks is a good indicator as to whether you have inadvertantly changed the default language of your Spec from British English to, say, French guillemets (where the marks will be rendered as small double chevrons: « ») or German Hochkommata (where the leading Gänsefüßchen will be on the base line rather than superscripted: „ ”).

Use double quotation marks, not single, since single quotation marks can be confused for appostrophes. However, if it is unavoidable to nest quotations within quotations, use double marks for the outer ones, and single marks for the inner ones.

Style and idiom

Bearing in mind your international readership, you should keep the style of the language of your Spec as simple as possible, compatible with being clear and unambiguous. Native English speakers, in particular, should take care not to use colloquial words or phrases, or regional idioms. Restrict your vocabulary insofar as possible to words which are likely to be readily understood by the vast majority of your readership.

Specs are to be written in the third person: avoid the pronouns "I" and "we".

Defined terms and abbreviations

If your Spec will make repeated use of a term or an abbreviation, make sure it is defined. The definition must appear in one of:

  • clause 3 of your Spec, or
  • the common 3GPP vocabulary document, TR 21.905, or
  • clause 3 of another 3GPP Spec which you explicitly reference, or
  • a technical document from some third party (such as an ITU Recommendation, an ISO standard, etc), which you explicitly reference.

If you are inventing a new term, first ask yourself whether that term or something very similar is already in use elsewhere in 3GPP.  If so, try to re-use that existing term.  If not, by all means create a new term, but try to make it sufficiently different from any existing term so as to minimize the possibility of confusion between them.

If your new term is likely to used beyond the bounds of your own Spec, consider making it generally available by inserting it in TR 21.905. It will then automatically be available for use within your Spec.

It may seem like a convenience to the reader of your Spec to copy the definition of a term from some other document so it is readily to hand rather than making the reader go off to the other document to search for it; but convenience for the reader is in this case secondary to rigorously correct terminology.  Avoid duplicating a definition which is already to be found in TR 21.905 or in some other 3GPP Spec. If any element of a Spec is replicated, it is certain that, with the passage time, those replicas will mutate and 3GPP will end up with multiple definitions of the same term.  This is obviously undesirable.

If you find that you cannot avoid re-using an existing term but cannot avoid giving it a slightly different meaning in your Spec to that which it has elsewhere, then the definition you include in clause 3 of your Spec will override all other definitions of that term. It might be worth adding in a note below the formal definition that this differs from the same term defined in other Specs.

You should use a defined term to express the same concept each time you use it.  You are not writing a gothic novel or a bed-time story.  You are writing a technical specification or report.  Thus once you have a term with a particular meaning, continue to use that term - and no other - each time you want to express that concept.  If the term is lengthy or complex, you may want to use it in abbreviated form; the same considerations apply to abbreviations as apply to terms.  This practice may make your Spec less readable, but it will more more rigorously technically precise, and faulty logic or ambiguities will be more easily detected.

Normative and informative text

Notwithstanding the foregoing section on Language, you should realize that 3GPP TSs (and to a lesser extent, TRs) are not written in everyday English, but have to observe some conventions of language which are laid down in the formal drafting rules.  Provisions of a Spec (that is to say, passages of text, including figures and tables) are divided into "normative" and "informative" types.

Normative content lays down the requirements of a TS: things which have to be complied with, or it is recommended to comply with, or are possible to comply with.

Informative content gives information or possibly guidance to implementors, but with which it is not necessary (or possible) for equipment to comply with.

Linguistic conventions - verbs

3GPP Specs are not written in "ordinary" English, but in a special "standardese" where certain conventions over auxiliary verbs apply. These conventions can be confusing for some non-native English speakers, whose own languages may have no equivalent to these words.

Mandatory requirements, use "shall": "The equipment shall send a setup message."

info DO NOT follow the IETF convention of using "must" instead of "shall": you shall use shall, you shall not use must.

Recommendations, use "should": "If there is supplementary information to convey, the equipment should send an information message."

Permissions, use "may": "The equipment may send an information message if it wishes to convey status information to the remote equipment."

Describing events which are outside the scope of the Spec, but which need to be taken into consideration, use "will": "The remote equipment will respond with an acknowledge message."

Stating facts, use present indicative: "The parameters are under user control."

Note that in the "recommendation" above, the recommendation was qualified with a condition: "if xxx then yyy". If at all possible, "should" is to be avoided, because, despite being a recommendation, it leaves the choice entirely to the implementer. Far better to specify a rigorous option with a mandatory action, as in "If there is supplementary information to convey, the equipment shall send an information message."

The use of "may" is even woolier, since there is not even a recommendation as to which action is more desirable, to do or not to do. Again, avoid "may" if at all possible.  Note that the negative of "may" is "need not", since "may not" is ambiguous.

Active or passive

Despite very many examples of the contrary, it is usually better to express provisions in the active voice rather than the passive voice, since the former explicitly states who or what is to carry out the action, whereas the latter can leave this unstated and therefore vague.

Thus prefer
"The user equipment shall confirm the receipt of the notification by returning an acknowlege message."
"On receipt of the notification, an acknowledge message shall be returned."
In the second example, it is not clear whether the duty of returning the acknowledge message is on the user equipment or on some other entity such as the distant end gateway.


Use the paragraph and font styles included in the template. It is seldom necessary - and always undesirable - to add new styles, and absolutely forbidden to modify existing styles

You may use italic and bold font for emphasis, but NOT underlining, because this can be confused with revision marking. For the same reason, avoid coloured font. If it is absolutely necessary to use coloured font, DO supply a key so that the reader knows the significance of each colour. But ideally, stick to automatic font colour (normally black).

DO NOT add blank paragraphs or manual page breaks to introduce vertial white space. This is never necessary. If your document throws a page break in an undesirable place, use Word's paragraph properties to, for example, keep all lines of a paragraph together, to enable widow/orphan control, to keep-with-next. In this way, you let Word insert page breaks where necessary, and prevent it from inserting them where undesirable.

DO NOT add vertical white space (leading) using blank paragraphs, except to ensure a clause title line does not immediately follow after a table (where layout can go wrong if this is not done). DO rely on the built-in paragraph styles to govern vertical spacing.

info If paragraphs of style "Normal" have no vertical white space after them, or if they are double-margin justified, it is a sure sign that your Spec does not have the 3GPP styles attached!

Never force a page break before a new clause.

Always force a page break before each new annex.

Use of tradenames, registered trademarks, etc. in Specs

In a word - don't. If at all possible, avoid using registered names or marks in your Spec, and use generic terms instead. If being specific is unavoidable, research the ownership of the tradename or mark, and acknowledge that organization's marks at the start of the Spec, at the foot of page 2.

Table of contents and history table

Each time you edit the draft Spec, remember to refresh the table of contents, and to update the history box at the end of the document to show the meeting at or shortly after which you edited it, the tdoc number (if any) of the new version, the changes wrought (for example by listing the tdocs bringing agreed text proposals to the Spec), and the new version number.

See also the clause above concerning the history table.

Be aware that the page numbers in the table of contents will vary as a function of the paper size (e.g. A4 or Letter) and margin settings on your default or chosen printer. Therefore, do not rely on the page number shown in the table of contents, but rather on the clause number. Never use page numbers in references, either within a Spec or to external 3GPP Specs.

ASN.1 in Technical Specifications

Many TSs include data structure descriptions in ASN.1. If you are proposing to add formal ASN.1 to a Spec (i.e. contributing a pCR or CR tdoc) and you need to define new Object Identifiers, then follow the instructions on how to allocate OI node values which you can find on the ASN.1 page.

Presentation of draft to TSG for information

More information on this, and the following, procedural aspects can be found in the 3GPP TSG Working Procedures, TR 21.900.

When the working group is agreed that a draft Spec is mature enough - subjectively at least 60% complete - it must be sent to the next TSG meeting for information. This simply gives the document wider visibility, and allows feedback from a wider circle of competence than just the working group delegates. 

The decision that a Spec is ready to be sent for information will be recorded in the meeting report. Send the working-group-agreed text to your MCC Project Manager. The version number will at this point be 0.<something>.<something> (unless it has already been seen by the TSG and is going round the loop again). The Project Manager will now run a final critical eye over your Spec and make any necessary minor improvements which may be necessary to ensure alignment with the 3GPP Drafting Rules (and the guidance on this page).

It sometimes happens that the actual Spec is not available by the end of the meeting, and the rapporteur needs a few days to incorporate all the finally agreed text. Remember that your MCC Project Manager will need additional time to do his final check on the document, and that he may have several Specs to handle in the same time scale. When he has finished his check, he will raise the Spec to version 1.0.0 and send it back to you, the rapporteur.

When presented to the TSG, the Spec must be accompanied by a special cover sheet which indicates the progress made since the previous presentation to the TSG (obviously this part will be left blank the first time it is presented).  It is your responsibility to fill in the cover sheet, and to obtain a TSG tdoc number, and to prepare the tdoc containing your cover sheet plus the MCC-adjusted version of the Spec itself.

It is normally only necessary to present a draft Spec to the TSG for information once. Drafting then resumes in the Working Group. DO make sure you use the version seen by the TSG (normally 1.0.0) as the starting point for further modifications, NOT the version you yourself last edited.

Presentation of draft to TSG for approval

When the working group is agreed that a draft Spec is mature enough - subjectively at least 80% complete - it must be sent to the next TSG meeting for approval.

The steps involved are similar to those above for presenting for information, except that this time, MCC will raise the WG-agreed document to version 2.0.0. The same cover sheet is used in the TSG tdoc, but obviously containing updated information. Pay particular attention to describe in some detail the remaining points of contention or incomplete elements. This text may be used to influence the decision as to whether the work is complete or not (i.e. the percentage completion of the work item concerned).

If the TSG approves the draft Spec, then it will be brought under change control - see below.

If, however, the TSG does not consider the Spec to be ripe enough for approval, it may ask the WG to continue to develop it, and this presentation for approval step will have to be repeated, with the rapporteur producing versions 2.y.z until it is again considered to be ready for approval. Again, the MCC Project Manager must give it a final once-over for conformity to the rules.

Ideally, when a Spec is brought for approval, there should be no, or at least very few, remaining "editor's notes" and "for further study" elements.

Combined information and approval

Although in contradiction of the formal working procedures (TR 21.900), in cases of urgency, a working group may decide to bring a mature Spec for information and for approval at a single TSG meeting, in effect combining the above proceeses. In this case, the Spec will be raised to version 1.0.0 (not 2.0.0), and the TSG may (or may not) immediately approve it to come under change control.

Spec brought under change control

Once a Spec has been approved by the TSG to be brought under change control, the MCC Project Manager will raise it to version x.0.0 where x represents the Release in question. From this point onwards, you, the rapporteur, have no right to edit the Spec. All changes must be done via formal change requests. However, you still have an important role to play in, for example, 

  • assisting your fellow working group delegates in the formulation of CRs;
  • reviewing CRs to your Spec to ensure there are no mutual contradictions amongst them;
  • checking the accuracy of CR implementations by MCC;
  • acting as a contact point and font of all knowlege for technical enquiries concerning the Spec.

 Nevertheless, the bulk of your creative work has reached a successful conclusion so ... congratulations!

And finally ...

You may be interested to read ETSI's A Guide to Writing World Class Standards published (2020 version supersedes 2014), a guide to rapporteurs and contributors to standardization.



Page last reviewed / updated ...
Link to 2020 version of A Guide to Wirting World Class Standards, replacing 2014 version [2020-08-28]
to indicate actions if a Spec's rapporteur can no longer continue in the role; to update guidance text on the use of .doc and .docx file formats [2019-01-05]
to add a hint on how to edit Specs containing equations [2014-09-24]
to "hide" supplementary informative text in rollover pop-up boxes [2014-05-06]
to incorporate remarks from F Firmin and M Pope [2014-03-20]
clarification on hanging paragraps and clause styles in annexes [2015-01-06]
to correct a spelling mistake [2016-08-05]
adding explanatory info tip on how to copy figures from one document to another [2018-03-07]
to add instructions relating to ASN.1 Object Identifiers [2018-04-10]

John M Meredith 


Fixed IMS mapping

Fixed network core IMS mapping (TISPAN)

Please click here to see the table of the ETSI publications relating to core functions of the IP Multimedia Subsystem (IMS) used by the Next Generation Network standardized within ETSI Technical Committee Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN). Because of different working methods between TISPAN and 3GPP, NGN Release 1 (R1) and (...)


More News:
News Feeds