ETSI EG 201 988-4 V1.1.1 (2008-02)
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service Provider Access; Open Service Access for API requirements; Part 4: Version 4
Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Service Provider Access; Open Service Access for API requirements; Part 4: Version 4
DEG/TISPAN-01058-OSA
Zlite telekomunikacijske in internetne storitve ter protokoli za napredno omreženje (TISPAN) - Dostop ponudnika storitve (SPA) - Odprt dostop do storitve za zahteve API - 4. del: Različica 4
General Information
Buy Standard
Standards Content (Sample)
ETSI EG 201 988-4 V1.1.1 (2008-02)
ETSI Guide
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Service Provider Access;
Open Service Access for API requirements;
Part 4: Version 4
---------------------- Page: 1 ----------------------
2 ETSI EG 201 988-4 V1.1.1 (2008-02)
Reference
DEG/TISPAN-01058-OSA
Keywords
API, architecture, interface, UML
ETSI
650 Route des Lucioles
F-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 C
Association à but non lucratif enregistrée à la
Sous-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 or
perceived 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 drive
within 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://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 2 ----------------------
3 ETSI EG 201 988-4 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.4
Foreword.4
Introduction .4
1 Scope.5
2 References.5
2.1 Normative references.5
2.2 Informative references.6
3 Abbreviations.6
4 ETSI Phase 4.0/Parlay 6.0 API Domains .6
4.1 Requirements on interfaces at different levels of abstractions .7
4.2 Parlay X Web Service Guidelines .7
5 Proposed enhancements to existing Interfaces.7
5.1 General requirements.7
5.1.1 Backwards Compatibility/Deprecation - Parlay/OSA APIs.7
5.1.2 Backwards Compatibility/Deprecation - Parlay X Web Services.8
5.2 Call Session Control.8
5.3 Scheduled Short and Multimedia Message Transmission (#6P11) .9
5.4 Charging.10
5.5 Account Management.10
5.6 Presence.11
6 New interfaces and areas of involvement.11
6.1 Message Broadcast.11
6.2 Multimedia Stream Control.12
6.3 Extend mobility to include Geocoding.14
6.4 Service Brokering.15
6.5 QoS for end-user/s involved in an application session.16
6.6 Multimedia Multicast Control .17
6.7 Device Capabilities and Configuration.19
Annex A (informative): Bibliography.22
History .23
ETSI
---------------------- Page: 3 ----------------------
4 ETSI EG 201 988-4 V1.1.1 (2008-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN).
The present document is part 4 of a multi-part deliverable covering Service Provider Access; Open Service Access for
API requirements, as identified below:
Part 1: "Version 1";
Part 2: "Version 2";
Part 3: "Version 3".
Part 4: "Version 4".
Introduction
The present document contains the Requirements capture for ETSI 4.0 "Third Party API" protocol specification:
ES 203 915 series [1] and ES 202 391 series [2].
ETSI
---------------------- Page: 4 ----------------------
5 ETSI EG 201 988-4 V1.1.1 (2008-02)
1 Scope
The present document contains the functional requirements for Open Service Access Requirements Version 4.0. The
present document has been compiled in conjunction with Parlay and represents the sixth phase of the Parlay API. The
ETSI and Parlay API have been specified and designed using the requirements identified both in the previously
published Parts of this specification, Parts 1 through 3 and in the present document, Part 4. The requirements are
intended to provide the necessary functionality for benchmark applications.
It is the intention that the new requirements should build upon the ETSI Phase 3.0 API and that of the Parlay 5.0
specification requirements, as described in EG 201 988-3 [3], and should be fully backward compatible. This means
that any network operator implementing ETSI Phase 4.0 or Parlay 6.0 should be able to interwork with a client
application provider implementing ETSI Phase 3.0 or Parlay 5.0. In other words ETSI Phase 4.0 and Parlay 6.0 will
retain ETSI Phase3.0 and Parlay 5.0 as a complete subset. A full description of backward compatibility considerations
is presented in clause 9 of ES 203 915-1 [4]. For any requirement that would result in an extension of, or would build
upon, a part of the API specification set that is published jointly by 3GPP as well, in addition to ETSI and Parlay, the
contributing companies are encouraged to submit their requirements to the 3GPP SA1 requirements process [5].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI ES 203 915 (series): "Open Service Access (OSA); Application Programming Interface
(API)".
[2] ETSI ES 202 391 (series): "Open Service Access (OSA); Parlay X Web Services".
[3] ETSI EG 201 988-3: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Service Provider Access; Open Service Access for API
Requirements; Part 3: Version 3".
ETSI
---------------------- Page: 5 ----------------------
6 ETSI EG 201 988-4 V1.1.1 (2008-02)
[4] ETSI ES 203 915-1: "Open Service Access (OSA); Application Programming Interface (API);
Part 1 Overview (Parlay 5)".
2.2 Informative references
[5] ETSI TS 122 127: "Universal Mobile Telecommunications System (UMTS); Service Requirement
for the Open Services Access (OSA); Stage 1 (3GPP TS 22.127)".
[6] ETSI TS 123 041: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Technical realization of Cell Broadcast Service (CBS)
(3GPP TS 23.041)".
[7] ETSI TS 123 032: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Universal Geographical Area Description (GAD)
(3GPP TS 23.032)".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADQ Application Driven Quality of Service
API Application Program Interface
ASP Application Service Provider
BM-SC Broadcast Multicast-Service Centre
CBC Cell Broadcast Centre
GGSN Gateway GPRS Support Node
IP Internet Protocol
IPTV Internetworking Protocol Television
IVR Interactive Voice Response
MMS Multimedia Messaging Service
OSA Open Service Access
SGSN Serving GPRS Support Node
SMS Short Messaging Service
TPC Third Party Control
4 ETSI Phase 4.0/Parlay 6.0 API Domains
The Parlay/OSA API is an open, technology-independent, and extensible interface into networking technologies. The
Parlay API is therefore applicable to a number of business and application domains, not just telecommunications
network operators.
Examples of business domains that may use the API include:
• Third Party NGN Service Providers.
• Interactive Multimedia Service Providers.
• Corporate Businesses.
• Small Businesses.
• Residential Customers.
• Network Operators.
All of these businesses have networking requirements, ranging from simple telephony and call routing to call centre's,
virtual private networks and fully interactive multimedia.
ETSI
---------------------- Page: 6 ----------------------
7 ETSI EG 201 988-4 V1.1.1 (2008-02)
4.1 Requirements on interfaces at different levels of
abstractions
As originally defined in clause 6.5 of EG 201 988-3 [3], the OSA-defined functions may be accessed through interfaces
at different levels of abstractions and according to different programming formalisms, in addition to those defined in the
previous Releases. Accordingly, ETSI Phase 3.0 and Parlay 5.0 is realized in two specifications sets:
• OSA APIs (Parlay 5).
• OSA Parlay X 2 Web Services.
For ETSI Phase 4.0 and Parlay 6.0, the requirements described in the present document will likewise be realized in two
specifications sets:
• OSA APIs (Parlay 6): i.e. ES 203 915 series [1].
• OSA Parlay X Web Services: i.e. ES 202 391 series [2].
Guidelines have been adopted to determine which of the two abstraction layers provides the appropriate domain to
realize the requirements described in the present document.
4.2 Parlay X Web Service Guidelines
The interfaces represented by the Parlay X Web Services should be powerful yet simple and highly abstracted. The
following rules serve as guidelines for realizing requirements using Parlay X Web Services. Exceptions to these rules
will be considered if they are justified by simplicity or completeness of the API, and if the resulting specification is
sufficiently differentiated from related specifications.
• A Parlay X Web Service specification will be a functional abstractions of a Parlay/OSA specification. Where a
functionally overlapping Parlay/OSA specification exists, the Parlay X Web Service specification will be an
abstraction of the Parlay/OSA specification.
• Parlay X Web Service specifications should offer a coarser granularity level (e.g. measured as the relative size,
level of detail, or depth of penetration), and contain less than half the methods of the equivalent Parlay/OSA
specifications.
• Parlay X Web Service specifications should not mandate the maintenance of state.
• Parlay X Web Service specifications should not contain asynchronous message exchange, but often include
event notification.
• Parlay X Web Service specifications should never imply detailed protocol knowledge.
• Parlay X Web Service specifications should be functionally self-contained from the developers point of view.
• For any Parlay X Web Service specification, 80 % of the above rules should be met.
5 Proposed enhancements to existing Interfaces
5.1 General requirements
5.1.1 Backwards Compatibility/Deprecation - Parlay/OSA APIs
A full description of backward compatibility considerations is presented in clause 9 of ES 203 915-1 [4].
ETSI
---------------------- Page: 7 ----------------------
8 ETSI EG 201 988-4 V1.1.1 (2008-02)
5.1.2 Backwards Compatibility/Deprecation - Parlay X Web Services
For OSA Parlay X 3 Web Services it is desirable, but it is not considered necessary, to retain backwards compatibility
with the existing OSA Parlay X 2 Web Services specifications. This is because the existing specifications are immature
and there are limited implementations and deployments to date. This provide an opportunity to correct identified
shortcomings, and in so doing provide a solution approach that will enable a richer set of applications whilst being
application agnostic in nature.
5.2 Call Session Control
Issues and Motivation:
Operators and vendors desire to extend the call control capabilities of the Parlay X Web Services. The suggested
approach to the evolution of Parlay X Call Control builds on the agreed view of keeping the Parlay X web services true
to the design goal of "Separation of Concerns" and to avoid bundling of functionality where possible. This approach is
not backward compatible with the existing Parlay X Call control-related web services, but this is an acceptable trade-off
as noted in clause 5.1.2.
Requirements Description:
• Call Participant Control. The ability to add, remove, transfer call participants, for either application or network
initiated calls.
• IVR Interaction. Application should be able to request IVR Interaction on a call. It should include simple Play
Announcement and Play and Collect information capabilities for both network and application initiated calls.
• Additional Call Notification events. The following are specifically identified:
- Call Progress.
- Call Setup failure.
- Call Party Disconnect.
- Call Party Answer.
- Call Rejected.
- Media Changed.
• Deassign Call Control. The ability to stop an application from receiving notifications on a specific call.
• Media Control. The ability to manipulate the media on either an application or network initiated call.
Proposed Solution and Further Considerations:
These functions are currently implemented in the Parlay/OSA APIs.
These functions are also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
Figure 1 shows the conceptual principles of how the involved call control elements relate.
ETSI
---------------------- Page: 8 ----------------------
9 ETSI EG 201 988-4 V1.1.1 (2008-02)
Figure 1
CallSession: The CallSession object can be used to interact with ongoing calls. It will also serve as a placeholder for a
set of calls. It can be viewed as a call "context" (uniquely identified) to/from which participants can be added/removed.
ThirdPartyCall: The Third Party Call Web Service will now be the only place where application initiated call
processing can and should be performed. This implies removing the call initiation from, for instance, the AudioCall web
service. CallNotification and CallDirection interfaces are updated to support the CallSession concept.
The ThirdPartyCall MakeCall operation will further be enhanced with an optional parameter to indicate which
CallSession the call is to be assigned to. If this parameter is not included in the request, the MakeCall will operate as in
previous versions of Parlay X.
ThirdPartyCall provides the ability to setup a call session, add and delete a call participant, transfer a call participant
from one call session into another call session, determine the status of an individual call participant or a complete call
session, and finally to end a call session.
AudioCall: For the AudioCall service, it is proposed change the name to MediaCall and add a PlayVideoMessage
operation to complete the set of operations. The service will now also change its behaviour such that it can only act on
already established CallSession objects. This keeps a clear distinction between where the call control lives and where
the media capabilities are added.
AudioCall will also be extended so that it can manipulate media on an ongoing call (either network or application
initiated) and IVR interactions can occur.
User: A user can be part of many calls, it is important to note that the concept of a user may involve resources such as
voice xml processing equipment and text-to-speech engines.
5.3 Scheduled Short and Multimedia Message Transmission
(#6P11)
Issues and Motivation:
Operators desire the ability to send a short or multimedia message to a large set of subscribers. In addition, operators
would like to provide third parties with the ability to create and schedule transmissions of large sets of message to
increase messaging infrastructure usage.
The current messaging interfaces provide immediate message transmission only and do not allow applications to
schedule message transmission during periods when network messaging resources are less utilized.
The commercial motivation is the ability to increase the volume of successfully delivered messages and the end-user
application experience.
ETSI
---------------------- Page: 9 ----------------------
10 ETSI EG 201 988-4 V1.1.1 (2008-02)
Scenarios:
Not applicable.
Requirements Description:
• Schedule the transmission of short messages to multiple destinations.
• Schedule the transmission of multimedia messages to multiple destinations.
• Retrieve the status of a scheduled message transmission request, including the number of messages
successfully sent if a scheduled request is in progress or has completed.
• Cancel a scheduled message transmission request:
- An ability to cancel a scheduled message transmission request has greater business value than an
equivalent function for the existing immediate message transmission function. This is because this new
function will typically be used to request transmission of large sets of messages well in advance of the
scheduled time, resulting in a higher probability of a successful cancellation result and a reduction in
unnecessary messaging resource usage.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function can also be mapped to the existing Parlay/OSA APIs.
5.4 Charging
Issues and Motivation:
The ability to split a charge between multiple end user accounts.
Scenarios:
A multi-player gaming application, where all participants share in the cost.
Requirements Description:
• Support split charging.
Proposed Solution and Further Considerations:
This function is currently implemented in the Parlay/OSA APIs.
This function is also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
5.5 Account Management
Issues and Motivation:
Desire to take proactive measures (e.g. recharging) when an account balance falls below a threshold. Also the ability to
monitor end user account activity: charging and recharging.
Scenarios:
Not applicable
Requirements Description:
• Support account balance related event notifications: charge, recharge, low balance.
Proposed Solution and Further Considerations:
This function is currently implemented in the Parlay/OSA APIs.
ETSI
---------------------- Page: 10 ----------------------
11 ETSI EG 201 988-4 V1.1.1 (2008-02)
This function is also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
5.6 Presence
Issues and Motivation:
Currently the Parlay X Presence Web Service provides information to the application on the various means of
communicating with a presentity: e.g. voice, chat, SMS, video etc. However the status of each such means of
communication is not available to the application which limits development of richer applications.
Scenarios:
Not applicable.
Requirements Description:
• For each of the possible means of communicating with a presentity, provide the application also with the
current status of that communication means.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function can also be mapped to the existing Parlay/OSA APIs and SIP/IMS networks.
The proposed solution would add a status element (on, off, busy) to the CommunicationMeans structure.
6 New interfaces and areas of involvement
6.1 Message Broadcast
Issues and Motivation:
Currently, most of the existing Parlay/Parlay X APIs are defined and used for the point-to-point communication such as
TPC, SMS, MMS, etc. But, in some other cases, point-to-multipoint communications - i.e. broadcasting of messages to
everyone who is in certain areas or multicasting of messages to a certain group - could be required and considered as
very useful and efficient communication method.
Message broadcast is a functionality that allows an application to send messages to all the fixed or mobile terminals in a
specific geographical area.
Scenarios:
There are various use cases of using Message Broadcast Web Service including the commercial application. This Web
Service could be also used for non-commercial purposes as follows:
• To provide area-based public information such as weather, traffic and other information of common interest.
• To provide emergency information such as severe weather warnings (e.g. typhoon, tsunami), environmental
hazards (e.g. chemical spills) and terrorism alerts.
ETSI
---------------------- Page: 11 ----------------------
12 ETSI EG 201 988-4 V1.1.1 (2008-02)
MMessageessage Broadcast Broadcast
WeWebb S Seerrvviiccee
333
PaParrllaayy X I/ X I/FF
MMessaessagigingng C Ceentrntere
SOSOAAPP (e.(e.gg., C., CBC)BC)
222
111
mobile mobile
ffiixedxed
brobroddcacastCstCooupuponon( )( )
nenetwtwororkk
nenetwtwororkk
{{
areareaa = = setAsetArreeaa();();
msmsgg = = ““ 2 h2 hourours, s,
20%20% di discoscountunt”” ;;
sensenderderNNaammee = = ““ GA GAPP”” ; ;
…….
SShohop map mananaggerer
sensenddBBrrooadcadcastastMMesessagsagee((aarreeaa, , msmsgg , ,
sensenderderNNaammee););
} }
SMSMSMSSS SMSMSMSSS SMSMSMSSS SMSMSMSSS
SShopping mahopping mallll
bbuuyy s soommeetthhiningg ( (oofflinfflinee))
Figure 2
Figure 2 shows an advertising scenario using the Message Broadcast Web Service to broadcast messages describing
shop discount offers inside, and in the vicinity of, a shopping mall. A shop manager who wants to increase sales during
a holiday period can make use of a message broadcast application. By using the application, the manager can set the
targeted area, compose the sales message and identify the shop offering the discount (1). Then, the application uses the
Parlay X interface to invoke the Message Broadcast Web Service operation (2). After invocation, the Message
Broadcast Web Service sends a message delivery operation to the messaging centre, e.g. the CBC (3). Subsequently, the
shop discount message is delivered to all the terminals within the targeted area.
Requirements Description:
• Broadcast a message to a designated area with frequency and interval.
• Retrieve the delivery status of previous broadcast request.
• Cancel the previous broadcast request.
• Be notified when the delivery has been done or is impossible.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function is also supported in the underlying network capabilities, as described in the following
specifications:
• TS 123 041 [6].
• TS 123 032 [7].
• SMPP v5.0 from SMS Forum.
6.2 Multimedia Stream Control
Issues and Motivation:
New terminals are advanced and can now handle streaming media like video clips and music. Operators have invested
in Streaming Servers and a new API is needed to support third party access to these Servers to stream content to
terminals.
ETSI
---------------------- Page: 12 ----------------------
13 ETSI EG 201 988-4 V1.1.1 (2008-02)
An alternative is to download all content to the operator and let subscribers access it via the operator, i.e. the walled
garden approach. Another alternative is to open the network completely. Neither of these are viable options.
The service provided to an end-user is consumption of streaming multi media. The end-user has a terminal that is able
to request a media stream, either from a built-in player, or an installed application. The terminal can be any terminal
with streaming media playing capabilities, and the service should allow a user to transfer between his terminals.
Scenarios:
• The basic scenario is where an individual is browsing the Internet and finds some interesting content that
he/she wants to watch. The end-user is then either doing this through the operator's portal or accesses the
content provider's site. In the first case, the request is then processed through the portal, and charged as the
stream is set-up. In the sec
...
Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
ETSI Guide
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Service Provider Access;
Open Service Access for API requirements;
Part 4: Version 4
---------------------- Page: 1 ----------------------
2 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
Reference
DEG/TISPAN-01058-OSA
Keywords
API, architecture, interface, UML
ETSI
650 Route des Lucioles
F-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 C
Association à but non lucratif enregistrée à la
Sous-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 or
perceived 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 drive
within 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://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2007.
All rights reserved.
TM TM TM
DECT , PLUGTESTS and UMTS are Trade Marks of ETSI registered for the benefit of its Members.
TM
TIPHON and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 2 ----------------------
3 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
Contents
Intellectual Property Rights.4
Foreword.4
Introduction .4
1 Scope.5
2 References.5
2.1 Normative references.5
2.2 Informative references.6
3 Abbreviations.6
4 ETSI Phase 4.0/ Parlay 6.0 API Domains .6
4.1 Requirements on interfaces at different levels of abstractions .7
4.2 Parlay X Web Service Guidelines .7
5 Proposed enhancements to existing Interfaces.7
5.1 General requirements.7
5.1.1 Backwards Compatibility/Deprecation - Parlay/OSA APIs.7
5.1.2 Backwards Compatibility/Deprecation - Parlay X Web Services.8
5.2 Call Session Control.8
5.3 Scheduled Short and Multimedia Message Transmission (#6P11) .9
5.4 Charging.10
5.5 Account Management.10
5.6 Presence.11
6 New interfaces and areas of involvement.11
6.1 Message Broadcast.11
6.2 Multimedia Stream Control.12
6.3 Extend mobility to include Geocoding.14
6.4 Service Brokering.15
6.5 QoS for end-user/s involved in an application session.16
6.6 Multimedia Multicast Control .17
6.7 Device Capabilities and Configuration.19
Annex A (informative): Bibliography.22
History .23
ETSI
---------------------- Page: 3 ----------------------
4 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN), and is now submitted for the ETSI standards Membership
Approval Procedure.
The present document is part 4 of a multi-part deliverable covering Service Provider Access; Open Service Access for
API requirements, as identified below:
Part 1: "Version 1";
Part 2: "Version 2";
Part 3: "Version 3".
Part 4: "Version 4".
Introduction
The present document contains the Requirements capture for ETSI 4.0 "Third Party API" protocol specification:
ES 203 915 series [1] and ES 202 391 series [2].
ETSI
---------------------- Page: 4 ----------------------
5 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
1 Scope
The present document contains the functional requirements for Open Service Access Requirements Version 4.0. The
present document has been compiled in conjunction with Parlay and represents the sixth phase of the Parlay API. The
ETSI and Parlay API have been specified and designed using the requirements identified both in the previously
published Parts of this specification, Parts 1 through 3 and in the present document, Part 4. The requirements are
intended to provide the necessary functionality for benchmark applications.
It is the intention that the new requirements should build upon the ETSI Phase 3.0 API and that of the Parlay 5.0
specification requirements, as described in EG 201 988-3 [3], and should be fully backward compatible. This means
that any network operator implementing ETSI Phase 4.0 or Parlay 6.0 should be able to interwork with a client
application provider implementing ETSI Phase 3.0 or Parlay 5.0. In other words ETSI Phase 4.0 and Parlay 6.0 will
retain ETSI Phase3.0 and Parlay 5.0 as a complete subset. A full description of backward compatibility considerations
is presented in clause 9 of ES 203 915-1 [4]. For any requirement that would result in an extension of, or would build
upon, a part of the API specification set that is published jointly by 3GPP as well, in addition to ETSI and Parlay, the
contributing companies are encouraged to submit their requirements to the 3GPP SA1 requirements process [5].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI ES 203 915 (series): "Open Service Access (OSA); Application Programming Interface
(API)".
[2] ETSI ES 202 391 (series): "Open Service Access (OSA); Parlay X Web Services".
[3] ETSI EG 201 988-3: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Service Provider Access; Open Service Access for API
Requirements; Part 3: Version 3".
ETSI
---------------------- Page: 5 ----------------------
6 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
[4] ETSI ES 203 915-1: "Open Service Access (OSA); Application Programming Interface (API);
Part 1 Overview (Parlay 5)".
2.2 Informative references
[5] ETSI TS 122 127: "Universal Mobile Telecommunications System (UMTS); Service Requirement
for the Open Services Access (OSA); Stage 1 (3GPP TS 22.127)".
[6] ETSI TS 123 041: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Technical realization of Cell Broadcast Service (CBS)
(3GPP TS 23.041)".
[7] ETSI TS 123 032: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Universal Geographical Area Description (GAD)
(3GPP TS 23.032)".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADQ Application Driven Quality of Service
API Application Program Interface
ASP Application Service Provider
BM-SC Broadcast Multicast-Service Centre
CBC Cell Broadcast Centre
GGSN Gateway GPRS Support Node
IP Internet Protocol
IPTV Internetworking Protocol Television
IVR Interactive Voice Response
MMS Multimedia Messaging Service
SGSN Serving GPRS Support Node
SMS Short Messaging Service
TPC Third Party Control
4 ETSI Phase 4.0/Parlay 6.0 API Domains
The Parlay/OSA API is an open, technology-independent, and extensible interface into networking technologies. The
Parlay API is therefore applicable to a number of business and application domains, not just telecommunications
network operators.
Examples of business domains that may use the API include:
• Third Party NGN Service Providers.
• Interactive Multimedia Service Providers.
• Corporate Businesses.
• Small Businesses.
• Residential Customers.
• Network Operators.
All of these businesses have networking requirements, ranging from simple telephony and call routing to call centre's,
virtual private networks and fully interactive multimedia.
ETSI
---------------------- Page: 6 ----------------------
7 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
4.1 Requirements on interfaces at different levels of
abstractions
As originally defined in clause 6.5 of EG 201 988-3 [3], the OSA-defined functions may be accessed through interfaces
at different levels of abstractions and according to different programming formalisms, in addition to those defined in the
previous Releases. Accordingly, ETSI Phase 3.0 and Parlay 5.0 is realized in two specifications sets:
• OSA APIs (Parlay 5).
• OSA Parlay X 2 Web Services.
For ETSI Phase 4.0 and Parlay 6.0, the requirements described in the present document will likewise be realized in two
specifications sets:
• OSA APIs (Parlay 6): i.e. ES 203 915 series [1].
• OSA Parlay X Web Services: i.e. ES 202 391 series [2].
Guidelines have been adopted to determine which of the two abstraction layers provides the appropriate domain to
realize the requirements described in the present document.
4.2 Parlay X Web Service Guidelines
The interfaces represented by the Parlay X Web Services should be powerful yet simple and highly abstracted. The
following rules serve as guidelines for realizing requirements using Parlay X Web Services. Exceptions to these rules
will be considered if they are justified by simplicity or completeness of the API, and if the resulting specification is
sufficiently differentiated from related specifications.
• A Parlay X Web Service specification will be a functional abstractions of a Parlay/OSA specification. Where a
functionally overlapping Parlay/OSA specification exists, the Parlay X Web Service specification will be an
abstraction of the Parlay/OSA specification.
• Parlay X Web Service specifications should offer a coarser granularity level (e.g. measured as the relative size,
level of detail, or depth of penetration), and contain less than half the methods of the equivalent Parlay/OSA
specifications.
• Parlay X Web Service specifications should not mandate the maintenance of state.
• Parlay X Web Service specifications should not contain asynchronous message exchange, but often include
event notification.
• Parlay X Web Service specifications should never imply detailed protocol knowledge.
• Parlay X Web Service specifications should be functionally self-contained from the developers point of view.
• For any Parlay X Web Service specification, 80 % of the above rules should be met.
5 Proposed enhancements to existing Interfaces
5.1 General requirements
5.1.1 Backwards Compatibility/Deprecation - Parlay/OSA APIs
A full description of backward compatibility considerations is presented in clause 9 of ES 203 915-1 [4].
ETSI
---------------------- Page: 7 ----------------------
8 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
5.1.2 Backwards Compatibility/Deprecation - Parlay X Web Services
For OSA Parlay X 3 Web Services it is desirable, but it is not considered necessary, to retain backwards compatibility
with the existing OSA Parlay X 2 Web Services specifications. This is because the existing specifications are immature
and there are limited implementations and deployments to date. This provide an opportunity to correct identified
shortcomings, and in so doing provide a solution approach that will enable a richer set of applications whilst being
application agnostic in nature.
5.2 Call Session Control
Issues and Motivation:
Operators and vendors desire to extend the call control capabilities of the Parlay X Web Services. The suggested
approach to the evolution of Parlay X Call Control builds on the agreed view of keeping the Parlay X web services true
to the design goal of "Separation of Concerns" and to avoid bundling of functionality where possible. This approach is
not backward compatible with the existing Parlay X Call control-related web services, but this is an acceptable trade-off
as noted in clause 5.1.2.
Requirements Description:
• Call Participant Control. The ability to add, remove, transfer call participants, for either application or network
initiated calls.
• IVR Interaction. Application should be able to request IVR Interaction on a call. It should include simple Play
Announcement and Play and Collect information capabilities for both network and application initiated calls.
• Additional Call Notification events. The following are specifically identified:
- Call Progress.
- Call Setup failure.
- Call Party Disconnect.
- Call Party Answer.
- Call Rejected.
- Media Changed.
• Deassign Call Control. The ability to stop an application from receiving notifications on a specific call.
• Media Control. The ability to manipulate the media on either an application or network initiated call.
Proposed Solution and Further Considerations:
These functions are currently implemented in the Parlay/OSA APIs.
These functions are also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
Figure 1 shows the conceptual principles of how the involved call control elements relate.
ETSI
---------------------- Page: 8 ----------------------
9 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
Figure 1
CallSession: The CallSession object can be used to interact with ongoing calls. It will also serve as a placeholder for a
set of calls. It can be viewed as a call "context" (uniquely identified) to/from which participants can be added/removed.
ThirdPartyCall: The Third Party Call Web Service will now be the only place where application initiated call
processing can and should be performed. This implies removing the call initiation from, for instance, the AudioCall web
service. CallNotification and CallDirection interfaces are updated to support the CallSession concept.
The ThirdPartyCall MakeCall operation will further be enhanced with an optional parameter to indicate which
CallSession the call is to be assigned to. If this parameter is not included in the request, the MakeCall will operate as in
previous versions of Parlay X.
ThirdPartyCall provides the ability to setup a call session, add and delete a call participant, transfer a call participant
from one call session into another call session, determine the status of an individual call participant or a complete call
session, and finally to end a call session.
AudioCall: For the AudioCall service, it is proposed change the name to MediaCall and add a PlayVideoMessage
operation to complete the set of operations. The service will now also change its behaviour such that it can only act on
already established CallSession objects. This keeps a clear distinction between where the call control lives and where
the media capabilities are added.
AudioCall will also be extended so that it can manipulate media on an ongoing call (either network or application
initiated) and IVR interactions can occur.
User: A user can be part of many calls, it is important to note that the concept of a user may involve resources such as
voice xml processing equipment and text-to-speech engines.
5.3 Scheduled Short and Multimedia Message Transmission
(#6P11)
Issues and Motivation:
Operators desire the ability to send a short or multimedia message to a large set of subscribers. In addition, operators
would like to provide third parties with the ability to create and schedule transmissions of large sets of message to
increase messaging infrastructure usage.
The current messaging interfaces provide immediate message transmission only and do not allow applications to
schedule message transmission during periods when network messaging resources are less utilized.
The commercial motivation is the ability to increase the volume of successfully delivered messages and the end-user
application experience.
ETSI
---------------------- Page: 9 ----------------------
10 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
Scenarios:
Not applicable.
Requirements Description:
• Schedule the transmission of short messages to multiple destinations.
• Schedule the transmission of multimedia messages to multiple destinations.
• Retrieve the status of a scheduled message transmission request, including the number of messages
successfully sent if a scheduled request is in progress or has completed.
• Cancel a scheduled message transmission request:
- An ability to cancel a scheduled message transmission request has greater business value than an
equivalent function for the existing immediate message transmission function. This is because this new
function will typically be used to request transmission of large sets of messages well in advance of the
scheduled time, resulting in a higher probability of a successful cancellation result and a reduction in
unnecessary messaging resource usage.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function can also be mapped to the existing Parlay/OSA APIs.
5.4 Charging
Issues and Motivation:
The ability to split a charge between multiple end user accounts.
Scenarios:
A multi-player gaming application, where all participants share in the cost.
Requirements Description:
• Support split charging.
Proposed Solution and Further Considerations:
This function is currently implemented in the Parlay/OSA APIs.
This function is also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
5.5 Account Management
Issues and Motivation:
Desire to take proactive measures (e.g. recharging) when an account balance falls below a threshold. Also the ability to
monitor end user account activity: charging and recharging.
Scenarios:
Not applicable
Requirements Description:
• Support account balance related event notifications: charge, recharge, low balance.
Proposed Solution and Further Considerations:
This function is currently implemented in the Parlay/OSA APIs.
ETSI
---------------------- Page: 10 ----------------------
11 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
This function is also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
5.6 Presence
Issues and Motivation:
Currently the Parlay X Presence Web Service provides information to the application on the various means of
communicating with a presentity: e.g. voice, chat, SMS, video etc. However the status of each such means of
communication is not available to the application which limits development of richer applications.
Scenarios:
Not applicable.
Requirements Description:
• For each of the possible means of communicating with a presentity, provide the application also with the
current status of that communication means.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function can also be mapped to the existing Parlay/OSA APIs and SIP/IMS networks.
The proposed solution would add a status element (on, off, busy) to the CommunicationMeans structure.
6 New interfaces and areas of involvement
6.1 Message Broadcast
Issues and Motivation:
Currently, most of the existing Parlay/Parlay X APIs are defined and used for the point-to-point communication such as
TPC, SMS, MMS, etc. But, in some other cases, point-to-multipoint communications - i.e. broadcasting of messages to
everyone who is in certain areas or multicasting of messages to a certain group - could be required and considered as
very useful and efficient communication method.
Message broadcast is a functionality that allows an application to send messages to all the fixed or mobile terminals in a
specific geographical area.
Scenarios:
There are various use cases of using Message Broadcast Web Service including the commercial application. This Web
Service could be also used for non-commercial purposes as follows:
• To provide area-based public information such as weather, traffic and other information of common interest.
• To provide emergency information such as severe weather warnings (e.g. typhoon, tsunami), environmental
hazards (e.g. chemical spills) and terrorism alerts.
ETSI
---------------------- Page: 11 ----------------------
12 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
MMeessassagege B Brrooaaddcascastt
WeWeb Serb Servvicicee
333
PPaarlarlayy X X I/I/FF
MMeesssaginsaging Cg Ceenntterer
SOSOAAPP (e.g., C(e.g., CBBCC))
222
111
mmobilobilee
fifixedxed
bbrrodcastCodcastCoupoupon( )on( )
nenettwwoorrkk
nenettwwoorrkk
{{
arareaea = = se setAtArea();rea();
mmssgg == “2 hours, “2 hours,
2020%% di discount”;scount”;
senderNsenderNaammee == “ “GGAAPP””;;
….….
SShhopop m maannaagegerr
sendBsendBrrooadadccaastMessagstMessagee((aarea, mrea, mssg, g,
sendsenderNerNaame);me);
} }
SMSMSMSSS SMSMSMSSS SMSMSMSSS SMSMSMSSS
SShhoppiopping mng maallll
bubuyy som someeththing (oing (offfflliinnee))
Figure 2
Figure 2 shows an advertising scenario using the Message Broadcast Web Service to broadcast messages describing
shop discount offers inside, and in the vicinity of, a shopping mall. A shop manager who wants to increase sales during
a holiday period can make use of a message broadcast application. By using the application, the manager can set the
targeted area, compose the sales message and identify the shop offering the discount (1). Then, the application uses the
Parlay X interface to invoke the Message Broadcast Web Service operation (2). After invocation, the Message
Broadcast Web Service sends a message delivery operation to the messaging centre, e.g. the CBC (3). Subsequently, the
shop discount message is delivered to all the terminals within the targeted area.
Requirements Description:
• Broadcast a message to a designated area with frequency and interval.
• Retrieve the delivery status of previous broadcast request.
• Cancel the previous broadcast request.
• Be notified when the delivery has been done or is impossible.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function is also supported in the underlying network capabilities, as described in the following
specifications:
• TS 123 041 [6].
• TS 123 032 [7].
• SMPP v5.0 from SMS Forum.
6.2 Multimedia Stream Control
Issues and Motivation:
New terminals are advanced and can now handle streaming media like video clips and music. Operators have invested
in Streaming Servers and a new API is needed to support third party access to these Servers to stream content to
terminals.
An alternative is to download all content to the operator and let subscribers access it via the operator, i.e. the walled
garden approach. Another alternative is to open the network completely. Neither of these are viable options.
ETSI
---------------------- Page: 12 ----------------------
13 Final draft ETSI EG 201 988-4 V1.1.1 (2007-12)
The service provided to an end-user is consumption of streaming multi media. The end-user has a terminal that is able
to request a media stream, either from a built-in player, or an installed application. The terminal can be any terminal
with streaming media playing capabilities, and the service should allow a user to transfer between his terminals.
Scenarios:
• The basic scenario is where an individual is browsing the Internet and finds some interesting content that
he/she wants to watch. The end-user is then ei
...
SLOVENSKI STANDARD
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
01-julij-2008
=OLWHWHOHNRPXQLNDFLMVNHLQLQWHUQHWQHVWRULWYHWHUSURWRNROL]DQDSUHGQRRPUHåHQMH
7,63$1 'RVWRSSRQXGQLNDVWRULWYH 63$ 2GSUWGRVWRSGRVWRULWYH]D]DKWHYH
$3,GHO 5D]OLþLFD
Telecommunications and Internet converged Services and Protocols for Advanced
Networking (TISPAN) - Service Provider Access - Open Service Access for API
requirements - Part 4: Version 4
Ta slovenski standard je istoveten z: EG 201 988-4 Version 1.1.1
ICS:
33.040.01 Telekomunikacijski sistemi Telecommunication systems
na splošno in general
33.080 Digitalno omrežje z Integrated Services Digital
integriranimi storitvami Network (ISDN)
(ISDN)
SIST-V ETSI/EG 201 988-4 V1.1.1:2008 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
---------------------- Page: 2 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
ETSI EG 201 988-4 V1.1.1 (2008-02)
ETSI Guide
Telecommunications and Internet converged Services and
Protocols for Advanced Networking (TISPAN);
Service Provider Access;
Open Service Access for API requirements;
Part 4: Version 4
---------------------- Page: 3 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
2 ETSI EG 201 988-4 V1.1.1 (2008-02)
Reference
DEG/TISPAN-01058-OSA
Keywords
API, architecture, interface, UML
ETSI
650 Route des Lucioles
F-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 C
Association à but non lucratif enregistrée à la
Sous-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 or
perceived 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 drive
within 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://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
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 2008.
All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
ETSI
---------------------- Page: 4 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
3 ETSI EG 201 988-4 V1.1.1 (2008-02)
Contents
Intellectual Property Rights.4
Foreword.4
Introduction .4
1 Scope.5
2 References.5
2.1 Normative references.5
2.2 Informative references.6
3 Abbreviations.6
4 ETSI Phase 4.0/Parlay 6.0 API Domains .6
4.1 Requirements on interfaces at different levels of abstractions .7
4.2 Parlay X Web Service Guidelines .7
5 Proposed enhancements to existing Interfaces.7
5.1 General requirements.7
5.1.1 Backwards Compatibility/Deprecation - Parlay/OSA APIs.7
5.1.2 Backwards Compatibility/Deprecation - Parlay X Web Services.8
5.2 Call Session Control.8
5.3 Scheduled Short and Multimedia Message Transmission (#6P11) .9
5.4 Charging.10
5.5 Account Management.10
5.6 Presence.11
6 New interfaces and areas of involvement.11
6.1 Message Broadcast.11
6.2 Multimedia Stream Control.12
6.3 Extend mobility to include Geocoding.14
6.4 Service Brokering.15
6.5 QoS for end-user/s involved in an application session.16
6.6 Multimedia Multicast Control .17
6.7 Device Capabilities and Configuration.19
Annex A (informative): Bibliography.22
History .23
ETSI
---------------------- Page: 5 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
4 ETSI EG 201 988-4 V1.1.1 (2008-02)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This ETSI Guide (EG) has been produced by ETSI Technical Committee Telecommunications and Internet converged
Services and Protocols for Advanced Networking (TISPAN).
The present document is part 4 of a multi-part deliverable covering Service Provider Access; Open Service Access for
API requirements, as identified below:
Part 1: "Version 1";
Part 2: "Version 2";
Part 3: "Version 3".
Part 4: "Version 4".
Introduction
The present document contains the Requirements capture for ETSI 4.0 "Third Party API" protocol specification:
ES 203 915 series [1] and ES 202 391 series [2].
ETSI
---------------------- Page: 6 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
5 ETSI EG 201 988-4 V1.1.1 (2008-02)
1 Scope
The present document contains the functional requirements for Open Service Access Requirements Version 4.0. The
present document has been compiled in conjunction with Parlay and represents the sixth phase of the Parlay API. The
ETSI and Parlay API have been specified and designed using the requirements identified both in the previously
published Parts of this specification, Parts 1 through 3 and in the present document, Part 4. The requirements are
intended to provide the necessary functionality for benchmark applications.
It is the intention that the new requirements should build upon the ETSI Phase 3.0 API and that of the Parlay 5.0
specification requirements, as described in EG 201 988-3 [3], and should be fully backward compatible. This means
that any network operator implementing ETSI Phase 4.0 or Parlay 6.0 should be able to interwork with a client
application provider implementing ETSI Phase 3.0 or Parlay 5.0. In other words ETSI Phase 4.0 and Parlay 6.0 will
retain ETSI Phase3.0 and Parlay 5.0 as a complete subset. A full description of backward compatibility considerations
is presented in clause 9 of ES 203 915-1 [4]. For any requirement that would result in an extension of, or would build
upon, a part of the API specification set that is published jointly by 3GPP as well, in addition to ETSI and Parlay, the
contributing companies are encouraged to submit their requirements to the 3GPP SA1 requirements process [5].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• Non-specific reference may be made only to a complete document or a part thereof and only in the following
cases:
- if it is accepted that it will be possible to use all future changes of the referenced document for the
purposes of the referring document;
- for informative references.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably,
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the
method of access to the referenced document and the full network address, with the same punctuation and use of upper
case and lower case letters.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are indispensable for the application of the present document. For dated
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document
(including any amendments) applies.
[1] ETSI ES 203 915 (series): "Open Service Access (OSA); Application Programming Interface
(API)".
[2] ETSI ES 202 391 (series): "Open Service Access (OSA); Parlay X Web Services".
[3] ETSI EG 201 988-3: "Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); Service Provider Access; Open Service Access for API
Requirements; Part 3: Version 3".
ETSI
---------------------- Page: 7 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
6 ETSI EG 201 988-4 V1.1.1 (2008-02)
[4] ETSI ES 203 915-1: "Open Service Access (OSA); Application Programming Interface (API);
Part 1 Overview (Parlay 5)".
2.2 Informative references
[5] ETSI TS 122 127: "Universal Mobile Telecommunications System (UMTS); Service Requirement
for the Open Services Access (OSA); Stage 1 (3GPP TS 22.127)".
[6] ETSI TS 123 041: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Technical realization of Cell Broadcast Service (CBS)
(3GPP TS 23.041)".
[7] ETSI TS 123 032: "Digital cellular telecommunications system (Phase 2+); Universal Mobile
Telecommunications System (UMTS); Universal Geographical Area Description (GAD)
(3GPP TS 23.032)".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
ADQ Application Driven Quality of Service
API Application Program Interface
ASP Application Service Provider
BM-SC Broadcast Multicast-Service Centre
CBC Cell Broadcast Centre
GGSN Gateway GPRS Support Node
IP Internet Protocol
IPTV Internetworking Protocol Television
IVR Interactive Voice Response
MMS Multimedia Messaging Service
OSA Open Service Access
SGSN Serving GPRS Support Node
SMS Short Messaging Service
TPC Third Party Control
4 ETSI Phase 4.0/Parlay 6.0 API Domains
The Parlay/OSA API is an open, technology-independent, and extensible interface into networking technologies. The
Parlay API is therefore applicable to a number of business and application domains, not just telecommunications
network operators.
Examples of business domains that may use the API include:
• Third Party NGN Service Providers.
• Interactive Multimedia Service Providers.
• Corporate Businesses.
• Small Businesses.
• Residential Customers.
• Network Operators.
All of these businesses have networking requirements, ranging from simple telephony and call routing to call centre's,
virtual private networks and fully interactive multimedia.
ETSI
---------------------- Page: 8 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
7 ETSI EG 201 988-4 V1.1.1 (2008-02)
4.1 Requirements on interfaces at different levels of
abstractions
As originally defined in clause 6.5 of EG 201 988-3 [3], the OSA-defined functions may be accessed through interfaces
at different levels of abstractions and according to different programming formalisms, in addition to those defined in the
previous Releases. Accordingly, ETSI Phase 3.0 and Parlay 5.0 is realized in two specifications sets:
• OSA APIs (Parlay 5).
• OSA Parlay X 2 Web Services.
For ETSI Phase 4.0 and Parlay 6.0, the requirements described in the present document will likewise be realized in two
specifications sets:
• OSA APIs (Parlay 6): i.e. ES 203 915 series [1].
• OSA Parlay X Web Services: i.e. ES 202 391 series [2].
Guidelines have been adopted to determine which of the two abstraction layers provides the appropriate domain to
realize the requirements described in the present document.
4.2 Parlay X Web Service Guidelines
The interfaces represented by the Parlay X Web Services should be powerful yet simple and highly abstracted. The
following rules serve as guidelines for realizing requirements using Parlay X Web Services. Exceptions to these rules
will be considered if they are justified by simplicity or completeness of the API, and if the resulting specification is
sufficiently differentiated from related specifications.
• A Parlay X Web Service specification will be a functional abstractions of a Parlay/OSA specification. Where a
functionally overlapping Parlay/OSA specification exists, the Parlay X Web Service specification will be an
abstraction of the Parlay/OSA specification.
• Parlay X Web Service specifications should offer a coarser granularity level (e.g. measured as the relative size,
level of detail, or depth of penetration), and contain less than half the methods of the equivalent Parlay/OSA
specifications.
• Parlay X Web Service specifications should not mandate the maintenance of state.
• Parlay X Web Service specifications should not contain asynchronous message exchange, but often include
event notification.
• Parlay X Web Service specifications should never imply detailed protocol knowledge.
• Parlay X Web Service specifications should be functionally self-contained from the developers point of view.
• For any Parlay X Web Service specification, 80 % of the above rules should be met.
5 Proposed enhancements to existing Interfaces
5.1 General requirements
5.1.1 Backwards Compatibility/Deprecation - Parlay/OSA APIs
A full description of backward compatibility considerations is presented in clause 9 of ES 203 915-1 [4].
ETSI
---------------------- Page: 9 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
8 ETSI EG 201 988-4 V1.1.1 (2008-02)
5.1.2 Backwards Compatibility/Deprecation - Parlay X Web Services
For OSA Parlay X 3 Web Services it is desirable, but it is not considered necessary, to retain backwards compatibility
with the existing OSA Parlay X 2 Web Services specifications. This is because the existing specifications are immature
and there are limited implementations and deployments to date. This provide an opportunity to correct identified
shortcomings, and in so doing provide a solution approach that will enable a richer set of applications whilst being
application agnostic in nature.
5.2 Call Session Control
Issues and Motivation:
Operators and vendors desire to extend the call control capabilities of the Parlay X Web Services. The suggested
approach to the evolution of Parlay X Call Control builds on the agreed view of keeping the Parlay X web services true
to the design goal of "Separation of Concerns" and to avoid bundling of functionality where possible. This approach is
not backward compatible with the existing Parlay X Call control-related web services, but this is an acceptable trade-off
as noted in clause 5.1.2.
Requirements Description:
• Call Participant Control. The ability to add, remove, transfer call participants, for either application or network
initiated calls.
• IVR Interaction. Application should be able to request IVR Interaction on a call. It should include simple Play
Announcement and Play and Collect information capabilities for both network and application initiated calls.
• Additional Call Notification events. The following are specifically identified:
- Call Progress.
- Call Setup failure.
- Call Party Disconnect.
- Call Party Answer.
- Call Rejected.
- Media Changed.
• Deassign Call Control. The ability to stop an application from receiving notifications on a specific call.
• Media Control. The ability to manipulate the media on either an application or network initiated call.
Proposed Solution and Further Considerations:
These functions are currently implemented in the Parlay/OSA APIs.
These functions are also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
Figure 1 shows the conceptual principles of how the involved call control elements relate.
ETSI
---------------------- Page: 10 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
9 ETSI EG 201 988-4 V1.1.1 (2008-02)
Figure 1
CallSession: The CallSession object can be used to interact with ongoing calls. It will also serve as a placeholder for a
set of calls. It can be viewed as a call "context" (uniquely identified) to/from which participants can be added/removed.
ThirdPartyCall: The Third Party Call Web Service will now be the only place where application initiated call
processing can and should be performed. This implies removing the call initiation from, for instance, the AudioCall web
service. CallNotification and CallDirection interfaces are updated to support the CallSession concept.
The ThirdPartyCall MakeCall operation will further be enhanced with an optional parameter to indicate which
CallSession the call is to be assigned to. If this parameter is not included in the request, the MakeCall will operate as in
previous versions of Parlay X.
ThirdPartyCall provides the ability to setup a call session, add and delete a call participant, transfer a call participant
from one call session into another call session, determine the status of an individual call participant or a complete call
session, and finally to end a call session.
AudioCall: For the AudioCall service, it is proposed change the name to MediaCall and add a PlayVideoMessage
operation to complete the set of operations. The service will now also change its behaviour such that it can only act on
already established CallSession objects. This keeps a clear distinction between where the call control lives and where
the media capabilities are added.
AudioCall will also be extended so that it can manipulate media on an ongoing call (either network or application
initiated) and IVR interactions can occur.
User: A user can be part of many calls, it is important to note that the concept of a user may involve resources such as
voice xml processing equipment and text-to-speech engines.
5.3 Scheduled Short and Multimedia Message Transmission
(#6P11)
Issues and Motivation:
Operators desire the ability to send a short or multimedia message to a large set of subscribers. In addition, operators
would like to provide third parties with the ability to create and schedule transmissions of large sets of message to
increase messaging infrastructure usage.
The current messaging interfaces provide immediate message transmission only and do not allow applications to
schedule message transmission during periods when network messaging resources are less utilized.
The commercial motivation is the ability to increase the volume of successfully delivered messages and the end-user
application experience.
ETSI
---------------------- Page: 11 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
10 ETSI EG 201 988-4 V1.1.1 (2008-02)
Scenarios:
Not applicable.
Requirements Description:
• Schedule the transmission of short messages to multiple destinations.
• Schedule the transmission of multimedia messages to multiple destinations.
• Retrieve the status of a scheduled message transmission request, including the number of messages
successfully sent if a scheduled request is in progress or has completed.
• Cancel a scheduled message transmission request:
- An ability to cancel a scheduled message transmission request has greater business value than an
equivalent function for the existing immediate message transmission function. This is because this new
function will typically be used to request transmission of large sets of messages well in advance of the
scheduled time, resulting in a higher probability of a successful cancellation result and a reduction in
unnecessary messaging resource usage.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function can also be mapped to the existing Parlay/OSA APIs.
5.4 Charging
Issues and Motivation:
The ability to split a charge between multiple end user accounts.
Scenarios:
A multi-player gaming application, where all participants share in the cost.
Requirements Description:
• Support split charging.
Proposed Solution and Further Considerations:
This function is currently implemented in the Parlay/OSA APIs.
This function is also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
5.5 Account Management
Issues and Motivation:
Desire to take proactive measures (e.g. recharging) when an account balance falls below a threshold. Also the ability to
monitor end user account activity: charging and recharging.
Scenarios:
Not applicable
Requirements Description:
• Support account balance related event notifications: charge, recharge, low balance.
Proposed Solution and Further Considerations:
This function is currently implemented in the Parlay/OSA APIs.
ETSI
---------------------- Page: 12 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
11 ETSI EG 201 988-4 V1.1.1 (2008-02)
This function is also viewed as appropriate for implementation at an abstraction level consistent with that of the
Parlay X Web Services.
5.6 Presence
Issues and Motivation:
Currently the Parlay X Presence Web Service provides information to the application on the various means of
communicating with a presentity: e.g. voice, chat, SMS, video etc. However the status of each such means of
communication is not available to the application which limits development of richer applications.
Scenarios:
Not applicable.
Requirements Description:
• For each of the possible means of communicating with a presentity, provide the application also with the
current status of that communication means.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function can also be mapped to the existing Parlay/OSA APIs and SIP/IMS networks.
The proposed solution would add a status element (on, off, busy) to the CommunicationMeans structure.
6 New interfaces and areas of involvement
6.1 Message Broadcast
Issues and Motivation:
Currently, most of the existing Parlay/Parlay X APIs are defined and used for the point-to-point communication such as
TPC, SMS, MMS, etc. But, in some other cases, point-to-multipoint communications - i.e. broadcasting of messages to
everyone who is in certain areas or multicasting of messages to a certain group - could be required and considered as
very useful and efficient communication method.
Message broadcast is a functionality that allows an application to send messages to all the fixed or mobile terminals in a
specific geographical area.
Scenarios:
There are various use cases of using Message Broadcast Web Service including the commercial application. This Web
Service could be also used for non-commercial purposes as follows:
• To provide area-based public information such as weather, traffic and other information of common interest.
• To provide emergency information such as severe weather warnings (e.g. typhoon, tsunami), environmental
hazards (e.g. chemical spills) and terrorism alerts.
ETSI
---------------------- Page: 13 ----------------------
SIST-V ETSI/EG 201 988-4 V1.1.1:2008
12 ETSI EG 201 988-4 V1.1.1 (2008-02)
MMessageessage Broadcast Broadcast
WeWebb S Seerrvviiccee
333
PaParrllaayy X I/ X I/FF
MMessaessagigingng C Ceentrntere
SOSOAAPP (e.(e.gg., C., CBC)BC)
222
111
mobile mobile
ffiixedxed
brobroddcacastCstCooupuponon( )( )
nenetwtwororkk
nenetwtwororkk
{{
areareaa = = setAsetArreeaa();();
msmsgg = = ““ 2 h2 hourours, s,
20%20% di discoscountunt”” ;;
sensenderderNNaammee = = ““ GA GAPP”” ; ;
…….
SShohop map mananaggerer
sensenddBBrrooadcadcastastMMesessagsagee((aarreeaa, , msmsgg , ,
sensenderderNNaammee););
} }
SMSMSMSSS SMSMSMSSS SMSMSMSSS SMSMSMSSS
SShopping mahopping mallll
bbuuyy s soommeetthhiningg ( (oofflinfflinee))
Figure 2
Figure 2 shows an advertising scenario using the Message Broadcast Web Service to broadcast messages describing
shop discount offers inside, and in the vicinity of, a shopping mall. A shop manager who wants to increase sales during
a holiday period can make use of a message broadcast application. By using the application, the manager can set the
targeted area, compose the sales message and identify the shop offering the discount (1). Then, the application uses the
Parlay X interface to invoke the Message Broadcast Web Service operation (2). After invocation, the Message
Broadcast Web Service sends a message delivery operation to the messaging centre, e.g. the CBC (3). Subsequently, the
shop discount message is delivered to all the terminals within the targeted area.
Requirements Description:
• Broadcast a message to a designated area with frequency and interval.
• Retrieve the delivery status of previous broadcast request.
• Cancel the previous broadcast request.
• Be notified when the delivery has been done or is impossible.
Proposed Solution and Further Considerations:
This function is viewed as appropriate for implementation at an abstraction level consistent with that of the Parlay X
Web Services. This function is also supported in the unde
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.