Reply LS on MBS Communication Service Type
This is a Reply Liaison Statement from RAN3 to SA4 regarding the MBS (Multicast/Broadcast Service) Communication Service Type specification. RAN3 is responding to SA4's previous LS and raising several follow-up questions concerning the implementation of the @communicationServiceType attribute in TS 26.247, specifically related to QoE (Quality of Experience) measurement collection and reporting.
Issue: SA4's CR to TS 26.247 (S4-251095) states that the @communicationServiceType attribute "shall contain one or more of the following values."
RAN3 Position:
- For a QMC (QoE Measurement Collection) configuration, only one communication service type is possible at a time
- The phrase "or more" should be deleted from the Description field
Request: RAN3 asks SA4 to confirm this interpretation and update the specification accordingly.
Issue: SA4 previously indicated that the value "all" for @communicationServiceType refers to all communication service types (broadcast, multicast, and unicast) - Option 1 interpretation.
RAN3 Position:
- A given QoE Reference can only point to a single communication service type in RAN3 specifications
- Combination of two or more communication service types in a single QMC configuration is not supported in RAN3 specifications
- Therefore, the value "all" should be deleted from the @communicationServiceType attribute
Request: RAN3 asks SA4 to confirm this and remove the "all" value.
Issue: SA4 revised the attribute from "OD" (Optional with Default) to "O" (Optional) in TS 26.247. However, the CR (S4-251095) still states: "When absent, quality metrics collection is requested for all communication service types."
RAN3 Questions:
1. Can the @communicationServiceType have a default value even though the Use is "O"?
2. If no: RAN3 asks SA4 to remove the sentence about default behavior from the Description field
3. If yes: RAN3 asks SA4 to confirm whether the default value can be "unicast" (since RAN3 specifications do not support combinations of multiple communication service types in a single QMC configuration)
RAN3 Assumption: Release 17 UEs can perform QoE measurement collection and reporting only for unicast communication service.
RAN3 requests SA4 to:
1. Take the above issues into account
2. Provide answers to Questions A, B, and C
3. Update SA4 specifications accordingly if feasible
The core technical disagreement centers on:
- Multiplicity constraint: RAN3 specifications support only single communication service type per QMC configuration, while SA4's text suggests multiple types are possible
- Default behavior: Misalignment between attribute cardinality (Optional) and presence of default value semantics
- Backward compatibility: Ensuring Release 17 UE capabilities (unicast-only) are properly considered in Release 18 specifications