final draft etsi eg 201 916 v1.1...2001/01/01 · service provider access; development of standards...

Final draft ETSI EG 201 916 V1.1.1 (2001-08)ETSI Guide

Services and Protocols for Advanced Networks (SPAN);Service Provider Access;

Development of standards to support Open Inter-NetworkInterfaces and Service Provider Access

ETSI

Final draft ETSI EG 201 916 V1.1.1 (2001-08)2

ReferenceDEG/SPAN-141605

Keywordsaccess

ETSI

650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing orperceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drivewithin ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status.Information on the current status of this and other ETSI documents is available at http://www.etsi.org/tb/status/

If you find errors in the present document, send your comment to:[email protected]

Copyright Notification

No part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2001.All rights reserved.

http://www.etsi.org/

http://www.etsi.org/tb/status

mailto:[email protected]

ETSI


Contents

Intellectual Property Rights ................................................................................................................................4

Foreword.............................................................................................................................................................4

Introduction ........................................................................................................................................................4

1 Scope ........................................................................................................................................................6

2 References ................................................................................................................................................6

3 Definitions and abbreviations...................................................................................................................83.1 Definitions..........................................................................................................................................................83.2 Abbreviations .....................................................................................................................................................8

4 History and Regulatory Background........................................................................................................94.1 Development of the Market................................................................................................................................94.2 EC Directives .....................................................................................................................................................9

5 Service aspects .........................................................................................................................................95.1 Service Definition...............................................................................................................................................95.2 Benchmark Services ...........................................................................................................................................95.3 Service Provider Access Management .............................................................................................................10

6 Architectural Aspects .............................................................................................................................106.1 API - Architectures...........................................................................................................................................126.2 Management Architecture ................................................................................................................................13

7 Interfaces ................................................................................................................................................137.1 Open Access using the User to Network Interface ...........................................................................................137.2 Open Access using the Network to Network interface.....................................................................................147.3 Requirements and Priorities .............................................................................................................................157.4 SP-PNO Scenarios analysed in this ETSI Guide..............................................................................................18

8 Protocol Aspects.....................................................................................................................................198.1 Impact of a service provider's access interface on the UNI between network operators and service

providers...........................................................................................................................................................198.2 Impact of a service provider's access interface on the NNI between network operators and service

providers...........................................................................................................................................................308.3 IN Protocol and API Assessment .....................................................................................................................438.4 Telephony IP Harmonization Aspects..............................................................................................................55

9 Indirect Service Provider access interface (I-SPAI)...............................................................................56

10 Mapping of Requirements against Benchmark Services........................................................................73

11 Management Plane requirements to support services. ...........................................................................7611.1 Relationship between Management Plane, Control Plane, and User Plane ......................................................7611.2 Management Plane categories: .........................................................................................................................76

12 Conclusions ............................................................................................................................................78

13 Future Work ...........................................................................................................................................7813.1 New/Emerging Protocols .................................................................................................................................7813.2 New Requirements ...........................................................................................................................................78

Annex A (informative): Bibliography...................................................................................................79

History ..............................................................................................................................................................80

ETSI


Intellectual Property RightsIPRs essential or potentially essential to the present document may have been declared to ETSI. The informationpertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be foundin ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI inrespect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Webserver (http://www.etsi.org/ipr).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guaranteecan be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Webserver) which are, or may be, or may become, essential to the present document.

ForewordThis ETSI Guide (EG) has been produced by ETSI Technical Committee Services and Protocols for AdvancedNetworks (SPAN), and is now submitted for the ETSI standards Membership Approval Procedure.

IntroductionThe purpose of the present document is to provide a source of reference material to enable Service Providers andNetwork Operators to determine standardized facilities that are available in published ETSI protocols to support theintroduction of services. The present document also validates a number of benchmark services initially identified by theEuropean Commission [1] for third-party service provision using a generic capability set for Open Intelligent NetworkInterconnection and the Service Provider Access Requirements (SPAR) that are captured in clause 7.3.

A number of open network architectural solutions are assessed including IN, Mobile Networks, Internet and ISDN.

Following regulatory and commercial drivers to expand the range and geographical scope of telecommunicationsservices, ETSI working groups are identifying new requirements and developing appropriate standards solutions tosupport open inter-network and service provider access. The present document covers the Open Inter-Network andOpen Network Access Requirements for the Fixed Network, 2nd and 3rd Generation Mobility and NetworkManagement. It addresses these requirements by taking a top down approach including Service requirements,Functional and Physical Architectures.

The present document commences with an introduction to the initial benchmark services to be provided by a ServiceProvider/Network Operator under European Commission mandate BC-T-305 [1] using Intelligent NetworkInterconnection. The present document then describes open access options via either Circuit Related and Non circuitrelated interfaces utilizing both direct service provider interconnection, via a SPAI, and indirect service providerinterconnection via an intermediate Network.

The present document enumerates the activities in relation to the production of a set of open standards for internetworkcontrol plane, management plane and service provider access interfaces. A Public Network Operator can also take theSP role, and indeed nothing in the present document should be taken as precluding such a possibility.

The Service Provider definition is not intended to map to certain country-specific meanings of the term, which are oftentaken as being "resellers", but is strictly intended in this context to cover the role of producing the telecommunicationsservice.

http://www.etsi.org/ipr

ETSI


NNI

'X'

SPAI(CP/UP)

SPAI(MP)

PNO PNO

SP

'Q' 'Q'

Calling partyCalled party

SwitchingTransmission

Management


Management

Management


UNI

Requirement DocumentsSPA

EG 201 722EG 201 897

PNOEG 201 807

APIEG 201 899

ManagementEG 201 965

Figure 1: Reference Architecture for SP-PTN interfaces

ETSI


1 ScopeThe present document aims to facilitate the technical introduction of open inter-network and service provider access. Itincludes architectural scenarios and guidelines, and identifies implementation requirements to support these moreadvanced services. The format is based on a staged approach, covering both circuit-related (CR) and non-circuit-related(NCR) interfaces, including IN-related signalling technologies. It commences with the definition of service providerarchitectural and implementation capabilities, the implementation of which is initially based on standards existing at thestart of the work. ETSI TC SPAN (that has produced the present document) has also been responsible for co-ordinationand the enhancement of protocols, where necessary, in order to meet the Service Provider Access Requirements (SPAR)as outlined in the present document. Open Service Provider access is enabled by means of enhanced User to Networkand Network-to-Network Interfaces. A number of Initial benchmark Services together with Service support and networkmanagement requirements are also considered.

Cross-referencing of the SPAR requirements and the candidate protocols is detailed through sets of tables. Existingprotocol standards are utilized in the analysis, and are considered as candidates for re-use. Emerging protocols and APIswere also considered.

The overall objective of the present document is to map out the facilities and protocols needed to allow delivery oftelecommunications services across multiple networks, including networks that may be geographically or technicallydiverse in nature. Where lack of support in protocol capabilities has been identified, these deficiencies are noted asitems for further work.

2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.

• References are either specific (identified by date of publication and/or edition number or version number) ornon-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies.

[1] ETSI ETR 244: "Intelligent Network (IN); ETSI workplan for IN; (Mandate BC-T-305, step 1)".

[2] ETSI EG 201 722: "Intelligent Network (IN); Service provider access requirements; Enhancedtelephony services".

[3] ETSI EG 201 807: "Network Aspects (NA); Intelligent Network (IN); Network operators'requirements for the delivery of service provider access".

[4] ETSI EG 201 897: "Services and Protocols for Advanced Networks (SPAN); Service ProviderAccess; Service Provider Access Requirements in a Fixed and Mobile Environment".

[5] Directive 97/33/EC of the European Parliament and of the Council of 30 June 1997 oninterconnection in Telecommunications with regard to ensuring universal service andinteroperability through application of the principles of Open Network Provision (ONP).

[6] Directive 98/10/EC of the European Parliament and of the Council of 26 February 1998 on theapplication of open network provision (ONP) to voice telephony and on universal service fortelecommunications in a competitive environment.

[7] ETSI ETS 300 208: "Integrated Services Digital Network (ISDN); Freephone (FPH)supplementary service; Service description".

[8] ETSI ETS 300 712: "Integrated Services Digital Network (ISDN); Public Switched TelephoneNetwork (PSTN); Premium Rate (PRM) service; Service description".

[9] ETSI ETS 300 711: "Integrated Services Digital Network (ISDN); Public Switched TelephoneNetwork (PSTN); Virtual Card Calling (VCC); Service description".

ETSI


[10] ETSI ETS 300 779 (Edition 1): "Network Aspects (NA); Universal Personal Telecommunication(UPT); Phase 1 - Service description".

[11] ETSI EG 201 965: "Services and Protocols for Advanced Networks (SPAN); Service ProviderAccess; Service Provider Access Management Requirements for Open Network Access".

[12] ETSI EN 300 403-1 through 7:"Integrated Services Digital Network (ISDN); Digital SubscriberSignalling System No. one (DSS1) protocol; Signalling network layer for circuit-mode basic callcontrol; Part 1: Protocol specification [ITU-T Recommendation Q.931 (1993/8) modified]". andsubsequent parts.

NOTE: Supplementary Services (SS) are described elsewhere.

[13] ETSI ETS 300 356-1 through 19: "Integrated Services Digital Network (ISDN); Signalling SystemNo.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services[ITU-T Recommendations Q.761 to Q.764 (1994)]"., and subsequent parts. ISUP Version 2.

[14] ETSI EN 300 356-1 through 36: "Integrated Services Digital Network (ISDN); Signalling SystemNo.7; ISDN User Part (ISUP) version 3 for the international interface; Part 1: Basic services[ITU-T Recommendations Q.761 to Q.764 (1997) modified]"., and subsequent parts. ISUPVersion 3.

[15] ETSI EN 300 356-1 through 21: "Integrated Services Digital Network (ISDN); Signalling SystemNo.7; ISDN User Part (ISUP) version 4 for the international interface; Part 1: Basic services [ITU-T Recommendations Q.761 to Q.764 (2000) modified]"., and subsequent parts; ISUP Version 4.

[16] ETSI ETS 300 121 (edition 1): "Integrated Services Digital Network (ISDN); Application of theISDN User Part (ISUP) of CCITT Signalling System No.7 for international ISDN interconnections(ISUP version 1)". (Based on ITU-T recommendation Q.767)

[17] 3GPP TS 29.002: "Digital cellular telecommunications system (Phase 2+) (GSM); UniversalMobile Telecommunications System (UMTS); Mobile Application Part (MAP) specification(3GPP TS 29.002 version 3.7.1 Release 1999)".

[18] ETSI ETS 300 374-1: "Intelligent Network (IN); Intelligent Network Capability Set 1 (CS1); CoreIntelligent Network Application Protocol (INAP); Part 1: Protocol specification".

[19] ETSI EN 301 140-1 (V1.3.4): "Intelligent Network (IN); Intelligent Network Application Protocol(INAP); Capability Set 2 (CS2); Part 1: Protocol specification".

[20] 3GPP TS 22.078: "Digital cellular telecommunications system (Phase 2+); CustomizedApplications for Mobile network Enhanced Logic (CAMEL) - Phase 3. Service description.Stage 1".

[21] ETSI EG 201 899 (V1.1.1): "Services and Protocols for Advanced Networks (SPAN); ServiceProvider Access; Modelling service provider access requirements using an API approach".

[22] ETSI ES 201 915-1 through 12: "Open Service Access; Application Programming Interface;Part 1: Overview".

[23] ETSI EG 201 988-1: "Services and Protocols for Advanced Networks (SPAN); Service Provider AccessRequirements (SPAR); Open Service Access for API requirements version 1".

[24] ETSI EG 201 988-2: "Services and Protocols for Advanced Networks (SPAN); Service Provider AccessRequirements (SPAR); Open Service Access for API requirements version 2".

[25] ETSI ES 201 296: "Integrated Services Digital Network (ISDN); Signalling System No.7; ISDNUser Part (ISUP); Signalling aspects of charging".

[26] ETSI ETR 172: "Business TeleCommunications (BTC); Virtual Private Networking (VPN);Services and networking aspects; Standardization requirements and work items".

[27] ETSI EG 201 367: "Intelligent Network (IN); Number Portability Task Force (NPTF); IN andIntelligence Support for Service Provider Number Portability".

Report_WorkItem.asp?WKI_ID=3314&curItemNr=49&totalNrItems=65&optDisplay=65&qSORT=REFNB&qINCLUDE_SUB_TB=True&qINCLUDE_MOVED_ON=&qSTOP_FLG=N&qTITLE=INAP&butExpertSearch=Search&includeNonActiveTB=FALSE&qREPORT_TYPE=SUMMARY

ETSI


[28] ETSI TR 101 917-1 through 12: "Services and Protocols for Advanced Networks (SPAN); APImapping for Open Service Access; Part 1: General issue on API mapping".

[29] ETSI EG 201 988-3: "Services and Protocols for Advanced Networks (SPAN); Service ProviderAccess Requirements (SPAR); Mapping of Open Service Access for API version 1 to SPArequirements".

[30] ETSI EN 300 650: "Integrated Services Digital Network (ISDN); Message Waiting Indication(MWI) supplementary service; Service description".

3 Definitions and abbreviations

3.1 DefinitionsFor the purposes of the present document, the terms and definitions of Service Provider related terms given in [2], [3]and [4] apply.

3.2 AbbreviationsFor the purposes of the present document, the following abbreviations apply:

API Application Programme InterfaceBICC Bearer Independent Call ControlCAMEL Customized Application for Mobile networks Enhanced LogicCdPy Called PartyCgPy Calling PartyCS-1 IN Capability Set 1CUSF Call Unrelated Service FunctionDSS1 Digital Subscriber Signalling System No. 1GMSC Gateway Mobile Switching CentreHLR Home Location RegisterIN Intelligent NetworkINAP Intelligent Network Application PartIP Internet ProtocolISDN Integrated Services Digital NetworkISUP ISDN User PartMAP Mobile Application PartNNI Network-Network InterfaceONP Open Network ProvisionPTN Public Telecommunications NetworkPTNorig Public Telecommunications Network originatingPTNterm Public Telecommunications Network terminatingSCF Service Control FunctionSP Service ProviderSPAI Service Provider Access InterfaceSPorig Service Provider originatingSPterm Service Provider terminatingSS Supplementary ServiceSSF Service Switching FunctionSSL Secure Sockets LayerTC Transaction CapabilitiesUNI User-Network InterfaceUPT Universal Personal TelecommunicationsUUS User User SignallingVMSC Visited MSCVPN Virtual Private Network

ETSI


4 History and Regulatory Background

4.1 Development of the MarketIn the original European work done in the 1980s, a clear link was drawn between the availability of economicallyefficient telecommunications services and the development of the economy of the region as a whole. Stimulatingcompetition to enable these services was seen as key.

The development of competition in the telecommunications market in Europe has been characterized, initially, by theliberalization of services, at the beginning of the 1990s. This was followed in 1998 by the liberalization of the provisionof infrastructure.

However, for a provider to deliver services where they do not themselves have control of the access network, this willnecessitate interconnection with and access to the network of a relevant network operator. This access has been limitedto ordinary user plane interconnection (call origination, transit and call termination), with the attendant limitations onthe type of services that can be delivered using this mechanism.

In order to enable advanced services, enhanced forms of access are required. These forms fall into two generictypes - control plane access and management plane access. It is in this context that the current work has beenprogressed.

4.2 EC DirectivesEC directives 97/33/EC [5] and 98/10/EC [6] require reasonable requests for access to the networks of operators withSignificant Market Power (SMP) to be met. In order to reduce the costs for all parties concerned, this work is aimed atstandardizing as many of the envisaged capabilities as possible.

5 Service aspectsIn developing the present document, five initial benchmark services have been identified, see [1]. These are currentlysupported under IN and terminal mobility signalling protocols. The benchmark services will be utilized to test theextension of the signalling protocols in support of open network access.

5.1 Service Definition.Services, as defined by current ETSI Standards, are taken within the present document as a benchmark for considerationof protocol support - see Benchmark IN services as listed in clause 5.1.2. Service Providers have the opportunity todevelop these or create their own services to meet specific user requirements. Such services may be developed byutilizing the flexibility offered through an API or by an IN.

5.2 Benchmark ServicesA list of benchmark services are listed in table 1 as defined in ETR 244 [1].

The identified services all have existing service definition for either the PSTN or the ISDN, as defined in table 1.

Table 1: Identification of service definitions for benchmark services (see note)

Identified service PSTN service definition ISDN service definitionFreephone --- ETS 300 208 [7]Premium rate ETS 300 712 [8] ETS 300 712 [8]Virtual card calling ETS 300 711 [9] ETS 300 711 [9]Virtual private network ETR 172 [26](see note) ETR 172 [26](see note)Universal personal telecommunications ETS 300 779 [10] ETS 300 779 [10]NOTE: This is not a service, but an alternative means of provision of existing services defined for the private network.

ETR 172 [26] identifies the work items required for this definition.

ETSI


The benchmark services have been used to specify the Open-INAP Protocol work being developed by ETSIWG-SPAN12 as a special PICS Proforma (DEN/SPAN-120084 (see bibliography)) to accompany IN CS-3, and theyhave also been mapped in the present document against the capabilities noted in the requirements clause 7.3 of thepresent document.

NOTE: ETSI WG-SPAN12 are also using the number portability service as defined in EG 201 367 [27] as anadditional benchmark service for OPEN-INAP.

5.3 Service Provider Access ManagementNetwork Management requirements to support Service Provider Access are listed in the companion Guide EG 201 965 [11].

6 Architectural AspectsA signalling connection between a public telecommunications network operator and a service provider is shown belowin figure 2. The physical connection of the call is only extended from the public telecommunications network to theservice provider's equipment for circuit related (CR) access.

For calls from a calling party (CgPy) in the originating PTN (PTNorig) to a called party (CdPy) in the terminating PTN(PTNterm), in which both PTNs and SPs are involved, various call connection scenarios are possible. Figure 2visualizes two examples of a call connection scenario from the viewpoint of the requirements of the SPs of theoriginating- and terminating-call-related services, called SPorig and SPterm, respectively.

P T N T ermP T N T er m

S erv ices o fo rig in a tin g ca lls

S erv ices o fte rm in a tin g ca lls

S P T er mS P O rig

P T N T ran s it

S cen ario B S cen ario A

C alled P arty (C d P y)

S P A I S P A I

P T N O rig

L egen d : T w o -w a y sp eec h an d /o r signa lling pa th of scenario A =

T w o-w a y spe ech and /o r s ign a llin g p ath o f scenario B =

C allin g P arty (C g P y)

B earer ex ten dedfo r C R case

Figure 2: Examples of call connection scenarios for circuit related SP access

Scenario A is an example of a call in which SPorig is involved. In this scenario A, the call is forwarded from thePTNorig to SPorig which provides a service to the call. SPorig returns the call to the PTNorig. The call is thenforwarded from the PTNorig, eventually via a transit network (PTNtran), to the PTNterm in which the call is terminatedat the called party's (CdPy) line.

ETSI


Scenario B is an example of a call in which both the SPorig and the SPterm are involved. In this scenario, the call isforwarded from the PTNorig to SPorig which provides a service to the call. SPorig returns the call to the PTNorig. Thecall is then forwarded from the PTNorig, eventually via a transit network (PTNtran), to the PTNterm. Then, from thePTNterm the call is forwarded to SPterm which provides a service to the call. SPterm returns the call to the PTNterm, inwhich the call is terminated at the called party's (CdPy) line.

For calls from a calling party (CgPy) in the originating PTN (PTNorig) to a called party (CdPy) in the terminating PTN(PTNterm), in which both PTNs and SPs are involved, various call connection scenarios are possible. Figure 3visualizes two examples of a call connection scenario in the NCR case from the viewpoint of the requirements of theSPs of the originating- and terminating-call-related services, called SPorig and SPterm, respectively.

P T N T ermP T N T erm

Services oforiginating calls

Services ofterm inating calls

SP T ermS P O rig

P TN Transit

Scenario D

C alled P arty (C dP y)

SP A I SP A I

P T N O rig

Legend: T wo-way speech and/or signalling path of scenario C =

C alling P arty (C gP y)

Signalling forN C R case

N on-circuit rela ted signalling path of scenario C =

Two-way speech and /or signalling path of scenario D =

N on-circu it related signalling path of scenario D =

Scenario C

Figure 3: Examples of call connection scenarios in the case of a non-circuit-related SP Access

Scenario C is an example of a call in which SPorig is involved. In this scenario, the signalling in the control plane isforwarded from the PTNorig to SPorig which provides a service to the call. Then, the signalling in the control plane isreturned to the PTNorig, which forwards the call to the PTNterm, eventually via a transit network (PTNtran), in whichthe call is terminated at the called party's (CdPy) line.

Scenario D is an example of a call in which SPorig is involved. In this scenario, the signalling in the control plane isforwarded from the PTNorig to SPorig which provides a service to the call. The signalling in the control plane is thenreturned to the PTNorig, which forwards the call to the PTNterm, eventually via a transit network (PTNtran). Then, thecontrol plane signalling is forwarded from the PTNterm to SPterm which provides a service to the call. The signallingin the control plane is then returned to the PTNterm, in which the call is terminated at the called party's (CdPy) line.

It is evident that a range of ETSI standards need to be invoked for the provision of the SPAI supporting UNI and NNIconfigurations e.g. DSS1 [12], ISUP [13], [14], [15], [16], GSM MAP [17], INAP CS1, CS2, CS3 [18], [19], CAMEL[20]). Implementation of these standards will lead to protocol-specific implementations of SP applications.

ETSI


6.1 API - ArchitecturesEG 201 899 [21] models service provider requirements using an API approach that leads to API definitions inES 201 915-1 [22] and documents EG 201 988-1 [23] and EG 201 988-2 [24] cover open service access APIrequirements.

An API modelling approach is referenced in the architecture under consideration in EP TIPHON. API modelling isbeing developed in the JAIN and PARLAY consortia and standardized in ETSI WG SPAN12 and 3GPP WG CN5. Thefollowing figure shows how different network technologies existing in today's networks can be integrated through APIto the application control plane.

Management

Application Domain

Transport Broker

Real World Network

API e.g. OSA

API e.g. OSA

BearerIPATMISDN

QoSConfirmed

Unconfirmed

Figure 4: Proposed conceptual model to support IP under consideration by EP TIPHON

ETSI


6.2 Management ArchitectureThe management function interface is shown in the following protocol stack allowing current tried and tested signallinglayers to be used.

NNI

'X'

SPAI(CP/UP)

SPAI(MP)

PNO PNO

SP

'Q' 'Q'

Calling partyCalled party


Management


Management

Management


UNI

Figure 5: Reference Architecture for SP-PTN management requirements

7 Interfaces

7.1 Open Access using the User to Network InterfaceFigures 6 and 7 illustrate the SPAI for circuit related and non-circuit-related access using the UNI interfaceconfiguration respectively.

SP

PTNCPE CPE

DSS1/GSM access

SPAI

Figure 6: Circuit-related service provider access using UNI

ETSI


SP

PTNCPE CPE

SCF SSFHLR

(GSM) (GSM)

APIAPIAPISPAI

Figure 7: Non-circuit-related service provider access using UNI

7.2 Open Access using the Network to Network interfaceFigures 8 and 9 illustrate the SPAI for circuit related and non-circuit-related access using the NNI interfaceconfiguration respectively.

SP

PTNCPE CPE

ISUP/BICC SPAI

Figure 8: Circuit-related Service Provider access using NNI

ETSI


SP

PTNCPE CPE

SCF SSF

SCFSCF HLR

HLRHLR

(GSM)

(GSM)(GSM)

MAP

MAPINAP/CAP

INAP

SPAI

Figure 9: Non-circuit-related Service Provider access using NNI

7.3 Requirements and PrioritiesTables 2 through to 7 give a cross-reference to the various requirements and their allocation to various priorities. Wherea requirement priority is indicated, this is taken from the associated requirements document (EG 201 897 [4]).

Table 2: Requirements cross reference - calling party information handling capabilities

EnhancedTelephony

Mobile andInternet

No. Reference Requirement

CR NCR CR NCRA1 [2] 5.2.1

[3] 5.2.2Reception of the calling line identity - Application of theCLIR supplementary service

High/High High/High

A2 [2] 5.2.2 Presentation of the complete CLI information to the PTN High High --- ---A3 [2] 5.2.3 Addition or substitution of a calling line identity High High --- ---A4 [2] 5.2.4 Provision of CLI information to an SP-initiated call High High --- ---A5 [2] 5.2.5

[3] 5.2.1Relaying of the malicious call identification data of areceived call

High/High NA/NA --- ---

A6 [4] 5.1.1 Network Location Determination --- --- High HighA7 [4] 5.1.2 Geographic Location Determination --- --- High HighA8 [4] 5.2.1 Determination of the terminal capabilities of the SP's

service user--- --- High High

ETSI


Table 3: Requirements cross reference - basic call set-up and clear-down capabilities

EnhancedTelephony

Mobile andInternet


CR NCR CR NCRB1 [2] 5.3.1 Return speech path connection from the terminating PTN to

the calling partyHigh High

B2 [2] 5.3.2 Routeing of an originating or incoming call from the PTN tothe SP

High NA

B3 [2] 5.3.3 Indication of an originating or incoming call from the PTN tothe SP

NA High

B4 [2] 5.3.4 Routeing of a terminating call from the PTN to the SP High NAB5 [2] 5.3.5 Indication of a terminating call from the PTN to the SP NA HighB6 [2] 5.3.6 Reception of a notification of the cause of an unsuccessful

callHigh High

B7 [2] 5.3.7 Provision of information for the destination and routeing of acall

High High

B8 [2] 5.3.8 Call drop-back Medium NAB9 [2] 5.3.9 User interaction without service charging of the end user Medium/

HighNA/NA

B10 [2] 5.3.10 Reception of the originally dialled digits by the SP low lowB11 [3] 5.3.1 Reception of the originally dialled digits by the PTN low lowB12 [2] 5.3.11 Disconnection of a call in progress Medium MediumB13 [2] 5.3.12 Connection of a call to an interactive voice response unit in

the PTNNA Medium

B14 [2] 5.3.13 Alternate routeing of calls or the indications of calls toanother "point of presence" of the SP

Medium Medium

B15 [3] 5.3.2 Alternate routeing of a call or the indication of a call toanother "point of presence" of the PTN

Medium Medium

B16 [4] 5.4.1 Indication of the disconnection of a call --- --- High HighB17 [4] 5.4.5 Supervision of a dropped-back call --- --- Void MediumB18 [4] 5.4.2 Join operation of individual legs of a call --- --- High HighB19 [4] 5.4.3 Split operation of individual legs of a call --- --- High HighB20 [4] 5.4.7 Multimedia Multiparty call control --- --- High HighB21 [4] 5.4.8 User Interaction for Text Delivery --- --- High HighB22 [4] 5.4.9 User-Plane resource negotiation and selection --- --- High High

Table 4: Requirements cross reference - supplementary call and data processing capabilities

Enhanced Telephony Mobile and InternetNo. Reference RequirementCR NCR CR NCR

C1 [2] 5.4.1 Interrogation of a network termination point fordata delivery

Medium Medium

C2 [2] 5.4.2 Overriding of the "incoming call barring"supplementary service

High High

C3 [2] 5.4.3 Bypassing of the "call diversion" supplementaryservice

low low

C4 [2] 5.4.4 Message waiting indication High HighC5 [3] 5.5.1 Application contents screening High HighC6 [4] 5.2.2 Modification of the terminal capabilities of the SP's

service user--- --- High High

C7 [4] 5.2.3 Modification of the Personality Device/Module ofthe SP's service user

--- --- High High

C8 [4] 5.3.1 Alteration of the profile of the SP's ServiceSubscriber

--- --- High High

C9 [4] 5.4.4 Delivery of information to the SP's service userprior to alerting

--- --- Medium Medium

ETSI


Table 5: Requirements cross reference - charging-related capabilities

EnhancedTelephony

Mobile andInternet


CR NCR CR NCRD1 [2] 5.5.1 Changes in the charging rate of a call - Dynamic High HighD2 [3] 5.5.2 Charging mechanisms between SP and PTNO - Dynamic High HighD3 [4] 5.6.1 Provision of call charging information in real time --- --- High HighD4 [4] 5.6.2 Exchange of charge detail record information in real time --- --- High HighD5 [11] Billing and Accounting mechanisms between SP and PNO Medium Medium Medium Medium

Table 6: Requirements cross reference - traffic-related capabilities

EnhancedTelephony

Mobile andInternet


CR NCR CR NCRE1 [2] 5.6.1 Event traceability requested by the SP Medium MediumE2 [3] 5.4.1 Event traceability requested by the PTN High HighE3 [2] 5.6.2 Traffic control capabilities controlled by the SP Medium MediumE4 [3] 5.4.2 Traffic control capabilities controlled by the PTN High HighE5 [2] 5.6.3

[3] 5.4.3Avoidance of the cyclical routeing of a call Medium/

HighNA/NA

E6 [4] 5.4.6 Avoidance of the cyclical routeing of signalling or usermessages

--- --- High High

Table 7: Requirements cross reference - management-related capabilities

EnhancedTelephony

Mobile andInternet


CR NCR CR NCRF1 [4] 5.5.1 Reporting of network events for measuring the quality of

service--- --- Medium Medium

F2 [4] 5.5.2 Reporting of network events for the purpose of faultdiagnostics

--- --- High High

F3 [4] 5.5.3 Request for event monitoring and subsequent reporting --- --- High HighF4 [4] 5.5.4 Electronic ordering of network management functions --- --- High High

ETSI


Table 8: Monitored deliverables

Deliverable Work item number TitleEG 201 722(V1.2.1) [2]

DEG/SPAN-061601 Intelligent Network (IN);Service provider access requirements;Enhanced telephony services

EG 201 897 [4] DEG/SPAN-141602 Services and Protocols for Advanced Networks (SPAN);Service Provider Access;Service Provider Access Requirements in a fixed and mobile environment

EG 201 807(V1.1.1) [3]

DEG/SPAN-141603 Network Aspects (NA);Intelligent Network (IN);Network operators' requirements for the delivery of service provider access

EG 201 899(v1.1.1) [21]

DEG/SPAN-140504 Services and Protocols for Advanced Networks (SPAN);Service Provider Access;Modelling service provider access requirements using an API approach

EG 201 988-3[29]

DEG/SPAN-1451606-3 Services and Protocols for Advanced Networks (SPAN);Service Provider Access RequirementsMapping of Open Service Access API Version 1

ES 201 915-1through 12 [22]

DEN/SPAN-120070-1/12 Services and Protocols for Advanced Networks (SPAN);Open Service Access;Application Programming Interface;All Parts

TR 101 917-1through 12 [28]

DEN/SPAN-120075-1/18 Services and Protocols for Advanced Networks (SPAN);API mapping for Open Service Access;All Parts

EG 201 965[11]

DEG/SPAN-141607 Services and Protocols for Advanced Networks (SPAN);Service Provider Access;Service Provider Access Management Requirements for Open NetworkAccess

Not allocatedyet (seebibliography)

DEN/SPAN-120084 PICS-Proforma for OPEN CORE INAP based on OPEN-INAP CS-2 subset,SCF-SCF, CUSF; OPEN-INAP CS-3 subset; SCF-SSF and SCF-SRF.

NOTE: CS-3 is not revising the SCF-SCF interface or the CUSF, which are being carried forward from CS-2. Thereforethe PICS proforma for OPEN-INAP will be applied to the CS-2 interfaces noted above.

7.4 SP-PNO Scenarios analysed in this ETSI GuideThe following figure identifies the results for the various SP-PNO configurations contained in clauses 8 and 9. Thedirect cases apply when the SPAI is connected to the same network as the SP' service user, whilst in the indirect case.

Table 9: Index to results of SP-PNO scenarios analysed in the present document

Service Provider Access InterfaceDSS1

93, 98, 01ISUPV1-4

INAPCS-1/2/3

CAMELPhase 1/2/3

Open INAPCS-2; CS-3

ETSI OSAAPI

Direct 10 11 12 12 12 12Indirect 13 13 13 13 13 13

ETSI


8 Protocol Aspects

8.1 Impact of a service provider's access interface on the UNI between network operators andservice providers

Any UNI that provides a circuit-related service provider interface will need to transfer additional information as well as the existing basic call requirements. Table 10 shows theresults of the analysis of the Service Provider Access Requirements against a Service Provider Access Interface configured using DSS.1 (1993, 1998, 2001). Support mechanismand parameters are indicated in table 10.

Table 10: Requirements assessment for SP<>NO circuit-related UNI interface

NOTE: Any feature provided as an application over UUS requires each of the Users to have an ISDN terminal.

Issues relating to thesupport of therequirement

UNI Protocol 1DSS.1 1993

EN 300 403 (all)(Edition 1) [12]


EN 300 403 (all parts,dates up to 1998) [12]



No. Requirement Information totransfer

Support Mechanism(s)and Parameters



A1 Reception of thecalling lineidentity - Application ofthe CLIRsupplementaryservice.

Receive CLI (whichmay be restricted)including theRestricted flag (if set)for calls from, or to,one of the SPsservice-subscribers.

The current protocolrequires procedures ofCLIP supplementaryservice to provide thiscapability. CLIR willrestrict provision of CLI,unless some form ofoverride capability isavailable. In the casewhere national regulationallows release of arestricted CLI to theservice provider, this isnot regarded as anadequate solution.

Support available as asupplementary service.Override of CLIR for theSPs Service user issubject to nationalregulation.



ETSI




EN 300 403 (all)(Edition 1) [12]









A2 Presentation of thecomplete CLIinformation to thePTN.

Provide to theNetwork the CLI(which may have beenrestricted as in (1)above) together withthe restricted flag (ifset) for calls from or toone of the SPsservice-subscribers.

In the current protocolbasic call will only transferCLI, but not relay theoriginal screeningindicators or presentationindicators. It is assumedthat the specialarrangement would haveto be available.Functionality in respect ofthe screening indicator isnot regarded as anadequate solution.

No support No support No support

A3 Addition orsubstitution of acalling line identity.

Provide to theNetwork a CLI, whichmay be additional toany CLI, or thesubstitution of originalCLI, with theagreement of the SPsservice-subscribers.This applies to callsdestined to thatservice subscriber.

A new parameter wouldneed to be defined withinthe SETUP message.Potentially an existingtransport mechanismcould be used to send theinformation between theSPorig and the PTNterm,but an application wouldneed to be defined.


A4 Provision of CLIinformation to anSP-initiated call.

Provide to theNetwork a CLI,provisioned by the SP.This applies to callsdestined to thatservice subscriber.

In the current protocolbasic call will transfer CLI,but not allow the suppliedscreening indicator to becontrolled. This is notregarded as an adequatesolution.


ETSI




EN 300 403 (all)(Edition 1) [12]









A5 Relaying of themalicious callidentification data of areceived call.

Passing on the CLI(which may berestricted) includingthe Restricted flag, (ifset), for calls from orto one of the SPsservice-subscribers.

MCID data is the calledparty number, the callingparty number andoptionally the calling partysub-address. In order forthe service provider toreceive this information,the procedures ofMSN/DDI and CLIP will berequired. CLIR will restrictprovision of CLI, unlesssome form of overridecapability is available. Inreturning the informationto the network provider,there is no problem withtransferring the calledparty number, but if this isdifferent from the originalcalled party number, thena new parameter will berequired. (or an additionalenhanced Called partynumber). The currentprotocol basic call will onlytransfer CLI, but not relaythe original screeningindicators or presentationindicators. It is assumedthat the specialarrangement would haveto be available. This is notregarded as an adequatesolution.


A6 Network LocationDetermination.

Network Identities,e.g. Port Numbers; BSNumbers, etc.

Yes, Data could bepassed in a FIE. A newFIE parameter would needto be defined. PTN to SPa PTN application clientwould be required.

Yes, Data could bepassed in a FIE. A newFIE parameter wouldneed to be defined. PTNto SP a PTN applicationclient would be required.

Yes, Data could bepassed in a FIE. A newFIE parameter wouldneed to be defined. PTNto SP a PTN applicationclient would be required.

ETSI




EN 300 403 (all)(Edition 1) [12]









A7 Geographic LocationDetermination.

Geodetic data Yes, Data could bepassed in a FIE. A newFIE parameter would needto be defined. Serviceuser's Terminal to SPtransparent.

Yes, Data could bepassed in a FIE. A newFIE parameter wouldneed to be defined.Service user's Terminal toSP transparent.

Yes, Data could bepassed in a FIE. A newFIE parameter wouldneed to be defined.Service user's Terminal toSP, transparent.

A8 Determination of theterminal capabilities ofthe SP's service user.

Coded terminal classcapabilities.

Yes, Data could bepassed in a FIE. A newFIE parameter would needto be defined. Serviceuser's Terminal to SPtransparent.



B1 Return speech pathconnection from theterminating PTN to thecalling party.

Early set-up of thebackward connectionpath. No additionalinformation required.

Requires use of Annex Kof basic call [12], which isnot implemented in allexchanges and is notallowed to be provided oninternational connections.Note that the protocol isrunning a timer within thisstate.

No support forinternational use.



B2 Routeing of anoriginating or incomingcall from the PTN tothe SP.

Setting up a call. Noadditional informationrequired.

No impact on protocol atservice providersinterface.

Yes, no impact Yes, no impact Yes, no impact

B3 Indication of anoriginating or incomingcall from the PTN tothe SP, VOID.

NCR requirementVOID.

Void Void Void

B4 Routeing of aterminating call fromthe PTN to the SP.

Setting up a call. Noadditional informationrequired.

No impact on protocol atthe service provider'sinterface.

Yes, no impact Yes, no impact Yes, no impact

B5 Indication of aterminating call fromthe PTN to the SP,VOID.

NCR requirementVOID.

No impact on protocol atthe service provider'sinterface.

Void Void Void

ETSI




EN 300 403 (all)(Edition 1) [12]









B6 Reception of anotification of thecause of anunsuccessful call.

Call Unsuccessfulcause value.

The reason for the failureof the call is carried by aCause informationelement within theDISCONNECT message.Creating a new SETUPmessage towards thenetwork provider,containing new callinformation providesfurther activity by theservice provider. It hasbeen assumed that thenetwork provider retainsno connection betweenthe original failed call andthe future new call.

Yes Yes Yes

B7 Provision ofinformation for thedestination androuteing of a call.

Provision to thenetwork of RoutingNumbers in addition toDialled (directory)numbers. E.g. Carrierselection codes, and(multiple) transitnetwork selectioncodes.

It is assumed that the useof the Called party numberinformation element andthe Transit networkselection informationelement (if supported)provide adequate supportfor this requirement.

Yes, single carrierselection possible throughuse of Transit NetworkSelection InformationElement.

Service providerinvocation of carrierselection, supportavailable subject tocomposite length of thePresented numberincluding the CSC.





B8 Call drop-back Drop back indicationfor a call.

This requirement couldpotentially be met byprovision of proceduresfor the call deflectionsupplementary service.This would howeverincrease the diversion hopcount by one.

No support Yes: A call can bedropped back from the SPto the local exchange withwhich the SP isconnected via DSS.1 viathe ECT SupplementaryService.

Yes: A call can bedropped back from the SPto the local exchange withwhich the SP isconnected via DSS.1 viathe ECT SupplementaryService.

ETSI




EN 300 403 (all)(Edition 1) [12]









B9 User interactionwithout servicecharging of the enduser.

Allowing and End toEnd Exchange beforethe start the chargingmaybe by providingtwo phase answering.

ETSI specifications do notspecify the point at whichcharging commences for acall. It is therefore unlikelythat ETSI will createspecifications changingthe point at whichcharging commences for acall. Most networkscommence charging at thepoint of transfer of theCONNECT/ANSWERmessage. Somenetworks/serviceproviders delay thetransfer of theCONNECT/ANSWERmessage to allow theprovision of services priorto charging. There ispotential in DSS1 for userinteraction prior to thetransfer of this message,e.g. in the User-to-usersupplementary service.Some networkscommence charging at anearlier point, at which timeeven the network providermay still be providingservices.

No No No

B10 Reception of theoriginally dialled digitsby the SP.

Originally dialled digits A new parameter wouldneed to be defined withinthe SETUP message (oran additional enhancedCalled party number).Potentially an existingtransport mechanismcould be used to send theinformation between thePTNorig and the SPorig or


ETSI




EN 300 403 (all)(Edition 1) [12]









SPterm, but an applicationwould need to be defined.

B11 Reception of theoriginally dialled digitsby the PTN.

Originally dialled digits A new parameter wouldneed to be defined withinthe SETUP message (oran additional enhancedCalled party number).Potentially an existingtransport mechanismcould be used to send theinformation between thePTNorig and the SPorig orSPterm, but an applicationwould need to be defined.


B12 Disconnection of a callin progress

Send Disconnect It is believed that thisrequirements can be metby the existing basic callsending a DISCONNECTmessage in both forwardand backward directions.

Yes Yes Yes

B13 Connection of a call toan interactive voiceresponse unit in thePTN.

Setting up a call to theIVR possibly byrouting number. Noadditional informationrequired.

No additional informationrequired.

Yes Yes Yes

B14 Alternate routeing ofcalls to another 'pointof presence' of theSP, at the instructionof the SP

Setting up a call to thePoP possibly byrouting number. Noadditional informationrequired.

It is possible that thisrequirement could be metby use of procedures ofeither the linehunting/trunk huntingsupplementary or (in alimited manner) by thediversion services.

Not required-management application



B15 Alternate routeing of acall to another 'point ofpresence' of the SP,at the instruction ofthe PTN.

Re-routeing a call tothe PoP possibly byrouting number. Noadditional informationrequired.

Depends on equipmentused by service provider;trunk selection is aninherent part of any PTNXDSS1 implementation.




B16 Indication of thedisconnection of acall.

Receiving theDisconnect message.

Yes, but cause value isimplicit.



ETSI




EN 300 403 (all)(Edition 1) [12]









B17 Supervision of adropped-back call.

Special Drop backindication for a call,and continued NCRinterface.

No No No

B18 Join operation ofindividual legs of acall.

Send Join request. Yes, limited support byCONF SupplementaryService.

Yes, limited support byCONF SupplementaryService.

Yes, limited support byCONF SupplementaryService.

B19 Split operation ofindividual legs of acall.

Send Split request. No, but parties may bedropped from theConference.

No, but parties may bedropped from theConference.

No, but parties may bedropped from theConference.

B20 Multimedia Multipartycall control.

Multimedia callcontrol.

Yes, narrowbandmultimedia multiparty callcontrol available betweenISDN end-points using theCONF supplementaryservice.

Yes, narrowbandmultimedia multiparty callcontrol available betweenISDN end-points usingthe CONF supplementaryservice.

Yes, narrowbandmultimedia multiparty callcontrol available betweenISDN end-points usingthe CONF supplementaryservice. There may besome BICC support in2001.

B21 User Interaction forText Delivery

Exchange use/textdata

Yes, a new FIE wouldneed to be defined fordelivering the textinformation.

Yes, a new FIE wouldneed to be defined fordelivering the textinformation, or the UUSSupplementary Servicecould be used, but this issubject to limitedimplementation. Or useUUS SSs.(for ISDNterminals).

Yes, a new FIE wouldneed to be defined fordelivering the textinformation, or the UUSSupplementary Servicecould be used, but this issubject to limitedimplementation. Or useUUS SSs.(for ISDNterminals).

B22 User-Plane resourcenegotiation andselection.

Multimedia bearercontrol.


ETSI




EN 300 403 (all)(Edition 1) [12]









C1 Interrogation of anetwork terminationpoint for data delivery.

Setting up a data callwith no alerting.

The teleaction teleservicewas designed to provide asimilar capability (but hasa low level ofimplementation). User touser service could also beused for such anexchange of data. NCICSwith a Facility informationelement could also beextended to provide this.

Yes, but limitedimplementation in currentnetworks.



C2 Overriding of the"incoming call barring"supplementaryservice.

Ability to send aSpecial SS overriderequest to the networkfor an SPs serviceuser.

No current capability. Analternative mechanism ofproviding this solutionwould be for thedestination exchange toallow all calls fromspecifically identifiedservice providers, seerequirement A3.

No capability withinDSS.1.



C3 Bypassing of the "calldiversion"supplementaryservice.

Ability to send aSpecial SS overriderequest to the networkfor an SPs serviceuser.

No current capability. No capability withinDSS.1.



C4 Message waitingindication.

Transfer the MWIdata/pulse.

Capabilities provided bythe message waitingindication supplementaryservice.

No support Yes, by the MWISupplementary Service.

Yes, by the MWISupplementary Service.

C5 Application contentsscreening.

Application SLAissues. No additionalinformation required.

No protocol implications.The service profile of theservice provider for agiven interface will providethe basis for meeting thisrequirement.

No capability withinDSS.1. Screening, whererequired, would be doneat application level.



C6 Modification of theterminal capabilities ofthe SP's service user.

Ability to exchangewith the terminalCoded terminal classcapabilities.

No capability withinDSS.1. Modification,where required, would bedone at application level.

No capability withinDSS.1. Modification,where required, would bedone at application level.Or use UUS SSs (forIDSN terminals).

No capability withinDSS.1. Modification,where required, would bedone at application level.Or use UUS SSs.(forIDSN terminals).

ETSI




EN 300 403 (all)(Edition 1) [12]









C7 Modification of thePersonalityDevice/module of theSP's service user.

Ability to exchangewith the User AgentCoded scripts or classcapabilities.

No capability exists or isrequired within DSS.1.Modification, whererequired, would be doneat application level.



C8 Alteration of the profileof the SP's servicesubscriber.

Ability to exchangewith the Profiledatabase Codedscripts or classcapabilities.

Not applicable. Not required withinDSS.1- managementrequirement.

Not required withinDSS.1- managementrequirement.

Not required withinDSS.1- managementrequirement.

C9 Delivery of informationto the SP's serviceuser prior to alerting.

Opening the forwardspeech path, toexchange information.


D1 Changes in thecharging rate of acall - Dynamic.

Exchange chargingrate.

No support in existingprotocol.


D2 Charging mechanismsbetween SP andPNO - Dynamic.

Exchange chargingrate parameters andSLAs.

This requirement could bedealt with entirely bybilateral agreement andbased on changes in thecharacteristics of the call.No explicit call chargeprotocol mechanismexists.

Yes, where the charginginformation needs to beincluded in a signallingmessage, a new FIEwould need to be defined.



D3 Provision of callcharging informationin real time

Exchange anAccounting Record,AOC or CDR atdefined intervals.

AOC No Support No Support No Support

D4 Exchange of chargedetail recordinformation in realtime.

Exchange anAccounting Record,AOC or CDR atdefined intervals.




D5 Billing and Accountingmechanisms betweenSP and PTNO.

Billing and accountinginformation.

Notrequired - managementrequirement.



E1 Event traceabilityrequested by the SP.

Exchanging statistics. No support in existingprotocol.




ETSI




EN 300 403 (all)(Edition 1) [12]









E2 Event traceabilityrequested by the PTN.

Exchanging statistic.s No support in existingprotocol.




E3 Traffic controlcapabilities controlledby the SP.

Exchangeconfiguration data.

No support in currentprotocol.




E4 Traffic controlcontrolled by the PTN

Exchangeconfiguration data.

No support in currentprotocol.




E5 Avoidance of thecyclical routeing of acall.

Passing some datawith the callassociated signalling,e.g. Hop count, ortransaction number.

No mechanism exists,except in the form of rigidcontrol of routeing tables.Mechanism in someprotocols, e.g. QSIG, is touse a transit counter.Where diversion explicitlyoccurs, then a hopcounter does exist, butsupporting other servicesis not an appropriate useof this service or theparameter.


E6 Avoidance of thecyclical routeing ofsignalling or usermessages.

Passing some datawith the usermessage, e.g. Hopcount or transactionnumber.


F1 Reporting of networkevents for measuringthe quality of service.

Exchange QoS SLAconfiguration data.



Notrequired - managementrequirement. There maybe some BICC support in2001.

F2 Reporting of networkevents for the purposeof fault diagnostics.

Exchange fault data. Notrequired - managementrequirement.



F3 Request for eventmonitoring andsubsequent reporting.

Exchange Monitoringconfiguration data.




F4 Electronic ordering ofnetwork managementfunctions.

Exchange SLA data. Notrequired - managementrequirement.



ETSI


8.2 Impact of a service provider's access interface on the NNI between network operators andservice providers

Any NNI that provides a circuit-related service provider interface will need to transfer additional information as well as the existing basic call requirements.

Table 11 shows the results of the analysis of the Service Provider Access Requirements against a Service Provider Access Interface configured using ISUP v1/2/3/4. Supportmechanism and parameters are indicated in table 11.

Table 11: Requirements assessment for SP<>NO circuit-related NNI interface

ISUP Version 1 (1991)ETS 300 121

(Edition 1) [16]


(Edition 1) [13]

ISUP Version 3 (1997)EN 300 356 v3.x.x [14]

ISUP Version 4 (2000)EN 300 356 v4.x.x

[15]No. Requirement Information

to transfer

General Notes onRequirement

SupportMechanism(s) and

Parameters


Parameters


Parameters


ParametersA1 Reception of the calling line

identity - Application of theCLIR supplementary service.

Receive CLI(which may berestricted)including theRestricted flag(if set) for callsfrom or to oneof the SPsservice-subscribers.

Adequate support basedon the use of the Callingparty number and Genericnumber parameters withinthe IAM message.Application of the CLIRsupplementary service isnot specified in ISUP, butmay form a part of manyISUP gatewayimplementations. Noimpact on protocol, only onservice application. ISUPversion 2 onwards.

No Yes: IAM message,Calling Party numberparameter.

Yes: IAM message,Calling Party numberparameter


ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersA2 Presentation of the complete

CLI information to the PTN.Provide to theNetwork theCLI (whichmay havebeen restrictedas in (1)above)together withthe restrictedflag (if set); forcalls from or toone of the SPsservice-subscribers.

Adequate support basedon the use of the Callingparty number and Genericnumber parameters withinthe IAM message. Noimpact on protocol, only onservice application. ISUPversion 2 onwards.


Yes: IAM message,Calling Party numberparameter.


A3 Addition of a calling lineidentity.

Provide to theNetwork a CLI,which may beadditional toany CLI, or thesubstitution oforiginal CLI,with theagreement ofthe SPsservice-subscribers.This applies tocalls destinedto that servicesubscriber.

ISUP version 4 withoriginal CLI of calling userin generic number andidentity of service providerin the calling number withmarking identified by thenetwork. This howeveronly has the capability iftwo number delivery is notbeing used. If existing twonumber delivery is beingused, it will have tooverride one of thenumbers. If this is anunacceptable constraint,the requirement cannot bemet.

No Yes(limited): IAMmessage, Calling Partynumber parameter.ETSI version ofEN 300 356-3 [14] ifpresentation number isreplaced, if nationalregulations permitISUPv2 does notprovide the ability tochange the CgPynumber in conjunctionwith changing therelevant indicator.

Yes(limited): IAMmessage, Calling Partynumber parameter.ETSI version ofEN 300 356-3 [14] ifpresentation number isreplaced, if nationallaw permits. As perISUP v2, ISUP v3doesnot provide the abilityto change the CgPynumber in conjunctionwith changing therelevant indicator.

ISUP v4 meets thisrequirement.completely. Theimplementation issubject to nationalregulations.

A4 Provision of CLI information toan SP-initiated call.

Provide to theNetwork a CLI,provisioned bythe SP. Thisapplies to callsdestined tothat servicesubscriber.

Adequate support basedon the use of the Callingparty number parameterwithin the IAM message.ISUP version 2 onwards.




ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersA5 Relaying of the malicious call

identification data of a receivedcall.

Passing on theCLI (whichmay berestricted)including theRestrictedflag, (if set),for calls fromor to one ofthe SPsservice-subscribers.

Adequate support basedon the use of the Callingparty number and ATPparameters. ISUP version2 onwards. Based onpossible manipulation ofdata of previousrequirements e.g. 3, thenthere may be a loss ofMCID information.




A6 Network LocationDetermination.

NetworkIdentities, e.g.Port Numbers;BS Numbers,etc.

Note: ISUP version 4 callreference includes anetwork identity of theassigning network, but thegenerator of the callreference is notnecessarily the network ofthe SP's customer.

No No No Yes: IAM message,additional callingPartynumber parameter.

A7 Geographic LocationDetermination.

Geodetic data ISUP version 4 includesthe geodetic locationparameter which will fulfilthis requirement.

No No No Yes: IAM message,additional Geodeticdata parameter.

A8 Determination of the terminalcapabilities of the SP's serviceuser.

Codedterminal classcapabilities.

There is no explicit supportfor this function in ISUP;this requirement wouldhave to be implementedeither using an alternativeprotocol or at theapplication level.

No No No No

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersB1 Return speech path connection

from the terminating PTN tothe calling party

Early set-up ofthe backwardconnectionpath. Noadditionalinformationrequired.

Adequate support basedon the assumption that alltransit exchanges(including that supportingthe NNI to the serviceprovider) connect thespeech path in bothdirections, and theoriginating exchangeconnects the speech pathin the backward direction.ISUP version 2 onwards.

No Yes: E.g. Connectbefore Answer.

Yes: E.g. Connectbefore Answer.


B2 Routeing of an originating orincoming call from the PTN tothe SP.

Setting up acall. Noadditionalinformationrequired.

No impact on protocol atservice providers interface.

Yes: No specificmechanism requiredother than use ofstandard ISUPmessages.




B3 Indication of an originating orincoming call from the PTN tothe SP.

NCRrequirementVOID.

VOID- Non-Circuit-RelatedRequirement.

N/a N/a N/a N/a

B4 Routeing of a terminating callfrom the PTN to the SP.

Setting up acall. Noadditionalinformationrequired

No impact on protocol atservice providers interface.





B5 Indication of a terminating callfrom the PTN to the SP.

NCR.requirementVOID.

VOID- Non-Circuit-RelatedRequirement.

N/a N/a N/a N/a

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersB5 Reception of a notification of

the cause of an unsuccessfulcall.

CallUnsuccessfulcause value.

The reason for the failureof the call is carried by aCause parameter withinthe REL message. Furtheractivity by the serviceprovider is provided bycreating a new IAMmessage towards thenetwork provider,containing new callinformation. It has beenassumed that the networkprovider retains noconnection between theoriginal failed call andfuture new call.

Yes: Release anddisconnect messages;Release cause value.




B7 Provision of information for thedestination and routeing of acall.

Provision tothe network ofRoutingNumbers inaddition toDialled(directory)numbers. E.g.Carrierselectioncodes, and(multiple)transit networkselectioncodes.

It is assumed that the useof the Called party numberparameter (ISUP version 2onwards) and the Transitnetwork selectionparameter (ISUP version 3onwards, if supported)provide adequate supportfor this requirement. Theservice provider will needto take account of anyinteraction with numberportability and thepresence of portednumbers.

Yes: Extremely limitedsupport possible inETSI version 1. Carrierselection codes, canbe utilized in CalledParty Number unlessincompatible withnational regulations,but the number ofdigits available in theCdPy number isunlikely to support therequirement.

Yes: Some supportpossible in ETSIversion 2. Carrierselection codes, up tofour digits, can beutilized in Called PartyNumber unlessincompatible withnational regulations.

Yes: Some support inETSI version of EN300 356-3 v3[14],Where signallingbetween ISUP v4endpoints is supportedby transparentparameter deliveryover ISUP v3; theRouting numberparameter, The TransitNetwork Selectionparameter, supportedin ISUP v4 may becarried across ISUPv3for number portability.This is subject tonational regulations.

Yes: Full support ofcarrier and transitnetwork selection canbe achieved in ETSIversion of EN 300 356-3 v4 [15], which givesgreater flexibility for theuse of an extendedCdPy number, theNature of AddressIndicator, and theRouting numberparameter, also usedfor number portability.Implementation of thismechanism will requirean applicationdocument to cover theconventions used forpacking and unpackingthe information.Subject to nationalregulations.

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersB8 Call drop-back. Drop back

indication for acall.

This requirement can besupported by provision ofthe procedures for pivotrouteing and redirection.This is only available inISUP v4 for use in anational context.

No No No Yes: by pivot routeingand redirection.Implementation of pivotrouteing andredirection acrossnetwork boundaries willbe subject to nationalinterconnectionconventions andregulations.

B9 User interaction withoutservice charging of the enduser.

Allowing andEnd to EndExchangebefore startingthe chargingmaybe byproviding twophaseanswering.

ETSI specifications do notspecify the point at whichcharging commences for acall. It is therefore unlikelythat ETSI will createspecifications changing thepoint at which chargingcommences for a call.Most networks commencecharging at the point oftransfer of theCONNECT/ANSWERmessage. ISUP version 4includes theOCCRUI/UTSI procedureswhich could provide amechanism for this userinteraction. There is alsopotential in ISUP for userinteraction prior to thetransfer ofCONNECT/ANSWERmessage, e.g. in the User-to-user supplementaryservice. Some networkscommence charging at anearlier point, at which timeeven the network providermay still be providingservices. NB the userinteraction requirement

Not explicitly supportedin the ISUP Call Model:In-band requirementsare not supported, butmay be possible atnational level,depending on thenational line-chargingand interconnectionpolicies.

Out-of bandrequirements may beimplemented via theUUS SupplementaryService, but in v1,there are somelimitations.

No: In-bandrequirements are notsupported, but may bepossible at nationallevel, depending on thenational line-chargingand interconnectionpolicies.

Out-of bandrequirements may beimplemented via theUUS SupplementaryService.




Out-of bandrequirements may beimplemented via theUUS SupplementaryService, and via theOCCRUI/UTSIprocedures.

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


Parameterscould well be an in-bandrequirement see [2] 6.3.9.

B10 Reception of the originallydialled digits by the SP.

Originallydialled digits

ISUP version 3 containsThe called IN numberparameter which issufficient for this purpose.

No No Yes: via use of thecalled numberparameter.

Yes: via use of thecalled numberparameter.

B11 Reception of the originallydialled digits by the PTN.

Originallydialled digits

ISUP version 3 containsThe called IN numberparameter which issufficient for this purpose.

No No Yes: via use of thecalled numberparameter.

Yes: via use of thecalled numberparameter.

B12 Disconnection of a call inprogress.

SendDisconnect

This requirement can bemet by the existing basiccall sending a RELmessage in both forwardand backward directions.

Yes: Release anddisconnect messages,Release cause value.




B13 Connection of a call to aninteractive voice response unitin the PTN.

Setting up acall to the IVRpossibly byroutingnumber. Noadditionalinformationrequired.

There is no explicit supportneeded in ISUP for thisrequirement, which can befulfilled using standardISUP procedures.

Yes: Yes: Yes: Yes:

B14 Alternate routeing of calls orthe indications of calls toanother "point of presence" ofthe SP.

Setting up acall to the PoPpossibly byroutingnumber. Noadditionalinformationrequired.

This may be achieved byrouteing procedures for outof service routes, whichare outside the scope ofthe signalling protocol.This is a managementrequirement.

N/a N/a N/a N/a

B15 Alternate routeing of a call orthe indication of a call toanother "point of presence" ofthe TNP.

Re-routeing acall to the PoPpossibly byroutingnumber. Noadditionalinformationrequired.

This may be achieved byrouteing procedures for outof service routes, whichare outside the scope ofthe signalling protocol.This is a managementrequirement.

N/a N/a N/a N/a

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersB16 Indication of the disconnection

of a callReceiving theDisconnectmessage

If the SP is in the call path,the requirement is fulfilledas the SP receives theREL message.





B17 Supervision of a dropped-backcall.

Special Dropback indicationfor a call, andcontinuedNCR interface.

There is no support inISUP for this requirement,except via the PivotRouteing and RedirectionProcedures in ISUP v4.

No No No Yes: Available in ISUPv4 for use in a nationalcontext, by pivotrouteing andredirection.Supervision of adropped back call iswritten into ISUP v4but as at the time ofpublication this has notyet been implementedat national level. Seerequirement 17.

B18 Join operation of individuallegs of a call.

Send Joinrequest.

There is no explicit supportwithin ISUP. Thisrequirement will thereforebe met at the applicationlevel.

Yes (limited): this mustbe effective at theapplication level inconjunction with abridging device.




B19 Split operation of individuallegs of a call.

Send Splitrequest.






B20 Multimedia Multiparty callcontrol.

Multimedia callcontrol.


Yes (limited):narrowband multimediamultiparty call controlsupport available, butthis must be effectivein conjunction with abridging device.




ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersB21 User Interaction for Text

Delivery.Exchangeuse/text data.

No explicit solution inISUP. Out-of bandrequirements may beimplemented via the UUSSupplementary Service, ormay require a differentinterconnect protocol. In-band solutions may bepossible, using ISUP as abearer channel only.Additional out-bandsolutions are available inISUP v4.

No: Time-limited Out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.UUS is limited in ISUPv1.

In-band solutions maybe possible, usingISUP as a bearerchannel only.

No: Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.


No: Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.


No: Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.Or these may beimplemented via theOCCRUI/UTSIprocedures dependingon terminalcapabilities.


B22 User-Plane resourcenegotiation and selection.

Multimediabearer control.

No support is availablewithin ISUP.

No No No No

C1 Interrogation of a networktermination point for datadelivery.

Setting up adata call withno alerting.

No explicit solution inISUP. Out-of bandrequirements may beimplemented via the UUSSupplementary Service, ormay require a differentinterconnect protocol. In-band solutions may bepossible, using ISUP as abearer channel only.Additional out-bandsolutions are available inISUP v4.

No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.UUS is limited in ISUPv1.

No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.


No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.Non time-limited out-ofband requirementsmay be implementedvia the OCCRUI/UTSIprocedures dependingon terminalcapabilities.

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersC2 Overriding of the "incoming call

barring" supplementaryservice.

Ability to senda Special SSoverriderequest to thenetwork for anSPs serviceuser.

No current capability. Theremote control service hassome of the capabilities,but this is provided onbehalf of the served uservia DSS.1. This could beimplemented via a SCCPservice. Call Barring is aterminating switch/line cardsupplementary service.

No No No No

C3 Bypassing of the "calldiversion" supplementaryservice.

Ability to senda Special SSoverriderequest to thenetwork for anSPs serviceuser.

This is supported by ISUPversion 3, using theparameters andprocedures specified inQ.1600.

No No Yes: Using theparameters andprocedures specified inQ.1600 mapping INAPCS-1 to ISUPv3.

Yes: Using theparameters andprocedures specified inQ.1600 mapping INAPCS-1 to ISUPv3.

C4 Message waiting indication. Transfer theMWIdata/pulse.

Capabilities provided bythe message waitingindication supplementaryservice. Note that this isnot a circuit relatedservice. Implementation ofthis SCCP-based servicebetween network providerand service provider willrequire bilateral agreementon global title translationand SCCP. SeeEN 300 650 [30] for MWIservice description.

No support within basicISUP: needs to beimplemented as anSCCP-based service.




C5 Application contents screening. ApplicationSLA issues.No additionalinformationrequired.

No impact on protocol,only on service application.ISUP version 2 onwards.

Not required: thisrequirement is met atthe application level.




ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersC6 Modification of the terminal

capabilities of the SP's serviceuser.

Ability toexchange withthe terminalCodedterminal classcapabilities.

No Explicit Support inISUP.




C7 Modification of the PersonalityDevice/ module of the SP'sservice user.

Ability toexchange withthe UserAgent Codedscripts or classcapabilities.

Not applicable. No Explicit Support inISUP.




C8 Alteration of the profile of theSP's service subscriber.

Ability toexchange withthe ProfiledatabaseCoded scriptsor classcapabilities.

Not applicable. No Explicit Support inISUP.




C9 Delivery of information to theSP's service user prior toalerting.

Opening theforwardspeech path,to exchangeinformation.




No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.Or these may beimplemented via theOCCRUI/UTSIprocedures dependingon terminalcapabilities.

D1 Changes in the charging rateof a call - Dynamic.

Exchangecharging rate.

Capabilities ofES 201 296 [25] (ISUPSupport of charging) [25]can be used in a nationalcontext whereimplemented. Otherwisethe PTN will need todetermine this by numberanalysis.

No Yes: ES 201 296 [25]can be used but this isvery limited in nationalimplementation.

Yes: ES 201 296 [25]can be used but this isvery limited in nationalimplementation.

Yes: ES 201 296 [25]can be used but this isvery limited in nationalimplementation.

ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersD2 Charging mechanisms

between SP and PNO -Dynamic.

Exchangecharging rateparametersand SLAs.

Assuming this is based onoffline exchange ofinformation, then does notform part of the ISUPprotocol.

Yes, where thecharging informationneeds to be included ina signalling message,a new mechanismwithin ISUP wouldneed to be defined.




D3 Provision of call charginginformation in real time.

Exchange anAccountingRecord, AOCor CDR atdefinedintervals.

No explicit support withinISUP.

No No No No

D4 Exchange of charge detailrecord information in real time.

Exchange anAccountingRecord, AOCor CDR atdefinedintervals.

Capabilities ofES 201 296 [25] (ISUPSupport of charging) canbe used in a nationalcontext whereimplemented, however thisdoes not meet all theelements of therequirement.

No No No No

D5 Billing and Accountingmechanisms between SP andPNO.

Void Void Void Void

E1 Event traceability requested bythe SP.

Exchangingstatistics.

No support in existingprotocol. A "global" callreference can besupported in ISUPversion 4.

No No No Yes (limited):Correlation parameter.

E2 Event traceability requested bythe PTN.

Exchangingstatistics.

No support in existingprotocol. A "global" callreference can besupported in ISUPversion 4.


E3 Traffic control capabilitiescontrolled by the SP.

Exchangeconfigurationdata.

Automatic congestioncontrol provided in ISUPversion 2 onwards will fulfilthis requirement.

No Yes: Automaticcongestion controlprocedure.

Yes: Automaticcongestion controlprocedure.


ETSI



(Edition 1) [16]


(Edition 1) [13]




to transfer



Parameters


Parameters


Parameters


ParametersE4 Traffic control capabilities

controlled by the PTN.Exchangeconfigurationdata.

Automatic congestioncontrol provided in ISUPversion 2 onwards will fulfilthis requirement.

No Yes: Automaticcongestion controlprocedure.



E5 Avoidance of the cyclicalrouteing of a call.

Passing somedata with thecall associatedsignalling, e.g.Hop count ortransactionnumber.

ISUP version 3 supports ahop counter parameter thatcan be used to fulfil thisfunction. Use of thisprocedure is optional.

No No Yes: Hop Countparameter inEN 300 356 [14] v3.

Yes: Hop Countparameter inEN 300 356 [15] v4.

E6 Avoidance of the cyclicalrouteing of signalling or usermessages.

Passing somedata with theuser message,e.g. Hop countor transactionnumber.

No No Yes: via Hop Countparameter inEN 300 356 v3 [14].

Yes: via Hop Countparameter inEN 300 356 v4 [15].

F1 Reporting of network eventsfor measuring the quality ofservice.

ExchangeQoS SLAconfigurationdata.

N/a: Managementrequirement.




F2 Reporting of network eventsfor the purpose of faultdiagnostics.

Exchange faultdata.





F3 Request for event monitoringand subsequent reporting.

ExchangeMonitoringconfigurationdata.

Where CR interface isused, many events arereported through thenormal signallingmessages, but setting upthe preconditions is aseparate managementrequirement.





F4 Electronic ordering of networkmanagement functions.

Exchange SLAdata.





ETSI


8.3 IN Protocol and API AssessmentTable 12 shows the results of the analysis of the Service Provider Access Requirements against a Service Provider Access Interface configured using INAP CS-1/2/3, CAMELPhase 1/2/3, OPEN INAP CS-2 and CS-3 and ETSI Open Service Access API. Support mechanism and parameters are indicated in table 12.

Table 12: Requirements assessment for SP<>NO NNI interface

INAP CS-1/2/3, - allreference points;

SCF-SSF, SCF-SCF(CS-2), CUSF (CS-2)

and SCF-SRF

CAMEL Phase 1/2/3,all reference points

OPEN-INAP CS-2subset, SCF-SCF,CUSF; OPEN-INAP

CS-3 subset;SCF-SSF and

SCF-SRF.

ETSI Open ServiceAccess API

No. Requirement Notes SupportMechanism(s)

and Parameters,

Support Mechanism(s) and Parameters,



A1 Reception of the calling line identity - Application ofthe CLIR supplementary service.

initialDP, (CS-1 andabove)

initialDP (Phase 1 andabove)

initialDP. reportNotification().

A2 Presentation of the complete CLI information to thePTN.

initiateCallAttempt,connect (CS-1 andabove)

initiateCallAttempt notsupportedconnect can alter CLIparameters e.g. therestricted flags, butcannot alter the CLIitself. (Phase 1 andabove)

initiateCallAttempt,connect.

createCallLeg,createAndRouteCallLegReq, routeReq.

A3 Addition of a calling line identity. initiateCallAttempt,connect (CS-1 andabove)

initiateCallAttempt notsupportedconnect with Genericnumbers (Phase 1 andabove)

initiateCallAttempt,connect

createCallLeg,createAndRouteCallLegReq, routeReq.

A4 Provision of CLI information to an SP-initiated call. initiateCallAttempt(CS-1 and above)

Not supported initiateCallAttempt createCallLeg,createAndRouteCallLegReq, routeReq.

A5 Relaying of the malicious call identification data of areceived call.

connect (CS-1 andabove)

Not supported connect createCallLeg,createAndRouteCallLegReq, routeReq.

A6 Network Location Determination. initialDP (CS-2 andabove)

initialDP (Phase 1 andabove)

initialDP reportNotification().

A7 Geographic Location Determination. initialDP (CS-3) initialDP (Phase 1 andabove)

initialDP reportNotification().

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




A8 Determination of the terminal capabilities of the SP'sservice user.

initialDP{uSIInformation (CS-2 and above),terminalType (CS-1and above)} (scenario2);

reportUTSI (CS-2 andabove), sendSTUI(CS-2 and above),requestReportUTSI(CS-2 and above:scenario 1 and 3)

Not supported

Note: Supported byUSSD.

initialDP{uSIInformation, terminalType}(scenario 2);

reportUTSI ,sendSTUI,requestReportUTSI(scenario 1 and 3)

getTerminalCapabilities.

B1 Return speech path connection from the terminatingPTN to the calling party.

No impact of protocol,return speech path ishandled within theuser-plane signallingthrough asymmetricalswitch-through. Ifblocked, would need toconnect to a SRF.



No impact of protocol,return speech path ishandled within theuser-plane signallingthrough asymmetricalswitch-through. Ifblocked, would needto connect to a SRF.

B2 Routeing of an originating or incoming call from thePTN to the SP.

connect, (CS-1 andabove)

Originating call andterminating call in theGMSC: connect(Phase 1 and above)

connect createCallLeg,createAndRouteCallLegReq, routeReq

B3 Indication of an originating or incoming call from thePTN to the SP.

initialDP (CS-1 andabove)

Originating call andterminating call in theGMSC: intialDP(Phase 1 and above)

initialDP ReportNotification,

B4 Routeing of a terminating call from the PTN to theSP.

connect (CS-1 andabove)

Terminating call in theVMSC: connect(Phase 3)

connect createCallLeg,createAndRouteCallLegReq, routeReq

B5 Indication of a terminating call from the PTN to theSP.

initialDP (CS-1 andabove)

Terminating call in theVMSC: IntialDP(Phase 3)

initialDP reportNotification()

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




B6 Reception of a notification of the cause of anunsuccessful call.

initialDP,requestReportBCSMEvent (CS-1 and above)eventReportBCSM(CS-1 and above)

initialDP(Phase 3)requestReportBCSMEvent (Phase 2 (GMSConly) and above (alsoVMSC))eventReportBCSM(Phase 2 (GMSC only)and above (alsoVMSC))

initialDP,requestReportBCSMEventeventReportBCSM

reportNotificationeventReportRes

B7 Provision of information for the destination androuteing of a call.

connect,initiateCallAttempt(CS-1 and above)

connect (Phase 1 andabove)initiateCallAttempt notsupported

connect,initiateCallAttempt

createCallLeg,createAndRouteCallLegReq, routeReq

B8 Call drop-back. VOID VOID VOID VOIDB9 User interaction without service charging of the end

user.connectToResource,establishTemporaryConnection (CS-1 andabove)

connectToResource,establishTemporaryConnection (Phase 2 andabove)

connectToResource,establishTemporaryConnection

createUICall

B10 Reception of the originally dialled digits by the SP. initialDP-if from originatingexchange (CS-1 andabove)

initialDP-only at originatingVMSC (Phase 1 andabove)

initialDP-if from originatingexchange

reportNotification()

B11 Reception of the originally dialled digits by the PTN. connect (CS-1 andabove)

In the connectPTNTerm may notreceive BCD dialleddigits as DNr.

connect

B12 Disconnection of a call in progress. releaseCall, (CS-1 andabove) disconnectLeg(CS-2 and above)

releaseCall (Phase 1and above)disconnectLeg notsupported

releaseCall,disconnectLeg

release(IpMultiPartyCall);release (IpCallLeg)

B13 Connection of a call to an interactive voice responseunit in the PTN.

connectToResource,(CS-1 and above)establishTemporaryConnection (CS-1 andabove)

connectToResource,(Phase 2 and above)establishTemporaryConnection (Phase 2 andabove)

connectToResource,establishTemporaryConnection

createUICall

B14 Alternate routeing of calls or the indications of callsto another 'point of presence' of the SP.

Handled at CCF level Handled at CCF level Handled at CCF level Handled by theunderlaying network

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




B15 Alternate routeing of a call or the indication of a callto another 'point of presence' of the PTN.

Handled at CCF level Handled at CCF level Handled at CCF level Handled by theunderlaying network

B16 Indication of the disconnection of a call. requestReportBCSMEvent (CS-1 and above)eventReportBCSM,(CS-1 and above)initialDP (CS-1 andabove)

requestReportBCSMEvent (Phase 1 andabove)eventReportBCSM,(Phase 1 and above)initialDP (notsupported)

requestReportBCSMEventeventReportBCSM,initialDP

eventReportReq,reportNotification

B17 Supervision of a dropped-back call. VOIDB18 Join operation of individual legs of a call. moveLeg,

mergeCallSegments(CS-2 and above)

Not supported moveLeg,mergeCallSegments

moveCallLeg,mergeSubconference

B19 Split operation of individual legs of a call. splitLeg, moveLeg(CS-2 and above)

Not supported splitLeg, moveLeg splitSubConference,moveCallLeg

B20 Multimedia Multiparty call control. No support formultimedia- formultiparty support seerequirements B18 andB19, supported byCS-2 and above.

Not supported No support formultimedia- formultiparty support seerequirements B18 andB19

Supported by thefollowing services:MultiParty Call ControlService;MultiMedia CallControl Service;Conference CallControl Service(see servicedescription. foravailable methods -ES 201 915-4 [22]

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




B21 User Interaction for Text Delivery. connect (CS-2 andabove),continueWithArgument(CS-2 andabove)connnectToResource (CS-1 andabove),playAnnouncement,promptAndCollectUperInformation,PromptAndReceiveMessageestablishTemporaryConnection (CS-1 andabove)Call related supportonly.

Supported by USSD connect,continueWithArgumentconnnectToResource,playAnnouncement,promptAndCollectUserInformation,promptAndReceiveMessageestablishTemporaryConnectionCall related supportonly.

createUICall, createUI,sendInfoReq,sendInfoRes,recordMessageReq,recordMessageRes

B22 User-Plane resource negotiation and selection. No support in anyprotocol

Not supported No support in anyprotocol

Monitoring andacceptance ofunder-laying networkresource negotiationvia;mediaChannelMonitorReq,mediaChannelMonitorRes,mediaChannelAllow,getMediaChannels,close

C1 Interrogation of a network termination point for data.delivery

reportUTSI (CS-2 andabove), sendSTUI(CS-2 and above),requestReportUTSI(CS-2 and above)

Not supported reportUTSI ,sendSTUI,requestReportUTSI

createUICall,sendInfoReq,sendInfoRes

C2 Overriding of the 'incoming call barring'supplementary service.

continueWithArgument(with SIITwo) , connect(with SIITwo) (CS-2

Not supported continueWithArgument(with SIITwo) , connect(with SIITwo)

Not provided

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




and above)C3 Bypassing of the 'call diversion' supplementary

service.continueWithArgument(with SIITwo),connect(with SIITwo)(CS-2 and above)

continueWithArgument(with SIITwo; Phase 3),connect (with SIITwo)(Phase 3)

continueWithArgument(with SIITwo),connect(with SIITwo)

Not provided.

C4 Message waiting indication. sendSTUI; (CS-2 andabove) or;

connectToResource,(CS-1 and above)establishTemporaryConnection, (CS-1 andabove)playAnnouncement(CS-1 and above)

sendSTUI notsupported

connectToResource,(Phase 2 and above)establishTemporaryConnection, (Phase 2 andabove)playAnnouncement(Phase 2 and above)

NOTE: Supportedby USSD.

sendSTUI; or;connectToResource,establishTemporaryConnection,playAnnouncement

createUICall,sendInfoReq,sendInfoRes

C5 Application contents screening. Protocol Independent Protocol Independent= not supported byCAMEL protocol

Protocol Independent Depending on theunder-laying network

C6 Modification of the terminal capabilities of the SP'sservice user.

sendSTUI (CUSF)(CS-2 and above)

Not supported


sendSTUI (CUSF) createUI,sendInfoReq,

C7 Modification of the Personality Device/ module ofthe SP's service user.

sendSTUI (CUSF)(CS-2 and above)

Not supported


sendSTUI (CUSF) createUI,sendInfoReq

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




C8 Alteration of the profile of the SP's servicesubscriber:

manageTriggerData(CS-2 and above),setServiceProfile (CS-3),createOrRemoveTriggerData (CS-3)sendSTUI (CUSF)(CS-2 and above)

manageTriggerData isnot supported,Camel ServiceSubscriptionInformation will bedownloaded by theinsertSubscriberDataMAP message fromHLR to VMSC (phase1 and above), and bythe acknowledgementfrom HLR to GMSC ofthe MAPsendRoutingInformation message (phase 1and above) . CamelService SubscriptionInformation in the HLRcan be enabled ordisabled by theanyTimeModificationMAP message to theHLR (Phase 3)

manageTriggerDatasetServiceProfilecreateOrRemoveTriggerDatasendSTUI (CUSF)

createUI,sendInfoReq

C9 Delivery of information to the SP's service user priorto alerting.

setServiceProfile (CS-3), SendSTUI (CUSF)(CS-2 and above)

Supported by USSD setServiceProfilesendSTUI (CUSF)

createUI,sendInfoReq

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




D1 Changes in the charging rate of a call - Dynamic. furnishChargingInformation and/orsendChargingInformation (CS-1 and above)

furnishChargingInformation. (Phase 2 andabove)

[sendChargingInformation can also be used,but is notrecommended - Phase2 and above)

Any tariff switch mayinfluencepost-processing.

furnishChargingInformation and/orsendChargingInformation

setChargePlan

D2 Charging mechanisms between SP and PTNO -Dynamic.

Note:parameterswill needspecificagreement ineachSP/PTNcombination.

For the PTN to chargethe SP:furnishChargingInformation + applyCharging,andapplyChargingReport(CS1 and above)

For SP to charge thePTN:furnishChargingInformation (CS1 and above).

For the PTN to chargethe SP:furnishChargingInformation + applyCharging,andapplyChargingReport(Phase 2 and above)

For SP to charge thePTN:furnishChargingInformation (Phase 2 andabove).

For the PTN to chargethe SP:furnishChargingInformation + applyCharging, andapplyChargingReport

For SP to charge thePTN:furnishChargingInformation.

Not supported

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




D3 Provision of call charging information in real time. applyCharging,sendChargingInformation (for tariff switch)applyChargingReport(CS-1 and above)

requestNotificationChargingEvent,eventNotifiactionCharging (CS-2 and above)

applyCharging,sendChargingInformation (for tariff switch),applyChargingReport(Phase 2 and above)will indicate the usedtime, no charging unitsare indicated. The timeof answer and of tariffswitches (provided bythe gsmSCF) will beconsidered in theduration informationprovided.

applyCharging,sendChargingInformation,applyChargingReport

requestNotificationChargingEventeventNotifiactionCharging,

setAdviceOfCharge,superviseReq andsuperviseRes(IpMultiPartyCall and IpCallLeg)

D4 Exchange of charge detail record information in realtime.

For the PTN to chargethe SP:applyCharging,applyChargingReport(CS-1 and above)

eventNotificationCharging,requestNotificationChargingEvent (CS-2 andabove)

For SP to charge thePTN:furnishChargingInformation (CS1 and above).

For the PTN to chargethe SP:applyCharging,applyChargingReport(Phase 2 and above)will indicate the usedtime.furnishChargingInformation will providecharging information(Phase 2 and above)

For SP to charge thePTN:furnishChargingInformation will providecharging information(Phase 2 and above)

For the PTN to chargethe SP:applyCharging,applyChargingReport

eventNotificationCharging,requestNotificationChargingEvent

For SP to charge thePTN:FurnishChargingInformation

SetAdviceOfCharge,superviseReq andsuperviseRes(IpMultiPartyCall and IpCallLeg)

D5 Billing and Accounting mechanisms between SPand PNO.

N/a N/a N/a N/a

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




E1 Event traceability requested by the SP. requestReportBCSMEvent (CS-1 and above)eventReportBCSM,(CS-1 and above)callInformationRequest,callInformationReport(CS-1 and above),

Higher phases willresult in more detailsfor the specific eventsand more events.requestReportBCSMEvent (Phase 1 andabove)eventReportBCSM,(Phase 1 and above)

callInformationRequest,callInformationReport(Phase 2 and above),

requestReportBCSMEventeventReportBCSM,callInformationRequest, callInformationReport

eventReportReq,eventReportRes,getInfoReq andgetInfoRes(IpMultiPartyCall andIpCallLeg),

E2 Event traceability requested by the PTN. not supported handledby networkmanagement

Not supported not supported handledby networkmanagement

Not supported

E3 Traffic control capabilities controlled by the SP. activateServiceFilteringandserviceFilteringResponse (CS-1 and above)

Not supported activateServiceFilteringandserviceFilteringResponse

setCallLoadControl,callOverloadEncountered,callOverloadCeased

E4 Traffic control capabilities controlled by the PTN. callGap (CS-1 andabove)

callGap (Phase 3) callGap setCallLoadControl,callOverloadEncountered,callOverloadCeased

E5 Avoidance of the cyclical routeing of a call. initialDP contains theloop counter of theredirectionInformation(CS-1-encoding) andRedirecting number(ISUP-encoding) CS1and above)

initialDP contains theloop counter of theredirectionInformation(CS-1-encoding) andRedirecting number(ISUP-encoding)

initialDP contains theloop counter of theredirectionInformation(CS-1-encoding) andRedirecting number(ISUP-encoding)

Not supported

E6 Avoidance of the cyclical routeing of signalling oruser messages.

Not supported Not supported , nocyclic routing ofCAMEL signalling orUSSD messages

Not supported Not supported

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




F1 Reporting of network events for measuring thequality of service.

initialDP + parameterextension (no supportin any protocol),requestReportBCSMEvent (CS-1 and above)eventReportBCSM,(CS-1 and above)callInformationReport(CS-1 and above),applyChargingReport(CS-1 and above),+ parameter extensionneeded (no support, inany protocol) Callrelated, no agreedQoS classes.

no QoSrequestReportBCSMEvent (Phase-1 andabove)eventReportBCSM,(Phase-1 and above)callInformationReport(Phase-2 and above),applyChargingReport(Phase-2 and above)+ parameter extensionneeded (no support, inany protocol) Callrelated, no agreedQoS classes.

initialDP + parameterextension (no supportin any protocol),requestReportBCSMEventeventReportBCSM,callInformationReportapplyChargingReport+ parameter extensionneeded (no support, inany protocol) Callrelated, no agreedQoS classes.

F2 Reporting of network events for the purpose of faultdiagnostics.

requestReportBCSMEvent (CS-1 and above)eventReportBCSM(CS-1 and above),activityTest (CS-1 andabove), entityReleased(CS-2 and above)

requestReportBCSMEvent (Phase 1 andabove)eventReportBCSM(Phase 1 and above),activityTest (Phase 2and above), noentityReleased

requestReportBCSMEventeventReportBCSMactivityTest ,entityReleased

eventReportReq,eventReportRes,

ETSI




and SCF-SRF




SCF-SRF.



and Parameters,




F3 Request for event monitoring and subsequentreporting.

CallInformationRequest, callInformationReport(CS-1 and above),requestReportBCSMEvent,eventReportBCSM(CS-1 and above): callrelated;statusReport,requestEveryStatusChangeReport,requestFirstStatusMatchReport,requestCurrentStatusReport: CS-3applyCharging andapplyChargingReportfor call supervision(CS-1 and above)

callInformationRequestCallInformationReport(Phas-2 and above),requestReportBCSMEvent,eventReportBCSM(Phase -1 and above):call related;applyCharging andapplyChargingReportfor call supervision(Phase 2 and above)

CallInformationRequest, callInformationReport,requestReportBCSMEvent,eventReportBCSM:call related;statusReport,requestEveryStatusChangeReport,requestFirstStatusMatchReport,requestCurrentStatusReportapplyCharging andapplyChargingReportfor call supervision:

eventReportReq,eventReportRes,

F4 Electronic ordering of network managementfunctions.

VOID VOID VOID

ETSI


8.4 Telephony IP Harmonization AspectsTIPHON release 3 supports basic call and hence may support the SPAR requirements in EG 201 722 [2] andEG 201 807 [3], however no explicit support has been given to open the service provision to service control.

The capabilities described by TC SPAN for advanced telephony services match the service capabilities define by EPTIPHON. EP TIPHON has not explicitly defined a Service Provider Access Interface (SPAI), but it is believed thatshould such an interface to a telecommunications network be provided to meet the requirements contained inEG 201 722 [2], EG 201 807 [3] and EG 201 897 [4], this would also be consistent with the TIPHON servicearchitecture.

In addition, TIPHON Release 4 and beyond may include an SPAI in the relevant TIPHON deliverables. In any case, EPTIPHON maps the service requirements through service capabilities onto the network in a technology independent way.Hence, circuit switched and packet network implementations support the TIPHON service requirements.

Other User-to-User IP protocols for the support of multimedia are under development, e.g. H.323 (see bibliography),SIP; these protocols are considered outside the scope of the present document and the analysis.

Other IP protocols for the support of multimedia, e.g. between gateways and gateway controllers, are underdevelopment, e.g. H.248/Megaco (see bibliography); these protocols are considered outside the scope of the presentdocument and the analysis.

ETSI


9 Indirect Service Provider access interface (I-SPAI)This clause analyses the impact of a service provider's access interface where the SPAI is not directly connected to the local network where the SP-Service user is connected(i.e. the originating or terminating network), but instead is connected via an intermediate PTN. This results in a reliance on the protocol used at the NNI between networkproviders. The following table analyses the capabilities of ISUP used at the NNI for its potential impact or restriction on the capabilities that the Service Provider can delivererto its service user.

SP

PTN Intermediate PTN

SP Access via Transit PTN

PTN

NNI NNISPAI

Figure 10: Indirect Service Provider Access via a Transit PTN.

For a Service Provider connected via a Transit PTN, the NNI will need to transfer additional information to the basic call requirements. (Requirements assessment for NNIinterface between networks in the "call path" to relay information required as a result of circuit-related or non-circuit-related SP interfaces.) This table is to be used to indicatewhether or not the requirement can be fulfilled with a "perfect" Indirect SPAI but with the relevant version of ISUP in the "call path" between the Intermediate PTN and theoriginating or terminating network as appropriate.

NOTE: The least capable network in the call path will limit any relayed support of Supplementary Services.

ETSI


Table 13: Requirements assessment for PTN<>NO PTN NNI interface.

ISUP Version 1(1991)

ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]

No. Requirement Informationto transfer



Parameters


Parameters


Parameters


ParametersA1 Reception of the calling

line identity -Application of the CLIRsupplementary service

Passing theReceived CLIor CLIsthrough thenetwork forcalls from orto one of theSPs service-subscribers,together withany"restricted"CLI flags leftunaltered.

Adequate supportbased on the use ofthe Calling partynumber and Genericnumber parameterswithin the IAMmessage. Applicationof the CLIRsupplementary serviceis not specified inISUP, but may form apart of many ISUPgatewayimplementations. Noimpact on protocol,only on serviceapplication. ISUPversion 2 onwards.

No Yes: IAM message,Calling Party numberparameter



A2 Presentation of thecomplete CLIinformation to the PTN

Passing theSP-ProvidedCLI or CLIsthrough thenetwork forcalls from orto one of theSPs service-subscribers,together withany"restricted"CLI flags leftunaltered.

Adequate supportbased on the use ofthe Calling partynumber and Genericnumber parameterswithin the IAMmessage. No impacton protocol, only onservice application.ISUP version 2onwards.




ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersA3 Addition or substitution

of a calling line identityAs per #A2above.

ISUP version 4 withoriginal CLI of callinguser in genericnumber and identity ofservice provider in thecalling number withmarking identified bythe network. Thishowever only has thecapability if twonumber delivery is notbeing used. If existingtwo number delivery isbeing used, it will haveto override one of thenumbers. If this is anunacceptableconstraint, therequirement cannot bemet.

No Yes(limited): IAMmessage, CallingParty numberparameter. ETSIversion ofEN 300 356-3 [13] ifpresentation numberis replaced, if nationalregulations permit.

ISUP v2 does notprovide the ability tochange the CgPynumber in conjunctionwith changing therelevant indicator.

Yes(limited): IAMmessage, CallingParty numberparameter. ETSIversion ofEN 300 356-3 [14] ifpresentation numberis replaced, if nationalregulations permit.

As per ISUP v2, ISUPv3 does not providethe ability to changethe CgPy number inconjunction withchanging the relevantindicator.

Yes: ISUP v4 meetsthis req. completely

A4 Provision of CLIinformation to anSP-initiated call

As per#A2above.

Adequate supportbased on the use ofthe Calling partynumber parameterwithin the IAMmessage. ISUPversion 2 onwards.




A5 Relaying of themalicious callidentification data of areceived call

Passing onthe CLI (whichmay berestricted)including theRestrictedflag, (if set),for calls fromor to one ofthe SPsservice-subscribers

Adequate supportbased on the use ofthe Calling partynumber and ATPparameters. ISUPversion 2 onwards.Based on possiblemanipulation of data ofprevious requirementse.g. A3, then theremay be a loss of MCIDinformation.




ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersA6 Network Location

DeterminationPassing theprovidedNetworkIdentities, e.g.Port Numbers;BS Numbers,etc.

Note that theproposed ISUPversion 4 callreference includes anetwork identity of theassigning network, butthe generator of thecall reference is notnecessarily thenetwork of the SP'scustomer.

No No No Yes: IAM message,additional CallingParty numberparameter.EN 300 356-3 v4 [15]

A7 Geographic LocationDetermination

Passing theprovidedGeodetic data

ISUP version 4includes the geodeticlocation parameterwhich will fulfil thisrequirement.

No No No Yes: IAM message,additional Geodeticdata parameter.EN 300 356-3 v4 [15]

A8 Determination of theterminal capabilities ofthe SP's service user

Passing theprovidedCodedterminal classcapabilities

There is no explicitsupport for thisfunction in ISUP; thisrequirement wouldhave to beimplemented eitherusing an alternativeprotocol or at theapplication level.

No support withinISUP, but it may bepossible as a TCbased service usingSCCP routing withinSS#7.




B1 Return speech pathconnection from theterminating PTN to thecalling party

Allowing Earlyset-up of thebackwardconnectionpath. Noadditionalinformationrequired.

Adequate supportbased on theassumption that alltransit exchanges(including thatsupporting the NNI tothe service provider)connect the speechpath in both directions,and the originatingexchange connectsthe speech path in thebackward direction.ISUP version 2onwards.

No Yes: E.g. Connectbefore Answer.



ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersB2 Routeing of an

originating or incomingcall from the PTN to theSP

Allowing theSetting up of acall. Noadditionalinformationrequired.

No impact on protocolat service providersinterface.





B3 Indication of anoriginating or incomingcall from the PTN to theSP

VOID VOID- Non-Circuit-Related Requirement.

N/A N/A N/A N/A

B4 Routeing of aterminating call from thePTN to the SP

Allowing theSetting up of acall. Noadditionalinformationrequired

No impact on protocolat service providersinterface.





B5 Indication of aterminating call from thePTN to the SP

VOID VOID- Non-Circuit-Related Requirement.

N/A N/A N/A N/A

B6 Reception of anotification of the causeof an unsuccessful call

Passing theCallUnsuccessfulcause valuethrough thenetwork.

No impact on protocolbetween networks inthe call path. ISUP istransparent in thisrespect.

Yes Yes Yes Yes

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersB7 Provision of information

for the destination androuteing of a call

Passing theProvidedRoutingNumbers inaddition toDialled(directory)numbers. E.g.Carrierselectioncodes, and(multiple)transitnetworkselectioncodes.

It is assumed that theuse of the Called partynumber parameter(ISUP version 2onwards) and theTransit networkselection parameter(ISUP version 3onwards, if supported)provide adequatesupport for thisrequirement. Theservice provider willneed to take accountof any interaction withnumber portability andthe presence of portednumbers.

Yes: Extremely limitedsupport possible inETSI version 1.Carrier selectioncodes, can be utilizedin Called PartyNumber unlessincompatible withnational regulations,but the number ofdigits available in theCdPy number isunlikely to support therequirement.

Yes: Some supportpossible in ETSIversion 2. Carrierselection codes, up tofour digits, can beutilized in Called PartyNumber unlessincompatible withnational regulations.

Yes: Some support inETSI version 3, wheresignalling betweenISUP v4 endpoints issupported bytransparent parameterdelivery over ISUP v3;the Routing numberparameter, the TransitNetwork Selectionparameter, supportedin ISUP v4 may becarried across ISUPv3for number portability.This is subject tonational regulations.

Yes: Full support ofcarrier and transitnetwork selection canbe achieved in ETSIversion of EN 300356-3 v4 [15], whichgives greater flexibilityfor the use of anextended CdPynumber, the Nature ofAddress Indicator, andthe Routing numberparameter, also usedfor number portability.Implementation of thismechanism willrequire an applicationdocument to cover theconventions used forpacking andunpacking theinformation. Subject tonational regulations.

B8 Call drop-back Drop backindication fora call, whereroute isoptimizedacrossnetworkboundaries.

This requirement canbe supported byprovision of theprocedures for pivotrouteing andredirection. This isonly available in ISUPv4 for use in a nationalcontext. Transparentsupport of theseprocedures across athird party network inthe call path isdependent on the SLAbetween the networks.

Yes as long as pivotalrouting, ISUP v4, isavailable within thePTN(s) that consent todo, or get involved in,the dropback. Theother parties in the callcontrol-signalling pathneed only support anearlier version ofISUP.



Yes. For the networksthat are involved in thecall path other thanthose between the SP(pivot direction point)and the PTN whichperforms theredirection, there is notransparency issue inany version of ISUP.

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersB9 User interaction without

service charging of theend user

Allowing anEnd-to-Endexchange ofdata beforethe start ofcharging, e.g.by providingtwo phaseanswering, orUUS.

ETSI specifications donot specify the point atwhich chargingcommences for a call.It is therefore unlikelythat ETSI will createspecificationschanging the point atwhich chargingcommences for a call.Most networkscommence charging atthe point of transfer oftheCONNECT/ANSWERmessage. ISUPversion 4 includes theOCCRUI/UTSIprocedures whichcould provide amechanism for thisuser interaction. Thereis also potential inISUP for userinteraction prior to thetransfer ofCONNECT/ANSWERmessage, e.g. in theUser-to-usersupplementaryservice. Somenetworks commencecharging at an earlierpoint, at which timeeven the networkprovider may still beproviding services. NBthe user interactionrequirement could wellbe an in-band

No: In-bandrequirements are notsupported, but may bepossible at nationallevel, depending onthe nationalline-charging andinterconnectionpolicies.

Out-of bandrequirements may beimplemented via theUUS SupplementaryService, but in v1,there are somelimitations. AnyRelayed support of SSwill be limited by theleast capable networkin the call path. Seenote.






Out-of bandrequirements may beimplemented via theUUS SupplementaryService, and via theOCCRUI/UTSIprocedures.*

*Provided that theendpoints are ISUPv4capable and links inthe call path areISUPv2 or above.

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


Parametersrequirement see [2]6.3.9 ; the two-phaseanswer is notguaranteed to workacross the networkboundary.

B10 Reception of theoriginally dialled digitsby the SP

RelayingOriginallydialled digits

ISUP version 3contains The called INnumber parameterwhich is sufficient forthis purpose.

No No Yes: via use of thecalled IN numberparameter.

Yes: via use of thecalled IN numberparameter.

B11 Reception of theoriginally dialled digitsby the PTN

RelayingOriginallydialled digits

ISUP version 3contains The called INnumber parameterwhich is sufficient forthis purpose.

No No Yes: via use of thecalled IN numberparameter.

Yes: via use of thecalled IN numberparameter.

B12 Disconnection of a callin progress

Relaying theDisconnectsignal.

This requirement canbe met by the existingbasic call sending aREL message in bothforward and backwarddirections. No impacton protocol betweennetworks in the callpath. ISUP istransparent in thisrespect.

Yes Yes Yes Yes

B13 Connection of a call toan interactive voiceresponse unit in thePTN.

Relaying theSetting up of acall to the IVRpossibly byroutingnumber. Noadditionalinformationrequired

There is no explicitsupport needed inISUP for thisrequirement, whichcan be fulfilled usingstandard ISUPprocedures. No impacton protocol betweennetworks in the callpath. ISUP istransparent in thisrespect.

Yes Yes Yes Yes

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersB14 Alternate routeing of

calls or the indicationsof calls to another "pointof presence" of the SP

VOID in termsof itsrequirementon user planeNNI protocols.

This may be achievedby routeingprocedures for out ofservice routes, whichare outside the scopeof the signallingprotocol. This is amanagementrequirement.

N/a N/a N/a N/a

B15 Alternate routeing of acall or the indication ofa call to another "pointof presence" of the PTN

See 22 above. This may be achievedby routeingprocedures for out ofservice routes, whichare outside the scopeof the signallingprotocol. This is amanagementrequirement.

N/a N/a N/a N/a

B16 Indication of thedisconnection of a call

Relaying theReceipt of theDisconnectmessage.

No impact on protocolbetween networks inthe call path. ISUP istransparent in thisrespect.

Yes Yes Yes Yes

B17 Supervision of adropped-back call

Relaying ofcontrol planeinformation forcontinuedsupervision ofa call, whereroute isoptimizedacrossnetworkboundaries.

There is no support inISUP for thisrequirement, exceptvia the Pivot Routeingand RedirectionProcedures in ISUPv4. For the networksthat are involved in thecall path other thanthose between the SP(pivot direction point)and the PTN whichperforms theredirection, there is notransparency issue inany version of ISUP.

No Yes as long as pivotalrouting, ISUP v4, isavailable within thePTN(s) that consent todo, or get involved in,the pivot orredirection. The otherparties in the callcontrol-signalling pathneed only supportversion2 or above ofISUP that have theability to tunnel therelevant ISUP v4messages.

Yes as long as pivotalrouting, ISUP v4, isavailable within thePTN(s) that consent todo, or get involved in,the pivot orredirection. The otherparties in the callcontrol-signalling pathneed only supportversion2 or above ofISUP that have theability to tunnel therelevant ISUP v4messages.

Yes. For the networksthat are involved in thecall path other thanthose between the SP(pivot direction point)and the PTN whichperforms theredirection, there is notransparency issue inany version of ISUP.

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersB18 Join operation of

individual legs of acall - Void in theinter-network case

VOID There is no explicitsupport within ISUP.This requirement willtherefore be met at theapplication level. Noimpact on protocolbetween networks inthe call path. ISUP istransparent in thisrespect. It is assumedthat the conferencebridge has to besupported in the PTNto which the SP has aSPAI.

Yes Yes Yes Yes

B19 Split operation ofindividual legs of a call

VOID There is no explicitsupport within ISUP.This requirement willtherefore be met at theapplication level. Noimpact on protocolbetween networks inthe call path. ISUP istransparent in thisrespect. It is assumedthat the conferencebridge has to besupported in the PTNto which the SP has aSPAI.

Yes Yes Yes Yes

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersB20 Multimedia Multiparty

call controlFull Transitfunctionalityfor Multimediacall control issupported insome versionsof ISUP. Note:all or some ofthemultimediacapabilitiesmay be in theevolvingversions ofSIP, H.323,BICC, etc.

No impact on protocolbetween networks inthe call path. ISUP istransparent in thisrespect. It is assumedthat the conferencebridge has to besupported in the PTNto which the SP has aSPAI.

Yes (limited):narrowbandmultimedia multipartycall control supportavailable, but thismust be effective inconjunction with abridging device.




B21 User Interaction for TextDelivery

Relay use/textdata

No explicit solution inISUP. Out-of bandrequirements may beimplemented via theUUS SupplementaryService, or mayrequire a differentinterconnect protocol.In-band solutions maybe possible, usingISUP as a bearerchannel only.Additional out-bandsolutions are availablein ISUP v4.Transparent support ofthese proceduresacross the third partynetwork is dependenton the SLA betweenthe networks.

No

Transparent deliveryof in-band solutions ispossible, using ISUPas a bearer channelonly.

Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.UUS is limited inISUPv1. Any relayedsupport of SS will belimited by the leastcapable network in thecall path.

No


Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.

No


Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.

No


Out-of bandrequirements may beimplemented via theUUS SupplementaryService, depending onterminal capabilities.These requirementsmay also beimplemented via theOCCRUI/UTSIprocedures dependingon terminalcapabilities. *

*Provided that theendpoints are ISUPv4

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


Parameterscapable and links inthe call path areISUPv2 or above.

B22 User-Plane resourcenegotiation andselection

Multimediabearer control,ability to makerequests andindications tothe PTN onbehalf ofservice users.

No support is availableor relevant withinISUP.

No No No No

C1 Interrogation of anetwork terminationpoint for data delivery

Relaying themessages forsetting up adata call withno alerting.

No explicit solution inISUP. Out-of bandrequirements may beimplemented via theUUS SupplementaryService, or mayrequire a differentinterconnect protocol.In-band solutions maybe possible, usingISUP as a bearerchannel only.Additional out-bandsolutions are availablein ISUP v4.




No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.Non time-limited out-ofband requirementsmay be implementedvia the OCCRUI/UTSIprocedures dependingon terminalcapabilities. *


ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersC2 Overriding of the

'incoming call barring'supplementary service-Void in the inter-network case

The requirement canonly be enabled over aSPAI with the PTN towhich the service useris directly connected.





C3 Bypassing of the 'calldiversion'supplementary






C4 Message waitingindication

Transparentrelayingrequired iftreated as aremotesupplementary service, e.g.using UUS orSMS.






C5 Application contentsscreening

ApplicationSLA issues.No additionalinformationrequired.

The requirement canonly be enabled over aSPAI with the PTN towhich the serviceprovider is directlyconnected. There isthus no impact ofISUP. Not a NNIprotocol requirement.

N/a N/a N/a N/a

C6 Modification of theterminal capabilities ofthe SP's service user

Relay theinformationexchange withthe terminal,e.g. Codedterminal classcapabilities

Transparent support ofthese proceduresacross the third partynetwork is notpossible. Securetunnelling of the SPAIacross the transitnetwork may be asolution; e.g.. SSL/IP.





ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersC7 Modification of the

Personality Device/module of the SP'sservice user

Relay theinformationexchange e.g.User Agentcoded scriptsor classcapabilities.

Transparent support ofthese proceduresacross the third partynetwork is notpossible. Securetunnelling of the SPAIacross the transitnetwork may be asolution; e.g. SSL/IP.





C8 Alteration of the profileof the SP's servicesubscriber

Relay theinformationexchange withthe Profiledatabase, e.g.coded scriptsor classcapabilities.






C9 Delivery of informationto the SP's service userprior to alerting

Allowing theopening of theforwardspeech path,to exchangeinformation.

Transparent support ofthese proceduresacross the third partynetwork is dependenton the SLA betweenthe networks.

No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.UUS is Limited inISUPv1.



No: Time-limited out-ofband requirementsmay be implementedvia the UUSSupplementaryService, depending onterminal capabilities.Or these may beimplemented via theOCCRUI/UTSIprocedures dependingon terminalcapabilities. *


ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersD1 Changes in the

charging rate of a call -Dynamic

Exchangingcharging rateinformation.






D2 Charging mechanismsbetween SP and PTNO- Dynamic

VOID Assuming this isbased on offlineexchange ofinformation, then doesnot form part of theISUP protocol. Therequirement can onlybe enabled over aSPAI with the PTN towhich the service useris directly connected.

N/a. N/a. N/a. N/a.

D3 Provision of callcharging information inreal time

Same as #D2above: e.g.Exchange anAccountingRecord, AOCor CDR atdefinedintervals.

No explicit supportwithin ISUP.





D4 Exchange of chargedetail record informationin real time

Exchange anAccountingRecord, AOCor CDR atdefinedintervals

Capabilities ofES 201 296 [25] (ISUPSupport of charging)can be used in anational context whereimplemented, howeverthis does not meet allthe elements of therequirement.

No No No No

D5 Billing and Accountingmechanisms betweenSP and PNO

N/a N/a N/a N/a

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersE1 Event traceability

requested by the SPExchangingstatistics-VOID as noreal-timerequirement.

No support in existingprotocol. A "global"call reference can besupported in ISUPversion 4.


E2 Event traceabilityrequested by the PTN

Exchangingstatistics-VOID as noreal-timerequirement.

No support in existingprotocol. A "global"call reference can besupported in ISUPversion 4.


E3 Traffic controlcapabilities controlledby the SP

VOID Not applicable. It isassumed that therequirement can onlybe enabled over aSPAI with the PTN towhich the service useris directly connected.There is thus noimpact of ISUP from atransparencyperspective.

N/a N/a N/a N/a

E4 Traffic controlcapabilities controlledby the PTN

VOID Not applicable. It isassumed that therequirement can onlybe enabled over aSPAI with the PTN towhich the service useris directly connected.There is therefore noimpact on ISUP from atransparencyperspective.

N/a N/a N/a N/a

ETSI



ETS 300 121(Edition 1) [16]


ETS 300 356(Edition 1) [13]


EN 300 356 (v3.x.x)[14]


EN 300 356 (v4.x.x)[15]




Parameters


Parameters


Parameters


ParametersE5 Avoidance of the

cyclical routeing of acall

Passing somedata with thecallassociatedsignalling, e.g.Hop count ortransactionnumber.

ISUP version 3supports a hopcounter parameter,which can be used tofulfil this function. Useof this procedure isoptional.

No No Yes: Hop Countparameter in EN 300356 v3

Yes: Hop Countparameter in EN 300356 v4

F1 Reporting of networkevents for measuringthe quality of service

ExchangeQoS SLAconfigurationdata e.g. forbroadbandcalls.





F2 Reporting of networkevents for the purposeof fault diagnostics

No additionalinter-networkrequired, butwhere suchinformation isavailable, itshould berelayedtransparently.





F3 Request for eventmonitoring andsubsequent reporting

Likely to beVOID as nocontractualarrangementwith furthernetworks inthe route.

Where CR interface isused, many events arereported through thenormal signallingmessages, but settingup the preconditions isa separatemanagementrequirement.





F4 Electronic ordering ofnetwork managementfunctions

VOID N/a: Managementrequirement.




ETSI


10 Mapping of Requirements against Benchmark ServicesTable 14 shows the results of mapping between the Service Provider Access Requirements and "Freephone", "Premium Rate", "Virtual Calling Card", "Virtual PrivateNetwork" and "Universal Personal Telecommunication" Benchmark Services. The level of support is indicated in table 14.

Table 14: Requirements assessment for Benchmark Services supported by Open-INAP (or other NCR Interface)

Freephone Premium Rate Virtual Card Calling Virtual PrivateNetwork

Universal PersonalTelecommunication

sNo. Requirement ETS 300 208 [7]

(Edition 1)ETS 300 712 [8]

(Edition 1)ETS 300 711 [9]

(Edition 1)ETR 172 [26]

(Edition 2)ETS 300 779 [10]

(Edition 1)* Y1 (required for core feature), Y2 (required for optional feature), or N/A (not applicable to the requirement). Where theanswer is "Y2", the option(s) are specified. Alternatively P (possibly, not specified in standard but could be included aspart of the relevant service), G (General, not service-specific).

A1 Reception of the calling line identity - Applicationof the CLIR supplementary service

Y1 Y1 Y1 Y1 Y1

A2 Presentation of the complete CLI information tothe PTN

Y1 Y1 Y1 Y1 Y1

A3 Addition or substitution of a calling line identity N/A N/A N/A P PA4 Provision of CLI information to an SP-initiated call N/a N/a N/a N/A N/AA5 Relaying of the malicious call identification data of

a received callY1 Y1 Y1 Y1 Y1

A6 Network Location Determination P P P P PA7 Geographic Location Determination P P P P PA8 Determination of the terminal capabilities of the

SP's service userN/a N/a N/a P P

B1 Return speech path connection from theterminating PTN to the calling party

P P P P P

B2 Routeing of an originating or incoming call fromthe PTN to the SP

P N/a Y1 Y1 Y1

B3 Indication of an originating or incoming call fromthe PTN to the SP

P N/a Y1 Y1 Y1

B4 Routeing of a terminating call from the PTN to theSP

Y1 Y1 N/a Y1 Y1

B5 Indication of a terminating call from the PTN tothe SP

Y1 Y1 N/a Y1 Y1

B6 Reception of a notification of the cause of anunsuccessful call

Y2 (Alternative destinationon busy/no reply - 5.2.8,

call queuing - 5.2.9)

Y2 (Call distribution -5.2.2)

Y2 (Call logging - 5.2.12) Y1 Y2 (UPTSupplementaryServices. - 4.3)

B7 Provision of information for the destination androuteing of a call

Y1 Y1 Y1 Y1 Y1

B8 Call drop-back N/a N/a N/a N/A N/A

ETSI





(Edition 1)ETS 300 712 [8]

(Edition 1)ETS 300 711 [9]


(Edition 2)ETS 300 779 [10]

(Edition 1)B9 User interaction without service charging of the

end userP N/A P P P

B10 Reception of the originally dialled digits by the SP Y1 Y1 Y1 Y1 Y1B11 Reception of the originally dialled digits by the

PTNY1 Y1 Y1 Y1 Y1

B12 Disconnection of a call in progress P P Y1 Y1 Y1B13 Connection of a call to an interactive voice

response unit in the PTNY2 (call queuing - 5.2.9) Y2 (presentation of

charging information -5.2.1, customized

recordedannouncements - 5.2.4,

Originating UserPrompter - 5.2.5)

Y1, Y2 (languageselection - 5.2.10)

P Y1, Y2 (languageselection)

B14 Alternate routeing of calls or the indications ofcalls to another "point of presence" of the SP

N/a N/a N/a Y1 N/A

B15 Alternate routeing of a call or the indication of acall to another "point of presence" of the PTN

N/a N/a N/a Y1 N/A

B16 Indication of the disconnection of a call Y2 (call limiter - 5.2.6,call queuing - 5.2.9,statistics - 5.2.13)

Y2 (statistics - 5.2.7)P

Y2 (Call logging - 5.2.12)P

Y1 Y1

B17 Supervision of a dropped-back call N/a N/a N/a N/A N/AB18 Join operation of individual legs of a call N/a N/a N/a P PB19 Split operation of individual legs of a call N/a N/a N/a P PB20 Multimedia Multiparty call control P P P P PB21 User Interaction for Text Delivery P P P P PB22 User-Plane resource negotiation and selection N/a N/a N/a P N/AC1 Interrogation of a network termination point for

data deliveryN/a N/a N/a P N/A

C2 Overriding of the 'incoming call barring'supplementary service

P Y1 (Service specificcalls only - 5.2.10)

N/a P P

C3 Bypassing of the 'call diversion' supplementaryservice

P Y1 (Service specificcalls only - 5.2.10)

N/a P P

C4 Message waiting indication N/a N/a N/a P PC5 Application contents screening P P P P PC6 Modification of the terminal capabilities of the

SP's service userP P N/a P P

C7 Modification of the Personality Device/module ofthe SP's service user

N/a N/a N/a N/A P

C8 Alteration of the profile of the SP's servicesubscriber

P (especially if IndividualNumber Allocation is

enabled)

P (esp. if IndividualNumber Allocation is

enabled)

Y2, P (Depending onimplementation of Speed

Dialling - 5.2.8)

Y1 Y1

ETSI





(Edition 1)ETS 300 712 [8]

(Edition 1)ETS 300 711 [9]


(Edition 2)ETS 300 779 [10]

(Edition 1)C9 Delivery of information to the SP's service user

prior to alertingP P N/A Y1 Y1

D1 Changes in the charging rate of a call - Dynamic N/a P P P PD2 Charging mechanisms between SP and PNO -

DynamicY1 Y1 Y1 P P

D3 Provision of call charging information in real time P P P P PD4 Exchange of charge detail record information in

real timeP P P P Y1

D5 Billing and Accounting mechanisms between SPand PNO

Void Void Void Void Void

E1 Event traceability requested by the SP G G G G GE2 Event traceability requested by the PTN G G G G GE3 Traffic control capabilities controlled by the SP G G G G GE4 Traffic control capabilities controlled by the PTN G G G G GE5 Avoidance of the cyclical routeing of a call N/a N/a N/a P N/AE6 Avoidance of the cyclical routeing of signalling or

user messagesG G G G G

F1 Reporting of network events for measuring thequality of service

G G G G G

F2 Reporting of network events for the purpose offault diagnostics

G G G G G

F3 Request for event monitoring and subsequentreporting

Y1 Y1 Y1 Y1 Y1

F4 Electronic ordering of network managementfunctions

G G G G P

ETSI


11 Management Plane requirements to support services.The Service Provider Access Requirements were analysed to determine what management plane facilities are needed, ifany, in order to enable their support and provision . This work on Service Provider Access Management Requirementsfor Open Network Access was undertaken co-operatively between TC SPAN and TC TMN and is contained inEG 201 965 [11].

11.1 Relationship between Management Plane, Control Plane,and User Plane

This is discussed in some detail in EG 201 722 [2], clause 8.5. An overview is presented below:

The management plane is a plane providing layer management and plane management functions in order to manage thefunctions of the control and user plane and their functional layers.

The requirements that the SPs have to the PTNs can be split into three categories:

- Control Plane functions of call control and service control of traffic in a PTN by the SP. The abovementioned CPfunctions can be provided by the control interface(s) located between the SP's equipment and PTN. For manyapplications, the SP-controlled voice traffic will not exit the PTN to the SP, but will be directed by the SPtowards its intended destination.

- User Plane functions of transferring voice traffic between the SP's equipment and PTN. The abovementionedUser Plane functions can be provided by the existing UNIs or NNIs.

- Management Plane functions to manage the functions of the control and user plane.

11.2 Management Plane categories:The Management Plane requirements can be split into:

• Traffic Related Capabilities (e.g. setting switch triggers, datafill, etc), necessary in order to enable from anoperational perspective one or more of the Service Provider Access Requirements.

• Performance Management Capabilities - e.g. monitoring performance of SP/PTN links, link reconfiguration, etc.

• Electronic Bonding/Ordering.

Table 15: Management requirements cross reference to EG 201 965 [11]

CapabilityNo. Requirement ReferenceTraffic

RelatedPerformanceManagement

ElectronicBonding/Ordering

A1 Reception of the calling line identity - Application of the CLIRsupplementary service

[1] 5.2.1,[3] 5.2.2

A2 Presentation of the complete CLI information to the PTN [1] 5.2.2A3 Addition or substitution of a calling line identity [1] 5.2.3A4 Provision of CLI information to an SP-initiated call [1] 5.2.4A5 Relaying of the malicious call identification data of a received

call[1] 5.2.5,[3] 5.2.1

A6 Network Location Determination [2] 5.1.1A7 Geographic Location Determination [2] 5.1.2A8 Determination of the terminal capabilities of the SP's service

user[2] 5.2.1

B1 Return speech path connection from the terminating PTN tothe calling party

[1] 5.3.1

B2 Routeing of an originating or incoming call from the PTN to theSP

[1] 5.3.2

ETSI


CapabilityNo. Requirement ReferenceTraffic

RelatedPerformanceManagement

ElectronicBonding/Ordering

B3 Indication of an originating or incoming call from the PTN tothe SP

[1] 5.3.3

B4 Routeing of a terminating call from the PTN to the SP [1] 5.3.4B5 Indication of a terminating call from the PTN to the SP [1] 5.3.5B6 Reception of a notification of the cause of an unsuccessful call [1] 5.3.6B7 Provision of information for the destination and routeing of a

call[1] 5.3.7

B8 Call drop-back [1] 5.3.8B9 User interaction without service charging of the end user [1] 5.3.9

B10 Reception of the originally dialled digits by the SP [1] 5.3.10B11 Reception of the originally dialled digits by the PTN [3] 5.3.1B12 Disconnection of a call in progress [1] 5.3.11B13 Connection of a call to an interactive voice response unit in the

PTN.[1] 5.3.12

B14 Alternate routeing of calls or the indications of calls to another"point of presence" of the SP

[1] 5.3.13

B15 Alternate routeing of a call or the indication of a call to another"point of presence" of the PTN

[3] 5.3.2

B16 Indication of the disconnection of a call [2] 5.4.1B17 Supervision of a dropped-back call. [2] 5.4.5B18 Join operation of individual legs of a call [2] 5.4.2B19 Split operation of individual legs of a cal [2] 5.4.3B20 Multimedia Multiparty call control [2] 5.4.7B21 User Interaction for Text Delivery [2] 5.4.8B22 User-Plane resource negotiation and selection [2] 5.4.9C1 Interrogation of a network termination point for data delivery [1] 5.4.1C2 Overriding of the "incoming call barring" supplementary service [1] 5.4.2C3 Bypassing of the "call diversion'"supplementary service. [1] 5.4.3C4 Message waiting indication [1] 5.4.4C5 Application contents screening [3] 5.5.1C6 Modification of the terminal capabilities of the SP's service

user[2] 5.2.2

C7 Modification of the Personality Device/ module of the SP'sservice user

[2] 5.2.3

C8 Alteration of the profile of the SP's service subscriber [2] 5.3.1C9 Delivery of information to the SP's service user prior to alerting [2] 5.4.4D1 Changes in the charging rate of a call - Dynamic [1] 5.5.1D2 Charging mechanisms between SP and PTNO - Dynamic [3] 5.5.2D3 Provision of call charging information in real time [2] 5.6.1D4 Exchange of charge detail record information in real time [2] 5.6.2E1 Event traceability requested by the SP [1] 5.6.1E2 Event traceability requested by the PTN [3] 5.4.1E3 Traffic control capabilities controlled by the SP [1] 5.6.2E4 Traffic control capabilities controlled by the PTN [3] 5.4.2E5 Avoidance of the cyclical routeing of a call [1] 5.6.3,

[3] 5.4.3E6 Avoidance of the cyclical routeing of signalling or user

messages[2] 5.4.6

F1 Reporting of network events for measuring the quality ofservice

[2] 5.5.1

F2 Reporting of network events for the purpose of faultdiagnostics

[2] 5.5.2

F3 Request for event monitoring and subsequent reporting [2] 5.5.3F4 Electronic ordering of network management functions [2] 5.5.4

ETSI


12 ConclusionsFrom an analysis of the protocol mapping work, it is clear from the results above that the UNI circuit-related protocolcan only achieve a partial subset of the requirements. However, NNI circuit-related protocols meet a more complete setof the requirements; these are the published standard interconnection protocols in current use between interconnectednetworks in diverse countries.

The highest level of support for the SPAR requirements is found in the non-circuit-related signalling configurations inconjunction with the management plane access, which is required to establish the pre-conditions for the monitorednetwork events (e.g.: triggers).The features provided in the IN capability sets with the capabilities specified in CAMELhave the advantage of supporting these non-circuit-related control plane configurations. Open INAP offers theopportunity to implement these NCR interfaces without parameter options, i.e. to a tightly defined PICS proforma. Theongoing ETSI API work represents a possible path for future evolution for such access.

13 Future Work

13.1 New/Emerging ProtocolsIt is clear that the area of IP and Multimedia support can usefully be mapped against the current requirements, when thestatus of the implementation of the existing emerging standards (SIP, H.323, H.248 (see bibliography)) is more mature.

13.2 New RequirementsThe current set of requirements has been defined in EG 201 722 [2], EG 201 897 [4], and EG 201 807 [3]. As furtherrequirements emerge, a similar approach to mapping these against the current and new sets of protocols can be taken.

ETSI


Annex A (informative):Bibliography

- ETSI TCRTR 034 (Edition 2): "Business TeleCommunications (BTC); Virtual Private Networking (VPN);Services and networking aspects; Standardization requirements and work items".

- DEN/SPAN-120084: "Services and Protocols for Advanced Networks (SPAN); PICS proforma for open coreINAP".

- ITU-T Recommendation H.323: "Packet-based multimedia communications systems".

- ITU-T Recommendation H.248: "Gateway control protocol".

ETSI


History

Document history

V1.1.1 August 2001 Membership Approval Procedure MV 20011005: 2001-08-07 to 2001-10-05