TS 29.244 - Wrong information element name for MBS Session

[Borjis131]

Description

Table 7.5.3.1-4 in TS 129 244 V17.9.0: MBS Session N4mb Information IE within PFCP Session Establishment Response shows "MBS Session N4 Information IE Type = 303 (decimal)" in the Octet 1 and 2 row instead of "MBS Session N4mb Information IE Type = 303 (decimal)".

Suggested solution

Replace Octet 1 and 2 row with "MBS Session N4mb Information IE Type = 303 (decimal)".

Additional context

The error is causing Open5GS to have an incorrect implementation.

(Open5GS seems to parse the .docx spec using the tools here.)

[dsilhavy]

@haudiobe to forward to CT4 delegate

[rjb1000]

Suggest checking if this affects V18.3.0 as well.

If so, please add the "3GPP Rel-18" tag to this issue.

[rjb1000]

Response from Hanna Lim, Qualcomm delegate to 3GPP CT4:

As indicated in the link, Octec 1 and 2 of the table 7.5.3.1-4 in TS29.244 needs to be revised to N4mb.

I think the CRs for both Rel-17 and Rel-18 are necessary. I will contact the Rapporteur of the 5MBS_Ph2 (Huawei) and handle it in CT4#121/Feb.

[Borjis131]

The issue is present in Release 18.3.0 too

[rjb1000]

I notice that CT4#121 in February was cancelled. The next meeting is CT4#122 (Athens) starting on Monday, 26th February. It looks like @haudiobe's colleague Hanna Lim has made a contribution to address this issue:

• TS 29.244
  • Rel-17: No contribution.
  • Rel-18: CR0821 "Editorial correction of MBS Session N4mb Information IE" in C4-240320

@Borjis131: Please review the CR and confirm urgently to @haudiobe whether you need this change to be mirrored into Rel-17 as well so that this can happen during the CT4#121 meeting next week.

[Borjis131]

Thanks @rjb1000 and @haudiobe. The main idea was to change it in Rel-17, were I found it because I was working with that spec. So this change should be mirrored to Rel-17 too.

[rjb1000]

The final response from CT4 delegates on the possibility of an additional Rel-17 CR is as follows:

On 27/02/2024 17:00, Bruno Landais (Nokia) wrote:

The correction has zero effect on the protocol/messages between the SMF and UPF. In other words, the correction is purely editorial and does not qualify as a CR correcting a Frequent and Serious Misoperation (FASMO) and accordingly cannot be agreed against frozen 3GPP releases as per 3GPP working procedures.

So, that's a no, I'm afraid, @Borjis131! You'll have to be content with the Rel-18 change only (if it is agreed at CT4#121 this week). You can monitor progress of CR0821 and any revisions here.

[Borjis131]

Thank you @rjb1000 and @haudiobe! It is ok, the Rel-17 case was fixed by Sukchan a couple weeks ago. So I think we can close this one?

[rjb1000]

I'd like to keep the issue open to record the agreement (or otherwise) at CT4#121 this week and the approval (or otherwise) at SA#103 next month.

[rjb1000]

Change Request agreed at CT4#122 (Athens):

• TS 29.244
  • Rel-17: No contribution.
  • Rel-18: CR0821 "Editorial correction of MBS Session N4mb Information IE" in C4-240320

CT4 declined to make the same change on Rel-17 on the grounds that it is a purely editorial correction in a frozen release. However, this doesn't take into account the fact that @acetcom autogenerates code for Open5GS by parsing the specification document.