3GPP IMS and UMTS Specifications -- 29.199 OSA Series:
Open Service Access -- Parlay X Web Services
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-01 |
CP |
|
OSA Parlay X Web Services - Part 1: Common |
This TS is Part 1 of the Stage 3 Parlay X Web Services specification for Open Service Access (OSA).
The OSA specifications define an architecture that enables application developers to make use
of network functionality through an open standardized interface, i.e. the OSA APIs.
The concepts and the functional architecture for the OSA are contained in
3GPP TS 23.198.
The requirements for OSA are contained in
3GPP TS 22.127.
The present document specifies the Common aspects of the Parlay X Web Services.
The following are defined here:
- Name spaces.
- Data definitions.
- Fault definitions.
- WSDL Description of the interfaces.
The present document has been defined jointly between 3GPP TSG CT WG5, ETSI TISPAN and The Parlay Group.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-02 |
CP |
|
OSA Parlay X Web Services - Part 2: Third Party Call |
Currently, in order to perform a third party call in telecommunication networks we have to write applications using specific protocols to access Call Control functions provided by network elements (specifically operations to initiate a call from applications). This approach requires a high degree of network expertise. We can also use the OSA gateway approach, invoking standard interfaces to gain access to call control capabilities, but these interfaces are usually perceived to be quite complex by application IT developers. Developers must have advanced telecommunication skills to use Call Control OSA interfaces.
This TS specifies
a Parlay X Web Service, Third Party Call, for creating and managing a call initiated by an application (third party call). The overall scope of this Web Service is to provide functions to application developers to create a call in a simple way. Using the Third Party Call Web Service, application developers can invoke call handling functions without detailed telecommunication knowledge.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-03 |
CP |
|
OSA Parlay X Web Services - Part 3: Call Notification |
Currently, in order to determine the handling of a subscriber initiated call in telecommunication networks we have to write applications using specific protocols to access Call Control functions provided by network elements. This approach requires a high degree of network expertise. We can also use the OSA gateway approach, invoking standard interfaces to gain access to call control capabilities, but these interfaces are usually perceived to be quite complex by application IT developers. Developers must have advanced telecommunication skills to use Call Control OSA interfaces.
This TS specifies
a Parlay X Web Service, Call Notification, for handling calls initiated by a subscriber in the network. A (third party) application determines how the call should be treated. The overall scope of this Web Service is to provide simple functions to application developers to determine how a call should be treated. It is possible to request to end the call, continue the call or re-route the call. Optionally, it is also possible to request the media type(s) when the action is to re-route the call. It provides, for example, the capability to route a call to an IVR in order to play a video stream to the calling subscriber. A service policy determines if multimedia application control is supported.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-04 |
CP |
|
OSA Parlay X Web Services - Part 4: Short Messaging |
Currently, in order to programmatically receive and send SMS it is necessary to write applications using specific protocols to access SMS functions provided by network elements (e.g. SMS-C). This approach requires a high degree of network expertise. Alternatively it is possible to use the Parlay/OSA approach, invoking standard interfaces (e.g. User Interaction or Messaging Service Interfaces) to gain access to SMS capabilities, but these interfaces are usually perceived to be quite complex by IT application developers. Developers must have advanced telecommunication skills to use OSA interfaces.
This TS specifies a Parlay X Web Service, for sending and receiving SMS messages. The overall scope of this Web Service is to provide to application developers primitives to handle SMS in a simple way. In fact, using the SMS Web Service, application developers can invoke SMS functions without specific Telco knowledge.
ShortMessaging provides operations for sending a SMS message to the network and a polling mechanism for monitoring the delivery status of a sent SMS message. It also provides an asynchronous notification mechanism for delivery status. In addition, a mechanism is provided to start and stop the notification of delivery receipts.
ShortMessaging also allows an application to receive SMS messages. Both a polling and an asynchronous notification mechanism are available.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-05 |
CP |
|
OSA Parlay X Web Services - Part 5: Multimedia Messaging |
|
Currently, in order to programmatically receive and send Multimedia Messages, it is necessary to write applications using specific protocols to access MMS functions provided by network elements (e.g. MMS-C). This approach requires application developers to have a high degree of network expertise.
This contribution defines a Multimedia Messaging Web Service that can map to SMS, EMS, MMS, IM, E-mail, etc.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-06 |
CP |
|
OSA Parlay X Web Services - Part 6: Payment |
A vast amount of content, both information and entertainment, will be made available to subscribers. To support a business model that enables operators to offer integrated billing, a payment API is crucial. Open and inter-operable "payment APIs" are the key to market growth and investment protection. The Payment Web Service supports payments for any content in an open, Web-like environment.
The Payment Web Service described in the present document supports payment reservation, pre-paid payments, and post-paid payments. It supports charging of both volume and currency amounts, a conversion function and a settlement function in case of a financially resolved dispute.
Note that certain parameters are negotiated as part of a service level agreement. For example the taxation procedures and parameters.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-07 |
CP |
|
OSA Parlay X Web Services - Part 7: Account Management |
Pre-paid subscribers, whether they have subscribed to pre-paid telephony, SMS, or data service, have credits with their service providers; the consumption of services will lead to reduction of their credit, or the credit may expire.
Therefore, from time to time, subscribers may have to recharge their accounts. This occurs through an application that interfaces with the subscriber either directly or indirectly. Examples of direct interaction are voice prompts and WAP/web pages, or even SMS.
Typically, such multi-modal applications either request a currency amount and, e.g. credit card information, or a voucher number plus credentials. The voucher number and credentials are then validated and causes a pre-determined currency amount to be transferred.
The Parlay X Account Management API described in the present document supports account querying, direct recharging and recharging through vouchers. As a side effect, it may prevent subscribers from having their account balance credits expire.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-08 |
CP |
|
OSA Parlay X Web Services - Part 8: Terminal Status |
Terminal Status provides access to the status of a terminal through:
| - |
Request for the status of a terminal.
|
| - |
Request for the status of a group of terminals.
|
| - |
Notification of a change in the status of a terminal.
|
The status of a terminal can be expressed as reachable, unreachable or busy - however not all terminals distinguish a busy status, so applications should be able to adapt to what information is available (using the service properties to determine available information).
When a request for a group of terminals is made, the response may contain a full or partial set of results. This allows the service to provide results based on a number of criteria including number of terminals for which the request is made and amount of time required to retrieve the information. This allows the requester to initiate additional requests for those terminals for which information was not provided.
This TS specifies the Terminal Status Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-09 |
CP |
|
OSA Parlay X Web Services - Part 9: Terminal Location |
Terminal Location provides access to the location of a terminal through:
| - |
Request for the location of a terminal.
|
| - |
Request for the location of a group of terminals.
|
| - |
Notification of a change in the location of a terminal.
|
| - |
Notification of terminal location on a periodic basis.
|
| - |
Location is expressed through a latitude, longitude, altitude and accuracy.
|
When a request for a group of terminals is made, the response may contain a full or partial set of results. This allows the service to provide results based on a number of criteria including number of terminals for which the request is made and amount of time required to retrieve the information. This allows the requester to initiate additional requests for those terminals for which information was not provided.
This TS specifies the Terminal Location Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-10 |
CP |
|
OSA Parlay X Web Services - Part 10: Call Handling |
The Call Handling Web Service provides a mechanism for an application to specify how calls are to be handled for a specific number. Call handling includes commonly utilized actions:
| - |
Call accepting - only accepting calls from a list of numbers.
|
| - |
Call blocking - blocking calls if they are on a blocking list.
|
| - |
Conditional call forwarding - changing the destination of a call to another number for a specific calling number.
|
| - |
Unconditional call forwarding - changing the destination of a call to another number.
|
| - |
Play audio - initiate audio with the caller (e.g. an announcement or menu).
|
The set of rules are provided to the Web Service which is responsible for establishing the call handling function. Only one action is taken for a call, and once this action is started the rules will stop being processed.
There is a specific order in which these rules are processed, providing a predictable call handling expectation for rules provided. The processing is done as follows.
| 1) |
Call accepting determines if the call is accepted or rejected. If the caller is not on the accept list, the call is rejected and rule processing ends.
|
| 2) |
Call blocking determines if the call is rejected. If the caller is on the block list, the call is rejected and rule processing ends.
|
| 3) |
Conditional call forwarding - each calling number that has a specific forwarding instruction is checked, and the call is forwarded on a match, and rule processing ends.
|
| 4) |
Unconditional call forwarding - the called number is changed to the call forwarding number and rule processing ends.
|
| 5) |
Play audio - the call is handled by a voice system, which handles all further processing of the call. Rule processing ends when the call is handed off.
|
| 6) |
Continue processing call, to complete call to the original called number.
|
If no rules are specified in a particular area, then that step is skipped. If the rule processing ends without any action being indicated, then the call will continue to the called number.
Call Handling provides its function without further interaction with the Application. This is in contrast to the Call Notification interfaces which provide notifications to the Application for processing.
This TS specifies the Call Handling Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-11 |
CP |
|
OSA Parlay X Web Services - Part 11: Audio Call |
This service provides a flexible way to provide multimedia message delivery and the dynamic management of the media involved for the call participants. The interface is very simple, not requiring the developer to manage the creation of the call.
The Audio Call web service allows media to be added/dropped for any ongoing call. This web service also allows interaction with other call control web services (e.g. multimedia conference, third party call), enabling delivery of multimedia to call participants in an ongoing call.
The underlying model of the service is based on the following entities:
| - |
Call Session: a call (uniquely identified) to which participants can be added/removed.
|
| - |
Call Participant: each of the call parties (uniquely identified) involved in the call session.
|
| - |
Media: the call can utilize multiple media types to support the participants' communication. In particular both audio and video streams are available, including the specific stream direction (i.e. incoming, outgoing, bidirectional).
|
There are several mechanisms which may be utilized for the message content:
| - |
Text, to be rendered using a Text-To-Speech (TTS) engine.
|
| - |
Audio content (such as .WAV content), to be rendered by an audio player.
|
| - |
VoiceXML, to be rendered using a VoiceXML browser.
|
| - |
Video, to provide video streaming to the user.
|
| - |
Capture media input from the end user.
|
The service may provide one or more mechanisms, as determined by service policy.
The service allows application control of the call participants' multimedia in a call:
| - |
Allow multiple media types for each participant. In particular both audio and video as well as chat and data.
|
| - |
Add and delete media types.
|
| - |
Control the specific media stream direction (i.e. incoming, outgoing, bidirectional) for each media type.
|
| - |
Get the current media status of a single call participant or for all the call participants in a call.
|
| - |
Control the media interactions for a call participant.
|
A service policy determines if multimedia application control is supported.
This TS specifies the Audio Call Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-12 |
CP |
|
OSA Parlay X Web Services - Part 12: Multimedia Conference |
The Multimedia Conferencing is a simple Web Service that allows the creation of a multimedia conference and the dynamic management of the participants involved.
The underlying model of the service is based on the following entities:
| - |
Conference: a "context" (uniquely identified) to which participants can be added/removed.
|
| - |
Participant: each of the parties involved in the conference. There may exist a participant that is also the "owner" of the conference, i.e. the user who can end the call and/or be the reference user for billing purposes.
|
| - |
Media: the conference can utilize multiple media streams to support the participants' communication. In particular both audio and video streams are available, including the specific stream direction (i.e. in, out, bidirectional).
|
NOTE: A call session allows the application to avail of other web service features that can add value to the created call session. For example the Audio Call web service can provide multimedia message delivery to call participants in the call session (playXXXMessage operation) and furthermore control of the media streams for the call participants thus enabling conversational multimedia communication including voice, video, chat, and data. Media can be added/removed for participants using the operations addMediaForParticipants and deleteMediaForParticipants in Audio Call
An application setting up a multimedia conference must initially invoke the createConference operation. The result of such invocation is the creation of a "context" that represents a "virtual" room where users can "meet". A unique identifier, a callSessionIdentifier is assigned to the just-created conference. At this stage no participant is connected yet.
Subsequently the application may wish to add participants to the conference. In order to do so the operation inviteParticipant can be used. The result of such operation is to alert the user of the incoming connection request (e.g. the user's terminal rings).
If the application wishes to check whether the user has accepted the invitation (i.e. is connected) it can invoke (at a later time) the getParticipantInfo operation.
Note that:
| - |
As soon as the first participant connects, the conference becomes "active". The duration of the conference is then measured starting from the moment the conference has became active.
|
| - |
The initial media set utilized by the participant will depend on the conference type and the media actually supported by the participant's terminal.
|
During the conference session the application is able to:
| - |
Add (or remove) a specific media stream to a single participant: e.g. adding a video bidirectional stream to a participant that has an audio connection to the conference. This can be obtained by invoking the media control (addMediaForParticipants and the deleteMediaForParticipants) operations of the Audio Call web service.
|
| - |
Disconnect a participant from the conference, by invoking the disconnectParticipant operation.
|
| - |
Retrieve information related to the conference and its status, by invoking getConferenceInfo and getParticipants.
|
There are different conditions that can determine the end of the conference:
| 1) |
The application may invoke the operation endConference, that "forces" the termination of the conference and the disconnection of all participants.
|
| 2) |
The owner of the conference (if defined) leaves the conference. If the owner is not defined this condition will apply when all the participants have left the conference (disconnected).
|
| 3) |
The conference duration exceeds a maximum value (specified during the conference creation step).
|
This TS specifies the Multimedia Conference Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-13 |
CP |
|
OSA Parlay X Web Services - Part 13: Address List Management |
The present document defines two related interfaces, one to manage the groups themselves - creation, deletion, query and access right management. The second interface manages the members within a group, supporting add, delete and query operations.
Addresses are not created using this service, they must already exist.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-14 |
CP |
|
OSA Parlay X Web Services - Part 14: Presence |
The presence service allows for presence information to be obtained about one or more users and to register presence for the same. It is assumed that the typical client of these interfaces is either a supplier or a consumer of the presence information. An Instant Messaging application is a canonical example of such a client of this interface.
The OSA/Parlay PAM SCF is the straightforward option and implements the presence server with extended identity, device capability, and presence agent management.
OSA/Parlay PAM allows aggregation of presence information from internet, mobile and enterprise users, etc. using a presence transport network of SIP or XMPP servers. The Presence Web Service can however communicate directly for example with IMS presence network elements (presence and resource list servers) using the ISC (SIP/SIMPLE) protocol interface.
This TS specifies the Presence Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Salim Mounir Alaoui |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-15 |
CP |
|
OSA Parlay X Web Services - Part 15: Message Broadcast |
Message broadcast is a functionality that allows an application to send messages to all the fixed or mobile terminals in a specified geographical area.
Message broadcast provides operations for sending a broadcast message to the network and a polling mechanism for monitoring the delivery status of a sent broadcast message. It also provides an asynchronous notification mechanism for broadcast delivery status.
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 purpose as follows:
| - |
Add (or remove) a specific media stream to a single participant: e.g. adding a video bidirectional stream to a participant that has an audio connection to the conference. This can be obtained by invoking the media control (addMediaForParticipants and the deleteMediaForParticipants) operations of the Audio Call web service.
|
| - |
To provide area-based public information like weather, traffic and other commonly-interested information.
|
| - |
To provide emergency information like severe weather warning (e.g. typhoon, tsunami), environments hazards(e.g. chemical spills) and terrorism information.
|
This TS specifies the Message Broadcast Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: JeongHwan Kim |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-16 |
CP |
|
OSA Parlay X Web Services - Part 16: Geocoding |
Where the Parlay X Terminal Location Web Service provides access to the geographical coordinates at which a terminal is located, the Geocoding Web Service provides access to an additional level of refinement, allowing the service developer to work with actual location addresses and the like:
| - |
Request the location address of a terminal number.
|
| - |
Request the location address of a group of terminals.
|
| - |
Request the distance of a terminal from a specific location address.
|
When a request is made on behalf of a group of terminals, the response may be a full or partial set of results. This allows the service to provide results based on a number of criteria, including number of terminals for which the request is made and amount of time required to retrieve the information. This allows the requestor to initiate additional requests for those terminals for which information was not provided.
This TS specifies the Geocoding Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Hyunkyung Yoo |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-17 |
CP |
|
OSA Parlay X Web Services - Part 17: Application-driven Quality of Service (QoS) |
Application Driven QoS is a service which enables applications to dynamically change the quality of service (e.g. bandwidth) available on end user network connections. Changes in QoS may be applied on either a temporary basis (i.e. for a defined period of time), or as the default QoS to be applied for a user each time they connect to the network.
Applications will govern the quality of service available to the end user by requesting that pre-defined QoS Feature profiles are applied on the end user's connection. It is the responsibility of the Service Provider to define these QoS Features and share them beforehand with application providers, along with a clear indication as to which of these can be used as temporary QoS Features and which can be used to set the default QoS on an end user connection.
This TS specifies the Application-driven Quality of Service (QoS) Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Darren Gunning |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-18 |
CP |
|
OSA Parlay X Web Services - Part 18: Device Capabilities and Configuration |
The Parlay X Device Capabilities and Configuration Web Service will allow applications to get information about device capabilities and push device configuration to a device.
An application retrieves the device capabilities of a user's device by providing their phone number. The device capabilities are described by a user profile XML file, which URL is stored in the DeviceCapability structure returned when the capabilities are requested. In addition there is an operation to get the equipment identifier of the device. (The operation to get the device identifier is in a separate call, in case there is a wish to restrict this information more than the device capabilities.)
In addition it is possible to set up notification for device identifier changes and receive the notifications when the device identifier changes.
The application pushes the device configuration to a user's device by providing their phone number and the configuration (chosen from a list of available configurations.) The application can get the list of available configurations for a given device and the history of the configurations previously pushed to the user's device.
This TS specifies the Device Capabilities and Configuration Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Gaute Nygreen |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-19 |
CP |
|
OSA Parlay X Web Services - Part 19: Multimedia Streaming Control |
The service provided to an end-user is consumption of streaming Multimedia. 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.
| - |
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 second case, the content provider redirects the request to the operator, so that the terminal capabilities can be collected and charging is done, before the stream is started.
|
| - |
One scenario is an individual watching his favourite sports stream on his TV or PC at home, but he/she must leave the house of some reason, and still wants to continue the session on his mobile terminal. In that case he/she would transfer the ongoing session to the other terminal with other capabilities, since he already paid for the entire episode.
|
| - |
The other way is a similar case where an individual arrives at a destination with better viewing capabilities.
|
This TS specifies the Multimedia streaming control Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Sune Jakobsson |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-20 |
CP |
|
OSA Parlay X Web Services - Part 20: Multimedia Multicast Session Management |
The Multimedia multicast session management Web Service allows for a third party (e.g. application) to control a multicast session, its members and multimedia stream, and obtain channel presence information.
The Multimedia multicast session management is a simple Web Service consisting of three interfaces:
| - |
Multicast: the management of sessions and user participation in sessions
|
| - |
Multicast Notification: delivering channel presence information events to the application, as users join or leave multicast sessions
|
| - |
Multicast Notification Manager: providing on-line set up and tear down of notifications for channel presence information events
|
NOTE: For control of a multimedia stream associated with a multicast session (e.g. start/stop/pause/resume), a third party (e.g. application) invokes the appropriate operations defined in 3GPP TS 29.199-19.
The GPRS Packet network or IP Multicast Network delivers multimedia multicast streams from a multimedia source to users who are already participating in multicast sessions. The basic scenario is as follows:
An application creates a multicast session for personal broadcasting and plays the multicast stream. A unique identifier (i.e. multicast address) is assigned to the just-created multicast session. The user participating in the multicast session for personal broadcasting may wish to invite their friends to participate in the session. If the invited friends accept this invitation request, they see the same program for personal broadcasting on their terminals. They usually communicate with each other by using a multimedia over IP while they are participating in the same session. Furthermore the application monitors user participation status (i.e. joining or leaving the multicast session) using a notification mechanism. For example, if a friend has left the session, the application is notified.
This TS specifies the Multimedia multicast session management Web Service aspects of the interface.
|
|
|
| |
| Up |
Rapporteur: Chang Sup Keum |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-21 |
CP |
|
OSA Parlay X Web Services - Part 21: Content Management |
The content management web service enables uploading content into the network (or a third party content provider) and consuming content from the network (or a third party content provider). This functional element stores and manages the meta-data associated with content elements. It provides interfaces to submit, modify and delete content entries. It also provides interfaces to query for content items including content identifier, meta data, control data and content upload date (matching specific criteria).
The network entities composed of content management web service are service portal, parlay X gateway, content server, streaming server and end user. End user uses the service portal that provides or consumes contents. The content server functions as a content storage and a management system in the network.
|
|
|
| |
| Up |
Rapporteur: Hyunkyung Yoo |
|
|
|
|
|
|
|
|
| | |
3GPP TS 29.199
-22 |
CP |
|
OSA Parlay X Web Services - Part 22: Policy |
The Policy Web Service is defined to offer provisioning and evaluation functions for policies. This Specification is separated into four interfaces.
| - |
PolicyProvisioning interface includes the operation to create, modify, view, and delete policies.
|
| - |
PolicyEvaluation interface provides operations to request evaluation of policies.
|
| - |
PolicyEventNotificationManager interface provides functions for starting and ending subscription of the notification about events.
|
| - |
PolicyEventNotification interface is defined for delivering the notification to the application when the event occurs.
|
|
|
The Policy Web Service is defined to provide simple means for applications to make use policies to satisfy two purposes as follows:
|
|
| - |
The first one is to provide the user defined policies for the 3rd party applications who want to personalize their services by using their own preference expressed as policies at a high level. At this level, policies could be defined and managed by 3rd party applications, and applied to any policy enabled service.
|
| - |
The second one is to protect resources in network from unauthorized requests based on policies, therefore enables the network operators and service providers to control the access to their resources. Network resources can be accessed in a secure and controlled way and network operator could impose constraints on the usage of their services.
|
|
|
|
| |
| Up |
Rapporteur: Yongjoo Lee |
|
|
|
|
|
|
|
|
|
|
