2 Activation, deactivation, registration, erasure, interrogation and invocation
23.0113GPPRelease 17Technical realization of Supplementary ServicesTS
2.1 General
Activation, deactivation, registration, erasure, interrogation and invocation are defined independently from a particular supplementary service. Whether they are applicable to a particular supplementary service or not is defined in the corresponding 3GPP TS 23.08x and 23.09x‑series. Activation, deactivation, registration, erasure and invocation are applicable for CS domain. For PS domain o nly invocation of call barring of SMS is applicable.
The invocation of a supplementary service is executed as described in the corresponding stage 2 description and always includes an MSC and a location register for CS domain and an SGSN for PS domain.
When an MSC receives a request for either activation/deactivation or registration/erasure or an interrogation, it invokes one of the following procedures.
The MSC then can:
‑ contact only the current VLR (e.g. interrogation of a call forwarding conditional supplementary service);
‑ contact only the HLR (e.g. interrogation of the supplementary service call forwarding unconditional);
‑ contact the HLR, after which the HLR updates the VLR (e.g. registration of a forwarding number for a conditional call forwarding supplementary service).
Which of the above listed procedures is applied for a call independent supplementary service operation is described in the corresponding 3GPP TS 23.08x and 23.09x ‑series.
Successful activation, deactivation, registration and erasure change the service state at the HLR. These transitions (if applicable to a particular service) are defined in the 3GPP TS 23.08x and 23.09x ‑series. Note that the HLR may also change the service state due to "HLR Induction" (see clause 2.1.1).
In connection with supplementary service operations the served subscriber or remote subscribers may get notifications from the network. .
If an SGSN receives a request for registration, erasure, activation, deactivation, interrogation or change of password, it shall return an error to the MS.
2.1.1 Definition of "state vectors"
In order to provide a tool to define service states the concept of a "state vector" is introduced. The state vector is used to represent the state of the service in terms of four variables:
1) Provisioning State,
possible values are "Provisioned" or "Not Provisioned";
2) Registration State,
possible values are "Registered", "Erased", or "Not Applicable";
3) Activation State,
possible values are "Not Active", "Active and Operative" or "Active and Quiescent";
4) HLR Induction State,
possible values are "Induced" or "Not Induced".
The state vector represents the state of the service by using all four variables together. The state vector is represented using the notation:
(Provisioning State, Registration State, Activation State, HLR Induction State)
e.g.: (Provisioned, Registered, Not Active, Not Induced).
Note that the state vector is a logical (not a physical) representation of the service state. Note also that though some parts of the state vector are similar to elements of SS‑Status the mapping between the state vector and SS‑Status is not one to one. The use of state vectors is not intended to specify any particular implementation internally in a node. There is a relationship specified between the state vector and parts of the transfer syntax. This relationship is not a direct one‑to‑one mapping.
The following text specifies the semantics of each variable in the state vector.
The three variables "Provisioning State", "Registration State" and "Activation State" are used to represent the state of the service according to the normal behaviour based on service provider and user actions.
The "HLR Induction State" records whether or not the HLR has temporarily induced the service (e.g. if the VLR does not support CUG, the HLR may induce an outgoing barring service). The Provisioning State, Registration State and Activation State are not affected by HLR induction of a service.
Provisioning State
‑ has value "provisioned", if the subscriber has a subscription to the service;
‑ has value "Not Provisioned" otherwise.
Registration State
‑ has value "Not Applicable", if registration is not applicable to the service;
‑ has value "Registered", if registration is applicable, and there is registration data available;
‑ has value "Erased" otherwise.
Activation State
‑ has value "Active and Operative", if the service is in a state where it can be invoked (and this is not due to HLR induction);
‑ has value "Active and Quiescent", if the service is in a state where it cannot be invoked, but where it will automatically move to the "Active and Operative" state when conflicting conditions are removed;
‑ has value "Not Active" otherwise.
HLR Induction State
‑ has the value "Induced" if the HLR has induced the service (e.g. if the VLR does not support CUG, the HLR may induce an outgoing barring service);
‑ has the value "Not Induced" otherwise.
For further information about how HLR induction applies to particular services refer to the 3GPP TS 23.08x and 23.09x‑series.
2.1.2 Handling of service states at the HLR
Valid states (represented by state vectors) are defined on a service‑by‑service basis in the 3GPP TS 23.08x and 23.09x ‑series. For each service the set of valid states represents the logical states that can exist in the HLR. The HLR contains the master copy of service state information.
2.1.2.1 Encoding of SS‑Status
To send service state information to the VLR, the SGSN or the MS, the HLR often uses the SS‑Status parameter. This parameter contains four bits (referred to here as the "P bit", "R bit", "A bit" and "Q bit"). In a phase 2 context the HLR shall encode the SS‑Status using the mapping defined in this clause from the service states to SS‑Status.
If the HLR Induction State is "Not Induced" then:
‑ If the Provisioning State is "Provisioned", then the P bit shall be 1, otherwise the P bit shall be 0.
‑ If the Registration State is "Registered", the R bit shall be 1. If the Registration State is "Not Registered" the R bit shall be 0. If the Registration State is "Not Applicable" the R bit shall be either 0 or 1.
‑ If the Activation State is "Active and Operative" the A bit shall be 1 and the Q bit shall be 0. If the Activation State is "Active and Quiescent" the A bit shall be 1 and the Q bit shall be 1. If the Activation State is "Not Active" the A bit shall be 0 and the Q bit shall be either 0 or 1.
If the HLR Induction State is "Induced" then the P bit shall be 1, the R bit shall be 0 or 1, the A bit shall be 1 and the Q bit shall be 0.
Table 2.1: Encoding of the P, R, A and Q bits in the SS‑Status parameter
|
HLR Induction State "Not Induced" |
P bit |
R bit |
A bit |
Q bit |
|
Provisioning State "Provisioned" |
1 |
|||
|
Registration State "Registered" |
1 |
|||
|
Activation State "Active and Operative" |
1 |
0 |
|
P bit |
R bit |
A bit |
Q bit |
|
|
HLR Induction State "Induced" |
1 |
0/1 |
1 |
0 |
2.1.2.2 Invocation of services at the HLR
If the service can be invoked at the HLR (e.g. to bar an incoming call) then invocation is possible only if the Activation State is "Active and Operative". Note that the concept of HLR induction does not apply to services invoked at the HLR as the HLR can invoke the effect of these services without needing to induce them first.
2.1.3 Handling of SS‑Status at the VLR or the SGSN
The VLR shall store sufficient information to support VLR based invocation, interrogation and notifications from the VLR to the MS. The SGSN shall store sufficient information to support SGSN based invocation.
The VLR or the SGSN shall not check the internal consistency of SS‑Status values received from the HLR (i.e. it shall not impose any rules relating values of some bits in SS‑Status to other bits). The VLR or the SGSN shall not check that the SS‑Status received from the HLR is valid according to the VLR’s or SGSN’s definition of the relevant service.
2.1.3.1 Invocation of services at the VLR or the SGSN
The ability to invoke the service at the VLR (e.g. to forward a call, or create an MPTY call) is based on the A and Q bits of SS‑Status. The service can only be invoked if A=1 and Q=0. Other bits in SS‑Status are not relevant to invocation at the VLR. .
The ability to invoke the service at the SGSN (i.e. to bar MO SMS submission) is based on the A bit of SS-Status. The service can only be invoked if A=1. Other bits in SS-Status are not relevant to invocation at the SGSN.
2.1.3.2 Interrogation of the service at the VLR and notifications from VLR
If the VLR sends a notification or an interrogation result that includes an SS‑Status parameter the VLR shall set the P, R, A and Q bits to the same values received from the HLR. Unless stated otherwise in individual service specifications, it the service is not provisioned and the VLR has not received a value for SS‑Status from the HLR then if the VLR has to send SS‑Status for that service it shall set the P, R, A, and Q bits to 0.
2.1.4 Handling of SS‑Status at the MS
The MS has to interpret SS‑Status values received from the network. The following information is provided as guidance as to how to treat the SS‑Status information:
‑ The P, A and Q bits are relevant for all phase 2 supplementary services for which the MS may receive SS‑Status information from the network.
‑ The value of the R bit is only relevant if registration is applicable to the supplementary service the SS‑Status relates to.
‑ The A and Q bits shall be treated as a pair with the following meanings assumed:
If A=1 and Q=0, then the service is "Active and Operative";
If A=1 and Q=1, then the service is "Active and Quiescent";
If A=0 and Q=0 or 1, then the service is deactivated.
‑ The MS may assume that if P=0 then the service is also deactivated (and if registration is applicable erased).
‑ If registration is applicable to the service then the MS may assume that if R=0 then the service is also deactivated.
2.2 Handling of call independent SS procedures with respect to basic service groups
A request for registration, erasure, activation, deactivation or interrogation of a supplementary service always refers to a basic service group.
The basic service group may be either an elementary basic service group (defined in 3GPP TS 22.004) or a collective basic service group (defined in 3GPP TS 22.030).
The following text and figure 2.1 describe the general handling of call independent SS procedures in the destination entity with respect to basic service groups.
‑ The VLR or HLR (i.e. the destination entity) shall check the received request for general problems (see figure 2.1 sheet 2 and sheet 3).
‑ In case of general error the procedure shall be terminated by sending an error towards the MS (see figure 2.1 sheet 1).
‑ If there is no general problem, the HLR or VLR shall split the received basic service group (BSG) into elementary basic service groups (EBSG) and continue with separate handling of each elementary basic service group (see figure 2.1 sheet 1).
Note that the received basic service group may be an elementary basic service group. In this case splitting is not required.
‑ Elementary basic service groups shall be ignored if:
‑ there is no basic service provisioned in the group; or
‑ the supplementary service is not applicable for any basic service within this elementary basic service group;
(see figure 2.1 sheet 4).
Note that in case the SS is either not provisioned or all the elementary basic service groups were ignored a general error will be returned (see above).
For interrogation the following handling continues (see figure 2.1 sheet 4):
‑ For all other elementary basic service groups the information requested will be returned to the MS and the procedure is terminated.
For registration/erasure and activation/deactivation the following handling continues (see figure 2.1 sheet 4):
‑ For all other elementary basic service groups the requested procedure will either be executed or rejected due to interaction with other supplementary services.
‑ If the request cannot be accepted for any of these elementary basic service groups due to interaction, the corresponding error will be returned and the procedure is terminated.
‑ If the request was executed for all of these elementary basic service groups an acknowledgement is returned towards the MS and the procedure is terminated.
Note that this acknowledgement will include the same basic service group as received in the request.
‑ In case the request is accepted for some but not for all of these elementary basic service groups, partial acceptance will be signalled towards the MS and the procedure will be terminated.
The return errors for supplementary service operations and applicability of these errors are defined in 3GPP TS 24.080. Detailed description of call independent handling for a specific supplementary service is described in 3GPP TS 23.08x and 23.09x ‑series of technical specifications.
2.3 Exceptional handling of basic service codes
When an individual teleservice code or bearer service code is sent by an MS instead of an elementary basic service group the network shall treat such a request as a request for the corresponding elementary basic service group.
The response to such a request shall include the elementary basic service group code of this basic service code if this is required by the protocol or application.
Figure 2.1 (sheet 1 of 4): Handling of call independent SS procedures with respect to basic service groups
Figure 2.1 (sheet 2 of 4): Handling of call independent SS procedures with respect to basic service groups
Figure 2.1 (sheet 3 of 4): Handling of call independent SS procedures with respect to basic service groups
Figure 2.1 (sheet 4 of 4): Handling of call independent SS procedures with respect to basic service groups