Working Group Chairman: Peter Randall, Telinco
SPIG Secretary: Jacqui Brookes,
Service Providers Interest Group
Keswick House,
207 Anerley Road,
LONDON,
SE20 8ER
Tel: +44 (0)20 8778 5656
Fax: +44 (0)20 8778 8402
|
Issue date |
Number |
Changes |
|
29th October 1998 |
Issue 1 |
First issue |
|
30th October 1998 |
Issue 2 |
Expanded some descriptions |
|
24th November 1998 |
Issue 3 |
Reordered and updated sections following steering group meeting on 16th November 98 |
|
7th December 1998 |
Issue 4 |
Minor modifications following group meeting of 7th December 98 |
|
26th January 1999 |
Issue 5 |
Minor modification agreed at TIG meeting on 25th January 1999. (Sections 1,3 and 4.) |
|
February 1999 |
Issue 6 |
Proposed text for Network Element Unbundling added. |
|
17th March 1999 |
Issue 7 |
Final edit incorporating agreed Network Unbundling Text |
|
31st March 1999 |
Issue 8 |
Prepared for publication |
This document has been compiled by the Technical Interfaces Group ("TIG") working under the auspices of the NICC during the period from the middle of 1998 to March 1999. It is proposed that a further development of the existing Phase 1 work is carried out to provide enhanced services. These Phase 2 requirements are the scope of this document. Each of the numbered requirements is described in text form and followed by example call flows. Note that this is an incremental upgrade to Phase 1 – i. e. it assumes that all the Phase 1 features are also included. If there is a conflict between the requirements for Phase 1 and Phase 2, then the requirements will be evaluated on a case by case basis.
The fixed network requirements of TIG Phase 1 and the ETSI NA6 Service Provider Access Requirements are applicable to Phase 2, which extends these requirements to include mobile and data networks.
Service and feature interactions need to be considered. This includes interactions between services operated by different service providers, on single and multiple networks, and interactions between service provider and network operator services.
The provisioning or OSS interface needs to be considered and a detailed specification produced. This exercise is outside the scope of this document and of TIG. The Phase 2 interface is referred to as the Service Provider Interface throughout this document.
Disclaimer: No responsibility is taken for the accuracy of the information included in this document. Inclusion of features and requirements in this document does not imply a commitment on the part of any TIG member companies or network operators to support these requirements.
2. Terminal and Line Capability Identification
4. Remotely Provision Features in User Terminals
5. Remote Access to Users’ Terminal Features
6. Suspend/Resume End Customer Charging
7. SP to act as SMS-C for messaging.
10. Monitoring of network events which have impact on service levels
11. Real time charge rate and usage information
SPs require the ability to establish the network location of the SP's end customer from information passed over the interface. This is to be applicable both to fixed and mobile networks including those using non-geographic fixed numbers. This will enable the SP to offer follow-me or personal number type services with the customer location automatically maintained.
Implies use of and access to some form of real time location register in the network. The register keeps real time location data (fixed or mobile). Service Provider interface to allow access to appropriate location register information. This interface must be through non-circuit related signalling or a data communications interface.
Call sequence example
|
Calling user |
SP |
Called user |
|
Switches on mobile or makes outgoing call from fixed phone |
||
|
Polls location register for ‘customer location’. Location register returns location data with date/time stamp of last update |
||
|
Controls routing of calls, etc, to legitimate customer location as appropriate |
2. Terminal and Line Capability Identification
1. SPs require the ability to identify, through the Service Provider Interface ("SPI"), the capabilities of the calling user's terminal and line for each call received. This may be done by means of separate messages since one may be call related and one call unrelated.
2. SPs require the ability to identify, through the SPI, the capabilities of the called user's terminal and line before a call is established between the called and calling users.
Capabilities include: telephony, data, video (analogue or digital).
Note: Network operators do not know terminal capabilities.
OPTION 1: SP proactive in requesting calling user's capabilities.
|
Calling User |
SP |
Called User |
|
Initiates call to SP, e.g. by dialling number. |
||
|
SP requests calling user's terminal and line capabilities, e.g. using in-band negotiation. |
||
|
Calling user supplies calling terminal and line capabilities, or required called terminal and line capabilities. |
||
|
SP continues to process call. |
||
|
SP requests called user's terminal and line capabilities, e.g. by making call to called user and using in-band negotiation. |
||
|
Called user supplies terminal and line capabilities. |
||
|
SP continues to process call. |
||
OPTION 2: Calling user provides terminal and line capabilities automatically.
|
Calling User |
SP |
Called User |
|
Initiates call to SP, e.g. by dialling number, and includes calling user's terminal and line capabilities, or required called user line capabilities. |
||
|
SP receives call with calling user's terminal and line capabilities. |
||
|
SP continues to process call. |
||
|
SP requests called user's terminal and line capabilities, e.g. by making call to called user and using in-band negotiation. |
||
|
Called user supplies terminal and line capabilities. |
||
|
SP continues to process call. |
||
3. Alter Customers’ Profile
1. SPs require the ability to alter, through the Service Provider Interface, the equal access or any other pre-selected routing conditions set up on each of their customers’ profiles. An example of this is the voice messaging service selection.
2. SPs require the ability to make the alterations in (1) above without the need to establish a circuit switched call.
3. Any changed routing arrangements to remain active and current until overridden by a further authorised change to the customers profile.
Call sequence example
|
Service Provider |
Network |
|
SP through the SPI sets up a NCR call to a network management centre. |
|
|
SP issues instructions for a change to its customer’s equal access or carrier pre-selection status. |
|
|
Network management centre validates SP’s request, issues instructions to alter local exchange set-up, or other database. |
|
|
Network management centre sets up a NCR call to Service Provider to acknowledge completion of instruction. |
4. There must be a means of notifying another provider which provider controls the customers profile. To avoid misuse, it should be possible to mark profiles as unavailable or withheld, merely providing the notification rather than the actual data.
4. Remotely Provision Features in User Terminals
1. SPs require the ability, through the SPI, to provision features in user terminals if static or within personality devices, for example SIM cards, which identify the user to a serving network in mobile or portable applications in mobile and fixed networks.
2. It is envisaged that a user would have the ability to move between terminals static or mobile. On insertion of the user’s personality module in a terminal, subject to the capability set of the terminal and the access network, the terminal and/or the access network will take on the personality of the user.
3. When a user’s personality module is inserted in a remote terminal, or if a remote terminal is otherwise identified as being utilised by the user, by reference to the service provider, but without the need to establish a circuit switched call to the relevant network or the service provider, the serving access network will:
OPTION 1 Terminal with provision for SIM or other personality device
|
User |
Access Network |
Service Provider |
|
User inserts personality module in terminal. Terminal sets up a NCR call to access network to request validation of user and other instructions. |
||
|
Access network sets up NCR call to service provider with request for validation of user, user feature set, required mobile access network (if different) address of terminal and instructions for routing outgoing calls. |
||
|
Service provider validates user and returns other requested instructions to access network. |
||
|
Access network sets up NCR call to terminal, validates user to make calls, downloads or invokes feature set, returns identity of access network to use and call routing instructions. |
||
|
Terminal stores personality and instructions in user SIM. |
OPTION 2 Terminal with no provision for personality device
|
User |
Access Network |
Service Provider |
|
User initiates call to SP from the terminal by dialling a number and inputting a PIN. |
||
|
Service provider acknowledges call and validates user. |
||
|
Service provider sets up via the SPI a NCR call to the access network serving the terminal and delivers user feature set, required mobile access network (if different), address of terminal and instructions for routing outgoing calls |
||
|
Access network sets up NCR call to terminal validates user to make calls, downloads or invokes feature set, returns identity of access network to use and call routing instructions. |
. |
|
|
Terminal stores user personality subject to PIN usage on outgoing calls. |
Send outcome of interaction to SP. |
5. Remote Access to Users’ Terminal Features
SPs require the ability to assess and use terminal features remotely in support of calls to or from their customers, e.g. speech recognition embedded in a terminal. Requirement 4 is related to this requirement.
Remote features include for example: voice announcements with tone digit collection, voice announcements with speech recognition, voice announcements, voice recording / playback, generation of screen menus and receipt of user keystrokes.
OPTION 1 Subscriber call
|
Calling User |
SP |
Terminal |
|
Initiates call to SP, e.g. by dialling number. |
||
|
Receive call and determine feature required, e.g. by analysing CdPN. |
||
|
Deliver instructions/data to terminal to activate required feature or provide data to user/terminal |
||
|
Receive instructions/data and activate required feature. |
||
|
Interaction between terminal and user. |
||
|
Send outcome of interaction, or continuous data, to SP. |
||
|
SP continues to process call in accordance with the service specific requirements |
||
OPTION 2 SP initiates call
|
Called User |
SP |
Terminal |
|
Generate call and determine feature required, e.g. from internal database |
||
|
Deliver instructions/data to terminal to activate required feature or provide data to user/terminal |
||
|
Receive instructions/data and activate required feature. |
||
|
Interaction between terminal and user. |
||
|
Send outcome of interaction, or continuous data, to SP. |
||
|
SP continues to process call in accordance with the service specific requirements |
||
6. Suspend/Resume End Customer Charging
Note: whilst the SP may seek to suspend call charging to the end customer, call charges will still be incurred, with those charges being levied against the SP who invoked the suspend.
SPs require the ability to control the application of charging on calls controlled by the SP whilst a call is in progress. It must be possible for SPs to apply fixed or variable charging on a per call leg basis. This would apply where the SP seeks to influence the content of a bill sent by a NO to a customer.
Data flow
|
Calling user |
Network operator |
SP |
Called user |
|
Initiates call controlled by SP, e. g. by dialling number |
|||
|
Reaches a point in call where charging is inappropriate |
|||
|
Requests that end customer charging be suspended |
|||
|
Switches call charges to SP account |
|||
|
Reaches a point in call where charging is appropriate |
|||
|
Requests that end customer charging be resumed |
|||
|
Switches call charges to end customer |
7. SP to act as SMS-C for messaging.
SPs require the functionality to act as a Short Message Service Centre (SMS-C) for messaging. The protocol for incoming and outgoing calls and cell broadcast should each be available separately at the SPI.
8. Element unbundling
(This is similar to 3 above, however goes much further than setting customer profiles)
Service Providers have a requirement for access to unbundled network element functionality. As further unbundled network element functionality becomes available, then Service Providers will need access to that as well.
Non-exhaustive examples of unbundled network element functionality include the ability to access HLRs in a mobile network, or to control line and circuit elements in a fixed network.
The principle is one of access via electronic ordering interfaces to functionality in the network such that the requesting party can construct their own services using elements of, or functionality within, the network, that may be combined with the functionality in the requesting party’s apparatus. It should be noted that such access does not require interconnection to each element to which access is required.
The critical point is to define the unbundled network element functionality which can be used as building blocks for services in such a way that it is both technically feasible for the requested operator to deliver, and also of sufficient granularity to be of use to the service provider in constructing their own services. There may be a number of "layers" of functionality levels below those described as "retail services".
These examples below are non-exhaustive and are provided for illustrative purposes so that readers can further understand the principle involved.
Examples
1. Provisioning and activating available subscriber line services:
2. The ability to vary the mechanism for charging, for example for a £/month charge vs a p/min charge.
3. To gain access to the provisioning mechanism in HLRs, e. g. for provisioning new IMSIs.
4. Providing instructions to the network operator to change the routing table in a particular local exchange for the routing of incoming calls against a particular customer’s line.
5. Providing instructions for the requested operator to provision trigger detection points in the SSP.
Service providers require the ability to initiate and notify the following actions on a per caller basis (e. g. where the functionality equivalent to an external bridge is embedded in the network):
Service providers should be notified of, and be able to respond to, these events when initiated from a terminal or another network
Call flows
|
Participant |
Service Provider |
Network Operator |
Conference administrator |
|
Set up conferees |
|||
|
Receive and process list of participants and preferences |
|||
|
Send data to operator(s) using NCR connection |
|||
|
Receive instructions (may include delayed activation) |
|||
|
Receive call |
Monitor progress, initiate disconnects/reconnects as appropriate |
Monitor conference and manage |
|
|
Connect and disconnect participants as instructed |
|||
|
Request extra features via SP |
|||
|
Process and manage conference |
|||
|
Hang up |
Clear down calls |
||
|
Provide statistics to SP |
|||
|
Process statistics and supply to organiser |
10. Monitoring of network events which have impact on service levels
SP to have visibility of network events detected by the network, e. g. via alarms, quality of service degradation indicators, which could impact the quality of service/service level agreements which the SP provides to its customers. SP would then be able to decide upon action to be taken, if
any, to restore or improve the customers service level, e. g. by re-routing calls.
This is divided into per call and aggregated statistics. Per call information may be delivered before, during or after a call, indicating information such as ability to accept a call, in-call degradation of service, abnormal termination. Aggregated information will be delivered on request or on a regular basis from the operator to the SP via the SPI.
Data flows
|
Service Provider |
Network Operator |
|
Send request for timed delivery of statistics |
|
|
Acknowledge and deliver statistics on time |
|
|
Send request for call availability |
|
|
Acknowledge with viability of call set up requested |
11. Real time charge rate and usage information
Interface: information to be passed either through a NCR signalling transaction or through a data-communications interface.
The charging advice will reflect the charge made by the NO to the NO billed party, where the billed party may be any of the parties to the call, the SP or another NO.
Call flows
|
Calling user |
Network operator |
SP |
Called user |
|
Initiates call controlled by SP, e. g. by dialling number |
|||
|
Requests charging advice |
Receives call |
||
|
Provides charging advice in real time (selected calls) |
|||
|
Call terminates |
|||
|
Call charge advice automatically provided to SP (all calls) |
CdPN | Called Party Number |
| ETSI | European Telecommunications Standards Institute |
| HLR | Home Location Register |
| IMSI | International Mobile Station Identity |
| NCR | Non Circuit Related |
| NO | Network Operator |
| SIM | Subscriber Identification Module |
| SP | Service Provider |
| SPI | Service Provider Interface |
| SMS | Short Message Service |
| SMS-C | Short Message Service Centre |
| SSP | Service Switching Point |