Document text
ETSITS123 094V11.0.0
(2012-10)
Digital cellular telecommunications system (Phase 2+);
Universal Mobile Telecommunications System (UMTS);
Follow-Me (FM);
Stage 2
(3GPP TS 23.094 version 11.0.0 Release 11)
®
A fi LO B A I
GLOBAL SYSTEM FOR
T I A T 1 V E MOBILE COMMUNICATIONS
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 1 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
Reference
RTS/TSGC-0423094vb00
Keywords
GSM,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6
Siret N ° 348 623 562 0001 7 - NAF 742 C
Association a but non lucratif enregistree a la
Sous-Prefecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from:
http://www.etsi.orq
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.orq/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.orq/chaircor/ETSI support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.
© European Telecommunications Standards Institute 2012.
All rights reserved.
DECT™, PLUGTESTS™, UMTS'^" and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
2QppTM ^^^ LTETM are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 2 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server ( http://ipr.etsi.org ).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/kev/quervform.asp .
ETSI
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 3 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
Contents
Intellectual Property Rights 2
Foreword 2
Foreword 4
1 Scope 5
2 References 5
3 Definitions and abbreviations 5
3.1 Definitions 5
3.2 Abbreviations 6
4 Handling of Follow Me 6
4.1 General 6
4.1.1 Provision 7
4.1.2 Registration 7
4.1.3 Erasure 7
4.1.4 Interrogation 7
4.2 Information Flows 7
4.2.1 Information Flow for the handling of FM by the initiating subscriber 7
4.2.2 Information Flow for the handling of FM by the remote party 10
4.3 Handling of FM control in HLRa and FFNb 10
4.3.1 Handling of FM control in HLRa 10
4.3.2 Handling of FM control in FFNb 13
4.4 USSD interworking and Cross-phase compatibility 22
5 Information stored in the network entities 23
5.1 Information stored in HLRa and FFNb 23
5.2 State transition model 23
5.3 Information stored in the VLR 24
5.4 Transfer of information fromHLR to VLR 24
Annex A (informative): Checking matrix for FM-CFU interaction in FFNb 25
Annex B (normative): FM control Messages and their contents 27
B.l General principles 27
B.2 Information Elements used in the messages 27
B.3 Messages Contents of the FM Request 27
B.4 Messages Contents of the HLR-FM -Request 28
B.5 Contents and Format of the USSD String of the USSD-Notify 30
B.6 Inter-process Message Init-Notify 31
Annex C (informative): Change history 32
History 33
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 4 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
Foreword
rd ,
This Technical Specification (TS) has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
X the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 5 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
1 Scope
The present document specifies the stage 2 description for the Follow Me feature.
The Follow Me feature enables a mobile subscriber A to manipulate the Follow Me data of a remote party B in such a
way that subsequent calls directed to remote party B will be forwarded to subscriber A.
2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.
• References are either specific (identified by date of publication, edition number, version number, etc.) or
non-specific.
• For a specific reference, subsequent revisions do not apply.
• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.
[I] 3GPP TR 21.905: "3G Vocabulary".
[2] 3GPP TS 22.004: "General on Supplementary Services".
[3] 3GPP TS 22.030: "Man-Machine Interface (MMI) of the Mobile Station (MS)".
[4] 3GPP TS 22.082: "Call Forwarding (CF) supplementary services - Stage 1".
[5] 3GPP TS 22.094: "Follow Me (FM) feature - Stage 1".
[6] 3GPP TS 23.01 1: "Technical realisation of Supplementary Services - General Aspects".
[7] 3GPP TS 23.015: "Technical reaUsation of Operator Determined Barring (ODB)".
[8] 3GPP TS 23.090: "Unstructured Supplementary Services Data (USSD)- Stage 2".
[9] 3GPP TS 23.082: "Call Forwarding (CF) supplementary services - Stage 2".
[10] 3GPP TS 22.090: "Unstructured Supplementary Services Data (USSD)- Stage 1".
[II] 3GPP TS 24.090: "Unstructured Supplementary Services Data (USSD)- Stage 3".
[12] 3GPP TS 29.002: "Mobile Application Part (MAP)".
3 Definitions and abbreviations
3.1 Definitions
initiating subscriber: mobile subscriber who modifies the Follow Me data of the remote party.
initiating number: number (the MSISDN of the initiating subscriber) to which incoming calls, originally destined for
the remote party, shall be forwarded. It is subsequently also referred to as MSISDNa.
remote party: is characterised by the remote number which is defined in the numbering plan of a PLMN operator. The
Follow Me feature enables the initiating subscriber to modify the Follow Me data of the remote party. In particular
cases the remote party is a GSM subscriber of the PLMN and the remote number denotes her basic MSISDN.
Previously registered subscriber: Is the initiating service subscriber who has registered Follow Me with respect to a
remote party. Her Registration can be erased by herself or by an FM service supervisor via forced erasure procedure.
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 6 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
FM service supervisor: is an initiating subscriber who is allowed to modify the Follow Me data of a remote party who
has been registered to a previously registered subscriber for the Follow Me application. The FM service supervisor shall
be authorised by her network operator.
remote number: is a number in E.164 format which identifies a remote party. In general this number is not assigned to
a subscriber and can be regarded as a "dummy MSISDN". In particular cases the remote party is a GSM subscriber of
the PLMN and the remote number denotes her basic MSISDN. The remote number is entered by the initiating
subscriber for registration, interrogation, forced erasure and erasure of the Follow Me feature with respect to the remote
party.
Follow Me function node: is a network node in the PLMN operator of the remote party. The FM data of the remote
party are stored in this node. This node can be implemented in:
- an HLR;
any other operator specific network node e.g.:
- a gsmSCF;
- an SCP.
3.2 Abbreviations
FFN Follow Me function node
FM Follow Me
SCP Service Control Part
Other abbreviations used in this ETS are listed in 3GPP TR 21.905.
Handling of Follow Me
4.1 General
Follow Me enables an initiating mobile subscriber A to have control over the Follow Me data of a remote party B. The
remote party B is characterised by the remote number which is defined in the numbering plan of a PLMN operator.
Initiating Subscriber A shall be able to manipulate the Follow Me data of remote party B such that subsequent calls
destined for remote party B are forwarded to initiating subscriber A. In the case of Forced Erasure by an FM service
supervisor, the initiating subscriber is allowed to erase the Follow Me data of a remote party who has been registered to
a different initiating subscriber for the Follow Me application.
Follow Me is a PLMN specific feature and the control operations of FM are based on USSD. All messages between the
MS and the mobile network and internal to the mobile network are USSD messages.
The present document deals with the control operations of FM in HLRa and FFN. If the FFN is an HLR, the control of
the requests for both FM and CFU services is specified (see subclause 4.3.2).
The functionality of forwarding calls for remote party B to initiating subscriber A (after successful registration of FM)
is out of the scope of the present document. This functionality is the same as the functionality of the Call Forwarding
Unconditional Supplementary Service applied to all telecommunication services of remote party B for which CFU is
applicable.
NOTE 1: the "served mobile subscriber" in 3GPP TS 22.094 [5] corresponds to the "remote party" in the present
document and the "forwarded-to subscriber" in 3GPP TS 22.094 [5] corresponds to the "initiating
subscriber" in the present document.
NOTE 2: The forwarding of calls for remote party B to initiating subscriber A can be achieved by invoking the Call
Forwarding Unconditional Supplementary Service or by making use of an equivalent operator specific
service (e.g. via CAMEL).
The functionality of the control of Follow Me (registration, erasure, forced erasure and interrogation) is split between
the HLR of the initiating subscriber A (HLRa) and the FFN of the remote party B (FFNb).
ETSI
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 7 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
4.1.1 Provision
FM can be registered / erased / interrogated by an initiating subscriber A with respect to a remote party B if both parties
are provisioned with FM.
To enable forced erasure by an FM service supervisor, the FM service shall be provisioned to the FM service
supervisor. Additionally, she needs the subscription entitlement to perform the forced erasure.
NOTE: In general remote party B does not correspond to a GSM subscriber. In this case provisioning of FM for
remote party B is operator specific.
If remote party B is a GSM subscriber and if the forwarding of calls for remote party B to initiating subscriber A is
achieved by invoking the Call Forwarding Unconditional Supplementary Service, provision of CFU for remote party B
is required.
4.1.2 Registration
The initiating subscriber registers the FM feature with respect to a particular remote party.
If an initiating subscriber A successfully registers FM with respect to a remote party B then FM becomes registered,
active and operative for remote party B.
As a result of the registration subsequent calls directed to remote party B are forwarded to initiating subscriber A.
NOTE: The remote party cannot register FM with respect to herself.
4.1.3 Erasure
If an initiating subscriber A or the FM service supervisor successfully erases FM with respect to a remote party B then
FM becomes not registered and not active for remote party B.
For forced erasure by the FM service supervisor the previously registered subscriber shall be informed of the successful
forced erasure via a network initiated USSD Notify message with appropriate contents. This message is sent by the
FFN.
If remote party B is a GSM subscriber and successfully erases FM then FM becomes not registered and not active for
remote party B.
4.1.4 Interrogation
If an initiating subscriber A or the FM service supervisor successfully interrogates FM with respect to a remote party B
then this procedure interrogates the FM data of subscriber B.
If remote party B is a GSM subscriber and successfully interrogates FM then this procedure interrogates her own FM
data.
4.2 Information Flows
4.2.1 Information Flow for the handling of FM by the initiating subscriber
Figure 4. 1 shows the Information Flow for the control of FM (registration, erasure, forced erasure and interrogation) by
the initiating subscriber.
For any control operation on FM, the initiating subscriber (MSa) enters a Follow Me Request (FM-Request). This is a
USSD string containing the requested FM operation and the remote number. The Follow Me Request is routed via the
MSC/VLR to the HLR of the initiating subscriber (HLRa).
The HLRa performs a series of checks as described in the SDLs (subclause 4.3). If these checks fail, the MSa receives a
response (FM-Response) indicating the error.
If the checks pass, the HLRa forwards the operation request (HLR-FM-Request) to the FFN of the remote party (FFNb).
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 8 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
FFNb carries out the appropriate control operation and checks as described in the SDLs (subclause 4.3) for the remote
party.
The result of this operation (success or error) is reported back in a USSD Response to the initiating subscriber.
For successful forced erasure by a service supervisor, the FFN shall send a Network Initiated USSD notify message
with the corresponding USSD string to the HLR of the previously registered subscriber who had registered the Follow
Me data. The HLR shall forward the USSD notify to VLR which will relay the USSD Notify towards the MS.
Upon receipt of the USSD Notify, the MS shall respond by sending a FACILITY message with empty return result
component.
An error response with corresponding reason can be returned from any entity, when error happens at the entity 3GPP
TS 23.090 [8].
£75/
3GPP TS 23.094 version 11.0.0 Release 11
ETSI TS 123 094 V1 1.0.0 (2012-10)
MSa
MSC
VLR
HLRa
FFNb
FM-Request
(OCSC.RN,
[(SI,PIM,)][AI])
FM-Response
(Error)
FM-Response
(Result)
FM-Request
(OCSC.RN,
[(SI,PIM,)][AI])
FM-Response
(Error)
^M-Response
(Result)
MSp
MSC
^SSD-Notify
(OC,SC,FN,SI,
MSISDN-A,AI)
USSD-Respon|(
(error)
USSD-Respon^
(result)
JSSD-Notify
FM-Request
(OCSC.RN,
[(SI,PIM,)][AI])
FM-Response
0R1
N
(Error)
FM-Response
(Result)
0R1
Y
HLR-FM-Request
(OC,SC,RN,
[(SI,PIM,)][AI,]
MSISDN-A)
HLR-FM-Respon
se
(Result)
VLR
HLRp
(OCSC.FN.SI,
MSISDN-A,AI)
(error)
y.§.§.?"Jis?P°!]|J
(error)
USSD-
Respori g !
(result)
^USSD-Notify
(OCSC.FN.SI,
MSISDN-A,AI)
y^^Pj Response
(error)
y S S_D - R e s po ns e
(error)
USSD-Response
(error)
USSD-Response
(result)
(OCSC.FN.SI
MSISDN-A.AI
USSD-Respons
(error)
USSD-Respons;
USSD-Notify
(error)
JSSD-Responss
(error)
y§§Pj?§5.P?Jlif
(error)
USSD-Respori s ^
(result)
In case of successful
forced erasure by a
service supervisor.
an USSD Notify with
corresponding USSD
string is sent to the
previously registered
subscriber.
Figure 4.1 : Information flow for the control of FM by the initiating subscriber or service supervisor
£75/
3GPP TS 23.094 version 11.0.0 Release 11
10
ETSI TS 123 094 V1 1.0.0 (2012-10)
NOTE 1: ORl:N: The case where the checks in the HLR resuh in a negative outcome, e.g. FM is not
provisioned for the initiating subscriber or the initiating subscriber is not allowed to
operate FM for the remote party.
ORl:Y: The case where all the checks in the HLR are successful, e.g. FM is provisioned for the
initiating subscriber and the initiating subscriber is allowed to operate FM for the remote
party.
NOTE 2: [...] Optional parameter.
(...)] Conditional parameter.
OC Operation Code (Register, Erase or Interrogate).
SC Service Code for FM.
RN Remote Number.
SI Supervisor Indicator. This parameter is conditional and only used for forced erasure by a
FM service supervisor.
PIM MSISDN of previously registered subscriber who has registered the FM to remote
number. This parameter is conditional and only used for forced erasure by a FM service
supervisor..
AI Supplementary Information containing additional information.
MSISDN-A initiating number in international format. It is not a part of the USSD string, but is sent
from HLRa to the FFNb together with the HLR-FM -Request within the MAP operation.
For forced erasure, the MSISDN-A corresponds to the supervisor"s MSISDN and will be
part of the USSD-notify.
MSp MS of previously registered service subscriber.
HLRp HLR of the previously registered service subscriber.
4.2.2 Information Flow for the handling of FM by the remote party
Control of FM by the remote party is possible if the remote party is a GSM subscriber.
The information flow for control of FM by the remote party (erasure and interrogation of her own FM data) is the same
as the information flow for control of FM by the initiating subscriber.
If a remote party tries to register FM to herself the registration is rejected and an error is reported.
4.3 Handling of FM control in HLRa and FFNb
HLRa and FFNb can both receive FM control messages, based on USSD. The USSD handler in each entity analyses the
Service Code contained in the USSD string and, recognising the Service Code for FM, invokes the FM USSD
application.
The FM control messages and their contents are given in Annex B (normative).
4.3.1 Handling of FIVI control in HLRa
The FM USSD apphcation in HLRa is the process FM_initiating_subscriber_handling_in_HLR (figure 4.2). It
receives the FM-Request from the initiating subscriber. This FM-Request is an USSD-string containing:
the operation code (register, erase, interrogate);
the remote number;
- an additional operator specific information field.
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 11 11 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
The HLR checks:
the provisioning of FM to the initiating subscriber;
whether the FFN can be deduced from the remote number;
whether any operator specific restrictions to engage in FM activity with the remote party apply;
if the initiating subscriber requires forced erasure, the HLR checks Whether the initiating subscriber is entitled to
do it, i.e. Whether the initiating subscriber is a FM service supervisor.
The basic MSISDN of the initiating subscriber is sent together with the original USSD string to the FFN of the remote
party.
The HLR forwards the response from the FFN to the initiating subscriber.
For successful forced erasure by a service supervisor, the HLR of the previously registered subscriber (HLRp) shall
relay the USSD Notify to the VLR when the USSD Notify from the FFN is received. The VLR will then forward the
USSD Notify towards the MS of the previously registered service subscriber.
On receipt of an USSD response from the MS of the previously registered subscriber, the HLRp shall relay it to the
FFN.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
12
ETSI TS 123 094 V1 1.0.0 (2012-10)
Process FM_lnitiating_Subscriber_Handling_in_HLR
1(1)
A process in the HLR to handlei
an FM-Request from an initiating^
subscriber.
Signals to/from the left K
areto/ftomtheVLRofthe
initiating subscriber;
Signals to/from the right
are to/from the FFN
Idle
FM-Request
(Operation,
RemoteNumb^
Additional Infol
HLR receives USSD
I string from initiating
subscriber
checl< If Initiating
T subscriber is FM
provisioned
checl< If address of FFN
"can be deduced from
Remote Number
aupervlsbr-^^
Indicator
.^esent?,,--^
Jyes
Checl< lit the forced erasure
'Forced^-.^
^ J
Is allowed to the ritiating
subscriber.
Erasure
allowed?,-'^
Error :=
unauthorised
request
FM-Response
(Error)
Idle
HLR-FM-Request :=
FM-Request
-1- initial MSISDN
HLR-FM-Request
(Operation,
RemoteNumber,
Additionaljnfo,
InifaLMSISDN)
wai_for_answer_
from FFN
HLR-FM-Response
(Result) \
check operator specific
restrictions on initiating
subscriber to engage
Remote Party in FM activity
Basic MSISDN of Initiating
subscriber is sent to the FFNb
together with the FM-Request
within the MAP operation.
FM-Response
(Result)
Idle
Figure 4.2: Process: FMJnitiatingSubscriberHandlingJnHLR
£75/
3GPP TS 23.094 version 11.0.0 Release 11
13
ETSI TS 123 094 V1 1.0.0 (2012-10)
Process Notification_for_previously_registered_subscriber_in_HLRp
Process in HLRp to handle i
the forced erasure notificatiorl
sent from the FFN
Signals tc/from the left ^
are to/ftom the VLR of the
initiating subscriber;
Signals to/From the right
are to/from the F FN
USSD-Notify-
Response( error)
Idle
USSD-Notify /
(OC,SC,FN,SI, < '
MSISDN-A,AI) \
USSD-Notify-
Response()/(error) ,
Idle
from the FFN
1 process FFN_Forced
Erasure_Notfy
Errors can orrucr
" in HLRp when
handling
USSD-Notify
send to VLR
Response
"I from VLR
send to the FFN
" process FFN_
Foroed_Erasure_
Notify
1(1)
Figure 4.2a: Process Notification_for_previously_registered_subscriber_in_HLRp
4.3.2 Handling of FM control in FFNb
If the FFN is an HLR, the FFN is responsible for handUng the interactions between FM and CPU. Two kinds of request
may be received in an FFN which deals with forwarding services:
CFU requests sent by the VLR for CFU operations (only if the FFN is a HLR);
FM-HLR-Requests which are USSD strings sent by HLRa for FM operations.
When the control process in the FFN receives a CFU request, it shall either pass the CFU operation request directly to a
CFU process or reject it depending on the registration and/or activation states of both FM and CFU services (see Table
A.l for permission checks).
On receipt of an HLR-FM request, the control process in the FFN performs a series of FM specific checks and checks
the states of both FM and CFU. If the checks are successful, a CFU operation request is sent to a CFU process. On
receipt of an HLR-FM-Request from HLRa, the FFN performs a series of checks, e.g.:
if the remote party is a GSM subscriber:
provisioning of FM to the remote party;
provisioning of CFU to the remote party;
illegal interaction with CFU registered or active to remote party.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
14
ETSI TS 123 094 V1 1.0.0 (2012-10)
if the remote number is registered in the FFN;
if any operator specific restrictions to engage in FM activity with the initiating subscriber apply;
specific checks for forced erasure.
Depending on the requested operation, one of the following procedures is performed:
registration with implicit Activation (procedure Handle_Remote_Party_Registration, figure 4.6);
erasure with implicit Deactivation (procedure Handle_Remote_Party_Erasure, figure 4.7);
interrogation (procedure Handle_Remote_Party_Interrogation, figure 4.8).
For successful forced erasure by a service supervisor, the FFN shall generate an USSD-Notify message and send it to
the HLRp, which will relay the USSD Notify towards the MS of the previously registered subscriber (MSp). On receipt
of an error response that the USSD Notify message could not be transferred to the MS, the FFN shall check the error
code of the response. Depending on the error types and the specific implementation the process shall decide to resend
the USSD message after a predefined time.
For the resend procedure the process shall start a timer. On timer expiry it shall send the message again. The FFN shall
repeat the messages up to 5 times.
The length of the timer is defined by operator and has the value in the range of 1 - 10 minutes.
Figure 4.3 shows the message flow between the process Forwarding_Service_Control and the processes handling CFU
operation requests, defined in 3GPP TS 23.082 [9].
from/tC'
HLRa
from/tC'
VLR
Block FFN Processes
FM-HLR-Request
FM-HLR-Response|
[CFU-Request]
CFU acknowledge
this is appiicabie
if the FFN is a HLR i
1(1)
process_
forwarcling_
Service_
control
- Process defined in 03.94
CFU operation request
acl^nowiedge
Processes defined
in 03.82: CFU1,
CFU2,CFU3or
CFU4
process_CFU_
handling
Figure 4.3: FFN_processes
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1
15
ETSI TS 123 094 V1 1.0.0 (2012-10)
Process Forwarding_Service_Control
This process describes ,_v
the case where the FFN is sr
HLR. Camel or IN solution ' ,
should have the similar
behavior.
Signals to/from the right are K
loifrom the appropriate CFU
process. Signals to/from the
left are lo/from the VLR
unless otherwise stated.
It's from the HLR of
the ritiating subscriber.
HLR-FM-
, Request (Reg,
-^rase, interr.,
forced erasure)
FM_remotej3arty_
handlingJnFFN
Result :=
Conflicting
situation
with other SS
1(2)
>RegisterCFU >activateCFU >eraseCFU
\ ( \ (
X deactivate
^CFU
X interrogate
^CFU
waitforresponse
acknowledge
acknowledge
J it should contain the appropiate
I message, e.g. "register CFU" etc.
if it's an FM-Request,
J the message is to the VLR
of the initiating subscriber.
4.4 Process Forwarding_Service_Control
£75/
3GPP TS 23.094 version 11.0.0 Release 11
16
ETSI TS 123 094 V1 1.0.0 (2012-10)
Procedure FM_Remote_Party_Handling_in_FFN
1(1)
This process describes the case ;
where the FFN is an HLR.
IN solutions should have
similar behaviour.
signals to/from the left areL
to/from the HLR of the
initiating subscriber
Result :=
unknown remote
party
Result :=
remote party
authorisation
failed
yes
check operator specific
' restrictions on remote party
to be engageed in FM activity
with Initiating subscriber
handle_Remote_
Party_
Registration
Figure 4.5: Procedure: FM_Remote_Party_Handling_in_FFN
£75/
3GPP TS 23.094 version 11.0.0 Release 11
17
ETSI TS 123 094 V1 1.0.0 (2012-10)
Procedure Handle_Remote_Party_Registration
1(1)
n>^
This process describes the case
where the FFN is an HLR
IN solutions should have
similar behaviour.
signals to'from the left are|\
to/fromtheHLRofthe
initiating subscriber
signals to/from the right are
to/from the CFU processas
indicated
Result :-
request to ovi^n
MSISDN not possible
FM states :=
registered & active
Result :=
FM successful
registered
result := corresponding
unsuccessful
outcome code
Figure 4.6: Procedure: Handle_Remote_Party_Registration
£75/
3GPP TS 23.094 version 11.0.0 Release 11
18
ETSI TS 123 094 V1 1.0.0 (2012-10)
Procedure Register_FM_for_Remote_Party
This process describes the case \
wheretheFFN isan HLR. ^
iN solutions shou id have
simiiar behaviour.
1(1)
signals to/from the right areb
to/from the CFU processas
indicated.
yes
to process CFU1
(GSM 03.82)
ifyes, the initiating
subscriber repeats
her previous
registration
Result := remote
party already
registered
from process CFU1
(GSM 03.82)
acknowledge
(error)
acknowledge
(result)
from process GFU1
"I (GSM 03.82)
Result :=
(error)
Result :=pass
Figure 4.6a: Procedure Register_FM_for_Remote_Party
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1
19
ETSI TS 123 094 V1 1.0.0 (2012-10)
Procedure handle_Remote_Party_Erasure
iThis proceduredescribesthecase, >
I where the FFN is an HLR. ^ x"
I IN Solutions should have | /
I similar behaviour, ,
1(1)
signals to/from the leftareK
to/from the HLR of the
initiating subscrit)er
signals to/fromthe rightare
to/from the C FU process as
indicated
NotifbationRequired
:= FALSE
Result :=FM
not registered to
remote party
if yes, then FM
service
supervisor
performs FM
erasure
if yes, remote
party erases
her own FM
data
Resuit := remote
party not
registered to
thislVISiSDN
to the FFN process
FFN_Forced_
erasure_Notify
Figure 4.7: Procedure: Handle_Remote_Party_Erasure
£75/
3GPP TS 23.094 version 11.0.0 Release 11
20
ETSI TS 123 094 V1 1.0.0 (2012-10)
Procedure Erase_FM_for_Remote_Party
1(1)
This procedure is caiied i \
by the procedure ^
handie„Remotej)arty_Erasure
after the authorisation checl^s
have been done. This procedure
describes the case if the FFN is
an HLR. Camel or IN solution
should have the same behavior '
signals to/from the leftare^
toAromtheHLRofthe
initiating subscriber
signals to/from the right are
toArom the CFU process as
indicated.
Erase_CFU
(BS = all BS)
to process CFU 2
1 (GSM 03.82)
wait_for_
response
from process CFU2
(GSM 03.82)
acknowledge
' (result)
acknowledge
(error)
from process CFU2
1 (GSM 03.82)
Result := pass
Result := (error)
Figure 4.7a: Procedure Erase_FM_for_Remote_party
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1
21
ETSI TS 123 094 V1 1.0.0 (2012-10)
Procedure Handle_Remote_Party_lnterrogation
I \':
I This procedure describes , ,
I the case whenre the FFN is^
I an HLR. IN solutions should '
I have similar behaviour. ,
1(1)
signals to/from the left arel
to/from the HLR of the
initiating subscriber
The MSISDN digits are sent
" in the USSD response
separated by a blank
character from the outcome
code
Figure 4.8: Procedure Handle_Remote_Party_lnterrogation
£75/
3GPP TS 23.094 version 11.0.0 Release 11
22
ETSI TS 123 094 V1 1.0.0 (2012-10)
Process FFN_Forced_Erasure_Notify
1(1)
This process describes the, >
case where the FFN is an "'
HLR. Camel or IN solutions '
should have the similar '
behavior. |
Signals to/from the right |\
are to/from the process
Forwarding_Service_Control.
Signals to/from the left are
to/from the HLRp unless
othenwise staled.
start the Network l
initiated USSD \
start Timer for
resending Notify
Depending on the
" error types and the
specific
implementation the
process shalldedde
toresend the USSD
message.
I After Timer over,
"ithe process
I goes on.
Figure 4.9: Process FFN_Forced_Erasure_Notify
4.4 USSD interworking and Cross-phase compatibility
All the messages between MS and the mobile network and internal to the mobile network, which are used for control of
Follow Me, are USSD Phase 2 messages.
A Cross-phase compatibility mechanism specified in 3GPP TS 23.011 [6] for networks or MS not supporting USSD
Phase 2 is not required.
Networks subject to the Interoperability Directive have to implement FM using USSD Phase 2.
NOTE: As an option, these networks may also implement FM using USSD Phase 1.
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 23 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
5 Information stored in the network entities
5.1 Information stored in HLRa and FFNb
The HLRa shall store:
the state of FM (which shall be one of the valid states listed below).
The FFNb shall store:
the state of FM if the remote party is a GSM subscriber;
the registration parameter:
- the initiating number (MSISDNa).
The following logical states are applicable for FM (refer to TS 23.011 for an explanation of the notation):
In HLRa (for the initiating subscriber)
Provisioning State Registration State Activation State HLR Induction State
(Not Provisioned, Not Registered, Not Active, Not Induced)
(Provisioned, Not Registered, Not Active, Not Induced)
The registration and activation state is the same for each applicable elementary basic service group.
The provisioning state shall be per subscriber, and hence the same for all basic service groups.
In FFNb (for the remote party).
Provisioning State Registration State Activation State HLR Induction State
(Not Provisioned, Not Registered, Not Active, Not Induced)
(Provisioned, Not Registered, Not Active, Not Induced)
(Provisioned, Registered, Active and Operative, Not Induced)
The registration and activation state is the same for each applicable elementary basic service group.
The provisioning state shall be per subscriber, and hence the same for all basic service groups.
5.2 State transition model
The following figure shows the successful cases of transition between the applicable logical states of FM. The state
changes are caused by actions of the service provider, the mobile user or the network.
NOTE: Error cases are not shown in the diagram as they do not normally cause a state change. Successful
requests that do not cause a state change are not shown in the diagram.
The diagram only shows operations on an elementary basic service group.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
24
ETSI TS 123 094 V1 1.0.0 (2012-10)
Figure 5.1 : State transition model for FM
5.3
Information stored in the VLR
There is no FM information stored in the VLR.
5.4 Transfer of information from HLR to VLR
There is no FM information transferred from HLR to VLR.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
25
ETSI TS 123 094 V1 1.0.0 (2012-10)
Annex A (informative):
Checking matrix for FIVI-CFU interaction in FFNb
The following table is applicable under the assumption that FM and CFU are always provisioned to the remote party.
If FM is not provisioned then there is no interaction between FM and CFU.
If FM is Registered and Active, CFU must also be Registered and Active.
Interrogation of both FM and CFU is allowed in any registration state.
Table A.I : Operation allowance check according registration states of FM and CFU (informative)
Operation
Registration States
Outcome
FIM
CFU
Registration FM
Not registered
Not registered
FM: Registered and Active
CFU: Registered and Active
Registered, not active
operation not allowed
Registered, active
operation not allowed
registered and active
Registered, active
see note 1
Erasure FIVl
Not registered
Not registered
operation not allowed,
see note 2
Registered, not active
operation not allowed
Registered, active
operation not allowed
registered and active
Registered, active
FM: Not Registered
CFU: Not Registered
Registration
CFU
Not registered
Not registered
FM: Not registered
CFU: Registered, active
see note 3
Registered, not active
FM: Not registered
CFU: Registered, active
see note 3
Registered, active
FM: Not registered
CFU: Registered, active
see note 3
registered and active
Registered, active
operation not allowed,
see note 4
Erasure CFU
Not registered
Not registered
operation not allowed,
see note 3
Registered, not active
FM: Not registered
CFU: Not registered
note 3
Registered, active
FM: Not registered
CFU: Not registered
see note 3
registered and active
Registered, active
operation not allowed,
see note 4
Activation CFU
Not registered
Not registered
operation not allowed,
see note 3
Registered, not active
FM: Not registered
CFU: Registered, active
see note 3
Registered, active
FM: Not registered
CFU: Registered, active
see note 3
registered and active
Registered, active
operation not allowed,
see note 4
Deactivation
CFU
Not registered
Not registered
operation not allowed,
see note 3
Registered, not active
operation not allowed,
see note 3
Registered, active
FM: Not registered
CFU: Registered, not active
see note 3
£75/
3GPP TS 23.094 version 11.0.0 Release 11
26
ETSI TS 123 094 V1 1.0.0 (2012-10)
Operation
Registration States
Outcome
FIVI
CFU
registered and active
Registered, active
operation not allowed,
see note 4
NOTE 1 : The operation is only allowed when the registration is made by the same initiating subscriber. The
registration states of FM and CFU shall not be changed by the operation.
NOTE 2: The outcome code should be "Remote party not registered".
NOTE 3: Refer to TS 23.082 for CFU handling.
NOTE 4: Conflicting situation with other supplementary service (see TS 22.082: Exceptional procedures or
unsuccessful outcome).
£75/
3GPP TS 23.094 version 1 1 .0.0 Release 1 1 27 ETSI TS 1 23 094 V1 1 .0.0 (201 2-1 0)
Annex B (normative):
FM control Messages and their contents
B.1 General principles
All messages used for the control of FM are based on mobile initiated USSD. The principles of USSD can be found in
3GPP TS 22.090, 3GPP TS 23.090, 3GPP TS 24.090 and 3GPP TS 29.002.
The present document is only concerned with the contents of the USSD strings.
B.2 Information Elements used in the messages
The operation code
The operation code is defined in 3GPP TS 22.030 for the control of Supplementary Services and consists of the two
characters:
** for Registration;
## for Erasure;
*# for Interrogation.
The Service Codes
The Service Code is service specific for FM.
The remote number
The remote number is the basic MSISDN of the remote party if the remote party is a GSM subscriber. It is entered by
the initiating subscriber as part of the registration request. It is a number in international format.
Additional information field
An additional information field which does not exceed 30 octets may be optionally included in all FM control messages
to convey operator specific information to the FFNb. The content and use of this additional information is operator
specific and out of scope of the present document.
The initiating number
The initiating number is the basic MSISDN of the initiating subscriber. It is derived by HLRa from the IMSI of the
initiating subscriber.
This parameter is used in international format according to the scheme:
country code, national (significant) number.
B.3 Messages Contents of the FM Request
Contents of the USSD string of FM-Request:
all parameters are entered by the initiating subscriber and transported transparently to HLRa.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
28
ETSI TS 123 094 V1 1.0.0 (2012-10)
Table B.I : Contents of the USSD string of FM-Request
Parameter
number
Value
Parameter
mandatory (M)
or optional (0)
Comment
1
OC
M
Operation Code:
OC = ** ... for Registration
OC = ##... for Erasure
OC = *# ... for Interrogation
2
sc
M
Service Code for Follow Me. SMG1 Refer to 22.030
for the Service Code for Follow Me.
3
*
M
Delimiter
4
REMOTE
NUMBER
M
remote number
5
*
M
Delimiter.
6
Supervisor
Indicator
C
Supervisor Indicator = 88. Used for Forced Erasure
by FM Service Supervisor.
7
*
M
Delimiter
8
MSISDN
C
MSISDN of previous initiating subscriber who has
registered the FM to remote number. This
parameter is conditional, only used for forced
erasure.
9
*
M
Delimiter
10
Additional
information field
For operator specific use
last
#
M
End of USSD string
B.4 Messages Contents of the HLR-FM-Request
Contents of the USSD string of HLR-FM- Request is the same of FM-Request described in clause B.3. Additionally, the
MSISDNa is sent to the FFNb together with the FM-Request within the MAP operation. Contents of the FM -Response
Messages.
The FM-Response messages which are generated by the HLR, as well as the HLR-FM-Response messages which are
received by the HLR from the FFN and are forwarded unchanged as FM-Response messages to the MS, contain the
following two parts:
mandatory part: two digit outcome codes, which are interpreted in the MS according to operator specific
requirements;
optional part: the response texts.
The optional part is separated by a space character as separator which occurs together with the optional part.
These outcome codes indicating success or error of the requested FM operation are 2 USSD characters according to the
following table (table B.2).
£75/
3GPP TS 23.094 version 11.0.0 Release 11
29
ETSI TS 123 094 V1 1.0.0 (2012-10)
Table B.2 Outcome codes for FM-Response
Scenario
Text examples for MS display
Req
Era
Interro
Outcome
Code
Outcome codes for successful
cases
00 series
Success registration Case
Follow Me activated
X
01
Success erasure Case
Follow Me deactivated
X
02
Success interrogation Case
Follow Me active to
<MSISDN>
The MSISDN digits are sent in
the USSD response separated
by a blank character from the
outcome code.
X
03
Operator Specific outcome codes
04-06
Reserved for future enhancement
07-09
Spare outcome code
10
Reserved for GSM-Railway
11-12
Spare outcome codes
13-19
Outcome codes generated at
the HLRa in non-successful
cases
20,30
series
Incoming barrings
Illegal interaction with incoming
barring
X
X
X
21
Unauthorised request
Unauthorised request
X
X
X
22
Operator Specific outcome codes
23-30
Reserved for future enhancement
31-39
Outcome codes generated at
both the HLRa and the FM
function node in non-
successful cases
40 series
Unknown remote party
Unknown remote party
X
X
X
41
FIVI not subscribed
FM not subscribed
X
X
X
42
Operator Specific outcome codes
43-45
Reserved for future enhancement
46-49
Spare unsuccessful outcome
codes
50 series
Outcome codes generated at
the FM function node in non-
successful cases
60,70
series
Remote party already
registered
Remote party already registered
X
61
FIVI not registered to remote party
FMnot
registered to remote party
X
X
62
Remote party not registered to
this MSISDN
Remote party not
registered to this MSISDN
X
63
£75/
3GPP TS 23.094 version 11.0.0 Release 11
30
ETSI TS 123 094 V1 1.0.0 (2012-10)
Scenario
Text examples for MS display
Req
Era
Interro
Outcome
Code
Remote Party Authorisation failed
Unauthorised changes to remote
party
X
X
64
Call Forwarding active or
registered
Illegal interaction with call
forwarding
X
65
Incoming or outgoing barrings
Illegal interaction with call
barrings
X
X
66
Request to own MSISDN not
possible
Request to own MSISDN not
possible
X
67
Operator Specific outcome codes
68-72
Reserved for future enhancement
73-79
Outcome codes could be sent
back by CFU processes in
unsuccessful cases
forwarded-to number is invalid
directory number
forwarded-to number is invalid
directory number
X
80
insufficient information
insufficient information
X
X
81
forwarded-to number is a special
service code
forwarded-to number is a special
service code (e.g. police)
X
82
Conflicting situation with other
supplementary services
Conflicting situation with other
supplementary services (e.g.
incoming call barring has been
activated)
X
X
83
Inconsistent with registration
Inconsistent with registration
X
84
Spare unsuccessful outcome
codes
85-99
B.5 Contents and Format of the USSD String of the
USSD-Notify
The Contents and the format of the USSD string of the USSD-Notify are described in the following table.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
31
ETSI TS 123 094 V1 1.0.0 (2012-10)
Table B.3: Contents of the USSD string of the USSD-Notify for forced de-registration
Parameter
number
Value
Parameter
mandatory (M),
optional (0) or
conditional (C)
Comment
1
OC
M
Operation Code:
OC = ##... for Erasure
2
sc
M
Service Code for Follow Me. SMG1 Refer to 22.030
for the Service Code for Follow Me.
3
*
M
Delimiter
4
REMOTE
NUMBER (forced
deregistered
number)
M
remote number
5
*
M
Delimiter.
6
Supervisor
Indicator
C
Supervisor Indicator = 88. This parameter is
mandatory used for Forced Erasure by FM Service
Supervisor (see also parameter number 8).
7
*
M
Delimiter
8
MSISDN
C
This parameter is mandatory as MSISDN of
supervisor who initiated the forced
deregistration request.
This parameter shall not be included if
initiated by an administrative terminal
connected to the FFN.
9
*
M
Delimiter
10
Additional
information field
Additional information field
last
#
M
End of USSD string
Note: USSD Notification for Forced deregistration done by administrative terminal in general is optional.
B.6 Inter-process Message Init-Notify
The Init-Notify message is an inter-process message in FFN. It is sent from the process Handle_Remote_Party_Erasure
to process FFN_Forced_Erasure_Notify.
This message consists of the parameter USSD String. On receipt of the Init-Notify message, the process
FFN_Forced_Erasure_Notify will pack the USSD String into the USSD-Notify message and send it to the HLRp. Refer
to Table B.3 for the contents and format of the USSD String.
This message is only required where the FFN is based on an HLR. If the FFN is based on an IN system it is not
required.
£75/
3GPP TS 23.094 version 11.0.0 Release 11
32
ETSI TS 123 094 V1 1.0.0 (2012-10)
Annex C (informative):
Change history
Change history |
TSG CN#
Version
CR
Rel.
New Version
Subject/Comment
CN#06
-
R99
3.0.0
Approved at TSG CN#06 and placed under Cliange Control
CN#07
3.0.0
001
R99
3.1.0
Some corrections and further clear formulations to FM stage
2 specification
CN#09
3.1.0
002
R99
3.2.0
Correction of the wrong Service Code
CN#11
3.2.0
Rel-4
4.0.0
Release 4 after CN#1 1
CN#16
4.0.0
Rel-5
5.0.0
Release 5 after CN#1 6
Jun 2002
5.0.0
Rel-5
5.0.1
Corrupted figure 5.1 fixed
Dec 2003
5.0.1
003
Rel-6
6.0.0
Notify of forced erasure to previously regisstered subscriber
of his deregistration
Dec 2006
6.0.0
004
Rel-7
7.0.0
Reservation of outcome codes for GSM-Railway
Dec 2008
7.0.0
Rel-8
8.0.0
Upgraded unchanged from Rel-7
Dec 2009
8.0.0
-
Rel-9
9.0.0
Update to Rel-9 version (MCC)
2011-03
9.0.0
-
Rel-10
10.0.0
Update to Rel-10 version (MCC)
2012-09
10.0.0
-
Rel-11
11.0.0
Update to Rel-1 1 version (MCC)
£75/
3GPP TS 23.094 version 11.0.0 Release 11
33
ETSI TS 123 094 V1 1.0.0 (2012-10)
History
Document history
Vll.0.0
October 2012
Publication
£75/