4.4 Network Elements

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

4.4.1 General

The following 3GPP network elements provide functionality to support the Indirect and Hybrid models of MTC.

NOTE: As further development of the MTC architecture takes place as well as when additional MTC common functionality and features are addressed, further network elements may be defined.

4.4.2 MTC-IWF

To support the Indirect and Hybrid models of MTC, one or more instances of an MTC InterWorking Function (MTC-IWF) reside in the HPLMN. A MTC-IWF may be a standalone entity or a functional entity of another network element. The MTC-IWF hides the internal PLMN topology and relays or translates signalling protocols used over Tsp to invoke specific functionality in the PLMN.

The functionality of the MTC-IWF includes the following:

– termination of the Tsp, T4 and S6m and Rf/Ga reference points;

– ability to authorize the SCS before communication establishment with the 3GPP network;

– ability to authorize control plane requests from an SCS;

– the following device trigger functionalities:

– reception of a device trigger request from SCS that includes an Application Port ID used by the UE to route the trigger internally to the appropriate triggering function;

– report to the SCS the acceptance or non-acceptance of the device trigger request;

– report to the SCS the success or failure of a device trigger delivery;

– may apply MTC-IWF and/or SGSN/MME induced congestion/load control as part of the response to trigger requests; and

– uses a standardised identifier to allow the UE and the network to distinguish an MT message carrying device triggering information from any other type of messages.

– an HSS resolution mechanism for use when multiple and separately addressable HSSs have been deployed by the network operator (see e.g. the SLF / Diameter Proxy agent specified in clause 5.8 TS 23.228 [10]);

– interrogation of the appropriate HSS, when needed for device triggering, to:

– map E.164 MSISDN or External Identifier to IMSI;

– retrieve serving node information for the UE (e.g. serving SGSN/MME/MSC/IP-SM-GW identifier); and

– determine if a SCS is allowed to send a device trigger to a particular UE.

– reception of a MO data and device identities (i.e, IMSI and Application Port ID) from SMS-SC;

– deliver the MO data, External ID, and application port ID associated with the UE to the SCS;

– report to the SMS-SC the success or failure of a MO data delivery;

– interrogation of the appropriate HSS, when needed for MO delivery, to map IMSI and Application Port ID to External Identifier;

– selection of the most efficient and effective device trigger delivery mechanism and shielding of this detail from SCS based on;

– current UE serving node information from HSS/HLR (e.g. serving MME/SGSN/MSC/IP-SM-GW identifier);

– the device trigger delivery mechanisms supported by the UE;

– the possible device trigger delivery services supported by the HPLMN and, when roaming, VPLMN;

– operator defined device trigger delivery policies, if any; and/or

– optionally, any information received from the SCS.

– protocol translation, if necessary, and forwarding towards the relevant network entity (i.e. serving SGSN/MME/MSC or SMS-SC inside HPLMN domain) of a device trigger request to match the selected trigger delivery mechanism;

– generation of device trigger CDRs with External Identifier and SCS Identifier and forwarding to CDF/CGF over instance of Rf/Ga; and

NOTE 1: CDR generation with or without a device trigger indication by other network entities is not precluded by CDR generation by the MTC-IWF.

– ability for secure communications between the 3GPP network and the SCS.

The architecture shall allow the use of multiple MTC-IWFs within a HPLMN

NOTE 2: This is useful in particular to maintain service upon single MTC-IWF failure.

4.4.3 HSS/HLR

An HSS/HLR supporting device triggering shall support the following functionalities:

– termination of the S6m reference point where MTC-IWFs connect to the HLR/HSS;

– stores and provides to MTC-IWF (and optionally to MTC AAA) the mapping/lookup of E.164 MSISDN or external identifier(s) to IMSI and subscription information used by MTC-IWF for device triggering;

– mapping of IMSI and Application Port ID to external identifier;

– mapping of E.164 MSISDN or external identifiers to IMSI;

– optionally, mapping from External Identifiers to MSISDN is also provided for legacy SMS infrastructure not supporting MSISDN-less SMS;

– HSS stored "Routing information" including serving node information if available for the UE (e.g. serving SGSN/MME/MSC identifier and registered IP-SM-GW identifier); and

– determine if a SCS is allowed to send a device trigger to a particular UE;

– termination of the S6n reference point;

– provides to MTC-AAA the mapping between IMSI and External Identifier(s).

An HSS supporting monitoring events feature shall support the following functionalities:

– termination of the S6t reference point where SCEF connect to the HSS;

– mapping of E.164 MSISDN or external identifiers to IMSI for request received over S6t;

– monitoring event configuration by the SCEF; and

– monitoring event reporting to the SCEF.

An HSS supporting the feature of handling of CP parameters from SCEF to MME shall support the following functionalities:

– termination of the S6t reference point where SCEF connect to the HSS; and

– receiving CP parameters with an External ID; and

– storing the received CP parameters with the corresponding subscriber data; and

– forwarding the received CP parameters with the subscriber data to the corresponding MME.

An HSS supporting non-IP data delivery via SCEF feature shall support the following functionalities:

– termination of the S6t reference point where SCEF connect to the HSS; and

– mapping of E.164 MSISDN or external identifier to IMSI.

4.4.4 GGSN/P-GW

A GGSN or P-GW supporting the Indirect or Hybrid model of MTC may support the following functionality

– Based on APN configuration and unavailability of MSISDN and External Identifiers(s) in the GGSN/PGW, the GGSN/PGW either queries a MTC AAA server for retrieval of External Identifier(s) based on IMSI or routes RADIUS/Diameter requests for AAA servers in external PDNs (as specified in TS 29.061 [8]) via a MTC AAA proxy.

4.4.5 SGSN/MME/MSC

SGSN and MME specific functionality to support the Indirect and Hybrid models of MTC includes the following:

– MME terminates the T6a reference point;

– SGSN terminates the T6b reference point;

– may provide SGSN/MME congestion/load information to the MTC-IWF;

– monitoring event configuration by the SCEF; and

– monitoring event reporting to the SCEF.

– The MME and SGSN transfers non-IP data to the UE using a PDN connection to the SCEF as defined in TS 23.401 [7] and TS 23.060 [6] respectively.

– The MME/SGSN transfers non-IP data to the (IWK-)SCEF.

– MME may use the CP parameters for deriving the CN assisted eNodeB parameters. The CP parameters received from the HSS are used by the MME as input to derive the CN assisted eNodeB parameter values.

4.4.6 SMS-SC

SMS-SC specific functionality to support the Indirect and Hybrid models of MTC includes the following:

– terminates the T4 reference point where MTC-IWFs connect to the SMS-SC; and

– supports PS-only MT-SMS that can be delivered with IMSI in lieu of E.164 MSISDN;

– provides the routing information it received from MTC-IWF to SMS-GMSC if needed;

– deliver the SMS payload, Application Port ID, IMSI of the UE to MTC-IWF via T4; and

– send SMS delivery report to UE.

4.4.7 MTC AAA

To support translation of the IMSI to External Identifier(s) at the network egress, an AAA function (MTC AAA) is used in the HPLMN. The MTC AAA may be deployed to return the External Identifier(s) based on IMSI. Alternatively the MTC AAA may be deployed as a RADIUS/Diameter proxy between the GGSN/PGW and the AAA server in the external PDN.

When deployed as an AAA Server, the MTC AAA shall support the following functionalities:

– termination of the S6n reference point where the MTC-AAA communicates with the HLR/HSS;

– return the external identifier(s) corresponding to an IMSI; and

– may query the HSS with IMSI to retrieve the External Identifier(s) and may cache IMSI/External Identifier mapping to avoid multiple HSS queries.

When deployed as an AAA Proxy, the MTC AAA shall support the following functionalities:

– termination of the S6n reference point where the MTC-AAA communicates with the HLR/HSS;

– replace IMSI with an External Identifier for messages to an external AAA server;

– replace External Identifier with IMSI for messages from an external AAA server;

– identifying the destination external AAA server using standard RADIUS/Diameter procedures; and

– optionally, query the HSS with IMSI to retrieve the external identifier(s) and cache IMSI/External Identifier mapping to avoid multiple HSS queries.

4.4.8 Service Capability Exposure Function

The Service Capability Exposure Function (SCEF) provides a means to securely expose the services and capabilities provided by 3GPP network interfaces. The SCEF provides a means for the discovery of the exposed services and capabilities. The SCEF provides access to network capabilities through homogenous network application programming interfaces (e.g. Network APIs) defined over T8 interface. The SCEF abstracts the services from the underlying 3GPP network interfaces and protocols.

Individual instances of SCEF may vary depending on what service capabilities are exposed and what API features are supported.

The SCEF is always within the trust domain. An application can belong to the trust domain or may lie outside the trust domain.

The SCEF may support CAPIF. When CAPIF is supported, the SCEF supports the CAPIF API provider domain functions. The CAPIF and associated API provider domain functions are specified in TS 23.222 [43].

The functionality of the SCEF may include the following:

– Authentication and Authorization:

– Identification of the API consumer,

– Profile management,

– ACL (access control list) management.

NOTE 1: The details of security aspects of T8 interface are outside the scope of this specification.

– Ability for the external entities to discover the exposed service capabilities

– Policy enforcement:

– Infrastructural Policy: policies to protect platforms and network. An example of which maybe ensuring that a service node such as SMS-SC is not overloaded.

– Business Policy: policies related to the specific functionalities exposed. An example may be number portability, service routing, subscriber consent etc.

– Application Layer Policy: policies that are primarily focused on message payload or throughput provided by an application. An example may be throttling.

– Assurance:

– Integration with O&M systems,

– Assurance process related to usage of APIs.

– Accounting for inter operator settlements.

NOTE 2: The details of accounting aspects of T8 interface are outside the scope of this specification.

– Access: issues related to external interconnection and point of contact

– Abstraction: hides the underlying 3GPP network interfaces and protocols to allow full network integration. The following functions are among those that may be supported:

– Underlying protocol connectivity, routing and traffic control,

– Mapping specific APIs onto appropriate network interfaces,

– Protocol translation.

NOTE 3: Abstraction is applied only in cases where required functionality is not natively provided by 3GPP network

The services and capabilities offered by SCEF to SCS/AS include:

– Group Message Delivery (see clause 4.5.5),

– Monitoring events (see clause 4.5.6),

– High latency communication (see clause 4.5.7),

– Informing about potential network issues (see clause 4.5.8),

– Resource management of background data transfer (see clause 4.5.9),

– E-UTRAN network resource optimizations based on communication patterns provided to the MME (see clause 4.5.10),

– Support of setting up an AS session with required QoS (see clause 4.5.11),

– Change the chargeable party at session set-up or during the session (see clause 4.5.12),

– Non-IP Data Delivery (see clause 4.5.14),

– Packet Flow Description management (see clause 4.5.15),

– Enhanced Coverage restriction control (see clause 4.5.17),

– Network Parameter Configuration (see clause 4.5.20),

– Accessing MTC-IWF Functionality via T8 (see clause 5.17),

The SCEF shall protect the other PLMN entities (e.g. HSS, MME) from requests exceeding the permission arranged in the SLA with the third-party service provider.

When needed, the SCEF supports mapping between information exchanged with SCS/AS (e.g. geographical identifiers) and information exchanged with internal PLMN functions (e.g. cell-Id / ENB-Id / TAI / MBMS SAI, etc.). This mapping is assumed to be provided by the SCEF based on local configuration data.

4.4.9 Interworking SCEF

The Interworking SCEF (IWK-SCEF) is optional. When deployed, the IWK-SCEF is located in the VPLMN for inter-connection with the SCEF of the HPLMN. The Interworking SCEF receives the Monitoring Event Reports from the underlying entities and sends them to the SCEF. The IWK-SCEF relays the non-IP data between the MME/SGSN and the SCEF.

NOTE: In this release the only VPLMN network entities connected towards the IWK-SCEF are the MMEs and SGSNs.

The functionality of the Interworking SCEF includes the following:

– Storing of state information to identify e.g. the connection to SCEF (see clause 5.6.0); and

– Forwarding messages between the serving PLMN and HPLMN SCEF (see clause 5.13); and

– Authorisation of monitoring request (see clause 5.6.6.1); and

– Storing of monitoring request during its life time (see clause 5.6.6.1); and

– Normalization of reports according to roaming agreement between VPLMN and HPLMN, e.g. change the location granularity (from cell level to a level appropriate for the HPLMN) of Monitoring Event Reports received from the underlying entities; and

– Optionally, generate charging/accounting information:

– For generation of charging/accounting information, the IWK-SCEF receives the Monitoring configuration information as well as the Monitoring Event Report from the underlying nodes;

– For generation of charging/accounting information, the IWK-SCEF receives the NIDD charging ID from the SCEF during the T6a/T6b Connection Establishment Procedure (see clause 5.13.1.2).

4.4.10 RAN Congestion Awareness Function

A RCAF supporting network status reporting shall support the following functionalities:

– termination of the Ns reference point where SCEF connects to the RCAF;

– request for one-time or continuous reporting of network status changes by the SCEF; and

– report of one-time or continuous network status changes to the SCEF.

4.4.11 Packet Flow Description Function

A Packet Flow Description Function (PFDF) shall support the following functionalities:

– Termination of the Nu reference point where SCEF connects to the PFDF;

– Management of Packet Flow Descriptions (PFDs) (i.e. provision, modification and removal) according to the instructions received from the SCS/AS via the SCEF;

– Provision of Packet Flow Description (PFDs) to the PCEF/TDF as specified in TS 23.203 [27].

4.4.12 UE radio Capabilities Management Function

UCMF specific functionality to support provisioning of RACS information includes the following:

– UCMF terminates the T9a reference point;

– UCMF terminates the T9b reference point.

The services and capabilities offered by UCMF to SCEF and SCS/AS include:

– RACS information provisioning.