Content for TS 26.114 Word version: 18.8.0

0… 3… 4… 5… 6… 6.2.3… 6.2.5… 6.2.7… 6.2.10… 7… 7.5… 8… 9… 10… 10.2.1.6… 10.2.2… 10.3… 10.4… 11… 12… 12.3… 12.7… 13a… 16… 16.5… 17… 18… 19… A… A.3… A.4… A.5… A.10… A.14… A.15… B… C… C.1.3… C.1.3.5 C.2… D E… E.18… E.31… G… K… L… M… N… O… P… P.3 Q… R… S… T… U… V… W… X… Y… Y.6… Y.6.4… Y.6.5… Y.7…

16 Quality of Experience |R8| p. 168

16.1 General p. 168

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 p. 169

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" (subclause 16.3.2). They are reported to the server according to the measurement reporting interval "Sending-Rate" (subclause 16.3.2) and after the end of the session (subclause 16.4).

16.2.1 Corruption duration metric p. 169

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:

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.
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 subclause 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" (subclause 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 (subclause 16.4).

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

16.2.2 Successive loss of RTP packets p. 169

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 subclause 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 (subclause 16.4)

16.2.3 Frame rate p. 170

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 subclause 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 (subclause 16.4).

16.2.4 Jitter duration p. 170

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 subclause 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" (subclause 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 (subclause 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 p. 170

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 subclause 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" (subclause 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 (subclause 16.4).

16.2.6 Round-trip time p. 171

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 subclause 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 (subclause 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 p. 171

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 subclause 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 (subclause 16.4).

16.2.8 Codec information |R13| p. 171

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 "320x240".

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 subclause 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 (subclause 16.4).

16.2.9 Call setup time |R17| p. 172

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 subclause 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 (subclause 16.4).

16.3 Metric Configuration p. 172

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 p. 172

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):

Reproduction of 3GPP TS 26.114, Fig. 16.1: MTSI QoE metrics management object tree

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), RFC 1952 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 p. 178

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

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.

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 p. 178

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 p. 179

16.4.0 General |R18| p. 179

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 (subclause 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 (subclause 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" (subclause 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 9112) 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, TS 27.007) or the specific traffic mapping with URSP rule, TS 24.526.

Each QoE report is formatted in XML according the following XML schema (subclause 16.4.1). An informative example of a single reception report XML object is also given (subclause 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 subclause 16.4.1 and correspond to the QoE metrics listed in subclause 16.2. Individual metrics can be selected as described in subclause 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 TS 23.003.
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 TS 28.405). 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 p. 180

<?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 p. 182

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="176x144 = ="
    averageCodecBitRate="124.5 128.0 115.1"/>
    callSetupTime="345"/>
  </statisticalReport>
</QoeReport>