5G-MAG / Standards

Specifications related to 5G-MAG's areas of work. Tracking comments, bug-fixing, request for new features, etc.
https://www.5g-mag.com/standards
12 stars 4 forks source link

Clarification on direction of RTC QoE metrics reported #137

Closed samhurst closed 6 days ago

samhurst commented 3 months ago

Context

Clause 15 of TS 26.113 V18.0.0 describes the QoE metrics which can be reported by the Media Session Handler pertaining to an RTC session.

RTC sessions may be unidirectional.

Problem description

TS 26.506 does not specify whether QoE metrics reporting for RTC applies to downlink or uplink or both.

Clause 15 of TS 26.113 does not specify whether these metrics apply to uplink aspects of an RTC session or downlink aspects.

Reading the metrics specified, most of them only make sense to be reported by a receiving RTC Client, but this is not explicitly stated.

Suggested solution

Explicitly state in TS 26.506 which direction whether it's for contributed or consumed media sessions the QoE metrics are to be collected and reported for.

srinivasgu commented 3 months ago

Hi @samhurst, @rjb1000

Thanks for pointing out this missing information. The proposed QoE metrics shall be reported by an RTC UE for the down-link media. I can clarify this TS 26.113 specification as below "An RTC UE supporting Quality of Experience (QoE) shall report QoE metrics for receiving media according to the QoE configuration.

rjb1000 commented 3 months ago

Thanks for confirming the design intent, @srinivasgu .

For TS 26.113, how about;

An RTC UE supporting Quality of Experience (QoE) shall report QoE metrics for the media it has received according to the QoE configuration.

rjb1000 commented 3 months ago

In addition, the QoE metrics reporting feature is very poorly motivated at stage-2, @srinivasgu . It's severely underdefined in TS 26.506, leaving the stage-3 specification open to criticism. Shortcutting the 3GPP process in this way only leads to trouble further down the line.

Functionality of the RTC Media Session Handler

I notice the following relevant paragraph in clause 4.2.4 of TS 26.506:

In addition, one of subfunction in RTC MSH is the metric collection and reporting. It executes the collection of QoS and QoE metrics measurements from the RTC Access Function and the RTC Application and sends metrics reports to the RTC AF for the purpose of metrics analysis or to enable potential transport optimizations by the network.

(The grammar in the first sentence is very dodgy.)

This should be improved upon to explain what kind of QoE metrics are to be collected and reported by the Media Session Handler. It sounds like the answer is metrics about received RTC sessions.

A stage-2 specification should go further and explicitly list the classes of metric that are in scope of the release. This could be a simple bullet list with one entry for each kind of metric you ended up specifying in TS 26.113, accompanied by a sentence briefly explaining what that metric is used for in the RTC System. (Actually, a two-column table might be better on reflection.)

Definition of reference point RTC-5

Clause 4.3.4 lists the metrics reporting configuration as something the Media Session Handler obtains at RTC-5, but completely fails to mention that metrics reports (and consumption reports for that matter) are subsequently submitted to the RTC AF at this reference point!

Maybe that is what is meant by the following bullet, but it's as clear as mud, and could usefully be clarified to explicitly mention the vital missing keywords metrics reporting and consumption reporting:

  • RTC MSH informs the RTC AF about a RTC session and its state

Procedures for RTC

Finally, clause 5.1 of TS 26.506 fails to mention reporting at all in its bullet list of procedures. Hence, there are no subsequent clauses describing the procedures for metrics reporting or consumption reporting. The closest I could find was step 19 in clause 5.5, but that's quite well hidden.

If QoE metrics reporting is a procedure common to the various collaboration scenarios, it should be given its own dedicated clause under 5.2 with a simple sequence diagram and a description of the steps in the call flow.

rjb1000 commented 2 months ago

@srinivasgu from InterDigital has confirmed that he will prepare Change Requests for SA4#129-e on both TS 25.506 (stage-2) and TS 26.113 (stage-3).

rjb1000 commented 2 months ago

CRs contributed by @srinivasgu (InterDigital) to SA4#129-e for agreement:

rjb1000 commented 1 month ago

CRs agreed at SA4#129-e Closing Plenary:

Thanks for addressing this issue, @srinivasgu. Check these out, @samhurst.

rjb1000 commented 6 days ago

CRs approved at SA#105 (Melbourne):

rjb1000 commented 6 days ago

New TS versions published: