GSM Association Official Document BA.

51

CONFIDENTIAL

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 Confidential Confidential Confidential GSMA Full Members GSMA Associate Members GSMA Rapporteur Members GSMA Parent Company Members X X X 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 Official Document BA.51

CONFIDENTIAL

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 2 3 4 5 6 7 8 9 General .......................................................................................................3 Introduction ...............................................................................................3 QOS PARAMETER values .........................................................................4 Different Methods for Measuring QoS Parameters.................................5 Conditions and REcommendations for QOS Parameters ......................6 Cost of Testing ..........................................................................................7 Implementation and calibration................................................................7 exchange OF test results ..........................................................................8 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 Official Document BA.51

CONFIDENTIAL

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 Official Document BA.51

CONFIDENTIAL

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.

Ref# 1 V3.1

Parameter CSLUSR

Relevance High

AverageTrigger valuesintrial N/A

AverageSLA valuesintrial 95% Page 4 of 14

GSM Association Official Document BA.51

CONFIDENTIAL

2 3 4 5 6 7 8 9 10 11 12 13 14 21 22 23 24 25 26 31 32 33 34 35 36 37 38 39 40

CSLUDelay NERMO NERMT PDDMO PDDMT CSSRMO CSSRMT REL OCN&RDN CCR ALOC CLI SpQ SAMO SAMT ADMO ADMT E2EDTMO E2EDTMT PSLUCR PSLUDelay PDPCAct.CR PDPCAct.Time PDPCCutOffRatio PDPCAv.SessionTime ThroughputGPRS GoodputGPRS RoundtripTimeGPRS PacketLossGPRS

Low High High Medium Medium High High Low Low High Low High Medium High High Medium Medium Low Low High Low High Medium Medium Low High Medium Medium Medium

9s N/A N/A 10s 9s N/A N/A N/A notmeasured N/A notmeasured N/A 3 N/A N/A 5s 5s 12s 13s N/A 7s N/A 3s N/A notmeasured 29kbit/sec 32kbit/sec 1200msec N/A

notmeasured 96% 98% notmeasured notmeasured 94% 93% 99% notmeasured 97% notmeasured 99% notmeasured 94% 97% notmeasured notmeasured notmeasured notmeasured 97% notmeasured 98% notmeasured 3% notmeasured notmeasured notmeasured notmeasured 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 Official Document BA.51

CONFIDENTIAL

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 (prepaid) 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 Official Document BA.51

CONFIDENTIAL

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 Official Document BA.51

CONFIDENTIAL

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 Official Document BA.51

CONFIDENTIAL

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 Official Document BA.51

CONFIDENTIAL

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* Priority Minor: One customer or VIP affected* Priority Major: A number of customers affected* Priority Critical: One of the roaming services down*

5 Days 4 Days 12 Hours 4 Hours

2 Days 2 Days 6 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 Official Document BA.51

CONFIDENTIAL

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 IR.78 IR.81 BA.51 Definition of Quality of Service parameters and their computation Roaming Trouble Report GRQ Measurement Implementation 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 endto-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 Official Document BA.51

CONFIDENTIAL

iii.

iv.

v. vi. vii.

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 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. Protect the data security and confidentiality involved in roaming relationships Provide technical and operational guides to help Client Operators and their suppliers with implementing the GRQ framework using its GRQ products or services. 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 Official Document BA.51

CONFIDENTIAL

DOCUMENT MANAGEMENT
Document History Version 0.1 0.2 0.2.1 0.4 0.5 0.6 Date June 7th 2006 June 16th 2006 21 June 2006 21 July 2006 17 Aug 2006 7 Sept 2006 Brief Description of Change First draft discussed at Taskforce meeting #7 Version for discussion at Taskforce meeting #8 Review by GSMA/PMO for style compliance Final draft sent to AGREE for review Final version sent to AGREE for approval Revised by Director R&B following comments gathered at RING, AGREE & BARG Sub-group Chairs Meetings Change to paragraph 4 as PRD IR42 has not been updated yet. Removed annex 1, and turned this into article 10. This version will be presented at BARG#69 in Brighton. Removed article 4.2, as this is now all documented in PRD IR.42 Revised following comments gathered at RING, AGREE and BARG. Awaiting BARG Approval. BARG Approved by Email (BARG Doc 71_006Rev1)
CR 001 and 002 to BA.51 (BARG Docs 72_032 and 72_057)

Approval Authority
BARG #nn EMC #nn BARG #nn eVote EMC #nn

Editor / Company

0.7

6 Feb 2007 1 March 2007

0.8

0.9

2 May 2007 28 Septembe r 2007 December 2007 20 November 2008 29 April 2010

0.10

1.0

BARG #71 BARG #73 EMC #69 BARG #75 & EMC #82 Jan Willem de Haan (KPN)

2.0

3.0

Major CR 003 to BA.51 Addition of OC GRQ Selection guidelines

BARG Doc 75_060Rev1

Jan Willem de Haan (KPN) Jan Willem Dehaan (KPN)

3.1

2 July 2010

Minor CR 004 to BA.51 Addition of GRQ in Roaming Hubs (Agree doc 73_004)

AGREE #73

V3.1

Page 13 of 14

GSM Association Official Document BA.51

CONFIDENTIAL

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

V3.1

Page 14 of 14