16 Quality of Experience

26.1143GPPIP Multimedia Subsystem (IMS)Media handling and interactionMultimedia telephonyRelease 18TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

16.1 General

The MTSI Quality of Experience (QoE) metrics feature is optional for an MTSI client in a terminal and shall not disturb the MTSI service. Non-terminal MTSI clients (such as gateways) should not implement MTSI QoE reporting. An MTSI client that supports the QoE metrics feature shall support OMA-DM. The OMA-DM configuration server can configure the activation/deactivation and gathering of QoE metrics in the MTSI client (see clause 16.3). Configuration can also be done using the QMC functionality (see clause 16.5). An MTSI client supporting the QoE metrics feature shall perform the quality measurements in accordance to the measurement definitions, aggregate them into client QoE metrics and report the metrics. The MTSI client may send QoE metrics reports during the session and at the end of the session. The way how the QoE metrics are processed and made available is out of the scope of this specification.

16.2 Metrics Definition

An MTSI client supporting the QoE metrics feature shall support the reporting of the metrics in this clause. The metrics are valid for speech, video and text media, and are calculated for each measurement resolution interval "Measure-Resolution" (sub-clause 16.3.2). They are reported to the server according to the measurement reporting interval "Sending-Rate" (sub-clause 16.3.2) and after the end of the session (sub-clause 16.4).

16.2.1 Corruption duration metric

Corruption duration, M, is the time period from the NPT time of the last good frame (since the NPT time for the first corrupted frame cannot always be determined) before the corruption, to the NPT time of the first subsequent good frame. A corrupted frame may either be an entirely lost frame, or a media frame that has quality degradation and the decoded frame is not the same as in error-free decoding.

A good frame is a completely received frame:

– where all parts of the image are guaranteed to contain the correct content; or

– that is a refresh frame, that is, does not reference any previously decoded frames; or

– which only references previously decoded good frames

Completely received means that all the bits are received and no bit error has occurred.

Corruption duration, M, in milliseconds can be calculated as below:

a) M can be derived by the client using the codec layer, in which case the codec layer signals the decoding of a good frame to the client. A good frame could also be derived by error tracking methods, but decoding quality evaluation methods shall not be used.

b) Alternatively, the corruption is considered as ended after N milliseconds with consecutively completely received frames, or when a refresh frame has been completely received, whichever comes first..

The optional configuration parameter N can be set to define the average characteristics of the codec. If N has not been configured it shall default to the length of one measurement interval for video media, and to one frame duration for non-video media.

The syntax for the metrics "Corruption_Duration" is as defined in sub-clause 16.3.2.

The N parameter is specified in milliseconds and is used with the "Corruption_Duration" parameter in the "3GPP-QoE-Metrics" definition. The value of N may be set by the server. The syntax for N to be included in the "att-measure-spec" (sub-clause 16.3.2) is as follows:

– N = "N" "=" 1*DIGIT

All the occurred corruption durations within each resolution period are summed and stored in the vector TotalCorruptionDuration. The unit of this metrics is expressed in milliseconds. Within each resolution period the number of individual corruption events are summed up and stored in the vector NumberOfCorruptionEvents. These two vectors are reported by the MTSI client as part of the reception report (sub-clause 16.4).

The parameter CorruptionAlternative indicates how the metric has been calculated, and shall be sent by the client via reception reporting (sub-clause 16.3.2) as "a", or "b".

16.2.2 Successive loss of RTP packets

The metric "Successive_Loss" indicates the number of RTP packets lost in succession per media channel.

The syntax for the metrics "Successive_Loss" is as defined in sub-clause 16.3.2.

All the number of successively lost RTP packets are summed up within each measurement resolution period of the stream and stored in the vector TotalNumberofSuccessivePacketLoss. The unit of this metric is expressed as an integer equal to or larger than 0. The number of individual successive packet loss events within each measurement resolution period are summed up and stored in the vector NumberOfSuccessiveLossEvents. The number of received packets are also summed up within each measurement resolution period and stored in the vector NumberOfReceivedPackets. These three vectors are reported by the MTSI client as part of the QoE report (sub-clause 16.4)

16.2.3 Frame rate

Frame rate indicates the playback frame rate. The playback frame rate is equal to the number of frames displayed during the measurement resolution period divided by the time duration, in seconds, of the measurement resolution period.

The syntax for the metric "Frame_Rate" is defined in sub-clause 16.3.2.

For the Metrics-Name "Frame_Rate", the value field indicates the frame rate value. This metric is expressed in frames per second, and can be a fractional value. The frame rates for each resolution period are stored in the vector FrameRate and reported by the MTSI client as part of the QoE report (sub-clause 16.4).

16.2.4 Jitter duration

Jitter happens when the absolute difference between the actual playback time and the expected playback time is larger than JitterThreshold milliseconds. The expected time of a frame is equal to the actual playback time of the last played frame plus the difference between the NPT time of the frame and the NPT time of the last played frame.

The syntax for the metric "Jitter_Duration" is defined in sub-clause 16.3.2.

The optional configuration parameter JT can be set to control the amount of allowed jitter. If the parameter has not been set, it defaults to 100 ms. The JT parameter is specified in ms and is used with the "Jitter_Duration" parameter in the "3GPP-QoE-Metrics" definition. The value of JT may be set by the server. The syntax for JT to be included in the "att-measure-spec" (sub-clause 16.3.2) is as follows:

– JT = "JT" "=" 1*DIGIT

All the jitter durations are summed up within each measurement resolution period and stored in the vector TotalJitterDuration. The unit of this metric is expressed in seconds, and can be a fractional value. The number of individual events within the measurement resolution period are summed up and stored in the vector NumberOfJitterEvents. These two vectors are reported by the MTSI client as part of the QoE report (sub-clause 16.4).

Note that the jitter duration metric is not measuring the incoming RTP or frame jitter, but instead the actual visible media playback jitter. Thus with a large enough jitter buffer the incoming RTP or frame jitter might be substantial, without any measurable jitter duration being reported (even if the JitterThreshold would have been set to zero).

16.2.5 Sync loss duration

Sync loss happens when the absolute difference between value A and value B is larger than SyncThreshold milliseconds. Value A represents the difference between the playback time of the last played frame of the video stream and the playback time of the last played frame of the speech/audio stream. Value B represents the difference between the expected playback time of the last played frame of the video stream and the expected playback time of the last played frame of the speech/audio stream.

The syntax for the metric "SyncLoss_Duration" is defined in sub-clause 16.3.2.

The optional configuration parameter ST can be set to control the amount of allowed sync mismatch. If the parameter has not been set, it defaults to 100 ms. The ST parameter is specified in ms and is used with the "SyncLoss_Duration" parameter in the "3GPP-QoE-Metrics" definition. The value of ST may be set by the server. The syntax for ST to be included in the "att-measure-spec" (sub-clause 16.3.2) is as follows:

– ST = "ST" "=" 1*DIGIT

All the sync loss durations are summed up within each measurement resolution period and stored in the vector TotalSyncLossDuration. The unit of this metric is expressed in seconds, and can be a fractional value. The number of individual events within the measurement resolution period are summed up and stored in the vector NumberOfSyncLossEvents. These two vectors are reported by the MTSI client as part of the QoE report (sub-clause 16.4).

16.2.6 Round-trip time

The round-trip time (RTT) consists of the RTP-level round-trip time, plus the additional two-way delay (RTP level->loudspeaker->microphone->RTP level) due to buffering and other processing in each client.

The syntax for the metric "Round_Trip_Time" is defined in sub-clause 16.3.2.

The last RTCP round-trip time value estimated during each measurement resolution period shall be stored in the vector NetworkRTT. The unit of this metrics is expressed in milliseconds.

The two-way additional internal client delay valid at the end of each measurement resolution period shall be stored in the vector InternalRTT. The unit of this metrics is expressed in milliseconds.

The two vectors are reported by the MTSI client as part of the QoE report (sub-clause 16.4).

Note that if the RTP and the RTCP packets for a media are not sent in the same RTP stream the estimated media round-trip time might be unreliable.

16.2.7 Average codec bitrate

The average codec bitrate is the bitrate used for coding "active" media information during the measurement resolution period.

For speech media "active" information is defined by frames containing speech, i.e. silence frames (SID-frames) and DTX periods are excluded from the calculation. If application-layer redundancy is used, any redundant frames should also be excluded. If partial redundancy is used within frames (e.g. EVS channel-aware mode), only the non-redundant bits in these frame should be counted as having "active" information.

The exact method for how the client identifies the active frames or bits is not specified here, and it is recognized that an implementation might not be able to fully exclude all non-active frames or bits from the calculation.

Thus for speech media the average codec bitrate can be calculated as the number of "active" speech bits received for "active" frames , divided by the total time, in seconds, covered by these frames. The total time covered is calculated as the number of "active" frames times the length of each speech frame.

For non-speech media the average codec bitrate is the total number of RTP payload bits received, divided by the length of the measurement resolution period.

The syntax for the metric "Average_Codec_Bitrate" is defined in sub-clause 16.3.2.

The average codec bitrate value for each measurement resolution period shall be stored in the vector AverageCodecBitrate. The unit of this metrics is expressed in kbit/s and can be a fractional value. The vector is reported by the MTSI client as part of the QoE report (sub-clause 16.4).

16.2.8 Codec information

The codec information metrics contain details of the media codec settings used in the receiving direction during the measurement resolution period. If the codec information is changed during the measurement resolution period, the codec information valid when each measurement resolution period ends shall be reported. The unit of this metric is a string value. No "white space" characters are allowed in the string values, and shall be removed if necessary.

For speech media the semi-colon-separated codec information contains the used speech codec type (represented as in an SDP rtpmap offer) and the used codec settings for bandwidth and redundancy (represented as in an SDP fmtp offer). For instance "EVS/16000/1;bw=swb;", or "EVS/16000/1;ch-aw-recv=3".

For video media, the codec information contains the video codec type, represented as in an SDP offer, for instance "H265/90000". Furthermore, the semi-colon-separated video profile, level (and tier if applicable) used shall be reported, represented as in an SDP offer. For instance for H.265, "profile-id=1;level-id=120;tier-flag=1", or for H.264, "profile-level-id=42e00a". The actually used image size (not the maximum allowed) shall also be reported, represented as "WxH", for example "320×240".

For real-time text media, the codec information contains the text encoding, represented as in an SDP offer, for instance "t140/1000/1".

The syntax for the metric "Codec_Info", "Codec_ProfileLevel" and "Codec_ImageSize" are defined in sub-clause 16.3.2.

The codec info, profile/level/tier and codec image size value for each measurement resolution period shall be stored in the vectors CodecInfo, CodecProfileLevel and CodecImageSize respectively. If the metric values in these vectors for a measurement resolution period are unchanged from the previous values in the respective vector, it is allowed to put the value "=" in the vector to indicate this. The CodecInfo, CodecProfileLevel and CodecImageSize vectors are reported by the MTSI client as part of the QoE report (sub-clause 16.4).

16.2.9 Call setup time

The call setup time is measured on SIP level for originating calls (see ITU-T G-1028 [181] Table 3). It is defined as the time between the transmitted INVITE, and the reception of either "200 OK" or "180 RINGING" (whichever comes first).

The syntax for the metric "Call_Setup_Time" is defined in sub-clause 16.3.2.

The measured call setup time shall be stored in the variable CallSetupTime. The unit of this metrics is expressed in milliseconds. The variable is reported by the MTSI client as part of the QoE report (sub-clause 16.4).

NOTE: The reason for also using "180 RINGING" as an end-of-call-setup criteria is to compensate for the physical answering delay caused by the called user. Thus the metric measures the fastest possible call setup time, i.e. as if the called user had answered directly.

16.3 Metric Configuration

An MTSI client supporting the QoE metrics feature shall support the OMA-DM solution specified in this clause for configuration of QoE metrics and their activation. The MTSI client shall also support the QMC functionality specified in clause 16.5 for configuration of QoE metrics.

The QoE configuration shall only be evaluated by the client at the start of a QoE measurement and reporting session (“QoE session”) associated with a MTSI session. This includes evaluation of any filtering criteria such as by geographical area. Client evaluation of all measurement and reporting criterias for an ongoing QoE session shall be unaffected by any QoE configuration changes received during that session – i.e., any changes to the QoE configuration shall only affect QoE sessions started after these configuration changes have been received.

If an MTSI client uses the OMA-DM configuration feature, it is mandatory for the MTSI client to implement the Management Object (MO) as described in this clause.

The 3GPP MTSIQOE (MTSI QoE metrics) MO defined in this clause may be used to configure the QoE metrics and reporting settings.

The metrics specified in the MO may be derived by the MTSI client. Version numbering is included for possible extension of the MO.

The Management Object Identifier shall be: urn:oma:mo:ext-3gpp-mtsiqoe:1.0.

Protocol compatibility: The MO is compatible with OMA Device Management protocol specifications, version 1.2 and upwards, and is defined using the OMA DM Device Description Framework as described in the Enabler Release Definition OMA-ERELD _DM-V1_2 [67].

16.3.1 QoE metrics reporting management object

The following nodes and leaf objects in figure 16.1 shall be contained under the 3GPP_MTSIQOE node if an MTSI client supports the feature described in this clause (information of DDF for this MO is given in Annex I):

Figure 16.1: MTSI QoE metrics management object tree

Node: /<X>

This interior node specifies the unique object id of a MTSI QoE metrics management object. The purpose of this interior node is to group together the parameters of a single object.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

The following interior nodes shall be contained if the MTSI client supports the "MTSI QoE metrics Management Object".

/<X>/Enabled

This leaf indicates if QoE reporting is requested by the provider.

– Occurrence: One

– Format: bool

– Minimum Access Types: Get

/<X>/Servers

This leaf contains a space-separated list of URL of servers to which the QoE reports can be transmitted. It is URI addresses, e.g. http://qoeserver.operator.com. In case of multiple servers, the MTSI client randomly selects one of the servers from the list, with uniform distribution.

– Occurrence: One

– Format: chr

– Minimum Access Types: Get

– Values: URI of the servers to receive the QoE report.

/<X>/APN

This leaf contains the Access Point Name that should be used for establishing the PDP context or EPS bearer on which the QoE metric reports will be transmitted. This may be used to ensure that no costs are charged for QoE metrics reporting.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: the Access Point Name

/<X>/Format

This leaf specifies the format of the report and if compression (Gzip XML) [71] is used.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: "XML", "GZIPXML".

/<X>/Rules

This leaf provides in textual format the rules used to decide whether metrics are to be reported to the QoE metrics report server. The syntax and semantics of this leaf are defined in clause 16.3.3.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: See clause 16.3.3.

/<X>/Ext

The Ext node is an interior node where the vendor specific information can be placed (vendor includes application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Speech

The Speech node is the starting point of the speech media level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Speech/Metrics

This leaf provides in textual format the QoE metrics that need to be reported, the measurement frequency, the reporting interval and the reporting range. The syntax and semantics of this leaf are defined in clause 16.3.2.

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: see clause 16.3.2.

/<X>/Speech/Ext

The Ext node is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Video

The Video node is the starting point of the video media level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Video/Metrics

– Occurrence: ZeroOrOne

– Format: chr

– Access Types: Get

– Values: see clause 16.3.2.

/<X>/Video/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the Ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/Text

The Text node is the starting point of the real-time text media level QoE metrics definitions.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

– Values: see clause 16.3.2.

/<X>/Text/Metrics

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: see clause 16.3.2.

/<X>/Text/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/<LocationFilter>

When present, this element indicates the geographic area(s) or location(s) where quality metric collection is requested. When not present, quality metric collection is requested regardless of the device’s location. The LocationFilter element comprises one or more instances of any combination of targeted cell-IDs, polygons and circular areas.Each cell-ID entry in LocationFilter is announced in cellList, and each polygon and circular area entry is announced in the polygonList or and circularAreaList elements, respectively.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

/<X>/<LocationFilter>/CellList

This element specifies a list of cell identified by the CGI (i.e., NCGI, ECGI, CGI).

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: a list of CGI.

/<X>/<LocationFilter>/PolygonList

This leaf specifies a list of shapes defined as ‘Polygon’ by OMA MLP [159].

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: a list of ‘Polygon’ defined by OMA MLP [159].

/<X>/<LocationFilter>/Polygon_Conf_Level

This leaf indicates the probability in percent that the MTSI client is located in the corresponding polygon area specified by leaf ‘PolygonList’. It is defined as ‘lev_conf’ by OMA MLP [159]. If not present, it has default value of 60.

– Occurrence: ZeroOrOne

– Format: int

– Minimum Access Types: Get

– Values: ‘lev_conf’ defined by OMA MLP [159].

/<X>/<LocationFilter>/CircularAreaList

This leaf specifies a list of shapes defined as ‘CircularArea’ by OMA MLP [159].

– Occurrence: ZeroOrOne

– Format: chr

– Minimum Access Types: Get

– Values: a list of ‘CircularArea’ defined by OMA MLP [159].

/<X>/<LocationFilter>/Circular_Conf_Level

This leaf indicates the probability in percent that the MTSI client is located in the corresponding circular area specified by leaf ‘CircularAreaList’. It is defined as ‘lev_conf’ by OMA MLP [159]. If not present, it has default value of 60.

– Occurrence: ZeroOrOne

– Format: int

– Minimum Access Types: Get

– Values: ‘lev_conf’ defined by OMA MLP [159].

/<X>/<LocationFilter>/Ext

The Ext is an interior node where the vendor specific information can be placed (vendor meaning application vendor, device vendor etc.). Usually the vendor extension is identified by vendor specific name under the ext node. The tree structure under the vendor identified is not defined and can therefore include one or more un-standardized sub-trees.

– Occurrence: ZeroOrOne

– Format: node

– Minimum Access Types: Get

16.3.2 QoE metric reporting configuration

The syntax of the text contained in the Metrics leaf is similar to the "3GPP-QoE-Metrics" attribute syntax specified in TS 26.234 [60] and TS 26.346 [74]:

– QoE-Metrics = "3GPP-QoE-Metrics:" att-measure-spec *("," att-measure-spec)) CRLF

– att-measure-spec = Metrics ";" Sending-rate [";" Measure-Range]
[";" Measure-Resolution] *([";" Parameter-Ext])

– Metrics = "metrics" "=" "{"Metrics-Name *("|" Metrics-Name) " }"

– Metrics-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"

– Sending-Rate = "rate" "=" 1*DIGIT / "End"

– Measure-Resolution = "resolution" "=" 1*DIGIT ; in seconds

– Measure-Range = "range" ":" Ranges-Specifier

– Parameter-Ext = (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))

– Ranges-Specifier = as defined in RFC 2326 [72].

This attribute is used to indicate which QoE metrics are supported, the reporting interval, the measurement interval and reporting range.

The "Metrics" field contains the list of names that describes the metrics/measurements that are required to be reported in a MTSI call, provided that the MTSI client supports these measurements and the reporting rule conditions are met (see clause 16.3.3). The names that are not included in the "Metrics" field shall not be reported during the session.

The "Sending-Rate" shall be set, and it expresses the maximum time period in seconds between two successive QoE reports. If the "Sending-Rate" value is 0, then the client shall decide the sending time of the reports depending on the events occurred in the client. Values ≥ 1 indicate a precise reporting interval. The shortest interval is one second and the longest interval is undefined. The reporting interval can be different for different media, but it is recommended to maintain a degree of synchronization in order to avoid extra traffic in the uplink direction. The value "End" indicates that only one report is sent at the end of the session.

The optional "Measure-Resolution" field, if used, shall define a time over which each metrics value is calculated. The "Measure-Resolution" field splits the session duration into a number of equally sized periods where each period is of the length specified by the "Measure-Resolution" field. The "Measure-Resolution" field is thus defining the time before the calculation of a QoE parameter starts over. If the "Measure-Resolution" field is not present, the metrics resolution shall cover the period specified by the "Measure-Range" field. If the "Measure-Range" field is not present the metrics resolution shall be the whole session duration.

The optional "Measure-Range" field, if used, shall define the time range in the stream for which the QoE metrics will be reported. There shall be only one range per measurement specification. The range format shall be any of the formats allowed by the media. If the "Measure-Range" field is not present, the metrics range shall be the whole call duration.

16.3.3 QoE reporting rule definition

This clause defines the syntax and semantics of a set of rules which are used to reduce the amount of reporting to the QoE metrics report server. The syntax of the metrics reporting rules is defined below:

– QoE-Rule = "3GPP-QoE-Rule" ":" rule-spec *("," rule-spec)

– rule-spec = rule-name [";" parameters]

– rule-name = "OnlyCallerReports" / "LimitSessionInterval" / "SamplePercentage"

– parameters = parameter *(";" parameter)

– parameter = Param-Name ["=" Param-Value ]

– Param-Name = 1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7e) ;VCHAR except ";", ",", "{" or "}"

– Param-Value = (1*DIGIT ["." 1*DIGIT]) / (1*((0x21..0x2b) / (0x2d..0x3a) / (0x3c..0x7a) / 0x7c / 0x7e))

The semantics of the rules and the syntax of its parameters is defined below:

The OnlyCallerReports rule is used to determine the metrics reporting sources. When this rule is present, only the initiator of the call, i.e., caller, will report metrics to the QoE report server. When absent all parties report metrics.

The SamplePercentage rule can be used to set a percentage sample of calls which should report reception. This can be useful for statistical data analysis of large populations while increasing scalability due to reduced total uplink signalling. The sample_percentage parameter takes on a value between 0 and 100, including the use of decimals. It is recommended that no more than 3 digits follow a decimal point (e.g. 67.323 is sufficient precision).

When the SamplePercentage rule is not present or its sample_percentage parameter value is 100 each MTSI client shall send metric report(s). If the sample_percentage value is less than 100, the UE generates a random number which is uniformly distributed in the range of 0 to 100. The UE sends the reception report when the generated random number is of a lower value than the sample_percentage value.

The LimitSessionInterval rule is used to limit the time interval between consecutive calls that report metrics. The min_interval parameter for this rule indicates the minimum time distance between the start of two calls that are allowed to report metrics. When this rule is absent there is no limitation on the minimum time interval.

In case multiple rules are defined in the Management Object, the MTSI client should only report metrics when all individual rules evaluate to true (i.e. the rules are logically ANDed). In case no rules are present the MTSI client should always report metrics (see also clause 16.4 for metrics reporting procedures).

An example for a QoE metric reporting rule is shown below:

3GPP-QoE-Rule:OnlyCallerReports,SamplePercentage;sample_percentage=10.0,
LimitSessionInterval;min_interval=300,

This example rule defines that only the caller shall report, and only for 10% of the sessions, with the minimum time interval between the start times of two consecutive calls that report metrics to be 5 minutes.

16.4 Metrics Reporting

When a session is started, the MTSI client must determine whether QoE reporting is required for the session. If the parameter "Enabled" is set to false, no QoE reporting shall be done. If the "Enabled" parameter is set to true the optional "Rules" parameters are checked (sub-clause 16.3.3) to define if QoE reporting shall be done.

Once the need for QoE reporting has been established, the client shall continuously compute all specified metrics for each measurement interval period, according to the "Measure-Resolution" parameter (sub-clause 16.3.2). In order to bound the resources used by metrics reporting, the minimum values for the Measure-Resolution and Sending-Rate are specified to be 5 seconds and 30 seconds respectively. The computed metrics are represented in a vector format, adding an additional metric value to each metric vector after each new measurement interval period.

Note that the calculated metrics shall only cover one measurement interval. For instance, if the corruption duration extends longer than to the end of the current measurement interval, only the portion which fits into the current measurement interval shall be reported. The remaining portion of the corruption duration shall be reported as belonging to the next measurement interval.

The end of the session will normally not correspond to the end of a measurement interval period, so the metrics for the last measurement interval period will typically be calculated over a time shorter than the configured measurement interval. Note, however, that these last metrics shall still be added to the metrics vectors and reported to the server.

It is possible for the server to use the start and stop timestamps, together with the knowledge of the configured measurement interval, to derive the actual length of the last measurement interval period, but any specific action or interpretation of these last shorter measurements is out of scope of this specification.

The MTSI client shall send QoE report messages to the server in accordance with the specified reporting interval "Sending-Rate" (sub-clause 16.3.2). All stored metrics data shall then be sent to the server, and then deleted from the metrics storage.

Note that if the reporting interval is not an integer multiple of the measurement interval, only the measurement interval periods which have been fully passed shall be included in the report. The ongoing not-passed measurement interval period shall be included in the next report. The only exception is at the end of the session, where also the last ongoing measurement interval period shall be directly calculated and included in the report.

If QoE configuration has been done via the OMA MO, the client shall send QoE reports using the HTTP (RFC 2616 [73]) POST request carrying XML formatted metadata. If the optional "APN" parameter is defined in the OMA managed object, that APN shall be used for establishing the PDP context or EPS bearer on which the QoE metric reports will be transmitted. The MTSI client randomly selects one of the URIs from the MO "Server" parameter, with uniform distribution.

If QoE configuration has been done via the QMC functionality (see clause 16.5), the client shall also send the QoE reports as described in clause 16.5. Note that for QMC scheme, if the SliceScope is included in the QoE configuration and the slice associated with the MTSI service is within the SliceScope, the QoE collection shall be executed and the S-NSSAI and DNN that correspond to the report data shall be included for support of per-slice QoE reporting and evaluation in OAM. This information may be retrieved via the AT Command +CGDCONT [161]) or the specific traffic mapping with URSP rule[182].

Each QoE report is formatted in XML according the following XML schema (sub-clause 16.4.1). An informative example of a single reception report XML object is also given (sub-clause 16.4.2). The reports should be compressed using GZIP only if the MO parameter "Format" specifies this.

Each QoE Metrics element has a set of attributes and any number of media level QoE Metrics elements. All attributes are defined in sub-clause 16.4.1 and correspond to the QoE metrics listed in sub-clause 16.2. Individual metrics can be selected as described in sub-clause 16.3.2.

Except for the media level QoE metrics, the following parameters shall be reported for each report:

– The callId attribute identifies the call identity of the SIP session.

– The clientId attribute is unique identifier for the receiver, e.g. an MSISDN of the UE as defined in [80].

– The startTime and stopTime attributes identifies the client NTP time when the measurements included in the report were started and stopped. The time is based on the local real-time clock in the client, and might not be consistent with the true NTP time. However, assuming that the reporting is done without any extra delay the server can use the stopTime attribute to correct the timestamps if necessary.

– The mediaId attribute shall be reported for each media level QoE report, and identifies the port number for the media.

If the attribute qoeReferenceId was defined in the QMC configuration (see clause 16.5.2), the value shall be copied into each QoE report, to facilitate network-side correlation (see [178]). If this attribute was defined, the attribute recordingSessionId shall also be returned for each QoE report. The recordingSessionId is a two-byte octet defined by the client. It shall remain the same for all QoE reports belonging to the same session, and it should be different for QoE reports belonging to different sessions.

16.4.1 XML schema for QoE report message

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="urn:3gpp:metadata:2008:MTSI:qoereport"

xmlns="urn:3gpp:metadata:2008:MTSI:qoereport"

elementFormDefault="qualified">

<xs:element name="QoeReport" type="QoeReportType"/>

<xs:complexType name="QoeReportType">

<xs:sequence>

<xs:element name="statisticalReport" type="starType" minOccurs="0"

maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="skip" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="starType">

<xs:sequence>

<xs:element name="mediaLevelQoeMetrics" type="mediaLevelQoeMetricsType" minOccurs="1"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="startTime" type="xs:unsignedLong" use="required"/>

<xs:attribute name="stopTime" type="xs:unsignedLong" use="required"/>

<xs:attribute name="callId" type="xs:string" use="required"/>

<xs:attribute name="clientId" type="xs:string" use="required"/>

<xs:attribute name="qoeReferenceId" type="xs:hexBinary" use="optional"/>

<xs:attribute name="recordingSessionId" type="xs:hexBinary" use="optional"/>

<xs:attribute name="dnn" type="xs:string" use="optional"/>

<xs:attribute name="snssai" type="xs:unsignedLong" use=”optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:complexType name="mediaLevelQoeMetricsType">

<xs:sequence>

<xs:any namespace="##other" processContents="skip" minOccurs="0"

maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="mediaId" type="xs:integer" use="required"/>

<xs:attribute name="totalCorruptionDuration" type="unsignedLongVectorType"
use="optional"/>

<xs:attribute name="numberOfCorruptionEvents" type="unsignedLongVectorType"
use="optional"/>

<xs:attribute name="corruptionAlternative" type="xs:string" use="optional"/>

<xs:attribute name="totalNumberofSuccessivePacketLoss" type="unsignedLongVectorType"

use="optional"/>

<xs:attribute name="numberOfSuccessiveLossEvents" type="unsignedLongVectorType"
use="optional"/>

<xs:attribute name="numberOfReceivedPackets" type="unsignedLongVectorType"
use="optional"/>

<xs:attribute name="framerate" type="doubleVectorType" use="optional"/>

<xs:attribute name="totalJitterDuration" type="doubleVectorType" use="optional"/>

<xs:attribute name="numberOfJitterEvents" type="unsignedLongVectorType"

use="optional"/>

<xs:attribute name="totalSyncLossDuration" type="doubleVectorType" use="optional"/>

<xs:attribute name="numberOfSyncLossEvents" type="unsignedLongVectorType"

use="optional"/>

<xs:attribute name="networkRTT" type="unsignedLongVectorType" use="optional"/>

<xs:attribute name="internalRTT" type="unsignedLongVectorType" use="optional"/>

<xs:attribute name="codecInfo" type="stringVectorType" use="optional"/>

<xs:attribute name="codecProfileLevel" type="stringVectorType" use="optional"/>

<xs:attribute name="codecImageSize" type="stringVectorType" use="optional"/>

<xs:attribute name="averageCodecBitrate" type="doubleVectorType" use="optional"/>

<xs:attribute name="callSetupTime" type="xs:unsignedLong" use="optional"/>

<xs:anyAttribute processContents="skip"/>

</xs:complexType>

<xs:simpleType name="doubleVectorType">

<xs:list itemType="xs:double"/>

</xs:simpleType>

<xs:simpleType name="stringVectorType">

<xs:list itemType="xs:string"/>

</xs:simpleType>

<xs:simpleType name="unsignedLongVectorType">

<xs:list itemType="xs:unsignedLong"/>

</xs:simpleType>

</xs:schema>

16.4.2 Example XML for QoE report message

Below is one example of QoE report message, in this example the measurement interval is 20 seconds, the reporting interval is 5 minutes, but the call ends after 55 seconds.

<?xml version="1.0" encoding="UTF-8"?>

<QoeReport xmlns="urn:3gpp:metadata:2008:MTSI:qoereport"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:3gpp:metadata:2008:MTSI:qoereport qoereport.xsd">

<statisticalReport

startTime="1219322514"

stopTime="1219322569"

clientId="clientID"

callId="callID">

qoeReferenceId="240F512A"

snssai="01000FFF"

dnn="internet.mnc015.mcc234.gprs"

recordingSessionId="0001"

<mediaLevelQoeMetrics

mediaId="1234"

totalCorruptionDuration="480 0 120"

numberOfCorruptionEvents="5 0 2"

corruptionAlternative="a"

totalNumberofSuccessivePacketLoss="24 0 6"

numberOfSuccessiveLossEvents="5 0 2"

numberOfReceivedPackets="535 645 300"

framerate="50.0 49.2 50.0"

numberOfJitterEvents="0 1 0"

totalJitterDuration="0 0.346 0"

networkRTT="120 132 125"

internalRTT="20 24 20"

codecInfo="AMR-WB/16000/1 = ="

averageCodecBitRate="12.4 12.65 12.7"/>

callSetupTime="345"

<mediaLevelQoeMetrics

mediaId="1236"

totalCorruptionDuration="83 0 0"

numberOfCorruptionEvents="1 0 0"

corruptionAlternative="b"

totalNumberofSuccessivePacketLoss="3 0 0"

numberOfSuccessiveLossEvents="2 0 0"

numberOfReceivedPackets="297 300 225"

framerate="14.7 15.0 14.9"

numberOfJitterEvents="0 0 0"

totalJitterDuration="0 0 0"

numberOfSyncLossEvents="0 1 0"

totalSyncLossDuration="0 0.789 0"

networkRTT="220 232 215"

internalRTT="27 20 25"

codecInfo="H263-2000/90000 = ="

codecProfileLevel="profile=0;level=45 = ="

codecImageSize="176×144 = ="

averageCodecBitRate="124.5 128.0 115.1"/>

callSetupTime="345"/>

</statisticalReport>

</QoeReport>

16.5 QoE Measurement Collection Functionalities

16.5.1 Configuration and reporting

As an alternative to configuration via OMA-DM, the QoE configuration can optionally be specified by the QoE Measurement Collection (QMC) functionality. In this case the QoE configuration is received via specific RRC [158] messages for UMTS, RRC [160] messages for LTE, and RRC [163] messages for NR over the control plane, and the QoE reporting is also sent back via RRC messages over the control plane.

If QMC is supported, the UE shall support the following QMC functionalities:

– QoE Configuration: The QoE configuration will be delivered via RRC to the UE as a container according to "Application Layer Measurement Configuration" (see [158]) for UMTS, "measConfigAppLayer" (see [160]) for LTE and “AppLayerMeasConfig” for NR (see [163]). The container is an octet string with gzip-encoded data (see [71]) stored in network byte order. The maximum size of the container is 1000 bytes for UMTS (see [158]) and LTE (see [160]), and 8000 bytes for NR (see [163]). When the container is uncompressed it is expected to conform to XML-formatted QoE configuration data according to clause 16.5.2 in the current specification. This uncompressed QoE Configuration shall be delivered to the MTSI client. The interface towards the RRC signalling is handled by the AT command +CAPPLEVMC for UMTS and LTE, and the AT command +CAPPLEVMCNR for NR [161].

– QoE Metrics: QoE Metrics from the MTSI client shall be XML-formatted according to clause 16.4 in the current specification. The XML data shall be compressed with gzip (see [71]) and stored in network byte order into an octet string container. The maximum size is 8000 bytes for UMTS (see [158]) and LTE (see [160]). For NR (see [163]), the maximum size is 8000 bytes if RRC segmentation is not enabled, and 144000 bytes if enabled. The container shall be delivered via RRC to the RNC according to "Application Layer Measurement Reporting" (see [158]) for UMTS, to the eNB according to "measReportAppLayer" (see [160]) for LTE, and to the gNB according to “MeasurementReportAppLayer” for NR (see [163]). The behaviour if the compressed data is larger than the maximum container size is unspecified in this version of the specification. The interface towards the RRC signalling is handled by the AT command +CAPPLEVMR for UMTS and LTE, and the AT command +CAPPLEVMRNR for NR [161].

– The UE shall also set the QMC capability "QoE Measurement Collection for MTSI services" (see [158]) to TRUE for UMTS, include the QMC capability "qoe-mtsi-MeasReport" (see [160]) for LTE, and include the QMC capability “qoe-MTSI-MeasReport” (see [163]) for NR.

The QoE configuration AT command +CAPPLEVMC or AT command +CAPPLEVMCNR [161] may also indicate with an Within-area Indication if the UE is inside or outside a wanted geographic area. Such an indication may arrive with or without any QoE configuration container attached. If the MTSI client is informed that it is not inside the area, it shall not start any new QoE measurements even if it has received a valid QoE configuration container, but shall continue measuring for already started sessions.

When a new session is started, the QoE reporting AT command +CAPPLEVMR or AT command +CAPPLEVMRNR [161] shall be used to send a Recording Session Indication. Such an indication does not contain any QoE report, but indicates that QoE recording has started for a session.

When the QoE configuration is to be released, an unsolicited result code associated with the AT command +CAPPLEVMC or AT command +CAPPLEVMCNR [161] and containing the parameter <start-stop_reporting> set to "1", shall be sent to the MTSI client as notification of a discard request. Then the MTSI client shall stop collecting quality metrics and discard any already collected information [178].

The exact implementation is not specified here, but example signalling diagrams for UMTS, LTE and NR below show the QMC functionality with a hypothetical "QMC Handler" entity.

Figure 16.5.1-1: Example signalling diagram for UMTS

Figure 16.5.1-2: Example signalling diagram for LTE

Figure 16.5.1-3: Example signalling diagram for NR

NOTE: The QMC Handler is only shown here as one possible implementation, and it need not be implemented as such. The corresponding QMC functionality could be built into the MTSI client or into other UE entities. In this version of the specification the detailed implementation of the above functionalities is left to the UE vendor.

16.5.2 XML configuration

When QoE reporting is configured via the QMC functionality, the configuration basically contains the same information as in the QoE metrics reporting managed object (see clause 16.3.1), but encapsulated according to the XML scheme below. Note that the managed object leaves "Servers", "APN" and "Format" are not needed for the QMC functionality, and thus not included.

Note that if geographical filtering is handled on the network side (i.e. QoE reporting is turned on/off by the network depending on the UE location), no LocationFilter should be specified in the QoE Configuration, as this would mean two consecutive filterings.

Also note that the optional attribute qoeReferenceId is a reference set by the network side (see [178]), which is not directly used by the client. However, if this attribute is defined, it shall be copied into each QoE report, to facilitate network-side correlation.

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema targetNamespace="urn:3gpp:metadata:2017:MTSI:qoeconfig"

elementFormDefault="qualified"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

xmlns:sv="urn:3gpp:metadata:2017:MTSI:schemaVersion"

xmlns="urn:3gpp:metadata:2017:MTSI:qoeconfig">

<xs:element name="MTSIQualityReporting" type="QualityReportingType"/>

<xs:complexType name="QualityReportingType">

<xs:sequence>

<xs:element name="LocationFilter" type="LocationFilterType" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="enabled" type="xs:boolean" use="required"/>

<xs:attribute name="rules" type="xs:string" use="optional"/>

<xs:attribute name="speechMetrics" type="xs:string" use="optional"/>

<xs:attribute name="videoMetrics" type="xs:string" use="optional"/>

<xs:attribute name="textMetrics" type="xs:string" use="optional"/>

<xs:attribute name="qoeReferenceId" type="xs:hexBinary" use="optional"/>

<xs:attribute name="sliceScope" type="UnsignedIntVectorType" use="optional"/>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:complexType name="LocationFilterType">

<xs:sequence>

<xs:element name="cellID" type="xs:unsignedLong" minOccurs="0" maxOccurs="unbounded"/>

<xs:element name="shape" type="ShapeType" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:complexType name="ShapeType">

<xs:sequence>

<xs:element name="PolygonList" type="PolygonListType" minOccurs="0"/>

<xs:element name="CircularAreaList" type="CircularAreaListType" minOccurs="0"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:complexType name="PolygonListType">

<xs:annotation>

<xs:documentation> see [OMA MLP] </xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="Polygon" minOccurs="0" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="ConfLevel" type="xs:unsignedInt" use="optional"/>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:complexType name="CircularAreaListType">

<xs:annotation>

<xs:documentation> see [OMA MLP] </xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="CircularArea" minOccurs="0" maxOccurs="unbounded"/>

<xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>

</xs:sequence>

<xs:attribute name="ConfLevel" type="xs:unsignedInt" use="optional"/>

<xs:anyAttribute namespace="##other" processContents="lax"/>

</xs:complexType>

<xs:simpleType name="UnsignedIntVectorType">
<xs:list itemType="xs:unsignedInt"/>
</xs:simpleType>

</xs:schema>

<?xml version="1.0" encoding="UTF-8"?>

<xs:schema targetNamespace="urn:3gpp:metadata:2017:MTSI:schemaVersion"

xmlns="urn:3gpp:metadata:2017:MTSI:schemaVersion"

xmlns:xs="http://www.w3.org/2001/XMLSchema"

elementFormDefault="qualified">

<xs:element name="schemaVersion" type="xs:unsignedInt"/>

<xs:element name="delimiter" type="xs:byte"/>

</xs:schema>