OA20080A - Audit process for the monitoring of events. - Google Patents

Abstract

The invention relates to a method for operating a tracking entity (100, 400) configured to track to which access and connectivity management entity (200) a mobile device (50) is connected in a mobile communications network, wherein an application server (60) is initiating a monitoring of an event occurring at the mobile device, the method comprising: - receiving a request to monitor the event at the mobile device (50), the request comprising an indication for an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time, - transmitting the received request for the event with the indication for the audit and the indicated period of time to the access and connectivity management entity (200) to which the mobile device is connected, - receiving a notification from the access and connectivity management entity (200) that the event has not been detected for the indicated period of time, - determining, in response to the received notification, based on information available in the tracking unit whether the monitoring of the event should be continued or not.

Description

Technica'i Field

The présent invention relaies to a method for operating a tracking entity configured to track to which access and connectivity management entity a mobile device is connected in a mobile communications network. Furthermore, the corresponding tracking entity is provided. The invention additionally relates to a method for operating an access and 10 connectivity management entity configured to monitor the access and connectivity of a mobile device to a mobile communications network, and to the corresponding access and connectivity management entity. Additionally, a method for operating an exposure entity configured to expose services provided by the mobile communications network is provided and the corresponding exposure entity itself. In addition a system comprising the tracking 15 entity, the access and connectivity management entity and/or the exposure entity is provided, together a computer program comprising program code, and a carrier comprising the computer program.

Background

Cellular Internet of Things (CloT) is a technology which involves Machine-Type Communication devices (MTC device) so that a télécommunications operator may provide other parties/companies its network for different applications.

A clear example of such applications is the use of smart-metering readers, in which an MTC device can be placed in different locations and start sending and receiving data on a regular basis (e.g. electricity consumption reports, water-levels). This information requîtes that a given provider (e.g. electricity company) configures monitoring events on the different devices via a Service Capability Exposure Function (SCEF) for 4G devices and Network 30 Exposure Function (NEF) for 5G devices.

The Exposure Function or exposure entity is the SCEF or NEF, depending on the type of access (4G or 5G) and is a functional entity which receives the configuration of different monitoring events (e.g. MTC device becornes reachabie or any other event) initiated by an 35 Application Server (AS) and via the HSS (Home Subscriber Server) towards the Mobility Management Entity (MME) in 4G Core, or via UDM (Unified Data Management) towards the Access Management Function (AMF) in 5G Core. The MME/AMF will monitor the events for the duration requested by the AS, or until a given number of reports (also requested by the AS) is reached. This is called in 3GPP TS 23.682 (4G) and TS 23.502 (5G), and it may last months.

Fig. 1 shows a situation when the MME has lost connectivity to the other entities. In step S11, the application server configures the monitoring of an event in the exposure entity including the information which events should be monitored and including an expiration time until which the event should be monitored (e.g. with a message configure monitoring event, including information monitor-event=X, expiration-time=2019-01-01). In step S12, the exposure entity transmits a request to the subscriber database with the configuration data to monitor the desired event until the expiration date as indicated (ConfigurationInformation-Request, monitor-event=X, expiration-time=2019-01-01). In step S13, the subscriber database transmits a request to the MME, an insert data request including the information of the monitored event and the expiration time (Insert-Data-Request, monitorevent=X, expiration-time=2019-01-01). In step S14, the event is configured and the continuous monitoring and reporting is performed by the entities as indicated. In step S15, the MME detects the event for the MTC device and in step S16 the MME sends a report information request about the detected event to the SCEF (Report-Information-Request, event=X), wherein the request is confirmed in step S17 (Report-Information-Answer, ok). In steps S18 (Report, event-=X) and S19 (Ack, event-=X), the application server is informed, the latter acknowledging the report of step S18. As symbolized by step S20, the event may not occur for a certain period of time and this is detected by the MME, and the application server may détermine in step S21 (Configure monitoring event, removeevent=X) that the monitoring of the event should be removed so that the SCEF is informed accordingly. In step S22 (Configuration-Information-Request, remove-event=X), the subscriber database is informed accordingly with the configuration information request to remove the event. In Fig. 1, it is assumed that the MME has a temporary connectivity problem so that the MME cannot receive and transmit data from other entities or to other entities. Thus a connectivity failure occurs in step S23 and in step S24 (Insert-DataRequest, remove-event=X) to S26 the request for the removal of the event is sent several times and after a certain time the request is discarded after several reattempts. In step S27, the monitoring of the event is removed at the HSS, the exposure function and the application server, however, the MME is still monitoring the event until the desired expiration time without releasing its internai resources.

Accordingly. as shown in Fig. 1, the problem in the situation of Fig. 1 is that one entity may still monitor the event while others hâve already stopped monitoring the event.

A similar situation is shown in Fig. 2, the SCEF ioses ail the monitoring event data which then makes the MME monitoring useless since even if the event occurs, the reporting will never reacned the MTC application server since the application server was part of the data lost by the SCEF. Accordingly, in step S31 (Configure monitoring event, monitor-event=X, max-number-of-reports=Y), similar to step S21 a message is sent to the SCEF to configure the monitoring of the event the message including the event to be monitored at the maximum number of reports. This information is then provided to the subscriber database in step S32 (Configuration-Information-Request, monitor-event=X, max-number-ofreports=Y) and the other step S33 (Insert-Data-Request, monitor-event=X, max-numberof-reports=Y) and steps S34 to S39 correspond to steps S24 to S29.

Simiiar to Fig. 1, the event does not occur for a long time in step S40 and in step S41 the SCEF Ioses ail its data, e.g. due to a restant including the identity of the application server which requested the reporting of the event. Accordingly, after step S42 even if the event does not occur, the MME will keep monitoring the identified event identified by the request of step S31, even though the SCEF is not able to send the reports about the events to the application server.

In Fig. 3 the situation discussed above in connection with Fig. 1 is disclosed in connection with a 5G network. In step S51 (Nnef_EventExposure_Subscribe, monitor-event=X, expiration-time-2019-01-01), the application server subscribes to an event of a defined type inciuding the expiration time until which the event should be monitored. The subscriber message is transmitted in step S52 (Nudm_EventExposure_Subscribe_! monitor-event=X_; expiration-time=2019-01-01) to the UDM which forwards the message with the information as received to the AMF, S53 (Namf_EventExposure_Subscribe, monitor-event-X, expiration-time=2019-01-01). Similar to steps S14 to S16 the event is configured in S54 and the continuous monitoring is performed and when the AMF detects the event for the MTC device in S55 the network exposure function is informed accordingiy in S56 (Namf_EventExposure_Notify, event=X) with a confirmation been transmitted in step S57 (Namf_EventExposure_NotifyResponse, ok). Additionaily, the information is transmitted to the application server with a confirmation in steps S58 (NNef_EventExposure_Notify, event-=X) and S59 (Ack, event-=X).

L .4.

In step S60 the event does not occur for a certain time and in step S61 (Nnef_EventExposure_Unsubscribe, event=X) the application server détermines that it doesn't want to monitor the event anymore, wherein this information is transmitted to the UDM in step S62 (Nudm_EventExposure_Unsubscribe, everrt=X). tn step S63, the AMF 5 loses its connectivity so that in steps S64 to S66 the request to unsubscribe from the monitoring of the event is discarded after severai reattempts. in step S67, the event is removed at the involved entities, but notât the AMF and when the connectivity is recovered at the AMF in step S6S, the AMF will continue monitoring the event even though the other involved entities hâve already stopped monitoring the event.

Figure 4 describes a situation similar for the situation explaîned in connection with Fig. 2, however, for a 5G network. Acœrïfingly, the application server subscribes in S71 (Nnef_EventExposure_Subscribe, monitor-event=X, max-number-of-mports=Y) to the monitoring of the event with a maximum number of reports in the network exposure 15 function, wherein the information is forwarded to the UDM and the AMF in steps S72 (Nudm_EventExposura_Subs(mbe, monitor-event=X, max-number-of-reports=Y) and S73 (Namf_EventExposure_Subschbe, monitor-event^X, max-number-of-reports= Y), respectively. Steps S74 to S75 correspond to steps S34 and S35. Afterthe event is deleted în step S75, the information about the event is exchanged with the NEF in step S76 20 (Namf_EventExposure_Notify, event=X) and S77 (Namf_EventExposure_NotffyResponse, ot^. Furthermore, the AS is informed in steps S78 (Nnef_EventExposure_Notify, event-=X) and S79 (Ack, event-=X). When the event does not occur for a certain time period tn step S80 and when the metric exposure function loses its connectivity ali data is lest in step 882 so that the AMF will keep monitoring the event 25 even though the NEF is not able to send the report towards the application server.

As can be seen from the above discussion of Figs. 1 to 4 a main drawback résides in the basic concept of the continuons monitoring over a longer period of time. From the beginning there is a continuous monitoring for events which do not occur very often and the MTC 30 devices which may be stationary so that there is no change in the MME or AMF, any problem occurring in any of the nodes involved makes the information across the network inconsistent. This inconsistency may last days or months, and during such time the monitoring and resources associated to the monitoring are of no use and, what is more important, they cannot give room for new events if the resources such as the memory in 35 the MME or AMF are exhausted due to a large number of hanging monitoring events.

In the situation shown in Fig. 1 the HSS or UDM could keep the event to reattempt the request towards the MME or AMF for the removal after a given time, but this solution is not practical when there is a large number of events to be temporarily stored in the subscriber database HSS/UDM. Furthermore, this would lead to a large signaling increase when reattempting ail the events queued.

Summary

Accordingïy, a need exists to overcome the above mentioned probïems and to provide a solution in which a consistent way of monitoring of events is obtained at the different entities involved.

This need is met by the features of the independent claims. Further aspects are described in the dépendent claims.

According to a first aspect a method for operating a tracking entity configured to track to which access and connectivity management entity a mobile device is connected in a mobile communications network is provided, wherein an application server is initiating a monitoring of an event occurring at the mobile device. in the method a request is received at the tracking entity to monitory the event at the mobile device, wherein the request comprises an indication for an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time. The tracking entity furthermore transmits the received request for the event with the indication for the audit and the indicated period of time to the access and connectivity management entity to which the mobile device is connected. Furthermore, it receives a notification from the access and connectivity management entity that the event has not been detected for indicated period of time. In response to the received notification it is determined based on information available in the tracking entity whether the monitoring of the event should be continued or not.

The audit helps to keep the monitoring of events consistent. When the notification is received from the access and connectivity management, a query may be received to check with the rest of the network entities involved if the monitoring should be continued on not.

The information upon which the tracking entity détermines whether the monitoring should be continued on not can comprise information such as a unique identity of the device for «

-6which the event is monitored such as the 1MSI (International Mobility Subscriber Identity) and the unique identifier of the event being monitored.

Furthermore, the corresponding tracking entity is provided comprising a memory and at 5 least one processing unit, wherein the memory contains instructions exécutable by the at least one processing unit wherein the tracking entity is operative to work as discussed above or as discussed in further detail below.

As an alternative, a tracking entity is provided configured to track to which access and 10 connectivity management entity a mobile device is connected in a mobile communications network, wherein the tracking entity comprises a first module configured to receive a request to monitor the event at the mobile device wherein the request comprises an indication for an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked when the event has not occurred for an indicated period of 15 time. The tracking entity comprises a second module configured to transmit the received request for the event with the indication for the audit and the indicated period of time to the access and connectivity management entity. A third module is configured to receive a notification from the access and connectivity management entity that the event has not been detected for the indicated period of time and a fourth module of the tracking entity is 20 configured to détermine, in response to the received notification, whether the monitoring of the event should be continued based on the information provided in the tracking entity.

The request received at the tracking entity comprises the indication for the audit which is also transmitted to the access and connectivity management entity. The latter then carries 25 out the audit and informs the tracking entity accordingly if the event has not been detected for the indicated time range. The tracking entity can then détermine whether the monitoring of the event should be continued or not.

According., to a further aspect a method for operating an access and connectivity 30 management entity is provided configured to monitor the access and connectivity of the mobile device to the mobile communications network. The access and connectivity management entity receives a request to monitor the event at the mobile device initiated by an application server wherein the request comprises the indication for an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked 35 when the event has not been detected for an indicated period of time. The access and connectivity management entity then monitors whether the event occurs for the mobile (

device and if it is determined that the event has not occurred during the indicated period of time, the notification is transmitted to the tracking entity which is configured to track by which access and connectivity management entity the mobile device is connected to the mobile communications network. The notification can indicate that the event has not been 5 detected during the indicated period of time and that the audit should be started in other entities of the mobile communications network involved in the monitoring of the event.

Furthermore, the corresponding access and connectivity management entity is provided comprising a memory and at least one processing unit, wherein the memory contains 10 instructions exécutable by the at least one processing unit wherein the access and connectivity management entity is operative to work as discussed above or as discussed in further detail below.

As an alternative an access and connectivity management entity is provided comprising a 15 first module configured to receive a request to monitor an event at the mobile device initiated by an application server wherein the request comprises the indication for an audit for the monitoring of the event by which the validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time. The access and connectivity management entity comprises a second module configured to 20 monîtor whether the event occurs at the mobile device and when the second module detects that the event has not occurred within the indicated period of time, a third module is configured to transmit a notification to the tracking entity wherein the notification indicates that the event has not been detected during the indicated period of time and that an audit should be started in the other entities of the mobile communications network involved in 25 the monitoring of the event such as the tracking entity, the exposure entity or the application server.

Additionally, a method for operating an exposure entity configured to expose the services provided by or through the mobile communications network is provided. The method 30 comprises the steps of receiving a request from an application server to monitor an event at a mobile device connected to the mobile communications network. Furthermore, the monitoring of the event is configured in the mobile communications network wherein the configuration comprises configuring an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked when the event has not been 35 detected for an indicated period of time. Furthermore, a request is transmitted to monitor the event to the tracking entity which is configured to track to which access and connectivity

-8management entity the mobile device is connected to the mobile communications network. The request comprises the indication for the audit and the indicated period of time.

Additionally, the exposure entity is provided comprising the memory and at least one processing unit wherein memory contains instructions exécutable by the at least one processing unit, wherein the exposure entity is operative to work as discussed above or as discussed in further detail below.

As an alternative, an exposure entity is provided configured to expose services provided by the mobile communications network wherein the exposure entity comprises a first module configured to receive the request from the application server to monitor an event. A second module is provided configured to configure the monitoring of the event in the network wherein the audit for the monitoring of the event is configured. A third module of the exposure entity is configured to transmit the request to monitor the event to a tracking entity wherein the request comprises the indication for the audit and the indicated period of time.

Furthermore, a system comprising at least two éléments from the group of éléments comprising the tracking entity, the access and connectivity management entity and the exposure entity is provided.

Furthermore, a computer program comprising program code to be executed by the at least one processing unitofthe tracking entity, ofthe access and connectivity management entity or of the exposure entity is provided wherein execution of the program code causes the at least one processing unit to execute a method as discussed above for as discussed in further detail below.

Additionally, a carrier comprising the computer program is provided wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

it is to be understood that the features mentioned above and features yet to be expiained below can be used not only in the respective combinations indicated, but also in other combinations or in isolation without departing from the scope of the présent invention. Features of the above mentioned aspects and embodiments described below may be combined with each other in other embodiments unless explicitly mentioned otherwise.

- 9Brief Description of Drawings

The foregoing and additional features and effects of the application will become apparent from the following detailed description when read in conjunction with the accompanying drawings in which like reference numerals refer to like éléments.

Fig. 1 shows a situation ofthe entities involved în a monitoring of an event in a 4G network when an MME connectivity problem occurs in the solution known in the art.

Fig. 2 shows the situation at the involved entities for the monitoring of an event when an exposure function failure occurs in a system as known in the art.

Fig. 3 shows a situation similar to Fig. 1 concerning the monitoring of an event for a 5G network.

Fig. 4 shows a situation similar to the situation shown in Fig. 2 in a 5G network.

Fig. 5 shows a schematic message exchange between the involved entities in a situation in which the problems of the prior art shown in Figs. 1 to 4 are overcome with an audit mechanism in a 4G network.

Fig. 6 shows a situation similar to the situation shown in Figs. 2 and 4 for a 4G network in which the problems of Figs. 2 and 4 are overcome with the audit mechanism.

Fig. 7 shows a schematic message exchange between the entities involved in which it is determined to audit ali events.

Fig. 8 shows a schematic message exchange between the entities involved in a 5G network for a situation as discussed in connection with Fig. 5.

Fig. 9 shows a schematic view of a message exchange in a 5G network between the entities involved in a situation similar to the situation as shown in Fig. 6.

Fig. 10 shows a schematic view of a message exchange between the entities involved in a 5G network where the monitoring of ail events is initiated.

ï

- 10Fig. 11 shows a schematic view of a flow chart comprising the steps carried out at a tracking entity with the use of the audit mechanism.

Fig. 12 shows a schematic viewof aflowchart comprising the steps carried out at an access and connectivity management entity in the monitoring of an event with an audit mechanism.

Fig. 13 shows a schematic view of a flowchart comprising the steps carried out at an exposure entity in the monitoring of the events with to use of the audit mechanism.

Fig. 14 is a schematic architectural view of a tracking entity configured to control the monitoring of the event in case of an audit mechanism.

Fig. 15 shows another example schematic représentation of a tracking entity configured to monitor an event with an audit mechanism.

Fig. 16 shows a schematic architectural view of an access and connectivity management entity configured to monitor an event based on an audit mechanism.

Fig. 17 shows another example schematic représentation of the access and connectivity management entity configured to monitor an event with an audit mechanism.

Fig. 18 shows an example schematic architectural view of an exposure entity configured to use the monitoring of the event with an audit mechanism.

Fig. 19 shows another example schematic architectural view of an exposure entity configured to monitor events with an audit mechanism.

Detaiied Description of Drawings

In the following, embodiments of the invention will be described in detail with reference to the accompanying drawings. It should be understood, that the following description of embodiments is not to be taken in a limiting sense. The scope of the invention is not inîênded to be limited by the embodiments described hereinafter or by the drawings, which are to be illustrative only.

- 11 The drawings are to be regarded as being schematic représentations, and éléments illustrated in the drawings are not necessarily shown to scale. Rather, the various éléments are represented such that their function and general purpose becomes apparent to a person skilled in the art. Any connection or coupling between functional blocks, devices, components of physical or functional units shown in the drawings and described hereinafter may also be implemented by an indirect connection or coupling. A coupling between components may be established over a wired or wireless connection. Functional blocks may be implemented by hardware, software, firmware, or a combination thereof,

With the context of the présent application the term MTC device, mobile entity or user equipment, UE refers to a device for instance used by a person or which is associated with non-humans like animais, plants or machines. It may be a téléphoné type of device, for example a téléphoné or a session initiating protocol or voice over IP phone, cellular téléphoné, mobile station, cordless phone, or persona! digital assistant type of device like laptop, notebook, notepad, tablet equipped with a wireless data communication. The UE may be equipped with a subscriber identity module, SIM or entities such as the international mobile subscriber identity, IMSI, TMSI (the Temporary Mobile Subscriber Identity) or the globally unique temporary identity, GUTI, associated with the user using the UE. The presence of the SIM with the UE customizes the UE uniquely with a subscription of the user.

For the sake of clarity it is to be noted that there is a différence but a tight connection between a user and a subscriber. The user gets access to the network by acquiring a subscription to the network by that becomes a subscriber within the network. The mobile communications network then recognizes the subscriber and uses the associated subscription to identify related subscription data. A user can be the actual user of the UE and that the user may also be the owner of the subscription, but the user and the owner of the subscription may also be different.

In the following, the invention is described in connection with an MTC device. However, it should be understood that the invention is applicable to ali kinds of mobile devices or user equipment as elaborated above.

As will be discussed below, a mechanism is provided which ensures the consistency among ail the functional entities and release resources whenever an event is stale or not valid any longer. Accordingly the root cause that neither the interface between the >

MME/MMF and HSS/UDM and SCEF/NEF offers a mechanism to solve the problem is overcome.

A mechanism is introduced to audit events, especially long-lasting events which hâve not involved any e.g. traffic activity for an indicated time. As will be discussed below, the mechanism can be proactive, meaning that, when configuring an event, the .HSS or UDM corresponding to a tracking entity configured to track to which access and connectivity management entity the mobile device is connected to will request the access and connectivity management entity to audit the event in case it is dormant for an indicated maximum time. The mechanism as described below, can also be implemented in a reactive way in which the tracking entity such as the HSS/UDM can immediately request an audit so that the tracking entity audits ail events which are dormant for a given time.

In the following, the solution is shown for a faulty network in Fig. 5. As in connection with Fig. 1 an event is configured by the application server not shown in this Figure. In step S91 (Configuration-informatiûn-Request, monitor-ëvent=X, expiration-time=2019-01-01, suggested-audit-time=24 hours) the exposure entity, here the SCEF 300, configures the event in the network using a configuration information request including the monitored to be event, the expiration time for the monitoring and an audit time, meaning an indicated period of time after which the audit mechanism should start when the event has not occurred for the indicated time period. The time period can be several hours, several days, e.g. 24 hours, 48 hours, 1 week, etc..

In step S92 (Insert-Data-Request, monitor-event^X, expiration=2019-01-01, suggestedaudit-time=24 hours) the tracking entity which is configured to track to which access and connectivity management entity 200 the mobile device 50 is connected to, sends the configuration request with the requested audit time to the access and connectivity management entity, MME 200. în step S93 (InserLData-Answer, event-configured, accepted-audit-time=24hours) the MME accepts the request and indicates that the audit time requested was successfully initiated. In step S94 {Configuration-Information-Answer, event-configured, accepted-audit-time=24 hours) the response is returned by the subscriber data base, the tracking entity 100, including the accepted audit time.

In step S95 the event is removed as discussed above in connection with Fig. 1 in steps S21 to S28. Accordingly, an event is removed during an IP-connectivity failure ofthe MME which is not aware of the fact that the monitoring of the event should hâve been removed.

- 13When the connectivity is restored, in step S96, the MME still has the event active since it is not aware of the removal of the event by the HSS 100 or the SCEF. Since no activity is detected for the indicated period of time, such as 24 hours, the MME audits the event. In step S97 (Notification-Request, event-X, audit-request=status_inquiry), the MME sends a notification request indicating that the indicated type of event is active, requesting to check the status in the other network éléments such as the subscriber database or the exposure entity. In step S98, the HSS 100 does not find the event so it responds to the MME with the status that the event has been removed (Notification-Request, event-X, auditresult=removed), so that the MME is aware of the fact that the event is stale or not vaiid. In step S99, the MME locally removes the event in the MME. In the same time the HSS 100 informs the SCEF 300 that the specified event has been removed due to an audit, indicating that the requested type of event is not consistent across ail network éléments. In step S100 (Report-information-Request, event-X, audit-request^remove), the HSS 100 sends a reporting information request towards the SCEF 300 to remove the requested type of event if it exists in the SCEF. The removal is send expressively indicating that it is due to an inconsistency detected during an audit. In step S101, the SCEF checks whether the event audited exists. If this is the case, it is removed, otherwise the SCEF simply confirms the removal in step S102 (Report-Information-Answer, event=X, audit-resuit=removed). In step S103, if the event was removed in the SCEF, the application server is informed, that the event is no longer monitored. The application server can initiate a new monitoring if the event is still needed by the application. In step SI04, the monitoring of the event is stopped in the involved entities such as the MME, the HSS and the SCEF and the application server, wherein the resources are released in these entities, which were needed for monitoring of the event. Thus no inconsistency between the entities involved exists due to the audit mechanism.

Fig. 6 shows the situation with the audit mechanism when the SCEF 300 lost ail data. In step S111 (Configuration-Information-Request, monitor-event=X, expiration-time=201901-01, suggested-audit-time=24 hours), the request for the configuration of the monitoring is sent from the SCEF 300 to the HSS 100 including the information about the monitored event, the expiration time and the suggested audit time. In step S112 (insert-Data-Request, monitor-event=X, expiration-time=2019-01-01, suggested-audit-time=24 hours), the request is sent to the MME including the suggested audit time, wherein the réception is confirmed by the MME in step S113 (Insert-Data-Answer, event-configured, acceptedaudit-time=24 hours). In step S114 (Configuration-Information-Answer, event-configured, accepted-audit-time=24 hours), the configuration with the audit time is confirmed to the

- 14SCEF. In step S115, the SCEF fails as discussed above in connection with Fig. 2 in steps S41 and S42. In step S116, it is detected that the event does not occur for the indicated audit time so that in step S117 (Notification-Request, event-X, auditrequest=status_inquirÿ) the MME 200 informs the HSS accordingly requesting the status of the monitoring. In step S118, the event to be monitored is found in the HSS and the HSS audits the event in the SCEF so that in step S119 (Report-Information-Answer, event-X, audit-result=removed) a request is sent to the SCEF 300 comprising a status inquiry whether the monitoring of the event should be continued. Since the SCEF has lost ali data as discussed above, it does not find the event in step S120. In step S121 (ReportInformation-Answer, event-X, audit-nesult^removed), it informs the HSS 100 indicating that the event is no longer valid and should be removed. In step S122, the event is removed at the HSS 100 and in step S123 (Notification-Answer, event-X, audit-result=removed) an answer is sent in response to the request of step S117 that the event should be removed, !n step S124, the monitoring of the event is removed in the mobile device, the MME and the HSS so that the network éléments are consistent and the resources are released in the MME 200 and the HSS 100.

Fig. 7 shows a situation in which an audit of the complété network should be carried out. By way of example, after a failure in the SCEF an operator of the network may want to perform an audit in the network. To do so, it sends in step S131 an order to the SCEF to check whether there are events that hâve not been active for the defined period of time, such as 24 hours or more. In step S132, the SCEF checks the events with no activity in the indicated period of time such as 24hours after the recovery. In step S133 (Configurationinformation-Request, audit-request=status_inquiry_ALL_events, dormant_du'ation=24 hours), the SCEF 300 sends a configuration request to trigger an audit in the MME for ail events dormant for more than the indicated period of time. In step S134 (ConfigurationInformation-Answer, audit-result=status_inquiry_started), the HSS transmits a response indicating that auditing has been started. In step S135 (Insert-Data-Request, auditrëquest-status_inquiry_ALL_events, dormant_duration=24 hours), the HSS 100 sends a request to ail MMEs so that they start auditing the events with no traffic activity for the indicated period of time. Each MME also indicates that the auditing has started in step S136 (Insert-Data-Answer, audit-result=status_inquiry_started). In the embodiment shown in Fig. 7, one MME of the plurality of MMEs checks ail the events donnant for more than 24 hours and in step S138 (Notification-Request, event-X, audit-nequest=status_inquirÿ) the HSS 100 is informed accordingly when no traffic has been detected for the monitoring of an event. In step S139 (Report-Information-Request, event-X, audit-request=status_inquiry),

I

- 15a request is transmitted to the SCEF 300 requesting a status inquiry. if the event is found in step S140 in the SCEF, it replies with a successful answer. Otherwise, if the event does not exist in the SCEF it informs the HSS 100 that the event should be removed. This information is transmitted in step S141 (Report-Information-Answer, event=X, audit5 result=removed), wherein the information is forwarded in step S142 (Notification-Answer, audit-result=removed) to the MME. In step S143, the monitoring for the indicated event is ended and the resources are released.

In Fig. 8, the solution is shown for the problem discussed above in connection with Fig. 3 10 in which the AMF has a connectivity problem. In step S151 (Nudm_EventExposure_Audiï, monitor-event=X, êxpiration-time=2019-01-01, suggêsted-audit-time=24 hours), the exposure entity subscribes to the monitoring of the event in the U DM, the message in step S151 including the monitored event, the expiration time and the suggested audit time, thus, the indicated period of time. In steps S152 (Namf_EventExposure_Audit, monitor-event=X, 15 expiration-time=2019-01-01, suggested-audit-time=24 hours) and S153 (Namf_EventExposure_AuditResponse, event-configured, accepted-audit-time=24 hours), the information about the audit is exchanged between the UDM and the AMF and in step S154 (Numd_EventExposure_AuditResponse, event-configured, accepted-audit-time=24 hours) the response is transmitted in response to step S151 including that the audit has 20 been accepted. in step S155, the event is removed as discussed above in connection with

Fig. 3, steps S61 to S68, however, in view of the connectivity problem of the AMF, that continues the monitoring and as the event has not occurred for the defined period of time the audit is started in the AMF in step S156 so a status enquiry for the monitoring of the event is sent to the UDM in step S157 (Nudm_EventExposure_Audit, event-X. audit25 request=status_inquiry) with the response in step S158 (Nudm_EventExposure_AuditResponse, event-X, audit-resulf=removed) that the monitoring of the event has been removed. In step S159, the monitoring of the event is removed in the AMF and at the same time the network exposure function or entry is informed about the fact that the event has been removed due to the audit. In step S160 30 (Nnef_EventExposure_Audit, event=X, audit-request=remove), the request is send to the exposure entity to remove the monitoring of the event. In step S161, it is checked in the exposure entity, whether the monitoring of the event is active or not. If the event exists in the NEF it is removed at this point. Otherwise, the NEF simpiy confirms the removal in step S162 (Nnef_EventExposure_AuditResponse, event-X, audit-result=removed). In step 35 S163, if the event has been removed in the previous steps, the exposure entity notifies the application server which should initiate a new request to monitor the event if needed. In f

- 16step S164, the monitoring of the event is ended and the resources are released in the AMF, the UDM, the NEF and the application server.

Fig. 9 shows the situation in a 5G network when the faillira occurs at the NEF. Steps S171 to S174 correspond to steps S151 to S154. In step S175, the exposure entity fails as discussed above in connection with Fig. 4 in connection with steps S81 and S82. Accordingly, ail data is lost including the identity of the application server which requested the monitoring of the event. In step S176, the AMF détermines that the event has not occurred for an identified period of time and an audit request is transmitted in step S177 (Nudm_EventExposure_Audit, event-X, audit-request=status_inquiry) to the UDM. In step S178, the requested event is found in the UDM and the UDM audits the event in the network exposure function by transmitting the audit request with a status inquiry in step S179 (Nnef_EventExposure_Audit, event-X, audît-request=status_inquiry). In step S180, the event is not found in the NEF so that a response is transmitted in step S181 (Nnef_EventExposure_AuditResponse, event-X, audit-resu!t=removed) requesting to remove the event. In step S182, the event is removed from the UDM and the AMF is informed accordingly in step S183 (Nudm_EventExposure_AuditResponse, event-X. auditresult=removed) so that in step S184 the event is removed and the network is consistent with the resources being released in the AMF and the UDM.

In connection with Fig. 10, a situation similar to the one shown in connection with Fig. 7 is shown for a 5G network. In step S191, the network exposure function, NEF recovers from a failure and in step S192 the NEF desires to check longer lasting events such as events with no activity in the last 24 hours after the recovery of step S191. In step S193 (Nudm_EventExposure_Audit, auditrequest=status_inquiry_ALL_events.dormant_duration= hours), the UDM is asked to carry out the audit for ail events which are dormant for more than a defined time period. In step S194 (Nudm_EventExposure_AuditResponse, auditresult=status_inquiry_started), the response is sent to the NEF. In step 195 (Namf_EventExposure_Audit, auditrequest=status_inquiry_ALL_events,dormant_duration= hours), the UDM sends the audit request to the AMF with the response being sent back in step S196 (Namf_EventExposure_AuditResponse, auditresults=status_inquiry_started). In step S197, the AMF checks ail events which are dormant for more than the defined tîme period. In step S198 (Nudm_EventExposure_Audit_! event-X,audit-request=status_inquiry), the resuit of the audit of one event is transmitted to

- 17the UDM which transmits in step SI 99 (Nnef_EventExposure^Audit, event-X, auditrequest=status_inquiry) the information to the NEF. ln step 200, if the event is found in the NEF, it replies with a successful answer. Otherwise, if the event does not exist in the NEF, it informs the UDM that îhe event should be removed. This îs shown in step S201 (Nnef_EventExposure_AuditResponse, event=X, audit-resutl=removed), based on the assumption that the event does not exist in the NEF. This information is forwarded in step S202 (Nudm_EventExposure_AuditResponse, audît-result^removed) to the AMF and in step S203 the monitoring for this event is ended and the results are released in the UDM and AMF.

As far as the diameter protocol in the 4G cases is concerned, the following is noted:

a) A new IE (Information Element, in the form of an AVP) may be provided in s6a/s6t to indicate the desired audit time

b) A new IE (in the form of an AVP) may be provided in s6a/s6tto indicate the acceptée audit time (value not higher than the desired audit time)

c) A new IE (in the form of an AVP) may be provided in s6a/s6t to indicate the audit action (e.g. status_inquiry, status_inquiry_ALL_events, remove_event)

d) A new IE (in the form of an AVP) may be provided in s6a/s6t to indicate the audit resuit (e.g. event_removed, event_active)

As far as a serviced base interface protocol is concerned for the 5G network, a service operation network may be required for the audit, namely in more detail a new service operation is required for the Namf_EventExposure, Nnf_EventExposure, Nudm_EventExposure services (e.g. audit) or an existing service operation can be reused (e.g, notify).

Fig. 11 summarizes some of the main steps carried out at the tracking entity, such as the HSS or UDM 100. In step S210, the tracking entity, which tracks to which MME the mobile device is connected, receives the request with the indication for an audit as discussed above in connection with Fig. 5, step S91, S111 of Fig. 6, S151 ofFig. 8orS171 of Fig. 9. In step S211, the received request is transmitted to the MME or AMF including the indication for the audit and the indicated period of time. ln step S212, the tracking entity then receives a notification from the MME that the event has not been detected for the indicated period of time and in step S213 it is determined based on information whether the monitoring should be continued or not.

- 18In connection with Fig. 12, some of the main steps carried out at the access and connectivity management entity such as the MME or AMF are discussed in more detail. In step S221 the request is received to monitor the event at the mobile device as discussed above in connection with step S92, S112, S152 orS172. The monitoring whether the event occurs is carried out in step S222 for the mobile device and it is determined that the event has not occurred during the indicated period of time, so that in step S223 a notification is transmitted to the tracking entity to start the audit. The notification indicates that the event has not been detected and that the audit should be started in the other entities.

Fig. 13 shows some ofthe main steps carried out at the exposure entity such as the SCEF or the NEF discussed above. In step S231, the request is received from the application server to monitor the event and in step S232, the monitoring of the event is configured in the network with the audit for the monitoring by which the validity of the monitoring should be checked when the event has not occurred for the period of time. In step S233, a request is transmitted to the tracking entity wherein the request comprises the indication for the audit and the indicated period of time.

Fig. 14 shows a schematic architectural view of the tracking entity which can carry out the above discussed steps in which the tracking entity 100 is involved. The entity 100 comprises an interface or input/output which is provided for transmitting user data or control messages to other entities as discussed above or configured to receive user data or control messages from other entities as mentioned above. The interface can receive the request for the monitoring of the event with the audit and can transmit the received request to the MME. The entity 100 furthermore comprises a processing unit 120 which is responsible for the operation ofthe tracking entity 100. The processing unit 120 comprises one or more processors and can carry out instructions stored on a memory 130, wherein the memory may include a read-only memory, a random-access memory, a mass-storage, a hard disk or the like. The memory can include a suitable program code to be executed by the processing unit 120 so as to implement the above described functionalities in which the tracking entity is involved.

Fig. 15 shows another schematic architectural view of a tracking entity (400) comprising a first module (410) configured to receive the request to monitor the event with the indication for the audit, The entity 400 comprises a second module 420 configured to transmit the received request to the MME including the indication for the audit. A module 430 is provided which is configured to receive the notification from the MME that the event has not been detected for the indicated period of time and a module 440 is provided, configured to détermine based on information provided in the tracking unit 400 whether the monitoring of the event shouïd be continued or not.

Fig. 16 shows a schematic architectural view of an access and connectivity management entity 200 such as the MME or AMF discussed above. The access and connectivity management entity 200 comprises an interface or input/output 210 which is configured to transmit user data or control messages and which is configured to receive user data or control messages. The entity 200 furthermore comprises a processing unit 220 which is responsible for the operation of the access and connectivity management entity. The processing unit 220 comprises one or more processors and can carry out instructions stored on a memory 230, wherein the memory may include a read-only memory, a randomaccess memory, a mass-storage, a hard disk or the like. The memory furthermore includes suitable program code to be executed by the processing unit 220 so as to implement the above described functionalities in which the entity 200 is involved.

Fig. 17 shows another schematic architectural view of the access and connectivity management entity 500 which is configured to monitor the access and connectivity of the mobile device wherein the entity 500 comprises a first module 510 configured to receive the request to monitor the event including the indication for the audit. Module 520 is provided configured to monitor the event at the mobile device. Module 530 is provided for transmitting the notification to the tracking entity which indicates that the event has not been detected during the indicated period of time and that the audit should be started in the other entities.

Fig. 18 shows a schematic architectural view of the exposure entity configured to expose the services provided through the mobile communications network wherein the exposure entity comprises an input/output or interface 310 configured to transmit user data or control messages and configured to receive user data and control messages. The exposure entity 300 furthermore comprises a processing unit 320 which is responsible for the operation of the entity 300. The processing unit 320 comprises one or more processors and can carry out instructions stored on a memory 330. wherein the memory may include a read-only memory, a random-access memory, a mass-storage, a hard disk or the like. The memory can furthermore include suitable program code to be executed by the processing unit 320 so as to implement the above described functionalities in which the exposure entity is involved.

Fig. 19 shows another schematic architectural view of the exposure entity comprising a first module 610, configured to receive the request for the monitoring of the event, a second module 620 is provided, configured to implement the monitoring with the audit as discussed above. A third module 630 is provided configured to transmit a request to monitor the event with the indication for the audit to the MME.

As far as the event is concerned, different options exist. One example of an event is a reachability of a UE. By way of example, IMSI_1 is configured an event (e.g. UE reachability status) by SCEF_1. In this case, SCEF_1 créâtes a Reference-ld to uniquely identify such event in SCEF_1. This makes the event unique in the whole network, since by concatenating SCEF_1 with Reference-ld, the resuit is unique.

IMSI_1=214031111111111

SCEF-Reference-ld=l23456789

Event type = USE reachability

In HSS/UDM and AMF/MME, the event will be audited by simpîy indicating SCEF_1:123456789

In another example the event is the location status of the UE:, where IMSI_2 is configured an event (e.g. UE location status) by SCEF_2. In this case, SCEF_2 créâtes a Referenceid to uniquely identify such event in SCEF_2. This makes the event unique in the whole network, since by concatenating SCEF_2 with Reference-ld, the resuit is unique.

I MSI_2=214032222222222

Reference-I d=987654321

Event type - UE location status

In HSS/UDM and AMF/MME, the event will be audited by simpiy indicating SCEF_2: 987654321

From the above said, some general conclusions can be drawn:

- 21 As far as the tracking entity is concerned, the tracking entity détermines in response to the received notification from the access and connectivity management entity, that the event has not been detected for the indicated period of time, and the tracking entity détermines whether the monitoring of the event should be continued or not. This can be achieved by the tracking entity in combination with the exposure entity (e.g. NEF). If NEF does not hâve the event, then the tracking entity removes the event also in the access and connectivity entity. In short: the détermination is based on local checks and also on external checks (in NEF).

When the information available in the tracking unit indicates that the monitoring of the event should not be continued, a notification response may be transmitted to the access and connectivity management entity indicating that the monitoring of the event should be removed.

Furthermore, it is possible to inform the exposure entity configured to expose the services provided in the mobile communications network, that the monitoring of the event has been removed in response to the audit.

Furthermore, it is possible that the information available in the tracking entity indicates that the monitoring of the event should be continued. If this is the case, a report request is transmitted to the exposure entity in which it is requested whether the monitoring of the event should be continued or not.

Here it is possible to receive a response to the report request from the exposure entity in which it is indicated that the monitoring of the event should not be continued. The information available in the tracking unit may then be amended accordingly, such that the monitoring of the event is not continued.

When it is determined, based on the information available in the tracking unit, that the monitoring of the event should not be continued, the resources for the monitoring of the event may be reïeased.

Furthermore, the tracking unit may détermine that the audit for ail events to be monitored should be carried out for ail events for which the corresponding event has not been detected for the indicated period of time ( e.g. based on an operator’s request e.g. a manual command or request can be initiated in the NEF or the UDM to initiate this poîling of î

-22dormant events). The tracking entity then transmits a request to a plurality of access and connectivity management entities, requesting each of the access and connectivity management entities to start the audit for the monitoring of ail events for which the corresponding event has not been detected for the indicated period of time. Furthermore, 5 a modification may be received from at least one of the plurality of access and connectivity management entities wherein the notification indicates that one of the corresponding events has not been detected. The exposure entity is then asked, whether the event should still be monitored in viewofthe fact, that said one ofthe corresponding events has not been detected.

The step of determining that the audit for ail events should be carried out can be based on a request received from the exposure entity configured to expose the services provided by the mobile communications network by which the tracking entity is requested that the audit for ali events should be carried out. As an alternative, the step of determining that the audit 15 for ail events should be carried out, may also be triggered based on a predefined trigger event provided in the tracking unit (e.g. a prioritized event set by an operator of the mobile communications network).

As far as the operation of the access and connectivity management entity 200 such as the 20 MME or AMF is concerned, the access and connectivity management entity transmits a notification to the tracking entity 100 indicating that the audit should be started. The access and connectivity management entity 200 may receive a response to the notification wherein this response indicates that the monitoring of the event should not be continued, so that the monitoring of the event is removed in réaction to the received response and the 25 resources used for the monitoring of the event are released.

As far as the exposure entity 300 is concerned, the exposure entity may receive a report from the tracking entity indicating that the monitoring of the event at the tracking entity has been removed in response to the audit. The exposure entity can furthermore check, 30 whether the monitoring of the event is active in the exposure entity and when the monitoring of the event is active, the monitoring of the event can be stopped and at least one of the tracking entity and the application servers can be informed about the stopping of the monitoring.

The exposure entity may furthermore receive a request for the tracking entity to check whether the monitoring of the event is active in the exposure entity. The exposure entity f

-23can check whether the monitoring of the event is active in the exposure entity and when the monitoring is not active in the exposure entity, a response is transmitted to the tracking entity, asking the tracking entity to remove the monitoring ofthe event atthe tracking entity.

Furthermore, the exposure entity may détermine that an audit should be carried out for ali events to be monitored for which the corresponding event has not been detected within the indicated period of time. Furthermore, a request is forwarded to the tracking entity to audit ail events to be monitored for which the corresponding event has not been detected for the indicated period of time. A response may be received to the request from the tracking entity indicating that the monitoring of one event is active for which the event has not been detected within the indicated period of time and it is checked, whether the event is found in the exposure entity. When the event is not found, the tracking entity is requested to remove the monitoring of the event.

The fact, that the audit should be carried out for ail events, may be due to a request that the audit should be carried out, e.g. a request from the operator as discussed in connection with Fig. 7. Furthermore, it is possible that it is determined that the audit should be carried out based on a predefined trigger event provided in the exposure entity which starts the auditing of ail events when the trigger event occurs (e.g. also set by the operator).

The above described application offers a mechanism to ensure the consistency of ongoing monitoring of events across the different 4G or 5G function entities or network functions, especially for long-lasting monitoring events for devices with a long battery life-time, a low mobility and a low activity.

Claims (15)

1. A method for operating a tracking entity (100, 400) configured to track to which access and connectivity management entity (200) a mobile device (50) is connected in a 5 mobile communications network, wherein an application server (60) is initiating a monitoring of an event occurring at the mobile device, the method executed at the tracking entity and comprising:

- receiving (S210), from an exposure entity (300), a request to monitor the event at the mobile device (50), the request comprising an indication for an audit for the monitoring 10 of the event by which a validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time,

- transmitting (S211) the received request for the event with the indication for the audit and the indicated period of time to the access and connectivity management entity (200) to which the mobile device is connected,

15 - receiving (S212) a notification from the access and connectivity management entity (200) that the event has not been detected for the indicated period of time,

- determining (S213), in response to the received notification, based on information available in the tracking entity whether the monitoring of the event should be continued or not.

2. The method according to claim 1, wherein when the information available in the tracking entity indicates that the monitoring of the event should not be continued if a notification response is transmitted to the access and connectivity management entity (200) indicating that the monitoring of the event should be removed.

3. The method according to claim 2, further informing the exposure entity (300) configured to expose services provided by the mobile communications network that the monitoring of the event has been removed in response to the audit.

30

4. The method according to any of the preceding claims, comprising the steps of

- determining, at the tracking entity, that the audit for ail events to be monitored for which the corresponding event has not been detected within the indicated period of time should be carried out,

- transmitting a request, from the tracking entity to a plurality of access and

35 connectivity management entities (200), requesting each access and connectivity

-25management entity to start the audit for the monitoring of ail events for which the corresponding event has not been detected for the indicated period of time,

- receiving the notification, at the tracking entity from at least one of the plurality of access and connectivity management entities (200) indicating that one of the corresponding events has not been detected,

- wherein determining at the tracking entity whether the monitoring of the event should be continued or not further comprises asking the exposure entity (300) whether the event should stil! be monitored in view of the fact that said one of the corresponding events has not been detected.

5. A method for operating an access and connectivity management entity (200, 500) configured to monitor the access and connectivity of a mobile device (50) to a mobile communications network, the method executed at the access and connectivity management entity and comprising:

- receiving (S221), from a tracking entity (100, 400), a request to monitor an event at the mobile device initiated by an application server (60), the request comprising an indication for an audit for the monitoring of the event by which a validity of monitoring of the event should be checked when the event has not been detected for an indicated period of time,

- monitoring (S222) whether the event occurs for the mobile device (50), wherein when it is determined that the event has not occurred during the indicated period of time, a notification is transmitted (S223) to a tracking entity (100) configured to track by which access and connectivity management entity the mobile device is connected to a mobile communications network, the notification indicating that the event has not been detected during the indicated period of time, and that the audit should be started in other entities of the mobile communications network involved in the monitoring of the event,

6. A method for operating an exposure entity (300, 600) configured to expose services provided by the mobile communications network, the method executed at the exposure entity and comprising:

- receiving (S231) a request from an application server (60) to monitor an event at a mobile device connected to the mobile communications network, and

- configuring the monitoring of the event in the mobile communications network, wherein the configuring comprises:

-26configuring (S232) an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time, and transmitting (S233) a request to monitor the event to a tracking entity configured to track to which access and connectivity management entity the mobile device is connecied to the mobile communications network, fhe request comprising the indication for the audit and the indicated period of time.

7. The method according to claim 6, further comprising:

- receiving a request from the tracking entity to check whether the monitoring of the event is active in the exposure entity,

- checking whether the monitoring of the event is active in the exposure entity, wherein when the monitoring of the event is not active in the exposure entity,

- transmitting a response to the tracking entity asking the tracking entity to remove the monitoring of the event at the tracking entity.

8. The method according to any of daims 6 or 7,

- determining that the audit should be carried out for ail events to be monitored for which the corresponding event has not been detected within the indicated period of time,

- forwarding a request to the tracking entity to audit ail events to be monitored for which the corresponding event has not been detected with the indicated period of time

- receiving a response to the request from the tracking entity indicating that the monitoring of one event is active for which the event has not been detected within the indicated period of time,

- checking whether the event is found in the exposure entity, wherein when the event is not found, the tracking entity is requested to remove the monitoring of the event.

9. A tracking entity (100, 400) configured to track to which access and connectivity management entity (200, 500) a mobile device (50) is connected in a mobile communications network, wherein an application server (60) is initiating a monitoring of an event occurring at the mobile device, the tracking entity comprising a memory and at least one processing unit, the memory containing instructions, which when executed by said at least one processing unit, cause the tracking entity being operative to:

- receive, from an exposure entity (300, 600), a request to monitor the event at the mobile device (50), the request comprising an indication for an audit for the monitoring of

-27the event by which a validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time,

- transmit the received request for the event with the indication for the audit and the indicated period of time to the access and connectivity management entity (200, 500) to which the mobile device is connected,

- receive a notification from the access and connectivity management entity (200, 500) that the event has not been detected for the indicated period of time,

- détermine, in response to the received notification, based on information available in the tracking entity whether the monitoring of the event should be continued or not.

10. The tracking entity according to claim 9, further being operative, when the information available in the tracking entity indicates that the monitoring of the event should not be continued, to transmit a notification response to the access and connectivity management entity (200, 500) indicating that the monitoring of the event should be removed.

11. The tracking entity according to claim 10, further being operative to inform the exposure entity (300, 600) configured to expose services provided by the mobile communications network that the monitoring of the event has been removed in response to the audit.

12. The tracking entity according to any of claims 9 to 11, further being operative to - détermine that the audit for ail events to be monitored for which the corresponding event has not been detected within the indicated period of time should be carried out,

- transmit a request to a plurality of access and connectivity management entities (200, 500), requesting each access and connectivity management entity to start the audit for the monitoring of ail events for which the corresponding event has not been detected for the indicated period of time,

- receive the notification from at least one of the plurality of access and connectivity management entities (200, 500) indicating that one of the corresponding events has not been detected, and

- wherein, in determining whether the monitoring of the event should be continued or not, the tracking entity is further operative to ask the exposure entity (300) whether the event should still be monitored în view of the fact that said one of the corresponding events has not been detected.

13. An access and connectivity management entity (200, 500) configured to monitor the access and connectivity of a mobile device (50) to a mobile communications network, the access and connectivity management entity comprising a memory and at least one processing unit, the memory containing instructions, which when executed by said at least one processing unit, cause the access and connectivity management entity being operative to:

- receive, from a tracking entity (100, 400), a request to monitor an event at the mobile device initiated by an application server (60), the request comprising an indication for an audit for the monitoring of the event by which a validity of monitoring of the event should be checked when the event has not been detected for an indicated period of time,

- monitor whether the event occurs for the mobile device (50), wherein when it is determined that the event has not occurred during the indicated period of time, the access and connectivity management entity is operative to transmit a notification to a tracking entity (100, 400) configured to track by which access and connectivity management entity the mobile device is connected to a mobile communications network, the notification indicating that the event has not been detected during the indicated period of time, and that the audit should be started in other entities of the mobile communications network involved in the monitoring of the event.

14. An exposure entity (300, 600) configured to expose services provided by the mobile communications network, the exposure entity comprising a memory and at least one processing unit, the memory containing instructions, which when executed by said at least one processing unit, cause the exposure entity being operative to:

- receive a request from an application server (60) to monitor an event at a mobile device connected to the mobile communications network, and

- configure the monitoring of the event in the mobile communications network, wherein in order to configure, the exposure entity is further operative to:

configure an audit for the monitoring of the event by which a validity of the monitoring of the event should be checked when the event has not been detected for an indicated period of time, and transmit a request to monitor the event to a tracking entity configured to track to which access and connectivity management entity the mobile device is connected to the mobile communications network, the request comprising the indication for the audit and the indicated period of time.

15. The exposure entity according to claim 14, further being operative to:

- receive a request from the tracking entity to check whether the monitoring of the event is active in the exposure entity,

5 - check whether the monitoring of the event is active in the exposure entity, wherein when the monitoring of the event is not active in the exposure entity,

- transmit a response to the tracking entity asking the tracking entity to remove the monitoring of the event at the tracking entity.