Camel For UMTS

Requirements Document
Feature Title:
UMTS-MSC R1V2 CAMEL
Issue.Version: Authors:
4.0 Marianne Picha (version 3.0,4.0) Andrew McClurg Akhil Khare
Author: Date:
Marianne Picha November 18, 2002
Accepted QDI ID: 19337 Lucent Technologies - Proprietary Page: Use pursuant to Company Instructions
Issue: 4 1
TABLE OF CONTENTS 1
1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9
FEATURE DESCRIPTION
Scope Guide to Requirements History / Change Record Benchmark Dates Open Issues Implementation Decision Record Competitive Information Relation to Other Features Acknowledgements
814
814 814 814 814 915 915 915 915 915 1016 1016 1016 1218
1.10 Glossary of Terms & Abbreviations 1.10.1 Standard Terms 1.10.2 Standard Acronyms 1.10.3 Lucent Acronyms
2
2.1 2.2 2.3 2.4 2.5 2.6
OVERVIEW
Scope Logical Functionality within the MSC Intra-MSC Messaging Intra-MSC States Message Error Handling Notes for Feature Testers
1319
1319 1319 1319 1319 1420 1420
3 4
4.1
CAMEL ARCHITECTURE SCENARIOS

Relation between external and internal messages Author: Marianne Picha Lucent Technologies - Proprietary
1521 1521
1521 Issue: 4 2
QDI ID: 19337 Date: November 18, 2002
Page:
4.2 Originating Call Scenarios 4.2.1 Sunny Day Call: A-party disconnect 4.2.2 Warning Tone Played - A-party disconnect 4.2.3 Interval Timer Expires 4.2.4 Two Apply Charging Operations 4.2.5 Switch Based Announcement Prior to Call Completion 4.2.6 IP Based Announcement Prior to Call Completion 4.2.7 IP based announcement prior to call to busy B-party 4.3 Terminating Call Scenarios 4.3.1 Basic Mobile Termination with CAMEL 4.3.2 Termination with gsmSCF Modified Number 4.3.3 Mobile Termination with Unmodified Number 4.4 Call Forwarding Call Scenarios 4.4.1 GSM Call Forwarding Unconditional at GMSC 4.4.2 Termination with GSM Call Forwarding on Mobile Not Reachable at GMSC 4.4.3 CAMEL Call Forwarding 4.4.4 GSM Call Forwarding at the VMSC
1521 1521 1723 1824 1925 2026 2127 2127 2228 2228 2430 2531 2531 2632 2733 2935 3036
5
5.1
CAMEL STANDARDS
Standards Documents
3036
3036 3137 3137 3238 3339 3339 3339
5.2 Roadmap to CAMEL Stage 2 5.2.1 Processes and Procedures for Originating Calls 5.2.2 Processes and Procedures for Terminating and Forwarded Calls 5.3 5.4 5.5 CAMEL Standards and FSD Requirements Call Control Function State Machine Service Switching Function State Machine
6
6.1
VLR REQUIREMENTS
CAMEL Subscriber Data
3339
3339
7
7.1 7.2 7.3 7.4 7.5
MSC DATA
Incoming roaming restrictions for CAMEL subscribers Location Numbers CAMEL phase supported Network Operator Specific parameters Announcement identifiers for internal gsmSRF Author: Marianne Picha Lucent Technologies - Proprietary
3440
3440 3440 3541 3541 3642 Issue: 4 3
Page:
7.6
Global Title Translation
3743
8
8.1 8.2
MSC REQUIREMENTS
Digit Analysis Emergency Calls
3743
3743 3743 3743 3844 3844 4551 5359 6066 6066
8.3 Call Control Function (CCF) 8.3.1 Triggering a gsmSCF Interaction 8.3.2 Originating Call Processing
8.3.3
8.3.4 8.3.5 8.3.6
Terminating Call Processing

Call Forwarding Call Processing Connecting to Assisting SSPs and IPs Interworking with other Intelligent Network features
8.3.6.1 8.3.6.2
Trigger Detection Points......................................................................................................... 6066 Multiple control relationships ................................................................................................. 6167
8.3.7
Interworking with Supplementary Services
6167
8.3.7.1 8.3.7.2 8.3.7.3 8.3.7.4 8.3.7.5 8.3.7.6 8.3.7.7 8.3.7.8 8.3.7.9 8.3.7.10 8.3.7.11 8.3.7.12
Calling Line Identification Presentation (CLIP)....................................................................... 6268 Calling Line Identification Restriction (CLIR)......................................................................... 6268 Connected Line Identity Presentation (COLP)......................................................................... 6268 Call Forwarding ..................................................................................................................... 6268 Call Hold ............................................................................................................................... 6369 Call Waiting........................................................................................................................... 6369 Multi Party............................................................................................................................. 6369 Closed User Group (CUG)...................................................................................................... 6369 Mobile Number Portability (MNP) ......................................................................................... 6470 Advice of Charge (AoC)..................................................................................................... 6470 Call Barring ....................................................................................................................... 6470 Interactions with Lucent proprietary features....................................................................... 6470
8.3.8
MAP and CCF Interworking
6571
8.3.8.1 8.3.8.2
Receipt of ProvideSubscriberInfo operation ............................................................................ 6571 R-FSD19337.2-V1>R-FSD19337.2-V1>Receipt of Suppression of Announcement parameter.. 6571
8.4 Service Switching Function (SSF or gsmSSF) 8.4.1 InitialDP Sent to the SCP 8.4.2 Receiving SCP Call Handling Instructions
8.4.2.1 8.4.2.2 8.4.2.3 8.4.2.4
6571 6571 6672
Receipt of CAP Continue operation ........................................................................................ 6773 Receipt of Connect operation.................................................................................................. 6773 Receipt of ResetTimer operation............................................................................................. 6874 Expiration of SSF guard timer (Tssf)....................................................................................... 6874
8.4.3
Event Detection Points
6975
8.4.3.1 8.4.3.2
Receipt of RequestReportBCSMEvent.................................................................................... 6975 Receipt of Cancel operation for pending EDPs and reports ...................................................... 7076
8.4.4
Call Termination
7076
8.4.4.1 8.4.4.2 8.4.4.3 8.4.4.4
Receipt of ReleaseCall operation ............................................................................................ 7076 Call termination due to internal error....................................................................................... 7177 Disconnect from A or B party................................................................................................. 7177 Caller Abandon ...................................................................................................................... 7278
8.4.5
Announcement Session Operations and Results

Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 4
7379
8.4.5.1 8.4.5.2 8.4.5.3 8.4.5.4 8.4.5.5 8.4.5.6 8.4.5.7 8.4.5.8 8.4.5.9 8.4.5.10 8.4.5.11 8.4.5.12 8.4.5.13 8.4.5.14 8.4.5.15
Announcement Configurations................................................................................................ 7379 Contacting an assisting gsmSSF.............................................................................................. 7379 Triggering on an assisting gsmSSF ......................................................................................... 7480 The gsmSSF state machine and the gsmSRF ........................................................................... 7480 Receipt of EstablishTemporaryConnection operation............................................................... 7581 Receipt of DisconnectForwardConnection............................................................................... 7581 Receipt of ConnectToResource............................................................................................... 7682 Receipt of PlayAnnouncement................................................................................................ 7682 Receipt of PromptAndCollectUserInformation ........................................................................ 7682 Receipt of Cancel operation for announcement sessions ...................................................... 7783 Sending CAP Canceled error .............................................................................................. 7884 Sending CAP Cancel Failed error ....................................................................................... 7884 Sending PromptAndCollectUserInformation result.............................................................. 7985 Sending SpecializedResourceReport ................................................................................... 7985 Expiration of Tssf timer during announcement session ........................................................ 8086
8.4.6
8.4.6.1 8.4.6.2 8.4.6.3 8.4.6.4 8.4.6.5
Announcement and digit collection: intermediate states
8086
Connection establishment to IP or Assisting SSP..................................................................... 8086 Connection establishment from internal SRF........................................................................... 8187 Connection release to internal SRF ......................................................................................... 8288 Release of Temporary Connection from Call Control............................................................... 8288 Announcement session: miscellaneous.................................................................................... 8389
8.4.7
Monitoring State
8591
8.4.7.1 8.4.7.2 8.4.7.3 8.4.7.4 8.4.7.5 8.4.7.6
Receipt of RequestReportBCSMEvent.................................................................................... 8591 Disconnect or Abandon .......................................................................................................... 8692 Timer Expiration.................................................................................................................... 8692 Receipt of CAP Cancel for pending EDPs and reports ............................................................. 8894 Answer event detected............................................................................................................ 8894 Pre-answer events detected ..................................................................................................... 8995
8.4.8
8.4.8.1 8.4.8.2 8.4.8.3 8.4.8.4
Billing and Information request operations
9096
Receipt of ApplyCharging operation ....................................................................................... 9096 Receipt of SendChargingInformation operation....................................................................... 9096 Receipt of FurnishChargingInformation operation ................................................................... 9197 Receipt of CallInformationRequest operation .......................................................................... 9197
ASSISTING MSC
9298
9298 9298 9399 96102 96102 96102
9.1 Assisting Call Control State Machine 9.1.1 Receipt of Initial Request from Initiating MSC 9.1.2 Awaiting Instructions on Announcement Sessions 9.2 Process Assisting_gsmSSF 9.2.1 Requesting Instructions from the gsmSCF
9.2.2
9.2.2.1 9.2.2.2 9.2.2.3 9.2.2.4 9.2.2.5 9.2.2.6 9.2.2.7
gsmSCF Instructions
Receipt of ResetTimer operation............................................................................................97103 Receipt of ConnectToResource operation...............................................................................97103 Receipt of DisconnectForwardConnection operation ..............................................................98104 Receipt of PlayAnnouncement operation................................................................................99105 Receipt of PromptAndCollectUserInformation operation ........................................................99105 Receipt of Cancel operation for announcement sessions........................................................100106 Sending PromptAndCollectUserInformation result ...............................................................101107
Author: Marianne Picha Lucent Technologies - Proprietary
Page:
Issue: 4 5
9.2.2.8 9.2.2.9
Sending SpecializedResourceReport ....................................................................................101107 Expiration of Tssf timer during announcement session .........................................................102108
10
MAP REQUIREMENTS
103109
103109 103109 104110 104110 105111 105111 105111 106112 106112 107113 107113 108114
10.1 HLR !" VLR Information Flows 10.1.1 MAP ProvideSubscriberInfo operation 10.1.2 MAP Insert Subscriber Data operation 10.1.3 Map DeleteSubscriberData operation 10.1.4 Map UpdateLocation operation 10.1.5 Map RestoreData operation 10.1.6 Map ProvideRoamingNumber operation 10.2 HLR !" GMSC Information Flows 10.2.1 MAP SendRoutingInfo operation 10.3 VMSC !" GMSC Information Flows 10.3.1 MAP ResumeCallHandling operation 10.4 MSC to gsmSCF Information Flows
11
11.1
CAP REQUIREMENTS
CAP Application Contexts
108114
108114 109115 109115 109115 110116 110116 110116 111117 111117 111117 112118 112118 113119 113119 114120 114120 115121 115121 116122 116122 116122 117123 118124 119125 119125 Issue: 4 6
11.2 CAP Operations 11.2.1 CAP ActivityTest operation 11.2.2 CAP ApplyCharging operation 11.2.3 CAP ApplyChargingReport operation 11.2.4 CAP AssistRequestInstructions operation 11.2.5 CAP CallInformationReport operation 11.2.6 CAP CallInformationRequest operation 11.2.7 CAP Cancel operation 11.2.8 CAP Connect operation 11.2.9 CAP ConnectToResource operation 11.2.10 CAP Continue operation 11.2.11 CAP DisconnectForwardConnection operation 11.2.12 CAP EstablishTemporaryConnection operation 11.2.13 CAP EventReportBCSM operation 11.2.14 CAP FurnishChargingInformation operation 11.2.15 CAP InitialDP operation 11.2.16 CAP ReleaseCall operation 11.2.17 CAP RequestReportBCSMEvent operation 11.2.18 CAP ResetTimer operation 11.2.19 CAP SendChargingInformation operation 11.2.20 CAP PlayAnnouncement operation 11.2.21 CAP PromptAndCollectUserInformation operation 11.2.22 CAP SpecializedResourceReport operation 11.2.23 Operation Timers QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary
Page:
11.3 11.4
CAP and ISUP Interworking CAP and RANAP Interworking
120126 120126
12 13
13.1 13.2 13.3
INTERNAL ANNOUNCEMENT INTERFACE BILLING REQUIREMENTS

Mobile Origination Call Record Mobile Originated Call Forwarding Call Record Terminating CAMEL Call Record
121127 121127
121127 122128 124130
14 15
PERFORMANCE REQUIREMENTS
126133
APPENDIX 1: CALLING HIERARCHIES IN CAMEL STANDARDS 126133
16 APPENDIX 2: ALGORITHM FOR HANDLING CAMEL DATA RECEIVED AT THE GMSC 130137
Table of Figures
FIGURE 1 - CAMEL ARCHITECTURE FIGURE 2 - SUNNY DAY CALL WITH A PARTY DISCONNECT FIGURE 3 - WARNING TONE PLAYS FIGURE 4 - INTERVAL TIMER EXPIRES, CALL IS DISCONNECTED FIGURE 5 - TWO APPLY CHARGING OPERATIONS FIGURE 6 - SWITCH BASED ANNOUNCEMENT FIGURE 7 - IP BASED ANNOUNCEMENT FIGURE 8 - MOBILE TERMINATION WITH CAMEL AND ANY TIME INTERROGATION FIGURE 9 - TERMINATION WITH GSMSCF MODIFIED NUMBER FIGURE 10 - TERMINATION WITH UNMODIFIED NUMBER FIGURE 11 - CALL FORWARDING UNCONDITIONAL FIGURE 12 - CALL FORWARDING ON MOBILE STATION NOT REACHABLE (PART 1) FIGURE 13 - CALL FORWARDING ON MOBILE STATION NOT REACHABLE (PART 2) FIGURE 14 - CAMEL CALL FORWARDING FIGURE 15 - CALL FORWARDING AT THE VMSC FOR A CAMEL SUBSCRIBER FIGURE 16 - VLR PROCESSING STRUCTURE IN CAMEL SPEC 03.78 FIGURE 17 - TERMINATING ARCHITECTURE FIGURE 18 - CALL FORWARDING STRUCTURE IN CAMEL SPEC 03.78 152 162 172 182 192 202 212 232 242 252 262 272 282 292 302 402 462 542
Page:
Issue: 4 7
1 Feature Description
1.1 Scope
This requirements document specifies CAMEL requirements for the 3G UMTS MSC. The requirements cover mainly feature server functionality, but there is an impact on the LMS, and so the level of this document is technically 3G-MSC.
1.2
Guide to Requirements
Each requirement for the 3G MSC is specified using a RADIX macro. Each RADIX macro is individually labeled " < R-FSD19337.P-XYZV1V1>" ".P" represents the CAMEL phase, e.g., ".2" signifies CAMEL phase 2. "XYZ" is a unique number that identifies the requirement. "V1" signifies the first version of a requirement. Bold text specifying the requirement Notes sections contains information for reference, but is not a normative part of the requirement. used to reference the inputs used for this requirement owner/author of the requirement used to provide a keyword describing the functional area of the requirement.
Requirement text Notes:
References: Owner: Keyword:
1.3
History / Change Record

Date 20-oct-00 22-Nov-00 18-oct-01 Author A. McClurg A. McClurg M.Picha Chapte r Change Description Initial version Review comments incorporated MRs 17711, 17718, 17719, 17729, 17783, 17799 MRs 17861, 17951, 17999, 18117 (IMR 747756) MRs 19163, 19627, 19628, 19740, 19742, 19737
Issue.Version Draft 1.0 Accepted 1.0 Accepted 2.0
Version 3.0 Version 4.0
20-feb-02
M.Picha M.Picha, A.Remoquillo
All (tagged v1.01) Tagged v1.02 Tagged v1.03
1.4
Benchmark Dates
Original Estimated Date Updated Estimated Date Actual Date Comments
Benchmark Definition FSD Initiated
Page:
Issue: 4 8
Benchmark Definition Champion Assigned FDT Assigned Critical Reviewers Assigned Draft Available Review (desktop) Draft 2 Available Review Ready for Approval
Original Estimated Date
Updated Estimated Date
Actual Date
Comments
1.5
Open Issues
Date Issue Resolution and date
1.6
Implementation Decision Record

Date Implementation Decision Resolution and date
1.7
Competitive Information
CAMEL has had a high profile with the advent of prepaid services in GSM networks. Prepaid for voice, short messages and packet data continues to be in demand by network operators. It is safe to say that without a CAMEL product, many operators would consider doing business with Lucent a non-starter.
1.8
Relation to Other Features
CAMEL has known interactions with other GSM standard features such as standards supplementary services, Optimal Routing and Call Completion to Busy Subscriber. Some of these interactions will be detailed in this requirements document.
1.9
Acknowledgements
The author would like to thank all of the people who provided input and advice about the CAMEL product, including all of the systems engineers, developers and feature testers of the 5ESS CAMEL and ETSI INAP products.
Page:
Issue: 4 9
1.10 Glossary of Terms & Abbreviations 1.10.1 Standard Terms

2G 2G is used to reference the existing GSM network. A 2G MSC is an MSC as defined by ETSI GSM standards. 3G is used to reference the UMTS network. A 3G MSC is the UMTS Mobile Switching Center with functionality as described by 3GPP standards. Third Generation MSC describes the UMTS Mobile Switching Center that is responsible for Mobility Management, Services, and Call Control for circuit switched services. 3G MSC which also provides Visiting Location Register (VLR) functionality. Third Generation SGSN describes the UMTS Serving GPRS Support Node that is responsible for Mobility Management, Services, and Session Management for packet data services.
3G 3G MSC
3G MSC/VLR 3G SGSN
Intelligent Network The entire set of network elements used for providing Intelligent Network services, including a Service Swithcing Point, a Service Control Point and a Service Management Point. UMSC UMTS Mobile Switching Center describes a UMTS Core Network (CN) element that contains both the 3G MSC and 3G SGSN functions. UMSC is not described in this document.
Vocoder/Vocoding The functional element/process of converting audio signals into low bit rate encoded signals taking into account, Voice Activity, Background Noise, etc. The process exists in the TX side of the bearer traffic.
1.10.2 Standard Acronyms

2G 3G 3GPP ACM AMR ANM ATM AuC BCI BICC CAMEL CDMA CCBS CIS CFB CFNRc CFNRy CFU CLI Second Generation network (GSM) Third Generation network (UMTS) Third Generation Partnership Project (a 3G standards organization) ISUP Address Complete Message Adaptive Multi Rate ISUP Answer Message Asynchronous Transfer Mode Authentication Center Backward Call Indicator Bearer Independent Connection Control Customer Application for Mobile network Enhanced Logic Code Division Multiple Access Call Completion to Busy Subscriber Call Intercept System Call Forwarding Busy Call Forwarding Not Reachable Call Forwarding No Reply Call Forwarding Unconditional Calling Line Identity Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 10
Page:
CLIP CLIR COLP COLR CSE DNS EIR ETSI FCAP FTP GGSN GPRS GSM gsmSCF gsmSRF gsmSSF HLR IAM IMSI IMUI IN INAP IP IP ISDN Iu IWF LA LAC LAI LCS LM MAP MM MO MS MSC MT OAM OAM&P NNI OMC OSA PCM PLMN PS PSPDN PSTN PVC QoS RAB RANAP RNC RNS
Calling Line Identity Presentation Calling Line Identity Presentation Restriction Connected Line Identity Presentation Connected Line Identity Presentation Restriction CAMEL Service Environment (logical Service Control Point) Domain Name Server Equipment Identity Register European Telecommunications Standards Institute Fault, Configuration, Accounting, Performance File Transfer Protocol Gateway GPRS Support Node Generalize Packet Radio Services Global System for Mobile Communications CAMEL Service Control Function CAMEL Specialized Resource Function CAMEL Service Switching Function Home Location Register ISUP Initial Address Message International Mobile Station Identification International Mobile User Identification Intelligent Network Intelligent Networking Application Part Internet Protocol Intelligent Peripheral Integrated Services Digital Network Interface between the UTRAN and the Core Network Inter-working Function Location Area Local Area Code Location Area Identification Location Services Location Management Mobile Application Part Mobility Management Mobile Origination Mobile Station Mobile Switching Center Mobile Termination Operation, Administration and Maintenance Operation, Administration, Maintenance & Provisioning Network to Network Interface Operations Management Center Open Services Architecture Pulse Code Modulation Public Land Mobile Network Packet Switched Packet Switched Public Data Network Public Switched Telephone Network Permanent Virtual Circuit Quality of Service Radio Access Bearer Radio Access Network Application Part Radio Network Controller Radio Network System Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 11
RNTI RRC RTCP RTP SoLSA SSCF SSCOP SCF SCP SGSN SMP SMS SMS SMSC SN SNMP SRF SRNS SS7 SSF SSP STP TCP TFTP TMSI UCN UDI UNI URA UTRAN VLR VMS UE UEA UIA VLAN UP USSD
Radio Network Temporary Identifier Radio Resource Control Real Time Control Protocol Real Time Protocol Support of Localized Service Area Service Specific Convergence Function Service Specific Connection Oriented Protocol Service Control Function Service Control Point Serving GPRS Support Node Service Management Point Service Management System (Lucent SMP) Short Message Service Short Message Service Center Service Node Simple Network Management Protocol Specialized Resource Function Serving RNS Signaling System 7 Service Switching Function Service Switching Point Signal Transfer Points Transmission Control Protocol Trivial File Transfer Protocol Temporary Mobile Station Identification UMTS Core Network User Data Input User to Network Signaling UTRAN Routing Area UMTS Terrestrial Radio Access Network Visitor Location Register Voice Messaging Service User Equipment, same as MS in GSM UMTS Encryption Algorithm UMTS Integrity Algorithm Virtual Local Area Network User Plane Unstructured Supplementary Service Data
1.10.3 Lucent Acronyms

AG AP CN CSP DS DSI FS IPDC IWU LMS LSS MG Access Gateway Adjunct/Application Processor Core Network Centralized Services Platform (part of Lucent SoftSwitch) Device Server Device Server Interface Feature Server Internet Protocol for Device Control Interworking Unit (same as IWF for data/fax) Lucent Media Server (formerly MMRS) Lucent SoftSwitch Media Gateway Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 12
MMRS
Multimedia Resource Server
SRD SSP TAG TC TPU WAG WSG
System Requirements Document SoftSwitch Server Platform Trunk Access Gateway Transcoder Traffic Processing Unit Wireless Access Gateway Wireless Signaling Gateway.
Overview
This document contains the feature level requirements for CAMEL phase 2 for the 3G UMTS MSC. CAMEL (Customised Application for Mobile network Enhanced Logic) is a GSM and 3GPP standardized way of allowing mobile subscribers to access IN based services while either in their home or visited networks.
2.1
Scope
The scope of this Feature Specification Document is the functional behavior of the entire MSC for the support of CAMEL. The FSD is designed to give a "black box" view of CAMEL functionality from an MSC perspective, but in addition, it will borrow heavily from the conceptual framework provided by the CAMEL standards, which split the MSC into two functional areas.
2.2
Logical Functionality within the MSC
The CAMEL standards -- ETSI GSM 03.78 for CAMEL phases 1 and 2 and 3GPP 23.078 for CAMEL phase 3 -- split the MSC logically into two functional entities: 1. The Call Control Function (CCF) provides call/service processing and control. Basic CCF functionality to support call processing is specified in the Basic Call specifications 03.18 (releases 98 and earlier) and 23.018 (release 99 and later). CAMEL procedures are called from the CCF to determine if the any CAMEL processing is required. 2. The Service Switching Function (SSF or gsmSSF) is a functional entity that interfaces the CCF in the MSC/GMSC to the Service Control Point (SCP). In the CAMEL standards the SSF is referred to as the gsmSSF to differentiate it from the SSF of wireline IN standards and the SCP is referred to as the gsmSCF.
2.3
Intra-MSC Messaging
Messages between the CCF and gsmSSF processes on the MSC cannot be feature tested, although such intra-MSC messaging will be discussed as part of this specification for specifying feature level behavior. Since the software architecture will include internal MSC processes, the design will make use of intra-MSC messages between the CCF and SSF. From a feature test perspective, however, only messages external to the MSC are testable.
2.4
Intra-MSC States
Although internal states are not formally testable, this FSD will use the concept of states as a way to aid precision and brevity in writing requirements as well as to facilitate understanding. The states used for the Service Switching Function will correspond to the states used in the CAMEL standards. Many requirements will have the format: Initial State: Input: QDI ID: 19337 Date: November 18, 2002
Page:
Issue: 4 13
Conditions: Action: Next State: The reason for introducing states is to maintain consistency with the CAMEL standards and to avoid needless repetition. For example, each of about 20 requirements could begin with the statement: "After a SETUP message has been received and an InitialDP operation has been sent to an SCP, but before a Connect, Continue or ReleaseCall operation has been received back from the SCP, " Or we can use a state, called "Waiting For Instructions" which corresponds to the above condition, and introduce the requirement with the statement: Initial State: Waiting for Instructions.
2.5
Message Error Handling
There are two levels of error checking -- syntactical and semantic. Syntactical level errors occur when required information elements, as specified in ETSI GSM 09.78 or 09.02, are missing or out of range, or when additional information elements are included that are not according to GSM specifications. Semantic level errors occur when the contents of the information elements are not appropriate for the particular context or conditions, as specified in ETSI GSM 03.78 or 03.18. Syntactical checking will be done by the decoding functions, and the specific errors will be specified in the protocol sections, i.e., for CAP and MAP. Semantic errors will be discussed in sections that deal with the actions required when operations are received that have passed syntactical checks.
2.6
Notes for Feature Testers
Some of the requirements in this FSD will be testable as stand alone entities, e.g., a requirement for being able to provision certain subscriber data. Other requirements will be part of larger call scenarios, and feature tests will need to be written that encompass multiple requirements. An example would be a prepaid call scenario involving the running of timers and the playing of warning tones as credit expiration approaches. In some cases, one requirement may result in multiple feature tests, particularly where more than one state is combined because of identical processing.
Page:
Issue: 4 14
CAMEL Architecture
The following figure illustrates the overall CAMEL architecture.

MAP, etc.
HLR record CAMEL info
gsmSCF
(SCP)
HLR
MAP CAP MAP
HPLMN VPLMN
Roaming Leg VLR record CAMEL
MAP
CAP MAP
Incoming Call
Gateway v MSC
info
VMSC/VLR
Forwarding Leg
gsmSSF
MO Call: Outgoing Leg
Figure 1 - CAMEL architecture The Visited MSC (VMSC) can be either in the home network or a visited network; the latter case is shown in the diagram. CAMEL can be invoked for mobile originations, mobile terminations or call forwarding. The VMSC is responsible for mobile originations and conditional call forwarding (call forwarding on busy, no reply and mobile station not reachable in the case of no paging response). VMSC call forwarding is referred to as late call forwarding. The GMSC is responsible for mobile terminations and call forwarding unconditional and some cases of call forwarding on mobile station not reachable. GMSC call forwarding is referred to as early call forwarding.
4 4.1
Scenarios Relation between external and internal messages
In many cases, there will be a direct correlation between internal CCF to gsmSSF messages and external CAP messages. In some cases however, the internal messages will not result in or be the result of an external stimulus.
4.2
Originating Call Scenarios
The following figures show the call flows for a typical prepaid SIM service.
4.2.1 Sunny Day Call: A-party disconnect
Page:
Issue: 4 15
MSC
CCF
SETUP (A)
CSE
gsmSCF
InitialDP (DP2) RRBE(7N, 9A-N, 9B-N) CallInformationRequest
gsmSSF
Int_Inv_gsmSSF
IAM (B) ACM (B) ANM (B)
Int_Continue
ApplyCharging(interval) Continue
Int_DP_O_Answer
EventReportBCSM (7-N)
Start timer: (Tcp - 30) seconds
DISCONNECT(A)
REL (B)
Int_DP_O_Disc(A)
Stop Timer
EventReportBCSM (9A-N) CallInformationReport ApplyChargingReport Prearranged End
Figure 2 - Sunny day call with A party disconnect
Page:
Issue: 4 16
4.2.2 Warning Tone Played - A-party disconnect

In the following scenario, an interval timer is sent in an ApplyCharging operation and thirty seconds before expiration of the interval timer, a warning tone is played. Before the final 30 seconds has elapsed, the CAMEL subscriber (A-party) disconnects.
MSC
CCF
SETUP (A)
CSE
gsmSCF
InitialDP (DP2) RRBE(7N, 9A-N, 9B-N) ApplyCharging(interval) FurnishChargingInfo
gsmSSF
Int_Inv_gsmSSF
IAM (B) ANM (B)
Int_Continue
Int_DP_O_Answer
Continue EventReportBCSM (7-N)
In-band tone(A)
Int_Apply_Tone
DISCONNECT(A)
(Tcp - 30) seconds
Start timer: 30 seconds
Int_DP_O_Disc(A)
REL (B)
EventReportBCSM (9A-N) ApplyChargingReport Prearranged End
Figure 3 - Warning Tone Plays
Page:
Issue: 4 17
4.2.3 Interval Timer Expires

In the following scenario, the warning tone plays and the CAMEL subscriber does not disconnect before the final 30 seconds have elapsed. A parameter in the ApplyCharging indicated that the call should be released upon timer expiration and so the call is torn down. Note that when the MSC tears down the call, the armed A and B disconnect events are not reported.
MSC
CCF
SETUP (A)
CSE
gsmSCF
InitialDP (DP2) RRBE(7N, 9A-N, 9B-N) ApplyCharging(intvl, rel=y) Continue EventReportBCSM (7-N)
gsmSSF
Int_Inv_gsmSSF
IAM (B) ANM (B)
Int_Continue
Int_DP_O_Answer
(Tcp - 30) seconds
In-band tone(A) Int_Apply_Tone
Start timer: 30 seconds Tcp expires, Release = Yes
Int_Release
DISCONNECT(A)
ApplyChargingReport
REL (B) Prearranged End
Figure 4 - Interval timer expires, call is disconnected
Page:
Issue: 4 18
4.2.4 Two Apply Charging Operations

In the following scenario, the gsmSCF (SCP) sends two ApplyCharging operations with different interval times. For the first, release on timer expiration is not specified and for the second, release is specified. Both interval timers are allowed to expire, and the second causes the call to be torn down. The delta timer run on the gsmSSF between the sending of the first ApplyChargingReport and the receipt of the second ApplyCharging is to allow the interval sent in the second ApplyCharging to be accurately timed. The second interval will be timed from the sending of the previous ApplyChargingReport and not from the receipt of the second ApplyCharging.
M SC
CCF
SE TU P (A )
C SE
g sm S C F
In itialD P (D P 2) R R B E(7N , 9 A -N , 9 B -N ) A pply C ha rging(intv l, rel= n ) C o ntinu e E ventR eportB C S M (7-N )
S tart tim er: T cp - 3 0
g sm SS F
In t_In v_g sm S S F
IA M (B ) A N M (B )
In t_ C on tinue
In t_ D P _ O _ A n sw er
In-band tone (A)
Int_A p ply_T one S tart tim er:3 0 second s T cp ex pires, R elease = N o S tart d elta tim er S top delta tim er
A pp ly C ha rging R eport A pply C ha rging(intv l(2 ), rel= y)

T c p (2 ) = T c p (2 ) - d e lta S tart tim er: T c p (2 ) -30 Start tim er:3 0 second s Tcp(2) expires, R elease =Y es
In-band tone(A )
D ISC O N N EC T(A )
In t_ A p p ly_ T on e In t_R elease
R E L (B )
A p ply Ch arg ing R epo rt Prea rran ge d En d
Figure 5 - Two Apply Charging operations
Page:
Issue: 4 19
4.2.5 Switch Based Announcement Prior to Call Completion

In the following scenario, the gsmSCF instructs the gsmSSF to play a switch based announcement prior to the call being routed.
MSC
CCF
SETUP (A)
gsmSSF
gsmSCF
CSE
Int_Inv_gsmSSF
_get_annc_resrc _play_annc(id)
_rt_to_annc
InitialDP (DP2) ConnectToResource PlayAnnouncement (ID)
PROGRESS(A)
_Annc_Complete _annc_complete
SpecialisedResourceReport RRBE(7N, 9A-N, 9B-N) CallInformationRequest ApplyCharging(interval) Continue
Int_Continue
Int_DP_O_Answer
EventReportBCSM (7-N)
DISCONNECT(A)
REL (B)
Int_DP_O_Disc(A)
Stop Timer
Figure 6 - Switch based announcement
Page:
Issue: 4 20
4.2.6 IP Based Announcement Prior to Call Completion

In the following scenario, the gsmSCF instructs the gsmSSF to connect to an external IP (or assisting MSC). In CAMEL spec 03.78, messages are shown as going directly from the gsmSSF to an external IP, but this scenario shows the CCF acting as the go-between.
CCF
SETUP (A)
MSC
gsmSSF
gsmSCF
InitialDP (DP2)
CSE
Int_Inv_gsmSSF
_route_to_ip
IAM(IP)
PROGRESS(A)
EstablishTemporaryConnection
ANM(IP)
CONNECT(A) REL(IP)
_disc_to_ip
Int_Continue
DisconnectForwardConnection RRBE(7N, 9A-N, 9B-N) CallInformationRequest FurnishChargingInfo ApplyCharging(interval) Continue EventReportBCSM (7-N)
Int_DP_O_Answer
DISCONNECT(A)
REL (B)
Int_DP_O_Disc(A)
Stop Timer
Figure 7 - IP based announcement and call completion to B-party
4.2.7 IP based announcement prior to call to busy B-party

In the following scenario, the gsmSCF instructs the gsmSSF to connect to an external IP (or assisting MSC). Unlike the previous scenario, the B-party exchange returns busy. The MSC QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 21
Page:
does not return a PROGRESS to the mobile indicating busy, since a CONNECT has already been sent. Instead, the MSC returns a DISCONNECT with cause = 17 (User Busy) to the mobile.
CCF
SETUP (A)
MSC
gsmSSF
InitialDP
gsmSCF
CSE
Int_Inv_gsmSSF
_route_to_ip
IAM(IP)
PROGRESS(A)
EstablishTemporaryConnection
ANM(IP)
CONNECT(A) REL(IP)
_disc_to_ip
DisconnectForwardConnection RRBE(7N, 9A-N, 9B-N) CallInformationRequest
IAM (B)
DISCONNECT(A)
Int_Continue
Int_DP_O_Busy Int_DP_O_Disc(A)
ApplyCharging(interval) Continue
CPG (B-party Busy) REL (B) EventReportBCSM (9A-N) CallInformationReport ApplyChargingReport Prearranged End
Figure 8 - IP based announcement and B-party busy
4.3
Terminating Call Scenarios
4.3.1 Basic Mobile Termination with CAMEL

The following figure shows a typical mobile terminated scenario with a CAMEL interaction including the gsmSCF requesting location and state information from the HLR, which in turn forwards the request to the VMSC.
Page:
Issue: 4 22
HLR
2.SRI(1)
5: ATI 12: PRN Ack 7. PSI Ack
8: ATI Ack
gsmSCF_1
10.SRI(2) 4.InitialDP 11: PRN 6: PSI 9. ApplyCharging, Continue 14. IAM (MSRN) (15. ResumeCallHandling*) 13.SRIAck (MSRN)
3.SRIAck (T-CSI)
1.IAM
GMSC/ gsmSSF
VMSC
Figure 9 - Mobile Termination with CAMEL and Any Time Interrogation
*A ResumeCallHandling is sent if Call Forwarding on Busy, No Reply or Not Reachable is

invoked and then Optimal Routing is invoked. Legend: SRI = MAP SendRoutingInformation operation Ack = result of an operation (e.g., SRI Ack is the result of the SRI operation) ATI = MAP AnyTimeInterrogation operation PSI = MAP ProvideSubscriberInfo operation PRN = MAP ProvideRoamingNumber IAM = ISUP Initial Address Message MSRN = Mobile Station Roaming Number (used to route from GMSC to VMSC)
Page:
Issue: 4 23
4.3.2 Termination with gsmSCF Modified Number

The following scenario shows a mobile termination for a CAMEL subscriber where the gsmSCF modifies the routing number.
IAM
CCF
gsmSSF SRI
HLR
SCP
VMSC
SRI ack (T-CSI)

Int_Inv_gsmSSF
InitialDP Connect(CMN)
Int_Connect
IAM
Figure 10 - Termination with gsmSCF modified number Legend: T-CSI = Terminating CAMEL Subscription Information CMN = CAMEL Modified Number, or gsmSCF translated number
Page:
Issue: 4 24
4.3.3 Mobile Termination with Unmodified Number

The following scenario shows a mobile termination for a CAMEL subscriber where the gsmSCF does not modify the routing number. This will typically happen for prepaid SIM services. Since the call must be delivered to the mobile subscriber as originally dialed, a second query is launched to the HLR (SRI 2) and a routing number is obtained as per standard GSM.
IAM
CCF
gsmSSF SRI(1) SRI ack (T-CSI)
HLR
SCP
VMSC
Int_Inv_gsmSSF
InitialDP Continue
Int_Continue
SRI(2) PRN SRI ack (MSRN) IAM (MSRN) PRN ack (MSRN)
Figure 11 - Termination with unmodified number
4.4
Call Forwarding Call Scenarios
CAMEL interactions with call forwarding can take place at the GMSC (Call Forwarding Unconditional and Call Forwarding on Mobile Station Not Reachable) or at the VMSC (Call Forwarding on Busy, Call Forwarding on No Reply and some instances of Call Forwarding on Mobile Not Reachable). There are two types of call forwarding in the CAMEL context: 1) standard GSM call forwarding, e.g., Call Forwarding Unconditional or Call Forwarding on Busy; and 2) CAMEL call forwarding, which occurs on a GMSC when a combination of events occur, including the gsmSCF supplying call forwarding parameters. This is described in more detail below.
Page:
Issue: 4 25
4.4.1 GSM Call Forwarding Unconditional at GMSC

The following scenario shows CAMEL applied to GSM standard call forwarding. A forwarding number sent from the HLR to the GMSC in a SendRoutingInfo result along with an O-CSI (Originating CAMEL Subscription Information) causes a query to be launched to a gsmSCF.
CCF (GMSC) IAM
gsmSSF
HLR
SCP
C-Exchange
SRI SRI ack (O-CSI, FTN)
Int_Inv_gsmSSF
InitialDP (FTN, Forwarding flag, DP2) ApplyCharging RRBE (7N, 9N-A,B) Continue Int_Continue IAM ANM Int_DP_O_Answer EventReportBCSM(7N) REL
Int_DP_O_Disconnect
EventReportBCSM(9N-B) ApplyChargingReport Prearranged end

Figure 12 - Call Forwarding Unconditional and CAMEL
Page:
Issue: 4 26
4.4.2 Termination with GSM Call Forwarding on Mobile Not Reachable at GMSC
The following two figures show the CAMEL interaction for a terminating call where the gsmSCF arms a detection point for busy, which also serves as a detection point for the invocation of Call Forwarding on Not Reachable (CFNRc) and Call Forwarding on No Reply (CFNRy); the latter is applicable for Optimal Routing. For this scenario, there are two transaction active -- one for the termination and one for the call forwarding invocation. Theoretically, there could be two gsmSCFs involved, although in practice, one gsmSCF may handle both dialogues, and the latter is shown in the scenario.
CCF (GMSC) gsmSSF IAM SRI SRI ack (T-CSI)

Int_Inv_gsmSSF
HLR
CFNRc gsmSCF
VMSC
InitialDP (DP12) ApplyCharging (for termination) RRBE (13N, 14N, 15N, 17N-A,B) Continue
Int_Continue
SRI(suppress T-CSI) SRI ack (FTN, O-CSI)

Int_DP_T_Busy(CF)
PRN PRN error (absent subscriber)
EventReportBCSM(13N, cause = not reachable)

All terminating EDPs except A-Disconnect (17A) are implicitly disarmed
ApplyCharging (for termination)
Figure 13 - GSM Call Forwarding on Mobile Station Not Reachable (part 1)
Page:
Issue: 4 27
CCF (GMSC)
CFNRc (2) gsmSSF C-Exch
HLR SCP InitialDP (DP2, FTN, RedirectingNo=C) ApplyCharging (for CF leg) RRBE (7N, 9N-A,B) Continue Int_Continue IAM (C) ANM (C) Int_DP_O_Answer EventReportBCSM(7N)
Int_Inv_gsmSSF Int_DP_T_Answer
REL (C)
Int_DP_O_Disconnect Int_DP_T_Disconnect
EventReportBCSM(9N-B) ApplyChargingReport(CF) ApplyChargingReport(term) Prearranged End
Figure 14 - GSM Call Forwarding on Mobile Station Not Reachable (part 2)
Page:
Issue: 4 28
4.4.3 CAMEL Call Forwarding

The next figure shows call forwarding that is gsmSCF generated as opposed to being initiated as a standards GSM supplementary service. The HLR must return a T-CSI and an O-CSI, and the gsmSCF, in response to the query initiated by the T-CSI, must send back forwarding information and an indication that the O-CSI is applicable. For this scenario, two separate SCPs are used, one specified by the T-CSI and another by the O-CSI.
CCF (GMSC) gsmSSF IAM
HLR
SCP1
SCP2 C-Exch
SRI SRI ack (T-CSI, O-CSI) Int_Inv_gsmSSF InitialDP(DP12) Connect(CMN, redirecting info, O-CSI applicable) Int_Connect
Int_Inv_gsmSSF
CPG
InitialDP(DP2) ApplyCharging RRBE (9N-A,B) Continue Int_Continue IAM ANM Int_DP_O_Answer REL Int_DP_O_Disconnect EventReportBCSM(9N-B) ApplyChargingReport
Prearranged end
Prearranged end
Figure 15 - CAMEL Call Forwarding
Page:
Issue: 4 29
4.4.4 GSM Call Forwarding at the VMSC

The following figure shows call forwarding at the VMSC for a subscriber with originating CAMEL. Both Call Forwarding on Busy and Call Forwarding on No Reply can trigger a CAMEL interaction. The no reply case is illustrated here, with the call being forwarded to a voice mail system.
CCF (VMSC) IAM
gsmSSF
SCP
MS
Voice Mail System
PAGING REQUEST PAGING RESPONSE ALERTING
No reply from mobile

Int_Inv_gsmSSF
InitialDP(DP2, FTN, Redirecting Number) Connect(CMN)

Int_Connect
IAM
Figure 16 - GSM Call Forwarding at the VMSC for a CAMEL subscriber
5 5.1
CAMEL Standards Standards Documents
Unless otherwise indicated, the standards documents referenced in this specification are highlighted in bold below. The standards referenced are a combination of release 98 and release 99 standards. This combination reflects the belief that for CAMEL Phase 2, the release 98 and release 99 standards are equivalent. The release 98 standards provide a more precise definition of CAMEL Phase 2 because one need not filter out extraneous CAMEL Phase 3 information. Release 99 standards are used either when it is easy to filter out the CAMEL Phase 3 information (e.g. 22.078) or when the standard is shared with other u01.03 features. The relevant standards for CAMEL phase 2 are: # 02.78 v7.1.0 -- CAMEL Phase 2 (release 98), Stage 1 (services description) # 03.78 v7.6.1 -- CAMEL Phase 2 (release 98), Stage 2 (architecture and information flows) # 09.78 v7.1.0 -- CAMEL Phase 2 (release 98), Stage 3 (protocol) QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 30
Page:
# 03.18 v7.4.0 -- Basic Call (release 98) # 04.08 v7.d.0 -- DTAP (release 98) # 08.08 v7.7.0 -- BSSMAP (release 98) The equivalent CAMEL phase 3 and release 99 standards are: # 22.078 v3.8.0 -- CAMEL Phase 3 (release 99), Stage 1 (services description) # 23.078 v3.9.0 -- CAMEL Phase 3 (release 99), Stage 2 (architecture and information flows) # 29.078 v3.7.0 -- CAMEL Phase 3 (release 99), Stage 3 (protocol) # 23.018 v3.8.0 -- Basic Call (release 99) # 24.008 v3.8.0 -- DTAP (release 99) # 29.002 v3.9.0 MAP Spec 3GPP standards for release 99 may be found at the following url: http://www.3gpp.org/ftp/Specs/
5.2
Roadmap to CAMEL Stage 2
The following section provides a guide to the SDLs contained in 03.78. The SDLs contain both processes and procedures. A process is considered to be running at all times, waiting for input messages, either internal or external. A procedure is called from a process or from another procedure. When it is called it is spawned and when it is done with its processing it dies. A procedure may have internal states and inputs, but it is essentially temporary.
5.2.1 Processes and Procedures for Originating Calls

The following tables show the processes and procedures in 03.78 with the calling process/procedure.
Name of CAMEL Procedure

CAMEL_OCH_MSC_INIT CAMEL_Start_TNRy CAMEL_Stop_TNRy CAMEL_OCH_MSC_ANSWER CAMEL_OCH_MSC1 CAMEL_OCH_MSC2 CAMEL_OCH_MSC_DISC1, CAMEL_OCH_MSC_DISC2 CAMEL_OCH_MSC_DISC3 (CAMEL phase 1 only: 03.78) CAMEL_OCH_MSC_DISC4 CAMEL_OCH_ETC, CAMEL_OCH_CTR
Calling Procedure Name ( In23.018 unless

other document specified)
OG_CALL_SETUP_MSC* OCSM OCSM OCSM OCSM OCSM OCSM(35), CAMEL_OCH_MSC_ ANSWER(03.78) OCSM OCSM CAMEL_OCH_MSC_INIT (03.78), CAMEL_OCH_MSC1 (03.78), CAMEL_OCH_MSC2 (03.78), CAMEL_OCH_MSC_DISC2 (03.78) CAMEL_OCH_ETC (03.78), CAMEL_OCH_CTR (03.78)
SEND_ALERTING_IF_REQUIRED, SEND_ACCESS_CONNECT_IF_REQUIRED** *OCSM(OG_CALL_SETUP_MSC) ** Non CAMEL Procedures defined in 023.018 QDI ID: 19337 Date: November 18, 2002
Page:
Issue: 4 31
Name of CAMEL Procedure CAMEL_OCH_VLR Name of CAMEL Process CAMEL_Reconnected_Call_VLR
Calling Procedure Name( Page No. In 23.018 unless other

document specified)
OG_CALL_SUBSCRIPTION_CHECK_VLR Receives initial input message (Send Info for Reconnected Call) from: CAMEL_OCH_MSC1, CAMEL_OCH_MSC2, CAMEL_OCH_MSC_DISC2
5.2.2 Processes and Procedures for Terminating and Forwarded Calls Name of CAMEL Procedure Calling Procedure Name ( In 23.018 unless
CAMEL_SET_ORA_PARAMETERS CAMEL_Start_TNRy CAMEL_Stop_TNRy CAMEL_MT_GMSC_INIT CAMEL_MT_GMSC_NOTIFY_CF CAMEL_MT_GMSC_ANSWER CAMEL_MT_GMSC_DISC1, CAMEL_MT_GMSC_DISC2 CAMEL_MT_GMSC_DISC3 (CAMEL Phase 1) CAMEL_MT_GMSC_DISC4 CAMEL_MT_GMSC_DISC5 CAMEL_MT_GMSC_DISC6 CAMEL_OCH_MSC_DISC3 (CAMEL Phase 1) CAMEL_OCH_MSC_DISC4 CAMEL_OCH_MSC_DISC1, CAMEL_OCH_MSC_DISC2 CAMEL_CF_MSC_INIT CAMEL_CF_MSC_ANSWER CAMEL_OCH_MSC1 CAMEL_OCH_MSC2 CAMEL_MT_ETC, CAMEL_MT_CTR
other document specified) MT_GMSC MT_GMSC, MT_CF_MSC MT_GMSC, MT_CF_MSC Obtain_Routeing_Address Obtain_Routeing_Address MT_GMSC MT_GMSC, CAMEL_MT_GMSC_ ANSWER(03.78) MT_GMSC, Obtain_Routeing_Address
MT_GMSC MT_GMSC MT_CF_MSC, MT_CF_MSC, CAMEL_CF_MSC_ANSWER(03.78) MT_CF_MSC MT_CF_MSC MT_CF_MSC MT_CF_MSC CAMEL_MT_GMSC_INIT(03.78), CAMEL_MT_GMSC_DISC2(03.78), CAMEL_MT_GMSC_DISC4(03.78) CAMEL_MT_GMSC_DISC5(03.78) CAMEL_CF_MSC_INIT(03.78) ICH_MSC CAMEL_MT_ETC(03.78), CAMEL_CF_ETC(03.78) CAMEL_MT_ETC(03.78), CAMEL_MT_CTR(03.78), CAMEL_CF_ETC(03.78), CAMEL_CF_CTR(03.78) CAMEL_MT_GMSC_INIT(03.78), CAMEL_MT_ETC(03.78), CAMEL_MT_CTR(03.78), CAMEL_CF_ETC(03.78), CAMEL_CF_CTR(03.78) Page: Issue: 4 32
CAMEL_CF_ETC, CAMEL_CF_CTR CAMEL_Check_ORLCF_VMSC SEND_ANSWER_IF_REQUIRED** SEND_NETWORK_CONNECT_IF_REQUIRED**
SEND_ACM_IF_REQUIRED**
**Non CAMEL procedure Name of CAMEL Procedure CAMEL_SET_SOA Calling Procedure Name(In 23.018
document specified) unless other
PRN_VLR
5.3
CAMEL Standards and FSD Requirements
Rather than reproduce an entire standards specification, this FSD will follow a high level approach that parallels the CCF and SSF states as specified in 023.018 and 03.78 respectively. Under the requirement for a particular CCF state, any procedures that are listed in bold will be considered covered under that requirement. Some of the called procedures have their own internal states and in some cases, particularly in the gsmSSF state machine, this FSD will specify requirements dealing with those states. The aim of the FSD is to tie requirements to external events, whenever possible, in order to aid feature testers in grouping requirements into scenarios and mapping feature tests to requirements.
5.4
Call Control Function State Machine
Basic Call Control functionality (CCF) is specified in ETSI 03.18 for releases through release 98 and in 3GPP 23.018 for release 99 and later. These documents specify where call control calls CAMEL specific procedure. CAMEL procedures called by the CCF are specified in ETSI 03.78 and 3GPP 23.078.
5.5
Service Switching Function State Machine
The gsmSSF state machine is specified in ETSI 03.78 (through release 98) and 3GPP 23.078 (releases 99 and beyond).
6 6.1
VLR Requirements CAMEL Subscriber Data
ETSI spec 03.08 and 3GPP spec 23.008 contain the data requirements for the HLR and VLR. This FSD will cover VLR data requirements specific to CAMEL. <R-FSD19337.2-2V1.01> The following data is required to be stored on the VLR for CAMEL subscribers. 1. Originating CAMEL subscription information (O-CSI) 2. Supplementary Services notification subscription information (SS-CSI) Notes: This data is sent along with subscriber data to the VLR from the HLR at the time of location update. References: 03.78 section 6; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 33
<End of R-FSD19337.2-2V1> < R-FSD19337.2-4V1.01> Once a subscriber registers on the VLR with a certain level of CAMEL support, that level must be stored for a subscriber. Notes: For example, an MSC may support CAMEL phase 2, but a subscriber may roam in from network that only supports CAMEL phase 1. For this subscriber, only CAMEL phase 1 functionality and operations are applicable. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-4V1>
7 7.1
MSC Data Incoming roaming restrictions for CAMEL subscribers
< R-FSD19337.2-7000V1.02> The MSC/VLR will be able to restrict CAMEL service for roamers. The MSC will store a provisionable and updateable table that can screen incoming roamers for CAMEL at a country level and a PLMN level. The entries in the table can be populated as either "allowed" or "restricted". If CAMEL service is restricted -- because the subscribers home is in a network or country that is restricted -- then the VLR will not indicate CAMEL support in the UpdateLocation operation sent to the HLR, i.e., all phases in the SupportedCamelPhases element of the "vlr-Capability" parameter shall be set to not supported. Notes: 1. It is expected that the country list will be checked first. If the country is allowed or is not restricted, then the PLMN list will be checked. 2. This table will be checked once during location update. If the table is updated during a location update for a subscriber, the restrictions that apply when the data is read will apply. If the restriction data is modified after a subscriber registers, the restriction status applied at the time of registration will still apply until another location registration requiring HLR action occurs. This means that it is not required that, after an update, all VLR records be searched and that remedial action be taken for all subscribers from the affected PLMN or country. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). In version 1.02 removed restriction based on HLR (mr=17999). Owner: Andrew McClurg Keyword: Operations and Maintenance <End of R-FSD19337.2-7000V1>
7.2

Location Numbers
<R-FSD19337.2-7010V1.01> Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 34
Page:
The MSC/VLR will have a table that will have as input the location area and Service Area ID of a subscriber and as output an E.164 location number. The location number will be used to populate the locationNumber field of the InitialDP message. The table will be updatable via administrative terminal, will have insert, delete, update and read capabilities and will contain at least 500 entries. Notes: 1. Thus, for example, a Service Area ID may indicate north Naperville, and this can be mapped to an ISDN number such as 979-1234. 2. This will allow SCPs that are currently set up to use location number to continue to do so without having to modify their service logic to deal with the new CAMEL information in the InitialDP which includes location area and cell ID or Service Area ID. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: Operations and Maintenance <End of R-FSD19337.2-7010V1>
7.3
CAMEL phase supported
<R-FSD19337.2-7020V1V1.01> The MSC/VLR will have parameter that will indicate whether CAMEL is active and the particular phase of CAMEL that is supported. This parameter will be updatable via administrative terminal but will be password protected with a password controlled by Lucent. Notes: 1. This could be accomplished by having a single parameter with values: 0 - CAMEL not supported; 1 - CAMEL phase 1; 2 - CAMEL phase 2; 3 - CAMEL phase 3, etc. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: Operations and Maintenance <End of R-FSD19337.2-7020V1V1>
7.4
Network Operator Specific parameters
The CAMEL standards are more specific as to the encodings of network operator specific (NOS) parameters than are the corresponding ETSI CS-1 INAP standards. However, there are some NOSs in CAMEL that are left completely up to network operator discretion, as follows: 1. fCIBillingChargingCharacteristics of the FurnishChargingInformation 2. correlationID of the EstablishTemporaryConnection and AssistRequestInstructions operations 3. sCFID of the EstablishTemporaryConnection and AssistRequestInstructions operations In order to expedite the introduction of CAMEL service into a network, some default values for these parameters have been chosen by Lucent -- these are specified in the CAP protocol section requirements of this document. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 35
Page:
<R-FSD19337.2-7030V1.01> It shall be possible, for each of the NOS parameters in the list below, to have its value for a particular network operator set at the time of switch initialization. 1. fCIBillingChargingCharacteristics of the FurnishChargingInformation 2. correlationID of the EstablishTemporaryConnection and AssistRequestInstructions operations 3. sCFID of the EstablishTemporaryConnection and AssistRequestInstructions operations Notes: 1. Default values are specified in the CAP protocol requirements section. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: Operations and Maintenance <End of R-FSD19337.2-7030V1>
7.5
Announcement identifiers for internal gsmSRF
The internal gsmSRF will be provided within the UMTS MSC by the Lucent Media Server (LMS). The feature server communicates with the LMS using DSI messages, and specifies announcements to be played using announcement identifiers understood by the LMS. The gsmSCF also sends announcement identifiers to the gsmSSF within PlayAnnouncement or PromptAndCollectUserInformation operations. In order to provide flexibility, it will be useful to maintain a table on the MSC that maps gsmSCF announcement IDs to LMS announcement IDs. <R-FSD19337.2-7040V1.02> The MSC shall have a table that maps gsmSCF announcement IDs to one or more LMS announcement IDs. The table shall be provisionable and modifiable via adminstrative terminal and shall hold a minimum of 500 entries. Notes: Provisioning should allow mapping from gsmSCF announcement ID to up to 6 LMS announcement Ids. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). In version 1.02, clarified that mapping is to one or more LMS Ids (mr=17951) Owner: Andrew McClurg Keyword: Operations and Maintenance <End of R-FSD19337.2-7040V1> <R-FSD19337.2-7045V1.02> The MSC shall have a table that maps gsmSCF Tone IDs to LMS Tone IDs. The table shall be provisionable and modifiable via adminstrative terminal and shall hold a minimum of 30 entries. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: Added new as v1.02 to specify needed tone mapping (mr=17951) Owner: mpicha Keyword: Operations and Maintenance QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 36
<End of R-FSD19337.2-7045V1>
7.6
Global Title Translation
Populating Global Title tables for Global Title Translation (GTT) will be done by the basic call team. CAMEL makes use of GTT for sending CAP messages to gsmSCFs (SCPs). Global Title addresses for gsmSCFs in supported networks must be populated in the Global Title tables.
8 8.1
MSC requirements Digit Analysis
When a translated number is returned from an SCP, it is useful to be able to analyze it with different digit analysis tables than is used for the original dialed number. In general, an entry point into a digit analysis tree is called a digit analysis selector (DAS). A separate DAS is required for SCP translated numbers. <R-FSD19337.2-7100V1.01> It shall be possible to specify a unique digit analysis selector for translated numbers returned from a gsmSCF. References: Engineerng Judgement Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-7100V1>
8.2
Emergency Calls
An emergency call can be distinguished in two ways: 1. The 3G-MSC receives a CM Service Request with request type set to Emergency Call, followed by an Emergency Setup (ESETUP) message. 2. Digit analysis of the called party number determines that the call is an emergency call. <R-FSD19337.2-7150V1.01> CAMEL is not applicable to an Emergency Setup call. Notes: This requirement is only applicable to case one above. Any call identified as an emergency call as a result of digit analysis will be subject to CAMEL treatment. References: 03.78 section 1 Feature ID: 50.100 Modification Reason: Added new in version 1.01 (mr=17799). Owner: mpicha Keyword: gsmSSF <End of R-FSD19337.2-7150V1>
8.3
Call Control Function (CCF)
This section deals with functionality that is initiated in the Call Control Function (CCF) as specified in ETSI GSM 03.78. Classifying requirements as being CCF initiated or Service Switching Function (SSF) initiated is designed to provide a correspondence with the standards. The QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 37
Page:
requirements themselves are written from a whole MSC perspective, and requirements in this section may have SSF impacts.
8.3.1 Triggering a gsmSCF Interaction

Various events detected by the CCF result in the SSF initiating a query to the SCP to obtain further instructions. Triggering is initiated for three different types of calls: mobile originations, mobile terminations and call forwarding. For Mobile Originations, the CAMEL trigger is detected in the Visited MSC through CAMEL subscriber data stored in the originating subscriber's VLR record. For Mobile Terminations, the CAMEL trigger is handled in the Gateway MSC and the CAMEL data is sent from the HLR to the GMSC in a Send Routing Info result. For Call Forwarding, the CAMEL trigger may be initiated on either the GMSC for GSM standard early call forwarding or CAMEL call forwarding, or on the VMSC for GSM standard late (or conditional) call forwarding. Receipt of terminating CAMEL subscription information (T-CSI) by a GMSC will always result in an SCP interaction, provided that any criteria are met. However, the receipt of an O-CSI by a GMSC may or may not result in a second SCP interaction. The second SCP interaction, if it occurs, can be with the same or a different SCP. For a summary of all the possible interactions with received data and SCP instructions see the appendices.
8.3.2 Originating Call Processing

<R-FSD19337.2-10V1.01> Process: OCH_MSC (023.018, Figure 6) Initial State: Wait for Setup External Input: DTAP SETUP, i.e., from a mobile subscriber Action: the behavior will be as specified in 023.018 Figure 6 -- Process OCH_MSC. Next state: Idle Notes: 1. Procedure OG_Call_Setup_MSC is called, and the bulk of the originating call processing work is done in that procedure. Other actions will be specified in the requirement for that procedure. References: GSM 023.018 figure 6. Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-10V1> <R-FSD19337.2-20V1.01> Procedure: OG_Call_Setup_MSC (023.018, Figure 8) Initial State: None Action: processing will be as in the following procedures: 1. Procedure OG_Call_Setup_MSC (023.018 Figure 8) 2. Process OCH_VLR (023.018 Figure 19) and the two sub-procedures that are called: a) Procedure OG_Call_Subscription_Check_VLR (023.018 Figure 21) b) CAMEL_OCH_VLR (03.78 Figure 21) The essential requirement is that for calls with an SCP interaction, call barring checks must be suspended until the final routing number is known. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 38
Page:
3. CAMEL_OCH_MSC_INIT (03.78 figure 10). CAMEL_OCH_MSC_INIT may call the following procedures: a) CAMEL_OCH_ETC (03.78 figure 17). Depending on whether ISUP or ISDN signaling is used to an IP or Assisting SSP, this procedure can send and receive ISUP or ISDN signaling messages. b) CAMEL_OCH_CTR (03.78 figure 18). c) CAMEL_OCH_MSC_DISC1 (03.78 figure 14) d) CAMEL_OCH_MSC_DISC2 (03.78 figure 15) Next state: Wait For ACM Notes: 1. Procedure OG_Call_Setup_MSC sends an internal message to process OCH_VLR which calls procedure OG_Call_Subscription_Check_VLR. 2. OG_Call_Subscription_Check_VLR performs various checks of subscriber data, but before outgoing call barring checks are made, a call is made to procedure CAMEL_OCH_VLR. 3. The purpose of CAMEL_OCH_VLR is to allow the procedure CAMEL_OCH_MSC_INIT to run before call barring checks are made, in case the SCP returns a different routing number than was originally dialed. After the actual routing number has been determined, then control is returned to OG_Call_Subscription_Check_VLR which does call barring checks and returns an internal message to the MSC indicating the outcome of the checks, i.e., either positive or negative. 4. CAMEL_OCH_MSC_INIT can initiate an SCP dialogue, the results of which can be: # Continue with the call as dialed. # Route the call to a new SCP supplied number. # Disallow the call (i.e., release the connection to the A-party). When CAMEL_OCH_MSC_INIT returns, a resulting return value of "Pass" means that either of the first two options above occurred. Call control simply proceeds to route the call to whatever number is has been returned -- either the originally dialed number or a new SCP supplied number (translated number). A return value of "Fail" means that the call is to be torn down. References: 03.78; 023.018 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-20V1> The following list describes the inputs and outputs of CAMEL_OCH_MSC_INIT: # External Input: Release from the mobile station # External Output: Progress and Release towards the mobile station # Internal Input: Int_gsmSSF_Invoked, Int_Error, Int_Release_Call, Int_Continue, Int_Connect, Int_Establish_Temporary_Connection, Int_Connect_To_Resource, # Internal Output: Int_Invoke_gsmSSF(O-CSI), Int_DP_Collected_Info, Int_O_Exception, Int_DP_O_Abandon The following figure shows the procedure calls and internal messages used by the procedures involved with VLR processing for the previous requirement. The labels at the tops of the lines represent process and procedure names. The dashed lines represent procedure calls and returns with return values noted.
Page:
Issue: 4 39
OG_Call_Setup _MSC IAM Send Info For

Outgoing Call
OCH_VLR
gsmSSF
OG_Call_Subscription _Check_VLR CAMEL_OCH_VLR
Complete Call
CAMEL_OCH _MSC_INIT
Int_Invoke_ gsmSSF
CAP InitialDP
CAP Int_Connect/ Int_Continue Connect/Continue

Send Info For Outgoing Call Complete Call Pass Pass Perform outgoing call barring checks Pass
Figure 17 - VLR processing structure in CAMEL spec 03.78
<R-FSD19337.2-40V1.01> Procedure: Outgoing_Call_Setup_MSC (023.018 Figure 8) Initial State: Wait_For_ACM External Input: Address Complete (e.g., ISUP ACM) Action: Processing will be as in 023.018 figure 8, Procedure Outgoing_Call_Setup. 1. The procedure CAMEL_Start_TNRy (03.78 figure 19) is called to start the CAMEL no reply timer. This timer must be less than the network no reply timer (e.g., for ISUP). Next state: Wait_For_Answer References: 023.018, 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-40V1>
<R-FSD19337.2-50V1.01> Procedure: Outgoing_Call_Setup_MSC (023.018 Figure 8) Initial State: Wait_For_Answer External Input: Answer (e.g., ISUP ANM) Action: Processing will be as in the following procedures: 1. 23.018 procedure Outgoing_Call_Setup (23.018 figure 8 sheets 4 and5). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 40
Page:
2. The procedure CAMEL_Stop_TNRy (03.78 figure 20) is called to stop the CAMEL no reply timer. 3. Procedure CAMEL_OCH_MSC_ANSWER (03.78 figure 11): this procedure is called to notify the gsmSSF that an answer event has occurred and to await possible further instructions from the gsmSSF process. Next state: Wait_For_Clear (via Wait_For_Connect_Ack) Notes: 1. Procedure CAMEL_OCH_MSC_ANSWER is covered under the requirement for Wait_For_ACM state. That procedure can deal with disconnect or release events, meaning that procedures CAMEL_OCH_DISC1 or CAMEL_OCH_DISC2 may be called. Disconnect processing will be handled separately under the requirement for the Wait_For_Clear state in this 23.018 procedure (Outgoing_Call_Setup_MSC). 2. The Wait_For_Connect_Ack state is not considered in this context. References: 23.018, 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-50V1> <R-FSD19337.2-60V1.01> Procedure: Outgoing_Call_Setup_MSC (23.018 Figure 8) Initial State: Wait_For_ACM External Input: Connect (i.e., DTAP CONNECT) from B-party Action: Processing will be as in the following procedures: 1. 23.018 procedure Outgoing_Call_Setup (figure 8 sheets 4 and 5). 2. Procedure CAMEL_OCH_MSC_ANSWER (03.78 figure 11): this procedure is called to notify the gsmSSF that an answer event has occurred and to await possible further instructions from the gsmSSF process. Next state: Wait_For_Clear (via Wait_For_Connect_Ack) Notes: 1. This requirement deals with the case where the B-Party is a mobile subscriber on the same MSC. 2. As with the requirement for the Wait_For_Answer state, procedure CAMEL_OCH_MSC_ANSWER is called which can deal with disconnect or release events. Disconnect processing will be covered separately under the requirement for the Wait_For_Clear state in this same 23.018 procedure (Outgoing_Call_Setup_MSC). 3. The Wait_For_Connect_Ack state is not considered in this context. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-60V1> <R-FSD19337.2-70V1> Procedure: Outgoing_Call_Setup_MSC (23.018 figure 8) Initial State: Wait_For_ACM, Wait_For_Connect_Ack or Wait_For_Answer External Input: A-Party release (e.g., DTAP DISCONNECT) External Output: Release towards B-party (e.g., ISUP REL) Action: Processing will be as in the following procedures: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 41
1. Outgoing_Call_Setup_MSC (23.018 figure 8) sheets 6 and 7. 2. CAMEL_OCH_MSC_DISC4 (03.78 figure 16): if CAMEL phase 2 is active for the subscriber. 3. CAMEL_OCH_MSC_DISC3 (03.78 Rel 97 figure 8.1-6): if CAMEL phase 1 is active for the subscriber. Next state: Null Notes: 1. The degree of CAMEL support is determined at the time of location registration. 2. From the perspective of CAMEL behavior, the states Wait_For_ACM, Wait_For_Connect_Ack and Wait_For_Answer are equivalent. There are CCBS checks that are performed by call control in the Wait_For_ACM state, but these are independent of CAMEL. References: 23.018; 03.78, 03.78 Rel 97 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-70V1> <R-FSD19337.2-80V1.01> Procedure: Outgoing_Call_Setup_MSC Initial State: Wait_For_ACM External Input: B-Party release (e.g,. ISUP REL) External Output: Release towards A-Party (e.g., DTAP DISCONNECT) Action: Processing will be as in the following procedures: 1. Outgoing_Call_Setup_MSC (23.018 figure 8) sheet 6. 2. CAMEL_OCH_MSC1 (03.78 figure 12): if CAMEL phase 2 is active for the subscriber and the release cause is other than "No answer from user". 3. CAMEL_OCH_MSC2 (03.78 figure 13): if CAMEL phase 2 is active for the subscriber and the release cause is "No answer from user". 4. CAMEL_OCH_MSC_DISC3 (03.78 Rel 97 figure 8.1-6): if CAMEL phase 1 is active for the subscriber. Next state: Null Notes: 1. The degree of CAMEL support is determined at the time of location registration. 2. CAMEL phase 2 adds event detection points for originating busy and no answer and for route select failure. References: 23.018; 03.78. 03.78 Rel 97 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-80V1>
<R-FSD19337.2-90V1> Procedure: Outgoing_Call_Setup_MSC Initial State: Wait_For_Connect_Ack or Wait_For_Answer External Input: B-Party release (e.g,. ISUP REL) External Output: Release towards A-Party (e.g., DTAP DISCONNECT) Action: Processing will be as in the following procedures: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 42
1. Outgoing_Call_Setup_MSC (23.018 figure 8) sheet 7. 2. CAMEL_OCH_MSC1 (03.78 figure 12): if CAMEL phase 2 is active for the subscriber and the release cause is other than "No answer from user". # If the return from CAMEL_OCH_MSC1 is "reconnect" then procedure CAMEL_Stop_TNRy is called to stop the no reply timer. 3. CAMEL_OCH_MSC2 (03.78 figure 13): if CAMEL phase 2 is active for the subscriber and the release cause is "No answer from user". 4. CAMEL_OCH_MSC_DISC3 (03.78 Rel 97 figure 8.1-6): if CAMEL phase 1 is active for the subscriber. Next state: Null Notes: 1. The degree of CAMEL support is determined at the time of location registration. 2. CAMEL phase 2 adds event detection points for Busy, No Answer and Route Select Failure. 3. From the perspective of CAMEL behavior, the states Wait_For_ACM, Wait_For_Connect_Ack and Wait_For_Answer are equivalent. There are CCBS checks that are performed by call control in the Wait_For_ACM state, but these are independent of CAMEL. References: 23.018; 03.78, 03.78 Rel 97 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-90V1> <R-FSD19337.2-100V1.01> Procedure: Outgoing_Call_Setup_MSC Initial State: Wait_For_ACM, Wait_For_Connect_Ack, Wait_For_Answer or Wait_For_Clear Internal Input: Int_Release_Call -- sent by the gsmSSF when a CAP ReleaseCall operation is received from the SCP. External Output: 1. Release towards A-Party (i.e., DTAP DISCONNECT) 2. Release towards the B-Party (e.g., ISUP REL) Action: Processing will be as in Outgoing_Call_Setup_MSC (23.018 figure 8) sheets 6, 7 and 9. Next state: Null Notes: 1. The degree of CAMEL support is determined at the time of location registration. 2. From the perspective of CAMEL behavior, the states Wait_For_ACM, Wait_For_Connect_Ack and Wait_For_Answer are equivalent. There are CCBS checks that are performed by call control in the Wait_For_ACM state, but these are independent of CAMEL. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-100V1>
<R-FSD19337.2-110V1.01> Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 43
Procedure: Outgoing_Call_Setup_MSC Initial State: Wait_For_Answer Internal Input: Expiration of no reply timer (TNRy). External Output: 1. Release towards the B-Party (e.g., ISUP REL) 2. Release towards A-Party (i.e., DTAP DISCONNECT) unless a follow-on call is requested by the SCP. Action: Processing will be as in the following procedures: 1. Outgoing_Call_Setup_MSC (23.018 figure 8) sheet 8 and sheet 2 in the reconnect case. 2. CAMEL_OCH_MSC2 (03.78 figure 13). Next state: Null Notes: 1. The degree of CAMEL support is determined at the time of location registration. 2. From the perspective of CAMEL behavior, the states Wait_For_ACM, Wait_For_Connect_Ack and Wait_For_Answer are equivalent. There are CCBS checks that are performed by call control in the Wait_For_ACM state, but these are independent of CAMEL. 3. CAMEL_OCH_MSC2 handles the internally defined "no answer" event. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-110V1> <R-FSD19337.2-120V1.01> Procedure: Outgoing_Call_Setup_MSC Initial State: Wait_For_Clear External Input: B-Party Release (e.g., ISUP REL) External Output: 1. Release towards the A-Party (DTAP DISCONNECT) either from this procedure or from called procedure CAMEL_OCH_MSC_DISC2, except when a reconnect is to take place. Action: Processing will be as in the following procedures: 1. Outgoing_Call_Setup_MSC (23.018 figure 8) sheet 9 and in the reconnect case, sheet 2. 2. CAMEL_OCH_MSC_DISC2 (03.78 figure 13). Next state: Null Notes: 1. CAMEL_OCH_MSC_DISC2 is the same for both CAMEL phase 1 and phase 2. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-120V1>
<R-FSD19337.2-130V1.01> Procedure: Outgoing_Call_Setup_MSC Initial State: Wait_For_Clear External Input: A-Party Release (i.e., DTAP DISCONNECT) QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 44
External Output: 1. Release towards the B-Party (e.g., ISUP REL) either from this procedure or from called procedure CAMEL_OCH_MSC_DISC1. Action: Processing will be as in the following procedures: 1. Outgoing_Call_Setup_MSC (23.018 figure 8) sheet 9. 2. CAMEL_OCH_MSC_DISC1 (03.78 figure 12). Next state: Null References: 23.018; 03.78 Feature ID: 50.100 Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-130V1>
8.3.3 Terminating Call Processing

Terminating call processing for GSM and UMTS systems is more complex than for wireline networks because of the need to locate the called mobile subscriber's current MSC in real time. The system architecture and interfaces for a terminating call involving CAMEL are illustrated in the following figure. For complete scenarios, see the Scenarios chapter.
Page:
Issue: 4 45
HLR
MAP gsmSCF MAP
MAP CAP, MAP GMSC

CCF/SSF
ISUP, TUP,...
VMSC
CCF/SSF
Figure 18 - Terminating Architecture A SendRoutingInfo (SRI) operation is sent from a Gateway MSC to an HLR when a routing request (e.g., ISUP IAM) is received at the Gateway MSC containing a called party number that is an MSISDN number of a subscriber in the GMSC's network. In response to the SRI, if the subscriber is provisioned with CAMEL subscription information, the HLR will send the CAMEL data back to the GMSC in a SRI result. Before sending back the SRI result, the HLR may optionally send a query to the VMSC where the subscriber is registered to get location and/or state information, and this information will be included in the SRI result returned to the GMSC. The HLR can send both terminating CAMEL subscription information (T-CSI) and originating CAMEL subscription information (O-CSI) to the GMSC. CSIs may also include triggering criteria that add conditions on when an IN interaction will take place. The action of the GMSC depends on four factors that can occur in various combinations: 1. T-CSI 2. O-CSI 3. Forwarding information 4. SCP instructions A complete list of combinations and actions is provided in the Appendix entitled Algorithm for handling CAMEL data received at the GMSC. <R-FSD19337.2-300V1.01> Procedure: MT_GMSC (23.018 figure 35) Initial State: Idle Input: Initial routing message from trunk signaling (e.g., ISUP IAM)
Page:
Issue: 4 46
Output: Depending on the outcome of called procedure Obtain_Routeing_Address one of the following outputs will occur: 1. Initial Address Message (or non-ISUP equivalent) 2. Release to A-Party Actions: the behavior will be as specified in process MT_GMSC (23.018 Figure 35). Next state: Depending on the outcome of called procedure Obtain_Routeing_Address, the state will transition to one of the following: 1. Wait for ACM 2. Wait for Forward ACM 3. Idle Notes: 1. Procedure Obtain_Routeing_Address is called, and the bulk of the initial call processing work is done in that procedure. Separate requirements are specified for procedure Obtain_Routeing_Address 2. Unlike the process for originating calls (OCH_MSC), where a called procedure contains the call control states, process MT_GMSC itself contains the full set of call control states. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-300V1>
<R-FSD19337.2-310V1.01> Procedure: Obtain_Routeing_Address (23.018 figure 36) Initial State: Wait_For_Routeing_Info Input: MAP SendRoutingInfo result with terminating CAMEL subscription information. Actions: Processing will be as in 23.018 figure 36. This requirement covers all of the combinations of CAMEL subscription information that may be received from the HLR and all of the possible SCP instructions. The following procedures relevant to CAMEL are covered under this requirement: 1. CAMEL_MT_GMSC_INIT. The requirements for this procedure are covered under this requirement. CAMEL_MT_GMSC_INIT can receive the following external inputs: a) A-Party Release b) B-Party Release In addition, CAMEL_MT_GMSC_INIT may call the following procedures: a) CAMEL_MT_ETC. If ISUP signaling is used for the connection to the IP or Assisting SSP, then both Address Complete and Answer are of interest to this procedure, in addition to release messages from both parties. Other messages may be received, but CAMEL_MT_ETC is not concerned with them and they are simply relayed to Call Control. If ISDN signaling is used then an ISDN Connect message is of interest. b) CAMEL_MT_CTR 2. If CAMEL_MT_GMSC_INIT returns, "CMN" (CAMEL Modified Number): if the route is not permitted, then CAMEL_MT_GMSC_DISC4 is called for mobiles supporting CAMEL phase 2 and CAMEL_MT_GMSC_DISC3 is called for mobiles supporting CAMEL phase 1. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 47
Page:
3. If CAMEL_MT_GMSC_INIT returns "CAMEL_FTN", then procedure Activate_CF_Process is called which sends a message to process MT_CF_MSC MSC (see Call Forwarding Processing section). 4. If CAMEL_MT_GMSC_INIT returns "GSM_FTN" (standard GSM call forwarding) then CAMEL_MT_GMSC_Notify_CF is called. This procedure notifies the gsmSSF process of a gsm call forwarding event. 5. If CAMEL_MT_GMSC_Notify_CF returns "continue" then the procedure Activate_CF_Process is called which sends a message to process MT_CF_MSC (see Call Forwarding Processing section. 6. If CAMEL_MT_GMSC_Notify_CF returns "reconnect", then this will lead to a reconnection being initiated as per process MT_GMSC, figure 35, sheet 1. 7. If CAMEL_MT_GMSC_INIT returns "MSRN" then normal GSM terminating call processing occurs. Next state: Null Notes: 1. The specific criteria and the matching rules are specified in separate requirements. If there is no terminating CAMEL subscription data or if the triggering criteria do not match, then no IN query is performed, and the state remains NULL. 2. For a complete algorithm covering all of the data combinations that can be received by the GMSC, see the Appendices. References: GSM 23.018 figure 36. 03.78 figure 24 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg <End of R-FSD19337.2-310V1> <R-FSD19337.2-320V1.01> Process: MT_GMSC Initial State: Wait_For_ACM External Input: Address Complete (e.g., ISUP ACM) Action: Processing will be as in 23.018 figure 35, procedure MT_GMSC. 2. The procedure CAMEL_Start_TNRy (03.78 figure 19) is called to start the CAMEL no reply timer. This timer must be less than the network no reply timer (e.g., for ISUP). Next state: Wait_For_Answer References: GSM 23.018 figure 36. 03.78 figure 24 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg <End of R-FSD19337.2-310V1> <R-FSD19337.2-330V1.01> Procedure: MT_GMSC (23.018 Figure 35) Initial State: Wait_For_Answer External Input: Answer (e.g., ISUP ANM) Action: Processing will be as in the following procedures: 1. MT_GMSC (23.018 figure 35 sheet 2). 2. The procedure CAMEL_Stop_TNRy (03.78 figure 20) is called to stop the CAMEL no reply timer. 3. Procedure CAMEL_MT_GMSC_ANSWER (03.78 figure 25): this procedure is called to notify the gsmSSF that an answer event has occurred and if there is a request type detection point armed and to await possible further instructions gsmSSF process. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 48
Next state: If the return from CAMEL_MT_GMSC_ANSWER is "pass" then the next state is Wait_For_Clear. If it return is "fail" then the next state is "Idle". If the return is "reconnect" then processing is as per the reconnect handling of MT_GMSC sheet 1. Notes: 1. Procedure CAMEL_MT_GMSC_ANSWER is covered under this requirement. That procedure can deal with disconnect or release events, meaning that procedures CAMEL_MT_GMSC_DISC1 or CAMEL_MT_GMSC_DISC2 may be called. Disconnect processing will be handled separately under the requirement for the Wait_For_Clear state in this 23.018 process (MT_GMSC). References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-330V1> <R-FSD19337.2-340V1.01> Process: MT_GMSC (23.018 Figure 35) Initial State: Wait_For_ACM External Input: Connect (i.e., DTAP CONNECT) from B-party Action: Processing will be as in the following procedures: 1. 23.018 procedure MT_GMSC (figure 35 sheet 2). 2. Procedure CAMEL_MT_GMSC_ANSWER (03.78 figure 11): this procedure is called to notify the gsmSSF that an answer event has occurred and to await possible further instructions from the gsmSSF process. Next state: If the return from CAMEL_MT_GMSC_ANSWER is "pass" then the next state is Wait_For_Clear. If it return is "fail" then the next state is "Idle". If the return is "reconnect" then processing is as per the reconnect handling of MT_GMSC sheet 1. Notes: 1. This requirement deals with the case where the B-Party is a mobile subscriber on the same MSC. 2. As with the requirement for the Wait_For_Answer state, procedure CAMEL_MT_GMSC_ANSWER is called which can deal with disconnect or release events. Disconnect processing will be covered separately under the requirement for the Wait_For_Clear state in this same 23.018 procedure (MT_GMSC). References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-340V1> <R-FSD19337.2-350V1.01> Procedure: MT_GMSC (23.018 Figure 35) Initial State: Wait_For_Forward_Answer External Input: Answer (e.g., ISUP ANM) Action: Processing will be as in the following procedures: 1. MT_GMSC (23.018 figure 35 sheet 3). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 49
2. Procedure CAMEL_MT_GMSC_ANSWER (03.78 figure 25): this procedure is called to notify the gsmSSF that an answer event has occurred and if there is a request type detection point armed and to await possible further instructions gsmSSF process. Next state: If the return from CAMEL_MT_GMSC_ANSWER is "pass" then the next state is Wait_For_Clear. If the return is "fail" then the next state is "Idle". If the return is "reconnect" then processing is as per the reconnect handling of MT_GMSC sheet 1. Notes: 1. The state Wait_For_Forward_ACM and input Address Complete is not covered as there is no specific CAMEL requirements in that case. 2. Procedure CAMEL_MT_GMSC_ANSWER is covered under this requirement. That procedure can deal with disconnect or release events, meaning that procedures CAMEL_MT_GMSC_DISC1 or CAMEL_MT_GMSC_DISC2 may be called. Disconnect processing will be handled separately under the requirement for the Wait_For_Clear state in this 23.018 process (MT_GMSC). 3. Details of how forwarded calls are handled are presented in the Call Forwarding Processing section below. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-350V1> <R-FSD19337.2-360V1.01> Process: MT_GMSC (23.018 Figure 35) Initial State: Wait_For_Forward_ACM External Input: Connect (i.e., DTAP CONNECT) from B-party Action: Processing will be as in the following procedures: 1. 23.018 procedure MT_GMSC (figure 35 sheet 3). 2. Procedure CAMEL_MT_GMSC_ANSWER (03.78 figure 11): this procedure is called to notify the gsmSSF that an answer event has occurred and to await possible further instructions from the gsmSSF process. Next state: If the return from CAMEL_MT_GMSC_ANSWER is "pass" then the next state is Wait_For_Clear. If it return is "fail" then the next state is "Idle". If the return is "reconnect" then processing is as per the reconnect handling of MT_GMSC sheet 1. Notes: 1. This requirement deals with the case where the B-Party is a mobile subscriber on the same MSC. 2. As with the requirement for the Wait_For_Forward_Answer state, procedure CAMEL_MT_GMSC_ANSWER is called which can deal with disconnect or release events. Disconnect processing will be covered separately under the requirement for the Wait_For_Clear state in this same 23.018 procedure (MT_GMSC). References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-360V1>
Page:
Issue: 4 50
<R-FSD19337.2-370V1.01> Process: MT_GMSC (23.018 figure 35) Initial State: Wait_For_Answer Internal Input: Expiration of no reply timer (TNRy). External Output: 1. Release towards the B-Party (e.g., ISUP REL) 2. Release towards A-Party (e.g., DTAP DISCONNECT) unless a follow-on call is requested by the SCP. Action: Processing will be as in the following procedures: 1. MT_GMSC (23.018 figure 35) sheet 5. 2. CAMEL_MT_GMSC_DISC5 (03.78 figure 29). Next state: Null Notes:. 1. CAMEL_MT_GMSC_DISC5 handles the internally defined "no answer" event. Notes: References: 23.018; 03.78 Modification Reason: In version 1.01, modified references (mr=17711). Feature ID: 50.100 Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-370V1> <R-FSD19337.2-380V1.01> Process: MT_GMSC (23.018 figure 35) Initial State: Wait_For_ACM, Wait_For_Forward_ACM, Wait_For_Answer or Wait_For_Forward_Answer External Input: A-Party Release (e.g., DTAP DISCONNECT) External Output: Release towards B-party (e.g., ISUP REL) Action: Processing will be as in the following procedures: 1. MT_GMSC (23.018 figure 35) sheet 6. 2. CAMEL_MT_GMSC_DISC6 (03.78 figure 30): if CAMEL phase 2 is active for the subscriber. 3. CAMEL_MT_GMSC_DISC3 (03.78 v5.8.0 figure 8.2-9): if CAMEL phase 1 is active for the subscriber. Next state: Idle Notes: 1. CAMEL_MT_GMSC_DISC6 handles the abandon event in CAMEL phase 2. The addition for CAMEL phase 2 is that abandon is a detection point, and so an internal notification is sent to the gsmSSF process to indicate that an abandon event has occurred. 2. CAMEL_MT_GMSC_DISC3 handles the abandon event for CAMEL phase 1. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-380V1> <R-FSD19337.2-390V1.01> Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 51
Process: MT_GMSC (23.018 figure 35) Initial State: Wait_For_ACM, Wait_For_Forward_ACM, Wait_For_Answer or Wait_For_Forward_Answer External Input: B-Party release (e.g,. ISUP REL) External Output: Release towards A-Party (e.g., DTAP DISCONNECT) Action: Processing will be as in the following procedures: 1. MT_GMSC (23.018 figure 35) sheets 6. 2. CAMEL_MT_GMSC_DISC4 (03.78 figure 28): if CAMEL phase 2 is active for the subscriber and the release cause is other than "No answer from user". 3. CAMEL_MT_GMSC_DISC5 (03.78 figure 29): if CAMEL phase 2 is active for the subscriber and the release cause is "No answer from user". 4. CAMEL_MT_GMSC_DISC3 (03.78 v5.8.0 figure 8.2-9): if CAMEL phase 1 is active for the subscriber. Next state: Idle Notes: 1. CAMEL phase 2 adds event detection points for terminating busy and no answer. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-390V1> <R-FSD19337.2-400V1.01> Process: MT_GMSC (23.018 figure 35) Initial State: Wait_For_ACM, Wait_For_Forward_ACM, Wait_For_Answer or Wait_For_Forward_Answer, Wait_For_Clear Internal Input: Int_Release_Call -- sent by the gsmSSF when a CAP ReleaseCall operation is received from the SCP. External Output: 1. Release towards A-Party (e.g., DTAP DISCONNECT) 2. Release towards the B-Party (e.g., ISUP REL) Action: Processing will be as in MT_GMSC (23.018 figure 35) sheets 6 and 7. Next state: Idle References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-400V1> <R-FSD19337.2-410V1.01> Process: MT_GMSC (23.018 figure 35) Initial State: Wait_For_Clear External Input: A-Party Release (e.g., DTAP DISCONNECT) External Output: 1. Release towards the B-Party (e.g., ISUP REL) either from this procedure or from called procedure CAMEL_MT_GMSC_DISC1. Action: Processing will be as in the following procedures: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 52
1. MT_GMSC (23.018 figure 35) sheet 7. 2. CAMEL_MT _GMSC_DISC1 (03.78 figure 12). Next state: Idle Notes: 1. CAMEL_MT_GMSC_DISC1 is the same for CAMEL phases 1 and 2. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-410V1> <R-FSD19337.2-420V1.01> Process: MT_GMSC (23.018 figure 35) Initial State: Wait_For_Clear External Input: B-Party Release (e.g., ISUP REL) External Output: 1. Release towards the A-Party (DTAP DISCONNECT) either from this procedure or from called procedure CAMEL_MT_GMSC_DISC2, except when a reconnect is to take place. Action: Processing will be as in the following procedures: 1. MT_GMSC (23.018 figure 35) sheet 7. 2. CAMEL_MT_GMSC_DISC2 (03.78 figure 13). Next state: Idle Notes: 1. CAMEL_MT_GMSC_DISC2 is the same for CAMEL phases 1 and 2. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-420V1>
8.3.4 Call Forwarding Call Processing

Process MT_CF_MSC is considered to be a "child" process to MT_GMSC, in that it acts in parallel with the latter process, and never runs separately. When MT_CF_MSC is invoked, it receives inputs indirectly from the A-party via MT_GMSC and from the destination exchange directly. Conversely, MT_GMSC receives inputs from the A-party directly and indirectly from the destination exchange via MT_CF_MSC. The following diagram illustrates the relation between the call control processes and procedures (from 03.18 or 23.018) that are involved with call forwarding. Processes are shown at the top with vertical lines indicating their flow of control, and states indicated along the lines. Boxes represent procedures, called either directly by the processes (when on the process's line) or by other procedures, indicated by dashed lines with arrows to the called procedure. Return values are noted along with dashed lines returning to the calling process/procedure.
Page:
Issue: 4 53
IAM
Process MT_GMSC Idle
Process MT_CF_MSC Idle

CAMEL_MT_ GMSC_INIT
Obtain_Routing _Address CAMEL_FTN

GSM_FTN
Forward
PASS Activate_CF_ Process PASS Perform Call Forwarding CAMEL_CF_ MSC_INIT Perform Call Forwarding Ack Internal IAM PASS IAM ACM
Wait For IAM

Wait For ACM
Wait For Forward ACM
ACM
Wait For Forward Answer
Internal ACM
Wait For Answer
Etc...
Etc...
Figure 19 - Call Forwarding structure in CAMEL spec 03.78 Call forwarding may be invoked both through standard GSM call forwarding and through a set of conditions involving both CAMEL subscriber data and SCP instructions. The former is referred as GSM call forwarding and the latter as CAMEL call forwarding. CAMEL call forwarding occurs when all of the following occur: 1. A T-CSI and O-CSI arereturned in the Send Routing Info acknowledgement from the HLR to the GMSC. 2. The SCP returns a Connect operation with the following: # A new translated number (i.e., different from the original dialed number) # An "O-CSI applicable" flag. # Forwarding information (e.g., redirection information) See 03.78 section 7.5.3, "Call Forwarding at the GMSC". The requirements in this section will follow the states in the 23.018 process called "MT_CF_MSC" (figure 42). <R-FSD19337.2-600V1.01> Process: MT_CF_MSC Initial State: Idle Internal Input: "Perform Call Forwarding" from procedure Activate_CF_Process (23.018 figure 41). External Output: Initial Address (e.g., ISUP IAM) Internal Output: "Perform Call Forwarding Ack" or "Perform Call Forwarding negative response". Action: Processing will be as in 23.018 figure 42 "MT_CF_MSC". This process calls procedure CAMEL_CF_MSC_INIT, which may initiate an interaction with an SCP for further QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 54
Page:
call handling instructions. The following procedures relevant to CAMEL are covered under this requirement: 1. CAMEL_CF_MSC_INIT (03.78 figure 39). 2. CAMEL_CF_MSC_INIT may call the following procedures: # CAMEL_CF_ETC # CAMEL_CF_CTR Next state: If CAMEL_CF_MSC_INIT returns "Pass", the next state is "Wait for IAM". If it returns something other than "Pass", then the next state is "Idle". Notes: 1. An SCP interaction due to call forwarding is much like an origination. Thus, as with CAMEL_OCH_MSC_INIT for originations and CAMEL_MT_GMSC_INIT, CAMEL_CF_MSC_INIT can receive internal messages from the gsmSSF process as the latter communicates with an SCP. 2. For forwarded calls, the query message to the SCP indicates that call forwarding has been invoked. See the section on the CAP InitialDP operation. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-600V1> <R-FSD19337.2-610V1.01> Process: MT_CF_MSC Initial State: Wait_For_IAM Internal Input: CF Cancelled (from procedure Activate_CF_Process) External Output: Internal Output: Conditions: Action: Processing will be as in the following procedures: 1. MT_CF_MSC (23.018 figure 42) 2. CAMEL_OCH_MSC_DISC4 (03.78 figure 16): if CAMEL phase 2 is active for the subscriber. 3. CAMEL_OCH_MSC_DISC3 (03.78 v5.8.0 figure 8.1-6): if CAMEL phase 1 is active for the subscriber. Next state: If a CF canceled is received, the next state is "Idle". Notes: 1. The case where an IAM is received from process MT_GMSC in the Wait_For_IAM state is not covered, as there is no specific CAMEL processing involved. The next state in that case is the Wait_For_ACM state. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-610V1>
Page:
Issue: 4 55
<R-FSD19337.2-620V1.01> Process: MT_CF_MSC Initial State: Wait_For_ACM External Input: Address Complete (e.g., ISUP ACM) Action: Processing will be as in 23.018 figure 42, procedure MT_CF_MSC. 1. The procedure CAMEL_Start_TNRy (03.78 figure 19) is called to start the CAMEL no reply timer. This timer must be less than the network no reply timer (e.g., for ISUP). Next state: Wait_For_Answer Notes: References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-620V1> <R-FSD19337.2-630V1.01> Initial State: Wait_For_Answer External Input: Answer (e.g., ISUP ANM) Action: Processing will be as in the following procedures: 1. MT_CF_MSC (23.018 figure 42 sheet 2). 2. The procedure CAMEL_Stop_TNRy (03.78 figure 20) is called to stop the CAMEL no reply timer. 3. Procedure CAMEL_CF_MSC_ANSWER (03.78 figure 40): this procedure is called to notify the gsmSSF that an answer event has occurred and if there is a request type detection point armed and to await possible further instructions gsmSSF process. Next state: If the return from CAMEL_CF_MSC_ANSWER is "pass" then the next state is Wait_For_Clear. If it return is "fail" then the next state is "Idle". If the return is "reconnect" then processing is as per the reconnect handling of MT_CF_MSC sheet 1. Notes: 1. Procedure CAMEL_CF_MSC_ANSWER is covered under this requirement. That procedure can deal with disconnect or release events, meaning that procedures CAMEL_OCH_MSC_DISC1 or CAMEL_OCH_MSC_DISC2 may be called. Disconnect processing will be handled separately under the requirement for the Wait_For_Clear state in this 23.018 process (MT_CF_MSC). References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-630V1> <R-FSD19337.2-640V1.01> Process: MT_CF_MSC (23.018 Figure 42) Initial State: Wait_For_ACM External Input: Connect (i.e., DTAP CONNECT) from B-party Action: Processing will be as in the following procedures: 1. 23.018 procedure MT_CF_MSC (figure 42 sheet 2). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 56
Page:
2. Procedure CAMEL_CF_MSC_ANSWER (03.78 figure 40): this procedure is called to notify the gsmSSF that an answer event has occurred and to await possible further instructions from the gsmSSF process. Next state: If the return from CAMEL_CF_MSC_ANSWER is "pass" then the next state is Wait_For_Clear. If it return is "fail" then the next state is "Idle". If the return is "reconnect" then processing is as per the reconnect handling of MT_CF_MSC sheet 1. Notes: 1. This requirement deals with the case where the B-Party is a mobile subscriber on the same MSC. 2. As with the requirement for the Wait_For_Answer state, procedure CAMEL_CF_MSC_ANSWER is called which can deal with disconnect or release events. Disconnect processing will be covered separately under the requirement for the Wait_For_Clear state in this same 23.018 procedure (MT_CF_MSC). References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-640V1> <R-FSD19337.2-650V1.01> Process: MT_CF_MSC (23.018 figure 42) Initial State: Wait_For_Answer Internal Input: Expiration of no reply timer (TNRy). External Output: 1. Release towards the B-Party (e.g., ISUP REL) 2. Release towards A-Party (via process MT_GMSC) unless a follow-on call is requested by the SCP. Action: Processing will be as in the following procedures: 1. MT_CF_MSC (23.018 figure 42) sheet 4. 2. CAMEL_OCH_MSC2 (03.78 figure 29). Next state: Null Notes: 1. CAMEL_OCH_MSC2 handles the internally defined "no answer" event. References: 23.018 v6.6.0; 03.78 v6.6.0 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-650V1> <R-FSD19337.2-660V1.01> Process: MT_CF_MSC (23.018 figure 42) Initial State: Wait_For_ACM, Wait_For_Answer External Input: A-Party Release (via process MT_GMSC) External Output: Release towards B-party (e.g., ISUP REL) Action: Processing will be as in the following procedures: 1. MT_CF_MSC (23.018 figure 42) sheet 3. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 57
2. CAMEL_OCH_MSC_DISC4 (03.78 figure 16): if CAMEL phase 2 is active for the subscriber. 3. CAMEL_OCH_MSC_DISC3 (03.78 v5.8.0 figure 8.1-6): if CAMEL phase 1 is active for the subscriber. Next state: Idle Notes: 1. CAMEL_OCH_MSC_DISC4 handles the abandon event in CAMEL phase 2. The addition for CAMEL phase 2 is that abandon is a detection point, and so an internal notification is sent to the gsmSSF process to indicate that an abandon event has occurred. 2. CAMEL_OCH_MSC_DISC3 handles the abandon event for CAMEL phase 1. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-660V1> <R-FSD19337.2-670V1.01> Process: MT_GMSC (23.018 figure 42) Initial State: Wait_For_ACM, Wait_For_Answer External Input: B-Party release (e.g,. ISUP REL) External Output: Release towards A-Party (via process MT_GMSC) Action: Processing will be as in the following procedures: 1. MT_CF_MSC (23.018 figure 42) sheets 3. 2. CAMEL_OCH_MSC1 (03.78 figure 12): if CAMEL phase 2 is active for the subscriber and the release cause is other than "No answer from user". 3. CAMEL_OCH_MSC2 (03.78 figure 13): if CAMEL phase 2 is active for the subscriber and the release cause is "No answer from user". 4. CAMEL_OCH_MSC_DISC3 (03.78 v5.8.0 figure 8.1-6): if CAMEL phase 1 is active for the subscriber. Next state: Idle Notes: 1. The degree of CAMEL support is determined at the time of location registration. 2. CAMEL phase 2 adds event detection points for busy and no answer. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-670V1> <R-FSD19337.2-680V1.01> Process: MT_GMSC (23.018 figure 42) Initial State: Wait_For_ACM, Wait_For_Answer or Wait_For_Clear Internal Input: Int_Release_Call -- sent by the gsmSSF when a CAP ReleaseCall operation is received from the SCP. External Output: 1. Release towards A-Party (e.g., DTAP DISCONNECT) QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 58
2. Release towards the B-Party (e.g., ISUP REL) Action: Processing will be as in MT_GMSC (23.018 figure 35) sheets 6 and 7. Next state: Idle References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-680V1> <R-FSD19337.2-690V1.01> Process: MT_CF_MSC (23.018 figure 42) Initial State: Wait_For_Clear External Input: A-Party Release (via process MT_GMSC) External Output: 1. Release towards the B-Party (e.g., ISUP REL) either from this procedure or from called procedure CAMEL_OCH_MSC_DISC1. Action: Processing will be as in the following procedures: 3. MT_CF_MSC (23.018 figure 42) sheet 5. 4. CAMEL_OCH_MSC_DISC1 (03.78 figure 14). Next state: Idle Notes: 1. CAMEL_MT_GMSC_DISC1 is the same for CAMEL phases 1 and 2. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-690V1> <R-FSD19337.2-700V1.01> Process: MT_GMSC (23.018 figure 42) Initial State: Wait_For_Clear External Input: B-Party Release (e.g., ISUP REL) External Output: 1. Release towards the A-Party (via process MT_GMSC) either from this procedure or from called procedure CAMEL_OCH_MSC_DISC2, except when a reconnect is to take place. Action: Processing will be as in the following procedures: 3. MT_CF_MSC (23.018 figure 35) sheet 5. 4. CAMEL_OCH_MSC_DISC2 (03.78 figure 15). Next state: Idle Notes: 1. CAMEL_MT_GMSC_DISC2 is the same for CAMEL phases 1 and 2. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 59
Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-700V1>
8.3.5 Connecting to Assisting SSPs and IPs

The main announcement and digit collection requirements are covered in the section entitled "Announcement Session Operations and Results". The CCF has a part to play in establishing connections to assisting SSPs and external IPs. From call control's perspective, it makes no difference whether it is connecting to an assisting SSP or to an external IP -- the signaling is identical in either case. This section contains the requirements for connecting to external announcement facilities from the call control perspective. <R-FSD19337.2-720V1.01> The MSC will be required to support an ISUP connection to external IPs and/or assisting SSPs. Notes: 1. A connection to an external IP or assisting SSP is created following the receipt of the CAP EstablishTemporaryConnection operation. 2. The mapping of EstablishTemporaryConnection parameters to ISUP parameters is covered in requirement 4300. OPEN ISSUE: Support of ISDN to an IP. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-720V1> <R-FSD19337.2-725V1.01> For ISUP, the Correlation ID and SCF ID will be appended to the called party number field of the outgoing IAM message. Notes: The formats of the Correlation ID and SCF ID are specified in the CAP requirement for the EstablishTemporaryConnection operation. References: 03.78; 09.02 Feature ID: 50.100 Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-725V1>
8.3.6 Interworking with other Intelligent Network features
8.3.6.1 Trigger Detection Points

The CAMEL standards specify two trigger detection points: 1. DP2 -- CollectedInfo -- for originations. This DP is triggered at the point digits are collected, before digit analysis, and is armed via subscriber data sent from the HLR to the VLR.
Page:
Issue: 4 60
2. DP12 -- TerminationAttemptAuthorized -- for terminations. This DP is triggered when a termination arrives at a Gateway MSC for a terminating mobile subscriber. It is armed via parameters sent by the HLR in response to a routing request from the GMSC. The ETSI CS-1 standards specify other trigger detection points for both originations and terminations, two of which are relevant for mobile subscribers: 1. DP3 -- AnalyzedInfo -- for originations. This DP is triggered after digit analysis and before routing, and is often used for services that are accessed via a special number, e.g., 800 services. 2. DP4 -- RouteSelectFailure -- for both originations and terminations. This DP is triggered when a call cannot be routed for reasons other than busy, no answer or mobile station not reachable. DP4 is widely used for number portability services. DP2 is always provisioned on a subscriber basis for CAMEL. DPs 3 and 4 are often provisioned on a switch basis, e.g., any subscriber (CAMEL and non-CAMEL) can access an 800 service.
8.3.6.2 Multiple control relationships

Although the IN standards state that only one control relationship may exist at a time for a call, the standards only properly control what happens between and SSP and an SCP, not what happens within the SSP. As long as the SSP handles the TDPs with separate transactions, there will be no interaction problems with the SCP. DP2 services accessing DP3 or DP4 services can be done using looparound trunks, and logically, this is what is being covered by this requirement, only without looparounds. Thus, for example, from a logical view, we can model a DP2 service accessing a DP3 or DP4 service as an internal ISUP connection. How this internal "connection" is realized is internal to the SSP and invisible to the standards. In reality, the requirement to have separate IN interactions at different DPs requires only separate transactions and separate call records for the different trigger detection points. <R-FSD19337.2-730V1.01> It is required that mobile subscribers who are CAMEL subscribers be able to access dialed digit based IN services, such as Freephone and Number Portability. Such access is required even while a relationship with an SCP exists for an existing CAMEL based service. Notes: 1. This requirement may require two control relationships to be active for a single subscriber for the same call -- one for CAMEL and one for IN. 2. In CAMEL phase 3, dialed digit services (DP3) are supported within the context of a collected digits SCP interaction (DP2). References: 03.78; 22.078 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-730V1>
8.3.7 Interworking with Supplementary Services

Interactions between CAMEL supplementary services will be as specified in ETSI 22.078 section 18 and 03.78 section 10. Notes: 1. The interactions are summarized in this section. 2. The following services are not supported in u01.03: COLP, CUG, AOC, ECT, CCBS and Call Deflection. References: 03.78; 22.078 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711) and added note to reflect unsupported services in u01.03 (mr=17718). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-740V1>
8.3.7.1 Calling Line Identification Presentation (CLIP)

The CSE shall be able to add additional calling party number information, at both the originating and the terminating side of a mobile call. The additional information is provided in the genericNumbers parameter as part of the Connect procedure.
8.3.7.2 Calling Line Identification Restriction (CLIR)

CAMEL will have no effect on CLIR, and vice versa. The restriction indicator will not be changed by the SCP. If an access code prefix is used to access CLIR for a call, these digits will be sent to the gsmSCF. Since the CSE should have no effect on CLIR invocation, it will need to be able to ignore these digits in the case where the destination number is not changed (Continue or Connect with unmodified number), or it must prepend the access code to any modified destination number that it sends back. For follow-on-calls the CLIP/CLIR options shall be same as the original call. This is also true for dual numbering features.
8.3.7.3 Connected Line Identity Presentation (COLP)

CAMEL will have no effect on this service, and vice versa. The SCP will not be able to change the connected line identity. COLP does not work for follow-on calls.
8.3.7.4 Call Forwarding

All flavors of call forwarding -- Call Forward Unconditional (CFU), Call Forwarding on Mobile Not Reachable (CFNRc), Call Forwarding on Busy (CFB) and Call Forwarding on No Reply (CFNRy) will be invoked after any terminating CAMEL based service. Any forwarded call resulting from a GSM Call Forwarded supplementary service may cause invocation of mobile originated CAMEL based services. For the registration of call forwarding the network shall accept an FTN in a non international E.164 format and store it unchanged for a subscriber provided with MO CAMEL service and who has the TIF-CSI flag set in his subscriber data. This FTN shall be used by the network for the processing of call forwarding service. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 62
8.3.7.5 Call Hold

There is no interaction between CAMEL and Call Hold. For terminating calls, the Call Hold service is invoked after the CAMEL feature is invoked. A new call created after the invocation of the Call Hold service will be treated as a normal call setup and may be subject to CAMEL in the same way as a normal mobile originated call. For a call on hold, the following procedures will not be supported: 1. Announcement resource set up (SCP sends ConnectToResource or EstablishTemporaryConnection) 2. Announcements and/or digit collection request (SCP sends PlayAnnouncement or PromptAndCollectUserInformation). 3. Follow-on calls
8.3.7.6 Call Waiting

There is no interaction between CAMEL and Call Waiting. Incoming, waiting calls are treated by the gsmSCF as any other mobile terminating calls which encounter an idle subscriber.
8.3.7.7 Multi Party

There is no interaction between CAMEL and multi-party. A multi party call may include one or more calls subject to CAMEL interactions. Supplementary Services notifications are covered in a separate section. ??? For a multi-party call, the following procedures will not be supported: 1. Announcement resource set up (SCP sends ConnectToResource or EstablishTemporaryConnection) 2. Announcements and/or digit collection request (SCP sends PlayAnnouncement or PromptAndCollectUserInformation). 3. Follow-on calls
A CAP "Task Refused" error will be returned if these operations are invoked for a held call. These operations shall be blocked to a multi-part call when it is split. Once the multi-party is dropped and the call becomes a regular call then these operations should be allowed.
8.3.7.8 Closed User Group (CUG)

CUG will be invoked before any originating or terminating CAMEL based service. When a terminating call with CUG information is received for a CAMEL marked subscriber, if the terminating CAMEL based service attempts to modify the called party number: 1. If the called party is subscribed to CUG, the interrogating PLMN (IPLMN) will release the call towards the calling party with cause = "Incoming calls barred within CUG" (55). 2. If the called party is not subscribed to CUG, the IPLMN will continue the establishment of the call towards the modified called party number. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 63
Page:
For example, access restrictions for a CUG subscriber will take precedence over gsmSCF based VPN access restrictions.
8.3.7.9 Mobile Number Portability (MNP)

CAMEL will take precedence over Mobile Number Portability (MNP). A termination to a subscriber with CAMEL information in the HLR record will be treated as a CAMEL termination no matter what the MNP status of the subscriber in the HLR record. If T-CSI suppression is set in the SendRoutingInfo invoke (second interrogation), then any MNP data will be used. Some mobile operators may wish to implement MNP using CAMEL, in which case they could maintain CAMEL data for ported subscribers in the HLR, and the gsmSCF will return the address of the GMSC in the new network as a destination routing number.
8.3.7.10
Advice of Charge (AoC)
The gsmSCF will be able to send the Advice of Charge data (e-values) to the originating MSC. The MSC shall use the e-values received from the SCF, for the purpose of AoC. The gsmSCF evalues shall take precedence over any e-values generated by standard GSM Advice of Charge.
8.3.7.11 8.3.7.12
Call Barring Interactions with Lucent proprietary features
8.3.7.12.1 Call Forwarding announcements

The Lucent SoftSwitch MSC will support playing announcements for forwarded calls to the calling party (A-party). <R-FSD19337.2-750V1.01> When GSM (standard supplementary services) call forwarding is invoked after a CAMEL interaction, then if a call forwarding announcement is applicable for a subscriber it will be played. If CAMEL call forwarding is invoked, then a call forwarding announcement will not be played. Notes: 1. The normal situation for playing a call forwarding announcement after a CAMEL interaction will be when a T-CSI returned from an HLR to a GMSC causes an SCP query after which the SCP sends back a Continue operation. This will cause a second routing query to be sent to the HLR, and if call forwarding is active for the terminating subscriber, a forwarding number will be returned by the HLR to the GMSC, as per standard GSM call forwarding. 2. CAMEL call forwarding results from a particular combination of parameters sent from both the HLR and the SCP. Standard GSM call forwarding is not involved. References: 03.78; 22.078 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 64
<End of R-FSD19337.2-750V1>
8.3.8 MAP and CCF Interworking
8.3.8.1 Receipt of ProvideSubscriberInfo operation

<R-FSD19337.2-800V1.01> The CCF shall handle a received MAP ProvideSubscriberInfo operation as specified in 29.002 section 8.11.2 and 23.018 sections 8.3.4, 8.3.5 and 8.3.6. Notes: The location information that is required is the SAI. When active location retrieval is requested, the UE must be paged in order to obtain the SAI. References: 29.002 section 8.11.2 and 23.018 sections 8.3.4, 8.3.6 and 8.3.6 Feature ID: 50.100 Modification Reason: Added new in version 1.01 (mr=17729). Owner: Mpicha Keyword: CCF <End of R-FSD19337.2-750V1>
8.3.8.2 R-FSD19337.2-V1>R-FSD19337.2-V1>Receipt of Suppression of Announcement parameter

R-FSD19337.2-V1>R-FSD19337.2-V1>
8.4
Service Switching Function (SSF or gsmSSF)
The gsmSSF process receives internal inputs from call control (the CCF) for originating, terminating and call forwarded calls. It is the responsibility of the gsmSSF to act as the interface between the CCF and the external SCP (i.e., the gsmSCF). The gsmSSF has a direct interface to the SCP and an indirect interface to subscribers via the CCF.
8.4.1 InitialDP Sent to the SCP

<R-FSD19337.2-1000V1.01> Initial State: Idle Internal Input: Int_Invoke_gsmSSF Conditions: Internal Output: Int_gsmSSF_Invoked Actions: Processing will be as per 03.78 figure 45 sheet 1. 1. Arm the DP depending on whether an O-CSI (DP 2) or a T-CSI (DP 12) is indicated. 2. If any other internal input is received from CCF, send an Int_Continue back to CCF and remain in Idle state. Next state: Wait_For_Request Notes: 1. The call type is indicated to the gsmSSF process via the DP number (2 for originations or 12 for terminations) and for call forwarding, by the presence of forwarding information. 2. The mechanism for indicating call forwarding is internal and is a design issue. References: GSM 03.78; 09.78 QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 65
Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1000V1> <R-FSD19337.2-1005V1.01> Initial State: Wait_For_Request Internal Input: 1. Int_DP_Collected_Info or 2. Int_DP_Termating_Attempt_Authorized Actions: Processing will be as in 03.78 figure 45 sheet 2. 1. Call procedure Check_Criteria for Int_DP_Collected_Info 2. After the InitialDP is sent, start a Tssf timer. 3. Open a control relationship. 4. Set the following: # ACR sent = false # AC pending = false # Outstanding requests = 1 # Outstanding Call Information Requests = 0 5. If Int_T_Exception, Int_O_Exception, Int_DP_T_Abandon or Int_DP_O_Abandon are received, transition to Idle state. External Output: Send a CAP InitialDP operation to the gsmSCF containing all of the mandatory and conditional parameters that are available, as indicated in ETSI GSM 03.78 section 9.1.5, for the indicated call type: mobile origination, mobile termination or call forwarding. Next state: Waiting for Instructions Notes: 3. This requirement covers two gsmSSF states from 03.78 -- "Idle" and the intermediate state "Wait_For_Request" -- as all the information necessary can be transmitted with one internal message and requires only one gsmSSF state. 4. The call type is indicated to the gsmSSF process via the DP number (2 for originations or 12 for terminations) and for call forwarding, by the presence of forwarding information. 5. The mechanism for indicating call forwarding is internal and is a design issue. References: GSM 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1005V1>
8.4.2 Receiving SCP Call Handling Instructions

After the SSP sends an Initial DP operation to the SCP, it waits for instructions from the SCP. The SCP can send one or more operations that instruct the SSP to perform various functions. Two operations sent from the SCP to the SSP -- Continue and Connect -- cause the SSP to continue with call processing. This section covers the requirements on the SSP for handling SCP operations. There are several gsmSSF call states. In some cases in 03.78, more than one state is covered in the same SDL for ease of specification, and these requirements often follow the 03.78 convention. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 66
8.4.2.1 Receipt of CAP Continue operation

The SCP has the option of instructing the SSP to continue call processing as it normally would have before being interrupted due to the SCP interaction. The SCP does this via a CAP Continue operation. <R-FSD19337.2-1010V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions External Input: CAP Continue Internal Output: Int_Continue Action: processing will be as in 03.78 figure 45 sheet 3. The following procedures may be called: 1. The following 03.78 procedures may be called: # Complete_FCI_Record (figure 51) # Handle_CIR (figure 49) # Complete_all_FCI_records (figure 52) 2. The Tssf timer is stopped. Next state: 1. If there are no outstanding requests or reports, the next state is "Idle". 2. If there are outstanding request type event detection points (EDP-R), the next state is "Waiting_For_Instructions". 3. If there are any outstanding notification type event detection points or any pending reports, the next state is "Monitoring". Notes: 1. If no outstanding request type event detection points are armed, the control relationship is terminated. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1010V1>
8.4.2.2 Receipt of Connect operation

<R-FSD19337.2-1020V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions External Input: CAP Connect Internal Output: Int_Connect Action: processing will be as in 03.78 figure 45 sheet 3. 1. The following 03.78 procedures may be called: # Complete_FCI_Record (figure 51) # Handle_CIR (figure 49) # Complete_all_FCI_records (figure 52) 2. The Tssf timer is stopped. Next state: 1. If there are no outstanding requests or reports, the next state is "Idle". QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 67
Page:
2. If there are outstanding request type event detection points (EDP-R), the next state is "Waiting_For_Instructions". 3. If there are any outstanding notification type event detection points or any pending reports, the next state is "Monitoring". Notes: 1. If no outstanding request type event detection points are armed, the control relationship is terminated. 2. The gsmSSF communicates to the CCF all of the modified calling instructions via the Int_Connect message. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1020V1>
8.4.2.3 Receipt of ResetTimer operation

<R-FSD19337.2-1040V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions, Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction External Input: CAP ResetTimer Action: processing will be as in 03.78 figure 45 sheet 4, 13 and 16. 1. The Tssf timer is set to the value contained in the ResetTimer operation. Next state: Same as initial state References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1040V1>
8.4.2.4 Expiration of SSF guard timer (Tssf)

<R-FSD19337.2-1050V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions Internal Input: Expiration of Tssf timer External Output: TCAP Abort towards SCP Internal Output: Int_Error to CCF Action: processing will be as in 03.78 figure 45 sheet 4. Next state: Idle Notes: 1. The Int_Error will cause the CCF to release the call towards the A-party. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 68
2. Procedure Complete_all_FCI_records is called. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1050V1>
8.4.3 Event Detection Points
8.4.3.1 Receipt of RequestReportBCSMEvent

<R-FSD19337.2-1060V1.01> Initial State: Waiting for Instructions Input: CAP RequestReportBCSMEvent operation Conditions: all valid event types Action: Processing will be as for 03.78 figure 45 sheet 5. 1. For each requested event type, arm the event detection point (EDP) and store the detection point type -- request or notification. 2. Restart the Tssf timer with the last used value for Tssf. 3. If the event type is "O-NoAnswer" or "T-NoAnswer", an optional timer value may also be included. The value of this timer must be greater than or equal to 10 seconds and less than or equal to 40 seconds, and in any case, the value must be less than the value of the network no answer timer (i.e., for ISUP). If any of the conditions just mentioned are not true for the timer value, then an error of "UnexpectedDataValue" will be returned to the gsmSCF. 4. If not included, the following defaults are assumed for LegID: # "legID" = 1 for the events O-Abandon and T-Abandon # "legID" = 2 for the events RouteSelectFailure, O-Busy, O-NoAnswer, O-Answer, TBusy, T-NoAnswer, and T-Answer. # The "legID" parameter shall always be included for the events O-Disconnect and TDisconnect. If it is not included, an error of "Missing Parameter " will be returned to the gsmSCF. Next state: Waiting for Instructions Notes: 1. Valid EDPs are 4, 5, 6, 7, 9, 10, 13, 14, 15, 17 and 18. 2. The network reanswer timer is determined under trunk signaling requirements. 3. The arming rules are specified in a separate requirement. References: GSM 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1060V1>
Page:
Issue: 4 69
8.4.3.2 Receipt of Cancel operation for pending EDPs and reports

<R-FSD19337.2-1065V1.01> Initial State: Waiting_For_Instructions External Input: CAP Cancel Action: Processing will be as in 03.78 figure 45 sheet 6. 1. All pending Event Detection Points are disarmed and all pending reports are canceled. 2. The Tssf is reset to the last used value and restarted. Next state: Waiting_For_Instructions Notes: the CAP Cancel operation is also used in the context of an announcement or digit collection session to cancel the session. This is covered separately. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1065V1>
8.4.4 Call Termination
8.4.4.1 Receipt of ReleaseCall operation

<R-FSD19337.2-1070V1.01> Initial State: Waiting_For_Instructions, Monitoring External Input: CAP ReleaseCall operation External Output: CAP ApplyChargingReport operation (if pending) Internal Output: Int_Release_Call to CCF. Conditions: there must be a control relationship with the gsmSCF for this operation to be valid. Action: Processing will be as in 03.78 figure 45 sheets 5 and 21. 1. The following procedures are called: # Handle_CIR # Complete_all_FCI_records 2. If the initial state is Waiting_For_Instructions then stop the Tssf timer. 3. The control relationship is terminated. 4. If there is not a control relationship, then the gsmSSF will ignore the operation. Next state: If the operation is valid, then the next state is Idle. If not, the state remains the same. Notes: 1. The ReleaseCall operation is class 4, and thus no error is returned if it is received in a noncontrol relationship. References: ETSI GSM 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 70
Page:
Owner: A. McClurg Keyword: gsmSSF <End of R-FSD19337.2-1070V1>
8.4.4.2 Call termination due to internal error

<R-FSD19337.2-1080V1.01> Initial State: Waiting_For_Instructions, Monitoring Internal Input: Int_O_Exception, Int_T_Exception External Output: 1. TCAP Abort to gsmSCF 2. CAP ApplyChargingReport operation (if pending) 3. CAP CallInformationReport (if pending) Action: Processing will be as in 03.78 figure 45 sheets 5 and 21. 1. The following procedures are called: # Handle_CIR # Complete_all_FCI_records 2. The control relationship is terminated. Next state: Idle Notes: Exception events can be generated by the CCF for any kind of internal error (e.g., database read failure). References: ETSI GSM 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: A. McClurg Feature ID: 50.100 Keyword: gsmSSF <End of R-FSD19337.2-1080V1>
8.4.4.3 Disconnect from A or B party

<R-FSD19337.2-1140V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions, Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction, Await_Temporary_Connection_Establishment Internal Input: Int_DP_T_Disconnect or Int_DP_O_Disconnect Action: Processing will be as for 03.78 figure 45 sheet 9. 1. If a disconnect EDP is armed for the leg ID indicated in the input message from the CCF: # If it is an EDP-N, then: Send a CAP EventReportBCSM to the gsmSCF indicating "notify and continue" before calling the below procedures. Reload and restart the Tssf timer to the non-user interaction default (see section entitled "Timers and Timer Handling") # If it is an EDP-R, then: send a CAP EventReportBCSM to the gsmSCF indicating "interrupted" after calling the below procedures. Issue: 4 QDI ID: 19337 Author: Marianne Picha Lucent Technologies - Proprietary Date: November 18, 2002 Page: 71
Set Tssf timer to default non-user interaction timer and restart it (see section on "Timers and Timer Handling"). Increment the Outstanding_Requests counter. 2. Perform implicit disarming of DPs. 3. Call procedure Handle_ACR with "call active" equal to "False". 4. Call procedure "Handle_CIR". Next state: Waiting_For_Instructions Notes: 1. Implicit disarming rules are covered in 03.78 section 7.4. 2. The CCF will indicate in the internal disconnect message the leg ID of the disconnecting party. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1140V1>
8.4.4.4 Caller Abandon

<R-FSD19337.2-1150V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions, Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction, Await_Temporary_Connection_Establishment Internal Input: Int_DP_T_Abandon or Int_DP_O_Abandon Internal Output: Int_Continue to the CCF Action: 1. If an O-Abandon or T-Abandon Event Detection Point is armed, then send a CAP EventReportBCSM operation to the gsmSCF indicating "notify and continue". 2. Perform implicit disarming of DPs. 3. Call procedure Handle_ACR with "call active" equal to "False". 4. Call procedure "Handle_CIR". 5. Stop the Tssf timer. 6. Terminate the control relationship. Next state: Waiting_For_Instructions Notes: 1. Implicit disarming rules are covered in 03.78 section 7.4. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1150V1>
Page:
Issue: 4 72
8.4.5 Announcement Session Operations and Results

8.4.5.1 Announcement Configurations
The CAMEL standards allow the same configurations of SCPs, SSPs and SRFs (or gsmSCF, gsmSSF and gsmSRF) as do the CS-1 INAP standards, although they are presented differently. 09.78 section 4.2 shows 4 scenarios: 1. Scenario 1 involves a direct connect between the gsmSCF and the gsmSRF 2. Scenario 2 has two variations: a) Scenario 2a involves an assisting SSP, with the gsmSRF being internal to the assisting gsmSSF. b) Scenario 2b also involves an assisting SSP, but the gsmSRF (IP) is separate from the gsmSSF. 3. Scenario 3 has the gsmSRF internal to the gsmSSF (i.e., the initiating gsmSSF). 4. Scenario 4 is similar to scenario 3, except that the gsmSRF (IP) is separate. There is no requirement currently to support scenarios 2b from the perspective of the assisting gsmSSF and scenario 4 from the perspective of the initiating gsmSSF -- i.e., the cases where the gsmSSF relays CAP operations via an ISUP or ISDN interface to an external IP. <R-FSD19337.2-1205V1.01> Support of the following gsmSRF configurations from 09.78 section 4.2 is required: 1. Direct gsmSCF to gsmSRF messaging (scenario 1). 2. Assisting gsmSSF with co-located gsmSRF (scenario 2a). 3. gsmSSF with co-located gsmSRF (scenario 3). Notes: 1. The "relay to non co-located gsmSRF" cases are not covered, i.e., scenarios 2b and 4. 2. The scenarios not supported require the gsmSSF to forward CAP messages via trunk signaling, e.g., by overloading existing ISUP parameters. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1205V1>
8.4.5.2 Contacting an assisting gsmSSF

When a gsmSSF on the MSC where call control (CCF) also resides needs to request announcement resources from an external IP or assisting gsmSSF, it does so via an ISUP or ISDN connection. For simplicity, this section will assume ISUP, although the same principles also apply for ISDN with different message names. There are three pieces of information that must be conveyed from the gsmSSF to the assisting gsmSSF or IP. 1. The fact that the call is a request for an assist, as opposed to any other trunk origination. This is accomplished by using a special called party number that maps in digit analysis to a unique value on the assisting SSP or IP. 2. A correlation ID. This is sent from the gsmSCF to the gsmSSF in an EstablishTemporaryConnection operation and is used by the gsmSCF to correlate the request from the assisting gsmSSF or IP for announcement instructions. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 73
Page:
3. An SCF ID. The SCF ID is either a gsmSCF address or can be mapped to a gsmSCF address by the assisting SSP or IP. The gsmSCF address is used to route the request for announcement instructions to the correct gsmSCF. The CAMEL standards do not specify how the Correlation ID and SCF ID are transmitted from a gsmSSF to an assisting gsmSSF or IP. ISUP 97 has separate parameters for Correlation ID and SCF ID in the ISUP IAM, but earlier versions do not. Earlier versions have to rely on putting these parameters in existing fields, e.g., appending them to the called party number field. As most networks are running ISUP 88 or ISUP 92, this method will have to be followed. The requirements are contained in this section and in the section entitled "Assisting MSC".
8.4.5.3 Triggering on an assisting gsmSSF

Because the initial input to an assisting gsmSSF is an initial address signaling (e.g., in an ISUP IAM), the only way to determine if the call is an assist is through digit analysis. This means that essentially a dialed digit trigger is used, i.e., DP3 or AnalyzedInfo. Thus, although the CAMEL standards do not mention DP3 as part of subscriber based services, some variant of DP3 must be introduced to support assists. In addition, a CAMEL based assist must be distinguishable from a CS-1 INAP based assist. <R-FSD19337.2-1210V1.01> An assisting gsmSSF must be able to determine from digit analysis on an incoming network initial address message (e.g., ISUP IAM) one of the following: 1. If the message is a request for a CAMEL assist. 2. If the message is a request for a CS-1 INAP assist. Notes: 3. The most straightforward way to accomplish this is to have separate digit strings for the two types, and to have separate digit analysis results for those digit strings. 4. The digit strings will be contained in the called party address field of the incoming signaling message. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1210V1>
8.4.5.4 The gsmSSF state machine and the gsmSRF

Because of some of the scenarios mentioned above, the gsmSSF state machine (i.e., 03.78 process gsmSSF) is shown as transmitting some received CAP operations directly to a gsmSRF and receiving indications back from the gsmSRF directly. In reality, the gsmSSF will have no direct connection with any gsmSRF, and all communication between the gsmSSF and a gsmSRF, whether internal to the MSC or external, will be via the CCF. Thus, when SDLs for process gsmSSF show messages being sent to and received from a gsmSRF, it may be assumed for design purposes that the messages will be sent via the CCF. However, there will be no externally observable impact, and so this requirements document will not attempt to create new internal gsmSSF to CCF messages to illustrate the internal path these messages will take.
Page:
Issue: 4 74
8.4.5.5 Receipt of EstablishTemporaryConnection operation

<R-FSD19337.2-1200V1.01> Initial State: Waiting_For_Instructions External Input: CAP EstablishTemporaryConnection Internal Output: Int_Establish_Temporary_Connect to CCF. Action: Processing will be as in 03.78 figure 45 sheet 6. 1. The Tssf timer is stopped. Next state: Await_Temporary_Connection_Establishment References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1200V1> R-FSD19337.2-V1>R-FSD19337.2-V1>
8.4.5.6 Receipt of DisconnectForwardConnection

<R-FSD19337.2-1215V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction External Input: CAP DisconnectForwardConnection Internal Output: Int_Disconnect_Forward_Connection to CCF Action: Processing will be as in 03.78 figure 45 sheets 13 and 17. 1. Call Handle_ACR to process any pending ApplyChargingReports 2. Set the Tssf timer to the last used interval and restart it. Next state: 1. If initial state is Waiting_For_End_Of_Temporary_Connection, then the next state is Waiting_For_Instructions. 2. If the initial state is Waiting_For_End_Of_User_Interaction, then the state remains the same. Notes: 1. The DisconnectForwardConnection operation will cause the CCF to tear down the voice path to the SRF. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1215V1>
Page:
Issue: 4 75
8.4.5.7 Receipt of ConnectToResource

<R-FSD19337.2-1220V1.01> Initial State: Waiting_For_Instructions External Input: CAP ConnectToResource Internal Output: Int_Connect_To_Resource to CCF. Action: Processing will be as in 03.78 figure 45 sheet 7. 1. The Tssf timer is stopped. Next state: Await_Resource_Connection References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1220V1>
8.4.5.8 Receipt of PlayAnnouncement

<R-FSD19337.2-1230V1.03> Initial State: Waiting_For_End_Of_User_Interaction External input: CAP PlayAnnouncement operation Internal output: CAP PlayAnnouncement relayed to CCF in some internal format. Action: Processing will be as in 03.78 figure 45 sheet 16. 1. Reset the Tssf timer to the last value used and restart it. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The various gsmSRF configurations are shown in 09.78 section 4.2 "Physical Scenarios". The scenario covered by this requirement is 3. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). In version 1.03 clarified note regarding supported scenarios (mr=19628). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1230V1>
8.4.5.9 Receipt of PromptAndCollectUserInformation

<R-FSD19337.2-1240V1.03> Initial State: Waiting_For_End_Of_User_Interaction External input: CAP PromptAndCollectUserInformation operation Internal output: CAP PromptAndCollectUserInformation operation relayed to CCF in some internal format. Action: Processing will be as in 03.78 figure 45 sheet 16. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 76
Page:
1. Reset the Tssf timer to the last value used and restart it. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The various gsmSRF configurations are shown in 09.78 section 4.2 "Physical Scenarios". The scenario covered by this requirement is 3. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). In version 1.03 clarified note regarding supported scenarios (mr=19628). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1240V1> <R-FSD19337.2-1242V1.01> Announcement session related operations for an internal gsmSRF -- ConnectToResource, EstablishTemporaryConnection, PlayAnnouncement and PromptAndCollectUserInformation -- will be not be supported in the following circumstances: 1. When the leg for which the announcement operation applies is on hold 2. When the leg for which the announcement operation applies has a data connection If one of these operations is received for the above cases, a CAP "Task Refused" error will be returned to the gsmSCF. Notes: References: SE Judgement Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1242V1> <R-FSD19337.2-1244V1.01> After an announcement session is initiated to either an internal or external gsmSRF, the following messages must be sent back to the A-party: 1. PROGRESS and CONNECT if the connection to the A-party is via BSSAP. 2. Network Setup and Answer (e.g., ISUP ACM and ANM) if the connection to the A-party is via trunk signaling. Notes: References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1244V1>
8.4.5.10

Receipt of Cancel operation for announcement sessions

Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 77
<R-FSD19337.2-1250V1.01>
Page:
Initial State: Waiting_For_End_Of_User_Interaction External input: CAP Cancel operation containing the "invoke ID" parameter. Internal output: CAP Cancel relayed to CCF in some internal format. Action: Processing will be as in 03.78 figure 45 sheet 16. 1. Reset the Tssf timer to the last value used and restart it. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The various gsmSRF configurations are shown in 09.78 section 4.2 "Physical Scenarios". References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1250V1>
8.4.5.11
Sending CAP Canceled error
<R-FSD19337.2-1260V1.01> Initial State: Waiting_For_End_Of_User_Interaction Internal input: Previous operation "Canceled" error indicated from SRF. External output: CAP Cancel error sent to gsmSCF. Action: Processing will be as in 03.78 figure 45 sheet 18. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. This is one instance where an error indicates the successful execution of an operation -- i.e., a CAP Cancel operation. If the previously requested operation (PlayAnnouncement or PromptAndCollectUserInformation) was successfully canceled, then this error is returned to the gsmSCF in a Return Error. See the definition of the Cancel operation in 09.78. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1260V1>
8.4.5.12
Sending CAP Cancel Failed error
<R-FSD19337.2-1270V1.01> Initial State: Waiting_For_End_Of_User_Interaction Internal input: "Cancel failed" error indicated from CCF. External output: CAP Cancel Failed error sent to gsmSCF. Action: Processing will be as in 03.78 figure 45 sheet 18. Next state: Waiting_For_End_Of_User_Interaction Notes: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 78
Page:
1. This is the case where a Cancel operation was not successfully carried out, e.g., because the announcement was already successfully played. See the definition of the Cancel operation in 09.78. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1270V1>
8.4.5.13
Sending PromptAndCollectUserInformation result
<R-FSD19337.2-1280V1.01> Initial State: Waiting_For_End_Of_User_Interaction Internal input: Collected digits from user interaction from CCF. External output: CAP PromptAndCollectUserInformation Return Result. Action: Processing will be as in 03.78 figure 45 sheet 18. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. After a caller has entered digits in response to some prompt, the digits are sent back to the gsmSCF. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1280V1>
8.4.5.14
Sending SpecializedResourceReport
<R-FSD19337.2-1285V1.01> Initial State: Waiting_For_End_Of_User_Interaction Internal input: Announcement complete indication from CCF. External output: If the previously received PlayAnnouncement indicated that a response is required, then a CAP SpecializedResourceReport operation is sent to the gsmSCF. Action: Processing will be as in 03.78 figure 45 sheet 18. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The PlayAnnouncement parameter that controls whether a SpecializedResourceReport is sent is "requestAnnouncementComplete". See 09.78. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1285V1> QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 79
Page:
8.4.5.15
Expiration of Tssf timer during announcement session
<R-FSD19337.2-1290V1.01> Initial State: Waiting_For_End_Of_User_Interaction Internal Input: Expiration of Tssf timer External Output: TCAP Abort towards SCP Internal Output: Int_Disconnect_Forward_Connection to CCF Action: processing will be as in 03.78 figure 45 sheet 18. Next state: SRF_Release_Pending Notes:
References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1290V1> <R-FSD19337.2-1295V1.01> Process: gsmSSF Initial State: SRF_Release_Pending Internal Input: Int_SRF_Released External Output: Int_Error Action: Processing will be as in 03.78 figure 45 sheet 18 1. Procedure Complete_all_FCI_records is called. Notes: References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1295V1>
8.4.6 Announcement and digit collection: intermediate states

The following section deals with the intermediate gsmSSF states involved with playing announcements and collecting digits.
8.4.6.1 Connection establishment to IP or Assisting SSP

<R-FSD19337.2-1300V1.01> Process: gsmSSF Initial State: Await_Temporary_Connection_Establishment Internal Input: Int_Temporary_Connection_Established or Int_ETC_Failed Internal Output: In failure case, an "ETC failed" error is sent to the gsmSCF. External output: e-parameters to the mobile in some cases. Action: Processing will be as in 03.78 figure 45 sheet 6. 1. If the connection to the IP or Assisting SSP is successful: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 80
# If an ApplyCharging is pending, the call period timer (Tcp) is started. # If the warning timer interval is greater than 0, then the warning timer (Tw) is started. # If any e-parameters are stored, they are sent to the mobile. # Set the Tssf timer to the user interaction timer and restart it. 2. If the connection is unsuccessful: # An EstablishTemporaryConnect error is sent to the SCP with error cause of "ETC failed". # Set the Tssf timer to the last used interval and restart it. Next state: 1. If the connection to the IP or Assisting SSP is successful, then the next state is Waiting_For_End_Of_Temporary_Connection 2. If unsuccessful, then the next state is Waiting_For_Instructions Notes: 1. The Int_Temporary_Connection_Established message is sent by the CCF after it receives an Answer message (e.g., ISUP ANM) from the IP or Assisting SSP. 2. The SCP can send an ApplyCharging to control and monitor the length of the connection to the IP. This is what the Tcp controls. 3. It is possible for Tcp to be less than or equal to 30 seconds, in which case no warning tone is played, and the warning timer (Tw) does not need to be started. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1300V1>
8.4.6.2 Connection establishment from internal SRF

<R-FSD19337.2-1305V1.01> Process: gsmSSF Initial State: Await_Resource_Connection Internal Input: Int_SRF_Connected or Int_CTR_Failed Internal Output: In failure case, a "System Failure" error is sent to the gsmSCF. External Output: e-parameters to the mobile in some cases. Action: Processing will be as in 03.78 figure 45 sheet 8. 1. If the connection to the IP or Assisting SSP is successful: # If an ApplyCharging is pending, the call period timer (Tcp) is started. # If the warning timer interval is greater than 0, then the warning timer (Tw) is started. # If any e-parameters are stored, they are sent to the mobile. # Set the Tssf timer to the user interaction timer and restart it. 2. If the connection is unsuccessful: # An EstablishTemporaryConnect error is sent to the SCP with error cause of "ETC failed". # Set the Tssf timer to the last used interval and restart it. Next state: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 81
Page:
1. If the connection to the IP or Assisting SSP is successful, then the next state is Waiting_For_End_Of_Temporary_Connection 2. If unsuccessful, then the next state is Waiting_For_Instructions Notes: 1. The SCP can send an ApplyCharging to control and monitor the length of the connection to the IP. This is what the Tcp controls. 2. It is possible for Tcp to be less than or equal to 30 seconds, in which case no warning tone is played, and the warning timer (Tw) does not need to be started. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1305V1>
8.4.6.3 Connection release to internal SRF

<R-FSD19337.2-1310V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_User_Interaction Internal Input: Int_SRF_Released to SRF Action: Processing will be as in 03.78 figure 45 sheet 17. 1. Procedure Handle_ACR is called. 2. Set the Tssf timer to the last used interval and restart it. Next state: Waiting_For_Instructions References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1310V1>
8.4.6.4 Release of Temporary Connection from Call Control

<R-FSD19337.2-1315V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_Temporary_Connection Internal Input: Int_TC_Released Action: Processing will be as in 03.78 figure 45 sheet 13. 1. Call Handle_ACR to process any pending ApplyChargingReports. 2. Set the Tssf to the last used interval and restart it. Next state: Waiting_For_Instructions References: 03.78; 09.78 QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 82
Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1315V1>
8.4.6.5 Announcement session: miscellaneous

This section covers all remaining inputs for the "Waiting_For_End_Of_Temporary_Connection" and/or the "Waiting_For_End_Of_User_Interaction" states. <R-FSD19337.2-1320V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_Temporary_Connection Internal Input: Expiration of Tssf timer External Output: TCAP Abort towards SCP Internal Output: Int_Disconnect_Forward_Connection to CCF Action: processing will be as in 03.78 figure 45 sheet 13. Next state: TC_Release_Pending References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1320V1>
<R-FSD19337.2-1325V1.01> Process: gsmSSF Initial State: TC_Release_Pending Internal Input: Int_TC_Released External Output: Int_Error Action: Processing will be as in 03.78 figure 45 sheet 13 2. Procedure Complete_All_FCI_Records is called. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1325V1>
<R-FSD19337.2-1330V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction or Monitoring Internal Input: Warning Tone Timer (Tw) expired Internal Output: Int_Apply_Warning_Tone to CCF QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 83
Page:
Action: Processing will be as in 03.78 figure 45 sheets 14 and 15. Next state: the same as the initial state. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1330V1>
<R-FSD19337.2-1335V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction or Monitoring Internal Input: Tariff Switch Timer (Tsw) expired Internal Output: Send_e_Parameters to CCF Action: Processing will be as in 03.78 figure 45 sheets 14 and 15. 1. If e-parameters are stored then they are sent to the mobile station via the CCF 2. The current value of the call period timer (Tcp) is stored. Next state: the same as the initial state. Notes: 1. The next ApplyChargingReport will contain both the initial tariff switch interval and the time since the last tariff switch. The current value of the Tcp timer is stored so that the time since the tariff switch can be determined. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-1335V1> <R-FSD19337.2-1340V1.01> Process: gsmSSF Initial State: Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction Internal Input: Call Period Timer (Tcp) expired Internal Output: see "Action" section. External Output: see "Action" section. Action: Processing will be as in 03.78 figure 45 sheet 14. If the ApplyCharging report indicated release on Tcp timer expiration, then: # Send a CAP ApplyChargingReport to the gsmSCF. # Send an Int_Disconnect_Forward_Connection to the CCF. # Call procedure Handle_CIR. # Call procedure Complete_All_FCI_Records # Send an Int_Release to the CCF QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 84
Page:
If the ApplyCharging report indicates no release, then: # Procedure Handle_ACR is called. # The Tssf is set to the last used value and restarted. Next state: the same as the initial state. Notes: 1. Whether or not to release the call at the expiration of the Tcp timer is indicated in an ApplyCharging parameter received at the same time as the Tcp interval. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-1340V1>
8.4.7 Monitoring State

The monitoring state is entered once an SCP interaction has occurred and there is still some action pending, i.e., either an Event Detection Point has been armed or a report has been requested. The CAMEL standards allow more CAP operations to be received in the Monitoring state than do the ETSI CS-1 standards. The ApplyCharging, FurnishChargingInformation and SendChargingInfo may be received in the monitoring state. Requirements for the receipt of ApplyCharging and SendChargingInfo in the Monitoring state are covered in the "Billing and Information request operations" section below, as the requirements are the same as when these operations are received in the Waiting_For_Instructions state. In other cases also, the requirements for the Monitoring state have been combined with other states as the processing is identical. Requirements that are unique to the Monitoring state are covered in this section.
8.4.7.1 Receipt of RequestReportBCSMEvent

<R-FSD19337.2-1400V1.01> Initial State: Monitoring Input: CAP RequestReportBCSMEvent operation External Output: Error if EDP-R is requested. Conditions: Requests to arm EDP-Ns or to disarm EDPs are valid. Action: Processing will be as for 03.78 figure 45 sheet 10. 1. If an EDP-R is requested, then return an "Unexpected Data Value" error. 2. For each requested event type, arm the EDP-N and store the event type (i.e., Notification) or disarm the EDP, as indicated. Next state: Monitoring Notes: 4. Valid EDPs are 4, 5, 6, 7, 9, 10, 13, 14, 15, 17 and 18. 5. The network reanswer timer is determined under trunk signaling requirements. 6. The arming rules are specified in a separate requirement. References: GSM 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 85
Keyword: gsmSSF <End of R-FSD19337.2-1400V1>
8.4.7.2 Disconnect or Abandon

<R-FSD19337.2-1405V1.01> Process: gsmSSF Initial State: Monitoring Internal Input: Int_DP_T_Disconnect, Int_DP_O_Disconnect, Int_T_Abandon or Int_O_Abandon Internal Output: Int_Continue for non EDP-R cases. External Output: CAP EventReportBCSM operation to gsmSCF for EDP armed cases. Action: Processing will be as in 03.78 figure 45 sheet 11. 1. If no EDP is armed for the event and leg ID indicated in the input message from the CCF: Call procedure Handle_ACR Call procedure Handle_CIR Call procedure Compute_all_FCI_records 2. If an EDP-N is armed for the event and leg ID: Send a CAP EventReportBCSM to the gsmSCF indicating "notify and continue" Call procedure Handle_ACR Call procedure Handle_CIR Call procedure Compute_all_FCI_records 3. If an EDP-R is armed for the event and leg ID: Call procedure Handle_ACR Call procedure Handle_CIR_leg with the appropriate leg ID. Set Tssf timer to default non-user interaction timer and restart it (see section entitled "Timers and Timer Handling"). Increment the Outstanding_Requests counter. Send a CAP EventReportBCSM to the gsmSCF indicating "interrupted" 4. For all cases, perform implicit disarming of DPs. Next state: Waiting_For_Instructions (EDP-R case) or Idle for the other cases. Notes: 1. Implicit disarming rules are covered in 03.78 section 7.4. 2. The CCF will indicate in the internal disconnect message the leg ID of the disconnecting party. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1405V1>
8.4.7.3 Timer Expiration

Three internal timers can expire while in the monitoring state: the warning timer (Tw), the tariff switch timer (Tsw) and the call period timer (Tcp). The first two are covered for the Monitoring QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 86
Page:
state under previous requirements which combine more than one state. The expiration of the call period timer in Monitoring state has some unique handling and is covered here. <R-FSD19337.2-1410V1.01> Process: gsmSSF Initial State: Monitoring Internal Input: Call Period Timer (Tcp) expired Internal Output: see "Action" section. External Output: see "Action" section. Action: Processing will be as in 03.78 figure 45 sheet 15. 1. If the ApplyCharging report indicated release on Tcp timer expiration, then: # Send a CAP ApplyChargingReport to the gsmSCF. # Call procedure Handle_CIR. # Call procedure Complete_all_FCI_records # Send an Int_Release to the CCF # Go to the Idle state 2. If the ApplyCharging report indicates no release, then: # If there are any outstanding EDPs or requests: Call procedure Handle_ACR Remain in the Monitoring state # If no EDPs or requests: Send a CAP ApplyChargingReport to the gsmSCF Call procedure Complete_all_FCI_records Go to the Idle state Next state: Monitoring or Idle Notes: 1. Whether or not to release the call at the expiration of the Tcp timer is indicated in an ApplyCharging parameter received at the same time as the Tcp interval. References: 23.018; 03.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-1410V1>
8.4.7.3.1
Reconnect after expiration of call period timer -- future
A feature developed on the 5ESS for OneTel in Australia allows for different handling when a call period timer expires. Essentially, instead of tearing both legs of the call down, which is the CAMEL standard treatment, if there is an EDP armed as "request" type for B-party disconnect, the B-party leg is torn down but instead of tearing down the A-party leg, the EDP-9R is reported to the SCP. The SCP then has the option of reconnecting the A-party to a new destination, e.g., to a recharge operation. This functionality is not a required feature for R1V2 but is added here for information. The details are as follows.
Page:
Issue: 4 87
1. When the ApplyCharging timer expires (e.g., no time left on prepaid calling card), the gsmSSF process sends an internal message to the CCF. 2. After checking data for whether this functionality is active, and determining that EDP 9B-R is set, the CCF disconnects the B-party but not the A-party. The CCF then sends an internal message indicating that B-party disconnect has been encountered to the gsmSSF. 3. The gsmSSF sends an EventReportBCSM (9B-R) to the gsmSCF. The gsmSSF also sends an ApplyChargingReport as usual, with the CallResult parameter of the ApplyChargingReport operation containing a parameter which indicates how much time has been used. 4. Upon checking the ApplyChargingReport and the EventReportBCSM, the SCP service logic must send back further call handling instructions, e.g., a CAP Connect to the gsmSSF to connect the subscriber to an operator.
8.4.7.4 Receipt of CAP Cancel for pending EDPs and reports

<R-FSD19337.2-1415V1.01> Initial State: Monitoring External Input: CAP Cancel Internal output: Int_Continue Action: Processing will be as in 03.78 figure 45 sheet 19. 1. All pending Event Detection Points are disarmed and all pending reports are canceled. 2. The relationship with the gsmSCF is terminated. 3. Call procedure Complete_all_FCI_records. Next state: Idle Notes: the CAP Cancel operation is also used in the context of an announcement or digit collection session to cancel the session. This is covered separately. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1415V1>
8.4.7.5 Answer event detected

<R-FSD19337.2-1420V1.01> Initial State: Monitoring Internal input: Int_DP_T_Answer or Int_DP_O_Answer Internal output: Int_Continue if the corresponding answer EDP is not armed or if it is armed as a notification type. External output: 1. CAP EventReportBCSM if a corresponding EDP is armed. 2. e-parameters if they are stored Action: Processing will be as in 03.78 figure 45 sheet 19. 1. If an ApplyCharging is pending, then the Call Period Timer (Tcp) is started. 2. If the Warning Timer (Tw) time is greater than 0, then it is started. 3. If e-parameters are stored then they are sent to the mobile. 4. Perform implicit disarming of DPs. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 88
5. The rest of the processing is as indicated in figure 45 sheet 19, and depends on whether the corresponding EDP is armed, and whether it is armed as notification or request type. Next state: Waiting_For_Instructions, Monitoring or Idle Notes: 1. The Tcp timer is started at the time of answer so that the duration of the active call can be timed. If other time values are required (e.g., time for call setup), the CallInformationRequest operation can be used. 2. The Tw timer is equal to the Tcp time minus the standard delta value (30 seconds). 3. Implicit disarming rules are covered in 03.78 section 7.4. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1420V1>
8.4.7.6 Pre-answer events detected

<R-FSD19337.2-1425V1.01> Initial State: Monitoring Internal input: Int_DP_O_No_Answer, Int_DP_T_No_Answer, Int_DP_O_Busy, Int_DP_T_Busy or Int_DP_Route_Select_Failure Internal output: Int_Continue if the corresponding answer EDP is not armed or if it is armed as a notification type. External output: 1. CAP EventReportBCSM if a corresponding EDP is armed. 2. e-parameters if they are stored Action: Processing will be as in 03.78 figure 45 sheet 20. 1. There are three possible outcomes, depending on whether the EDP for the event is armed, and if armed, whether it is armed as a request or a notification. Next state: Monitoring, Idle or Waiting_For_Instructions Notes: 1. After the process Handle_ACR is called, the Delta timer is explicitly stopped. This timer is started in procedure Handle_ACR so that the time between the sending of the ApplyChargingReport and the receipt of a subsequent ApplyCharging can be properly accounted for in the total call period time. The timer is stopped because no further ApplyCharging operations can be received for this particular call configuration. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1425V1>
Page:
Issue: 4 89
8.4.8 Billing and Information request operations

8.4.8.1 Receipt of ApplyCharging operation
<R-FSD19337.2-1500V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions, Monitoring, Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction External Input: CAP ApplyCharging Action: processing will be as in 03.78 figure 45 sheets 4, 13, 17 and 21. Procedure Handle_AC is called (03.78 figure 47) Next state: Same as initial state Notes: 1. Procedure Handle_AC may set an interval timer for the purpose of timing the call after answer is received. 2. Depending on the values of parameters received in the ApplyCharging operation, a warning timer may be played to the CAMEL subscriber 30 seconds before the expiration of the interval timer. References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1500V1>
8.4.8.1.1
Provisionable delta timer -- future
As an option for a release past R1V2, the standard 30-second delta timer value before the call period timer expires may be made settable by the operator.
8.4.8.2 Receipt of SendChargingInformation operation

<R-FSD19337.2-1510V1.01> Initial State: Waiting_For_Instructions, Monitoring, Waiting_For_End_Of_User_Interaction Waiting_For_End_Of_Temporary_Connection External Input: CAP SendChargingInformation Action: Processing will be as in 03.78 figure 45 sheet 24. 1. The following procedure is called: # Handle_SCI Next state: the same as the initial state Notes: References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 90
Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1510V1>
8.4.8.3 Receipt of FurnishChargingInformation operation

<R-FSD19337.2-1520V1.01> Initial State: Waiting_For_Instructions, Waiting_For_End_Of_Temporary_Connection, Waiting_For_End_Of_User_Interaction External Input: CAP FurnishChargingInformation Action: Processing will be as in 03.78 figure 45 sheet 24. 1. Set Tssf to last used time and restart it. 2. If a call record does not exist for this leg ID, then create one with the information contained in the FCI. If a call record already exists for this leg ID, then overwrite it with the FCI information. Next state: the same as the initial state References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1520V1> <R-FSD19337.2-1525V1.01> Initial State: Monitoring External Input: CAP FurnishChargingInformation Action: Processing will be as in 03.78 figure 45 sheet 25. 1. If a call record does not exist for this leg ID, then create one with the information contained in the FCI. If a call record already exists for this leg ID, then overwrite it with the FCI information. Next state: the same as the initial state References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1525V1>
8.4.8.4 Receipt of CallInformationRequest operation

<R-FSD19337.2-1530V1.01> Process: gsmSSF Initial State: Waiting_For_Instructions External Input: CAP CallInformationRequest Action: Processing will be as in 03.78 figure 45 sheet 25. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 91
Page:
1. The request is stored and the number of outstanding Call Information Requests is incremented. 2. The Tssf timer is set to the last used value and restarted. Next state: Waiting_For_Instructions References: 03.78; 09.78 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-1530V1>
Assisting MSC
The assisting MSC is used to set up an announcement and digit collection session for another MSC that requests its services. An assisting MSC can have either internal SRF functionality or can connect to an external IP. The exact configuration makes no difference to the initiating MSC, and in fact from the perspective of the initiating MSC, an assisting MSC is the same as an external IP. As with the MSC, there are two distinct models on the assisting MSC: the CCF and the SSF. The assisting CCF requirements are located in 03.78 and not in 23.018, the basic call handling specification. An MSC acting as an assisting MSC will contact an internal SRF similar to the procedures for an initiating MSC that has an internal SRF. The internal SRF will be implemented on the Lucent Media Server (LMS), and internal messages will be passed from call control to the LMS.
9.1
Assisting Call Control State Machine
The CAMEL specification 03.78 models events from an internal or external case for the relay case as going directly from the gsmSSF to the SRF. In practice, since the CCF is typically responsible for setting up voice connections to announcement and digit collection functions, whether internal or external to the MSC, these messages will likely pass through the CCF. However, for requirements purposes, this does not have to be shown, and the convention of 03.78 will be followed.
9.1.1 Receipt of Initial Request from Initiating MSC

<R-FSD19337.2-2000V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Idle External Input: Initial routing message from initiating MSC (e.g., ISUP IAM) Internal Output: Int_Assist_Required Action: Processing will be as in 03.78 Figure 53 sheet 1 Next State: Wait_for_assisting_gsm_SSF_invoked References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2000V1> QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 92
Page:
<R-FSD19337.2-2010V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Wait_for_assisting_gsm_SSF_invoked Internal Input: Int_Assisting_gsmSSF_invoked Action: Processing will be as in 03.78 Figure 53 sheet 1 Next State: Wait_For_Assisting_Event References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2010V1> <R-FSD19337.2-2020V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Wait_for_assisting_gsm_SSF_invoked External Input: Release from Initiating MSC Internal Output: Int_Release_Assisting_gsmSSF Action: Processing will be as in 03.78 Figure 53 sheet 1 Next State: Idle References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2020V1>
9.1.2
Awaiting Instructions on Announcement Sessions
<R-FSD19337.2-2030V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Wait_For_Assisting_Event Internal Input: Int_Connect_To_Resource Internal Output: Int_Invoke_SRF (to SRF) Action: Processing will be as in 03.78 Figure 53 sheet 2 1. A connection must be set up to an announcement and digit collection facility. Next State: Await_SRF_Initialization References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2030V1> <R-FSD19337.2-2040V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Wait_For_Assisting_Event QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 93
Page:
Internal Input: Int_assisting_gsmSSF_released External Output: Release message back to initiating MSC Action: Processing will be as in 03.78 Figure 53 sheet 2 Next State: Idle References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2040V1> FUTURE <R-FSD19337.2-2050V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Wait_For_Assisting_Event External Input: Release from initiating MSC Internal Output: Int_release_assisting_gsmSSF Action: Processing will be as in 03.78 Figure 53 sheet 2 Next State: Idle Notes: 1. Figure 53 sheet 2 has an added intermediate state -- "Release_Assisting_gsmSSF" -- which waits for an addition input from process Assisting_gsmSSF -"Int_assisting_gsmSSF_released". However, there process Assisting_gsmSSF has no choice but to send this internal message back, so this added state essentially adds no value, and is skipped. References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2050V1> <R-FSD19337.2-2060V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Await_SRF_Initialization Internal Input: Int_SRF_Connected (from SRF) Internal Output: Int_release_assisting_gsmSSF Action: Processing will be as in 03.78 Figure 53 sheet 3 1. The incoming path must be joined to the SRF. 2. Call procedure Send_ACM_If_Required. 3. Call procedure Send_Answer_If_Required. Next State: Wait_For_Assisting_Event References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2060V1> QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 94
<R-FSD19337.2-2070V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Await_SRF_Initialization Internal Input: Int_SRF_Connection_Failure (from SRF) Internal Output: Int_CTR_Failed Action: Processing will be as in 03.78 Figure 53 sheet 3 Next State: Wait_For_Assisting_Event References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2070V1> <R-FSD19337.2-2080V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Await_SRF_Initialization External Input: Release from initiating MSC Internal Output: Int_Disconnect_SRF (to SRF) Action: Processing will be as in 03.78 Figure 53 sheet 3 Next State: Await_gsmSRF_Disconnection References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2080V1> <R-FSD19337.2-2090V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Await_gsmSRF_Disconnection Internal Input: Int_SRF_Released (from SRF) Internal Output: Int_release_assisting_gsmSSF Action: Processing will be as in 03.78 Figure 53 sheet 3 Next State: Idle Notes: the "Releasing_assisting_gsmSSF" state is not specified separately. References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2090V1> <R-FSD19337.2-2100V1.01> FUTURE Process: CAMEL_Assisting_MSC Initial State: Await_SRF_Initialization Internal Input: Int_assisting_gsmSSF_released (from gsmSSF) QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 95
External Output: Release back to initiating MSC Action: Processing will be as in 03.78 Figure 53 sheet 3 Next State: Idle References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2100V1>
9.2 9.2.1
Process Assisting_gsmSSF Requesting Instructions from the gsmSCF
<R-FSD19337.2-2310V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Idle Internal Input: Int_Assist_Required Internal Output: Int_Assisting_gsmSSF_Invoked External Output: CAP AssistRequestInstructions operation to the gsmSCF Action: Processing will be as in 03.78 Figure 54 sheet 1 1. Set Tssf to default user interaction value (see section entitled "Timers and Timer Handling") 2. Open a control relationship Next State: Waiting_For_Instructions References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2310V1>
9.2.2 gsmSCF Instructions

<R-FSD19337.2-2320V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Waiting_For_Instructions Internal Input: Expiration of Tssf timer Internal Output: Int_assisting_gsmSSF_released External Output: TCAP Abort to gsmSCF Action: Processing will be as in 03.78 Figure 54 sheet 2 Next State: Idle References: 23.018; 03.78 Feature ID: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 96
Page:
Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2320V1>
9.2.2.1 Receipt of ResetTimer operation

<R-FSD19337.2-2330V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Waiting_For_Instructions External Input: CAP ResetTimer operation Action: Processing will be as in 03.78 Figure 54 sheet 2 1. The Tssf is reset to the value in the operation and restarted. Next State: Waiting_For_Instructions References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2330V1>
9.2.2.2 Receipt of ConnectToResource operation

<R-FSD19337.2-2340V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Waiting_For_Instructions External Input: CAP ConnectToResource operation Internal Output: Int_Connect_To_Resource Action: Processing will be as in 03.78 Figure 54 sheet 2 Next State: Await_Resource_Connection References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2340V1> <R-FSD19337.2-2350V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Await_Resource_Connection Internal Input: Int_CTR_Failed External Output: "System Failure" error to gsmSCF Action: Processing will be as in 03.78 Figure 54 sheet 2 Next State: Waiting_For_Instructions References: 23.018; 03.78 QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 97
Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2350V1> <R-FSD19337.2-2360V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Await_Resource_Connection Internal Input: Int_SRF_Connected Action: Processing will be as in 03.78 Figure 54 sheet 2 1. Reset the Tssf timer to the user interaction value and restart it (see the section entitled "Timers and Timer Handling". Next State: Waiting_For_End_Of_User_Interaction References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2360V1>
9.2.2.3 Receipt of DisconnectForwardConnection operation

<R-FSD19337.2-2370V1.01> FUTURE Process: Assisting_gsmSSF Initial State: Waiting_For_End_Of_User_Interaction External Input: CAP DisconnectForwardConnection Internal Output: Int_Disconnect_SRF to SRF Action: Processing will be as in 03.78 Figure 54 sheet 3 1. Reset the Tssf timer to the default user interaction value and restart it (see the section entitled "Timers and Timer Handling". Next State: Waiting_For_End_Of_User_Interaction Notes: 1. 03.78 shows internal messages going directly from the Assisting_gsmSSF to the SRF. In the gsmSSF state machine, these messages are sent via the CCF. This convention will be followed here. Thus, the CCF will receive some extra internal messages not covered in process CAMEL_Assisting_MSC dealing with the SRF connection. References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2370V1> <R-FSD19337.2-2380V1.01> FUTURE Process: Assisting_gsmSSF QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 98
Page:
Initial State: Waiting_For_End_Of_User_Interaction Internal Input: Int_SRF_Released Action: Processing will be as for 03.78 figure 54 sheet 3. Next State: Waiting_For_Instructions References: 23.018; 03.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-2380V1>
9.2.2.4 Receipt of PlayAnnouncement operation

<R-FSD19337.2-2390V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction External input: CAP PlayAnnouncement operation Internal output: CAP PlayAnnouncement relayed to SRF Action: Processing will be as in 03.78 figure 54 sheet 3. 1. Reset the Tssf timer to the last value used and restart it. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The various gsmSRF configurations are shown in 09.78 section 4.2 "Physical Scenarios". The scenarios covered by this requirement are 3 and 4. [Note: it is still an open issue whether scenario 4 (connection to IP with relay function) will be supported). References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2390V1>
9.2.2.5 Receipt of PromptAndCollectUserInformation operation

<R-FSD19337.2-2400V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction External input: CAP UserInformation operation Internal output: CAP PromptAndCollectUserInformation operation relayed to SRF Action: Processing will be as in 03.78 figure 54 sheet 3. 1. Reset the Tssf timer to the last value used and restart it. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The various gsmSRF configurations are shown in 09.78 section 4.2 "Physical Scenarios". The scenarios covered by this requirement are 3 and 4. [Note: it is still an open issue whether scenario 4 (connection to IP with relay function) will be supported). QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 99
References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2400V1>
9.2.2.6 Receipt of Cancel operation for announcement sessions

<R-FSD19337.2-2410V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction External input: CAP Cancel operation containing the "invoke ID" parameter. Internal output: CAP Cancel relayed to SRF Action: Processing will be as in 03.78 figure 54 sheet 3. 1. Reset the Tssf timer to the last value used and restart it. Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The various gsmSRF configurations are shown in 09.78 section 4.2 "Physical Scenarios". References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2410V1> <R-FSD19337.2-2420V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction Internal input: Previous operation "Canceled" error indicated from CCF. External output: CAP Cancel error sent to gsmSCF. Action: Processing will be as in 03.78 figure 54 sheet 4. Next state: Waiting_For_End_Of_User_Interaction Notes: 2. This is one instance where an error indicates the successful execution of an operation -- i.e., a CAP Cancel operation. If the previously requested operation (PlayAnnouncement or PromptAndCollectUserInformation) was successfully canceled, then this error is returned to the gsmSCF in a Return Error. See the definition of the Cancel operation in 09.78. References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2420V1> QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 100
Page:
<R-FSD19337.2-2430V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction Internal input: "Cancel failed" error indicated from SRF External output: CAP Cancel Failed error sent to gsmSCF. Action: Processing will be as in 03.78 figure 54 sheet 4. Next state: Waiting_For_End_Of_User_Interaction Notes: 2. This is the case where a Cancel operation was not successfully carried out, e.g., because the announcement was already successfully played. See the definition of the Cancel operation in 09.78. References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2430V1>
9.2.2.7 Sending PromptAndCollectUserInformation result

<R-FSD19337.2-2440V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction Internal input: Collected digits from user interaction from SRF External output: CAP PromptAndCollectUserInformation Return Result. Action: Processing will be as in 03.78 figure 54 sheet 4. Next state: Waiting_For_End_Of_User_Interaction Notes: 2. After a caller has entered digits in response to some prompt, the digits are sent back to the gsmSCF. References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2440V1>
9.2.2.8 Sending SpecializedResourceReport

<R-FSD19337.2-2450V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction Internal input: Announcement complete indication from SRF External output: If the previously received PlayAnnouncement indicated that a response is required, then a CAP SpecializedResourceReport operation is sent to the gsmSCF. Action: Processing will be as in 03.78 figure 54 sheet 4. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 101
Page:
Next state: Waiting_For_End_Of_User_Interaction Notes: 1. The PlayAnnouncement parameter is called "requestAnnouncementComplete". See 09.78. References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2450V1>
9.2.2.9 Expiration of Tssf timer during announcement session

<R-FSD19337.2-2460V1.01> FUTURE Initial State: Waiting_For_End_Of_User_Interaction Internal Input: Expiration of Tssf timer External Output: TCAP Abort towards gsmSCF Internal Output: Int_Disconnect_SRF to gsmSRF Next State: Wait_For_gsmSRF_Release Action: processing will be as in 03.78 figure 54 sheet 5. Notes: 1. The PlayAnnouncement parameter is called "requestAnnouncementComplete". See 09.78. References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783) . Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2460V1> <R-FSD19337.2-2470V1.01> FUTURE Process: gsmSSF Initial State: Wait_For_gsmSRF_Release Internal Input: Int_SRF_Released from SRF External Output: Int_assisting_gsmSSF_released Next State: Idle Action: Processing will be as in 03.78 figure 54 sheet 5 1. Procedure Complete_all_FCI_records is called. References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2470V1> QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 102
Page:
<R-FSD19337.2-2480V1.02> FUTURE Process: gsmSSF Initial State: Waiting_For_Instructions, Waiting_For_End_Of_User_Interaction Internal Input: Int_release_assisting_gsmSSF External Output: Int_assisting_gsmSSF_Released Next State: Idle Action: Processing will be as in 03.78 figure 54 sheet 6 1. The control relationship is terminated References: 03.78; 09.78 Feature ID: Modification Reason: In version 1.01, modified references (mr=17711) and marked the requirement as FUTURE (mr=17783). In version 1.02 changed duplicate reqs number (mr=18117/IMR=747756). Owner: Andrew McClurg Keyword: Assisting gsmSSF <End of R-FSD19337.2-2480V1>
10 MAP Requirements
This section contains all of the MAP operations that are affected by CAMEL, including new and modified operations. 03.78 and 23.078 contain the information flow view of the affected MAP operations, with descriptions of the new and modified information elements. 09.02 and 29.002 contain the protocol definitions and message handling. For modified MAP messages, no new message handling is specified in this requirements document. For new MAP messages for CAMEL, the section in 09.02 that must be followed is specified.
10.1 HLR !" VLR Information Flows 10.1.1 MAP ProvideSubscriberInfo operation
<R-FSD19337.2-3000V1.02> The ProvideSubscriberInfo operation, result and errors will be handled as defined in 29.002 and 03.78. 1. The parameters that will be supported in the ProvideSubscriberInfo result for location information will be: Age of location information VLR number Location number Service Area ID or LAI Current Location Retrieved indicator 2. Subscriber state is defined in 03.78 section 9.10.2. Message handling will be as specified in ETSI 29.002 section 21.2.6. Notes: 1. The ProvideSubscriberInfo operation may request subscriber location and/or state information. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 103
Page:
2. The location number will be derived from the last known Service Area ID and LAI using the table defined in the VLR requirements section. References: 03.78; 29.002 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). In version, 1.02 clarified the parameters of the operation (mr=17861). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-3000V1> <R-FSD19337.2-3005V1.02> Upon receipt of a ProvideSubscriberInfo operation, the MSC must send back the information requested if available. Notes: 1. Information requested can include any or all of: VLR address, location area or Service Area ID, and subscriber state. 2. A separate data requirement covers the table that allows the derivation of geographical position from Service Area ID. References: 03.78; 09.02 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). In version, 1.02 clarified the parameters of the operation (mr=17861). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3005V1>
10.1.2 MAP Insert Subscriber Data operation

<R-FSD19337.2-3010V1.01> The following CAMEL information elements will be supported when received in the InsertSubscriberData (ISD) operation, as specified in ETSI 29.002 and 03.78: 1. Originating CAMEL subscription information (O-CSI) 2. Supplementary Services Invocation Notification subscription information (SS-CSI) The following information element will be included in the InsertSubscriberData result when CAMEL subscription information has been sent in an ISD operation: 1. Supported Camel Phases References: 03.78; 29.002 v6.6.0 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3010V1>
10.1.3 Map DeleteSubscriberData operation

The following CAMEL information elements will be supported in the DeleteSubscriberData operation, as specified in ETSI 29.002 and 03.78: 1. Camel Subscription Information Withdraw References: 03.78; 29.002 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3020V1>
10.1.4 Map UpdateLocation operation

<R-FSD19337.2-3030V1.01> The following CAMEL information elements will be supported in the UpdateLocation operation, as specified in ETSI 29.002 and 03.78: 1. Supported CAMEL phases References: 03.78; 29.002 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3030V1>
10.1.5 Map RestoreData operation

<R-FSD19337.2-3040V1.01> The following CAMEL information elements will be supported in the RestoreData operation, as specified in ETSI 29.002 and 03.78: 1. Supported CAMEL phases References: 03.78; 29.002 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3040V1>
10.1.6 Map ProvideRoamingNumber operation

<R-FSD19337.2-3050V1.01> The following CAMEL information elements will be supported in the ProvideRoamingNumber operation, as specified in ETSI 29.002 and 03.78: 1. Suppression of announcements 2. Call reference number 3. GMSC address 4. Alerting pattern 5. GMSC CAMEL phases QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 105
Page:
Notes: 1. Suppression of announcement and alerting pattern are covered in separate requirements below. 2. Refer to 03.78 and its section on the InitialDP information flow for details on the use of the GMSC address parameter. 3. The call reference number is included in the InitialDP sent to the gsmSCF. References: 03.78; 29.002 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3050V1> <R-FSD19337.2-3052V1.01> After receipt of a ProvideRoamingNumber operation with the "announcement suppression" parameter included, the MSC must not play any switch generated error announcements back to the calling subscriber. Notes: 1. The reason for announcement suppression is so that callers to a CAMEL subscriber will not be able to determine where the CAMEL subscriber is based on a local VMSCs error message (e.g., a Swedish announcement would make it clear the subscriber was in Sweden). References: 03.78; 29.002 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3052V1> <R-FSD19337.2-3054V1.01> After receipt of a ProvideRoamingNumber operation with the "alerting pattern" parameter included, the MSC will send the alerting pattern to the terminating CAMEL subscriber's mobile. Notes: 1. The mobile may not support the alerting pattern sent. References: 03.78; 29.002 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-3054V1>
10.2 HLR !" GMSC Information Flows 10.2.1 MAP SendRoutingInfo operation
<R-FSD19337.2-3060V1.01> Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 106
Page:
The following CAMEL information elements will be supported in the SendRoutingInfo as specified in ETSI 29.002 and 03.78 section 9.12.1: 1. Alerting Pattern 2. Suppression of announcement (sent only in the second SRI, if available) 3. Suppress T-CSI (sent only in the second SRI) 4. Supported CAMEL phases 5. Call reference number 6. GMSC address The following CAMEL information elements will be supported in the SendRoutingInfo result, as specified in ETSI 29.002 and 03.78 section 9.11.1: 1. Location information 2. Originating CAMEL subscription information (O-CSI) 3. Subscriber state 4. Terminating CAMEL subscription information (T-CSI) 5. Basic Service code 6. GMSC CAMEL phases Notes: 1. The CUG subscription flag parameter will be required when CUG is supported. References: 03.78; 29.02 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-3060V1>
10.3 VMSC !" GMSC Information Flows 10.3.1 MAP ResumeCallHandling operation
<R-FSD19337.2-3070V1.01> The following CAMEL information elements will be supported in the ResumeCallHandling as specified in ETSI 29.02 and 03.78 section 9.12.1: 1. Originating CAMEL subscription information (O-CSI) The procedures for handling this operation will be as in ETSI 29.002 section 21.3. Notes: Optimal Routing will not be supported in R1V2, but other VMSCs may support it. References: 03.78; 29.002 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-3070V1>
Page:
Issue: 4 107
10.4 MSC to gsmSCF Information Flows

<R-FSD19337.2-3080V1.01> The SS-InvocationNotification operation, result and errors will be handled as defined in 29.02. When one of the following services is invoked, the MSC will send an SSInvocationNotification to the gsmSCF indicating the service: 1. Explicit Call Transfer 2. Multi-Party 3. Call Deflection When the Explicit Call Transfer (ECT) or Call Deflection (CD) service is invoked, then an additional parameter is sent (ss-EventSpecification) is sent. For ECT, this parameter contains the called party number for each call originated by the subscriber and relevant to the ECT invocation. For CD, the called party number of the deflected to party is included. Notes: 1. In u01.03, only Multi-Party will be supported on the MSC. References: 03.78; 29.002 Feature ID: 50.100 Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: gsmSSF <End of R-FSD19337.2-3080V1>
11 CAP Requirements
11.1 CAP Application Contexts
<R-FSD19337.2-4000V1.01> The following CAP phase 2 application contexts will be supported as per ETSI 09.78 section 6.6: CAP-v2-gsmSSF-to-gsmSCF-AC APPLICATION-CONTEXT CAP-v2-assist-gsmSSF-to-gsmSCF-AC APPLICATION-CONTEXT CAP-v2-gsmSRF-to-gsmSCF-AC APPLICATION-CONTEXT Notes: these application contexts include application service elements (ASEs) that are defined in 09.78 section 6.5. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4000V1> <R-FSD19337.2-4010V1> The following CAP phase 1 application context will be supported as per ETSI 09.78 release 96 (version 5.7.0) section 6.6 for subscribers whose CAMEL subscription information indicates that CAMEL phase 1 is the highest version supported: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 108
Page:
CAP-v1-gsmSSF-to-gsmSCF-AC APPLICATION-CONTEXT Notes: 1. This application context includes application service elements (ASEs) that are defined in 09.78 section 6.4. 2. If a mobile subscriber's subscription data indicates CAMEL phase 1, then CAP phase 1 operations must be sent to the gsmSCF. References: 09.78 v5.7.0 Feature ID: 50.100F Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4010V1>
11.2 CAP Operations

For the following requirements, support of an operation implies support of any argument, result and/or errors defined in specification 09.78 sections 6, 8 and 9. In addition, the timer values will be supported as defined in 09.78 for each operation. Default timer values are given in a separate requirement in this section.
11.2.1 CAP ActivityTest operation

<R-FSD19337.2-4100V1.01> The CAP ActivityTest operation will be supported as per ETSI 09.78. Notes: This operation allows the gsmSCF to determine if a dialogue is still active in the gsmSSF. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4100V1>
11.2.2 CAP ApplyCharging operation

<R-FSD19337.2-4105V1.02> The CAP ApplyCharging operation will be supported as per ETSI 09.78. Notes: 1. This operation requests call related information to be returned to the gsmSCF via an ApplyChargingReport operation. 2. The parameter aChBillingChargingCharacteristics is encoded at the top level as an OCTET STRING and then is "CONSTRAINED BY" the definition CAMELAChBillingChargingCharacteristics. The encoding of the ApplyCharging will treat this parameter as an OCTET STRING, i.e., will use a primitive tag. A secondary decoding will have to be performed on the constructor element that is contained in the OCTET STRING and is further defined in the specification. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 109
Page:
References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). In version 1.02 changed duplicate requirements number (mr=18117/IMR=747756). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4105V1>
11.2.3 CAP ApplyChargingReport operation

<R-FSD19337.2-4110V1.01> The CAP ApplyChargingReport operation will be supported as per ETSI 09.78. Notes: 1. This operation sends call related information to the gsmSCF previously requested via an ApplyCharging operation. 2. The parameter CallResult is encoded at the top level as an OCTET STRING and then is "CONSTRAINED BY" the definition CAMEL-CallResult. The encoding of the ApplyChargingReport will treat this parameter as an OCTET STRING, i.e., will use a primitive tag. A secondary decoding will have to be performed on the constructor element that is contained in the OCTET STRING and is further defined in the specification. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4110V1>
11.2.4 CAP AssistRequestInstructions operation

<R-FSD19337.2-4120V1.03> FUTURE The CAP AssistRequestInstructions operation will be supported as per ETSI 09.78. Notes: This operation is sent from an assisting gsmSSF to a gsmSCF requesting announcement and/or digit collection instructions. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). In version 1.03 marked as FUTURE (mr=19627). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4120V1>
11.2.5 CAP CallInformationReport operation

<R-FSD19337.2-4130V1.01> The CAP CallInformationReport operation will be supported as per ETSI 09.78. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 110
Page:
Notes: This operation sends call related information to the gsmSCF previously requested via a CallInformationRequest operation. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4130V1>
11.2.6 CAP CallInformationRequest operation

<R-FSD19337.2-4130V1.01> The CAP CallInformationRequest operation will be supported as per ETSI 09.78. Notes: This operation requests call related information to be returned to the gsmSCF via a CallInformationReport operation. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4130V1>
11.2.7 CAP Cancel operation

<R-FSD19337.2-4140V1.01> The CAP Cancel operation will be supported as per ETSI 09.78. Notes: 1. This operation instructs the gsmSSF either to cancel a previously invoked announcement operation or to cancel any outstanding event detection points and requests. 2. If the Cancel operation contains an Invoke ID as an operation parameter (i.e., not the generic TCAP invoke ID for an Invoke component) for an operation that cannot be canceled, then an "operationNotCancellable" error is returned to the gsmSCF. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4140V1>
11.2.8 CAP Connect operation

<R-FSD19337.2-4150V1.03> The CAP Connect operation will be supported as per ETSI 09.78. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 111
Page:
Notes: 1. This operation allows the gsmSSF to modify routing instructions. 2. The support of the "na-info" parameter in u01.03 is for further study. 3. The "alertingPattern" parameter, if sent from a gsmSCF to a GMSC in a Connect that does not change the destination number, is sent to the HLR in a second SendRoutingInfo operation. 4. The Generic Numbers received in the Connect operation replace any existing generic numbers. The maximum number of supported generic numbers is left to implementation. That is, supporting a maximum of 2 or 3 generic numbers is acceptable even though the ASN.1 states a maximum of 5. References: 09.78 Sections 9.11, Annex A.2 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). In version 1.03 added note on Generic number and added section numbers to reference. Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4150V1>
11.2.9 CAP ConnectToResource operation

<R-FSD19337.2-4160V1.01> The CAP ConnectToResource operation will be supported as per ETSI 09.78. Notes: This operation instructs the gsmSSF to set up a connection to announcement and/or tone detection facilities. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4160V1>
11.2.10
CAP Continue operation
<R-FSD19337.2-4170V1.01> The CAP Continue operation will be supported as per ETSI 09.78. Notes: This operation instructs the gsmSSF to continue with call processing from the point at which it was suspended for the CAMEL interaction. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4170V1>
Page:
Issue: 4 112
11.2.11
CAP DisconnectForwardConnection operation
<R-FSD19337.2-4170V1.01> The CAP DisconnectForwardConnection operation will be supported as per ETSI 09.78. Notes: This operation instructs the gsmSSF to tear down an announcement session. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4170V1>
11.2.12
CAP EstablishTemporaryConnection operation
<R-FSD19337.2-4180V1.01.03> The CAP EstablishTemporaryConnection operation will be supported as per ETSI 09.78. Contrary to ETSI 09.78 specification, the gsmSSF shall allow receipt of a correlationID parameter in the CAP ETC with a variable length of 2-16 octets. Contrary to ETSI 09.78 specification, the gsmSSF shall allow receipt of an assistingSSPIPRoutingAddresss parameter in the CAP ETC with a variable length of 3-16 octets. Notes: 1. This operation instructs the gsmSSF to set up an announcement session with an external IP or assisting gsmSSF. 2. The requirements to support a maximum of 16 octets for the correlationID and assistingSSPIPRoutingAddress are based on the engineering decision to implement Rel-99 TS 29.078 definition for maximum length of these parameters for CAMEL Phase 2. (In Rel-98 GSM specification 09.078, the correlationID and assistingSSPIPRoutingAddress are both defined to be maximum 11 octets long.) 3. Defining the minimum length of the assistingSSPIPRoutingAddress parameter to 3 octets long (contrary to the 3GPP Standards specification of minimum 2 octets) allows the re-use of the existing 5E code for design/implementation of this parameter. It is also very unlikely that the SCF will send an assistingSSPIPRoutingAddress parameter without the digits included in the parameter. 4. Based on ASN.1 definition in 09.078, the encoding of the scfID is network operator specific. For the correlationID CAP parameter, the encoding is based on the Generic Digits format specified in Figure 24 in ITU-T Recommendation Q.763.
5. If an error is encountered when mapping the scfId and/or correlationId received from the CAP ETC to the outgoing ISUP IAM message (e.g. the value received is 2 octets long but the ISUP parameters for scfId and/or correlation id require minimum length of 3 octets), the gsmSSF shall send an error response indicating ETCFailed to the QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 113
Page:
gsmSCF. For 3G-MSC ISUP requirements on SCF Id and Correlation Id optional parameters, refer to SRD-CC-IMS-IIUC-1. . References: 09.78, 29.078 Feature ID: 50.100F Modification Reason: - In version 1.01, modified references (mr=17711). - Correction of support for scfID and correlationID per MR=19737. Owner: Andrew McClurg, A.T.Remoquillo Keyword: CAP <End of R-FSD19337.2-4180V1.03>
11.2.13
CAP EventReportBCSM operation
<R-FSD19337.2-4190V1.01> The CAP EventReportBCSM operation will be supported as per ETSI 09.78. Notes: This operation reports an event to the gsmSCF previously requested via a RequestReportBCSMEvent operation. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4190V1>
11.2.14
CAP FurnishChargingInformation operation
<R-FSD19337.2-4200V1.01> The CAP FurnishChargingInformation operation will be supported as per ETSI 09.78. The format of the fCiBillingChargingCharacteristics parameter is network operator specific (NOS) and will be defined for the first release as follows:
1 2 3 4 5 6 7 8 9 10 11 12
8 Spare
7 FUB ind.
6 Dest. ind
5 Orig. ind.
4 Dial. ind.
3 AC/DC ind.
2 ABN ind
1 Annc
Spare Billing Data (CPS, SIC, BOP, Documentation Type) Announcement Units (optional) Length of Alternate Billing Number (optional) Alternate Billing Number (optional) Length of Account/Department Code (optional) Account/Department Code (optional) Length of Dialed Number (optional) Dialed Number (optional) Length of Originating Number (optional) Originating Number (optional) Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 114
13 14 15 16 17 18 19 20 21 22
Usage count 3 Usage count 7 Usage count 11 Usage count 15 Usage count 19 Usage count 23 Usage count 27 Usage count 31
Length of Destination Number (optional) Destination Number (optional) Usage count 2 Usage count 1 Usage count 6 Usage count 5 Usage count 10 Usage count 9 Usage count 14 Usage count 13 Usage count 18 Usage count 17 Usage count 22 Usage count 21 Usage count 26 Usage count 25 Usage count 30 Usage count 29
spare overflow Usage count 4 Usage count 8 Usage count 12 Usage count 16 Usage count 20 Usage count 24 Usage count 28
Notes: 1. This operation instructs the gsmSSF to create or overwrite a billing record and write information into it. 2. The above NOS format is equivalent to 5ESS SSP value 2 for option 9 of feature I1352. . References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4200V1>
11.2.15
CAP InitialDP operation
<R-FSD19337.2-4210V1.01> The CAP InitialDP operation will be supported as per ETSI 09.78. Notes: 1. This operation opens a dialogue with a gsmSCF at DP2 or DP12. 2. For mobile originations, the locationNumber parameter is mapped from the location area and Service Area ID using a relation on the MSC. See the requirement in the VLR Requirements section. 3. The iPSSPCapabilities parameter will be as encoded in 09.78. The bilateral part is not specified in this requirements document at this time and will be added later for specific network operators. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4210V1>
11.2.16
CAP ReleaseCall operation
<R-FSD19337.2-4220V1.01> The CAP ReleaseCall operation will be supported as per ETSI 09.78. Issue: 4 115
Page:
Notes: 1. This operation instructs the gsmSSF to tear down a call. 2. The cause value contained in the operation is mapped to any forward and backward RANAP or ISUP release messages. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4220V1>
11.2.17
CAP RequestReportBCSMEvent operation
<R-FSD19337.2-4230V1.01> The CAP RequestReportBCSMEvent operation will be supported as per ETSI 09.78. Notes: This operation instructs the gsmSSF to monitor for a call related event and then send an EventReportBCSM operation if that event is encountered. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4230V1>
11.2.18
CAP ResetTimer operation
<R-FSD19337.2-4240V1.01> The CAP ResetTimer operation will be supported as per ETSI 09.78. Notes: This operation instructs the gsmSSF to reset the Tssf timer. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4240V1>
11.2.19
CAP SendChargingInformation operation
<R-FSD19337.2-4250V1.03> The CAP SendChargingInformation operation will be supported as per ETSI 09.78. Notes: This operation instructs the gsmSSF to send charging information to a party in the call. It is used for mobile originations to send e-parameters (for GSM Advice of Charge) to a mobile station. QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 116
Page:
Notes: 1. Advice of Charge (AoC) will not be supported in R1V2, i.e., e-values will not be calculated on the MSC. Hence, the e-parameters received in the CAP SendChargingInformation message will not be sent to the MS. In addition, the gsmSSF will not send any error to the gsmSCF to indicate this. References: 09.78 Feature ID: 50.100F Modification Reason: - In version 1.01, modified references (mr=17711). - Modified Notes section per MR= 19740. Owner: Andrew McClurg, A.T.Remoquillo Keyword: CAP <End of R-FSD19337.2-4250V1.03>
11.2.20
CAP PlayAnnouncement operation
<R-FSD19337.2-4260V1.01> The CAP PlayAnnouncement operation will be supported as per ETSI 09.78. The following constraints apply: 1. In the messageID parameter (within the inbandInfo parameter within the informationToSend parameter): elementaryMessageID elementaryMessageIDs variableMessage 2. Although CAP will support "duration" and "interval" parameters up to 32767 seconds, the CCF will support a maximum of 600 seconds (10 minutes) for the total announcement duration, and a maximum of 60 seconds for an announcement interval. Any duration timer value received in a PlayAnnouncement operation of greater than 600 seconds will be reduced to 600 seconds, and any interval timer value greater than 60 seconds will be reduced to 60 seconds. Notes: 1. This operation instructs a gsmSRF (e.g., switch based announcement and digit collection facility) to play an announcement. 2. The "text" parameter within the messageID parameter will not be supported. 3. Each duration and/or interval of 32767 seconds is over 9 hours long. Although the standard specifies this value, no service designer will ever ask for such a value, and if a gsmSCF did, it is considered acceptable for the gsmSSF and CCF to scale back the actual time that an announcement would play. 4. The "variableMessage" contains a "variablePart" that has as input integer numbers and which causes those numbers to be announced interspersed with a standard message. An example would be: "Your balance is five dollars and twenty seven cents", where the italicized numbers are specified in the variablePart parameter as actual integer numbers. The types are as follows: integer number (a string of individual numbers, e.g., telephone number) time date price QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 117
Page:
References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4260V1>
11.2.21
CAP PromptAndCollectUserInformation operation
<R-FSD19337.2-4270V1.01> The CAP PromptAndCollectUserInformation operation will be supported as per ETSI 09.78. The following constraints apply: 1. In the messageID parameter (within the inbandInfo parameter within the informationToSend parameter): elementaryMessageID elementaryMessageIDs variableMessage 2. Although CAP will support "duration" and "interval" parameters up to 32767 seconds, the CCF and or LMS retains the right to run guard timers and to cut off announcements when it deems it appropriate. 3. The "voiceInformation" parameter will be supported for "FALSE. 4. An end of reply digit parameter may be included in this operation. It can be one or two digits and can take the value 0-9 "star" (0x0A) or "pound" (0x0B). 5. A cancel digit parameter may be included in this operation. It can be any digit from 0-9 or "star" or "pound". Only one cancel digit can be received for a prompt and collect session before error processing occurs. If a second cancel digit is received (i.e., during the repeat of the prompt and collect sequence caused by the first cancel digit), then this will be treated as an error condition. Note that if the error treatment is "reprompt" then the whole prompt and collect sequence will begin again, and a cancel digit will again be valid one time. 6. A start digit parameter may be included in this operation. It can be any digit from 0-9 or "star" or "pound". 7. The rest of the standard functionality will be supported (see notes). Notes: 1. This operation instructs a gsmSRF (e.g., switch based announcement and digit collection facility) to play an announcement and collect digits or other in band information. 2. For details on the announcement part, see the "PlayAnnouncement" operation above. 3. Text to speech will not be supported in u01.03 for the internal SRF. External IPs may support this. 4. User input can be terminated by one of the following. Once a termination condition is encountered, no more digits will be processed. maximum number of digits reached (this is a parameter of the operation) end of reply received cancel received pre digit timeout inter digit timeout 5. If the minimum number of digits is not received, this is treated as an error condition (see errorTreatment parameter below). The default value is 1. 6. The "voiceBack" parameter will not be supported. 7. The "interruptibleAnnInd" parameter will be supported, i.e., if this value is set to "TRUE" then the first received digit will halt the announcement and that digit will be processed. If this value QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 118
8.
9. 10. 11.
12. 13.
is set to FALSE then the announcement will play to completion while digits may be collected at the same time. The errorTreatment parameter determines what happens if there is an error in the digit collection process. The default is "standard error and info" which means that normal error processing occurs, i.e., a return error is sent to the SCP. The second option is "help" which indicates that no error is returned to the SCP, and instead a network dependent default announcement is played to the caller and digits collection is repeated. The third option is "repeat prompt", where the original announcement is repeated and digits collection is repeated. The second or third option is executed only once. A second error will result in standard error treatment. (see 03.78 section 9.22.3.1). The first received digit that interrupts an announcement may be valid or invalid, and will be processed accordingly. The start digit may be any one or two digit string, as per 09.78. When a cancel digit is received, all previously received digits are discarded and the prompt and collect sequence begins again, i.e., the prompt announcement is replayed and data entry begins again. It makes little sense from a service perspective to have an end of reply or cancel digit as a regular number (0-9). More sophisticated automatic speech recognition is for further study.
References: 09.78, 03.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711) and removed stated support for text to voice, voice recognition and voice back (rm=17783). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4270V1>
11.2.22
CAP SpecializedResourceReport operation
<R-FSD19337.2-4280V1.01> The CAP SpecializedResourceReport operation will be supported as per ETSI 09.78. Notes: 1. This operation is used by the gsmSRF to notify a gsmSCF that an announcement session is complete. 2. This is a linked operation -- linked to a previously received PlayAnnouncement operation. Thus the TCAP invoke will include a linked ID that is the invoke ID of the PlayAnnouncement operation to which the SpecializedResourceReport is responding References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4280V1>
11.2.23
Operation Timers
<R-FSD19337.2-4290V1.01> Timers for individual operations will be modifiable through the administrative terminal within the bounds established for the specific timer value -- e.g., short, medium or long. The default values for operation timers are as follows: QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Page: Issue: 4 119
Short: 10 seconds Medium: 30 seconds Long: 120 seconds Notes: 1. Timers for each operation are specified in 09.78 section 6.1. Each operation timer is assigned a value of "short", "medium" or "long", which gives a range for the timer. References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4290V1>
11.3 CAP and ISUP Interworking

<R-FSD19337.2-4300V1.01> The interworking between CAP operations and ISUP will be supported as specified in Annex A -- "Mapping between CAP and ISUP" -- of ETSI 09.78. Notes: 1. This section covers the following operations: InitialDP Connect AssistRequestInstructions ConnectToResource EstablishTemporaryConnection ReleaseCall References: 09.78 Feature ID: 50.100F Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CAP <End of R-FSD19337.2-4300V1>
11.4 CAP and RANAP Interworking

The interworking between CAP and RANAP is addressed in the individual requirements for the Connect and ReleaseCall operations.
Page:
Issue: 4 120
12 Internal Announcement Interface

The internal messages between the Feature Server and the Lucent Media Server (LMS), for the support of MSC based announcements for IN services, are specified in the architecture interface document (QDI reference to be specified later).
13 Billing Requirements
The billing information specified in this section is derived from 3GPP specification 32.005 "GSM call and event data for the Circuit Switched (CS) domain (Release 99)". For further information on the fields, please refer to that document, available from the 3GPP server (see References section).
13.1 Mobile Origination Call Record

<R-FSD19337.2-6000V1.03> For mobile originations, the information included in the following table will be stored in a call record. Notes: 1. The information listed below does not show the entire contents of the call record, just the CAMEL specific information. 2. The following information included in the MOC call record are specific to CAMEL Phase 3 capabilities and will not be set during invocation of a CAMEL Phase 2 DP: - Free format data append indicator - Default call handling 2 - GsmSCF address 2 - Service key 2 - Free format data append indicator 2 - Free format data append indicator 2 References: 32.005 V3.6.0 Feature ID: 50.100 Modification Reason: Additional notes for clarification (MR= 19742). Owner: Andrew McClurg, A.T.Remoquillo Keyword: Billing and Charging <End of R-FSD19337.2-6000V1.03>
Page:
Issue: 4 121
Field
Translated Number gsmSCF address Service key Network call reference MSC Address Default call handling Number of DP encountered Level of CAMEL service Free format Data O C C C C O O O C
Description
The called number after digit translation within the MSC (if applicable) Identifies the CAMEL server serving the subscriber. The CAMEL service logic to be applied. An identifier to correlate transactions on the same call taking place in different network nodes, shall be present if CAMEL is applied. This field contains the E.164 number assigned to the MSC that generated the network call reference. Indicates whether or not a CAMEL call encountered default call handling. This field shall be present only if default call handling has been applied. Number that counts how often armed detection points (TDP and EDP) were encountered. Indicator for the complexity of the CAMEL feature used. This field contains data sent by the gsmSCF in the FCI message(s). The data can be sent either in one FCI message or several FCI messages with append indicator. Set of CAMEL information IEs. Each of these IEs contains information related to one outgoing CAMEL call leg. Indicator if free format data from this CDR is to be appended to free format data in previous partial CDR. Indicates whether or not a CAMEL call encountered default call handling for 2nd service such as dialled service. This field shall be present only if default call handling has been applied. Identifies the CAMEL server serving the subscriber for 2nd service such as dialled service. The CAMEL service logic to be applied for 2nd service such as dialled service. nd This field contains data sent by the gsmSCF in the FCI message(s) for 2 service such as dialled service. The data can be sent either in one FCI message or several FCI messages with append indicator. Indicator if free format data for 2nd service from this CDR is to be appended to free format data in previous partial CDR. This is not in 32.005 but is added for this requirements document.
CAMEL call leg information Free format data append indicator Default call handling 2
C C O
GsmSCF address 2 Service key 2 Free format Data 2
C C C
Free format data append indicator 2 SCP translated number
C M
Table 1
13.2 Mobile Originated Call Forwarding Call Record

<R-FSD19337.2-6010V1.03> For mobile call forwarding, the information included in the following table will be stored in a call record. Notes: 1. The following information included in the MOC, Call Forwarding call record are specific to CAMEL Phase 3 capabilities and will not be set during invocation of a CAMEL Phase 2 DP: - Free format data append indicator - Default call handling 2 QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 122
Page:
GsmSCF address 2 Service key 2 Free format data append indicator 2 Free format data append indicator 2
2. The following Lucent extensions have been added to the MOC, CF call attempt record for invocation of CAMEL Trigger Detection Points at the GMSC for Lucent's Flexent Packet Gateway (FPG) product: - NAOliInfo - NAChargeNumber Refer to SRD-1992 and SRD-CC-FPG-UPCR-1 for CAMEL billing requirements specific to Lucent's FPG Carrier Select feature. References: 32.005 V3.6.0 Feature ID: 50.100 Modification Reason: Additional notes for clarification (MR= 19742). Owner: Andrew McClurg, A.T.Remoquillo Keyword: Billing and Charging <End of R-FSD19337.2-6010V1.03>
Page:
Issue: 4 123
Field gsmSCF address Service key Network call reference MSC Address CAMEL initiated CF indicator Default call handling Number of DP encountered Level of CAMEL service Free format Data
C C C C C O O O C
CAMEL call leg information Free format data append indicator Default call handling 2
C C O
GsmSCF address 2 Service key 2 Free format Data 2
C C C
Free format data append indicator 2 SCP translated number NAOliInfo NAChargeNumber
C M C C
Description Identifies the CAMEL server serving the subscriber. The CAMEL service logic to be applied. An identifier to correlate transactions on the same call taking place in different network nodes, shall be present if CAMEL is applied. This field contains the E.164 number assigned to the MSC that generated the network call reference. Indicates that the CAMEL server initiated call forwarding. Indicates whether or not a CAMEL call encountered default call handling. This field shall be present only if default call handling has been applied. Number that counts how often armed detection points (TDP and EDP) were encountered. Indicator of the complexity of the CAMEL feature used. This field contains data sent by the gsmSCF in the FCI messages. The data can be sent either in one FCI message or several FCI messages with append indicator. Set of CAMEL information IEs. Each of these IEs contains information related to one outgoing CAMEL call leg. Indicator if free format data from this CDR is to be appended to free format data in previous partial CDR. Indicates whether or not a CAMEL call encountered default call handling for 2nd service such as dialled service. This field shall be present only if default call handling has been applied. Identifies the CAMEL server serving the subscriber for 2nd service such as dialled service. The CAMEL service logic to be applied for 2nd service such as dialled service. This field contains data sent by the gsmSCF in the FCI message(s) for 2nd service such as dialled service. The data can be sent either in one FCI message or several FCI messages with append indicator. Indicator if free format data for 2nd service from this CDR is to be appended to free format data in previous partial CDR. This is not in 32.005 but is added for this requirements document. Added as a Lucent extension for the Carrier Select feature. This field contains the North America Originating Line Information received from the gsmSCF. Added as a Lucent extension for the Carrier Select feature. This field contains the North America Charge Number received from the gsmSCF.
Table 2
13.3 Terminating CAMEL Call Record

Some of the fields in the following record will already be available from existing call processing. However, since 32.005 has a specific CAMEL terminating call record (unlike for originations and call forwarding) the entire record is reproduced here. <R-FSD19337.2-6020V1.03> For mobile terminations involving a T-CSI being invoked, the information included in the following table will be stored in a call record. Notes: 1. The following Lucent extensions have been added to the Terminating CAMEL call attempt record for invocation of CAMEL Trigger Detection Points at the GMSC for Lucent's Flexent Packet Gateway (FPG) product: - NAOliInfo QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 124
Page:
- NAChargeNumber Refer to SRD-1992 and SRD-CC-FPG-UPCR-1 for CAMEL billing requirements specific to Lucent's FPG Carrier Select feature.
References: 32.005 v3.6.0 Feature ID: 50.100 Modification Reason: Modified to be compliant with R99 Specifications (MR=19742). Owner: Andrew McClurg, A.T.Remoquillo Keyword: Billing and Charging <End of R-FSD19337.2-6020V1.03>
Field Record Type Served IMSI Served MSISDN Recording Entity Int. time stamp CAMEL Destination Number gsmSCF Address Service key Network call reference MSC Address Default call handling Record extensions Called Number Calling Number Incoming TKGP Outgoing TKGP Event time stamps: Description Terminating CAMEL interrogation. IMSI of the called party The MSISDN of the called party. The E.164 number of the GMSC. Time at which the interrogation was invoked. The number available for routing after the CAMEL server enquiry. The CAMEL server serving the subscriber. The CAMEL service logic to be applied. An identifier to correlate transactions on the same call taking place in different network nodes, shall be present if CAMEL is applied. This field contains the E.164 number assigned to the MSC that generated the network call reference. Indicates whether or not a CAMEL call encountered default call handling. This field shall be present only if default call handling has been applied. A set of network/ manufacturer specific extensions to the record. The address of the called party as received by the GMSC/gsmSSF. The address of the calling party, if available. The GMSC trunk group on which the call originated. The trunk group on which the call left the GMSC Seizure of incoming traffic channel (for unsuccessful call attempts) Answer (for successful calls) Release of traffic channel The chargeable duration of the connection for successful calls, the holding time of call attempts. The number of data segments transmitted if available at the GMSC The reason for the release of the connection. A more detailed reason for the release of the connection. A local identifier distinguishing between transactions on the same MS Partial record sequence number, only present in case of partial records. Number that counts how often armed detection points (TDP and EDP) were encountered. Indicator of the complexity of the CAMEL feature used. This field contains data sent by the gsmSCF in the FCI message Set of CAMEL information IEs. Each of these IEs contains information related to one outgoing CAMEL call leg. Added as a Lucent extension for the Carrier Select feature. This field contains the North America Originating Line Information received from the gsmSCF. Added as a Lucent extension for the Carrier Select feature. This field contains the North America Charge Number received from the gsmSCF.
M M O M M M M M M M O O M C O O C C O M C M O M C O O C C C C
Call duration Data volume Cause for termination Diagnostics Call reference Sequence no. Number of DP encountered Level of CAMEL service Free format Data CAMEL call leg information NAOliInfo NAChargeNumber
<R-FSD19337.2-6030V1.03> (DELETED) QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 125
Page:
References: 32.005 v3.1.0 Feature ID: 50.100 Modification Reason: Deleted requirement to be compliant with 3GPP specification (MR=19742). Owner: Andrew McClurg, A.T.Remoquillo Keyword: Billing and Charging <End of R-FSD19337.2-6030V1.03>
14 Performance Requirements
The UMTS MSC based on the Lucent SoftSwitch (LSS) platform is required to support 360,000 busy hour calls. In addition, the expectation is that 100% of the subscribers will be CAMEL (or Intelligent Network) subscribers. CAMEL processing requires real time, and thus the baseline capacity of the UMTS MSC without CAMEL must be higher than 360K BHCA.
15 Appendix 1: Calling Hierarchies in CAMEL Standards

The following figures show the calling hierarchies for originations, terminations and call forwarding for the processes and procedures in 23.018 that are affected by CAMEL and for the processes and procedures in 03.78.
Page:
Issue: 4 126
CAMEL Originations
C A M E L _ O C H _M S C _ A N S W E R
O G _ C A L L _ S E T U P_ M S C
C A M E L _O C H _M S C _ D IS C 1
C A M E L _ O C H _ M S C _ D IS C 2
C A M E L _ O C H _ M S C _ IN IT
S E N D _ A C C E S S _ C O L L E C T _ IF _ R E Q U IR E D
S E N D _ A L E R T IN G _ IF _ R E Q U IR E D
C A M EL _OC H _C TR
C A M E L _O C H _ E T C C A M E L _ O C H _M S C 1
CAM EL OCH M SC2 C A M E L _ O C H _ M S C _ D IS C 3 ( C A M E L p h a se 1 o n ly )
C A M E L _ S ta rt _ T N R y C A M E L _ O C H _M S C _ D IS C 4
C A M E L _ S to p _ T N R y
Page:
Issue: 4 127
CAMEL Terminations
IN CCF
CAMEL_MT_GMSC_ANSWER MT_GMSC CAMEL_MT_GMSC_DISC1 CAMEL_SET_ORA _PARAMETERS CAMEL_MT_GMSC_DISC2 CAMEL_MT_GMSC_INIT Obtain_Routeing _Address
SEND_ACM_IF_REQUIRED
SEND_NETWORK_ CONNECT_IF_REQ UIRED SEND_ANSWER_I F_REQUIRED CAMEL_MT_CTR
CAMEL_MT_ETC CAMEL_MT_GMSC_DISC5
CAMEL_MT_GMSC_DISC3
(CAMEL Phase 1 only)
CAMEL_MT_GMSC_DISC4 CAMEL_MT_GMSC_ NOTIFY_CF CAMEL_Start_TNRy CAMEL_MT_GMSC_DISC6
CAMEL_Stop_TNRy
Page:
Issue: 4 128
Call Forwarding
CAMEL_CF_MSC_ANSWER MT_CF_MSC CAMEL_OCH_MSC_DISC1
CAMEL_OCH_MSC_DISC2
CAMEL_CF_MSC_INIT
SEND_ACM_IF_REQUIRED
SEND_NETWORK_ CONNECT_IF_REQ UIRED CAMEL_CF_CTR
CAMEL_CF_ETC
SEND_ANSWER_IF _REQUIRED
CAMEL_OCH_MSC_DISC3
Not defined in 03.78?,
CAMEL_OCH_MSC_DISC4*
CAMEL_Start_TNRy
CAMEL_Stop_TNRy
Page:
Issue: 4 129
16 Appendix 2: Algorithm for handling CAMEL data received at the GMSC

The following section applies to 03.78 procedure CAMEL_MT_GMSC_INIT. The algorithm below indicates what actions are performed when various combinations of CAMEL subscription information and/or forwarding data is received by the GMSC in a SendRoutingInformation result sent from the HLR. T-CSI: IF CAP_Connect with modified number Use CAMEL Modified Number ELSE IF CAP_Connect with unmodified number Store any modified call data (e.g., additional calling party number) nd Use original called party number (2 SendRoutingInfo sent to HLR) ELSE IF CAP_Continue nd Use original called party number (2 SendRoutingInfo sent to HLR) ENDIF T-CSI and O-CSI: IF CAP_Connect with modified number IF O-CSI applicable present and Redirecting Information present nd Treat CMN as forward to number (FTN) and launch 2 query to the gsmSCF indicated in O-CSI ELSE Use CMN ENDIF ELSE IF CAP_Connect with unmodified number Store any modified call data (e.g., additional calling party number) nd Use original called party number (2 SendRoutingInfo sent to HLR) ELSE IF CAP_Continue nd Use original called party number (2 SendRoutingInfo sent to HLR) ENDIF T-CSI & FTN: IF CAP_Connect with modified number Use CMN ELSE IF CAP_Connect with unmodified number Use forward to number ELSE IF CAP_Continue Use forward to number ENDIF T-CSI & O-CSI & FTN: IF CAP_Connect with modified number IF O-CSI applicable present and Redirecting Information present nd Use CMN like FTN and launch 2 query to the gsmSCF indicated in OCSI ELSE Use CMN ENDIF ELSE IF CAP_Connect with unmodified number nd Use forward to number to launch 2 query to the gsmSCF indicated in O-CSI ELSE IF Continue nd Use forward to number to launch 2 query to the gsmSCF indicated in O-CSI ENDIF QDI ID: 19337 Date: November 18, 2002 Author: Marianne Picha Lucent Technologies - Proprietary Issue: 4 130
Page:
O-CSI & FTN (received in either 1st or 2nd SendRoutingInfo result): Use forward to number to launch query to the gsmSCF indicated in O-CSI
Page:
Issue: 4 131

Camel For UMTS

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Camel For UMTS

Enviado por

Direitos autorais:

Formatos disponíveis

Requirements Document

UMTS-MSC R1V2 CAMEL

4.0 Marianne Picha (version 3.0,4.0) Andrew McClurg Akhil Khare

Marianne Picha November 18, 2002

CAMEL ARCHITECTURE SCENARIOS

QDI ID: 19337 Date: November 18, 2002

QDI ID: 19337 Date: November 18, 2002

Global Title Translation

Terminating Call Processing

Trigger Detection Points......................................................................................................... 6066 Multiple control relationships ................................................................................................. 6167

Interworking with Supplementary Services

MAP and CCF Interworking

6571 6571 6672

Event Detection Points

8.4.4.1 8.4.4.2 8.4.4.3 8.4.4.4

Announcement Session Operations and Results

QDI ID: 19337 Date: November 18, 2002

Announcement and digit collection: intermediate states

8.4.7.1 8.4.7.2 8.4.7.3 8.4.7.4 8.4.7.5 8.4.7.6

Billing and Information request operations

QDI ID: 19337 Date: November 18, 2002

Author: Marianne Picha Lucent Technologies - Proprietary

CAP and ISUP Interworking CAP and RANAP Interworking

INTERNAL ANNOUNCEMENT INTERFACE BILLING REQUIREMENTS

APPENDIX 1: CALLING HIERARCHIES IN CAMEL STANDARDS 126133

QDI ID: 19337 Date: November 18, 2002

Author: Marianne Picha Lucent Technologies - Proprietary

Requirement text Notes:

References: Owner: Keyword:

History / Change Record

Issue.Version Draft 1.0 Accepted 1.0 Accepted 2.0

Version 3.0 Version 4.0

M.Picha M.Picha, A.Remoquillo

All (tagged v1.01) Tagged v1.02 Tagged v1.03

Benchmark Definition FSD Initiated

QDI ID: 19337 Date: November 18, 2002

Author: Marianne Picha Lucent Technologies - Proprietary

Original Estimated Date

Updated Estimated Date

Implementation Decision Record

Relation to Other Features

QDI ID: 19337 Date: November 18, 2002

Author: Marianne Picha Lucent Technologies - Proprietary

1.10 Glossary of Terms & Abbreviations 1.10.1 Standard Terms

1.10.2 Standard Acronyms

QDI ID: 19337 Date: November 18, 2002

QDI ID: 19337 Date: November 18, 2002

1.10.3 Lucent Acronyms

QDI ID: 19337 Date: November 18, 2002

Multimedia Resource Server

SRD SSP TAG TC TPU WAG WSG

Logical Functionality within the MSC

Author: Marianne Picha Lucent Technologies - Proprietary

Message Error Handling

Notes for Feature Testers

QDI ID: 19337 Date: November 18, 2002

Author: Marianne Picha Lucent Technologies - Proprietary

The following figure illustrates the overall CAMEL architecture.

HLR record CAMEL info

MO Call: Outgoing Leg

Scenarios Relation between external and internal messages

Originating Call Scenarios

4.2.1 Sunny Day Call: A-party disconnect