MME/SGSN Topology Hiding is concerned with hiding the identity of a Protected Home Network's MME/SGSNs and the number of MME/SGSNs in the network, when it exchanges messages with Untrusted Networks. A MME/SGSN's identity is embedded in the Origin-Host and Session-Id AVPs sent in Request messages and in the Origin-Host AVP sent in Answer messages. MME/SGSN Topology Hiding is associated with the Diameter S6a/S6d application message set defined in 3GPP TS 29.272, "Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol".
MME/SGSN Topology Hiding determines which entity (HSS or MME/SGSN) initiated an S6a/S6d message based on the Command Code in the message.
MME/SGSN identities are hidden by replacing the Actual Hostname portion of the Origin-Host and Session-Id AVPs (Session-Id format: <host name><implementation portion>) with an MME/SGSN Pseudo Hostname. The Origin-Host and Session-Id AVPs can have different MME/SGSN Hostnames. A unique Pseudo Hostname must be created for each MME/SGSN in a Protected Network. When the MME/SGSN initiates a transaction to the HSS, the HSS saves the MME/SGSN's identity for use in subsequent HSS-to-MME/SGSN transactions. This MME/SGSN Pseudo Hostname must not only be unique, but the DEA must be able to convert the MME/SGSN's Pseudo Hostname to an Actual MME/SGSN Hostname for these subsequent HSS-to-MME/SGSN transactions.
In order to hide the number of MME/SGSNs in a network, each MME/SGSN will be assigned either a random or fixed number of Pseudo Hostnames. A maximum number is defined by the Count in the Pseudo Hostname Generation attribute of the MME/SGSN Topology Hiding Configuration Set. The Randomize Count creates a random number of Pseudo Hostnames, between 1 and the Count value, that are associated with an Actual Hostname. This procedure of creating randomized MME/SGSN Pseudo Hostnames and assigning them to an Actual Pseudo Hostname is performed by the GUI, then used by the Diameter Routing Function. The created MME/SGSN TH Hostnames allow the Diameter Routing Function to map a Protected-MME/SGSN Actual Hostname to a set of MME/SGSN Pseudo Hostnames, and to map a MME/SGSN Pseudo Hostname received from an Untrusted-HSS to a Protected-MME/SGSN Actual Hostname.
Table 1 shows an example of MME/SGSN TH Host Names configuration for a Protected Network with a maximum of 3 randomly created Pseudo Hostnames.
Example of Configuration of MME/SGSN TH Hostnames for a Protected Network
MME/SGSN TH Configuration Set Name
|
MME/SGSN Actual Hostname
|
MME/SGSN Pseudo Hostnames
|
Protected Network-1 MME/SGSN Config
|
mme1.westregion.example.com
|
mme042.example.com
mme821.example.com
|
Protected Network-1 MME/SGSN Config
|
mme1.westregion.example.com
|
mme123.example.com
|
Protected Network-1 MME/SGSN Config
|
mme2.westregion.example.com
|
mme533.example.com
mme773.example.com
mme092.example.com
|
Protected Network-1 MME/SGSN Config
|
mme1.eastregion.example.com
|
mme922.example.com
mme729.example.com
|
Protected Network-1 MME/SGSN Config
|
mme2.eastregion.example.com
|
mme411.example.com
mme002.example.com
mme655.example.com
|
Protected Network-1 MME/SGSN Config
|
mme2.eastregion.example.com
|
mme218.example.com
|
Protected Network-1 MME/SGSN Config
|
mme2.eastregion.example.com
|
mme331.example.com
mme249.example.com
mme447.example.com
|
Protected Network-1 MME/SGSN Config
|
mme1.texasregion.example.com
|
mme776.example.com
mme077.example.com
|
Protected Network-1 MME/SGSN Config
|
mme1.texasregion.example.com
|
mme295.example.com
mme622.example.com
mme861.example.com
|
Protected Network-1 MME/SGSN Config
|
mme1.texasregion.example.com
|
mme333.example.com
|
Protected-MME/SGSN to Untrusted-HSS Transactions
For Protected-MME/SGSN to Untrusted-HSS Diameter transactions, MME/SGSN Topology Hiding is concerned with the following topology information hiding and restoral issues:
- The AVPs containing an MME/SGSN's Actual Hostname in Request messages must be hidden with one of the Pseudo Hostnames assigned to the MME/SGSN at TH Trigger Point RTH.
- The HSS saves the subscriber's location using the Origin-Host AVP contents containing a Pseudo Hostname. In subsequent HSS-to-MME/SGSN transactions, the MME/SGSN will be addressed by one of its Pseudo Hostnames, requiring a Pseudo-to-Actual Hostname restoral.
- All MME/SGSN-to-HSS transactions associated with a particular subscriber must use the same MME/SGSN Pseudo Hostname. Otherwise, the HSS will think that the subscriber has moved to another MME/SGSN and unnecessarily change the subscriber's location. For S6a/S6d transactions, the subscriber associated with the transaction is identified by an IMSI, which for the S6a/S6d message set is embedded in the User-Name AVP, a mandatory AVP in all MME/SGSN-to-HSS Request messages.
Note: Although the Origin-Host and Session-Id AVPs both have MME/SGSN Actual Hostnames, the names could be different. Because the HSS associates the MME/SGSN's location based on the Origin-Host AVP content, it is the MME/SGSN Actual Hostname in the Origin-Host AVP that must be used for selecting a MME/SGSN Pseudo Hostname. This MME/SGSN Pseudo Hostname can be used to replace both of the Hostname fields in the forwarded Request message.
- The HSS sends an Answer response to the transaction with the Session-Id received in the Request and containing an MME/SGSN Pseudo Hostname. Because the Session-Id value returned in the Answer must match the value in the Request, the MME/SGSN Pseudo Hostname in the Session-Id AVP must be replaced with its corresponding value received in the Request message. The value is restored at TH Trigger Point ATR, with the Hostname portion of the Session-Id AVP value that is stored in the PTR.
This Hostname restoral procedure is not required for Answers initiated by DSR internal nodes (the Diameter Routing Function and DSR Applications) as these Answer responses are based upon the original Request message content.
An example of a Protected-MME/SGSN to Untrusted-HSS Diameter transaction is shown in Figure 1.
MME/SGSN TH Protected-MME/SGSN to Untrusted HSS Transaction
In S6a/S6d, the subscriber's
IMSI is carried in the User-Name AVP. The content of the User-Name AVP content can be one of the following forms:
It is not necessary to extract the IMSI portion from the User-Name AVP value. The User-Name AVP value content will be the same in all transactions associated with subscriber.
For Protected-MME/SGSN to Untrusted-HSS transactions, S6a/S6d HSS Topology Hiding is required only on Request messages that meet the following criteria:
- Message was a candidate for Topology Hiding as defined by topology Trigger Point RTH in Table 6
- MME/SGSN Topology Hiding is enabled for the Protected Network (an MME/SGSN TH Configuration Set is assigned to the Protected Network)
- The Request message is a member of the S6a/S6d message set and was initiated by an MME/SGSN as determined from the Command Code in the message
- The Origin-Host and/or Session-Id AVPs in the Request contain an MME/SGSN Actual Hostname assigned to the Protected Network in its MME/SGSN Topology Hiding Configuration Set.
For Protected-MME/SGSN to Untrusted-HSS transactions, MME/SGSN topology information restoral is performed only on Answer messages that meet the following criterion:
- At TH Trigger Point ATR, the MME/SGSN TH ATR flag in the PTR associated with the Answer message is set to "Enabled".
Untrusted-HSS to Protected-MME/SGSN Transactions
When an Untrusted-HSS initiates a transaction to a Protected-MME/SGSN, it is typically addressed to one of the MME/SGSN's Pseudo Hostnames that the HSS saved in a previous MME/SGSN-to-HSS transaction for which MME/SGSN Topology Hiding was applied. For Untrusted-HSS to Protected-MME/SGSN Diameter transactions, MME/SGSN Topology Hiding is concerned with the following topology information hiding and restoral issues:
An example of an Untrusted-HSS to Protected-MME/SGSN Diameter transaction is shown in Figure 2.
MME/SGSN TH Untrusted-HSS to Protected MME/SGSN Transaction
For Untrusted-HSS to Protected-MME/SGSN transactions, S6a/S6d HSS Topology Hiding is invoked only on Request messages that meet the following criteria:
- Message was a candidate for topology Hiding as defined by TH Trigger Point RTR in Table 6
- MME/SGSN Topology Hiding is enabled for the Protected Network (an MME/SGSN Topology Hiding Configuration Set is assigned to the Protected Network)
- The Request message is a member of the S6a/S6d message set and was initiated by an MME/SGSN as determined from the Command Code in the message
- The Destination-Host AVP contains a MME/SGSN Pseudo Hostname that is assigned to the Protected Network as determined from the list of created MME/SGSN TH Host Names described in MME/SGSN Topology Hiding.
For Untrusted-HSS to Protected-MME/SGSN transactions, S6a/S6d HSS Topology Hiding is invoked only on Answer messages at TH Trigger Point ATH that meet the following criteria:
- Message was a candidate for Topology Hiding as defined by topology Trigger Point ATH in Table 6
- MME/SGSN Topology Hiding is enabled for the Protected Network (an MME/SGSN Topology Hiding Configuration Set is assigned to the Protected Network)
- The Answer message is a member of the S6a/S6d message set and was initiated by an MME/SGSN as determined from the Command Code in the message
- The Origin-Host AVP contains an MME/SGSN Actual Hostname that is assigned to the Protected Network in its MME/SGSN Topology Hiding Configuration Set.