1 / 14

GERAN Voice and Data Multiplexing (OS2) Proposal

GERAN Voice and Data Multiplexing (OS2) Proposal. Source: AT&T, Ericsson For: 3GPP TSG GERAN Adhoc #2 9 -13 October 2000 Munich, Germany. Introduction. Operational Scenario 2 is a fundamental service requirement for R00

bisa
Télécharger la présentation

GERAN Voice and Data Multiplexing (OS2) Proposal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GERAN Voice and Data Multiplexing (OS2) Proposal Source: AT&T, Ericsson For: 3GPP TSG GERAN Adhoc #2 9 -13 October 2000 Munich, Germany

  2. Introduction • Operational Scenario 2 is a fundamental service requirement for R00 • OS2 multiplex single user’s voice and (E)GPRS data on to single physical sub-channel • Objectives are: • support delay sensitive interactive data • improve channel utilization by sending data between talk spurts • Voice quality should not be impacted by best effort data

  3. Basic Requirements • Support single user’s voice and data multiplexing on single physical sub-channel for both FR and HR • Support time critical interactive data with limited interruption of speech that is similar to FACCH • No degradation of the speech quality with BED • No major degradation in the stealing bit performance • No changes to existing channel coding • No or minor change on current stealing bit design • BED performance is secondary to that of speech • Should not preclude legacy transceiver support.

  4. Background Information • State-based multiplexing • using the information from previously received and current data blocks for multiplexing • higher reliability with stealing bits in current data block • solutions shown so far required exhaustive search by decoder. • Stateless multiplexing • solely based on SB contained in current data block • number of SB will have to be increased, implying change in channel coding • This proposal is a sate-based approach based on existing AMR procedure

  5. OS2 Proposal with AMR Procedures • Use the already defined AMR procedures for DTX operation to place the receiver in different states. • Have a stealing bit codeword in DTX indicating speech.

  6. AMR DTX Identification markers Identifier types defined for AMR full and half-rate speech • SID_FIRST Marker to define end of speech • SID_UPDATE Used to convey comfort noise parameters during DTX • ONSET Used to signal the Codec mode for the first speech frame after DTX • RATCCH Robust AMR Traffic Synchronised Control Channel, used for codec renegotiations.

  7. AMR RX Speech Identifiers • SPEECH_GOOD Speech frame with CRC OK, Channel Decoder soft values also OK • SPEECH_DEGRADED Speech frame with CRC OK, but 1B bits and class2 bits may be corrupted • SPEECH_BAD (likely) speech frame, bad CRC (or very bad Channel Decoder measures) • NO_DATA Nothing useable (for the speech decoder) was received.

  8. AMR Rx DTX handler states

  9. Physical layer states

  10. Example of OS2 Operation

  11. Missed ONSET example • In case of missed ONSET • Receiver still in DTX state • Will move to speech state by block interleaved stealing bits indicating speech (all zeros)

  12. State Transition Reliability Issue • State transition reliability requires error recovery e.g. when state transition messages are lost. • All error scenarios will have to be thoroughly investigated. • Methods to further improve state transition reliability, if believed necessary, are not precluded (such as using predefined USF bit pattern on downlink, check data header CRC etc).

  13. Enhancements to Support Delay Critical Data • Proposed scheme could be enhanced to support time critical data, such as SIP by forcing interrupt speech for a short period.

  14. Conclusions • A mechanism to support OS2 multiplexing has been presented that meets the speech quality performance and design simplicity requirements. • There are no changes to the existing channel coding. • Minor change of stealing bits. • Full link adaptation possible for EGPRS. • Low increase in receiver complexity. • Easily extendable to support SIP.

More Related