WO2022012674A1

WO2022012674A1 - Method and apparatus for event monitoring

Info

Publication number: WO2022012674A1
Application number: PCT/CN2021/106811
Authority: WO
Inventors: Jingrui TAO; David Castellanos Zamora; Beatriz Maroto Gil; Emiliano Merino Vazquez
Original assignee: Telefonaktiebolaget LM Ericsson AB
Current assignee: Telefonaktiebolaget LM Ericsson AB
Priority date: 2020-07-17
Filing date: 2021-07-16
Publication date: 2022-01-20
Anticipated expiration: 2023-01-17

Abstract

Embodiments of the present disclosure provide methods and apparatuses for event monitoring. A method comprises receiving a first monitoring request from an application function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity. The method further comprises sending a second monitoring request to the data management entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.

Description

METHOD AND APPARATUS FOR EVENT MONITORING

TECHNICAL FIELD

The non-limiting and exemplary embodiments of the present disclosure generally relate to the technical field of communications, and specifically to methods and apparatuses for event monitoring.

BACKGROUND

This section introduces aspects that may facilitate a better understanding of the disclosure. Accordingly, the statements of this section are to be read in this light and are not to be understood as admissions about what is in the prior art or what is not in the prior art.

Cellular Internet of Things (CIoT) is a technology which involves Machine-Type Communication (MTC) devices so that a telecommunications operator may provide other parties/companies their network for different applications. An example of such applications is the use of smart-metering readers, in which an MTC device can be placed in different locations and start sending and/or receiving data on a regular basis (e.g. electricity consumption reports, water-levels) . A hiring car company is another example, since they can place an MTC device on each car to track the consumers/customers and send them any kind of local advertising whenever they pass through a certain location.

In a communication network such as 3rd Generation Partnership Project (3GPP) network, an exposure function entity such as service capability exposure function (SCEF) or network exposure function (NEF) or an SCEF+NEF provides a means to securely expose the services and capabilities provided by a 3GPP network. The exposure function entity is a functional entity (network function) which receives the configuration of different monitoring events (e.g. when MTC device becomes reachable) initiated by an Application Function (AF) . This monitoring request is then sent by the exposure function entity via the HSS (Home Subscriber Server) towards the Mobility Management Entity (MME) in fourth generation (4G) core network via a diameter protocol (s6t interface, as described in 3GPP TS 29.336 V16.2.0, the disclosure of which is incorporated by reference herein in its entirety, or via UDM (User Data Management) towards the Access Management Function (AMF) in fifth generation (5G) core network, as described in 3GPP TS 29.503, the disclosure of which is incorporated by reference herein in its entirety. This monitoring can be requested for an individual user/device identified by an External Identifier, e.g. device1@ericsson. com, or for a group of users/devices identified by an External Group Identifier, e.g. devices-group-1@ericsson. com.

Depending on the vendor, SCEF and NEF can be a combined node or separate nodes. The same happens for HSS and UDM, since they can be co-located or deployed in separate functional entities. The detail of SCEF has been defined in 3GPP TS 23.682 V16.7.0, the disclosure of which is incorporated by reference herein in its entirety. The detail of NEF has been defined in 3GPP TS 23.501 V16.5.0, the disclosure of which is incorporated by reference herein in its entirety. NEF may inherit the functions from SCEF. For example, the architecture for SCEF and/or NEF may enable the 3GPP network to securely expose its services and capabilities provided by the 3GPP network interfaces to an external 3rd party service provider such as services capability server/an application server (SCS/AS) or application function (AF) entity hosting an application (s) .

SUMMARY

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.

There are some problems for the existing monitoring procedures. As described in 3GPP TS 23.682 V16.7.0, when the External Group Identifier is used in the communication pattern provisioning or monitoring event configuration and deletion procedures, the HSS shall be able to resolve the External Group Identifier to an IMSI-Group Identifier and one of the External Identifier (s) for each of the IMSIs in the IMSI-Group. If an AF or AS requires the reporting of an event for all the UEs in an operator’s network (e.g. international mobile equipment identity (IMEI) change) , it cannot be performed, since the interface between AF and exposure function entity only allows an External Identifiers (a single UE) or an External Group Identifier (a group of UEs) . One of these two identifiers is a mandatory field in T8 interface. If all UEs managed by the HSS are requested to be monitored, a possible choice is to create a group and provision each and every UE in the network inside the group. This results in huge signaling since when the group is resolved to its individual members, each UE within the group requires a monitoring request. In addition, each time the operator adds or removes one or several UEs (e.g. new users) in the network, it needs to perform an update to include those new UEs. In short, keeping the group updated is a hard task for the operator. In addition, it is very inefficient from the storage perspective, since this group containing all devices should be defined and maintained in the database.

To overcome or mitigate at least one above mentioned problems or other problems, the embodiments of the present disclosure propose an improved event monitoring solution.

In a first aspect of the disclosure, there is provided a method performed by an exposure function entity. The method comprises receiving a first monitoring request from an application function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity. The method further comprises sending a second monitoring request to the data management entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.

In an embodiment, the first monitoring request further comprises an indication of global group identifier.

In an embodiment, the second monitoring request further comprises the indication of global group identifier.

In an embodiment, the method may further comprise identifying the external group identifier as a global group identifier. The second monitoring request further comprises an indication of global group identifier.

In an embodiment, identifying the external group identifier as a global group identifier comprises identifying the external group identifier as the global group identifier based on a local policy.

In an embodiment, the local policy is based on machine-type communication (MTC) provider information and the external group identifier.

In an embodiment, the external group identifier is a global group identifier.

In an embodiment, a group reporting guard timer and maximum number of reports are absent in both the first monitoring request and the second monitoring request.

In an embodiment, the method may further comprise receiving a first monitoring indication message from a network entity. The method may further comprise sending a second monitoring indication message to the application function entity.

In an embodiment, the first monitoring request and the second monitoring request are used for configuration and/or deletion of monitoring events for all UEs managed by the data management entity.

In an embodiment, the monitoring events for all UEs managed by the data management entity comprises at least one of association of a UE and Universal Integrated Circuit Card (UICC) and/or new international mobile subscriber identity, international mobile equipment identity software version (IMSI-IMEI-SV) association; or roaming status of a UE, and change in roaming status of the UE.

In an embodiment, the method may further comprise receiving a second monitoring response from the data management entity, wherein a number of UEs belonging to a global group is absent in the second monitoring response.

In an embodiment, the application function entity is an Application Function (AF) or Services Capability Server/Application Server (SCS/AS) .

In an embodiment, the exposure function entity is a service capability exposure function (SCEF) or a network exposure function (NEF) or an SCEF+NEF.

In an embodiment, the data management entity is a home subscriber server (HSS) or a unified data management (UDM) or a HSS+UDM.

In a second aspect of the disclosure, there is provided a method performed by a data management entity. The method comprises receiving a second monitoring request from an exposure function entity. The second monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity. The method further comprises handling the second monitoring request.

In an embodiment, the second monitoring request further comprises an indication of global group identifier.

In an embodiment, the method may further comprise identifying the external group identifier as a global group identifier.

In an embodiment, a group reporting guard timer and maximum number of reports are absent in the second monitoring request.

In an embodiment, the method may further comprise sending a first monitoring indication message to the exposure function entity.

In an embodiment, the second monitoring request is used for configuration and/or deletion of monitoring events for all UEs managed by the data management entity.

In an embodiment, the method may further comprise sending a second monitoring response to the exposure function entity. The number of UEs belonging to a global group is absent in the second monitoring response.

In an embodiment, handling the second monitoring request comprises at least one of skipping a check for authorization of a machine-type communication (MTC) provider identifier; skipping a resolution of the external group identifier to an international mobile subscriber (IMSI) group identifier; skipping sending of configuration progress reports to the exposure function entity; or skipping a check of existence of the external group identifier.

In a third aspect of the disclosure, there is provided a method performed by an application function entity. The method comprises sending a first monitoring request to an exposure function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity.

In an embodiment, a group reporting guard timer and maximum number of reports are absent in the first monitoring request.

In an embodiment, the method may further comprise receiving a second monitoring indication message from the exposure function entity.

In an embodiment, the first monitoring request is used for configuration and/or deletion of monitoring events for all UEs managed by the data management entity.

In a fourth aspect of the disclosure, there is provided an exposure function entity. The exposure function entity comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said exposure function entity is operative to receive a first monitoring request from an application function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity. Said exposure function entity is further operative to send a second monitoring request to the data management entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.

In a fifth aspect of the disclosure, there is provided a data management entity. The data management entity comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said data management entity is operative to receive a second monitoring request from an exposure function entity. The second monitoring request comprises an external group identifier identifying all UEs managed by the data management entity. Said data management entity is further operative to handle the second monitoring request.

In a sixth aspect of the disclosure, there is provided an application function entity. The application function entity comprises a processor and a memory coupled to the processor. Said memory contains instructions executable by said processor. Said application function entity is operative to send a first monitoring request to an exposure function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity.

In a seventh aspect of the disclosure, there is provided an exposure function entity. The exposure function entity comprises a receiving module and a sending module. The receiving module may be configured to receive a first monitoring request from an application function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity. The sending module may be configured to send a second monitoring request to the data management entity, wherein the second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.

In an eighth aspect of the disclosure, there is provided a data management entity. The data management entity comprises a receiving module and a handling module. The receiving module may be configured to receive a second monitoring request from an exposure function entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity. The handling module may be configured to handle the second monitoring request.

In a ninth aspect of the disclosure, there is provided an application function entity. The application function entity comprises a sending module. The sending module may be configured to send a first monitoring request to an exposure function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity.

In another aspect of the disclosure, there is provided a computer program product, comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods according to the first, second and third aspects of the disclosure.

In another aspect of the disclosure, there is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods according to the first, second and third aspects of the disclosure.

Embodiments herein afford many advantages, of which a non-exhaustive list of examples follows. In some embodiments herein, the proposed solution introduces the concept of Global Group Identifier so that it can be used by operators to avoid provisioning of individual UEs within the group. In some embodiments herein, the proposed solution can reduce network signaling since there is not individual signaling for UE group member. In some embodiments herein, the proposed solution can reduce the unnecessary signaling for intermediate reporting on groups involving all UEs for a network. In some embodiments herein, the proposed solution proposes an efficient way to manage the storage for all UEs as a group while maintains backward compatibility within current interfaces towards external applications. The embodiments herein are not limited to the features and advantages mentioned above. A person skilled in the art will recognize additional features and advantages upon reading the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The above and other aspects, features, and benefits of various embodiments of the present disclosure will become more fully apparent, by way of example, from the following detailed description with reference to the accompanying drawings, in which like reference numerals or letters are used to designate like or equivalent elements. The drawings are illustrated for facilitating better understanding of the embodiments of the disclosure and not necessarily drawn to scale, in which:

FIG. 1a is a diagram illustrating a monitoring event configuration procedure according to an embodiment of the present disclosure;

FIG. 1b is a diagram illustrating a monitoring event reporting procedure according to an embodiment of the present disclosure;

FIG. 1c schematically shows a high level architecture in a 4G network;

FIG. 1d schematically shows a high level architecture in a 5G network;

FIG. 1e schematically shows a high level architecture for service exposure for EPC -5GC interworking;

FIG. 2 shows a flowchart of a method according to an embodiment of the present disclosure;

FIG. 3 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG. 4 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG. 5 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG. 6 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG. 7 shows a flowchart of a method according to another embodiment of the present disclosure;

FIG. 8 is a diagram illustrating a monitoring event configuration procedure according to an embodiment of the present disclosure;

FIG. 9 is a diagram illustrating a monitoring event reporting procedure according to an embodiment of the present disclosure;

FIG. 10 illustrates the procedure of configuring monitoring at the HSS or the MME/SGSN according to an embodiment of the present disclosure;

FIG. 11a illustrates the procedure of configuring monitoring at the MME/SGSN according to an embodiment of the present disclosure;

FIG. 11b illustrates the common procedure flow of reporting Monitoring Events that are detected by the MME/SGSN or HSS according to an embodiment of the present disclosure; ;

FIG. 12 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure;

FIG. 13 is a block diagram showing an exposure function entity according to an embodiment of the disclosure;

FIG. 14 is a block diagram showing a data management entity according to an embodiment of the disclosure; and

FIG. 15 is a block diagram showing an application function entity according to an embodiment of the disclosure.

DETAILED DESCRIPTION

The embodiments of the present disclosure are described in detail with reference to the accompanying drawings. It should be understood that these embodiments are discussed only for the purpose of enabling those skilled persons in the art to better understand and thus implement the present disclosure, rather than suggesting any limitations on the scope of the present disclosure. Reference throughout this specification to features, advantages, or similar language does not imply that all of the features and advantages that may be realized with the present disclosure should be or are in any single embodiment of the disclosure. Rather, language referring to the features and advantages is understood to mean that a specific feature, advantage, or characteristic described in connection with an embodiment is included in at least one embodiment of the present disclosure. Furthermore, the described features, advantages, and characteristics of the disclosure may be combined in any suitable manner in one or more embodiments. One skilled in the relevant art will recognize that the disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the disclosure.

As used herein, the term “network” refers to a network following any suitable (wireless or wired) communication standards. For example, the wireless communication standards may comprise new radio (NR) , long term evolution (LTE) , LTE-Advanced, wideband code division multiple access (WCDMA) , high-speed packet access (HSPA) , Code Division Multiple Access (CDMA) , Time Division Multiple Address (TDMA) , Frequency Division Multiple Access (FDMA) , Orthogonal Frequency-Division Multiple Access (OFDMA) , Single carrier frequency division multiple access (SC-FDMA) and other wireless networks. A CDMA network may implement a radio technology such as Universal Terrestrial Radio Access (UTRA) , etc. UTRA includes WCDMA and other variants of CDMA. A TDMA network may implement a radio technology such as Global System for Mobile Communications (GSM) . An OFDMA network may implement a radio technology such as Evolved UTRA (E-UTRA) , Ultra Mobile Broadband (UMB) , IEEE 802.11 (Wi-Fi) , IEEE 802.16 (WiMAX) , IEEE 802.20, Flash-OFDMA, Ad-hoc network, wireless sensor network, etc. In the following description, the terms “network” and “system” can be used interchangeably. Furthermore, the communications between two devices in the network may be performed according to any suitable communication protocols, including, but not limited to, the wireless communication protocols as defined by a standard organization such as 3rd generation partnership project (3GPP) or the wired communication protocols. For example, the wireless communication protocols may comprise the first generation (1G) , 2G, 3G, 4G, 4.5G, 5G communication protocols, and/or any other protocols either currently known or to be developed in the future.

The term “entity” used herein refers to a network device or network node or network function in a communication network. For example, in a wireless communication network such as a 3GPP-type cellular network, a core network device may offer numerous services to customers who are interconnected by an access network device. Each access network device is connectable to the core network device over a wired or wireless connection.

The term “network function” refers to any suitable function which can be implemented in a network entity (physical or virtual) of a communication network. For example, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g. on a cloud infrastructure. For example, the 5G system (5GS) may comprise a plurality of NFs such as AMF (Access and mobility Function) , SMF (Session Management Function) , AUSF (Authentication Service Function) , UDM (Unified Data Management) , PCF (Policy Control Function) , AF (Application Function) , NEF (Network Exposure Function) , UPF (User plane Function) and NRF (Network Repository Function) , RAN (radio access network) , SCP (service communication proxy) , NWDAF (network data analytics function) , etc. For example, the 4G system (such as LTE) may include MME (Mobile Management Entity) , HSS (home subscriber server) , SCEF, etc. In other embodiments, the network function may comprise different types of NFs for example depending on the specific network.

The term “terminal device” refers to any end device that can access a communication network and receive services therefrom. By way of example and not limitation, the terminal device refers to a mobile terminal, user equipment (UE) , or other suitable devices. The UE may be, for example, a Subscriber Station (SS) , a Portable Subscriber Station, a Mobile Station (MS) , or an Access Terminal (AT) . The terminal device may include, but not limited to, a portable computer, an image capture terminal device such as a digital camera, a gaming terminal device, a music storage and a playback appliance, a mobile phone, a cellular phone, a smart phone, a voice over IP (VoIP) phone, a wireless local loop phone, a tablet, a wearable device, a personal digital assistant (PDA) , a portable computer, a desktop computer, a wearable terminal device, a vehicle-mounted wireless terminal device, a wireless endpoint, a mobile station, a laptop-embedded equipment (LEE) , a laptop-mounted equipment (LME) , a USB dongle, a smart device, a wireless customer-premises equipment (CPE) and the like. In the following description, the terms “terminal device” , “terminal” , “user equipment” and “UE” may be used interchangeably. As one example, a terminal device may represent a UE configured for communication in accordance with one or more communication standards promulgated by the 3GPP, such as 3GPP’ LTE standard or NR standard. As used herein, a “user equipment” or “UE” may not necessarily have a “user” in the sense of a human user who owns and/or operates the relevant device. In some embodiments, a terminal device may be configured to transmit and/or receive information without direct human interaction. For instance, a terminal device may be designed to transmit information to a network on a predetermined schedule, when triggered by an internal or external event, or in response to requests from the communication network. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but that may not initially be associated with a specific human user.

As yet another example, in an Internet of Things (IoT) scenario, a terminal device may represent a machine or other device that performs monitoring and/or measurements, and transmits the results of such monitoring and/or measurements to another terminal device and/or network equipment. The terminal device may in this case be a machine-to-machine (M2M) device, which may in a 3GPP context be referred to as a machine-type communication (MTC) device. As one particular example, the terminal device may be a UE implementing the 3GPP narrow band internet of things (NB-IoT) standard. Particular examples of such machines or devices are sensors, metering devices such as power meters, industrial machinery, or home or personal appliances, for example refrigerators, televisions, personal wearables such as watches etc. In other scenarios, a terminal device may represent a vehicle or other equipment that is capable of monitoring and/or reporting on its operational status or other functions associated with its operation.

References in the specification to “one embodiment, ” “an embodiment, ” “an example embodiment, ” and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

It shall be understood that although the terms “first” and “second” etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed terms.

As used herein, the phrase “at least one of A and B” should be understood to mean “only A, only B, or both A and B. ” The phrase “A and/or B” should be understood to mean “only A, only B, or both A and B. ”

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of example embodiments. As used herein, the singular forms “a” , “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” , “comprising” , “has” , “having” , “includes” and/or “including” , when used herein, specify the presence of stated features, elements, and/or components etc., but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof.

It is noted that these terms as used in this document are used only for ease of description and differentiation among nodes, devices or networks etc. With the development of the technology, other terms with the similar/same meanings may also be used.

In the following description and claims, unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skills in the art to which this disclosure belongs.

It is noted that some embodiments of the present disclosure are mainly described in relation to the cellular network as defined by 3GPP being used as non-limiting examples for certain exemplary network configurations and system deployments. As such, the description of exemplary embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples and embodiments, and does naturally not limit the present disclosure in any way. Rather, any other system configuration or radio technologies such as wireless sensor network may equally be utilized as long as exemplary embodiments described herein are applicable.

FIG. 1a is a diagram illustrating a monitoring event configuration procedure according to an embodiment of the present disclosure. Some exemplary network elements such as a UE, a MME, a UDR (Unified Data Repository) , a HSS, a SCEF+NEF, and a SCS/AS/AF are depicted in FIG. 1a.

According to the procedure shown in FIG. 1a, at step 101, the operator has indicated the AFs that, if they want to subscribe to an event for all UEs, the external group ID (identifier) to be used is e.g., all-UEs@google. com. This group includes all UEs in the network and it is constantly updated by the operator every time a UE is added (the operator provisions the UE in the group) or removed (the operator removes the UE in the group) .

At step 102, an application subscribes to an event for the external group ID which contains all UEs.

At step 103, SCS/AS/AF sends a monitoring event subscription request to SCEF+NEF. The monitoring event subscription request includes External Group ID=all-UEs@google. com and event=IMEISV (international mobile station equipment identity software version) change.

At step 104, SCEF+NEF sends the subscription to HSS over s6t, indicating the group-guard-timer for HSS to send progress reports (i.e., time interval for reports) for the configuration result for each UE in the group (success/failure) . For example, SCEF+NEF sends s6t-configuration-information-request to HSS. The s6t-configuration-information-request includes External Group ID=all-UEs@google. com, event=IMEISV change and group-guard-timer=60 seconds.

At step 105, HSS retrieves the group data, that is, the group members (UE external identifiers) . In this way, the group is resolved to its individual members.

At step 106, HSS sends s6t-configuration-information-Answer including configuration-in-progress to SCEF+NEF.

At step 107, during the interval indicated by the group-guard-timer, for each UE in the group, the HSS stores the event (IMEI-change) and the SCEF-ID which is to be notified when the IMEISV changes.

FIG. 1b is a diagram illustrating a monitoring event reporting procedure according to an embodiment of the present disclosure. Some exemplary network elements such as a UE, a MME, a UDR (Unified Data Repository) , a HSS, a SCEF+NEF, and a SCS/AS/AF are depicted in FIG. 1b.

According to the procedure shown in FIG. 1b, at step 111, HSS sends a s6t-reporting-information-request including a list of UEs configured so far to SCEF+NEF.

At step 112, SCEF+NEF sends a s6t-reporting-information-Answer to HSS.

At step 113, during the interval indicated by the group-guard-timer, HSS keeps on storing the event for the remaining UEs.

At step 114, HSS sends a s6t-reporting-information-request including a list of UEs configured since a last report to SCEF+NEF.

At step 115, SCEF+NEF sends a s6t-reporting-information-Answer to HSS.

At step 116, HSS keeps on storing the event for the remaining UEs and sends reports after each interval expires for all UEs in the group until last UE is configured.

However there are some problems for the above solution as shown in FIGs. 1a-1b. For example, the configuration for a large group of UEs or all UEs (e.g., millions of UEs) involves a lot of time and signaling. Moreover, every time a new UE joins the group or leave the group, the group needs to be updated or provisioned by the operator.

FIGs. 1c-1e show some system architectures in which the embodiments of the present disclosure can be implemented. For simplicity, the system architectures of FIGs. 1c-1e only depict some exemplary elements. In practice, a communication system may further include any additional elements suitable to support communication between terminal devices or between a wireless device and another communication device, such as a landline telephone, a service provider, or any other network node or terminal device. The communication system may provide communication and various types of services to one or more terminal devices to facilitate the terminal devices’ access to and/or use of the services provided by, or via, the communication system.

FIG. 1c schematically shows a high level architecture in a 4G network, which is same as Figure 4.2-1a of 3GPP TS 23.682 V16.7.0, the disclosure of which is incorporated by reference herein in its entirety. The system architecture of FIG. 1c may comprise some exemplary elements such as SCS, AS, SCEF, HSS (home subscriber server) , UE, RAN (Radio Access Network) , SGSN (Serving GPRS (General Packet Radio Service) Support Node) , MME (Mobile Management Entity) , MSC (Mobile Switching Centre) , S-GW (Serving Gateway) , GGSN/P-GW (Gateway GPRS Support Node/PDN (Packet Data Network) Gateway) , MTC-IWF (Machine Type Communications-InterWorking Function) CDF/CGF (Charging Data Function/Charging Gateway Function) , MTC-AAA (Machine Type Communications-authentication, authorization and accounting) , SMS-SC/GMSC/IWMSC (Short Message Service-Service Centre/Gateway MSC/InterWorking MSC) IP-SM-GW (Internet protocol Short Message Gateway) . The network elements and interfaces as shown in FIG. 1c may be same as the corresponding network elements and interfaces as described in 3GPP TS 23.682 V16.7.0.

FIG. 1d schematically shows a high level architecture in a 5G network, which is same as Figure 4.2.3-1 of 3GPP TS 23.501 V16.5.0, the disclosure of which is incorporated by reference herein in its entirety. The system architecture of FIG. 1d may comprise some exemplary elements such as AMF, SMF, AUSF, UDM, PCF, AF, NEF, UPF and NRF, (R) AN, SCP, etc. The network elements, reference points and interfaces as shown in FIG. 1d may be same as the corresponding network elements, reference points and interfaces as described in 3GPP TS 23.501 V16.5.0.

FIG. 1e schematically shows a high level architecture for service exposure for EPC (evolved packet core) -5GC (5G core) interworking, which is same as Figure 4.3.5.1 1 of 3GPP TS 23.501 V16.5.0. For example, if the UE is capable of mobility between EPS (evolved packet system) and 5GS (5G system) , the network is expected to associate the UE with an SCEF+NEF node for service capability exposure. The system architecture of FIG. 1e may comprise some exemplary elements such as AF/AS, SCEF+NEF, EPC node, NF, etc. The network elements and interfaces as shown in FIG. 1e may be same as the corresponding network elements and interfaces as described in 3GPP TS 23.501 V16.5.0.

The exposure function entity such as SCEF and NEF may provide a means to securely expose the services and capabilities provided by the network (such as 3GPP network) interfaces. The exposure function entity may provide a means for the discovery of the exposed services and capabilities. The exposure function entity may provide access to network capabilities through network application programming interfaces (e.g. Network APIs (Application Programming Interfaces) ) . The exposure function entity may abstract the services from the underlying network interfaces and protocols.

There may be various kinds of network exposure services. For example, monitoring capability may be used for monitoring of specific event for a terminal device in a network such as 4G/5G system and making such monitoring events information available for external exposure via the exposure function entity such as SCEF/NEF. The provisioning capability may be used for allowing external party to provision of information which can be used for the terminal device such as UE in the network such as 4G/5G system. The policy/charging capability may be used for handling QoS (quality of service) and charging policy for the terminal device such as UE based on the request from an external party. The analytics reporting capability may be used for allowing an external party to fetch or subscribe/unsubscribe to analytics information generated by the network such as 4G/5G system. Data capability may be used for allowing an external party to communicate with a terminal device such as UE via an application programming interface.

In an embodiment, the exposure function entity may support network exposure function and network exposure services as described in 3GPP TS 23.501 V16.5.0 (such as clause 6.2.5, clause 7.2.8 of 3GPP TS 23.501 V16.5.0) .

In an embodiment, the exposure function entity may support the network exposure function as described in clause 4.4.8 of 3GPP TS 23.682 V16.7.0 (such as clause 4.4.8) .

FIG. 2 shows a flowchart of a method 200 according to an embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as an exposure function entity (such as SCEF, NEF or SCEF+NEF) or communicatively coupled to the exposure function entity. As such, the apparatus may provide means or modules for accomplishing various parts of the method 200 as well as means or modules for accomplishing other processes in conjunction with other components.

The method 200 illustrates the procedure of configuring monitoring at network entity such as the HSS or the MME/SGSN. The method 200 may be used for various monitoring event types. For example, the following events may be configured for monitoring for all UEs managed by a data management entity such as HSS:

-association of a UE and Universal Integrated Circuit Card (UICC) and/or new international mobile subscriber identity, international mobile equipment identity software version (IMSI-IMEI-SV) association; and/or

-roaming status of a UE, and change in roaming status of the UE.

The method 200 is also used for deleting a previously configured monitoring event either as a standalone procedure or together with configuring a new monitoring event between the same SCEF and the same SCS/AS, or replacing a previously configured monitoring event with a new monitoring event of the same type between the same SCEF and the same SCS/AS, or for one-time reporting in case the configured monitoring event is available at the configured node

At block 202, the exposure function entity receives a first monitoring request from an application function entity. The first monitoring request comprises an external group identifier identifying all UEs managed by the data management entity. The first monitoring request may further comprise any other suitable parameters. For example, the first monitoring request may further include common parameters as described in clause 5.6.0 of 3GPP TS 23.682 V16.7.0.

In an embodiment, the application function entity may be an SCS/AS or AF.

In an embodiment, the data management entity may be a home subscriber server (HSS) or a unified data management (UDM) or a HSS+UDM.

In an embodiment, the first monitoring request may be similar to the monitoring request sent from the SCS/AS to the SCEF as described in clause 5.6.1.1 of 3GPP TS 23.682 V16.7.0 except that the first monitoring request may include the external group identifier identifying all UEs managed by the data management entity.

For example, the SCS/AS sends a Monitoring Request (external group identifier identifying all UEs managed by a data management entity, SCS/AS Identifier, Monitoring Type, Monitoring Duration, T8 Destination Address, TLTRI (T8 Long Term Transaction Reference ID) for Deletion, Group Reporting Guard Time, MTC Provider Information) message to the SCEF. The SCEF assigns a TLTRI that identifies the Monitoring Request. The SCS/AS may perform deletion of a previously configured monitoring event together with configuring a new monitoring event. If the SCS/AS wants to perform deletion of a previously configured monitoring event, then it shall include TLTRI for Deletion. If the SCS/AS wants to configure monitoring event for the external group identifier identifying all UEs managed by a data management entity, the SCS/AS can send Monitoring Request message including the external group identifier identifying all UEs managed by the data management entity. If the SCS/AS includes the external group identifier identifying all UEs managed by the data management entity in the Monitoring Request message, External Identifier or MSISDN shall be ignored.

In an embodiment, the exposure function entity handles the first monitoring request. For example, the SCEF stores SCS/AS Identifier, T8 Destination Address, Monitoring Duration. The SCEF stores the TLTRI, and also assigns it to an SCEF Reference ID. Based on operator policies, if either the SCS/AS is not authorized to perform this request (e.g. if the SLA (Service Level Agreement) does not allow for it) or the Monitoring Request is malformed or the SCS/AS has exceeded its quota or rate of submitting monitoring requests, the SCEF sends monitoring response and provides a Cause value appropriately indicating the error. If the SCEF received a TLTRI for Deletion, the SCEF looks up the SCEF context pointed to by the TLTRI to derive the related SCEF Reference ID for Deletion.

At block 204, the exposure function entity sends a second monitoring request to the data management entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity. The second monitoring request may be any suitable monitoring requests for various monitoring event types. The second monitoring request may further include any other suitable parameters. For example, the second monitoring request may further include common parameters as described in clause 5.6.0 of 3GPP TS 23.682 V16.7.0.

In an embodiment, the second monitoring request may be the monitoring request sent from the SCEF to the HSS as described in clause 5.6.1.1 of 3GPP TS 23.682 V16.7.0.

For example, the SCEF sends a Monitoring Request (External Group Identifier identifying all UEs managed by a data management entity, SCEF ID, SCEF Reference ID, Monitoring Type, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier, MTC Provider Information) message to the HSS to configure the given monitoring event on the HSS and on the MME/SGSN, if required. The MTC Provider Information is an optional parameter. The SCEF should validate the provided MTC Provider Information and may override it to an SCEF selected MTC Provider Information based on configuration.

In an embodiment, the first monitoring request further comprises an indication of global group identifier. The second monitoring request further comprises the indication of global group identifier. The indication of global group identifier may take any suitable form. For example, the indication of global group identifier may be an explicit or implicit indication.

At block 206, optionally, the exposure function entity receives a second monitoring response from the data management entity. A number of UEs belonging to a global group is absent in the second monitoring response. The second monitoring response may include any parameters. In an embodiment, the second monitoring response may be similar to the monitoring response sent from the HSS to the SCEF as described in clause 5.6.1.1 of 3GPP TS 23.682 V16.7.0 except that the number of UEs belonging to the global group is absent in the second monitoring response.

FIG. 3 shows a flowchart of a method 300 according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as an exposure function entity (such as SCEF, NEF or SCEF+NEF) or communicatively coupled to the exposure function entity. As such, the apparatus may provide means or modules for accomplishing various parts of the method 300 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block 302, the exposure function entity receives a first monitoring request from an application function entity, wherein the first monitoring request comprises an external group identifier identifying all UEs managed by a data management entity. Block 302 is same as block 202 of FIG. 2.

At block 304, the exposure function entity identifies the external group identifier as a global group identifier. The second monitoring request further comprises an indication of global group identifier. The exposure function entity may identify the external group identifier as the global group identifier in various ways. For example, an external group identifier may be defined as the global group identifier which is known by the exposure function entity and the application function entity.

In an embodiment, the exposure function entity may identify the external group identifier as the global group identifier based on a local policy.

In an embodiment, the local policy is based on machine-type communication (MTC) provider information and the external group identifier. The MTC provider information may identify the MTC Service Provider and/or MTC Application.

At block 306, the exposure function entity sends a second monitoring request to the data management entity, wherein the second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity. Block 308 is same as block 206 of FIG. 2.

At block 308, the exposure function entity receives a second monitoring response from the data management entity. Block 308 is same as block 206 of FIG. 2.

In an embodiment, the external group identifier may be a global group identifier. For example, the external group identifier may be GLOBAL-GROUP-IDENTIFIER-TYPE (2) . The value 2 indicates the External-Identifier AVP (attribute-value pair) carries an identity which has been identified as a Global Group (all UEs) . In an embodiment, the Global Group Identifier may only be used if the monitoring event is either IMEI (SV) change or Roaming Status.

In an embodiment, a group reporting guard timer and maximum number of reports are absent in both the first monitoring request and the second monitoring request. The group reporting guard timer indicates that the collected status indications and/or reports for UEs belonging to a group shall be reported no later than at the interval indicated by the group reporting guard timer. In an embodiment, the group reporting guard timer shall be present if the User-Identifier contains an External Group Identifier and the External Group Identifier is not identified as a Global Group Identifier; otherwise, the group reporting guard timer shall be absent. Maximum number of reports is a parameter that indicates the maximum number of event reports to be generated by a network entity such as the HSS, MME, or SGSN until the associated monitoring event is considered to expire.

FIG. 4 shows a flowchart of a method 400 according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as an exposure function entity (such as SCEF, NEF or SCEF+NEF) or communicatively coupled to the exposure function entity. As such, the apparatus may provide means or modules for accomplishing various parts of the method 400 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block 402, the exposure function entity receives a first monitoring indication message from a network entity. In an embodiment, the network entity may be the HSS or UDM or HSS+UDM. In another embodiment, the network entity may be the MME/SGSN. In still another embodiment, the network entity may be the AMF.

For example, a monitoring event may be detected by a network entity such as the HSS, or the network entity such as the HSS needs to inform the exposure function entity such as SCEF about the change of status (suspend/resume/cancel) of an ongoing monitoring if an event related with the change of monitoring support at the serving node, (e.g. lack of monitoring support in a network entity such as MME/SGSN or revocation of monitoring authorization) is detected in the network entity such as the HSS. The network entity such as HSS also stores the time when the event is detected or the status is changed. When reporting for an individual UE or individual Group Member UE, the network entity such as HSS sends a Monitoring Indication (SCEF Reference ID (s) , External ID or MSISDN (Mobile Subscriber ISDN (Integrated Services Digital Network) Number) , Monitoring Event Report) message to the exposure function entity such as SCEF. External ID or MSISDN are only included if the indication is associated with an individual Group Member UE. Based on SCEF Reference ID, the SCEF can determine what groups the report pertains to. Multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

At block 404, the exposure function entity sends a second monitoring indication message to the application function entity. For example, using the SCEF Reference ID, the SCEF retrieves the associated TLTRI along with the T8 Destination Address. If the TLTRI refers to a group-based Monitoring Event configuration, and if no Group Reporting Guard Time was set, then the SCEF sends a Monitoring Indication (TLTRI (s) , Cause, Monitoring Event Report) message to the identified destination. So that the SCEF can determine what groups the report pertains to, multiple TLTRIs can be included if the UE is part of multiple groups that require the same monitoring indication. For each group member UE all the received Monitoring Event Report, and the corresponding time received at SCEF or the time value sent by HSS, are sent to the SCS/AS.

FIG. 5 shows a flowchart of a method 500 according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a data management entity (such as HSS, UDM or HSS+UDM) or communicatively coupled to the data management entity. As such, the apparatus may provide means or modules for accomplishing various parts of the method 500 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block 502, the data management entity receives a second monitoring request from an exposure function entity. The second monitoring request comprises an external group identifier identifying all UEs managed by the data management entity. For example, the exposure function entity such as SCEF may send the second monitoring request to the data management entity at block 204 of FIG. 2, and the data management entity may receive the second monitoring request from the exposure function entity.

In an embodiment, the external group identifier is a global group identifier.

At block 504, the data management entity handles the second monitoring request. For example, the data management entity such as HSS examines the monitoring Request message, e.g. with regard to the existence of External Group Identifier, whether any included parameters are in the range acceptable for the operator, whether the monitoring event (s) is supported by the serving MME/SGSN, whether the group-basis monitoring event feature is supported by the serving MME/SGSN, or whether the monitoring event that shall be deleted is valid. The HSS optionally authorizes the chargeable party identified by Chargeable Party Identifier. If this check fails, the HSS sends a Monitoring Response and provides a Cause value indicating the reason for the failure condition to the SCEF.

In an embodiment, if the HSS receives the Monitoring Request with an External Group Identifier identifying all UEs managed by the data management entity, the HSS sends a Monitoring Response (SCEF Reference ID, Cause) message to the SCEF to acknowledge acceptance of the Monitoring Request immediately. The HSS deletes the monitoring event configuration identified by the SCEF Reference ID, if it was requested.

In an embodiment, the HSS stores the SCEF Reference ID, the SCEF ID, Monitoring Duration and the SCEF Reference ID for Deletion as provided by the SCEF. For a Monitoring Request for a group not identified as global, such parameters are stored for every group member UE.

In an embodiment, HSS stores the subscription with an external Identity as “virtual user” (associated to the “global” group) . No progress reports shall be sent to SCEF.

In an embodiment, the data management entity may skip a check for authorization of a machine-type communication (MTC) provider identifier.

In an embodiment, the data management entity may skip a resolution of the external group identifier to an international mobile subscriber (IMSI) group identifier.

In an embodiment, the data management entity may skip a check of existence of the external group identifier.

In an embodiment, the data management entity may skip sending of configuration progress reports to the exposure function entity.

At block 506, optionally, the data management entity sends a second monitoring response to the exposure function entity. The number of UEs belonging to a global group is absent in the second monitoring response.

At block 508, optionally, the data management entity sends a first monitoring indication message to the exposure function entity.

FIG. 6 shows a flowchart of a method 600 according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as a data management entity (such as HSS, UDM or HSS+UDM) or communicatively coupled to the data management entity. As such, the apparatus may provide means or modules for accomplishing various parts of the method 600 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block 602, the data management entity receives a second monitoring request from an exposure function entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity. Block 602 is same as block 502 of FIG. 5.

At block 604, the data management entity identifies the external group identifier as a global group identifier.

In an embodiment, the data management entity may identify the external group identifier as the global group identifier based on a local policy. In an embodiment, the local policy is based on machine-type communication (MTC) provider information and the external group identifier.

At block 606, the data management entity handles the second monitoring request. Block 606 is same as block 504 of FIG. 5.

At block 608, the data management entity sends a second monitoring response to the exposure function entity. The number of UEs belonging to a global group is absent in the second monitoring response. Block 608 is same as block 506 of FIG. 5.

At block 610, the data management entity sends a first monitoring indication message to the exposure function entity. Block 610 is same as block 508 of FIG. 5.

FIG. 7 shows a flowchart of a method 700 according to another embodiment of the present disclosure, which may be performed by an apparatus implemented in or at or as an application function entity (such as SCS/AS or AF) or communicatively coupled to the application function entity. As such, the apparatus may provide means or modules for accomplishing various parts of the method 700 as well as means or modules for accomplishing other processes in conjunction with other components. For some parts which have been described in the above embodiments, detailed description thereof is omitted here for brevity.

At block 702, the application function entity may send a first monitoring request to an exposure function entity. The first monitoring request comprises an external group identifier identifying all UEs managed by the data management entity.

At block 704, optionally, the application function entity may receive a first monitoring response from the exposure function entity. For example, the application function entity may receive a Monitoring Response (TLTRI, Cause) message from the exposure function entity. The Cause value indicates progress of group processing request.

At block 706, optionally, the application function entity may receive a second monitoring indication message from the exposure function entity. For example, when the exposure function entity is SCEF, using the SCEF Reference ID, the SCEF retrieves the associated TLTRI along with the T8 Destination Address. If the TLTRI refers to a group-based Monitoring Event configuration, and if no Group Reporting Guard Time was set, then the SCEF sends a Monitoring Indication (TLTRI (s) , Cause, Monitoring Event Report) message to the identified destination. So that the SCEF can determine what groups the report pertains to, multiple TLTRIs can be included if the UE is part of multiple groups that require the same monitoring indication.

According to various embodiments, when a monitoring request for all UE is required, the Global External Group Identifier may be used to identify all UEs in an operator’s network (i.e. all UEs managed by a network entity such as HSS) . The application function entity such as AF may use this global/special group that may be understood as all UEs in a network such as HPLMN (Home Public Land Mobile Network) .

According to various embodiments, the exposure function entity such as SCEF may (e.g., based on local configuration) identify an external group identifier as a Global Group, that is, involving all UEs managed by a data management entity such as HSS.

According to various embodiments, the exposure function entity such as SCEF may indicate a data management entity such as HSS that the External Group is of type Global. This new type of Group may serve as an indication that no progress reports are required, neither the number of UEs within the group.

According to various embodiments, the data management entity such as HSS detects the indication of a global group and acts accordingly, that is, it does not need to check the group existence, since it is understood as global subscription. The data management entity such as HSS also understands that there is no need (as it does not make any sense) of any progress reports or number of UEs within the group.

FIG. 8 is a diagram illustrating a monitoring event configuration procedure according to an embodiment of the present disclosure. Some exemplary network elements such as a UE, a MME, a UDR (Unified Data Repository) , a HSS, a SCEF+NEF, and a SCS/AS/AF are depicted in FIG. 8.

According to the procedure shown in FIG. 8, at step 801, the operator has indicated the AFs that, if they want to apply a subscription for all UEs, the external group ID (identifier) to be used is e.g., all-UEs@google. com. Nothing is provisioned by the operator, i.e., no UE group members are associated to the external group ID: all-UEs@google. com.

At step 802, an application subscribes to an event for the external group ID which identifies all UEs. For example, The application subscribes to an event to be monitored and reported for an External Group Identifier which identifies “all UEs in the network” , e.g. all-UEs@ericsson. com.

At step 803, SCS/AS/AF sends a monitoring event subscription request to SCEF+NEF. The monitoring event subscription request includes External Group ID=all-UEs@google. com and event=IMEISV change.

At step 804, SCEF+NEF detects, based on a local policy, that the External Group ID corresponds to all UEs. Hence, a new type of identifier (global group ID) is to be sent to HSS. Since this a bulk subscription for SCEF, progress report items and number of UEs in the group are not expected.

At step 805, SCEF+NEF sends s6t-configuration-information-request to HSS. The s6t-configuration-information-request includes External Group ID=all-UEs@google. com, group type=global and event=IMEISV change.

For example, SCEF+NEF detects, based on a local policy, that the group identifier is a Global group (i.e. it corresponds to all UEs, hence it is not provisioned as a group) . SCEF+NEF includes a new group-type information element to indicate that the group has been identified as global.

At step 806, HSS detects, based on the new type of external group ID, that the external group ID identifies all UEs managed by the HSS. The presence of this type indicates that no configuration progress report are to be sent to SCEF, neither the number of UEs.

At step 807, HSS sends a modification request to UDR including External Group ID=all-UEs@google. com and event type=IMEISV change. HSS stores the subscription data in a “virtual user” identified with an external ID matching the external group ID, i.e., External Group ID=all-UEs@google. com. The data stored in the “virtual user” contain event=IMEISV change and SCEF ID.

For example, HSS stores the subscription with an external Identity as “virtual user” (associated to the “global” group) . No progress reports shall be sent to SCEF.

At step 808, HSS sends a response including result=success to SCEF.

FIG. 9 is a diagram illustrating a monitoring event reporting procedure according to an embodiment of the present disclosure. Some exemplary network elements such as a UE, a MME, a UDR (Unified Data Repository) , a HSS, a SCEF+NEF, and a SCS/AS/AF are depicted in FIG. 9.

According to the procedure shown in FIG. 9, at step 901, after changing smart phone (IMEI changes to a 5G capable device) , a user attaches to the network over 4G network.

At step 902, MME sends an update-location-request including IMEISV to HSS. For example, when a UE in the network changes its IMEISV and attaches to the 4G network. HSS receives the new IMEISV in the location update procedure.

At step 903, HSS reads user data from UDR and checks stored IMEISV. Since the IMEI has changed, HSS stores the new IMEI.

At step 904, HSS also retrieves the subscription data stored in the “virtual user” identifying all UEs (External Group ID=all-UEs@google. com) by querying the event subscription (event type=IMEISV change) . The retrieved subscription data includes the SCEF IDs.

At step 905, HSS sends a s6t-reporting-information-request to notifies SCEF+NEF about the event (IMEI change) . The s6t-reporting-information-request includes user ID, event=IMEI change, and new IMEISV.

For example, HSS reads the User’s data from the database and detects that the IMEI has changed. It then retrieves the subscription to events being monitored for this virtual user associated to the “global” group by querying the event subscription (IMEISV change) . The subscriptions data retrieved include the identities (i.e. SCEF-ID) subscribed to those changes and HSS notifies the event to that identity.

At step 906, SCEF+NEF sends a monitoring event notification to SCS/AS. The monitoring event notification includes user ID, event=IMEI change, and new IMEISV. For example, HSS notifies SCEF so that SCEF is able to notify SCS/AS/AF.

There are some advantages of the solutions of FIGs. 8-9. For example, there is no extra signaling regarding of the amount of UEs present in the group. In addition, there is no provisioning required at all for new/removed UEs, since this “virtual user” is equivalent to “all UEs” .

According to various embodiments, the Global Group Identifier can be detected (via local policy) in the data management entity such as HSS

According to various embodiments, the Global Group Identifier can be indicated by the application function entity such as SCS/AS/AF with a simple additional indicator (e.g. type of group=global) towards the exposure function entity such as SCEF.

The methods as shown in FIGs. 2-9 are also applicable for 5GS. In 5GC (5G Core Network) , the SCEF is replaced by NEF, MME is replaced by AMF and HSS is replaced by UDM.

The various blocks shown in FIGs. 2-9 may be viewed as method steps, and/or as operations that result from operation of computer program code, and/or as a plurality of coupled logic circuit elements constructed to carry out the associated function (s) . The schematic flow chart diagrams described above are generally set forth as logical flow chart diagrams. As such, the depicted order and labeled steps are indicative of specific embodiments of the presented methods. Other steps and methods may be conceived that are equivalent in function, logic, or effect to one or more steps, or portions thereof, of the illustrated methods. Additionally, the order in which a particular method occurs may or may not strictly adhere to the order of the corresponding steps shown.

In an embodiment, the following clauses of 3GPP TS 29.336 V16.2.0 may be amended as following.

***First Change ****

7.2.1.1 General

This procedure is used between the SCEF and the HSS for:

- the configuration/deletion of Monitoring events for a UE or a Group of UEs or any UE managed by the HSS (i.e. a Global Group) ;

- the configuration/deletion of Communication Patterns;

- the configuration/query of Enhanced Coverage Restrictions;

- the configuration of Network Configuration parameters;

- the translation of an External Group Identifier (s) to IMSI Group Id (s) .

The following events may be configured for monitoring for an individual UE or a group of UEs:

- Association of the UE and UICC and/or new IMSI-IMEI-SV association;

- UE reachability;

- Location of the UE, and change in location of the UE;

- Loss of connectivity;

- Communication failure;

- Roaming status (i.e. Roaming or No Roaming, VPLMN-ID) of the UE, and change in roaming status of the UE;

- Availability after DDN failure;

- Idle Status Indication in addition to UE reachability or Availability after DDN failure;

- PDN Connectivity Status.

Additionally, the following events may be configured for monitoring for all UEs managed by the HSS:

- Association of the UE and UICC and/or new IMSI-IMEI-SV association;

This procedure is mapped to the commands Configuration-Information-Request/Answer in the Diameter application specified in clause 8. The tables 7.2.1.1-1 and 7.2.1.1-2 detail the involved information elements.

Table 7.2.1.1-1: Configuration Information Request

Table 7.2.1.1-2: Configuration Information Answer

***Next Change ****

7.2.1.2 Detailed Behaviour of the HSS

When the Configuration Information Request is received from the SCEF, the HSS shall, in the following order:

1. Check that the User Identity for whom data is asked exists in HSS. If not, Experimental-Result shall be set to DIAMETER_ERROR_USER_UNKNOWN (5001) in the Configuration Information Answer.

2. Check whether the requesting SCEF is authorized to request the specified service (e.g. presence of Monitoring Event Configuration AVPs indicates the MONTE service) . If not, Experimental-Result shall be set to DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510) in the Configuration Information Answer.

2a. If the MTC Provider Information is received, check if the MTC Provider ID is authorized for the UE or the group of UEs. If not, Experimental-Result shall be set to DIAMETER_ERROR_UNAUTHORIZED_MTC_PROVIDER (5516) in the Configuration Information Answer.

NOTE: If the user Identity contains a Global Group Identifier, the HSS can skip the check for authorization of the MTC Provider ID

3. Check that the requested service (e.g. MONTE, indicated by the presence of Monitoring-Event-Configuration AVPs, or Communication Pattern, indicated by the presence of AESE-Communication-Pattern AVP) is authorized for the UE or the group of UEs. If not, Experimental-Result shall be set to DIAMETER_ERROR_UNAUTHORIZED_SERVICE (5511) in the Configuration Information Answer.

3a. If the request is IMSI Group Id Retrieval (as indicated by the CIR-Flags AVP) , the HSS shall return the IMSI Group Id (s) in the order of sequence that corresponds to the order of sequence of the received External Group Identifier (s) received in the User-Identifier AVP and AdditionalIdentifiers AVP. The Result Code shall be set to DIAMETER_SUCCESS. Stop processing.

Otherwise, continue to step 4.

NOTE: Applicable steps 4-8 are performed for each monitoring event type or communication pattern requested.

4. Check whether the limits on number of monitoring events that can be requested per monitoring type and SCEF-ID is reached. If so, Result-Code in Monitoring-Event-Config-Status for the affected service (s) shall be set to DIAMETER_RESOURCES_EXCEEDED (5006) . The Result-Code shall be set to DIAMETER_SUCCESS in the Configuration Information Answer.

4a. Check whether the requesting SCEF is authorized to request the specific service configuration (s) (e.g. Monitoring Event Type indicates a specific monitoring event configuration) . If not, Experimental-Result-Code in Monitoring-Event-Config-Status for the affected service configuration (s) shall be set to DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510) . The Result-Code shall be set to DIAMETER_SUCCESS in the Configuration Information Answer.

4b. Check that the requested specific service configuration (s) (e.g. Monitoring Event Type) is authorized for the UE or the group of UEs. If not, Experimental-Result-Code in Monitoring-Event-Config-Status for the affected service (s) shall be set to DIAMETER_ERROR_UNAUTHORIZED_SERVICE (5511) . The Result-Code shall be set to DIAMETER_SUCCESS in the Configuration Information Answer.

5. When the request is for a group, i.e. because the External-Identifier AVP of the User-Identifier AVP contain an External Group Identifier not identified as a Global Group Identifier, the HSS applies the Monitoring-Event-Configuration AVP to each UE of the Group and includes the CIA-Flags AVP with the Group-Configuration-In-Progress bit set in the Configuration Information Answer. The Result-Code shall be set to DIAMETER_SUCCESS in the Configuration Information Answer.

6. If a serving node is registered and is involved in the reporting of the configured monitoring event, the HSS shall forward the monitoring event configuration to the serving node and wait for the answer before sending the Configuration Information Answer to the SCEF. The monitoring event configuration status from the serving node for each event shall be conveyed by the HSS to the SCEF. The Result-Code shall be set to DIAMETER_SUCCESS in the Configuration Information Answer.

7. If the user is not registered in any serving node or the user is purged in the registered serving node (s) , the HSS shall store the configuration data related to the service; also, it shall indicate to the SCEF that the user is absent, in the Configuration Information Answer, by setting the relevant bit in the S6t-HSS-Cause IE. The Result-Code shall be set to DIAMETER_SUCCESS in the Configuration Information Answer.

8. For Monitoring, if the data related to an immediate reporting is available in the HSS, the HSS (e.g. as being received from the MME/SGSN in the Insert Subscriber Data answer) shall include this data in the Configuration Information Answer.

If the HSS is aware that the UE is registered in an MME and an SGSN and the services supported by the MME and SGSN are different, the HSS shall additionally report the capabilities of the different nodes to the SCEF by including Supported-Services AVP (s) with the subset of services supported by the serving node (s) among those supported by the HSS, as indicated by the Node-Type AVP (e.g. HSS, MME) . If the capabilities are the same reported from the MME, the SGSN and the HSS, the HSS shall report the service capabilities without Node-Type to the SCEF. If the Supported-Services of the SGSN and MME are different and the UE is purged in SGSN or MME the HSS shall report the Supported-Services to the SCEF excluding the Supported-Services from the purged node.

If the HSS receives CIR command from SCEF and has sent IDR commands over S6a/S6d to an MME and an SGSN, the HSS shall check the Result-Codes in Monitoring-Event-Config-Status AVPs reported by the MME and the SGSN:

- if they are different, the HSS shall include both Service-Report AVPs with the respective Node-Type (indicating the type of serving node) in the Monitoring-Event-Config-Status AVP to the SCEF in the CIA command;

- otherwise, the HSS shall include one Service-Report AVP without Node-Type in the Monitoring-Event-Config-Status AVP to the SCEF in the CIA command.

If the configuration data in the CIR command are out of the allowed range, the HSS shall set the Experimental-Result-Code in Monitoring-Event-Config-Status for the affected service (s) to DIAMETER_ERROR_REQUESTED_RANGE_IS_NOT ALLOWED (5512) .

If the received SCEF Reference ID for Deletion does not exist, the HSS shall set the Experimental-Result-Code in Monitoring-Event-Config-Status for the affected service (s) to DIAMETER_ERROR_CONFIGURATION_EVENT_NON_EXISTANT (5514) .

If the SCEF Reference ID exists and the old configuration data could not be replaced by new Configuration event data, the HSS shall set the Experimental-Result-Code in Monitoring-Event-Config-Status for the affected service (s) to DIAMETER_ERROR_CONFIGURATION_EVENT_STORAGE_NOT_SUCCESSFUL (5513) .

If the HSS cannot fulfil the received request for reasons not stated in the above steps (e.g. due to a database error) , it shall stop processing the request and set Result-Code in Configuration Information Answer to DIAMETER_UNABLE_TO_COMPLY.

If the HSS detects that configuration data provided by a Monitoring-Event-Configuration are overwritten by a CIR command and both configurations were initiated by the same SCEF, the HSS shall include in the CIA command the Monitoring Event Report AVP including the SCEF Reference ID of the overwritten configuration data in the SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion AVPs.

If the HSS needs to report loss of connectivity it shall include the Monitoring-Type AVP set to "LOSS_OF_CONNECTIVITY" in the Monitoring Event Report. In addition, the HSS may also include the Loss-Of-Connectivity-Reason AVP in the Monitoring Event Report.

For the "CHANGE_OF_IMSI_IMEI (SV) _ASSOCIATION" event type, if there was no previous IMEI (SV) information stored in the HSS, and a new IMEI (SV) is received from the MME/SGSN, this is equivalent to a change of IMEI (SV) and the corresponding event shall be reported, by setting the "IMEI" flag (bit 0) in the IMEI-Change AVP, as described in clause 8.4.22.

For the "ROAMING_STATUS" event type, if there was no previous roaming status information stored in the HSS, and a certain PLMN ID value is received from the MME/SGSN, this is equivalent to a change of roaming status and the corresponding event shall be reported.

If the SCEF indicates the support of Monitoring event feature to the HSS and the HSS supports Monitoring. The HSS shall include the Supported-Services AVP with the Supported-Monitoring-Events AVP indicating the authorized monitoring events for the requesting SCEF in the CIA command.

If CIR message includes multiple SCEF Reference ID and one, several or all SCEF Reference ID Monitoring events cannot be handled, or fail to be configured at the registered serving node (s) , the HSS shall report all SCEF-Reference-ID requested to the SCEF with an appropriate Experimental-Result-Code or Result-Code in the Monitoring-Event-Config-Status AVP (s) .

NOTE: In order to avoid reattempts from the SCS/AS when some configuration failed at the serving node (s) , based on operator's choice, the HSS can still store the configuration data, return a successful response to SCEF and report the SCEF with monitoring event (s) suspended. The configuration data can then be forwarded whenever traffic is received from MME/SGSN and event (s) can be reported to SCEF as resumed, as described in chapter 7.2.2.

If a CIR message includes multiple SCEF Reference ID and for a SCEF Reference ID at least one CP parameter set cannot be handled, the HSS shall reply within the AESE-Communication-Pattern-Config-Status all SCEF Reference ID requested to the SCEF with an appropriate Experimental-Result-Code or Result-Code.

If an SCEF Reference ID received in a CIR command match with an SCEF Reference ID stored in the HSS and both SCEF Reference ID are provided by the same SCEF ID, the HSS shall delete the stored CP sets associated with the SCEF reference Id and store the new CP set (s) .

If the CIR message contains combinations of monitoring events and CP parameter set it shall handle each set belonging to an SCEF Reference ID separately and shall send a combined answer to the SCEF with all SCEF Reference IDs requested.

If the SCEF-Reference-ID-for-Deletion is present, the receiving node shall delete the corresponding configuration, if stored.

If the SCEF-Reference-ID is present, the receiving node shall store the configuration event.

IF the CIR message contains the CIR-Flags with delete all monitoring events, the HSS shall delete all Monitoring events configured by the SCEF for the subscriber. This includes forwarding the deletion to involved serving nodes.

If the CIR message contains the CIR-Flags with delete all communication pattern, and the feature Config-Eff-CP is supported, the HSS shall delete all Communication Pattern configured by the SCEF for the subscriber. This includes forwarding the deletion to involved serving nodes.

If the CIR message contains the CIR-Flags with delete all network parameter configurations, and the feature Config-Eff-NP is supported, the HSS shall delete all Suggested Network Configurations configured by the SCEF for the subscriber. This includes the updating of involved serving nodes.

If the CIR command contains the CIR-Flags AVP with the bit for Enhanced Coverage Query set, the HSS shall return the current settings of Enhanced Coverage together with the current Serving PLMN-ID (if any) in the CIA command.

If the CIR command contains Enhanced-Coverage-Restriction AVP, the HSS shall update the subscription data for Enhanced Coverage; the update shall be a complete replacement of any stored information with the received information. This may result in the need to update the MME/SGSN via S6a/d/MAP-Gr with the new value for access restriction; there is however no need for the HSS to delay sending of CIA until updates of serving nodes are confirmed.

If the CIR command contains Suggested-Network-Configuration AVP, the HSS shall check whether the suggested parameters are acceptable, and if so, update the stored UE's subscription parameters accordingly and overwrites the old SCEF-Reference-ID and SCEF-ID with the new values. This may result in Insert Subscriber Data Signalling towards the UE's serving node. If the HSS modifies parameters received in Suggested-Network-Configuration AVP, the HSS shall inform the SCEF about the active parameters.

If a Monitoring-Event-Report is included in a CIA command and the Monitoring-Event-Report is related to a One-time Monitoring event request, the HSS shall delete the related Monitoring event for the UE or the individual group member UE locally after sending the Monitoring-Event-Report.

If the subscribed periodic RAU/TAU Timer, Active Time, Suggested number of downlink packets, or any combinatio was previously set by a different SCEF requests including the Monitoring-Event-Configuration AVP (s) or Suggested-Network-Configuration AVP identified by a different SCEF Reference ID for the same UE, the HSS shall accept the request as follows:

- If the newly received the value of the Maximum-Detection-Time AVP or the Maximum-Latency AVP within the Monitoring-Event-Configuration AVP (s) or the value of the Subscribed-Periodic-RAU-TAU-Timer AVP within the Suggested-Network-Configuration AVP is lower than the provided subscribed periodic RAU/TAU timer, the HSS shall set the subscribed periodic RAU/TAU timer using the newly received value.

- If the newly received the value of Maximum-Response-Time AVP within the Monitoring-Event-Configuration AVP (s) or the value of the Active-Time AVP within the Suggested-Network-Configuration AVP is higher than the provided subscribed Active Time (i.e. previously provided Maximum Response Time) , the HSS shall set the subscribed Active Time using the newly received value.

- If the DL-Buffering-Suggested-Packet-Count AVP is newly received within the Monitoring-Event-Configuration AVP (s) or Suggested-Network-Configuration AVP, the HSS shall set the subscribed Suggested number of downlink packets by adding the newly received value to the currently used value of Suggested number of downlink packets if the aggregated value is within the operator defined range. If the aggregated value is not within the operator defined range, the HSS shall set the subscribed Suggested number of downlink packets according to operator defined range.

***Next Change ****

7.2.2.2 Detailed Behaviour of the HSS

For group-based configuration processing, if the Group Guard Timer was included in the CIR command (i.e. the External Group Identifier is not identified as a Global Group Identifier) , the HSS shall send the RIR command before the Group Guard Timer expires and shall include several reports and/or status indications in one or more Group Report AVPs.

NOTE: The HSS may divide the accumulated Monitoring Configuration Indications/immediate reports into multiple messages.

The HSS shall send immediate reports and/or status indications (for Monitoring Event Configurations) and/or Network Parameter Configurations (for Suggested Network Configurations) for group-based configuration processing using the Group-Report.

If the HSS knows that it has additional RIR commands to send for the same group, the HSS shall include the RIR-Flags AVP with the Group-Configuration-In-Progress bit set and restart the Group Guard Timer to the value it originally received in the CIR.

For group based configuration processing, if the MME/SGSN previously indicated that it does not support the External-Identifier in the ULR command and the UE does not have an MSISDN configured as part of its subscription data, the HSS shall indicate that the UE is absent by setting the relevant bit in the S6t-HSS-Cause IE of the Group Report-Item AVP.

If the HSS detects that configuration data provided by a Monitoring-Event-Configuration are overwritten by a new CIR command and the configurations were initiated by different SCEFs, the HSS shall initiate an RIR command and include a Monitoring-Event-Report AVP including the SCEF Reference ID of the overwritten configuration data and provide the SCEF Reference ID in the SCEF-Reference-ID-for-Deletion AVP.

If the HSS updates a previously accepted Network Parameter Configuration (s) , e.g. Active Time is updated due to several SCS/AS suggesting different values for the same network parameter (s) for the same UE (see 3GPP TS 23.682 [2] , clause 5.6.1.4) , the HSS may initiate a RIR command providing the SCEF Reference ID of the previous Network Parameter Configurations and include the Updated-Network-Configuration AVP including only those parameter configuration (s) which have been updated and are being applied in the network.

If the HSS detects that suggested network configuration data provided by a Configuration Information Request are overwritten by a new CIR command and the configurations were initiated by different SCEFs, the HSS shall initiate an RIR command and include a Monitoring-Event-Report AVP including the SCEF Reference ID of the overwritten configuration data and provide the SCEF Reference ID in the SCEF-Reference-ID-for-Deletion AVP.

If the Monitoring-Event-Report is related to a One-time Monitoring event request, the HSS shall delete the related Monitoring event for the UE or the individual group member UE locally after sending the Monitoring-Event-Report. If UE Reachability is reported, a Maximum-UE-Availability-Time AVP may also be present in the report.

If the HSS detects that the serving node does not support or does not activate (as indicated in IDA or NOR commands) a Monitoring event, or if the UE is part of a group and requires the External-Identifier to be supported by the serving node when it does not, it shall send to the SCEF, an RIR command with the Event-Handling AVP with the value SUSPEND.

If an HSS detects that in the new serving node an event to be activated is supported which was not supported in the old serving node or if the HSS detects that the new serving node supports the External-Identifier for a UE that is part of a group and requires the External-Identifier which was not supported in the old serving node, it shall send an RIR command with the Event-handling AVP with the value RESUME to the SCEF.

If the HSS receives a Notify Request from the MME/SGSN to inform the Monitoring-Event-Config-Status at the IWK-SCEF, the HSS shall send an RIR command to the SCEF, for the monitoring event configurations not accepted by the IWK-SCEF, with the Event-Handling AVP set to the value CANCEL.

If the HSS receives a Notify Request from the MME/SGSN to inform that monitoring event configuration (s) no longer exist in the SCEF (DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN in Monitoring-Event-Config-Status) , the HSS shall locally delete the monitoring event configuration (s) and shall skip the sending of a RIR command to the SCEF.

If the HSS receives the DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN within an RIA command, it shall delete the event stored for the indicated SCEF-Reference-ID (see 3GPP TS 23.007 [19] ) .

If the Supported-Services of the SGSN and/or MME have been previously reported to the SCEF, an the HSS detects that they have changed from a previous report, the HSS shall report all the Supported-Services AVP (s) to the SCEF with the corresponding Node-Type AVP (e.g. HSS, MME) If the services supported and authorized by the HSS are the same than those supported by the serving node (s) , the Node-Type AVP shall be absent.

If a subscriber is barred/un-barred for services relevant to an active monitoring, the HSS shall send an RIR command to the SCEF with the Event-Handling AVP set to the value SUSPEND/RESUME.

NOTE: When there is an HSS-initiated detach (e.g. due to MM interaction) or when the subscriber is purged in registered serving node (s) while monitoring is active, the sending of a RIR command to the SCEF is not needed since it is assumed that any SCS/AS requiring to be notified when this event is detected has configured monitoring event Loss of connectivity as specified in 3GPP TS 23.682 [2] , clause 5.6.8.2.

If authorization for one or more events is granted or revoked for an SCEF and the Report-Eff-MONTE is supported by HSS and SCEF, the HSS shall send RIR command with RIR-flags indicating that authorization has changed for one or more events. The Supported-Monitoring-Events AVP shall indicate the authorized or revoked authorization for each event.

When a subscriber is deleted from the HSS while monitoring is active or the authorization for monitoring is revoked, if Report-Eff-MONTE feature is not supported by SCEF or HSS, the HSS shall send an RIR command to the SCEF with the Event-Handling AVP set to the value CANCEL. If the HSS and SCEF support the Report-Eff-MONTE feature, the HSS shall make use of RIR-flags AVP for a given User-Identity and no Monitoring-Event-Report AVP(s) shall be included.

When a subscriber is deleted from the HSS or the authorization for communication pattern is revoked while communication pattern are configured, and the Config-Eff-CP feature is supported by SCEF and HSS, the HSS shall make use of the RIR-flag "All-Communication-Pattern-Cancelled" to indicate removal of Communication Pattern for a given User-Identity.

***Next Change ****

8.4.36 User-Identifier

The User-Identifier AVP is of type Grouped and it contains the different identifiers used by the UE. This AVP is defined in clause 6.4.2. The AVP format for the S6t interface shall be as given below.

AVP format:

User-Identifier : : = <AVP header: 3102 10415>

[User-Name]

[MSISDN]

[External-Identifier]

[Type-Of-External-Identifier]

* [AVP]

This AVP shall contain one of the identifiers (IMSI, MSISDN or External-Identifier) . The IMSI of the UE shall be included (when applicable) in the User-Name AVP.

The External-Identifier AVP may either contain the identity of an individual UE or the identity of a Group of UEs or the identity identified as Global Group. The Type-Of-External-Identifier is used to indicate which type of identity is carried in the External-Identifier. When the Type-Of-External-Identifier is not present, it means the External-Identifier AVP contains the identity of an individual UE.

***Next Change ****

8.4.8 Maximum-Number-of-Reports

The Maximum-Number-of-Reports AVP is of type Unsigned32. It shall contain the number of reports to be generated and sent to the SCEF.

This AVP shall not be present when Monitoring-Type is AVAILABILITY_AFTER_DDN_FAILURE (6) or when the External Group is identified as a Global Group.

This AVP shall not be greater than one if:

- Monitoring-Type is UE_REACHABILITY (1) and Reachability-Type is "Reachability for SMS" or

- Monitoring-Type is LOCATION_REPORTING (2) and MONTE-Location-Type is LAST_KNOWN_LOCATION (1) .

***Next Change ****

8.4.64 Type-Of-External-Identifier

The Type-Of-External-Identifier AVP is of type Unsigned32 and it shall indicate which type of identity is carried in the External-Identifier AVP. The following values are defined:

EXTERNAL-UE-IDENTIFIER-TYPE (0)

The value 0 indicates the External-Identifier AVP carries the identity of an individual UE.

EXTERNAL-GROUP-IDENTIFIER-TYPE (1)

The value 1 indicates the External-Identifier AVP carries the identity of a Group of UEs.

GLOBAL-GROUP-IDENTIFIER-TYPE (2)

The value 2 indicates the External-Identifier AVP carries an identity which has been identified as a Global Group (all UEs) . A Global Group Identifier may only be used if the monitoring event is either IMEI (SV) change or Roaming Status.

***End of Change ****

In an embodiment, the following clauses of 3GPP TS 23.682 V16.7.0 may be amended as following.

***First Change ****

4.6.3x Global Group Identifier

The Global Group Identifier is an External Group Identifier which applies to any UE managed by the HSS. It is used on the interface between the SCS/AS and the SCEF and on the interface between the SCEF and the HSS. This identifier is used in monitoring event configuration and deletion for all UEs managed by the HSS.

When the Global Group Identifier is used in monitoring event configuration, the SCEF shall be able to identify the External Group Identifier as a Global Group Identifier and indicate HSS that the External Group Identifier is a Global Group Identifier.

NOTE: How the SCEF identifies an External Group Identifier as Global Group Identifier is implementation specific (e.g. SCEF can use the External Group Identifier in combination with the MTC Provider Information) .

When a Global Group Identifier is used, HSS does not inform that Group processing is in progress for each individual UE and the number of UEs is not provided to SCEF. Similarly, Maximum Number of Reports is not applicable for Global Group Identifiers (i.e. only Monitoring Duration is used) .

An External Group Identifier identified as Global Group Identifier does not map to an IMSI-Group Identifier.

***Next Change ****

5.6.0 Common Parameters

This clause describes the common parameters required for Monitoring Event procedures.

SCEF Reference ID is a parameter created by the SCEF to associate a Monitoring Event report or a deletion of a Monitoring Event to a specific Monitoring Request and the associated context information within the SCEF. SCEF Reference ID is stored by HSS, MME, SGSN, and IWK-SCEF.

NOTE 1: For the case of an individual UE, an SCEF may aggregate Monitoring Event configuration requests for the same External identifier/MSISDN from different SCS/AS instances.

NOTE 2: For the case of groups, an SCEF may aggregate Monitoring Event configuration requests for the same External Group Identifier from different SCS/AS instances.

SCEF ID indicates the SCEF to which the Monitoring Indication message has to be sent to by the HSS, MME, SGSN, or IWK-SCEF. SCEF ID is stored by the HSS, MME, SGSN, and IWK-SCEF.

SCEF Reference ID for Deletion identifies the monitoring event configuration that shall be deleted before applying the requested monitoring event configuration.

Monitoring Type identifies the specific Monitoring Event being requested.

If the Monitoring Event Configuration requested from the SCEF is for a group of UEs, the HSS includes User Identity in the monitoring event configuration.

Maximum Number of Reports is an optional parameter that indicates the maximum number of event reports to be generated by the HSS, MME, or SGSN until the associated monitoring event is considered to expire. This parameter can be used when configuring a monitoring event for an individual UE or a group not identified as Global. When the parameter is configured for a group, the configured value is applied to each individual UE's monitoring event configuration. A value of one implies a single event report is to be generated which makes it equivalent to a One-time Monitoring Request.

Monitoring Duration is an optional parameter that indicates the absolute time at which the related monitoring event request is considered to expire. For Monitoring Requests for a group not identified as Global, this parameter applies to every group member UE. For Monitoring Requests for a group identified as Global, this parameter applies to all UEs managed by the HSS.

Inclusion of either Maximum Number of Reports (with a value higher than one) or Monitoring Duration makes the Monitoring Request a Continuous Monitoring Request. For a Continuous Monitoring Request, a single Monitoring Request may generate more than one Monitoring Indication message. Support of continuous monitoring is optional.

Absence of both Maximum Number of Reports and Monitoring Duration makes the Monitoring Request a One-time Monitoring Request. For One-time Monitoring Requests, a single Monitoring Request generates only one Monitoring Report for an individual UE and for an individual group member UE.

If for a given Monitoring Event both Maximum Number of Reports and Monitoring Duration are included then the monitoring request is considered to expire as soon as one of the conditions is met.

Chargeable Party Identifier is an optional parameter included by the SCEF. It identifies the entity towards which accounting/charging functionality is performed by the involved 3GPP network elements.

MTC Provider Information is an optional parameter included by the SCEF. It identifies the MTC Service Provider and/or MTC Application. Optionally the MTC Provider Information may also be provided by the SCS/AS.

Group Reporting Guard Time is an optional parameter for group-based monitoring configuration. The parameter is not applicable if the group is identified as Global Group. It is used to indicate the time for which the Monitoring Event Reporting (s) detected by the UEs in a group can be aggregated before sending them to the SCEF/SCS/AS. The value of the Group Reporting Guard time should be set less than the Monitoring Duration. For the continuous monitoring reporting, unless the Monitoring Duration has been reached, the Group Reporting Guard timer is restarted when it expires. If the time left until Monitoring Duration is less than the Group Reporting Guard Time, then the Group Reporting Guard timer shall be set to expire when the Monitoring Duration expires. If the Monitoring Duration is expired, the Group Reporting Guard Time, if running, shall be considered to expire and aggregated Monitoring Event Reporting (s) is sent to destination immediately.

Number of UEs is a parameter that is provided to the SCEF during group-based monitoring configuration if the group is not identified as Global. It is used to indicate the number of UEs within the group identified by the External Group Identifier. The SCEF uses this value to determine whether the monitoring event has been reported for all group member UEs.

***Next Change ****

5.6.1.1 Configuration Procedure

FIG. 10 illustrates the procedure of configuring monitoring at the HSS or the MME/SGSN. The procedure is common for various Monitoring Event types. Common parameters for this procedure are detailed in clause 5.6.0. The steps and parameters specific to different Monitoring Event types are detailed in clauses 5.6.1.3 to 5.6.1.9.

The procedure is also used for deleting a previously configured Monitoring Event either as a standalone procedure or together with configuring a new Monitoring Event between the same SCEF and the same SCS/AS, or replacing a previously configured Monitoring Event with a new Monitoring Event of the same type between the same SCEF and the same SCS/AS, or for one-time reporting in case the Configured Monitoring Event is available at the configured node.

1. The SCS/AS sends a Monitoring Request (External Identifier or MSISDN or External Group ID, SCS/AS Identifier, Monitoring Type, Maximum Number of Reports, Monitoring Duration, T8 Destination Address, TLTRI for Deletion, Group Reporting Guard Time, MTC Provider Information) message to the SCEF. The SCEF assigns a TLTRI that identifies the Monitoring Request. If the SCS/AS may perform deletion of a previously configured Monitoring Event together with configuring a new Monitoring Event. If the SCS/AS wants to perform deletion of a previously configured Monitoring Event, then it shall include TLTRI for Deletion.

If the SCS/AS wants to configure Monitoring Event for the group of UEs, the SCS/AS can send Monitoring Request message including External Group Identifier and optionally Group Reporting Guard Time. If the SCS/AS includes External Group Identifier in the Monitoring Request message, External Identifier or MSISDN shall be ignored. A Group Reporting Guard Time is an optional parameter to indicate that aggregated Monitoring Event Reporting (s) which have been detected for the UEs in a group needs to be sent to the SCS/AS once the Group Reporting Guard Time is expired.

NOTE 1: A relative priority scheme for the treatment of multiple SCS/AS Monitoring Requests, e.g. for deciding which requests to serve under overload condition, can be applied. This priority scheme is used locally by the SCEF, i.e. it is not used nor translated in procedures towards other functions.

2. The SCEF stores SCS/AS Identifier, T8 Destination Address, Monitoring Duration, Maximum Number of Reports and Group Reporting Guard Time, if provided. The SCEF stores the TLTRI, and also assigns it to an SCEF Reference ID. Based on operator policies, if either the SCS/AS is not authorized to perform this request (e.g. if the SLA does not allow for it) or the Monitoring Request is malformed or the SCS/AS has exceeded its quota or rate of submitting monitoring requests, the SCEF performs step 9 and provides a Cause value appropriately indicating the error. If the SCEF received a TLTRI for Deletion, the SCEF looks up the SCEF context pointed to by the TLTRI to derive the related SCEF Reference ID for Deletion.

The SCEF uses the Group Reporting Guard Time for a Monitoring Event Reporting for the group of UEs when the Monitoring Indication message is sent from the MME/SGSN to the SCEF. The SCEF sets the Group Reporting Guard Time for HSS less than the value for the SCEF received from SCS/AS in order to ensure to receive accumulated Monitoring Indication from HSS before the Group Reporting Guard Timer for SCEF is expired.

3. The SCEF sends a Monitoring Request (External Identifier or MSISDN or External Group Identifier, SCEF ID, SCEF Reference ID, Monitoring Type, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier, Group Reporting Guard Time, MTC Provider Information) message to the HSS to configure the given Monitoring Event on the HSS and on the MME/SGSN, if required. If the External Group Identifier is included, External Identifier or MSISDN shall be ignored. For Monitoring Request of Roaming Status and/or change of IMSI-IMEI (SV) , the SCEF does not indicate the Group Reporting Guard Time. In addition, for Monitoring Request of Roaming Status and/or change of IMSI-IMEI (SV) , the SCEF may identify the External Group Identifier as a Global Group Identifier. If the External Group is a Global Group, the SCEF shall include an indication of Global Group Identifier towards the HSS.

NOTE 2: The MTC Provider Information in step 1 is an optional parameter. The SCEF should validate the provided MTC Provider Information and may override it to an SCEF selected MTC Provider Information based on configuration. How the SCEF determines the MTC Provider Information if not present in step 1 is left to implementation (e.g. based on the requesting SCS/AS) .

4. The HSS examines the Monitoring Request message, e.g. with regard to the existence of External Identifier or MSISDN or External Group Identifier, whether any included parameters are in the range acceptable for the operator, whether the monitoring event (s) is supported by the serving MME/SGSN, whether the group-basis monitoring event feature is supported by the serving MME/SGSN, or whether the monitoring event that shall be deleted is valid. The HSS optionally authorizes the chargeable party identified by Chargeable Party Identifier. If this check fails the HSS follows step 8 and provides a Cause value indicating the reason for the failure condition to the SCEF.

NOTE 3: The details of the chargeable party authorization are outside the scope of this specification.

The HSS stores the SCEF Reference ID, the SCEF ID, Maximum Number of Reports, Monitoring Duration and the SCEF Reference ID for Deletion as provided by the SCEF. For a Monitoring Request for a group not identified as global, such parameters are stored for every group member UE.

The HSS uses the Group Reporting Guard Time for a Monitoring Event Reporting for the group of UEs not identified as Global when the Monitoring Indication message is sent from the HSS to the SCEF.

4a. For group based processing, if the HSS receives the Monitoring Request with an External Group Identifier, the HSS sends a Monitoring Response (SCEF Reference ID, Number of UEs, Cause) message to the SCEF to acknowledge acceptance of the Monitoring Request immediately. If the group is not identified as Global, the HSS shall begin the processing of individual UEs indicating that Group processing is in progress. The HSS deletes the monitoring event configuration identified by the SCEF Reference ID, if it was requested.

4b. The SCEF sends a Monitoring Response (TLTRI, Cause) message to the SCS/AS. The Cause value indicates progress of Group processing request.

5. If required by the specific Monitoring Type and when Monitoring Event (s) is supported by the serving MME/SGSN, the HSS sends an Insert Subscriber Data Request (Monitoring Type, SCEF ID, SCEF Reference ID, Maximum Number of Reports, Monitoring Duration, SCEF Reference ID for Deletion, Chargeable Party Identifier) message to the MME/SGSN for each individual UE and for each individual group member UE. If the Monitoring Request message is for a group of UEs, for each UE group member, the HSS includes the selected External ID or the MSISDN in the monitoring event configuration and sends an Insert Subscriber Data Request message per UE to all the MME/SGSN (s) serving the members of the group. Optionally, the HSS allocates a Provider-Group-ID based on the MTC Provider Information (different from the IMSI-Group-Id) and sends it to the MME/SGSN to assist the serving node (s) when selecting and differentiating configurations for a given MTC Service Provider (e.g. to delete the configurations for a specific MTC Service Provider at the MME/SGSN) .

NOTE 4: How the HSS selects an External ID when multiple External IDs are associated with the same IMSI is left to implementation, e.g. based on the MTC Provider Information (if received) or the default External ID (if not received)

NOTE 5: The Provider-Group-ID is used for group operations e.g. as specified in TS 23.401 [7] , clause 4.3.7.4.2 NAS level congestion control.

6. If the MME/SGSN is configured to use an IWK-SCEF for the PLMN of the SCEF then clause 5.6.6 applies. Otherwise, the MME/SGSN verifies the request, e.g. if the Monitoring Type is covered by a roaming agreement when the request is from another PLMN or whether it serves the SCEF Reference ID for Deletion and can delete it. If this check fails, the MME/SGSN follows step 7 and provides a Cause value indicating the reason for the failure condition to the HSS. Based on operator policies, the MME/SGSN may also reject the request due to other reasons (e.g. overload or HSS has exceeded its quota or rate of submitting monitoring requests defined by an SLA) .

The MME/SGSN stores the received parameters and starts to watch for the indicated Monitoring Event unless it is a One-time request and the Monitoring Event is available to the MME/SGSN at the time of sending Insert Subscriber Data Answer. The MME/SGSN deletes the monitoring configuration identified by the SCEF Reference ID for Deletion, if provided.

NOTE 6: The MME/SGSN will transfer the parameters stored for every monitoring task as part of its context information during an MME/SGSN change.

7. If the monitoring configuration is successful, the MME/SGSN sends an Insert Subscriber Data Answer (Cause) message to the HSS. If the requested Monitoring Event is available to the MME/SGSN at the time of sending Insert Subscriber Data Answer, then the MME/SGSN includes the Monitoring Event Report in the Insert Subscriber Data Answer message.

8. For single UE processing, the HSS sends a Monitoring Response (SCEF Reference ID, Cause, Monitoring Event Report) message to the SCEF to acknowledge acceptance of the Monitoring Request and the deletion of the identified monitoring event configuration, if it was requested. The HSS deletes the monitoring event configuration identified by the SCEF Reference ID, if it was requested. If the requested Monitoring Event is available to the HSS at the time of sending Monitoring Response message or was received from the MME/SGSN in step 7, then the HSS includes a Monitoring Event Report in the Monitoring Response message.

If it is a One-time request and the Insert Subscriber Data Answer includes a Monitoring Event Report, the HSS deletes the associated Monitoring Event configuration for the individual UE or for the individual group member UE.

For group-based processing, if the HSS sent the Monitoring Response in step 4a, i.e. due to having received a Monitoring Request with an External Group Identifier not identified as Global and if the Group Reporting Guard Time was provided in the Monitoring Request, the HSS accumulates multiple responses for the UEs of the group within the Group Reporting Guard Time. After the Group Reporting Guard Time expiration, the HSS sends a Monitoring Indication with the accumulated responses. The HSS includes UE identity (ies) and a Cause value indicating the reason for the failure in the message if the monitoring configuration of the group member failed.

NOTE 7: For the group-basis Monitoring Event configuration, the HSS may divide the accumulated Monitoring Indications into multiple messages due to e.g. limitation of the message size.

In the case of UE mobility, the HSS determines whether the new MME/SGSN supports requested Monitoring Event (s) .

9a. For single UE processing, the SCEF sends a Monitoring Response (Cause, Monitoring Event Report) message to the SCS/AS to acknowledge acceptance of the Monitoring Request and the deletion of the identified monitoring event configuration, if it was requested. If the SCEF received a Monitoring Event Report then it includes the Monitoring Event Report in the Monitoring Response message. If it is a One-time request for an individual UE and the Monitoring Response includes a Monitoring Event Report for the UE, the SCEF deletes the associated Monitoring Event configuration.

9b. For group-based processing, if no Group Reporting Guard Time was set, then the SCEF sends the Monitor Indication (TLTRI, Cause, Monitoring Event Report) message to the SCS/AS as it receives them from the HSS. Otherwise, it accumulates Monitoring Event for the UEs of the group until the expiration of Group Reporting Guard Time. Upon expiration, the SCEF sends a Monitoring Indication (TLTRI, Cause, list of (External Identifier or MSISDN, Monitoring Event Report) ) message to the SCS/AS. A list of accumulated Monitoring Event Report for each UE identified by either External Identifier or MSISDN is also included.

If the Monitoring Request is a one-time request for a group of UEs, the SCEF uses the list of UE Identities that were received in step 8 and the Number of UEs parameter that was received in step 4a to check if the reports for all the individual group member UEs have been received. If the SCEF determines that a report for all individual group member UEs have been received, the SCEF sends a request to the HSS to delete the associated Monitoring Event configuration for the group.

9c. For each Monitoring Indication message received in step 9b, the SCS/AS sends a Monitoring Indication Response (Cause) message to the SCEF. Cause value reflects successful or unsuccessful acknowledgement of Monitoring Indication message.

If the HSS detects that the current serving MME/SGSN cannot support a requested Monitoring Event or the group-basis monitoring event feature (e.g. after a UE mobility event) , the HSS performs the procedures given below.

- Notify the SCEF that the configured Monitoring Event for the UE is considered to be suspended. The SCEF interprets this to mean that the network will temporarily be unable to serve the configured Monitoring Event. In this case:

- When the MME/SGSN for the UE changes (e.g. due to UE mobility) , and the new MME/SGSN supports the suspended Monitoring Event, the HSS shall configure the new MME/SGSN with the Monitoring Event and notify the SCEF of resumption of the suspended Monitoring Event;

- If the criteria for Continuous Reporting expire while the Monitoring Event is suspended, the HSS and the SCEF shall independently delete the Monitoring Event.

***Next Change ****

5.6.2.1 Configuration Procedure

FIG. 11a illustrates the procedure of configuring monitoring at the MME/SGSN. The procedure is common for various monitoring event types. Common parameters for this procedure are detailed in clause 5.6.2.2. The steps specific to different Monitoring Event types are detailed in clause 5.6.2.3. This procedure is not applicable for group configuration.

1. The SCS/AS sends a Monitoring Request (SCS/AS Identifier, Monitoring Type, Monitoring Duration, Maximum Number of Reports, T8 Destination Address, TLTRI for Deletion) message to the SCEF. The SCEF assigns a TLTRI that identifies the Monitoring Request.

NOTE: A relative priority scheme for the treatment of multiple SCS/AS Monitoring Requests, e.g. for deciding which requests to serve under overload condition, can be applied. This priority scheme is used locally by the SCEF, i.e. it is not used nor translated in procedures towards other functions.

2. The SCEF stores the TLTRI, and also assigns it to an SCEF Reference ID. Based on operator policies, if either the SCS/AS is not authorized to perform this request (e.g. if the SLA does not allow for it) or the Monitoring Request is malformed or the SCS/AS has exceeded its quota or rate of submitting monitoring requests, the SCEF performs step 6 and provides a Cause value appropriately indicating the error. The SCEF stores the Monitoring Duration, the Maximum Number of Reports, the T8 Destination Address, the SCS/AS Identifier. If the SCEF received a TLTRI for Deletion, the SCEF looks up the SCEF context pointed to by the TLTRI to derive the related SCEF Reference ID for Deletion. If an External Group Identifier (s) was included in the request of step 1, then then flow proceeds to step 2a, otherwise steps 2a and 2b are skipped.

2a. When the SCS/AS includes External Group Identifier (s) in the monitoring request, the SCEF sends an External Group ID Resolution Request (External Group Identifier (s) ) message to the HSS.

2b. The HSS resolves the External Group Identifier (s) , if not identified as Global, to IMSI-Group Identifier (s) and sends an External Group ID Resolution Response (IMSI-Group Identifier (s) ) message to the SCEF.

3. The SCEF sends a Monitoring Request (SCEF ID, SCEF Reference ID, Monitoring Type, Monitoring Duration, Maximum Number of Reports, SCEF Reference ID for Deletion) message to the MME (s) /SGSN (s) .

4. The MME/SGSN examines whether it can accept the request from that SCEF based on operator configuration or whether it serves the SCEF Reference ID for Deletion and can delete it. If acceptable, the MME/SGSN stores SCEF ID, SCEF Reference ID, Monitoring Duration, Maximum Number of Reports and other relevant parameters unless it is a One-time request and the Monitoring Event is available to the MME/SGSN at this time. The MME/SGSN deletes the monitoring configuration identified by the SCEF Reference ID for Deletion, if provided.

5. The MME/SGSN sends a Monitoring Response (SCEF Reference ID, Cause, Monitoring Event Report) message to the SCEF to acknowledge acceptance of the Monitoring Request and to provide the requested monitoring information or to acknowledge the deletion of the identified monitoring event configuration, if it was requested.

6. The SCEF sends a Monitoring Response (TLTRI, Cause, Monitoring Event Report) message to the SCS/AS to acknowledge acceptance of the Monitoring Request and to provide the requested monitoring information in Monitoring Event Report parameter or to acknowledge the deletion of the identified monitoring event configuration, if it was requested.

***Next Change ****

5.6.3.1 Reporting Procedure

FIG. 11b illustrates the common procedure flow of reporting Monitoring Events that are detected by the MME/SGSN or HSS. The steps specific to different Monitoring Event types are detailed in clauses 5.6.3.2 to 5.6.3.8.

1a. A Monitoring Event is detected by the MME/SGSN at which the Monitoring Event is configured.

1b. Either a Monitoring Event is detected by the HSS, or the HSS needs to inform the SCEF about the change of status (suspend/resume/cancel) of an ongoing monitoring if an event related with the change of monitoring support at the serving node, (e.g. lack of monitoring support in MME/SGSN or revocation of monitoring authorization) is detected in the HSS. The HSS also stores the time when the Event is detected or the status is changed.

2a. The MME/SGSN sends a Monitoring Indication (SCEF Reference ID (s) , Monitoring Event Report, User Identity) message to the SCEF. The SCEF store the time when it receives the Monitoring Indication.

If the Monitoring Event configuration was triggered by a One-time Monitoring Request, then the Monitoring Event configuration is deleted by the MME/SGSN upon completion of this step. If the MME/SGSN has a Maximum Number of Reports stored for this monitoring task, the MME/SGSN shall decrease its value by one. If the value of remaining number of reports is zero, the MME/SGSN shall locally remove the Monitoring Event Configuration. If the Monitoring Event configuration includes User Identity, the MME/SGSN sends the Monitoring Indication message including the User Identity. So that the SCEF can determine what groups the report pertains to, multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

2b. When reporting for an individual UE or individual Group Member UE, the HSS sends a Monitoring Indication (SCEF Reference ID (s) , External ID or MSISDN, Monitoring Event Report) message to the SCEF. External ID or MSISDN are only included if the indication is associated with an individual Group Member UE.If the Monitoring Event configuration was triggered by a One-time Monitoring Request, then the Monitoring Event configuration for the individual UE and for the individual group member UE is deleted by the HSS upon completion of this step. If the HSS has a Maximum Number of Reports stored for this monitoring task, the HSS shall decrease its value by one. Based on SCEF Reference ID, the SCEF can determine what groups the report pertains to. Multiple SCEF Reference IDs can be included if the UE is part of multiple groups that require the same monitoring indication.

If Group Reporting Guard Time was provided during the Monitoring Event configuration procedure, the HSS accumulates a Monitoring Event for the UEs of the group within the Group Reporting Guard Time. After the Group Reporting Guard Time expiration, the HSS send a Monitoring Indication (SCEF Reference ID, (Monitoring Event Report (s) , External ID or MSISDN) Set, External Group ID) message to the SCEF. For each group member UE all the Monitoring Event Report and the corresponding stored time (s) are sent to the SCEF.

The External Group ID may be included in the message to indicate that the event has been detected for all group members. When the External Group ID is included in the indication, External ID (s) and MSISDN (s) are optional.

NOTE: For the group-basis Monitoring Event configuration, the HSS may divide the accumulated Monitoring Event Reports into multiple Monitoring indication messages due to the limitation of the message size.

3a. Using the SCEF Reference ID, the SCEF retrieves the associated TLTRI along with the T8 Destination Address.

If the TLTRI refers to a Monitoring Event Configuration for a single UE, the SCEF sends a Monitoring Indication (TLTRI, Cause, Monitoring Event Report) message to the identified destination. If the TLTRI refers to a group-based Monitoring Event configuration, and if no Group Reporting Guard Time was set, then the SCEF sends a Monitoring Indication (TLTRI (s) , Cause, Monitoring Event Report) message to the identified destination. So that the SCEF can determine what groups the report pertains to, multiple TLTRIs can be included if the UE is part of multiple groups that require the same monitoring indication.

If the TLTRI refers to a group-based Monitoring Event Configuration, and if Group Reporting Guard Time was provided during the Monitoring Event configuration procedure, then the SCEF accumulates Monitoring Event for the UEs of the group until the Group Reporting Guard Time expiry. Upon expiration of which, the SCEF sends a Monitoring Indication (TLTRI, Cause, list of (External Identifier or MSISDN, Monitoring Event Report (s) ) ) message to the identified destination. A list of accumulated Monitoring Event Report for each group member UE identified by either External Identifier or MSISDN is also included. For each group member UE all the received Monitoring Event Report, and the corresponding time received at SCEF or the time value sent by HSS, are sent to the SCS/AS.

For individual UE, if a report is received (step 2a or step 2b) for One-time Monitoring Request or the maximum number of reports is reached for a Continuous Monitoring Request, the SCEF requests the HSS (for monitoring events configured via HSS) to delete the related monitoring event configuration for the individual UE and deletes also its associated Monitoring Event configuration according to the procedure of clause 5.6.1.1 step 3-8.

For an individual group member UE, if a report is received (step 2a or step 2b) for One-time Monitoring Request or the maximum number of reports is reached for a Continuous Monitoring Request, based on the Number of UEs received in step 4a in clause 5.6.1.1 and local policy, the SCEF shall either:

- request the HSS (for monitoring events configured via HSS) to delete the related monitoring event configuration for the individual group member UE; or

- wait until reports for all group member UEs are complete and then request the HSS (for monitoring events configured via HSS) to delete the related monitoring event configuration.

The SCEF uses the identity of individual group member UE (s) (i.e. External Identifier or MSISDN) received in the step 2a or step 2b and the Number of UEs received in step 4a in clause 5.6.1.1 to determine if reporting for the group is complete. If it is complete, the SCEF deletes the associated Monitoring Event configuration for the group.

3b. For each Monitoring Indication message received in step 3a, the SCS/AS sends a Monitoring Indication Response (Cause) message to the SCEF. Cause value reflects successful or unsuccessful acknowledgement of Monitoring Indication message.

When the Monitoring Duration expires for a continuous Monitoring Request in the HSS, the MME/SGSN or the SCEF, then each of these nodes shall locally delete the related Monitoring Event configuration associated with the individual UE or group member UE or the Global Group.

***Next Change ****

5.6.3.5 Reporting Event: Change of IMSI-IMEISV association

1b. This monitoring event is detected as of step 1b of clause 5.6.3.1, which is when the HSS receives from a serving node an IMEISV that is different from the IMEISV stored by the HSS for the IMSI.

2b. Step 2b of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed. The Monitoring Indication message includes the new IMEISV. Operator policies may allow this event to be applied to any UE managed by the HSS (i.e. SCEF may identify an External Group Identifier as Global Group Identifier)

***Next Change ****

5.6.3.6 Reporting Event: Roaming Status

1b. This monitoring event is detected as of step 1b of clause 5.6.3.1, which is when the HSS receives from a serving node a serving PLMN ID that is different from the one stored by the HSS.

2b. Step 2b of clause 5.6.3.1 is executed.

3. Step 3 of clause 5.6.3.1 is executed. The monitoring information indicates the ID of the serving PLMN and whether it is the home or a roaming PLMN. Operator policies may allow this event to be applied to any UE managed by the HSS (i.e. SCEF may identify an External Group Identifier as Global Group Identifier) . Additional operator policies in the SCEF may restrict the report, e.g. to indicate only whether the UE is in the

***End of Changes ****

FIG. 12 is a block diagram showing an apparatus suitable for practicing some embodiments of the disclosure. For example, any one of the exposure function entity, the application function entity and the data management entity described above may be implemented as or through the apparatus 1200.

The apparatus 1200 comprises at least one processor 1221, such as a digital processor (DP) , and at least one memory (MEM) 1222 coupled to the processor 1221. The apparatus 1220 may further comprise a transmitter TX and receiver RX 1223 coupled to the processor 1221. The MEM 1222 stores a program (PROG) 1224. The PROG 1224 may include instructions that, when executed on the associated processor 1221, enable the apparatus 1220 to operate in accordance with the embodiments of the present disclosure. A combination of the at least one processor 1221 and the at least one MEM 1222 may form processing means 1225 adapted to implement various embodiments of the present disclosure.

Various embodiments of the present disclosure may be implemented by computer program executable by one or more of the processor 1221, software, firmware, hardware or in a combination thereof.

The MEM 1222 may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memories and removable memories, as non-limiting examples.

The processor 1221 may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on multicore processor architecture, as non-limiting examples.

In an embodiment where the apparatus is implemented as or at the exposure function entity, the memory 1222 contains instructions executable by the processor 1221, whereby the exposure function entity operates according to any step of any of the methods related to the exposure function entity as described above.

In an embodiment where the apparatus is implemented as or at the data management entity, the memory 1222 contains instructions executable by the processor 1221, whereby the data management entity operates according to any step of the methods related to the data management entity as described above.

In an embodiment where the apparatus is implemented as or at the application function entity, the memory 1222 contains instructions executable by the processor 1221, whereby the application function entity operates according to any step of the methods related to the application function entity as described above.

FIG. 13 is a block diagram showing an exposure function entity according to an embodiment of the disclosure. As shown, the exposure function entity 1300 comprises a receiving module 1302 and a sending module 1304. The receiving module 1302 may be configured to receive a first monitoring request from an application function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity. The sending module 1304 may be configured to send a second monitoring request to the data management entity, wherein the second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.

FIG. 14 is a block diagram showing a data management entity according to an embodiment of the disclosure. As shown, the data management entity 1400 comprises a receiving module 1402 and a handling module 1404. The receiving module 1402 may be configured to receive a second monitoring request from an exposure function entity. The second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity. The handling module 1404 may be configured to handle the second monitoring request.

FIG. 15 is a block diagram showing an application function entity according to an embodiment of the disclosure. As shown, the application function entity 1500 comprises a sending module 1502. The sending module 1502 may be configured to send a first monitoring request to an exposure function entity. The first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity.

The term unit or module may have conventional meaning in the field of electronics, electrical devices and/or electronic devices and may include, for example, electrical and/or electronic circuitry, devices, modules, processors, memories, logic solid state and/or discrete devices, computer programs or instructions for carrying out respective tasks, procedures, computations, outputs, and/or displaying functions, and so on, as such as those that are described herein.

With function units, the exposure function entity, the application function entity or the data management entity may not need a fixed processor or memory, any computing resource and storage resource may be arranged from the exposure function entity, the application function entity or the data management entity in the communication system. The introduction of virtualization technology and network computing technology may improve the usage efficiency of the network resources and the flexibility of the network.

According to an aspect of the disclosure it is provided a computer program product being tangibly stored on a computer readable storage medium and including instructions which, when executed on at least one processor, cause the at least one processor to carry out any of the methods as described above.

According to an aspect of the disclosure it is provided a computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to carry out any of the methods as described above.

In addition, the present disclosure may also provide a carrier containing the computer program as mentioned above, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium. The computer readable storage medium can be, for example, an optical compact disk or an electronic memory device like a RAM (random access memory) , a ROM (read only memory) , Flash memory, magnetic tape, CD-ROM, DVD, Blue-ray disc and the like.

The techniques described herein may be implemented by various means so that an apparatus implementing one or more functions of a corresponding apparatus described with an embodiment comprises not only prior art means, but also means for implementing the one or more functions of the corresponding apparatus described with the embodiment and it may comprise separate means for each separate function or means that may be configured to perform one or more functions. For example, these techniques may be implemented in hardware (one or more apparatuses) , firmware (one or more apparatuses) , software (one or more modules) , or combinations thereof. For a firmware or software, implementation may be made through modules (e.g., procedures, functions, and so on) that perform the functions described herein.

Exemplary embodiments herein have been described above with reference to block diagrams and flowchart illustrations of methods and apparatuses. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functions specified in the flowchart block or blocks.

Further, while operations are depicted in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In certain circumstances, multitasking and parallel processing may be advantageous. Likewise, while several specific implementation details are contained in the above discussions, these should not be construed as limitations on the scope of the subject matter described herein, but rather as descriptions of features that may be specific to particular embodiments. Certain features that are described in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment may also be implemented in multiple embodiments separately or in any suitable sub-combination.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any implementation or of what may be claimed, but rather as descriptions of features that may be specific to particular embodiments of particular implementations. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. Conversely, various features that are described in the context of a single embodiment can also be implemented in multiple embodiments separately or in any suitable sub-combination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a sub-combination or variation of a sub-combination.

It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The above described embodiments are given for describing rather than limiting the disclosure, and it is to be understood that modifications and variations may be resorted to without departing from the spirit and scope of the disclosure as those skilled in the art readily understand. Such modifications and variations are considered to be within the scope of the disclosure and the appended claims. The protection scope of the disclosure is defined by the accompanying claims.

Claims

A method (200) performed by an exposure function entity, comprising:

receiving (202) a first monitoring request from an application function entity, wherein the first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity; and

sending (204) a second monitoring request to the data management entity, wherein the second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.
The method according to claim 1,

wherein the first monitoring request further comprises an indication of global group identifier; and

wherein the second monitoring request further comprises the indication of global group identifier.
The method according to claim 1, further comprising:

identifying (304) the external group identifier as a global group identifier,

wherein the second monitoring request further comprises an indication of global group identifier.
The method according to claim 3, wherein identifying the external group identifier as a global group identifier comprising:

identifying the external group identifier as the global group identifier based on a local policy.
The method according to claim 4, wherein the local policy is based on machine-type communication (MTC) provider information and the external group identifier.
The method according to claim 1, wherein the external group identifier is a global group identifier.
The method according to any of claims 1-6, wherein a group reporting guard timer and maximum number of reports are absent in both the first monitoring request and the second monitoring request.
The method according to any of claims 1-7, further comprising:

receiving (402) a first monitoring indication message from a network entity; and

sending (404) a second monitoring indication message to the application function entity.
The method according to any of claims 1-8, wherein the first monitoring request and the second monitoring request are used for configuration and/or deletion of monitoring events for all UEs managed by the data management entity.
The method according to claim 9, wherein the monitoring events for all UEs managed by the data management entity comprises at least one of:

association of a UE and Universal Integrated Circuit Card (UICC) and/or new international mobile subscriber identity, international mobile equipment identity software version (IMSI-IMEI-SV) association; or

roaming status of a UE, and change in roaming status of the UE.
The method according to any of claims 1-10, further comprising:

receiving (206) a second monitoring response from the data management entity, wherein a number of UEs belonging to a global group is absent in the second monitoring response.
The method according to any of claims 1-11, wherein the application function entity is an Application Function (AF) or Services Capability Server/Application Server (SCS/AS) .
The method according to any of claims 1-12, wherein the exposure function entity is a service capability exposure function (SCEF) or a network exposure function (NEF) or an SCEF+NEF.
The method according to any of claims 1-13, wherein the data management entity is a home subscriber server (HSS) or a unified data management (UDM) or a HSS+UDM.
A method (500) performed by a data management entity, comprising:

receiving (502) a second monitoring request from an exposure function entity, wherein the second monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity; and

handling (504) the second monitoring request.
The method according to claim 15, wherein the second monitoring request further comprises an indication of global group identifier.
The method according to claim 15, further comprising:

identifying (604) the external group identifier as a global group identifier.
The method according to claim 17, wherein identifying the external group identifier as a global group identifier comprising:

identifying the external group identifier as the global group identifier based on a local policy.
The method according to claim 18, wherein the local policy is based on machine-type communication (MTC) provider information and the external group identifier.
The method according to claim 15, wherein the external group identifier is a global group identifier.
The method according to any of claims 15-20, wherein a group reporting guard timer and maximum number of reports are absent in the second monitoring request.
The method according to any of claims 15-21, further comprising:

sending (508) a first monitoring indication message to the exposure function entity.
The method according to any of claims 15-22, wherein the second monitoring request is used for configuration and/or deletion of monitoring events for all UEs managed by the data management entity.
The method according to claim 23, wherein the monitoring events for all UEs managed by the data management entity comprises at least one of:

association of a UE and Universal Integrated Circuit Card (UICC) and/or new international mobile subscriber identity, international mobile equipment identity software version (IMSI-IMEI-SV) association; or

roaming status of a UE, and change in roaming status of the UE.
The method according to any of claims 15-24, further comprising:

sending (506) a second monitoring response to the exposure function entity, wherein a number of UEs belonging to a global group is absent in the second monitoring response.
The method according to any of claims 15-25, wherein the exposure function entity is a service capability exposure function (SCEF) or a network exposure function (NEF) or an SCEF+NEF.
The method according to any of claims 15-26, wherein the data management entity is a home subscriber server (HSS) or a unified data management (UDM) or a HSS+UDM.
The method according to any of claims 15-27, wherein handling the second monitoring request comprises at least one of:

skipping a check for authorization of a machine-type communication (MTC) provider identifier;

skipping a resolution of the external group identifier to an international mobile subscriber (IMSI) group identifier;

skipping a check of existence of the external group identifier; or

skipping sending of configuration progress reports to the exposure function entity.
A method (700) performed by an application function entity, comprising:

sending (702) a first monitoring request to an exposure function entity, wherein the first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity.
The method according to claim 29, wherein the first monitoring request further comprises an indication of global group identifier.
The method according to claim 29, wherein the external group identifier is a global group identifier.
The method according to any of claims 29-31, wherein a group reporting guard timer and maximum number of reports are absent in the first monitoring request.
The method according to any of claims 29-32, further comprising:

receiving (704) a second monitoring indication message from the exposure function entity.
The method according to any of claims 29-33, wherein the first monitoring request is used for configuration and/or deletion of monitoring events for all UEs managed by the data management entity.
The method according to claim 34, wherein the monitoring events for all UEs managed by the data management entity comprises at least one of:

association of a UE and Universal Integrated Circuit Card (UICC) and/or new international mobile subscriber identity, international mobile equipment identity, software version (IMSI-IMEI-SV) association; or

roaming status of a UE, and change in roaming status of the UE.
The method according to any of claims 29-35, wherein the application function entity is an Application Function (AF) or Services Capability Server/Application Server (SCS/AS) .
The method according to any of claims 29-36, wherein the exposure function entity is a service capability exposure function (SCEF) or a network exposure function (NEF) or an SCEF+NEF.
An exposure function entity (1200) , comprising:

a processor (1221) ; and

a memory (1222) coupled to the processor (1221) , said memory (1222) containing instructions executable by said processor (1221) , whereby said exposure function entity (1200) is operative to:

receive a first monitoring request from an application function entity, wherein the first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by a data management entity; and

send a second monitoring request to the data management entity, wherein the second monitoring request comprises the external group identifier identifying all UEs managed by the data management entity.
The exposure function entity according to claim 38, wherein the exposure function entity is further operative to perform the method of any one of claims 2 to 14.
A data management entity (1200) , comprising:

a processor (1221) ; and

a memory (1222) coupled to the processor (1221) , said memory (1222) containing instructions executable by said processor (1221) , whereby said data management entity (1200) is operative to:

receive a second monitoring request from an exposure function entity, wherein the second monitoring request comprises an external group identifier identifying all UEs managed by the data management entity; and

handle the second monitoring request.
The data management entity according to claim 40, wherein the data management entity is further operative to perform the method of any one of claims 16 to 28.
An application function entity (1200) , comprising:

a processor (1221) ; and

a memory (1222) coupled to the processor (1221) , said memory (1222) containing instructions executable by said processor (1221) , whereby said application function entity (1200) is operative to:

send a first monitoring request to an exposure function entity, wherein the first monitoring request comprises an external group identifier identifying all user equipments (UEs) managed by the data management entity.
The application function entity according to claim 42, wherein the application function entity is further operative to perform the method of any one of claims 30 to 37.
A computer-readable storage medium storing instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any one of claims 1 to 37.
A computer program product comprising instructions which when executed by at least one processor, cause the at least one processor to perform the method according to any of claims 1 to 37.