MME/SGSN Topology Hiding
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.
To hide the number of MME/SGSNs in a network, each MME/SGSN is 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 9-16 shows an example of MME/SGSN TH Host Names configuration for a Protected Network with a maximum of 3 randomly created Pseudo Hostnames.
Table 9-16 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
- 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 is 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
thinks the subscriber has moved to another MME/SGSN and unnecessarily changes
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 diameter internal nodes (the Diameter Routing Function and 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 9-15.
Figure 9-15 MME/SGSN TH Protected-MME/SGSN to Untrusted HSS Transaction
- IMSI
- IMSI@realm
It is not necessary to extract the IMSI portion from the User-Name AVP value. The User-Name AVP value content is the same in all transactions associated with subscriber.
- Message was a candidate for Topology Hiding as defined by topology Trigger Point RTH in Table 9-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.
- 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
- The Destination-Host AVP contains a MME/SGSN Pseudo Hostname that must be replaced with the MME/SGSN's Actual Hostname at TH Trigger Point RTR. Pseudo-to-Actual Hostname mapping is performed using the list of created MME/SGSN TH Hostnames described in MME/SGSN Topology Hiding. It is acceptable that an Untrusted-HSS to Protected-MME/SGSN Request message does not contain a MME/SGSN Pseudo Hostname. If the Destination-Host AVP value does not match an entry in the MME/SGSN TH Host Names list, then no Hostname conversion is required and the Request message is routed normally. Destination-Hostname conversion is performed to prevent the following problems:
- Certain MME/SGSNs do not accept messages that do not contain its Actual Hostname.
- Diameter routing problems associated with Pseudo
Hostnames. For example, Diameter Implicit Routing works only with Actual
Hostnames (such as the FQDN assigned to the Peer Node and used for the
Capabilities Exchange procedure [CER/CEA]).
Note:
For local nodes, CEAs are sent in response to erroneous CERs. - An Origin-Host AVP containing an MME/SGSN's Actual Hostname in the Answer response from the Protected-MME/SGSN must be hidden with one of the Pseudo Hostnames assigned to that MME/SGSN. This is done at TH Trigger Point ATH.
An example of an Untrusted-HSS to Protected-MME/SGSN Diameter transaction is shown in Figure 9-16.
Figure 9-16 MME/SGSN TH Untrusted-HSS to Protected MME/SGSN Transaction
- Message was a candidate for topology Hiding as defined by TH Trigger Point RTR in Table 9-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.
- Message was a candidate for Topology Hiding as defined by topology Trigger Point ATH in Table 9-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.