4.2 Architectural Reference Model

23.6823GPPArchitecture enhancements to facilitate communications with packet data networks and applicationsRelease 17TS

Figures 4.2-1a and 4.2-1b show the architecture for a UE used for MTC connecting to the 3GPP network (UTRAN, WB-E-UTRAN, NB-IoT, GERAN, etc.) via the Um/Uu/LTE-Uu interfaces or satellite access interface for NB-IoT, WB-E-UTRAN and LTE-M. They also show the 3GPP network service capability exposure to SCS and AS. The architecture covers the various architectural models described in clause 4.1.

Figure 4.2-1a: 3GPP Architecture for Machine-Type Communication (non-roaming)

Figure 4.2-1b: 3GPP Architecture for Machine-Type Communication (Roaming)

Figure 4.2-2 shows the overall architecture for Service Capability Exposure which enables the 3GPP network to securely expose its services and capabilities provided by 3GPP network interfaces to external 3rd party service provider SCS/AS hosting an Application(s).

Figure 4.2-2: 3GPP Architecture for Service Capability Exposure

Figure 4.2-3: 3GPP roaming Architecture for Service Capability Exposure

Figure 4.2-4 shows the overall architecture for RACS which enables provisioning of RACS database information in the 3GPP network.

Figure 4.2-4: 3GPP Architecture for RACS

NOTE 1: Refer to TS 23.002 [5], TS 23.060 [6], TS 23.401 [7], TS 23.272 [11] and TS 23.040 [12] for the details of 3GPP network-internal reference points not specifically shown or labelled in figure 4.2-1a, figure 4.2-1b, figure 4.2-2, or described in this specification.

NOTE 2: The SCS is controlled by the operator of the HPLMN or by a MTC Service Provider.

NOTE 3: In the non-roaming case, all 3GPP network entities providing functionality for MTC are in the same PLMN. In the roaming case, 3GPP architecture for MTC supports both the home routed (illustrated in Figures 4.2-1a and 4.2-1b) and the local-breakout roaming (not illustrated) scenarios. For the home routed scenario, the MTC Server/Application User Plane communication is routed through the HPLMN. In the local breakout scenario, the User Plane communication is routed directly through the serving PLMN/VPLMN over deployed GGSN/P-GW.

NOTE 4: Figure 4.2-2 does not include all the interfaces and network elements that may be connected to SCEF.

NOTE 5: Figure 4.2-3 does not include all the interfaces and network elements that may be connected to an Interworking SCEF (IWK-SCEF).

The SCS is an entity which connects to the 3GPP network to communicate with UEs used for MTC and the MTC-IWF and/or SCEF in the HPLMN. The SCS offers capabilities for use by one or multiple MTC Applications. A UE can host one or multiple MTC Applications. The corresponding MTC Applications in the external network are hosted on one or multiple ASs.

Tsms is the interface that encompasses all the various proprietary SMS-SC to SME interface standards (see TR 23.039 [14]) and is outside the scope of 3GPP specifications. Tsms can be used to send a trigger to a UE encapsulated in a MT-SMS as an over-the-top application by any network entity (e.g. SCS) acting as a SME. Tsp is a 3GPP standardized interface to facilitate value-added services motivated by MTC (e.g. control plane device triggering) and provided by a SCS.

T8 is the interface between the SCEF and the SCS/AS. SCEF exposed network services can be accessed by SCS/AS through APIs over T8 interface. In the indirect model, the SCS and the Application Server hosting Application(s) can be collocated.

For the roaming scenario, the MTC-IWF shall have the connection with HSS and SMS-SC within the home network only as shown in the figure 4.2-1b.

The Service Capability Exposure Function (SCEF) is the key entity within the 3GPP architecture for service capability exposure that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces. In standalone MTC-IWF deployment, MTC-IWF functionality (e.g. T4 triggering) is made available to the SCS/AS via the Tsp interface. In certain deployments, the MTC-IWF may be co-located with the SCEF in which case MTC-IWF functionality is exposed to the SCS/AS via T8 interface (i.e. API). In deployments where MTC-IWF is not co-located with SCEF, interactions between MTC-IWF and SCEF are left up to the implementation.

The trust domain (see figure 4.2-2) cover entities that are protected by adequate network domain security. The entities and interfaces within the trust domain may all be within one operator’s control, or some may be controlled by a trusted business partner which has a trust relationship with the operator e.g. another operator or a 3rd party. The security requirements for the trust domain are out of scope of this specification.

When the SCEF belongs to a trusted business partner of the HPLMN, it is still seen as an HPLMN entity by other HPLMN or VPLMN functional entities invoked by the SCEF (e.g. HSS, MME).

Applications operating in the trust domain may require only a subset of functionalities (e.g. authentication, authorization, etc.) provided by the SCEF. Applications operating in the trust domain can also access network entities (e.g. PCRF), wherever the required 3GPP interface(s) are made available, directly without the need to go through the SCEF.

The Interworking SCEF (IWK-SCEF) is optional. When deployed, the IWK-SCEF is located in the VPLMN as shown in the figure 4.2-1b.