To provide the mobile service as it is defined, it is necessary to introduce some specific functions. These functional entities can be implemented in different equipments or gathered. In any case, exchanges of data occur between these entities.
Entities in the mobile system can be either implemented in a monolithic way where user data are stored within the entity itself (or in an external entity via non standard interfaces) or according to the User Data Convergence (UDC) concept (see TS 23.335) where the entity becomes a so-called user-dataless Application Front End (AFE). Application Front Ends access, via the Ud reference point, a User Data Repository (UDR), which stores the relevant user data managed by the applications. Unless explicitly stated otherwise, this document describes entities in its monolithic form, e.g. stating that user data are stored in the HSS. If however the UDC concept applies, user data are actually stored in the UDR and managed by one or several Application Front Ends, so that user data may be shared among the different Application Front Ends, allowing several AFEs of the same application type (e.g. HSS) to serve the same user at any given time.
For the 5G System, see clause 4a.38.
The HSS is the master database for a given user. It is the entity containing the subscription-related information to support the network entities actually handling calls/sessions.
A Home Network may contain one or several HSSs: it depends on the number of mobile subscribers, on the capacity of the equipment and on the organisation of the network.
As an example, the HSS provides support to the call control servers in order to complete the routing/roaming procedures by solving authentication, authorisation, naming/addressing resolution, location dependencies, etc.
The HSS is responsible for holding the following user related information:
User Identification, Numbering and addressing information;
User Security information: Network access control information for authentication and authorization;
User Location information at inter-system level: the HSS supports the user registration, and stores inter-system location information, etc.;
User profile information.
The HSS also generates User Security information for mutual authentication, communication integrity check and ciphering.
Based on this information, the HSS also is responsible to support the call control and session management entities of the different Domains and Subsystems (defined in clause 3.3 and clause 3.3a) of the operator as shown in Figure 0-a.
(not reproduced yet)
Figure 0-a: Example of a Generic HSS structure and basic interfaces
The HSS may integrate heterogeneous information, and enable enhanced features in the core network to be offered to the application & services domain, at the same time hiding the heterogeneity.
The HSS consists of the following functionalities:
IP multimedia functionality to provide support to control functions of the IM subsystem such as the CSCF. It is needed to enable subscriber usage of the IM CN subsystem services. This IP multimedia functionality is independent of the access network used to access the IM CN subsystem.
The subset of the HLR/AUC functionality required by the PS Domain (GPRS and EPC).
The subset of the HLR/AUC functionality required by the CS Domain, if it is desired to enable subscriber access to the CS Domain or to support roaming to legacy GSM/UMTS CS Domain networks.
The organisation of the subscriber data is outlined in TS 23.008. It also indicates which numbers, addresses and identifiers specified in TS 23.003 are stored in HSS.
The HLR is shown in the Reference Architecture up to and including Rel-4.
The HLR can be considered a subset of the HSS that holds the following functionality:
The functionality required to provide support to PS Domain entities such as the SGSN, MME and GGSN, through the Gr, S6a, S6dand Gc interfaces and the 3GPP AAA Server for EPS in case of non-3GPP access via SWx and for the I-WLAN through the D'/Gr' interface. It is needed to enable subscriber access to the PS Domain services.
The functionality required to provide support to CS Domain entities such as the MSC/MSC server and GMSC/GMSC server, through the C and D interfaces. It is needed to enable subscriber access to the CS Domain services and to support roaming to legacy GSM/UMTS CS Domain networks.
The AuC is shown in the Reference Architecture up to and including Rel-4.
The AuC can be considered a subset of the HSS that holds the following functionality for the CS Domain and PS Domain:
The AuC is associated with an HLR and stores an identity key for each mobile subscriber registered with the associated HLR. This key is used to generate security data for each mobile subscriber:
data which are used for mutual authentication of the International Mobile Subscriber Identity (IMSI) and the network;
a key used to check the integrity of the communication over the radio path between the mobile station and the network;
a key used to cipher communication over the radio path between the mobile station and the network.
The AuC communicates only with its associated HLR over a non-standardised interface denoted the H-interface. The HLR requests the data needed for authentication and ciphering from the AuC via the H-interface, stores them and delivers them to the VLR and SGSN and MME which need them to perform the security functions for a mobile station.
This clause provides a high level and not exhaustive description of HSS functionality.
(not reproduced yet)
Figure 0.b: HSS logical functions
This function supports the user mobility through CS Domain, PS Domain and IM CN subsystem.
Call and/or session establishment support
The HSS supports the call and/or session establishment procedures in CS Domain, PS Domain and IM CN subsystem. For terminating traffic, it provides information on which call and/or session control entity currently hosts the user.
User security information generation
The HSS generates user authentication, integrity and ciphering data for the CS and PS Domains and for the IM CN subsystem. User security support
The HSS supports the authentication procedures to access CS Domain, PS Domain and IM CN subsystem services by storing the generated data for authentication, integrity and ciphering and by providing these data to the appropriate entity in the CN (i.e. MSC/VLR, SGSN, MME, 3GPP AAA Server or CSCF).
User identification handling
The HSS provides the appropriate relations among all the identifiers uniquely determining the user in the system: CS Domain, PS Domain and IM CN subsystem (e.g. IMSI and MSISDNs for CS Domain; IMSI, MSISDNs and IP addresses for PS Domain, private identity and public identities for IM CN subsystem).
The HSS authorises the user for mobile access when requested by the MSC/VLR, SGSN, MME, 3GPP AAA Server or CSCF, by checking that the user is allowed to roam to that visited network.
Service authorisation support
The HSS provides basic authorisation for MT call/session establishment and service invocation. Besides, the HSS updates the appropriate serving entities (i.e., MSC/VLR, SGSN, MME, 3GPP AAA Server, CSCF) with the relevant information related to the services to be provided to the user.
Service Provisioning Support
The HSS provides access to the service profile data for use within the CS Domain, PS Domain and/or IM CN subsystem. Application Services and CAMEL Services Support (for GERAN and UTRAN access).
The HSS communicates with the SIP Application Server and the OSA-SCS to support Application Services in the IM CN subsystem. It communicates with the IM-SSF to support the CAMEL Services related to the IM CN subsystem. The IMS CAMEL subscription data may be transferred to the IM-SSF AS using Sh reference point in addition to the Si reference point. The HSS communicates with the gsmSCF to support CAMEL Services in the CS Domain and GPRS PS Domain (for GERAN and UTRAN access).
CAMEL support for GERAN/UTRAN via EPS (i.e. for S4 SGSN) is FFS.
GUP Data Repository
The HSS supports the storage of IM CN Subsystem user related data, and provides access to these data through the Rp reference point as described in TS 23.240.
A mobile station roaming in an MSC area or within a GERAN/UTRAN pool-area is controlled by a Visitor Location Register. When a Mobile Station (MS) enters a new location area it starts a registration procedure. An MSC in charge of that area notices this registration and transfers to a Visitor Location Register the identity of the location area where the MS is situated. If this MS is not yet registered in the VLR, the VLR and the HLR exchange information to allow the proper handling of CS calls involving the MS.
A VLR may be in charge of one or several MSC areas.
The VLR contains also the information needed to handle the calls set-up or received by the MSs registered in its data base (for some supplementary services the VLR may have to obtain additional information from the HLR). The following elements are included:
the International Mobile Subscriber Identity (IMSI);
the Mobile Station International ISDN number (MSISDN);
the Mobile Station Roaming Number (MSRN), see TS 23.003 for allocation principles;
the Temporary Mobile Station Identity (TMSI), if applicable;
the Local Mobile Station Identity (LMSI), if used;
the location area where the mobile station has been registered;
the identity of the SGSN where the MS has been registered. Only applicable to PLMNs supporting GPRS and which have a Gs interface between MSC/VLR and SGSN;
the last known location and the initial location of the MS;
the identity of the MME where the MS has been registered. Only applicable to PLMNs supporting EPC and CS Fallback and which have a SGs interface between MSC/VLR and MME.
The VLR also contains supplementary service parameters attached to the mobile subscriber and received from the HLR. The organisation of the subscriber data is outlined in TS 23.008.
The Equipment Identity Register (EIR) in the GSM system is the logical entity which is responsible for storing in the network the International Mobile Equipment Identities (IMEIs), used in the GERAN/UTRAN/E-UTRAN system.
The equipment is classified as "white listed", "grey listed", "black listed" or it may be unknown as specified in TS 22.016 and TS 29.002.
This functional entity contains one or several databases which store(s) the IMEIs used in the system.
The mobile equipment may be classified as "white listed", "grey listed" and "black listed" and therefore may be stored in three separate lists.
An IMEI may also be unknown to the EIR.
An EIR shall as a minimum contain a "white list" (Equipment classified as "white listed").
See also TS 22.016 on IMEI.
The SMS Gateway MSC (SMS-GMSC) acts as an interface between a Short Message Service Centre and the PLMN, to allow short messages to be delivered to mobile stations from the Service Centre (SC).
The choice of which MSCs can act as SMS Gateway MSCs is a network operator matter (e.g. all MSCs or some designated MSCs).
The SMS Interworking MSC acts as an interface between the PLMN and a Short Message Service Centre (SC) to allow short messages to be submitted from Mobile Stations to the SC.
The choice of which MSCs can act as SMS Interworking MSCs is a network operator matter (e.g. all MSCs or some designated MSCs).
Is queried by the I CSCF during the Registration and Session Setup to get the name of the HSS containing the required subscriber specific data. Furthermore the SLF is also queried by the S CSCF during the Registration.
Is queried by the AS in conjunction with the Sh interface operation to get the name of the HSS containing the required subscriber specific data.
Is queried by the 3GPP AAA server to get the name of the HSS containing the required subscriber specific data.
Is accessed via the Dx interface by the CSCF, via the Dh interface by the AS, and via the Dw interface by the 3GPP AAA Server.
The SLF is not required in a single HSS environment. An example for a single HSS environment is a server farm architecture. Use of SLF is not required when AS are configured/managed to use pre-defined HSS.
The Mobile-services Switching Centre (MSC) constitutes the interface between the radio system and the fixed networks. The MSC performs all necessary functions in order to handle the circuit switched services to and from the mobile stations.
In order to obtain radio coverage of a given geographical area, a number of BSS and/or RNS are normally required; i.e. each MSC would thus have to interface to one or more BSS(s) and/or RNS(s). In addition several MSCs may be required to cover a country.
When Intra Domain Connection of RAN Nodes to Multiple CN Nodes is applied, all the MSCs serving a pool-area share the responsibility to serve the MSs located in the pool-area. All these MSCs interface to all the BSS(s) and/or RNS(s) forming the pool-area.
The Mobile-services Switching Centre is an exchange, which performs all the switching and signalling functions for mobile stations located in a geographical area designated as the MSC area. When Intra Domain Connection of RAN Nodes to Multiple CN Nodes is applied, one or more MSCs serve a pool-area, but each individual MS is served by only one out of these MSCs, as described in TS 23.236. The main difference between a MSC and an exchange in a fixed network is that the MSC has to take into account the impact of the allocation of radio resources and the mobile nature of the subscribers and has to perform in addition, at least the following procedures:
procedures required for the location registration (see TS 23.012);
When needed, the MSC can be implemented in two different entities: the MSC Server, handling only signalling, and the CS-MGW, handling user's data. A MSC Server and a CS-MGW make up the full functionality of a MSC.
The CS fallback enabled MSC supports the following additional functions according to TS 23.272:
Maintaining SGs association towards MME for EPS/IMSI attached UE;
Supporting SMS procedures according to CS Fallback.
The MSC Server mainly comprises the call control (CC) and mobility control parts of a MSC.
The MSC Server is responsible for the control of mobile originated and mobile terminated CC CS Domain calls. It terminates the user-network signalling and translates it into the relevant network - network signalling. The MSC Server also contains a VLR to hold the mobile subscriber's service data and CAMEL related data.
The MSC Server controls the parts of the call state that pertain to connection control for media channels in a CS-MGW.
An MSC Server which has been enhanced for SRVCC provides the following functions as needed for support of SRVCC according to TS 23.216:
Handling the Relocation Preparation procedure requested for the voice component from MME via Sv interface;
Invoking the session transfer procedure from IMS to CS ;
Coordinating the CS Handover and session transfer procedures;
Handling the MAP_Update_Location procedure without it being triggered from the UE.
If a MSC Server is enhanced for IMS Centralized Services (as defined in TS 23.292), it is responsible for the CS to IMS interworking, and it terminates the user-network signalling received over the CS access (A/Iu and E interface) and translates it into SIP signalling in IMS and vice versa.
This component is PSTN/PLMN transport termination point for a defined network and interfaces UTRAN with the core network over Iu.
A CS-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). Over Iu, the CS-MGW may support media conversion, bearer control and payload processing (e.g. codec, echo canceller, conference bridge) for support of different Iu options for CS services (AAL2/ATM based as well as RTP/UDP/IP based).
Interacts with MGCF, MSC server and GMSC server for resource control.
Owns and handles resources such as echo cancellers etc.
May need to have Codecs.
The CS-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 CS-MGW bearer control and payload processing capabilities will also need to support mobile specific functions such as SRNS relocation/handover and anchoring. It is expected that current H.248  standard mechanisms can be applied to enable this.
If a network delivering a call to the PLMN cannot interrogate the HLR, the call is routed to an MSC. This MSC will interrogate the appropriate HLR and then route the call to the MSC where the mobile station is located. The MSC which performs the routing function to the actual location of the MS is called the Gateway MSC (GMSC).
The acceptance of an interrogation to an HLR is the decision of the operator.
The choice of which MSCs can act as Gateway MSCs is for the operator to decide (i.e. all MSCs or some designated MSCs).
If the call is a voice group/broadcast call, it is routed directly from the GMSC to the VBS/VGCS Anchor MSC, based on information (VBS/VGCS call reference) contained in the dialled number (see also TS 43.068 and TS 43.069).
When needed, the GMSC can be implemented in two different entities: the GMSC Server, handling only signalling, as defined below, and the CS-MGW, defined above. A GMSC Server and a CS-MGW make up the full functionality of a GMSC.
The Interworking Function (IWF) is a functional entity associated with the MSC. The IWF provides the functionality necessary to allow interworking between a PLMN and the fixed networks (ISDN, PSTN and PDNs). The functions of the IWF depend on the services and the type of fixed network. The IWF is required to convert the protocols used in the PLMN to those used in the appropriate fixed network. The IWF may have no functionality where the service implementation in the PLMN is directly compatible with that at the fixed network. The interworking functions are described in TS 29.007.
The UTRAN/GERAN PS-domain (or GPRS) Support Nodes (GSN) are the Gateway GSN (GGSN) and the Serving GSN (SGSN). They constitute the interface between the radio system and the fixed networks for packet switched services. The GSN performs all necessary functions in order to handle the packet transmission to and from the mobile stations.
The location register function in the SGSN stores two types of subscriber data needed to handle originating and terminating packet data transfer:
one or more temporary identities;
zero or more PDP addresses.
depending on the operating mode of the MS, the cell or the routeing area where the MS is registered;
the VLR number of the associated VLR (if the Gs interface is implemented);
the GGSN address of each GGSN for which an active PDP context exists.
The SGSN .provide support for Direct Tunnel functions as specified in TS 23.060.
The organisation of the subscriber data in the SGSN is defined in TS 23.008 and TS 23.060.
The procedures for information transfer between the SGSN, the GGSN, the VLR and the HLR are defined in TS 23.016 and TS 23.060.
The SGSN provides support for SRVCC functions as specified in TS 23.216.
The location register function in the GGSN stores subscriber data received from the HLR and the SGSN. There are two types of subscriber data needed to handle originating and terminating packet data transfer:
zero or more PDP addresses.
the SGSN address for the SGSN where the MS is registered.
The organisation of the subscriber data in the GGSN is defined in TS 23.008 and TS 23.060.
The procedures for information transfer between the GGSN, the SGSN and the HLR are defined in TS 23.016 and TS 23.060.
MME is the control plane entity within EPS supporting functions as listed below. For detailed functional role of MME, see specifications TS 23.401, TS 23.402 and TS 36.300.
NAS signalling and security;
Inter CN node signalling for mobility between 3GPP access networks;
Tracking Area list management;
PDN GW and Serving GW selection;
SGSN selection for handovers to 2G or 3G 3GPP access networks;
Bearer management functions including dedicated bearer establishment.
Lawful Interception of signalling traffic.
In order to support 3GPP2 access, MME supports:
HRPD access node selection and maintenance for handovers to HRPD;
Transparent transfer of HRPD signalling messages and transfer of status information between E-UTRAN and HRPD access;
Transparent transfer of RIM signalling messages between E-UTRAN and HRPD access;
The procedures for information transfer between the SGSN, the MME and the HSS are defined in TS 23.401 and TS 23.060.
The CS fallback enabled MME supports the following additional functions according to TS 23.272:
Deriving a VLR number and LAI out of the TAI
Maintaining of SGs association towards MSC/VLR for EPS/IMSI attached UE
Initiating IMSI detach at EPS detach
Initiating paging procedure towards eNodeB when MSC pages the UE for CS services
Supporting SMS procedures for CS Fallback.
Support CS Fallback interface and related functions for 1xRTT CDMA access.
When the MME supports the interworking to 3GPP CS, the MME supports the following functions as specified in TS 23.216:
Performing the PS bearer splitting function by separating the voice PS bearer from the non-voice PS bearers.
Handling the non-voice PS bearers handover with the target cell as according to Inter RAT handover procedure as defined in TS 23.401.
Initiating the SRVCC handover procedure for handover of the voice component to the target cell.
Coordinating PS handover and SRVCC handover procedures when both procedures are performed,
support interworking and SRVCC related functions for 1xRTT CDMA access.
The Serving GW is the gateway which terminates the interface towards E-UTRAN.
For each UE associated with the EPS, at a given point of time, there is a single Serving GW. For detailed S-GW functions, see TS 23.401 and TS 23.402.
Connectivity to a GGSN is not supported.
The functions of the Serving GW include:
the local Mobility Anchor point for inter-eNodeB handover;
Mobility anchoring for inter-3GPP mobility;
ECM-IDLE mode downlink packet buffering and initiation of network triggered service request procedure;
Packet routeing and forwarding;
Transport level packet marking in the uplink and the downlink;
Accounting on user and QCI granularity for inter-operator charging;
A local non-3GPP anchor for the case of roaming when the non-3GPP IP accesses connected to the VPLMN;
Event reporting (change of RAT, etc.) to the PCRF;
Uplink and downlink bearer binding towards 3GPP accesses as defined in TS 23.203;
Uplink bearer binding verification with packet dropping of "misbehaving UL traffic";
Mobile Access Gateway (MAG) functions if PMIP-based S5 or S8 is used;
Support necessary functions in order for enabling GTP/PMIP chaining functions.
The Serving GW can be split into SGW-C and SGW-U, which jointly provide above functionalities. The functional split between SGW-C and SGW-U are defined in TS 23.214.
The PDN GW is the gateway which terminates the SGi interface towards the PDN.
If a UE is accessing multiple PDNs, there may be more than one PDN GW for that UE, however a mix of S5/S8 connectivity and Gn/Gp connectivity is not supported for that UE simultaneously.
The PDN GW provides PDN connectivity to both GERAN/UTRAN only UEs and E UTRAN capable UEs using any of E UTRAN, GERAN or UTRAN. The PDN GW provides PDN connectivity to E UTRAN capable UEs using E UTRAN only over the S5/S8 interface. The PDN GW may also provide PDN connectivity to UEs using non-3GPP access networks with the procedures defined in TS 23.402.
For detailed PDN GW functions, see TS 23.401 and TS 23.402.
PDN GW functions include:
Per-user based packet filtering (by e.g. deep packet inspection);
UE IP address allocation;
Transport level packet marking in the uplink and downlink, e.g. setting the DiffServ Code Point, based on the QCI of the associated EPS bearer;
UL and DL service level charging, gating control, rate enforcement as defined in TS 23.203;
UL and DL rate enforcement based on APN-AMBR;
DL rate enforcement based on the accumulated MBRs of the aggregate of SDFs with the same GBR QCI
(e.g. by rate policing/shaping);
DHCPv4 (server and client) and DHCPv6 (client and server) functions;
Additionally the PDN GW includes the following functions for the GTP-based S5/S8/S2a/S2b:
Trusted and Untrusted Non-3GPP Access Networks are IP access networks that use access technology whose specification is out of the scope of 3GPP.
Whether a Non-3GPP IP access network is Trusted or Untrusted is not a characteristic of the access network.
In non-roaming scenario it is the HPLMN's operator decision if a Non-3GPP IP access network is used as Trusted or Untrusted Non-3GPP Access Network.
In roaming scenario, the HSS/3GPP AAA Server in HPLMN makes the final decision of whether a Non-3GPP IP access network is used as Trusted or Untrusted non-3GPP Access Network. The HSS/3GPP AAA Server may take the VPLMN's policy and capability returned from the 3GPP AAA Proxy or roaming agreement into account.
For details, see TS 23.402.
Functionality defined for the PDG in TS 23.234 for the allocation of a remote IP address as an IP address local to the ePDG which is used as CoA when S2c is used;
Functionality for transportation of a remote IP address as an IP address specific to a PDN when S2b is used;
Routing of packets from/to PDN GW (and from/to Serving GW if it is used as local anchor in VPLMN) to/from UE; if GTP based S2b is used, this includes routing of uplink packets based on the uplink packet filters in the TFTs assigned to the S2b bearers of the PDN connection;
Routing of downlink packets towards the SWu instance associated to the PDN connection;
De-capsulation/Encapsulation of packets for IPSec and, if network based mobility (S2b) is used, for GTP or PMIP tunnels;
Mobile Access Gateway (MAG) for PMIPv6 if PMIP based S2b is used;
Tunnel authentication and authorization (termination of IKEv2 signalling and relay via AAA messages);
Local mobility anchor within untrusted non-3GPP access networks using MOBIKE (if needed);
Transport level packet marking in the uplink;
Enforcement of QoS policies based on information received via AAA infrastructure;
The 3GPP AAA Server is located at the HPLMN and provides support for non-3GPP Access users with services like Authentication, Authorisation and location management services in order to get access to EPS. It also contains necessary user related information in order to grant access to non-3GPP access. It also coordinates the information needed to support mobility between 3GPP and non-3GPP accesses such as coordination of PDN GW information. It interacts with HSS to maintain consistent information for users supporting mobility and service continuity between 3GPP and non-3GPP access. For details, see TS 23.402.
The 3GPP AAA Proxy provides support for roaming non-3GPP Access users in the VPLMN necessary the Authentication, Authorisation and location management services in order to get access to EPS. It may also provide roaming related information for support of chaining scenarios as described in TS 23.402. If an S-GW is needed for non-3GPP access in the visited network, the 3GPP AAA proxy selects an S-GW for the UE during initial attach or handover attach.
The ANDSF (which is an optional element in the architecture) contains data management and control functionality necessary to provide network discovery and selection assistance data as per operators' policy. The ANDSF is able to initiate data transfer to the UE, based on network triggers, and respond to requests from the UE. It provides functions such as inter-system mobility policy, access network discovery information.
The ANDSF in the subscriber's home operator network may interact with other databases such as the HSS user profile information residing in subscriber's home operator network. Details of such interaction with these databases are not described in this Release of the specifications. For details on ANDSF, see TS 23.402.
The Border Gateway (BG) is a gateway between a PLMN supporting GPRS/EPC and an external inter-PLMN backbone network used to interconnect with other PLMNs also supporting GPRS/EPC. The role of the BG is to provide the appropriate level of security to protect the PLMN and its subscribers.
The BG is only needed in PLMNs supporting GPRS and EPC.