PROCEDURES AND COMMUNICATION DEVICES RELATING TO LEGAL ENCLOSING
Patent Information
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
- Filing Date
- 2020-09-14
- Publication Date
- 2026-08-05
AI Technical Summary
In lawful interception systems, network elements (NE) may fail to deliver ReportIssue requests to the Lawful Interception Administrative Function (ADMF) due to network problems or misconfigurations, leading to unrecoverable situations and network overload from periodic realignment mechanisms.
A method involving communication devices that prepare and send ReportIssue request messages with an incremented Issue count, allowing the ADMF to identify and request missing information, using Ping or Keep Alive messages for real-time alignment, reducing the need for periodic GetAllDetails requests.
Ensures reliable messaging by aligning the ADMF with NEs in real-time, minimizing network overload and enabling immediate recovery from missed reports, thus enhancing the reliability and efficiency of lawful interception systems.
Description
Technical Field
[0001] The invention relates to a method performed by a communication device hosting a Network Element, a method performed by a communication device comprising a Lawful Interception Administration Function, communication devices, and a corresponding computer program.Background
[0002] Figure 1 shows an exemplary Lawful Interception, LI, network and system according to document ETSI GR NFV-SEC 011 V1.1.1. Figure 1 shows a high-level architecture for lawful interception in a virtualized environment. Entities are logically represented, therefore it does not necessary reflect separate physical entities. Entities will be described herein for a non-virtualized environment and for a virtualized environment.
[0003] The exemplary LI system comprises a Law Enforcement Agency, LEA, network and a Communications Service Provider, CSP, network. LEA 101 is an organization authorized by a lawful authorization based on the applicable jurisdiction to request and receive the results of telecommunications interceptions of an interception target. The target is a person of interest and / or user equipment possessed or used by the person of interest being surveyed by the LEA 101. Said LEA 101 communicates with the CSP network through a network interface, called Handover Interface, HI. LEA 101 comprises a Warrant Issuing Authority / Warrant Issuing Authority device 102 and a Law Enforcement Monitoring Facility, LEMF 103. The Warrant Issuing Authority 102 issues an intercept request, e.g. lawful authorization or warrant to the CSP through a first Handover Interface, HI1. The LEMF 103 collects the intercepted information of the interception target. The LEMF 103 communicates with an LI site 104 through a second Handover Interface, HI2, for receiving Intercept Related Information, IRI, and through a third Handover Interface, HI3, for receiving Content of Communication, CC. Interfaces HI1, HI2, and HI3 are specified in more detail in the ETSI TS 102 232-1 V3.21.1 standard, "Lawful Interception (LI); Part 1: Internal Network Interface X1 for Lawful Interception".
[0004] Entities within the CSP network communicate through internal network interfaces.
[0005] The LI site 104 comprises an LI Administration Function, ADMF, 105 and a Mediation and Delivery Function, MF / DF, 106. The LI ADMF 105 communicates with the MF / DF 106 through an X1_2 interface and an X1_3 interface. The LI ADMF 105 generate, based on said received intercept request, a warrant comprising one or more interception target identities, and send the warrant to a Point Of Interception, POI, 107, within an NE 108 via an interface denoted by X1_1; the NE 108 is an entity that performs the interception. Said POI 107 detects the interception target communication, derives the IRI or CC from the target communications, and delivers the POI Output to the MD / MF 106. POls are divided into two types based on the type of data they send to the MF / DF 106: IRI-POI delivers Intercept Related Information to the MF through an X2 interface and CC-POI delivers CC to the MF through an X3 interface. IRI are collection of information or data associated with telecommunications services involving the interception target identity, specifically call associated information or data (e.g. unsuccessful call attempts), service associated information or data (e.g. service profile management by subscriber) and location information. The CC is information exchanged between two or more users of a telecommunications service, excluding IRI. The MF receives IRI and CC and transforms them from internal interface format to Handover Interface format. The DF will then handle dispatching of said data to the one or more designated LEAs 101.
[0006] In a Network Functions Virtualization, NFV, environment, MF / DF 106 and POI 107 may be embedded within a Network Function, NF. In this scenario, an X1_DC interface is used by a virtualized POI, vPOI and virtualized MF / DF, vMF / vDF to inform each other of changes (e.g. scaling or mobility) in the virtualized environment. An NFV Management and Orchestration function, MANO, and / or a Security Orchestrator, SO, 109 handle the management and orchestration of all resources in a virtualized data center including computing, networking, storage, and virtual machine, VM, resources. An LI controller is responsible for creating, modifying, deleting, and auditing vPOI and vMF / vDF configuration during their lifecycle. The LI controller has two sub-functions: LI controller at network service application level, called LI App Controller 110, and LI controller at NFV level, called LI NFV controller 111. LI App Controller 110 and LI ADMF 105 communicate through an LI-Os-0 interface; LI App controller 110 and vPOI 107 communicate through an X0_1 interface; LI App controller 110 and vMF / vDF 106 communicate through an X0_2 interface. The LI NFV controller 111 is managed by the LI App controller 110 via an LI-OS-1 interface. X1_DC, X0_1, X0_2, LI-OS-0 and LI-OS-1 interfaces are specified in more detail in ETSI GR NFV-SEC 011 V1.1.1.
[0007] A Lawful Interception Routing Proxy Gateway, LRPG, 112 can be used to provide a Handover Interface proxy function to isolate the LEMF 103 and prevent the LEMF 103 to be visible to MANO 109. This function is optional.
[0008] Figure 2 is a block diagram of an exemplary LI network and system according to document ETSI TS 103 221-1 V1.7.1. The exemplary LI system comprises a number of communication devices, which host an NE, 108 connected to the LI ADMF 105 through the X1 interface.
[0009] According to the ETSI TS 103 221-1 standard, a command is sent from an LI ADMF to an NE as a "task", such as "activate", "modify" and "deactivate" on the X1 interface using a message structure defined in the standard, and the NE responds to the LI ADMF with a response message. The NE is manually provided (at installation and during network maintenance) with a specific destination for reporting issues to the LI ADMF. Issues can be reported using, for example ReportTasklssue, ReportDestinationlssue or ReportNElssue requests sent by the NE to the LI ADMF on the X1 interface as a spontaneous notification. In case of any issue (warning or fault) on Task, NE or Destination, the NE informs the LI ADMF with a related Reportxxxlssue request.Summary
[0010] It is an object to enable a more reliable LI system, e.g. through improved certainty in messaging between a network element, NE, and a lawful interception, LI, administrative function, ADMF.
[0011] A first aspect provides a method performed by a communication device for use with a communication device according to a firth aspect and hosting a network element, NE. The method comprises preparing a Report Issue request message for reporting an Issue and incrementing an Issue count to obtain a current Issue count of Issues reported by the NE to a lawful interception, LI, administrative function, ADMF, wherein the current Issue count also forms an identifier of the Issue. The current Issue count is added to the Report Issue request message and the Report Issue request message including the current Issue count is sent to the LI ADMF. The method further comprises receiving a request message from the LI ADMF requesting information about at least one Report Issue request message sent by the NE and not received by the LI ADMF, based on comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE and determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF, and sending a response message including the requested information.
[0012] Currently, in the case of a network problem an LI ADMF may not receive one or more Reportlssue requests sent by an NE and when the connection between the NE and the LI ADMF is reestablished, the LI ADMF is not aware that some Reportlssue requests have not been received and so it cannot take any action to recover from this situation. Also, in the case of a misconfiguration between an NE and an LI ADMF Reportlssue requests sent by the NE will be not received by the LI ADMF. The method advantageously enables a way for an LI ADMF to understand whether one or more Report Issue request messages, such as Reportlssue requests in the ETSI TS 103 221-1 standard, sent to it by an NE have not been received. The method also enables the NE to resend the information sent in the Report Issue request message that was not received by the LI ADMF. The LI ADMF may therefore be maintained aligned in real time with the NE as regards Reportlssue messages. The method may advantageously mitigate overload of the network because the NE will only resend information about Report Issue requests not received by the LI ADMF when really needed, removing the need for a periodic mechanism for realigning the LI ADMF with the NE as regards Report Issue requests.
[0013] In an embodiment, the Report Issue request message includes a CounterIssue field and the current Issue count is added in the Counterlssue field.
[0014] In an embodiment, the method further comprises receiving from the LI ADMF one of a Ping request or a Keep Alive request and sending a respective one of a Ping response or a Keep Alive response to the LI ADMF. The respective Ping response or Keep Alive response including information indicative of a current Issue count of Issues reported by the NE to the LI ADMF. Including the current Issue in Ping responses or Keep Alive responses may enable the LI ADMF to be aligned in real time with NE as regards Reportlssue requests and so any recovery action can be put in place immediately or just after few seconds.
[0015] In an embodiment, the request message is a GetAllDetails request and the response message is a GetAllDetails response. The method thus enables the GetAllDetails messages already present in the ETSI TS 103 221-1 standard to be used to cause the NE to resend the information sent in the Report Issue request message that was not received by the LI ADMF. The method may advantageously mitigate overload of the network because the NE will only send a GetAllDetails response when really needed, removing the need for a periodic mechanism for realigning the LI ADMF with the NE as regards Report Issue requests.
[0016] In an embodiment, the request message includes at least one identifier identifying the at least one Issue reported in the at least one Report Issue message for which information is requested. The response message includes information about the at least one Issue identified by the at least one identifier.
[0017] The method advantageously enables the information sent in the one or more Report Issue request messages that were not received by the LI ADMF to be requested and sent, thus reducing the use of GetAllDetails requests and GetAllDetails responses, the creation and handling of which can be computationally expensive. This method may advantageously mitigate overload of the network because a GetAllDetails message will be requested only when really needed. The method may advantageously mitigate overload of the network because the NE will only send a response message when really needed, removing the need for a periodic mechanism for realigning the LI ADMF with the NE as regards Report Issue requests.
[0018] Corresponding advantages apply also to a communication device of a fourth aspect.
[0019] A second aspect provides a method performed by a communication device hosting a lawful interception, LI, administrative function, ADMF. The method comprises receiving a message from a network element, NE, and obtaining from the message a current Issue count of Issues reported from the NE to the LI ADMF, wherein the current Issue count also forms an identifier of the Issue. The current Issue count of Issues reported from the NE to the LI ADMF is compared with a current Issue count of Issues received at the LI ADMF from the NE. The method further comprises determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF. A request message is sent to the NE requesting information about at least one Issue reported in the at least one Report Issue request message. A response message is received from the NE including the information about the at least one Issue reported in the at least one Report Issue request message. The current Issue count of Issues received at the LI ADMF from the NE is incremented based on the information in the response message.
[0020] Currently, in the case of a network problem an LI ADMF may not receive one or more Reportlssue requests sent by an NE and when the connection between the NE and the LI ADMF is reestablished, the LI ADMF is not aware that some Reportlssue requests have not been received and so it cannot take any action to recover from this situation. Also, in the case of a misconfiguration between an NE and an LI ADMF Reportlssue requests sent by the NE will be not received by the LI ADMF. The present method advantageously enables a way for an LI ADMF to understand whether one or more Report Issue request messages, such as Reportlssue requests in the ETSI TS 103 221-1 standard, sent to it by an NE have not been received. The method also enables the LI ADMF to obtain the information sent in the Report Issue request message that was not received.
[0021] In an embodiment, the message received from the NE is a Report Issue request including a Counterlssue field containing the current Issue count.
[0022] In an embodiment, the method further comprises sending one of a Ping request or a Keep Alive request to the NE and the message received from the NE is a respective one of a Ping response or a Keep Alive response. The respective Ping response or Keep Alive response including information indicative of a current Issue count of Issues reported by the NE to the LI ADMF. Receiving the current Issue in Ping responses or Keep Alive responses may enable the LI ADMF to be aligned in real time with NE as regards Reportlssue requests and so any recovery action by the LI ADMF can be put in place immediately or just after few seconds.
[0023] In an embodiment, the request message is a GetAllDetails request and the response message is a GetAllDetails response. The method thus enables the GetAllDetails messages already present in the ETSI TS 103 221-1 standard to be used to request the NE to resend the information sent in the Report Issue request message that was not received by the LI ADMF. The method may advantageously mitigate overload of the network because the LI ADMF will only send a GetAllDetails request, and the NE will only send a GetAllDetails response, when really needed, removing the need for a periodic mechanism for realigning the LI ADMF with the NE as regards Report Issue requests.
[0024] In an embodiment, the request message includes at least one identifier identifying the at least one Issue reported in the at least one Report Issue message for which information is requested. The response message includes information about the at least one Issue identified by the at least one identifier.
[0025] The method advantageously enables the information sent in the one or more Report Issue request messages that were not received by the LI ADMF to be requested and received, thus reducing the use of GetAllDetails requests and GetAllDetails responses, the creation and handling of which can be computationally expensive. This method may advantageously mitigate overload of the network because a GetAllDetails message will be send only when a GetAllDetails response is really needed. The method may advantageously mitigate overload of the network because the NE will only send a response message when really needed, removing the need for a periodic mechanism for realigning the LI ADMF with the NE as regards Report Issue requests.
[0026] Corresponding advantages apply also to a communication device of the fifth aspect.
[0027] A third aspect provides a computer program comprising instructions which, when executed on a communication device, cause the communication device to carry out the method according to the first aspect or second aspect.
[0028] The fourth aspect provides a communication device for use with a communication device according to the fifth aspect and comprising interface circuitry, at least one processor and memory. The memory comprises instructions which when performed by the at least one processor cause the communication device to perform the following network element, NE, operations. An operation of preparing a Report Issue request message for reporting an Issue. An operation of incrementing an Issue count to obtain a current Issue count of Issues reported by the NE to a lawful interception, LI, administrative function, ADMF, wherein the current Issue count also forms an identifier of the Issue. An operation of adding the current Issue count to the Report Issue request message. An operation of sending the Report Issue request message including the current Issue count to the LI ADMF. An operation of receiving a request message from the ADMF requesting information about at least one Report Issue request message sent by the NE and not received by the LI ADMF, based on comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE and determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF. An operation of sending a response message including the requested information.
[0029] A fifth aspect provides a communication device comprising interface circuitry, at least one processor and memory. The memory comprises instructions which when performed by the at least one processor cause the second communication device to perform the following lawful interception, LI, administrative function, ADMF, operations. An operation of receiving a message from the network element, NE. An operation of obtaining from the message a current Issue count of Issues reported from the NE to the LI ADMF, wherein the current Issue count also forms an identifier of the Issue. An operation of comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE. An operation of determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF. An operation of sending a request message to the NE requesting information about at least one Issue reported in the at least one Report Issue request message. An operation of receiving from the NE a response message including the information about the at least one Issue reported in the at least one Report Issue request message. An operation of incrementing the current Issue count of Issues received at the LI ADMF from the NE based on the information in the response message.
[0030] Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.Brief Description of the drawings
[0031] Figure 1 is a block diagram of an exemplary LI network and system according to prior art; Figure 2 is a block diagram of an exemplary LI network and system according to prior art; Figure 3 is a flowchart illustrating a method performed by a communication device according to embodiments; Figure 4 is a flowchart illustrating a method performed by a communication device according to embodiments; Figures 5 and 6 are block diagrams depicting communication devices according to embodiments; Figures 7 to 12 are signalling diagrams illustrating exchanges of messages in embodiments of the invention; and Figure 13 is a block diagram illustrating a method according to an embodiment. Detailed description
[0032] The same reference numbers will used for corresponding features in different embodiments.
[0033] An embodiment provides a method 200 performed by a communication device hosting a network element, NE. The steps of the method 200 are illustrated in Figure 3 and comprise: preparing 202 a Report Issue request message for reporting an Issue; incrementing 204 an Issue count to obtain a current Issue count of Issues reported by the NE to a lawful interception, LI, administrative function, ADMF; adding 206 the current Issue count to the Report Issue request message; sending 208 the Report Issue request message including the current Issue count to the LI ADMF; receiving 210 a request message from the LI ADMF requesting information about at least one Report Issue request message sent by the NE and not received by the LI ADMF; and sending 212 a response message including the requested information.
[0034] In an embodiment, the current Issue count also forms an identifier of the Issue.
[0035] In an embodiment, the Report Issue request message includes a CounterIssue field and the current Issue count is added in the Counterlssue field.
[0036] In an embodiment, the Report Issue request message is one of a ReportTasklssueRequest, ReportNElssueRequest or a ReportDestinationlssueRequest, each having a Counterlssue field. For example, the ReportTaskissueRequest, ReportNEIssueRequest and ReportDestinationlssueRequest message formats defined in Tables 34, 36 and 38 of the ETSI TS 103 221-1 standard for the LI X1 interface may be modified to include Counterlssue fields, as illustrated in Tables 34A, 36A and 38A below: Table 34A: Modified ReportTaskissueRequest FieldDescription Format M / C / O XIDSee clause 5.1See clause 5.1MTaskReportTypeType of IssueSee clause 6.5.2.2MTasklssueErrorCodeError code associated with the issue, if appropriateSee clause 6.7OTasklssueDetailsFurther description of issue if appropriateFree textOCounterIssue Identifier of the reported Issue Integer O Table 36A: Modified ReportDestinationlssueRequest FieldDescription Format M / C / O DIDSee clause 5.1See clause 5.1MDestinationReportTypeType of IssueSame as TaskReportType, see clause 6.5.2.2MDestinationIssueErrorCodeError code for the issue, if appropriateSee clause 6.7ODestinationIssueDetailsFurther description of issue if appropriateFree textOCounterIssue Identifier of the reported Issue Integer O Table 38A: Modified ReportNEIssueRequest FieldDescription Format M / C / O NEIssueDetailsDescription of issue being reported, including type of message (Warning, Fault Cleared, Fault Report) and descriptionErrorInformation structure (see clause 6.7)MCounterIssue Identifier of the reported Issue Integer O
[0037] In an embodiment, the step of incrementing an Issue count comprises incrementing a respective one of a Tasklssue count, an NEIssue count or a DestinationIssue count. Each of the ReportTasklssueRequest, ReportNEIssueRequest or a ReportDestinationlssueRequest has a respective Counterlssue field and the current TaskIssue count, the current NElssue count or the current DestinationIssue count is added to the respective Counterlssue field. The count of each type of Issue is thereby separately incremented and added to the respective Report Issue request message. In terms of the tables above, for example, a current Tasklssue count would be added to the Counterlssue field in the ReportTaskissueRequest, a current NElssue count would be added to the Counterlssue field of the ReportNEIssueRequest and a current DestinationIssue count would be added to the Counterlssue field in the ReportDestinationlssueRequest.
[0038] As described above, the current Issue count forms an Identified of the respective Issue, so the Tasklssue count added to CounterIssue field in the ReportTasklssueRequest forms an Identifier of the reported Tasklssue, the DestinationIssue count added to Counterlssue field in ReportDestinationlssueRequest forms an Identifier of the reported DestinationIssue and the NElssue count added to Counterlssue field in ReportNEIssueRequest forms an Identifier of the reported NElssue.
[0039] Corresponding embodiments relating to the Report Issue request apply to the method 300 performed by a communication device hosting an LI ADMF described below, with reference to Figure 4.
[0040] In an embodiment, the method 200 further comprises receiving a Ping request or a Keep Alive request from the LI ADMF and sending a respective one of a Ping response or a Keep Alive response to the LI ADMF. The Ping response or Keep Alive response includes information indicative of a current Issue count of Issues reported by the NE to the LI ADMF.
[0041] In an embodiment, the Ping response or Keep Alive response includes a CounterIssue field and the information indicative of a current Issue count is added in the Counterlssue field.
[0042] For example, the PingResponse and KeepAliveResponse message formats defined in Tables 41 and 43 of the ETSI TS 103 221-1 standard for the LI X1 interface may be modified to include Counterlssue fields, as illustrated in Tables 41A and 43A below: Table 41A: Modified PingResponse FieldDescription Format M / C / O OK or ErrorThe OK response has no other content. The general errors in clause 6.7 apply.See clause 6.7MCounterIssue Counter of the Issues Reported by NE to ADMF Integer O Table 43A: Modified KeepAliveResponse FieldDescription Format M / C / O OK or ErrorThe OK response has no other content. The general errors in clause 6.7 apply.See clause 6.7MCounterIssue Counter of the Issues Reported by NE to ADMF Integer O
[0043] In an embodiment, the Ping response or Keep Alive response includes a CounterTasklssue field, a CounterNElssue field and a CounterDestinationlssue field and a current Tasklssue count, a current NElssue count and a current DestinationIssue count are added in the respective field.
[0044] For example, the PingResponse and KeepAliveResponse message formats defined in Tables 41 and 43 of the ETSI TS 103 221-1 standard for the LI X1 interface may be modified to include three Counterlssue fields, one for each Issue type, as illustrated in Tables 41B and 43B below: Table 41B: Modified PingResponse FieldDescription Format M / C / O OK or ErrorThe OK response has no other content.See clause 6.7MThe general errors in clause 6.7 apply.CounterTaskIssue Counter of the TaskIssues Reported by NE to ADMF Integer O CounterNEIssue Counter of the NEIssues Reported by NE to ADMF Integer O CounterDestinationIssue Counter of the DestinationIssues Reported by NE to ADMF Integer O Table 43B: Modified KeepAliveResponse FieldDescription Format M / C / O OK or ErrorThe OK response has no other content.See clause 6.7MThe general errors in clause 6.7 apply.CounterTaskIssue Counter of the TaskIssues Reported by NE to ADMF Integer O CounterNEIssue Counter of the NEIssues Reported by NE to ADMF Integer O CounterDestinationIssue Counter of the DestinationIssues Reported by NE to ADMF Integer O
[0045] In an embodiment, the request message received from the LI ADMF is a GetAllDetails request and the response message sent to the LI ADMF is a GetAllDetails response. The GetAllDetails request and the GetAllDetails response messages have the format defined in the ETSI TS 103 221-1 standard for the LI X1 interface.
[0046] In an embodiment, the request message received from the LI ADMG includes at least one identifier identifying the at least one Issue reported in the at least one Report Issue message for which information is requested. The response message includes information about the at least one Issue identified by the at least one identifier.
[0047] The request message may have the message format illustrated in Table 1, below, and may be referred to as a GetReportlssueRequest message: Table 1: GetReportissueRequest Field Description Format M / C / O ReportlssueIdentifiersIdentifier of the reported Issues requested.StringO
[0048] The Reportlssueldentifiers filed contains at least one Identifier of at least one Issue reported in the at least one Report Issue message for which information is requested, i.e. that was not received by the LI ADMF. The Reportlssueldentifiers field may contain a plurality of Identifiers as numbers and / or ranges separated by commas, for example: 1,3,5-12; the respective Identifier being the integer current IssueCount, as described above. The contents of the Reportlssueldentifiers field may therefore be chosen to request a range of Identifiers, a list of Identifiers or a single Identifier; information about a range of Issues reported in a range of Report Issue messages not received by the LI ADMF may be requested, information about a plurality of Issues reported in a non-sequential plurality of Report Issue message not received by the LI ADMF, or information about a single Issue reported in a single Report issue message not received by the LI ADMF may thereby be requested.
[0049] The Reportlssueldentifiers field may alternatively be left empty in which case information about all active issues is requested.
[0050] The response message may have the message format illustrated in Table 2, below, and may be referred to as a GetReportlssueResponse message: Table 2: GetReportlssueResponse FieldDescription Format M / C / O ListOfReportTaskIssueList of requested active Task IssueList of Task issue structuresOListOfReportDestinationIssueList of requested active Destination IssueList of Destination issue structuresOListOfReportNEIssueList of requested active NE IssueList of NE issue structuresO
[0051] The lists of Task issue structures, Destination issue structures and NE issue structures may be as described in Tables 34, 36 and 38 of the ETSI TS 103 221-1 standard.
[0052] An embodiment provides a method 300 performed by a communication device hosting a lawful interception, LI, administrative function, ADMF. The steps of the method 300 are illustrated in Figure 4 and comprise: receiving 302 a message from a network element, NE; obtaining 304 from the message a current Issue count of Issues reported from the NE to the LI ADMF; comparing 306 the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE; determining 308 based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF; sending 310 a request message to the NE requesting information about at least one Issue reported in the at least one Report Issue request message; receiving 312 from the NE a response message including the information about the at least one Issue reported in the at least one Report Issue request message; and incrementing 314 the current Issue count of Issues received at the LI ADMF from the NE based on the information in the response message.
[0053] In an embodiment, the current Issue count also forms an identifier of the Issue.
[0054] In an embodiment, the message received from the NE is a Report Issue request including a Counterlssue field containing the current Issue count.
[0055] In an embodiment, the Report Issue request is one of a ReportTasklssueRequest, ReportNElssueRequest or a ReportDestinationlssueRequest and the respective Counterlssue field includes a respective one of a current Tasklssue count, a current NElssue count or a current DestinationIssue count, as described above with reference to Figure 3 and Tables 34A, 36A and 38A.
[0056] In an embodiment, the method 300 further comprises sending one of a Ping request or a Keep Alive request to the NE. The message received from the NE is a respective one of a Ping response or a Keep Alive response. The respective Ping response or Keep Alive response includes information indicative of a current Issue count of Issues reported by the NE to the LI ADMF.
[0057] In an embodiment, the respective one of a Ping request or a Keep Alive request includes a Counterlssue field including the information indicative of a current Issue count of Issues reported by the NE to the LI ADMF, as described above with reference to Figure 3 and Tables 41A and 43A.
[0058] In an embodiment, the Ping request or Keep Alive request includes a CounterTasklssue field including a current Tasklssue count, a CounterNElssue field including a current NElssue count and a CounterDestinationlssue field including a current DestinationIssue count, as described above with reference to Figure 3 and Tables 41B and 43B.
[0059] In an embodiment, the request message sent to the NE is a GetAllDetails request and the response message received from the NE is a GetAllDetails response. The GetAllDetails request and the GetAllDetails response messages have the format defined in the ETSI TS 103 221-1 standard for the LI X1 interface.
[0060] In an embodiment, the request message sent to the NE includes at least one identifier identifying the at least one Issue reported in the at least one Report Issue message for which information is requested. The response message includes information about the at least one Issue identified by the at least one identifier.
[0061] The request message may have the message format described above with reference to Table 1. The response message may have the message format described above with reference to Table 2.
[0062] An embodiment provides a method 700 of Issue reporting during lawful interception in a telecommunication network, illustrated in Figure 13. The method of this embodiment comprises the method 200 performed by a communication device hosting a NE, as described above with reference to Figure 3 and Tables 1, 2, 34A, 36A, 38A, 41A, 41B, 43A and 43B, combined with the method 300 performed by a communication device hosting an LI ADMF, as described above with reference to Figure 4 and Tables 1, 2, 34A, 36A, 38A, 41A, 41B, 43A and 43B.
[0063] Referring to Figures 5, 7 and 8, an embodiment provides a communication device 400 comprising interface circuitry 402, a processor 404 and a data carrier 406 in the form of a memory . The interface circuitry is configured to receive requests and / or send responses between the communication device 400 and an LI ADMF (or a communication device 500 which hosts the LI ADMF).
[0064] The memory comprises instructions 408 which when performed by the at least one processor 404 cause the communication device to perform network element, NE, operations of: preparing a Report Issue request message for reporting an Issue; incrementing an Issue count to obtain a current Issue count of Issues reported by the NE to a lawful interception, LI, administrative function, ADMF; adding the current Issue count to the Report Issue request message; sending the Report Issue request message 610 including the current Issue count to the LI ADMF; receiving a request message 620 from the ADMF requesting information about at least one Report Issue request message sent by the NE and not received by the LI ADMF; and sending a response message 622 including the requested information.
[0065] In other words, the instructions may be a NE software hosted by the communication device 400, the NE software configured to perform one or more of the methods and embodiments described herein.
[0066] In an embodiment, the interface circuitry is configured to receive requests and / or send responses over an interface, X1, in accordance with the ETSI TS 103 221-1 standard for the LI X1 interface.
[0067] Referring to Figures 6 to 8, an embodiment provides a communication device 500 comprising interface circuitry 502, a processor 504 and memory 506. The interface circuitry is configured to receive requests and / or send responses between the communication device 500 and a NE (or a communication device 400 which hosts the NE).
[0068] The memory comprises instructions 508 which when performed by the at least one processor 504 cause the communication device to perform lawful interception, LI, administrative function, ADMF, operations of: receiving a message 610 from the network element, NE; obtaining from the message a current Issue count of Issues reported from the NE to the LI ADMF; comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE; determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF; sending a request message 620 to the NE requesting information about at least one Issue reported in the at least one Report Issue request message; receiving from the NE a response message 622 including the information about the at least one Issue reported in the at least one Report Issue request message; and incrementing the current Issue count of Issues received at the LI ADMF from the NE based on the information in the response message.
[0069] In other words, the instructions may be a LI ADMF software hosted by the communication device 500, the LI ADMF software configured to perform one or more of the methods and embodiments described herein.
[0070] In an embodiment, the interface circuitry is configured to receive requests and / or send responses over an interface, X1, in accordance with the ETSI TS 103 221-1 standard for the LI X1 interface.
[0071] In an embodiment, the instructions further implement a Counter, the ADMFCounterlssue, configured to store the current Issue count of Issues received from the NE; the ADMFCounterIssue is incremented based on the information in the response message received from the NE.
[0072] Referring to Figure 9, in an embodiment, the memory comprises further instructions 508 which when performed by the at least one processor 504 cause the communication device to perform operations of: sending a Keep Alive Request 630 to the NE, as described above with reference to Figure 4; and receiving a Keep Alive Response 632 from the NE, as described above with reference to Figure 4 and Tables 43A and 43B.
[0073] In other words, in this embodiment, the message 610 received from the NE is a Keep Alive Response 632.
[0074] Referring to Figure 10, in an embodiment, the memory comprises further instructions 508 which when performed by the at least one processor 504 cause the communication device to perform operations of: sending a Ping Request 640 to the NE, as described above with reference to Figure 4; and receiving a Ping Response 642 from the NE, as described above with reference to Figure 4 and Tables 41A and 41B.
[0075] In other words, in this embodiment, the message 610 received from the NE is a Ping Response 642; for example, an HPPT(S) 200 OK X1 Ping Response including a Counterlssue field, as illustrated in Tables 41A and 41B above.
[0076] Figure 11 illustrates an example exchange of Ping messages between the NE 400 and LI ADMF 500 when the LI ADMF is first connected to a NE.
[0077] When the LI ADMF is connected to the NE for the first time, the current Issue count of Issues received at the LI ADMF from the NE (the "ADMFCounterlssue") is reset 650 to an initial value.
[0078] When the LI ADMF sends a PingRequest 640 to the NE and the NE sends a PingResponse 652 back to the LI ADMF, the PingResponse including a Counterlssue field containing the current Issue count of Issues reported from the NE to the LI ADMF (the "NECounterIssue"), as illustrated in Table 41A above.
[0079] Following sending of a first PingRequest by the LI ADMF and receipt of a first PingResponse from the NE, containing the current NECounterlssue, the LI ADMF sets 654 the ADMFCounterlssue to a valid value, i.e. the ADMF is set to the current NECounterlssue.
[0080] A corresponding message exchange can also be performed with Keep Alive messages.
[0081] Ping (or KeepAlive) messages are sent periodically when a NE is connected to an LI ADMF. After the first reception, any time a PingResponse or a KeepAliveResponse is received containing a NECounterlssue, the LI ADMF checks 658 the received NECounterlssue against the ADMFCounterlssue. If values are the same, there are no Report Issue requests sent by the NE that have not been received by the LI ADMF. If the values are not the same, i.e. the ADMFCounterlssue is lower than the received NECounterlssue, the LI ADMF determines that one or more Report Issue requests sent by the NE have not been received at the LI ADMF. The LI ADMF then sends a request message 620 to the NE requesting information about one or more Issue / s reported by the NE and not received by the LI ADMF. The LI ADMF may send a GetAllDetails request to the NE, and the NE respond with a GetAllDetails response, as described above, or the LI ADMF may send a GetReportlssueRequest and the NE respond with a GetReportlssueResponse, as described above with reference to Tables 1 and 2.
[0082] Figure 12 illustrates an example exchange of Report Issue messages between the NE 400 and LI ADMF 500 when the NE has a new Issue to report.
[0083] The NE prepares a Report Issue request message for reporting the Issue, for example a ReportNElssue request to report an NElssue and increments 660 the NECounterlssue by 1. The incremented NECounterlssue is added to the ReportNElssue request in the Counterlssue field and the NE sends 662 the ReportNElssue request to the LI ADMF.
[0084] The LI ADMF checks 664 the received Counterlssue against the current ADMFCounterlssue. If the received CounterIssue is only one greater than the current ADMFCounterlssue, no Reportlssue requests sent by the NE have not been received at the LI ADMF. The LI ADMF then sets 666 the ADMFCounterlssue to the received CounterIssue and sends 668 a ReportNElssueResponse to the NE.
[0085] If the received Counterlssue is more than one greater than the current ADMFCounterlssue, an indicated number of Reportlssue requests have not been received by the LI ADMF and the LI ADMF must request information about one or more Issue / s reported by the NE and not received by the LI ADMF. The LI ADMF may send a GetAllDetails request to the NE, and the NE respond with a GetAllDetails response, as described above, or the LI ADMF may send a GetReportlssueRequest and the NE respond with a GetReportlssueResponse, as described above with reference to Tables 1 and 2.
[0086] The ADMF using the Reportlssue counter can know if one or more notification is lost from NE.
[0087] An embodiment provides a lawful interception system 600 in a telecommunication network, as illustrated in Figures 5 to 8. The system comprising a first communication device 400 hosting a NE and a second communication device hosting an LI ADMF, as described above.
[0088] Referring to Figure 5, an embodiment provides a computer program 408 comprising instructions 410 which, when executed on a communication device 400, cause the communication device 400 to carry out the method 200 performed by a communication device hosting NE described above, with reference to Figure 3.
[0089] Referring to Figure 5, an embodiment provides the data carrier 406, for example memory having computer readable instructions embodied therein, the computer readable instructions for providing access to resources available on a communication device 400. The computer readable instructions comprising instructions to cause the communication device to perform the steps of the method 200 performed by a communication device hosting an NE described above, with reference to Figure 3.
[0090] Referring to Figure 6, an embodiment provides a computer program 508 comprising instructions 510 which, when executed on a communication device 500, cause the communication device 500 to carry out the method 300 performed by a communication device hosting an LI ADMF described above, with reference to Figure 4.
[0091] Referring to Figure 6, an embodiment provides a data carrier, for example memory, 506 having computer readable instructions embodied therein, the computer readable instructions for providing access to resources available on a communication device 500. The computer readable instructions comprising instructions to cause the communication device to perform the steps of the method 300 performed by a communication device hosting an LI ADMF described above, with reference to Figure 4.
Claims
1. A method (200) performed by a communication device (400) for use with a communication device (500) of claim 13 and hosting a network element, NE, the method comprising - preparing (202) a Report Issue request message for reporting an Issue; and characterized by: - incrementing (204) an Issue count to obtain a current Issue count of Issues reported by the NE to a lawful interception, LI, administrative function, ADMF, wherein the current Issue count also forms an identifier of the Issue; - adding (206) the current Issue count to the Report Issue request message; - sending (208) the Report Issue request message (610) including the current Issue count to the LI ADMF; - receiving (210) a request message (620) from the LI ADMF requesting information about at least one Report Issue request message sent by the NE and not received by the LI ADMF, based on comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE and determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF; and - sending (212) a response message (622) including the requested information.
2. The method of claim 1, wherein the Report Issue request message includes a CounterIssue field and the current Issue count is added in the Counterlssue field.
3. The method of any one of claims 1 to 2, further comprising: - receiving from the LI ADMF one of a Ping request (640) or a Keep Alive request (630); and - sending a respective one of a Ping response (642) or a Keep Alive response (632) to the LI ADMF, the respective Ping response or Keep Alive response including information indicative of a current Issue count of Issues reported by the NE to the LI ADMF.
4. The method of any one of claims 1 to 3, wherein the request message (620) is a GetAllDetails request and the response message (622) is a GetAllDetails response.
5. The method of any one of claims 1 to 3, wherein the request message (620) includes at least one identifier identifying the at least one Issue reported in the at least one Report Issue message for which information is requested and the response message (622) includes information about the at least one Issue identified by the at least one identifier.
6. A method (300) performed by a communication device hosting a lawful interception, LI, administrative function, ADMF, the method comprising - receiving (302) a message (610, 632, 642) from a network element, NE; and characterized by: - obtaining (304) from the message a current Issue count of Issues reported from the NE to the LI ADMF, wherein the current Issue count also forms an identifier of the Issue; - comparing (306) the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE; - determining (308) based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF; - sending (310) a request message (620) to the NE requesting information about at least one Issue reported in the at least one Report Issue request message; - receiving (312) from the NE a response message (622) including the information about the at least one Issue reported in the at least one Report Issue request message; and - incrementing (314) the current Issue count of Issues received at the LI ADMF from the NE based on the information in the response message.
7. The method of claim 6, wherein the message received from the NE is a Report Issue request (610) including a Counterlssue field containing the current Issue count.
8. The method of any one of claims 6 to 7, further comprising sending one of a Ping request or a Keep Alive request to the NE and wherein the message received from the NE is a respective one of a Ping response (642) or a Keep Alive response (632), the respective Ping response or Keep Alive response including information indicative of a current Issue count of Issues reported by the NE to the LI ADMF.
9. The method of any one of claims 6 to 8, wherein the request message (620) is a GetAllDetails request and the response message (622) is a GetAllDetails response.
10. The method of any one of claims 6 to 8, wherein the request message (620) includes at least one identifier identifying the at least one Issue reported in the at least one Report Issue message for which information is requested and the response message (622) includes information about the at least one Issue identified by the at least one identifier.
11. A computer program (408, 508) comprising instructions (410, 510) which, when executed on a communication device, cause the communication device to carry out the method according to any one of claims 1 to 10.
12. A communication device (400) for use with a communication device (500) according to claim 13 and comprising interface circuitry (402), at least one processor (404) and memory comprising instructions (408) which when performed by the at least one processor cause the communication device to perform network element, NE, operations of: - preparing a Report Issue request message for reporting an Issue; - incrementing an Issue count to obtain a current Issue count of Issues reported by the NE to a lawful interception, LI, administrative function, ADMF, wherein the current Issue count also forms an identifier of the Issue; - adding the current Issue count to the Report Issue request message; - sending the Report Issue request message (610) including the current Issue count to the LI ADMF; - receiving a request message (620) from the ADMF requesting information about at least one Report Issue request message sent by the NE and not received by the LI ADMF, based on comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE and determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF; and - sending a response message (622) including the requested information.
13. A communication device (500) comprising interface circuitry (502), at least one processor (504) and memory (506) comprising instructions (508) which when performed by the at least one processor cause the communication device to perform lawful interception, LI, administrative function, ADMF, operations of: - receiving a message (610, 632, 642) from the network element, NE; - obtaining from the message a current Issue count of Issues reported from the NE to the LI ADMF, wherein the current Issue count also forms an identifier of the Issue; - comparing the current Issue count of Issues reported from the NE to the LI ADMF with a current Issue count of Issues received at the LI ADMF from the NE; - determining based on the comparing that there is at least one Report Issue request message sent by the NE and not received by the LI ADMF; - sending a request message (620) to the NE requesting information about at least one Issue reported in the at least one Report Issue request message; - receiving from the NE a response message (622) including the information about the at least one Issue reported in the at least one Report Issue request message; and - incrementing the current Issue count of Issues received at the LI ADMF from the NE based on the information in the response message.