Patent Description:
The present specification generally relates to network entities and methods for enabling on-the-fly massive Quality of Service monitoring. Particularly, the present specification is targeted for 3GPP NR Ultra-Reliable Low Latency Communication (URLLC) based Industrial Internet of Things/Vehicle-to-Everything (IIoT/V2X) support in Rel'<NUM> and beyond. However, this is referred to as an example only and the present specification is applicable also to other sessions.

Each enhanced V2X (eV2X) service, as defined in TS <NUM>, may be provided with different application configurations, such as Levels of Automation (LoA), inter-vehicle gap, etc. Each application configuration may have a different Quality of Service (QoS) requirement. As a consequence, the application may have to adjust its configuration in case of a QoS change due to a new QoS that can be delivered. Considering the requirements of eV2X services, it may be important for some application(s) to be notified about a potential change in the delivered QoS in advance, in order to be able to dynamically adjust its configuration. The notification may consider locations in which a terminal device, e.g. known as a user equipment (UE), is likely to be present/driving for a given time period.

Therefore, it is an issue to study 5th Generation System (5GS) enhancements to assist application adjustments for eV2X services, according to notifications about a potential change in a delivered QoS. Such an issue applies mainly to UEs connected to a network device, e.g. known as a Next Generarion NodeB (gNB), via Uu. However, it may not be excluded that concepts as taught by the present specification may be applicable to other devices (like e.g. other network entities) via other interfaces.

In this context, this at least one issue addresses aspects in view of what information is required as input to enable an assessment of a potential change in QoS in given areas by the 5GS, in view of how the 5GS may determine that a notification about a potential change in a delivered QoS is necessary, and in view of how the 5GS may communicate such information to the application in the Application Function (AF) and/or the UE.

Further, in a V2X scenario, for a given Category of Requirement (CoR), the LoA can be adjusted in the range between <NUM> and <NUM> and this adjustment in LoA may be a result of a particular network situation (e.g. congestion). The V2X application may monitor the network situation and adapt the LoA for a given CoR corresponding to a V2X scenario. This change in LoA should also be communicated to the V2X UE by a V2X application server. Thus, this aspect in which a V2X application server is capable to adjust the LoA for single or specified sets of users of the same service (e.g. platooning), by monitoring the network situation (e.g. network load) and communicating the change of LoA with a V2X UE over V1 reference point is currently not addressed in 3GPP TS <NUM>.

Therefore, the ability to provide a V2X application with the 3GPP network conditions (e.g. network load) and the aspect of communicating a change of LoA to a V2X UE is highly important and requires further study.

In 3GPP SA2 TR <NUM>, a solution for a QoS support for eV2X over a Uu interface is provided, addressing enhancements for QoS monitoring and control with two alternative options. Option <NUM> is a Radio Access Network (RAN) based multi-QoS profile, and Option <NUM> is a Core Network (CN) based multi-QoS profile. However, an on-the-fly massive QoS monitoring, as well as which parameters to monitor, and how to perform such QoS monitoring are neither addressed nor suggested.

Protocol Data Unit (PDU) session management procedures of a New Radio (NR) <NUM> system are described in 3GPP TS <NUM>. <FIG>, taken from TS <NUM>, illustrates a current UE-initiated PDU session establishment. Accordingly, this shows that the signalling overhead needed for establishing a PDU session for a UE is rather substantial. Within TS <NUM>, Section <NUM>. <NUM> describes on high level some essential control information to be communicated in a PDU session management. Accordingly, as defined in <NUM>3GPP SA2 TR <NUM> clause <NUM>. <NUM>, considering the case of Home Routed PDU Session, the Non-Access Stratum Session Management (NAS SM) information processing by a Session Management Function (SMF) considers the following kind of NAS SM information. Namely, information that both the Visited-NAS (V-SMF) and Home-NAS (H-SMF) process: indication of the nature of the NAS SM signalling (e.g. PDU Session Establishment Request), PDU Session Type, Session Aggregate Maximum Bit Rate (Session-AMBR), UE addressing information (allocated IPv4 address, interface identifier). As well as information that is not visible to the V-SMF, only processed by the H-SMF: Session and Service Continuity (SSC) mode, Protocol Configuration Options, SM PDU Data Network (DN) Request Container, QoS Rule(s) and QoS Flow level QoS parameters if any for the QoS Flow(s) associated with the QoS rule(s).

The QoS architecture of a NR <NUM> system is described in 3GPP TS <NUM> (an overview is provided in 3GPP TS <NUM>), showing how user data in form of QoS flows are handled within each PDU session, as illustrated in <FIG> (cited from TS <NUM>). QoS handling in RAN, including PDU session and QoS flow setup, is captured in Annex A of TS <NUM>.

<CIT> discloses selecting and monitoring a plurality of services key performance indicators using a two-way active measurement protocol (TWAMP) in a software defined network (SDN) and network function virtualization (NFV) architecture.

Document <CIT> discloses another example of the prior art.

Therefore, as derivable from above, it is thus an object of various exemplary embodiments to solve the problems of enabling on-the-fly massive QoS monitoring.

In accordance with the present invention, there is provided a network entity and a corresponding method as claimed in the accompanying claims.

In the following, various exemplary embodiments will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which.

Various exemplary embodiments are described herein with reference to particular non-limiting examples, as well as with reference to what are presently considered to be conceivable embodiments of various exemplary embodiments. A person skilled in the art will appreciate that the disclosure is by no means limited to these examples, and may be more broadly applied.

It is to be noted that the following description of various exemplary embodiments mainly refers to specifications being used as non-limiting examples for certain exemplary network entities and/or terminal devices. 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 does naturally not limit the disclosure in any way. Rather, any other network entity and/or terminal device, etc. may also be utilized as long as compliant with the features described herein.

Hereinafter, various embodiments and implementations of the present disclosure and its aspects or embodiments are described using several variants and/or alternatives. It is generally noted that, according to certain needs and constraints, all of the described variants and/or alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various variants and/or alternatives).

According to exemplary embodiments, in order to, basically, enable on-the-fly massive QoS monitoring, there are provided devices, methods, and systems to solve these problems.

Specifically, various exemplary embodiments relate to the need for facilitating on-the-fly monitoring of certain network situations or predetermined indicators, like e.g. KPIs, and, in particular, deliverable QoS level(s) related to some targeted application(s) and service(s) or service class(es) of V2X and the like, such as IIoT. This kind of monitoring is not specific to an individual UE but rather averaged out over a certain service area and a certain time period at the present. Such monitoring is thus referred to herein as on-the-fly massive QoS monitoring.

NR considers support of URLLC based applications and services over Uu access including remote driving and automation applications in V2X and IIoT. Important KPIs for such challenging URLLC based applications and services include E2E latency and reliability. In addition, service availability and service access latency may be of high interest as well.

The present specification provides among others an effective method to facilitate on-the-fly massive QoS monitoring for URLLC driven applications and services in V2X and IIoT. According to at least some exemplary embodiments, it is assumed that the network side performs the actual QoS monitoring for KPIs of interest including E2E latency and reliability of data packet transmissions on a targeted QoS class based on feedback from involved UEs.

The present specification according to at least some exemplary embodiments is based on the idea of allowing the CN to initiate an on-the-fly massive QoS monitoring session of some E2E KPI(s) for URLLC support over Uu, based on using a common PDU session which is introduced specifically for such massive QoS monitoring considered herein. Thus, further from the current PDU session in NR (which is a UE-specific set up for an individual ACTIVE UE upon a request initiated by the UE and then maintained for the UE when the UE is staying in either ACTIVE or INACTIVE state) at least some certain contexts of the common PDU session are preconfigured to all relevant UEs and maintained regardless of the states the relevant UEs are in. The rest of the contexts of the common PDU session can be cell-specific and/or UE-specific, as the common PDU session is activated by the serving network.

Furthermore, the contexts of the common PDU session are extended to include pre-defined contents or data packets, also referred to as test data or test packets, to be exchanged between the UE and the network according to a pre-defined traffic pattern for the common PDU session when being activated. In this connection, the main reasons include the following. First, the massive QoS monitoring is not specific to an individual UE but a certain service area consisting of one or more cells, thus involving one or more gNBs and a plural of relevant UEs in the targeted service area. Second, the massive QoS monitoring is for on-the-fly adaptive service provisioning and adjustment and therefore not necessarily limited to only some of those active UEs which are currently operating the targeted applications and services.

In addition, according to at least some exemplary embodiments, the common PDU session, specific to the on-the-fly massive QoS monitoring considered herein, consists of predefined QoS flows in downlink (DL) for feedforward from the network and corresponding QoS flows in uplink (UL) for feedback from individual involved UEs in order to enable the network to perform the actual QoS monitoring of at least one of the targeted E2E KPIs. Thus, there is a predefined mapping between a DL QoS flow and a UL QoS flow or, that is, if an involved UE receives a packet of a DL QoS flow, then the UE will be able to determine and send a packet of a corresponding UL QoS flow back to the network.

Further, according to various exemplary embodiments, the contents of DL packets and UL packets sent on predefined QoS flows of the common PDU session are also predefined, referred to as test packets. The predefined QoS flows as well as contents of test packets are specific to associated applications and QoS profiles.

According to at least some exemplary embodiments, the predefined configurations or contexts of the common PDU session, including IDs of the PDU session and all basic QoS flows and QoS profiles, sizes and contents of test packets corresponding to individual QoS flows, mapping between individual DL QoS flows and individual UL QoS flows, etc., are common and can be preconfigured to a User Plane Function (UPF), a Next Generation NodeB (gNBs) and/or UEs which are capable of supporting the on-the-fly massive QoS monitoring in advance, either hardcoded or by on-line configuration and update using common or dedicated control signaling. For example, regarding the static or default contexts of the common PDU session regardless of individual UEs, serving cells or UE states can be hard-coded or provided once-off to individual UEs. Then, cell-specific contexts of the common PDU session may be provided using cell-specific common control signaling such as in a System Information Block (SIB) whereas UE-specific contexts of the common PDU session regarding an individual UE in ACTIVE state may be provided to the UE using dedicated control signaling. The provided cell-specific and UE-specific contexts may add, modify or overwrite some corresponding items or elements of the default contexts.

Furthermore, according to various exemplary embodiments, the network function in control of the QoS monitoring (e.g., enhanced AMF/SMF) may initiate an on-the-fly massive QoS monitoring session by activating the preconfigured common PDU session to involved UPFs, gNBs and UEs for the targeted service area. This activation may come with a setting of all on-the-fly configuration variables, such as which of those preconfigured QoS flows need to be activated, and for how long need to be activated. The activation towards involved UEs can be triggered using either common (using Paging or SIB for examples) or dedicated control signaling (using dedicated Radio Resource Control (RRC) or Non-Access Stratum (NAS) signaling for examples), considering involved UEs may be in idle/inactive or connected/active state when receiving the trigger for the activation of the common PDU session. This allows for reducing signaling overhead as well as proactive deactivation of the common PDU session after the set session lifetime elapses.

According to at least some exemplary embodiments, in case an idle/inactive UE is triggered to be involved in the initiated QoS monitoring session, the UE then upon establishment of the radio connection for the common PDU session may indicate a new cause for the radio connection establishment (and proactive release or deactivation of the common PDU session or individual QoS flow thereof once the preconfigured lifetime of the common PDU session or individual QoS flow elapses). In this case, the serving network may also be able to monitor, e.g., access latency and availability of the targeted application(s) and service(s).

Further, according to various exemplary embodiments, the network entities serving the activated common PDU session (UPF and/or gNB) has full control of how to generate and distribute a test packet in DL to one or more involved UEs using either multicast or unicast, so as to keep overhead controllable as well as to enable QoS monitoring in different network load and with different transmission mode (e.g. multicast or unicast transmission mode). The multicast option may generate high load in UL, depending on how many involved UEs are there on individual cell basis. This is because many UEs may receive the same DL packet and send feedback in UL simultaneously. There can be a coordination between the serving UPF and involved gNB(s) for an optimized distribution of test packets in DL. Namely, for instance, the gNB may be left to be in charge of how to distribute a test packet which is initiated by the serving UPF towards involved UEs. In this case, in addition to sending all the individual UL feedback packets to the serving UPF, the gNB needs to indicate to the UPF about losses of any expected UL feedback packets. The gNB may then determine whether to set up multicast radio bearer (RB) and/or unicast RB to an involved UE. The determination may be e.g. based on cell load, variation of current active data radio bearers (DRBs) for different QoS flows in UL and DL, awareness of UE conditions, etc..

For realizing the proposed massive QoS monitoring as described above, UE, gNB, AMF/SMF and UPF are proposed to be enhanced as will be detailed below. Accordingly, <FIG> shows network entities according to at least some exemplary embodiments, in which aspects of the present disclosure are embodied.

Regarding <FIG>, several devices (network entities and terminal devices) are illustrated, being connected via interfaces. Accordingly, there is an interface between entity AMF/SMF (shown within <FIG> as separated entities) and each of the entities UE, gNB, and UPF. The entity UE is further connected to the entity gNB, and the entity gNB is further connected to the entity UPF. The entity AMF/SMF is referred to as first network entity <NUM> herein below, the entity UPF is referred to as second network entity <NUM> herein below, the entity gNB is referred to as third network entity <NUM> herein below, and the entity UE is referred to as terminal device <NUM> herein below. In user plane, UE, gNB and UPF may originate and/or terminate UL and DL test data for the activated common PDU session as well as perform actual QoS monitoring on the transmitted and received test data - on the radio access level between UE and gNB as well as higher layer level between UE and UPF.

In the following, the devices according to <FIG> are defined individually and in more detail.

<FIG> is a schematic diagram, illustrating a first network entity <NUM> according to the claimed embodiments. The first network entity may correspond to an AMF/SMF according to <FIG>.

In particular, according to <FIG>, a first network entity <NUM> is shown, wherein the first network entity <NUM> comprises a defining unit <NUM>, a preconfiguring unit <NUM>, a first initiating unit <NUM>, and a triggering unit <NUM>. The defining unit <NUM> is configured to define a common communication session comprising a plurality of contexts, wherein the common communication session is common to a plurality of network entities and terminal devices. The preconfiguring unit <NUM> is configured to preconfigure the common communication session by preconfiguring at least one context out of the plurality of contexts to be common for more than one network entity out of the plurality of network entities and for more than one terminal device out of the plurality of terminal devices. The first initiating unit <NUM> is configured to, based on the preconfiguration by the preconfiguring unit <NUM>, initiate the preconfigured common communication session for at least one network entity out of the more than one network entities. The triggering unit <NUM> is configured to, based on the initiation by the first initiating unit <NUM>, trigger to initiate the preconfigured common communication session for at least one terminal device out of the more than one terminal devices.

<FIG> is a flowchart, illustrating a first network entity according to the claimed embodiments. The first network entity <NUM> according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the first network entity <NUM> of <FIG> but is not limited to being performed by this first network entity <NUM>. In particular, according to <FIG>, a first method comprises the steps of defining S51 a common communication session comprising a plurality of contexts, wherein the common communication session is common to a plurality of network entities and terminal devices. The first method further comprises preconfiguring S52 the common communication session by preconfiguring at least one context out of the plurality of contexts to be common for more than one network entity out of the plurality of network entities and for more than one terminal device out of the plurality of terminal devices. In addition, the first method comprises initiating S53, based on the preconfiguring step, the preconfigured common communication session for at least one network entity out of the more than one network entities, and triggering S54, based on the initiating step, to initiate the preconfigured common communication session for at least one terminal device out of the more than one terminal devices.

<FIG> is a schematic diagram, illustrating a second network entity <NUM> according to at least some exemplary embodiments. The second network entity <NUM> may correspond to a UPF according to <FIG>.

In particular, according to <FIG>, the second network entity <NUM> comprises an activating unit <NUM>, a generating and distributing unit <NUM>, and a monitoring unit <NUM>. The activating unit <NUM> is configured to activate a preconfigured common communication session based on a control signaling. The generating and distributing unit <NUM> is configured to, based on the control signaling, generate and distribute a test packet to at least one network entity out of a plurality of network entities and/or to at least one terminal device out of a plurality of terminal devices. The monitoring unit <NUM> is configured to, based on a first initiation signaling, monitor transmittance of the test packet and response thereto in terms of at least one predetermined performance indicator out of a plurality of predetermined performance indicators.

<FIG> is a flowchart, illustrating a second method according to at least some exemplary embodiments. The second network entity <NUM> according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the second network entity <NUM> of <FIG> but is not limited to being performed by this second network entity <NUM>.

In particular, according to <FIG>, a second method comprises the steps of activating S71 a preconfigured common communication session based on a first initiation signaling, and generating and distributing S72, based on the activating step, a test packet to at least one network entity out of a plurality of network entities and/or to at least one terminal device out of a plurality of terminal devices. The second method further comprises monitoring S73, based on the first initiation signaling, transmittance of the test packet and response thereto in terms of at least one predetermined performance indicator out of a plurality of predetermined performance indicators.

<FIG> is a schematic diagram, illustrating a third network entity <NUM> according to at least some exemplary embodiments. The third network entity <NUM> may correspond to a gNB according to <FIG>.

In particular, according to <FIG>, the third network entity <NUM> comprises an activating unit <NUM>, a second initiating unit <NUM>, a generating and distributing unit <NUM>, and a monitoring unit <NUM>. The activating unit <NUM> is configured to activate a preconfigured common communication session based on a first initiation signaling. The second initiating unit <NUM> is configured to, based on a trigger signaling, initiate the preconfigured common communication session for at least one terminal device out of a plurality of terminal devices. The generating and distributing unit <NUM> is configured to, based on the activation by the activating unit <NUM>, generate and distribute a test packet to at least one network entity out of a plurality of network entities and/or to the at least one terminal device. The monitoring unit <NUM> is configured to, based on the first initiation signaling, monitor transmittance of the test packet and response thereto in terms of at least one predetermined performance indicator out of the plurality of predetermined performance indicators.

<FIG> is a flowchart, illustrating a third method according to at least some exemplary embodiments. The third network entity <NUM> according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the third network entity <NUM> of <FIG> but is not limited to being performed by this third network entity <NUM>.

In particular, according to <FIG>, a third method comprises the steps of activating S91 a preconfigured common communication session based on a first initiation signaling, and initiating S92, based on a trigger signaling, the preconfigured common communication session for at least one terminal device out of a plurality of terminal devices. The third method further comprises generating and distributing S93, based on the activating step, a test packet to at least one network entity out of a plurality of network entities and/or to the at least one terminal device, and monitoring S94, based on the first initiation signaling, transmittance of the test packet and response thereto in terms of at least one predetermined performance indicator out of the plurality of predetermined performance indicators.

<FIG> is a schematic diagram, illustrating a terminal device <NUM> according to at least some exemplary embodiments. The terminal device <NUM> may correspond to a UE according to <FIG>.

In particular, according to <FIG>, the terminal device <NUM> comprises an activating unit <NUM>, and a generating and distributing unit <NUM>. The activating unit <NUM> is configured to activate a preconfigured common communication session based on a second initiation signaling. The generating and distributing unit <NUM> is configured to, based on the activation by the activating unit <NUM>, generate and distribute a test packet to at least one network entity out of a plurality of network entities.

<FIG> is a flowchart, illustrating a fourth method according to at least some exemplary embodiments. The terminal device <NUM> according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the terminal device <NUM> of <FIG> but is not limited to being performed by this terminal device <NUM>.

In particular, according to <FIG>, a fourth method comprises the steps of activating Sill a preconfigured common communication session based on a second initiation signaling, and generating and distributing S112, based on the activating step, a test packet to at least one network entity out of a plurality of network entities.

Regarding <FIG>, it is to be noted that any one of the first network entity <NUM> (according to <FIG>), the second network entity <NUM> (according to <FIG>), the third network entity <NUM> (according to <FIG>), and the terminal device <NUM> (according to <FIG>) may be used in any combination thereof. However, neither one of the first network entity <NUM>, the second network entity <NUM>, the third network entity <NUM>, and the terminal device <NUM> is limited to being used in any combination thereof.

Furthermore, in various embodiments, at least some of the functionalities of any one of the first network entity <NUM>, the second network entity <NUM>, the third network entity <NUM>, and the terminal device <NUM> may be shared between two physically separate devices forming one operational device. Thus, any one of the first network entity <NUM>, the second network entity <NUM>, the third network entity <NUM>, and the terminal device <NUM> may be seen to depict the operational device comprising one or more physically separate devices for executing at least some of the described processes.

In the following, further exemplary embodiments are described. However, these exemplary embodiments may also be valid in relation with the aforementioned devices, methods, and/or systems.

According to various exemplary embodiments, regarding the first network entity <NUM>, the preconfiguring unit <NUM> is further configured to use hard code or on-line configuration to preconfigure the at least one context.

In addition, according to at least some exemplary embodiments, the first network entity <NUM> may further comprise a controlling unit configured to maintain the at least one preconfigured context regardless of the state of the at least one terminal device out of the more than one terminal devices.

Furthermore, according to various exemplary embodiments, the first network entity <NUM> may further comprise a controlling unit configured to maintain the at least one preconfigured context regardless of a state of the at least one terminal device out of the more than one terminal devices; and/or to update the preconfigured at least one context using common or dedicated control signaling.

Further, according to various exemplary embodiments, regarding the first network entity <NUM>, the first initiating unit <NUM> may further be configured to initiate, for at least one network entity out of the more than one network entities, monitoring activities, wherein the monitoring activities may comprise to monitor transmittance of data and response thereto in terms of at least one predetermined performance indicator out of the plurality of predetermined performance indicators.

According to at least some exemplary embodiments, regarding the first network entity <NUM>, the first initiating unit <NUM> may further be configured to initiate, for at least one network entity out of the more than one network entities, on-the-fly massive Quality of Service monitoring based on at least one predetermined performance indicator out of a plurality of predetermined performance indicators, wherein the plurality of predetermined performance indicators comprises end-to-end key performance indicators for URLLC support over Uu.

Additionally, according to at least some exemplary embodiments, the at least one preconfigured context may include predefined test data and/or predefined test packets, specific to associated applications and/or Quality of Service profiles.

According to various exemplary embodiments, the monitored at least one predetermined performance indicator out of the plurality of predetermined performance indicators may comprise an end-to-end key performance indicator for URLLC support over Uu.

Furthermore, according to various exemplary embodiments, the at least one preconfigured context out of the plurality of contexts of the common communication session may include predefined test data and/or predefined test packets, specific to associated applications and/or Quality of Service profiles.

In addition, according to at least some exemplary embodiments, the at least one preconfigured context may be hardcoded or on-line configured.

Further, according to various exemplary embodiments, the plurality of contexts exclusive the at least one preconfigured context may be specific for one network entity out of the plurality of network entities and/or for one terminal device out of the plurality of terminal devices.

Furthermore, according to at least some exemplary embodiments, the common communication session may be a common PDU session.

Additionally, according to at least some exemplary embodiments, the common communication session may consist of predefined Quality of Service flows in downlink for feedforward from the at least one network entity out of the more than one network entities and/or the at least one terminal device out of the more than one terminal devices, and of corresponding Quality of Service flows in uplink for feedback from the at least one network entity out of the more than one network entities and/or the at least one terminal device out of the more than one terminal devices. The predefined Quality of Service flows may be specific to associated applications and/or Quality of Service profiles.

Furthermore, according to various exemplary embodiments, regarding the second network entity <NUM>, the generating and distributing unit <NUM> may further be configured to generate and distribute the test packet by using either multicast or unicast.

Further, according to various exemplary embodiments, regarding the second network entity <NUM>, the generating and distributing unit <NUM> may further be configured to be in coordination with a generating and distributing unit corresponding to the at least one network entity and/or to the at least one terminal device.

In addition, according to at least some exemplary embodiments, regarding the third network entity <NUM>, the second initiating unit <NUM> may further be configured to initiate, for the at least one network entity, monitoring activities, wherein the monitoring activities may comprise to monitor transmittance of data and response thereto in terms of at least one predetermined performance indicator out of the plurality of predetermined performance indicators.

Additionally, according to at least some exemplary embodiments, regarding the third network entity <NUM>, the generating and distributing unit <NUM> may further be configured to generate and distribute the test packet by using either multicast or unicast.

In addition, according to various exemplary embodiments, regarding the third network entity <NUM>, the generating and distributing unit <NUM> may further be configured to be in coordination with a generating and distributing unit corresponding to the at least one network entity and/or to the at least one terminal device.

Further, according to at least some exemplary embodiments, the terminal device <NUM> may further comprise a monitoring unit configured to, based on the second initiation signaling, monitor transmittance of the test packet and response thereto in terms of at least one predetermined performance indicator out of a plurality of predetermined performance indicators.

Furthermore, according to various exemplary embodiments, the terminal device <NUM> may further be configured to comprise a determining unit configured to determine, based on a state of the terminal device <NUM>, if to participate in the preconfigured common communication session and/or if to monitor transmittance of the test packet and response thereto.

In addition, according to at least some exemplary embodiments, a system is defined, wherein the system may comprise the third network entity <NUM> and a plurality of terminal devices <NUM>, wherein at least one out of the plurality of terminal devices <NUM> corresponds at least to the third network entity <NUM>.

After the detailed description of the individual devices according to <FIG>, <FIG> now illustrates signaling flows according to at least some exemplary embodiments. Regarding <FIG>, relevant entities are arranged horizontally, subsequent process steps are arranged vertically, control signaling are presented by arrows, and individual processes are presented by filled boxes/double-arrows. It is to be noted that a terminal device <NUM> (UE) may be configured to determine whether it needs to be involved or not in the initiated massive QoS monitoring. For example, in case a, in which CommonPDUSessionActivation is initiated using common signaling, a terminal device <NUM> (UE) which is not relevant may ignore the request and therefore may not be involved. Further, according to another example, a relevant UE which is in ACTIVE state, thus having ongoing QoS flows with the same QoS levels as that indicated in a CommonPDUSessionActivation, may also ignore the request.

For the fast setup step to be found in <FIG>, as a common PDU session context is preconfigured to all relevant network entities such as a second network entity <NUM> (UPF), a third network entity <NUM> (gNB) and a plurality of terminal devices <NUM> (UEs), the activation of a common PDU session and QoS flows procedure can be rather fast and requires only limited signaling to indicate a PDU session ID, activated QoS flows to be monitored, and optional lifetime of an activated common PDU session.

It is further noted that, according to at least some exemplary embodiments, for how to transmit test packets for different activated QoS flows in the userplane according to <FIG> between a second network entity <NUM> (UPF), a third network entity <NUM> (gNB) and a terminal devices <NUM> (UE), using either unicast or multicast, single-connectivity or multi-connectivity for open-loop or closeloop E2E is assumed by using existing mechanisms specified for URLLC support.

Thus, according to various exemplary embodiments, basically, on-the-fly massive Quality of Service monitoring is enabled.

In the foregoing exemplary description of the network entities and/or terminal devices, only the units that are relevant for understanding the principles according to at least some embodiments have been described. The network entities and/or terminal devices may comprise further units that are necessary for its respective operation. However, a description of these units is omitted in this specification. The arrangement of the units of the network entities and/or terminal devices is not construed to limit the disclosure, and the functions may be performed by one unit or further split into sub-units.

When in the foregoing description it is stated that the network entity and/or terminal device (or some other circuitry/means) is configured to perform some function, this is to be construed to be equivalent to a description stating that a (i.e. at least one) processor, potentially in cooperation with computer program code stored in a memory of the respective network entity and/or terminal device, is configured to cause the network entity and/or terminal device to perform at least the thus mentioned function. Also, such function is to be construed to be equivalently implementable by specifically configured means for performing the respective function (i.e. the expression "unit configured to" is construed to be equivalent to an expression such as "means for").

For the purpose of various exemplary embodiments as described herein above, it should be noted that.

Claim 1:
A first network entity, comprising:
a defining unit (<NUM>) configured to define a common communication session comprising a plurality of contexts, wherein the common communication session is common to a plurality of network entities and terminal devices,
a preconfiguring unit (<NUM>) configured to preconfigure the common communication session by preconfiguring at least one context out of the plurality of contexts to be common for more than one network entity out of the plurality of network entities and for more than one terminal device out of the plurality of terminal devices,
a first initiating unit (<NUM>) configured to, based on the preconfiguration by the preconfiguring unit, initiate the preconfigured common communication session for at least one network entity out of the more than one network entities, and
a triggering unit (<NUM>) configured to, based on the initiation by the first initiating unit, trigger to initiate the preconfigured common communication session for at least one terminal device out of the more than one terminal devices.