Internet DRAFT - draft-brusilovsky-spirits-is41
draft-brusilovsky-spirits-is41
On selection of IS-41 SPIRITS mobility-related parameters [Page 1]
Internet Engineering Task Force SPIRITS WG
Internet Draft
draft-brusilovsky-spirits-is41-00.txt
February 2003
Expires: August 2003 Alec Brusilovsky
Artcare
On selection of IS-41 SPIRITS mobility-related parameters
draft-brusilovsky-spirits-is41-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups
may also distribute working documents as Internet-Drafts. Internet
-Drafts are draft documents valid for a maximum of six months and may
be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes IS-41 mobility-related parameters (WIN
information and its encoding) which the SPIRITS protocol can
transport from the PSTN (wireline, as well as wireless) into the IP
network. The SPIRITS protocol is a protocol through which PSTN can
request actions (services) to be carried out in the IP network in
response to events occurring within the PSTN/IN (wireline, as well as
wireless). This draft outlines, what IS-41 mobility-ralated
parameters are of immediate interest to SPIRITS, how they may be
extracted and encoded for use within the SPIRITS domain. IS-41 is
used as an example protocol to clarify the SPIRITS message encoding
process. This Internet-Draft has been written in response to the
SPIRITS WG chairs' call for SPIRITS Protocol proposals. It may be
viewed as being a direct contribution to the Informational RFC on the
SPIRITS protocol parameters. Section 1 of this document gives
background of wireless cellular communication networks, including
Core Networks, Section 2 gives a backgrouder for the Wireless
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 2]
Intelligent Network (WIN). Sections 3 and 4 briefly explain WIN
Functional and Physical entities. Section 5 provides WIN BCSM
Description. Section 6 gives ASN.1 Notation for the selected WIN
Parameters. Sections 7, 8, 9, 10 and 11 respectively provide
Acknowledgements, References, Author's Address, Acronyms and Full
Copyright Statement, as required. Addendum 1 contains figures.
1. Introduction
1.1 Brief history of cellular wireless technology
The history of existing cellular wireless systems can be easily
broken down into generations:
1.1.1 First Generation - 1G:
- Advanced Mobile Phone Service (AMPS) - Still used in the US and
many parts of the world; US trials 1978; deployed in Japan (1979) &
US (1983) Carrier frequency: 800 MHz band û two 20 MHz bands
Standard: TIA-553
- Nordic Mobile Telephony (NMT) - Sweden, Norway, Demark & Finland
Launched 1981; now largely retired Carrier frequency: 450 MHz; later
at 900 MHz (NMT900)
- Total Access Communications System (TACS) - some TACS-900 systems
still in use in Europe British design; similar to AMPS; deployed 1985
1.1.2 Second Generation û 2G (and 2.5G as well): Digital systems that
leverage technology to increase capacity and utilize speech
compression; digital signal processing. In addition, 2G systems take
advantage and extend traditional wireline IN concepts to improve
fraud prevention and add new services.
There are a wide diversity of 2G systems:
- IS-54/ IS-136 North American TDMA; PDC (Japan) Speech coded as
digital bit stream - compression plus error protection bits
(aggressive compression limits voice quality) Time division multiple
access (TDMA) - 3 calls per radio channel using repeating time
slices. Deployed in 1993 (PDC 1994), developed through 1980s;
bakeoff in 1987; it is IS-54 / IS-136 standard in the US (TIA) ATT
Wireless & Cingular use IS-136 today and plan to migrate to GSM and
then to W-CDMA PDC dominant cellular system in Japan today - NTT
DoCoMo has largest PDC network
- iDEN Used by Nextel (Motorola proprietary technology), utilises
time division multiple access technology and based on GSM
architecture Carrier frequency: 800 MHz Private Mobile Radio (PMR)
spectrum IDEN's specialised networking protocol supports fast
ôPush-to-Talkö - digital replacement for old PMR services.
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 3]
- Dect - Digital European Cordless Telephony - Based on time division
multiple access technology. Focused on business use, i.e., wireless
PBX, very small cells; prone to in building RF propagation issues.
Relatively wide bandwidth (32 Kbps channels) - high quality voice
and/or ISDN data.
- PHS - Personal Handiphone Service is similar performance (32 Kbps
channels) to DECT and is deployed across Japanese cities (with high
pop. density). 4 channel base station uses one ISDN BRI line base
stations on top of phone booths. PHS is legacy in Japan; New
deployments spotted recently in China.
- IS-95 CDMA (CDMAOne) Code Division Multiple Access - all users
share same frequency band. Qualcomm demoed CDMAOne in 1989 Magor
improvements: better capacity & simplified planning First deployment
in Hong Kong late 1994 Deployed by Verizon Wireless and SprintPCS in
the US TIA standard IS-95 (ANSI-95) in 1993 Carrier frequency: IS-95
deployed in the 800 MHz cellular band, J-STD-08 variant deployed in
1900 MHz in the US ôPCSö band IS-95A provides data rates up to 14.4
kbps IS-95B provides rates up to 64 kbps (2.5G) All CDMAOne variants
designed for TIA IS-41 core networks (ANSI 41)
- GSM "Groupe Special Mobile", later changed to "Global System for
Mobile" - joint European effort beginning in 1982 and focused on
seamless roaming across Europe. First GSM Services launched 1991.
Utilizes time division multiple access (8 users per 200KHz) Carrier
frequency: 900 MHz band, later extended to 1800MHz and added 1900 MHz
(US PCS bands) GSM is dominant world standard today due to well
defined interfaces and great availability of equipment.
1.2 Core Network technology Two types of widely deployed core
networkarchitecture exist today:
- GSM-MAP - is used by GSM operators. ôMobile Application Partö
defines extra (SS7-based) signaling for mobility, authentication,
prepaid charging, etc. - ANSI-41 MAP -- used with AMPS, TDMA &
CDMAOne. TIA (ANSI) standard for ôcellular radio telecommunications
inter-system operationö. Both GSM MAP and ANSI-41 are based on SS7
ISUP and specific SS7 Application Parts and are responsible for
mobility, call-handling and network services, such as O&M,
authentication, supplementary services SMS, etc.
1.3 WIN Concepts
The Wireless Intelligent Network (WIN) concepts have been developed
based on the rapid emergence of cellular networks over the past two
decades [2]. The basic requirement of a mobile network is to provide
its users with the ability to initiate and receive calls regardless
of their location. From the service provider perspective, such
capabilities also allowed the use of IN not only to provide
point-to-point telephony, but also to incorporate capabilities for
rapid introduction of new services and customization of such services
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 4]
according to the subscriber needs. The WIN architecture provides a
framework for interruption of call processing at triggers, and
querying databases to determine the treatment of the call, depending
on the provisions made by the subscriber and the service provider.
The WIN architecture is structured so that the triggers and
signaling can be made independent of specific services, so that the
services can be constructed using external service logic. The WIN
emphasizes open interfaces, so that the end user can roam across
service provider networks that may have been integrated by different
equipment providers but interoperate to provide transparency of
service capabilities. These capabilities are determined by the
special agreements between the service providers. This level of
interoperability and transparency has led to significant efforts in
the standardization of INs for wireless systems, and are embodied in
the IS-41 set of standards published by the Telecommunications
Industry Association (TIA).
The Wireless network reference model (Figure 1) is described in [2].
The Mobile Station, Base Station, Mobile Switching Center,
Authentication Center, Home Location Register (HLR), and Visitor
Location Register (VLR) (see Fig. 1.3) are conventional elements of
the cellular wireless access networks.
A Mobile Station is the interface equipment used to terminate the
radio path at the user side. It is the Mobile Station that provides
a user with the capabilities to access network services. The
authentication information related to a particular Mobile Station is
managed by an Authentication Center.
The Mobile Switching Center is a Service Switching Point (SSP) for
wireless networks, and it is the point in the network that detects
the IN triggers. The Mobile Switching Center also constitutes the
interface for user traffic between the wireless network and other
public switched networks, as well as to other Mobile Switching
Centers.
A subscriberÆs identity is assigned to an HLR, which keeps the
subscriberÆs (and his or her Mobile Station) information and provides
service control and mobility management for one or more Mobile
Switching Centers on behalf of the subscriber. An HLR may be located
within the Mobile Switching Center (Standalone HLR); it may also be
located within a Service Control Point.
A VLR is used by a Mobile Switching Center to retrieve information
for handling calls to (or from) a visiting user. A VLR provides
mobility management for one or more Mobile Switching Centers on
behalf of a subscriber in visited networks. Similarly to an HLR, a
VLR may be located within the Mobile Switching Center.
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 5]
2. IN and WIN, WIN services
The Wireless Intelligent Network (WIN) is a network which supports
the use of intelligent network capabilities to provide seamless
terminal services, personal mobility services and advanced network
services in the mobile environment. Intelligent network capabilities
are all those functional capabilities which support creation and
execution of service logic programs which reside outside of switching
equipment, but work in collaboration with the switching equipment
based upon a common definition of call models and protocols. These
service logic programs may utilize data resources and physical
resources which also reside outside of the switching equipment.
Terminal mobility services are services created using intelligent
network capabilities to serve customers with mobile terminals. A set
of these services will be associated with each mobile terminal based
on the capabilities of the terminal and subscription selections.
Some prerequisites of providing these services are the abilities to
identify and authenticate the terminal and to provide seamless
operations capabilities between wireless and wireline networks.
Personal mobility services are services created using intelligent
network capabilities to serve customers who are mobile. A set of
these services will be associated with each customer based on
personal subscription selections. The customer may utilize a variety
of mobile and fixed terminals at different locations. Some
prerequisites of providing these services are the abilities to: ò
identify and authenticate the person (subscriber) who has been
provisioned for the service ò provide seamless operations
capabilities among the wireless, fixed and other networks (e.g.,
broadband, internet, data networks) ò provide a unique set of
services to the subscriber based on the subscriberÆs access point to
the WIN service
2.1 Advanced network service has the functionality to identify the
capability of the serving network, to provide service based on the
network and terminal capability, and to provide seamless service
mobility between wireless and wireline networks. The basic
difference between terminal mobility service, personal mobility
service and advanced network service is as follows: ò Terminal
mobility services: services based on the terminal capability
irrespective of the terminal user. ò Personal mobility services:
services based on personal needs or business entity needs
irrespective of terminals or networks. ò Advanced network services:
customized services which can be provided ubiquitously in home or
roaming networks (wireless or wireline).
2.2 Service management functionality is used to provision and manage
the service control functionality, the service data functionality,
and the specialized resource functionality in the network. Service
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 6]
creation functionality is used to create services. Service
management and service creation functionality may use standardized
interfaces. However, the ability of a service subscriber to interact
directly with subscriber-specific service management information will
not be excluded or constrained for WIN.
2.3 The functions required to support the desired wireless services
include:
ò end user access to call and service processing
ò service invocation and control
ò end user interaction with service control
ò service management
The scope of each of these functions is described below.
2.3.1 End User Access End user access to call and service processing
will be provided via the following access arrangements: ò line
interfaces that are provided by radio access systems
ò traditional trunk and SS7 interfaces
ò other types of network access arrangements such as roamer ports
2.3.2 Service Invocation and Control Call and service processing for
WIN builds upon the call processing infrastructure of existing MSCs.
It does so by using a generic model of existing call control
functionality to process basic two-party calls, then adding service
switching functionality to invoke and manage WIN service logic. Once
invoked, WIN service logic is executed under the control of service
control functionality in conjunction with service data
functionality. With this distributed approach to call and service
processing, the existing call control functionality retains ultimate
responsibility for the integrity of calls, as well as for the control
of call processing resources.
The following call and service processing constraints apply for WIN:
a) Call control and service switching functionality are tightly
coupled in the MSC, thus the relationship between SSF and CCF is not
standardized.
b) A call is either between two or more end users that are external
to the network and addressable via a directory number or combination
of directory number and bearer capability, or a call is between one
or more end users and the network itself.
c) A call may be initiated by an end user, or by an SCF within the
network on behalf of an end user. To supplement a call, WIN service
logic may either be invoked by an end user served by a WIN MSC, or by
the network on behalf of an end user.
d) A call may span multiple MSCs. As such, each MSC only controls the
portion of the call in that MSC. Call processing is functionally
separated between MSCs. WIN service logic invoked on WIN MSCs in such
an inter-MSC call are managed independently by each WIN MSC.
e) MSCs can be viewed as having two functionally separate sets of
call processing logic that coordinate call processing activities to
create and maintain a basic two-party call. This functional
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 7]
separation is provided between the originating portion of the call
and the terminating portion of the call. This functional separation
should be maintained in a WIN MSC to allow WIN service logic invoked
on the originating portion of the call (i.e. on behalf of the calling
party) to be managed independently of WIN s ervice logic invoked on
the terminating portion of the call (i.e. on behalf of the called
party).
f) It is desirable to allow multiple WIN-supported service logic
instances to be simultaneously active for a given end user. It is
also recognized that non-WIN service logic will continue to exist in
the network. As such, service feature logic instances mechanisms for
WIN should:
û determine which service logic to invoke for a given service
request. This mechanism should select the appropriate WIN-supported
service logic or non-WIN-supported service logic, and block the
invocation of any other service logic for that particular service
request;
û manage WIN- and non-WIN-supported service logic instances which are
simultaneously active (this may require limiting the service logic
instances which are active);
û ensure that simultaneously active WIN-supported service logic
instances adhere to single-ended, single point of control service
processing.
g) The distributed approach and added complexity of call and service
processing for WIN requires mechanisms for fault detection and
recovery, allowing graceful termination of calls and appropriate
treatments for end users.
2.3.3 End User Interaction End user interaction with the network to
send and receive information is provided by service switching and
call control resources, augmented by specialized resources. These
specialized resources are controlled by service control
functionality, and are connected to end users via call control and
service switching functionality.
2.3.4 Service Management Service management functionality is used to
provision and manage the service control functionality, service data
functionality, and specialized resource functionality in the network,
outside of the context of call and service processing. Standardized
interfaces for this functionality are outside the scope of WIN.
However, the ability of a service subscriber to interact directly
with subscriber-specific service management information will not be
excluded or constrained for WIN.
3. WIN Functional Entities
The WIN functional entities provide the following functionality:
3.1 Authentication Control Function (ACF) The Authentication Control
Function (ACF) provides the service logic and service data function
to provide authentication, voice privacy and signaling message
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 8]
encryption functions. The ACF:
a) interacts with the SCF, LRFH, LRFV, RACF and other ACF functional
entities for the authentication of mobile stations.
b) maintains the authentication parameters for the MS c)
authenticates the MS access.
d) computes the voice privacy mask and signaling message encryption
key for MS origination and page response accesses.
e) updates the MSÆs authentication parameters.
f) provides trigger mechanisms to access WIN service logic (for
further study).
3.2 Call Control Function (CCF) The Call Control Function (CCF)
provides call and service processing and control. The CCF:
a) establishes, manipulates and releases call and connection as
requested by the MACF, RACF, RCF and by other CCF functional
entities;
b) provides the capability to associate and relate RCF functional
entities, and other CCF functional entities that are involved in a
particular call and/or connection instance (that may be due to SSF
requests);
c) manages the relationship between RCF functional entities and
between other CCF functional entities involved in a call (e.g.
supervises the overall perspective of the call and connection) d)
interacts with the MACF and RACF to establish an information exchange
path (e.g., call delivery, short message delivery) to an MS;
e) provides trigger mechanisms to access WIN functionality (e.g.,
passes events to the SSF).
3.3 Location Registration Functions (LRFH, LRFV) The Location
Registration Function (LRF) provides the service logic and service
data function to manage the mobility aspects for wireless users.
There are two complementary LRF FEs: LRFH and LRFV. The LRFH:
a) interacts with the LRFV and MACF1 functional entities to maintain
the location and active/inactive status for mobile stations;
b) maintains the subscriber profile (e.g., switch-based features,
triggers) and interacts with the LRFV functional entity to transfer
and update the subscriber profile;
c) interacts with the LRFV functional entity to provide a routing
address for establishment of an information exchange path (e.g., call
delivery, short message delivery);
d) interacts with the ACF functional entity to provide
authentication, voice privacy and signaling message encryption for
mobile stations;
e) maintains mobile station access information (e.g., SMS pending
flag).
f) provides trigger mechanisms to access WIN service logic at an SCF
The LRFV:
a) interacts with the LRFH and MACF functional entities to maintain
the location and active/inactive status for mobile stations;
b) stores the subscriber profile (e.g., switch-based features,
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 9]
triggers) and interacts with the LRFH and the MACF functional
entities to transfer and update the subscriber profile;
c) interacts with the LRFH and the MACF functional entities to
provide a routing address for establishment of an information
exchange path (e.g., call delivery, short message delivery);
d) interacts with the ACF functional entity to provide
authentication, voice privacy and signaling message encryption for
mobile stations;
e) at the request of the LRFH functional entity, interacts with the
MACF functional entity to provide mobile station notification
information;
f) provides trigger mechanisms to access WIN service logic at an SCF;
3.4 Mobile Station Access Control Function (MACF) The Mobile Station
Access Control Function (MACF) stores subscriber data and dynamically
associates system resources with a particular set of call instance
data. The MACF:
a) interacts with the LRFH1, LRFV and RACF functional entities to
maintain the location and active/inactive status for mobile stations;
b) stores the subscriber profile (e.g., switch-based features,
triggers) and interacts with the SSF/CCF and with the LRFV functional
entities to transfer and update the subscriber profile;
c) provides subscriber profile information (e.g., switch-based
services, triggers) and authorization information to the CCF and RACF
functional entities;
d) maintains the mobile station access information (e.g., SMS pending
flag);
e) interacts with the RACF and LRFV functional entities to provide a
routing address for establishment of an information exchange path
(e.g., call delivery, short message delivery) to an MS f) interacts
with the RACF functional entity to establish an information exchange
path (e.g., call delivery, short message delivery) to an MS;
g) interacts with the RACF functional entity to verify the presence
of the mobile station;
h) at the request of the LRFV functional entity, interacts with the
RACF functional entity to provide mobile station notification
information;
i) interacts with the LRFV functional entity to provide the paging
strategy to the RACF functional entity to verify the presence of the
mobile station;
j) provides trigger mechanisms to access WIN service logic;
3.5 Radio Access Control Function (RACF) The Radio Access Control
Function (RACF) provides the service logic and service data
functionality specifically related to the radio link. The RACF:
a) interacts with the CCF, ACF, MACF, RCF and with other RACF
functional entities in the processing of call, non-call, or service
related functions;
b) interacts with the CCF and MACF to establish an information
exchange path (e.g., call delivery, short message delivery) to an MS;
c) interacts with the ACF to authenticate the MS access;
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 10]
d) interacts with the MACF to provide a routing address for
establishment of an information exchange path (e.g., call delivery,
short message delivery);
e) manages the RCF functions for associated RCFs;
f) provides radio access control functions such as assignment of
radio resources;
g) interacts with the associated RCF and with other RACF functional
entities to coordinate handoff activities, including the
determination of target RCFs, handoff decision and handoff
completion;
h) interacts with other RACF functional entities to process border
cell operations;
i) contains service logic functionality to handle service requests
that are specific to radio bearer requirements;
j) executes mobile station paging;
3.6 Radio Control Function (RCF) The Radio Control Function (RCF)
provides the radio port and radio port control. The RCF:
a) establishes, manipulates and releases call/connection as
ôrequestedö by the RACF, CCF, and RTF;
b) provides radio functions including carrier generation, signal
amplification, selective filtering, modulation and demodulation,
radio channel assignment and supervision;
c) provides interconnection between the radio and network bearer
connections;
3.7 Radio Terminal Function (RTF) The Radio Terminal Function (RTF)
provides access for wireless users. It is the interface between the
wireless user and network call control functions. The RTF:
a) provides for user access, interacting with the user to establish,
maintain, modify and release as required, a call or instance of
service;
b) interacts with the Radio Control Function (RCF) using service
requests (e.g., setup, transfer, hold, etc.) for the establishment,
manipulation and release of a call or instance of service;
c) receives indications relating to the call or service from the RCF
and relays them to the user as required;
d) maintains call and service state information as perceived by this
functional entity;
3.8 Service Control Function (SCF) The Service Control Function (SCF)
commands call control functions in the processing of WIN provided and
custom service requests. The SCF may interact with other functional
entities to access additional logic or to obtain information (service
or user data) required to process a call and service logic instance.
The SCF:
a) interfaces and interacts with service switching function/call
control function;
b) contains the logic and processing capability required to handle
WIN provided service attempts;
c) interfaces and interacts with other SCFs for secured data
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 11]
acquisition and manipulation, distributed service control and
unsolicited service notifications, if necessary;
d) interfaces and interacts with SDFs for data acquisition and
manipulation of data;
e) interfaces and interacts with SRFs;
3.9 Service Creation Entity Function (SCEF) The Service Creation
Entity Function (SCEF) provides the capability for the creation,
verification, and testing of WIN services. The output of the SCEF
includes service logic and service data templates.
3.10 Service Data Function (SDF) The Service Data Function (SDF)
contains customer and network data for real-time access by the SCF in
the execution of WIN-provided services. The SDF interfaces and
interacts with SCFs as required. The SDF contains data relating
directly to the provision or operation of WIN-provided services, thus
it does not necessarily encompass data provided by a third party such
as credit information, but may provide access to the data.
3.11 Service Management Access Function (SMAF) The Service Management
Access Function (SMAF) provides the human interface to service
management functions.
3.12 Service Management Function (SMF) The Service Management
Function (SMF) provides overall service management functionality for
the network. The SMF may interact with any or all of the other FEs
to perform service provisioning, monitoring, testing, and subscriber
data management functions.
3.13 Service Switching Function (SSF) The Service Switching Function
(SSF) is associated with the CCF and provides the set of functions
required for interaction between the CCF and a service control
function (SCF). The SSF:
a) extends the logic of the CCF to include recognition of service
control triggers and to interact with the SCF;
b) manages signaling between the CCF and the SCF;
c) modifies call and connection processing functions (in the CCF) as
required to process requests for WIN provided service usage under the
control of the SCF;
3.14 Specialized Resource Function (SRF) The Specialized Resource
Function (SRF) provides the specialized resources required for the
execution of WIN-provided services (e.g., digit receivers,
announcements, conference bridges, etc.). The SRF:
a) interfaces and interacts with SCF and SSF (and with the CCF);
b) may contain the logic and processing capability to receive, send
and convert information received from users;
c) may contain functionality similar to the CCF to manage bearer
connections to the specialized resources;
4. Network Physical Entities
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 12]
Intelligent Peripheral (IP) The IP is an entity that performs
specialized resource functions such as playing announcements,
collecting digits, performing speech-to-text or text-to-speech
conversion, recording and storing voice messages, facsimile services,
data services, etc.
Service Control Point (SCP) The SCP is an entity that acts as a
real-time database and transaction processing system to provide
service control and service data functionality.
Service Node (SN) The SN is an entity that provides service control,
service data, specialized resources and call control functions to
support bearer related services.
5. WIN BCSM Description
The BCSM described here is based on the overall BCSM in Section 4 of
Q.1224 [17, 18], refined as applicable for WIN. It reflects the
functional separation between the originating and terminating
portions of calls as illustrated in Figures X and X (To be done later
-A.B.). These figures show an originating half BCSM and a terminating
half BCSM, each of which is managed by a functionally separate Basic
Call Model in the SSF/CCF. The description is a starting point to
identify the aspects of the BCSM that are
visible to WIN service logic instances. In order to maintain
uniqueness of DP names between the originating and terminating half
BCSMs, ôOö and ôTö is prefixed to certain originating and terminating
DP names, respectively. Certain PICs correspond to switch-based
service feature functionality, and thus are not ubiquitous among all
switching systems. They are denoted ôoptionalö to reflect the
current understanding.
The BCSMs described in this section show normal call flow progression
and the more commonly encountered exception conditions. For ease of
reference, the DPs associated with the transition implied by each
entry and exit event for each PIC are listed along with the PIC
descriptions.
5.1 Originating BCSM The originating half of the BCSM corresponds to
that portion of the BCSM associated with the originating party. The
descriptions for each of the PICs in the originating half of the BCSM
are described below:
5.1.1 O_Null
Entry Event:
û Disconnect and clearing of a previous call. (DPs: O_Disconnect and
O_Abandon).
û Default handling of exceptions by SSF/CCF completed (Transition
from O_Exception PIC).
Functions:
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 13]
û Clear any resources allocated to the originating party (no call
exists, no call reference exists, no radio channel allocated for
call, etc.).
Exit Event:
û Indication of a desire to place an outgoing call (e.g., an
indication is received from the RACF of an origination attempt by an
MS user).
(DP: Origination_Attempt).
û Other indication from an originating party of a desire to place a
call (e.g., ISDNUP IAM message). (DP: Origination_Attempt).
û The following exception exit event is applicable to the O_Null PIC.
For this PIC, if the call encounters this exception during O_Null PIC
processing, the exception event is not visible because there is no
corresponding DP.
i) The O_Abandon occurs when the calling party disconnects.
5.1.2 Authorize_Origination_Attempt
Entry Event:
û An indication is available that the originating MS needs to be
authorized (DP: Origination_Attempt).
Functions:
û Collects the information required to authorize the call for MS
origination.
û The originating MS rights are checked using the MS identity and
service profile.
The right of the MS to place the call with given properties (e.g.,
bearer capability, subscriber profile restrictions) is verified.
û For MS origination, sends an indication to the RACF to select a
radio channel (i.e., select RCF) for MS origination and order the MS
to use the channel. If no channel is immediately available, the RACF
may invoke Priority Access and Channel Assignment (PACA) to wait for
a channel to become available.
Exit Event:
û Authority/ability to place outgoing call verified. For MS
origination, radio channel is available and assigned to the MS.
(DP: Origination_Attempt_Authorized).
û Authority/ability to originate call is denied. This event causes a
transition to the O_Exception PIC.
û Failure to select a radio channel for the MS. This event causes a
transition to the
O_Exception PIC.
û A disconnection indication is received from the originating party.
(DP: O_Abandon).
5.1.3 Collect_Information
Entry Event:
û Authority/ability to place outgoing call verified. For MS
origination, radio channel available and assigned to the MS.
Functions:
û Initial information package/dialing string (e.g., service codes,
prefixes, dialed address digits) being collected from originating
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 14]
party. Information being examined according to dialing plan to
determine end of collection. No further action may be required if an
en bloc signaling method is in use (e.g., an incoming SS7 trunk).
û Subsequent digit collection according to the subscriber profile
(e.g., for PIN collection). After digit collection is completed, the
SSF/CCF should be able to verify that the MS is authorized for the
outgoing call.
Exit Event:
û Availability of complete initial information package/dialing string
from originating party. (This event may have already occurred in the
case of en bloc signaling, in which case the duration of this PIC is
zero). (DP: Collected_Information).
û Originating party abandons call. (DP: O_Abandon).
û After digit collection is complete, authority to originate call is
denied. This event causes a transition to the O_Exception PIC.
û Information collection error has occurred (e.g., invalid dial
string format, digit collection timeout). This event causes a
transition to the O_Exception PIC.
Comment: Some digit analysis is required to determine the end of
dialing. However, it is assumed that this analysis may be modeled as
separable from the rest of digit analysis, which occurs in the
analyze_Information PIC. There is no intention to specify an
implementation. However, an MSC should externally present the
separable views described.
The separable views are provided by supporting distinct DPs for
Collected_Information and Analyzed_Information and by populating
information flows accordingly for corresponding TDP and EDP
information flows to the SCF.
5.1.4 Analyze_Information
Entry Event:
û Availability of complete initial information package/dialing string
from originating party. (DP: Collected_Information).
Functions:
û Information being analyzed and/or translated according to dialing
plan to determine routing address and call type (e.g., termination to
MS, local exchange call, transit exchange call, international
exchange call).
Exit Event:
û Availability of routing address and call type. (DP:
Analyzed_Information).
û The invalid information event (e.g., invalid dialed digits). This
event causes a transition to the O_Exception PIC.
û Originating party abandons the call. (DP: O_Abandon).
Comment: Note that routing address does not necessarily mean that the
final physical route has been determined (e.g., route list has not
been searched, hunt groups have not been searched, directory number
has not yet been translated to a physical port address), though this
may be the case (e.g., when routing to a special private facility).
5.1.5 Select_Route
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 15]
Entry Event:
û Availability of routing address and call type. (DP:
Analyzed_Information).
û Route failure reported from the Send_Call PIC or O_Alerting PIC.
Functions:
û Routing address and call type being interpreted. The next route is
being selected. This may involve sequentially searching a route
list, translating a directory number into a physical port address,
etc. The individual destination resource out of a resource group
(e.g., a multi-line hunt group, a trunk group) is not selected.
Exit Event:
û Unable to select a route (e.g., unable to determine a correct
route, no more routes on the route list). (DP:
Route_Select_Failure).
û The route_busy event leading to the Analyze_Information PIC.
Route_busy is a non-WIN transition which is part of a basic call. If
the trunk group selected for the call is busy at this switch, the
SSF/CCF attempts to route the call on the next trunk group that has
been specified for the call. Call processing moves to the
Analyze_Information PIC when routing to a particular intra-network or
internetwork carrier has been tried and an alternate carrier is
allowed.
û Terminating resource (group) to which call should be routed has
been identified. This event causes call processing to move to the
Authorize_Call_Setup PIC.
û Originating party abandons the call. (DP: O_Abandon).
5.1.6 Authorize_Call_Setup
Entry Event:
û Terminating resource (group) to which call should be routed has
been identified.
Functions:
û The authority of the calling party to place this particular call is
verified. Exit Event:
û Authority of originating party to place this call is denied (e.g.,
business group restriction mismatch, toll restricted calling line).
This event causes a transition to the O_Exception PIC.
û Authority of originating party to place this call is verified.
This event causes call processing to move to the Send_Call PIC.
û Originating party abandons the call. (DP: O_Abandon).
5.1.7 Send_Call
Entry Event:
û Authority of originating party to place this call is verified.
Functions:
û The originating half BCSM sends an indication to the terminating
half BCSM of the desire to set up a call to the specified called
party. Continued processing of call setup (e.g., ringing, audible
ring indication) is taking place. The originating half BCSM waits
for the indication that the call has been answered by the terminating
party.
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 16]
Exit Event:
û An indication is received from the terminating half BCSM that the
terminating party is busy. (DP: O_Called_Party_Busy). In addition to
terminating party busy events, the following call_rejected conditions
are also treated as O_Called_Party_Busy events:
i) a termination_denied indication is received from the terminating
half BCSM (Authorize_Termination_Attempt PIC); or,
ii) a call_rejected indication is received from the terminating half
BCSM (T_Alerting PIC) that does not specify busy.
û An indication is received from the terminating half BCSM that the
terminating party does not answer. (DP: O_No_Answer).
û An indication is received from the terminating half BCSM that the
terminating party is being alerted. (DP: O_Term_Seized).
û An indication is received from the terminating half BCSM that the
call is accepted and answered by the terminating party. (DP:
O_Answer DP).
û A route_failure event is detected when:
i) an indication of a T_Busy event specifying route busy; is received
from the terminating half BCSM, or ii) an indication of a
call_rejected event specifying route busy (received when the route is
found to be busy at a switch other than the local switch) is received
from the terminating half BCSM (T_Alerting PIC). iii) an indication
of a presentation_failure event specifying route busy is received
from the terminating half BCSM (Present_Call PIC).
In all these cases, the originating half BCSM returns to the
Select_Route PIC. This event is not detected at a DP.
Note: The route_failure event takes precedence over the
O_Called_Party_Busy and O_No_Answer events.
û An indication is received from the RCF of a service feature request
by the originating MS. (DP: O_Mid_Call).
û For SS7-supported trunk interface, the authorization_route_failure
event occurs when the continuity check procedure results in failure.
This event causes a transition to the O_Exception PIC.
û Originating party abandons the call. (DP: O_Abandon).
5.1.8 O_Alerting
Entry Event:
û An indication is received from terminating half BCSM that the
terminating party is being alerted. (DP: O_Term_Seized).
Functions:
û Continue processing of call setup.
û Waiting for indication from the terminating half BCSM that the call
has been answered by the terminating party.
Exit Event:
û A route failure event is detected when all of the following
conditions are met:
û An indication is received from the terminating half BCSM that the
terminating party does not answer within a specified time period.
(DP: O_No_Answer).
û An indication is received from the terminating half BCSM that the
call is accepted and answered by the terminating party. (DP:
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 17]
O_Answer).
û From this PIC, the O_Called_Party_Busy event occurs either when:
i) an indication of a call_rejected event specifying user busy is
received from the terminating half BCSM (T_Alerting PIC), or
ii) an indication of a call_rejected event not specifying user busy
is received from the terminating half BCSM (T_Alerting PIC). For
example, the terminating party may reject the call.
The originating half BCSM moves to the O_Called_Party_Busy DP.
û An indication is received from the RCF of a service feature request
by the originating MS. (DP: O_Mid_Call).
û Originating party abandons the call. (DP: O_Abandon)
5.1.9 O_Active
Entry Event:
û An indication is received from the terminating half BCSM that the
call is accepted and answered by the terminating party. (DP:
O_Answer).
Functions:
û Connection established between originating and terminating party.
Message accounting/charging data may be collected. Call supervision
is being provided.
Exit Event:
û An indication is received from the RCF of a service feature request
by the originating MS. (DP: O_Mid_Call).
û A disconnect indication is received from the originating party.
(DP: O_Disconnect).
û A disconnect indication is received from the terminating party via
the terminating half BCSM. (DP: O_Suspend).
û A connection failure occurs. This event causes a transition to the
O_Exception PIC.
5.1.10 O_Suspended
Entry Event:
û A disconnect indication is received from the terminating party via
the terminating half BCSM. (DP: O_Suspend).
Functions:
û The connection with the originating party is maintained and
depending on the incoming access connection, appropriate signaling
takes place.
Exit Event:
û Connection to the terminating party is resumed. The originating
half BCSM returns to the O_Active PIC. (DP: O_Re-answer). Note: This
transition to the O_Active PIC is not applicable for wireless calls.
û An indication is received from the RCF of a service feature request
by the originating MS. (DP: O_Mid_Call).
û A disconnection indication is received from the originating party.
(DP: O_Disconnect).
û A disconnection indication is received from the terminating party.
(DP: O_Disconnect).
û An exception event is encountered. This event causes a transition
to the O_Exception PIC.
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 18]
û An indication of expiration of the timer waiting for re-answer
request is received from the terminating half BCSM. (DP:
O_Disconnect).
û A trigger at O_Mid_Call is not initiated during an appropriate
period. (DP: O_Disconnect).
5.1.11 O_Exception
Entry Event:
û An exception event is encountered as described above for each PIC.
Functions:
û Default handling of the exception condition is being provided.
This includes general actions necessary to ensure no resources remain
inappropriately allocated, such as:
i) If any relationships exist between the SSF and SCF(s), send an
error information flow to the SCF(s) closing the relationships and
indicating that any outstanding call handling instructions will not
run to completion.
ii) The SSF/CCF should make use of vendor-specific procedures to
ensure release of resources so that radio, trunk, and other resources
are made available for new calls.
Exit Event:
û Default handling of the exception condition by SSF/CCF completed.
(Transition to O_Null PIC)
5.2 Terminating BCSM The terminating half of the BCSM corresponds to
that portion of the BCSM associated with the terminating party. The
description for each of the PICs in the terminating half of the BCSM
are described below:
5.2.1 T_Null
Entry Event:
û Disconnect and clearing of a previous call (DPs: T_Disconnect or
T_Abandon)
û Default handling of the exception condition by SSF/CCF completed.
(Transition from T_Exception PIC).
Functions:
û Clear any resources allocated to the terminating MS.
Exit Event:
û An indication of incoming call is received from the originating
half BCSM. (DP: Termination_Attempt).
û The following exception exit event is applicable to this PIC:
T_Abandon.
i) The T_Abandon occurs when an indication of call disconnection is
received from the originating half BCSM. If the call encounters
T_Abandon during PIC processing, the exception event is not visible
because there is no corresponding DP.
5.2.2 Authorize_Termination_Attempt
Entry Event:
û Indication of incoming call received from the originating half
BCSM. (DP: Termination_Attempt)
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 19]
Functions:
û Authority to route the call to the terminating access (e.g., MS or
trunk group) is being verified, e.g., check business group
restrictions, restricted incoming access to line, or bearer
capability compatibility.
Exit Event:
û Termination_Attempt_Authorized event. This event occurs when the
MSC has verified the authority to terminate the call to the
terminating access. (DP: Termination_Attempt_Authorized).
û The Termination Denied event occurs when the authority to route
these call to the terminating user is denied. (This causes a
transition to the T_Exception PIC).
û The T_Abandon event occurs when an indication of clearing is
received from the originating half BCSM. (DP: T_Abandon).
5.2.3 Select_Facility
Entry Event:
û Termination_Attempt_Authorized event. This event occurs when the
MSC has verified the authority to terminate the call to the
terminating access. (DP: Termination_Attempt_Authorized).
û An SS7 failure occurs causing a re-attempt. The SS7 failure in the
Present_Call PIC can be caused by a timer expiry upon sending the
first Circuit Reservation Message (CRM) or a continuity check
failure.
Functions:
û A particular network resource is being selected. It is possible
that all resources in the group could be busy or unavailable. A
single resource is considered a group of one.
û For MS termination, the terminating half BCSM sends an indication
to the RACF to select facilities (e.g., page the MS, MS page
response, trunk to cell, radio channel within cell) for the call.
The MS is assigned to the radio channel.
û The busy/idle status of the terminating access is determined.
i) For termination to an MS, the MS is treated as user busy if it is
already involved in an existing call and cannot receive another call
(e.g., call waiting is not active).
ii) For termination to an MS, the MS is treated as network busy if no
radio channels are available or a routing failure occurs while
attempting to complete the call.
iii) For termination to an MS, the MS is treated as unavailable if it
is not available for call termination, an indication that the MS does
not respond to a page is received from the RACF2, or an indication of
a failure to assign the MS to a radio channel is received from the
RACF.
iv) For calls routed out of this SSF/CCF, network-determined user
busy is the detection of terminating party busy.
v) For calls routed out of this SSF/CCF, network busy is when all
trunks within the selected trunk group are busy.
For call arrival with TLDN, if the MS status is busy (user or
network) or unavailable and the subscriber profile indicates call
redirection on Busy, No Page Response, No Answer or Routing Failure,
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 20]
a RedirectionRequest INVOKE is sent to the Originating MSC with the
RedirectionReason parameter set to indicate the reason for
redirection. The response determines the exit event.
1. If the MS is already assigned to a radio channel, only the
selection of a trunk to the serving cell may be required.
2. The MS is treated as unavailable if it fails authentication when
it responds to the page. 3. The REDREQ will not be sent if office
provisioning indicates that call redirection will be done by the
Serving MSC.
Exit Event:
û Terminating access is not busy, available terminating resources
available and facilities selected. (DP:
Facility_Selected_and_Available).
û For call arrival with TLDN, the MS status is busy or unavailable,
and the response to the RedirectionRequest INVOKE indicates success.
(DP: T_Abandon).
û A T_Busy event occurs when the terminating access is busy or
unavailable (as defined above) and there is no call redirection
(i.e., local termination, TLDN call arrival with call redirection not
applicable, TLDN call arrival with response to RedirectionRequest
INVOKE indicating failure). (DP: T_Busy)
After detecting T_Busy, if WIN service logic is not needed on the
call and no switch-based features apply, an indication of the T_Busy
event describing the type of busy (e.g., user or network) is passed
to the originating half BCSM (Send_Call PIC). If a terminating
feature acts on the T_Busy event and changes the event [e.g., as in
the Call Waiting feature], the event is not passed to the originating
half BCSM.
û The T_Abandon event occurs when an indication of clearing is
received from the originating half BCSM. (DP: T_Abandon).
5.2.4 Present_Call
Entry Event:
û Available terminating resource identified and facilities selected.
(DP: Facility_Selected_and_Available). Functions:
û Terminating resource informed of incoming call (e.g., indication
sent to RCF about the call).
Exit Event:
û Terminating party is being alerted (e.g., indication from RCF that
ringing is being applied, ringing being applied, ISDN-UP ACM
message). (DP: Call_Accepted).
û Call is accepted and answered by terminating party (e.g.,
indication from RCF of call answer by MS, terminating party goes off
hook, ISDN-UP answer message received). (DP: T_Answer).
û For call routed out of this SSF/CCF to an MS, RedirectionRequest
INVOKE received with the RedirectionReason parameter indicating Busy,
No Page Response, Unavailable or Unroutable. (DP: T_Busy).
After detecting T_Busy, if WIN service logic is not needed on the
call, an indication of the T_Busy event is passed to the originating
half BCSM (Send_Call PIC). If a terminating feature acts on the
T_Busy event and changes the event [e.g., as in the Call Forwarding
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 21]
feature], the event is not passed to the originating half BCSM.
û For call routed out of this SSF/CCF to an MS, RedirectionRequest
INVOKE message received with the RedirectionReason parameter
indicating No Answer or Call Refused. (DP: T_No_Answer).
After detecting T_No_Answer, if WIN service logic is not needed on
the call, an indication of the T_No_Answer event is passed to the
originating half BCSM (Send_Call PIC). If a terminating feature acts
on the T_No_Answer event and changes the event [e.g., as in the Call
Forwarding feature], the event is not passed to the originating half
BCSM.
û A timer expiry upon sending the first Circuit Reservation Message
(CRM) or a continuity check failure. (SS7 failure). This event
causes call processing to move to the Select_Facility PIC.
û Presentation Failure: For call routed out of this SSF/CCF, the call
cannot be presented, (e.g., ISDN user determined busy, ISDN-UP
release message with busy cause). This event causes the terminating
half BCSM to move to the T_Exception PIC and an indication sent to
the originating half BCSM (Send_Call PIC).
û An indication of originating party abandon is received from
originating half BCSM. (DP: T_Abandon).
5.2.5 T_Alerting
Entry Event:
û Terminating party is being alerted of incoming call (DP:
Call_Accepted).
Functions:
û An indication is sent to the originating half BCSM that the
terminating party is being alerted. Continued processing of call
setup (e.g., ringing, audible ring indication) is taking place.
Waiting for the call to be answered by the terminating party.
û For call arrival with TLDN, if the MS does not answer the alert and
the subscriber profile indicates call redirection on a ôno answerö
condition1, a RedirectionRequest INVOKE is sent to the Originating
MSC with the RedirectionReason parameter indicating No Answer or Call
Refused, as appropriate. The response determines the exit event.
Exit Event:
û Call is accepted and answered by terminating party (e.g.,
indication from RCF of call answer by MS, terminating party goes off
hook, ISDN-UP answer message received). (DP: T_Answer).
û For call arrival with TLDN, the MS does not answer the alert and
the response to the RedirectionRequest INVOKE indicates success.
(DP: T_Exception).
û Terminating party does not answer before the MSC-based ringing
timer expires.
For call arrival with TLDN, the MS does not answer the alert and the
response to the RedirectionRequest INVOKE indicates failure. For MS
termination, loss of radio contact with MS. For call routed out of
this SSF/CCF to an MS, RedirectionRequest INVOKE received with the
RedirectionReason parameter indicating No Answer or Call Refused.
(DP: T_No_Answer).
The REDREQ will not be sent if office provisioning indicates that
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 22]
call redirection will be done by the Serving MSC.
After detecting T_No_Answer, if WIN service logic is not needed on
the call, an indication of the T_No_Answer event is passed to the
originating half BCSM (Send_Call PIC). If a terminating feature acts
on the T_No_Answer event and changes the event [e.g., as in the Call
Forwarding feature], the event is not passed to the originating half
BCSM.
û Call_rejected exception event may happen when a user rejects a call
while being alerted. This event causes the terminating half BCSM to
move to the T_Exception PIC and an indication sent to the originating
half BCSM (Send_Call PIC).
û Indication of originating party abandon received from the
originating half BCSM. (DP T_Abandon)
5.2.6 T_Active
Entry Event:
û Call is accepted and answered by terminating party. (DP:
T_Answer).
Functions:
û An indication is sent to the origination half BCSM that the
terminating party has accepted and answered the call. Connection
established between originating and terminating party. Call
supervision is being provided.
Exit Event:
û An indication is received from the RCF of a service feature request
by the terminating MS. (DP: T_Mid_Call).
û A disconnect indication is received from the terminating party.
(DP: T_Suspend).
û A disconnect indication is received from the originating party via
the originating half BCSM. (DP: T_Disconnect).
û A connection failure occurs or loss of radio contact with MS. This
event causes the terminating half BCSM to move to the T_Exception PIC
and an indication sent to the originating half BCSM.
5.2.7 T_Suspended
Entry Event:
û A disconnect indication is received from the terminating party.
(DP: T_Suspend).
Functions:
û The physical resources associated with the call remain connected.
û A suspend indication is sent to the originating half BCSM.
û A disconnect indication (e.g., Q.931 disconnect message, SS7
release message) is received from the terminating party, this PIC is
immediately exited to the T_Disconnect DP without any action.
û For an SS7 supported trunk, when the receiving network initiates a
suspend message, a timer is started and the call processing waits for
re-answer request from the terminating party. If re-answer request
(e.g., off-hook, SS7 resume message) is received from the terminating
party before the timer expires, the originating and terminating
parties are reconnected.
Note: Both a Call Resume timer and a Call Retention timer may exist
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 23]
in this PIC. WIN implementations may use a single timer for both
conditions.
Exit Event:
û The terminating party re-answers or a resume message is received
before the timer expires. The T_BCSM returns to the T_Active PIC.
(DP: T_Re-answer).
Note: This transition to the T_Active PIC is not applicable for
wireless calls.
û The expiration of the timer waiting for re-answer from the
terminating party. (DP: T_Disconnect).
û A disconnection indication is received from the terminating party
(DP: T_Disconnect).
û A disconnection indication is received from the originating party
via the originating half BCSM. (DP: T_Disconnect).
û An exception event is encountered. This event causes a transition
to the T_Exception PIC.
5.2.8 T_Exception
Entry Event:
û An exception event is encountered as described above for each PIC.
Functions:
û An indication of the exception condition is sent to the originating
half BCSM. Default handling of the exception condition is being
provided. This includes general actions necessary to ensure no
resources remain inappropriately allocated, such as:
i) If any relationships exist between the SSF and SCF(s), send an
error information flow to the SCF(s) closing the relationships and
indicating that any outstanding call handling instructions will not
run to completion.
ii) The SSF/CCF should make use of vendor-specific procedures to
ensure release of resources so that radio, trunk, and other resources
are made available for new calls.
Exit Event: û Default handling of the exception condition by SSF/CCF
completed. (Transition to O_Null PIC).
5.3 BCSM Detection Points Certain call and connection events may be
visible to WIN service logic instances. DPs are the points in the
call processing at which these events are detected. A DP can be
armed in order to notify a WIN service logic instance that the DP was
encountered, and potentially to allow the WIN service logic instance
to influence subsequent call processing. If a DP is not armed, the
SSF/CCF continues call processing without SCF involvement. DPs are
characterized by the following four attributes:
1. Arming/disarming mechanism. A DP must be armed in order for the
event to be detected. A DP may be statically armed or dynamically
armed. A DP is statically armed through service feature
provisioning. A statically armed DP remains armed until explicitly
disarmed. Statically armed DPs are of type TDP-R or TDP-N.
A DP may be dynamically armed by a Service Logic Program (SLP)
instance at an SCF within the context of the current call and the
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 24]
current control relationship with that SLP instance at that SCF.
Dynamically armed DPs of this type are labeled EDP-R or EDP-N.
While the SSF/CCF-SCF control relationship exists, the dynamically
armed triggers at EDPs may be adjusted as needed by the SLP instance
at the SCF. EDPs may remain armed to provide notifications only to
the SLP instance at the SCF when the relationship shifts from control
to monitoring. These dynamically armed EDPs are automatically
disarmed when the relationship terminates, even if the call
continues. If the relationship shifts to monitoring mode, a new
control relationship may be established with another SLP instance at
the same or a different SCF within the same call. When a mobile
station initially registers within the serving area of an SSF/CCF,
the set of DPs armed, the trigger criteria and related information
(e.g., the SCF to which a call handling instruction request should be
addressed) need to be placed in the SSF/CCF serving the subscriber
when the registration takes place. This represents dynamic
geographic placement of statically armed DPs, and is distinct from
dynamic DP arming as discussed above. This requires that an image of
the statically armed DPs (type TDP-R and TDP-N) for the registering
subscriber be provided to the SSF/CCF as part of the registration
notification process. Upon intersystem handoff, the original SSF/CCF
becomes the anchor SSF/CCF and remains responsible for the
relationship(s) to the SCF(s) influencing the call. Therefore, there
is no impact as a result of the handoff. Specific triggers may be
dynamically armed as TDPs within the context of the current call.
The SCF response to the SSF/CCF can provide this trigger arming
information.
2. Criteria. In addition to the condition that a DP be armed, DP
criteria must be satisfied in order to notify the SCF that the DP was
encountered.
3. Relationship. Given that an armed DP was encountered and DP
criteria are satisfied, the SSF may provide an information flow via a
relationship:
a) If this relationship is between the SSF/CCF and the SCF for the
purpose of call and service logic processing, it is considered to be
a WIN service relationship. This relationship may be of two types: û
a control relationship if the SCF is able to influence call
processing via the relationship;
û a monitor relationship if the SCF is not able to influence call
processing via the relationship
b) If this relationship is between the SSF/CCF and the SCF or the SMF
for management purposes, it is considered to be a service management
control relationship. This relationship is for further study.
4. Call processing suspension. Given that an armed DP was
encountered and DP criteria are satisfied for a WIN service control
relationship, the SSF may suspend call processing to allow the SCF to
influence subsequent call processing. When call processing is
suspended, the SSF sends an information flow to the SCF requesting
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 25]
instructions, and waits for a response. When call processing is not
suspended, the SSF sends an information flow notifying the SCF that a
DP was encountered, and does not expect a response. This attribute
is set by the same mechanism that arms the DP.
Based on these attributes, four types of DPs are identified for WIN.
The DP types are:
a. Trigger Detection Point û Request (TDP-R)
b. Trigger Detection Point û Notification (TDP-N)
c. Event Detection Point û Request (EDP-R)
d. Event Detection Point û Notification (EDP-N)
6. Selected Parameter Acronym ASN.1 Notation
AllOrNone AON AllOrNone ::= IMPLICIT UNSIGNED ENUMERATED{
AllChangesMustSucceedOrNoneShouldBeApplied (1),
TreatEachChangeIndependently (2)}
Change CHANGE Change ::= IMPLICIT UNSIGNED ENUMERATED {
SetDataItemToDefaultValue (1),
AddDataItem (2),
DeleteDataItem (3),
ReplaceDataItemWithAssociatedDataValue (4),
à}
DataAccessElement DAE DataAccessElement ::= IMPLICIT SEQUENCE {
DataID OPTIONAL,
Change,
DataValue}
DataAccessElementList DAEL DataAccessElementList ::= IMPLICIT SEQUENCE OF {
DataAccessElement}
DataID DATAID DataID ::= IMPLICIT OCTET STRING
--encoding of value is any valid TIA/EIA-41 parameter
--(explicitly defined in standard or private).
DatabaseKey DATAKEY DatabaseKey ::= IMPLICIT OCTET STRING
--value is determined by bi-lateral negotiation between sender
--and receiver to be interpreted as a database key.
DataResult DATARES DataResult :: = IMPLICIT UNSIGNED ENUMERATED {
Successful (1),
Unsuccessful (2),
à}
DataUpdateResult DATUR DataUpdateResult ::= IMPLICIT SEQUENCE {
DataID,
DataResult}
DataUpdateResultList DATURL DataUpdateResultList :: = IMPLICIT SEQUENCE OF {
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 26]
DataUpdateResult}
DataValue DATAVAL DataValue :: = IMPLICIT OCTET STRING
--encoding of this parameter will vary according to the type
--of data item
DestinationAddress (none) DestinationAddress ::= CHOICE {
PC_SSN,
GlobalTitle}
DetectionPointType DPTYPE DetectionPointType ::= IMPLICIT UNSIGNED
ENUMERATED {
TDP-R (1),
TDP-N (2),
EDP-R (3),
EDP-N (4),
à}
ExecuteScript EXESCR ExecuteScript ::= IMPLICIT SEQUENCE {
ScriptName OPTIONAL,
ScriptArgument}
FailureCause FAILCAUSE FailureCause ::= IMPLICIT OCTET STRING
--encoding of this parameter is based on the encoding of
--the information elements in T1.113.3 section 2.3.9.
FailureType FAILTYPE FailureType ::= IMPLICIT UNSIGNED ENUMERATED {
CallAbandoned (1),
ResourceDisconnect (2),
FailureAtMSC (3),
SSFTExpiration (4),
à}
GlobalTitle (none) GlobalTitle ::= IMPLICIT OCTET STRING
--parameter carries the SCCP Global Title as defined in
--Section 3 of ANSI T1.112.
ModificationRequest MODRQ ModificationRequest ::= IMPLICIT SEQUENCE {
ServiceDataAccessElementList OPTIONAL,
AllOrNone}
ModificationRequestList MODRQL ModificationRequestList ::= IMPLICIT SEQUENCE OF {
ModificationRequest}
ModificationResult MODRS ModificationResult ::= CHOICE
{DataResult,
ServiceDataResultList}
ModificationResultList MODRSL ModificationResultList ::= IMPLICIT SEQUENCE OF {
ModificationResult}
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 27]
PrivateSpecializedResource (none) PrivateSpecializedResource ::= IMPLICIT OCTET STRING
--values are allocated by network operators for use
--within their networks
ResumePIC RESUMEPIC ResumePIC ::= IMPLICIT UNSIGNED ENUMERATED {
Continue_Call_Processing (1),
Collect_InformationPIC (2),
Analyze_InformationPIC (3),
Select_RoutePIC (4),
Select_FacilityPIC (32),
Present_CallPIC (33),
à}
ScriptArgument SCRARG ScriptArgument ::= IMPLICIT OCTET STRING
--value encoding is undefined
ScriptName SCRNAME ScriptName ::= IMPLICIT OCTET STRING
--value encoding is undefined
ScriptResult SCRRESULT ScriptResult ::= IMPLICIT OCTET STRING
--value encoding is undefined
ScriptResult SCRRESULT ScriptResult ::= IMPLICIT OCTET STRING
--value encoding is undefined
ServiceDataAccessElement SDAE ServiceDataAccessElement ::= IMPLICIT SEQUENCE {
DataAccessElementList OPTIONAL,
ServiceID}
ServiceDataAccessElementList
SDAEL ServiceDataAccessElementList ::= IMPLICIT SEQUENCE OF
{
ServiceDataAccessElement}
ServiceDataResult SDR ServiceDataResult ::= IMPLICIT SEQUENCE {
DataUpdateResultList OPTIONAL,
ServiceID}
ServiceDataResultList SDRL ServiceDataResultList ::= IMPLICIT SEQUENCE OF {
ServiceDataResult}
SpecializedResource (none) SpecializedResource ::= IMPLICIT OCTET STRING
--value encoding is undefined
SRFCapability SRFCAP SRFCapability ::= IMPLICIT SET {
SpecializedResource OPTIONAL,
PrivateSpecializedResource OPTIONAL}
--at least one must be present
TriggerAddressList TRIGADDRLIST TriggerAddressList ::= IMPLICIT SET OF {
TriggerList}
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 28]
TriggerCapability TRIGCAP TriggerCapability ::= IMPLICIT OCTET STRING
--see 6.5.2.gg for encoding
TriggerList TRIGLIST TriggerList ::= IMPLICIT SET {
DestinationAddress,
CHOICE {
WIN_Trigger,
WIN_TriggerList} }
TriggerType TRIGTYPE TriggerType ::= IMPLICIT UNSIGNED ENUMERATED {
All_Calls (1),
Double_Introducing_Star (2),
Single_Introducing_Star (3),
Reserved_for_Home_System_Feature_Code (4),
Double_Introducing_Pound (5),
Single_Introducing_Pound (6),
Revertive_Call (7),
0-Digit (8),
1-Digit (9),
2-Digit (10),
3-Digit (11),
4-Digit (12),
5-Digit (13),
6-Digit (14),
7-Digit (15),
8-Digit (16),
9-Digit (17),
10-Digit (18),
11-Digit (19),
12-Digit (20),
13-Digit (21),
14-Digit (22),
15-Digit (23),
Local_Call (24),
Intra-LATA_Toll_Call (25),
Inter-LATA_Toll_Call (26),
World_Zone_Call (27),
International_Call (28),
Unrecognized_Number (29),
Prior_Agreement (30),
Specific_Called_Party_Digit_String (31),
Mobile_Termination (32),
Advanced_Termination (33),
Location (34),
Terminating_Resource_Available (64),
T_Busy (65),
T_No_Answer (66),
T_No_Page_Response (67),
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 29]
7.0 Acknowledgements
The author would like to thank Igor Faynberg, Vijay Gurbani, Hui-Lan Lu and Doug Varney for their time and insightful comments during the preparation of this I-D.
8.0 References
[1] ITU-T Q.763, December 1999: "Specifications of Signalling System
No. 7 Formats and codes of the ISDN user part".
[2] Faynberg, I., L. Gabuzda, M. Kaplan, and N.Shah, "The Intelligent
Network Standards: Their Application to Services", McGraw-Hill, 1997.
[3] TIA/EIA Interim Standard IS-848, Enhanced Charging Services
[4] TIA/EIA/IS-771, Wireless Intelligent Network; Telecommunications Industry
Association; December 1998
[5] 3G TS 23.032, "Universal Geographical Area Description (GAD)".
[6] 3G TS 23.073, "Support of Localised Service Area (SoLSA); Stage 2"
[7] GSM 03.32 Version 5.0.0, " Digital cellular telecommunications
system (Phase 2+) (GSM); Universal Geographical Area Description
(GAD) "
[8] TS GSM 03.03, " Digital cellular telecommunications system
(Phase 2+) (GSM); Numbering, addressing and identification"
[9] TS GSM 04.08, " Digital cellular telecommunications system
(Phase 2+) (GSM); Mobile radio interface; Layer 3 specification"
[10] L. Slutsman (Ed.), I. Faynberg, H. Lu, M. Weissman, "The SPIRITS
Architecture", IETF RFC 3136, June 2001,
<http://www.ietf.org/rfc/rfc3136.txt>
[12] Adam Roach, "SIP-Specific Event Notification", IETF RFC 3265,
June 2002, <http://www.ietf.org/rfc/rfc3265.txt>
[13] I.Faynberg, J. Gato, H. Lu, and L. Slutsman, "SPIRITS Protocol
Requirements", IETF RFC 3298, August 2002,
<http://www.ietf.org/rfc/rfc3298.txt>
[14] J. Rosenberg, H. Schulzrinne, G. Camarillo, J. Peterson, R.
Sparks, A. Johnston, M. Handley, and E. Schooler, "SIP: Session
Initiation Protocol" IETF RFC 3261, June 2002,
<http://www.ietf.org/rfc/rfc3261.txt>
[15] M. Unmehopa, K. Vemuri, A. Brusilovsky, E. Dacloush, A. Zaki, F.
Haerens, J-L. Bakker, B. Chatras, and J. Dobrowolski, "On selection
of IN parameters to be carried by the SPIRITS Protocol", IETF I-D,
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 30]
Expires January 2003, Work In Progress.
[16] Vijay K. Gurbani, "Security for SPIRITS services", IETF
Internet-Draft, Work in Progress.
[17] Intelligent Network Capability Set 2. ITU-T, Recommendation Q.1228
[18] Distributed functional plane for intelligent network capability Set 2.
ITU-T, Recommendation Q.1224, 09/97.
[19] Recommendation Q.763 (12/99) - Signalling System No. 7 - ISDN user
part formats and codes
[20] Recommendation Q.931 (05/98) - ISDN user-network interface layer 3
specification for basic call control
[21] 3G TS 23.127 version 4.0.0, "3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects; Virtual
Home Environment" (Release 4)
[22] 3G TS 29.198-04 version 4.0.0, "3rd Generation Partnership
Project; Technical Specification Group Core Network; Open Service
Access (OSA); Application Programming Interface (API); Part 4:
Call Control" (Release 4)
[23] 3G TR 29.998 v3.2.0 "3rd Generation Partnership Project; Technical
Specification Group Core Network; Open Services Architecture;
Application Programming Interface - Part 2" (Release 1999)
[24] ISO 8601-1997, "Data elements and interchange formats -
Information interchange - Representation of dates and times".
[25] ETSI DocBox, SPAN 12 OPEN SERVICE ACCESS API,
http://docbox.etsi.org/tech-org/span/Open/Span12/Overview.html
9.0 Authors' Addresses
Alec Brusilovsky,
Artcare,
559 Roxbury Drive,
Naperville, IL 60565
USA.
abrusilovsky@ieee.org
10.0 Acronyms
3GPP Third Generation Partnership Project
ASN.1 Abstract Syntax Notation One
ASP Application Service Provider
API Application Programming Interface
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 31]
BCSM Basic Call State Model
CAMEL Customized Applications for Mobile Network Enhanced
Logic
CC Call Control
CM Call Model
CS Capability Set
DN Directory Number
DP Detection Point
DTD Document Type Definition
EDP Event Detection Point
EDP-N Event Detection Point "Notification"
EDP-R Event Detection Point "Request"
GSTN Global Switched Telephone Network
HTTP Hypertext Transfer Protocol
IANA Internet Assigned Numbers Authority
ICW Internet Call Waiting
IE Information Element
IDL Interface Definition Language
IF Information Flow
IN Intelligent Network
INAP Intelligent Network Application Protocol
IP Internet Protocol
ISUP ISDN User Part (SS7 Protocol)
ITU International Telecommunications Union
MIME Multipurpose Internet Mail Extensions
MP CC MultiParty Call Control
OBCSM Originating Basic Call State Model
PIC Point In Call
PINT PSTN/Internet Interworking
PSTN Public Switched Telephone Network
SCF Service Control Function
SCP Service Control Point
SDP Session Description Protocol
SIP Session Initiation Protocol
SIP-T SIP for Telephones
SPIRITS Services in the PSTN/IN Requesting InTernet Services
SSF Service Switching Function
SSP Service Switching Point
STD State Transition Diagram
TBCSM Terminating Basic Call State Model
TDP Trigger Detection Point
TDP-N Trigger Detection Point "Notification"
TDP-R Trigger Detection Point "Request"
XML Extensible Markup Language
11.0 Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved. This
document and translations of it may be copied and furnished to others,
and derivative works that comment on or otherwise explain it or assist
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 32]
in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Addendum 1. Figures
//---\\ //---\\
| | | |
|\\---//+----------------+\\---//|
| VLR | | VLR |
| +-----------+ | |
\\-+-// | \\---//
| |
| |
| |
+---------+ +---------+ +-----+-----+ | //---\\
| | | | | Mobile | | | |
| Mobile | | Base | | Switching | | |\\---//|
| Station +---+ Station +----+ Center | | | HLR |
| | | | | | | | |
+---------+ +---------+ +-+-------+-+ | \\-+-//
| | +--------+
| +----+ |
+-----------+ | | +------+-------+
| Mobile | --+-- /--+-\ | |
| Switching | // \\ // \\ |Authentication|
| Center | | ISDN | | PSTN | | Center |
| | \\ // \\ // | |
+-----------+ ----- \----/ +--------------+
Figure 1. Wireless Network Reference Model
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
On selection of IS-41 SPIRITS mobility-related parameters [Page 33]
+---+----------------------------------------+
| | Network Entities (NEs) |
| +----+---+---+---+---+---+---+---+---+---+
| | |AC |BS |HLR|IP |MS |MSC|SCP|SN |VLR|
+---+----+---+---+---+---+---+---+---+---+---+
| |ACF | X | | | | | | | | X |
| F +----+---+---+---+---+---+---+---+---+---+
| u |CCF | | | | | | X | | X | |
| n +----+---+---+---+---+---+---+---+---+---+
| c |LRFh| | | X | | | | | | |
| t +----+---+---+---+---+---+---+---+---+---+
| i |LRFv| | | | | | | | | X |
| o +----+---+---+---+---+---+---+---+---+---+
| n |MACF| | | | | | X | | | |
| a +----+---+---+---+---+---+---+---+---+---+
| l |RACF| | | | | | X | | | |
| +----+---+---+---+---+---+---+---+---+---+
| E |RCF | | X | | | | | | | |
| n +----+---+---+---+---+---+---+---+---+---+
| t |RTF | | | | | X | | | | |
| i +----+---+---+---+---+---+---+---+---+---+
| t |SCF | | | X | | | | X | X | |
| i +----+---+---+---+---+---+---+---+---+---+
| e |SDF | | | X | | | | X | X | |
| s +----+---+---+---+---+---+---+---+---+---+
| |SRF | | | | X | | X | | X | |
|FEs+----+---+---+---+---+---+---+---+---+---+
| |SSF | | | | | | X | | | |
+---+----+---+---+---+---+---+---+---+---+---+
Figure 2. Mapping of WIN Functional Entities to Network Entities
<draft-brusilovsky-spirits-is41-00.txt> July 2002 Expires Aug 2003
