Methods and apparatuses for event reporting by a telecommunications network

Abstract

According to an aspect, there is provided a method (1500) of operation by a network node The method comprises: sending (1502) a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receiving (1504) a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpreting (1506) a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status.

Description

[0001] METHODS AND APPARATUSES FOR EVENT REPORTING BY A TELECOMMUNICATIONS NETWORK TECHNICAL FIELD Disclosed methods and apparatuses relate to event reporting by a telecommunications network. BACKGROUND In the context of cellular networks, event exposure plays a key role in the interaction between applications and the core network functions. For example, in the context of Fifth Generation (5G) specifications promulgated by the Third Generation Partnership Project (3GPP), a Network Exposure Function (NEF) exposes the capabilities of the 3GPP network to third-party applications and translates such requests to the network. Event reporting serves several multiple purposes, such as real-time monitoring and analytics. In this context, event reporting allows service providers and third-party applications to monitor network status and performance in real time. This includes things like user location, service consumption, Quality of Service (QoS), etc. Event reporting also supports policy control and charging. In this context, event reporting assists in real-time policy decisions by providing information on network usage and other events. This can impact charging mechanisms and enable more dynamic and flexible service offerings. Further, event reporting can provide data necessary for the management and orchestration of network slices, ensuring that different virtual networks are appropriately allocated resources according to their needs. Still further, event reporting can be used to ensure that only authorized third-party applications can access network functions, and event reporting can be part of tracking and managing these permissions, as well as auditing and logging for security purposes. Event reporting also facilitates diagnosis of network problems, service optimization for improved user experiences, integration with third-party services, and compliance with regulatory requirements. SUMMARY Disclosed methods and apparatuses address one or more problems associated with event reporting, such as preventing ambiguous event reporting and avoiding correspondingly erroneous interpretations of event reports. One problem addressed is the behavior of the nodes involved in event reporting in the context of immediate reporting. With immediate reporting, a node subscribing to event reporting requests that current event status be returned in the subscription response. However, there are multiple reasons that current event status may be omitted from the subscription response, and disclosed techniques avoid ambiguity at the requesting node by adding information to a subscription response. One embodiment comprises a method of operation by a network node. The method includes: sending a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receiving a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpreting a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status. In such embodiments, the network node may be understood as the requesting node, in that it originates the subscription request. An example requesting node includes communications circuitry and processing circuitry operatively associated with the communications circuitry—i.e., arranged to use the communications circuitry to exchange messages or other signaling with other entities, such as other network nodes of the same type or a different type. In an example embodiment of a requesting node, its processing circuitry is configured to: send a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receive a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpret a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status. Another embodiment comprises a method of operation by a network node of a telecommunications network, where the method includes: receiving a subscription request, requesting event notifications for a specified event in the telecommunications network and requesting immediate reporting of current event status; and sending a subscription response in reply to the subscription request, the subscription response omitting the current event status. The method further includes the network node including an indication of unavailability of the current event status in the subscription response, responsive to determining that the current event status is unavailable. In such embodiments, the network node may be understood as the responding node, in that it responds the subscription request. An example responding node includes communications circuitry and processing circuitry operatively associated with the communications circuitry—i.e., arranged to use the communications circuitry to exchange messages or other signaling with other entities, such as other network nodes of the same type or a different type. In an example embodiment of a responding node, its processing circuitry is configured to: receive a subscription request, requesting event notifications for a specified event in the telecommunications network and requesting immediate reporting of current event status; and send a subscription response in reply to the subscription request, the subscription response omitting the current event status. For sending the subscription response, the processing circuitry is configured to include an indication of unavailability of the current event status in the subscription response, responsive to determining that the current event status is unavailable. In at least one embodiment, the techniques are extended to subscription requests and corresponding subscription responses that involve multiple specified events. In at least one such embodiment, the responding node is configured to include unavailability indications on a per specified event basis, such that unavailability can be indicated on an individual basis for each specified event included in the subscription request. The indications may be explicit, e.g., such as set or cleared flags or other Information Elements (IEs) contained in the subscription response. Alternatively, the indications may be implicit, such as where the responding node interprets the absence of current event status in the subscription response for a given one among two or more specified events as an implicit indication of unavailability of the current event status for the given event, so long as the subscription response includes current event status for one or more others of the specified events. In at least one embodiment, with respect to a subscription response that omits requested current event status because immediate reporting of current event status is not supported, the responding node is configured to include an indication of non-support in the subscription response. Correspondingly, the receiving node is configured to recognize the inclusion of such information and to interpret a first event notification received after the subscription response as indicating the requested current event status rather than as indicating a new event detection. Of course, the present invention is not limited to the above features and advantages. Indeed, those skilled in the art will recognize additional features and advantages upon reading the following detailed description, and upon viewing the accompanying drawings. BRIEF SUMMARY OF THE DRAWINGS Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings, in which: Fig.1 is a signalling diagram for a situation where a current state is available and Immediate Event Report in Subscription Creation Response for Subscriptions (IERSR) is supported; Fig.2 is a signalling diagram for a situation where a current state is available but IERSR is not supported between an Access and Mobility Management Function (AMF) & a Unified Data Management (UDM); Fig.3(a) is a signalling diagram for a “Problem A”, where a current state is NOT available regardless of IERSR support; Fig.3(b) is a signalling diagram for “Problem A”, where a current state is NOT available and the event is detected by a UDM; Fig.3(c) is a signalling diagram for “Problem A”, where a current state is NOT available, the event is detected by an AMF (subscription direct from a NEF); Fig.4(a) is a signalling diagram for a situation where a current state is available and Event Reports in Response (ERIR) is supported (event detected by a Mobility Management Entity (MME)); Fig.4(b) is a signalling diagram for a situation where a current state is available and ERIR is supported (event detected by a Home Subscriber Server (HSS)); Fig.5(a) is a signalling diagram for a “Problem B1” where current state is available but ERIR is not supported; Fig.5(b) is a signalling diagram for “Problem B1” where current state is available but ERIR is not supported (the event is detected by HSS); Fig.6(a) is a signalling diagram for a “Problem B2” where the current state is NOT available regardless of ERIR support; Fig.6(b) is a signalling diagram for “Problem B2” where the current state is NOT available regardless of ERIR support; Fig.7(a) is a signalling diagram illustrating a solution to “Problem A” with a “current state not available” indication; Fig.7(b) is a signalling diagram illustrating a solution to “Problem A” with a “current state not available” indication where the event is detected by the UDM; Fig.7(c) is a signalling diagram illustrating a solution to “Problem A” with a “current state not available” indication where the event is detected by the AMF (direct subscription); Fig.8(a) is a signalling diagram illustrating a solution to “Problem B1” where a HSS sends “current state” on behalf of the MME; Fig.8(b) is a signalling diagram illustrating another solution to “Problem B1” where the HSS sends “current state” on behalf of the MME (with the event detected by HSS); Fig.9(a) is a signalling diagram illustrating a solution to “Problem B2” where a “current state not available” indication is sent; Fig.9(b) is a signalling diagram illustrating another solution to “Problem B2” where the HSS sends “current state not available” (with the event detected by HSS); Fig.10 is a signalling diagram illustrating a general example of the techniques described herein; Fig.11 is a block diagram of a telecommunications network according to exemplary embodiments; Fig.12 is a block diagram illustrating components of a network node according to an exemplary arrangement; Fig.13 is a block diagram illustrating an exemplary implementation of processing circuitry components of a network node; Fig.14 is a block diagram illustrating another embodiment of a network node according to an exemplary arrangement; Fig.15 is a flow chart illustrating an exemplary method of operation of a network node; Fig.16 is a flow chart illustrating another exemplary method of operation of a network node; Fig.17 shows an Event Occurrence Notification procedure; Fig.18 shows a procedure for Configuration of Monitoring Events in MME; Fig.19 shows a procedure in which a NF service consumer subscribes to notifications; and Fig.20 shows an Event Occurrence Notification procedure. DETAILED DESCRIPTION The AF (Application Function) may subscribe to the NEF (Network Exposure Function) to request being notified for certain events. In this subscription request it is possible to request “immediate reporting” (including “immediateRep” flag in MonitoringEventSubscription data type), included as part of the enhancements to northbound Application Programming Interface (API) (NEF to AF) in Rel-18 (feature enNB1), see 3GPP Technical Standard (TS) 29.122 version 18.1.0: “T8 reference point for Northbound APIs”. Immediate reporting requires that when the subscription request is received by the “notification sender” if there is any current status for the requested notification, the value of such a current status shall be provided embedded in the subscription response. E.g. if immediate reporting is requested for AOI (Area Of Interest) event, then if Access and Mobility Management Function (AMF) already has a value for this AOI (e.g. IN, OUT), then this value shall be included in the subscription response. In case the immediate reporting is required via an intermediate node, Immediate Event Report in Subscription Creation Response for Subscriptions (IERSR) feature is required to be supported by both intermediate node and the “notification sender” to provide the immediate reporting (in the subs response). See the extract below from clause 6.2.8 of 3GPP TS 29.518 version 18.1.0: “Access and Mobility Management Services”: 5 IERSR O Immediate Event Report in Subscription Creation Response for Subscriptions on behalf of another NF An NF consumer (e.g., UDM) supporting this feature shall be able to handle the immediate event reports in the Subscription Creation Response for subscriptions on behalf of another NF, as specified in clause 5.3.2.2.2. In addition, see the below extract from clause 6.4.8 of 3GPP TS 29.503 version 18.1.0: “Unified Data Management Services”: 4 IERSR Immediate Event Report in Subscription Creation Response for events detected by another NF The UDM and the NF consumer (e.g., NEF) supporting this feature shall be able to handle the immediate event reports in the Subscription Creation Response for events with direct reporting by another NF (e.g. AMF, HSS), as specified in clause 5.5.2.2. There is a different use case, but with some similarities: the Unified Data Management (UDM) receives a Subscription request that applies to Evolved Packet Core (EPC) with the indication that “immediate reporting” is requested, see clause 5.5.2.2.2 of 3GPP TS 29.503 version 18.1.0: “Unified Data Management Services”: If the NF Service Consumer has included the immediateFlag with value as "true" in the event subscription for an individual UE, the indication on whether the subscription applies also to EPC is included and set to "true" in the request and the NF service consumer has indicated supporting of "IERSR" feature (see clause 6.4.8), the UDM shall indicate the support of "ERIR" feature when subscribing to the event on the HSS (see clause 6.4.8 of 3GPP TS 29.563

[0062] ). UDM shall include the current status of the event in EPC if received from the HSS in subscription creation response. In this case, the UDM sends the Subscription request to Mobility Management Entity (MME) via Home Subscriber Server (HSS), and the support of Event Reports in Response (ERIR) feature is relevant as indicated above. See in 3GPP TS 29.563 version 18.1.0: “Home Subscriber Server (HSS) services for interworking with Unified Data Management (UDM)”: 1 ERIR Event Reports in Response An NF consumer supporting this feature shall be able to handle the event reports within the Event Subscription Create Response, as specified in clause 5.5.2.2.2. At least two scenarios are of interest in the context of the disclosed techniques: a) Subscription via an intermediate Network Function (NF) (without Fourth Generation (4G) / 5G interworking) b) Subscription to MME via UDM+HSS (4G / 5G interworking) It should be noted that a Session Management Function (SMF) can take the place of the AMF in the diagrams in the context of this disclosure. A) Subscription via an intermediate NF (without 4G / 5G interworking) For example, NEF subscribes via UDM to AMF, and then AMF notifies directly to NEF. Fig.1 is a signalling diagram for a situation where a current state is available and IERSR is supported. See the following description of Fig.1, for an event detected by AMF. In Fig.1: Step 0: Pre-requisites: IERSR feature is supported end-to-end. Step 1: EE (Event Exposure) Subscription request is sent with “immediate reporting” flag. Step 2: EE Subscription request is sent to UDM. Step 3: EE Subscription request is sent to AMF. Step 4: Event current state is available, in this example, it is equal to “X”. Since IERSR is supported by both AMF and UDM, then “current state” shall be included in the Subs response. Step 5,6,7: EE Subscription response is sent including “current state”. Step 8: received event information (“X”) is correctly interpreted by the Application Function (AF) as “current state”. See the further description below for Fig.2, which is a signalling diagram for a situation where a current state is available, when IERSR is not supported between UDM and AMF. In Fig.2: Step 0: Pre-requisites: IERSR feature is not supported by both AMF & UDM. Step 1, 2, 3: similar to Fig.1. Step 4: Since IERSR is not supported by both AMF & UDM, then “current state” is not included in the Subs response. However, a notification shall be sent to provide this value (step 9). Step 5, 6, 7: similar to Fig.1 but the event information is not included. Step 8: since the Subs response is received without Event information, the AF expects “current state” to be received in a subsequent notification, since the request sent by the AF requested “immediate reporting”. Step 9 and 10: AMF sends available “current state” in a subsequent notification. Step 11: event information received is correctly interpreted as “current state”. However, some problems are identified, which can be seen in Fig.3(a). Fig.3(a) is a signalling diagram illustrating “Problem A”, where a current state is NOT available regardless IERSR support. In Fig.3(a): Step 0: There are no pre-requisites, IERSR may or not be supported. Step 1, 2, 3: similar to Fig.1. Step 4: Regardless support of IERSR, the key to this step is that “current state” is not available. It should be noted that “current state” is not available in AMF e.g. in case of User Equipment (UE) mobility, when there is not UE context transfer between serving nodes (e.g. UE context is not supported between Public Land Mobile Networks (PLMNs) by different vendors); or some events like “PDN [Packet Data Network] connectivity status” (MME) or “Loss of connectivity” (AMF) does not necessarily have a “current state” Steps 5,6,7: similar to Fig.1. Step 8: PROBLEM-A1: when the AF does not receive Event information in the Subs response, it assumes the “current state” will be provided in a subsequent notification, however, in this case, the current state is not available, then AF may wait for a long time, in fact until an event is detected for that subscription. Step 9, 10: When an Event is detected by AMF (e.g. Event=Y), a notification is sent. Step 11: PROBLEM-A2: AF assumes the value received corresponds to the “current state” that is waiting for, not to a new detected event. E.g. it may assume a UE was “IN” when in fact it has just been moved “IN”, this will cause errors. A similar problem occurs when the event is detected by UDM. In this case, since there is not an intermediate NF, the support of IERSR is not relevant. See the description below of Fig.3(b), which is another signalling diagram for “Problem A” where current state is NOT available, and the event is detected by UDM. In Fig.3(b): Steps 1, 2: similar to Fig.3(a). Step 3: since current state is not available, then Subs response is sent without event information. Step 4,5: similar to steps 6,7 in Fig.3(a). Steps 6 to 9: similar to steps 8 to 11 in Fig.3(a). In addition, a similar problem arises for an event detected by AMF, when the subscription is done directly from NEF to AMF, see the description below of Fig.3(c), which is another signalling diagram for “Problem A” where current state is NOT available, the event is detected by AMF (subscription direct from NEF). In Fig.3(c): Similar to Fig.3(b), where AMF takes the place of UDM. B) Subscription to MME via UDM+HSS (4G / 5G interworking) See the description of Fig.4(a), which is a signalling diagram for a problem where current state is available and ERIR is supported (event detected by MME), for an event detected by MME. In Fig.4(a): Step 0: Pre-requisites: it is supported end-to-end the functionality to provide event notification in the subscription response. This requires support of the IERSR feature in Service Capabilities Exposure Function (SCEF)+NEF and UDM, while UDM and HSS shall support ERIR feature. Step 1,2,3: EE subscription request is sent with immediate report. The SCEF+NEF sends the request to UDM with the indication that the request is applicable to EPC. Then UDM shall indicate support of ERIR to HSS. Step 4: HSS send the EE subscription to MME, using Insert Subscription Data Request (IDR) diameter request. Step 5: As long as “current state” is available, this “current state” shall be provided in the response. Step 6: since “current state” is available, the event information (“current state”) is included in the Insert Subscription Data Answer (IDA) diameter request. Step 7: Since ERIR is supported (it indicates the network has the capability to provide the event information in the response to AF), then the “current state” is included in the response. Step 8,9,10: EE subscription response including event information “current state” is sent. Step 11: AF correctly interprets the event information received is the “current state”. In case the event is detected by HSS, the following description of Fig.4(b) applies. Fig.4(b) is a signalling diagram for a problem where current state is available and ERIR is supported (event detected by HSS). In Fig.4(b): Steps 0 to 3: similar to Fig.4(a). Steps 4 to 8. Similar to steps 7 to 11 in Fig.4(a). A problem is identified in Fig.5(a), which is a signalling diagram for a “Problem B1” where current state is available but ERIR is not supported. In Fig.5(a): Step 0: Pre-requisites: ERIR feature is not supported by both UDM&HSS Steps 1 to 6: similar to Fig.4(a). Step 7: Since ERIR is not supported by both UDM & HSS, then “current state” is not included in the Subs response. Step 8,9,10: similar to Fig.4(a) but the event information is not included. Step 11: when the Subs resp is received without event information, the AF assumes a subsequent notification will provide the “current state”. Step 12: PROBLEM B1: the “current state” is not received. It is not clearly described in 3GPP how the “current state” can be provided in this case. A similar problem is identified for the case the event is detected by HSS, as described below with reference to Fig.5(b), which is a signalling diagram showing “Problem B1” where current state is available but ERIR is not supported (the event is detected by HSS). In Fig.5(b): Steps 0 to 3: similar to Fig.5(a). Steps 4 to 9. Similar to steps 7 to 12 in Fig.5(a). Another problem is identified, see the description below for Fig.6(a), which is a signalling diagram for a “Problem B2” where the current state is NOT available regardless of ERIR support, for an event detected by MME. In Fig.6(a): Step 0: There are not pre-requisites. ERIR support is not relevant for this use case. Steps 1 to 4: similar to Fig.5(a). Step 5: “current state” is not available. Step 6: Regardless support of ERIR, since “current state” is not available, it can’t be included in the subscription response. Step 8,9,10: similar to Fig.5(a). Step 11: PROBLEM B2: the AF when the subscription response is received without event information, being “immediate reporting” requested, it will assume a subsequent notification will provide “current state”, but “current state” is not available. Step 12, 13: When an Event is detected by MME (e.g. Event=Y), a notification is sent. Step 14: PROBLEM-B2: AF assumes the value received corresponds to the “current state” that is waiting for, not to a new detected event. E.g. it may assume a UE was “IN” when in fact it has just been moved “IN”, this will cause errors. A similar problem is identified for the case the event is detected by HSS, as described below for Fig.6(b), which is a signalling diagram for “Problem B2” where the current state is NOT available regardless of ERIR support. In Fig.6(a): Steps 0 to 3: similar to Fig.6(a). Step 4: “current state” for the event detected in HSS is not available. Steps 5 to 9. Similar to steps 7 to 11 in Fig.6(a). Step 10,11: According to clause 5.6.2 of 3GPP TS 23.632 version 18.1.0: “User data interworking, coexistence and migration”, see extract below, HSS sends Notification to UDM, and this one sends the notification to SCEF+NEF. clause 5.6.2 8. The monitoring event is reported to the SCEF+NEF. The MME notifies the event as defined in 3GPP TS 23.682

[0016] by using the SCEF notification address provided by the HSS in step 4, if applicable. If the monitoring event is detected at the HSS or reported by the MME to the HSS, the HSS notifies the monitoring event to UDM using the Nhss_EE_Notify service operation. The UDM then notifies NEF using the Nudm_EE_Notify service operation. Steps 12,13. Similar to steps 13, 14 in Fig.6(a). Two different scenarios are areas of focus in this disclosure: ^ Subscription via an intermediate NF (without 4G / 5G interworking) – this includes the case where the event is detected by the UDM or the AMF. Note that the case where the subscription is direct to the AMF is also included here, since the issue is similar. ^ Subscription to the MME via the UDM+HSS (4G / 5G interworking) – this includes the case where the event is detected by the MME as well as the case when the event is detected by the HSS. The techniques describe herein include the following, with respect to example embodiments: ^ The AMF / SMF or HSS add a new indication in the EE subscription response when “immediate reporting” is requested, but the “current state” is not available. It should be noted that the “current state” is not available in AMF, for example in case of UE mobility or when there is no UE context transfer between serving nodes (e.g. UE context is not supported between PLMNs by different vendors); also some events like “PDN connectivity status” (MME) or “Loss of connectivity” (AMF) do not necessarily have a “current state”. ^ In addition, for scenario b): when there is “current state” available and provided by the MME, but the HSS is unable to provide this information in the EE Subs response, the HSS will send a subsequent Notification including this “current state”. The same applies when the HSS detects an occurrence of the event. The disclosed techniques address one or more of the problems noted earlier herein. A proposal according to one embodiment is a mechanism to inform a requesting node (e.g., an AF) when “current state” is not available, which is crucial for application logic. In addition, for a specific use case, it allows that the “current state” is provided to the AF when it otherwise would have been lost. One or more of the following advantages can flow from the disclosed techniques. For example, based on the new indication(s) received, an AF can know that “current state” is not available. This can allow the AF to not wait for a subsequent notification that will never be received. And in addition, this provides a valid information for its application logic, e.g. for AOI event, it is known that there is not any information about the event, therefore if a new AOI event is received, e.g. with “IN”, it will be interpreted as the UE has just entered the AOI, then the application will behave accordingly (e.g. showing some ads). In addition, for scenario b): when there is “current state” available and provided by the MME, but the HSS is unable to provide this information in the EE Subs response (or when the event is detected by the HSS), this solution can prevent the “current state” from being lost (never received by the AF). It can also prevent the AF from waiting (until timer expires, which may be a long time and waste resources) for a subsequent notification that will not indicate the “current state” but rather “event detected”. Absent the proposed solution(s), missing a “current state” will interfere in the application logic. For example, a user, also referred to as a User Equipment or UE, can be “IN” a particular tracking area or other defined area for some time, but the AF would miss that info. The Change Request (CR) documents in the Appendix to this Detailed Description provide additional information for one or more of the solutions described herein. A) Example Solution to Problem A – Subscription via an intermediate NF For the problem described above with respect to Fig.3, the signalling diagram in Fig.7(a) and the description below provide a solution. In particular, Fig.7(a) is a signalling diagram illustrating a solution to “Problem A” with a new indication that “current state not available”. In Fig.7(a): Step 0 to 4: similar to Fig.3. Steps 5,6,7: similar to Fig.3, apart from when the AMF identifies the “current state” is not available, and “immediate reporting” is requested (step 3), then an indication is included in the EE subscription response to inform about the situation, i.e. “current state is not available”. Step 8: based on the new indication received, the AF knows the “current state” is not available. This allows the AF to avoid waiting for a subsequent notification that will never be received. In addition, this provides a valid information for its application logic, e.g. for AOI event, it is known that there is not any information about the event, therefore if a new AOI event is received, e.g. with “IN” it will be interpreted as the UE has just entered the AOI, then the application will behave accordingly (e.g. showing some ads). Step 9,10: similar to Fig.3. Step 11:Due to the new indication received in step 7, the AF knows that the subsequent notification is for an event detected, not for the “current state”. A similar solution is presented in Fig.7(b) for the case where the event is detected by the UDM. Fig.7(b) illustrates a solution to “Problem A” with a “current state not available” indication where the event is detected by the UDM. Fig.7(b) has a similar description to Fig.7(a). A similar solution applies to the case where the event is detected by the AMF, when the subscription is received directly from NEF, as shown in Fig.7(c). Fig.7(c) is a signalling diagram illustrating a solution to “Problem A” with a “current state not available” indication where the event is detected by the AMF (direct subscription). Fig.7(c) has a similar description to Fig.7(a). B) Subscription to MME via UDM+HSS For the problem described with respect to Fig.5 (Problem B1), the signalling diagram in Fig.8(a) and the description below provide a solution. Fig.8(a) is a signalling diagram illustrating a solution to Problem B1 where a HSS sends “current state” on behalf of the MME. In Fig.8(a): Step 0 to 11: similar to Fig.5(a). Step 12:the HSS has received (in step 6) the event information, that is, “current state”. The HSS is unable to send this “current state” in the EE subscription response (in step 8) because ERIR is not supported, so it should be able to send it later with an ad-hoc notification for that purpose. This behavior is not described in current 3GPP specifications. Step 13: Three different solution proposals are described: Variant 1: the HSS sends the “current state” in a Notification (using the Service-Based Interface (SBI)) to NEF directly. Variant 2: the HSS sends the “current state” in a Notification (using Diameter) to the SCEF directly. Variant 3: the HSS sends the “current state” in a Notification (using SBI) to the UDM, and the UDM sends the Notification to the NEF (using SBI). Step 14,15:“current state” is provided to the AF that is waiting for that information. A similar solution to Fig.8(a) applies to the case where the event is detected by HSS, as described below and shown in Fig.8(b). In particular, Fig.8(b) is a signalling diagram illustrating another solution to Problem B1 where the HSS sends “current state” on behalf of the MME (with the event detected by HSS). In Fig.8(b): Steps 0 to 3: similar to Fig.8(a). Steps 4 to 12. Similar to steps 7 to 15 in Fig.8(a). For the problem described above with respect to Fig.6(a), the signalling diagram in Fig.9(a) and the description below provide a solution,, which is similar to the solution to Problem A described above with respect to Fig.7(a). Fig.9(a) is a signalling diagram illustrating a solution to Problem B2 where a “current state not available” indication is sent. In Fig.9(a): Steps 0 to 7: similar to Fig.6(a). Steps 8,9,10: similar to Fig.6(a), apart from when the HSS identifies the “current state” is not available and “immediate reporting” is requested (step 3), then an indication is included in the EE subscription response to inform about the situation, i.e. “current state is not available”. Step 11:based on the “current state is not available” indication received, the AF knows the “current state” is not available. This allows the AF to avoid waiting for a subsequent notification that will never be received. In addition, this provides a valid information for its application logic. Step 12,13: similar to Fig.6(a). Step 14: due to the “current state is not available” indication received in step 10, the AF knows that the subsequent notification is for an event detected, not for the “current state”. A similar solution to Fig.9(a) applies to the case where the event is detected by the HSS, as described below and shown in Fig.9(b). In particular, Fig.9(b) is a signalling diagram illustrating another solution to Problem B2 where the HSS sends “current state not available” (with the event detected by HSS). In Fig.9(b): Steps 0 to 3: similar to Fig.9(a). Step 4: “current state” for the event detected in HSS is not available. Steps 5 to 9. Similar to steps 7 to 11 in Fig.9(a). Step 10,11: According to clause 5.6.2 of 3GPP TS 23.632 version 18.1.0: “User data interworking, coexistence and migration”, see the extract below, the HSS sends a Notification to the UDM, and the UDM sends the notification to SCEF+NEF. Clause 5.6.2: 8. The monitoring event is reported to the SCEF+NEF. The MME notifies the event as defined in 3GPP TS 23.682

[0016] by using the SCEF notification address provided by the HSS in step 4, if applicable. If the monitoring event is detected at the HSS or reported by the MME to the HSS, the HSS notifies the monitoring event to UDM using the Nhss_EE_Notify service operation. The UDM then notifies NEF using the Nudm_EE_Notify service operation. Steps 12,13: Similar to steps 13, 14 in Fig.9(a). Fig.10 illustrates a broad example according to one or more embodiments, where a telecommunications network 10 includes a responding node 12 that receives a subscription request from a requesting node 14. As seen, the responding node 12 may or may not be communicatively coupled to the requesting node 14, e.g., there may be one or more intermediary nodes between them. Further, the responding node 12 is not necessarily the node that maintains event status and performs detection of occurrences of the events specified in the subscription request. In at least one scenario, the responding node 12 communicatively couples to another node that serves as a detecting node 18. The coupling may be direct or may be through one or more intermediary nodes 20. In an example scenario, the requesting node 14 is an Application Function (AF) node and the responding node is an Access and Mobility Management Function (AMF) node, and the two nodes are communicatively coupled via a Network Exposure Function (NEF) node as an intermediary node 16. Regardless of such particulars, the responding node 12 generates a subscription response for reply to the requesting node 14. Here, Fig.10 assumes that the subscription request requests immediate reporting. For example, the subscription request includes an “immediate flag” indicating that current event status should be included in the subscription response. Further, it should be understood that “generation” of the response in Fig.10 means either original, local generation of the response, or means reforming (modifying or revising) a response that was initially generated by another node. In either case, the generation is intelligent with respect to whether current event status is available for inclusion in the response. If current event status is unavailable, the responding node 12 indicates unavailability of the current event status in the subscription response. As noted, indication of unavailability of the current event status may be provided with respect to each specified event identified in the subscription response. As seen in Fig.10, the requesting node 14 advantageously uses the included indication for correct interpretation of a first event notification received subsequent to its reception of the subscription response. Namely, based on knowing that the subscription response omitted current event status because of unavailability of the current event status, the requesting node 14 correctly interprets the subsequent event notification as indicating a new event detection rather than as providing the earlier requested current event status. In at least one embodiment, the responding node is configured to perform response generation based on whether immediate event reporting is supported. In this regard, “support” refers to the relevant capabilities or configurations of the responding node 12 and / or any other node involved in generating or forwarding the subscription response towards the requesting node 14. Consider an example scenario where the subscription request requests immediate reporting but immediate reporting is not supported. Consequently, the subscription response returned to the requesting node 14 omits current event status. However, rather than leaving the requesting node 14 to make (possibly incorrect) assumptions about that omission and about how a next event notification ought to be interpreted, the responding node 12 in at least one embodiment is configured to include an indication that immediate reporting is not supported, in a subscription response that omits current event status because of the non-support. In turn, with respect to receiving such a response, the requesting node 14 in one or more embodiments is configured to interpret the first event notification for the specified event that is received subsequent to the subscription response as indicating current event status as requested in the subscription request, rather than as indicating a new event detection. Fig.11 illustrates the example telecommunications network 10 from Fig.10 in more detail, according to an example embodiment. As depicted, the telecommunications network in the example of Fig.11 comprises a wireless communications network, such as a cellular network. In a particular example, the telecommunications network 10 comprises a cellular network that is configured according to specifications promulgated by the 3GPP, such as the Fifth Generation (5G) specifications. The example network 10 includes a Radio Access Network (RAN) 30, a Core Network (CN) 32, which includes the responding node 12. In the example, the requesting node 14 is external to the telecommunications network 10 and may be communicatively coupled to the CN 32 via one or more external networks (NW(s)) 34, such as the Internet or other Packet Data Network (PDN). The requesting node 14 comprises an AF node, for example, or other host computer that runs one or more application services that response to event status and notifications provided via the responding node 12. In one or more other embodiments, the requesting node 14 resides within the telecommunications network 10. Fig.11 also depicts a plurality of terminals 36 that are associated with the telecommunications network 10, e.g., they connect with or otherwise use communications services provided through the telecommunications network 10. A subscription request going from the requesting node 14 to the responding node 12 in one or more embodiments specifies the event(s) of interest and further specifies the terminals 36 of interest. In other words, the subscription request requests notifications for occurrences of one or more specific types of events involving one or more specific terminals 36. A subscription request may request reporting for a single terminal 36 or more than one terminal 36, such as by indicating a group or population of terminals 36. Fig.12 illustrates an example arrangement for a network node such as either the responding node 12 or the requesting node 14. The example arrangement includes processing circuitry 40 and communications circuitry 42. The processing circuitry 40 may comprise fixed circuitry or programmatically configured circuitry or a mix of both. The communications circuitry 42 includes physical layer wired or wireless signaling circuitry for transmitting (TX) and receiving (RX) signaling, such as messages or other information. The communications circuitry 42 may further include timing circuitry and protocol processing circuitry for the implementation of one or more protocol stacks, such as may be used in one or more embodiments. Fig.13 illustrates an example implementation of the processing circuitry 40, where the processing circuitry 40 comprises one or more microprocessors 50 (or other type of digital processor, such as a microcontroller or DSP) that are specially adapted to perform the respective operations described herein for either the responding node 12 or the requesting node 14, based on executing computer program instructions stored in storage / memory 52. Fig.13 illustrates such computer program instructions as one or more computer programs 54 stored in the storage / memory 52. The storage / memory 52 comprises one or more types of computer-readable media and may include volatile storage or non-volatile storage or a mix of both volatile and non-volatile storage. Example storage / memory 52 includes any one or more of SRAM, DRAM, NVRAM, FLASH, EEPROM, Solid State Disk (SSD) storage or hard drives. It will be appreciated that the computer program instructions and corresponding microprocessor adaptations differ as between the responding node 14 and requesting node 14. Fig.14 illustrates another embodiment of a network node, where the network node comprises processing units or modules. Here, a processing unit or module may be understood as a logic circuit realized via underlying circuitry and the example network node includes a communications module 60 and an associated processing module 62. While the same generalized modular approach may be used in both the responding node 12 and the requesting node 14, it will be appreciated that the configuration of the processing module 62 will be different as between the two nodes. For the requesting node 14, the processing module 62 is configured to: send a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receive a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpret a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status. For the responding node 12, the processing module 62 is configured to: receive a subscription request, requesting event notifications for a specified event in the telecommunications network and requesting immediate reporting of current event status; and send a subscription response in reply to the subscription request, the subscription response omitting the current event status. The subscription response includes an indication of unavailability of the current event status in the subscription response, responsive to the processing module 62 determining that the current event status is unavailable. Fig.15 illustrates an example method 1500 of operation by a network node operating as a requesting node 14. The method 1500 includes the requesting node 14: sending (Block 1502) a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receiving (Block 1504) a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpreting (Block 1506) a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status. The telecommunications network may be a cellular network operating according to 3GPP specifications. The cellular network may be a 5G cellular network as defined by the 3GPP specifications. In some embodiments, responsive to the subscription response having indicated unavailability of the current event status, the first event notification can be interpreted as indicating a new event detection. In some embodiments, responsive to the subscription response not having indicated unavailability of the current event status, the first event notification can be interpreted as indicating the current event status as requested in the subscription request. In some embodiments, responsive to the subscription response having indicated non-support for immediate event reporting, not having indicated unavailability of the current event status, and is otherwise interpreted as indicating a new event detection, the first event notification can be interpreted as indicating the current event status as requested in the subscription response. In some embodiments, the specified event is a first specified event among two or more specified events indicated in the subscription request, and the request for immediate status reporting applies to each of the two or more specified events. In these embodiments, responsive to a current event status having been included in the subscription response for one or more other ones among the two or more specified events, the method 1500 can include determining that the subscription response implicitly indicated unavailability of the current event status for the first specified event. In some embodiments, the specified event is a first specified event among two or more specified events indicated in the subscription request, and the request for immediate status reporting applies to each of the two or more specified events. In these embodiments, responsive to an event- specific indication of unavailability of the current event status having been included in the subscription response for the first specified event, the method 1500 can include determining that the subscription response implicitly indicated unavailability of the current event status for the first specified event. Step 1502 can comprise the network node sending the subscription request towards a NEF node of the telecommunications network. The NEF node is configured to expose events of specified criteria occurring within the telecommunications network. Step 1504 can comprise the network node receiving the subscription response from the NEF. In the above embodiments, the events can involve activities or movements of UEs with respect to communication services or network coverage areas provided by the telecommunications network. In these embodiments, the subscription request can specify one or more UEs as subjects of the requested event reporting. In these embodiments, the network node may be an Application Function (AF) node configured to provide application services responsive to the event notifications, for one or more subscribers to the application services. Fig.16 illustrates an example method 1600 of operation by a network node operating as a responding node 12. The method 1600 includes: receiving (Block 1602) a subscription request, requesting event notifications for a specified event in the telecommunications network and requesting immediate reporting of current event status; and sending (Block 1604) a subscription response in reply to the subscription request. Responsive to the responding node determining that current event status is unavailable, the subscription response omits the current event status and includes an indication of unavailability of current event status. The telecommunications network may be a cellular network that comprises one of a User Data Management (UDM) node, an Access and Mobility Management Function (AMF) node, a Session Management Function (SMF) node, or a Home Subscriber Server (HSS) node. The specified event may involve activities or movements of one or more UEs with respect to communication services or network coverage areas provided by the telecommunications network. In these embodiments, the subscription request may specify the one or more UEs as subjects of the requested event reporting. The telecommunications network may be a cellular network operating according to 3GPP specifications. The cellular network may be a 5G cellular network as defined by the 3GPP specifications. In the method 1600, the network node can determine that the current event status is unavailable based on local information maintained by the network node. In some embodiments, responsive to determining that immediate reporting is not supported for the subscription request, the method can further comprise a step of including an indication of non-support for immediate reporting. In these embodiments, determining that immediate reporting is not supported for the subscription request can be based on capabilities of the network node. In some alternatives, determining that immediate reporting is not supported for the subscription request can be based on capabilities of another network node operating as an intermediate node between the network node and a requesting node originating the subscription request. In other alternatives, determining that immediate reporting is not supported for the subscription request can be based on capabilities of another network node operating as a detecting node with respect to the specified event. The specified event may be a first specified event among two or more specified events indicated in the subscription request, and the request for immediate status reporting applies to each of the two or more specified events. In some embodiments, including the indication of unavailability of the current event status in the subscription response comprises implicitly indicating unavailability of the current event status by omitting the current event status for the first specified event in conjunction with including current event status for any other specified event among the two or more specified events for which the current event status is available. In alternative embodiments, the method 1600 includes indicating unavailability of current event status per specified event in the subscription response. Notably, modifications and other embodiments of the disclosed invention(s) will come to mind to one skilled in the art having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the invention(s) is / are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of this disclosure. Although specific terms may be employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation. EXAMPLE EMBODIMENTS 1. A method of operation by a network node, the method comprising: sending a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receiving a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpreting a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status. 2. The method according to embodiment 1, wherein the first event notification is interpreted as indicating a new event detection, responsive to the subscription response having indicated unavailability of the current event status. 3. The method according to embodiment 1, wherein the first event notification is interpreted as indicating the current event status as requested in the subscription request, responsive to the subscription response not having indicated unavailability of the current event status. 4. The method according to embodiment 1, wherein the first event notification is interpreted as indicating the current event status as requested in the subscription response, responsive to the subscription response having indicated non-support for immediate event reporting and not having indicated unavailability of the current event status and is otherwise interpreted as indicating a new event detection. 5. The method according to embodiment 1, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein the method includes determining that the subscription response implicitly indicated unavailability of the current event status for the first specified event, responsive to a current event status having been included in the subscription response for one or more other ones among the two or more specified events. 6. The method according to embodiment 1, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein the method includes determining that the subscription response implicitly indicated unavailability of the current event status for the first specified event, responsive to an event-specific indication of unavailability of the current event status having been included in the subscription response for the first specified event. 7. The method according to any of embodiments 1-6, wherein sending the subscription request comprises the network node sending the subscription request towards a Network Exposure Function (NEF) node of the telecommunications network, the NEF node configured to expose events of specified criteria occurring within the telecommunications network, and wherein receiving the subscription response comprises the network node receiving the subscription response from the NEF. 8. The method according to embodiment 7, wherein the events involve activities or movements of User Equipment (UEs) with respect to communication services or network coverage areas provided by the telecommunications network. 9. The method according to embodiment 7 or 8, wherein the subscription request specifies one or more UEs as subjects of the requested event reporting. 10. The method according to any one of embodiments 7-9, wherein the network node is an Application Function (AF) node configured to provide application services responsive to the event notifications, for one or more subscribers to the application services. 11. The method according to any one of embodiments 1-10, wherein the telecommunications network is a cellular network operating according to Third Generation Partnership Project (3GPP) specifications. 12. The method according to embodiment 11, wherein the cellular network is a Fifth Generation (5G) cellular network, as defined by the 3GPP specifications. 13. A network node comprising: communications circuitry; and processing circuitry configured to perform the method as set out in any one of embodiments 1-12. 14. A method of operation by a network node of a telecommunications network, the method comprising: receiving a subscription request, requesting event notifications for a specified event in the telecommunications network and requesting immediate reporting of current event status; and sending a subscription response in reply to the subscription request, the subscription response omitting the current event status; wherein the method further comprises including an indication of unavailability of the current event status in the subscription response, responsive to determining that the current event status is unavailable. 15. The method according to embodiment 14, further comprising determining that the current event status is unavailable based on local information maintained by the network node. 16. The method according to embodiment 14, wherein the method further comprises including an indication of non-support for immediate reporting, responsive to determining that immediate reporting is not supported for the subscription request. 17. The method according to embodiment 16, further comprising determining that immediate reporting is not supported for the subscription request based on capabilities of the network node. 18. The method according to embodiment 16, further comprising determining that immediate reporting is not supported for the subscription request based on capabilities of another network node operating as an intermediate node between the network node and a requesting node originating the subscription request. 19. The method according to embodiment 16, further comprising determining that immediate reporting is not supported for the subscription request based on capabilities of another network node operating as a detecting node with respect to the specified event. 20. The method according to embodiment 14, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein including the indication of unavailability of the current event status in the subscription response comprises implicitly indicating unavailability of the current event status by omitting the current event status for the first specified event in conjunction with including current event status for any other specified event among the two or more specified events for which the current event status is available. 21. The method according to embodiment 14, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein the method includes indicating unavailability of current event status per specified event in the subscription response. 22. The method according to any of embodiments 14-21, wherein the telecommunications network is a cellular network, and wherein the network node comprises one of a User Data Management (UDM) node, an Authorization and Mobility Management Function (AMF) node, a Session Management Function (SMF) node, a Policy Control Function (PCF) node, or a Home Subscriber Server (HSS) node. 23. The method according to any of embodiments 14-22, wherein the specified event involves activities or movements of one or more User Equipment (UEs) with respect to communication services or network coverage areas provided by the telecommunications network. 24. The method according to embodiment 23, wherein the subscription request specifies the one or more UEs as subjects of the requested event reporting. 25. The method according to any one of embodiments 14-24, wherein the telecommunications network is a cellular network operating according to Third Generation Partnership Project (3GPP) specifications. 26. The method according to embodiment 25, wherein the cellular network is a Fifth Generation (5G) cellular network, as defined by the 3GPP specifications. 27. A network node comprising: communications circuitry; and processing circuitry configured to perform the method as set out in any one of embodiments 14-26.

[0002] APPENDIX 3GPP TSG-CT WG4 Meeting #117 C4-233abc Göteborg, Sweden, 21st– 25thAugust 2023 CR-Form-v12.2 CHANGE REQUEST 29.503 CR xxxx rev - Current version: 18.2.0 For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp.org / Change-Requests. Proposed change affects: UICC apps ME Radio Access Network Core Network X Title: Immediate Reporting Handling Source to WG: Ericsson Source to TSG: CT4 Work item code: TEI18, UDICOM Date: 2023-06-19 Category: F Release: Rel-18 Use one of the following categories: Use one of the following releases: F (correction) Rel-8 (Release 8) A (mirror corresponding to a change in an earlier Rel-9 (Release 9) Rel-10 (Release 10) Rel-11 (Release 11) release) … B (addition of feature), Rel-16 (Release 16) C (functional modification of feature) Rel-17 (Release 17) D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900. Reason for change: 1 / When the immediate report is requested but the current status was not available at HSS / MME (or AMF / UDM), the immediate report cannot be included in the response (or via a notification), regardless whether the ERIR / IERIR feature is supported. In business logic, the NF consumer (AS / SCS / AF) may process the application logic differently for current status and newly detected events and may expect the CN to send current state (as immediate report was requested) in the subsequent request. If current status is not available, the NF consumer should be informed, thus the NF consumer will stop expecting the immediate reporting and only handle the late detected event reports. See CRxxxx of TS 23.632 for more details. Summary of change: 1 / Update Notification service procedure for immediate reporting 2 / Add new indication in CreatedEeSubscription data type 3 / Update OpenAPI accordingly. Consequences if not AS / SCS / AF is unable to distinguish between event current state or event approved: detected, and then it is unable to apply right application logic. Clauses affected: 5.5.2.4.2, 6.4.6.2.9, A.5 Y N Other specs X Other core specifications TS 23.632 CR xxxx affected: X Test specifications TS / TR ... CR ...

[0003] * * * First Change * * * * 5.5.2.4.2 Event Occurrence Notification Figure 5.5.2.4.2-1 shows a scenario where the UDM notifies the NF service consumer (that has subscribed to receive such notification) about occurrence of an event (see also 3GPP TS 23.502 [3] figure 4.15.3.2.2-1 step 4a), or the current status of subscribed events for immediate reporting if event reports cannot be included in the subscription response (i.e. the IERSR / ERIR features are not supported end-to-end by NEF / UDM / AMF / HSS). The request contains the Reference IDs as previously received in the EESubscription (see clause 6.4.6.2.2). [Fig.17 shows “Figure 5.5.2.4.2-1: Event Occurrence Notification” of 3GPP TS 29.503 v18.2.0] 1. The UDM sends a POST request to the callbackReference URI as provided by the NF service consumer during the subscription, the request shall include in each report the Reference ID of the associated monitoring configuration. 2. The NF Service Consumer responds with "204 No Content". On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body. * * * Next Change * * * * 6.4.6.2.9 Type: CreatedEeSubscription Table 6.4.6.2.9-1: Definition of type CreatedEeSubscription Attribute name Data type P Cardinality Description eeSubscription EeSubscription M 1 This IE shall contain the representation of the created event subscription. numberOfUEs Uinteger C 0..1 This IE shall be included if the event subscription is for a group of UEs. When present, this IE shall represent the number of UEs in the group. eventReports array(Monitoring O 1..N This IE when present, shall contain the status of Report) events that are requested for immediate reporting as well, if those events are available at the time of subscription. If an event requested for immediate reporting is detected by another NF (e.g. AMF or HSS) and both the UDM and the NF consumer (e.g. NEF) supports the "IERSR" feature, this UDM shall require the other NF to include the immediate reporting in subscription creation response and the UDM shall include the immediate event reports received from other NF in this IE; otherwise, the UDM shall require the other NF to directly notified to the NF consumer, thus the status of the event shall not be included in this IE. epcStatusInd boolean C 0..1 This IE indicates whether the subscription was also successful in EPC domain or not. true: the subscription was also successful in EPC domain. false: the subscription was not successful in EPC domain. This IE shall be included if epcAppliedInd is true in the subscription request. failedMonitoringConfigs map(FailedMonit O 1..N A map (list of key-value pairs where ReferenceId oringConfiguratio converted from integer to string serves as key; see n) clause 6.4.6.3.2) of FailedMonitoringConfiguration; see clause 6.4.6.2.24. This IE is used to indicate the failed subscriptions of event monitoring configuration and the failed cause for them. failedMoniConfigsEPC map(FailedMonit O 1..N A map (list of key-value pairs where ReferenceId oringConfiguratio converted from integer to string serves as key; see n) clause 6.4.6.3.2) of FailedMonitoringConfiguration; see clause 6.4.6.2.24. In addition to defined EventTypes, the key value "ALL" may be used to identify a map entry which contains the failed cause of the EE subscription was not successful in EPC domain. This IE is used to indicate the failed subscriptions of event monitoring configuration in EPC and the failed cause for them. This IE may be present when the EE subscription applies also to the EPC. When present, - the key-value "ALL" shall be used and only one map entry exists if the epcStatusInd sets false; - the key-values shall be ReferenceId converted from integer to string if the epcStatusInd sets true or absent. resetIds array(string) O 1..N May be present in subscribe response messages. The NF service consumer may decide to re- subscribe at the UDM when receiving a data restoration notification containing a matching resetId. currentStatusNotAvailab array(EventType) O 1..N This IE should be present if immediate reporting was leList requested by the NF consumer, but the current status of at least one of the subscribed events is not available at the time of subscription. When present, this IE shall list the events for which the current status is not available for immediate reporting. * * * Next Change * * * * A.5 Nudm_EE API openapi: 3.0.0 ************************ Text Skipped for Clarity ************************ # CreatedEeSubscription: type: object required: - eeSubscription properties: eeSubscription: $ref: '# / components / schemas / EeSubscription' numberOfUes: $ref: 'TS29571_CommonData.yaml# / components / schemas / Uinteger' eventReports: type: array items: $ref: '# / components / schemas / MonitoringReport' minItems: 1 epcStatusInd: type: boolean failedMonitoringConfigs: description: > A map (list of key-value pairs where referenceId converted from integer to string serves as key; see clause 6.4.6.3.2) of FailedMonitoringConfiguration type: object additionalProperties: $ref: '# / components / schemas / FailedMonitoringConfiguration' minProperties: 1 failedMoniConfigsEPC: description: > A map (list of key-value pairs where referenceId converted from integer to string serves As key; see clause 6.4.6.3.2) of FailedMonitoringConfiguration, the key value "ALL" may Be used to identify a map entry which contains the failed cause of the EE subscription was not successful in EPC domain. type: object additionalProperties: $ref: '# / components / schemas / FailedMonitoringConfiguration' minProperties: 1 resetIds: type: array items: type: string minItems: 1 currentStatusNotAvailableList: type: array items: $ref: '# / components / schemas / EventType' minItems: 1 ************************ Text Skipped for Clarity ************************ * * * End of Changes * * * *

[0004] 3GPP TSG-CT WG4 Meeting #117 C4-233abc Göteborg, Sweden, 21st– 25thAugust 2023 CR-Form-v12.2 CHANGE REQUEST 23.632 CR xxxx rev - Current version: 18.3.0 For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp.org / Change-Requests. Proposed change affects: UICC apps ME Radio Access Network Core Network X Title: Immediate Reporting Handling Source to WG: Ericsson Source to TSG: CT4 Work item code: TEI18, UDICOM Date: 2023-06-19 Category: F Release: Rel-18 Use one of the following categories: Use one of the following releases: F (correction) Rel-8 (Release 8) A (mirror corresponding to a change in an earlier Rel-9 (Release 9) Rel-10 (Release 10) Rel-11 (Release 11) release) … B (addition of feature), Rel-16 (Release 16) C (functional modification of feature) Rel-17 (Release 17) D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900. Reason for change: 1 / When UDM is used to handle common exposure for 4G / 5G interaction, the UDM will subscribe to HSS via Nhss_EE service for event monitoring in EPS. When immediate reporting is requested and current status is available at HSS (or returned by MME in the response message when configuring the subscribed events to MME), if "event reporting in response" feature (ERIR feature, see TS 29.563) is not supported between UDM and HSS, the HSS cannot include the current status in the subscription response. It is not clear how the current status of the event should be handled by HSS. It is proposed that the HSS shall send the current event status via a separate notification to the NF consumer (via UDM). 2 / When the immediate report is requested but the current status was not available at HSS / MME (or AMF / UDM), the immediate report cannot be included in the response (or via a notification), regardless whether the ERIR / IERIR feature is supported. In business logic, the NF consumer (AS / SCS / AF) may process the application logic differently for current status and newly detected events and may expect the CN to send current state (as immediate report was requested) in the subsequent notification request. If current status is not available, the NF consumer should be informed, thus the NF consumer will stop expecting the immediate reporting and only handle the late detected event reports. Summary of change: 1 / Update service procedure on how the immediate reporting is handled in clause 5.6.2. 2 / Add the new indication for Nhss_EE_Subscription service operation. Consequences if not 1) Immediate reports cannot be delivered to NF consumer, if the approved: UDM / HSS does not support Event Reports in Response feature. Application logic for immediate reports cannot be applied at NF consumer (AS / SCS / AF). 2) AS / SCS / AF is unable to distinguish between event current state or event detected, and then it is unable to apply right application logic. Clauses affected: 5.6.2, 6.1.5.1 Y N Other specs X Other core specifications TS / TR ... CR ... affected: X Test specifications TS / TR ... CR ... (show related CRs) X O&M Specifications TS / TR ... CR ... Other comments: This CR's revision history:

[0005] * * * First Change * * * * 5.6.2 Configuration of Monitoring Events in MME Figure 5.6.2-1 shows the scenario where the UDM receives a request from a combined SCEF+NEF to configure a monitoring event that needs to be reported by EPC (e.g. location change). [Fig.18 shows “Figure 5.6.2-1: Configuration of Monitoring Events in MME" of 3GPP TS 23.632 v18.3.0] 1. The UDM receives a request from a combined SCEF+NEF to configure a monitoring event for a UE. The request indicates that the subscription applies also to EPC and the monitoring event is to be reported by the MME (e.g., location change). The request includes the notification addresses of both the NEF and the SCEF. 2. The UDM configures the monitoring event for the UE in 5GC. If the 5GS UDR is used, the UDM stores the configuration of the monitoring event for the UE in the 5GS-UDR. The UDM contacts the corresponding NF within the 5GC (e.g., AMF, SMF) as required by the monitoring event. 3. Unless the subscription information related to the UE indicates that the UE has no EPC subscription data, then the UDM requests the HSS to configure the monitoring event for the UE in EPC using a Nhss_EventExposure_Subscribe operation. In addition to the UDM notification address, the UDM provides the SCEF notification address (i.e., SCEF Id). 4. The HSS configures the monitoring event for the UE in EPC using the procedures defined in 3GPP TS 23.682

[0016] . 5. The HSS replies to the UDM with the result of the subscription request. If immediate reporting was required and the current event status is available at HSS (or received from MME in step 4) and if both the UDM and the HSS support to include event reports in the subscription response, the HSS also includes the current event status in the subscription response to UDM and step 6a is skipped. If immediate reporting was required but the current event status is not available at HSS (and not received from MME in step 4), the HSS includes a flag in the subscription response indicating that immediate event report is not available. 6. The UDM replies to the combined SCEF+NEF including confirmation that the subscription was also successful in EPC domain. 6a. (Conditional) If immediate reporting was required and the current event status is available at HSS (or received from MME in step 4) but the UDM and / or the HSS cannot support to include event reports in the subscription response, the HSS sends a notification including the current event status for immediate reporting, to the UDM using the Nhss_EE_Notify service operation. The UDM then notifies NEF using the Nudm_EE_Notify service operation. 7. At a later stage, the monitoring event is detected for the UE in the EPC domain. The event may be detected at the MME (e.g., location change) or at the HSS (e.g., UE reachability for SMS). 8. The monitoring event is reported to the SCEF+NEF. The MME notifies the event as defined in 3GPP TS 23.682

[0016] by using the SCEF notification address provided by the HSS in step 4, if applicable. If the monitoring event is detected at the HSS or reported by the MME to the HSS, the HSS notifies the monitoring event to UDM using the Nhss_EE_Notify service operation. The UDM then notifies NEF using the Nudm_EE_Notify service operation. NOTE: The notification of monitoring events from HSS (e.g., reachability for SMS) using SBA interfaces supersedes the option of HSS using diameter S6t. Only the events reported by MME will keep diameter T6a interface towards SCEF. * * * Next Change * * * * 6.1.5.1 Nhss_EE_Subscribe service operation Service operation name: Nhss_EE_Subscribe. Description: The NF consumer request the HSS to subscribe to notifications for monitoring events as described in 3GPP TS 23.682

[0016] (e.g. location change). Inputs, Required: IMSI, monitoring event type(s), notification address. Inputs, Optional: - Outputs, Required: Result Indication, Subscription ID. Outputs, Optional: Current State Not Available Indication. * * * End of Changes * * * *

[0006] 3GPP TSG-CT WG4 Meeting #117 C4-233abc Göteborg, Sweden, 21st– 25thAugust 2023 CR-Form-v12.2 CHANGE REQUEST 29.563 CR xxxx rev - Current version: 18.2.0 For HELP on using this form: comprehensive instructions can be found at http: / / www.3gpp.org / Change-Requests. Proposed change affects: UICC apps ME Radio Access Network Core Network X Title: Immediate Reporting Handling Source to WG: Ericsson Source to TSG: CT4 Work item code: TEI18, UDICOM Date: 2023-06-19 Category: F Release: Rel-18 Use one of the following categories: Use one of the following releases: F (correction) Rel-8 (Release 8) A (mirror corresponding to a change in an earlier Rel-9 (Release 9) Rel-10 (Release 10) Rel-11 (Release 11) release) … B (addition of feature), Rel-16 (Release 16) C (functional modification of feature) Rel-17 (Release 17) D (editorial modification) Rel-18 (Release 18) Detailed explanations of the above categories can Rel-19 (Release 19) be found in 3GPP TR 21.900. Reason for change: 1 / When UDM is used to handle common exposure for 4G / 5G interaction, the UDM will subscribe to HSS via Nhss_EE service for event monitoring in EPS. When immediate reporting is requested and current status is available at HSS (or returned by MME in the response message when configuring the subscribed events to MME), if "event reporting in response" feature (ERIR feature, see TS 29.563) is not supported between UDM and HSS, the HSS cannot include the current status in the subscription response. It is not clear how the current status of the event should be handled by HSS. It is proposed that the HSS shall send the current event status via a separate notification to the NF consumer (via UDM). 2 / When the immediate report is requested but the current status was not available at HSS / MME (or AMF / UDM), the immediate report cannot be included in the response (or via a notification), regardless whether the ERIR / IERIR feature is supported. In business logic, the NF consumer (AS / SCS / AF) may process the application logic differently for current status and newly detected events and may expect the CN to send current state (as immediate report was requested) in a subsequent notification. If current status is not available, the NF consumer should be informed, thus the NF consumer will stop expecting the immediate reporting and only handle the late detected event reports. See CRxxxx of TS 23.632 for more details. Summary of change: 1 / Update service procedure on how the immediate reporting is handled in clause 5.5.2.2.2. 2 / Update Notification service procedure for immediate reporting 3 / Add new indication in CreatedEeSubscription data type 4 / Update OpenAPI accordingly. Consequences if not 1) Immediate reports cannot be delivered to NF consumer, if the approved: UDM / HSS does not support Event Reports in Response feature. Application logic for immediate reports cannot be applied at NF consumer (AS / SCS / AF). 2) AS / SCS / AF is unable to distinguish between event current state or event detected, and then it is unable to apply right application logic. Clauses affected: 5.5.2.2.2, 5.5.2.4.2, 6.4.6.2.3, A.5 Y N Other specs X Other core specifications TS 23.632 CR xxxx affected: X Test specifications TS / TR ... CR ... (show related CRs) X O&M Specifications TS / TR ... CR ... Other comments: This CR introduces backward compatible corrections to OpenAPI file of Nhss_EE API. This CR's revision history:

[0007] * * * First Change * * * * 5.5.2.2.2 Subscription to Notification of event occurrence Figure 5.5.2.2.2-1 shows a scenario where the NF service consumer sends a request to the HSS to subscribe to notifications of event occurrence. The request contains a callback URI, the type of event that is monitored and additional information e.g. SCEF Id, event filters and reporting options. [Fig.19 shows “Figure 5.5.2.2.2-1: NF service consumer subscribes to notifications” of 3GPP TS 29.563 v18.2.0] 1. The NF service consumer sends a POST request to the parent resource (collection of subscriptions) (... / {ueId} / ee-subscriptions), to create a subscription as present in message body. The request may contain an expiry time, suggested by the NF Service Consumer, representing the time upto which the subscription is desired to be kept active and the time after which the subscribed event(s) shall stop generating notifications. Additionally, the request may include an SCEF Id if Common Network Exposure is used (i.e., if combined SCEF+NEF requested the event(s) to be subscribed / monitored in EPC) If MTC Provider information is received in the request, the HSS shall check whether the MTC Provider is allowed to perform this operation for the UE; otherwise, the HSS shall skip the MTC provider authorization check. 2a. On success, the HSS responds with "201 Created" with the message body containing a representation of the created subscription. The Location HTTP header shall contain the URI of the created subscription. If immediate reporting is requested and if both HSS and NF consumer has indicated supporting of ERIR feature (see clause 6.4.8), the HSS shall include available immediate event reports, i.e. reports already received from MME, in the response body; otherwise if the HSS and / or the NF consumer cannot support the ERIR feature, the HSS shall send a notification (see clause 5.5.2.4.2) towards the NF consumer including the current status of the events requested for immediate reporting. If immediate reporting is requested but the current status of the event(s) is not available at the time of subscription, the HSS should include the current status not available indication in the response. If some of the requested monitoring configurations fails, the response may include the failedMonitoringConfigs to indicate the failed cause of the failed monitoring configurations. 2b. If the user does not exist, HTTP status code "404 Not Found" shall be returned including additional error information in the response body (in the "ProblemDetails" element). 2c. If there is no valid subscription data for the UE, i.e., based on the UE's subscription information monitoring of the requested EventType is not allowed, or the requested EventType is not supported, or the MTC Provider is not allowed to perform this operation for the UE, HTTP status code "403 Forbidden" shall be returned including additional error information in the response body (in the "ProblemDetails" element). 2d. In the case of redirection, the HSS shall return 3xx status code, which shall contain a Location header with an URI pointing to the endpoint of another HSS (service) instance. 2e. If the requested monitoring event types or reporting options are not supported, HTTP status code "501 Not Implemented" shall be returned including additional error information in the response body (in the "ProblemDetails" element). On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body. * * * Next Change * * * * 5.5.2.4.2 Event Occurrence Notification Figure 5.5.2.4.2-1 shows a scenario where the HSS notifies the NF service consumer (that has subscribed to receive such notification) about occurrence of an event or the current status of the events requested for immediate reporting if ERIR feature (see clause 6.4.8) is not supported by the HSS and / or the NF consumer. The request contains the Reference IDs as previously received in the EeSubscription. [Fig.20 shows “Figure 5.5.2.4.2-1: Event Occurrence Notification” of 3GPP TS 29.563 v18.2.0] 1. The HSS sends a POST request to the callbackReference URI as provided by the NF service consumer during the subscription. 2a. The NF Service Consumer responds with "204 No Content". On failure, the appropriate HTTP status code indicating the error shall be returned and appropriate additional error information should be returned in the POST response body. In the case of redirection, the NF Service Consumer shall return 3xx status code, which shall contain a Location header with an URI pointing to an alternative notification endpoint. * * * Next Change * * * *

[0008] 6.4.6.2.3 Type: CreatedEeSubscription Table 6.4.6.2.3-1: Definition of type CreatedEeSubscription Attribute name Data type P Cardinality Description Applicability eeSubscription EeSubscription M 1 This IE shall contain the representation of the created event subscription. eventReports array(MonitoringReport) O 1..N This IE may be included when ERIR the NF consumer has indicated supporting of ERIR feature in the subscription creation request (see clause 6.4.8). This IE when present, shall contain the status of events that are requested for immediate reporting as well, if those events are available at the time of subscription. failedMonitoringConf map(FailedMonitoringCo O 1..N A map (list of key-value pairs igs nfiguration) where ReferenceId converted from integer to string serves as key; see clause 6.4.6.3.2) of FailedMonitoringConfiguration; see clause 6.4.6.2.14. This IE is used to indicate the failed subscriptions of event monitoring configuration and the failed cause for them. currentStatusNotAva array(EventType) O 1..N This IE should be present if ilableList immediate reporting was requested by the NF consumer, but the current status of at least one of the subscribed events is not available at the time of subscription. When present, this IE shall list the events for which the current status is not available for immediate reporting. supportedFeatures SupportedFeatures O 0..1 See clause 6.4.8 * * * Next Change * * * * A.5 Nhss_EE API openapi: 3.0.0 ************************ Text Skipped for Clarity ************************ > It represents the response body of the subscription request, containing data of the created subscription in the HSS type: object required: - eeSubscription properties: eeSubscription: $ref: '# / components / schemas / EeSubscription' eventReports: type: array items: serves type: object additionalProperties: $ref: '# / components / schemas / FailedMonitoringConfiguration' minProperties: 1 currentStatusNotAvailableList: type: array items: $ref: '# / components / schemas / EventType' minItems: 1 supportedFeatures: $ref: 'TS29571_CommonData.yaml# / components / schemas / SupportedFeatures' ************************ Text Skipped for Clarity ************************ * * * End of Changes * * * *

Claims

CLAIMS 1. A method (1500) of operation by a network node, the method comprising: sending (1502) a subscription request, requesting event notifications for a specified event in a telecommunications network and requesting immediate reporting of current event status; receiving (1504) a subscription response in reply to the subscription request, the subscription response omitting the current event status; and interpreting (1506) a first event notification received subsequent to the subscription response either as indicating a new event detection or indicating the current event status as requested in the subscription request, in dependence on whether the subscription response indicated unavailability of the current event status.

2. The method (1500) according to claim 1, wherein the first event notification is interpreted as indicating a new event detection, responsive to the subscription response having indicated unavailability of the current event status.

3. The method (1500) according to claim 1, wherein the first event notification is interpreted as indicating the current event status as requested in the subscription request, responsive to the subscription response not having indicated unavailability of the current event status.

4. The method (1500) according to claim 1, wherein the first event notification is interpreted as indicating the current event status as requested in the subscription response, responsive to the subscription response having indicated non-support for immediate event reporting and not having indicated unavailability of the current event status and is otherwise interpreted as indicating a new event detection.

5. The method (1500) according to claim 1, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein the method includes determining that the subscription response implicitly indicated unavailability of the current event status for the first specified event, responsive to a current event status having been included in the subscription response for one or more other ones among the two or more specified events.

6. The method (1500) according to claim 1, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein the method includes determining that the subscription response implicitly indicated unavailability of the current event status for the first specified event, responsive to an event- specific indication of unavailability of the current event status having been included in the subscription response for the first specified event.

7. The method (1500) according to any of claims 1-6, wherein sending the subscription request comprises the network node sending the subscription request towards a Network Exposure Function, NEF, node of the telecommunications network, the NEF node configured to expose events of specified criteria occurring within the telecommunications network, and wherein receiving the subscription response comprises the network node receiving the subscription response from the NEF.

8. The method (1500) according to claim 7, wherein the events involve activities or movements of User Equipments, UEs, with respect to communication services or network coverage areas provided by the telecommunications network.

9. The method according to claim 7 or 8, wherein the subscription request specifies one or more UEs as subjects of the requested event reporting.

10. The method (1500) according to any one of claims 7-9, wherein the network node is an Application Function, AF, node configured to provide application services responsive to the event notifications, for one or more subscribers to the application services.

11. The method (1500) according to any one of claims 1-10, wherein the telecommunications network is a cellular network operating according to Third Generation Partnership Project, 3GPP, specifications.

12. The method (1500) according to claim 11, wherein the cellular network is a Fifth Generation, 5G, cellular network, as defined by the 3GPP specifications.

13. A network node comprising:communications circuitry (42); and processing circuitry (40) configured to perform the method as set out in any one of claims 1-12.

14. A method (1600) of operation by a network node of a telecommunications network, the method comprising: receiving (1602) a subscription request, requesting event notifications for a specified event in the telecommunications network and requesting immediate reporting of current event status; and sending (1604) a subscription response in reply to the subscription request, the subscription response omitting the current event status; wherein the method further comprises including an indication of unavailability of the current event status in the subscription response, responsive to determining that the current event status is unavailable.

15. The method (1600) according to claim 14, further comprising determining that the current event status is unavailable based on local information maintained by the network node.

16. The method (1600) according to claim 14, wherein the method further comprises including an indication of non-support for immediate reporting, responsive to determining that immediate reporting is not supported for the subscription request.

17. The method (1600) according to claim 16, further comprising determining that immediate reporting is not supported for the subscription request based on capabilities of the network node.

18. The method (1600) according to claim 16, further comprising determining that immediate reporting is not supported for the subscription request based on capabilities of another network node operating as an intermediate node between the network node and a requesting node originating the subscription request.

19. The method (1600) according to claim 16, further comprising determining that immediate reporting is not supported for the subscription request based on capabilities of another network node operating as a detecting node with respect to the specified event.

20. The method (1600) according to claim 14, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein including the indication of unavailability of the current event status in the subscription response comprises implicitly indicating unavailability of the current event status by omitting the current event status for the first specified event in conjunction with including current event status for any other specified event among the two or more specified events for which the current event status is available.

21. The method (1600) according to claim 14, wherein the specified event is a first specified event among two or more specified events indicated in the subscription request, with the request for immediate status reporting applying to each of the two or more specified events, and wherein the method includes indicating unavailability of current event status per specified event in the subscription response.

22. The method (1600) according to any of claims 14-21, wherein the telecommunications network is a cellular network, and wherein the network node comprises one of a User Data Management, UDM,) node, an Access and Mobility Management Function, AMF, node, a Session Management Function, SMF, node, or a Home Subscriber Server, HSS, node.

23. The method according to any of claims 14-22, wherein the specified event involves activities or movements of one or more User Equipments, UEs, with respect to communication services or network coverage areas provided by the telecommunications network.

24. The method according to claim 23, wherein the subscription request specifies the one or more UEs as subjects of the requested event reporting.

25. The method according to any one of claims 14-24, wherein the telecommunications network is a cellular network operating according to Third Generation Partnership Project, 3GPP, specifications.

26. The method according to claim 25, wherein the cellular network is a Fifth Generation, 5G, cellular network, as defined by the 3GPP specifications.

27. A network node comprising:communications circuitry; and processing circuitry configured to perform the method as set out in any one of claims 14- 26.

28. A network node comprising a processor and a memory, said memory containing instructions executable by said processor whereby said network node is operative to perform the method of any of claims 1-12 and 14-26.

Images