Camel for UMTS

Author: Marianne Picha Accepted QDI ID: 19337 Issue: 4 Date: November 18, 2002 Lucent Technologies - Proprietary

Use pursuant to Company Instructions

Page: 1

Requirements Document

Feature Title: UMTS-MSC R1V2 CAMEL

Issue.Version: 4.0

Authors: Marianne Picha (version 3.0,4.0)

Andrew McClurg

Akhil Khare

QDI ID: 19337 Author: Marianne Picha Issue: 4 Date: November 18, 2002 Lucent Technologies - Proprietary Page: 2

TABLE OF CONTENTS

1 FEATURE DESCRIPTION 814

1.1 Scope 814

1.2 Guide to Requirements 814

1.3 History / Change Record 814

1.4 Benchmark Dates 814

1.5 Open Issues 915

1.6 Implementation Decision Record 915

1.7 Competitive Information 915

1.8 Relation to Other Features 915

1.9 Acknowledgements 915

1.10 Glossary of Terms & Abbreviations 1016 1.10.1 Standard Terms 1016 1.10.2 Standard Acronyms 1016 1.10.3 Lucent Acronyms 1218

2 OVERVIEW 1319

2.1 Scope 1319

2.2 Logical Functionality within the MSC 1319

2.3 Intra-MSC Messaging 1319

2.4 Intra-MSC States 1319

2.5 Message Error Handling 1420

2.6 Notes for Feature Testers 1420

3 CAMEL ARCHITECTURE 1521

4 SCENARIOS 1521

4.1 Relation between external and internal messages 1521


4.2 Originating Call Scenarios 1521 4.2.1 Sunny Day Call: A-party disconnect 1521 4.2.2 Warning Tone Played - A-party disconnect 1723 4.2.3 Interval Timer Expires 1824 4.2.4 Two Apply Charging Operations 1925 4.2.5 Switch Based Announcement Prior to Call Completion 2026 4.2.6 IP Based Announcement Prior to Call Completion 2127 4.2.7 IP based announcement prior to call to busy B-party 2127

4.3 Terminating Call Scenarios 2228 4.3.1 Basic Mobile Termination with CAMEL 2228 4.3.2 Termination with gsmSCF Modified Number 2430 4.3.3 Mobile Termination with Unmodified Number 2531

4.4 Call Forwarding Call Scenarios 2531 4.4.1 GSM Call Forwarding Unconditional at GMSC 2632 4.4.2 Termination with GSM Call Forwarding on Mobile Not Reachable at GMSC 2733 4.4.3 CAMEL Call Forwarding 2935 4.4.4 GSM Call Forwarding at the VMSC 3036

5 CAMEL STANDARDS 3036

5.1 Standards Documents 3036

5.2 Roadmap to CAMEL Stage 2 3137 5.2.1 Processes and Procedures for Originating Calls 3137 5.2.2 Processes and Procedures for Terminating and Forwarded Calls 3238

5.3 CAMEL Standards and FSD Requirements 3339

5.4 Call Control Function State Machine 3339

5.5 Service Switching Function State Machine 3339

6 VLR REQUIREMENTS 3339

6.1 CAMEL Subscriber Data 3339

7 MSC DATA 3440

7.1 Incoming roaming restrictions for CAMEL subscribers 3440

7.2 Location Numbers 3440

7.3 CAMEL phase supported 3541

7.4 Network Operator Specific parameters 3541

7.5 Announcement identifiers for internal gsmSRF 3642


7.6 Global Title Translation 3743

8 MSC REQUIREMENTS 3743

8.1 Digit Analysis 3743

8.2 Emergency Calls 3743

8.3 Call Control Function (CCF) 3743 8.3.1 Triggering a gsmSCF Interaction 3844 8.3.2 Originating Call Processing 3844 8.3.3 Terminating Call Processing 4551 8.3.4 Call Forwarding Call Processing 5359 8.3.5 Connecting to Assisting SSPs and IPs 6066 8.3.6 Interworking with other Intelligent Network features 6066

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

8.3.7 Interworking with Supplementary Services 6167 8.3.7.1 Calling Line Identification Presentation (CLIP)....................................................................... 6268 8.3.7.2 Calling Line Identification Restriction (CLIR)......................................................................... 6268 8.3.7.3 Connected Line Identity Presentation (COLP)......................................................................... 6268 8.3.7.4 Call Forwarding ..................................................................................................................... 6268 8.3.7.5 Call Hold ............................................................................................................................... 6369 8.3.7.6 Call Waiting........................................................................................................................... 6369 8.3.7.7 Multi Party............................................................................................................................. 6369 8.3.7.8 Closed User Group (CUG)...................................................................................................... 6369 8.3.7.9 Mobile Number Portability (MNP) ......................................................................................... 6470 8.3.7.10 Advice of Charge (AoC)..................................................................................................... 6470 8.3.7.11 Call Barring....................................................................................................................... 6470 8.3.7.12 Interactions with Lucent proprietary features....................................................................... 6470

8.3.8 MAP and CCF Interworking 6571 8.3.8.1 Receipt of ProvideSubscriberInfo operation ............................................................................ 6571 8.3.8.2 R-FSD19337.2-V1>R-FSD19337.2-V1>Receipt of Suppression of Announcement parameter.. 6571

8.4 Service Switching Function (SSF or gsmSSF) 6571 8.4.1 InitialDP Sent to the SCP 6571 8.4.2 Receiving SCP Call Handling Instructions 6672

8.4.2.1 Receipt of CAP Continue operation ........................................................................................ 6773 8.4.2.2 Receipt of Connect operation.................................................................................................. 6773 8.4.2.3 Receipt of ResetTimer operation............................................................................................. 6874 8.4.2.4 Expiration of SSF guard timer (Tssf)....................................................................................... 6874

8.4.3 Event Detection Points 6975 8.4.3.1 Receipt of RequestReportBCSMEvent.................................................................................... 6975 8.4.3.2 Receipt of Cancel operation for pending EDPs and reports ...................................................... 7076

8.4.4 Call Termination 7076 8.4.4.1 Receipt of ReleaseCall operation ............................................................................................ 7076 8.4.4.2 Call termination due to internal error....................................................................................... 7177 8.4.4.3 Disconnect from A or B party................................................................................................. 7177 8.4.4.4 Caller Abandon...................................................................................................................... 7278

8.4.5 Announcement Session Operations and Results 7379


8.4.5.1 Announcement Configurations................................................................................................ 7379 8.4.5.2 Contacting an assisting gsmSSF.............................................................................................. 7379 8.4.5.3 Triggering on an assisting gsmSSF ......................................................................................... 7480 8.4.5.4 The gsmSSF state machine and the gsmSRF ........................................................................... 7480 8.4.5.5 Receipt of EstablishTemporaryConnection operation............................................................... 7581 8.4.5.6 Receipt of DisconnectForwardConnection............................................................................... 7581 8.4.5.7 Receipt of ConnectToResource............................................................................................... 7682 8.4.5.8 Receipt of PlayAnnouncement................................................................................................ 7682 8.4.5.9 Receipt of PromptAndCollectUserInformation ........................................................................ 7682 8.4.5.10 Receipt of Cancel operation for announcement sessions ...................................................... 7783 8.4.5.11 Sending CAP Canceled error .............................................................................................. 7884 8.4.5.12 Sending CAP Cancel Failed error ....................................................................................... 7884 8.4.5.13 Sending PromptAndCollectUserInformation result .............................................................. 7985 8.4.5.14 Sending SpecializedResourceReport ................................................................................... 7985 8.4.5.15 Expiration of Tssf timer during announcement session ........................................................ 8086

8.4.6 Announcement and digit collection: intermediate states 8086 8.4.6.1 Connection establishment to IP or Assisting SSP..................................................................... 8086 8.4.6.2 Connection establishment from internal SRF........................................................................... 8187 8.4.6.3 Connection release to internal SRF ......................................................................................... 8288 8.4.6.4 Release of Temporary Connection from Call Control............................................................... 8288 8.4.6.5 Announcement session: miscellaneous.................................................................................... 8389

8.4.7 Monitoring State 8591 8.4.7.1 Receipt of RequestReportBCSMEvent.................................................................................... 8591 8.4.7.2 Disconnect or Abandon .......................................................................................................... 8692 8.4.7.3 Timer Expiration.................................................................................................................... 8692 8.4.7.4 Receipt of CAP Cancel for pending EDPs and reports ............................................................. 8894 8.4.7.5 Answer event detected............................................................................................................ 8894 8.4.7.6 Pre-answer events detected ..................................................................................................... 8995

8.4.8 Billing and Information request operations 9096 8.4.8.1 Receipt of ApplyCharging operation....................................................................................... 9096 8.4.8.2 Receipt of SendChargingInformation operation....................................................................... 9096 8.4.8.3 Receipt of FurnishChargingInformation operation................................................................... 9197 8.4.8.4 Receipt of CallInformationRequest operation .......................................................................... 9197

9 ASSISTING MSC 9298

9.1 Assisting Call Control State Machine 9298 9.1.1 Receipt of Initial Request from Initiating MSC 9298 9.1.2 Awaiting Instructions on Announcement Sessions 9399

9.2 Process Assisting_gsmSSF 96102 9.2.1 Requesting Instructions from the gsmSCF 96102 9.2.2 gsmSCF Instructions 96102

9.2.2.1 Receipt of ResetTimer operation............................................................................................97103 9.2.2.2 Receipt of ConnectToResource operation...............................................................................97103 9.2.2.3 Receipt of DisconnectForwardConnection operation ..............................................................98104 9.2.2.4 Receipt of PlayAnnouncement operation................................................................................99105 9.2.2.5 Receipt of PromptAndCollectUserInformation operation........................................................99105 9.2.2.6 Receipt of Cancel operation for announcement sessions........................................................100106 9.2.2.7 Sending PromptAndCollectUserInformation result ...............................................................101107


9.2.2.8 Sending SpecializedResourceReport ....................................................................................101107 9.2.2.9 Expiration of Tssf timer during announcement session .........................................................102108

10 MAP REQUIREMENTS 103109

10.1 HLR !!!!"""" VLR Information Flows 103109 10.1.1 MAP ProvideSubscriberInfo operation 103109 10.1.2 MAP Insert Subscriber Data operation 104110 10.1.3 Map DeleteSubscriberData operation 104110 10.1.4 Map UpdateLocation operation 105111 10.1.5 Map RestoreData operation 105111 10.1.6 Map ProvideRoamingNumber operation 105111

10.2 HLR !!!!"""" GMSC Information Flows 106112 10.2.1 MAP SendRoutingInfo operation 106112

10.3 VMSC !!!!"""" GMSC Information Flows 107113 10.3.1 MAP ResumeCallHandling operation 107113

10.4 MSC to gsmSCF Information Flows 108114

11 CAP REQUIREMENTS 108114

11.1 CAP Application Contexts 108114

11.2 CAP Operations 109115 11.2.1 CAP ActivityTest operation 109115 11.2.2 CAP ApplyCharging operation 109115 11.2.3 CAP ApplyChargingReport operation 110116 11.2.4 CAP AssistRequestInstructions operation 110116 11.2.5 CAP CallInformationReport operation 110116 11.2.6 CAP CallInformationRequest operation 111117 11.2.7 CAP Cancel operation 111117 11.2.8 CAP Connect operation 111117 11.2.9 CAP ConnectToResource operation 112118 11.2.10 CAP Continue operation 112118 11.2.11 CAP DisconnectForwardConnection operation 113119 11.2.12 CAP EstablishTemporaryConnection operation 113119 11.2.13 CAP EventReportBCSM operation 114120 11.2.14 CAP FurnishChargingInformation operation 114120 11.2.15 CAP InitialDP operation 115121 11.2.16 CAP ReleaseCall operation 115121 11.2.17 CAP RequestReportBCSMEvent operation 116122 11.2.18 CAP ResetTimer operation 116122 11.2.19 CAP SendChargingInformation operation 116122 11.2.20 CAP PlayAnnouncement operation 117123 11.2.21 CAP PromptAndCollectUserInformation operation 118124 11.2.22 CAP SpecializedResourceReport operation 119125 11.2.23 Operation Timers 119125


11.3 CAP and ISUP Interworking 120126

11.4 CAP and RANAP Interworking 120126

12 INTERNAL ANNOUNCEMENT INTERFACE 121127

13 BILLING REQUIREMENTS 121127

13.1 Mobile Origination Call Record 121127

13.2 Mobile Originated Call Forwarding Call Record 122128

13.3 Terminating CAMEL Call Record 124130

14 PERFORMANCE REQUIREMENTS 126133

15 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 152 FIGURE 2 - SUNNY DAY CALL WITH A PARTY DISCONNECT 162 FIGURE 3 - WARNING TONE PLAYS 172 FIGURE 4 - INTERVAL TIMER EXPIRES, CALL IS DISCONNECTED 182 FIGURE 5 - TWO APPLY CHARGING OPERATIONS 192 FIGURE 6 - SWITCH BASED ANNOUNCEMENT 202 FIGURE 7 - IP BASED ANNOUNCEMENT 212 FIGURE 8 - MOBILE TERMINATION WITH CAMEL AND ANY TIME INTERROGATION 232 FIGURE 9 - TERMINATION WITH GSMSCF MODIFIED NUMBER 242 FIGURE 10 - TERMINATION WITH UNMODIFIED NUMBER 252 FIGURE 11 - CALL FORWARDING UNCONDITIONAL 262 FIGURE 12 - CALL FORWARDING ON MOBILE STATION NOT REACHABLE (PART 1) 272 FIGURE 13 - CALL FORWARDING ON MOBILE STATION NOT REACHABLE (PART 2) 282 FIGURE 14 - CAMEL CALL FORWARDING 292 FIGURE 15 - CALL FORWARDING AT THE VMSC FOR A CAMEL SUBSCRIBER 302 FIGURE 16 - VLR PROCESSING STRUCTURE IN CAMEL SPEC 03.78 402 FIGURE 17 - TERMINATING ARCHITECTURE 462 FIGURE 18 - CALL FORWARDING STRUCTURE IN CAMEL SPEC 03.78 542


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.

Requirement text Bold text specifying the requirement Notes: Notes sections contains information for

reference, but is not a normative part of the requirement.

References: used to reference the inputs used for

this requirement Owner: owner/author of the requirement Keyword: used to provide a keyword describing

the functional area of the requirement.

1.3 History / Change Record Issue.Version Date Author Chapte

r Change Description

Draft 1.0 20-oct-00 A. McClurg Initial version Accepted 1.0 22-Nov-00 A. McClurg Review comments incorporated Accepted 2.0 18-oct-01 M.Picha All

(tagged v1.01)

MRs 17711, 17718, 17719, 17729, 17783, 17799

Version 3.0 20-feb-02 M.Picha Tagged v1.02

MRs 17861, 17951, 17999, 18117 (IMR 747756)

Version 4.0 M.Picha, A.Remoquillo

Tagged v1.03

MRs 19163, 19627, 19628, 19740, 19742, 19737

1.4 Benchmark Dates

Benchmark Definition Original

Estimated Date Updated

Estimated Date Actual Date Comments

FSD Initiated


Benchmark Definition

Original Estimated Date

Updated Estimated Date

Actual Date Comments

Champion Assigned FDT Assigned

Critical Reviewers Assigned

Draft Available Review (desktop) Draft 2 Available

Review Ready for Approval

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.


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 3G is used to reference the UMTS network. A 3G MSC is the UMTS Mobile

Switching Center with functionality as described by 3GPP standards. 3G MSC 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/VLR 3G MSC which also provides Visiting Location Register (VLR) functionality. 3G SGSN Third Generation SGSN describes the UMTS Serving GPRS Support Node

that is responsible for Mobility Management, Services, and Session Management for packet data services.

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 Second Generation network (GSM) 3G Third Generation network (UMTS) 3GPP Third Generation Partnership Project (a 3G standards organization) ACM ISUP Address Complete Message AMR Adaptive Multi Rate ANM ISUP Answer Message ATM Asynchronous Transfer Mode AuC Authentication Center BCI Backward Call Indicator BICC Bearer Independent Connection Control CAMEL Customer Application for Mobile network Enhanced Logic CDMA Code Division Multiple Access CCBS Call Completion to Busy Subscriber CIS Call Intercept System CFB Call Forwarding Busy CFNRc Call Forwarding Not Reachable CFNRy Call Forwarding No Reply CFU Call Forwarding Unconditional CLI Calling Line Identity


CLIP Calling Line Identity Presentation CLIR Calling Line Identity Presentation Restriction COLP Connected Line Identity Presentation COLR Connected Line Identity Presentation Restriction CSE CAMEL Service Environment (logical Service Control Point) DNS Domain Name Server EIR Equipment Identity Register ETSI European Telecommunications Standards Institute FCAP Fault, Configuration, Accounting, Performance FTP File Transfer Protocol GGSN Gateway GPRS Support Node GPRS Generalize Packet Radio Services GSM Global System for Mobile Communications gsmSCF CAMEL Service Control Function gsmSRF CAMEL Specialized Resource Function gsmSSF CAMEL Service Switching Function HLR Home Location Register IAM ISUP Initial Address Message IMSI International Mobile Station Identification IMUI International Mobile User Identification IN Intelligent Network INAP Intelligent Networking Application Part IP Internet Protocol IP Intelligent Peripheral ISDN Integrated Services Digital Network Iu Interface between the UTRAN and the Core Network IWF Inter-working Function LA Location Area LAC Local Area Code LAI Location Area Identification LCS Location Services LM Location Management MAP Mobile Application Part MM Mobility Management MO Mobile Origination MS Mobile Station MSC Mobile Switching Center MT Mobile Termination OAM Operation, Administration and Maintenance OAM&P Operation, Administration, Maintenance & Provisioning NNI Network to Network Interface OMC Operations Management Center OSA Open Services Architecture PCM Pulse Code Modulation PLMN Public Land Mobile Network PS Packet Switched PSPDN Packet Switched Public Data Network PSTN Public Switched Telephone Network PVC Permanent Virtual Circuit QoS Quality of Service RAB Radio Access Bearer RANAP Radio Access Network Application Part RNC Radio Network Controller RNS Radio Network System


RNTI Radio Network Temporary Identifier RRC Radio Resource Control RTCP Real Time Control Protocol RTP Real Time Protocol SoLSA Support of Localized Service Area SSCF Service Specific Convergence Function SSCOP Service Specific Connection Oriented Protocol SCF Service Control Function SCP Service Control Point SGSN Serving GPRS Support Node SMP Service Management Point SMS Service Management System (Lucent SMP) SMS Short Message Service SMSC Short Message Service Center SN Service Node SNMP Simple Network Management Protocol SRF Specialized Resource Function SRNS Serving RNS SS7 Signaling System 7 SSF Service Switching Function SSP Service Switching Point STP Signal Transfer Points TCP Transmission Control Protocol TFTP Trivial File Transfer Protocol TMSI Temporary Mobile Station Identification UCN UMTS Core Network UDI User Data Input UNI User to Network Signaling URA UTRAN Routing Area UTRAN UMTS Terrestrial Radio Access Network VLR Visitor Location Register VMS Voice Messaging Service UE User Equipment, same as MS in GSM UEA UMTS Encryption Algorithm UIA UMTS Integrity Algorithm VLAN Virtual Local Area Network UP User Plane USSD Unstructured Supplementary Service Data

1.10.3 Lucent Acronyms AG Access Gateway AP Adjunct/Application Processor CN Core Network CSP Centralized Services Platform (part of Lucent SoftSwitch) DS Device Server DSI Device Server Interface FS Feature Server IPDC Internet Protocol for Device Control IWU Interworking Unit (same as IWF for data/fax) LMS Lucent Media Server (formerly MMRS) LSS Lucent SoftSwitch MG Media Gateway


MMRS Multimedia Resource Server SRD System Requirements Document SSP SoftSwitch Server Platform TAG Trunk Access Gateway TC Transcoder TPU Traffic Processing Unit WAG Wireless Access Gateway WSG Wireless Signaling Gateway. 2 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:


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.


3 CAMEL Architecture The following figure illustrates the overall CAMEL architecture.

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 Scenarios

4.1 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

HLR

gsmSCF(SCP)

HLR record CAMELinfo

VMSC/VLR gsmSSF

VLR record CAMELinfo

HPLMN

VPLMN

CAPMAP

MAP, etc.

vGateway

MSC

MAP

IncomingCall

ForwardingLeg

RoamingLeg

CAP

MO Call:Outgoing Leg

MAP

MAP


Figure 2 - Sunny day call with A party disconnect

CCF gsmSSF gsmSCF

MSC

ApplyCharging(interval)

SETUP (A)

Continue

Int_DP_O_Disc(A)

Start timer:(Tcp - 30) seconds

Int_Inv_gsmSSF InitialDP (DP2)

Int_ContinueIAM (B)

ANM (B)

REL (B)

ApplyChargingReport

Int_DP_O_Answer

Prearranged End

RRBE(7N, 9A-N, 9B-N)

EventReportBCSM (7-N)

DISCONNECT(A)

EventReportBCSM (9A-N)

CSE

Stop Timer

ACM (B)

CallInformationRequest

CallInformationReport


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.

Figure 3 - Warning Tone Plays

ApplyCharging(interval)

SETUP (A)

Continue

Int_DP_O_Disc(A)

(Tcp - 30) seconds


Int_ContinueIAM (B)ANM (B)

REL (B) ApplyChargingReport

In-band tone(A)

Int_DP_O_Answer

Prearranged End

Int_Apply_Tone



DISCONNECT(A)


Start timer:30 seconds

CCF gsmSSF gsmSCF

MSC CSE

FurnishChargingInfo


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.

Figure 4 - Interval timer expires, call is disconnected

ApplyCharging(intvl, rel=y)

SETUP (A)

Continue

Int_Release

(Tcp - 30) seconds


Int_ContinueIAM (B)ANM (B)

REL (B)

ApplyChargingReport

In-band tone(A)

Int_DP_O_Answer

Prearranged End

Int_Apply_Tone



DISCONNECT(A)

Start timer:30 seconds

Tcp expires, Release = Yes

CCF gsmSSF gsmSCF

MSC CSE


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.

Figure 5 - Two Apply Charging operations

A pplyCharging(intv l, rel=n)

SETU P (A )

Continue

Int_Inv_gsm S SF InitialDP (D P2)

In t_ContinueIA M (B)A NM (B)

REL (B)

A pplyChargingReport

In-band tone(A)

Int_D P_O _An sw er

Prearranged End

Int_A p ply_T one

R RBE(7N , 9A -N , 9B-N )

EventReportBC SM (7-N )

DISCO NN ECT(A)

Start tim er:3 0 second sTcp ex pires, Release = N o

Start tim er: Tcp - 30

A pply ChargingReport

Start tim er:3 0 second sTcp(2) expires, R elease =Y es

Start tim er: Tcp(2) -30

S tart delta tim er

A pplyCharging(intv l(2), rel=y)Tcp(2) = Tcp(2) - delta

Int_R elease

In-band tone(A) Int_A pply_T one

CCF gsmSSF gsm SCF

M SC CSE

S top delta tim er


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.

Figure 6 - Switch based announcement

PlayAnnouncement (ID)

SETUP (A) Int_Inv_gsmSSF InitialDP (DP2)

_rt_to_annc

_get_annc_resrc

SpecialisedResourceReport

CCF gsmSSF gsmSCFMSC CSE

ConnectToResource_play_annc(id)

_annc_complete

ApplyCharging(interval)Continue

Int_DP_O_Disc(A)


Int_ContinueIAM (B)

ANM (B)

REL (B)

ApplyChargingReport

Int_DP_O_Answer

Prearranged End


DISCONNECT(A)

EventReportBCSM (9A-N)Stop Timer

ACM (B)




_Annc_Complete

PROGRESS(A)


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.

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

SETUP (A) Int_Inv_gsmSSF InitialDP (DP2)

IAM(IP) _route_to_ip

DisconnectForwardConnection


EstablishTemporaryConnection

_disc_to_ip


Int_DP_O_Disc(A)


Int_ContinueIAM (B)

ANM (B)

REL (B)

ApplyChargingReport

Int_DP_O_Answer

Prearranged End


DISCONNECT(A)

EventReportBCSM (9A-N)Stop Timer

ACM (B)




ANM(IP)

REL(IP)

PROGRESS(A)

CONNECT(A)

FurnishChargingInfo


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.

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.

SETUP (A) Int_Inv_gsmSSF InitialDP

IAM(IP) _route_to_ip

DisconnectForwardConnection


EstablishTemporaryConnection

_disc_to_ip


Int_DP_O_Disc(A)

Int_ContinueIAM (B)

ApplyChargingReport

Int_DP_O_Busy

Prearranged End

DISCONNECT(A)

REL (B)




ANM(IP)

REL(IP)

PROGRESS(A)

CONNECT(A)

CPG (B-party Busy)



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)

GMSC/gsmSSF

gsmSCF_1

VMSC

4.InitialDP

9. ApplyCharging,Continue

HLR

2.SRI(1)

3.SRIAck(T-CSI)

10.SRI(2)

13.SRIAck(MSRN)

14. IAM (MSRN)1.IAM

11: PRN

12: PRN Ack8: ATI Ack5: ATI

6: PSI

7. PSI Ack

(15. ResumeCallHandling*)


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.

Figure 10 - Termination with gsmSCF modified number

Legend: T-CSI = Terminating CAMEL Subscription Information CMN = CAMEL Modified Number, or gsmSCF translated number

CCF gsmSSF VMSCSCPHLRIAMSRI

SRI ack (T-CSI)

InitialDP

Connect(CMN)

IAM

Int_Inv_gsmSSF

Int_Connect


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.

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.

CCF gsmSSF VMSCSCPHLRIAM

SRI(1)

SRI ack (T-CSI)

InitialDP

Continue

IAM (MSRN)

SRI(2)PRN

SRI ack (MSRN)

Int_Inv_gsmSSF

Int_Continue

PRN ack (MSRN)


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.

Figure 12 - Call Forwarding Unconditional and CAMEL

CCF(GMSC) C-ExchangeSCPHLR

IAM SRISRI ack (O-CSI, FTN)

InitialDP (FTN, Forwarding flag, DP2)

IAM

RELEventReportBCSM(7N)

EventReportBCSM(9N-B)

ANM

ApplyChargingReport

RRBE (7N, 9N-A,B)ApplyCharging

Prearrangedend

gsmSSF

Int_DP_O_Answer

Int_DP_O_Disconnect

Int_Inv_gsmSSF

ContinueInt_Continue


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.

Figure 13 - GSM Call Forwarding on Mobile Station Not Reachable (part 1)

CCF(GMSC) VMSCgsmSCFHLR

IAM SRISRI ack (T-CSI)

InitialDP (DP12)

Continue

SRI(suppress T-CSI)PRN

SRI ack (FTN, O-CSI) PRN error (absent subscriber)

ApplyCharging (for termination)RRBE (13N, 14N, 15N, 17N-A,B)

EventReportBCSM(13N, cause = not reachable)

ApplyCharging (for termination)

gsmSSF

Int_Inv_gsmSSF

Int_Continue

Int_DP_T_Busy(CF)

CFNRc

All terminating EDPs except A-Disconnect(17A) are implicitly disarmed


Figure 14 - GSM Call Forwarding on Mobile Station Not Reachable (part 2)

C-ExchSCPHLR

IAM (C)

REL (C)

EventReportBCSM(7N)

EventReportBCSM(9N-B)

ApplyChargingReport(term)Prearranged End

ANM (C)

ApplyChargingReport(CF)

ApplyCharging (for CF leg)RRBE (7N, 9N-A,B)

InitialDP (DP2, FTN, RedirectingNo=C)

gsmSSF

Int_DP_T_Answer

Int_DP_O_Answer

Int_DP_O_Disconnect

Int_DP_T_Disconnect

CCF(GMSC)

Int_Inv_gsmSSF

CFNRc (2)

ContinueInt_Continue


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.

Figure 15 - CAMEL Call Forwarding

CCF(GMSC) C-ExchSCP1HLR

IAMSRI

SRI ack (T-CSI, O-CSI)InitialDP(DP12)

Connect(CMN, redirecting info, O-CSI applicable)

IAM

InitialDP(DP2)

SCP2

RRBE (9N-A,B)ApplyCharging

RELEventReportBCSM(9N-B)ApplyChargingReport

gsmSSF

Int_Inv_gsmSSF

Int_Continue

Int_DP_O_Disconnect

Int_Connect

Int_Inv_gsmSSF

Continue

Prearranged end

Prearranged end

CPG

ANMInt_DP_O_Answer


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.

Figure 16 - GSM Call Forwarding at the VMSC for a CAMEL subscriber 5 CAMEL Standards

5.1 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)

CCF(VMSC) gsmSSF

Voice MailSystemSCPIAM

InitialDP(DP2, FTN, Redirecting Number)

Connect(CMN)

IAM

Int_Inv_gsmSSF

Int_Connect

MSPAGING REQUESTPAGING RESPONSE

No reply from mobileALERTING


# 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 Calling Procedure Name ( In23.018 unless

other document specified) CAMEL_OCH_MSC_INIT OG_CALL_SETUP_MSC* CAMEL_Start_TNRy OCSM CAMEL_Stop_TNRy OCSM CAMEL_OCH_MSC_ANSWER OCSM CAMEL_OCH_MSC1 OCSM CAMEL_OCH_MSC2 OCSM CAMEL_OCH_MSC_DISC1, CAMEL_OCH_MSC_DISC2

OCSM(35), CAMEL_OCH_MSC_ ANSWER(03.78)

CAMEL_OCH_MSC_DISC3 (CAMEL phase 1 only: 03.78)

OCSM

CAMEL_OCH_MSC_DISC4 OCSM CAMEL_OCH_ETC, CAMEL_OCH_CTR

CAMEL_OCH_MSC_INIT (03.78), CAMEL_OCH_MSC1 (03.78), CAMEL_OCH_MSC2 (03.78), CAMEL_OCH_MSC_DISC2 (03.78)

SEND_ALERTING_IF_REQUIRED, SEND_ACCESS_CONNECT_IF_REQUIRED**

CAMEL_OCH_ETC (03.78), CAMEL_OCH_CTR (03.78)

*OCSM(OG_CALL_SETUP_MSC) ** Non CAMEL Procedures defined in 023.018


Name of CAMEL Procedure Calling Procedure Name( Page No. In 23.018 unless other

document specified) CAMEL_OCH_VLR OG_CALL_SUBSCRIPTION_CHECK_VLR Name of CAMEL Process Receives initial input message (Send Info for

Reconnected Call) from: CAMEL_Reconnected_Call_VLR 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

other document specified) CAMEL_SET_ORA_PARAMETERS MT_GMSC CAMEL_Start_TNRy MT_GMSC, MT_CF_MSC CAMEL_Stop_TNRy MT_GMSC, MT_CF_MSC CAMEL_MT_GMSC_INIT Obtain_Routeing_Address CAMEL_MT_GMSC_NOTIFY_CF Obtain_Routeing_Address CAMEL_MT_GMSC_ANSWER MT_GMSC CAMEL_MT_GMSC_DISC1, CAMEL_MT_GMSC_DISC2

MT_GMSC, CAMEL_MT_GMSC_ ANSWER(03.78)

CAMEL_MT_GMSC_DISC3 (CAMEL Phase 1) CAMEL_MT_GMSC_DISC4

MT_GMSC, Obtain_Routeing_Address

CAMEL_MT_GMSC_DISC5 MT_GMSC CAMEL_MT_GMSC_DISC6 MT_GMSC CAMEL_OCH_MSC_DISC3 (CAMEL Phase 1) CAMEL_OCH_MSC_DISC4

MT_CF_MSC,

CAMEL_OCH_MSC_DISC1, CAMEL_OCH_MSC_DISC2

MT_CF_MSC, CAMEL_CF_MSC_ANSWER(03.78)

CAMEL_CF_MSC_INIT MT_CF_MSC CAMEL_CF_MSC_ANSWER MT_CF_MSC CAMEL_OCH_MSC1 MT_CF_MSC CAMEL_OCH_MSC2 MT_CF_MSC CAMEL_MT_ETC, CAMEL_MT_CTR

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_ETC, CAMEL_CF_CTR

CAMEL_CF_MSC_INIT(03.78)

CAMEL_Check_ORLCF_VMSC ICH_MSC SEND_ANSWER_IF_REQUIRED** CAMEL_MT_ETC(03.78),

CAMEL_CF_ETC(03.78) SEND_NETWORK_CONNECT_IF_REQUIRED** CAMEL_MT_ETC(03.78),

CAMEL_MT_CTR(03.78), CAMEL_CF_ETC(03.78), CAMEL_CF_CTR(03.78)

SEND_ACM_IF_REQUIRED** 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)


**Non CAMEL procedure Name of CAMEL Procedure Calling Procedure Name(In 23.018 unless other

document specified) CAMEL_SET_SOA 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 VLR Requirements

6.1 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


<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 MSC Data

7.1 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 subscriber’s 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>


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.


☞☞☞☞ <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.


Modification Reason: Added new as v1.02 to specify needed tone mapping (mr=17951) Owner: mpicha Keyword: Operations and Maintenance


<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 MSC requirements

8.1 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


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.


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.


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.


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).

OG_Call_Setup_MSC

CAMEL_OCH_MSC_INIT

OCH_VLR

OG_Call_Subscription_Check_VLR

CAMEL_OCH_VLR

Send Info ForOutgoing Call

Complete Call

gsmSSF

CAPConnect/Continue

Int_Connect/ Int_Continue

Send Info ForOutgoing Call

Complete Call

Int_Invoke_gsmSSF

CAPInitialDP

Pass

PassPass

Perform outgoing call barring checks

IAM


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:


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:


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,


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,


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>


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,


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)


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.


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)

GMSCCCF/SSF

gsmSCF

VMSCCCF/SSF

HLRMAP

MAPCAP, MAP

MAP

ISUP, TUP,...


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.


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.


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.


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).


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


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


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).


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


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>


☞☞☞☞ <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>


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:


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.


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

IdleProcess MT_GMSC

IdleProcess MT_CF_MSC

Obtain_Routing_Address

Forward

CAMEL_MT_GMSC_INITCAMEL_FTN

Activate_CF_Process

Perform Call Forwarding

CAMEL_CF_MSC_INIT

PASSPASS

Perform Call Forwarding Ack

Wait For IAM

Wait For Forward ACM

Internal IAM IAM

Wait For ACM

IAM

GSM_FTNPASS

ACMACMWait For Forward

AnswerWait For Answer

Internal ACM

Etc... Etc...


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.


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.


Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF <End of R-FSD19337.2-610V1>


☞☞☞☞ <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).


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).


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


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).


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.


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)


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).


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.


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.


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 ☞☞☞☞ <R-FSD19337.2-740V1.01>


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.


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.


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 e-values shall take precedence over any e-values generated by standard GSM Advice of Charge.

8.3.7.11 Call Barring

8.3.7.12 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.


Modification Reason: In version 1.01, modified references (mr=17711). Owner: Andrew McClurg Keyword: CCF


<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


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


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.


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


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".


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


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


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.


2. Procedure Complete_all_FCI_records is called. References: 03.78; 09.78 Feature ID: 50.100


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, T-Busy, T-NoAnswer, and T-Answer.

# The "legID" parameter shall always be included for the events O-Disconnect and T-Disconnect. 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



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


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 non-

control relationship.

References: ETSI GSM 03.78; 09.78 Feature ID: 50.100

Modification Reason: In version 1.01, modified references (mr=17711).


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.


• 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


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



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.


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.


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.



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.


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



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


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.


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


8.4.5.10 Receipt of Cancel operation for announcement sessions ☞☞☞☞ <R-FSD19337.2-1250V1.01>


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


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:


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.



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


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



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


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:


# 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:


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


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


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


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


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


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.


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.


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.



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.


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).


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.


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> 9 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>


☞☞☞☞ <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


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.


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>


☞☞☞☞ <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)


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 Process Assisting_gsmSSF

9.2.1 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


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:


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


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



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


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.


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


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


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).


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.



☞☞☞☞ <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.


Next state: Waiting_For_End_Of_User_Interaction Notes:

1. The PlayAnnouncement parameter is called "requestAnnouncementComplete". See 09.78.


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>


☞☞☞☞ <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.


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 ☞☞☞☞ <R-FSD19337.2-3020V1.01>


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


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>


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>


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 SS-InvocationNotification 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:


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 CAMEL-AChBillingChargingCharacteristics. 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.


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.


Notes: This operation sends call related information to the gsmSCF previously requested via a CallInformationRequest operation.


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. .


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


11.2.8 CAP Connect operation ☞☞☞☞ <R-FSD19337.2-4150V1.03> The CAP Connect operation will be supported as per ETSI 09.78.


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. .


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. .



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. .


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


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. .


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:

8 7 6 5 4 3 2 1 1 Spare FUB ind. Dest. ind Orig. ind. Dial. ind. AC/DC

ind. ABN ind Annc

2 Spare 3 Billing Data (CPS, SIC, BOP, Documentation Type) 4 Announcement Units (optional) 5 Length of Alternate Billing Number (optional) 6 Alternate Billing Number (optional) 7 Length of Account/Department Code (optional) 8 Account/Department Code (optional) 9 Length of Dialed Number (optional)

10 Dialed Number (optional) 11 Length of Originating Number (optional) 12 Originating Number (optional)


13 Length of Destination Number (optional) 14 Destination Number (optional) 15 Usage count 3 Usage count 2 Usage count 1 spare overflow 16 Usage count 7 Usage count 6 Usage count 5 Usage count 4 17 Usage count 11 Usage count 10 Usage count 9 Usage count 8 18 Usage count 15 Usage count 14 Usage count 13 Usage count 12 19 Usage count 19 Usage count 18 Usage count 17 Usage count 16 20 Usage count 23 Usage count 22 Usage count 21 Usage count 20 21 Usage count 27 Usage count 26 Usage count 25 Usage count 24 22 Usage count 31 Usage count 30 Usage count 29 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. .


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


11.2.16 CAP ReleaseCall operation ☞☞☞☞ <R-FSD19337.2-4220V1.01> The CAP ReleaseCall operation will be supported as per ETSI 09.78.


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.


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.


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.


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.


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



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


is set to “FALSE” then the announcement will play to completion while digits may be collected at the same time.

8. 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).

9. The first received digit that interrupts an announcement may be valid or invalid, and will be processed accordingly.

10. The start digit may be any one or two digit string, as per 09.78. 11. 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.

12. It makes little sense from a service perspective to have an end of reply or cancel digit as a regular number (0-9).

13. 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


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:


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.


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>


Field Description

Translated Number O The called number after digit translation within the MSC (if applicable) gsmSCF address C Identifies the CAMEL server serving the subscriber. Service key C The CAMEL service logic to be applied. Network call reference C An identifier to correlate transactions on the same call taking place in different

network nodes, shall be present if CAMEL is applied. MSC Address C This field contains the E.164 number assigned to the MSC that generated the

network call reference. Default call handling O 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 of DP encountered

O Number that counts how often armed detection points (TDP and EDP) were encountered.

Level of CAMEL service O Indicator for the complexity of the CAMEL feature used. Free format Data C 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.

CAMEL call leg information

C Set of CAMEL information IEs. Each of these IEs contains information related to one outgoing CAMEL call leg.

Free format data append indicator

C Indicator if free format data from this CDR is to be appended to free format data in previous partial CDR.

Default call handling 2 O 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.

GsmSCF address 2 C Identifies the CAMEL server serving the subscriber for 2nd service such as dialled service.

Service key 2 C The CAMEL service logic to be applied for 2nd service such as dialled service. Free format Data 2 C 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.

Free format data append indicator 2

C Indicator if free format data for 2nd service from this CDR is to be appended to free format data in previous partial CDR.

SCP translated number M This is not in 32.005 but is added for this requirements document.

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


- 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>


Field Description gsmSCF address C Identifies the CAMEL server serving the subscriber. Service key C The CAMEL service logic to be applied. Network call reference C An identifier to correlate transactions on the same call taking place in different

network nodes, shall be present if CAMEL is applied. MSC Address C This field contains the E.164 number assigned to the MSC that generated the

network call reference. CAMEL initiated CF indicator C Indicates that the CAMEL server initiated call forwarding. Default call handling O 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 of DP encountered O Number that counts how often armed detection points (TDP and EDP) were

encountered. Level of CAMEL service O Indicator of the complexity of the CAMEL feature used. Free format Data C 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.

CAMEL call leg information C Set of CAMEL information IEs. Each of these IEs contains information related to one outgoing CAMEL call leg.

Free format data append indicator

C Indicator if free format data from this CDR is to be appended to free format data in previous partial CDR.

Default call handling 2 O 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.

GsmSCF address 2 C Identifies the CAMEL server serving the subscriber for 2nd service such as dialled service.

Service key 2 C The CAMEL service logic to be applied for 2nd service such as dialled service. Free format Data 2 C 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.

Free format data append indicator 2

C Indicator if free format data for 2nd service from this CDR is to be appended to free format data in previous partial CDR.

SCP translated number M This is not in 32.005 but is added for this requirements document. NAOliInfo C Added as a Lucent extension for the Carrier Select feature. This field contains

the North America Originating Line Information received from the gsmSCF. NAChargeNumber C 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


- 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 Description Record Type M Terminating CAMEL interrogation. Served IMSI M IMSI of the called party Served MSISDN O The MSISDN of the called party. Recording Entity M The E.164 number of the GMSC. Int. time stamp M Time at which the interrogation was invoked. CAMEL Destination Number

M The number available for routing after the CAMEL server enquiry.

gsmSCF Address M The CAMEL server serving the subscriber. Service key M The CAMEL service logic to be applied. Network call reference M An identifier to correlate transactions on the same call taking place in different

network nodes, shall be present if CAMEL is applied. MSC Address M This field contains the E.164 number assigned to the MSC that generated the

network call reference. Default call handling O Indicates whether or not a CAMEL call encountered default call handling. This

field shall be present only if default call handling has been applied. Record extensions O A set of network/ manufacturer specific extensions to the record. Called Number M The address of the called party as received by the GMSC/gsmSSF. Calling Number C The address of the calling party, if available. Incoming TKGP O The GMSC trunk group on which the call originated. Outgoing TKGP O The trunk group on which the call left the GMSC Event time stamps: C

C O

Seizure of incoming traffic channel (for unsuccessful call attempts) Answer (for successful calls) Release of traffic channel

Call duration M The chargeable duration of the connection for successful calls, the holding time of call attempts.

Data volume C The number of data segments transmitted if available at the GMSC Cause for termination M The reason for the release of the connection. Diagnostics O A more detailed reason for the release of the connection. Call reference M A local identifier distinguishing between transactions on the same MS Sequence no. C Partial record sequence number, only present in case of partial records. Number of DP encountered

O Number that counts how often armed detection points (TDP and EDP) were encountered.

Level of CAMEL service O Indicator of the complexity of the CAMEL feature used. Free format Data C This field contains data sent by the gsmSCF in the FCI message CAMEL call leg information

C Set of CAMEL information IEs. Each of these IEs contains information related to one outgoing CAMEL call leg.

NAOliInfo C Added as a Lucent extension for the Carrier Select feature. This field contains the North America Originating Line Information received from the gsmSCF.

NAChargeNumber C Added as a Lucent extension for the Carrier Select feature. This field contains the North America Charge Number received from the gsmSCF.

☞☞☞☞ <R-FSD19337.2-6030V1.03> (DELETED)


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.


CAMEL Originations

C A M E L _O C H _M SC _A N SW E R

C A M E L _O C H _M SC _D ISC 1


C A M E L _O C H _M SC _IN IT

C A M E L _O C H _E T C

C A M E L _O C H _C T R

C A M E L O C H M S C 2

C A M E L _O C H _M SC 1

S E N D _A C C E SS _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 E L _S tart_T N R y

C A M E L _S top_T NR y

C A M E L _O C H _M SC _D ISC 3(C A M E L phase 1 on ly )

O G _CA L L _S E T U P_M SC



CAMEL_MT_GMSC_ANSWER

CAMEL_MT_GMSC_DISC1

CAMEL_MT_GMSC_DISC2

CAMEL_MT_GMSC_INIT

CAMEL_MT_ETC

CAMEL_MT_CTR

CAMEL_MT_GMSC_DISC3(CAMEL Phase 1 only)

CAMEL_MT_GMSC_DISC4

CAMEL_MT_GMSC_DISC5

SEND_ACM_IF_REQUIRED

SEND_ANSWER_IF_REQUIRED

CAMEL_Start_TNRy

CAMEL_Stop_TNRy

IN CCF

MT_GMSC

Obtain_Routeing_Address

CAMEL_MT_GMSC_DISC6

CAMEL_SET_ORA_PARAMETERS

SEND_NETWORK_CONNECT_IF_REQ

UIRED

CAMEL_MT_GMSC_NOTIFY_CF

CAMEL Terminations


CAMEL_CF_MSC_ANSWER

CAMEL_OCH_MSC_DISC1

CAMEL_OCH_MSC_DISC2

CAMEL_CF_MSC_INIT

CAMEL_CF_ETC

CAMEL_CF_CTR

CAMEL_OCH_MSC_DISC3Not defined in 03.78?,

CAMEL_OCH_MSC_DISC4*

SEND_ACM_IF_REQUIRED

CAMEL_Start_TNRy

CAMEL_Stop_TNRy

MT_CF_MSC

SEND_NETWORK_CONNECT_IF_REQ

UIRED

SEND_ANSWER_IF_REQUIRED

Call Forwarding


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) Use original called party number (2nd SendRoutingInfo sent to HLR)

ELSE IF CAP_Continue Use original called party number (2nd 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

Treat CMN as forward to number (FTN) and launch 2nd 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) Use original called party number (2nd SendRoutingInfo sent to HLR)

ELSE IF CAP_Continue Use original called party number (2nd 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

Use CMN like FTN and launch 2nd query to the gsmSCF indicated in O-CSI ELSE

Use CMN ENDIF

ELSE IF CAP_Connect with unmodified number Use forward to number to launch 2nd query to the gsmSCF indicated in O-CSI

ELSE IF Continue Use forward to number to launch 2nd query to the gsmSCF indicated in O-CSI

ENDIF


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

Camel for UMTS

Documents

Transcript of Camel for UMTS