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.060  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   5…   5.3.8…   5.4…   5.4.2…   5.4.9…   5.6…   5.6.2   5.6.3…   5.6.3.7…   5.7…   6…   6.3…   6.5…   6.6…   6.8…   6.9…   6.9.1.3   6.9.2…   6.9.2.2…   6.9.2.2.2   6.9.2.2.3…   6.9.2.2.5…   6.9.3…   6.10…   6.12…   6.13…   6.13.1.2…   6.13.2…   6.13.2.2   6.14…   8…   8.2   9…   9.2.2…   9.2.2.2   9.2.2.3…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.4.2…   9.2.5…   12…   12.5…   12.6…   12.7…   12.8…   13…   14…   15…   15.3…   16…   16.2…   A…   B… 
6.10 Tunnelling of non-GSM Signalling Messages Function (A/Gb mode)  6.11 Subscriber Management Function 
...

 

6.10  Tunnelling of non-GSM Signalling Messages Function (A/Gb mode)  p. 171

Tunnelling of Messages (TOM) is an optional protocol layer that uses the LLC unacknowledged mode procedures to tunnel messages between the MS and the SGSN (see TS 44.064). TOM uses two LLC SAPs for communication between the MS and the SGSN; one for high-priority messages and one for low-priority messages. A network that supports TIA/EIA 136 [49] shall support the TOM protocol and the Gs interface.
Upon receiving a non-GSM signalling message from an MS via the TOM protocol, the SGSN forwards the message to a non-GSM MSC/VLR using the BSSAP+ protocol (see GSM 09.18). The specific Gs interface used by the SGSN is determined by the:
  • RAI associated with the current location of the MS when the SGSN does not provide functionality for the Intra Domain Connection of RAN Nodes to Multiple CN Nodes. When the SGSN provides functionality for Intra Domain Connection of RAN Nodes to Multiple CN Nodes, the SGSN uses the RAI and a hash value from the IMSI to determine the Gs interface; and
  • information in the TOM protocol header.
Upon receiving a non-GSM signalling message from a non-GSM MSC/VLR via the BSSAP+ protocol, the SGSN forwards the message to a specific MS using the TOM protocol. The specific MS is determined by the SGSN based on the content of the BSSAP+ header.
The control plane between an MS and a non-GSM MSC/VLR that uses tunnelling procedures for non-GSM signalling is shown in Figure 45.
Reproduction of 3GPP TS 23.060, Fig. 45: Control Plane MS - Non-GSM MSC/VLR
Figure 45: Control Plane MS - Non-GSM MSC/VLR
Up

6.10.1  Uplink Tunnelling of non-GSM Signalling Messages Procedure  p. 171

The Uplink Tunnelling of non-GSM Signalling Messages procedure is illustrated in Figure 46.
Reproduction of 3GPP TS 23.060, Fig. 46: Uplink Tunnelling of non-GSM Signalling Messages Procedure
Figure 46: Uplink Tunnelling of non-GSM Signalling Messages Procedure
Up
Step 1.
The MS sends a TOM Protocol Envelope (Non-GSM Signalling Message) to the SGSN either in ciphered or clear mode. The TOM protocol header contains information about the application using the TOM facility and any other TOM Protocol Discriminator-specific information. The TOM Protocol Envelope is received on one of the two LLC SAPs used for tunnelling of messages.
Step 2.
The SGSN identifies the non-GSM MSC/VLR to which to forward the non-GSM signalling message. It then sends a BSSAP+ Uplink Tunnel Request (IMSI, SGSN Address, TOM Priority, Cipher, Non-GSM Signalling Message) message to the identified non-GSM MSC/VLR. The Cipher parameter is set to cipher if the TOM Protocol Envelope was received in ciphered form by the LLC layer. Otherwise, it is set to not cipher. TOM Priority is set to high priority if the TOM Protocol Envelope was received on the high-priority LLC SAP, Otherwise, it is set to low priority.
Up

6.10.2  Downlink Tunnelling of non-GSM Signalling Messages Procedure  p. 172

The Downlink Tunnelling of non-GSM Signalling Messages procedure is illustrated in Figure 47.
Reproduction of 3GPP TS 23.060, Fig. 47: Downlink Tunnelling of non-GSM Signalling Messages Procedure
Figure 47: Downlink Tunnelling of non-GSM Signalling Messages Procedure
Up
Step 1.
The non-GSM MSC/VLR sends a BSSAP+ Downlink Tunnel Request (IMSI, VLR Address, TOM Priority, Cipher, Non-GSM Signalling Message) message to the SGSN associated with the MS. TOM Priority indicates whether the SGSN shall select the high-priority or low-priority LLC SAP when forwarding the non-GSM signalling message to the MS. Cipher indicates whether or not the SGSN shall cipher the non-GSM signalling message before forwarding it to the MS.
Step 2.
The SGSN sends a TOM Protocol Envelope (Non-GSM Signalling Message) to the MS using the selected LLC SAP.
Up

6.11  Subscriber Management Function  p. 172

The Subscriber Management function provides a mechanism to inform the nodes about changes of the subscription data for a specific subscriber.

6.11.1  Subscriber Management Procedures  p. 172

Whenever the GPRS subscription data is changed for a subscriber in the HLR/HSS, and the changes affect the GPRS subscription data stored in the SGSN, the SGSN node shall be informed about these changes by means of the following procedures:
  • Insert Subscriber Data procedure, used to add or modify subscription data in the SGSN; or Delete Subscriber Data procedure, used to remove PS subscription data in the SGSN.
  • Delete Subscriber Data procedure, used to remove subscription data from the SGSN.

6.11.1.1  Insert Subscriber Data Procedure  p. 172

In addition to the insertion and modification of general subscription data for a PS subscriber, see TS 29.002, the HLR may request the insertion or modification of one or several new or existing PDP subscription contexts in the SGSN. It should be noted that the modification may trigger a PDP Context Modification procedure as described in clause "Modification Procedures". In particular, the following PDP context parameters may be modified by the HLR:
  • QoS Profile Subscribed;
  • Subscribed Evolved ARP; and
  • VPLMN Address Allowed.
The Insert Subscriber Data procedure is illustrated in Figure 48.
Reproduction of 3GPP TS 23.060, Fig. 48: Insert Subscriber Data Procedure
Figure 48: Insert Subscriber Data Procedure
Up
1)
The HLR sends an Insert Subscriber Data (IMSI, Subscription Data) message to the SGSN.
2)
The SGSN updates its GPRS subscription data and acknowledges the Insert Subscriber Data message by returning an Insert Subscriber Data Ack (IMSI) message. For each PDP context that is included in Subscription Data the SGSN shall check whether it is a new, an active, or an inactive PDP context:
For architecture variants using Gn/Gp based interaction with GGSN the PDP contexts are handled as follows:
  • For a new or inactive PDP context, no further action is required except storage in the SGSN.
  • For an active PDP context, the SGSN shall in addition compare the new QoS Subscribed with QoS Negotiated, new Subscribed Evolved ARP with the previously stored Subscribed Evolved ARP, respectively and shall, if necessary and MS is in the READY or PMM CONNECTED State, initiate a PDP Context Modification procedure as described in clause "Modification Procedures". If modification is necessary, when MS is not in the READY or PMM CONNECTED State, or the modification is not successful when MS is in the READY or PMM CONNECTED State, the SGSN shall directly delete the concerned PDP context(s). PDP Context Modification due to changes in Subscribed Evolved ARP may be skipped if there is no previously stored value for Subscribed Evolved ARP.
  • For an MS in PMM-CONNECTED State and connected via a CSG or hybrid cell, the SGSN shall check the received CSG subscription data. If the SGSN detects that the UE's CSG membership to that cell has changed or expired, the SGSN initiates the procedure in clause 9.2.3.7.
For architecture variants using S4 based interaction with S-GW and P-GW, the PDP contexts are handled as follows:
  • For a new or inactive PDP context, no further action is required except storage in the SGSN.
  • For an active PDP context, the SGSN shall in addition compare the new QoS Subscribed with bearer QoS and shall, if necessary and MS is in the READY or PMM CONNECTED State, initiate a PDP Context Modification procedure as described in clause "Modification Procedures". If modification is necessary, when MS is not in the READY or PMM CONNECTED State, or the modification is not successful when MS is in the READY or PMM CONNECTED State:
    1. If ISR is activated when the next activity from MS is detected the S4-SGSN shall compare the stored updated subscription data with the existing data for that PDP context and initiate modification procedure.
    2. If ISR is not activated, the SGSN shall directly delete the concerned PDP context.
  • For an MS in PMM-CONNECTED State and connected via a CSG or hybrid cell, the SGSN shall check the received CSG subscription data. If the SGSN detects that the UE's CSG membership to that cell has changed or expired, the SGSN initiates the procedure in clause 9.2.3.7.
Furthermore, if VPLMN Address Allowed is changed, the SGSN shall, if necessary (e.g., if the PDP context is currently routed via a GGSN in the VPLMN and VPLMN Address Allowed is changed to not allowed), initiate a PDP Context Deactivation procedure as explained in clause 9.2.4.
Up

6.11.1.2  Delete Subscriber Data Procedure |R5|  p. 173

In addition to the deletion of general subscription data for a subscriber, see TS 29.002, the HLR may request the deletion of one or several PDP contexts from the SGSN.
The Delete Subscriber Data procedure is illustrated in Figure 49.
Reproduction of 3GPP TS 23.060, Fig. 49: Delete Subscriber Data Procedure
Figure 49: Delete Subscriber Data Procedure
Up
1)
The HLR sends a Delete Subscriber Data (IMSI, PDP Context Identifiers List) message to the SGSN.
2)
The SGSN acknowledges the Delete Subscriber Data message by returning a Delete Subscriber Data Ack (IMSI) message. For each PDP context identifier included in PDP Context Identifiers List, the SGSN shall check whether it belongs to an active or an inactive PDP context:
  • For an inactive PDP context no further action is required except deletion of the PDP context.
  • For an active PDP context, the SGSN shall initiate the PDP Context Deactivation Initiated by the SGSN procedure as explained in clause "Deactivation Procedures" before the PDP context is deleted.
Up

6.11.1.3  Insert CSG Subscriber Data Procedure |R11|  p. 174

The CSS may request insertion of new or modification of existing CSG subscription data in the SGSN. Whenever the CSG subscription data is changed for a user in the CSS, and the changes affect the CSG subscription data stored in the SGSN, the CSS shall inform the SGSN about these changes by the means of the Insert CSG Subscriber Data procedure.
The CSS Subscription data is stored and managed in the SGSN independently from the CSG Subscription Data received from the HLR/HSS. The Insert CSG Subscriber Data procedure only affects the CSS Subscription data.
The Insert CSG Subscriber Data procedure for the CSS is illustrated in Figure 49a.
Reproduction of 3GPP TS 23.060, Fig. 49a: Insert CSG Subscriber Data Procedure
Figure 49a: Insert CSG Subscriber Data Procedure
Up
1)
The CSS sends an Insert CSG Subscriber Data (IMSI, CSG Subscription Data) message to the SGSN.
2)
The SGSN updates the stored CSG Subscription Data and acknowledges the Insert CSG Subscriber Data message by returning an Insert CSG Subscriber Data Ack (IMSI) message to the CSS. The update result should be contained in the Ack message.
For an MS in PMM-CONNECTED State and connected via a CSG or hybrid cell, the SGSN shall check the received CSG subscription data. If the SGSN detects that the UE's CSG membership to that cell has changed or expired, the SGSN initiates the procedure in clause 9.2.3.7.
Up

Up   Top   ToC