# 3GPP Technical Document Summary

## Document Information
- **Document Number:** S4-260016 / R3-255896
- **Meeting:** SA4 #135 (February 2026) / RAN3 #129 (August 2025)
- **Title:** Reply LS on MBS Communication Service Type
- **Release:** Release 18
- **Work Item:** NR_QoE_enh-Core
- **Response to:** S4-251096/R3-255028

## Overall Context

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.

## Technical Issues and Questions Raised

### Question A: Cardinality of Communication Service Types

**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.

### Question B: Support for "all" Value

**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.

### Question C: Default Value for Optional Attribute

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

### Additional Observation

**RAN3 Assumption:** Release 17 UEs can perform QoE measurement collection and reporting **only for unicast** communication service.

## Actions Requested

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

## Key Technical Implications

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