Structure of 3GPP

3GPP is organized into several different Technical Specification Groups (TSGs). These TSGs are responsible for the technical work and production of the specifications. There are four TSGs, split across the different areas that 3GPP works with:

• TSG GERAN: responsible for the specification of the radio access part of GSM/EDGE.

• TSG RAN: responsible for the definition of the functions, requirements and interfaces of the UTRA/E-UTRA (WCDMA and LTE) radio networks covering both FDD and TDD variants.

• TSG SA: responsible for the overall architecture and service capabilities of systems based on 3GPP specifications, and also for co-ordination between the different TSGs.

• TSG CT: responsible for specifying terminal interfaces and capabilities. Also responsible for specifying the core network protocols of 3GPP systems.

Each of these TSGs has a number of Working Groups (WGs) associated with them; each WG is responsible for a certain number of tasks within the mandate of the TSG that they fall under. For example, WG SA1 is responsible for system requirements, while WG SA2 is responsible for the system architecture. WG CT4, meanwhile, handles the protocol definition for Basic Call Processing and protocols between nodes within the Network. The relationship between the TSGs and the different WGs is illustrated below.

The overall management of 3GPP, for example, organisation and allocation of work, is handled by the highest decision-making body in 3GPP – the Project Coordination Group (PCG).

Each WG in 3GPP is responsible for producing Technical Specifications (TSs) and Technical Reports (TRs), that is, the actual technical documents that can be downloaded from the 3GPP website (www.3gpp.org), but they are not allowed to just create whatever specification they like and publish it; each TS and TR must go through an approval process within the TSG responsible for their particular WG. Once this is completed, the specifications can then be taken to regional organizations (such as ETSI for Europe) to be approved as formal standards, or the ITU for use in their set of standards.

Each TS and TR is referred to be a set of digits; ‘xx.yyy’, where xx refers to the so-called series number, while yyy refers to the particular specification within that series. As an example, 23.401 indicates that it is a system architecture document (23 series), while 401 refers to the actual specification, in this case: GPRS enhancements for E-UTRAN access.

LTE specifications are handled in RAN WG1, RAN WG2, RAN WG3, RAN WG4 and RAN WG5. SAE specifications, meanwhile, are handled in SA WG1, SA WG2, SA WG3, CT WG1, CT WG3 and CT WG4. Each of these WGs is responsible for a different section of the SAE work and will be covered in more detail in subsequent chapters.

Stages in 3GPP standardization

When 3GPP develops a new standard or amends an existing standard, the work proceeds in three logical phases; stage 1, stage 2 and stage 3. It has been adopted by 3GPP and is also used by several other standardization organizations. It can be noted that work on the three stages often takes place simultaneously, or at least with significant temporal overlap, in order to make the standardization work time efficient.

During stage 1 the service requirements are specified, that is, the functions that the system as a whole is intended to support. In the next step, stage 2, the architectural requirements are specified, taking the stage 1 requirements into account. This means that the different logical network entities and the reference points between the network entities are defined. The purpose and functions of each network entity and each reference point are also specified. The procedures, that is, the logical message flow between network entities, are defined; including what information is transferred across the reference points. In the third stage, stage 3, the actual protocols are defined based on the architectural work done during stage 2. Each message is specified in detail and the message content such as parameter formats, information element structure and so on, is defined. The stage 3 work also has the very important task of making sure that error cases are handled appropriately by the system. This includes, for example, defining relevant result codes in response messages.

Tracking down the right specification in 3GPP

All 3GPP specifications are freely available online for anyone to read. In order to find the right specification, it is generally easiest to search for it by its specification number, for example, 23.401, or via the working group responsible for its development, for example, SA2.

An important thing to remember when searching for specifications is to ensure that the release number is correct. 3GPP uses a parallel release mechanism in order to ensure that any developer has a stable platform to work upon. Once a release is frozen, it means that no more functional changes may be made to the specifications; they may, however, be changed if errors are found or for maintenance purposes.

Different WGs often work towards different releases at the same time. For example, the requirements specifications developed in SA1 are often frozen at a much earlier date than for the System Architecture documents created in SA2. So, SA1 may be working on Rel-9 requirements, while SA2 is working on Rel-8 architecture documents. This is quite natural; in order to ensure that SA2 has a stable set of requirements to work upon, they need to be frozen before work can commence.

A full list of different specifications and the working groups responsible for them at the time of writing is available in Appendix A.

Structure of the IETF

The IETF is split into different areas: Applications Area, General Area, Internet Area, Operations and Management Area, Real-time Applications and Infrastructure Area, Routing Area, Security Area and the Transport Area. Each of these areas has several WGs under its directorship and each WG has a particular technical subject that it works on and produces a set of documents for. The WGs are therefore referred to as ‘Area Directorates’. WGs are created for specific purposes and after their documents are complete, they are either disbanded or ‘rechartered’ with a new set of deliverable documents. As a result, the active WGs in the IETF change; the latest list of WGs is, at the time of writing, available at: http://www.ietf.org/html.charters/wg-dir.html.

WGs are assigned a unique acronym which identifies the task that they are working on, for example, mip4 relates to Mobility for IPv4, or sipping refers to the group that handles the SIP, the protocol that forms a key component of the IMS.

In a similar fashion to 3GPP, the IETF has an overall group that forms the technical management team of the IETF; this is called the Internet Engineering Steering Group (IESG). Each Area Directorate has one or two directors who join the IETF chairman in the IESG. It is the IESG’s responsibility to review all specifications that the WGs produce and also to decide on the overall technical direction that the IETF will take, that is, what areas the IETF should work on.

A high-level view of the IETF is illustrated below: