# 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)