GSM Association

CONFIDENTIAL
Official Document BA.51

Roaming Service Level Agreement Guidelines between

Operators and between an operator and a Roaming Hub
Provider
Version 3.1
2 July 2010
This is a non-binding permanent reference document of the GSM Association.
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. 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 Associations antitrust compliance policy.

V3.1 Page 1 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

Table of Contents
Roaming Service Level Agreement Guidelines between Operators and
between an operator and a Roaming Hub Provider ......................................1
Version 3.1........................................................................................................1
2 July 2010........................................................................................................1
1 General .......................................................................................................3
2 Introduction ...............................................................................................3
3 QOS PARAMETER values .........................................................................4
4 Different Methods for Measuring QoS Parameters.................................5
5 Conditions and REcommendations for QOS Parameters ......................6
6 Cost of Testing ..........................................................................................7
7 Implementation and calibration................................................................7
8 exchange OF test results ..........................................................................8
9 Maximum time to restore service (mtrs) ..................................................9
9.1 General ...............................................................................................9
9.2 Troubleshooting remarks ....................................................................9
9.3 RSLA Parameter Investigations ..........................................................9
9.4 Response, Update and Restoration times ........................................10
10 Dispute resolution and escalation .........................................................10
11 Guidelines on the use of the RSLA ........................................................11
12 Guidelines for sourcing an OC-compliant GRQ monitoring Solution .11
Annex 1 SLA SPECIFICATION ......................................................................12
DOCUMENT MANAGEMENT .........................................................................13

V3.1 Page 2 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

1 GENERAL

This document provides guidelines to those Operators wishing to establish an end-to-end

Roaming Service Level Agreement (RSLA) either between themselves and/or through a
Roaming Hub Provider. It includes suggestions on how to set up a RSLA, as well as
information on Quality of Service (QoS) Parameters and procedures. Operators willing to
sign a RSLA are free to select the QoS Parameters and measuring methods they find most
appropriate for their business.

The basis for the RSLA is the signing of Annex C12 of AA.13 (if signed between Operators)
and/or the corresponding annex of the AA.73 (if signed between an Operator and a
Roaming Hub Provider). For bilateral relationships, this Annex C12 consists of a template
for the RSLA contract and an embedded excel sheet which can be used for the regular
exchange of the RSLA results between Operators (cf Annex).

2 INTRODUCTION

The purpose of a RSLA is to ensure the quality of the roaming wholesale services provided
by the roaming partners and/or the Operators and Roaming Hub Providers. In order to fulfil
the QoS Parameters and escalation processes in the RSLA, it is important to have a clear
understanding of how the international traffic is exchanged between roaming partners. The
international traffic can be handled in various ways e.g. direct interconnect, mobile carrier
products or least cost routing. The various ways of terminating international traffic has pros
and cons linked to fulfilling a RSLA and it is important to clearly understand the link between
the QoS Parameters and escalation processes and the various ways of terminating
international traffic before implementing a RSLA. This is also the case for signalling and
GRX traffic.

It is therefore strongly advised that operators using the RSLA will have corresponding
Service Level Agreements in place with the involved carriers / service providers either
directly or through the Roaming Hub Provider (if provided).

Standardized formats for such SLAs can be found in the PRDs IN.01 (voice), IN.05
(signalling) and IN.10 (GRX). It is also important to agree in your SLAs with your vendors
times for restoration and updates for minor, major and critical issues that are in line with
your Roaming SLAs.

Other assumptions / conditions for implementing and measuring the QoS Parameters are:

QoS Parameters must be measurable by either Party in a large enough sample. The
information can be gathered using test traffic (e.g. thanks to the use of automatic
test probes on the VPMN network) or using live traffic monitoring tools (e.g.
signalling monitoring, traffic reports or data from HPMN network and/or Roaming
Hub Provider)

It is assumed that the end user can handle his mobile and the service he wants to
use (the service is available and not barred, no interoperability problem between end
user equipment and the visited network, routing is defined correctly without errors,
the end user equipment is ready to answer the call)

V3.1 Page 3 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

It is assumed that the conditions enabling roaming are fulfilled i.e. the routing, the
GRX/international voice infrastructure are correctly configured and available

3 QOS PARAMETER VALUES

All these Parameters are listed in the excel attachment (cf Annex). Operators and Roaming
Hub Providers should mutually agree which of the suggested Parameters they want to use
in their RSLA. Below there is an overview of what Parameters are considered of high,
medium or low relevance. This is merely a guidance and not a recommendation! Moreover,
the Parameters which can be used when using a Roaming Hub Provider might be far less
than the ones which can be used on a bilateral relationship.

Most Parameters have 2 values that need to be agreed upon between the Parties to the
RSLA:
Trigger values = for Parameters measuring delays or throughputs, these is the
threshold value used to expressed the SLA values in %. Trigger values are also
negotiated between two Operators and/or the Operator and the Roaming Hub
Provider and contracted in the RSLA.

SLA values = negotiated target values between two Operators and/or the Operator
and the Roaming Hub Provider and contracted in the RSLA. These values are
always expressed in %. SLA values are committed values from the Operator or the
Roaming Hub Provider.

Example for the Parameter "Post Dialing Delay":

Trigger value = 10 s

SLA value = 90%

This means the Party commits to have at least 90% of the calls made by the roamers with a
Post Dialing Delay < 10s.

Below you will also find an overview for all RSLA and Trigger Values. These Values are
based upon the results of the 40 GRQ Trials between Operators (it is the average from all
trial measurements). They can be used by both the VPMN and HPMN, and by the Roaming
Hub Provider, to compare the network quality perceived by the HPMN or the Roaming Hub
Provider and that of the VPMN roaming partners (either through a bilateral relationship or
through a Roaming Hub Provider). Data trials have only been done on GPRS networks.
Some Parameters have not been measured at all in the trial for various reasons. As it was
decided to use RSLA values for all Parameters only after the trial period, quite a few of
these values are also missing in this overview. However it is fair to say that for these
Parameters a typical RSLA value would be 95%, and the Trigger value is the one to focus
on.

AverageTrigger AverageSLA
Ref# Parameter Relevance
valuesintrial valuesintrial

1 CSLUSR High N/A 95%

V3.1 Page 4 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

2 CSLUDelay Low 9s notmeasured

3 NERMO High N/A 96%
4 NERMT High N/A 98%
5 PDDMO Medium 10s notmeasured
6 PDDMT Medium 9s notmeasured
7 CSSRMO High N/A 94%
8 CSSRMT High N/A 93%
9 REL Low N/A 99%
10 OCN&RDN Low notmeasured notmeasured
11 CCR High N/A 97%
12 ALOC Low notmeasured notmeasured
13 CLI High N/A 99%
14 SpQ Medium 3 notmeasured
21 SAMO High N/A 94%
22 SAMT High N/A 97%
23 ADMO Medium 5s notmeasured
24 ADMT Medium 5s notmeasured
25 E2EDTMO Low 12s notmeasured
26 E2EDTMT Low 13s notmeasured
31 PSLUCR High N/A 97%
32 PSLUDelay Low 7s notmeasured
33 PDPCAct.CR High N/A 98%
34 PDPCAct.Time Medium 3s notmeasured
35 PDPCCutOffRatio Medium N/A 3%
36 PDPCAv.SessionTime Low notmeasured notmeasured
37 ThroughputGPRS High 29kbit/sec notmeasured
38 GoodputGPRS Medium 32kbit/sec notmeasured
39 RoundtripTimeGPRS Medium 1200msec notmeasured
40 PacketLossGPRS Medium N/A 2%

4 DIFFERENT METHODS FOR MEASURING QOS PARAMETERS

Broadly speaking there are two methods available: active and passive ones. Both have
further sub versions, for instance static and mobile active probes, and passive systems
using either C7 signalling or CAMEL.

There are pros and cons to all methods, so it is hard to give any recommendation. The
choice will be based upon what suits best to the budget and the objectives.

From a HPMN and/or a Roaming Hub Provider perspective there is one clear advantage of
using a C7 signalling based passive solution. That is the fact it will cover all your existing
roaming networks. Active systems will have limitations in the number of locations they can
offer, although that number is likely to grow rapidly. The number of locations is not only
related to the number of countries, but also geographic locations within a country. While the
ideal recommendation for the probe location would be to have at least one active probe per

V3.1 Page 5 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

MSC vendor area, this is subject to financial consideration that has to be evaluated in
collaboration with the active probes solution vendors.

On the other hand a great advantage of an active system is that they can be used to
reproduce any specific situation or problem. This is very useful for trouble shooting and to
avoid false alarms during testing due to bad coverage, subscription or credit problems (pre-
paid) and phones running out of battery. Also intrusive tests can only be done with active
systems, like Speech Quality and specific data applications. In networks where you have
little roaming traffic, the active probe can generate enough traffic to make sure you know the
service is working fine and the QoS level is good.

Ideally we would recommend operators to use both methods in conjunction. This would
give the best of both worlds. Apart from the fact you need to implement and maintain two
systems, the actual costs of measuring would not have to be higher than using just one
method. You can choose to use either method in a particular country/network without
having to do double measurements. It is also possible to change methods from time to time
depending on the situation.

5 CONDITIONS AND RECOMMENDATIONS FOR QOS

PARAMETERS

PRD IR.81 describes how to perform the measurements, under what conditions, how
frequently and when. We strongly recommend both parties to ahere to the rules in IR.81, in
order to limit the risk of obtaining differences between the measurement results.

The occurrence of active test traffic must be controlled time-wisely. The IR.81 indicates
recommended time periods to take samples. They are all noted in local time at the VPMN
location. There is a spread in time between peak and off-peak times in the local network.
They might not correspond with the peak times the HPMN customers make their calls (due
to time zone differences). By following the recommendations mentioned in the PRD IR.81,
the operator will obtain a balanced scorecard. It will provide the operator with a complete
overview of the QoS level in the VPMN.

In the case of passive systems the sampling can be 100%, but in case it is less, it is also
important to follow the guidelines of the PRD IR.81. This is especially to spread the
samples in time and keep them comparable with result from an active system.

One specific condition that needs to be taken into account is Steering of Roaming (SoR).
Traffic steering will influence the results of certain Parameters (see for more details PRD.
IR.81). In case you sign a RSLA and roaming is made on a non-preferred network, and you
are steering traffic away from this network, you need to be aware of the impact on the QoS
levels. SoR vendors usually provide blacklisting mechanism for avoiding the application of
SoR to specific IMSI (for active probes). For live traffic on passive probes it is possible to
share technical details to filter out the SoR effect.

V3.1 Page 6 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

6 COST OF TESTING
The cost of testing is in principle at the expense of the requesting Party but both Parties can
agree to do otherwise. By using passive probes (live traffic) there are no additional roaming
costs.

By establishing real connections with an active probe, the HPMN and/or the Roaming Hub
Provider will incur roaming charges on the test SIM cards that are being used. This is only
the case for a limited number of Parameters, but charges can be considerable, especially
for data tests. In case both Parties are testing the QoS with active probes, the costs will
more or less level out.

In case only one of the Parties is performing QoS tests with active probes, or the IOTs are
not in balance, the Parties can agree bilaterally on the settlement for the costs incurred.

The Annex C.12 has some text that can be used to that purpose for bilateral relationships.
For an Operator wishing to have RSLA with a Roaming Hub Provider, there is a need to
agree on the charging mechanism. In any case, the options are as follows :
- The costs of tests performed by the VPMN are part of the standard roaming
agreement and/or the AA.73 and will remain unchanged in the context of this
agreement, unless otherwise agreed. In this case, the threshold for test usage as
per the AA12 and/or the AA.73 will likely remain in place.
- However, it is possible to include these test SIM cards in the list of non-chargeable
SIM cards specifically exchanged for RSLA purposes (see Annex C.12 for bilateral
relationships). In this case, both Parties will agree that the Party bearing the charges
will issue a (yearly) credit note for the usage of the notified test SIM cards.

7 IMPLEMENTATION AND CALIBRATION

When implementing a new RSLA, it is recommended to make sure that the monitoring setup
is conforming to IR.81 and that the results are usable for troubleshooting. The advice is to
go through a calibration process for every new implementation or in case you add new
Parameters that have never been calibrated before. The ultimate decision to do calibration
is up to the VPMN and/or the Client Operator of the Roaming Hub Provider. In case the
VPMN and/or the Client Operator of the Roaming Hub Provider does not require calibration
it means the VPMN and/or the Client Operator of the Roaming Hub Provider will accept the
HPMN and/or the Roaming Hub Provider measurement results as undisputedly correct,
which is important for any follow-up action in the trouble shooting process.

In case both roaming partners and/or the Operator and the Roaming Hub Provider use the
same vendor, a calibration is not required. Also in the case both use the same monitoring
method, it is recommended to only have one calibration with each vendor. It is likely you
will go through quite a few calibrations tests initially with your first 10 RSLAs, but this will
reduce significantly afterwards. Roaming partners and/or Roaming Hub Providers using an
in-house solution are advised to do calibration with each roaming partner and/or Operator,
as they are in fact their own unique vendor.

Calibration is something that is mainly performed by the vendors. In case both roaming
partners and/or the Roaming Hub Provider and its Client Operator request a calibration, the
two vendors will perform a week of measurements on both sides and exchange and
compare the results between them. Based upon these results they will discuss and correct
any issues if needed.

V3.1 Page 7 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

If both are using different methods (active vs. passive) they will have to use this calibration
process to agree on the differences in the measurement results in order to reach a mutually
accepted level of comparability. This is required to take into account the specific customer
behaviour (e.g. voice-mail usage) and mix (e.g. pre-paid vs. post-paid) of the HPMN.

Based upon the trial results extra attention should be paid to Parameters 5, 6, 34, 36 and
37, as they have shown the most variation between the different vendors in the trials.

Once all parties are satisfied with the results and the additional agreements, the monthly
measurements can start.

8 EXCHANGE OF TEST RESULTS

There is no requirement in the RSLA or any of the relevant PRDs requiring either Party to
measure all of the QoS Parameters. First of all it should only be limited to those
Parameters that have been agreed upon in the RSLA. But even these agreed Parameters
do not require monthly measurements.

In certain cases both parties can agree that only one Party performs measurements, and
provides the report on a monthly basis. We recommend documenting that clearly in your
RSLA.

The HPMN and/or the Roaming Hub Provider can also decide to reduce monthly tests to
once per quarter, or even less, in case the QoS levels on a certain VPMN are always good.
This way, resources can be freed up to focus on more problematic networks.

It is important to note that in case any Party does not (completely) measure the QoS
Parameters, it will have to rely on reports from the other Party. In the case where the
reports on Parameters do not reach the agreed levels, the Party which has not (completely)
measured the QoS Parameters will be able to take immediate action to solve this issue.

The test results can be exchanged using the following five steps:

1. The report will be provided in the format as described in the RSLA.

2. The receiving Party will review the reports at the earliest possible date following the
end of the month. In case one or more Parameters have underscored, it will check
the results to make sure there are no problems with the monitoring system itself or
no specific issue has affected their system. See for more details chapter 9.3 of this
document.
3. The report will be sent to either Party using the template (or otherwise as agreed)
and in case of one or more Parameter having underscored the commitment, the
other Party can raise a Trouble Ticket (see for template PRD IR78) and send it as
described in the procedure in chapter 9.3 below (unless a different procedure has
been agreed between both parties).
4. In case of under-achievement of any of the QoS Parameters, the faulty Party will
respond as described in the MTRS procedure (see below). The commercial
contacts will follow the procedure as described in the escalation procedure.
5. Exchange of reporting shall start following the first full month after this agreement
has been signed by both Parties.

V3.1 Page 8 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

Should either Party experience a major outage, it is recommended to report this straight
away at least to the other Party. This will be beneficial for any trouble shooting, as well as
explain any possible underperformances in the QoS measurements.

9 MAXIMUM TIME TO RESTORE SERVICE (MTRS)

9.1 General
The procedure for troubleshooting is defined in PRD IR.78. For additional information on
using IR78 in an RSLA see 9.2 & 9.3 below.
Response, update & restoration times need to be agreed upon in the RSLA, see 9.4 for
additional guidance.

9.2 Troubleshooting remarks

This non-binding PRD IR78 can be made binding between the two Parties by signing the
RSLA. Any deviations from this PRD IR.78 need to be specified within the RSLA. The
resolution times will only count from the moment either Party has received all the
information that is necessary to resolve the issue. In case additional information that was
requested by this Party is not deemed necessary for the resolution, the initial report will
count as starting time for the problem resolution.
Operators need to ensure that they have RSLAs in place with all suppliers and carriers that
could impact on the quality of service they provide to inbound roamers.

9.3 RSLA Parameter Investigations

Either Party shall confirm it is fully compliant with GRQ Parameters as defined in IR81. They
should also confirm they have performed a preliminary analysis:
at network level to check data fill is correct and up to date, no service outages
notifications have been received etc.
verify there is no problem with their test systems, probes, SIMs etc.

The Party shall provide details of its measurements like MSISDN (calling and called
numbers), IMSI, probe location etc. Use the call record tab in the trouble report for these
details together with the exact days when the Parameter requires investigation.

It is suggested that the above exchange of information is conducted as soon as a

Parameter problem is detected, it will be difficult for the other Party to troubleshoot if the
Parameter has restored to normal or to investigate a problem that occurred in the past.
Sharing test results/ information on a regular basis between home and visited network
should assist in providing the high quality of roaming service all parties require.

Detecting Parameter problems for inbound and outbound roamers, it is strongly

recommended that operators continuously monitor their performance by use of alarms. This
will provide quick detection of problems on both sides and assist with quality of service and
resolution times.

V3.1 Page 9 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

9.4 Response, Update and Restoration times

Both Parties can agree on response times for acknowledgement, updates and resolution in
the SLA. Resolution times can be differentiated for SLA Parameter investigation, minor,
major and critical cases.
Both Parties can also agree on penalty clauses for any delays in resolution times. There is
no standard framework available for penalties.
For major and critical issues an email should be followed with a telephone call to ensure the
other Party is immediately aware of the problems.
Various factors will determine operator and Roaming Hub Providers response and
restoration times i.e. if they have a 24/7 technical roaming team, SLAs in place with
vendors and carriers etc.
In case the response, update or restoration times are not met, the IR.21 and/or the Roaming
Hub Agreement will have to provide an escalation point that should be used in these cases.
On top of that there is a commercial escalation procedure (see chapter 10).
For guidance below listed are typical times used by some of the larger operators, use
should also be made of the Exceptions column for areas that are not under your control.

initial e-mail Response 2 Hours

Restoration - Update -
Parameter Investigation: One or
more PARAMETER's below
threshold* 5 Days 2 Days
Priority Minor: One customer or
VIP affected* 4 Days 2 Days
Priority Major: A number of
customers affected* 12 Hours 6 Hours
Priority Critical: One of the
roaming services down* 4 Hours 2 Hours

10 DISPUTE RESOLUTION AND ESCALATION

The Parties agree to seek to resolve any dispute or problem arising out of the Agreement in
accordance with the following escalation procedures:

1. The nominated RSLA contact persons of each Party (as defined in the spreadsheet
in Annex) shall work in good faith to try to resolve the dispute within thirty days from
the date that one Party first gives notice that a dispute has occurred.

2. If the RSLA contact persons fail to reach an agreement on the dispute within thirty
days, the dispute shall be referred to the escalation RSLA contact persons within the
respective Parties organisations (also as defined in Annex spreadsheet) who shall
endeavour to resolve the dispute within a further thirty-day period.

V3.1 Page 10 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

11 GUIDELINES ON THE USE OF THE RSLA

In order to implement a RSLA between this can be done in the following steps:

1. Review the proposed word document and see what sections you need to remove or
fill out.
2. Add the excel sheets (cf Annex 1) as addenda to it. All the operator specific data is
to be populated in this sheet. Both Parties will fill in a spreadsheet, one for each
Party. Either Party will provide the QoS levels it can commit to, and all the contact
details. The Party making the measurements will fill in the frequency and method of
measuring.
3. In case one of the Parties requires a different format than an excel sheet for signing
the RSLA, the excel sheet can be exported into a word and/or PDF document.
4. The spreadsheet may also be used as a template for the monthly reporting of the
QoS levels either Party has measured. It is important to report the data in the exact
same fields as within the standard, so the results can easily be aggregated and
downloaded into other systems.
5. It is advised to follow the instructions on how to use the spreadsheet carefully and
avoid adding or deleting any rows or columns, as this will change the location of the
data and will make the automatic upload of data impossible.
6. It is recommended to only fill in the data in the field that is designed for that
particular data. These fields are marked in green. Fields that should not be
changed are marked in red.
7. It is recommended to only fill in QoS levels for the QoS Parameters that have been
committed to, leaving the other rows blank.

12 GUIDELINES FOR SOURCING AN OC-COMPLIANT GRQ

MONITORING SOLUTION
Operators that will be using the services of a quality monitoring product or service provider
as part of RSLA implementation are recommended to engage an OC-compliant GRQ
monitoring provider. An OC-compliant GRQ monitoring provider is one that supports the
following GRQ framework permanent reference documents (PRDs):

IR.42 Definition of Quality of Service parameters and their computation

IR.78 Roaming Trouble Report
IR.81 GRQ Measurement Implementation
BA.51 Roaming Service Level Agreement Guidelines

An OC-compliant GRQ monitoring product or service provider should also:

i. Offer a product or service that supports configuration of the following aspects of end-
to-end roaming QoS monitoring:
a. GRQ parameter set
b. RSLA values (trigger and SLA values)
c. Test procedures and conditions (e.g. test frequency).
d. Report production
ii. Include a well-defined level of roaming trouble-shooting and problem-solving support
as part of its standard service. Optional additional support should also be available
outside of the standard service contract.

V3.1 Page 11 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

iii. Offer a product or service that can provide (at a minimum) the following detailed
measurement data on individual GRQ parameters for the last 10 calendar days to
enable Client Operators to complete the IR.78 trouble shooting report:
a. Time and date of transaction
b. IMSI
c. MSISDN
d. Location of client device (e.g. IMSI)
e. SMSC address
f. APN address
g. Bearer
h. Dialled number
iv. Be capable of:
a. Providing copies of detailed measurement data going back 90 calendar days
from receipt of the Client Operator request.
b. Performing end-to-end roaming QoS testing prior to launch or activation of
roaming services.
c. Providing automated detection of shortfalls of end-to-end roaming QoS level
as agreed in a RSLA.
d. Adding new roaming SLAs to the GRQ product or service.
v. Protect the data security and confidentiality involved in roaming relationships
vi. Provide technical and operational guides to help Client Operators and their suppliers
with implementing the GRQ framework using its GRQ products or services.
vii. Provide well-defined written procedures for the management of SIM cards provided
by HPMN, VPMN, or their suppliers for the purpose of GRQ monitoring. (applies to
active monitoring solutions only)

Operators are recommended to consider including clauses specifying the desired features
above to their bilateral agreements with their GRQ monitoring product or service providers.

ANNEX 1 SLA SPECIFICATION

D:\DONNEES\
SCHEVRIER\GSMA - C

V3.1 Page 12 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

DOCUMENT MANAGEMENT
Document History

Approval Editor /
Version Date Brief Description of Change
Authority Company
0.1 June 7th First draft discussed at BARG #nn
2006 Taskforce meeting #7 EMC #nn
0.2 June 16th Version for discussion at
BARG #nn
2006 Taskforce meeting #8
0.2.1 21 June Review by GSMA/PMO for eVote
2006 style compliance EMC #nn
0.4 21 July Final draft sent to AGREE for
2006 review
0.5 17 Aug Final version sent to AGREE
2006 for approval
0.6 7 Sept Revised by Director R&B
2006 following comments gathered
at RING, AGREE & BARG
Sub-group Chairs Meetings
0.7 6 Feb Change to paragraph 4 as
2007 PRD IR42 has not been
updated yet.
0.8 1 March Removed annex 1, and turned
2007 this into article 10. This version
will be presented at BARG#69
in Brighton.
0.9 2 May Removed article 4.2, as this is
2007 now all documented in PRD
IR.42
0.10 28 Revised following comments
Septembe gathered at RING, AGREE and
r 2007 BARG. Awaiting BARG
Approval.
1.0 December BARG Approved by Email
BARG #71
2007 (BARG Doc 71_006Rev1)
20
CR 001 and 002 to BA.51 (BARG BARG #73 Jan Willem de
2.0 November Docs 72_032 and 72_057) EMC #69 Haan (KPN)
2008
Major CR 003 to BA.51
Addition of OC GRQ Selection BARG #75 &
29 April guidelines Jan Willem de
3.0 EMC #82
2010 BARG Doc 75_060Rev1 Haan (KPN)

Minor CR 004 to BA.51 Jan Willem

2 July
3.1 Addition of GRQ in Roaming AGREE #73 Dehaan
2010
Hubs (Agree doc 73_004) (KPN)

V3.1 Page 13 of 14
GSM Association
CONFIDENTIAL
Official Document BA.51

Other Information
Type Description
Document Owner BARG - AGREE
Editor / Company Jan Willem de Haan (KPN)

V3.1 Page 14 of 14