Packet Voice Interconnection Service Schedule To AA.80 25 January 2013

GSM Association
Non-confidential
Official Document AA.81 - PACKET VOICE INTERCONNECTION SERVICE SCHEDULE to AA.80
PACKET VOICE INTERCONNECTION SERVICE SCHEDULE

to AA.80
Version 3.1
25 January 2013
This is a Non-binding Permanent Reference Document of the GSMA
Security Classification: Non-confidential
Access to and distribution of this document is restricted to the persons permitted by the security classification. 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 permitted
under the security classification without the prior written approval of the Association.
Copyright Notice
Copyright 2013 GSM Association
Disclaimer
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.
Antitrust Notice
The information contain herein is in full compliance with the GSM Associations antitrust compliance policy.
V3.1
Page 1 of 42
GSM Association
Non-confidential
Table of Contents
1
2
3
Preamble
1.1 General Introduction
1.2 Structure
Commencement of Initial Services
Regulatory requirements
6
6
6
6
6
4
5
6
Termination of Service
Penalties
Opt in-Opt Out Process
6
6
7
Election Process
Signatures
Annex 1: Billing
9 Service Provider Termination Charges

10 IPX Transit Charges
11 Participating service Providers termination rates
8
8
8
12 Data Exchange and Invoice Procedure

12.1 Invoice Period
12.2 Minimum content of the invoice
Annex 2: Technical
8
8
8
9
13 Participating Service Parameter Change Notification

14 Participating Service Providers Parameters
9
9
15 Service Providers Parameters
16 Monthly Report
17 Service features for PVI
Annex 3: Service Level Agreement (SLA) for Packet Voice Interworking
9
10
12
18 Purpose
19 Scope and Assumptions
20 Packet Voice Service Definition
12
12
13
21 IPX End to End responsibility

22 Key Performance Indicators (KPIs)
22.1 Maximum Time to Restore the Packet Voice Service MTRS
22.1.1 Critical Errors
22.1.2 Severe Errors
22.1.3 Warning Errors
22.2 Packet Voice Service availability
22.2.1 Packet Voice Service System Availability
22.2.2 Packet Voice Transit Service Availability
22.2.3 Packet Voice Transit Service Availability per Destination
22.3 Packet Voice Service Provisioning Timeframes
22.4 Answer Seizure Ratio (ASR)
22.4.1 Abstract definition
22.4.2 Abstract equation:
13
14
15
15
15
15
16
16
16
17
17
18
18
18
V3.0
GSM Association
Non-confidential
22.5 Answer Bid Ratio

22.5.2 Abstract equation
22.6 Network Efficiency Ratio (NER)
22.7 Post Gateway Access Delay (PGAD)
22.7.1 Abstract definition:
22.8 Average Length of Call (ALOC)
22.9 CLI Transmission
22.10 KPIs quantifying the media plane of Packet Voice Service
22.10.1 Definition
22.10.2 Media plane KPIs when more than one IPXP are involved
22.10.3 Measurement methods
22.10.4 Statistical parameters
23 Targets for KPI
23.4 Answer Seizure Ratio
23.6 Network Efficiency Ratio
23.7 Post Gateway Access Delay
23.8 Average Length of Call
23.10 Delay
23.11 Packet Loss
23.12 Jitter
23.13 MOSCQE
24 QUALIFYING FAULTS
25 PACKET VOICE SERVICE CREDITS
18
18
19
19
20
20
20
20
21
21
22
22
22
23
23
23
24
25
25
27
27
27
27
27
27
27
27
28
28
28
28
28
28
28
28
25.1 Qualifying Claims

25.2 Packet Voice Service Credit Level
25.3 Packet Voice Service Credits Claim Procedure
26 CONTROLLED CONNECTIVITY POLICY
28
28
28
29
26.1 Direct connectivity

26.2 Indirect connectivity
26.3 Gateway connectivity
27 CUSTOMER CARE and MONITORING
28 OPERATION & MAINTENANCE FAULT MANAGEMENT
29
29
30
30
30
V3.0
GSM Association
Non-confidential
28.1 Introduction
28.2 Central Notification Addresses
28.3 Fault Classification:
28.4 Fault Reporting procedures:
28.4.1 Fault Reporting by Packet Voice Service Provider
28.4.2 Fault Reporting by IPX Provider
28.5 Fault Resolution:
28.6 Escalation procedure
28.7 Official Status Information
28.8 Fault Clearance Procedures
28.9 Duration of a fault
28.10 Communications
28.11 Planned Outages, Product Updates/Upgrades
28.12 Fault Handling Performance Reporting
28.12.1 General provisions
28.12.2 Monthly Fault Report
28.12.3 Monthly Review Fault Report
28.12.4 Monthly Traffic Report
28.12.5 Monthly Quality of Service Report (= Monthly Performance Report =
MPR)
29 OPERATION & MAINTENANCE NON-FAULT MANAGEMENT
29.1
29.2
29.3
29.4
29.5
29.6
30
30
31
31
31
32
32
33
34
34
34
34
34
35
35
36
36
36
37
37
Packet Voice Service Management

Traffic Management
Participating Service Provider Management
Maintenance Operations management
Parameter Change Notification & contact points update
Connection between IPX Provider System and the PVI Service Providers
System
29.7 SLA Review
Annex A
Schedule A Packet Voice Service Credit Level
37
37
37
38
38
Document Management
Document History
Other Information
41
41
42
V3.0
38
39
40
GSM Association
Non-confidential
AA.81 Packet Voice Interconnection Service Schedule to AA.80
Entered by and between
IPX_Provider_full_name
[IPX_Provider_full_address]
Registered in the [____] register sub file # [____]
VAT# [____],
Hereinafter IPX PROVIDER or ____ or PARTY
And
Service_Provider_full_name
[Service_Provider_full_address]
Registered in the [____] register sub file # [____]
VAT# [____],
Hereinafter SERVICE PROVIDER or ____ or PARTY
V3.0
GSM Association
Non-confidential
1 Preamble
1.1
General Introduction
The PARTIES have executed an agreement on IP Packet eXchange (IPX) Services.

The Parties now wish to extend the aforementioned agreement for Packet Voice services
provided over an IPX Service Hub by this Packet Voice Interconnection Service (PVI)
Schedule. Unless provided otherwise the provisions (and therefore also the definitions) of
the aforementioned agreement apply to this Service Schedule. For a short description of the
Service in this service see clause 20 of Annex 3.
1.2
Structure
This Service Schedule consist a few general provisions which are complemented by 3
Annexes:
Error! Reference source not found.
Annex 2: Technical
Annex 3: Service Level Agreement (SLA) for Packet Voice Interworking
2 Commencement of Initial Services

The Service set out herein shall be provided no sooner than on this Services
Commencement Date:
[State date agreed between parties with the following format
MM/DD/YYYY]
In relation to the initial commencement of the Service and without prejudice to the other
obligations of the Parties set out in this Service Schedule:
The Service Provider shall inform the IPX Provider about the commencement of the service
interoperability in due time.
All billing and charging mechanisms shall start from the Commencement Date.
3 Regulatory requirements
Emergency calls: [agreed requirements specific to this service schedule]
DRM (Digital Rights Management): [agreed requirements specific to this service schedule]
4 Termination of Service
A PARTY may terminate this Service at the end of a calendar month by giving no less than
ninety (90) days prior notice.
5 Penalties
For all penalties regarding payment, licensing and suspending the service beyond cases
indicated in the Main Body of this Schedule shall remain within the scope of the IPX
Governance document XX [currently being defined by IPIAG].
V3.0
GSM Association
Non-confidential
Opt in-Opt Out Process
Opt in-Opt Out Process does not apply for PVI.
7 Election Process
For PVI this is not applicable.
8 Signatures
IN WITNESS WHEREOF the Parties have caused this Agreement to be executed by their
duly authorised representatives on the date(s) shown below.
Signed on this _________________ in [City]
The IPX PROVIDER: IPX_Provider_full_name
___ (name + function)
Signed on this _________________ in _________________ (place)
TheError! Reference source not found.: Service_Provider_full_name
V3.0
GSM Association
Non-confidential
Annex 1: Billing
9 Service Provider Termination Charges
The Service Provider termination charges are based on call duration.
The Service Provider will charge the IPX Provider amount/currencyper minute/second
10 IPX Transit Charges

The IPX Provider will charge the Service Provider amount/currency .
11 Participating service Providers termination rates

The IPX Provider should provide the Service Provider, on a monthly basis, with the
termination charges of all participating Service Providers.
12 Data Exchange and Invoice Procedure

12.1 Invoice Period
The invoice period is a one-month period (n), which lasts from 00.00.00AM of the 1st day of
the calendar month (n) to the 11.59.59PM of the last day of the calendar month (n) (local
dates/times).
12.2 Minimum content of the invoice

The minimum content of an invoice issued either by the IPX Provider or the Service
Provider has to be the following:
General details:
name of the receiving operator
name of the sending operator
invoicing date and number
invoicing due date
the bank details
Specific details for each elected participating service provider destination:
name and country of the elected service provider
number of minutes per destination
applied elected service providers termination fee per minute
transit fee
total invoice amount
Separation of termination and transit fees may be omitted, if an IPX Provider or Participating
Service Provider is not allowed by regulatory bodies, applicable law, and contractual
agreements between Participating Service Provider and IPX Provider to disclose
termination rates. These limitations if any must be provided in writing by the IPX Provider to
the Service Provider.
V3.0
GSM Association
Non-confidential
Annex 2: Technical
13 Participating Service Parameter Change Notification
IPX Provider to Service Provider: The Service Provider will be notified once monthly of any
parameter changes for existing and new participating service providers and (in the case of
new participating service providers) also the wished dates for the openings. The Service
Provider will be notified at the time of how many days the Service Provider has to respond
to the change request.
Service Provider to IPX Provider: The Service Provider will need to notify the IPX Provider
as soon as possible of any parameter changes which will impact either the IPX Provider or
the Participating Service Providers.
Emergency notifications should be carried out in accordance with the terms of the Service
Level Agreement.
14 Participating Service Providers Parameters

TBD based on the outcomes of the trial.
15 Service Providers Parameters

TBD based on the outcomes of the trial.
16 Monthly Report
The IPXP shall send a forecast five (5) Working Days before the start of the month to the
Service Provider upon each price chance and/or notification period agreed between IPXP
and SP, which shall include all the Participating Service Providers information described on
the tables below (lines filled in grey provided as an example only).
The IPXP and SP shall agree the granularity of destinations and the tool how to exchange
this information.
Destination
Country
Operator
Country A
Country A
Country B
Global
Operator A
Operator B
Operator C
OTT
V3.0
Directly
connected
Direct
Connectivity to the
Participating
PVI
SP? (Y/N)
No
No
Yes
No
Indirectly
connected
Indirect
Connectivity
via 3rd IPXP
to the Participating PVI
SP (Y/N)
No
Yes
No
No
Gateway
Connectivity
TDM or IP
break-in/out
to the Participating PVI
SP (Y/N)
Yes
No
No
Yes
Charges
Blended
Rate per
minute
Transit
Rate
per
minute
Termination Rate
per
minute
GSM Association
Non-confidential
17 Service features for PVI

The following key Service Features are deemed to be mandatory for the operation of the
Packet Voice Interconnect Service over the IPX:
Mobile Network
Fixed Network
(c) 3GPP SIP-I protocol
specification (for
TrFO/OoBTC) with
International ISUP
encapsulation (ITU-T
Q.761-4 enc. As RFC
3204).
(d) ITU-T Recommendation
Q.1912.5 (for no OoBTC)
with international ISUP
encapsulation (ITU-T
Q.761-4 enc. As RFC
3204).
Protocol Specification
(a) 3GPP SIP-I protocol

specification
(for
TrFO/OoBTC)
with
International
ISUP
encapsulation
(ITU-T
Q.761-4 enc. As RFC
3204).
(b) 3GPP IMS-SIP protocol
specification (TS 24.229)
as required at the Ici
reference point (TS
29.165) (refer IR.65 for
details).
Codecs Voice
G.711, EFR,
AMR-WB
Codecs Video
3G-324M
Codecs Fax
T.38, G.711 (transport in T.38, G.711 (transport in

RTP per RFC 3551)
RTP per RFC 3551)
Codecs analogue data
G.711 (transport in RTP per G.711 (transport in RTP per

RFC 3551)
RFC 3551)
Codecs Text telephony
T.140
T.140
DTMF Support
In band G.711, RFC4733
In band G.711, RFC4733
Packetisation rate
5ms, 20ms
10ms (others?)
Transport media plane
RTP
RTP
Transport control plane
TCP, SCTP
TCP, SCTP
Supplementary Services
CLIP
CLIP
CLIR
CLIR
CFB
CFB
CFNR
CFNR
CFU
CFU
CW
CW
CUG
CUG
CH
CH
CF
CF
V3.0
FR,
AMR, G.711, G.729 (inc D and E),

G.723,
H.261, H.263, H.264, mpv4es
GSM Association
Non-confidential
Multiparty
Multiparty
ECT
ECT
Prioritised (Mandatory)
Later Phase
Protocol Specification
ITU-T Q.1912.5 Profile C; 3GPP SIP-I;

International
ISUP
International
ISUP
encapsulation and 3GPP
encapsulation
SIP-I;
3GPP IMS-SIP protocol
International
ISUP
specification (TS 24.229) as
encapsulation
required at the Ici reference
point (TS 29.165) (refer
IR.65 for details).
Codec
G.711
Call establishment
A and B party establishment.
AMR 12.2 (TrFO)
Ring tone generation

Abnormal conditions, clean
handling of calling busy
subscriber, clearing before
completion, etc
Call clearing
Normal cases A and B.

Abnormal cases confirm
clean
handling
with
appropriate user indications
Supplementary Services
CLIP; CLIR
UUS; Call Complete to Busy

Subscriber; Multiparty;
Multicall; Call Waiting; Call
Hold; CFU; CFB; CFNRy;
CFNRc;
COLP;
COLR;
Closed User Group.
Charging
CDR
Generation
to
determine duration of open
media channel. Collection of
expected event labels and
cause codes
Packetisation Period?
20ms for G.711
5ms for G.711
DTMF
In-band transport (G.711).
Method FFS
Echo Cancellation
None.
FFS, to be discussed with

FNOs.
IPX Protocol Interworking
None
ISUP FFS?
Other:
V3.0
Video
Telephony
(3G324M/UDI 64); Fax/Modem
GSM Association
Non-confidential
Annex 3: Service Level Agreement (SLA) for Packet Voice

Interworking
18 Purpose
The architecture of the IPX domain is clearly split in two layers: Service and Transport. The
Service layer is in charge of Service Hub and Service Transit capabilities, and the Transport
layer is in charge of maintaining along the whole path the technical characteristics of the
communication depending on the Traffic Class of Service used.
The PVI Service and the Transport layer of the IPX domain have different Quality of Service
metrics measured between different end points.
The IPXP is responsible to operate the underlying transport service (carrying the PVI
service) and to ensure Transport Quality within the boundaries (demarcation points as
defined in AA.80) of the IPX network. Transport Quality is defined in AA.80; sample KPIs
being delay, jitter, and packet loss.
The IPXP is responsible to operate the PVI Service Hub / PVI Service Transit from the PVI
Service Provider to the Participating Service Provider. Quality of PVI Service Hub / PVI
Service Transit is typically measured on signalling information from the IPX Providers first
switching proxy up to and including the Participating Service Providers network; sample
KPIs being NER, ASR, ABR, ALOC, and PGAD.
According to these principles, this Annex includes the following areas:
Packet Voice Service Definitions

Definition of Terms
Packet Voice Service Quality commitments
Qualifying faults
Packet Voice Service credits
Packet Voice Service Credits claim procedures
IPX Provider and Packet Voice Service Provider commitment to end-to-end quality
Troubleshooting
Customer Care
Fast response times
Monthly reporting on QoS indicators
SLA Review
19 Scope and Assumptions

The parties agree to:
Provide a detailed description of end to end Quality of Packet Voice Service (QoS),
including related terms definition, initial requirements, provisioning and measurement
methods.
not to cover the IPX end-to-end QoS at the Transport layer as defined in IR.34 and it is
independent of the IP network transport layer used. To avoid any misunderstanding,
V3.0
GSM Association
Non-confidential
only 2 possibilities can be applied for the transport layer: GRX transport or IPX
transport.
cover IPX end-to-end QoS at the Packet Voice Service layer only for the
communications where PVI Service Provider is the originating network. That is, it is
intended as a one way SLA, that is, traffic that starts from the PVI Service Provider,
goes via the IPX Provider only or also via third party IPX Provider(s) and ends at a
terminating PVI service provider (that is, the participating PVI service provider on whose
network the traffic has to be terminated). The IPX Provider commits to send to the PVI
Service Provider all the traffic it receives from other elected participating PVI service
providers or third party IPX provider(s) at the same QoS by which the IPX Provider
receives the traffic.
apply a cascade responsibility principle. This means that, in the typical scenario
analysed in this annex, in order to ensure end-to-end quality of the PVI Service there will
be an SLA in place between the PVI Service Provider and the IPX Provider and an SLA
between the IPX Provider and the third party IPX provider(s) (in the case when a third
party IPX provider is involved in the traffic handling). The IPX Provider must be held
responsible for the behaviour of third party IPX provider up to the elected participating
PVI
service
provider(s).
Transport quality is independent of the Participating PVI Service Provider (refer AA.80)
whereas PVI Quality depends on the Participating Service Providers network quality.
in order to guarantee a full end-to-end SLA both ways from the PVI Service Provider to
the elected participating PVI service provider, a similar SLA chain must be in place on
the return path .
assume that any two PVI Service Providers are interconnected through no more than
two IPX networks (unless this is not possible as in exceptional cases). In the event that
more than two IPX providers are needed to provide the connectivity, the QoS
requirements shall remain unaltered
Transport Quality as defined in AA.80 shall be measured and reported for the path
carrying PVI service. If the IPXP implements two different paths for signalling and media
Transport Quality shall be measured along the media path.
The following circumstances are considered out of scope:
A fault in, or any other problem associated with, PVI Service Provider supplied power,
any PVI Service Provider equipment, non-maintained structured cabling.
Packet Voice Service suspension in accordance with the terms of the AA.80 Agreement.
20 Packet Voice Service Definition

The Packet Voice Service Hub/ Packet Voice Service Transit rendered by IPX Provider to
the PVI Service Provider enables the connectivity between the PVI Service Provider and the
elected participating PVI service providers listed in the Agreement with the QoS
requirements described in this Annex, enabling Packet Voice Service interworking and
(when applicable) Roaming Packet Voice Services.
21 IPX End to End responsibility

The Parties intend this SLA to ensure end-to-end quality of the PVI Service rendered to the
PVI Service Provider in a way that all commitments of the IPX Provider are valid from the
PVI Service Providers network to the elected participating PVI service provider(s) network
whatever technical solution is used and operated by the IPX Provider.
V3.0
GSM Association
Non-confidential
To achieve this goal this SLA defines a set of Key Performance Indicators (KPIs) that
provide a measurement of the level of QoS associated to the Packet Voice Service
rendered by the IPX Provider
The Parties agree that it is the responsibility of the IPX Provider to provide the end-to-end
quality as described in this SLA within the boundaries (demarcation points as defined in
AA.80) of the IPX network. In order to achieve end-to-end quality of the PVI Service all
parties involved in the message flow should be compliant with the requirements expressed
in this SLA.
Parties understand that the end-to-end path in an IP Packet Voice Service connection can
be made up of many diverse components. The following drawing is only an illustration of
what could be in the path:
Figure 1:
IPX End to End responsibility
22 Key Performance Indicators (KPIs)

The parties have agreed a set of KPIs that reflect the QoS rendered by IPX Provider.
These KPIs are:
MTRS
Packet Voice Service Availability
Packet Voice Service Provisioning Timeframes
ASR
ABR
NER
ALOC
PGAD
CLI Transmission
Delay
Packet Loss
Jitter
MOSCQE
V3.0
GSM Association
Non-confidential
These indicators relate only to traffic sent by the PVI Service Provider to each elected
participating PVI service provider via the IPX Provider. For ASR, ABR, NER, ALOC, PGAD
and CLI Transmission, the origin of the measurements is from the IPX Providers first
switching proxy up to and including the Terminating Service Providers network otherwise
state different.

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 Providers 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 PVI Service Provider and IPX Provider platform
Packet Voice Service affecting outage in the interconnection equipment
22.1.1 Critical Errors

A complete breakdown/outage, critical performance degradation, functionality of a single
Packet Voice Service causing Packet Voice Service unavailability included but not limited
to:
Failure of connectivity and/or Traffic between IPX Provider and a connected third party
IPX provider
Total loss of connectivity between PVI Service Provider and IPX Provider platform
Packet Voice Service affecting outage in the interconnection equipment
Serious degradation of the quality as measured by the KPIs indicated within this SLA
measured both by the PVI Service Provider or the IPX Provider
22.1.2 Severe Errors

The functionality of the Packet Voice 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 Packet Voice Service, either of the performance or the
quality, includes but it is not limited to:
Loss of diversity or duplicity of the routes or/and signalling links, without isolation with
the other network, i.e., one link of the redundant connections is out of Packet Voice
Service; backbone congestion causes excessive packet loss or jitter.
Degradation of the QoS to any elected participating PVI service provider, being defined
as when any measured value for KPI is below the target threshold as indicated in the
SLA.
22.1.3 Warning Errors

A minimal limitation to the Packet Voice 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 Packet Voice Service numbers
V3.0
GSM Association
Non-confidential

Is the proportion of the time that IPX Packet Voice Service is available to the PVI Service
Provider on a monthly basis. Three different types of availabilities apply:
22.2.1 Packet Voice Service System Availability
It applies to the Packet Voice Service offered by the IPX Provider on its own network from
the BG of the PVI Service Provider.
Calculating Availability: The parameter [IPX Packet Voice Service] System Availability
describes the percentage of time that the [IPX Packet Voice Service] System is carrying its
function out properly (see calculation below).
Am Bm
100
Am
where:
Am = Number of hours in Month of Packet Voice Service System Availability

Bm = Number of hours when Packet Voice Service System is unavailable (approving
planned outages)
Packet Voice Service System Unavailability time begins at time of detection of unavailability
by either the IPX Provider or the PVI Service Provider whichever the earlier and ends at
time of Packet Voice Service restoration.
Packet Voice Service System Availability means that the IPX Provider is able to transit the
PVI Service Providers traffic to the elected participating PVI service providers network or to
the third partys IPX provider, if any.
22.2.2 Packet Voice Transit Service Availability
Packet Voice Transit Service Availability applies to the Packet Voice Service offered by the
IPX Provider from the PVI Service Providers network up to the elected participating PVI
service providers network.
Availability on the access is determined by the relevant IPX Provider type of connection.
Calculating Availability: The parameter Packet Voice Transit Service Availability describes
the percentage of time that the Packet Voice Transit Service is carrying its function out
properly (see calculation below).
Am Bm
100
Am
where:
Am = Number of hours in Month of Packet Voice Transit Service Availability
V3.0
GSM Association
Non-confidential
Bm = Number of hours when IPX Providers Packet Voice Transit Service is unavailable
(excluding planned outages)
Packet Voice Transit Service Unavailability time begins at time of detection of unavailability
by either the IPX Provider or the PVI Service Provider whichever the earlier and ends at
time of Packet Voice Service restoration.
Packet Voice Transit Service availability means that the IPX is able to transit and terminate
the PVI Service Providers traffic to the elected participating PVI service providers network.
22.2.3 Packet Voice Transit Service Availability per Destination
Packet Voice Transit Service Availability per destination applies to the Packet Voice Service
offered by the IPX Provider from the PVI Service Providers network up to the elected
participating PVI Service providers network. This indicator reflects possibility for the PVI
Service Provider to access a particular destination included in the Packet Voice Service
offered by the IPX Provider.
Availability on the access is determined by the relevant IPX Provider type of connection.
Calculating Availability: The parameter Packet Voice Transit Service Availability per
destination describes the percentage of time that the Packet Voice Transit Service is
carrying its function out properly for the terminating PVI service provider (see calculation
below).
Am Bm
100
Am
Am = Number of hours in Month of IPXs Packet Voice Transit Service Availability for a
Terminating PVI Service Provider
Bm = Number of hours when IPXPacket Voice Transit Service is unavailable for a
Terminating PVI Service Provider (excluding planned outages)
Packet Voice Transit Service per destination unavailability time begins at time of detection
of unavailability of a terminating PVI service provider by either the IPX Provider or the
originating PVI service provider whichever the earlier and ends at time of Packet Voice
Service restoration for a terminating PVI service provider.
Packet Voice Transit Service der destination availability means that the IPX Provider is able
to transit and terminate the terminating PVI service providers traffic to a specific elected
participating PVI service providers network.

This defines the average timeframes for the IPX to perform and undertake certain priotities
in respect of provisioning/commissioning new customers and Packet Voice Services. Such
as:
Maximum Time to turn on a new destination that is included in the IPX connectivity list,
assuming that the new destination (elected participating PVI service provider) accepts
traffic from the client PVI service provider.
V3.0
GSM Association
Non-confidential
Maximum Time to Modifying existing client PVI service provider data

It represents an indication of the commitment of the IPX to commission new customers and
new Packet Voice Services for existing customers expeditiously.
22.4 Answer Seizure Ratio (ASR)

ASR expresses the relationship between the number of call sessions started by SP voice
server and the number of calls set-up normally in a given period of time.
ASR is the ratio of the relationship between the number of INVITE with an encapsulated
IAM sent by the SP voice server and the number of response 200 OK INVITE with an
encapsulated ANM received by SP voice server on a monthly basis.
ASR
Total # of 200 OK INVITE [ANM]SP

10
Voice Server
Total # of INVITE [IAM]SP Voice 0
Server
SP Voice
Server
Voice HUB
Server
Normal flow for a call setup. Trigger points for ASR
Figure 2:
Normal flow for a call setup. Trigger points for ASR

ABR expresses the relationship between the amount of call sessions Voice HUB server is
asked to set-up and the amount of then set-up normally in a given period of time.
V3.0
GSM Association
Non-confidential
ABR is the ratio of the relationship between the number of INVITE with an encapsulated
IAM received by the voice HUB server and the number of responses with an encapsulated
ANM sent by voice HUB server on a monthly basis.
ABR
# of 200 OK INVITE [ANM]

Server
# of INVITE [IAM]
Voice HUB
Voice HUB
10
0
Server
SP Voice
Server
Voice HUB
Server
Normal flow for a call setup. Trigger points for ABR
Figure 3:
Normal Flow for a call setup. Trigger points for ABR
22.6 Network Efficiency Ratio (NER)

NER expresses the ability of a network to deliver a call without taking into account user
interferences in a given period of time.
NER is the ratio of the relationship between the number of INVITE with an encapsulated
IAM sent by SP voice server with encapsulated IAM and the responses received by SP
voice server that result in:
A response 200 OK INVITE with an ANM encapsulated (normally setup) or

A BYE response or message type 486 Busy Here with REL encapsulated and cause
release 17 or
A BYE response or message type 600 Busy everywhere with REL encapsulated with
cause release 17 or
V3.0
GSM Association
Non-confidential
A BYE response or message type 480 Temporarily unavailable with REL

encapsulated with cause value 18 or 19 or 20 or 21 or 31, or
A BYE response or message type 484 Address Incomplete with REL encapsulated
with cause value 28 or
A BYE response or message type 404 Not Found with REL encapsulated with cause
value 1 or
A BYE response or message type 604 Does not exist anywhere with REL
encapsulated with cause value 1 or
A BYE response or message type 500 Server Internal Error with REL encapsulated
with cause value 50 or 53 or 55 or 57 or 87 or 88 or 90.
A CANCEL message with REL encapsulated with cause value 16 normal call clearing
in forward direction.
on a monthly basis.
NER
# 200 OK INVITEANM # BYEREL 1,17 21,28,31,50,53,55,87,90

#404REL 1 #604REL 1 #486REL 17 #600REL 17
#480REL 18 21,31 #484REL 28
#500REL 50,53,55,57,87,88,90 # CANCELREL 16
Total # of INVITEIAM
SP Voice Server
* 100
SP Voice Server
22.7 Post Gateway Access Delay (PGAD)

22.7.1 Abstract definition:
PGAD expresses the time elapsed between the SP voice server asking for a call setup and
the ringing tone for that call in a given period of time.
PGAD is the average time between SP voice server sending an INVITE with an
encapsulated IAM and the SP voice server receiving a 180 Ringing with encapsulated
ACM on a monthly basis.
PGAD
[T180 ringing[ACM ] - TINVITE [IAM]]

SP Voice Server
# of INVITE [IAM] SP Voice Server
V3.0
100
GSM Association
Non-confidential
SP Voice Server
Voice HUB
Server
Normal flow for a call setup. Trigger points for PGAD
Figure 4:
Normal flow for a call setup, Trigger points for PGAD
22.8 Average Length of Call (ALOC)

ALOC expresses the average time of conversation for all the calls successfully setup in a
given period of time.
ALOC is the average time between SP voice server receiving a 200 OK INVITE with an
encapsulated ANM and the SP voice server receiving a BYE message with encapsulated
REL on a monthly basis.
V3.0
GSM Association
Non-confidential
ALOC
[ in seconds]
[TBYE[REL] -T200 OK INVITE [ANM]

]Voice
SP
# of 200 OK INVITE
Server
[ANM] SP Voice
10
0
Server
SP Voice
Server
Voice HUB
Server
Normal flow for a call setup. Trigger points for ALOC
Figure 5:
Normal flow for a call setup. Trigger points for ALOC

CLI Transmission expresses the ability of a network to successfully transmit the Calling Line
Identification/P-Asserted Identity through the network in a given period of time.
CLI Transmission is the ratio of the relationship between the number of INVITE with an
encapsulated IAM with CLI information encapsulated sent by the SP voice server and the
number of INVITE with an encapsulated IAM with CLI information encapsulated received by
the voice HUB server on a monthly basis.
V3.0
GSM Association
Non-confidential
# of INVITE [IAM<CLI present>]
CLI Transmision
SP Voice
Server
Voice
HUB Server
10
0
Voice HUB
Server
Normal flow for a call setup. Trigger points for CLI Tx.
Figure 6:
Normal flow for a call setup. Trigger points for CLI Tx.
22.10 KPIs quantifying the media plane of Packet Voice Service

22.10.1
Definition
Delay is defined as the time it takes for a packet to go from one point to another as specified
by the IP Packet Transfer Delay (IPTD) in ITU-T Recommendation Y.1540.
Jitter describes the variation of inter-packet arrival time. Jitter is defined as One-point packet
delay variation as specified in Appendix II of Y.1540.
Jitter is summarized by providing:
a. Total number of measured packet delay variations
b. Total number of packets exceeding a pre-defined delay variation interval, e.g.
40 ms (covering all packets arriving too late for playout)
These values shall be used to calculate objectives as specified in sect. 6.2.4.3 of Y.1540.
Packet loss is the ratio between the total lost packets and the total sent packets over a
given time period as specified in ITU-T Recommendation Y.1540 as IP packet loss ratio
(IPLR).
V3.0
GSM Association
Non-confidential
MOS (Mean Opinion Score) is a subjective parameter defined in ITU-T Rec. P.10 as the
mean of opinion scores, that is, of the values on a predefined scale that subjects assign to
their opinion of the performance of the telephone transmission system used either for
conversation or for listening to spoken material. ITU-T Rec. G.107 defines an objective
transmission rating model (the E-model) for representing voice quality as an R-Factor,
accounting for transmission impairments including lost packets, delay impairments and
codecs. The R-Factor may be converted into an estimated MOS which is called MOS
Conversational Quality Estimated or MOSCQE (as defined in ITU-T Rec. P.10) using
formula in ITU-T Rec G 107 Annex B.
[OPTIONAL] When agreed between SP and IPXP MOSCQE can be replaced by P.564
conformant MOSLQE plus one-way end-to-end delay as a suitable alternative. P.564

conformant MOSLQE can be used for benchmarking; no such benchmark standard is
available for MOSCQE.
The IPXP is responsible to operate the media plane (carrying the PVI service) and to ensure
service quality within the demarcation points as defined in clauseError! Reference source
ot found. 21. This applies for the following KPIs: Delay, Jitter, Packet loss, and MOSCQE.
Since the PVI Service relies on the use of Border Functions (SBC) and Call Handling
Functions the path followed by voice media and voice signaling can be significantly different
from that one followed at IP layer (as used for example by the Transport Service applying
the OSPF / BGP routing protocols). IPXP shall measure and report the path carrying PVI
service; if the IPXP implements two different paths for signaling and media of PVI traffic
quality shall be measured along the media path.
Since the PVI Service is bidirectional (voice sent from user A to user B and vice versa),
KPIs shall be measured and reported for each media direction independently. Measurement
and reporting applies for calls originated by the Service Provider.
22.10.2
Media plane KPIs when more than one IPXP are involved
When more than one IPX Provider is required to transport PVI Service from Service
Provider to another Participating PVI Service Provider, the end-to-end quality can be
derived differently.
If end-to-end measurement between the demarcation points is impossible, IPXP shall
aggregate KPIs as follows:
a. for the Delay, IPXP and each involved 3rd Party IPXP computes the delay of its
own domain by summing up the values computed for each segment covered by
the RTP path. The end-to-end Delay is passed to the IPXP for a further
aggregation (always summing up the values);
b. for Jitter, no aggregation takes place. IPXP measures and reports Jitter for all
destinations that can be reached via Direct Connectivity;
c.
for Packet Loss, IPXP and each involved 3rd Party IPXP computes the loss of its
own domain by computing the joint probability of a loss for each segment
covered by the RTP path. For 2 segments the formula is
i. Packet Loss end-to-end = [1- (1- PL1)* (1-PL2)]
where
PL1 is the Packet Loss of the 1st segment
and PL2 is the Packet Loss of the 2nd segment

V3.0
GSM Association
Non-confidential
The end-to-end Packet Loss is passed to the IPXP for a further aggregation
(always computing the joint probability of a loss).
d. MOSCQE can be computed on the basis of aggregated packet loss and delay.
When end-to-end measurement between the demarcation points is possible, IPXP shall
apply this methodology; IPXP shall provide a time plan when end-to-end measurements are
available.
Measurement methods
22.10.3
IPXP is free to measure the aforementioned KPIs in different ways. When active
measurements are applied at least the following measurement parameters shall apply.
Full analysis of all traffic or sampling at least once every 5 minutes (300 sec.)
Samples must cover a full minute of bi-directional voice communication
Sampling pattern: 400 packets, 160 Byte each transmitted every 20 ms; in general
the pattern should have the characteristics of an RTP stream, in order to be treated
by the network like an actual VoIP call. This means IP/UDP/RTP transport and RTP
payload of 160 bytes (for G.711 20 ms emulation); a minimum of 8 seconds speech
data is required to compute a MOS.
Duration: continuously during the day (24h x 7 days).
During one day at least 12x24=288 sampling pattern are generated per each route
When media loopback is used as end-to-end measurement methodology, encapsulated

loopback shall be applied as defined in RFC [An Extension to the Session Description
Protocol (SDP) for Media Loopback; draft-ietf-mmusic-media-loopback-16].
MOSCQE shall be measured for G.711 codec. IPXP shall measure MOSCQE for other codecs
if requested by the SP.
Upon request, IPXP shall provide the SP all parameters used to measure and calculate
MOSCQE and the underlying R-Factor.
IPXP shall inform the Service Provider on the measurement points, the applied QoS
measurement methods and the measurement parameters.
Statistical parameters
22.10.4
IPXP computes and reports the aforementioned KPIs on a monthly basis for each media
direction independently at least with the following granularity.
V3.0
Delay
o
Average Delay per month
[Optional] Minimum Delay (of any 15 min interval during the month)
[Optional] Maximum Delay (of any 15 min interval during the month)
[Optional] 95% percentile of delay (during the month)
GSM Association
Non-confidential
V3.0
99% percentile of delay (during the month)
Packet Loss
o
Average Packet Loss per month
[Optional] Minimum Packet Loss (of any 15 min interval during the month)
[Optional] Maximum Packet Loss (of any 15 min interval during the month)
[Optional] 95% percentile of Packet Loss (during the month)
99% percentile of Packet Loss (during the month)
Jitter
o
For destinations with Direct Connectivity or Gateway Connectivity only
Average Jitter per month
[Optional] Minimum Jitter (of any 15 min interval during the month)
[Optional] Maximum Jitter (of any 15 min interval during the month
[Optional] 95% percentile of Jitter (during the month)
99% percentile of Jitter (during the month)
MOSCQE
o
Minimum MOSCQE (during the month)
Average MOSCQE (during the month)
Maximum MOSCQE (during the month)
Percentage of MOS-qualified minutes per month with MOSCQE >= 4.3 / RFactor >= 90
Percentage of MOS-qualified minutes per month with MOSCQE >= 4.0 / RFactor >= 80
Percentage of MOS-qualified minutes per month with MOSCQE

Factor >= 70
>= 3.6 / R-

Factor >= 60
>= 3.1 / R-

Factor < 60
< 3.1 / R-
GSM Association
Non-confidential
23 Targets for KPI

Severity
Maximum restoration
times
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
The maximum number of qualified Critical faults during the quarter must not be higher than
[State number of faults agreed between Parties]
Additionally, the maximum number of qualified critical faults associated with the same
problem, must never be more than one in the same terminating PVI service provider during
the years quarter.

Packet Voice System Availability target applies: [XX.X%].
Packet Voice Transit Service Availability target applies: [XX.X%].
Packet Voice Transit Service Availability per destination target applies: [XX.X%]
for an elected participating PVI service provider or a set of elected participating PVI service
provider, as indicated by PVI Service Provider
For example: 99,5% for top 20 elected participating PVI service provider, as indicated by
PVI Service Provider and 98.0% for remaining elected participating PVI service provider

Maximum Time to Turn On a New Destination (elected participating PVI service provider):
[State number of days agreed between Parties] days
Maximum Time to modify existing PVI Service Provider: [State number of days agreed
between Parties] days
23.4 Answer Seizure Ratio

ASR: XX.X% [To be agreed between Parties]:

ABR: XX.X % [To be agreed between Parties]
23.6 Network Efficiency Ratio

NER: XX.X % [To be agreed between Parties]
23.7 Post Gateway Access Delay

PGAD: XX.X milliseconds [To be agreed between Parties]
V3.0
GSM Association
Non-confidential
23.8 Average Length of Call

ALOC: XX.X milliseconds [To be agreed between Parties]

CLI Tx: XX.X % [To be agreed between Parties]
23.10 Delay
Delay: [To be agreed between Parties]
23.11 Packet Loss

Packet Loss: [To be agreed between Parties]
23.12 Jitter
Jitter: [To be agreed between Parties]
23.13 MOSCQE
MOSCQE: [To be agreed between Parties]
24 QUALIFYING FAULTS
When according to the PVI Service Providers own measurement, the average daily level of
QoS falls below the KPIs, the PVI Service Provider may raise a qualifying fault.
The PVI Service Provider may request the IPX Provider to handle and investigate all
qualifying faults, and to commit to resolve ___% of them within ___ hours when the fault lies
in its own network.
When according to the PVI Service Providers own measurement, the average weekly or
monthly QoS indicators listed above fall below the target point, PVI Service Provider is
entitled to raise a qualifying weekly/monthly fault.
25 PACKET VOICE SERVICE CREDITS

25.1 Qualifying Claims
PVI Service Provider may submit a claim for a Packet Voice Service credits when a
Qualifying fault has been raised and not resolved in the committed time.
25.2 Packet Voice Service Credit Level

PVI Service Providers can use Schedule A attached to this SLA as reference
25.3 Packet Voice Service Credits Claim Procedure

In order to claim for a Packet Voice Service credit, PVI Service Provider may provide the
following details of the faults to the IPX Provider`s commercial contact:
IPX Provider fault reference

PVI Service Provider fault reference
Destination
V3.0
GSM Association
Non-confidential
Time of notification
Time of resolution
Severity of error
Amount of credit claimed
The mechanism for compensating any eventual Packet Voice Service credit due will
mutually agree between parties.
26 CONTROLLED CONNECTIVITY POLICY

The PVI Service Provider may request that the IPXP provides all connectivity information
associated with its offer, namely identifying the type of routing used for each Participating
PVI SP. The IPXP shall also provide PVI SP with the information referred to in clause
Monthly Report on an on-going basis during the term of this Schedule.
In order to avoid deterioration of the quality of Packet Voice Service, information on the
connectivity for each terminating PVI service provider shall be made transparent to the PVI
Service Provider.
IPXP shall route all PVI calls as follows, in decreasing order of preference:
1. via Direct Connectivity if available;
2. via Indirect Connectivity over two hops if available;
3. via Indirect Connectivity over more than two hops if available;
4. via Gateway connectivity
In any case, the direct termination of traffic by the IPX Provider on the participating PVI
Service Provider shall be favoured whenever it is technically possible.
When selecting Third Party IPX Providers for routing cases where no Direct Connectivity
exists, the IPXP shall work efficiently to identify the maximum possible number of options for
onward routing and select the option with the best overall quality of service.
The IPXP shall inform PVI Service Provider each time it changes its Connectivity Option for
a Participating PVI SP, for example from Direct Connectivity to Indirect Connectivity,
except where the route is temporarily congested or out of service. If the route is
temporarily congested or out of service the IPX Provider shall ensure that:
the traffic automatically overflows to the next available route; and
quality of service is not compromised.
26.1 Direct connectivity

Direct connectivity to participating PVI service providers is when the IPX Provider offers a
direct connectivity with participating PVI service providers network to the PVI Service
Provider. That is, only one hop from the PVI Service Provider and the elected participating
PVI service provider. Direct Connectivity is also referred to as on net.
26.2 Indirect connectivity

Indirect connectivity to participating PVI service providers is when the IPX Provider uses a
third party IPX provider to offer connectivity to such third party IPX providers networks. That
V3.0
GSM Association
Non-confidential
is, at least two hops are needed to reach the elected participating PVI service provider.
Indirect Connectivity is also referred to as off net.
26.3 Gateway connectivity

If neither Direct Connectivity nor Indirect Connectivity is available to the IPXP, Gateway
Connectivity may be used by the IPXP for PVI Service. Such Gateway Connectivity shall
not affect any other obligation of the IPXP as defined in this Schedule.
For Gateway Connectivity the demarcation point is defined by the boarder element where
the IPXPs network connects to a non-IPX compliant network.
For security reasons and due to the obligation on the IPXP to assume end-to-end
responsibility, Gateway Connectivity which involves connecting the IPXPs network directly
to unsecure IP-based networks (for example, the public internet) is not recommended,
except as permitted by the clause below.
The Parties acknowledge that some numbers can be reached over the public internet only.
In such cases where a number is reached over the public internet, Gateway Connectivity to
the public internet shall be allowed. IPX Provider shall disclose such use of the public
internet to the Service Provider.
For PVI Service two specific types of Gateway Connectivity shall apply:
TDM break-in/out, which is allowed, covering TDM break-in as well as TDM breakout; and
IP break-in/out, which is allowed, covering IP break-in as well as IP break-out.
27 CUSTOMER CARE and MONITORING

IPX Provider must provide a 24x7 Help Desk.
The IPX Provider must provide a web access monitoring tool where the PVI Service
Provider sees the traffic performance of the IPX Provider.
This monitoring tool will only show the traffic originating from the Service Providers network.
28 OPERATION & MAINTENANCE FAULT MANAGEMENT

28.1 Introduction
This section details the operational processes to be provided to PVI Service Provider by IPX
Provider and vice versa for IPX Packet Voice Services.
The terms used in the Packet Voice Service Level Agreement between IPX Provider and
PVI Service Provider have the same meaning in the Operations and Maintenance Section
unless otherwise stated.
28.2 Central 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 PVI Service.
V3.0
GSM Association
Non-confidential
This contact must be available 24 hours a day at a single telephone contact number.
The requirements for the central notification contact are:
Competency concerning operational issues for IPX Packet Voice Services
Remote access to decentralized operational network elements
Relevant access to tools, resources and knowledgebase to solve problems
This contact has to be competent in operational issues for PVI Services, he has to have
remote access to decentralized operational network elements as well as relevant access to
tools, resources and knowledgebase to solve problems.
24 x7 Reference Details
IPX Provider Details
Packet Voice Service

Provider Details
Contact Point
Telephone Number
Facsimile Number
Email Address
28.3 Fault Classification:

The IPX Provider shall open a trouble ticket in the case of any fault on the Packet Voice
Service reported by the PVI Service Provider or as identified by the IPX Provider at the
contact points indicated in the matrix above. A severity level shall be assigned to each
trouble ticket to describe the effect of the fault.
The following three levels of severity will be used:
Critical Errors [see clause 22.1.1]

Severe Errors [see clause 22.1.2]
Warning Errors [see clause 22.2.3]
28.4 Fault Reporting procedures:

The following section describes the fault reporting procedure for both the PVI Service
Provider and the IPX Provider.
28.4.1 Fault Reporting by Packet Voice Service Provider
The IPX Provider shall provide a contact to receive fault reports 24x7. This contact is set out
in clause 28.2 above.
Suspected faults on the Packet Voice Service shall be reported to the IPX Provider by any
of the approved methods listed above (phone/fax/email) to the contact indicated in the
matrix detailed in 28.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 IPX Provider trouble ticket system to be used for all progress updates. The
PVI Service Provider will provide also its internal reference number for tracking.
V3.0
GSM Association
Non-confidential
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
PVI Service Providers contact name, telephone number and email, if different from the
above
PVI Service Providers Fault Trouble Ticket Number
Physical location of the fault if identified.
Details of the fault (IPX Providers Packet Voice Services at site, symptoms, any tests
carried out in attempting to isolate the problem)
Any environmental conditions, such as a power failure, that may be causing the fault
Severity
PVI Service Provider`s domain/DNS details (if applicable)
IPX Provider traffic details should be included if available.
28.4.2 Fault Reporting by IPX Provider

The IPX Provider shall quickly inform the Service Providers contact (see clause 28.2) by
telephone and email of any critical fault, no matter in which part of the systems involved the
fault occurs.
IPX Provider also agrees to work towards the implementation of an electronic notice board
solution for the delivery of such notifications. Following the issue of any such notice in
respect of a fault, IPX Provider shall keep the PVI Service Provider informed of the progress
of remedial works according to the time interval agreed in this SLA.
28.5 Fault Resolution:

IPX Provider shall immediately start proper fault handling intervention actions and inform
PVI Service Provider accordingly, in line with the procedure stated within clause 28.4.
The time interval to calculate MTRS shall start from the moment when the TT is opened.
Both Parties shall provide each other with the agreed progress updates as reported in
clause 22.1 above.
The minimum information required in the update are:
Liability for the fault

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 IPX Provider cannot resolve a fault within the defined MTRS targets defined in clause
22.1, IPX Provider 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 Packet Voice Service quality level
V3.0
GSM Association
Non-confidential
provided by IPX Provider to below the contractually agreed targets as measured by the
KPIs indicated within the SLA, PVI Service Provider reserves the right to:
Request IPX Provider to re-route the traffic to another Third Party IPX Provider if
appropriate or
Re-route the traffic to another IPX provider
In such cases and in any case, the time to restore the proper functionality of the Packet
Voice Service shall be taken into account when measuring the monthly MTRS level.
28.6 Escalation procedure

Both Parties must name contact persons as 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 either Party.
Both Parties are to comply with internal procedures for the escalation of faults. However, the
reporting Party may (at any time) request that a fault is escalated in advance of the times
set out below. This is done if in the reasonable opinion of that Party, an escalation is
required to increase the resources dedicated to a fault.
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.
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 PVI Service Provider and IPX Provider must be accomplished using
the following steps:
Escalation Level
IPX Provider
PVI Service Provider
Level I
Level II
Level III
<Contact Details>
<Contact Details>
<Contact Details>
<Contact Details>
<Contact Details>
<Contact Details>
Note: Non-Packet Voice Service affecting faults will not be escalated outside of normal
working hours.
Fault Status
Max Escalation Time to

Level II
Max Escalation Time to

Level III
Critical
<Time>
<Time>
Severe
<Time>
<Time>
Warning
<Time>
<Time>
V3.0
GSM Association
Non-confidential
28.7 Official Status Information

After the initial information, updates in accordance with clause 23.1 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.
28.8 Fault Clearance Procedures

Only the Central Notification Addresses can issue an official fault clearance (closure of
trouble ticket for fault resolution).
On mutual agreement of both Parties that the fault has been cleared and normal IPX Packet
Voice Service has been restored, faults will be classified as cleared and the Response
and Restoration Time Clock are stopped.
28.9 Duration of a fault

The duration of a fault shall be defined as per clause 23.1.
28.10 Communications
IPX 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 IPX Packet Voice Services: maximum XX days.
Parties agree that:
Emergency situations shall be expedited.

The contact persons for such communications will be those identified in clause 28.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 Packet Voice Service review meetings.
Where an event is planned, each Party is required to notify the other in advance of full
details concerning that event. A brief explanation of the operation shall be included and
the impact or risk of impact, in the IPX Packet Voice Service shall be always specified.
28.11 Planned Outages, Product Updates/Upgrades

Before any planned work is undertaken that might affect the Packet Voice Service, each
Party shall give an advanced notice to the other Party (receiving Party).
Unless agreed otherwise all planned works shall be made Monday through Thursday (if
working day) between 02:00 am and 06:00 am local time.
If such timescales are not respected, the work will be considered as an unplanned outage,
that is, a fault.
This work could be:
Configuration changes (physically, logically)

Changes of expected traffic (amount, quality)
Hardware changes
V3.0
GSM Association
Non-confidential
Software changes (software updates / software upgrades)

Maintenance works in the transmission network
In all cases described above, each Partys network management organization will take
action to reduce disruption of traffic flows to the minimum.
For all works affecting PVI Service Provider traffic, it is also essential to have in advance a
contact available during the planned work who can be contacted to know the status of the
work.
Both Parties reserve their right to refuse a scheduled event when an important reason
exists. A scheduled event is only approved and can be carried out if both Parties agree on
the event.
Advice of proposed planned work shall be notified by e-mail always at the contact points
indicated in clause 28.2 above, the receiving Party must acknowledge receipt of the advice
by a return e-mail within one (1) working day of the receipt of the advice. If the receiving
Party does not acknowledge the receipt, the originating Party will call the contact number of
the receiving Party and ask for a GO or NO GO decision. The originator must not
proceed with the work without concurrence of the receiving Party, which cannot be
unreasonably withheld, otherwise the work will be considered as an unplanned work/outage,
which is an MTRS impacting fault.
If a new release does not work properly for any reason, then IPX Provider will have a
proven rollback process in order to revert the system back to its original working state. In
such a case, the time to restore the proper functionality of the Packet Voice Service shall be
taken into account when measuring the MTRS levels.
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 country time).
28.12 Fault Handling Performance Reporting

28.12.1
General 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 Agreements
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.
PVI Service Provider commits to validating the data provided by the IPX Provider not
later than the 20th calendar day.
Reports and validations shall be emailed to the other Partys contact set out below:
IPX Providers contact details
Fill in name, position, email
Service Providers contact details

Fill in name, position, email
Either party may change contact names by providing written notice seven days in advance
of the change being valid.
V3.0
GSM Association
Non-confidential
In the event there is a discrepancy in the reporting of the KPI, between the reports provided
by IPX Provider, and PVI Service Providers own measurements, then the Parties will agree
the reconciliation process to follow.
28.12.2
Monthly Fault Report
To be measured:
Date and hour of the receipt of information pertaining to each Fault notification;
Date and hour of acknowledgement of receipt of Fault notification;
Date and hour of Fault resolution (and notification).
IPX Provider is to the PVI Service Provider supply a monthly Fault Report, with the
following fields completed:
Date and hour of the receipt of information pertaining to each fault notified
Date and hour of acknowledgement of receipt of fault notification;
Date and hour of fault resolution (and notification).
IPX Provider Trouble Ticket No
Service Provider Trouble Ticket No
Priority
Brief description of the problem
Brief description of cause of the problem
Start Fault Date &Time
Response Date & Time
Resolution Date & Time
Time to Restore the Service
28.12.3
Monthly Review Fault Report
Based on the fault report the IPX 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 critical trouble tickets
28.12.4
Monthly Traffic Report
IPX 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.
V3.0
GSM Association
Non-confidential
The Traffic report shall be used for forecast and billing management by both the IPX
Provider and the PVI Service Provider.
The results shall be monthly reported in the traffic report.
Monthly Quality of Service Report (= Monthly Performance Report

= MPR)
28.12.5
IPX Provider shall provide Monthly Performance Reports (MPR) and optionally Weekly
Performance Reports (WPR) on the QoS for the traffic handled from the PVI Service
Provider. These reports should be available to check the level of performance of the Packet
Voice 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.
IPX Provider is 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)
by severity and elected participating PVI service provider
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.
29 OPERATION & MAINTENANCE NON-FAULT MANAGEMENT

29.1 Packet Voice Service Management
Such customer care Packet Voice Service shall be provided on non-faults situations to
include, non-fault related operational problems, operations and maintenance routines and
documentation, pricing and billing queries and technical information.
This Service shall be provided Monday Friday, 9 am 5 pm (of the IPX Provider`s local
time) excluding Public Holidays.
29.2 Traffic Management

The PVI Service Provider commits to providing traffic forecasts at least monthly. The traffic
forecasting provisions shall be used for dimensioning the capabilities of the IPX Provider
network and the IPX Provider termination capabilities on the terminating PVI service
provider. They shall not have any binding effect unless otherwise agreed between IPX
Provider and the PVI Service Provider.
29.3 Participating Service Provider Management

Pursuant to the provisions for election and activation of the participating PVI services
providers, PVI Service Provider may request IPX Provider from time to time to activate the
V3.0
GSM Association
Non-confidential
interworking between its own network and a new terminating PVI service provider not
included in the IPX Provider list of participating PVI service providers.
In such cases, the IPX Provider shall inform PVI Service Provider within one month from his
request, of the road map for implementation of the interworking between the PVI Service
Provider and the required terminating PVI service provider.
If feasible, the IPX Provider shall offer this as a directly connected terminating PVI service
provider to his own Packet Voice Service, otherwise shall use a third partys IPX to
implement the required terminating PVI service provider in the shortest possible time.
At mutually agreed intervals the IPX Provider shall provide the PVI Service Providers with
its terminating PVI service provider forecasts on the activation of new terminating PVI
service providers. Those forecasts shall be used by IPX Provider for implementing all
necessary technical and charging parameters and by PVI Service Provider for systems
configuration.
29.4 Maintenance Operations management

Where an outage is planned by the PVI Service Provider or the IPX Provider, the Party shall
notify the other in advance with full details concerning that outage causing the outage is
required to notify the other in advance at the contact points indicated in clause 28.2 with full
details concerning that outage. A brief explanation of the operation as well as the impact or
risk of impact on the service shall be included.
The IPX Provider shall periodically conduct maintenance tests to check:
The proper functionality of the PVI Service Providers connection to the IPX platform;
The Interworking between the PVI Service Provider and its elected participating PVI
service providers
The Parties will agree, and document in the relevant Packet Voice Service Schedule, the
appropriate maintenance tests to be performed including the allocation of any costs.
29.5 Parameter Change Notification & contact points update

The Parties shall agree at signature of their Agreement on ad hoc timing for notification of
network and billing parameters change & contact points update.
29.6 Connection between IPX Provider System and the PVI Service Providers
System
IPX Provider shall designate a central contact to be responsible for the operational
management of the IPX Packet Voice Service from date of signature of the Agreement until
six calendar months after the Effective Date.
The central contact shall co-ordinate all technical and implementation operations with the
PVI Service Provider and shall report weekly to them on the project progress, unless
otherwise agreed between the parties.
V3.0
GSM Association
Non-confidential
29.7 SLA Review

The PVI Service Provider and IPX Provider agree to perform a review of SLAs QoS
benchmark levels every 6 months to verify the necessity to update such levels in order for
them to be always in line with the current technology and market trends.
V3.0
GSM Association
Non-confidential
Annex A
Schedule A Packet Voice Service Credit Level
Quality of PVI Service Hub / PVI Service Transit is impacted by the Participating Service
Providers network quality. Parties understand that PVI service credit levels either correlated
with committed SLAs of Participating Service Provider or are commercial commitments by
the IPXP.
[TO BE AGREED BETWEEN PARTIES]
V3.0
GSM Association
Non-confidential
Document Management
Document History
Version
Date
Brief Description of Change
1.0
5 May
2008
Document 41 approved by IWG

IWG #8 & EMC
#8Plenary June 2008
IWG #9 eVote
CR 001 (IWG Doc 09_008).
Dec 2008
Remove references to BA.27
EMC #69
CR 002 to AA.81 Quality
Improvements to SLA section
(IWG Doc 10_030) and CR 003 IWG#10
to AA.81 Quality Improvements EMC #74
to main body (IWG Doc
10_019)
1.1
24 Dec
2008
1.2
1 July
2009
Approval
Authority
Editor
/
Company
Maida Mas
(Telefonica)
Dimitri
Repinic
(Belgacom)
Dimitri
Repinic
(Belgacom)
IWG Doc 12_044 CR 006 to

AA.81 Opt in/Opt out
AA.81 Charging Transparency
IWG Doc 12_031Rev1 CR 008
to AA.81 Clarification proposed
regarding
boundary
demarcations
2.0
21 July
2010
IWG Doc 12_032Rev1 CR 004

to AA.81 Use of more than 2
IPX
IWG #12 & EMC
Dimitri
Repinic
(Belgacom)
IWG #14 & EMC

#95
Dimitri
Repinic
(Belgacom)
IWG #15 & IWG

#16
Andreas
Mann
(Vodafone)
IWG #17
Andreas
Mann
IWG Doc 12_033 CR 005

Refinement of NER in SLA
IWG Doc 12_018 CR 009
Removal of Operating Period
Editorial update to refer to
Critical, Severe & Warning
instead of Fatal, Severe &
Warning
2.1
27 July
2011
3.0
28.9.12
3.1
25.1.13
V3.1

AA.81 Transit Mode
IWG Doc 16_064 Media Plane
KPI
IWG Doc 16_063 NER
Definition with CUG
IWG Doc 16_062rev1 Breakin/out
IWG Doc 15_062 Boundary
for Voice KPI
IWG Doc 15_061 IMS SIP
AA.81 CR10001 Update
reporting requirement
Page 41 of 42
GSM Association
Non-confidential
(Vodafone
Other Information
Type
Document Owner
Editor / Company
Description
IWG
Andreas Mann (Vodafone)
It is our intention to provide a quality product for your use. If you find any errors or omissions,
please contact us with your comments. You may notify us at prd@gsm.org
Your comments or suggestions & questions are always welcome.
V3.1
Page 42 of 42

Packet Voice Interconnection Service Schedule To AA.80 25 January 2013

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Packet Voice Interconnection Service Schedule To AA.80 25 January 2013

Uploaded by

Copyright:

Available Formats

GSM Association

PACKET VOICE INTERCONNECTION SERVICE SCHEDULE

9 Service Provider Termination Charges

12 Data Exchange and Invoice Procedure

13 Participating Service Parameter Change Notification

15 Service Providers Parameters

21 IPX End to End responsibility

22.5 Answer Bid Ratio

25.1 Qualifying Claims

26.1 Direct connectivity

Packet Voice Service Management

AA.81 Packet Voice Interconnection Service Schedule to AA.80

Entered by and between

Hereinafter IPX PROVIDER or ____ or PARTY

Hereinafter SERVICE PROVIDER or ____ or PARTY

The PARTIES have executed an agreement on IP Packet eXchange (IPX) Services.

2 Commencement of Initial Services

Opt in-Opt Out Process

Opt in-Opt Out Process does not apply for PVI.

Signed on this _________________ in [City]

The IPX PROVIDER: IPX_Provider_full_name

___ (name + function)

___ (name + function)

Signed on this _________________ in _________________ (place)

TheError! Reference source not found.: Service_Provider_full_name

___ (name + function)

___ (name + function)

10 IPX Transit Charges

11 Participating service Providers termination rates

12 Data Exchange and Invoice Procedure

12.2 Minimum content of the invoice

14 Participating Service Providers Parameters

15 Service Providers Parameters

17 Service features for PVI

(a) 3GPP SIP-I protocol

T.38, G.711 (transport in T.38, G.711 (transport in

Codecs analogue data

G.711 (transport in RTP per G.711 (transport in RTP per

Codecs Text telephony

In band G.711, RFC4733

In band G.711, RFC4733

Transport media plane

Transport control plane

AMR, G.711, G.729 (inc D and E),

ITU-T Q.1912.5 Profile C; 3GPP SIP-I;

A and B party establishment.

AMR 12.2 (TrFO)

Ring tone generation

Normal cases A and B.

UUS; Call Complete to Busy

20ms for G.711

5ms for G.711

In-band transport (G.711).

FFS, to be discussed with

IPX Protocol Interworking

Annex 3: Service Level Agreement (SLA) for Packet Voice

Packet Voice Service Definitions

19 Scope and Assumptions

The following circumstances are considered out of scope:

20 Packet Voice Service Definition

21 IPX End to End responsibility

IPX End to End responsibility

22 Key Performance Indicators (KPIs)

Signed on this _ in _ (place)