DSR SCEF Architecture
The SCEF solution, supported by a DSR network, contains one or more DSR nodes (sites). Each DSR node may be connected to 3GPP entities, like MME/SGSN, SMS-SC, and HSS, in the trusted domain; and the SCS/AS in the trusted and/or untrusted domain. The connectivity of these nodes with the DSR network is shown in Figure 2-1.
Figure 2-1 DSR-SCEF Interconnections
The DSR architecture is shown in Figure 2-2.
Figure 2-2 DSR SCEF Architecture
The solution has the following components:
- An API gateway to manage the
REST interface(s) for the following:
- Authentication of SCS/AS
- Support for API lifecycle
- Profile management
- Quota and rate management
- Load balance HTTP traffic among the DA-MP servers
- Network OAM servers deployed in active-standby redundancy model for configuration and maintenance of the DSR topology.
- Site OAM servers deployed in one, two, or three site redundancy model for provisioning of the SCEF administration data.
- IPFE servers (optional) to load balance the Diameter traffic.
- DA-MP server(s) for processing the HTTP (REST) and Diameter signaling according to the provisioning done through the site OAM servers. The DA-MPs receive the HTTP signaling traffic from the SCS/AS using the DSR API gateway application servers and the Diameter signaling traffic from the IPFE servers, if present, or from the connected Diameter peers directly. Diameter traffic generated from DA-MP servers is set to the Diameter peers directly and the HTTP traffic generated from the DA-MP servers shall be routed to the SCS/AS using the DSR API gateway.
- U-SBR server(s) deployed in one, two, or three site redundancy model for caching context data. This data is volatile, that is, the data does not persist with a server reboot, therefore, it is important to plan an adequate redundancy model.
Each SCS/AS may have a configured quota and rate for T8 messages. For example, a quota of 1000 messages in 24 hours at a rate of no more than to 100 messages per hour. Such restrictions are enforced by the DSR API gateway. If the DSR API gateway determines the rate and/or quota to be exhausted, it responds with an appropriate error message to SCS/AS. If the quota and rate are found to be within limits, the DSR API gateway forwards the T8 message to one of the DSR MP servers chosen using a simple round-robin load-sharing algorithm.
For sending a T8 request message to the SCS/AS, the DSR MP servers forward the T8 message to one of the DSR API gateway servers chosen using a simple round-robin load-sharing algorithm.
The DSR MP servers provide the SCS/AS URL in an
X-callback-url header
and provide the callback type as defined in
Table 2-1
in a
X-callback-type header
to the DSR API gateway.
Table 2-1 DSR API Gateway Callback Types
| X-notification-type | Notification Description |
|---|---|
| 1 | Monitoring Event Notification |
| 2 | Device Triggering Delivery Report |
| 3 | NIDD Uplink Data Notification |
| 4 | NIDD Downlink Data Delivery Status Notification |