阅读说明：本技术 用于事件监视的审核过程 (Auditing process for event monitoring ) 是由 埃米利亚诺·美利奴巴斯克斯 杰苏斯-安杰尔·德-格雷格里奥-罗格里格斯 拉克尔·伊斯基耶多马丁 于 2018-10-15 设计创作，主要内容包括：本发明涉及一种用于操作跟踪实体(100,400)的方法,该跟踪实体(100,400)被配置为跟踪移动设备(50)在移动通信网络中连接到哪个接入和连接性管理实体(200),其中,应用服务器(60)正发起对在移动设备处发生的事件的监视,该方法包括：接收用于监视移动设备(50)处的事件的请求,该请求包括针对对事件的监视的审核的指示,当在指示的时间段内未检测到事件时,应通过审核来检查对事件的监视的有效性；向移动设备连接到的接入和连接性管理实体(200)发送所接收的针对事件的请求,该请求具有用于审核的指示和指示的时间段；从接入和连接性管理实体(200)接收在指示的时间段内未检测到事件的通知；响应于所接收的通知,基于跟踪实体中可用的信息来确定是否应继续对事件的监视。(The invention relates to a method for operating a tracking entity (100, 400), the tracking entity (100, 400) being configured to track to which access and connectivity management entity (200) a mobile device (50) is connected in a mobile communication network, wherein an application server (60) is initiating monitoring of events occurring at the mobile device, the method comprising: receiving a request for monitoring an event at a mobile device (50), the request comprising an indication of an audit of monitoring of the event by which validity of monitoring of the event should be checked when the event is not detected within an indicated time period; sending the received request for the event to an access and connectivity management entity (200) to which the mobile device is connected, the request having an indication for the audit and an indicated time period; receiving a notification from the access and connectivity management entity (200) that an event was not detected within the indicated time period; in response to the received notification, it is determined whether monitoring of the event should continue based on information available in the tracking entity.)

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

-receiving a request for monitoring the event at the mobile device (50), the request comprising an indication of an audit for the monitoring of the event by which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period,

-sending the received request for the event to the access and connectivity management entity (200) to which the mobile device is connected, the request having an indication for the audit and a time period for the indication,

-receiving a notification from the access and connectivity management entity (200) that the event was not detected within the indicated time period,

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

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

3. The method according to claim 2, further notifying an exposure entity (300) that monitoring of the event has been removed in response to the audit, the exposure entity (300) being configured to expose a service provided by the mobile communication network.

4. A method according to claim 1, wherein the information available in the tracking entity indicates that monitoring of the event should be continued, sending a report request requesting whether monitoring of the event should be continued to an exposure entity configured to expose services provided by the mobile communication network.

5. The method according to claim 4, further receiving a response to the report request from the exposure entity (300), the response indicating that monitoring of the event should not be continued, wherein information available in the tracking entity is modified such that monitoring of the event is not continued.

6. The method according to any of the preceding claims, wherein resources for monitoring of the event are released when it is determined that monitoring of the event should not be continued based on information available in the tracking unit.

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

-determining that an audit of all events to be monitored should be performed, for all events to be monitored, for which no corresponding event was detected within the indicated time period,

-sending a request to a plurality of access and connectivity management entities (200), the request requesting each access and connectivity management entity to start auditing the monitoring of all events for which a corresponding event was not detected within the indicated time period,

-receiving a notification from at least one of the plurality of access and connectivity management entities (200) of the access and connectivity management entities (200) indicating that one of the corresponding events was not detected, wherein the exposure entity (300) is queried in view of the fact that the one of the corresponding events was not detected as follows: whether the event should still be monitored.

8. The method of claim 7, wherein determining that a review of all events should be performed comprises: receiving a request from an exposure entity requesting that an audit of all events should be performed, the exposure entity being configured to expose services provided by the mobile communications network.

9. The method of claim 7, wherein determining that an audit of all events should be performed is triggered based on a predefined trigger event provided in the tracking entity.

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

-receiving a request initiated by an application server (60) for monitoring an event at the mobile device, the request comprising an indication of an audit for the monitoring of the event through which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period,

-monitoring for the mobile device (50) whether the event has occurred,

wherein, when it is determined that the event has not occurred during the indicated time period, a notification is sent to a tracking entity (100), the tracking entity (100) being configured to track through which access and connectivity management entity the mobile device is connected to a mobile communication network, the notification indicating that the event has not been detected during the indicated time period and that the auditing should be started in other entities in the mobile communication network that are involved in the monitoring of the event.

11. The method of claim 10, further receiving a response to the notification indicating that monitoring of the event should not continue, wherein monitoring of the event is removed in response to the received response and resources for monitoring the event are released.

12. A method for operating an exposure entity (300, 600), the exposure entity (300, 600) being configured to expose a service provided by a mobile communication network, the method comprising:

-receiving a request from an application server (60) for monitoring events at a mobile device connected to the mobile communication network,

-configuring monitoring of the event in the mobile communication network, the configuring comprising configuring an audit of the monitoring of the event by which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period,

-sending a request for monitoring said event to a tracking entity configured to track through which access and connectivity management entity said mobile device is connected to said mobile communication network, said request comprising an indication for said auditing and a time period for said indication.

13. The method of claim 12, further comprising:

-receiving a report from the tracking entity indicating that monitoring of the event has been removed at the tracking entity in response to the audit,

-checking whether the monitoring of the event is active in the exposure entity, wherein when the monitoring of the event is active, the monitoring of the event is stopped and at least one of the tracking entity and the application server is informed that the monitoring of the event is stopped.

14. The method of claim 12, further comprising:

-receiving a request from the tracing entity to check whether the monitoring of the event is active in the exposing 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,

-sending a response to the trace entity asking the trace entity to remove the monitoring of the event at the trace entity.

15. The method of any one of claims 12 to 14,

-determining that the audit should be performed on all events to be monitored for which no corresponding event was detected within the indicated time period,

-forwarding a request for auditing all events to be monitored for which no corresponding event was detected within the indicated time period to the tracking entity,

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

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

16. The method of claim 15, wherein determining that the audit should be performed on all events comprises: receiving a request requesting that the audit be performed on all events.

17. The method of claim 15, wherein determining that the audit should be performed on all events is triggered based on a predefined trigger event provided in the exposure entity.

18. 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 communication network, wherein an application server (60) is initiating monitoring of events occurring at the mobile device, the tracking entity comprising a memory containing instructions executable by at least one processing unit and at least one processing unit, wherein the tracking entity is operative to:

-receiving a request for monitoring the event at the mobile device (50), the request comprising an indication of an audit for the monitoring of the event by which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period,

-sending the received request for the event to the access and connectivity management entity (200, 500) to which the mobile device is connected, the request having an indication for the audit and a time period for the indication,

-receiving a notification from the access and connectivity management entity (200, 500) that the event was not detected within the indicated time period,

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

19. The tracking entity of claim 18, further operable to: when the information available in the tracking unit indicates that monitoring of the event should not be continued, sending a notification response to the access and connectivity management entity (200, 500) indicating that monitoring of the event should be removed.

20. The tracking entity of claim 19, further operable to: notifying an exposure entity (300, 600) that monitoring of the event has been removed in response to the audit, the exposure entity (300, 600) being configured to expose a service provided by the mobile communications network.

21. The tracking entity of claim 18, further operable to: when the information available in the tracking entity indicates that monitoring of the event should be continued, sending a report request requesting whether monitoring of the event should be continued to an exposure entity configured to expose a service provided by the mobile communication network.

22. The tracking entity of claim 21, further operable to: receiving a response to the report request from the exposure entity (300, 600) indicating that monitoring of the event should not be continued, and modifying information available in the tracking entity such that monitoring of the event is not continued.

23. The tracking unit of any of claims 18 to 22, further operable to: releasing resources for monitoring the event when it is determined that monitoring of the event should not continue based on information available in the tracking unit.

24. The tracking unit of any of claims 18 to 23, further operable to:

-determining that an audit of all events to be monitored should be performed, for all events to be monitored, for which no corresponding event was detected within the indicated time period,

-sending a request to a plurality of access and connectivity management entities (200, 500), the request requesting each access and connectivity management entity to start auditing the monitoring of all events for which a corresponding event was not detected within the indicated time period,

-receiving a notification from at least one of said plurality of access and connectivity management entities (200, 500), said notification indicating that one of said corresponding events was not detected, and inquiring said exposure entity (300) whether said event should still be monitored in view of the fact that said one of said corresponding events was not detected.

25. The tracking entity of claim 24, further operable to: in order to determine that audits for all events should be performed, a request is received from an exposure entity requesting that audits for all events should be performed, the exposure entity being configured to expose services provided by the mobile communications network.

26. The tracking entity of claim 24, further operable to: in order to determine that an audit of all events should be performed, the start of an audit of all events is triggered based on a predefined trigger event provided in the tracking unit.

27. An access and connectivity management entity (200, 500) configured to monitor access and connectivity of a mobile device (50) to a mobile communication network, the access and connectivity management entity comprising a memory and at least one processing unit, the memory containing instructions executable by the at least one processing unit, wherein the access and connectivity management entity is operative to:

-receiving a request initiated by an application server (60) for monitoring an event at the mobile device, the request comprising an indication of an audit for the monitoring of the event through which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period,

-monitoring for the mobile device (50) whether the event has occurred,

wherein, when it is determined that the event has not occurred during the indicated time period, the access and connectivity management entity is operative to send a notification to a tracking entity (100, 400), the tracking entity (100, 400) being configured to track through which access and connectivity management entity the mobile device is connected to a mobile communication network, the notification indicating that the event has not been detected during the indicated time period and that the auditing should be started in other entities of the mobile communication network participating in the monitoring of the event.

28. The access and connectivity management entity of claim 27, further operable to: receiving a response to the notification, the response indicating that monitoring of the event should not continue; and in response to the received response, removing the monitoring of the event and releasing resources for monitoring the event.

29. An exposure entity (300, 600) configured to expose services provided by a mobile communication network, the exposure entity (300, 600) comprising at least one processing unit and a memory, the memory containing instructions executable by the at least one processing unit, wherein the exposure entity is operative to:

-receiving a request from an application server (60) for monitoring events at a mobile device connected to the mobile communication network,

-configuring monitoring of the event in the mobile communication network, the configuring comprising configuring an audit of the monitoring of the event by which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period,

-sending a request for monitoring said event to a tracking entity configured to track through which access and connectivity management entity said mobile device is connected to said mobile communication network, said request comprising an indication for said auditing and a time period for said indication.

30. The exposure entity of claim 29, further operable to:

-receiving a report from the tracking entity indicating that monitoring of the event has been removed at the tracking entity in response to the audit,

-checking whether the monitoring of the event is active in the exposure entity, wherein when the monitoring of the event is active, the monitoring of the event is stopped and at least one of the tracking entity and the application server is informed that the monitoring of the event is stopped.

31. The exposure entity of claim 29, further operable to:

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

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

-sending a response to the tracing entity, the response requiring the tracing entity to remove the monitoring of the event at the tracing entity.

32. The exposure entity of any one of claims 29 to 31, further operable to:

-determining that the audit should be performed on all events to be monitored for which no corresponding event was detected within the indicated time period,

-forwarding a request for auditing all events to be monitored for which no corresponding event was detected within the indicated time period to the tracking entity,

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

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

33. The exposure entity of claim 32, further operable to: to determine that the audit should be performed on all events, a request is received requesting that the audit should be performed on all events.

34. The exposure entity of claim 32, further operable to: to determine that the audit should be performed on all events, the start of the audit on all events is triggered based on a predefined trigger event provided in the exposure entity.

35. A system comprising at least 2 elements from a group of elements comprising: the tracking entity according to any one of claims 18 to 26, the access and connectivity management entity according to any one of claims 27 or 28, and the exposure entity according to any one of claims 29 to 34.

36. A computer program comprising program code to be executed by at least one processing unit of a tracking entity, an access and connectivity management entity, or an exposure entity, wherein execution of the program code causes the at least one processing unit to perform the method according to any one of claims 1 to 9, 10 to 11, or 12 to 17.

37. A carrier comprising the computer program of claim 36, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

Technical Field

The present invention relates 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 communication network. Furthermore, a corresponding trace entity is provided. The present invention additionally relates to a method for operating an access and connectivity management entity configured to monitor access and connections of a mobile device to a mobile communication network, and to a corresponding access and connectivity management entity. Additionally, a method for operating an exposure entity configured to expose a service provided by a mobile communication network and the corresponding exposure entity itself are provided. Further, a system comprising a tracking entity, an access and connectivity management entity and/or an exposure entity is provided, as well as a computer program comprising program code and a carrier comprising the computer program.

Background

Cellular internet of things (CIoT) is a technology that involves machine type communication devices (MTC devices) so that telecommunication operators can provide other parties/companies with their own networks for different applications.

One obvious example of such an application is the use of smart meter readers, where MTC devices may be placed in different locations and begin to periodically send and receive data (e.g., power usage reports, water levels). Such information requires a specified provider (e.g., an electric utility company) to configure monitoring events on different devices via the Service Capability Exposure Function (SCEF) of the 4G device and the Network Exposure Function (NEF) of the 5G device.

The exposure function or exposure entity is SCEF or NEF according to the type of access (4G or 5G) and is the following functional entity: such a functional entity receives the configuration of different monitoring events (e.g. MTC devices becoming reachable or any other event) initiated by an Application Server (AS) and towards a Mobility Management Entity (MME) via an HSS (home subscriber server) in a 4G core or towards an Access Management Function (AMF) via a UDM (unified data management) in a 5G core. The MME/AMF will monitor for events for the duration of the AS request or before a given number of reports (also requested by the AS) are completed. This is referred to as "continuous monitoring" in 3GPP TS 23.682(4G) and TS 25.502(5G), and it may last for months.

Fig. 1 shows a case where an MME loses connection with other entities. In step S11, the application server configures monitoring of events in the exposed entity, including information of which events should be monitored, and including an expiration time before which events should be monitored (e.g., by message configuration monitoring event, including information monitor-event X, expiration-time 2019-01-01). In step S12, the exposure entity sends a Request to the subscriber database through the Configuration data to monitor for a desired event (Configuration-Information-Request) before the indicated expiration date (monitor-event) ═ X, expiration-time ═ 2019-01-01). In step S13, the subscriber database sends a Request, i.e., an Insert Data Request (Insert-Data-Request) including information of the monitored event and expiration time, monitor-event X, expiration-time 2019-01-01, to the MME. In step S14, the event is configured as indicated and continuous monitoring and reporting is performed by the entity. In step S15, the MME detects an event for the MTC device, and in step S16, the MME transmits a Report-Information-Request (Report-Information-Request), event ═ X), to the SCEF regarding the detected event, which is confirmed in step S17 (Report-Information-Answer, ok). In steps S18(Report, event ═ X) and S19(Ack, event ═ X), the application server is notified, and the application server confirms the Report of step S18. As shown by step S20, the event may not occur within a certain period of time and this is detected by the MME, and the application server may determine in step S21(Configure monitoring event), remove-event X that monitoring of the event should be removed, so that the SCEF is notified accordingly. In step S22(Configuration-Information-Request, remove-event ═ X), the subscriber database is notified of the Configuration Information Request for removing the event accordingly. In fig. 1, it is assumed that the MME has a temporary connection problem such that the MME cannot receive or transmit data from or to other entities. Therefore, a connection failure occurs in step S23, and in steps S24(Insert-Data-Request, remove-event ═ X) to S26, a Request for event removal is sent several times, and after a certain time, the Request is discarded after several retries. In step S27, the monitoring of the event is removed at the HSS, the exposure function and the application server, but the MME still monitors the event until the desired expiration time without releasing its internal resources.

Therefore, as shown in fig. 1, the problem in the case of fig. 1 is that: one entity may still monitor the event while the other entity has stopped monitoring the event.

A similar situation is shown in fig. 2, where the SCEF loses all monitoring event data, which makes MME monitoring useless, since even if an event occurs, the report will not reach the MTC application server, since the application server is part of the data that the SCEF lost. Therefore, in step S31 (configuration monitoring event), monitor-event X, max-number-of-reports Y), a message is sent to the SCEF to Configure monitoring of events, similar to step S21, including events to be monitored by the maximum number of reports. Then, in step S32 (Configuration-Information-Request), monitor-event (monitoring event) X, max-number-of-reports (maximum number of reports) Y, and other steps S33 (Insert-Data-Request), monitor-event (monitoring event) X, max-number-of-reports (maximum number of reports) Y), and steps S34 to S39 corresponding to steps S24 to S29, this Information is provided to the subscriber database.

Similar to fig. 1, in step S40, the event does not occur for a long time, and in step S41, the SCEF loses all of its data, e.g., due to a restart, including an identification of the application server requesting the reporting of the event. Therefore, after step S42, even if the event did not occur, the MME will keep monitoring the identified event identified by the request of step S31, even though the SCEF cannot send the report related to the event 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 events of a defined type, including the expiration time at which events should be monitored before. In step S52 (nutm _ EventExposure _ subscription, monitor-event ═ X, expiration-time ═ 2019-01-01), the subscriber message is sent to the UDM, and in S53(Namf _ EventExposure _ subscription, monitor-event ═ X, expiration-time ═ 2019-01-01), the UDM forwards the message with the received information to the AMF. Similar to steps S14 to S16, the event is configured and continuous monitoring is performed in S54, and when the AMF detects an event for the MTC device in S55, the network exposure function is notified accordingly in S56(Namf _ EventExposure _ Notify, event ═ X), while an acknowledgement (Namf _ EventExposure _ NotifyResponse, ok) is transmitted in step S57. Additionally, in steps S58(NNef _ EventExposure _ Notify, event- ═ X) and S59(Ack, event- ═ X), the information is sent to the application server with confirmation.

In step S60, an event does not occur within a certain time, and in step S61 (Nnef _ EventExposure _ unsubscript, event ═ X), the application server determines that it does not want to monitor the event any more, wherein this information is sent to the UDM in step S62 (nutm _ EventExposure _ unsubscript, event ═ X). In step S63, the AMF loses its connectivity, so that in steps S64 to S66, after several retries, the request for unsubscribing from monitoring of the event is discarded. In step S67, the event is removed at the involved entity but not at the AMF, and when connectivity is restored at the AMF in step S68, the AMF will continue to monitor the event even though the other involved entities have stopped monitoring the event.

Fig. 4 depicts a situation similar to that described in connection with fig. 2, but for a 5G network. Therefore, the application server subscribes to monitoring of the event with the maximum number of reports in the network exposure function in S71(Nnef _ EventExposure _ Subscribe, monitor-event _ X, max-number-of-reports _ Y), where the information is forwarded to UDM and AMF in steps S72 (dm _ EventExposure _ Subscribe, monitor-event _ X, max-number-of-reports _ Y) and S73(Namf _ EventExposure _ Subscribe, monitor-event _ X, max-number-of-reports _ Y), respectively. Steps S74 to S75 correspond to steps S34 and S35. After the event is deleted in step S75, information about the event is exchanged with NEF in steps S76(Namf _ EventExposure _ Notify, event ═ X) and S77(Namf _ EventExposure _ Notify response, ok). Further, the AS is notified in steps S78(Nnef _ EventExposure _ Notify, event ═ X) and S79(Ack, event ═ X). When the event does not occur within a certain period of time in step S80, and when the metric exposure function loses its connection, all data is lost in step S82, so that the AMF will keep monitoring the event even if the NEF cannot send a report to the application server.

As can be seen from the above discussion of fig. 1 to 4, the main disadvantage is the basic concept of continuous monitoring over a longer period of time. MTC devices that are not frequently involved and may be in a quiescent state such that there are no changes in the MME or AMF are continuously monitored from the outset, and therefore any problems occurring in any involved nodes may render the information on the network inconsistent. Such inconsistencies may last days or months and during this time the monitoring and monitoring related resources are useless and, more importantly, if resources such as memory in the MME or AMF are exhausted due to a large number of pending monitoring events, they cannot make room for new events.

In the case shown in fig. 1, the HSS or UDM may retain the event in order to re-attempt the request for removal after a given time to the MME or AMF, but this solution is not feasible when there are a large number of events to be temporarily stored in the subscriber database HSS/UDM. Furthermore, this will result in a significant increase in signalling when all events in the queue are reattempted.

Disclosure of Invention

Therefore, there is a need to overcome the above problems and to provide a solution that obtains a consistent way of event monitoring at the different entities involved.

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

According to a first aspect, there is provided 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 communication network, wherein an application server is initiating monitoring of events occurring at the mobile device. In the method, a request for monitoring of an event at a mobile device is received at a tracking entity, wherein the request comprises an indication of an audit of the monitoring of the event by which the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period. The tracking entity also sends the received request for the event with an indication for auditing and an indicated time period to an 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 no event has been detected within the indicated time period. In response to the received notification, it is determined whether monitoring of the event should continue based on information available in the tracking entity.

Auditing helps to keep monitoring of events consistent. When receiving the notification from the access and connectivity management entity, a query may be received to check whether monitoring should continue through the remaining network entities involved.

The information on which the tracking entity determines whether monitoring should continue may include information such as the unique identity of the device for which the event is to be monitored, e.g. the IMSI (international mobile subscriber identity), and the unique identifier of the event being monitored.

Furthermore, a corresponding trace entity is provided, the trace entity comprising a memory and at least one processing unit, wherein the memory contains instructions executable by the at least one processing unit, wherein the trace entity is operative to function as discussed above or as discussed in further detail below.

As an alternative, a tracking entity is provided, the tracking entity being configured to track to which access and connectivity management entity a mobile device is connected in a mobile communication network, wherein the tracking entity comprises a first module configured to receive a request for monitoring of an event at the mobile device, wherein the request comprises an indication of an audit for the monitoring of the event, by which audit the validity of the monitoring of the event should be checked when the event is not detected within an indicated time period. The tracking entity comprises a second module configured to send the received request for the event to the access and connectivity management entity with an indication for auditing and an indicated time period. The third module is configured to receive a notification from the access and connectivity management entity that an event was not detected within the indicated time period, and the fourth module of the tracking entity is configured to determine whether monitoring of the event should continue based on information provided in the tracking entity in response to the received notification.

The request received at the tracking entity includes an indication for an audit, which is also sent to the access and connectivity management entity. The access and connectivity management entity then performs an audit and informs the tracking entity accordingly in case no event is detected within the indicated time range. The tracking entity may then determine whether monitoring of the event should continue.

According to another aspect, a method is provided for operating an access and connectivity management entity configured to monitor access and connectivity of a mobile device to a mobile communications network. The access and connectivity management entity receives a request initiated by an application server for monitoring an event at a mobile device, wherein the request includes an indication of an audit for monitoring of the event by which validity of monitoring of the event should be checked when the event is not detected within an indicated time period. The access and connectivity management entity then monitors for the mobile device whether an event has occurred and, if it is determined that an event has not occurred during the indicated time period, sends a notification to a tracking entity configured to track through which access and connectivity management entity the mobile device is connected to the mobile communication network. The notification may indicate that the event was not detected during the indicated time period and that an audit should be started in other entities participating in the monitoring of the event in the mobile communication network.

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

As an alternative, an access and connectivity management entity is provided, comprising a first module configured to receive a request initiated by an application server for monitoring of an event at a mobile device, wherein the request comprises an indication of an audit for monitoring of the event by which validity of the monitoring of the event should be checked when the event is not detected within an indicated time period. The access and connectivity management entity comprises a second module configured to monitor whether an event has occurred at the mobile device, and when the second module detects that an event has not occurred within an indicated time period, a third module configured to send a notification to the tracking entity, wherein the notification indicates that an event has not been detected during the indicated time period and that an audit should be started in other entities (e.g. the tracking entity, the exposure entity or an application server) in the mobile communication network that are involved in the monitoring of the event.

In addition, a method for operating an exposure entity configured to expose a service provided by or through a mobile communication network is provided. The method comprises the following steps: a request is received from an application server for monitoring events at a mobile device connected to a mobile communications network. Furthermore, monitoring of events is configured in the mobile communication network, wherein the configuration comprises configuring an audit of the monitoring of events by which the validity of the monitoring of events should be checked when no event is detected within the indicated time period. Furthermore, a request for monitoring events is sent to a tracking entity configured to track through which access and connectivity management entity the mobile device is connected to the mobile communication network. The request includes an indication for the audit and an indicated time period.

In addition, an exposure entity is provided, the exposure entity comprising a memory and at least one processing unit, wherein the memory contains instructions executable by the at least one processing unit, wherein the exposure entity is operative to function as discussed above or as discussed in further detail below.

As an alternative, an exposing entity is provided, the exposing entity being configured to expose a service provided by a mobile communication network, wherein the exposing entity comprises a first module configured to receive a request for monitoring an event from an application server. A second module is provided that is configured to configure monitoring of events in a network, wherein auditing of the monitoring of events is configured. A third module of the exposure entity is configured to send a request for monitoring events to the tracking entity, wherein the request includes an indication for auditing and an indicated time period.

Furthermore, a system is provided, the system comprising at least two elements from a group of elements comprising: a tracking entity, an access and connectivity management entity and an exposure entity.

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

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

It is to be understood that the features mentioned above and those yet to be explained below can be used not only in the respective combinations indicated, but also in other combinations or alone without departing from the scope of the present invention. In other embodiments, the features of the aspects described above and the embodiments described below may be combined with each other, unless explicitly stated otherwise.

Drawings

The foregoing and additional features and advantages of the present application will become apparent upon reading the following detailed description in conjunction with the drawings in which like reference numerals refer to like elements.

Fig. 1 shows the situation of entities participating in monitoring events in a 4G network when an MME connectivity problem occurs in a solution known in the art.

Fig. 2 illustrates what is known in the art at the entity involved in monitoring events when an exposure function failure occurs in the system.

Fig. 3 shows a similar situation as fig. 1, involving monitoring of events for a 5G network.

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

Fig. 5 shows an exemplary message exchange between the involved entities in case the problems of the prior art shown in fig. 1 to 4 are overcome by an auditing mechanism in a 4G network.

Fig. 6 shows a situation similar to the situation shown in fig. 2 and 4 for a 4G network, where the problems of fig. 2 and 4 are overcome by an auditing mechanism.

Fig. 7 shows an exemplary message exchange between involved entities, wherein it is determined that all events are to be audited.

Fig. 8 shows an exemplary message exchange between the entities involved in the 5G network for the scenario discussed in connection with fig. 5.

Fig. 9 shows a schematic diagram of the exchange of messages between the entities involved in the 5G network in a situation similar to that shown in fig. 6.

Fig. 10 shows a schematic diagram of the exchange of messages between the entities involved in a 5G network, where monitoring of all events is initiated.

FIG. 11 shows a schematic diagram of a flow chart including steps performed at a tracking entity in the case of using an audit mechanism.

Fig. 12 shows a schematic illustration of a flow chart comprising steps performed at the access and connectivity management entities when monitoring events in case of an auditing mechanism.

FIG. 13 shows a schematic diagram of a flow chart including steps performed at an exposed entity when monitoring events using an auditing mechanism.

FIG. 14 is a schematic architecture diagram of a tracking entity configured to control monitoring of events in the context of an audit mechanism.

Fig. 15 shows another example schematic representation of a trace entity configured to monitor events in the context of an audit mechanism.

Fig. 16 shows a schematic architecture diagram of an access and connectivity management entity configured to monitor events based on an audit mechanism.

Fig. 17 illustrates another example schematic representation of an access and connectivity management entity configured to monitor events in the case of an audit mechanism.

FIG. 18 illustrates an exemplary schematic architecture diagram of an exposure entity configured to use monitoring of events in the context of an audit mechanism.

FIG. 19 illustrates another example schematic architecture diagram of an exposure entity configured to monitor events in the context of an audit mechanism.

Detailed Description

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings. It should be understood that the following description of the embodiments should not be construed in a limiting sense. The scope of the present invention is not intended to be limited by the embodiments or figures described below, which are illustrative only.

The figures are to be regarded as schematic representations and elements shown in the figures are not necessarily shown to scale. Rather, the various elements are represented such that their function and general purpose are readily apparent to those skilled in the art. Any connection or coupling between components of functional blocks, devices, physical or functional units shown in the figures and described below may also be achieved through an indirect connection or coupling. The coupling between the components may be established by a wired or wireless connection. The functional blocks may be implemented by hardware, software, firmware, or a combination thereof.

In the context of the present application, the term "MTC device", "mobile entity" or "user equipment, UE", refers to a device used, for example, by humans or associated with non-humans, such as animals, plants or machines. It may be a telephone type device (e.g. a telephone or session initiation protocol or voice over IP telephone, a cellular telephone, a mobile station, a cordless telephone) or a personal digital assistant type device (such as a laptop, notebook, notepad, tablet computer equipped with wireless data communication). The UE may be equipped with a subscriber identity module SIM or an entity associated with the user using the UE, such as an international mobile subscriber identity IMSI, TMSI (temporary mobile subscriber identity) or globally unique temporary identity GUTI. The presence of a SIM in the UE allows the UE to be uniquely customized by the user's subscription.

For clarity, it is noted that there is a distinction between users and subscribers, but there is a close connection. A user gains access to a network by acquiring a subscription to the network, thereby becoming a subscriber within the network. The mobile communications network then identifies the subscriber and uses the associated subscription to identify relevant subscription data. The user may be the actual user of the UE and the user may also be the owner of the subscription, but the user and the owner of the subscription may also be different.

Hereinafter, the present invention is described in connection with MTC devices. It should be understood, however, that the present invention is applicable to all kinds of mobile devices or user equipment as described above.

As will be discussed below, a mechanism is provided that ensures consistency among all functional entities and releases resources whenever an event becomes stale or no longer valid. Thus, the root cause that the interfaces between MME/MMF and HSS/UDM and SCEF/NEF can not provide a mechanism to solve the problem is overcome.

Mechanisms are introduced to audit events, especially persistent events that do not involve, for example, any traffic activity for the indicated time. As described below, this mechanism may be proactive, meaning that at the time of configuring an event, the HSS or UDM corresponding to the tracking entity configured to track which access and connectivity management entity the mobile device is connected to will request that the access and connectivity management entity audit the event if it is in an inactive state (dormant) for the maximum time indicated. The mechanism described below may also be implemented in a reactive manner, where a tracking entity such as a HSS/UDM may request an audit immediately, so that the tracking entity audits all events that are in an inactive state for a given time.

In the following, a solution for a failing network is shown in fig. 5. As shown in connection with fig. 1, the event is configured by an application server, which is not shown in this figure. In step S91(Configuration-Information-Request, monitor-event X, expiration-time 2019-01-01, and subscribed-audit time 24 hours), the exposed entity (here, SCEF 300) uses a Configuration Information Request to configure an event in the network, the Configuration Information Request including an event to be monitored, an expiration time for monitoring, and an audit time, the audit time referring to some indicated time period after which the audit mechanism should be started when no event occurs within the indicated time period. The time period may be several hours, days, e.g., 24 hours, 48 hours, 1 week, etc.

In step S92(Insert-Data-Request, monitor-event X, expiration 2019-01-01, subscribed-audio-time 24 hours), the tracking entity configured to track which access and connectivity management entity 200 the mobile device 50 is connected to sends a configuration Request with the requested audit time to the access and connectivity management entity MME 200. In step S93(Insert-Data-Answer, event-configured, accepted-audio-time ═ 24 hours), the MME accepts the request and indicates that the requested audit time has been successfully enabled. In step S94(Configuration-Information-Answer, event-configured, accepted-audio-time being 24 hours), a response including the accepted audit time is returned by the subscriber database (tracking entity 100).

In step S95, the event is removed, as discussed above in steps S21 through S28 in conjunction with fig. 1. Thus, an event is removed during an IP connection failure of the MME, and the MME is unaware of the fact that monitoring for the event should have been removed. When the connection is resumed, the MME still puts the event in the active state in step S96, since it is not aware of the HSS100 or SCEF removal event. Since no activity is detected for an indicated period of time (such as 24 hours), the MME audits the event. In step S97(Notification-Request, event-X, and audit-Request) status _ inquiry), the MME sends a Notification Request indicating that the event of the indicated type is in an active state, thereby requesting to check the state in other network elements such as a subscriber database or an exposure entity. In step S98, the HSS100 does not find the event, and therefore, it responds to the MME in a state where the event has been removed (Notification-Request, event-X, audit-result) so that the MME knows the fact that the event becomes stale or invalid. In step S99, the MME locally removes the event in the MME. At the same time, the HSS100 informs the SCEF 300 of the following: due to the audit, the specified event has been removed, indicating that the request type of event is inconsistent across all network elements. In step S100(Report-Information-Request, event X, and audit-Request remove), the HSS100 transmits a Report-Information Request to the SCEF 300 to remove an event of the Request type if the event exists in the SCEF. In step S101, the SCEF checks whether the audited event exists. If so, it is removed, otherwise, the SCEF confirms only the removal (Report-Information-Answer), event X, and audit result removed) in step S102. In step S103, if the event is removed in the SCEF, the application server is notified that the event is no longer monitored. If the application still requires the event, the application server may initiate a new monitoring. In step S104, the monitoring of the event is stopped in the involved entities, such as the MME, HSS and SCEF and the application server, where the resources needed for the monitoring of the event are released. Thus, there is no inconsistency between the involved entities due to the auditing mechanism.

Fig. 6 shows the case of the auditing mechanism when SCEF 300 loses all data. In step S111 (Configuration-Information-Request, monitor-event X, expiration-time 2019-01-01, and subscribed-audit time 24 hours), a Request for Configuration monitoring is sent from the SCEF 300 to the HSS100, the Request including Information about the monitored event, the expiration time, and the subscribed audit time. In step S112(Insert-Data-Request, monitor-event X, expiration-time 2019-01-01, subscribed-audio-time 24 hours), a Request including the recommended audit time is sent to the MME, wherein the MME confirms the reception in step S113 (Insert-Data-Answer, event-configured, accepted-audio-time 24 hours). In step S114(Configuration-Information-Answer, event-configured, and accepted-audio-time of 24 hours), the Configuration with the audit time is confirmed to the SCEF. In step S115, the SCEF fails, as discussed above in steps S41 and S42 in connection with fig. 2. In step S116, it is detected that an event has not occurred within the instructed auditing time, so that in step S117(Notification-Request, event-X, and audit-Request) status _ inquiry), the MME200 notifies the HSS to accordingly Request the monitored status. 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 (event X), audio-result (audit result) removed), a request is sent to the SCEF 300, the request including a status query whether monitoring of the event should be continued. As described above, since the SCEF has lost all data, it finds no event in step S120. In step S121(Report-Information-Answer, event-X, audit result) it notifies the HSS100 indicating that the event is no longer valid and should be removed. In step S122, the event is removed at the HSS100, and in step S123 (Notification-Answer, event-X, audit result) the Answer is transmitted in response to the request of step S117 that the event should be removed. In step S124, the monitoring of events is removed in the mobile device, MME and HSS so that the network elements are consistent and resources are released in MME200 and HSS 100.

Fig. 7 shows a case where an audit of the entire network should be performed. For example, after a failure in the SCEF, the operator of the network may want to perform an audit in the network. To achieve this, it sends a command to the SCEF in step S131 to check if there are events that have not been active for a defined period of time (such as 24 hours or more). In step S132, the SCEF checks for events that are not active for the indicated period of time (such as 24 hours) after recovery. In step S133 (Configuration-Information-Request), which is an audit Request (status _ inquiry _ ALL _ events) and a pending _ duration (inactive duration) of 24 hours, the SCEF 300 transmits a Configuration Request to trigger an audit in the MME for ALL events whose inactive duration exceeds the indicated duration. In step S134(Configuration-Information-Answer, audio-result (status _ inquiry _ started)), the HSS transmits a response indicating that the audit has started. In step S135 (Insert-Data-Request), audio-Request (audit Request) status _ inquiry _ ALL _ events, and dormant _ duration (24 hours), the HSS100 sends a Request to ALL MMEs to cause them to start auditing events for which there is no traffic activity for the indicated time period. Each MME also indicates that auditing has started in step S136(Insert-Data-Answer, audit result) ═ status _ inquiry _ started). In the embodiment shown in fig. 7, one MME among the plurality of MMEs checks all events that are inactive for more than 24 hours, and in step S138(Notification-Request, event-X, audit-Request) status _ inquiry, when no traffic for monitoring the event is detected, the HSS100 is notified accordingly. In step S139(Report-Information-Request, event-X, and audit-Request) status _ inquiry), a Request for requesting a status inquiry is transmitted to the SCEF 300. In step S140, if an event is found in the SCEF, it replies with a successful answer. Otherwise, if the event does not exist in the SCEF, it informs the HSS100 that the event should be removed. This Information is transmitted in step S141(Report-Information-Answer, event X, and audit result removed), where it is forwarded to the MME in step S142(Notification-Answer, audit result removed). In step S143, the monitoring of the indication event is ended and the resource is released.

In fig. 8, a solution to the problem discussed above in connection with fig. 3 (where the AMF has a connection problem) is shown. In step S151 (numdm _ EventExposure _ audio, monitor-event X, expiry-time 2019-01-01, subscribed-Audit time 24 hours), the exposed entity subscribes to monitoring of the event in the UDM, and the message in step S151 includes the monitored event, the expiry time, and the recommended Audit time, and thus includes the indicated time period. In steps S152(Namf _ EventExposure _ audio, monitor-event (monitoring event) ═ X, expiration-time (expiration time) ═ 2019-01-01, suggested-Audit time (proposed Audit time) > 24 hours) and S153(Namf _ EventExposure _ audio, event-configured, accepted-audio-time (accepted Audit time) — 24 hours), information on the Audit is exchanged between the UDM and the AMF, and in step S154(Numd _ EventExposure _ audio, event-configured, accepted-audio-time (event configured), accepted-audio-time (accepted Audit time) — 24 hours) is transmitted in response to step S151 including the Audit accepted. In step S155, the event is removed, as discussed above in connection with steps S61 to S68 of fig. 3, but in view of the connection problem of the continued monitoring of the AMF, and since the event does not occur within a defined period of time, the Audit is started in the AMF in step S156, so a status query for the monitoring of the event is sent to the UDM in step S157 (nutdm _ EventExposure _ audio, event-X, Audit request (status _ inquiry)), and there is a response in step S158 (nutdm _ EventExposure _ audioresponse, event-X, Audit result (removed)) that the monitoring of the event has been removed. In step S159, the monitoring of the event is removed in the AMF, while the network exposure function or entity is notified of the fact that the event has been removed because of the audit. In step S160(Nnef _ EventExposure _ audio, event X, and audio-request remove), a request is sent 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. If there is an event in the NEF, it is removed at this point. Otherwise, the NEF confirms only the removal in step S162(Nnef _ EventExposure _ audioresponse, event ═ X, audio-result ═ removed). In step S163, the exposure entity notifies the application server if the event has been removed in the previous step, and the application server should initiate a new request for monitoring the event, if necessary. In step S164, the monitoring of the event is ended, and the resources are released in the AMF, UDM, NEF, and application server.

Fig. 9 shows the situation in a 5G network when a failure occurs at the NEF. Steps S171 to S174 correspond to steps S151 to S154. In step S175, the exposed entity fails, as discussed above in connection with fig. 4 in connection with steps S81 and S82. Thus, all data is lost, including the identification of the application server requesting the monitoring event. In step S176, the AMF determines that an event has not occurred within the identified time period, and transmits an Audit request to the UDM in step S177 (numdm _ evendexamportaudit, event-X, audio-request ═ status _ inquiry). In step S178, the requested event is found in the UDM, and the UDM audits the event in the network exposure function by sending an Audit request with a status query in step S179(Nnef _ evendexposure _ audio, event-X, audio-request). In step S180, no event is found in the NEF, so that a response requesting removal of the event is transmitted in step S181(Nnef _ EventExposure _ audioresponse, event-X, audio-result (audit result) ═ removed). In step S182, the event is removed from the UDM, and the AMF is notified accordingly in step S183 (numdm _ EventExposure _ audioresponse, event-X (event X), audit result (removed)), so that the event is removed in step S184, and the network is made consistent by releasing the resource in the AMF and the UDM.

In connection with fig. 10, a situation similar to the situation shown in connection with fig. 7 is shown for a 5G network. In step S191, the network exposure function NEF recovers from the failure, and in step S192, NEF desires to check for more permanent events, such as events that have not been active within the last 24 hours after the recovery of step S191. In step S193 (nutm _ evendexposeusure _ audio, audio-request (status _ inquiry _ ALL _ events), and dormant _ duration (24 hours), the UDM is required to perform auditing for ALL events that are inactive for more than a defined period of time. In step S194 (nutm _ EventExposure _ audioresponse, audio-result (audit result) ═ status _ inquiry _ started), a response is transmitted to the NEF. In step S195(Namf _ EventExposure _ audio, audio-request (Audit request) ═ status _ inquiry _ ALL _ events, and domain _ duration ═ 24 hours), the UDM sends an Audit request to the AMF, and sends back a response in step S196(Namf _ EventExposure _ audio, audio-results (Audit result): status _ inquiry _ started). In step S197, the AMF checks all events that are inactive for more than a defined period of time. In step S198 (nutm _ evendexamplesoudet _ audio, event-X (event X), and audio-request (Audit request) ═ status _ inquiry), the Audit result of an event is sent to the UDM, which sends the information to the NEF in step S199(Nnef _ evendexamplesoudet _ audio, event-X (event X), and audio-request (Audit request) ═ status _ inquiry). In step 200, if an event is found in the NEF, it replies with a successful answer. Otherwise, if there is no event in NEF, it notifies UDM that the event should be removed. Based on the assumption that there is no event in the NEF, this is shown in step S201(Nnef _ EventExposure _ audioresponse, event ═ X, audio-result ═ removed). This information is forwarded to the AMF in step S202 (nutm _ EventExposure _ audioresponse, audio-result (removed)), and in step S203, the monitoring of the event is ended and the result is released in the UDM and the AMF.

As for the Diameter protocol in the 4G case, the following is noted:

a) a new IE (information element, in the form of AVP) may be provided in s6a/s6t to indicate the expected audit time

b) A new IE (in the form of an AVP) may be provided in s6a/s6t to indicate the accepted audit time (value no higher than the expected audit time)

c) A new IE (in the form of an AVP) may be provided in s6a/s6t to indicate audit actions (e.g., status _ inquiries _ ALL _ events, remove _ event)

d) A new IE (in the form of an AVP) may be provided in s6a/s6t to indicate the result of the audit (e.g., event _ removed, event _ active)

With respect to the service basic interface protocol for a 5G network, a service operation network may be required for auditing, in more detail, new service operations (e.g., auditing) of the Namf _ EventExposure, nff _ EventExposure, Nudm _ EventExposure services are required, or existing service operations may be reused (e.g., notified).

Fig. 11 outlines some of the main steps performed at a tracking entity such as the HSS or UDM 100. In step S210, the tracking entity tracking which MME the mobile device is connected to receives the request with an indication for the audit, as discussed above in connection with step S91 of fig. 5, step S111 of fig. 6, step S151 of fig. 8 or step S171 of fig. 9. In step S211, the received request is sent to the MME or AMF, which includes an indication for the audit and an indicated time period. The tracking entity then receives a notification from the MME that no event has been detected within the indicated time period in step S212, and determines whether monitoring should continue based on the information in step S213.

Some of the main steps performed at the access and connectivity management entity, such as the MME or AMF, are discussed in more detail in connection with fig. 12. In step S221, a request to monitor events at the mobile device is received, as discussed above in connection with steps S92, S112, S152, or S172. Monitoring of whether an event occurred is performed for the mobile device in step S222 and it is determined that the event did not occur during the indicated time period, such that a notification is sent to the tracking entity to start the audit in step S223. The notification indicates that an event has not been detected and that auditing should begin in other entities.

Fig. 13 shows some of the main steps performed at an exposed entity such as the SCEF or NEF discussed above. In step S231, a request for monitoring an event is received from an application server, and in step S232, monitoring of the event is configured in the network by an audit of the monitoring by which validity of the monitoring should be checked when the event does not occur within a time period. In step S233, a request is sent to the tracking entity, wherein the request comprises an indication for the audit and an indicated time period.

Fig. 14 shows a schematic architecture diagram of a trace entity that may perform the above-described steps in which the trace entity 100 participates. The entity 100 comprises an interface or input/output provided for sending user data or control messages to other entities as described above or configured to receive user data or control messages from other entities as described above. The interface may receive a request to monitor for an event with an audit and may send the received request to the MME. Entity 100 also includes a processing unit 120 that is responsible for tracking the operation of entity 100. Processing unit 120 includes one or more processors and may execute instructions stored in memory 130, which may include read-only memory, random access memory, mass storage, a hard disk, and the like. The memory may comprise suitable program code to be executed by the processing unit 120 to implement the above-described functions of tracking entity participation.

Fig. 15 shows another schematic architecture diagram of a tracking entity (400), the tracking entity (400) comprising a first module (410), the first module (410) being configured to receive a request for monitoring an event, the request having an indication for an audit. The entity 400 comprises a second module 420, the second module 420 configured to send the received request to the MME, the request comprising an indication for the audit. A module 430 is provided, which module 430 is configured to receive a notification from the MME that no event has been detected within the indicated time period, and a module 440 is provided, which module 440 is configured to determine whether monitoring of events should continue based on information provided in the tracking unit 400.

Fig. 16 shows a schematic architecture diagram 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, the interface or input/output 210 being configured to send user data or control messages and to receive user data or control messages. The entity 200 further comprises a processing unit 220 which is responsible for the operation of the access and connectivity management entities. Processing unit 220 includes one or more processors and may execute instructions stored on memory 230, which may include read-only memory, random access memory, mass storage, a hard disk, and the like. The memory also comprises suitable program code to be executed by the processing unit 220 to implement the above-described functions in which the entity 200 participates.

Fig. 17 shows another schematic architecture diagram of an access and connectivity management entity 500 configured to monitor access and connections of a mobile device, wherein the entity 500 comprises a first module 510, the first module 510 being configured to receive a request for monitoring an event, the request comprising an indication for an audit. A module 520 is provided, the module 520 configured to monitor events at a mobile device. A module 530 is provided for sending a notification to the tracking entity indicating that no event was detected during the indicated time period and that auditing should be initiated in other entities.

Fig. 18 shows a schematic architecture diagram of an exposed entity configured to expose services provided over a mobile communication network, wherein the exposed entity comprises an input/output or interface 310, the input/output or interface 310 being configured to transmit user data or control messages and being configured to receive user data or control messages. The exposure entity 300 further comprises a processing unit 320, which is responsible for the operation of the entity 300. Processing unit 320 includes one or more processors and may execute instructions stored on memory 330, which may include read only memory, random access memory, mass storage, a hard disk, and the like. The memory may also include suitable program code to be executed by the processing unit 320 to implement the above-described functions of exposing entities to participation.

Fig. 19 shows another schematic architecture diagram of an exposure entity comprising a first module 610, the first module 610 being configured to receive a request for monitoring of events, a second module 620 being provided, the second module 620 being configured to effect monitoring by auditing, as described above. A third module 630 is provided, the third module 630 configured to send a request with an indication for auditing to the MME for monitoring events.

In terms of events, there are different options. One example of an event is reachability of a UE. For example, IMSI _1 is an event (e.g., UE reachability state) configured by SCEF _ 1. In this case, SCEF _1 creates a Reference Id (Reference-Id) to uniquely identify such an event in SCEF _ 1. This makes the event unique throughout the network, since by cascading SCEF _1 with Reference-Id, the result is unique.

IMSI_1＝214031111111111

SCEF-Reference-Id＝123456789

Event type-USE reachability

In HSS/UDM and AMF/MME, events will be audited by simply indicating SCEF _1:123456789

In another example, the event is the location status of the UE: where IMSI _2 is an event (e.g., UE location status) configured by SCEF _ 2. In this case, SCEF _2 creates a Reference-Id to uniquely identify such an event in SCEF _ 2. This makes the event unique throughout the network, since by cascading SCEF _2 with Reference-Id, the result is unique.

IMSI_2＝214032222222222

Reference-Id＝987654321

Event type-UE location status

In HSS/UDM and AMF/MME, events will be audited by simply indicating SCEF _2:987654321

From the above, some general conclusions can be drawn:

in the case of the tracking entity, the tracking entity determines that no event has been detected within the indicated time period in response to the notification received from the access and connectivity management entity, and the tracking entity determines whether monitoring for the event should continue. This can be achieved by tracking entities in conjunction with exposed entities (e.g., NEF). If the NEF does not have an event, the tracking entity also removes the event in the access and connection entities. Briefly: the determination is made based on a local check and also on an external check (in the NEF).

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

Further, an exposure entity configured to expose a service provided in the mobile communication network may be notified that monitoring of the event has been removed in response to the audit.

Further, information available in the tracking entity may indicate that monitoring of the event should continue. If this is the case, a report request is sent to the exposure entity, wherein it is requested whether the monitoring of the event should be continued.

Here, a response to the report request may be received from the exposure entity indicating that monitoring for the event should not continue. The information available in the tracking unit may then be modified accordingly so that monitoring of the event is no longer continued.

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

Further, the tracking unit may determine that an audit of all events to be monitored should be performed on all events for which no corresponding event was detected within the indicated time period (e.g. based on an operator request, e.g. a manual command or request may be initiated in the NEF or UDM to initiate such polling for inactive events). The tracking entity then sends a request to a plurality of access and connectivity management entities requesting each access and connectivity management entity to start an audit of the monitoring of all events for which no corresponding event was detected within the indicated time period. Further, a notification 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 was not detected. Then in view of the fact that one of the corresponding events was not detected, the exposing entity is queried as follows: whether the event should still be monitored.

The step of determining that audits for all events should be performed may be based on a request received from an exposing entity configured to expose services provided by the mobile communication network, according to which request the auditing for all events should be performed is requested from the tracking entity. As an alternative, the step of determining that an audit for all events should be performed may also be triggered based on predefined trigger events provided in the tracking unit (e.g. priority events set by the operator of the mobile communication network).

In terms of operation of the access and connectivity management entity 200, such as an MME or AMF, the access and connectivity management entity sends a notification to the tracking entity 100 indicating that an audit should be started. The access and connectivity management entity 200 may receive a response to the notification, wherein the response indicates that monitoring for the event should not be continued, such that monitoring for the event is removed and resources for monitoring for the event are released in response to the received response.

With respect to the exposing entity 300, the exposing entity may receive a report from the tracking entity indicating that monitoring of events at the tracking entity has been removed in response to the audit. The exposing entity may further check whether the monitoring of the event is active in the exposing entity, and when the monitoring of the event is active, the monitoring of the event may be stopped, and at least one of the tracking entity and the application server may be notified of the stopping of the monitoring.

The exposing entity may also receive a request to track the entity, the request to check whether the monitoring of the event is active in the exposing entity. The exposing entity may check whether the monitoring of the event is active in the exposing entity and send a response to the tracing entity requesting the tracing entity to remove the monitoring of the event at the tracing entity when the monitoring is not active in the exposing entity.

Further, the exposure entity may determine that an audit should be performed on all events to be monitored for which no corresponding event was detected within the indicated time period. Further, the request is forwarded to the tracking entity to audit all events to be monitored for which no corresponding event was detected within the indicated time period. A response to the request may be received from the tracking entity indicating that monitoring for an event not detected within the indicated time period is active and checking whether the event is found in the exposing entity. When the event is not found, the tracking entity is requested to remove the monitoring of the event.

The fact that an audit should be performed for all events may be due to a request (e.g., from an operator as discussed in connection with fig. 7) that an audit should be performed. Further, it may be determined that the auditing should be performed based on predefined trigger events provided in the exposure entity, which when a trigger event occurs (e.g., also set by the operator) initiates auditing of all events.

The above-described application provides a mechanism to ensure consistency of ongoing monitoring of events on different 4G or 5G functional entities or network functions, in particular long-term monitoring of events for long-term devices with long battery life, low mobility and low activity.