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 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. 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 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. 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 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 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 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, 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; 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 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 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: 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 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 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. 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: 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. 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) 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, 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 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 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 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 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 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 { 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} 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} 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), 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, [12] Adam Roach, "SIP-Specific Event Notification", IETF RFC 3265, June 2002, [13] I.Faynberg, J. Gato, H. Lu, and L. Slutsman, "SPIRITS Protocol Requirements", IETF RFC 3298, August 2002, [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, [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, 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 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 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 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 July 2002 Expires Aug 2003