search

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

Misalignment between stage 2 and stage 3 of media session handling when a Background Data Transfer is granted #140

Closed samhurst closed 1 month ago

samhurst commented 3 months ago

Context

There is a difference between expected return types as described in TS 26.501 and TS 26.510 about granted Background Data Transfer sessions

Problem description

In step 12 of clause 5.7.8 of TS 26.501 it states (emphasis mine):

The 5GMSd AF responds to the Media Session Handler to grant the Background Data Transfer request. The grant response includes a recommendation from the 5GMSd AF of the maximum time period for which the Background Data Transfer is available and the maximum Background Data Transfer volume granted for the media streaming session during this grant period (which may be smaller than that requested in step 10).

Meanwhile, the M5BDTSpecification type specified in clause 9.3.3.3 of TS 26.510 states that the estimatedDataTransferVolume property is only provided in DynamicPolicy objects submitted by the Media Session Handler to the Media AF at reference point M5, which implies that it is not set by the Media AF on DynamicPolicy objects returned.

In addition, table 11.3.1.2-2 of TS 26.510 lists the following return values for the activatePolicy() client API method on the Media Session Handler at M6/M11:

Name Type Description
recommendedDownlinkBitRate dateTime The recommended downlink bit rate for the requested Service Operation Point.
recommendedUplinkBitRate dateTime The recommended uplink bit rate for the requested Service Operation Point.
backgroundDataTransferActivated integer Indicates whether Background Data Transfer has been successfully activated for the media delivery session for the duration of the indicated time window.

This deviates from what is defined in TS 26.501, because these are the QoS policy bit rates and not the maximum volume of data.

Thus, the existence of the maximum Background Data Transfer volume described in the sequence described in TS 26.501 is missing from the Media Session Handling Client API at reference points M6/M11 and the Session Handling API at reference point M5.

Suggested solution

Either add the maximum Background Data Transfer volume permitted by the 5G System at the reference points listed above, or amend TS 26.501 to mirror what's specified in TS 26.510.

rjb1000 commented 3 months ago

What do you reckon, @ibouazizi?

I think that returning the recommended uplink/downlink bit rate to the client API invoker in the Dynamic Policy grant is perfectly fine.

As for the substantive misalignment, however: what is the correct remedy to align the stage-2 design for Background Data Transfer with the stage-3 realisation? Can the Media AF realistically return a data volume grant to the Media Session Handler (and, thence, to the client API invoker)?

ibouazizi commented 3 months ago

I agree with Richard that stage 2 needs to be aligned with stage 3. The initial assumption was that the AF will get the aggregate data volume from the PCF and then just split it among all clients and signal each client's share to them via M5. This would not be optimal for several reasons. For once, the AF can hardly estimate the number of clients interested in that BDT window. It is also sub-optimal to split the aggregate data volume equally among all clients as some may need more than others. It is more preferable to have the MSH send the estimated data volume and then let the AF accept or reject the activation of BDT for that specific session.

rjb1000 commented 3 months ago

OK. So we jump in the direction of removing the granted maximum Background Data Transfer volume from the stage-2 design in TS 26.501 (Rel-18 only).

The affected locations are:

rjb1000 commented 3 months ago

Reserved TDocs at the forthcoming SA4#129-e meeting:

Draft shared with @ibouazizi, @haudiobe, @tlohmar and @samhurst.

rjb1000 commented 3 months ago

Change Requests agreed at SA4#129-e meeting:

To be sent to SA#105 seeking approval.

rjb1000 commented 1 month ago

Change Requests approved at SA#105 (Melbourne):

rjb1000 commented 1 month ago

New specifications published: