LS on issues related to support of IMS voice over NB-IoT NTN connected to EPC
SA2 is studying support for IMS voice over NB-IoT NTN connected to EPC under study item FS_5GSAT_Ph4_ARC (TR 23.700-019). The study is investigating solutions using both IP and non-IP PDN connection types for voice traffic. SA2 requires input from multiple working groups to evaluate alternative solutions and achieve target KPIs.
When IP PDN connections are used, Robust Header Compression (RoHC) is expected to be required to meet KPIs. RoHC is supported:
- Between UE and eNB for "user plane" DRBs
- Between UE and MME for "control plane CIoT" using SRBs
Key Technical Issue: During voice calls, consecutive packet losses or erroneous decompression can trigger RoHC state fallbacks:
- SO (Second Order) → FO (First Order) state: ~16 consecutive lost packets (e.g., UO-0 header with 4-bit SN)
- FO → IR (Initialization and Refresh) state: ~64 consecutive lost packets (e.g., UOR-2 header with 6-bit SN)
These state transitions cause gaps in voice packet transmission.
Question 1 (RAN2): Observations on number of consecutive packets lost/erroneously decompressed triggering RoHC state fallback?
Question 2 (RAN1): Probability data for 16 or 64 consecutive packet losses/erroneous decompression? Frequency of such events?
Voice packets exhibit different sizes due to:
- Talk/silence transitions
- RoHC state changes
- Other dynamic factors
Question 3 (RAN2): Can scheduling methods for IMS voice over NB-IoT NTN handle dynamically changing voice packet sizes?
For non-IP voice media traffic, there is no header compression. Understanding essential RTP header fields is necessary to reduce overhead.
Question 4 (SA4): What are the essential RTP header fields (sequence number, timestamp, SSRC, Payload Type) for minimum information needed in RTP header for IMS voice over NB-IoT NTN?
Question 5 (SA4): Views on reducing RTP header overhead for IMS voice over NB-IoT NTN?
Current limitation: NB-IoT UE supports maximum 2 DRBs. Supporting more DRBs would enable simultaneous voice and other services during calls.
Question 6 (RAN2): Is it feasible to support more than 2 DRBs for UE accessing NB-IoT in Rel-20?
Several solutions under Key Issue #1 use control-plane mechanisms with Control Plane CIoT EPS optimization and SRBs for SIP signaling and/or voice media.
Rel-19 NORDAT_CP WI specified new NAS message with reduced overhead:
- NAS layer overhead: 2 bytes
- Security overhead: 4 bytes (MAC for integrity protection)
- Sequence number: 1 byte
- Total: 7 bytes
Question 7 (SA3): For dedicated SRB (via dedicated EPS bearer for Data over NAS) carrying only voice media packets, is there concern to eliminate the 5 bytes of NAS layer security overhead?
Question 8 (CT1): Beyond security considerations, any further possibility to reduce NAS overhead beyond Rel-19 NORDAT_CP for transporting voice packets over NB-IoT NTN?
Currently, SRBs only support RLC Acknowledged Mode (AM) per TS 36.331. For control-plane solutions carrying voice media, RLC Unacknowledged Mode (UM) may be beneficial.
Question 9 (RAN2): Feedback on possibility to define new SRB for carrying voice media?
Question 10 (RAN2): If yes to Question 9, is it technically feasible to support and configure RLC UM for such SRB(s) in NB-IoT deployments over GEO satellite when SRBs carry voice media?
Per TS 22.228: UE can support multiple IMS voice calls (e.g., using communication HOLD service).
Per TS 23.014 and TS 26.114 Annex G: Dual Tone Multi-Frequency (DTMF) signaling requires DTMF events as telephone events within same RTP media stream as speech ("inband"), using same IP address and UDP port but different RTP Payload Type number.
These requirements affect overall protocol stack overhead for non-IP based solutions.
Question 11 (SA1): Can SA1 confirm whether support for multiple IMS voice calls and DTMF is required for IMS voice over NB-IoT NTN?
SA2 requests respective WGs to answer questions addressed to them and provide any other necessary feedback.