7 FIGS Levels 2 and 3

23.0313G Security3GPPFraud Information Gathering System (FIGS)Stage 2Technical realizationTS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

7.1 Method of FIGS Setting

A PLMN shall request that a VPLMN monitor a designated subscriber using FIGS levels 2 or 3 by setting the O-CSI, T-CSI and SS-CSI (level 3 only) flags in the subscriber data stored in the HLR of the HPLMN. This data is drawn down by the VPLMN when the subscriber first registers in the VPLMN.

If the HPLMN wishes to begin monitoring of a subscriber using FIGS Level 2 or 3 when the subscriber is already registered in the VPLMN, it resets the subscriber data in the VPLMN using command Insert Subscriber Data.

7.2 Information Flows

FIGS Levels 2 and 3 will be treated together in this section but it should be remembered that partial call records and SS notification invocation is not available with FIGS Level 2.

Each item of call data required by FIGS will be considered in turn and the information flows within CAMEL which provide this data given.

Text applies to the implementation of FIGS functionality using both Phases 1 and 2, unless otherwise stated.

MO and MT calls will be treated together. If a message or DP is named as O/T_Answer, for instance, this means that if the call is MO, the relevant DP is O_answer, and that if the call is MT, the relevant DP is T_answer.

Diagrams showing the information flows for FIGS levels 2 and 3 are given in Annex A.

7.2.1 Mobile Originated and Mobile Terminated Calls

7.2.1.1 Call Start Time

Information regarding a call attempt can be obtained from the InitialDP message sent from the gsmSSF to the gsmSCF. This message is sent after a control relationship for the call has been set up between the gsmSSF and gsmSCF. This message will provide notification to the FDS that a FIGS monitored subscriber has made a call attempt, or that an attempt is being made to call a FIGS monitored subscriber.

CAMEL Phase 1

The call, however, has not been connected at the time of the InitialDP message. The gsmSCF must therefore arm DP O/T_answer, so that the gsmSSF will inform the gsmSCF when the called party answers/connects. The gsmSCF arms the DP with message Request_Report_BCSM_Event sent to the gsmSSF.

If the called party answers, the gsmSSF sends Event_Report_BCSM (Notify and Continue) to gsmSCF. This message provides notification to the FDS that the attempted call has begun. The gsmSCF must then arm DP O/T_Disconnect, so that the gsmSSF will notify the gsmSCF when the call ends.

If the called party does not answer, the gsmSSF terminates the relationship for the call with the gsmSCF. It does this using message “ABORT”. This message provides notification to the FDS that the call attempted did not connect.

CAMEL Phase 2

The call, however, has not been connected at the time of the InitialDP message. The gsmSCF must therefore arm DP O/T_Answer, so that the gsmSSF will inform the gsmSCF when the called party answers/connects. The following DP’s (with trigger events given) must also be armed so that the gsmSCF will be informed if the trigger event occurs:

O_Route_Select_Failure (call establishment fails, MO calls only)

O/T_Busy (called party is busy)

O/T_No_Answer (no answer from called party)

O/T_Abandon (calling party abandons the call before the called party has answered)

O/T_Not_Reachable (called party is not reachable)

For the purposes of FIGS, these DP’s need only be armed for notification (N).

The gsmSCF arms all these DPs with a single message Request_Report_BCSM_Event, sent to the gsmSSF.

If the trigger event for any of O_Route_Select_Failure, O/T_Busy, O/T_No_Answer, O/T_Not_Reachable occurs then the gsmSCF is informed by the gsmSSF of the failure of the call attempt with Event_Report_BCSM, enclosing the relevant cause.

If the called party answers, the gsmSSF sends message Event_Report_BCSM to the gsmSCF. This message provides notification to the FDS of the start of a call by a FIGS monitored subscriber. The gsmSCF must then arm DP O/T_Disconnect, so that the gsmSSF will notify the gsmSCF when the call ends.

7.2.1.2 Partial Call Records

This functionality is available with CAMEL Phase 2 only.

Using the “Apply Charging” process within CAMEL Phase 2, the gsmSCF can control the duration of a call. The gsmSCF authorises the gsmSSF to allow the call to proceed continue for a certain time. At the conclusion of this time period, the gsmSSF seeks further instructions from the gsmSCF. The gsmSCF can, at this point, authorise the call to continue for another time period (which may be different to the first) or may instruct the gsmSSF to terminate the call.

With regard to FIGS, this functionality can be used to generate partial call records for the gsmSCF, as follows:

After the gsmSCF has received the InitialDP message from the gsmSSF, the gsmSCF sends message Apply_Charging to the gsmSSF, containing parameter “Tcs”, the “call segment” duration. The gsmSSF will then send message Apply_Charging_Report to the gsmSCF after Tcs seconds. This message c

ontains the duration of the call since the start of charging The gsmSCF may then instruct the gsmSSF to allow the call to continue for another Tcs seconds and this sequence of events continues until the call is released. When the call is released, Apply_Charging_Report is sent to the gsmSCF.

The gsmSCF can therefore define how often it is to receive partial call records on a per subscriber, per call basis, and can change how often the partial call records are received during a call

7.2.1.3 Call End Time

When either of the calling or called parties releases the call, the O/T-Disconnect DP is triggered and message Event_Report_BCSM is sent to the gsmSCF. This message provides notification to the FDS of the call end.

7.2.2 Forwarded Call

7.2.2.1 Call Start Time

The forwarded leg “from” the called party to the forwarded‑to number is considered as an MO call, originated by the called subscriber, as well as an MT call for the called subscriber. Two separate CAMEL dialogues will therefore be set up.

The CAMEL process for the terminating leg will follow subclause 7.1 as an MT call and the CAMEL process for the “originating” (forwarded) leg will follow subclause 7.1 as an MO call.

7.2.2.2 Partial Call Records

As for subclause 7.1.2.

7.2.2.3 Call End Time

As for subclause 7.1.3.

7.2.3 Supplementary Service Invocation

This functionality is available with CAMEL Phase 2 only.

From CAMEL Phase 2 (GSM 03.78 Release 97), subclause 8.11:

"At the invocation of any of the services ECT, CD and MPTY the MSC/VLR checks whether the criteria for sending a notification is fulfilled, i.e. whether the subscriber is provisioned with the SS-CSI and the particular invoked supplementary service is marked in the SS-CSI. If this is the case a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS-CSI. The processing of the particular SS invocation is not suspended. If the notification criteria is not fulfilled the processing of the particular supplementary service continues unchanged and no notification is sent.

The sending of the notification is independent of call related CAMEL processing, i.e. processing indicated by O/T-CSI."

Annex A (informative):
FIGS Data provided by CAMEL Messages

GSM 02.33 lists the information that should be present in FIGS Data messages. Tables A.1 to A.3 show the information required by GSM 02.33 for call start and end and partial call records, and the CAMEL messages, if any, that provide this information. Note that partial call records are only available with FIGS Level 3.

The CAMEL message given for a particular call event, e.g. call end, will not necessarily arrive at that event. The FDS must have the ability to build up a full picture of a call as various CAMEL messages are received.

Table A.1: Required Call Start information

Information	MO	MT	CF
Dialled digits	InitialDP (IDP), Called Party BCD Number	IDP, Called Party Number	IDP, Called Party Number
A party number	IDP, Calling Party Number	IDP, Calling Party Number, if available	IDP, Calling Party Number, if available
B party number	IDP, Called Party BCD Number	IDP, Called Party Number	IDP, Called Party Number
Modified B party number	gsmSCF	gsmSCF	gsmSCF
C party number	n/a	n/a	Called Party Number
Modified C party number	gsmSCF	gsmSCF	gsmSCF
CGI (of A party)	IDP, Location Number	location number in ISUP signalling, if available	location number in ISUP signalling, if available
IMSI	IDP, IMSI (of A party)	IDP, IMSI (of B party)	IDP, IMSI (of B party)
IMEI (of A party)	Not available	Not available	Not available
Call Start Time/Date	Phase 1: arrival time of Event_Report_BCSM Phase 2: Timestamp on Event_Report_BCSM	Phase 1: arrival time of Event_Report_BCSM Phase 2: Timestamp on Event_Report_BCSM	Phase 1: arrival time of Event_Report_BCSM Phase 2: Timestamp on Event_Report_BCSM
Call Reference	IDP, Call Reference_Number	IDP, Call Reference_Number	IDP, Call Reference_Number
MO/MT indicator	IDP, Event Type BCSM	IDP, Event Type BCSM	IDP, Event Type BCSM
Visited MSC address	IDP, MSC Address	IDP, MSC Address	IDP, MSC Address
Type of service	IDP, Basic Service Code, if available	IDP, Basic Service Code, if available	IDP, Basic Service Code, if available

Dialed digits: This always gives (for MO calls) the number originally entered by the party making the call, including any non-numeric characters.

Modified B/C party number: As the number is modified by the gsmSCF itself, it is assumed that the FDS will have direct access to this field and need not scan outgoing messages from the gsmSCF to obtain the field. If, however, the FDS must scan outgoing messages, the field is given in field Destination Routing Address in message Connect.

Cell Global Identifier (CGI): refers to the cell used by the MS at the start of the call.

Table A.2: Required Call End information

Information	MO	MT	CF
A party number	IDP, Calling Party Number	IDP, Calling Party Number, if available	IDP, Calling Party Number, if available
B party number	IDP, Called Party BCD Number	IDP, Called Party Number	IDP, Called Party Number
Modified B party number	gsmSCF	gsmSCF	gsmSCF
CGI	IDP, Location Number	location number in ISUP signalling, if available	location number in ISUP signalling, if available
IMSI	IDP, IMSI (of A party)	IDP, IMSI (of B party)	IDP, IMSI (of B party)
IMEI	Not available	Not available	Not available
Call Duration/end	Phase 1: Arrival time, Phase 2: Timestamp, of Event_Report_BCSM (with Event_Type_BCSM = O/T_Disconnect)	Phase 1: Arrival time, Phase 2: Timestamp, of Event_Report_BCSM (with Event_Type_BCSM = O/T_Disconnect)	Phase 1: Arrival time, Phase 2: Timestamp, of Event_Report_BCSM (with Event_Type_BCSM = O/T_Disconnect)
Call Reference	IDP, Call Reference_Number	IDP, Call Reference_Number	IDP, Call Reference_Number
MO/MT indicator	IDP, Event Type BCSM	IDP, Event Type BCSM	IDP, Event Type BCSM

CGI. If available, the CGI of the cell used by the MS at the end of the call is used. If this is not available, the CGI of the cell used at the start of the call is given.

Table A.3: Required Partial Call Information (CAMEL Phase 2 only)

Information	MO	MT	CF
Dialled digits	InitialDP (IDP), Called Party BCD Number	IDP, Called Party Number	IDP, Called Party Number
A party number	IDP, Calling Party Number	IDP, Calling Party Number, if available	IDP, Calling Party Number, if available
B party number	IDP, Called Party BCD Number	IDP, Called Party Number	IDP, Called Party Number
Modified B party number	gsmSCF	gsmSCF	gsmSCF
C party number	n/a	n/a	Called Party Number
Modified C party number	gsmSCF	gsmSCF	gsmSCF
CGI	IDP, Location Number	location number in ISUP signalling, if available	location number in ISUP signalling, if available
IMSI	IDP, IMSI (of A party)	IDP, IMSI (of B party)	IDP, IMSI (of B party)
IMEI	Not available	Not available	Not available
Call Start Time/Date	Phase 1: arrival time of Event_Report_BCSM Phase 2: Timestamp on Event_Report_BCSM	Phase 1: arrival time of Event_Report_BCSM Phase 2: Timestamp on Event_Report_BCSM	Phase 1: arrival time of Event_Report_BCSM Phase 2: Timestamp on Event_Report_BCSM
Call Duration	Apply_Charging_Report, Time Since Start of Charging	Apply_Charging_Report, Time Since Start of Charging	Apply_Charging_Report, Time Since Start of Charging
Call Reference	IDP, Call Reference_Number	IDP, Call Reference_Number	IDP, Call Reference_Number
MO/MT indicator	IDP, Event Type BCSM	IDP, Event Type BCSM	IDP, Event Type BCSM
Visited MSC address	IDP, MSC Address	IDP, MSC Address	IDP, MSC Address
Type of service	IDP, Basic Service Code, if available	IDP, Basic Service Code, if available	IDP, Basic Service Code, if available

The CAMEL message for SS invocation notification have not yet been defined so the call information for SS invocation notification can only be specified in general terms.

The notification of supplementary service (SS) invocation will be the same as table A.3, except that information field “Type of Service” will be “Type of SS”, and “Call Duration” will be “Time of SS invocation”. “Type of SS” will be given in the invocation notification sent from the gsmSSF to the gsmSCF. “Time of SS invocation” will be the timestamp in the invocation notification or its time of arrival at the gsmSCF.

Annex B (informative):
Information Flow for FIGS Levels 2 and 3

VPLMN	Messages	HPLMN	Comments
MSC		gsmSCF

	*For each call attempt :*

	Initial DP		Request for instructions from the SCP
	————————————->

	Request Report BCSM Event		To be aware of the call end
	<————————————-

	Continue		To continue the call
	<————————————-

	*+ For each successful call :*

	Event Report BCSM		To notify the SCP that the call has ended
EDP-N	————————————->

	*+ For each unsuccessful call :*

	Event Report BCSM
EDP-N	————————————->		Event report on « Busy », « no answer », etc.

Figure B.1: Message flow for a subscriber monitored using FIGS Level 2

VPLMN	Messages	HPLMN	Comments
MSC		SCP

	*For each call attempt :*

	Initial DP		Request for instructions from the SCP
	————————————->
	Apply Charging		To control the call duration
	<————————————-
	Request Report BCSM Event		To be aware of the call answer &the call end
	<————————————-
	Continue		To continue the call without change of the
	<————————————-		data by the SCP

	*+ For each successful call :*

	Event Report BCSM		To notify the SCP that the call has been
EDP-N	————————————->		answered by the remote party

	( <——— Release ——— )		This message is sent during the call only if the call must be released by the SCP because of a fraudulent situation
	: : :		End of the call :
	Apply Charging Report		To provide the SCP with the elapsed time
EDP-N	————————————->		since the start of charging
	Event Report BCSM		To notify the SCP that the call has ended
EDP-R	————————————->
	Continue / Release
	<————————————-		Release is sent to stop the call at the end


	*+ For each unsuccessful call :*

	Event Report BCSM
EDP-N	————————————->		Event report on « Busy », « no answer », etc..

Figure B.2: Message flow for a subscriber monitored using FIGS Level 3

Annex C (informative):
Change history

Change history GSM 03.31
Date	TSG #	TSG Doc.	CR	Rev	Subject/Comment	Old	New
					No Phase 1 version
03-1998	SMG#25				(cleaned up by SMG-PN) To SMG#25 for information		1.0.0
06-1998	SMG#26				To SMG#26 for approval		2.0.0
06-1998	SMG#26				TS approved by SMG#26	2.0.0	7.0.0
04-2000					Release 1999 version	7.0.0	8.0.0
Change history 3GPP TS 43.031
Date	TSG #	TSG Doc.	CR	Rev	Subject/Comment	Old	New
03-2001	SA#11				Upgrade to Release 4 (3GPP numbering)	03.31 V8.0.0	43.031 V4.0.0
06-2002	SA#16				Upgrade to Release 5	4.0.0	5.0.0
Change history 3GPP TS 23.031
Date	TSG #	TSG Doc.	CR	Rev	Subject/Comment	Old	New
12-2002	SA#18				Agreed to convert to 3GPP/GSM joint numbering scheme. 43.031 WITHDRAWN. Technically equivalent to 43.031 version 5.0.0	43.031 v5.0.0	23.031 v5.0.0
12-2004	SA#26				Upgrade to Release 6	5.0.0	6.0.0
06-2007	SA#36				Upgrade to Release 7	6.0.0	7.0.0
12-2008	SA#42				Upgrade to Release 8	7.0.0	8.0.0
12-2009	SA#46				Upgrade to Release 9	8.0.0	9.0.0
2011-03	–	–	–	–	Update to Rel-10 version (MCC)	9.0.0	10.0.0
2012-09	–	–	–	–	Update to Rel-11 version (MCC)	10.0.0	11.0.0
2014-09	–	–	–	–	Update to Rel-12 version (MCC)	11.0.0	12.0.0
2016-01	–	–	–	–	Update to Rel-13 version (MCC)	12.0.0	13.0.0
2017-03	–	–	–	–	Update to Rel-14 version (MCC)	13.0.0	14.0.0
2018-06	–	–	–	–	Update to Rel-15 version (MCC)	14.0.0	15.0.0
2020-07	–	–	–	–	Update to Rel-16 version (MCC)	15.0.0	16.0.0
2022-03	–	–	–	–	Update to Rel-17 version (MCC)	16.0.0	17.0.0