End-to-end VoIP QoS Shin-Gak Kang Protocol Engineering Center ETRI

Transcription

1 End-to-end VoIP QoS Shin-Gak Kang Protocol Engineering Center ETRI

2 Contents Introduction Characterizing End-to-End Speech QoS End-to-end QoS Architecture Delivering QoS End-to-end Conventional Approach Application Controlled Approach SIP-based end-to-end VoIP QoS Summary 2 S.G. Kang

3 Introduction(1) End-to-End QoS 관련 주요 표준화기구의 표준화 작업이 최근 활발하게 추진되고 있음 ITU-T SG 12 : End-to-end transmission performance of networks and terminals QoS Lead SG in ITU-T ITU-T SG 13 : Multi-protocol and IP-based networks and their internetworking IP Transfer Capabilities & IP QoS Classes ITU-T SG 11 : Signalling requirements and protocols BICC extension for End-to-end QoS service control ITU-T SG 16 : Multimedia services, systems and terminals Application Layer QoS Signaling 3 S.G. Kang

4 Introduction(2) ITU-T SSG : Special Study Group "IMT-2000 and Beyond 3GPP IETF Mobile QoS 3G Requirements and Protocols Request for IETF results SIP/SDP Extension ETSI/TIPHON(Telecommunications and Internet Protocol Harmonization Over Networks) End-to-end QoS Service : ETSI TS S.G. Kang

5 Characterizing End-to-End Speech QoS 5 S.G. Kang

6 Approach to Characterizing Speech QoS QoS is defined subjectively as perceived by the user, MOS Quality Ratio, R (by ITU-T G.109) Scored from 0 to 100 points It is end to end (e.g. mouth to ear for speech), A number of QoS Service Classes are defined, Classes include Guaranteed quality (statistically) and Unguaranteed (best effort) 6 S.G. Kang

7 Definition of TIPHON Speech QoS Classes BEST providies voice quality better than PSTN, using wideband audio (eg 7 khz) codecs, over QoS-engineered IP networks HIGH provides voice quality comparable to PSTN, over QoSengineered IP networks MEDIUM provides voice quality comparable to mobile telephony, over QoS-engineered IP networks BEST EFFORT provides usable voice quality, but not guaranteed, over non QoS-engineered IP networks 7 S.G. Kang

8 The TIPHON Speech QoS Classes Class Wideband High Narrowband Medium Acceptable Unguaranteed (Best Effort) Listener Speech Quality (One-way Noninteractive) Better than G.711 Equivalent or better than G.726 at 32 kbit/s Equivalent or better than GSM-FR Undefined Undefined End-to-end Delay (G.114) < 100ms < 100ms < 150ms < 400ms < 400ms* Overall Transmission Quality Rating (R) N.A. > 80 > 70 > 50 > 50* * Target value 8 S.G. Kang

9 TIPHON Service Classes & R Value R-value BEST HIGH MEDIUM BEST EFFORT BEST HIGH MEDIUM LOW POOR - ITU-T G.109 defines 5 categories of narrowband Telephony Speech Quality in terms of User Satisfaction * ITU-T Recommendation G.109: Definition of categories of Speech Transmission Quality 9 S.G. Kang

10 Inter-relationship of QoS Factors Network Packet Loss Network Jitter Network Delay Overall Packet Loss Jitter Buffers Codec Performance Overall Delay Perceived Quality Network Factors Application Factors QoS Service Level 10 S.G. Kang

11 QoS Parameters ITU-T SG12/16 QoS Service Class SERVICE ITU-T SG16/11 QoS Parameters: Codec Performance, Frame Size, Jitter Buffer Size, Codec Delay, Overall Packet Loss, FEC (Redundancy) APPLICATION ITU-T SG13/IETF Transport Parameters: Network Packet Loss, Mean Delay, Delay Variation TRANSPORT 11 S.G. Kang

12 Delivering QoS End-to-end - Conventional Approach - End-to-end signalling within and between Transport Domains which share common policies 12 S.G. Kang

13 Today s Internet QoS Model(1) Application Plane Transport Plane share common policies Transport Domain 1 Transport Domain 2 Transport Domain 3 Call Signaling QoS Signaling Media Packet Flow 13 S.G. Kang

14 Today s Internet QoS Model(2) Service Domain 1 Application Plane Transport Plane Transport Domain 1 Transport Domain 2 Transport Domain 3 Call Signaling QoS Signaling Media Packet Flow 14 S.G. Kang

15 End-to-end QoS Model in H.323 System H.225.0, H.245 Service Domain 1 H.225.0, H.245 H.225.0, H.245 RSVP, DiffServ Application Plane Transport Plane RSVP, DiffServ UDP/IP Transport Domain 1 RSVP, DiffServ UDP/IP Transport Domain 2 RSVP, DiffServ UDP/IP Transport Domain 3 UDP/IP H.323 Signaling QoS Signaling Packet Flow 15 S.G. Kang

16 H.323 End-to-end QoS Support H.323 Appendix 1 Allows for: End Points to indicate ability to support RSVP prior to call set-up, synchronization of QoS capability signalling with RSVP signalling between end points at call set-up 16 S.G. Kang

17 Problems with this Approach Transport domains may support different QoS mechanisms and policies Who owns the end to end picture? No mechanism to select transport domain on basis of QoS levels supported. c.f choice of alternative long distance carriers QoS messages are not signalled to the service provider - how can he control the QoS levels offered? Need a business model for supplying and charging for QoS 17 S.G. Kang

18 Current Work Need A new approach An end to end QoS architecture Domain by domain control A model that allows and supports charging for QoS 18 S.G. Kang

19 Delivering QoS End-to-end - Application Controlled Approach - 19 S.G. Kang

20 Two Alternative Business Models SERVICE PROVIDER ROUTED Clearing House Model Service Providers determine sequence of networks through which flows pass Service Providers have series of SLAs with Network Operators NETWORK OPERATOR ROUTED Service Provider has SLA with Local Network Operator Network operators determine sequence of networks through which flows pass Network Operators have SLAs among themselves 20 S.G. Kang

21 Service Provider Routed Model (1) Service Domain 1 Application Plane Transport Plane Transport Domain 1 Transport Domain 2 Transport Domain 3 QoS Signalling Call Signalling Packet Flow 21 S.G. Kang

22 Service Provider Routed Model (2) Service Domain 1 Service Domain 2 Application Plane Transport Plane Transport Domain 1 Transport Domain 2 Transport Domain 3 QoS Signalling Call Signalling Packet Flow 22 S.G. Kang

23 Network Operator Routed Model Service Domain 1 Application Plane Transport Plane Transport Domain 1 Local Network Operator SLA-1 Transport Domain 2 SLA-2 Transport Domain 3 Local Network Operator QoS Signalling Call Signalling Packet Flow 23 S.G. Kang

24 Additions to H.323 Protocols QoS is determined on a per media stream basis so, QoS is negotiated per media stream via H.245 New fields in H.245 under development QoS Class may be requested by End User via H.245 or H Additions to both protocols under development to enable this QoS characteristics of terminals may be registered with service providers This involves additions to H RAS New Annex N of H S.G. Kang

25 Advantages CLEAR BUSINESS MODEL The Application Service Provider is in the driving seat End-to-end QoS responsibility resides within the Application Plane Required end-to-end QoS levels are established within the Application Plane Between the End User and Service Provider Application Controlled Firewalls and NATS can be accommodated Transport Domains(Operators) provide a QoS service to the associated Service Domains(Service Providers) QoS control within a Transport Domain is the responsibility of the Operator of that domain 25 S.G. Kang

26 SIP 기반 종단간 VoIP QoS 제공 방안 26 S.G. Kang

27 SIP System Architecture Request Response SIP Redirect Server Location Service 1 12 SIP Client (UAC:User Agent Client) RTP Packets (Voice Data) End-to-end QoS SIP Proxy SIP Client (User Agent Server) Location Server SIP Proxy 27 S.G. Kang

28 SIP and end-to-end QoS draft-ietf-sip-manyfolks-resource-07 Integration of Resource Management and SIP Coordination between Call Signaling and Resource Management Session establishment doesn t take place until certain Preconditions are met Precondition a set of constraints about the session SIP extensions: Call Signaling Protocol SDP extensions: Session Parameters 28 S.G. Kang

29 SDP Parameters Extension Define Media Level SDP Attributes current-status = "a=curr:" precondition-type SP status-type SP direction-tag desired-status = "a=des:" precondition-type SP strength-tag SP status-type SP direction-tag confirm-status = "a=conf:" precondition-type SP status-type SP direction-tag precondition-type = "qos" token strength-tag = ("mandatory" "optional" "none = "failure" "unknown") status-type = ("e2e" "local" "remote") direction-tag = ("none" "send" "recv" "sendrecv") 29 S.G. Kang

30 SDP Attributes Current status carries the current status of network resources for a particular media stream Desired status carries the preconditions for a particular media stream Confirmation status carries threshold conditions for a media stream Strength tag indicates whether or not the callee can be alerted in case the network fails to meet the preconditions Direction tag indicates the direction a particular attribute is applicable to 30 S.G. Kang

31 SDP Attributes Status Type End-to-end reflects the status of the end-to-end reservation of resources useful when end-to-end resource reservation mechanisms are available Tag: e2e Segmented reflects the status of the access network reservations of both user agents useful when one or both UAs perform resource reservations on their respective access networks Tags: local, remote 31 S.G. Kang

32 Preconditions with Offer/Answer Model Both UA must maintain Local Precondition Status Local Status Table, Transaction Status Table Generating an Offer Transaction Status Table for End-to-end Status Type Direction Current Desired Strength send no mandatory recv no mandatory Transaction Status Table for Segmented Status Type Direction Current Desired Strength local send no none local recv no none remote send no optional remote recv no none 32 S.G. Kang

33 Preconditions with Offer/Answer Model SDP encoding m=audio RTP/AVP 0 a=curr:qos e2e none a=des:qos mandatory e2e sendrecv m=audio RTP/AVP 0 a=curr:qos local none a=curr:qos remote none a=des:qos optional remote send a=des:qos optional local none 33 S.G. Kang

34 Preconditions with Offer/Answer Model Generating an Answer Possible values for the Current fields Transaction Status Table Local Status Table New values Transaction/Local no no no/no yes yes yes/yes yes no yes/yes no yes depends on local info Values of tags in Offers and Answers Offer send recv local remote Answer recv send remote local 34 S.G. Kang

35 Preconditions with Offer/Answer Model Suspending and Resuming Session Establishment User SHOULD NOT be alerted until all the mandatory Preconditions are met Session establishment is suspended until that moment Ex: a PSTN Gateway reserves resources without sending signaling to the PSTN Status Confirmation Confirm-status attribute represents a Threshold for the resource reservation Confirmation attributes are not negotiated 35 S.G. Kang

36 Preconditions with Offer/Answer Model Refusing an Offer Define a new SIP status code Server-Error = 580 ; Precondition Failure Unknown Precondition Type Unknown tag Option Tag for Preconditions UA must support the PRACK method, and consequently, must include the 100rel tag in the Supported Header field Indicating Capabilities UA should add a precondition tag to the Supported Header field of its responses to OPTIONS requests 36 S.G. Kang

37 Call Flow Examples End-to-end Status Type 37 S.G. Kang

38 Call Flow Examples Session Modification with Preconditions 38 S.G. Kang

39 Call Flow Examples Segmented Status Type 39 S.G. Kang

40 Call Flow Examples Initial Offer in a 1xx response 40 S.G. Kang

41 Recent Activity in IETF NSIS (Next Step In Signaling) Scope of NSIS WG will develop Requirements, Architecture, Protocols for the next IETF steps on Signaling QoS will consider how to signal QoS(QoS parameters to use), and where to signal(end-to-end, end-to-edge, end-to-proxy, edge-to-edge, etc.) Main Ideas Decouple QoS signaling from resource reservation Resource reservation is increasingly seen as a network management issue Users should not to be forced to understand how different domains allocate resources 41 S.G. Kang

42 Summary End-to-end QoS is required by the ITSP and Users Various Standardization Activities and Various Approaches TIPHON uses a layered architecture which separates Application and Transport Planes SIP-based end-to-end VoIP QoS in IETF NSIS for end-to-end QoS Signaling in IETF 42 S.G. Kang

43 Any Questions? 43 S.G. Kang