WO2015160295A1

WO2015160295A1 - Methods and nodes for ensuring trusted warrants in li systems

Info

Publication number: WO2015160295A1
Application number: PCT/SE2014/050471
Authority: WO
Inventors: Antonio GIARDANO; Luigi SARTORATO
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2014-04-16
Filing date: 2014-04-16
Publication date: 2015-10-22

Abstract

The present invention comprises a number of nodes (N210; 230; 240) and methods in said nodes in a Lawful Intercept system enabling detection of unauthorized request of interception if the target belongs to a special list of identity that are not allowed to be intercepted. To achieve this objective, a new node (240) comprising a Trust Server (TS) is introduced in the network, said node containing all information about sensitive targets for e.g. a country. The solution is based on a list, a kind of RED-List, of said sensitive targets that are forbidden to intercept. These sensitive targets are e.g. certain persons or institutions. The list, or information, is stored in a node on secure location on the Law Enforcement Agency side.

Description

Methods and nodes for ensuring trusted warrants in LI systems

TECHNICAL FIELD

The present technology relates to nodes and methods in said nodes for ensuring the use of trusted warrants in LI systems.

BACKGROUND

Figure 1 shows the 3GPP standardized interfaces for LI in the packet domain.

Figure 1 is a block diagram of an exemplary Lawful Interception (LI) system 1 10 and network 10 according to prior art. Said system and network comprises a number of entities. The exemplary LI system comprises a Law Enforcement Management Function, LEMF, 12 for requesting LI services of the LI system and collecting the intercepted information of Intercepting Access Points, lAPs, 20 in the system. The system shall provide access to the intercepted Content of Communications, CC, and Intercept Related Information, IRI, of a target and services related to the target on behalf of one or more Law Enforcement Agencies, LEAs 80. A target is a person of interest and/or user equipment possessed or used by the person of interest being surveyed by the LEA. An intercept request, also denoted Request for LI activation, is sent through a first Handover Interface, HI1 , located between the Law Enforcement Management Function 12 and an Intercept Mediation and Delivery Unit, IMDU, 14 comprising a Mediation Function, MF, 16 and an Administration Function, ADMF, 18. Said Mediation Function 16 and Administration Function 18 generate based on said received request a warrant comprising said one or more target identities, and sends said warrant towards an Intercept Control Element, ICE, in an Interception Access Point, IAP, 20 via an interface denoted X1_1 . The IAP 20 may be connected to a node of a network, e.g. the Internet, a 3GMS (third generation Mobile Communications System), an Evolved Packet System (EPS) etc, from which it intercepts said Content of Communications and Intercept Related Information of a mobile target. Said CC and IRI are network related data. As reference to the standard model, see references [1 ], [2] and [3], the content of communication is intercepted in the lAP network node and it is based upon duplication of target communication payload without modification. In reference [3], the interfaces HI1 and HI2 are specified in more detail. The lAP sends IRI raw data via an interface X2 to a Delivery Function for IRI reporting, DF2, 22 and a Mediation Function of IRI, MF2, 24 that generates and delivers to a collection functionality a standardized IRI report based on the received IRI report. Said standardized IRI report is sent over a standardized interface HI2 to the LEMF 12. The lAP 20 also sends CC raw data via an interface X3 to a Delivery Function for CC reporting, DF3, 26 and a Mediation Function of IRI, MF3, 28 which generates and delivers to a collection functionality a standardized CC report based on the received CC report. Said standardized CC report is sent over a standardized interface HI3 to the requesting LEMF 12.

Together with the delivery functions it is used to hide from the third generation (3G) Intercepting Access Point lAP entities that there might be multiple activations by different Lawful Enforcement Agencies on the same target.

The HI2 and HI3-interfaces represent the interfaces between the LEA and two delivery functions. The delivery functions are used:

- to distribute the Intercept Related Information (IRI) to the relevant LEA(s) via HI2;

- to distribute the Content of Communication (CC) to the relevant LEA(s) via HI3.

According to known internet access services, all the IP streams related to a given target is intercepted and delivered as a whole session data flow regardless any service used within an interception session.

In the example in figure 1 , the lAP 20 is connected to, or contained within a user plane gateway, PGW, in a node 140 in a CN 1 15. The lAP may be connected to any type of user plane gateway, e.g. SGW, PGW and GGSN. The same interfaces are also used for control plane nodes like MME and HLR/HSS. Streams of content flow through the user plane gateway in both directions to the UE and from the UE. In one direction, content may come from any site within the CN or any site 1 19 in a connected communications network 1 17, e.g. LAN, WLAN, WAN, RAN, etc. The flow passes the (S)Gi interface connected to the user plane gateway. LI is therefore possible to perform. The flow passes an interface S5 between the PGW node 140 and a SGW node 150, and through an interface S1 -U between the SGW node 150 and a RAN/eNB 160 comprising one or more radio base stations, e.g. eNB. The radio base station forwards the content flow via the air interface LTE-Uu to the designated UE 170.

In the other direction, flow of packets comprising content generated by the UE passes the same interfaces, nodes and gateways. When passing the IAP entity, LI is performed.

As described above, a network shall provide access to the intercepted CC and the IRI of the mobile target and services related to the target, e.g. Call Forwarding, on behalf of LEAs. The LEA provides the intercept request, e.g. lawful authorization or warrant to the CSP. The intercept request identifies, at a minimum, the target, the type of intercept i.e. , IRI-only, or IRI and CC that is authorized, the authorized period for interception, and the LEA delivery address(-es) for the intercepted information.

The Communication Service Provider, CSP, shall securely administer the intercept (e.g. , to activate, deactivate, show, or list targets) within the network as quickly as possible. The CSP's administration function shall use appropriate authentication and audit procedures.

Currently the CSP is responsible to maintain and securely administer interception, obviously a malicious operator is able to insert unauthorized interceptions request towards the network. These "fraudulent warrants" are not easily to detect. SUMMARY

One object of the following solution is to mitigate the risk and thereby avoiding unauthorized requests if related to specific identity not interceptable by definition.

To achieve said object, a method and different embodiments of the method is provided. Said method is performed in a node comprising a target check functionality for supporting one or more Lawful Intercept, LI, systems. The method comprises receiving a request for target check, performing target check in one or more target registers, generating a response as a result of the target check, and sending a response comprising the result of the target check.

It is further provided a method, and embodiments thereof, in a LI system node comprising an Intercept Mediation and Deliver functionality. Said method comprises receiving an add_warrant message for an indicated target, sending a request for target check to a node comprising a target check functionality, receiving a response comprising a result of the target check, deciding whether to generate an add_warrant_massage or inhibit the generation of said message due to the received result, and forwarding the add_warrant message, if generated.

An additional method, and embodiments thereof, is provided, wherein the method is performed in a LI system node comprising an Intercept Mediation and Deliver functionality. Said method comprises receiving a request for target information modification, sending a request for target check to a node comprising a target check functionality, receiving a response comprising a result of the target check, and forwarding the request for target information modification to the Intercept Access Point, IAP.

Further one method in a LI system node comprising an Intercept Mediation and Deliver functionality is provided. Said method, and embodiments thereof, comprises receiving a request for target deactivation, sending a request for target check to a node comprising a target check functionality, receiving a response comprising a result of the target check, and forwarding the request for target deactivation to the Intercept Access Point, IAP.

It is also provided a method in a node of a Law Enforcement Agency. The method, and embodiments thereof, is enabling administration and handling of a node comprising target check functionality. Said method comprises sending an updating message over a management interface to the node comprising target check functionality, and receiving a response message over the management interface from the node comprising target check functionality.

An additional method, and embodiments thereof, is provided. The method is performed in a node comprising target check functionality. The method comprises receiving an updating message over a management interface from a Law Enforcement Agency, LEA, processing information regarding a sensitive target's identity, type and value, and sending a response message over the management interface to the node comprising the LEA.

For achieving the stated object and other objects, different nodes, and embodiments thereof, are also provided.

It is provided a node, and embodiments thereof, comprising a target check functionality for supporting one or more Lawful Intercept, LI, systems. Said node comprises an interface unit adapted to receive a request for target check and to send a response comprising the result of the target check, and processing means adapted to perform a target check in one or more target registers and to generate a response as a result of the target check.

It is further provided herein, a node, and embodiments thereof, comprising an Intercept Mediation and Deliver functionality. Said node comprises an interface unit and a processing means, which is adapted to receive an add warrant message for an indicated target, to generate and to send, via the interface unit, a request for target check to a node comprising a target check functionality, to receive a response comprising a result of the target check, to decide whether to generate an add_warrant message or inhibit said message due to the received result, and to forward the add_warrant message if generated.

A node, and embodiments thereof, comprising an Intercept Mediation and Deliver functionality, an interface unit and a processing means may further be adapted to receive a request for target information modification, to send a request for target check to a node comprising a target check functionality, to receive a response comprising a result of the target, and to forward the request for target information modification to the Intercept Access Point, IAP.

A node, and embodiments thereof, comprising an Intercept Mediation and Deliver functionality, an interface unit and a processing means may further be adapted to receive a request for target deactivation, to send a request for target check to a node comprising a target check functionality, to receive a response comprising a result of the target check, and to forward the request for target deactivation to the Intercept Access Point, IAP.

It is further provided a node of a Law Enforcement Agency, said node and embodiments thereof comprising an interface unit and a processing means, which is adapted to send an updating message over a management interface to the node comprising target check functionality, and to receive a response message over the management interface from the node comprising target check functionality.

It is also provided a node, and embodiments thereof, comprising a target check functionality for supporting one or more Lawful Intercept, LI, systems. Said node comprises an interface unit adapted to receive an updating message over a management interface from a Law Enforcement Agency, LEA, and processing means adapted to process information regarding a sensitive target's identity, type and value, and to send a response message, via the interface unit, over the management interface to the node comprising LEA.

There are also herein provided different computer program, and embodiments thereof, comprising computer program code which, when run in a processor means of a node, causes the node to perform the method steps of the herein provided methods, and embodiments thereof.

It is also provided computer program products comprising computer program and computer readable means on which the computer programs are stored.

It is also provided herein, carriers containing the computer programs wherein the carriers are any of an electronic signal, optical signal, radio signal or computer readable storage medium.

One advantage of the above mentioned solutions is that it allows the detection of unauthorized request of interception if the target belongs to a special list of identities that are not allowed to intercept.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing, and other, objects, features and advantages of the present technology will be more readily understood upon reading the following detailed description in conjunction with the drawings in which:

Figure 1 is a block diagram of an exemplary LI network and system according to prior art;

Figure 2 is a block diagram and a system overview for ensuring trusted warrants;

Figure 3 is a signalling scheme illustrating an example of a scenario of the process for checking targets and corresponding warrants;

Figure 4 is signalling scheme illustrating an example of another scenario the process for checking targets and corresponding warrants;

Figure 5A is a signalling scheme illustrating an example of a target modification signalling process;

Figure 5B is a signalling scheme illustrating another example of the target modification signalling process;

Figure 6A is a signalling scheme illustrating an example of a target deactivation signalling process;

Figure 6B is a signalling scheme illustrating another example of the target deactivation signalling process; Figure 7 is a flowchart illustrating an embodiment of a method for target checking in a node comprising target check functionality;

Figure 8 is a flowchart illustrating further one embodiment of the method for target checking in a node comprising target check functionality;

Figure 9 is a flowchart illustrating an example of a method for sending a target check request from a LI system node to a node comprising target check functionality;

Figure 10 is a flowchart illustrating one embodiment of the method for sending a target check request from the LI system node to the node comprising target check functionality;

Figure 1 1 is a flowchart of a method for enabling a node to send a request for target checking upon reception on a request for target information modification;

Figure 12 is a flowchart of a method for enabling a node to send a request for target checking upon reception on a request for target

deactivation;

Figure 13 is a block diagram of an exemplary LI system and network for enabling target check for sensitive targets;

Figure 14 is a signalling scheme illustrating an example of an updating action for inserting a new sensitive target in a node comprising target check functionality;

Figure 15 is a signalling scheme illustrating an example of an updating action for removing a sensitive target in a node comprising target check functionality;

Figure 16 is a flowchart of a method for administrating and handling a node comprising target check functionality;

Figure 17 is a flowchart of a method for updating target information in a node comprising target check functionality;

Figure 18 is a flowchart of an embodiment of the method for updating target information in a node comprising target check functionality;

Figure 19 is a flowchart of another embodiment of the method for updating target information in a node comprising target check functionality; Figure 20 is a block diagram illustrating one example of an embodiment of a node comprising target check functionality;

Figure 21 is a block diagram illustrating one example of an embodiment of a node comprising an IMDU of a LI system;

Figure 22 is a block diagram illustrating one example of an embodiment of a node of a LEA.

DETAILED DESCRIPTION

In the following description, for purposes of explanation and not limitation, specific details are set forth, such as particular circuits, circuit components, techniques, etc. in order to provide a thorough understanding of the present technology. However, it will be apparent to one skilled in the art that the present technology may be practiced in other embodiments that depart from these specific details. In other instances, detailed descriptions of well-known methods, devices, and circuits are omitted so as not to obscure the description of the present technology with unnecessary detail.

Figure 2 is a system overview of the technique to ensure trusted warrants to be used in LI systems.

The system 200 is schematically illustrated in fig. 2. The system involves a number of LI systems serving different LEAs 230 via Law

Enforcement Management Functions, LEMFs, as described in the

background. Each LI system involves an IMDU 210 and lAPs 220 connected to nodes in different operator/CSP networks. The IMDU 210 communicates with the lAPs 220 via X1_1 interfaces. The IMDUs 210 and the LEAs 220 communicate via HI1 interfaces.

The solution allows detecting of unauthorized request of interception if the target belongs to a special list of identity that should not be intercepted. To achieve this objective a new node is introduced in the network, said node being provided with a target check function which is herein denoted Trust Server (TS), containing all information about sensitive target for e.g. a country. The solution is based on a list of special targets, similar to a RED-List, that are forbidden to intercept. Said special targets for which lawful intercept is not allowed are herein denoted sensitive targets. The list, or information, is stored in a secure position on LEA side. An example of stored information is described in Table 1 - Content example of Trust Server.

The Intercept Mediation and Delivery Unit, IMDU, communicates with Trust Server by means of a new X interface, X4. When an operator creates a warrant, the system 200 checks the trust ability of such operation by performing a query towards a new node 240, here Trust Server,

implementing the "RED-List" functionality, which consists of the following operation:

• Check Warrant reliability

If the check is indicating a hit in the "RED-List", the malicious warrant is not created and IMDU sends an alarm towards LEA informing about the faulty situation, using three new dedicated HI1 events:

1. LI activation for a sensitive target denied: Is sent when a request of activation is for a sensitive target. IMDU denies the operation and no command is sent towards lAPs.

2. LI modified for a sensitive target: Is sent when a request of

modification is for a sensitive target. IMDU performs the operation and the proper command is sent towards lAPs but the LEA must be warned. This case could take place when the sensitive target is added and/or modified in the "RED-List" after warrant creation.

3. LI deactivated for a sensitive target: Is sent when a request of deactivation is for a sensitive target. IMDU performs the operation and the proper command is sent towards lAPs but the LEA must be warned. This case could take place when the sensitive target is deactivated and/or removed in the RED-List after warrant creation.

If the check is negative, i.e. there is no hit in the "RED-List", the warrant is correctly created as already implemented according to prior art. A LEA is allowed to communicate with the Trust server via a Trust Server Management Interface, TSMI.

A private directly connected terminal should be used to manage sensitive target in the Trust Server. If there is a need to manage the Trust Server from more than one client, then the Trust Server should expose his action as API in order to grant access from several government offices. All links between Trust Server and clients must be secured using encryption protocols.

Identity Target Type Target Value

Jhon Smith IMEI 011582001428839

Jhon Smith MSISDN 3345665123

Peter Red MSISDN 3366632127

Table 1 - Content example of TRUST Server

Depending on the Trust Server response, there may be two kind of behaviour applicable for operation of adding, removing or modifying a warrant. The different cases are explained in more detail in the following description by means of the enclosed diagrams.

Given the sensitive information managed by Trust Server, it should be placed in a secure site, for example in a governmentally controlled building. Trust Server should be unique for country, this means that several

Communications Service Providers, or Network Operators, can access to the single point of warrant reliability.

There are at least two actions in the Trust Server:

• lnsert_Sensitive_Target, wherein a new sensitive target is

inserted in the trust server;

· Remove_Sensitive_Target, wherein a new sensitive target is removed in the trust server. Figures 3 and 4 are signalling schemes illustrating examples of add_warrant signalling processes between four nodes in a system as given in figure 2.

Figure 3 illustrates an example of a signalling process when the target check does not result in a hit, i.e. match, in its stored sensitive target list.

Figure 4, on the other hand, illustrates an example of a signalling process when the target check does result in a hit, i.e. match, in its stored sensitive target list.

The nodes are a LEA communicating via a LEMF function, an operator communicating via an IMDU, a node comprising an IAP, and a node comprising a Trust Server, TS.

A LEA generates a warrant and, by means of the LEMF, sends an add_warrant message to the IMDU via the HI1 interface. The IMDU is provided with a function for sending a request for target check for each received add_warrant message. The TS comprises a target function, which is configured to receive a request for target check, perform a target check for each received request for target check, and to send the result of check to the IMDU.

The TS comprises a processing means such as a programmable processor executing a program of instructions to perform functions of the target check functionality by operating on input data and generating output. The target check functionality may thus be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by the programmable processor. Further, the TS comprises a "RED-list" or database of information containing sensitive targets for which lawful intercept is not allowed.

Figure 3 illustrates a scenario where the target check does not result in a hit in its stored sensitive target list. Thus, the target of the request is not a sensitive target. Therefore, the response message sent back to the IMDU comprises the information that the target check resulted in a "no hit". The IMDU is adapted to receive the response from the trust server node, and to interpret the result information in the response, i.e. hit or "no_hit".

When the result is "no matching", or "no_hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of LI activation: LI activation for a target. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the target in question will be intercepted by the LI system.

The IMDU is further configured to forward the add_warrant message to the IAP for reception and registration in the IAP. The IAP is then configured to generate and send a confirmation response, add_warrant_response, back to the IMDU. The IMDU receives the response and register the received add_warrant response. The signalling process is then registered and finalized.

Figure 4 illustrates a scenario where the target check does result in a match in its stored sensitive target list. Thus, the target of the request is a sensitive target. Therefore, the response message sent back to the IMDU comprises the information that the target check resulted in a hit.

The IMDU is adapted to receive the response from the trust server node, and to interpret the result information in the response.

As the result was "hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of LI activation: LI activation for a target denied. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the target in question will not be intercepted by the LI system. Thus, the method and the system have worked properly and fraudulent warrant activation is denied and prohibited.

The IMDU is further configured to not forward the add_warrant message to the IAP.

Figures 5A and 5B are signalling schemes illustrating examples of target information modification signalling processes between four nodes in a system as given in figure 2. Figure 5A illustrates an example of a target information modification signalling process when the target check does not result in a hit, i.e. match, in its stored sensitive target list.

Figure 5B, on the other hand, illustrates an example of a target information modification signalling process when the target check does result in a hit, i.e. match, in its stored sensitive target list.

A LEA generates a target information modification message and, by means of the LEMF, sends the target information modification message to the IMDU via the HI1 interface. The IMDU is provided with a function for sending a request for target check for each received target information modification message. The TS comprises as described the target function, which is configured to receive a request for target check, perform a target check for each received request for target check, and to send the result of check to the IMDU.

Figure 5A illustrates a scenario where the target check does not result in a hit in its stored sensitive target list. Thus, the target of the request is not a sensitive target. Therefore, the response message sent back to the IMDU comprises the information that the target check resulted in a "no hit".

The IMDU is adapted to receive the response from the trust server node, and to interpret the result information in the response, i.e. hit or

"no_hit".

When the result is "no matching", or "no_hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of target info modification: LI modification for a target. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the information of the target in question will be modified by the LI system.

The IMDU is further configured to forward the target information modification message to the lAP for reception and registration in the lAP. The lAP is then configured to generate and send a confirmation response, target information modification _response, back to the IMDU. The IMDU receives the response and register the received target information modification response. The signalling process is then registered and finalized.

Figure 5B illustrates a scenario where the target check does result in a match in its stored sensitive target list. Thus, the target of the request is a sensitive target. Therefore, the response message sent back to the IMDU comprises the information that the target check resulted in a hit.

As the result was "hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of LI modification: LI modification for a sensitive target.

According to one embodiment, the LEA is adapted to receive the HI notification message and to register the message in a memory storage that the information of the target in question will be modified by the LI system even though the target is sensitive. The modification is not denied because it is not allowed to modify the warrant target but only information related to it, e.g. the expiration date of the warrant.

According to another embodiment, the modification is denied because it is not allowed to modify the warrant target and the modification process is automatically terminated since it is on a sensitive target.

Figures 6A and 6B are signalling schemes illustrating examples of target deactivation signalling processes between four nodes in a system as given in figure 2.

Figure 6A illustrates an example of a target deactivation signalling process when the target check does not result in a hit, i.e. match, in its stored sensitive target list. Figure 6B, on the other hand, illustrates an example of a target deactivation signalling process when the target check does result in a hit, i.e. match, in its stored sensitive target list.

A LEA generates a target deactivation message and, by means of the LEMF, sends the message to the IMDU via the HI1 interface. The IMDU is provided with a function for sending a request for target check for each received target information modification termination message. The TS comprises as described the target function, which is configured to receive a request for target check, perform a target check for each received request for target check, and to send the result of check to the IMDU.

Figure 6A illustrates a scenario where the target check does not result in a hit in its stored sensitive target list. Thus, the target of the request is not a sensitive target. Therefore, the response message sent back to the IMDU comprises the information that the target check resulted in a "no hit".

The IMDU is adapted to receive the response from the trust server node, and to interpret the result information in the response, i.e. hit or "no_hit".

When the result is "no matching", or "no_hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of target deactivation: LI deactivation for a target. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the information of the target in question will be deactivated by the LI system.

The IMDU is further configured to forward the target deactivation message to the IAP for reception and registration in the IAP. The IAP is then configured to generate and send a confirmation response, target deactivation message _response, back to the IMDU. The IMDU receives the response and register the received target deactivation response. The signalling process is then registered and finalized.

Figure 6B illustrates a scenario where the target check does result in a match in its stored sensitive target list. Thus, the target of the request is a sensitive target. Therefore, the response message sent back to the IMDU comprises the information that the target check resulted in a hit.

As the result was "hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of LI deactivation: LI deactivation for a sensitive target. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the information of the target in question will be deactivated by the LI system even though the target is sensitive.

The IMDU is further configured to forward the target deactivation message to the IAP for reception and registration in the IAP. The IAP is then configured to generate and send a confirmation response, target deactivation _response, back to the IMDU. The IMDU receives the response and register the received target deactivation response. The signalling process is then registered and finalized.

As described above, the IMDU is adapted to receive different messages from the LEA and to handle said messages, e.g. add_warrant messages, target information modification messages and target deactivation messages.

The IMDU comprises a processing means such as a programmable processor executing a program of instructions to perform functions of the IMDU functionality by operating on input data and generating output. The IMDU functionality may thus be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by the programmable processor.

For enabling the IMDU to handle add_warrant messages, the IMDU functionality is adapted to, e.g.:

- receive add_warrant messages via the HI1 interface;

- send a request for target check for each received add_warrant message;

- receive the response from the trust server node comprising the result of the target check; - interpret the result information in the response, i.e. hit or "no_hit";

- send over the HI1 interface to the LEA a HI notification message of LI activation: LI activation for a target, if the result was "no_hit";

- send over the HI1 interface to the LEA a HI notification message of LI activation: LI activation for a target denied, if the result was "hit";

- forward the add_warrant messages to the IAP;

- receive the add_warrant responses and, optionally, register the received responses.

The IMDU is also adapted to receive and handle a target information modification message.

For enabling the IMDU to handle target information modification messages, the IMDU functionality is adapted to, e.g.:

- receive target modification messages via the HI1 interface;

- send a request for target check for each received target modification message;

- receive the response from the trust server node comprising the result of the target check;

- interpret the result information in the response, i.e. hit or "no_hit";

- send over the HI1 interface to the LEA a HI notification message of LI modification: LI modification for a target, if the result was "no_hit";

- send over the HI1 interface to the LEA a HI notification message of LI modification: LI modification for a sensitive target, if the result was "hit";

- forward the target information modification messages to the IAP;

- receive the target information modification responses and register the received responses.

The IMDU is also adapted to receive and handle a target deactivation message.

For enabling the IMDU to handle target deactivation messages, the IMDU functionality is adapted to, e.g.:

- receive target deactivation messages via the HI1 interface; - send a request for target check for each received target deactivation message;

- interpret the result information in the response, i.e. hit or "no_hit";

- send over the HI1 interface to the LEA a HI notification message of LI deactivation: LI deactivation for a target, if the result was "no_hit";

- send over the HI1 interface to the LEA a HI notification message of LI deactivation: LI deactivation for a sensitive target, if the result was "hit";

- forward the target deactivation messages to the IAP;

- receive the target deactivation responses and register the received responses.

Figures 7 and 8 are illustrating embodiments of a method, S100, supporting the signalling process as described in the text above and illustrated in figure 3, and a system, e.g. as illustrated in figure 2.

Figure 7 is a flowchart illustrating an embodiment of a method, S100,for target check in a node comprising target check functionality. Said

embodiment comprises the steps of:

S110: - receiving a request for target check. Said request may be received from an Intercept Mediation and Deliver Unit, IMDU, of a LI system, or any other node or entity in the LI system.

S120: - performing target check in one or more target registers. At least one of said one or more target registers is a list comprising targets for which Lawful Intercept is not allowed. The target check is performed by comparing received target information with stored target information in one or more target registers.

S130: - generating a response as a result of the target check. In this step, the result of the target check is interpreted and it is determined if any matching target has been found, i.e. hit or "no_hit", in the one or more target registers S140: - sending a response comprising the result of the target check. A response comprising the result of the target check is sent e.g. to the IMDU from which the corresponding request was sent. The request and/or response is/are received and/or sent over an interface, X4, and according to a protocol between the IMDU and the node.

Figure 8 is a flowchart illustrating further one embodiment of a method for target check in a node comprising target check functionality. The target check may be performed by processing means and computer program software implementing a Target Server, TS, in the node. Said embodiment comprises the steps of:

S110: - receiving a request for target check. Said request is received from e.g. an Intercept Mediation and Deliver Unit, IMDU.

S120: - performing target check in one or more target registers. The target check is performed by comparing received target information with stored target information in one or more target registers.

S130: - generating a response as a result of the target check. In this embodiment, the generating step involves sub-steps S132, S134 and S136, which are explained here below.

S140: - sending a response comprising the result of the target check to the IMDU.

The generating step, S130, of the embodiment involves further the steps of:

S134: - generating a no hit response if the result of the target check is no hit/match in said one or more target registers; and

S136: - generating a hit response if the result of the target check is a hit/match in said one or more target registers.

Whether step S134 or step S136 is performed may be determined by a check step, S132, wherein it is checked if the target checking step S120 has resulted in any hit/match:

S132: - Any register hit? If the result of the target check is no hit/match in said one or more target registers, a "no_ hit" response is generated in step S134. On the other hand, if the result of the target check is a hit/match in said one or more target registers, a hit response is generated in step S136.

Figures 9 and 10 are illustrating embodiments of a method, S200, supporting the signalling process as described in the text above and illustrated in figure 4, and a system e.g. as illustrated in figure 2.

Figure 9 is a flowchart illustrating an embodiment of a method, S200, in a LI system node, preferably a node comprising an Intercept Mediation and Deliver functionality provided by an IMDU. Said method enables requesting a target check in a node comprising target check functionality. Said

embodiment comprises the steps of:

S210: - receiving an add_warrant message for an indicated target. The add_warrant message is sent from the LEA and it is a generic message that has to be translated or adapted for the warrant format of the IAP before it is sent to the IAP. S220: - sending a request for target check to a node comprising a target check functionality. A request message for target check is generated by a dedicated unit, means, or circuitry in the IMDU, addressed and sent to a node comprising a target check functionality, i.e. a node comprising TS.

S230: - receiving a response comprising a result of the target check. The node comprising target check functionality sends a response, e.g. when a result of the target check is ready.

S240: - Deciding whether to generate an add_warrant message or inhibit the generation due to the received result. The node is provided with a dedicated unit, means, or circuitry adapted to analyse the received result, adjust if necessary the received add_warrant message to the warrant format of the IAP, and to decide whether to generate an add_warrant message or inhibit the generation due to the received result.

S250: - forwarding the add_warrant message, if generated. The node is provided with a dedicated unit, means, or circuitry adapted for forwarding the received add_warrant message, if received. Figure 10 is a flowchart illustrating an embodiment of the method, S200: S210: - receiving an add_warrant message for an indicated target;

S220: - sending a request for target check to a node comprising a target check functionality;

S230: - receiving a response comprising a result of the target check;

S250: - forwarding the add_warrant message, if generated.

The deciding step, S240, of the embodiment involves further the steps of:

S244: - generating an add_warrant message if a no_hit response is received;

S246: - inhibiting the generation of an add_warrant message if a hit response is received.

Whether step S244 or step S246 is performed may be decided in a checking step, S242, wherein it is checked by a dedicated unit, means, or circuitry if a HI response is received:

S242: - Hit response received? If the result of the check is that a hit response is received, YES, the generation of an add_warrant message is inhibited in step S246. On the other hand, if a no_hit response is received, the add_warrant message is generated in step S244.

According further one method, as illustrated in fig. 10, the inhibition of the generation of an add_warrant message, S246, further involves: S248: - Generating and sending via HI1 interface and LEMF a message informing LEA that LI activation for a sensitive target has been denied. Figure 1 1 is illustrating embodiments of a method, S400, supporting the signalling process as described in the text above and illustrated in figures 5A and 5B, and in a system, e.g. as illustrated in figure 2.

Figure 1 1 is a flowchart illustrating an embodiment of a method, S400, in a LI system node, preferably a node comprising an Intercept Mediation and Deliver functionality provided by an IMDU. Said method enables said node to receive a request for target information modification and to send a request for target check to a node comprising a target check function. Said embodiment comprises the steps of:

S410:- receiving a request for target information modification. The request for target information modification is sent from the LEA and it is a generic message that has to be translated or adapted for the format accepted by the IAP before it is sent to the IAP.

S420:- sending a request for target check to a node comprising a target check functionality. A request message for target check is generated by a dedicated unit, means, or circuitry in the IMDU, addressed and sent to a node comprising a target check functionality, i.e. a node comprising

TS.

S430:- receiving a response comprising a result of the target check. The node comprising target check functionality sends a response, e.g. when a result of the target check is ready.

S440:- forwarding the request for target information modification to the

Intercept Access Point, IAP. The node is provided with a dedicated unit, means, or circuitry adapted to analyse the received result, adjust if necessary the request for target information modification to the accepted format of the IAP.

According to further one embodiment of the method S400, the method as illustrated in figure 1 1 may further comprise a step:

S450: - If the result of the target check is a hit, sending via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been modified. This scenario is illustrated in the signalling scheme figure 5B. The IMDU is adapted to receive the response from the trust server node, and to interpret the result information in the response.

As the result was a hit, the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of LI modification: LI modification for a sensitive target.

The scenario when the target information modification request concern a target that is not a sensitive target, the trust check function generates a "no hit" response to the IMDU, as illustrated in figure 5A. When the result is "no matching", or "no_hit", the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of target info modification: LI modification for a target. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the information of the target in question will be modified by the LI system. The dedicated unit, means, or circuitry is adapted to handle this step S450 of the method.

For both scenarios, the IMDU is further configured to forward the target information modification message to the IAP for reception and registration in the IAP. The IAP is then configured to generate and send a confirmation response, target information modification response, back to the IMDU. The IMDU receives the response and register the received target information modification response. The signalling process is then registered and finalized.

Figure 12 is a flowchart illustrating embodiments of a method, S600, supporting the signalling process as described in the text above and illustrated in figures 6A and 6B, and in a system, e.g. as illustrated in figure 2.

The embodiment of the method, S600, is performed in a LI system node, preferably a node comprising an Intercept Mediation and Deliver functionality provided by an IMDU. Said method enables said node to receive a request for target deactivation and to send a request for target check to a node comprising a target check function. Said embodiment comprises the steps of:

Said method comprising the steps of:

S610: - receiving a request for target deactivation. The request is received from the LEA node via the LEMF function.

S620: - sending a request for target check to a node comprising a target check functionality.

S630: - receiving a response comprising a result of the target check; S640: - forwarding the request for target deactivation to the Intercept

Access Point, IAP.

The method may further comprise: S650: - If the result of the target check is a hit, sending via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been deactivated. This scenario is illustrated in the signalling scheme figure 6B. The IMDU is adapted to receive the response from the trust check function node, and to interpret the result information in the response, i.e. hit or "no_hit". As the result is a hit, the IMDU is adapted to send over the HI1 interface to the LEA a HI notification message of LI deactivation: LI deactivation for a sensitive target. The LEA is adapted to receive the HI notification message and to register the message in a memory storage that the information of the target in question will be deactivated by the LI system even though the target is sensitive.

The scenario when the target deactivation request concern a target that is not a sensitive target, the trust check function generates a "no hit" response to the IMDU, as illustrated in figure 6A.

Figure 13 is a block diagram of an exemplary Lawful Interception, LI, system 1 10 and network 100, said system and network enabling target check for sensitive targets. Said system and network comprises a number of entities as already described in the background section of this disclosure.

The new functions for enabling the object to enabling target check for sensitive targets are located in the LEA node 230, in a node N210 comprising target check function 400. Said target check function is herein denoted as trust server, and a warrant handling function 500 in the IMDU 210 for enabling the IMDU to communicate with the trust server400, the IAP 220 and LEA 230 via a LEMF function 12. Two new interfaces are provided. One of said interfaces is the interface X4 between the function 216 in the IMDU 210, and one management interface, herein denoted TSMI, between the LEA 230 and the trust server, TS, 400. TSMI is an abbreviation for Trust Server Management Interface.

A LEA 230 generates a warrant and, by means of the LEMF, sends an add_warrant message to the IMDU via the HI1 interface. The IMDU is provided with a function for sending a request for target check for each received add_warrant message. The TS comprises a target function, which is configured to receive a request for target check, perform a target check for each received request for target check, and to send the result of check to the IMDU.

The TS 240 may be implemented by a processing means such as a programmable processor executing a program of instructions to perform functions of the target check functionality by operating on input data and generating output. The target check functionality may thus be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by the programmable processor. Further, the TS comprises a "RED-list" or database of information containing sensitive targets for which lawful intercept is not allowed.

The LEA 230 may also be implemented by a processing means such as a programmable processor executing a program of instructions to perform functions by operating on input data and generating output. The function of the LEA 230 may thus be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by the programmable processor. Further, the LEA may be adapted to handle management operations for the TS 400, such as a "RED-list" or database of information containing sensitive targets for which lawful intercept is not allowed.

The function 500 in the IMDU 210 may also be implemented by a processing means such as a programmable processor executing a computer program of instructions to perform functions by operating on input data and generating output. The functionality of the function 500 may thus be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by the programmable processor.

Further, the function 500 in the IMDU 210 enables the IMDU to communicate with the trust server 400, the IAP 220 and LEA 230 via a LEMF function 12.

The TS 400, the LEA 230 and the function 500 in the IMDU 210 may be implemented in digital electronically circuitry, or in computer hardware, firmware, software, or in combinations of them. The TS 400, the LEA 230 and the function 500 in the IMDU 210 may be implemented in a computer program product tangibly embodied in a machine readable storage device for execution by a programmable processor; and method steps of the method and their embodiments S200, S400, S600, S700 and S800 may be performed by a programmable processor executing a program of instructions to perform functions of the method and their embodiments by operating on input data and generating output.

The TS 400, the LEA 230 and the function 500 in the IMDU 210 may advantageously be implemented in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language.

Generally, a processor will receive instructions and data from a readonly memory and/or a random access memory. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM (erasable programmable read only memory), EEPROM (electrically erasable programmable read only memory), and flash memory devices; magnetic disks such internal hard disks and removable disks; magneto-optical disks; and CD-ROM (Compact Disc Read-Only Memory) disks. Any of the foregoing may be supplemented by, or

incorporated in, specially - designed ASICs (Application Specific Integrated Circuits).

In figure 13, it is understood that the storage units may comprise a different number of storage areas, and the illustrated number of data storage areas only is for illustrative purposes. One or several of the data storage areas may be physically separated from the other data storage areas, or may reside on the same physical media.

The entities and units described above with reference to figure 13 are logical units, and do not necessarily correspond to separate physical units. Thus, the person skilled in the art would appreciate that the units disclosed in the figure 13 may be implemented as physically integrated units, and/or physically separate units, and that the units are provided with appropriate processing circuits.

Given the sensitive information managed by Trust Server400, it should be placed in a node 240 in a secure site, for example in a government building. Trust Server should be unique for country, this means that several Communications Service Provider, e.g. a Network Operator, can access to the single point of warrant reliability.

Figures 14 and 15 are signalling schemes illustrating update message signalling between the LEA 230 and the TS node 240 over the interface TSMI. There are two main update actions in the Trust Server, TS, 400:

• lnsert_Sensitive_Target; and

• Remove_Sensitive_Target.

Figure 14 is a signalling scheme illustrating the updating action when a new sensitive target is inserted in the trust server 400. An

lnsert_Sensitive_Target message is generated by the LEA 230 and sent to the node 240 comprising the trust server 400 over the interface TSMI. The trust server 190 receives the lnsert_Sensitive_Target message, processes said message and inserts the information into the "RED-list" or database of information containing sensitive targets for which lawful intercept is not allowed. When the information has been inserted, the trust server 400 is adapted to generate and send lnsert_Sensitive_Target response back to the LEA 230 for confirming the registration of the new sensitive target.

The message comprises information, which could be organized into different parameters. Table 2 is a table listing examples of mandatory, optional or conditional parameters that could be included in a message for inserting sensitive targets.

Table 2: Parameters in the lnsert_Sensitive_Target message. MOC columns describe the type of parameters: Mandatory, Optional or Conditional.

Figure 15 is a signalling scheme illustrating the updating action when a sensitive target is removed in the trust server 400. A Remove_Sensitive _Target message is generated by the LEA 230 and sent to the node 240 comprising the trust server 400 over the interface TSMI. The trust server 400 receives the Remove_Sensitive_Target message, processes said message for locating the target to be removed and removes the target and the corresponding information from the "RED-list" or database of information containing sensitive targets for which lawful intercept is not allowed. When the information has been removed, the trust server 400 is adapted to generate and send Remove_Sensitive_Target response back to the LEA 230 for confirming the removal of the new sensitive target.

The message comprises information, which could be organized into different parameters as mentioned in Table 2. Table 3 is a table listing examples of mandatory, optional or conditional parameters that could be included in a message for removing sensitive targets.

Table 3: Parameters in the Remove_Sensitive_Target message. MOC columns describe the type of parameters: Mandatory, Optional or

Conditional.

Figure 16 is a flowchart illustrating an embodiment of a method, S700, in a LEA node. The method is performed in a node of a Law Enforcement Agency, LEA, 230 for administrating and handling a node 240 comprising target check function. The method comprises the steps of: S710: - sending an updating message over a management interface to the node comprising target check functionality;

S720: - receiving a response message over the management interface from the node comprising target check functionality.

As illustrated in the signalling scheme of figure 14, the updating message may be a message for inserting a sensitive target into the target check functionality, the message comprising information regarding, e.g. parameters in table 2, such as the target's identity, type and value.

As illustrated in the signalling scheme of figure 15, the updating message may be a message for removing a sensitive target from the target check functionality, the message comprising information regarding, e.g. parameters in table 3, such as the target's identity, type and value.

Figure 17 is a flowchart illustrating an embodiment of a method, S800, in a node comprising target check functionality. Said method comprises the steps of:

S810: - receiving an updating message over a management interface from a Law Enforcement Agency, LEA, 230;

S820: - processing information regarding a sensitive target's identity, type and value;

S830: - sending a response message over the management interface to the node comprising LEA, 230.

Figure 18 is a flowchart illustrating further one embodiment of the method, S800. In this embodiment, the updating message is a message for inserting a sensitive target into the target check functionality comprising information regarding the target's identity, type and value, and the processing step S820 involves:

S822: - Inserting sensitive target's identity, type and value into a memory storage.

The trust server 400 receives the lnsert_Sensitive_Target message, processes said message and inserts, S822, the information into the "RED- list" or database of information containing sensitive targets for which lawful intercept is not allowed. When the information has been inserted, the trust server 400 is adapted to generate and send lnsert_Sensitive_Target response back to the LEA 230 for confirming the registration of the new sensitive target.

Figure 19 is a flowchart illustrating further one embodiment of the method, S800. In this embodiment, the updating message is a message for removing a sensitive target from the target check functionality comprising information regarding the target's identity, type and value, and the processing step S820 involves:

S824: - Removing sensitive target's identity, type and value from a memory storage.

Thus, a Remove_Sensitive_Target message is generated by the LEA 230 and sent to the node 240 comprising the trust server 400 over the interface TSMI. The trust server 400 receives the Remove_Sensitive_Target message, processes said message for locating the target to be removed and removes the target and the corresponding information from the "RED-list" or database of information containing sensitive targets for which lawful intercept is not allowed. When the information has been removed, the trust server 400 is adapted to generate and send Remove_Sensitive_Target response back to the LEA 230 for confirming the removal of the new sensitive target.

Figure 20 is a block diagram illustrating one example of a node 240, preferably a node 240, as described and illustrated in figures 3, 7 and 8, comprising a target check functionality 400 implemented as a TS for supporting one or more Lawful Intercept, LI, systems. Said node 240 comprises an interface unit 408 adapted to receive a request for target check and to send a response comprising the result of the target check, and processing means 402 adapted to perform a target check in one or more target registers 405, and to generate a response as a result of the target check.

The processing means 402 comprises a processor 404 and a memory storage 406. The processing means 402 are adapted to generate a no hit response if the result of the comparison is "no hit", i.e. no matching target post is found in said one or more target registers 405. The processing means 402 are further adapted to generate a hit response if the result of the comparison is a hit, i.e. a matching target is found in said one or more target registers.

According to one embodiment of the node 240, at least one of said one or more target registers are one or more lists or databases comprising targets for which Lawful Intercept is not allowed. The interface unit 408 of the node 240 is configured to receive requests and/or send responses over an interface, X4, in accordance to a predetermined protocol. Said requests and responses are sent between an Intercept Mediation and Delivery Unit, IMDU, 500 of said one or more LI systems and the node 240.

Further, an updating process is provided for the node 240 comprising the target check functionality 400. The node 240 is adapted by means of its interface unit 408 to receive (S810) an updating message over a

management interface TSMI from a Law Enforcement Agency, LEA, 230 and to send (S830) a response message over the management interface to the node comprising LEA 230. The processing means 402 of the node may be adapted to process (S820) information regarding a sensitive target's identity, type and value. The updating message may be a message for inserting a sensitive target into the target check functionality comprising information regarding the target's identity, type and value. The processing means 402 may therefore be adapted to insert (S822) sensitive target's identity, type and value into a memory storage 405.

The updating message may further be a message for removing a sensitive target the target check functionality comprising information regarding the target's identity, type and value. The processing means may therefore be adapted to remove (S824) sensitive target's identity, type and value from the memory storage 405.

Figure 21 is a block diagram illustrating an embodiment of the node

N210 comprising an Intercept Mediation and Deliver functionality, IMDU, 210 of a LI system. The node N210 comprises a unit 210 which implements the IMDU functionality. The IMDU comprises an ADMF 214. The function of the ADMF is described in the background section above. According to the illustrated embodiment, a warrant handling unit 500 is provided within the ADMF 501 and IMDU 210.

The IMDU further comprises an interface unit 508. The warrant handling unit 500 is connected to said interface unit 508, which unit enables

communication over different interfaces, e.g. X4, X1_1 and HI1 .

According to the illustrated example, the warrant handling unit 500 is implemented by a processing means 504 connected to a memory storage 507. The processing means 504 is implemented by a processor 505 and a memory storage 506.

The processing means 504 of the warrant handling unit 500 is adapted to receive (S210) an add warrant message for an indicated target, to generate and to send (S220), via the interface unit 508, a request for target check to a node comprising a target check functionality, to receive (S230) a response comprising a result of the target check, to decide (S240) whether to generate add_warrant message or inhibit said message due to the received result, and to forward (S250) the add_warrant message if generated.

The processing means 504 of the warrant handling unit 500 is adapted to generate (S244) the add_warrant message if a no hit response is received, and to inhibiting (S246) the generation of the add_warrant message if a hit response is received.

The processing means 504 of the warrant handling unit 500 is adapted to generate and send (S248) via HI1 interface and LEMF a message informing LEA that LI activation for a sensitive target has been denied.

The processing means 504 of the warrant handling unit 500 is adapted to support a method, as described in figures 5A, 5B and 1 1 (S400), for handling modification of target information in a LI system node N210 comprising an Intercept Mediation and Deliver functionality, IMDU. The processing means 504 of the warrant handling unit 500 is adapted to receive (S410) a request for target information modification, probably from a LEA 230. Said means 500 is further adapted to generate and send (S420) a request for target check to a node 240 comprising a target check

functionality, to receive (S430) a response comprising a result of the target check, and to forward (S440) the request for target information modification to the Intercept Access Point, IAP. The request for target information modification is sent regardless whether the result of the target check is a hit, or not. However, the processing means 504 of the warrant handling unit 500 is adapted to send (S450) via the HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been modified, only if the result of the target check is a hit, i.e. a match.

The processing means 504 of the warrant handling unit 500 is adapted to support a method, as described in figures 6A, 6B and 12 (S600) for target deactivation performed in a LI system node 240 comprising IMDU

functionality. The processing means 504 of the warrant handling unit 500 is adapted to receive (S610) a request for target deactivation, to generate and send (S620) a request for target check to a node comprising a target check functionality, to receive (S630) a response comprising a result of the target check, and to forward (S640) the request for target deactivation to the Intercept Access Point, IAP. The request for target deactivation is sent regardless whether the result of the target check is a hit, or not. However, the processing means 504 of the warrant handling unit 500 is adapted to send (S650) via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been deactivated, only if the result of the target check is a hit.

Figure 22 is a block diagram illustrating an embodiment of a node 230 of the Law Enforcement Agency, LEA.

Said node comprises a management unit 700, which is implemented by a processing means 704 connected to a memory storage 707.

The processing means 704 is implemented by a processor 705 and a memory storage 706. Said processing means is adapted to support a method, as described in connection to and illustrated in figures 14, 15 and 16, for administrating and handling a node comprising target check function- ality. Thus, the processing means is adapted to send (S710) an updating message over a management interface to the node comprising target check functionality, and to receive (S720) a response message over the

management interface from the node comprising target check functionality. The updating message may be a message for inserting a sensitive target into the target check functionality comprising information regarding the target's identity, type and value, or a message for removing a sensitive target the target check functionality comprising information regarding the target's identity, type and value.

The response message may be a message informing LEA that LI for a sensitive target has been deactivated, or that LI for a sensitive target has been modified.

The LEA further comprises an interface unit 708. The processing means 704 is connected to said interface unit 708, which unit enables communication over different interfaces, e.g. X4 and TSMI.

According to one embodiment, a computer program comprising computer program code for a processor means 402 of a node 240

comprising a target check functionality for supporting one or more Lawful Intercept, LI, systems is provided. When said computer program comprising computer program code is run in the processor means 402, it causes the node to perform the method steps of the method S100:

- receiving (S1 10) a request for target check;

- performing (S120) target check in one or more target registers;

- generating (S130) a response as a result of the target check;

- sending (S140) a response comprising the result of the target check.

The computer program may further comprise computer program code which, when run in the processing means of the node, causes the node to perform the method steps of different embodiments of the method S100.

A computer program product comprising the computer program and a computer readable means on which the computer program is stored are also provided. A carrier containing the computer program is also provided. The carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

Further one computer program is provided. The computer program comprises computer program code which, when run in a processor means 504 of a node N210 comprising an Intercept Mediation and Deliver functionality (IMDU), causes the node to perform the method steps of the method S200:

- receiving (S210) an add_warrant message for an indicated target; - sending (S220) a request for target check to a node comprising a target check functionality:

- receiving (S230) a response comprising a result of the target check;

- deciding (S240) whether to generate an add_warrant_massage or inhibiting the generation of said message due to the received result - forwarding (S250) the add_warrant message, if generated.

The computer program may further comprise computer program code which, when run in the processing means of the node, causes the node to perform the method steps of different embodiments of the method S200.

A computer program product comprising the computer program and a computer readable means on which the computer program is stored are also provided.

A carrier containing the computer program is also provided. The carrier is one of an electronic signal, optical signal, radio signal or computer readable storage medium.

Further one computer program is provided. The computer program comprises computer program code which, when run in a processor means 504 of a node N210 comprising an Intercept Mediation and Deliver functionality (IMDU), causes the node to perform the method steps of the method S400:

- receiving (S410) a request for target information modification;

- sending (S420) a request for target check to a node comprising a target check functionality: - receiving (S430) a response comprising a result of the target check;

- forwarding (S440) the request for target information modification to the Intercept Access Point, IAP.

The computer program may further comprise computer program code which, when run in the processing means of the node, causes the node to perform the method steps of different embodiments of the method S400.

Further one computer program is provided. The computer program comprises computer program code which, when run in a processor means 504 of a node N210 comprising an Intercept Mediation and Deliver functionality (IMDU), causes the node to perform the method steps of the method S600:

- receiving (S610) a request for target deactivation;

- sending (S620) a request for target check to a node comprising a target check functionality:

- receiving (S630) a response comprising a result of the target check;

- forwarding (S640) the request for target deactivation to the Intercept Access Point, IAP. Further, the computer program may involve a step:

- If (S650) the result of the target check is a hit, sending via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been deactivated.

The computer program may further comprise computer program code which, when run in the processing means of the node, causes the node to perform the method steps of different embodiments of the method S600.

Further one computer program is provided. The computer program comprises computer program code which, when run in a processor means 704 of a node 230 comprising an Intercept Mediation and Deliver functionality (IMDU), causes the node to perform the method steps of the method S700:

- sending (S710) an updating message over a management interface to the node comprising target check functionality;

- receiving (S720) a response message over the management interface from the node comprising target check functionality.

The computer program may further comprise computer program code which, when run in the processing means of the node, causes the node to perform the method steps of different embodiments of the method S700.

Further one computer program is provided. The computer program comprises computer program code which, when run in a processor means 402 of a node 240 comprising an Intercept Mediation and Deliver functionality (IMDU), causes the node to perform the method steps of the method S800:

- receiving (S810) an updating message over a management interface from a Law Enforcement Agency, LEA, 230;

- processing (S820) information regarding a sensitive target's identity, type and value;

- sending (S830) a response message over the management interface to the node comprising LEA, 230. The computer program may further comprise computer program code which, when run in the processing means of the node, causes the node to perform the method steps of different embodiments of the method S800.

A number of embodiments of the present technology have been described. It will be understood that various modifications may be made without departing from the scope of the described technology. Therefore, other implementations are within the scope of the following claims.

List of Abbreviations

Abbreviation Explanation

CSP Communications Service Provider

LEA Law Enforcement Agency

CC Call Content

MSIDN Is a number uniquely identifying a subscription in a GSM or a

UMTS mobile network

IMEI International Mobile Station Equipment

Identity is a unique number to identify 3GPP mobile phones

URI Uniform resource identifier. Used to identify a

mobile subscriber in Voice over LTE contex

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Packet Service

3GPP Third Generation Partnership Project

LTE Long Term Evolution HI Handover Interface

HLR Home Location Register

HSS Home Subscriber Server

LI Lawful Intercept(-ion)

RAN Radio Access Network

IMDU Intercept Mediation and Delivery Unit

DF Delivery Function

MF Mediation Function

LEMF Law Enforcement Monitoring Facility

ADMF Administration Function

EPC Evolved Packet Core

IP Internet Protocol

eNB base (transceiver) station in LTE systems

RNC Radio Network Controller

IAP Intercept Access Point

ICE Intercept Control Element

EPS Evolved Packet System

References

[1 ] 3GPP TS 33.106 "Lawful Interception requirements (Release 12)";

[2] 3GPP TS 33.107 "Lawful interception architecture and functions

(Release 12)";

[3] 3GPP TS 33.108 "Handover interface for Lawful Interception" (Release

12).

[4] ETSI ES 201 671

Claims

1 . Method in a node (240) comprising a target check functionality for

supporting one or more Lawful Intercept, LI, systems, said method comprising the steps of:

- receiving (S1 10) a request for target check;

- performing (S120) target check in one or more target registers;

- generating (S130) a response as a result of the target check;

- sending (S140) a response comprising the result of the target check.

The method according to claim 1 , wherein the comparing step involves: - generating (S134) a no hit response if the result of the comparison is no hit in said one or more target registers.

The method according to claim 1 , wherein the comparing step involves: - generating (S136) a hit response if the result of the comparison is a hit in said one or more target registers.

The method according to any of claims 1 - 3, wherein at least one of said one or more target registers are one or more lists comprising targets for which Lawful Intercept is not allowed.

The method according to any of claims 1 - 4, wherein the request and/or response is/are received and/or sent over an interface, X4, and according to a protocol between the IMDU of said one or more LI systems and the node.

Method in a LI system node (N210) comprising an Intercept Mediation and Deliver functionality, said method comprising the steps of:

- receiving (S210) an add_warrant message for an indicated target;

- sending (S220) a request for target check to a node comprising a target check functionality:

- receiving (S230) a response comprising a result of the target check; - deciding (S240) whether to generate an add_warrant_massage or inhibit the generation of said message due to the received result;

- forwarding (S250) the add_warrant message, if generated..

The method according to claim 6, wherein the deciding step involves: - generating (S244) the add_warrant message if a no hit response is received.

The method according to claim 6, wherein the deciding step involves: - inhibiting (S246) the generation of the add_warrant message if a hit response is received.

The method according to claim 8, wherein the inhibiting of said message involves:

- Generating and sending (S248) via HI1 interface and LEMF a message informing LEA that LI activation for a sensitive target has been denied.

10. Method in a LI system node comprising an Intercept Mediation and Deliver functionality, said method comprising the steps of:

- receiving (S410) a request for target information modification;

- sending (S420) a request for target check to a node comprising a target check functionality:

- receiving (S430) a response comprising a result of the target check; - forwarding (S440) the request for target information modification to the

Intercept Access Point, IAP.

The method according to claim 10, further comprising:

- If (S450) the result of the target check is hit, sending via H I1 interface and LEMF a message informing LEA that LI for a sensitive target has been modified. Method in a LI system node comprising an Intercept Mediation and Deliver functionality, said method comprising the steps of:

- receiving (S610) a request for target deactivation;

- receiving (S630) a response comprising a result of the target check;

- forwarding (S640) the request for target deactivation to the Intercept Access Point, IAP.

The method according to claim 12, further comprising:

- If (S650) the result of the target check is a hit, sending via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been deactivated. 14. Method in a node of a Law Enforcement Agency, LEA, (230) for

administrating and handling a node comprising target check

functionality, said method comprising the steps of:

The method according to claim 14, wherein the updating message is a message for inserting a sensitive target into the target check

functionality comprising information regarding the target's identity, type and value.

16. The method according to claim 14, wherein the updating message is a message for removing a sensitive target the target check functionality comprising information regarding the target's identity, type and value. Method in a node comprising target check functionality, said method comprising the steps of:

- receiving (S810) an updating message over a management interface from a Law Enforcement Agency, LEA, (230);

- sending (S830) a response message over the management interface to the node comprising LEA, (230). 18. The method according to claim 17, wherein the updating message is a message for inserting a sensitive target into the target check functionality comprising information regarding the target's identity, type and value, and the processing step involves:

- Inserting (S822) sensitive target's identity, type and value into a memory storage.

The method according to claim 17, wherein the updating message is a message for removing a sensitive target the target check functionality comprising information regarding the target's identity, type and value, and the processing step involves:

- Removing (S824) sensitive target's identity, type and value from a memory storage.

20. A node (240) comprising a target check functionality for supporting one or more Lawful Intercept, LI, systems, said node comprising an interface unit (408) adapted to receive a request for target check and to send a response comprising the result of the target check, and processing means (402) adapted to perform a target check in one or more target registers (405), and to generate a response as a result of the target check. The node according to claim 20, wherein the processing means are adapted to generate a no hit response if the result of the comparison no hit in said one or more target registers.

The node according to claim 20, wherein the processing means are adapted to generate a hit response if the result of the comparison is hit in said one or more target registers.

The node according to any of claims 20 - 22, wherein at least one of said one or more target registers are one or more lists comprising targets for which Lawful Intercept is not allowed.

The node according to any of claims 20 - 23, wherein the request and/or response is/are received and/or sent over an interface, X4, and according to a protocol between an IMDU of said one or more LI systems and the node.

25. A node (N210) comprising an Intercept Mediation and Deliver

functionality (IMDU), said node comprising an interface unit (508) and a processing means (504), which is adapted to receive (S210) an add warrant message for an indicated target, to generate and to send (S220), via the interface unit (508), a request for target check to a node comprising a target check functionality, to receive (S230) a response comprising a result of the target check, to decide (S240) whether to generate an add_warrant message or inhibit said message due to the received result, and to forward (S250) the add_warrant message if generated.

The node (N210) according to claim 25, wherein the processing means (504) are adapted to generate (S244) the add_warrant message if a no hit response is received, and to inhibit (S246) the generation of the add_warrant message if a hit response is received. The node (N210) according to claim 25, wherein the processing means (504) is adapted to generate and send (S248) via HI1 interface and LEMF a message informing LEA that LI activation for a sensitive target has been denied.

A node (N210) comprising an Intercept Mediation and Deliver functionality (IMDU), said node comprising an interface unit (508) and a processing means (504), which is adapted to receive (S410) a request for target information modification, to send (S420) a request for target check to a node comprising a target check functionality, to receive (S430) a response comprising a result of the target check, and to forward (S440) the request for target information modification to the Intercept Access Point, IAP.

The node (N210) according to claim 28, wherein the processing means (504) are adapted to, if (S450) the result of the target check is a hit, sending via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been modified.

A node (N210) comprising an Intercept Mediation and Deliver functionality (IMDU), said node comprising an interface unit (508) and a processing means (504), which is adapted to receive (S610) a request for target deactivation, to send (S620) a request for target check to a node comprising a target check functionality, to receive (S630) a response comprising a result of the target check, and to forward (S640) the request for target deactivation to the Intercept Access Point, IAP.

The node (N210) according to claim 30, wherein the processing means (504) are adapted to, if (S450) the result of the target check is a hit, sending via HI1 interface and LEMF a message informing LEA that LI for a sensitive target has been modified. A node (230) of a Law Enforcement Agency, LEA, said node comprising an interface unit (708) and a processing means (704), which is adapted to send (S710) an updating message over a management interface to the node comprising target check functionality, and to receive (S720) a response message over the management interface from the node comprising target check functionality.

The node (230) according to claim 32, wherein the updating message is a message for inserting a sensitive target into the target check functionality comprising information regarding the target's identity, type and value.

The node (230) according to claim 32, wherein the updating message is a message for removing a sensitive target the target check functionality comprising information regarding the target's identity, type and value.

35. A node (240) comprising a target check functionality for supporting one or more Lawful Intercept, LI, systems, said node comprising an interface unit (408) adapted to receive (S810) an updating message over a management interface from a Law Enforcement Agency, LEA, (230), and processing means (402) adapted to process (S820) information regarding a sensitive target's identity, type and value, and to send (S830) a response message, via the interface unit (408), over the management interface to the node comprising LEA, (230).

The node (240) according to claim 35, wherein the updating message is a message for inserting a sensitive target into the target check functionality comprising information regarding the target's identity, type and value, and the processing means (402) is adapted to insert (S822) sensitive target's identity, type and value into a memory storage. The node (240) according to claim 35, wherein the updating message is a message for removing a sensitive target the target check functionality comprising information regarding the target's identity, type and value, and the processing means (402) is adapted to remove (S824) sensitive target's identity, type and value from a memory storage.