QoE Measurement Collection

QoE (Quality of Experience) is how a service feels to the user: does the video start fast, does it stall, does the voice call sound clear. It is different from QoS. QoS is what the network promises to a traffic flow, such as a bit rate or a delay budget, and it is described in the QoS page. A network can meet every QoS target and still give a bad experience, because the experience also depends on the server, the player buffer and the codec. The only place that really sees QoE is the application in the UE.

QoE Measurement Collection (QMC) is the mechanism that brings those application measurements from the UE to the operator. Release 17 introduced it for NR, for DASH streaming, MTSI (voice and video over IMS) and VR. The same release also added a second layer called RAN visible QoE, where a few QoE values are reported in a form that the gNB itself can read. In the Uu interface the feature is called "application layer measurement", and on NG, Xn and OAM it is called "QoE measurement". Both names mean the same thing.

• Why collect QoE through the RAN ?
• Overall architecture
• RRC configuration
• How the UE reports
• RAN visible QoE
• Mobility, RRC states and NR-DC
• Release Evolution
• Reference

Why collect QoE through the RAN ?

Why does an application measurement need RRC at all ? The application could send its report directly to a server over the user plane, like any other data. The reason is control. The operator wants to decide which UEs measure, in which area, for which service and for how long, and wants the reports to arrive at its own collection server with an operator reference. The RAN is the part of the network that can select UEs by cell and area, and it already has a secure signalling path to every connected UE.

So 3GPP reused the same pattern as MDT. OAM starts a job, the gNB selects UEs and configures them over RRC, and the reports go to a collection entity, here called the MCE (Measurement Collection Entity). The difference from MDT is the content. MDT carries radio measurements that the UE modem makes. QMC carries application metrics that the gNB normally cannot even read, because they are defined by SA4 (TS 26.247 for DASH, TS 26.114 for MTSI, TS 26.118 for VR) and carried in a transparent container. MDT is described in the MDT page.

• Three service types: DASH streaming, MTSI and VR, signalled as streaming, mtsi and vr in serviceType-r17.
• The content is opaque to RRC: the configuration and the report are OCTET STRING containers. The UE AS passes them between RRC and the application without reading them.
• Connected mode first: in Release 17, QMC works in RRC_CONNECTED. Later releases extend it to MBS and to idle and inactive UEs receiving MBS broadcast.

Overall architecture

Who starts a QoE measurement, and where does the report end up ? Like MDT, there are two ways to start it. In management-based activation, OAM sends the QoE configuration directly to the gNB, and the gNB picks UEs that have the capability and meet the area and slice scope. In signalling-based activation, OAM targets one specific UE through the 5GC, and the gNB receives the configuration in UE-associated NGAP signalling. Figure 1 shows the path of the configuration and the report.

Figure 1. QoE measurement collection path. The configuration and the report are containers that the gNB and the UE access stratum pass along unchanged. Only the application and the MCE understand their content.

• QoE reference: each QoE measurement configuration is identified by a QoE reference from OAM. Several configurations can be active at a UE per service type.
• What the gNB receives: the application layer measurement configuration container, plus information such as service type, MCE IP address, slice scope, area scope, MDT alignment information and the available RAN visible QoE metrics.
• measConfigAppLayerId: inside RRC, the gNB gives each configuration a short ID. The same ID is carried in the reports, so the gNB can map a report back to its QoE reference and its MCE.
• Deactivation: OAM stops a QoE job toward the gNB, or through the core for signalling-based QoE. The UE then deletes the configuration and discards the unsent reports of it.

RRC configuration

On the radio side the configuration arrives in RRCReconfiguration or RRCResume, in the field appLayerMeasConfig-r17. Before that, the network must have configured SRB4. SRB4 is a dedicated SRB for application layer measurement reports, with lower priority than SRB1, and it can be configured only after AS security activation. The reason for a separate SRB is size and priority: a QoE report can be large, and it must not delay real control signalling.

The listing below has two levels. AppLayerMeasConfig-r17 is the list of configurations. Each MeasConfigAppLayer-r17 is one QoE configuration, with the opaque container and a few RRC-level switches around it. For now, just pay attention to the container, the service type and ran-VisibleParameters. The last one is the RAN visible layer described later.

Following is based on 38.331 v19.4.0 (Release 19)

AppLayerMeasConfig-r17 ::=           SEQUENCE {
    measConfigAppLayerToAddModList-r17   SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayer-r17     OPTIONAL, -- Need N
    measConfigAppLayerToReleaseList-r17  SEQUENCE (SIZE (1..maxNrofAppLayerMeas-r17)) OF MeasConfigAppLayerId-r17   OPTIONAL, -- Need N
    rrc-SegAllowedSRB4-r17               ENUMERATED {enabled}                                                       OPTIONAL, -- Need R
    ...,
    [[
    rrc-SegAllowedSRB5-r18               ENUMERATED {enabled}                                                       OPTIONAL, -- Need R
    idleInactiveReportAllowed-r18        ENUMERATED {enabled}                                                       OPTIONAL  -- Need R
    ]]
}

MeasConfigAppLayer-r17 ::=           SEQUENCE {
    measConfigAppLayerId-r17             MeasConfigAppLayerId-r17,
    measConfigAppLayerContainer-r17      OCTET STRING (SIZE (1..8000))                                              OPTIONAL, -- Need N
    serviceType-r17                      ENUMERATED {streaming, mtsi, vr, spare5, spare4, spare3, spare2, spare1}   OPTIONAL, -- Need M
    pauseReporting-r17                   BOOLEAN                                                                    OPTIONAL, -- Need M
    transmissionOfSessionStartStop-r17   BOOLEAN                                                                    OPTIONAL, -- Need M
    ran-VisibleParameters-r17            SetupRelease {RAN-VisibleParameters-r17}                                   OPTIONAL, -- Cond ServiceType
    ...,
    [[
    reportingSRB-r18                     ENUMERATED {srb4, srb5}                                                    OPTIONAL, -- Cond QoENRDC
    appLayerMeasPriority-r18             INTEGER (1..16)                                                            OPTIONAL, -- Need M
    appLayerIdleInactiveConfig-r18       SetupRelease {AppLayerIdleInactiveConfig-r18}                              OPTIONAL  -- Need M
    ]]
}

• maxNrofAppLayerMeas-r17: up to 16 simultaneous application layer measurement configurations.
• measConfigAppLayerContainer-r17: the SA4 configuration (TS 26.247 Annex L, TS 26.114 clause 16.5, TS 26.118 clause 9.4), up to 8000 octets. The UE AS forwards it to the application.
• serviceType-r17: which application the configuration is for.
• pauseReporting-r17: true pauses the transmission of the report containers. The UE keeps them in the AS layer and sends them when the gNB sets it back to false. This is the RAN overload tool.
• transmissionOfSessionStartStop-r17: true asks the UE to indicate when a measurement session starts and stops in the application. The gNB can use this to start the aligned MDT measurement only while a session is running.
• rrc-SegAllowedSRB4-r17: allows RRC segmentation of MeasurementReportAppLayer on SRB4, for reports larger than one PDCP SDU. Without it, a too large report is discarded.
• reportingSRB-r18 / appLayerMeasPriority-r18 / appLayerIdleInactiveConfig-r18: Release 18 additions for NR-DC, for priority-based discarding when memory is full, and for idle and inactive collection. They are covered in Mobility, RRC states and NR-DC.

How the UE reports

The application produces a report whenever its own configuration says so, usually periodically or at the end of a session. Then the UE AS has to send it. The report message is MeasurementReportAppLayer, and the UE starts the procedure when at least one configuration and SRB4 (or SRB5) exist. One message can carry the reports of several configurations.

Following is based on 38.331 v19.4.0 (Release 19)

MeasurementReportAppLayer-r17-IEs ::=   SEQUENCE {
    measurementReportAppLayerList-r17       MeasurementReportAppLayerList-r17,
    lateNonCriticalExtension                OCTET STRING                                                           OPTIONAL,
    nonCriticalExtension                    MeasurementReportAppLayer-v1800-IEs                                    OPTIONAL
}

MeasurementReportAppLayer-v1800-IEs ::= SEQUENCE {
    measurementReportAppLayerList-v1800     MeasurementReportAppLayerList-v1800                                    OPTIONAL,
    nonCriticalExtension                    SEQUENCE{}                                                             OPTIONAL
}

MeasReportAppLayer-r17 ::=            SEQUENCE {
    measConfigAppLayerId-r17              MeasConfigAppLayerId-r17,
    measReportAppLayerContainer-r17       OCTET STRING                                                             OPTIONAL,
    appLayerSessionStatus-r17             ENUMERATED {start, stop}                                                 OPTIONAL,
    ran-VisibleMeasurements-r17           RAN-VisibleMeasurements-r17                                              OPTIONAL
}

MeasReportAppLayer-v1800 ::=          SEQUENCE {
    appLayerIdleInactiveConfig-r18        AppLayerIdleInactiveConfig-r18                                           OPTIONAL,
    measReportAppLayerContainerList-r18   SEQUENCE (SIZE (1..maxNrofAppLayerReports-r18)) OF OCTET STRING          OPTIONAL,
    ...
}

• measReportAppLayerContainer-r17: the SA4 report. The gNB forwards it to the MCE with time stamp information, and with the MDT trace identifiers when the QoE job is aligned with MDT.
• appLayerSessionStatus-r17: start or stop, sent when the configuration asked for session indications.
• ran-VisibleMeasurements-r17: the explicit, gNB-readable part. A report can carry the container, the RAN visible values, or both.
• measReportAppLayerContainerList-r18: several stored containers for the same configuration in one entry, up to 16. This is used when reports collected in idle or inactive are sent after the UE connects.
• Segmentation: a report larger than the maximum PDCP SDU is segmented only if rrc-SegAllowedSRB4 (or SRB5) is enabled. Otherwise the message is discarded, so the network should enable it for long sessions.

There is a detail here that I think is easy to miss. The UE AS treats a report as delivered only in the normal RRC way. If the gNB pauses reporting, the containers are kept in the AS, not in the application. So the memory that matters is in the modem, and Release 18 added a capability for additional memory (qoe-AdditionalMemoryMeasReport-r18) and priority-based discarding when it fills up.

RAN visible QoE

Now the layer that makes NR QMC different from a pure OAM tool. The encapsulated report goes to the MCE, and the gNB cannot read it. So the gNB that schedules the UE has no idea whether the video is about to stall. Then you may ask: is there a way to let the gNB see at least the most useful QoE values, in real time ? That is RAN visible QoE (RVQoE). A small subset of QoE metrics is reported as explicit RRC fields, which the gNB can decode and use for its own optimization.

RAN visible QoE is supported for DASH streaming and VR, not for MTSI. It can be configured only together with a corresponding QoE configuration, and only for the metrics that OAM or the core marked as available. Figure 2 shows how the two layers travel in the same report.

Figure 2. The two layers of a QoE report. The encapsulated container goes through the gNB to the MCE unchanged, while the RAN visible measurements are explicit fields that the gNB reads itself.

Following is based on 38.331 v19.4.0 (Release 19)

RAN-VisibleParameters-r17 ::=        SEQUENCE {
    ran-VisiblePeriodicity-r17           ENUMERATED {ms120, ms240, ms480, ms640, ms1024}                            OPTIONAL, -- Need S
    numberOfBufferLevelEntries-r17       INTEGER (1..8)                                                             OPTIONAL, -- Need R
    reportPlayoutDelayForMediaStartup-r17 BOOLEAN                                                                   OPTIONAL, -- Need M
    ...,
    [[
    ran-VisibleReportingSRB-r18          ENUMERATED {srb4, srb5}                                                    OPTIONAL  -- Cond QoENRDC
    ]]
}

RAN-VisibleMeasurements-r17 ::=       SEQUENCE {
    appLayerBufferLevelList-r17           SEQUENCE (SIZE (1..8)) OF AppLayerBufferLevel-r17                        OPTIONAL,
    playoutDelayForMediaStartup-r17       INTEGER (0..30000)                                                       OPTIONAL,
    pdu-SessionIdList-r17                 SEQUENCE (SIZE (1..maxNrofPDU-Sessions-r17)) OF PDU-SessionID            OPTIONAL,
    ...,
    [[
    pdu-SessionIdListExt-v1800            SEQUENCE (SIZE (1..maxNrofPDU-Sessions-r17)) OF QFI-List-r18             OPTIONAL
    ]]
}

AppLayerBufferLevel-r17 ::= INTEGER (0..30000)

• ran-VisiblePeriodicity-r17: 120 ms to 1024 ms. If absent, the RAN visible part follows the reporting period inside the container, which is usually much longer.
• numberOfBufferLevelEntries-r17: up to 8 buffer level samples per report. The application samples the buffer at the reporting period divided by this number, so a 480 ms period with 4 entries gives one sample every 120 ms.
• appLayerBufferLevelList-r17: the player buffer level, newest first. The unit is 10 ms, so 30000 means 300 seconds (5 minutes), and anything larger is reported as 30000.
• playoutDelayForMediaStartup-r17: how long the media took to start, in ms, up to 30000 ms. It is reported when reportPlayoutDelayForMediaStartup is true.
• pdu-SessionIdList-r17 / pdu-SessionIdListExt-v1800: which PDU sessions, and in Release 18 which QoS flows, carry the measured service. This is what lets the gNB connect a QoE value to the right bearer.

How the gNB uses these values is not specified, and I think that is intended. A natural use is the buffer level. A DASH buffer that keeps falling means a stall is coming, so the scheduler could give that UE more resources before the user notices, and less to a UE whose buffer is already full. The PDU session and QFI list is what makes this possible, because it tells the gNB which flow to boost.

Mobility, RRC states and NR-DC

A QoE session can last much longer than a stay in one cell. A movie runs for two hours, and the UE may hand over many times or go to RRC_INACTIVE between video segments. So what happens to the QoE configuration ? Release 17 covered handover and RRC_INACTIVE, and Release 18 added NR-DC, MBS and collection in RRC_IDLE and RRC_INACTIVE.

• Handover: the source gNB can send the QoE configuration information to the target over Xn or NG, including the QoE reference, the container and the RAN visible configuration. For signalling-based QoE the target decides which configurations to keep. A target that does not support QMC makes the UE release all configurations.
• Area scope: the network keeps track of whether the UE is inside the area scope. A UE continues an ongoing measurement even after leaving the area, unless the network releases the configuration.
• RRC_INACTIVE: the QoE configuration is stored in the UE inactive AS context, as described in the RRC Inactive page.
• RRC_IDLE: the UE releases all configurations except those explicitly marked as applicable in RRC_IDLE and RRC_INACTIVE.
• Idle and inactive collection (Release 18): for MBS broadcast sessions, a configuration with appLayerIdleInactiveConfig-r18 continues in idle and inactive. The UE stores the reports in the AS and indicates their availability when it connects. The stored information includes the QoE reference, measurement type, area scope, MCE ID and available RAN visible metrics.
• NR-DC (Release 18): reports can go to the SN on SRB5, selected by reportingSRB-r18 and ran-VisibleReportingSRB-r18. SRB5 is configured by the SN and exists only in NR-DC. The DC side is in the MR-DC and NR-DC page.
• Inter-RAT: from a gNB to an ng-eNB only one QoE configuration can continue, and the UE then uses the LTE QoE configuration. In the other direction, the UE releases the LTE configuration and applies the NR one.

Two more items connect QMC to other pages of this site. A QoE configuration can carry a slice scope, so the experience can be measured per slice, and the UE includes the slice identifier inside the report container. This is the RAN side of per-slice SLA monitoring, related to the RAN Slicing page. And QoE can be aligned with Immediate MDT, so the radio measurements and the QoE values of the same UE can be correlated at the MCE and TCE. That alignment uses the session start and stop indications, as described in Overall Procedure of Immediate MDT.

Release Evolution

The release placement below is based on the release suffix of the fields in the latest ASN.1. Some features have no field of their own, such as per-slice QoE or MDT alignment. For those I took the item from the latest TS 38.300 clause 21 and did not tag a release, because the text does not say when it was added.

When QoE does not appear in a trace, the UE capability is the first thing to check. AppLayerMeasParameters-r17 reports support per service type (qoe-Streaming-MeasReport-r17, qoe-MTSI-MeasReport-r17, qoe-VR-MeasReport-r17), support of RAN visible QoE for streaming and VR, and support of segmentation (ul-MeasurementReportAppLayer-Seg-r17). The Release 18 group adds qoe-IdleInactiveMeasReport-r18, qoe-NRDC-MeasReport-r18, qoe-PriorityBasedDiscarding-r18 and srb5-r18. A gNB selects UEs for management-based QoE only among those with the required capability, so a UE that does not report the service type is never configured.

Reference

• 3GPP TS 38.300 V19.4.0 : NR; NR and NG-RAN Overall description; Stage-2. Clause 21 (Application Layer Measurement Collection)
• 3GPP TS 38.331 V19.4.0 : NR; Radio Resource Control (RRC) protocol specification. Clauses 5.3.5.13d and 5.7.16, AppLayerMeasConfig, MeasurementReportAppLayer
• 3GPP TS 37.340 V19.3.0 : NR; Multi-connectivity; Overall description; Stage-2. Clause 13.4 (Application Layer Measurement Collection in NR-DC)
• 3GPP TS 26.247 (DASH), TS 26.114 (MTSI) and TS 26.118 (VR) define the QoE metrics carried in the containers. These were not opened for this page.
• QoS, MDT for NR, MR-DC and NR-DC, RAN Slicing (ShareTechnote)