[FS_ULBC] Support for Dual-Tone Multi-Frequency for IMS voice over NB-IoT NTN
SA1 has mandated support for Dual-Tone Multi-Frequency (DTMF) for IMS voice over NB-IoT NTN. The document addresses the need to consider multiplexing of DTMF traffic with voice traffic in the system design, referencing RFC 4733 for DTMF payload formats.
RFC 4733 defines two DTMF payload format types:
- Telephone events: User button presses (0-9, , #) during calls
- Tones*: Ringing tone, busy tone, etc.
For IMS calls, tones are generated locally (e.g., "180 Ringing" or "486 Busy Here" SIP messages trigger local tone generation), so only telephone events need to be transported over the air.
The document identifies key DTMF traffic characteristics:
- DTMF packets are transmitted infrequently (only on button press)
- Telephone events may or may not overlap with active voice activity
- Multiple DTMF packets may be transmitted per button press, with the RTP marker bit indicating the first packet
- RTP packets must differentiate between voice and DTMF packets for multiplexing
Three key assumptions are established:
1. DTMF packet size ≤ voice packet size
2. DTMF delay requirements are less stringent than voice service
3. DTMF takes priority over voice
When SPS (Semi-Persistent Scheduling) is configured for voice traffic with fixed TBS:
- If DTMF packets don't overlap with active voice frames, they can be multiplexed with SID frames (smaller than active voice frames) and transmitted in SPS occasions
- If overlapping occurs, the UE can puncture an active voice frame and send the DTMF frame instead
- SA4 needs to coordinate with RAN1 and RAN2 on SPS design
Proposal 1: Make DTMF support an integral part of IMS voice service over NB-IoT NTN
Proposal 2: Design DTMF support based on the three assumptions:
- DTMF packet size ≤ voice packet size
- DTMF delay requirement less stringent than voice
- DTMF priority over voice
Proposal 3: SA4 to design mechanisms for voice and DTMF multiplexing for SPS and coordinate with RAN1 and RAN2