Guidelines for end to end GRX Service Level Agreement ... - GSMA

GSM Association 

Official Document IN.10 

Guidelines for end to end GRX Service Level Agreement 

between Mobile Operation and Carriers 

This is a non-binding permanent reference document of the GSM Association. 

Security Classification: This document contains GSMA Confidential 

Information 

1.3 

30 June 2010 

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. 

The GSM Association (“Association”) makes no representation, warranty or undertaking (express or implied) with respect to and does 

not accept any responsibility for, and hereby disclaims liability for the accuracy or completeness or timeliness of the information 

contained in this document. The information contained in this document may be subject to change without prior notice. 

Security Classification – CONFIDENTIAL GSMA Material 

Confidential GSMA Full Members X 

Confidential GSMA Associate Members X 

Confidential GSMA Rapporteur Members X 

Confidential GSMA Parent Company Members X 

Copyright Notice 

Copyright © 2010 GSM Association 

Antitrust Notice 

The information contain herein is in full compliance with the GSM Association’s antitrust compliance policy. 

v1.3 Page 1 of 34



Table of Contents 

1 Purpose ............................................................................................................. 4 

2 Scope and Assumption ................................................................................... 5 

3 Service Definition ............................................................................................. 5 

4 Definitions ......................................................................................................... 6 

4.1 Acronyms ...................................................................................................... 6 

5.1 End to end requirements .............................................................................. 8 

5.1.1 MNO to MNO Connection ............................................................................. 9 

5.1.2 MNO to GRX Connection ............................................................................. 9 

5.1.3 MNO to MNO Requirements ........................................................................ 9 

5.1.4 GRX to GRX SLA ......................................................................................... 9 

5.1.5 MNO to GRX SLA ....................................................................................... 10 

5.1.6 MNO to MNO Requirements ...................................................................... 10 

5.1.7 GPRS end-to-end requirements ................................................................. 11 

5.1.8 GRX end-to-end requirements ................................................................... 11 

6 Technical Characteristics of the Connection .............................................. 12 

6.1 End to end Demarcation Points .................................................................. 12 

6.2 GRX end to end .......................................................................................... 13 

6.2.1 Scenario 1 – Local Loop provided by the Mobile Operator, or the Mobile Operator 

chooses to use IPSec Access across the Internet to access the GRX Provider .... 13 

6.2.2 Scenario 2- Local Loop provided by the GRX Provider .............................. 13 

6.2.3 Scenario 3 - Local Loop provided by the GRX Provider. Mobile Operator refuses 

access to the Border Gateway ............................................................................... 14 

6.2.4 Worst Case - Both MNOs not agreeing to measurement/Monitoring local Tail, the 

GRX End-to-End Demarcation = Stages 3+4+3..................................................... 14 

6.2.5 Best Case- Both GRXs Provide ‘managed’ CPE End to End = Stage 9 .. 15 

6.3 Definition of Measurement Points ............................................................... 16 

7 Service Quality Parameters – KPIs ............................................................... 16 

7.1 MTRS- Maximum Time to Restore the Service .......................................... 17 

7.1.1 General ....................................................................................................... 17 

7.1.2 Critical Errors .............................................................................................. 17 

7.1.3 Severe Errors ............................................................................................. 17 

7.1.4 Warning Errors ........................................................................................... 17 

7.2 Delay .......................................................................................................... 17 

7.3 Jitter (= Delay variation = Standard Deviation of Delay) ............................. 18 

7.4 Packet Loss ................................................................................................ 18 

7.5 GRX Access Availability ............................................................................. 18 

7.5.1 Definition ..................................................................................................... 18 

7.5.2 Measurement Method ................................................................................. 18 

7.5.3 Calculation Method ..................................................................................... 18 

7.6 DNS Lookup Time ...................................................................................... 19 

7.7 Service Availability ...................................................................................... 19 

7.7.1 Availability of the Service per Destination................................................... 20 

7.8 DNS Availability .......................................................................................... 21 

7.8.1 Definition ..................................................................................................... 21 



7.9 PDP Context Creation delivery success ratio ............................................. 22 

7.9.1 Definition ..................................................................................................... 22 



v1.3 Page 2 of 34



7.9.4 General rule: ............................................................................................... 22 

9.1 Qualifying Claims ........................................................................................ 24 

9.2 Service Credit Level ................................................................................... 24 

9.3 Service Credit Claim Procedure ................................................................. 24 

10 Controlled Accessibility Policy ..................................................................... 24 

10.1 Direct Accessibility ...................................................................................... 25 

10.2 Accessibility ................................................................................................ 25 

11 Customer Care ............................................................................................... 25 

12 Operation & Maintenance – Fault Management .......................................... 25 

12.1 Introduction ................................................................................................. 25 

12.2 Central Notification Addresses ................................................................... 25 

12.3 Fault Classification ..................................................................................... 26 

12.4 Fault Reporting Procedures ........................................................................ 26 

12.4.1 Fault Reporting by the Mobile Operator ..................................................... 26 

12.4.2 Fault reporting by the Carrier ...................................................................... 27 

13 Fault Resolution ............................................................................................. 27 

13.1 Escalation Procedure ................................................................................. 27 

13.2 Official Status Information .......................................................................... 28 

13.3 Fault Clearance Procedures ....................................................................... 28 

13.4 Duration of a Fault ...................................................................................... 28 

13.5 Fault Handling and Performance Reporting ............................................... 29 

13.5.1 General provisions ...................................................................................... 29 

13.5.2 Monthly Fault Report .................................................................................. 29 

13.5.3 Monthly Review Fault Report ..................................................................... 30 

13.5.4 Monthly Traffic Report ................................................................................ 30 

13.5.5 Monthly Quality of Service Report (= Monthly Performance Report = MPR)30 

14.1 Service Management .................................................................................. 31 

14.2 Traffic Management .................................................................................... 31 

14.3 Maintenance Operations Management ...................................................... 31 

14.3.1 Planned Outages ........................................................................................ 31 

14.3.2 Parameter change notification & contact points update ............................. 32 

14.3.3 Connection between Carrier`s system and the Mobile Operator`s system 32 

14.3.4 Communication ........................................................................................... 32 

15 SLA Review ..................................................................................................... 32 

16 ANNEX A - SERVICE CREDIT LEVEL ........................................................... 32 

17 ANNEX B – Monthly Report ........................................................................... 33 

18 ANNEX C – Priority 1, 2 & 3 Destinations .................................................... 33 

19 DOCUMENT MANAGEMENT ......................................................................... 33 

v1.3 Page 3 of 34



1 PURPOSE 

This document is intended to provide Mobile Operators and GRX Providers with the 

minimum requirements to be included in the implementation of bilateral Service Level 

Agreements (“SLA”) related to the GRX Service agreed by between Mobile Operators and 

GRX. 

In support of these quality principles such recommended GRX Service Level Agreement can 

be used alongside that of the Roaming SLA. 

According to these Guidelines, a GRX SLA may include the following areas: 

• Service Definition 

• Scope and Assumption 

• Definitions 

• Quality of Service 

• Qualifying faults 

• Service Credits 

• Service Credits claim procedures 

• Carrier and Mobile Operator commitment to end-to-end quality 

• Adding SLAs to the peering model. 

• Implementation of peering at a second peering point/Redundancy and performance 

improvement 

• Customer Care 

• Operation and Maintenance - Fault Management 

• Operation and Maintenance - Non Fault Management 

• SLA Review 

Additionally, this document explains the practical end-to-end QoS meaning in GRX offering 

and presents a guideline for GRX Providers on the major aspects of the GRX end-to-end 

QoS provisioning. GRX Providers and Mobile Operators can use this document as a 

reference or educational material on GRX QoS related question. 

v1.3 Page 4 of 34



2 SCOPE AND ASSUMPTION 

This document provides a detailed technical description of end-to-end Quality of Service 

(QoS), including related terms definition, initial requirements, provisioning and measurement 

methods, and SLA general aspects. This document covers GRX end-to-end QoS. 

To place an agreement for GRX service between GRX Provider and Mobile Operator the 

AA.80 (Agreement for IP packet exchange services including IPX transport SLA) can be 

used as a template for. It provides the agreement for IPX transport service including the 

transport SLA. GRX service refers to the same requirements as transport traffic class 

“background” QoS described at the AA.80. In addition the following KPIs should be included 

in the AA.80 at the KPI section: 

• DNS lookup time 

• PDP context creation delivery success ratio 

• DNS availability 

This document delineates general requirements for GRX Providers and GPRS/UMTS 

operators related to GRX end-to-end service provisioning. Options for Mobile Operators’ 

GRX Providers’ internal QoS mechanism implementations are also provided. Each GRX 

Provider and Mobile Operator is free to choose any internal QoS and transport technology 

as long as this meets the general requirements specified in this document. 

This document also assumes that the well-known QoS terminology is understood. The 

concept and definitions introduced in this document are relevant only to GRX end-to-end 

QoS. 

The following circumstances will be considered out of scope: 

• A fault in, or any other problem associated with, Customer-supplied power, any 

Customer Equipment, non-maintained structured cabling. 

• Service suspension in accordance with the terms of the SLA. 

• All delay, jitter and that kind of values, as well DSCP bit combinations (and traffic 

classes) may be referred and used as examples in this document, but are introduced 

and updated in IR.34 

3 SERVICE DEFINITION 

The requested service may be described by: 

"Providing Internet protocol connectivity between GSM networks supporting IP roaming and 

interworking possibilities” 

Classic roaming is defined between GSM networks, i.e. between two connected GSM 

networks, and several roaming relationships exist simultaneously. Similar we will define 

GPRS roaming to take place between two GSM networks supporting GPRS (not only 

between GPRS networks, if we also look forward to for example, UMTS) 

v1.3 Page 5 of 34



The Service Level Agreements (SLA) shall cover all aspects of IP connectivity. Especially 

technical data describing the performance of the connections between the MNO and each of 

its’ roaming partners must be fixed. 

4 DEFINITIONS 

This section should include the definition of terms related to the quality parameters as based 

on the definitions below: 

Agreement = The Service Agreement between the Carrier and the Mobile Operator for the 

provision of services. 

Direct Termination: When the traffic is routed from the originated network towards the 

destination network using only one Carrier single network 

GRX TRAFFIC: IP traffic carried over the GRX network 

Month = from the 1st day of the calendar month 0:00:00 a.m. to the last day of calendar 

month 11:59:59 p.m. 

MTRS = Maximum time to restore the service in case of network or service errors/faults: 

The severity of errors may depend upon the network elements/services involved in the 

malfunctioning. In clause 7.1 a more detailed definition can be found. 

Service Credit = the amount that the Mobile Operator or GRX Provider is eligible for when 

submitting a qualifying claim with regards to QoS commitments. 

SLA = quality Service Level Agreement 

4.1 Acronyms 

ATM Asynchronous Transfer Mode 

BG Border Gateway 

BGP Border Gateway Protocol 

CB-WFQ Class Based Weighted Fair Queuing 

CIX Commercial Internet exchange 

CoS Class of Service 

DiffServ Differentiated Services 

DNS Domain Name Network 

DP Demarcation Point 

DSCP Differentiated Services Code Point 

v1.3 Page 6 of 34



DoS Denial of Service 

GPRS General Packet Radio Service (often referred as mobile 2.5G) 

GRX GPRS Roaming eXchange 

GTP GPRS Tunneling Protocol 

ICN Intra-Connect Network 

MNO Mobile Network Operator 

MPLS Multi Protocol Label Switching 

MPR Monthly Performance Report 

MTTR Mean Time To Restore 

PE Provider Edge 

PHB Per Hop Behavior 

PLMN Public Land Mobile Network 

PX Provider eXchange 

QoS Quality of Service 

RED Random Early Detect 

RP Reference Point 

RSVP Resource reSerVation Protocol 

SLA Service Level Agreement 

SMTP Simple Mail Transfer Protocol 

TOS Type of Service 

UMTS Universal Mobile Telecommunications Network 

VLAN Virtual LAN (Local Access Network) 

VPN Virtual Private Network 

5 QUALITY OF SERVICE 

At a high level of abstraction, “Quality of Service” refers to a set of service requirements to 

be met by the network while transporting a connection or flow and the ability to deliver 

network services according to the parameters specified in a SLA. “Quality” is characterized 

v1.3 Page 7 of 34



by service availability, delay, jitter and packet loss ratio. At this level, QoS is a set of service 

quality commitments that GRX Providers and Mobile Operators will offer to their customers. 

The QoS parameters and requirements are discussed later in this document. 

QoS Parameters Service Availability, Jitter, Packet Loss and Roundtrip Delay are defined in 

clause 7, Service Quality commitments. 

THE VALUES FOR GRX END TO END QOS ARE BASED ON MEASUREMENT 8 OR 

3+4+5 but real end to end QoS needs to be monitored between Border Gateway routers of 

the Mobile Operators 

Measurement Owner Action Required 

1 End user to BG MNO A MNO SLA 

2 BG to GRX1 edge device MNO A MNO SLA 

3 GRX1 edge to peering point GRX1 GRX SLA 

4 Peering point port to peering point Peering Peering point SLA 

port 

point 

5 Peering point to GRX2 edge device GRX2 GRX SLA –note, this example includes II 

and CPE 

6 CPE to end user MNO B MNO SLA 

7 End user to end user MNO A and 

B 

MNO SLA 

8 GRX edge to GRX edge GRX1 and 2 Intra GRX SLA 

1 2 3 4 

5 

MNO MNO A 

Provider 

Edge 

PCU 

IP IP 

network 

Router 

GRX1 GRX2 GRX2 

Border Border 

Peering 

Gateway 

Exchange Exchange 

DM3 Serial port 

5.1 End to end requirements 


8 

Provider 

Edge 

Router 

Local Local 

tail 

v1.3 Page 8 of 34 

CPE 

6 

MNO MNO B 

IP IP 

network 

BG 

Server 

DM1 Ethernet port 

The objective of this document is to detail how the GRX Providers and mobile industry will 

achieve a full end to end SLA on the GRX to allow us to achieve overall latency and QoS 

targets to support classes of services e.g. conversational, in line with the QoS requirements 

specified in the IR34. 

The end-to-end path in a GPRS connection is a very long path made up of many 

components of a great diversity. Following drawing is only an illustration of what could be in 

the path:



PCU 

MNO A 

IP 

network 

Border 

Gateway 

GRX1 GRX2 

Peering 

Exchange 

Edge 

router 

Local 

tail 

v1.3 Page 9 of 34 

CPE 

MNO B 

IP 

network 

Quality requirements are often first stated from the user’s point of view, e.g. what is the 

maximum allowed latency between the 2 end terminals. In this document, unless otherwise 

specified, end-to-end will mean BG to BG 

It should be noted, that the GRX and the MNO have a collective role in ensuring this end-toend 

SLA commitment, and the objective of this document is to detail the responsibilities of all 

parties in this chain. 

A number of end-to-end GRX connectivity possibilities are possible and these need to be 

considered when considering the impact on the end-to-end SLA. 

5.1.1 MNO to MNO Connection 

Originating and terminating MNO connected to the same GRX; 

Originating and terminating MNO connected to different GRX’s (maximum of two hops 

required between GRX); 

5.1.2 MNO to GRX Connection 

Originating/terminating MNO connected GRX using Managed Connection (local loop and CE 

router provided by GRX Provider); 

Originating/terminating MNO connected to GRX using an Un-Managed Connection (local 

loop provided by MNO); 

Originating/terminating MNO connected to GRX using IPSec connection. 

5.1.3 MNO to MNO Requirements 

It is expected also that MNO’s shall define and agree minimum GRX connectivity 

requirements within their Roaming Agreements. 

5.1.4 GRX to GRX SLA 

Where the originating and terminating MNO use the same SLA, the GRX Provider will be 

responsible for the end-to-end SLA between the MNO’s, providing the MNO satisfies its 

obligations as specified in this SLA. 

Where the GRX customers are connected to different GRX Providers, each GRX shall take 

responsibility for the other GRX’s it is connected to. When the GRX SLA is defined and 

agreed, it is expected that the same SLA will then be agreed by all the GRX Providers, so 

we achieve a full back to back SLA with all GRX Providers, providing the MNO satisfy 

their obligations as specified in this SLA. 

BG 

Server



The GRX Provider that is connected to each MNO is then expected to take full responsibility 

for subsequent qualified faults or service failures that may occur on other GRX’s that take 

place between it and the destination MNO, providing the MNO satisfies its obligations as 

specified in this SLA. 

GRX Providers will also be expected to agree on the overall latency and QoS requirements 

to allow the overall end to end QoS to be achieved, in accordance with the latency, jitter and 

availability performance specified in the IR34. 

5.1.5 MNO to GRX SLA 

Where the originating and terminating MNO’s are connected to a GRX using a Managed 

Connection (i.e local loop and CE router provided by GRX Provider), then the GRX’s are 

expected to take full end to end responsibility for the traffic, in accordance with the GRX to 

GRX SLA requirements defined above; 

Where the originating/terminating MNO is connected to GRX using an un-managed 

connection (local loop provided by MNO), then the MNO who is connected using an unmanaged 

connection will be required to provide an SLA to the GRX Provider on the Local 

Loop connection, as follows when there is a quality degradation: 

• Availability - [Specify Target in line with final IR34] 

• Jitter - [Specify Target in line with final IR34] 

• Roundtrip delay - [Specify Target in line with final IR34] 

• Packet Loss - [Specify Target in line with final IR34] 

In the case of qualifying network faults affecting connectivity under the control of the GRX 

Provider, the GRX has to take responsibility of the management of the failure until the point 

of demarcation. 

5.1.6 MNO to MNO Requirements 

The Roaming agreements will be modified to contain minimum levels of commitment on the 

MNO, to ensure good customer experience whilst roaming. These minimum commitments 

shall include; 

MNO shall ensure that it has geographically redundant connections to one or more GRX 

Providers; 

MNO shall ensure that sufficient capacity is provided at all times to support data roaming 

volumes of roaming customer on their network. MNO shall ensure that no more than 80% 

average utilisation in peak hour of the GRX is achieved at any time; GRX’s (or alternatively 

the responsible of line) will arrange forecasts of Local Loop early enough to ensure the 

upgrades do not introduce delays. 

Capacity upgrades should be achieved with the MNO’s GRX Provider in no less than XX 

working days from the MNO being aware that the above capacity requirements are not being 

met whenever there is no need for change of connection type [To be agreed between 

parties] 

The MNO to MNO commitment in the SLA shall not reduce the GRX’s commitment to 

manage the end to end performance of the GRX. The GRX’s are expected to take 

v1.3 Page 10 of 34



responsibility for all faults that are brought to their attention by its customers, and to seek 

resolution of these faults in accordance with the GSMA SLA. 

5.1.7 GPRS end-to-end requirements 

The GPRS end-to-end QoS recommendations (BG-to-BG) are defined by GSMA IR.34 

document 

The SLA parameters in the GPRS roaming agreement may have different values; they are 

bilaterally agreed between GPRS operators. 

There are differentiated service requirements in 3G, so every requirement is specific to a 

Class of Service. 

5.1.8 GRX end-to-end requirements 

GRX end-toend requirements (GRX access point to GRX access point) are derived from 

the GPRS end- to- end requirements. But several factors influence significantly the extent to 

how much GRX end-to-end path reflects GPRS end-to-end path. 

In most cases, a local tail connects the MNO’s network to the GRX backbone. For a good 

understanding of the importance of the local tail, the issues that are linked to it will be 

worked out in some more detail. 

1) MNO connects with a local tail to the GRX edge 

router in the GRX POP 

MNO 

GPRS 

network 

Border 

Gateway 

Local 

tail 

Edge 

router 

GRX 

2) MNO connects to a GRX managed CPE at his 

promises, the CPE is connected with a local tail to the 

GRX edge router in the GRX POP 

MNO 

GPRS 

network 

Border CPE 

Gateway 

In both cases, there is a local tail between the GPRS network and the GRX backbone. 

The impact of the local tail on the end-to-end performance can hardly be overestimated: 

v1.3 Page 11 of 34 

Local 

tail 

Edge 

router 

• It is often the bottleneck in terms of bandwidth and as such the determining factor for 

the quality of the BG to BG path 

• It is often sized in the agreement between MNO and GRX. While the GRX backbone 

dimensioning is obviously, the GRX’s own decision, the local tail is decided by MNO 

and/or GRX. Obviously, if one party decides on the dimensioning, the other party can 

not be held responsible for quality issues due to insufficient dimensioning Moreover, 

GRX 1 is limited in his possibilities to offer guarantees on BG to BG quality levels to 

MNO A if MNO B decides to have a local tail with GRX 2 that is not sufficiently sized. 

• Another very important factor is the nature of the local tail. Often two options are 

encountered 

o Physical link. Being some kind of a dedicated L1 or L2 link (SDH, FR, …) 

o Tunnel through the internet 

GRX



While quality can be specified and guaranteed easily for a physical link, this is 

often different for a tunnel through Internet. 

As a rule of thumb, it is often said that no quality parameters, such as Delay or Packet loss, 

can be guaranteed on a link that has a continuous load of more than 60 to 70 % of the 

capacity. 

A local tail must be included in the quality parameters; this is a choice of the GRX and the 

MNO. 

If differentiated services are provided by any of the GRX Providers, than every cell in the 

above table is split into several cells (one cell per CoS). 

In order to provide the GRX end-to-end QoS compliant with these requirements both GRX 

Providers and Mobile Operators shall agree on QoS parameters definition and the end-toend 

QoS Measurements Method. A single SLA built upon the Back-to-Back SLA between 

GRX Providers must be signed between MNOS and GRX Providers for guarantee of the 

commitments on the GRX end-to-end QoS defined in this section. All these areas are 

covered in the respective sections in this document. 

6 TECHNICAL CHARACTERISTICS OF THE CONNECTION 

The technical data of the requested service are defined in this chapter. We stress exactness, 

i.e. we try to define the connection characteristics or link characteristics in such detail that no 

"open points" remain. We do this by stating a set of parameters, which - taken together - 

define the connectivity service from a technical point of view. 

All service parameter definitions are in terms of the Internet Protocol. That means that all 

service parameters are defined using IP packets or are related to IP packets or IP packet 

transfer. 

These parameters are: Delay, Jitter (=Delay variation), Packet Loss and Availability. 

Each parameter shall be described in a dedicated section. Before doing so, we introduce 

"Demarcation Points" which will be used to define context, i.e. locate points in the 

communication link, where measurements will be done. 

6.1 End to end Demarcation Points 

This document assumes that any two MNO networks are interconnected by at most two 

GRX networks, as specified in IR.34, meaning there is no transit GRX service. 

A very important concept is the “demarcation point”. 

The demarcation point of the GRX is the point where the responsibility of the GRX Provider 

stops. It could also be called responsibility boundary. 

The demarcation point is also the point up to where the initial responsibility of the GRX ends 

for SLA purposes. 

v1.3 Page 12 of 34



6.1.1 GRX end to end 

In the case of a GRX Provider supplying ‘managed’ CPE End to End shall be from DM1 to 

either DM2 or DM3 (dependant on whether the local loop in stage 2 below is provided by the 

GRX Provider. See scenario 1, 2, 3) 

1 2 3 4 

5 

MNO A 

Provider 

Edge 

PCU PCU 

IP 

network 

Router 


Border 

Peering Peering 

Gateway 

Exchange Exchange 



8 

Provider 

Edge 

Router 

Local Local 

tail tail 

CPE CPE 

v1.3 Page 13 of 34 

6 

MNO MNO BB 

IP 

network 

BG 


A. Scenario 1 – Local Loop provided by the Mobile Operator, or the Mobile Operator 

chooses to use IPSec Access across the Internet to access the GRX Provider 

The Demarcation Point for End-to-End purposes shall be DM2 

In this case, the Mobile Operator shall be responsible for all the KPIs of stage 2. 

1 2 

PCU 

MNO A 

IP IP 

network 

Border 

Gateway 


Provider 

Edge 

Router 

GRX1 


The GRX should provide access to its Edge Router to return measurements. 

B. Scenario 2- Local Loop provided by the GRX Provider



The Demarcation Point for End to End purposes shall be DM3 

1 2 

PCU 

MNO AA 

IP 

network 

Border 

Gateway 


Provider 

Edge 

Router 



Providing that the Mobile Operator shall agree to allow the GRX Provider to measure and 

monitor the Border Gateway.Scenario 3 - Local Loop provided by the GRX Provider. Mobile 

Operator refuses access to the Border Gateway 

The Demarcation Point for End-to-End purposes shall be DM2 

1 2 

PCU 

MNO AA 

IP 

network 

Border 

Gateway 


Provider 

Edge 

Router 

GRX1 


The GRX Provider will only be responsible for Availability of the Local Loop – KPIs such as 

RTD, Packet Loss & Jitter are not able to be measured on the Local Loop and so become 

the responsibility of the Mobile Operator. 

D. Worst Case - Both MNOs not agreeing to measurement/Monitoring local Tail, the 

GRX End-to-End Demarcation = Stages 3+4+3 

In the IPSec tunnel case, MNOs should seek to maintain QoS, keeping the same values and 

KPIs as for other GRX access technologies. 

If the local loop/Internet transit is procured by the MNO, the demarcation point must be the 

edge of the GRX network where the IPSec tunnels terminate, with GRX Providers 

guaranteeing KPIs that are within the direct control of the GRX Providers. 

v1.3 Page 14 of 34



If GRX Providers, provide the local loop/Internet transit then it is up to the MNO and GRX 

Provider to agree levels of QoS, which keep as close as possible to the levels of QoS as for 

other GRX access technologies. 

1 2 3 4 

3 

2 

6 

MNO MNO A 

Provider 

Edge 

PCU 

IP IP 

network 

Router 


Border 

Peering 

Gateway 

Exchange 

Provider 

Edge 

Router 

Local 

tail 

v1.3 Page 15 of 34 

MNO B 

DM3 Serial port DM2 Serial port 

DM2 Serial port DM3 Serial port 

E. Best Case- Both GRXs Provide ‘managed’ CPE End to End = Stage 9 

1 5 

4 

5 

6 

MNO A 

Provider 

Edge 

PCU 

IP 

network 

Router 


Border Border CPE 

Peering 

Gateway 

Exchange 


9 

Provider 

Edge 

Router 

Local 

tail tail CPE 

IP 

network 

BG 

Server 

MNO B 

IP 

network 

BG 

Server Server 

DM1 Ethernet port



6.1.2 Mobile Operator – end to end = DM4 to DM5 To be written into Roaming 

Agreements 

1 2 3 4 

5 

MNO A 

Provider 

Edge 

PCU 

IP 

network 

Router 


Border 

Peering 

Gateway 

Exchange 



8 

Provider 

Edge 

Router 

Local 

tail CPE 

v1.3 Page 16 of 34 

6 


MNO MNO B 

IP 

network network 

BG 

Server 

DM4 Mobile Device DM5 Mobile Data Service 

6.2 Definition of Measurement Points 

Zooming into the last picture reveals the equipment at the border of the networks, i.e. we will 

find Border Gateways (BGs) in the NMOs and edge routers (ERs) in the GRX. Demarcation 

points become Measurement points. 

7 SERVICE QUALITY PARAMETERS – KPIS 

According to these Guidelines, the Mobile Operator and the Carrier commit to achieve 

certain average values of the following Quality of Service indicators as defined below: 

• MTRS in case of 

o Critical errors: x hours 

o Severe errors: y hours 

o Warning errors: z hours 

• Delay 

• Jitter 

• Packet Loss 

• Service Availability 

• Network Availably 

It is recommended that the measurements of these indicators are based only on the monthly 

traffic sent by the Mobile Operator for each destination or termination network via the GRX 

Supplier, so the origin of the measurements is the Operator network. Besides the global 

measurement (on a monthly basis), detailed figures concerning only the peak hour traffic can 

be taken into account.



7.1 MTRS- Maximum Time to Restore the Service 

7.1.1 General 

Maximum Time to Restore the Service (MTRS) in case of (a) Critical Errors, (b) Severe 

Errors or (c) Warning Errors. MTRS is the time that passes between the moment a trouble 

ticket in IPX Provider's trouble ticketing system is opened and the moment when the 

problem, which is dealt with in such trouble ticket, is resolved. 

• Total loss of connectivity between Mobile operator and GRX Provider platform 

• GRX Service affecting outage in the interconnection equipment 

7.1.2 Critical Errors 

A complete breakdown/outage, critical performance degradation, functionality of a single 

Service causing service unavailability included but not limited to: 

• Failure of connectivity and/or Traffic between Carrier and a connected Third Party 

Carrier 

• Total loss of connectivity between Mobile Operator and Carrier platform 

• Service affecting outage in the interconnection equipment 

• Serious degradation of the quality as measured by the KPIs indicated within this SLA 

7.1.3 Severe Errors 

The functionality of the Service is affected to a large extent, major performance degradation 

or loss of important function occurs, legislation or security is critically affected. Degradation 

of the service, either of the performance or the quality, includes but it is not limited to: 

• Loss of diversity or duplicity of the routes, without isolation with the other network. 

• Degradation of the QoS to any Terminating Mobile Operator, being defined as when 

any measured value for KPI is below the target threshold as indicated in the SLA. 

7.1.4 Warning Errors 

A minimal limitation to the Service functionality. This Fault implies irregular network 

behaviour without operational constriction and without an impact on business, included but 

not limited to: 

• Real-time reporting portal access problem; 

• Asymmetric routing management issues 

• Failure affecting isolated or individual service numbers. 

7.2 Delay 

Roundtrip delay is the total time that it takes to transmit an IP packet from the SOURCE to 

the DESTINATION and receive the reply packet from the DESTINATION at the SOURCE 

(measured over a given period of time, in milliseconds). For more detailed definition about 

this KPI consult IR.34. 

v1.3 Page 17 of 34



7.3 Jitter (= Delay variation = Standard Deviation of Delay) 

Is the delay variation among the different packets sent from the SOURCE to the 

DESTINATION (measured over a given period of time, in milliseconds). For more detailed 

definition about this KPI consult IR.34. 

7.4 Packet Loss 

Packet loss is the ratio of dropped packets to all packets sent from the SOURCE to the 

DESTINATION in percents (Measured over a given period of time). Consult IR.34 for more 

detailed definition of the KPI. 

7.5 GRX Access Availability 

7.5.1 Definition 

GRX Access Availability is the percentage of time that the GRX Access from MNO CE to 

GRX Edge has been available for the MNO within the measurement period. The availability 

is calculated separately for each CE access connection. GRX Access Availability can also 

be known as Local Loop Availability. 

7.5.2 Measurement Method 

The information sources for GRX Access Availability are internal management system 

measurements, reporting and trouble ticket history. Management system measures the 

availability by retrieving status information from the CE router via SNMP polling 

mechanisms. 

7.5.3 Calculation Method 

The availability is calculated based on the measurement data with the following formula: 

Availability-% = E rror! 

The measurement period is one calendar month. 

The unavailability time is the time the GRX Access has been unavailable to the MNO within 

the measurement period. The unavailability time starts when GRX Provider has noticed the 

problem or the MNO reports it to the GRX Provider help desk. A trouble ticket is opened 

when unavailability time starts. The unavailability time ends when the GRX Access is 

available for the MNO again. 

Additionally, the following principles are used when counting the availability figures. 

Breaks not calculated into the unavailability time: 

• Scheduled or other Maintenance breaks agreed between the MNO and the GRX 

Provider during the measurement period. 

• Breaks caused by the MNO or 3rd party owned equipment not maintained by the 

GRX Provider or the MNO premises environment being out of specification (e.g. 

power outages). 

• Breaks due to security or MNO responsibility violation. 

• Force Majeure 

v1.3 Page 18 of 34



• Each fault is counted only once. 

7.6 DNS Lookup Time 

Time required for a DNS packet to travel from a source to the DNS server, be resolved and 

travel back to the original source measured in ms. 

Abstract Equation: 

[ ms] 

= Tarrival @ src Tdepart @ src 

DNS_Lookup_Time T 

− 

Definitions: 

DNS packet DNS resolution request 

DNS_Lookup_Time T For a real number T, the DNS_Lookup_Time means that 

Source sent the first bit of a DNS packet to the DNS server at 

wire-time Tdepart@src, the DNS server received that packet, 

resolved the request and then immediately sent a DNS packet 

back to Source, and that Source received the last bit of that 

packet at wire-time Tarrival@src. 

Tdepart@src Source sends the first bit if a DNS packet to the DNS server 

Tarrival@src Source receives the last bit of a DNS packet from the DNS 

server 

7.7 23BService Availability 

There is a possibility for the Mobile Operator to access the service offered by the Carrier. 

The availability percentage to access the service offered by the Carrier will be calculated as 

the average of the time when the service was available to be used by the MNO during each 

month as follows: 

Where: 

P = 

A − B − C 

∑ = i n 

i 

i= 1 A − Bi 

• A is the number of hours in the period. 

• B is the time without service due to programmed works 

• C is the time without service due to critical (severity 1) failures 

• P is the total availability percentage 

To access the data services a PDP context must be first established. We can divide this 

procedure in two main parts: APN resolution and GTP tunnel establishment between the 

SGSN and GGSN. 

i 

* 

100 

v1.3 Page 19 of 34



The following diagram shows the mentioned procedures taken place in the Gp interface: 

In order to know the IP address of the right GGSN at the HPLMN, the GPRS DNS in the 

Visited MNO must resolve the APN. Although the Visited GPRS DNS could have manually 

defined the Home GPRS DNS address, the habitual procedure is to get this information from 

the GRX Root DNS. 

Therefore, the Visited GPRS DNS queries the GRX Root DNS to get the IP address of the 

Home GPRS DNS (1.a). 

Once the Visited GPRS DNS has gotten that information, it queries the Home GPRS DNS to 

obtain the IP address of the GGSN (1.b). 

The SGSN establishes the GTP tunnel (PDP context establishment) against the Home 

GGSN. 

7.7.1 61BAvailability of the Service per Destination 

Possibility for Mobile Operator to access a particular destination included in the service 

offered by the Carrier. 

The availability percentage to access the service offered by the Carrier will be calculated as 

the average of the time when the service was available to be used by the MNO during each 

month as follows: 

Where: 

P = 

A − B − C i * 

100 

∑ = i n 

i 

∑ 

i= 1 A − Bi 

= i n 

i 

∑ 

i= 1 A − Bi 

= i n 

i 

i= 1 A − Bi 

• A is the number of hours in the period. 

• B is the time without service due to programmed works 

v1.3 Page 20 of 34



• C is the time without service due to critical (severity 1) failures 

• P is the total availability percentage 

7.8 24BDNS Availability 

7.8.1 62BDefinition 

DNS Availability is the percentage of time that the DNS service has been available for the 

Customer within the measurement period. 

7.8.2 63BMeasurement Method 

The information sources for service availability are internal management system 

measurements, reporting and trouble ticket history. 

7.8.3 64BCalculation Method 


DNS Availability= AError! 


The unavailability time is the time the service has been unavailable to the MNO within the 

measurement period. The unavailability time starts when the GRX Provider has noticed the 

problem or the MNO reports it to the GRX Provider help desk. A trouble ticket is opened 

when unavailability time starts. The unavailability time ends when the service is available for 

the MNO again. 

Additionally, the following principles are used when counting the availability figures. 




• Breaks caused by the MNO or 3 rd party owned equipment not maintained by the GRX 

Provider or the MNO premises environment being out of specification (e.g. power 

outages). 



• Each fault is counted only once. 

For measuring this KPI and to determine the DNS Availability, the DNS Lookup time 

previously defined can be used. 

Note that DNS Availability from both the GRX DNS and the MNO GPRS DNS must be 

checked. 

If we only measured GRX DNS Availability and APN resolution against the MNO GPRS DNS 

didn’t work, we would never notice that problem, as PDP Context Creation messages are 

only sent if APN resolution succeeds. 

v1.3 Page 21 of 34



7.9 25BPDP Context Creation delivery success ratio 

7.9.1 65BDefinition 

PDP Context Creation delivery success ratio is the percentage of successfully delivered 

Create_PDP_Context Request/Response messages to the destination/originating MNO from 

all the received by the GRX. 

7.9.2 66BMeasurement Method 

The information sources for service availability are internal management system 

measurements, reporting and trouble ticket history. 

7.9.3 67B 

Calculation Method 


Ratio = 

Where: 

100 ∗( 

B + C) 

A 

• A = Number of Create_PDP_Context Request messages received by the GRX from 

the originating MNO 

• B= Number of Create_PDP_Context Request messages with its associated 

Create_PDP_Context_Response message received at the originating MNO 

• C= Number of Create_PDP_Context Request messages successfully delivered to the 

destination MNO with no answer from the destination MNO received by the GRX 

This KPI is measured per destination MNO. It means Create_PDP_Context Request to all 

GPRS backbone IP ranges of the destination MNO are taken into account when measuring 

this KPI. 

Note that APN resolution is prior to GTP tunnel establishment, therefore, DNS availability 

failures make the GPRS session establishment procedure stops and no 

Create_PDP_Context Request messages are sent to the GRX. Due to that this, KPI only 

measures the routing capabilities inside the GRX. 

Sometimes, due to network problems in the destination MNO, even though 

Create_PDP_Context Requests messages are successfully delivered by the GRX to the 

destination MNO, there is no answer from the GGSN. The originating MNO (in charge of 

measuring this KPI) has to be able to differentiate between problems in the GRX and the far 

MNO. Troubleshooting between the originating MNO and the GRX/destination MNO and 

Trouble Ticket reports will be necessary to determine that. 

7.9.4 68BGeneral rule: 

All Create_PDP_Context Request messages with their associated Create_PDP_Context 

Response messages received at the originating MNO will be count as successfully routed by 

the GRX Provider, despite the PDP Context hasn´t been established successfully (due to 

user failures etc). 

v1.3 Page 22 of 34



For instance, a failed PDP Context creation attempt because a Create_PDP_Context 

Response message with cause “User authentication failure” was received at the originating 

MNO will be considered as successfully routed by the GRX. 

Thus, Create_PDP_Context Request messages successfully delivered by the GRX to the 

destination MNO and without response from that MNO to the GRX, will also be considered 

as successfully routed by the GRX. 

For Create_PDP_Context Request messages without their associated Create_PDP_Context 

Response messages at the originating MNO, a troubleshooting analysis will be carried out 

between the involved parties to check if it really was a problem in the GRX. 

It will be considered a problem in the GRX when: 

• The Create_PDP_Context Request message is not successfully delivered to the 

destination MNO 

• The Create_PDP_Context Request message sent to a 2 nd GRX Provider is not 

successfully delivered to the destination MNO 

• The Create_PDP_Context Response message received by the GRX from the 

destination MNO is not successfully delivered to the originating MNO 

• The Create_PDP_Context Response message received by the GRX from a 2 nd GRX 

Provider is not successfully delivered to the originating MNO 


Additionally, the following principles are used when counting the Create_PDP_Context 

messages. 




• Breaks caused by the MNO or 3 rd party owned equipment not maintained by the GRX 

Provider or the MNO premises environment being out of specification (e.g. power 

outages). 



8 QUALIFYING FAULTS 

When according to either parties own measurement, the average daily QoS indicators listed 

above achieved by either party fall below the values agreed between the GRX and the 

Mobile Operator, either party may raise a “qualifying fault”. 

Either party must request the other to handle and investigate all disturbances in Quality 

Performance and to commit to resolve xx% of qualifying faults within xx hrs where the fault 

lies in its own network and when the fault lies in a third Party network involved in the traffic 

conveyance/termination. 

When according to the Mobile Operator’s own measurement, the average weekly or monthly 

QoS level falls below the KPIS; the Mobile Operator is entitled to raise a “qualifying 

weekly/monthly fault”. 

v1.3 Page 23 of 34



The Mobile Operator may request the Carrier to handle and investigate all qualifying 

weekly/monthly faults, and to commit to resolve ______% of them within ___ hours when the 

fault lies in its own network. 

9 SERVICE CREDITS 

Should the MPR or other source of information agreed between the GRX Carrier and the 

Mobile Operator show that the actual level of performance achieved in the relevant period 

deviates from the commitments specified in this SLA (KPIs’ target values committed in 

Schedule A), the Client Operator reserves the right to: 

Request a Service Credit. The precise amount of Service Credits to be applied by the GRX 

Carrier to the Mobile Operator for the relevant period is to be agreed by the parties e.g. 

deduct x% from the total out payment due to the GRX Carrier for the month in question. The 

Service Credit will be applied through a credit note relating to the concerned month; 

and/or 

To cease its obligations under the Agreement, e.g. continue to route traffic to the GRX 

Carrier on the effected destination(s). 

9.1 26BQualifying Claims 

Either party may submit a claim for a service credit under the agreed circumstances: 

• A valid qualifying fault was raised; 

• The qualifying fault was not resolved in the committed time 

9.2 27BService Credit Level 

Operators can use Annex A to these Guidelines as reference. 

9.3 28BService Credit Claim Procedure 

In order to claim for a service credit, the mobile operator may provide the following details of 

the faults to the GRX Carrier Account Manager: 

• GRX’s fault reference 

• Mobile operator’s faults reference 

• Destination 

• Time of notification 

• Time of resolution 

• Severity of error 

• Amount of credit claimed 

10 5BCONTROLLED ACCESSIBILITY POLICY 

In order to avoid deterioration of the quality of service, the accessibility for each destination 

may be made transparent to the Mobile Operator. 

v1.3 Page 24 of 34



In any case, the direct termination of traffic on the Mobile Operator can be favored whenever 

it is technically possible. 

The Mobile Operator may request the GRX to provide the accessibility information 

associated to its offer, namely identifying the type of routing used. . In particular the 

minimum information that the GRX should provide consist on the type of accessibility used to 

reach other mobile networks, classifying the connection into two groups depending if the 

accessibility is made through: direct accessibility, accessibility through other GRX Supplier. 

10.1 29BDirect Accessibility 

Identified as direct accessibility destinations are those for which the GRX offers the Mobile 

Operator direct termination to MNO. 

10.2 30BAccessibility 

Identified as accessibility through other GRX Supplier destinations are those for which the 

GRX offers the Mobile Operator terminating traffic through other GRX Supplier, different 

from the fore-mentioned in the previous paragraph to MNO. 

11 6BCUSTOMER CARE 

Each party may encourage the other to provide a Help Desk to support the needs of the SLA 

and attend to either parties enquiries on a 24x7 basis. 

The Carrier should provide a web access monitoring tool where the Mobile Operator sees 

the traffic performance of the Carrier. 

This monitoring tool will only show the traffic originated in the Mobile Operator’s network. 

12 7BOPERATION & MAINTENANCE – FAULT MANAGEMENT 

12.1 31BIntroduction 

This section details the operational processes and measures to be put in place by the 

Carrier and the Mobile Operator to guarantee the proper functioning of the Service in line 

with the requirements. 

The terms used in the Service Level Agreement between the Carrier and the Mobile 

Operator have the same meaning in this Operations and Maintenance Section unless 

otherwise stated. 

12.2 32BCentral Notification Addresses 

Each Party must name a central entity (single point of contact) who shall fulfil the duties in 

the notification processes in case of faults affecting the Service. 

This contact must be available 24 hours a day at a single telephone contact number. 

They have to be competent in operational issues for directly connected switch interconnect 

(The Service). 

v1.3 Page 25 of 34



They have to have remote access to decentralised operational network elements as well as 

relevant access to tools, resources and knowledgebase to solve problems. 

24 x7 Reference Details Carrier Details Mobile Operator Details 

Contact Point 

Telephone Number 

Facsimile Number 

Email Address 

12.3 33BFault Classification 

The Carrier shall open a trouble ticket in the case of any fault on the Service reported by the 

Service Mobile Operator or as identified by the Carrier. The appropriate severity level shall 

be assigned to each trouble ticket. There are three levels of severity: 

• Critical Errors (see clause 7.1.2) 

• Severe Errors (see clause 7.1.3) 

• Warning Errors (see clause 7.1.4) 

Maximum restoration times and status update intervals: 

Severity 

Maximum restoration 

time 

Initial Feedback Update Interval 

Critical 4 hours 30 minutes 1 hour 

Severe 6 hours 30 min 4 Hours 

Warning 5 working days 30 minutes 2 working day 

12.4 34BFault Reporting Procedures 

12.4.1 69BFault Reporting by the Mobile Operator 

Suspected faults on the Service shall be reported to the Carrier’s contact in clause 12.2. 

Reporting of critical faults shall be also followed by a phone call to the same contact. 

Faults will be logged and each call will be time-stamped and allocated a unique call 

reference number in the Carrier trouble ticket system to be used for all progress updates. To 

allow further tracking of each fault reported the Mobile Operator will also state its internal 

reference number when reporting any fault. 

Whenever a fault is reported the below information has to be given: 

• Company name 

• Name, telephone number and email of the person reporting the fault 

• Mobile Operator’s contact name, telephone number and email, if different from the 

above 

• Mobile Operator’s Fault Trouble Ticket Number 

• Physical location of the fault if identified 

• Details of the fault 

• Any environmental conditions, such as a power failure, that may be causing the fault 

• Severity 

v1.3 Page 26 of 34



• Carrier traffic details should be included if available 

12.4.2 70BFault reporting by the Carrier 

The Carrier shall immediately inform the Mobile Operator's contact (see clause 12.2) by 

telephone and email of any critical fault, no matter in which part of the systems involved the 

fault occurs. 

12.5 35BFault Resolution 

The Carrier shall immediately start proper fault handling intervention actions and inform the 

Mobile Operator accordingly, in line with the agreed procedure. 

The time interval shall start from the moment when the TT (Trouble Ticket) is opened. 

Both Parties shall provide each other with the agreed progress. 

• The minimum information required in the update is: 

• Expected resolution date/time 

• Any information as to the cause of the fault 

• All actions undertaken to date 

• Any further information required 

• Results of end-to-end measurement if applicable 

If the Carrier cannot resolve a fault within the defined MTRS targets, the Carrier shall 

allocate extra resources, via an escalation procedure, to achieve its resolution. 

In all cases, if the fault is not resolved within the timeframe agreed from when a trouble ticket 

is opened and there is a degradation of the Service quality level the Mobile Operator 

reserves the right to re-route the traffic to another Carrier. 

12.6 36BEscalation Procedure 

Both Parties must name a single point of contact for escalation (i.e. Fault Reporting Points). 

The escalation procedure can be delayed at the discretion of the Fault Reporting Points for a 

mutually agreed period when the fault has been identified and is being addressed by 

engineering staff of the appropriate Party. 

Non service-affecting faults will not be escalated outside of working ours. 

The recipient of the trouble ticket may escalate a fault in advance of the times set out below 

if it requires further information to progress the fault and that information has not been 

provided within a reasonable timescale. 

If the Carrier cannot resolve a fault within the estimated time, then an escalation procedure 

will be initiated. 

Escalation procedure is applied to all fault cases related to the services referred to in this 

contract. Only these can be the subject of an escalation that deals with persons with higher 

decision-making power. 

v1.3 Page 27 of 34



If an escalation criterion listed is fulfilled, escalation can take place to the next higher level 

following expiration of the escalation period. The escalation period is the time that must pass 

before a change can take place from one level to the next. 

In some cases certain faults need not be escalated automatically. A case can occur where 

the investigation of a fault is in progress and any escalation out of hours would serve no 

practical purpose. Both parties are to use reasonable and mutually agreed judgment 

regarding the benefit of escalating a particular fault. 

All escalation between the Mobile Operator and the Carrier must be accomplished using the 

following steps: 

Escalation Level Carrier Mobile Operator 

Level I 

Level II 

Level III 

Severity 

Critical 

Severe 

Warning 

Maximum Escalation Time to Level 

II 

12.7 37BOfficial Status Information 

Maximum Escalation Time to Level III 

After the initial information, updates in accordance with clause 12.3 will apply. On any 

reasonable request by either Party, the Central Notification Addresses are able to give 

information on the status of the trouble/problem. 

12.8 38BFault Clearance Procedures 

Only the Central Notification Addresses can issue an official fault clearance (closure of 

trouble ticket for fault resolution). 

If one Party's Central Notification Address closes a trouble ticket for fault resolution and 

informs the other Party thereon and the other Party does not complain about the fault still 

being there, such fault will be classified as «cleared» and the «Response and Restoration 

Time Clock» are stopped. 

12.9 39BDuration of a Fault 

The duration of a fault is the elapsed time between the Failure Start Time and the Failure 

Clear Time. 

Failure Start Time (FST) 

Any failure is deemed to start from the precise time of day that the alarm condition first 

v1.3 Page 28 of 34



Failure Clear Time (FCT) 

A failure is deemed to have cleared at the precise time of day that Carrier notifies the Mobile 

Operator that Service has been restored to normal. 

12.10 40BFault Handling and Performance Reporting 

12.10.1 71BGeneral provisions 

This section details the reports that shall be supplied and measured by both Parties. The 

information to be supplied shall be agreed between the Parties at the Agreement’s signature. 

Parties agree that: 

• The report shall be provided no later than the 10th calendar day of the month 

following the month to which the report applies. 

• The Mobile Operator commits to validating the data provided by the GRX Provider 

not later than the 20th calendar day. 

• Reports and validations shall be emailed to the other Party's contact set out below: 

GRX Provider's contact details Mobile Operators contact details 

>>Fill in name, position, email>Fill in name, position, email



12.10.3 73BMonthly Review Fault Report 

Based on the fault report the GRX Provider shall supply a monthly review fault report 

including the following statistics for the past month and the past 6 months in total. 

• Reporting Party 

• Reporting Period (calendar month) 

• Faults by severity and terminating service provider 

• Number of open tickets at the end of the reporting period 

• Number of tickets opened during the reporting period 

• Number of tickets closed during the reporting period 

• Average resolution time based on the closed tickets during the reporting period 

• Number of opened trouble tickets 

12.10.4 74BMonthly Traffic Report 

GRX Provider will produce traffic statistics in order to show: 

• The total volume of traffic transmitted per quarter, per month 

• The maximum amount of traffic transmitted during the busiest hours, 

• The average according with size definition. 

The Traffic report shall be used for forecast and billing management by both, the GRX 

Provider and the Mobile Operator. 

The results shall be monthly reported in the traffic report. 

12.10.5 75BMonthly Quality of Service Report (= Monthly Performance Report = 

MPR) 

GRX Provider shall provide Monthly Performance Reports (MPR) and optionally Weekly 

Performance Reports (WPR) on the QoS for the traffic handled from the Mobile Operator. 

These reports should be available to check the level of performance of the Service provided. 

Such level of performance is measured through the KPIs as indicated in this SLA. 

The MPR must include hourly values for the KPIs defined. The values should be measured 

24 x 7. 

The GRX Provider has to supply a monthly performance report including the following 

statistics for the past month and the past 6 months in total. 

• Reporting Party 

• Reporting Period (Calendar Month, i.e. January 2006) 

• Number of open tickets at the end of the reporting period 

• Number of open tickets during the reporting period 

• Number of closed tickets during the reporting period 

• Average resolution time based on the closed tickets during the reporting period 

• Number of opened critical trouble tickets. 

v1.3 Page 30 of 34



13 OPERATION & MAINTENANCE - NON FAULT MANAGEMENT 

13.1 41BService Management 

Such Customer Care Service shall be provided on Non-Faults situations to include non-fault 

related operational problems, operation and maintenance routines and documentation, 

pricing and billing queries and technical information. 

This service shall be provided Monday – Friday, 9 a.m. – 5 p.m. (of Carrier local time) 

excluding public holidays. 

13.2 42BTraffic Management 

The Mobile Operator commits to providing traffic forecasts at mutually agreed intervals. The 

traffic forecasting provisions shall be used for dimensioning the transport capabilities of the 

Carrier network and the Carrier termination capabilities on the Terminating Mobile 

Operators. They shall not have any binding effect unless otherwise agreed between the 

Carrier and the Mobile Operator in writing. 

13.3 43BMaintenance Operations Management 

13.3.1 76BPlanned Outages 

Where an outage is planned by the MNO or the GRX Carrier, the party causing the outage 

are required to notify the other in advance with full details concerning that outage. A brief 

explanation of the operation shall be included and the impact or risk of impact, on the service 

shall be always specified. 

Unless agreed otherwise all planned works shall be made [insert day] through [insert day] (if 

working days) between 00:00 and 06:00 am local time. 

In all cases described above, each Party's network management organization will take 

action to reduce disruption of traffic flows to the minimum. 

Carrier shall inform the Mobile Operator of a special who will be available during the time the 

Carrier carries out work which may affect the Mobile Operator’s traffic. Upon the Mobile 

Operator’s request this contact will provide information on the status of the work being 

carried out. 

Both Parties reserve their right to refuse a scheduled event for a good reason. In such a 

case the Parties will postpone the work to a later date which need not fit into the time slot for 

planned works. 

Advice of proposed planned work shall be notified e.g. by e-mail. Within 1 working day after 

receipt the receiving Party shall acknowledge receipt of the advice (e.g. by a return e-mail). 

Only if the receiving Party fails to acknowledge the receipt, the originating Party shall call the 

contact number of the receiving Party and ask for a “GO” or “NO GO” decision. The 

originator shall not carry out the work as long as the receiving Party has not reacted to the 

notice at all (otherwise the work will be considered as an unplanned work/outage, i.e. an 

MTRS impacting fault). 

If a new release (e.g. Software) does not work properly for any reason, then Carrier will have 

a proven rollback process in order to revert the system back to it’s original working state. In 

such a case, the time to restore the proper functionality of the Service shall be taken into 

account when measuring the MTRS levels. 

v1.3 Page 31 of 34



The Parties shall make no changes to their systems and any outage is defined as critical 

during this freeze period: ___ (set out days and time zone, e.g. 24 December – 26 

December). 

The Carrier shall periodically conduct maintenance test to check: 

The proper functionality of the Mobile Operator’s connection to the Carrier’s platform; 

The Interworking between the Mobile Operator and its Terminating Mobile Operators 

The Parties will mutually agree, and document in the relevant Service Schedule, the 

appropriate maintenance tests to be performed including the allocation of any costs. 

13.3.2 77BParameter change notification & contact points update 

Parties shall agree at on ad hoc timing for notification of network and billing parameters’ 

change & contact points’ update. 

13.3.3 78BConnection between Carrier`s system and the Mobile Operator`s system 

The Carrier shall designate a single point of contact (e.g. account manager) for the Service 

to co-ordinate all technical and implementation operations with the Mobile Operator. 

13.3.4 79BCommunication 

The GRX Provider will undertake to communicate the following events within the timescales 

below: 

• Planned Outages (including product upgrades/updates): minimum XX days 

• Communication of Suspension of the GRX Service: maximum XX days. 

Parties agree that: 

• Emergency situations shall be expedited. 

• The contact persons for such communications will be those identified in clause 12.2 

unless otherwise agreed 

• Reduced periods of notice will only be accepted as an exception and mutually 

agreed. The number of reduced periods of notice will be closely monitored by each 

Party and subject to review at regular Service review meetings. 

14 8BSLA REVIEW 

The Mobile Operator is encouraged to agree with the Carrier a periodical review of QoS 

benchmark levels (referred to in Annex A, B and C to these Guidelines), in a timeframe 

agreed. 

The parties will undertake a review of QoS benchmark levels every x months. 

15 9BANNEX A - SERVICE CREDIT LEVEL 

[TO BE AGREED BETWEEN PARTIES] 

v1.3 Page 32 of 34



16 10BANNEX B – MONTHLY REPORT 


17 11BANNEX C – PRIORITY 1, 2 & 3 DESTINATIONS 


18 12BDOCUMENT MANAGEMENT 

Document History 

Version Date Brief Description of Change 

0.1 

0.2 

January 

2006 

March 

2006 

0.9 May 2006 

1.0 10 Nov 

2006 

1.1 

May 2007 

1.2 24 

December 

2008 

Guidelines for improvement of 

GRX Service Level Agreement to 

be approved as a Non-binding 

PRD by IWG 

Guidelines for end to end GRX 

Service Level Agreement to be 

approved as a Non-binding PRD 

by IWG and IREG 


Service Level Agreement 

Between Mobile Operation and 

Carriers 

New Non-Binding PRD covering 

the Agreement for IP Packet 

eXchange (IPX) Services, 

approved by IWG #5 

Addition of new GRX KPIs at the 


Service Level Agreement 

Between Mobile Operation and 

Carriers 

Update to Service Credits Section 

Section 4 and Section 9 

Approval 

Authority 

IWG #5 

IWG #6 

IWG #9 eVote 

December 2008 

v1.3 Page 33 of 34 

Editor / 

Company 

José Antonio 

Aranda 

Legazpe, 

Vodafone 

España – IWG 

– QoSI Chair 


Aranda 

Legazpe, 

Vodafone 

España – GRX 

SLA ADHOC 

Chair 


Aranda 

Legazpe, 

Vodafone 

España – GRX 

SLA ADHOC 

Chair 

Ulrike Rössger, 

Telekom 

Austria AG 


Telekom 

Austria AG



Version Date Brief Description of Change 

1.3 30 June 

2010 

Other Information 

Update Fault severity, insert 

references to Roaming SLA, 

editorial updates for mCR003 to 

IN.10 (IWG Doc 12_026) 

Type Description 

Document Owner IWG - IMQ 


Editor / Company 

Telekom Austria AG 

Approval 

Authority 

IWG#12 

v1.3 Page 34 of 34 

Editor / 

Company 

Ulrike Rössger 

Mobilkom 

Austria

Guidelines for end to end GRX Service Level Agreement ... - GSMA

Create successful ePaper yourself

Delete template?

Save as template?