Reply LS on MBS Communication Service Type

Document Information

• Source: Nokia [to be SA4]
• Target: RAN3, RAN2 (CC: SA5)
• Meeting: SA4 Meeting #135 (9-13 February 2026, Goa, India)
• Response to: S4-260016/S4-251660/R3-255896
• Release: Release 18
• Work Item: NR_QoE_enh-Core

Overall Description

This is a reply LS from SA4 addressing RAN3's questions regarding the MBS Communication Service Type attribute in QoE (Quality of Experience) configurations, specifically related to TS 26.247.

Technical Responses

Response to Question A: Cardinality of Communication Service Types

RAN3's Question: RAN3 pointed out that for a QMC (QoE Measurement Collection) configuration, only one communication service type is possible at a time in their specifications. They requested confirmation to delete "or more" from the description stating "one or more" communication service types.

SA4's Answer: - SA4 acknowledges that Rel-18 signaling for QMC in RAN3 specifications only supports a single communication service type per QoE Reference - SA4 agrees to delete the term "or more" from the Description field of the @communicationServiceType attribute - The attribute will now indicate support for only one communication service type per QMC configuration

Response to Questions B and C: Default Value and "all" Value Handling

RAN3's Questions: - Question B: Should the value "all" be deleted since RAN3 specifications don't support combinations of multiple communication service types in a single QMC configuration? - Question C: Can the @communicationServiceType have a default value even though the Use is "O" (Optional)? If no, remove the sentence about default behavior. If yes, should the default be "unicast" since combinations aren't supported? RAN3 assumes Rel-17 UEs only support unicast communication service for QoE measurement.

SA4's Answer: - SA4 notes that @communicationServiceType is unspecified in Rel-17 - SA4 suggests leaving the implementation to vendors for Rel-17 behavior - SA4 will keep the @communicationServiceType attribute as optional (introduced in Rel-18) - A related CR to TS 26.247 is attached to further clarify the usage of QoE configuration and reporting by QMC functionalities

Action Requested

SA4 kindly asks RAN3 and RAN2 to take the above information into account.

Next SA4 Meetings

• SA4#135-bis-e: 13-17 April 2026 (e-meeting)
• SA4#136: 11-15 May 2026 (Montreal, Canada)