4a The specific entities of the 3GPP system
23.0023GPPNetwork architectureRelease 17TS
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.
4a.1 The Group Call Register (GCR) entity
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).
More information is provided in TS 43.068 [41] and TS 43.069 [42].
4a.2 (void)
4a.3 The Location Services (LCS) entities
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 [56].
For further details on LCS in UTRAN, see TS 25.305 [10b].
For further details on LCS in GERAN, see TS 43.059 [10d].
For further details on user-plane LCS in E-UTRAN, see OMA SUPL [80]. For further details on control plane LCS for E-UTRAN see TS 36.305 [122].
4a.3.1 Location Services (LCS) entities in RAN
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:
BSC/SRNC: 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.
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.
LMU: The Location Measurement Unit (LMU) entity makes measurements for one or more positioning methods.
Node B: Node B is a network element of UTRAN that may provide measurement results for position estimation and makes measurements of radio signals.
eNodeB: 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.
CBC: 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 [122].
For detail on Location services, entities and interfaces provided by UTRAN, see TS 25.305 [10b].
For detail on Location services, entities and interfaces provided by GERAN, see TS 43.059 [10d].
4a.3.2 Gateway Mobile Location Centre (GMLC)
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.
4a.3.3 Location Measurement Unit (LMU)
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.
4a.3.4 Evolved Serving Mobile Location Centre (E-SMLC)
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.
4a.4 CAMEL entities
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 [2c]. The following definitions are extracted from TS 23.078 [10c], which completely specifies CAMEL stage 2.
4a.4.1 GSM Service Control Function (gsmSCF)
A functional entity that contains the CAMEL service logic to implement Operator Specific Service. It interfaces with the gsmSSF, the gsmSRF and the HLR.
4a.4.2 GSM Service Switching Function (gsmSSF)
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.
4a.4.3 GSM Specialised Resource Function (gsmSRF)
A functional entity which provides various specialized resources. It interfaces with the gsmSCF and with the MSC. This entity is defined in ITU‑T Q.1214 [11] with variations defined in TS 23.078 [10c].
4a.4.4 GPRS Service Switching Function (gprsSSF)
A functional entity that interfaces the SGSN to the gsmSCF. The concept of the gprsSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network.
4a.5 CBS-specific entities
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 [8] contains the technical realization of the service.
4a.5.1 Cell Broadcast Centre (CBC)
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.
NOTE: Whether it should be possible that an RNC is connected to at least two CBCs at the same time (the "normal" one as in GSM and a second one for LCS) is for further study and depends on the solution taken for LCS.
4a.6 Number Portability Specific entities
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 [40].
4a.6.1 IN-based solution: Number Portability Database (NPDB)
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.
4a.6.2 Signalling Relay-based solution: Mobile Number Portability/Signalling Relay function (MNP-SRF)
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:
1. the MNP-SRF will reply back to the GMSC with the necessary routing information to route the call;
2. the message is relayed to the HLR;
3. 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.
4a.7 IP Multimedia (IM) Core Network (CN) Subsystem entities
4a.7.1 Call Session Control Function (CSCF)
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 [34]. Further definitions of the E‑CSCF is provided in TS 23.167 [74].
4a.7.2 Media Gateway Control Function (MGCF)
The MGCF:
– Controls the parts of the call state that pertain to connection control for media channels in an IMS-MGW.
– Communicates with CSCF, BGCF, and circuit switched network entities.
– Determines the next hop depending on the routing number for incoming calls from legacy networks.
– Performs protocol conversion between ISUP/TCAP/SIP-I and the IM subsystem call control protocols.
– Out of band information received in MGCF may be forwarded to CSCF/IMS-MGW.
4a.7.3 IP Multimedia Subsystem – Media Gateway Function (IMS-MGW)
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 [52] may be required to support additional Codecs and framing protocols, etc.
4a.7.4 Multimedia Resource Function Controller (MRFC)
The MRFC:
– Controls the media stream resources in the MRFP.
– Interprets information coming from an AS and S‑CSCF (e.g. session identifier) and control MRFP accordingly.
– Generates CDRs .
4a.7.4a Multimedia Resource Function Processor (MRFP)
The MRFP:
– Controls bearers on the Mb reference point.
– Provides resources to be controlled by the MRFC.
– Mixes incoming media streams (e.g. for multiple parties).
– Sources media streams (for multimedia announcements).
– Processes media streams (e.g. audio transcoding, media analysis).
– Floor Control (i.e. manage access rights to shared resources in a conferencing environment).
4a.7.4b Media Resource Broker (MRB)
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
– capacity models of particular MRF resources.
4a.7.5 Void
4a.7.6 Breakout Gateway Control Function (BGCF)
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 [34].
4a.7.7 Application Server (AS)
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.
NOTE 1: The OSA Application Server does not directly interact with the IMS network entities but through the OSA Service Capability Servers (OSA SCS-s). Further information on OSA is provided in TS 22.127 [4].
NOTE 2: A SIP Application Server specified within 3GPP that supports IMS reference points (e.g. ISC, Sh, Ut), in support of an application, is considered as part of the IM CN subsystem. Examples of such ASs are SCC AS and TAS.
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.
4a.7.8 Interconnection Border Control Function (IBCF)
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 [34].
4a.7.9 Transition Gateway (TrGW)
A TrGW is located within the media path and controlled by an IBCF. It provides functions like network address/port translation and IPv4/IPv6 protocol translation. Details are described in TS 23.228 [34].
4a.7.10 Location Retrieval Function (LRF)
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 [74].
4a.7.11 Service Centralization and Continuity Application Server (SCC AS)
The SCC AS is an IMS Application that can provide functionality required to enable IMS Centralized Services as defined in TS 23.292 [110], and can provide IMS-based mechanisms for enabling service continuity of multimedia sessions as defined in TS 23.237 [111].
4a.7.11a Emergency Access Transfer Function (EATF)
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 [111].
4a.7.12 Access Transfer Control Function (ATCF)
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 [111].
4a.7.13 Access Transfer Gateway (ATGW)
The ATGW is a media function in the serving (visited if roaming) IMS network. It may anchor the media for enhanced SRVCC procedure as defined in TS 23.237 [111].
4a.8 Signalling Gateway Function (SGW)
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.
4a.9 Global Text Telephony Specific entities
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 [37].
For further details of CTM, see TS 26.226 [38].
4a.10 Security Gateway (SEG)
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 [64].
4a.11 Application Function (AF)
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.
4a.12 Void
4a.13 3GPP/WLAN Interworking entities
4a.13.1 WLAN UE
A WLAN UE is the User Equipment using a UICC card utilized by a 3GPP subscriber to access the WLAN network for 3GPP interworking purpose.
4a.13.2 3GPP AAA Proxy
The 3GPP AAA Proxy in case of I-WLAN access as specified in TS 23.234 [67] 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.
4a.13.3 3GPP AAA Server
The 3GPP AAA server resides in the 3GPP network and in case of I-WLAN access as specified in TS 23.234 [67] is responsible for access and service authentication and authorization of a WLAN UE.
4a.13.4 WLAN Access Gateway (WAG)
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.
4a.13.5 Packet Data Gateway (PDG)
The Packet Data Gateway provides access to PS based services for a WLAN UE. It resides either in the home (for access to home services) or in the visited 3GPP network (for access to local services).
4a.13.6 Home Agent (HA)
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 [112].
4a.14 Multimedia Broadcast Multicast Service (MBMS) specific entities
4a.14.1 General
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 [70] contains the technical realization of the service.
4a.14.2 Broadcast-Multicast Service Centre (BM-SC)
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.
4a.14.3 MBMS‑GW
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.
4a.14.4 Multi-cell/multicast Coordination Entity (MCE)
The MCE is a functional entity providing functions for admission control and allocation of radio resources by E‑UTRAN and for MBMS session control. See TS 36.300 [78].
4a.15 Void
4a.16 GUP Server
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 [71].
4a.17 Policy and Charging Rules Function (PCRF)
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 [73].
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).
4a.18 Policy and Charging Enforcement Function (PCEF)
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 [73], TS 23.401 [76] and TS 23.402 [77].
4a.19 Support of Short Message Service over generic 3GPP Internet Protocol access (SMSIP) specific entities
4a.19.1 General
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 [75] contains the technical realization of the service.
4a.19.2 IP-Short-Message-Gateway (IP-SM-GW)
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 [75].
4a.20 Subscription Profile Repository (SPR)
The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies and charging control by the PCRF.
4a.21 Service Data Flow Based Credit Control Function
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 [108].
4a.22 Offline Charging System (OFCS)
The Offline Charging System is logically specified in TS 32.240 [85].
4a.23 Online Charging System (OCS)
The Online Charging System is specified in TS 32.296 [108].
4a.24 Bearer Binding and Event Reporting Function (BBERF)
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.
4a.25 Home (e)NodeB entities
4a.25.1 Home NodeB Subsystem (HNS)
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 [114].
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 [114].
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 [9a]. 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.
4a.25.2 Home eNodeB Subsystem (HeNS)
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 [78].
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 [78].
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 [76]. 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.
4a.25.3 CSG List Server
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 [118] or the OMA DM procedures defined in TS 24.285 [117].
The Allowed CSG list and the Operator CSG list are applicable to both UTRAN and E-UTRAN CSG cells for HNB and HeNB respectively.
4a.25.4 CSG Subscriber Server (CSS)
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 [130]).
The CSS is responsible for holding the following user related information:
– User Identification;
– 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 [5]. It also indicates which numbers and identifiers specified in TS 23.003 [3] are stored in the CSS.
4a.26 Application Front Ends (AFE)
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 [120].
4a.27 User Data Repository (UDR)
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 [120].
4a.28 Traffic Detection Function (TDF)
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 [73].
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 [145].
4a.29 Specific entities to facilitate communications with packet data networks and applications
4a.29.1 Machine Type Communication-InterWorking Function (MTC-IWF)
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 [132].
4a.29.2 Machine Type Communication- Authentication, Authorization and Accounting (MTC-AAA)
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 [132].
4a.29.3 Service Capability Exposure Function (SCEF)
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 [132].
4a.30 TCP Proxy Function
When TCP is being used, TCP connection is between a TCP client and a TCP server as defined in RFC793 [138]. 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.
Note: The TCP Proxy Function can be deployed in a GGSN/PGW or as an external function beyond SGi/Gi. The TCP Proxy is deployed such that it is transparent to the UE and its mobility.
The implementation and necessary protocols to realize the functions related to TCP Proxy Function are outside the scope of 3GPP specifications.
4a.31 Specific entities for Packet Switched Streaming (PSS) Service
4a.31.1 Packet Switched Streaming Service Server (PSS Server)
PSS Server provides the 3GPP packet switched streaming service based on the IETF RTSP/SDP and/or HTTP standards, with 3GPP extensions.
The description of the PSS Server is detailed in TS 26.233 [139].
4a.32 Specific entities for Group Communication System Enablers for LTE (GCSE_LTE)
4a.32.1 Group Communication Service Application Server (GCS AS)
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 [70]); or over EPS Bearers (TS 23.401 [76]); 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 [140].
4a.33 Specific entities for Proximity-based Services (ProSe)
4a.33.1 ProSe Function
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 [141].
4a.34 RAN Congestion Awareness Function (RCAF)
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 [73], TS 23.401 [76] and TS 23.060 [9a].
4a.35 Traffic Steering Support Function (TSSF)
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 [73].
4a.36 Specific entities for mission critical communication services
4a.36.1 Mission Critical Push To Talk Application Server (MCPTT AS)
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 [142].
The description of the MCPTT AS with the network functional models and the reference points is detailed in TS 23.179 [142].
4a.37 Packet Flow Description Function (PFDF)
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 [132].
4a.38 5G System architecture
The Stage 2 system architecture for the 5G System is specified in TS 23.501 [147].