The entities presented in this clause are dedicated to the provisioning of a given (set of) service(s). The fact that they are implemented or not in a given PLMN should have limited impact on all the other entities of the PLMN.
All the specific entities defined so far are located in the Core Network.
The Group Call Register (GCR) is a register holding information about VGCS or VBS calls, the voice group or broadcast call attributes, respectively.
Voice group or broadcast call attributes are defined for a specific voice group or broadcast call reference and include the data required to configure the conference bridge for a VGCS or VBS call and other call related attributes.
The Group Call Register (GCR) shall hold for a related MSC area for each group ID and cell from which Voice Group Call Service (VGCS) or Voice Broadcast Service (VBS) calls can be established by mobile stations the voice group call reference or voice broadcast call reference to be used for a VGCS or VBS call to be established and an indication whether the originating MSC is the MSC responsible for that call.
If the originating MSC is not responsible for that call, the GCR shall hold the routing information identifying the MSC responsible for that call.
A GCR may be in charge of one or several MSC. Each MSC involved in a voice group or broadcast call requests its proper voice group or broadcast call attributes from its related GCR by use of the voice group or broadcast call reference.
The contents of each list related to requests of the MSC responsible for a voice group or broadcast call is as follows:
a list of cells inside the MSC area of the requesting MSC into which the call is to be sent (part of the group call area);
a list of other MSCs into which the call is to be sent;
a list of identities of dispatchers to which a dedicated link is to be established;
a list of identities of dispatchers which are allowed to initiate the voice group or broadcast call;
a list of identities of dispatchers which are allowed to terminate the voice group or broadcast call;
the length of time over which no activity is detected before the voice group call is automatically terminated;
the default priority level related to the voice group or broadcast call if the eMLPP supplementary service applies;
a flag indicating if acknowledgements are required for this voice group or broadcast call.
The contents of each list related to requests of an MSC not responsible for a voice group or broadcast call is as follows:
a list of cells inside the MSC area of the requesting MSC into which the call is to be sent (part of the group call area).
This clause describes the Location Services entities found in the Core Network and Radio Access Network that support positioning methods for the UE/MS.
For further details on LCS in E-UTRAN, UMTS and GSM from system and core network point view, see TS 23.271.
For further details on LCS in UTRAN, see TS 25.305.
For further details on LCS in GERAN, see TS 43.059.
For further details on user-plane LCS in E-UTRAN, see OMA SUPL . For further details on control plane LCS for E-UTRAN see TS 36.305.
The RAN (E-UTRAN, UTRAN and GERAN) supports one or more UE/MS positioning methods to calculate the geographical position of the UE/MS and responds to the UE/MS location request received from the CN. For UTRAN and GERAN, the RAN may broadcast LCS assistance data to UEs/MSs under its coverage. In case this assistance data is ciphered, the ciphering key is provided by the CN to the UE/MS.
To support UE positioning methods, the RAN is made of several entities like:
the BSC for GERAN and SRNC for UTRAN receive authenticated location requests from the CN:
In UTRAN, the SRNC co-ordinates the positioning requests taking into account their priority and it selects the positioning method to fulfil the requested accuracy. It interfaces, when necessary, with the CRNC which mainly manages resources allocated to UE positioning operations and requests UE Positioning related measurements from its associated Node Bs and LMUs.
In GERAN, the BSC passes the location request to the SMLC.
The Serving Mobile Location Centre (SMLC) function can be part of the RNC or be a SAS (Stand-Alone SMLC) for UTRAN. The SMLC function can be part of the BSC or be in a separate SMLC server for GERAN.
In UTRAN, the SMLC function provides assistance data to the RNC and acts as a location calculation server if the location estimates are not to be calculated in the RNC.
In GERAN, the SMLC function co-ordinates the positioning request, schedules resources required to perform positioning of a mobile, and calculates the final location estimate and accuracy. The SMLC may control a number of LMUs.
The Location Measurement Unit (LMU) entity makes measurements for one or more positioning methods.
Node B is a network element of UTRAN that may provide measurement results for position estimation and makes measurements of radio signals.
The eNodeB is a network element of E-UTRAN that may provide measurement results for position estimation and makes measurements of radio signals for a target UE and communicates these measurements to an E-SMLC.
The Cell Broadcast Centre, in GERAN, the SMLC function may interface a CBC in order to broadcast assistance data using existing cell broadcast capabilities.
For detail on Location services, entities and interfaces provided by E-UTRAN, see TS 36.305.
For detail on Location services, entities and interfaces provided by UTRAN, see TS 25.305.
For detail on Location services, entities and interfaces provided by GERAN, see TS 43.059.
The Gateway Mobile Location Centre (GMLC) is the first node an external Location Application accesses in the GSM PLMN. The GMLC performs registration authorization and requests routing information from the HLR/HSS. There may be more than one GMLC in a PLMN.
An LMU makes radio measurements to support one or more positioning methods.
Two types of LMU are defined:
Type A LMU: accessed over the normal GSM air interface;
Type B LMU: accessed over the base station to controller interface (Abis in GSM and Iub in UMTS).
A type A LMU is accessed exclusively over the GSM air interface (Um interface): there is no wired connection to any other network element.
In GSM, a type A LMU has a serving BTS and BSC that provide signalling access to a controlling SMLC. With an NSS based SMLC, a type A LMU also has a serving MSC and VLR and a subscription profile in an HLR. A type A LMU always has a unique IMSI and supports all radio resource and mobility management functions of the GSM air interface that are necessary to support signalling using an SDCCH to the SMLC. A type A LMU supports those connection management functions necessary to support LCS signalling transactions with the SMLC and may support certain call control functions of to support signalling to an SMLC using a circuit switched data connection.
In UTRAN, a type A LMU has signalling access to the SRNC. Type A LMU is not supported in UMTS release 1999.
In GSM, a Type B LMU is accessed over the Abis interface from a BSC. The LMU may be either a standalone network element addressed using some pseudo-cell ID or connected to or integrated in a BTS. Signalling to a Type B LMU is by means of messages routed through the controlling BSC for a BSS based SMLC or messages routed through a controlling BSC and MSC for an NSS based SMLC.
In UTRAN, a Type B LMU is accessed over the Iub interface from an RNC. The LMU may be either a standalone network element addressed using some pseudo-cell ID or connected to or integrated in a Node B.
For E-UTRAN, the Evolved Serving Mobile Location Centre (E-SMLC) is a server in the core network. The E-SMLC manages the support of different location services for target UEs, including positioning of UEs and delivery of assistance data to UEs. The E-SMLC may interact with the serving eNodeB for a target UE in order to obtain position measurements for the UE, including uplink measurements made by the eNodeB and downlink measurements made by the UE that were provided to the eNodeB as part of other functions such as for support of handover.
The E-SMLC may interact with a target UE in order to deliver assistance data if requested for a particular location service, to obtain a location estimate, or location related measurements, if that was requested.
For positioning of a target UE, the E-SMLC decides on the position methods to be used, based on factors that may include the LCS Client type, the required QoS, UE positioning capabilities, and eNodeB positioning capabilities. The E-SMLC then invokes these positioning methods in the UE and/or serving eNodeB. The positioning methods may yield a location estimate for UE-based position methods and/or positioning measurements for UE-assisted and network-based position methods. The E-SMLC may combine all the received results and determine a single location estimate for the target UE (hybrid positioning). Additional information like accuracy of the location estimate and velocity may also be determined.
The entities of this clause support the CAMEL feature (Customised Applications for Mobile network Enhanced Logic). This feature provides the mechanisms to support services consistently independently of the serving network, as described in TS 22.078. The following definitions are extracted from TS 23.078, which completely specifies CAMEL stage 2.
A functional entity that interfaces the MSC/GMSC to the gsmSCF. The concept of the gsmSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network.
The cell broadcast service (CBS) is a Teleservice which enables an Information Provider to submit short messages for broadcasting to a specified area within the PLMN. TS 23.041 contains the technical realization of the service.
The CBC shall be responsible for the management of CBS messages and for determining the CBS delivery parameters of the BSS/RNS. The CBC may be connected to several BSCs/RNCs. The CBC is regarded to be integrated as a node into the core network.
Two different solutions are defined to support Number Portability. The first one is an IN based solution and is described in the next clause. The second one is a "Signalling Relay" based solution described in next but one clause.
For details on MNP see TS 23.066.
The Number Portability Database (NPDB) is the central element of the IN based solution for Mobile Number Portability (MNP). MNP is the ability for a mobile subscriber to change the GSM subscription network within a portability cluster (e.g. a country) whilst retaining his/her original MSISDN or MSISDNs.
The NPDB stores the table of correspondence between MSISDNs and Subscription networks. Upon request of the (gateway or visited) MSC, the NPDB retrieves from the MSISDN the Routing Number pointing out the Subscription network.
The MNP-Signalling Relay Function (MNP-SRF) is the central element of the Signalling Relay based solution for Mobile Number Portability.
The MNP-SRF obtains the routing information from a NP database to identify the subscription network associated with a particular national MSISDN. Upon request from gateway MSC, the MNP-SRF may perform one of the following actions:
the MNP-SRF will reply back to the GMSC with the necessary routing information to route the call;
the message is relayed to the HLR;
the message is relayed to MNP-SRF in the subscription network.
For non-call related signalling (e.g. delivery of SMS), only cases 2 and 3 are applicable.
The CSCF can act as Proxy CSCF (P CSCF), Serving CSCF (S CSCF), Emergency CSCF (E CSCF), or Interrogating CSCF (I CSCF). The P CSCF is the first contact point for the UE within the IM subsystem (IMS); the S CSCF actually handles the session states in the network; the E CSCF handles certain aspects of emergency sessions such as routing an emergency request to the correct emergency centre or PSAP; the I CSCF is mainly the contact point within an operator's network for all IMS connections destined to a subscriber of that network operator, or a roaming subscriber currently located within that network operator's service area. Further definitions of the P-, S- and I CSCF are provided in TS 23.228. Further definitions of the E CSCF is provided in TS 23.167.
Note: In this document the term Media Gateway Function (MGW) is used when there is no need to differentiate between the CS domain entity and the IP Multimedia CN Subsystem entity. When referring specifically to the CS domain entity, the term CS-MGW is used. When referring specifically to the IP Multimedia CN Subsystem entity, the term IMS-MGW is used.
A IMS-MGW may terminate bearer channels from a switched circuit network and media streams from a packet network (e.g., RTP streams in an IP network). The IMS-MGW may support media conversion, bearer control and payload processing (e.g. codec, echo canceller, conference bridge), it:
Interacts with the MGCF for resource control.
Owns and handles resources such as echo cancellers etc.
May need to have Codecs.
The IMS-MGW will be provisioned with the necessary resources for supporting UMTS/GSM transport media. Further tailoring (i.e. packages) of the H.248  may be required to support additional Codecs and framing protocols, etc.
The MRB supports the sharing of a pool of heterogeneous MRF resources by multiple heterogeneous applications. MRB assigns (and later releases) specific suitable MRF resources to calls as requested by the consuming applications, based on MRF attributes specified by the applications as well as other criteria.
The MRB may take the following kinds of information into account when assigning MRF resources to an application:
the specific characteristics of the media resources required for the call or calls;
the identity of the application;
rules for allocating MRF resources across different applications;
per-application or per-subscriber SLA or QoS criteria; and
The Breakout Gateway control function (BGCF) determines the next hop for routing the SIP message. This determination may be based on information received in the signalling protocol, administrative information, and/or database access. For PSTN /CS Domain terminations, the BGCF determines the network in which PSTN/CS Domain breakout is to occur and - within the network where the breakout is to occur - selects the MGCF.
Details are described in TS 23.228.
An Application Server (AS) i.e., SIP Application Server, OSA Application Server, or CAMEL IM-SSF, offers value added IM services and resides either in the user's home network or in a third party location. The third party could be a network or simply a stand-alone AS.
The AS (SIP Application Server and/or the OSA Service Capability Server and/or IM-SSF) can communicate with the HSS. The Sh and Si interfaces are used for this purpose.
The Serving CSCF to AS interface is used to provide services residing in an AS. Two cases were identified:
Serving CSCF to an AS in Home Network.
Serving CSCF to an AS in a trusted External Network (e.g., Third Party or Visited). The S CSCF does not provide authentication and security functionality for secure direct third party access to the IM Subsystem. The OSA framework provides a standardized way for third party access to the IM Subsystem.
The Interrogating CSCF to AS interface is used to forward SIP requests destined to a Public Service Identity hosted by the AS directly to that AS.
The AS to MRFC interfaces are:
Mr', used for session control;
Cr, used for media control.
The AS to MRB interface (Rc) is used by the AS to request that MRF resources with certain characteristics be assigned to a call.
An Application Server may influence and impact the SIP session on behalf of the services supported by the operator's network. An AS may host and execute services.
An IBCF provides application specific functions at the SIP/SDP protocol layer in order to perform interconnection between two operator domains. It enables communication between IPv6 and IPv4 SIP applications. network topology hiding, controlling transport plane functions, screening of SIP signalling information, selecting the appropriate signalling interconnect and generation of charging data records. Details are described in TS 23.228.
The LRF retrieves location information for the UE including, where required, interim location information, initial location and updated location information. The LRF may interact with a Routing Determination Function (RDF) in order to obtain routing information. The LRF may interact with a GMLC or other types of location server functions in order to obtain location information. Further definitions of the LRF is provided in TS 23.167.
The SCC AS is an IMS Application that can provide functionality required to enable IMS Centralized Services as defined in TS 23.292, and can provide IMS-based mechanisms for enabling service continuity of multimedia sessions as defined in TS 23.237.
The EATF provides IMS-based mechanisms for enabling service continuity of IMS emergency sessions. It is a function in the serving (visited if roaming) IMS network, providing the procedures for IMS emergency session anchoring and PS to CS access transfer as defined in TS 23.237.
The ATCF is a function in the serving (visited if roaming) IMS network. It enables SRVCC Session Transfer mechanisms in the serving network for a UE. The SCC AS can provide Session Transfer mechanisms in the serving network, if an ATCF is present in the SIP registration path of the UE, as defined in TS 23.237.
The SGW performs the signalling conversion (both ways) at transport level between the SS7 based transport of signalling used in pre-Rel 4 networks, and the IP based transport of signalling possibly used in post-R99 networks (i.e. between Sigtran SCTP/IP and SS7 MTP). The SGW does not interpret the application layer (e.g. MAP, CAP, BICC, ISUP) messages but may have to interpret the underlying SCCP or SCTP layer to ensure proper routing of the signalling.
Interworking between cellular text modem (CTM) and text telephony standards (e.g. V.18) used in external networks can be supported by three methods:
Routing calls through a CTM Special resource function (CTM-SRF) in the core network. The CTM-SRF is linked in to the call path via CAMEL procedures. Depending on operator configuration the CTM-SRF may also be linked in to the call path for Emergency calls.
A CTM / Text telephone converting function included along the speech call path selected by the network after an indication from the terminal that CTM is required.
A CTM / Text telephone converting function included in all speech call paths.
Further information of the support for text telephony is found in TS 23.226.
For further details of CTM, see TS 26.226.
The 3GPP system and its network domains shall be logically and physically divided into security domains in order to protect IP based control plane signalling. These security domains typically coincide with operator borders.
The interface between different security domains is protected by Security Gateways (SEGs). The SEGs are responsible for enforcing the security policy of a IP security domain towards other SEGs in the destination IP security domain. All NDS/IP traffic shall pass through a SEG before entering or leaving a security domain. For further details of SEG, see TS 33.210.
The Application Function (AF) is an element offering applications that require the control of IP bearer resources or the control of flow based bearer charging. The AF is capable of communicating with the PCRF to transfer dynamic QoS-related service information and/or dynamic charging-related service information.
One example of an AF is the P CSCF of the IM CN subsystem.
The 3GPP AAA Proxy in case of I-WLAN access as specified in TS 23.234 represents a AAA proxying and filtering function and resides in the visited 3GPP network. It is involved in access and service authentication and authorization procedures of a WLAN UE.
The WLAN access gateway is a gateway between WLAN and 3GPP network. In the roaming case it resides in the visited 3GPP network, otherwise in the home 3GPP network. It provides filtering, policing and charging functionality for the traffic between WLAN UE and 3GPP network.
The HA provides control and mobility function for service continuity between 3GPP WLAN Interworking system and 3GPP Systems. The HA terminates the HGi reference point towards the PDN as defined in TS 23.327.
The Multimedia Broadcast Multicast Service (MBMS) is a point-to-multipoint service in which data is transmitted from a single source entity to multiple recipients. TS 23.246 contains the technical realization of the service.
The Broadcast-Multicast Service Centre provides functions for MBMS user service provisioning and delivery. It may serve as an entry point for content provider MBMS transmissions, used to authorise and initiate MBMS Bearer Services within the PLMN and can be used to schedule and deliver MBMS transmissions.
The MBMS GW provides functions in the EPS for controlling MBMS session initiation/modification/termination by the MBMS User Service and for providing delivery of IP Multicast datagrams from the SGi-mb reference point to downstream nodes in the MBMS Service Area with a specified quality of service.
The GUP Server is a functional entity providing a single point of access to the Generic User Profile data of a particular subscriber. The architecture does not specify or limit the physical location of the GUP Server enabling flexibility in the implementations. For further details of the GUP Server, see TS 23.240.
The Policy and Charging Rules Function (PCRF) acts as a policy decision point for policy and charging control of service data flows/applications and IP bearer resources. The PCRF selects and provides the applicable policy and charging control decision to the PCEF and, if applicable, application detection and control decision to the TDF or PCEF with application detection and control feature. When the Gxx interface applies, the PCRF maintains the correlation between the GW control session over Gxx interface and the IP-CAN session over Gx. The PCRF also acts as an information exchange relay between BBERF and PCEF to forward event triggers, which can't be transferred directly.
When the Sd interface applies, the PCRF maintains the correlation between the IP-CAN session and the TDF session. Events subscribed by the TDF are reported by the PCRF.
When S9a interface applies, the PCRF provides to the BPCF the UE/H(e)NB local IP address and UDP port number, the QoS rules and PCC rules over S9a interface. PCRF maintains the correlation between the GW control session over S9a interface and the IP-CAN session over Gx interface (if IP-CAN session over Gx interface is available).
When S15 interface applies, the PCRF provides dynamic QoS control policies to the BPCF for the purpose of allocation of QoS resources in the Fixed Broadband Access Network for HNB CS traffic.
PCRF is the policy and charging control element. PCRF functions are described in more detail in TS 23.203.
In non-roaming scenario, there is only a single PCRF in the HPLMN associated with one UE's IP-CAN session.
In a roaming scenario with local breakout of traffic and/or when a Gxx interface applies there are two PCRFs associated with one UE's IP-CAN session:
H-PCRF that resides within the H-PLMN;
V-PCRF that resides within the V-PLMN.
A single logical PCRF entity may be deployed by means of multiple and separately addressable PCRFs in the PLMN. In this case, the PCRF discovery and selection is enabled by Diameter Routing Agency (DRA).
The Policy and Charging Enforcement Function (PCEF) acts as a policy enforcement point for policy and charging control of IP bearer resources.
This functional entity is located at the Gateway (e.g. GGSN in the GPRS case) and in the PDN GW for EPS).
The functionality of PCEF is described in TS 23.203, TS 23.401 and TS 23.402.
Support of Short Message Service over generic 3GPP Internet Protocol access (SMSIP) provide 3GPP SMS messaging services across any form of IP Connectivity Access Network. TS 23.204 contains the technical realization of the service.
The IP Short Message Gateway function is used for two functions: to deliver SMS messages over the IP network and to provide interworking between SMS users and Instant Messaging users. The interworking function translates between MAP or Diameter based signalling and SIP signalling to convey messages and responses between the two systems. Both functions are described in TS 23.204.
The Service Data Flow Based Credit Control Function performs online credit control functions. It is a functional entity embedded in the Online Charging Function (OCF) within the Online Charging System. (OCS) as specified in TS 32.296.
The Bearer Binding and Event Reporting Function (BBERF) acts as a policy enforcement point for bearer binding, uplink bearer binding verification and event reporting to the PCRF when Gxx applies.
This function entity is located at a GW (e.g. S-GW in the 3GPP access with PMIP based S5/S8 case, HSGW in the HRPD case, A-GW in the non- 3GPP access when PMIP or DSMIPv6 based mobility is used, ePDG with PMIP based S2b or Untrusted S2c case if Gxb* applies).
The BBERF in the ePDG supports only reporting of the UE's Local IP address and UDP port number to the PCRF. Bearer binding and bearer binding verification functions are not supported.
The Home NodeB Subsystem (HNS) consists of a Home NodeB (HNB), a Home NodeB Gateway (HNB-GW) and optionally a Local GW (L-GW). The Home NodeB Subsystem appears as an RNS to the core network and is connected by means of the Iu-CS interface to the MSC and by means of the Iu-PS interface to the SGSN.
A Home NodeB is a Customer Premises Equipment (CPE) offering UTRAN coverage, further details can be found in TS 25.467.
A Home NodeB Gateway is the gateway through which the Home NodeB accesses the core network, more details can be found in TS 25.467.
A Local GW is a gateway towards the IP networks (e.g. residential/enterprise networks, Internet) associated with the Home NodeB, more details can be found in TS 23.060. The Local GW can be colocated with the Home NodeB or can be a standalone GW (with Serving GW and Local GW collocated) residing in the Local Network.
The Home eNodeB Subsystem (HeNS) consists of a Home eNodeB (HeNB), optionally a Home eNodeB Gateway (HeNB-GW) and optionally a Local GW (L-GW). The Home eNodeB Subsystem is connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME interface and to the Serving Gateway (S-GW) by means of the S1-U interface.
A Home eNodeB is a Customer-Premises Equipment (CPE) offering E-UTRAN coverage, further details can be found in TS 36.300.
A Home eNodeB Gateway is an optional gateway through which the Home eNodeB accesses the core network, more details can be found in TS 36.300.
A Local GW is a gateway towards the IP networks (e.g. residential/enterprise networks, Internet) associated with the Home eNodeB, more details can be found in TS 23.401. The Local GW can be collocated with the Home eNodeB or can be a standalone GW (with Serving GW and Local GW collocated) residing in the Local Network.
The CSG List Server provisions the Allowed CSG list and the Operator CSG list on the UE using the OTA procedures defined in TS 31.102 or the OMA DM procedures defined in TS 24.285.
The Allowed CSG list and the Operator CSG list are applicable to both UTRAN and E-UTRAN CSG cells for HNB and HeNB respectively.
The CSS is the entity in the VPLMN storing and managing CSG subscription-related information for roaming UEs to enable VPLMN Autonomous CSG Roaming (see TS 22.220).
The CSS is responsible for holding the following user related information:
CSG membership granted to the subscriber during his stay in the VPLMN, i.e. list of CSG IDs and associated expiration dates;
User Location information: the CSS stores the location information of the subscriber for subsequent update of the CSG subscription information at the MME, SGSN and VLR upon subscription change.
The CSS consists of the following functionalities:
download of the CSG subscription information upon request from the serving MME, SGSN and VLR, through the S7a, S7d, Ghv and Hv interfaces, to enable roaming subscribers to access to the PS and CS Domain services via CSG cells;
service provisioning, including updating the appropriate serving entities (i.e. MME, SGSN and VLR) with modifications of the the CSG membership granted to the subscriber.
The organisation of the subscriber data is outlined in TS 23.008. It also indicates which numbers and identifiers specified in TS 23.003 are stored in the CSS.
When the User Data Convergence (UDC) architecture is applied, certain functional entities keep the application logic, but do not locally store user data permanently. Examples of such functional entities are HLR/HSS/AuC and Application Servers. These data-less functional entities are known in the UDC architecture as Application Front Ends. The application that is handled by an AFE determines the type of AFE, e.g. HLR-FE or HSS-FE. The reference points between the Front Ends and the core and service layers are not affected by the UDC architecture. More information on Application Front Ends can be found in TS 23.335.
The UDR is a functional entity that acts as a single logical repository storing user data. The user-related data traditionally stored in the HSS/HLR/AuC, Application Servers, etc., are now stored in the UDR. UDR facilitates the share and provisioning of user-related data. The UDR provides a unique reference point to Application Front Ends such as HSS/HLR/AuC/AS Front Ends. This reference point is named Ud. More information on the UDR can be found in TS 23.335.
The Traffic Detection Function (TDF) is a functional entity that performs application detection and control.
The functional description of the TDF is in TS 23.203.
The TDF can be split into TDF-C and TDF-U, which jointly provide TDF functionalities. The functional split between TDF-C and TDF-U are defined in TS 23.214.
The Machine Type Communication-InterWorking Function (MTC-IWF) is a functional entity that acts as an interface between the PLMN and a Services Capability Server (SCS) to provide specific MTC functionalities in the PLMN such as device triggering.
The functional description of the MTC-IWF is in TS 23.682.
The Machine Type Communication-Authentication, Authorization and Accounting (MTC-AAA) is a functional entity that translates an IMSI to the external identifier(s) of the user.
The functional description of the MTC-AAA is in TS 23.682.
The Service Capability Exposure Function (SCEF) is a functional entity that provides a means to securely expose the services and capabilities provided by 3GPP network interfaces.
The functional description of the SCEF is in TS 23.682.
When TCP is being used, TCP connection is between a TCP client and a TCP server as defined in RFC 793. A TCP Proxy Function splits a TCP connection such that it terminates the TCP connection received from the UE and establishes a corresponding TCP connection to the other end system in packet data network.
The implementation and necessary protocols to realize the functions related to TCP Proxy Function are outside the scope of 3GPP specifications.
The GCS AS transfers application data, e.g. media data and/or application signalling, to a group of UEs either over MBMS Bearer Services using the Broadcast Mode of MBMS (TS 23.246); or over EPS Bearers (TS 23.401); or over both MBMS and EPS bearer services. GCS AS uses the MB2 reference point to deliver data to UEs over MBMS Bearer Services.
The description of the GCS AS is detailed in TS 23.468.
The ProSe Function is the logical function that is used for network related actions required for ProSe. The ProSe Function plays different roles for each of the features of ProSe. In this version of the specification it is assumed that there is only one logical ProSe Function in each PLMN that supports Proximity Services.
The description of the ProSe Function is detailed in TS 23.303.
A RAN Congestion Awareness Function (RCAF) is a functional entity which reports RAN User Plane Congestion Information to the PCRF to enable the PCRF to take the RAN user plane congestion status into account for policy decisions.
The functional description of the RCAF can be found in TS 23.203, TS 23.401 and TS 23.060.
The Traffic Steering Support Function (TSSF) is a functional entity which receives traffic steering control information from the PCRF for the purpose of traffic steering in the (S)Gi-LAN.
The functional description of the TSSF can be found in TS 23.203.
MCPTT AS transfers mission critical application data, e.g. media data and/or application signalling, to a group of UEs over on-network services. MCPTT is provided either via on-network services and/or off-network services as specified in TS 23.179.
The description of the MCPTT AS with the network functional models and the reference points is detailed in TS 23.179.
The Packet Flow Description Function (PFDF) is a repository which stores Packet Flow Descriptions (PFDs) that can be managed, i.e. added, updated, or removed, by the SCS/AS (3rd party service provider) via the SCEF. The functional description of the PFDF can be found in TS 23.682.