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 and TS 43.069.

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 [80]. For further details on control plane LCS for E-UTRAN see TS 36.305.

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.

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.

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 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 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.

The SPR logical entity contains all subscriber/subscription related information needed for subscription-based policies and charging control by the PCRF.

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 Offline Charging System is logically specified in TS 32.240.

The Online Charging System is 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.

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.

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.

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.

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.

The Stage 2 system architecture for the 5G System is specified in TS 23.501.