Method and Devices for Lawful Interception

Abstract

Methods and devices provide service-specific information besides LI data extracted from communications of LI targets, which receive services via the network and interact with a core function of the network. LI data includes at least one of IRI and CC. This approach is particularly useful if LI at application/service level is unavailable.

Claims

1.-23. (canceled)

24. A method for lawful interception, LI, performed by a device of a communication service provider, CSP, the device having access to a communication of an LI target interacting with at least one core function of a network, the method comprising: extracting LI data from the communication; determining whether there is an association between the LI data and a IP Multimedia subsystem, IMS-based service provided to the LI target via the network; if determined that the association exists, forwarding (S430) one or more service-LI messages, which include service-specific information besides the LI data, to a law enforcement agency, LEA, wherein the LI data includes at least one of Intercept Related Information, IRI, and Content of Communication, CC; and if the communication contains user-related signaling, forwarding a service-IRI, which is one of the service-LI messages, to the LEA, the service-IRI including the service-specific information besides the IRI extracted from the communication.

25. The method of claim 24, wherein the determining is performed by a service function, SF, using a collection of service descriptions.

26. The method of claim 25, wherein a service description in the collection of service descriptions includes a service-identification rule, a service feature and a service policy.

27. The method of claim 26, wherein the service-specific information is generated according to the service policy.

28. The method of claim 24, wherein the service-IRI includes a communication session identifier, an origin-message type, a service identifier, a user-related-signaling type, the IRI extracted from the communication and a correlation identifier usable to correlate the IRI with other LI data.

29. The method of claim 24, wherein the service-IRI is delivered via an LI handover interface for IRI reporting, HI2.

30. The method of claim 24, wherein the method further includes if the communication contains user-related content, forwarding a service-CC, which is also one of the service-LI messages, to the LEA, the service-CC including the service-specific information besides the CC extracted from the communication.

31. The method of claim 30, wherein the service-CC includes a communication session identifier, an origin-message type, a service identifier, a user-related-content type, the CC and a correlation identifier usable to correlate the CC with other LI data.

32. The method of claim 30, wherein the service-CC is delivered via an LI handover interface for CC reporting, HI3.

33. A communications service provider, CSP, device for lawful interception, LI, the CSP device comprising: a communication interface configured to communicate via a network; and a data processing unit connected to the communication interface and configured: to extract LI data from a communication of an LI target interacting with at least one core function of the network, to determine whether there is an association between the LI data and a IP Multimedia subsystem, IMS-based service provided to the LI target via the network; if determined that the association exists, to generate one or more service-LI messages, which include service-specific information besides the LI data, to be forwarded to a law enforcement agency, LEA, via the communication interface, wherein the LI data includes at least one of Intercept Related Information, IRI, and Content of Communication, CC; and wherein if the communication contains user-related signaling, the data processing unit generates a service-IRI, which is one of the service-LI messages, the service-IRI including the service-specific information besides the IRI extracted from the communication.

34. The CSP device of claim 33, wherein the data processing unit executes a service function, SF, for determining whether the association exists, the SF using a collection of service descriptions.

35. The CSP device of claim 34, wherein a service description included in the collection of service descriptions includes a service-identification rule, a service feature and a service policy.

36. The CSP device of claim 35, wherein the data processing unit generates the service-specific information according to the service policy.

37. The CSP device of claim 33, wherein the service-IRI includes a communication session identifier, an origin-message type, a service identifier, a user-related-signaling type, the IRI extracted from the one of the communications and a correlation identifier usable to correlate the IRI with other LI data.

38. The CSP device of claim 33, wherein the communication interface forwards the service-IRI through an LI handover interface for IRI reporting, HI2.

39. The CSP device of claim 33, if the communication contains user-related content, the data processing unit generates a service-CC, which is also one of the service-LI messages, to be forwarded to the LEA via the communication interface, wherein the service-CC includes the service-specific information besides the CC extracted from the communication.

40. The CSP device of claim 39, wherein the service-CC includes a communication session identifier, an origin-message type, a service identifier, a user-related-content type, the CC and a correlation identifier usable to correlate the CC with other LI data.

41. The CSP device of claim 39, wherein the communication interface forwards the service-CC through an LI handover interface for CC reporting, HI3.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0048] The accompanying drawings, which are incorporated in and constitute a part of the specification, illustrate one or more embodiments and, together with the description, explain these embodiments. In the drawings:

[0049] FIG. 1 illustrates a logical representation of the functional entities achieving LI;

[0050] FIG. 2 illustrates different levels at which a CSP can capture LI data;

[0051] FIG. 3 exemplifies communications intercepted at each level;

[0052] FIG. 4 is a flowchart of a method according to an embodiment;

[0053] FIG. 5 illustrates a service analysis according to an embodiment;

[0054] FIG. 6 is an exemplary illustration of a SID for an RCS service as specific OTT application according to an embodiment;

[0055] FIG. 7 is a functional illustration of SF within the LI functional blocks according to an embodiment;

[0056] FIG. 8 describes interfaces between a service function and other LI functional entities upon intercepting a SIP message, according to an embodiment;

[0057] FIG. 9 describes interfaces between a service function and other LI functional entities upon intercepting a CC message according to an embodiment;

[0058] FIG. 10 is a block diagram of a CSP device according to another embodiment; and

[0059] FIG. 11 is a block diagram of another CSP device according to yet another embodiment.

DETAILED DESCRIPTION

[0060] The following description of the embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims.

[0061] Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with an embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification is not necessarily referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0062] The issues related to LI at network level (i.e., when CSP is not able to provide LI at application level) are solved by performing a service-aware LI. That is, the CSP device extracts LI data from captured communications of an LI target interacting with core functions of a network (i.e., at network level). The LI data includes at least one of intercept related information and communication content. If determined that there is an association between the LI data and a service provided to the LI target via the network, service-LI messages, which include service-specific information besides the LI data, are forwarded to the respective LEA. A core function is here defined as a function in a core network of a network, such as a wireless communications network in the form of an IMS core network. An IMS device/node in an IMS core network may of course as such include more than one core function. Examples of a core functions in the IMS core network are P-CSCF (Proxy-Call Session Control Function), S-CSCF (Serving-CSCF), I-CSCF (Interrogating-CSCF), Home Subscriber Server (HSS) and Subscription Locator Function (SLF). For example, a SIP registration as an IMS level registration involves a SIP REGISTER request where a user binds his/her public identity in the form of a public URI to a URI that contains the host name or IP address of an associated UE/LI target. The registration at the IMS level involves the core functions P-CSCF, I-CSCF, HSS and S-CSCF.

[0063] FIG. 4 is a flowchart of a method (400) for service-aware LI according to an embodiment. The method is performed by a device of a CSP having access to a communication of an LI target interacting with one or more core functions of the network. Such communications are captured for LI. LEAs may want to intercept a specific person's communications. From an LI perspective, a person may own one or more devices (identified for example by an IMEI), a SIM/ISIM/USIM (identified by an MSISDN) and included in a UICC/eUICC/iUICC, or a user identity (e.g., an URI). The term “LI target” is to be interpreted in the broadest manner as covering any physical entity associated with a person and could be any type of device such as a mobile phone, vehicle, tablet, laptop and a smart watch/wearable.

[0064] Method 400 includes extracting LI data from the communication at S410 and determining whether there is an association between the LI data and a service provided to the LI target via the network at S420. The LI data includes IRI and/or CC. The method further includes forwarding one or more service-LI messages, which include service-specific information besides the LI data, to a LEA at S430.

[0065] As articulated in the “Background” section, the LI problems that arise in the conventional approach to forwarding LI data captured at network level and associated with a service are: [0066] a. lack of visibility of service-specific events (e.g., because such event is embedded in the SIP signaling); [0067] b. loss of IRI service-specific events when CC interception not required or allowed and IRI are embedded in CC (e.g., in countries where only IRI can be lawfully intercepted); [0068] c. correlation problems due to the challenge of linking IRI and CC; [0069] d. delay in processing on the LEA side when absence of clear distinction between IRI and CC requires time-consuming post-processing on the LEA side.

[0070] The embodiments described in this section provide advantages for CSPs and LEAs, and more generally to all actors in the network community by providing service-aware LI, eliminating the need to deal with the above-identified problems in the standardization phase, making it easier also for application developers to test and troubleshoot their applications under development (e.g., via a more reliable statistics). This approach reduces the cost for monitoring LI targets by simplifying post-processing of LI data. For example, in case of RCS services provided as a specific OTT application, a LEA receiving LI data from a CSP using the above method has the IRI events specific for the RCS application highlighted, always delivered via HI2 (not both HI2 and HI3), and always available even if CC interception is not allowed. Therefore, the LEA more easily correlates IRI events specific to the OTT application and pertaining to the same communication regardless of whether they are delivered in SIP or MSRP messages. Furthermore, the embodiments enable an easy correlation between IRI and CC of the same communication, even when delivered inside standalone SIP messages (e.g., in the case of pager mode).

[0071] FIG. 5 illustrates a service analysis performed for an IRI (SIP message) or a CC packet within the service-aware LI at a network level (within the meaning of the description related to FIG. 2). These operations may be performed by a mediation module (e.g., including mediation/delivery functions 124 and 126 in FIG. 1, these functions being upgraded to enable service-awareness) of the CSP. The operations include (e.g., by a CSP device containing a mediation function): receiving LI data (i.e., the SIP message or the call content) at 510, identifying an IMS-based service associated with the LI data at 520, extracting user-related signaling and media of services according to service policies (i.e., a policy decision) at 530, and delivering LI data and the additional information at 540.

[0072] It is in service identification 520 determined whether an IMS service is associated with the LI data and which is the IMS-based service. According to one embodiment, this functionality is achieved with a service function (SF) and a data structure storing service-related information. A service is uniquely identified based on service-related information stored in a service identity structure (SID). The service-related information includes service-identification-rules, service-characteristics and service-policies. FIG. 6 exemplarily illustrates a SID for an RCS service as a specific OTT application.

[0073] FIG. 7 is a functional illustration of SF 725 within LI functions according to an embodiment. SF 725 communicates with IRI mediation function (MF2) 724 (which is a service-aware version of function 124), with CC mediation function (MF3) 726 (which is a service-aware version of function 126), and service collector SC 710. SC 710 stores service structures, i.e. a collection of service descriptions, similar with the one in FIG. 6. The service structures may be input to the service collector manually or be downloaded from predetermined documents. MF2 724 and MF3 726 forward LI data including service-related information to LEA 730.

[0074] FIGS. 8 and 9 describe interactions between an SF (such as 725 in FIG. 7) and other LI functions (e.g., MF2 and MF3). SF interacts with MF2 and MF3 to provide them the list of known services to be identified and with SC to check the presence of a service (identification process).

[0075] FIG. 8 illustrates service identification when a SIP message is intercepted at 810. MF2 extracts service characteristics (ListInMsg) from the SIP message and builds a communication session identifier (CSID) at 820. Here, CSID is a generic communication session identifier used for correlation purposes, which may also be used to correlate the user-related-signaling to the original message, X2 or X3. A definition of CSID called the Communication Identity Number (CIN) is found in ETSI TS 101 671 V3.15.1: “Lawful Interception (LI); Handover interface for the lawful interception of telecommunications traffic”). The assignment of CIN in IMS domain is described in ETSI TS 102 232-5. CIN identifies uniquely an intercepted communication session within the relevant network element. All the results of interception within a single communications session must have the same CIN.

[0076] At 830, the SF compares the extracted service characteristics (ListInMsg) with the ones in SI Ds stored in the SC. If there is no match (i.e., the received information is not associated with an IMS service), the received information is delivered at 880 (see branch NO of decision block 840).

[0077] On the other hand, if the extracted service characteristics (ListInMsg) match one of the SIDs stored in the SC (see branch YES of decision block 840), then SF returns “service-policies” of the matched SID to MF2 at 850 and stores the associated CSID-service in a memory cache at 860. Steps 870 (Policy Decision) and 880 (Format/Delivery) are going to be discussed in more detail below.

[0078] FIG. 9 illustrates service identification when a CC packet is received at 910. At 920, MF3 retrieves media protocol (i.e., one of the media protocols depending on the service, e.g., RTP) from the received CC. Then, at 930, MF3 builds a CSID used, at 940, to ask SF to verify if there is an associated service (already stored if another packet was previously received). If there is no match, the received information is delivered at 970 (see branch NO of decision block 950) without service-related information, otherwise the CC packet is forwarded to steps 960 (Policy Decision) and 970 (Format/Delivery) that, similar to 870 and 880, are going to be discussed below.

[0079] At steps 870 and 960, MF2 and MF3 respectively retrieve the service policies. These policies may indicate whether it is necessary to provide a service-related correlation (such as IMDN to IM correlation in case of RCS messaging). Depending on the service, such information is built and then the IRI/CC type of information is subjected to formatting/delivery steps 880 and 970, respectively.

[0080] When an association of LI data with an IMS service has been identified, the user-related-signaling and/or user-related-content (IRI/CC) messages are formatted by a serviceIri delivered over HI2 to LEA and a servicePayload delivered via HI3, respectively. The serviceIri message encapsulates service-related information besides the IRI type of information from SIP. In one embodiment, serviceIri includes: [0081] CSID, i.e., the communication session identifier used to correlate the user-related-signaling to the original message, X2 or X3 (here, X2 and X3 are the interfaces between the network element and the mediation function to provide IRI and CC, respectively as labeled on the arrows between 120 and 124/126 in FIG. 1); [0082] originMessageType (e.g., X2 or X3 which indicate where the user-related signaling was found); [0083] serviceID (i.e., a service identified such as RCS IM); [0084] userRelatedSignalingType (type of user-related signaling specific of a service, such as, IMDN content); [0085] userRelatedSignaling—user related signaling specific of a service (e.g. the IMDN content); and [0086] correlationID (i.e., a parameter used to correlate user-specific signaling and content).

[0087] The servicePayload message encapsulates user-related content extracted from X2 or X3 messages and delivered over HI3. Additionally, servicePayload includes service-specific info, user-related correlation, session-related correlation (i.e. CSID) to correlate the message with the message intercepted at a network level and the message itself. In one embodiment, servicePayload includes: [0088] CSID (i.e., the communication session identifier); [0089] originMessageType (e.g., X2 or X3 which indicate where was the user-related signaling found); [0090] serviceID (i.e., a service identified such as RCS IM); [0091] userRelatedContentType (i.e., type of user-related content specific of a service, such as, IM for RCS IM service); [0092] userRelatedContent-user related signaling specific of a service (e.g. the IM content) and [0093] correlation ID (i.e., a parameter used to correlate user-specific signaling and content).

[0094] If the interception of CC is not allowed, the “serviceIri” is formatted to deliver user-related signaling for the specific service, but the “servicePayload” is blocked.

[0095] FIG. 10 is a schematic diagram of a device 1000 of a CSP (i.e., a CSP device) according to an embodiment. The CSP device 1000, which may be an IMS node and/or may also implement the LI mediation function/system to forward the IRI and/or CC to LEA, includes a communication interface 1010 and a processing unit 1020. The communication interface is configured to communicate via a network, such as a telecommunications wireless network.

[0096] Data processing unit 1020, which is connected to the communication interface 1010, is configured to extract LI data from one or more communications of an LI target (e.g. a User Equipment associated with a user identity, such as a public user identity in IMS) interacting with at least one core function of the network. Data processing unit 1020 is also configured to determine whether there is an association between the LI data and a service provided to the LI target via the network, and, if determined that the association exists, to generate one or more service-LI messages, which include service-specific information besides the LI data, to be forwarded to the LEA via the communication interface.

[0097] The CSP device 1000 may also include a memory 1040 and an operator interface 1030. The memory may store executable codes and/or a program 1042 that, when executed by the processing unit, make the device to perform any of the methods described in this section.

[0098] FIG. 11 is a block diagram of the CSP device 1100 according to another embodiment. The CSP device 1100 includes a transceiver 1110 configured to receive a communication of an LI target interacting with at least one core function of the network, and an LI data extraction module 1120 configured to extract LI data from the communication.

[0099] The CSP device 1100 further includes a service-LI data association seeker 1130 configured to determine whether there is an association between the LI data and a service provided to the LI target via the network, and a service-LI message generator 1140 configured, if determined that the association exists, to generate one or more service-LI messages, which include service-specific information besides the LI data, to be forwarded to the LEA, via the transceiver. Modules 1120, 1130 and 1140 may be implemented in hardware (e.g., on one or more processors and other electronic circuits) and/or software.

[0100] Thus, the embodiments disclosed in this section provide methods and network devices for lawful interception based on communications of an LI target with core network functions. It should be understood that this description is not intended to limit the invention. On the contrary, the exemplary embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention. Further, in the detailed description of the exemplary embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the invention. However, one skilled in the art would understand that various embodiments may be practiced without such specific details.

[0101] Although the features and elements of the present exemplary embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein. The methods or flowcharts provided in the present application may be implemented in a computer program, software or firmware tangibly embodied in a computer-readable storage medium for execution by a computer or a processor.

[0102] This written description uses examples of the subject matter disclosed to enable any person skilled in the art to practice the same, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the subject matter is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims.