2.13.4 Gateway Location Application (GLA)

The DSR based PCA PDRA function manages state required to route Gx, Rx and other policy related Diameter sessions. The Policy DRA SBR-B is a network wide repository for that state.

Customers are recognizing the value of having a centralized, network wide repository for binding state and are identifying additional ways to leverage the Policy DRA managed state.

The Gateway Location Application (GLA) provides a Diameter signaling approach for accessing that binding state. The GLA gives the ability to retrieve the Diameter identity that initiated Gx sessions for a given IMSI or MsISDN.

A use case for this application is an IMSI query with a single matching Gx session. The figure below shows this use case where the GGR message includes a query that has IMSI as the query key. In this example a single Gx session matches the query.

Figure 2-59 IMSI Query with Single Matching Gx Session Use Case

The steps for this use case are as follows:

• Existing Policy DRA handling of a Gx CCR-I session. This session is the first for the IMSI and results in anew binding.
• The Policy DRA application stores the gateway state associated with the Gx session. This includes the APN for the session and the Origin-Host received in the CCR-I message. The Origin-Host contains the Diameter Identity of the PCEF that originates the CCR-I and will generally be the FQDN of the PCEF.
• The GQC generates a GGR message with IMSI as the query key.
• The GLA queries the SBR-B to get the gateway state for the Gx session or sessions associated with the IMSI combination.
• The SBR-B returns the gateway state for all sessions associated with the IMSI. In this case there is oneGx session, the one that resulted in the binding. The state returned included the Origin-Host and APN associated with the session. A time stamp for when the session was initiated is also included.
• The GLA returns the Gx session state in a GGA message. If no matching sessions are included in theGW State Response then the GLA returns a response.
• The GLA application’s role is to provide access to state generated by the PCA PDRA function. As a result, the GLA application must be deployed in a network that includes the PCA. The implication of this is that the PCA and the GLA application must be managed by the same NOAM. This is illustrated in the figure below:

Figure 2-60 PCA and GLA NOAM Architecture

Within a single DSR Network Element, there are three alternatives for deploying the GLA application

Dedicated GLA DA-MPs – The GLA application is deployed in a DSR NE that also supports the PCA but is deployed on dedicated DA-MPs. The benefit of this deployment architecture is that it isolates the GLA Diameter traffic from the Policy DRA Diameter traffic. The GLA traffic can vary greatly and at times can spike to a high traffic rate. This deployment alternative helps to minimize the impact of those traffic spikes on the mainline PCA. Note that the full impact of the traffic cannot be isolated as the GLA queries result in interactions with the SBR-B database.

• Shared GLA DA-MPs – The GLA application is deployed in a DSR NE that also supports the PCA. The GLA application and PCA are both enabled on common DA-MPs.
• Dedicated GLA Network Element – The GLA application is deployed as a separate set of DSR NEs. This must be in a network that includes DSR NEs running the PC.

When deployed using separate sets of MPs and when using IPFE to distribute client-initiated connections, it is necessary to configure separate target sets for each application. One IPFE target set contains the PCR MPs and a second IPFE target set contains the GLA MPs.