WO2017203328A1

WO2017203328A1 - Method for providing position information related to legal interception in an ims network

Info

Publication number: WO2017203328A1
Application number: PCT/IB2016/053098
Authority: WO
Inventors: Andrea SENATORE; Antonio Giordano; Francesco TORO
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2016-05-26
Filing date: 2016-05-26
Publication date: 2017-11-30

Abstract

A network device running a lawful intercept mediation function in an IMS obtains intercepted-user's location information from a device running the policy and charging rules function, and forwards the information to a legal interception agent.

Description

METHOD FOR PROVIDING POSITION INFORMATION RELATED TO LEGAL INTERCEPTION IN AN IMS NETWORK

TECHNICAL FIELD

[0001] Embodiments of the subject matter disclosed herein generally relate to methods and devices for providing reliable user's location information to a legal interception agent, in an Internet Protocol Multimedia Subsystem (IMS).

BACKGROUND

[0002] IMS brought a substantive change in telecommunication networks by separating the access network from the service network, thereby enabling provision of services regardless of the access technology used (e.g. LTE, WI-FI, 3G). This new IMS architecture is entirely based on internet protocol (IP) and allows faster introduction of new services compared to the circuit-switched (CS) legacy world, where a mobile switching center (MSC) controlled both service and access.

[0003] From a legal interception standpoint, the separation of access and service networks poses challenges to reporting to a law enforcement agency (LEA) the same information provided by legacy networks. One such challenge is related to providing an intercepted-user's location to a LEA, which is information typically available in the access network (not in IMS), location's accuracy depending on the access technology available (e.g., LTE, WI-FI, 3G).

[0004] Providing the intercepted-user's location to the LEA is often indicated as mandatory when an interception is ordered. The intercepted user's location is easily provided and updated (when it changes) by a CS network that controls both access and service. However, when the interception is limited to an IMS network, reporting the intercepted user's location is more complicated, since the access network has location information, which is not readily available in IMS.

[0005] When IMS was initially implemented, the IMS was completely unaware of a user's location. However, with more recent versions, the Private-Access-Network- Info (PANI) header includes User Provided Location Information (UPLI). Since corrupting UPLI seems possible, ULPI is not considered trustworthy in a legal interception context. Therefore, Network Provided Location Information (NPLI), which the user cannot tamper with, has been developed. However, NPLI is currently only available in the initial "INVITE" message, at startup of a service such as a voice-over- LTE call in a 4G network (known as a VoLTE call). No mechanism exists for updating location information if the user's location then changes.

[0006] It is desirable to find solutions for providing in IMS features similar to those in legacy CS networks, to make it possible to report intercepted users' initial locations and any changes to location that follow.

SUMMARY

[0007] In order to overcome the limitations of conventional IMS deployment relative to legal interception (in particular during VoLTE service), the Lawful

Interception Mediation Function (LIMF) implemented in IMS connects to the Policy and Charging Rules Function (PCRF) of the access network. This connection enables LIMF to retrieve the most recent location information of intercepted users at any time.

[0008] According to an embodiment, there is a method performed by a first network device running a LIMF in an IMS. The method includes sending a user location information request to a second network device running a PCRF, receiving intercepted- user's location information from the second network device, and forwarding the intercepted-user's location information to a legal interception agent.

[0009] According to another embodiment, there is a network device in an IMS having a communication interface and a processor. The communication interface is configured to exchange messages with a network device running a PCRF, and with a legal interception agent. The processor is configured to control the communication interface to send a user location information request to the network device running the PCRF, to extract intercepted-user's location information from a message received from the network device running the PCRF, and to control the communication interface to forward the intercepted-user's location information to the legal interception agent.

[0010] According to yet another embodiment, there is a computer-readable recording medium storing executable codes which, when executed by a network device, make the network device perform a method for providing an intercepted user's location to a legal interception agent. The method includes sending to a user location an information request to a network device running a PCRF, receiving intercepted-user's location information from the network device running the PCRF, and forwarding the intercepted-user's location information to a legal interception agent.

[0011] According to yet another embodiment, there is a method performed by a first network device running an LIMF in an IMS. The method includes initiating submission of a user location information request to a second network device, which runs a policy and charging rules function, PCRF. The method further includes obtaining intercepted-user's location information provided by the second network device, and causing the intercepted-user's location information be sent to a legal interception agent.

[0012] According to yet another embodiment, there is a network device in an Internet Protocol Multimedia Subsystem, for providing intercepted-user's location to a legal interception agent. The network device includes a first module causing

submission of a user location information request to a policy and charging rules function, a second module for receiving intercepted-user's location information and a third module for forwarding the intercepted-user's location information to a legal interception agent.

BRIEF DESCRIPTION OF THE DRAWINGS

[0013] 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:

[0014] Figure 1 is a diagram illustrating a method according to an embodiment;

[0015] Figure 2 is a flowchart of a method according to another embodiment;

[0016] Figure 3 is a block diagram of a network device according to an embodiment;

[0017] Figure 4 is a flowchart of a method according to another embodiment; and

[0018] Figure 5 is graphic representation of a computer program according to yet another embodiment.

DETAILED DESCRIPTION

[0019] 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.

[0020] 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.

[0021] As described in 3GPP TS 23.228 V13.5.0 of March 2016, the NPLI function provides location information from 3GPP mobile access networks to the IMS network based on two different architectures. The first one uses a Proxy-Call Session Control Function (P-CSCF) that requests location information over the Rx interface from the PCRF, as described in 3GPP TS 29.214 V13.5.0 of March 2016. The Rx interface can be based both on RESTful HTTP and XML as specified in 3GPP TS 29.201 V13.4.0 of March 2016 and on Diameter protocol as described in 3GPP TS 29.214.

[0022] The second architecture is an Application Server (AS) requesting location information from the Home Subscriber Server (HSS) via the Sh interface thereof, as described in 3GPP TS 29.329 V13.0.0 of December 2015. The Sh interface enables exchange of signals and messages based on Diameter protocol. [0023] Focusing now on the first architecture, the PCRF is a software node designed to determine policy rules in IMS, in real-time. An IMS node can communicate with the PCRF node via an Rx interface, which is based on the Diameter protocol as described in 3GPP TS 29.214.

[0024] The following embodiments refer to an IMS network device that runs a Legal Intercept Mediation Function (LIMF) retrieving intercepted-user's location information at any time, and tracking changes of the user's location. Two main situations are considered: event-based retrieval of location information and tracking changes of the location.

A. Event-based retrieval of intercepted-user's location information

[0025] According to an embodiment, in the event-based scenario, a first network device running the LIMF in IMS interacts with a second network device running the PCRF in the access network via the Rx interface. As well known, in order for performing its functionality the PCRF receives location information and updated of the location information. The interaction between the first and the second network device may follow the steps illustrated in Figure 1.

[0026] When an intercepted user starts a call session, the first network device 1 10 sends an Authentication and Authorization Request (AAR) command to the second network node 120 at S100 to request user location information. The AAR includes USER_LOCATION in the Required-Access-Info Attribute Value Pair, AVP, or in ReqAcclnfo xml element (RESTful based Rx interface) and

ACCESS_NETWORK_INFO_REPORT within the Specific-Action AVP or in

SpecificAction xml element (RESTful based Rx interface). [0027] At S101 , the first network device receives an Authentication and

Authorization Answer (AAA) message from the second network device, to acknowledge the AAR command.

[0028] Upon receiving a Response to Authorization Request (RAR) message at S102, the second device extracts the 3GPP-User-Location-lnfo attribute or the ULI xml element (RESTful based Rx interface), the RAT-Type attribute or the RATType xml element (RESTful based Rx interface) and User-Location-Info-Time attribute or the ULITime (RESTful based Rx interface), from the RAR. The second device may acknowledge the RAR by sending a Response to Authorization Acknowledgement (RAA) at S103.

[0029] The second device may then forward this intercepted-user's location information to a legal interception agent 130 at S104. For example, the intercepted- user's location information may be embedded in an HI2 message as described in 3GPP TS 33.108 13.1.0 of March 2016. The location may be sent to LEA agent both embedded in an HI2 message that also carries call-event related information and as an HI2 message carrying only independent information (i.e. carrying only location).

[0030] At any point during the call (from initial session establishment to session termination), the second network device 120 may send an RAR (e.g., at S105) that contains updated NPLI conveyed by the 3GPP-User-Location-lnfo AVP or by ULI xml element (RESTful based Rx interface) and the Specific-Action AVP or in SpecificAction xml element (RESTful based Rx interface), including

ACCESS_NETWORK_INFO_REPORT. The first device acknowledges RAR receipt by sending an RAA at S106. [0031] Upon receiving the RAR, the first network device 1 10 extracts 3GPP-User- Location-lnfo attribute or the ULI (RESTful based Rx interface) and the RAT-Type attribute or the RATType (RESTful based Rx interface) from RAR and may send them to the legal interception agent 130 in an HI2 message as independent information (i.e., HI2 IRI REPORT) at S107. This HI2 message has the same correlation identifier of the HI2 messages related to each call event. Steps S105-S107 may be repeated until the call ends.

B. Tracking the intercepted-user's location information

[0032] In the tracking scenario, according to another embodiment, a first network device running the LIMF in an IMS interacts with a second network device running the PCRF in the access network via the Rx interface, according to the Diameter protocol, in the following manner.

[0033] The first network device sends an AAR command to the PCRF, via the Rx interface, to request user location information of an intercepted user. Similar to the event-based scenario, the AAR includes USER_LOCATION in the Required-Access- Info AVP, or in ReqAcclnfo xml element (RESTful based Rx interface) and

ACCESS_NETWORK_INFO_REPORT within the Specific-Action AVP or in

SpecificAction xml element (RESTful based Rx interface). The first network device then receives an AAA message from the second network device, to acknowledge the AAR command, followed by an RAR message that includes the intercepted-user's location information (i.e., 3GPP-User-Location-lnfo attribute or the ULI (RESTful based Rx interface), the RAT-Type attribute or the RATType (RESTful based Rx interface) and User-Location-Info-Time attribute or the ULITime (RESTful based Rx interface). The first device acknowledges the RAR by sending an RAA.

[0034] The second device stores this intercepted-user's location information (1 ) if no location information for the intercepted user has previously been stored, or (2) if the previously stored location is different from a current intercepted user's location. If (1 ) or (2) is satisfied, then the first network device sends the intercepted user's location to the legal interception agent 130, with the information included in an HI2 message. Unlike in the event-based scenario, the intercepted-user's location information is delivered as independent information (i.e., as an HI2 Location Information REPORT), not correlated with call events.

[0035] At any time, the second network device may send an RAR with updated intercepted-user's location information to the first network device. The first network device then extracts the 3GPP-User-Location-lnfo attribute or the ULI (RESTful based Rx interface), the RAT-Type attribute or the RATType (RESTful based Rx interface) and User-Location-Info-Time or the ULITime (RESTful based Rx interface) from the received RAR and replies with an RAA to the second network device. The first network device forwards the information to the legal interception agent as independent information, regardless whether a call is ongoing or not.

[0036] A flowchart of a method 200 for providing an intercepted user's location to a legal interception agent according to an embodiment is illustrated in Figure 2. The method includes sending a user location information request from a first device to a second network device at S210. The first network device runs a mediation function for mediating a call interception in an IMS, and the second device runs a PCRF in an access network. The user location information request may be included in an AAR sent via an Rx interface.

[0037] Method 200 further includes receiving intercepted-user's location information from the second device at S220. The intercepted-user's location

information may be included in an RAR command. Specifically, the intercepted-user's location information may be included in a 3GPP-User-Location attribute or the ULI (RESTful based Rx interface), a RAT-Type attribute or the RATType (RESTful based Rx interface) and User-Location-Info-Time attribute or the ULITime (RESTful based Rx interface) in the RAR command.

[0038] Method 200 further includes forwarding the intercepted-user's location information to a legal interception agent at S230. The intercepted-user's location information may be forwarded to the legal interception agent within an intercept-related- information message triggered by a call-related event. Alternatively or additionally, the intercepted-user's location information may be forwarded to the legal interception agent in an intercept-related-information (IRI) message independent of a call-related event, with the IRI message including call-identifying information.

[0039] Figure 3 is a block diagram of a network device 300 able to perform the above-described methods. Network device 300 includes a communication interface 310 configured to communicate wirelessly with other network devices in IMS 312. The communication interface 310 is connected to a processing unit 320 configured to control interface 510 to receive and transmit messages.

[0040] Network device 300 may also include a user interface 330 and a memory 340. Memory 340 may store executable codes which, when executed by processing unit 320, make the processing unit perform methods for providing intercepted-user's information to a legal interception agent according to various embodiments. However, in one embodiment, executable codes may also be received by the CPU 320 from another device via the network interface 310.

[0041] Although the above description referred to network devices, the described functionality may be implemented in a cloud environment and thus distributed over plural network devices. In other words, software may be transparently executed over different devices. For example, exchanging messages via the Rx interface and exchanging messages with the legal interception agent may be controlled by a physical device but performed by another.

[0042] In cloud context, the network device running the legal interception mediation function may initiate or cause method steps to be performed in the cloud. Figure 4 is a flowchart of a method 400 performed by a network device in an IMS according to another embodiment. Method 400 includes initiating submission of a user location information request to a second network device which runs a PCRF in an access network at S410. Method 400 further includes obtaining intercepted-user's location information provided by the second network device at S420. Finally, method 400 includes causing the intercepted-user's location information be sent to a legal interception agent at S430. Unlike in case of S210 and S220, in this embodiment, the IMS network device running the LIMF may not be the physical device that submits the user location information request or the physical device that forwards the intercepted- user's location information be sent to the legal interception agent. [0043] According to yet another embodiment illustrated in Figure 5, a network 500 may include modules causing a network device to perform steps of the methods 200 and/or 400. For example, computer program 500 includes a first module 510 whose execution causes sending a user location information request from a first device in IMS to a second network device in the access network via an Rx interface, a second module 520 whose execution handles receiving intercepted-user's location information from the second device, and a third module 530 whose execution triggers forwarding the intercepted-user's location information to a legal interception agent.

[0044] The prominent advantage of the embodiments is that they enable providing of the most recent location information of intercepted users to a LEA agent even if only the call is intercepted in IMS domain only. Moreover, the location information can be easily correlated with call events intercepted in the IMS domain. The embodiments provide the same location information as legacy CS domain interception to LEAs, when the interception is available only in the IMS domain. Another valuable advantage is that adding this functionality does not appear to have impact on existing nodes of IMS domains, since available standard interfaces (e.g., Rx) are used.

[0045] Suitable storage devices may store executable codes which, when executed in a device, make the device perform methods according to the above- described embodiments. Suitable storage devices may be non-transitory computer- readable media such as a hard disk drive (HDD), solid-state memory devices including flash drives, ROM, RAM and optical media. Hardware, firmware, software or a combination thereof may be used to perform the various steps and operations described herein. [0046] The embodiments disclosed in this section provide methods and network devices in IMS that are able to provide a reliable and up-to-date intercepted user's location to a legal interception agent. 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.

[0047] 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.

[0048] 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.

Claims

WHAT IS CLAIMED IS:

1. A method (200) performed by a first network device (1 10) running a lawful interception mediation function, LIMF, in an Internet Protocol Multimedia Subsystem, IMS, the method comprising:

sending (S210) a user location information request to a second network device (120) running a policy and charging rules function, PCRF;

receiving (S220) intercepted-user's location information from the second network device; and

forwarding (S230) the intercepted-user's location information to a legal interception agent (130).

2. The method of claim 1 , wherein the user location information request is included in an Authentication and Authorization Request, AAR, sent via an Rx interface.

3. The method of claim 1 , wherein the intercepted-user's location information is included in a Re-Auth-Request, RAR, command.

4. The method of claim 3, wherein the intercepted-user's location information is extracted from a 3GPP-User-Location attribute or an ULI, a RAT-Type attribute or a RATType and User-Location-Info-Time attribute or ULITime in the RAR command.

5. The method of claim 1 , wherein the intercepted-user's location information is forwarded to the legal interception agent within an intercept-related-information, IRI, message triggered by a call-related event.

6. The method of claim 1 , wherein the intercepted-user's location information is forwarded to the legal interception agent in a intercept-related-information, IRI, message independent of a call-related event, the IRI message including call-identifying information.

7. The method of claim 1 , wherein the sending of the user location information request is performed regardless on whether the user is involved in a call or not.

8. The method of claim 1 , further comprising:

storing the intercepted-user's location information if no intercepted-user's location information has previously been stored, or if a current intercepted user's location is different from a previous intercepted-user's location.

9. The method of claim 1 , wherein the forwarding is performed after the receiving of the intercepted-user's location, if no intercepted-user's location information has previously been forwarded, or if a current intercepted user's location is different from a previous intercepted user's location.

10. A network device (210, 300) configured to run a lawful interception mediation function in an Internet Protocol Multimedia Subsystem, IMS, the network device comprising:

a communication interface (310) configured to exchange messages with a network device running a policy and charging rules function, PCRF, and with a legal interception agent; and

a processor (320) configured

to control the communication interface to send a user location information request to the network device running the PCRF,

to extract intercepted-user's location information from a message received from the network device running the PCRF, and

to control the communication interface to forward the intercepted-user's location information to the legal interception agent.

1 1. The network device of claim 10, wherein the intercepted-user's location information is forwarded to the legal interception agent via an intercept-related- information, IRI, message triggered by a call-related event.

12. The network device of claim 10, wherein the processor controls the communication interface to forward the intercepted-user's location information to the legal interception agent in a intercept-related-information, IRI, message independent of a call-related event, the IRI message including call-identifying information.

13. The network device of claim 10, wherein the processor controls the communication interface to send the user location information request to the network device running the PCRF regardless on whether the user is involved in a call or not.

14. The network device of claim 10, further comprising:

a memory, wherein the processor stores the intercepted-user's location information in the memory if no intercepted-user's location information related to the intercepted user has previously been stored, or if a current intercepted user's location is different from a previous intercepted user's location.

15. The network device of claim 10, wherein the processor controls the communication interface to forward the intercepted-user's location information if no intercepted-user's location information related to the intercepted user has previously been forwarded, or if a current intercepted user's location is different from a previous intercepted-user's location.

16. A computer-readable recording medium (330) storing executable codes, which, when executed by a network device (300) make the network device perform a method (200) for providing intercepted-user's location to a legal interception agent, the method comprising:

sending (S210) a user location information request to a network device running a policy and charging rules function, PCRF; receiving (S220) intercepted-user's location information from the network device running the PCRF; and

forwarding (S230) the intercepted-user's location information to the legal interception agent.

17. The computer-readable recording medium of claim 16, wherein the intercepted-user's location information is forwarded to the legal interception agent via an intercept-related-information, IRI, message triggered by a call-related event.

18. The computer-readable recording medium of claim 16, wherein the intercepted-user's location information is forwarded to the legal interception agent in a intercept-related-information, IRI, message independent of a call-related event, the IRI message including call-identifying information.

19. The computer-readable recording medium of claim 16, wherein the sending of the user location information request is performed regardless on whether the user is involved in a call or not.

20. The computer-readable recording medium of claim 19, further comprising: storing the intercepted-user's location information if no intercepted-user's location information has previously been stored, or if a current intercepted user's location is different from a previous intercepted-user's location.

21. A method (400) performed by a first network device (1 10) running a legal interception mediation function in an Internet Protocol Multimedia Subsystem, IMS, the method comprising:

initiating (S410) submission of a user location information request to a second network device (120), which runs a policy and charging rules function, PCRF;

obtaining (S420) intercepted-user's location information from the second network device; and

causing (S430) the intercepted-user's location information be sent to a legal interception agent (130).

22. A network device (500) in an Internet Protocol Multimedia Subsystem, for providing intercepted-user's location to a legal interception agent, the network device comprising:

a first module (510) causing submission of a user location information request to a policy and charging rules function;

a second module (520) for receiving intercepted-user's location information in response to the user location information request; and

a third module (530) for forwarding the intercepted-user's location information to a legal interception agent.