network 2020 operator interest group processes - gsma.com · pdf filesecurity classification...

GSM Association Confidential

Management Control Strategy

V0.2 of 15

Network 2020 – Operator Interest Group Processes


Version 1.0

Security Classification: This document contains GSMA Confidential

Information

Access to and distribution of this document is restricted to the persons listed under the heading Security Classification Category. This document

is confidential to the Association and is subject to copyright protection. This document is to be used only for the purposes for which it has been

supplied and information contained in it must not be disclosed or in any other way made available, in whole or in part, to persons other than those

listed under Security Classification Category without the prior written approval of the Association.

Security Classification – CONFIDENTIAL GSMA Material Can be distributed to: (mark X as appropriate)

Confidential GSMA Full Members X

Confidential GSMA Associate Members

Confidential GSMA Rapporteur Members

Confidential GSMA Parent Company Members

Copyright Notice

Copyright © 2016 GSM Association Antitrust Notice



V0.2 of 15

Table of Contents

1 Introduction 3

1.1 Overview 3

1.2 Scope 3

1.3 References 3

2 Governance structure 4

3 OIG workstream flow and key milestones 5

4 OIG Working principles 6

4.1 Basic working principles 6

4.2 Conflict resolution 6

5 Stages of delivery 7

5.1 OIG Conception 7

5.2 Gate 0 – Initial conception 7

5.3 Gate 1 – Full plan and scope 7

5.4 Proof of concept (PoC) 9

5.5 Testing 10

5.6 Candidate Contribution status 10

5.7 Gate 2 – Final documentation to be included within an RCS release 11

5.8 OIG project closure 11

6 Roles and responsibilities 12

7 Stakeholder Reporting 14

7.1 Reporting to the GSG / GFRG 14

7.1.1 Examples of outputs that are reviewed or/and approved by the

GSG/GFRG 14

7.2 Reporting to IP Comms ET 14

7.3 Reporting and liaison with external Network 2020 parties 14

8 GSMA Infocentre2 14

Document Management 15

Document History 15

Other Information 15



V0.2 of 15

1 Introduction

1.1 Overview

The aim of this document is to formalise the procedures and processes that govern an

Operator Interest Group (OIG) and support “agile” feature development within a set

specification release cycle. The document will also establish and formalise the cooperation

principles among the OIG’s stakeholders and governance structure, so the involved parties

(GSMA and members), clearly understand their role.Scope

This paper proposes a framework for analysing the operation of management control systems

for OIGs structured around the following central issues:

Governance structure

Roles and responsibilities

OIG Working principles

Stakeholder Reporting

Project and work stream flow and key milestones

1.2 References

Ref Title Description

[1] Operator Interest

Groups (OIGs)

Operator Interest Groups provide the framework for operators to

develop innovative concepts which build on the RCS specification in

smaller agile groups before they are contributed to the next

specification.

An OIG will consist of a group of operators, vendors and relevant

stakeholders, convened by a Lead operator (or operators), working

together in a transparent way to:

• focus on a single IP Communications enabler- or feature-

area,

• define a proposed solution description and specification

• develop a technical solution and implement as a proof of

concept or commercially available service

• disband once the plan goals have been achieved

[2] Network 2020

The GSMA’s Network 2020 Programme is designed to help operators

address and navigate the complexities of progression to an All-IP

world. Embracing this future is vital for mobile operators as they

compete to win customers and retain customer relevance. The

GSMA is working with mobile operators to use native IP

communication services such as voice and video calling over LTE,

Rich Communication Services, and HD Voice to provide the same

‘carrier grade’ experience historically linked with voice services

initiated via a handset’s green button.

[3]

IP

Communications

Execution Team

(IP Comms ET)

The IP Communications Execution team consists of delegates from

operators (full GSMA members) who have publicly committed to

launch Rich Communication services within 18 months and have



V0.2 of 15

Ref Title Description

appropriate business roles and the ability to make decisions on

behalf of their company.

[4]

RCS Global

specification

Group (GSG)

RCS Global Specification Group (GSG) is set up and governed by

the IP Communications Execution Team to continue with the

definition of the specification beyond RCS5.1. The goal of the group

is to produce a set of converged specifications for Rich

Communication Services. The GSG is open to members from MNOs,

device vendors, infrastructure vendors and software vendors.

[5]

RCS Global

Functional

Requirements

Group (GFRG)

RCS Global Functional Requirements Group (GFRG) is set up and governed by the IP Communications Execution Team, it is responsible for delivering Service Descriptions for the Global Common Core of RCS functionality for open market devices. The GFRG works to:

Ensure each release of the RCS specification meets the needs of all participating mobile operators

Provide a clear, well-developed and prioritised set of requirements to the Global Specification Group at the outset of each specification development cycle and,

Act as the voice of the end-user throughout the specification life cycle.

The GFRG is open to MNO members only.

2 Governance structure

Figure 1: Governance structure



V0.2 of 15

3 OIG work stream flow and key milestones

Figure 2: Process diagram

Figure 3: Recommended time allocations and focus

In addition to outlining the workflow for an OIG, Figure 2 also reflects the business as usual

workflow for the GSG and GFRG. The procedures applied are well defined within the

respective groups and therefore are not covered in this document.

Before an OIG is commissioned, there should be consideration given towards whether the

OIG process is the right application required or whether the change is best managed as part



V0.2 of 15

of business as usual i.e. general maintenance or a dedicated taskforce/focus group.For

example if developing a proof of concept to validate a change is not required, the change

may be addressed better using a focus group.

The procedures for a focus group are out of scope for this document.

4 OIG Working principles

4.1 Basic working principles

An OIG must follow the following principles:

• All feature development needs to be fully transparent to all from point of inception i.e.

must declare each initiative that is intended to enter the specification (recommended

from anti-trust perspective)

• An OIGs should set clear S.M.A.R.T. objectives (Specific, Measurable, Achievable,

Relevant, Timed) and tackle issues that extend over a year in a phased approach.

• A minimum of two Operators (i.e. Full members of GSM Association) can form an

OIG.

• Associate members of GSM Association may join an OIG. Indeed, such vendor

participation is encouraged.

• Participants must be active i.e. preparation of contributions, development of

prototypes, test clients and environments, interconnects etc.

• MNOs and vendors who do not participate may still follow the OIG on Infocentre, as

key documents will be available openly there.

• Decision-making is by consensus between active, participating companies. In

circumstances where consensus cannot be reached, and voting is required to make

decisions, active operators shall vote, one-company, one-vote.

• The Chair of the Operator Interest Group shall endeavour to incorporate all

participating companies views, requirements and use cases into the output of the

OIG.

4.2 Conflict resolution

Where the scope of an OIG is broader than the resources available to support it, the OIG

Chair is encouraged to develop a phased approach ensuring deliverables are accomplished

in the shortest feasible time and the entire scope of the subject matter is addressed over

time.

Where it becomes clear that it is not going to be possible to reach a decision or an area of

conflict is identified, the OIG(s) may decide to escalate the decision to the GSG/GFRG.

If a decisive outcome cannot be achieved within the GSG/GFRG it will be escalated further

to the IP Comms ET for a final decision. If the IP Comms ET rules against an OIG’s decision,



V0.2 of 15

and no corrective actions are made, the GSMA may withdraw resourcing and support from

the OIG.

5 Stages of delivery

5.1 OIG Conception

Ahead of an OIG’s initial kick off, a minimum of 2 operators is required to support the

proposed feature.

Upon meeting this criteria a request to kick off an OIG should be sent to the relevant GSMA

contacts upon the OIG’s official infocentre2 page: here. The first OIG meeting will then be

facilitated by the GSMA.

5.2 Gate 0 – Initial conception

The Gate 0 is when an OIG defines its initial ideas and intentions. The Gate 0 document is to

be created at the initial OIG kick off meeting and should include:

Feature Name

Leading and supporting Operators / Members

Feature description

Expected technical solution

Feature User Stories or use cases

Release target

The official Gate 0 template can be found on the infocentre: here

Upon completion the Gate 0 document is circulated to the GSG/GFRG and IP Comms ET for

information, and not formal approval, so that all companies that are interested in the feature

have visibility of the OIG’s initial proposal and are able join the group to contribute.

A formal objection can be made to the IP Comms ET if a group already exists that addresses

the topic. If this is the case it is encouraged that those proposing the new OIG joins the

existing group to contribute.

5.3 Gate 1 – Full plan and scope

The overall goal of Gate 1 is to improve the chances of successfully being approved at Gate

2, and as such, being included into the relevant specifications. This is achieved by providing

full visibility of all proposed activities to ensure all considerations have been sufficiently

thought out.

The GSMA recommend that OIGs should achieve Gate 1 approval within 2 months of Gate

0’s document circulation to maintain momentum, focus and ensure the outcome is still

achievable in the timeframe proposed by the OIG. An extension of this period, with a

justification of why it is needed, can be requested (e.g. significant comments have been

https://infocentre2.gsma.com/gp/pr/V2020/N2020/IPCOIG/Pages/Default.aspx

https://infocentre2.gsma.com/gp/pr/V2020/N2020/IPCOIG/WorkingDocuments/Forms/AllItems.aspx?RootFolder=%2Fgp%2Fpr%2FV2020%2FN2020%2FIPCOIG%2FWorkingDocuments%2FOIG%20Gate%20Management%20document%20templates&FolderCTID=0x012000E5D8E2520E818540B00064E013DF145E&View=%7b4CAA0193-3CF1-4220-94B3-4CEA0A5FA507%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence



V0.2 of 15

provided to the Gate 1 document, holiday period, etc). If this timeframe is not achieved the

situation will be raised by the GSMA Project Manager to the IP Comms ET who can assess

the situation and decide to close the OIG. It is highly recommended that OIGs, with a very

large proposed scope, should phase their approach.

In addition, Gate 1 exists to:

Confirm the OIG’s scope and set S.M.A.R.T. objectives

Communicate any limitations (which could potentially be handed over as work items to

the GSG, Working Groups or other OIGs)

Identify collaboration opportunities between OIGs and other stakeholders

Avoid fragmentation and conflicts in approaches between OIGs and other stakeholders

The Gate 1 document is the first detailed document of the full scope and plan of the OIG and

is used to communicate to the GSG/GFRG and to identify any other relevant stakeholders

(such as other OIG groups or external standards bodies).

The Gate 1 document should consist of:

The feature scope

Interaction and impact with existing services

Areas of collaboration with other groups

The technical scope

Proposed changes and endorsements of specifications

Considerations of testing and backwards compatibility

A project plan

A proof of concept plan

The official Gate 1 template can be found on the infocentre: here

The approval process for a Gate 1 document:

The OIG are required to submit their Gate 1 document to the GSG and GFRG for a week of

offline review, a dedicated conference call will then be held for interested parties and OIG

representatives to address any comments. Within this period the GSG/GFRG provide

consultation to the OIG on their proposed activities and how best to proceed to ensure

approval at Gate 2. This will need to be considered and included into an updated Gate 1

document.

Depending on the nature of the comments, the GSG/GFRG chairs can call for approval of

the Gate 1 document within the call, set up a follow up call for approval or circulate the

revised version for email approval.

https://infocentre2.gsma.com/gp/pr/V2020/N2020/IPCOIG/WorkingDocuments/Forms/AllItems.aspx?RootFolder=%2Fgp%2Fpr%2FV2020%2FN2020%2FIPCOIG%2FWorkingDocuments%2FOIG%20Gate%20Management%20document%20templates&FolderCTID=0x012000E5D8E2520E818540B00064E013DF145E&View=%7b4CAA0193-3CF1-4220-94B3-4CEA0A5FA507%7d&InitialTabId=Ribbon%2EDocument&VisibilityContext=WSSTabPersistence



V0.2 of 15

After Gate 1 has been passed, any proposals and scope changes by new joiners need to be

agreed by the OIG members that developed Gate 1. Any late joiner should join on good

faith, and be respectful of the timelines and existing scope of the OIG.

If a use case, that is out of scope of the OIG’s Gate 1 document is identified, and a

GSG/GFRG member is of the opinion that it should be included, they will need to provide the

adequate resource to accomplish this, otherwise it is the discretion of the OIG to accept or

note the use case.

Areas of comments that are considered within the Gate 1 review, and need to be considered

or addressed before progression:

If a services causes conflict and/or breaks implementations of other services that

have been or will be deployed. (Unless the GSG/GFRG decide that the benefit from

the new service is greater than the cost of changing the specification.)

A major comment is received and there is an agreement between the OIG and the

GSG/GFRG on a path of corrective actions to address it ahead of Gate 2.

Follow on actions to ensure a smooth transition to Gate 2:

Communicate any major changes made to the scope of the Gate 1 document ahead

of reaching Gate 2 to the GSG/GFRG. (Such as aspects identified and changed

during a proof of concept / limited market launch phase).

5.4 Proof of concept (PoC)

A key component of the OIG process is the need for an OIG to validate the use cases and

requirements which they are proposing.

An OIG is required to develop a technical solution and implement a proof of concept to

demonstrate that the solution works.

Developing a PoC provides the opportunity to:

Validate use cases through use in friendly user trials (FUT) / concept testing to gain

feedback

Detect and correct issues with the proposed specification

Ensure that the proposed approach is mature

Gain implementation experience ahead of eventual commercialisation, potentially

reducing the commercialisation effort/time to market.

It is at the OIG’s discretion to determine the scope of the PoC and the approach taken. The

OIG process identifies two possibilities:

1. Lab based- recommended for proving elements which only affect the network

2. Limited market trial- recommended for new feature/service propositions.



V0.2 of 15

5.5 Testing

The level of testing and the approach to testing is left to the discretion of the OIG to

determine what is applicable.

An OIG is required to provide their test scripts as an output in addition to the specification.

5.6 Candidate Contribution status

The RCS Candidate Contribution status is an interim stage between Gate 1 review and Gate

2 approval into the standards.

To be considered as a Candidate Contribution the following criteria should be met:

Passed OIG Gate 1 review

Baseline product requirements are validated

Baseline proposed technical solution are validated

Baseline documentation published on RCS Contribution space (Infocentre and

GSMA website)

Once this status has been reached, features can be launched with a reasonable guarantee

that the feature will remain stable.

OIGs are encouraged to capture the learnings from testing and trials in the final OIG

contributions which are submitted to the standard.

Relationship between Candidate Contributions and Commercial profiles

In general, a new feature should only be included in a profile release if it has successfully

passed Gate 2 and has been incorporated into the standard.

However a ‘Candidate Contribution’ can be included in a profile release provided the

following conditions are met:

The OIG feature requirements can be achieved without any modification to the

existing technical specification release

There is no NNI impact on operators who do not launch the service/feature.

The approval process for Candidate Contribution status:

The OIG submits their proposed technical specification to the GSG for a 2 week company

review period to collect comments, a series of dedicated conference calls will then be

scheduled for interested parties to address any submitted comments. Once the comments

have been addressed the OIG’s technical specification can be approved within the

conference call or the revised version could be circulated for email approval at the GSG

chairs’ discretion.



V0.2 of 15

Once the OIG’s technical specification has been approved within the GSG it will be

circulated to the IP Comms ET for information. It will then be submitted to the GSMA’s

official document approval process by the GSMA project manager for PSMC approval.

Note: The issuing approval group of any OIG PRDs will always be set as the GSG, to

approval any proposed changes to the PRD by the OIG.

5.7 Gate 2 – Final documentation to be included within an RCS release

The overall goal of Gate 2 is to determine whether an OIG’s output should be included in the

relevant specifications.

Gate 2 can be reached when:

The OIG has passed Gate 1.

The relevant Gate 2 documentations have been produced and agreed upon in the

OIG.

o Change requests to relevant GSMA owned specifications

o Inclusion or CRs to be included into the Common Core

The implementation is proven to be valued by customers and works without issues,

this can be achieved by:

o A proof of concept created and proven to be robust in real world scenarios

(further details included in 5.4 and 5.5) or,

o Candidate Solution Status limited market launch with findings and customer

feedback (further details included in 5.6)

The approval process for a Gate 2 document:

Once an OIG has reached the above criteria the OIG will then be able to submit their

proposed documentation to the GSG and GFRG for Gate 2. Developed technical CRs will be

circulated to the GSG to be included within the regular GSG specification cycle, with

deadlines and review cycles as defined by the GSG chairs for the next specification release.

Service Description CRs will be circulated to the GFRG, the CRs should highlight whether

they are considered to be a core service (to be supported by all) or to be included within the

general Service Description repository, and will follow the deadlines and review cycles as

defined by the GFRG chair for the next Common Core release.

5.8 OIG project closure

After an OIG is considered closed the GSMA will no longer facilitate meetings for an OIG or provide anti-trust and legal support. An OIG will formally close if it meets one of the following requirements:

The OIG has successfully progressed past Gate 2 for all intended phases identified

in their Gate 1 Document.



V0.2 of 15

If Gate 1 is not approved within the assigned timeframe the situation will be raised by

the GSMA PM to the IP Comms ET who can decide to close the OIG.

If Gate 1 document cannot be approved within the GSG/GFRG and the OIG then

goes against a ruling decision made by the IP Comms ET.

If there is no activity in an OIG for 2 months (excluding holiday periods) the situation

will be raised by the GSMA PM to the IP Comms ET who can decide to close the

OIG.

The OIG formally rules that the OIG should be closed.

An OIG can reopen if:

New operator interest that is willing to commit to its completion

New technological developments (new enablers developed that allow for the OIG

scope to be complete)

An OIG has re-scoped its remit, to resolve any conflicts, as per instruction by the IP

Comms ET

Upon closure the OIG chair and assigned GSMA project manager shall provide a closure report to GSG/GFRG and IP Comms ET stating:

Reason for closing

Lessons learnt

Any complete or incomplete outputs of the OIG

6 Roles and responsibilities

PSMC

Approval of OIG PRDs

IP Comms ET

Lead the programme Resolve escalations Provide strategic guidance

Approve process changes /

exceptions

Formally grant Candidate

Solution status

Ensure the programme is

resourced

Monitor OIGs progress Assure appropriate OIG

project governance

GSG/GFRG – Chairs

First Escalation point for

projects

Ensure Gate Management

process is upheld

Provide status updates to the IP

Comms ET

Provide guidance on external

stakeholder relations (e.g.

with OMA)

Escalates risks and issues to

IP Comms ET

GSG/GFRG – Group members

Review and approve Gate

documents

Review and approve

Candidate Solution status

submissions

Provide guidance to OIGs on

areas of concern



V0.2 of 15

GSG/GFRG – Group members

Represent their company’s

opinion

OIG Chair

Ensure meetings are effective

for all meeting attendees and

are driven towards decision

making

Ensure OIG group members

are fulfilling their roles and

that the OIG is representative

of all the views of the group

members to the greatest

extent practicable

Work with the Project manager to

regularly review programme

objectives, scope and Gate

timescales

Prioritise topics and scope of

the OIG for agile delivery,

including scoping second or

subsequent phases to cover

all use cases.

Conduct and follow up on IP

Comms ET and GSG/GFRG

decisions

Represent the OIG in

Stakeholder review meetings

and discussions by preparing the

relevant reports

Escalate risks and issues to

GSG/GFRG

Ensure the Gate documents

are correctly completed and

sufficiently reviewed by the

GSG and GFRG

Attend all OIG face-to-face

meetings and calls

OIG – Group member

Actively participates and

contributes to project tasks

Regularly attend face-to-face

meetings and calls

Prepare for each meeting as

required

Represent their company’s

opinion while understanding

the need for pragmatism and

compromise to preserve agile

processes and timely delivery

Ensure OIGs are

appropriately resourced Ensure their internal colleagues

are kept informed on the OIGs

progress

GSMA Project Manager

Responsible for assisting the

OIG Chair to deliver the

project to its scope,

timescales and reporting to

the IP Comms ET

Manage project

documentation

Facilitate and minute meetings

Manage change control

Highlight risks and issues to

OIG Chair

Create project closure report and

lessons learnt

Guide project leads and

assures project management

standards

Provide reporting to GSMA



V0.2 of 15

7 Stakeholder Reporting

7.1 Reporting to the GSG / GFRG

Each OIG reports to the GSG/GFRG at the stages defined in the stages of delivery (section

5), in addition an OIG will be expected to prepare an overview report at each GSG/GFRG

face-to-face meeting to show progress in line with the next RCS specification release. In

addition if an OIG requires guidance or escalations they can request time on a GSG/GFRG

conference call agenda and prepare a report highlighting where decisions are needed.

7.1.1 Examples of outputs that are reviewed or/and approved by the

GSG/GFRG

Gate documentation

Project Official Documentation:

Position statements

PRDs

Whitepapers

External project reporting related communication (e.g. Liaison statements).

7.2 Reporting to IP Comms ET

Each OIG reports to IP Comms ET at the stages defined in the stages of delivery (section 5).

If an OIG requires an escalation above the GSG/GFRG they can request time on the IP

Comms ET’s meeting agenda and the GSG/GFRG and OIG chairs need to prepare a report

highlighting where decisions are needed.

7.3 Reporting and liaison with external Network 2020 parties

External parties that have an impact on the OIG should be identifed within the Gate 1

document, the reporting structure and interactions should also be defined within the Gate 1

document and approved by the GSG/GFRG. (An example of this is providing requirements

to an external standards body (i.e. OMA) or a GSMA working group).

8 GSMA Infocentre2

The GSMA Infocentre2 is used to facilitate sharing and management of the following:

Documentation

Meeting documents and minutes

Action list

Approved Gate Management documents

Completed deliverables

Meeting information and registration

Communication through Infocentre2 mailing lists

OIG participants



V0.2 of 15

Document Management

Document History

Version Date Brief Description of Change Approval

Authority

Editor /

Company

0.1 04.09.15 New Document IP Comms ET GSMA

Other Information

Type Description

Document Owner IP Communications Execution Team

Editor / Company GSMA

It is our intention to provide a quality product for your use. If you find any errors or omissions,

please contact us with your comments.

Your comments or suggestions & questions are always welcome.