Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 23.016  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   4…   4.5.4… 
4 General on handling of subscriber information  4.1 Updating of the VLR or the SGSN in framed operation  4.2 Updating of VLR and the SGSN in stand alone operation  4.3 Order of information and distribution over message boundaries  4.4 Abstract data structure of shared subscriber data  4.5 Handling of supplementary service data with respect to basic service data  4.5.1 General  4.5.2 Changes to basic service subscription  4.5.3 Special rules for BS61 and BS81 "alternate" and "followed-by" services 

 

4  General on handling of subscriber information  p. 10

In general, the VLR and SGSN stores only a subset of the subscriber data available in the HLR. Similarly, the GGSN stores only a subset of the subscriber data available in the SGSN. Updating of subscriber information shall be done in a way to make available and to keep consistency of data shared between the HLR and the VLR, and between the HLR and the SGSN as appropriate.
Two different cases for the updating of subscriber data can be identified:
  1. framed operation: during location update or restoration a complete set of the shared subscriber data needs to be inserted in the VLR or the SGSN;
  2. stand-alone operation: whenever subscriber data are added, deleted or changed in the HLR, this may need partial insertion, deletion or change of shared subscriber data in the VLR or the SGSN.
Clauses 4.1 to 4.4 explain the actions of the HLR and the VLR or the SGSN within a framed or stand-alone dialogue on subscriber data handling.
Up

4.1  Updating of the VLR or the SGSN in framed operation  p. 11

For some services the VLR or the SGSN shall indicate in the subscriber data request to the HLR whether it supports the service, or (in case of a service with multiple phases) which phases it supports. Whether or not this indication is required for the service is defined in service specification.
If requested by the framing operation, the HLR shall send all relevant stored shared subscriber data to the VLR or the SGSN. This may be done with one or more messages within a single dialogue.
For services for which the VLR or the SGSN is required to indicate support of the service, the HLR shall send subscriber data to the VLR or the SGSN only if corresponding indication was received from the VLR or the SGSN in the subscriber data request. If both the originating entity and the HLR support the Super-Charger functionality the HLR may provide no subscriber data as part of the location update procedure, see TS 23.116. For control of stand-alone operation the HLR shall store the information for which of these services the subscriber data was sent.
For services for which the VLR or the SGSN is required to indicate supported phases of the service, the HLR shall send subscriber data to the VLR for at most one of the supported phases of service indicated in the subscriber data request. In this case the HLR may send also no data at all if none of the supported phases is suitable. For the case of stand-alone operation the HLR shall store the information for which phase of service the data was sent.
The HLR may send all stored shared subscriber data to the VLR or the SGSN with one or more messages within a single dialogue.
The VLR or the SGSN shall check the received messages, and:
  1. if mandatory data is missing in a message:
    • the VLR or the SGSN may immediately reject the message towards the HLR; or
    • the VLR or the SGSN may acknowledge the message towards the HLR and wait for further data from the HLR.
  2. if unexpected data are received in a message:
    • the VLR or the SGSN may reject the message towards the HLR; or
    • in case of unexpected data not required in a given context, the VLR or the SGSN may acknowledge the message towards the HLR and ignore this unexpected data. All other data shall be stored by the VLR or the SGSN.
  3. if data for unsupported services or features is received:
    • the VLR or the SGSN shall respond towards the HLR to the message indicating these features and shall ignore all received data related to them. All other subscriber data shall be stored;
  4. if cases a), b) and c) do not apply for a message, the VLR or SGSN shall store all subscriber data received.
If during the entire dialogue none of the messages was rejected by the VLR or the SGSN and at termination of the dialogue no mandatory subscriber data are missing, the VLR or the SGSN shall erase all previously stored data and shall store the data received from the HLR and mark the subscriber data as "confirmed by HLR". Otherwise the subscriber data shall remain marked as "not confirmed by HLR" (see TS 23.007).
The HLR shall check all responses from the VLR or the SGSN, and:
  1. if a message is rejected, no further updating of the VLR or the SGSN shall occur. The further action on the framing operation is out of scope of this specification;
  2. if one or more unsupported features are indicated by the VLR or the SGSN, the HLR may:
    • store subscriber data including replacement feature(s) locally;
    • store and send subscriber data including replacement feature(s);
    • ignore this indication.
  3. if a message is acknowledged by the VLR or the SGSN, this shall be recognized by the HLR.
The further action on the framing operation after all shared subscriber and replacement data have been sent (e.g. closing of the dialogue) is out of scope of this specification.
Up

4.2  Updating of VLR and the SGSN in stand alone operation  p. 12

If shared subscriber data are added, deleted or changed in the HLR, the HLR shall insert or delete this subscriber data in the VLR or the SGSN to keep consistency of data stored.
For services for which the VLR or the SGSN is required to indicate support of the service in the request, the HLR shall insert or delete this subscriber data in the VLR or the SGSN only if an appropriate indication is stored in the HLR (see clause 4.1).
For services for which the VLR or the SGSN is required to indicate supported phases of the service in the request, the HLR shall insert or delete subscriber data in the VLR or the SGSN only if it was added, deleted or changed for the phase of the service for which the data was sent to the VLR or the SGSN in the framed operation.
Up

4.2.1  Insertion of data in the VLR or the SGSN  p. 12

For the insertion of data, the HLR may send one or more messages in a single dialogue.
The VLR or the SGSN shall check the received data, and:
  1. if mandatory data is missing in a message:
    • the VLR or the SGSN may reject the message towards the HLR; or
    • the VLR or the SGSN may acknowledge the message towards the HLR and wait for further data from HLR.
  2. if unexpected data are received:
    • the VLR or the SGSN may reject the message towards the HLR; or
    • in case of unexpected data not required in a given context, the VLR or the SGSN may acknowledge the message towards the HLR and ignore this unexpected data. All other data shall be stored by the VLR or the SGSN.
  3. if data for unsupported services or features is received:
    • the VLR or the SGSN shall respond towards the HLR to the message indicating these features and shall ignore all data assigned to them. All other subscriber data shall be stored.
  4. if cases a), b) and c) do not apply for a message, the VLR or the SGSN shall store all subscriber data received.
If during the entire dialogue none of the messages was rejected by the VLR or the SGSN and at termination of the dialogue no subscriber data are missing, the VLR or the SGSN shall mark the subscriber data as "confirmed by HLR". Otherwise the subscriber data shall be marked as "not confirmed by HLR" (see TS 23.007).
The HLR shall check all responses from the VLR or the SGSN, and:
  1. if a message is rejected no further updating of the VLR or the SGSN is allowed and the HLR shall terminate the dialogue;
  2. if one or more unsupported features are indicated by the VLR or the SGSN, the HLR may:
    • store subscriber data including replacement feature(s) locally;
    • store and send subscriber data including replacement feature(s);
    • ignore this indication.
  3. if a message is acknowledged by the VLR or the SGSN, this shall be recognized by the HLR.
After all required shared subscriber and replacement data have been sent, the HLR shall terminate the dialogue with the VLR or the SGSN.
Up

4.2.2  Deletion of data in the VLR or the SGSN  p. 13

Deletion needs a separate dialogue.
HLR and VLR or SGSN actions are the same as above except for the following case:
  • if, in response to deletion, one or more unsupported features are indicated by the VLR or the SGSN, the HLR may:
    • delete subscriber data including replacement feature(s) locally;
    • delete subscriber data including replacement feature(s) locally and in the VLR or the SGSN (NOTE);
    • take no further action.
The VLR or SGSN shall terminate the dialogue VLR or SGSN the response to the HLR.
Up

4.2.3  Change of data in the VLR or in the SGSN  p. 13

If existing data in the VLR or the SGSN is to be modified, the HLR may insert the replacing data, which overwrites the existing data according to the rules described in clause 4.4. Alternatively, the HLR may delete the existing data as described in clause 4.2.2 and then insert the replacing data as described in clause 4.2.1.
Up

4.3  Order of information and distribution over message boundaries  p. 13

4.3.1  Order of information sent by the HLR  p. 13

The order of information is defined by the order in which the transfer syntax is generated by the HLR. This includes a sequence of messages as well as the syntax within a message (first to last message, component, operation, parameter, etc...).
With the above definitions, the following rules shall apply for non-GPRS subscriber data for the order of information within an HLR-VLR dialogue:
  • Group A information (subscriber status) shall be sent first;
  • Group B information shall be sent after Group A information and before any Group C, E, F, G, H, J, L, M or X information;
  • Group D information shall be sent after Group A information and in any order with respect to Group B, C, E, F, G, H, J, K, L, M and X information;
  • a specific order of Group C, E, F, G, H, J, K, L, M or X information is not required.
There is no requirement for the sending of subscriber information groups in the same message.
With the above definitions, the following rules shall apply for GPRS subscriber data for the order of information within a dialogue:
  • Group P1 information (subscriber status) shall be sent first;
  • Group P2 information shall be sent after P1 information and before P4 and P5 information;
  • Group P3 information shall be sent after Group P1 information and in any order with respect to Group P2, P4, P5, P6, P6a, P7, P8, P11 and P12 information;
  • a specific order of Group P4, P5, P6, P6a, P9, P10, P11 and P12 information is not required.
Up

4.3.2  Order of information received by the VLR or the SGSN  p. 14

Normally, the order of information sent and received shall be identical. However, if subscriber data are sent distributed over several messages within a dialogue in exceptional cases the order of these messages may change during transmission.
If the order of information received violates the rules given above, the VLR or the SGSN has the following options:
  • the VLR or the SGSN rejects all messages which cannot be processed due to violation of these rules. In this case, checking of missing mandatory parameters is done for each message;
  • the VLR or the SGSN processes and accepts all received messages although rules are violated. In this case, checking of missing mandatory parameters is done after the last message i.e. after termination of the dialogue.
Both options may be used in a single implementation. Missing parameters may be detected during the dialogue. For other parameters, the checking is done after termination of the dialogue between the HLR and the VLR or the SGSN.
The VLR or the SGSN is not required to handle received data in a specific order. As a consequence, any overlapping of data within a dialogue should be avoided to keep consistency of data between HLR and VLR or the SGSN. If the VLR or SGSN indicates that it does not support a feature or service, the HLR may send data for a feature or service to replace the unsupported one. If the data of that service or feature had already been sent, this shall not be regarded as overlapping data.
Up

4.4  Abstract data structure of shared subscriber data  p. 14

Figure 1 shows the general organization of the shared non-GPRS subscriber data stored in the HLR and VLR. Figure 2 shows the overall organization of subscriber data stored in HLR and SGSN. The figures 3 to 25 show the organization of the shared subscriber data stored in the HLR and VLR or in the HLR and SGSN. This structure is only valid for data stored in the registers and is not identical with the structure in the protocol, defining how data are transferred.
With this structure, the following general rules for the handling of subscriber data are defined:
  • the root of this data tree is always the IMSI which identifies the subscriber;
  • to address a specific parameter within this hierarchical tree, it is necessary to start from the IMSI and to go through the branches until the parameter is reached. The list of parameters met on the way defines the address of the parameter within the data structure;
  • to delete or insert a specific parameter, the complete address information is required;
  • if a parameter is inserted, all parameters in the address and the parameter itself shall be marked as present. A parameter value is stored irrespective of whether a value was already stored;
  • if a parameter is deleted, all parameters connected to it in the sub-branches are also deleted i.e. they are marked as not present;
  • if a parameter is overwritten with a new value, parameters connected to it in the sub-branches shall be set according to the rules of the individual service specification.
In addition to the general rules given above, special rules apply to certain specific subscriber data. This is out of scope of this specification (see references in the notes in figures 1 to 25).
Up

4.5  Handling of supplementary service data with respect to basic service data  p. 15

Some supplementary service data is qualified by Elementary Basic Service Group (EBSG) data. This part of the service data is below the parameter "BSG" in the abstract data hierarchy, and is referred to as the "EBSG-related SS data". This clause provides special rules for handling of EBSG-related SS data.
The internal representation of EBSGs and EBSG-related SS data in the HLR and VLR is outside the scope of this specification. For simplicity this description uses a model where all EBSG-related SS data is stored against individual EBSGs. Implementations may use alternative internal data structures.
Up

4.5.1  General  p. 15

EBSG-related SS data shall be stored in the HLR and VLR for all EBSGs that meet all the following criteria:
  • at least one basic service in the EBSG is supported; and
  • the supplementary service is applicable to at least one (possibly different) basic service in the EBSG; and
  • the subscriber has a subscription to at least one (possibly different) basic service in the EBSG.
EBSG-related SS data shall not be stored for any other EBSGs.
For each service for which the HLR sends EBSG-related SS data to the VLR, the HLR shall send the data for all EBSGs that meet all the following criteria:
  • at least one basic service in the EBSG is supported at the HLR; and
  • the supplementary service is applicable to at least one (possibly different) basic service in the EBSG; and
  • the subscriber has a subscription to at least one (possibly different) basic service in the EBSG.
At any time, if the HLR has to send identical EBSG-Related SS data for several EBSGs, then it may be able to represent a set of EBSGs by a collective basic service group (CBSG), or by omitting the EBSG information altogether. This is specified in detail in TS 29.002.
Up

4.5.2  Changes to basic service subscription  p. 15

Changes to the basic service subscription can impact EBSG-related SS data.
If a new basic service is provisioned, and this is the first basic service to be provisioned for this subscriber in a particular EBSG, then the HLR shall update supplementary service data in the VLR if necessary. The HLR shall insert in the VLR EBSG-related SS data for the new EBSG for all supplementary services that:
  • have EBSG-related SS data; and
  • are applicable to at least one basic service in the new EBSG; and
  • are in a state where the VLR should receive data (normally this means the service must be provisioned).
If a new basic service is provisioned, and this is not the first basic service provisioned for this subscriber in a particular EBSG, then the HLR is not required to send any new supplementary service data as a result.
If a basic service is withdrawn, and this was the last remaining basic service provisioned for this subscriber in a particular EBSG, then when they are informed about the withdrawal of the basic service the HLR and VLR shall locally delete any supplementary service data relating to that EBSG.
If a basic service is withdrawn, and this was not the last remaining basic service provisioned for this subscriber in a particular EBSG, then the HLR and VLR shall not make any changes to supplementary service data as a result.
Up

4.5.3  Special rules for BS61 and BS81 "alternate" and "followed-by" services  p. 16

There is no EBSG-related SS data for the groups BS61 and BS81 ("alternate" and "followed-by"). Instead, supplementary services related to these basic services are handled according to the bearer service group BS2x or BS3x corresponding to the data part of the "alternate" and "followed by" bearer service (see TS 22.004). This means that special rules are required for subscribers with subscriptions to BS61 or BS81.
For the handling of EBSG-related SS data, a subscription to BS61 or BS81 shall be treated in the same way as a subscription to a basic service in each of the groups "all data circuit asynchronous" and "all data circuit synchronous" (BS2x and BS3x). If a user subscribes to BS61 or BS81 then the HLR shall send any relevant EBSG-related SS data to the VLR for the groups BS2x and BS3x even if the subscriber does not subscribe to any basic services in the groups BS2x and BS3x.
Examples:
  • if a user who does not subscribe to any basic services in BS2x or BS3x is given a subscription to BS81 then the HLR updates the VLR with any relevant EBSG-related SS data for the groups BS2x and BS3x. If the subscription to BS81 is then withdrawn, the VLR locally deletes all EBSG-related SS data for BS2x and BS3x.
  • if a user who has a subscription to BS21, but not to any basic services in BS3x is given a subscription to BS81 then the HLR updates the VLR with any relevant EBSG-related SS data for the group BS3x. If the subscription to BS81 is then withdrawn, the VLR locally deletes all EBSG-related SS data for BS3x (though not for BS2x).
EBSG-related SS data shall not be qualified by the groups BS61 or BS81.
Up

Up   Top   ToC