06/28/06 1 TSG-C SWG 1.2 End-to-End Signalling of Over-the-Air QoS & Additional PSVT call flows June 28, 2006 Nikolai Leung, Hyukjune Chung QUALCOMM, Incorporated Notice QUALCOMM Incorporated grants a free, irrevocable license to 3GPP2 and its Organizational Partners to incorporate text or other copyrightable material contained in the contribution and any modifications thereof in the creation of 3GPP2 publications; to copyright and sell in Organizational Partner’s name any Organizational Partner’s standards publication even though it may include all or portions of this contribution; and at the Organizational Partner’s sole discretion to permit others to reproduce in whole or in part such contribution or the resulting Organizational Partner’s standards publication. QUALCOMM Incorporated is also willing to grant licenses under such contributor copyrights to third parties on reasonable, non-discriminatory terms and conditions for purpose of practicing an Organizational Partner’s standard which incorporates this contribution. This document has been prepared by QUALCOMM Incorporated to assist the development of specifications by 3GPP2. It is proposed to the Committee as a basis for discussion and is not to be construed as a binding proposal on QUALCOMM Incorporated. QUALCOMM Incorporated specifically reserves the right to amend or modify the material contained herein and nothing herein shall be construed as conferring or offering licenses or rights with respect to any intellectual property of QUALCOMM Incorporated other than provided in the copyright statement above.

06/28/06 2 TSG-C SWG 1.2 End-to-End Signalling of Over-the-Air QoS

06/28/06 3 TSG-C SWG 1.2 Negotiating End-to-End QoS  Problem: how does a terminal receiving a SIP INVITE (SDP offer) determine what level of QoS to activate with its RAN? –Activating an insufficient QoS reservation will result in poor user experience/service –Activating too stringent QoS reservation can waste network resources Admission policies can prevent full utilization of sector capacity  Rely on existing SDP parameters to determine, –Application type –QoS requirements of the application  Introduce/define additional SDP parameters to identify, –Application type –QoS requirements of the application

06/28/06 4 TSG-C SWG 1.2 Concerns with using current SDP parameters for QoS  b= AS parameter is the maximum received bandwidth –Does not specify average bandwidth Problem for EVRC-B codec which has different Capacity Operating Points (COPs) for different average rates but all with the same maximum rate –The admission control policy at the ‘receiver RAN’ will not be able to fully exploit the VoIP capacity gains of the EVRC-B COPs Can not specify maximum sender (transmission) bandwidth RFC 2327 (SDP) and RFC 3264 (Offer-Answer)  No SDP parameters for indicating tolerable packet error rate (PER) over the air interface –Services can be operated at higher PERs for codecs/transport layers with new error-resiliency features (e.g., packet loss feedback for video)  No SDP parameters for indicating tolerable latency over the air interface or End-to-end

06/28/06 5 TSG-C SWG 1.2 Concerns with using current SDP parameters for QoS 2  SIP feature tags will help identify the application –But this will not identify the actual/finer QoS requirements Requires inferring of QoS over the air (BW, latency, PER) Not all QoS parameter can be inferred with the current SDP parameters –SIP feature tags will not be standardized in 3GPP2 in time for PSVT specification  Need to define new QoS parameters for SDP –To enable interoperability these will need to be defined in IETF or in 3GPP/3GPP2 –Need much more time to get these standardized –Need time to determine what parameters to define  TSG-C SWG1.2 is planning to baseline the PSVT C.P document by September, 2006 and publish by the end of 2006

06/28/06 6 TSG-C SWG 1.2 FlowProfileIDs in SDP for near-term 3GPP2 solution  Until SIP feature tags for applications and additional SDP parameters are specified –Terminal has to infer both the application type and infer the QoS requirements –Not all applications or their QoS requirements can be inferred E.g., PTT, gaming  FlowProfileID provides hint to other 3GPP2 terminal for near term E2E QoS solution –Other terminal can use this to decide the appropriate QoS to reserve with its RAN  When more generic parameters are defined, they can be used for interoperability with 3GPP

06/28/06 7 TSG-C SWG 1.2 Syntax for FlowProfileID attribute in SDP  a=flowpfid”:  enterprise number = 5535 –Last part of SMI Network Management Private Enterprise Code value assigned by IANA in numbers. For 3GPP2 = http:// numbers. For 3GPP2  value= syntax to be defined by the enterprise.  Following is the 3GPP2 defined syntax for attribute. –. –payloadtype-list = comma separated list of payload type numbers from “m=” media line. –flowpfid = 16 bit decimal/hex value 3gpp2 flow profile id. –direction = {“send”|”recv”|”sendrecv”}  Included in a media (m=) line

06/28/06 8 TSG-C SWG 1.2 Semantics for FlowProfileID attribute in SDP  Sent in SDP as hint of what QoS to reserve with the RAN –Optionally included in SDP offer and SDP answer  Indicates the preferred FlowProfileID per payload type  Updates to QoS –If RAN QoS commitment changes (new FlowProfileID) the terminal should send an update in SDP

06/28/06 9 TSG-C SWG 1.2 Example  SDP Offer –m=audio RTP/AVP –a=rtpmap:96 EVRCB0/8000 –a=rtpmap:97 EVRC0/8000 –a=rtpmap:98 telephone-event/8000 –a= flowpfid: ,98 0x0110 –a= flowpfid: ,98 0x0287  0x0287 would be a new FlowProfileID for an EVRC-B operating points  SDP Answer –m=audio RTP/AVP –a=rtpmap:98 EVRCB0/8000 –a=rtpmap:98 telephone-event/8000 –a= flowpfid: ,98 0x0287

06/28/06 10 TSG-C SWG 1.2 Additional PSVT call flows

06/28/06 11 TSG-C SWG 1.2 Packet Switched Video Telephony Call Flows  X.R –Includes very high-level call flow for call set-up and establishment  X.P B –Includes optimized call flow examples for generic services Applies directly through VoIP but not PSVT  Future plans for defining call flows for generic supplementary services in MMD group –Call forwarding, 3-way calling, caller ID –Apply to VoIP, PSVT, and other services  Additional call flows specifically needed for PSVT –Supplementary services described in Stage 1 and Stage 2 document but do not have call flows PSVT Voice Retry Video on Hold –Call set-up and tear down specifically for PSVT