TECHNICAL FIELD

Embodiments herein relate to a network node, a monitoring node and methods performed therein. Furthermore, a computer program and a computer readable storage medium are also provided herein. In particular, embodiments herein relate to handling monitoring in a communication network.

BACKGROUND

In a typical communication network, wireless devices, also known as wireless communication devices, mobile stations, stations (STA) and/or user equipments (UE), communicate via e.g. a Radio Access Network (RAN) to one or more core networks (CN). The RAN covers a geographical area and provide radio coverage over service areas or cells, which may also be referred to as a beam or a beam group, with each service area or beam being served or controlled by a radio network node such as a radio access node e.g., a Wi-Fi access point or a radio base station (RBS), which in some networks may also be denoted, for example, a "NodeB" or "eNodeB". The radio network node communicates over an air interface operating on radio frequencies with the wireless device within range of the radio network node.

A Universal Mobile Telecommunications network (UMTS) is a third generation (3G) telecommunications network, which evolved from the second generation (2G) Global System for Mobile Communications (GSM). The UMTS terrestrial radio access network (UTRAN) is essentially a RAN using wideband code division multiple access (WCDMA) and/or High Speed Packet Access (HSPA) for user equipments. In a forum known as the Third Generation Partnership Project (3GPP), telecommunications suppliers propose and agree upon standards for third generation networks, and investigate enhanced data rate and radio capacity. In some RANs, e.g. as in UMTS, several radio network nodes may be connected, e.g., by landlines or microwave, to a controller node, such as a radio network controller (RNC) or a base station controller (BSC), which supervises and coordinates various activities of the plural radio network nodes connected thereto. This type of connection is sometimes referred to as a backhaul connection. The RNCs and BSCs are typically connected to one or more core networks. Specifications for the Evolved Packet System (EPS), also called a Fourth

Generation (4G) network, have been completed within the 3 ^rd Generation Partnership Project (3GPP) and this work continues in the coming 3GPP releases, for example to specify a Fifth Generation (5G) network also referred to as New Radio (NR). The EPS comprises the Evolved Universal Terrestrial Radio Access Network (E-UTRAN), also known as the Long Term Evolution (LTE) radio access network, and the Evolved Packet Core (EPC), also known as System Architecture Evolution (SAE) core network. E- UTRAN/LTE is a variant of a 3GPP radio access network wherein the radio network nodes are directly connected to the EPC core network rather than to RNCs. In general, in E-UTRAN/LTE the functions of an RNC are distributed between the radio network nodes, e.g. eNodeBs in LTE, and the core network. As such, the RAN of an EPS has an essentially "flat" architecture comprising radio network nodes connected directly to one or more core networks, i.e. they are not connected to RNCs. To compensate for that, the E- UTRAN specification defines a direct interface between the radio network nodes, this interface being denoted the X2 interface.

In the field of cloud-implemented services, resources for processing, storing and communication of data are basically hired and used temporarily for execution of a cloud service in a communication network. Cloud-implemented services represent any service that is executed for a client by means of processing and storage resources in a data centre which is typically selected to provide efficient and reliable processing and communication of the service data over the communication network. The communication network discussed herein may be any type of network, e.g. a wireless, fixed, public and/or private network, using any protocols and standards for communication.

Continuous monitoring in cloud-implemented services is critical for identifying and diagnosing performance problems. Monitoring methods consume compute and network resources and if the resources used for monitoring are not managed properly, the monitoring methods can affect the performance of applications/services. Therefore, it is important to limit and control the amount of resources being used for monitoring.

Additionally, running multiple monitoring sessions at the same time can lead to monitoring conflicts and interference. Monitoring conflicts can result in faulty monitoring results. For example, in 'Large-Scale Available Bandwidth Measurements: Interference in Current Techniques' D Croce et al. Published in IEEE Transactions on Network and Service Management; Volume: 8, Issue: 4, December 201 1 , it is shown that overlapping links of measurement paths may bias metric estimation due to interference in the communication network. That is, a packet transmission for estimating e.g. a throughput may affect another monitoring session over the same link.

A variety of studies have considered the scheduling problem of active

measurement tasks to prevent measurement conflicts while satisfying the measurement requirements. Examples include "HELM: Conflict-free active measurement scheduling for shared network resource management" Miao Zhang et al. 2015 IFIP/IEEE International Symposium on Integrated Network Management (IM) and "Mitigating interference in a network measurement service" Sriharsha Gangam et al 201 1 IEEE 19th International Workshop on Quality of Service (IWQoS), where measurement tasks are scheduled to reduce the interference.

Another example is "PingMesh: A Large-Scale System for Data Center Network Latency Measurement and Analysis" Chuanxiong Guo et al, SIGCOMM '15, August 17 - 21 , 2015, London, United Kingdom, which uses a centralized scheduler to schedule latency measurements between servers in a datacenter or between datacenters with an objective to achieve full coverage of the network.

In cloud environments where virtualized application instances may be started, stopped, and moved dynamically, the monitoring should keep up with the dynamic nature of applications. A party or a requesting party such as a user or applications, which require monitoring between devices providing the service(s) have no information about the deployment of their services, nor do the users know if their requested monitoring sessions conflict with each other or if the monitoring sessions requested by other users are sharing the same infrastructure. The services or application may be deployed in devices such as virtual machines (VM) or virtual containers.

Therefore, monitoring sessions started by different users and applications and between different devices can overlap with each other, i.e. use same links, and cause monitoring conflicts.

There is a need for a monitoring system to avoid interference between monitoring sessions and to respect the constraints on resources that can be used for monitoring, while satisfying the monitoring requirements of the requesting party. A monitoring system receiving different monitoring intents for different services should be able to schedule the measurements dynamically to avoid the conflicts while satisfying the intents and respecting the resource limits for monitoring. Existing solutions only focus on scheduling requested monitoring tasks for example to avoid interference resulting in a rather rigid and non-flexible solution. SUMMARY

An object herein is to provide a mechanism that improves monitoring of applications and/or services in an efficient manner.

According to an aspect the object is achieved by providing a method performed by a network node for handling monitoring of applications and/or services in a

communication network. The network node obtains an indication, such as a monitoring request or a stop request, associated with a monitoring session to monitor a metric, e.g. throughput, of a service and/or application. Furthermore, the network node obtains a location of deployment of the service and/or application, e.g. coordinates of a device hosting the service or application. The network node identifies one or more ongoing monitoring sessions for monitoring one or more metrics based on the metric associated with the indication and the location of deployment of the application or service. The network node further selects a monitoring process e.g. a monitoring configuration or reconfiguration, based on the identification; and triggers the selected monitoring process, e.g. transmitting, to a monitoring node, scheduling of packets.

According to another aspect the object is achieved by providing a method performed by a monitoring node for handling monitoring of applications and/or services in a communication network. The monitoring node transmits, to a network node, an indication associated with a monitoring session to monitor a metric of a service and/or application. The monitoring node receives, from the network node, data indicating scheduling, in frequency and/or phase, for performing one or more measurements, and further receives, from the network node, reconfiguration data for performing one or more measurements. The monitoring node then reconfigures itself based on the received reconfiguration data.

It is furthermore provided herein a computer program comprising instructions, which, when executed on at least one processor, cause the at least one processor to carry out any of the methods above, as performed by the network node. It is additionally provided herein a computer-readable storage medium, having stored thereon a computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out the method according to any of the methods above, as performed by the network node.

According to yet another aspect a network node for handling monitoring of applications and/or services in a communication network is herein provided. The network node is configured to obtain an indication associated with a monitoring session to monitor a metric of a service and/or application; and to obtain a location of deployment of the service and/or application. The network node is further configured to identify one or more ongoing monitoring sessions for monitoring one or more metrics based on the metric associated with the indication and the location of deployment of the application or service. The network node is configured to select a monitoring process based on the identification, and to trigger the selected monitoring process.

According to still another aspect a monitoring node for handling monitoring of applications and/or services in a communication network is herein provided. The monitoring node is configured to transmit, to a network node, an indication associated with a monitoring session to monitor a metric of a service and/or application. The monitoring node is further configured to receive, from the network node, data indicating scheduling, in frequency and/or phase, for performing one or more measurements. The monitoring node is configured to receive, from the network node, reconfiguration data for performing one or more measurements; and to reconfigure the monitoring node based on the received reconfiguration data.

According to embodiments herein it is herein provided a method for dynamic and adaptive configuration of monitoring functions based on indications, such as monitoring requests, from devices and provisions of monitoring results so that the overall overhead of monitoring may not exceed the resource limits for monitoring. The method is performed by a network node which receives indications from devices/service descriptions and keeps a view of the requested and ongoing monitoring sessions. Furthermore, whenever there is a change in the monitoring requests, e.g., new monitoring request or migration of service components, the network node identifies identical monitoring sessions, sets up or defines a new or updated monitoring schedule, updates e.g. the request descriptions, and/or (re- )configure the monitoring functions. This results in an efficient use of resources for monitoring services or application and improves monitoring of the applications and/or services in an efficient manner.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will now be described in more detail in relation to the enclosed drawings, in which:

Fig. 1 is a schematic diagram depicting a communication network according to

embodiments herein;

Fig. 2Ashows a combined signalling scheme and flowchart according to embodiments herein; Fig. 2Bshows a combined signalling scheme and flowchart according to embodiments herein;

Fig. 3 shows a method performed by a network node according to embodiments herein; Fig. 4 shows a method performed by a monitoring node according to embodiments

herein;

Fig. 5 shows a schematic overview depicting a scheduling according to embodiments herein;

Fig. 6 is a block diagram depicting a network node according to an embodiment herein; Fig. 7 is a block diagram depicting a monitoring node according to an embodiment herein.

DETAILED DESCRIPTION

Embodiments herein relate to communication networks in general. Fig. 1 is a schematic overview depicting a communication network 1. The communication network 1 comprises e.g. one or more RANs and one or more CNs. The communication network 1 may use one or a number of different technologies, such as New Radio (NR), Wi-Fi, Long Term Evolution (LTE), LTE-Advanced, 5G, Wideband Code Division Multiple Access (WCDMA), Global System for Mobile communications/enhanced Data rate for GSM Evolution (GSM/EDGE), Worldwide Interoperability for Microwave Access (WiMax), or Ultra Mobile Broadband (UMB), just to mention a few possible implementations.

Embodiments herein relate to recent technology trends that are of particular interest in a cloud computing environment, however, embodiments are also applicable in further development of the existing communication networks such as e.g. WCDMA and LTE. Cloud computing environment meaning that application instances and/or resources are distributed handled in the communication network.

In the communication network 1 , a network node 10, such as a server, a monitoring server, an Operations And Maintenance (OAM) node, a computer or similar, monitors, in a centralized manner, services or applications provided in the communication network 1 . The communication network further comprises devices A,B,C,D using or monitoring the applications or services in the communication network. The devices may comprise VM or containers of different hosts such as Host 1 and Host 2. Each device comprises a monitoring function and may be denoted as a monitoring node 11 .

In a (multi-tenant) cloud environment a monitoring system, such as the network node 10, can provide monitoring functionality for all devices. The goal is to perform the requested monitoring for different devices or users of devices while limiting the requested monitoring overhead and satisfying monitoring requests by distributing monitoring between them. The network node 10 identifies monitoring sessions that are identical and may automatically (re)configure the corresponding monitoring functions. Embodiments herein may dynamically adapt the monitoring by re-configuring one or more monitoring functions when e.g. services are started/stopped/moved. The dynamicity of monitoring 5 configuration and scheduling, i.e. that monitoring configuration is adapted, allows

minimization of impact of monitoring service on other services running in the cloud based environment. Devices "A", "B", "C", and "D" are illustrated as Virtual machines

(VM)/containers and "Mon" are the monitoring functions being configured by the network node 10.

10 Upon receiving an indication associated with a monitoring session to monitor a

metric of a service and/or application, the network node 10 coordinates the indication with existing monitoring sessions, and the network node 10 may then configure and start the required monitoring functions.

According to embodiments herein, the network node 10 takes into account the

15 monitoring sessions for different services and identifies identical metrics and locations for e.g. measurements among all the services and/or applications. Identical measurements may be measurements that are performed between same entities on the same resources. For example, throughput or available path capacity between two physical servers measured from different devices can be considered identical if the devices are connected

20 to a same virtual switch and their traffic traverses the same physical communication

network. The information about placement or deployment of services or applications and network configuration can be obtained by the network node 10 from a cloud orchestrator.

Once the network node 10 identifies the identical monitoring sessions, the network node 10 may define a schedule for them, and may then configure the monitoring functions

25 for each monitoring request. Additionally, the network node 10 may collect results of the measurements and may aggregate the results based on the original requests and reports the results or alarms according to the specified reactions.

Furthermore, if there is a change in deployment of the service or application or network configuration of the services or applications being monitored, the network node

30 10 may dynamically adapt the monitoring. For example, the network node 10 identifies that after migration of a device the monitoring tasks are not identical anymore, so the monitoring system will re-configure the monitoring functions so that the monitoring requests can be satisfied.

It should be understood by the skilled in the art that "device" is a non-limiting term

35 which means any terminal, VM, Container, computer, part of a server, wireless communications terminal, user equipment, Machine Type Communication (MTC) device, Device to Device (D2D) terminal, or node e.g. smart phone, laptop, mobile phone, sensor, relay, mobile tablets, base station or similar.

Furthermore, it should be noted that the network node 10 may be implemented in a distributed manner in a cloud system.

A combined flowchart and signaling scheme depicting embodiments herein is shown in Fig. 2A. In the illustrated example, the indication associated with the monitoring session to monitor a metric of a service and/or application is a monitoring request.

Action 201 . An application or a service or an agent associated with one or more applications sends an indication, such as a request, for monitoring. Thus, the network node 10 may receive, i.e. obtain, one or more monitoring requests from devices/service descriptions and keep a view of the requested and ongoing monitoring tasks. The network node 10 can receive these one or more monitoring requests either as part of service description or as separate monitoring requests after the deployment of the service or application. A monitoring request comprises a metric that needs to be monitored, along with where the metric is to be monitored and e.g. with what frequency it needs to be monitored. The intents can be defined using, for example, MEASURE annotations [1 ]. In the following MEASURE example, "measurement" defines "which measurement function to activate, and where the particular measurement should be taken, and how the measurement should be configured". The "zones" specify "how to aggregate

measurement results" and "reactions" specify the triggers. In the example, the one-way latency between VMs/containers 'A' and 'B' need to be measured. The measurement should be taken in every 5 minutes and if the latency starts to be larger than 10.0, a "Warning latency" shall be issued. measurement {

ml = oneway_latency(A, B, param);

m2 = cpu_load(A); zones {

z1 Avg(m1 , '5 minutes') >= 10.0;

z2 Avg(m1 , '5 minutes') < 10.0;

z3 Avg(m2, Ί minute') < 90%;

z4 Avg(m2, Ί minute') >= 90%; }

reaction {

z3->z4: Publish(topic=alarm, msg="Warning CPU");

z2->z1 : Publish(topic=alarm, msg="Warning latency");

}

Action 202. Upon receiving the indication indicating a monitoring intent, the network node 10 coordinates the monitoring intent with the existing monitoring sessions. That is, the network node 10 may compare to ongoing monitoring sessions and identify similar or identical ongoing monitoring sessions. Similar or identical meaning that the monitoring sessions monitors same metric(s) and same location of deployment of the

service/application.

Action 203. The network node may then configure and start the required monitoring functions of the monitoring nodes. The network node 10 may e.g. transmit configuration to the monitoring function of device A setting up measurement process for monitoring the metric.

Action 204. The network node may further configure other ongoing monitoring sessions. The network node 10 may e.g. transmit configuration to the monitoring function of device B releasing the measurement process for monitoring the metric, in case, the monitoring function of device A is enough for monitoring the metric also for device B. The configuration may also state scheduling of measurements in relation to the measurements performed by the monitoring function of device A such that resources are used in an efficient manner see Fig. 5.

Action 205. The monitoring function A may collect measurements and further transmit the measurements of the metric to the network node 10. It should be noted that the monitoring function may calculate the result itself and transmit the result to the network node for further distribution.

Action 206. The network node 10 may calculate result of the metric and then transmit the result to the monitoring function A.

Action 207. The network node 10 may further transmit the result of the metric to the monitoring function B e.g. in case the result of device A is enough for monitoring the metric also for device B.

A combined flowchart and signaling scheme depicting embodiments herein is additionally shown in Fig. 2B. In the illustrated example, the indication associated with the monitoring session to monitor a metric of a service and/or application is a stop request, indicating a stopping of a monitoring process of a monitoring function.

Action 211 . An application or a service or an agent associated with one or more applications sends an indication, such as a stop request, for stopping the monitoring of a metric.

Action 212. Upon receiving the indication indicating the stopping of monitoring the metric, the network node 10 coordinates the monitoring processes with the existing monitoring sessions. That is, the network node 10 may compare to ongoing monitoring sessions and identify similar or identical ongoing monitoring sessions. Similar or identical meaning that the monitoring sessions monitors same metric(s) and same location of deployment of the service/application.

Action 213. The network node 10 may then configure and stop the required monitoring function. The network node 10 may transmit configuration to the monitoring function of device A stopping the measurement process for monitoring the metric.

Action 214. The network node 10 may further reconfigure other ongoing monitoring sessions. The network node 10 may e.g. transmit reconfiguration to the monitoring function of device B initiating and setting up the measurement process for monitoring the metric.

Action 215. The monitoring function B may collect measurements and further transmit the measurements of the metric to the network node 10. It should be noted that the monitoring function may calculate the result itself and transmit the result to the network node for further distribution.

Action 216. The network node 10 may calculate result of the metric and then transmit the result to the monitoring function B.

Interrupting

The method actions performed by the network node 10 for handling monitoring of applications and/or services in the communication network 1 according to some embodiments will now be described with reference to a flowchart depicted in Fig. 3. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Actions performed in some embodiments are marked with dashed boxes.

Action 301 . The network node 10 obtains the indication associated with a monitoring session to monitor a metric of a service and/or application. The metric may be e.g. throughput, available path capacity, delay, jitter, round trip time, application response time, or similar. That the indication is associated with the monitoring session means that the indication, whether it is a monitoring request, a stop request or a location reconfiguration, is a message relating to the service/application. If indications, such as monitoring intents, are specified as part of the service description, the network node 10 may obtain the indications from the service description when the application/service is being deployed in the communication network. The monitoring intents or policies, referred to herein as monitoring requests, for different services may thus be specified as part of service descriptions or can be obtained after the deployment of a service or application. The monitoring request specify the metric that needs to be measured, where it should be measured, and may also indicate with what frequency, for example using MEASURE annotations in G. Marchetto, R. Sisto, W. John et al., "Final Service Provider DevOps concept and evaluation," ArXiv e-prints, vol. 1610.02387, 2016. [Online]. MEASURE is defined as: "Machine-readable descriptions of the capabilities and their configuration parameters need to be developed. They specify which measurement functions should be activated, what and where they should measure, how they should be configured, how the measurement results should be aggregated, and what the reactions to the measurements should be". Based on the MEASURE annotations, a monitoring system can instantiate and configure the required monitoring functions, collect and aggregate the results, and generate alarms or triggers.

The indication may comprise the request for monitoring the metric of the service and/or application, a stop request requesting to stop monitoring the metric, or a location reconfiguration indicating a relocation of the service/application or the device at least partly running the service.

Action 302. The network node 10 may request the location of deployment of the application or service from a cloud orchestrator.

Action 303. The network node 10 obtains the location of deployment of the service and/or application. This may be retrieved internally or from an external node such as a cloud orchestrator. A cloud orchestrator is a node running software that manages the interconnections and interactions among cloud-based services and applications. The network node 10 may, additionally or alternatively, obtain information about the network setup e.g. network node architecture, and/or topology of the services or applications as well.

Action 304. The network node 10 identifies one or more ongoing monitoring sessions for monitoring one or more metrics based on the metric associated with the indication and the location of deployment of the application or service. Action 305. The network node 10 selects a monitoring process based on the identification. The network node may select one or more monitoring processes i.e. for a plurality of monitoring functions or services/applications.

Action 306. The network node 10 then triggers the selected monitoring process, or at least one selected monitoring process.

Action 307. The network node 10 may, in some embodiments, schedule, in frequency and/or phase, one or more measurements of the identified one or more ongoing monitoring sessions taking resource limitations into account. For example, the network node may schedule measurements to be performed from a plurality of monitoring functions in a resource efficient manner, e.g. time multiplexed. Thus, the network node 10 may act as an arbitrator and calculate the frequency and phase for each overlapping monitoring session and (re-)configures the monitoring functions accordingly. The arbitration may be done to make sure that the overall monitoring overhead is reduced while satisfying the requested monitoring frequency and avoiding interference of measurements. The network node 10 may, thus, based on the received indication, reconfigure one or more monitoring sessions and send reconfiguration data to the monitoring node handling the one or more monitoring sessions.

Action 308. The network node 10 may then further obtain (collect) one or more results of the one or more measurements performed as scheduled. For example, the network node 10 may receive measurements performed as scheduled at one or more monitoring functions, and may then calculate the result of the metric based on the received measurement or measurements. Additionally or alternatively, the network node 10 may receive the results from one or more of the measurements i.e. the monitoring function may calculate the results and transmit back to the network node 10.

Action 309. The network node 10 may aggregate the one or more results e.g. from a plurality of monitoring sessions.

Action 310. The network node 10 may provide one or more results of the one or more ongoing monitoring sessions to a party, such as service or application, requesting the monitoring of the metric of the service and/or application. The network node 10 may e.g. report the obtained one or more results to the monitoring session and the identified one or more ongoing monitoring sessions. E.g. the network node 10 receives the monitoring results from different monitoring functions and may then aggregate the results and report the results with the requested frequency to the requesting parties. Another example of a requesting party may be the cloud orchestrator which cloud orchestrator use the monitoring data to make decisions such as scaling or migrating the application/service or VM/container. The results can also be shown to the operator/user/tenant via a dashboard.

Action 311 . The network node 10 may interrupt provision of one or more results of the one or more ongoing monitoring sessions based on the stop request.

Action 312. The network node 10 may identify a change in a monitoring session, e.g. by receiving an location indication that comprises a location reconfiguration from a host. Thus, the network node 10 is informed of location of the part that has been relocated.

Action 313. The network node 10 may then reconfigure, i.e. send reconfiguration data, one or more monitoring sessions taking the indication, such as stop request, into account or the identified change.

The method actions performed by the monitoring node for handling monitoring of applications and/or services in the communication network 1 according to some

embodiments will now be described with reference to a flowchart depicted in Fig. 4. The actions do not have to be taken in the order stated below, but may be taken in any suitable order. Actions performed in some embodiments are marked with dashed boxes.

Action 401 . The monitoring node transmits the indication associated with the monitoring session to monitor the metric of the service and/or application.

Action 402. The monitoring node receives, from the network node, data

indicating scheduling, in frequency and/or phase, for performing one or more

measurements.

Action 403. The monitoring node receives, from the network node,

reconfiguration data for performing one or more measurements.

Action 404. The monitoring node reconfigures the monitoring node based on the received reconfiguration data.

Action 405. The monitoring node may perform one or more measurements as reconfigured. E.g. the monitoring node may perform measurements as scheduled.

Action 406. The monitoring node may further report, to the network node, result and/or measurement. The monitoring node may in some embodiments calculate the result based on time stamps of packets transmitted over the monitored link, or may just forward the results of the transmitted monitoring packets.

Fig. 5 shows a schematic overview depicting a scheduling according to an example of an embodiment herein. The network node 10 receives a monitoring request for measurements between devices "A" and "B" for metric "throughput" every "10" seconds,

measurement {

ml = throughput^, B, 10s);

}

The network node 10 identifies if the same metric has already been measured between the same locations. For example, for all the monitoring requests, if metric being monitored is equal to "throughput", then compare the location of the end-points of the measurements. If the endpoints are located on the same hosts and on the same network interfaces, then it marks the monitoring requests as identical.

If this metric is not already being monitored and the overhead of the requested monitoring task does not exceed the available resources for monitoring, the network node may configure the requested monitoring functionality and collect and report metric "ml " every "10" seconds to the requesting party.

The network node 10 receives a new request from the same monitoring node or another for monitoring the same metric "throughput" between "C" and "D" every "10" seconds.

measurement {

m2 = throughput^, D, 10s);

}

The network node 10 may schedule the measurements as shown in Fig 5(b) to avoid interference of measurements. However, the network node 10 may check ongoing monitoring sessions and identify that this monitoring request is identical to the ongoing monitoring between "A" and "B" since "A" and "C" are located on the same server and connected to a same virtual switch, and "B" and "D" are also placed on the same server with same virtual switch.

The network node 10 may then (re-)configure the monitoring sessions so that the overall monitoring overhead does not exceed the limited available resources for monitoring. The scheduling can be done using for example the method in US

200901 1 1382 A1 . The network node 10 may re-configures the measurements between "A" and "B" to be performed every "20" seconds starting from a given start time, and configures measurements between "C" and "D" to also be performed every "20" seconds starting "10" seconds after the start of measurements between "A" and "B". In this way, metric "throughput" is monitored every "10" seconds by either "A" and "B" or "C" and "D" see Fig. 5(c). measurement {

ml = throughput^, B, 20s);

}

measurement {

m2 = throughput^, D, 20s);

}

The network node 10 then receives the monitoring results for metric "throughput" every "10" seconds (one from each user every "20" seconds). The monitoring system normalizes the results (if needed) and reports metric to both requesting parties every "10" seconds, regardless of which user's monitoring function measured the metric.

If there is any change in the placement of devices, the network node 10 adapts the monitoring configurations. For example, if "A" is migrated, the monitoring system has to re-configure measurements between "A" and "B" according to the new location for "A" according to its original intents. Additionally, the monitoring system re-configures the measurements between "C" and "D" so that the original requested one measurement per "10" seconds can be provided.

Another example where this method can be used is for measuring the response time of a service. If "A" and "C" are both using the service "E", e.g. a database, then the measurements can be scheduled in order to avoid overloading resources of "E".

In view (a) a monitoring of metric m between devices A and B is measured every t second. In view (b) a monitoring of metric m between devices A and B is measured every t second and multiplex with a monitoring of metric m between devices C and D in every t second. According to embodiments herein the network node 10 may upon identifying the monitoring sessions as identical the network node 10 may reschedule the measurements and thus measure the metric m every t second but between different pairs of devices.

It should further be understood that one may add data indicating when the measurement should start e.g. 10s. This may be exemplified as following:

measurement {

ml = throughput^, B, (20s, [initial_phase=10s]));

}

Fig. 6 shows a block diagram of the network node 10, in two exemplified embodiments, for handling monitoring of applications and/or services in a communication network according to embodiments herein. The network node 10 may comprise a processing circuitry 601 , e.g. one or more processors, configured to perform the methods herein.

The network node 10 may comprise an obtaining module 602, e.g. a receiver or a transceiver. The network node 10, the processing circuitry 601 , and/or the obtaining module 602 is configured to obtain the indication associated with the monitoring session to monitor the metric of the service and/or application. The network node 10, the processing circuitry 601 , and/or the obtaining module 602 is further configured to obtain the location of deployment of the service and/or application. The indication may comprise: a request for monitoring the metric of the service and/or application; a stop request; or a location reconfiguration.

The network node 10 may comprise an identifying module 603. The network node 10, the processing circuitry 601 , and/or the identifying module 603 is configured to identify the one or more ongoing monitoring sessions for monitoring one or more metrics based on the metric associated with the indication and the location of deployment of the application or service.

The network node 10 may comprise a selecting module 604. The network node 10, the processing circuitry 601 , and/or the selecting module 604 is configured to select the monitoring process based on the identification. It should here be noted that the network node may select a number of monitoring processes based on the identification.

The network node 10 may comprise a triggering module 605. The network node

10, the processing circuitry 601 , and/or the triggering module 605 is configured to trigger the selected monitoring process.

The network node 10 may comprise a providing module 606, e.g. a transmitter or transceiver. The network node 10, the processing circuitry 601 , and/or the providing module 606 may be configured to provide one or more results of the one or more ongoing monitoring sessions to the party requesting the monitoring of the metric of the service and/or application.

The network node 10 may comprise a scheduling module 607. The network node 10, the processing circuitry 601 , and/or the scheduling module 607 may be configured to schedule, in frequency and/or phase, one or more measurements of the identified one or more ongoing monitoring sessions taking resource limitations into account.

The network node 10, the processing circuitry 601 , and/or the obtaining module 602 may then be further configured to obtain the one or more results of the one or more measurements performed as scheduled. The network node 10, the processing circuitry 601 , and/or the providing module 606 may be configured to report the obtained one or more results to the monitoring session and the identified one or more ongoing monitoring sessions.

The network node 10 may comprise an interrupting module 608. The network node 10, the processing circuitry 601 , and/or the interrupting module 608 may be configured to interrupt provision of one or more results of the one or more ongoing monitoring sessions based on the stop request, i.e. when the indication is the stop request. It should further be noted that the network node 10, the processing circuitry 601 , and/or the interrupting module 608 may be configured to interrupt provision of one or more results in case a reconfiguration or rescheduling of the measurements may be performed.

The network node 10, the processing circuitry 601 , and/or the identifying module 603 may be configured to identify a change in a monitoring session. For example, the location of deployment may change or similar.

The network node 10 may comprise a reconfiguring module 609. The network node 10, the processing circuitry 601 , and/or the reconfiguring module 609 may be configured to reconfigure one or more monitoring sessions taking the indication into account or the identified change.

The network node 10 may comprise a requesting module 610. The network node 10, the processing circuitry 601 , and/or the requesting module 610 may be configured to request the location of deployment of the application or service from a cloud orchestrator. This may e.g. be triggered upon initiation of a monitoring session or a relocation of deployment of an application or service.

The network node 10 may comprise an aggregating module 611 . The network node 10, the processing circuitry 601 , and/or the aggregating module 61 1 may be configured to aggregate the one or more results.

The network node 10 further comprises a memory 612 comprising one or more memory units. The memory 612 comprises instructions executable by the processing circuitry 601 to perform the methods herein when being executed in the network node 10. The memory 612 is arranged to be used to store e.g. information, data such as monitoring information, measurements, results, locations, metrics, etc.

The methods according to the embodiments described herein for the network node 10 are respectively implemented by means of e.g. a computer program 613 or a computer program product, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the network node 10. The computer program 613 may be stored on a computer-readable storage medium 614, e.g. a disc, a USB, or similar. The computer-readable storage medium 614, having stored thereon the computer program, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the network node 10. In some embodiments, the computer-readable storage medium may be a non-transitory computer-readable storage medium. Thus, the network node 10 may comprise the processing circuitry and the memory, said memory comprising instructions executable by said processing circuitry whereby said network node is operative to perform the methods herein.

Fig. 7 shows a block diagram of the monitoring node, in two exemplified

embodiments, for handling monitoring of applications and/or services in the

communication network according to embodiments herein.

The monitoring node may comprise a processing circuitry 701 , e.g. one or more processors, configured to perform the methods herein.

The monitoring node may comprise a transmitting module 702, e.g. a transmitter or a transceiver. The monitoring node, the processing circuitry 701 , and/or the transmitting module 702 is configured to transmit, to the network node 10, the indication associated with the monitoring session to monitor the metric of the service and/or application.

The monitoring node may comprise a receiving module 703, e.g. a receiver or a transceiver. The monitoring node, the processing circuitry 701 , and/or the receiving module 703 is configured to receive, from the network node 10, data indicating scheduling, in frequency and/or phase, for performing one or more measurements. The monitoring node, the processing circuitry 701 , and/or the receiving module 703 is further configured to receive, from the network node 10, reconfiguration data for performing one or more measurements.

The monitoring node may comprise a reconfiguring module 704. The monitoring node, the processing circuitry 701 , and/or the reconfiguring module 704 is configured to reconfigure the monitoring node based on the received reconfiguration data.

The monitoring node may comprise a performing module 705. The monitoring node, the processing circuitry 701 , and/or the performing module 705, such as a measurement handler, may be configured to perform one or more measurements as reconfigured. The monitoring node may comprise a reporting module 706. The monitoring node, the processing circuitry 701 , and/or the reporting module 706 may be configured to report, to the network node, result and/or measurement.

The monitoring node further comprises a memory 707 comprising one or more memory units. The memory 707 comprises instructions executable by the processing circuitry 701 to perform the methods herein when being executed in the monitoring node. The memory 707 is arranged to be used to store e.g. information, data such as monitoring information, measurements, results, locations, metrics, etc.

The methods according to the embodiments described herein for the monitoring node are respectively implemented by means of e.g. a computer program 708 or a computer program product, comprising instructions, i.e., software code portions, which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the monitoring node. The computer program 708 may be stored on a computer-readable storage medium 709, e.g. a disc, a USB, or similar. The computer-readable storage medium 709, having stored thereon the computer program, may comprise the instructions which, when executed on at least one processor, cause the at least one processor to carry out the actions described herein, as performed by the monitoring node. In some embodiments, the computer-readable storage medium may be a non-transitory computer-readable storage medium. Thus, the monitoring node may comprise the processing circuitry and the memory, said memory comprising instructions executable by said processing circuitry whereby said monitoring node is operative to perform the methods herein.

As will be readily understood by those familiar with communications design, means or modules may be implemented using digital logic and/or one or more

microcontrollers, microprocessors, or other digital hardware. In some embodiments, several or all of the various functions may be implemented together, such as in a single application-specific integrated circuit (ASIC), or in two or more separate devices with appropriate hardware and/or software interfaces between them. Several of the functions may be implemented on a processor shared with other functional components of a wireless terminal or network node, for example.

Alternatively, several of the functional elements of the processing means discussed may be provided through the use of dedicated hardware, while others are provided with hardware for executing software, in association with the appropriate software or firmware. Thus, the term "processor" or "controller" as used herein does not exclusively refer to hardware capable of executing software and may implicitly include, without limitation, digital signal processor (DSP) hardware, read-only memory (ROM) for storing software, random-access memory for storing software and/or program or application data, and non-volatile memory. Other hardware, conventional and/or custom, may also be included. Designers of communications receivers will appreciate the cost, performance, and maintenance tradeoffs inherent in these design choices.

It will be appreciated that the foregoing description and the accompanying drawings represent non-limiting examples of the methods and apparatus taught herein. As such, the inventive apparatus and techniques taught herein are not limited by the foregoing description and accompanying drawings. Instead, the embodiments herein are limited only by the following claims and their legal equivalents.