2.1.1 Overview

The support for emergency calls, that is, calls to a special emergency center, is a mandatory functionality in all cellular wireless networks. Strictly speaking, User Equipment (UE) support of emergency calls is only required under the condition that the UE supports also speech calls. So a data card UE with no speech call support does not need to support emergency calls. In principle, emergency services can use other means for communication as well, for example, text messages for disabled persons or video calls.

Emergency calls will be routed to a call center called PSAP (Public Safety Answering Point). In general, a call is routed to a particular PSAP based on the dialed number (such as 911 or 112) and location of the user in accordance with national regulations. There are different emergency call centers for police, ambulance, fire brigade, marine guard, and mountain rescue depending on the type of emergency. Emergency call centers may be connected to the Public Switched Telephone Network (PSTN), Circuit-Switched (CS) domain, Packet Switched (PS) domain, or any other packet network. For historical reasons they are still connected to the PSTN but a transition to IP-based PSAPs is underway in some countries. An emergency call over the Long-Term Evolution (LTE) Internet Protocol (IP)-based network utilizes IP Multimedia Subsystem (IMS) as application over the top. Both LTE and IMS required some adaptations to fulfill regulatory requirements and enable emergency calls.

2.1.2 Requirements

Subject to local regulations, emergency calls are prioritized over nonemergency calls by the network. National regulations may also require wireless networks to provide emergency caller's location to the dispatcher. Emergency calls may be supplemented with emergency-related data. Support of so-called PSAP callback sessions, that is, the network recognizes that a call is a callback from the PSAP to the originator of the emergency call (e.g., to get more information about an accident) and handles this call differently compared to normal calls, is also subject to local regulation.

National regulations may decide whether networks should accept emergency calls from unauthenticated UEs or UEs without an Universal Subscriber Identity Module (USIM), thus networks must provide the ability to either allow or not allow emergency calls without USIM. As USIM-less emergency calls were misused by people in the past to test a mobile phone or dial fake emergency calls, these kinds of calls are no longer allowed in most countries. To support emergency calls without USIM or emergency calls placed by UEs that are connecting to a network they are not allowed, a special emergency registration and attach procedure was added to LTE. This allows UEs to place emergency calls even when normal registration would be rejected by the network. UEs can be divided in the following categories depending on which requirements must be fulfilled to place an emergency call over LTE:

1. Normal service UE(s). First category of UE(s) are the ones that have a valid subscription, can be authenticated and authorized for PS services and in addition, they are able to perform IMS registration in the registered location. If not attached already, such UEs perform a normal attach as they would do for any other call and initiate a UE requested Packet Data Network (PDN) connectivity procedure for emergency services with request type “emergency” when they detect that the user tries to make an emergency call. Normal attach will allow the UE to obtain regular services in addition to emergency services unlike emergency attach which allows the UE to obtain emergency services only.
2. Only UEs that can be authenticated are allowed. These UEs must have a valid USIM. These UEs are authenticated but may be in a so-called limited service state due to being in a location where they are not allowed to obtain service. UEs that cannot be authenticated will be rejected.
3. UEs that can be identified but authentication is optional. These UEs must have an USIM. If authentication fails for whatever reason, the UE is in limited service state but is granted access and the unauthenticated International Mobile Subscriber Identity (IMSI) is retained in the network for recording purposes. The network must request the device identity International Mobile Equipment Identity (IMEI) and use it as device identifier. UEs without USIM or without an unlocked USIM will be rejected.
4. All UEs are allowed. Along with authenticated UEs, this includes UEs with an IMSI that cannot be authenticated (e.g., due to an expired subscription or no valid roaming agreement) and UEs with only an IMEI (e.g., no USIM or USIM cannot be unlocked by the entered PIN code). This is again referred to as UEs in limited service state. If an unauthenticated IMSI is provided by the UE, the unauthenticated IMSI is retained in the network for recording purposes. The IMEI is used in the network to identify the device.

2.1.3 Emergency Call Architecture

Emergency calls in LTE are supported using either IMS or CS fallback. The IMS architecture for supporting emergency services is defined in the 3rd Generation Partnership Program (3GPP) Technical Specification (TS) 23.167 [1] and the Evolved Packet System (EPS) level aspects in 3GPP TS 23.401 [2]. The CS fallback architecture is specified in 3GPP TS 23.272 [3]. In current Global System for Mobile Communications (GSM)/Wideband Code Division Multiple Access (WCDMA)/Code Division Multiple Access (CDMA) networks, emergency calls are supported via the CS domain. CS Fallback procedure was defined for LTE in 3GPP since Release 8. Emergency calls can be supported in LTE with CS fallback toward GSM/WCDMA (CDMA case) networks. If Circuit-Switched Fall Back (CSFB) is not supported, the UE can autonomously switch to a neighboring GSM/WCDMA/CDMA network to initiate emergency calls. IMS Voice over IP (VoIP) emergency call support over LTE has been specified in 3GPP Release 9.

2.1.3.1 IMS Emergency Calls

Emergency services are provided locally by the serving network, that is, whenever a user roams into a foreign country and dials a well-known emergency number the call is routed to the nearest PSAP in this country. As voice services over LTE may utilize IMS (known as “VoLTE” service), IMS and LTE must support emergency calls to fulfill regulatory requirements. This section provides more insights into the architecture for IMS emergency calls over LTE and related procedures. High-level architecture is shown in Figure 2.1.

In contrary to normal voice calls over IMS, emergency calls over IMS require special treatment in the device, network (LTE/System Architecture Evolution (SAE)), and on the application layer (IMS). We have hinted some of these special requirements in the previous sections but here is a summary again:

• Emergency calls are routed locally in the (visited or roaming) network to the next available PSAP or emergency service center.
• In some countries, a PSAP must be able to callback the originator of the emergency call.
• The network must be able to provide accurate information about caller's location to the PSAP.
• Depending on the local regulation, devices in limited service state that are not allowed to connect to the whole network or not in a certain area for normal services must be able to make an emergency call.
• Depending on the local regulation, devices without USIM must be able to make an emergency call.
• Emergency calls deserve prioritized handling, for example, when the network is in a congestion situation or in overload.
• In order to allow a clear cost split between emergency and other services, resources reserved for an emergency connection are not allowed to be used for other services such as normal voice calls. By doing so, the operator can decide how to charge emergency calls. For example, depending on the country, the service may be sponsored by the national government or the wireless service provider. In some cases, wireless service providers may choose to pass on their costs of providing emergency services to their end customers.

The listed general requirements translate into the following high-level roles and responsibilities of devices and network elements during an emergency call setup.

UE

A UE can either camp normally in a suitable cell (i.e., selected cell is where normal services are offered) or camp in “limited service” state in the selected cell. If the UE is unable to find a suitable cell to camp on (i.e., selected cell is unable to provide normal service due to reasons such as lack of subscription, roaming agreement, etc.), then it enters “limited service” state. Detailed cell selection criteria and idle mode camping procedures for the UE are specified in 3GPP TS 36.304 [4] and 3GPP TS 23.122 [5].

UEs camping normally in a suitable cell needs to perform the following two main functions:

1. Initiate normal attach, if not attached already.
2. Initiate a special UE-requested PDN connectivity procedure for emergency services. The PDN connection request carries a special request type set to “emergency,” which allows the network to detect request for an emergency connection quite easily. In addition, the UE shall not include an APN (Access Point Name) when the request is for emergency.

UE(s) camping in “limited service” state in the selected cell needs to perform the following two main functions:

1. Initiate a special emergency attach procedure. The network can prioritize an emergency attach in case of congestion and suppress subscription checking and authentication/authorization procedures.
2. Initiate a special UE-requested PDN connectivity procedure for emergency services with emergency request type but no APN (this step is the same as for UEs camping normally).

eNodeB

It broadcasts support for IMS emergency calls to all UEs in coverage. It prioritizes the establishment of radio resources for requests based on emergency indicator. Prioritizes user plane establishment and retains existing user plane for emergency services based on QoS Class Identifier (QCI) and Address Resolution Protocol (ARP) in case of resource contention.

MME

Mobility Management Entity (MME) prioritizes the Attach and PDN connectivity requests from UEs when request is marked for emergency usage. MME stores emergency configuration data for use when UE requests for emergency bearer services. It retains emergency bearer services in case of overload and ignores certain restrictions for emergency-attached UEs (e.g., based on UEs location).

PDN-GW

When needed, Packet Data Network Gateway (PDN-GW) should have the ability to support initiating dedicated bearer establishment when an IMS VoIP emergency call is being established. PDN-GW starts a configurable inactivity timer (e.g., to enable PSAP call back) for the PDN connection when informed by the Policy and Charging Rules Function (PCRF) about an emergency service session.

PCRF

When informed by the Proxy Call Session Control Function (P-CSCF) that a new session is for emergency usage, PCRF removes all PCC rules with a QCI other than the default bearer QCI and the QCI used for IMS signaling. It also updates the PDN-GW.

MGCF/MGW

When converting a Session Initiation Protocol (SIP) to an ISDN User Part (ISUP) message within an emergency call, Media Gateway Control Function (MGCF) may indicate that the ISUP message (e.g., initial address message to setup the call) is high priority or for an emergency call. Such indications are normally country specific.

P-CSCF

Proxy CSCF has a list of emergency numbers in a certain country or worldwide known countries configured. Once an IMS emergency call is detected based on the received SIP URI or Tel URI, the P-CSCF forwards the call to the E-CSCF (see below) and informs the PCRF about a new session used for emergency services.

S-CSCF

Serving S-CSCF acts as the registrar for the IMS emergency registration including authentication. The S-CSCF is not in the call chain of the emergency call itself.

E-CSCF

Emergency Call State Control Function (E-CSCF) is a specific CSCF that takes the call handling role from the S-CSCF for emergency calls since only they require specific processing rules, for example, retrieving location information or disabling user-specific services such as call forwarding. E-CSCF determines the correct PSAP based on location information and routes emergency calls toward PSAP.

LRF

Location Retrieval Function (LRF) retrieves the location of the UE from the Location Server (LCS) and stores it. E-CSCF can interrogate the LRF for routing of emergency calls to the closest PSAP and for dispatching the emergency services to the right address.

RDF

Routing Determination Function (RDF) is usually integrated in a LCS or LRF, provides the proper PSAP destination address to the E-CSCF for routing the emergency request, that is, the RDF provides directly a routable SIP URI of the PSAP to E-CSCF. If there is no RDF in place, E-CSCF needs to translate location information and emergency number into a routable SIP address on its own.

Location Server (LCS)

Obtains the location of the UE. The LCS interacts with other network elements such as MME and/or eNodeB to retrieve UE's location. Location information can be in the simplest case just the cell ID from which the UE connects to the network or it can also be more accurate X–Y coordinates.

PSAP

A PSAP is a kind of call center responsible for answering calls destined to an emergency telephone number.

Procedure for IMS Emergency Calls

The signaling procedure for normally attached UEs for establishing an emergency call is not much different to a normal call setup procedure. The emergency call setup procedure for UEs in “normal service” state is shown in Figure 2.2.

The emergency call setup procedure for UEs in “limited service” state, shown in Figure 2.3, is by nature different from the procedure for UEs in “normal service” state.

An UE that can normally attach to the network initiates a PDN connectivity request procedure in order to perform an emergency call (reference Figure 2.2). An UE that intends to perform an emergency call but cannot attach normally due to either roaming restrictions or lack of valid credentials or lack of USIM performs an emergency attach by setting the attach type as emergency in the request (refer Figure 2.3).

The UE must identify itself during the attach procedure, both normal and emergency attach. The mobile identity can be a temporary identity assigned by the network or the subscription-based IMSI read from the USIM. For security reasons IMSI is used only, if no temporary identity exists.

When a device has got no USIM and therefore has none of the above-mentioned identities, then it can use its device identity (IMEI) in the emergency attach as the last resort. In this case, if the MME supports emergency attach with IMEI (e.g., based on local regulation), the MME skips authentication, ciphering, and integrity protection of those UEs that do not have security credentials and accepts attach.

If the MME does not support USIM-less emergency calls (e.g., local regulation does not allow this), receiving the IMEI as mobile identity triggers the MME to reject the emergency attach with IMEI and indicate to the UE that IMEI-based attach is not accepted.

The network stores emergency configuration data that consists of: QoS profile, Access Point Name-Aggregate Maximum Bit Rate (APN-AMBR), emergency APN, and statically configured P-GW. User subscription data will be ignored for emergency bearers. Unauthorized users may not have any subscription data.

For emergency use, the network can accept EPS Attach or Tracking Area Update (TAU) coming from an area that is forbidden for the UE, although normal services for the UE are still not allowed in that area.

If the UE has successfully registered to the network and has obtained emergency bearer resources when moving to an area where the UE is not allowed normal services by subscription, then after TAU the network must tear down all normal bearer resources, but maintain the emergency bearer resources. This case is related with regional roaming restrictions and the UE roaming outside of its regionally provisioned area in an allowed Public Land Mobile Network (PLMN). The logic behind is that emergency call does not allow the user to stretch other services to areas that are not allowed otherwise.

Bearer resource modification is not allowed for any PDN connection that has been established for emergency services. If the network receives such request from the UE, it must reject it. Default and dedicated bearers of a PDN connection associated with the emergency APN are always dedicated for emergency sessions. Additional PDN connections (i.e., besides the emergency PDN connection) are not allowed for UEs that are emergency attached. This is reasonable as the user does not have a proper subscription with the operator and the operator is not obligated to provide other services to the user except emergency services mandated by the national regulator.

Emergency calls are protected against network-initiated detach. If the UE has an emergency bearer context active, network-initiated detach requested by the Home Subscriber Server (HSS) should result in deactivation of all nonemergency bearer contexts. The network also attempts to maintain support for emergency bearer services in overload situations.

Upon successful establishment of emergency bearers, the UE may perform IMS emergency registration (as a prerequisite the UE needs to have all necessary credentials for IMS registration) (refer 3GPP TS 23.167 [1]). The UE performs IMS emergency registration in the following scenarios:

• If the UE is currently attached to its home operator's network (HPLMN, Home Public Land Mobile Network) and IMS registered, but the network indicates its support for emergency bearers.
• If the UE is currently attached to its home operator's network (HPLMN) but is not IMS registered.
• If the UE is attached to a different network, that is, not its home operator's network (Visited Public Land Mobile Network (VPLMN) in the home or foreign country). In this case, the UE may or may not be IMS registered with its HPLMN.

The UE does not perform an IMS emergency registration in the following cases:

• If the UE has no credentials, the UE establishes an IMS emergency call without IMS registration (support for this depends on local regulation).
• If the UE is currently attached to its home operator's network (HPLMN) and IMS registered, but the network does not support emergency bearers (this scenario depends on home network operator policies in which case the emergency call is treated like a normal call from EPS perspective). In this case, UE sets up an emergency call using the existing regular IMS registration.

The P-CSCF is configured to recognize an emergency call session and forwards the call set up to an appropriate E-CSCF. If available, the E-CSCF queries the LRF for location information. Afterwards the E-CSCF forwards the call to the proper PSAP either directly or via a MGCF.

2.1.3.2 CSFB Emergency Calls

Since not all LTE networks may deploy IMS and support voice (VoIP) services, 3GPP agreed to define CS fallback toward GSM/EDGE Radio Access Network (GERAN) and Universal Terrestrial Radio Access Network (UTRAN) network to support voice. CS fallback can be supported either using PS handover or network-assisted cell change. CS fallback to UTRAN is supported only using PS Handover while CS fallback to GERAN is supported using both PS handover and Network-Assisted Cell Change (NACC). These methods are illustrated in Figure 2.4.

When an emergency call is initiated the UE connects to the network by indicating “emergency” (refer TS 36.331 [6]). After it is successfully connected, UE sends a request for CSFB emergency call to the network. The MME redirects the UE toward 2G/3G network by instructing the eNB. Depending on the target cell, eNB triggers either PS handover or NACC procedure. If the Evolved NodeB (eNB) decides to perform PS handover, it triggers a normal PS handover procedure with CSFB indicator from LTE to UTRAN or GERAN. If eNB decides to trigger NACC, it commands the UE to move from LTE to GERAN. Upon completion of PS handover or cell change, UE connects to UTRAN or GERAN. Then, the UE initiates a CS emergency call setup in the UTRAN/GERAN CS domain.

2.1.4 PSAP Callback

The capability of the person in the PSAP to call back a UE, for example, in case the connection was interrupted has not been fully addressed in 3GPP. So, a PSAP callback is treated just like a normal call by the network. However, service requirements for PSAP callback exist since 3GPP release 7 in 3GPP TS 22.101 [7]. Actual definition in stage 3 and implementation of these requirements have been pending for completion of related work in Internet Engineering Task Force (IETF). IETF draft in Ref. [8] introduces “psap-callback” as another value for the SIP Priority header. This value indicates that the concerned SIP request is originated by the PSAP to a UE which had originated a call to that PSAP.

If no special PSAP callback indication is received, the call is to be treated as a normal voice call. PSAP or Emergency Centers are allowed to establish a call to which there had been an emergency call previously and the UE had registered with valid credentials. Indication that a call is a PSAP call back has to be supported when required by local regulation. If a terminating call has a PSAP call back indication, the UE should be able to detect this.

2.1.5 Emergency Numbers

If a user dials a local emergency number and the number is known to the UE, then the UE can detect that this is an emergency call. It is mandatory for the UE to store 112 and 911 among others as emergency numbers. There is multitude of emergency numbers used in countries across the globe. Hence, it is possible that a roaming UE does not detect all dialed numbers as an emergency number. If the dialed number is not detected by the UE as an emergency number, then the IMS network (P-CSCF) must recognize the number as emergency number and route the call to the next PSAP. Such a call will however use a normal PDN connection for IMS voice services.

Operators are allowed to add emergency numbers list to the UEs. This list contains numbers that are required for local needs. By default, the device must consider the following numbers as emergency numbers according to 3GPP TS 22.101 [7]:

1. 112 and 911 are always considered emergency numbers.
2. Any additional emergency numbers that are specified as such on the USIM.
3. 000, 08, 110, 118, 119, and 999 are considered as emergency numbers by a device without USIM.
4. Any additional emergency number that have been downloaded by the serving PLMN (VPLMN) to the device.

Although some countries may not use 112 or 911 as emergency numbers, the UE must always consider those as emergency numbers hence they cannot be used for any other purpose anywhere. Even if the national emergency number is, say 999, both 112 and 911 will also work as emergency numbers. Those inbound roamers who are used to the well-known numbers 112 and 911 at home can use them also when roaming in a foreign country.

In the countries where additional emergency numbers are used, the operators can configure the additional numbers on their subscribers' USIM.

2.1.6 Non Voice Emergency Services

For a typical emergency service, voice media is used to convey information between the caller and PSAP. However, there is a desire to allow individuals with disabilities (e.g., hearing impaired or speech disability) or under certain restricted situations (e.g., hiding from a suspect) to initiate an emergency session without a voice media or in addition to using voice media (e.g., sending a chat message, video, files, and so on while talking over the phone).

Emergency session in IMS without a voice component follows the same architecture and procedures as with voice sessions except that the media type will indicate that it is not voice related. The other allowed media types of IMS emergency sessions are real-time video (simplex or full duplex), text-based instant messaging, file transfer, video clip sharing, picture sharing, audio clip sharing, and Global Text Telephony (TTY).

Same as for emergency voice sessions, the use of nonvoice media is not a subscription-based service. Hence, a UE that is capable to establish IMS emergency sessions and supports other media types should also be capable to initiate IMS emergency session with media other than voice.

IMS emergency sessions can be initiated with both voice and nonvoice media together. If handover to a non-IMS voice supporting network (e.g., GSM) is required, then the voice media is maintained as CS emergency call but other nonvoice media will be removed.

2.1.7 Automated Emergency Calls

The eCall service is a European initiative intended to bring rapid assistance to motorists involved in a collision anywhere in the European Union. The eCall initiative aims to deploy a device installed in a vehicle that will automatically dial an emergency number (e.g., 112) in the event of a serious road accident to the closest emergency center, and wirelessly send airbag and sensor information, as well as GPS coordinates to local emergency agencies. The eCall service builds on the E112 emergency call. The European Commission is aiming to have a fully functional eCall service to be in place throughout the EU by 2015. It could be foreseen that eCall speeds up emergency response times significantly in urban areas and in rural areas.

The current eCall service is based on the circuit-switched emergency call in GSM and Universal Mobile Telecommunications System (UMTS) networks. eCall was deliberately designed in a way that works with any GSM or UMTS mobile network that deploys a CS domain. Thus, data are transferred in a circuit-switched channel using a special in-band codec during the first few seconds of the emergency call. Only after that, voice communication between the PSAP and the passengers in the vehicle is established. Figure 2.5 shows eCall information flow.

The longevity of GSM networks in the EU over the lifetime of vehicles is uncertain and GSM spectrum is likely to be reallocated for UMTS and/or LTE. In LTE, emergency calls can be placed either using CSFB or IMS. European Telecommunications Standards Institute (ETSI) Technical Committee Mobile Standards Group (TC MSG) has a work item on Migration of eCall Transport. As part of this study, Technical Report (see ETSI TR in Ref. [9]) was created. The scope of the document was to analyze the necessary adaptations of IMS emergency call and IMS Multimedia Emergency Service for supporting current and future services required by eCall, assessment of possible solution options, that is, in-band modem solution in case there is no use of CS bearers, Hybrid CS/IMS solution, and migration options. The IETF Emergency Context Resolution with Internet Technologies (ECRIT) is currently working on drafts for eCall [10] and Automatic Crash Notification (ACN) [11] contains information about activities outside Europe.

On the basis of input from ETSI [12], 3GPP has discussed about supporting eCall service based on VoLTE. When there is agreement to initiate such a work in 3GPP, the applicability of the existing technical solution for eCall (in-band modem) may be assessed as part of this work, as well as new technical solutions to be developed that are suitable for packet-switched networks such as UMTS and LTE.

2.3.1 Principles

Lawful (or Legal) Interception (LI) in public telecommunication networks is a regulatory obligation in basically every country around the world. Therefore, interception is an integral capability of each modern telecommunication network. The process to order and execute interception is strictly regulated by national laws and telecommunication regulations to avoid misuse of this function.

Even though the national laws require different details of interception functionality, the principal architecture is the same for almost all countries and network domains.

The 3GPP LI architecture provides the Law Enforcement Agency (LEA), a government agency responsible for the enforcement of laws, with three interfaces by which Lawful Interception can be initiated and data being delivered to the LEA. These interfaces are called Handover Interfaces 1, 2, and 3 (HI1, HI2, and HI3) (shown in Figure 2.7). “Handover” in this context does not refer to handover of a UE from one cell to another due to mobility but just to provide content from the network domain to the LEA domain.

Handover Interface 1 (HI1) is used to deliver the interception warrant order to the telecommunication provider and to initiate LI for certain subscribers. The HI1 interface is typically a fax-/paper-based interface and not standardized. The warrant describes the interception target (e.g., Mobile Subscriber ISDN Number (MSISDN), IMSI, or IMEI), the length of the interception period, and usually the delivery address of intercepted communication and events. These delivery addresses are used at the Handover Interface 2 (HI2) and Handover Interface 3 (HI3) along with other interception identifiers received with the warrant to send data to the LEA. The additional identifiers help the LEA to correlate interception data received via HI2 and HI3 interfaces regarding the same communication event.

HI2 delivers call-related data, for example, date, time, communicating party identifiers, call duration, used supplementary services, in a so-called Interception Record Information (IRI) event to the LEA. In case of a communication, an IRI contains correlation information enabling the LEA to identify the proper HI3 interception data.

HI3 can be used to provide a copy of the actual communication content (e.g., voice and video samples, data) to the LEA. This is valid for both circuit-switched and packed-switched communication. At the HI3 interface, correlation information is also delivered to the LEA to identify the matching HI2 IRI event reports. The LEA can instruct the network whether to deliver only call-related data or also the content.

Additional mediation functions in the network provide network hiding and postprocessing functionality for the IRIs and in some cases for the intercepted communication stream as well. They also duplicate the intercepted data toward several LEAs, if more than one LEA is intercepting the same target at the same time.

For security reasons, it is important to keep the interception warrant information, that is, who is going to be intercepted, secret. This information is not even accessible by network operator's maintenance personnel. Thus, eNodeB and UEs are not involved in the LI process as both of them are considered not trusted entities with respect to LI.

It has to be pointed out that LI mechanisms will also be applicable to Public Safety communication.

2.3.2 Lawful Interception for EPS

The Lawful Interception functionality for EPS was defined during 3GPP Release 8. The content of communication (in general IP packets) and interception-related information is provided by the EPS gateway nodes Serving Gateway (S-GW) or optionally Packet Data Network Gateway (P-GW). Additional header information is added to the intercepted packets. This extra header allows identifying the actual interception and correlates the HI3 interception data with the HI2 IRI event reports.

Additionally, the MME and the HSS also provide interception-related information to the LEA as they play an important role in mobility management procedures like handover and in case of roaming.

The EPS interception configuration architecture can be found in 3GPP TS 33.107 [15], while 3GPP TS 33.108 [16] specifies the encoding of intercepted content and interception-related information.