METHOD, APPARATUS AND COMPUTER PROGRAM PRODUCT PROVIDING INTEROPERABLE QoS PARAMETERS AND SIGNALING THEREOF IN A 3GPP2-3GPP AND 3GPP2-3GPP2 CONVERSATIONAL

MULTIMEDIA EXCHANGE

TECHNICAL FIELD:

[0001] The exemplary and non-limiting embodiments of this invention relate generally to wireless communications systems, devices and methods and, more specifically, relate to systems, devices and methods for performing multimedia wireless communications.

BACKGROUND:

[0002] Various abbreviations that may appear herein are defined as follows:

[0003] 3GPP: 3rd Generation Partnership Project

[0004] 3GPP2: 3rd Generation Partnership Project 2

[0005] E2E: End-to-End

[0006] FL: Forward Link

[0007] GSM: Global System for Mobile Communication

[0008] IP: Internet Protocol

[0009] QOS: Quality of Service

[0010] MMD: All-IP MultiMedia Domain

[0011] MS: Mobile Station

[0012] MT: Mobile Terminal

[0013] PSVT: Packet Switched Video Telephony

[0014] RAN: Radio Access Network

[0015] RL: Reverse Link

[0016] RTCP: Real Time Control Protocol

[0017] SIP: Session Initiation Protocol

[0018] SDP: Session Description Protocol

[0019] SWIS: See What I See

[0020] UE: User Equipment

[0021] UMTS: Universal Mobile Telecommunications System

[0022] VoIP: Voice over IP

[0023] 3GPP2 has adopted the method of flow_profile_ID for establishing QoS in the RAN for IP multimedia communications including: VoIP, PSVT and Mobile-to-Mobile Multimedia Streaming. A flowjprofile_ID (or "QoS setting") may be assigned to individual flows or to an ensemble of flows, as well as asymmetrically for FL and RL traffic. Although the user device, referred to variously as a MS, MT or UE, depending on the context, is aware of its local flow_profile_ID(s), it cannot be aware of the flow_profile_ID(s) of the other party and thus cannot be aware of the E2E QoS.

[0024] Similarly 3GPP has defined in its technical specification (see 3GPP

Technical Specification TS 23.107 QoS Concept and Architecture) the overall concept and architecture for QoS in 3 G mobile communications. In this technical specification four traffic classes have been defined (conversational, streaming, interactive and background), along with associated parameters such as delay, error rate, guaranteed bit rate and maximum bit rate. Reference with regard to 3GPP signaling may be made to 3GPP Contribution TD S4-050341 "End-to-end signaling of QoS parameters for IMS multimedia sessions in CS-IMS combinational services (CSICS)", May 9-13, 2005, Nokia.

SUMMARY:

[0025] In an exemplary aspect of the invention, a method is provided to enable an initiator of a multimedia call to signal at least one QoS parameter to a called party. The method includes: obtaining at least one flow_profile_ID; performing calculations to convert the at least one flow_profile_ID to at least one QoS parameter of the called party; and sending the at least one QoS parameter to the called party.

[0026] In another exemplary aspect of the invention, an electronic device is provided to enable an initiator of a multimedia call to signal at least one QoS parameter to a called party. The electronic device includes: at least one memory; and a transceiver

coupled to at least one data processor, wherein the at least one data processor is coupled to the at least one memory, wherein the at least one data processor is configured to execute a program of machine-readable instructions. The program is capable of performing the operations of: obtaining at least one flow_profile_ID; performing calculations to convert the at least one flow__profϊle_ID to at least one QoS parameter of the called party; and sending the at least one QoS parameter to the called party.

[0027] In a further exemplary aspect of the invention, a computer program product is provided to enable an initiator of a multimedia call to signal at least one QoS parameter to a called party. The computer program product includes program instructions embodied on a tangible computer-readable medium. Execution of the program instructions results in operations including: obtaining at least one flow_profile_ID; performing calculations to convert the at least one flow_profile_ID to at least one QoS parameter of the called party; and sending the at least one QoS parameter to the called party.

[0028] In another exemplary aspect of the invention, a method is provided. The method includes: a sender party of a multimedia session informing a called party of its negotiated QoS parameters for the multimedia session; called party negotiating similar QoS attributes with its network; and the called party exchanging the similar QoS attributes with the sender during a session set up phase.

[0029] In a further exemplary aspect of the invention, an electronic device is provided. The electronic device includes: at least one memoiy; and a transceiver coupled to at least one data processor, wherein the at least one data processor is coupled to the at least one memory, wherein the at least one data processor is configured to execute a program of machine-readable instructions. The program is capable of performing the operations of: a sender party of a multimedia session informing a called party of its negotiated QoS parameters for the multimedia session; called party negotiating similar QoS attributes with its network; and the called party exchanging the similar QoS attributes with the sender during a session set up phase.

[0030] m another exemplary aspect of the invention, a computer program product

is provided. The computer program product includes program instructions embodied on a tangible computer-readable medium. Execution of the program instructions results in operations including: a sender party of a multimedia session informing a called party of its negotiated QoS parameters for the multimedia session; called party negotiating similar QoS attributes with its network; and the called party exchanging the similar QoS attributes with the sender during a session set up phase.

[0031] In a further exemplary aspect of the invention, a method is provided to enable an initiator of a multimedia call to signal at least one QoS parameter to a called party. The method includes: means for obtaining at least one flow_profile_ID; means for performing calculations to convert the at least one flowjprofile_ID to at least one QoS parameter of the called party; and means for sending the at least one QoS parameter to the called party.

[0032] In another exemplary aspect of the invention, a method is provided. The method includes: means for a sender party of a multimedia session informing a called party of its negotiated QoS parameters for the multimedia session; means for the called party negotiating similar QoS attributes with its network; and means for the called party exchanging the similar QoS attributes with the sender during a session set up phase.

BRIEF DESCRIPTION OF THE DRAWINGS:

[0033] The foregoing and other aspects of embodiments of this invention are made more evident in the following Detailed Description, when read in conjunction with the attached Drawing Figures, wherein:

[0034] Fig. 1 shows E2E signaling of equivalent 3GPP2 flow_Profile_ID to a

3GPP party during IP call setup in accordance with a first aspect of this invention (3GPP2-3GPP);

[0035] Fig.2 shows E2E signaling of a 3GPP2 flow_Profile_ID at IP call setup in accordance with a further aspect of this invention (3GPP2-3GPP2);

[0036] Fig. 3 shows a mobile terminal in the context of a wireless communications system, and illustrates one suitable technical environment for implementing various non-limiting embodiments of the invention;

[0037] Fig. 4 is a logic flow diagram that illustrates a method for practicing the exemplary embodiments of the invention; and

[0038] Fig. 5 depicts a logic flow diagram of another method for practicing the exemplary embodiments of the invention.

DETAILED DESCRIPTION:

[0039] One example of this invention relates to a technique for use in heterogeneous calls (3GPP2 to 3 GPP) wherein conversion between the QoS types, and signaling of the QoS parameters, is employed.

[0040] Disclosed in accordance with non-limiting aspects of this invention is a technique for signaling 3GPP2 QoS support using standardized call set-up and negotiation/re-negotiation procedures for use in, for example, SIP (IETF RFC 3261 "SIP: Session Initiation Protocol"), SDP (IETF RFC 2327 "SDP: Session Description Protocol") and MMD (3GPP2 Technical Specification X.S0013 "All-IP Core Network Multimedia Domain").

[0041] As will be described in detail below, various exemplary embodiments of this invention relate generally to the field of IP multimedia communication between a party in a 3GPP2 network (cdma2000) and a party in a 3GPP network (GSM ₅ UMTS). Various exemplary embodiments of this invention relate more specifically to methods, apparatus and computer programs to enhance and optimize QoS in an IP multimedia communication by interpreting the QoS parameters from the 3GPP2 network flow_profile_ID (see 3GPP2 Technical Report CPlOOl-E "Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards Release E") or qos_profϊle_ID (see 3GPP2 Technical SpecificationX.SOOl 1-004-D "cdma2000 Wireless IP Network Standard: Quality of Service and Header Reduction") into QoS parameters

(e.g., guaranteed bit rate, maximum bit rate and granted delay) that are understood by a 3GPP terminal and network, and further relate to signaling E2E QoS parameters flow__profile_ID or qos_profϊle_ID negotiated by an initiating terminal (sender party) through the wireless network to the other terminal (called party) in the session. The protocol used for exchanging QoS parameters in certain exemplary embodiments of the invention is SDP, although any other suitable protocol for session set-up may be employed.

[0042] Certain exemplary embodiments of this invention permit a receiving 3GPP party (referred to for convenience as a PP called party) in a multimedia call to set-up wireless network resources in an optimal and efficient way according to 3GPP-defined signaling, where the resources comprise those that align to similar QoS settings as defined by 3GPP2 flow_profile_ID(s), and further permit multimedia applications for both the called and calling parties to have a better understanding of the possible operating QoS ranges of the overall (E2E) call.

[0043] Certain exemplary embodiments of this invention permit an initiator of the

3 G multimedia call in a 3GPP2 network (referred to for convenience as a PP2 sender party) to signal its negotiated QoS parameters flow_profile_ID(s) to the PP called party of the session during the session set-up procedure by mapping flow_profile_ID to 3GPP guaranteed bit rate, maximum bit rate and granted delay. The session set-up may be uni-directional (streaming) or bi-directional (e.g. , similar to video conferencing). If the session is bi-directional, the PP called party signals its QoS parameters to the PP2 sender party.

[0044] It is understood that SDP and SIP are exemplary protocols, and that the various aspects of this invention may be practiced using protocols other than SDP and SIP. In general, the information between the parties can be transferred using any protocol message at any layer of the ISO OSI stack.

[0045] In accordance with non-limiting embodiments, the 3 GPP2 party interprets its negotiated flow_profϊle_ID(s) to the 3GPP QoS parameters 3gpp-guaranteedbitrate, 3gpp-maxbitrate, 3gpp-granteddelay. Reference is also made to the exemplary call

control flow diagram shown in Fig. 1, where elements of most interest to this invention are illustrated to be a 3GPP2 terminal 10 (Terminal A) ₅ a 3GPP2 network 14 (Network A), a 3GPP network 14 (Network B) and a 3GPP terminal 16 (Terminal B). These elements are each shown to include at least one data processor (DP) 1OA, 12 A, 14A and 16A and at least one associated memory device or unit (MEM) 1OB, 12B, 14B and 16B. Each memory is assumed to store computer program instructions the execution of which by the associated data processor directs operations of the associated network element, including operations in accordance with the non-limiting embodiments of this invention.

[0046] The memories 1 OB, 12B, 14B and 16B may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as semiconductor-based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors 1 OA, 12 A, 14 A and 16 A may be of any type suitable to the local technical environment, and may include one or more of general purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs) and processors based on a multi-core processor architecture, as non-limiting examples.

[0047] In general, the various embodiments of the terminals 10 and 16 can include, but are not limited to, cellular telephones, personal digital assistants (PDAs) having wireless communication capabilities, portable computers having wireless communication capabilities, image capture devices such as digital cameras having wireless communication capabilities, gaming devices having wireless communication capabilities, music storage and playback appliances having wireless communication capabilities, Internet appliances permitting wireless Internet access and browsing, as well as portable units or terminals that incorporate combinations of such functions.

[0048] The process begins in this exemplary embodiment with terminal 10 sending a SIP invite to terminal 16 (Step A) to which a response (200 OK) is received (Step B). Terminal 10 then sends a QoS Support request to 3GPP2 network 14 for 48 Kbps media type video and 8 Kbps speech (Step C), and terminal 16 sends a QoS Request to 3GPP network 14 via initial SIP Invite parameters (Step D).

[0049] The terminal 10 is assumed to receive from 3GPP2 network 14 a

Flow_Profile_ID Grant, (Step E) i.e., it receives a list of negotiated flow_profile_ID(s) for the call. At Step F the 3GPP2 terminal 10 performs a Flow_Profile_ID conversion. In an exemplary embodiment this occurs by calculating the 3GPP guaranteed_bitrate as the sum of the minimum granted bitrates per media type (e.g., audio, video, text), or the minimum bitrate of generic data type (see the examples given below); calculating the 3GPP maximum_bitrate as the sum of the maximum granted bitrates per media type, or the maximum bitrate of a generic data type (see the examples below); and calculating the 3GPP granted_delay as the maximum of the granted delay independent of media type (see the examples below).

[0050] At Step G the 3GPP2 terminal 10 sends to the 3GPP terminal 16 as, for example, SDP signals:

[0051] a=3gpp-guaranteedbitrate:<guaranteed_bitrate>

[0052] a=3gpp-maxbitrate:<maximum_bitrate>

[0053] a=3gpp-granteddelay:<granted_delay>,

[0054] where it should be noted that these values are not defined for the case where media data and generic data flow_piOfile_ID(s) are mixed.

[0055] Terminal 16 may then optionally renegotiate with network 14 for QoS support (Step H).

[0056] Several non-limiting examples are now given to provide a fuller understanding of the operation of these aspects of the invention.

[0057] Example 1 - Media data related fiowjprofileJD(s) (Table 1 from 3GPP2

Technical Report CRlOOl-E "Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards Release E", referred to below for simplicity as CRlOOl).

[0058] The 3 GPP2 terminal 10 (Terminal A) desiring to establish a PSVT call is granted the following flow_profile__ID(s) in the 3GPP2 network 12:

[0059] 0x0100 - conversational Rate Set 1 Interactive Speech with no frame bundling;

[0060] 0x0301 - conversational Interactive Video _. 32K;

[0061] 0x0302 - conversational Interactive Video 4OK;

[0062] 0x0303 - conversational Interactive Video 48K; and

[0063] 0x0500 - conversational Media Control Signaling.

[0064] Example 1, part a:

[0065] According to CRlOOl, associated with 0x0100 is an 8Kbps guaranteed bitrate for speech, and associated with 0x0301, 0x0302, 0x0303 are 32 Kbps, 40 Kbps and 48 Kbps guaranteed bitrates for video.

[0066] The DP 1OA of terminal 10 calculates the guaranteed_bitrate as:

[0067] min {0x0100_audio_bitrate} + min {0x0301_video_bitrate,

0x0302_video_bitrate, 0x0303_video_bitrate} or guaranteed_bitrate = min {8K} +min {32K, 40K, 48K} = 4OK.

[0068] Example 1 , part b:

[0069] According to CRlOOl, associated with 0x0100 is an 8Kbps guaranteed bitrate for speech and associated with 0x0301, 0x0302, 0x0303 are 32 Kbps, 40 Kbps and 48 Kbps guaranteed bitrates for video.

[0070] The DP 1OA of terminal 10 calculates the maximum_bitrate as:

[0071] max {0x0100_audio_bitrate} + max {0x0301_video_bitrate,

0x0302_video_bitrate, 0x0303_video_bitrate} or maximum_bitrate = max {8K} +max {32K, 4OK, 48K} = 56K.

[0072] Example 1 , part c:

[0073] According to CRlOOl, associated with 0x0100 is a maximum delay of

100 milliseconds, and associated with 0x0301, 0x0302, 0x0303 is a maximum delay of 200 milliseconds, where it should be noted that these parameters are currently not finalized in CRl 001 and may not exist for all flow_profile_ID(s). In this case the 3GPP2 terminal 10 may choose to use the "0" or "*" for the granted_delay, as defined in the above-referenced copending United States Provisional Patent Application No.: 60/677,283 filed May 3, 2005, "Signaling Quality of Service (QoS) Parameters for a Multimedia Session", by Igor Curcio and Umesh Chandra, which is incorporated by reference herein in its entirety.

[0074] As stated in the above-referenced copending Curcio et al., by way of example, the 3gpp-granteddelay SDP attribute can also be assigned values of* and 0. A value of * specifies that the delay value is unknown and is unbounded meaning there is no guarantee on the delay values and the packets can experience different amounts of transfer delays. For interactive and background traffic classes, the network does not assign any PDP context transfer delay value which implies its unbounded or best effort depending on the network resources and load, hi that case, the SDP attribute can be assigned a value of * or 0.

[0075] The DP 1OA of terminal 10 calculates the granted_delay as:

[0076] max {0x0100_delay, 0x0301_delay, 0x0302_delay, 0x0303_delay} or granted_delay = max {100, 200, 200, 200} = 200 ms.

[0077] The following SDP messages are signaled to the receiving (called party,

the terminal 16 in this case):

[0078] a=3gpp-guaranteedbitrate: 40;

[0079] a=3gpρ-maxbitrate: 56; and

[0080] a=3gpρ-granteddelay: 200.

[0081] Example 2 - Generic data related flow_profϊle_ID(s) (Table 2 from

CRlOOl).

[0082] The 3GPP2 terminal 10 (Terminal A) desiring to establish a PSVT call is granted the following flowjprofile_ID(s) in the 3GPP2 network 12:

[0083] 0x0005 - generic data, minimum data rate 32K with 100 ms maximum delay;

[0084] 0x0006 - generic data, minimum data rate 64K with 100 ms maximum delay; and

[0085] 0x0017 - generic data, minimum data rate 96K with 500 ms maximum delay.

[0086] Example 2, part a:

[0087] The DP 1OA of terminal 10 calculates the guaranteed_bitrate as:

[0088] min {0x0005_bitrate, 0x0006_bitrate, 0x0017_bitrate} or guaranteed_bitrate = min {32K, 64K, 96K} = 32K.

[0089] Example 2, part b:

[0090] The DP 1OA of terminal 10 calculates the maximum_bitrate as:

[0091] max {OxOOO5_bitrate, OxOOO6_bitrate, 0x0017_bitrate} or maximum_bitrate = max {32K, 64K, 96K} = 96K.

[0092] Example 2, part c:

[0093] The DP 1OA of terminal 10 calculates the granted_delay as:

[0094] max {0x0005_delay, 0x0006_delay, 0x0017_delay} or granted_delay = max {100, 100, 500} = 500 ms.

[0095] The following SDP messages are signaled to the receiving (called party, the terminal 16 in this case):

[0096] a=3gpp-guaranteedbitrate: 32;

[0097] a=3gρp-maxbitrate: 96; and

[0098] a=3gpρ-granteddelay: 500.

[0099] Additionally, a 3GPP2 party (terminal 10) may, upon receiving the guaranteed bitrate, maximum bitrate and granted delay information, request 3GPP2 levels of QoS support based on possible flowjprofile_ID bitrates and delays. The terminal 10 may further divide the request according to audio and video by examining the media attribute (m=) of the 3GPP SIP/SDP INVITE.

[00100] Example 3, 3GPP received parameters

[00101] The 3GPP2 terminal 10 receives QoS parameters from a calling 3GPP party (terminal 16) with messages:

[00102] a=3gρp-guaranteedbitrate: 32;

[00103] a=3gpp-maxbitrate: 96; and

[00104] a=3gpp-granteddelay: 500.

[00105] In response, the 3 GPP2 terminal 10 requests of the 3 GPP2 network 12 the generic data flowjprofile_ID(s):

[00106] 0x0005 - generic data, minimum data rate 32K with 100 ms maximum delay;

[00107] 0x0006 - generic data, minimum data rate 64K with 100 ms maximum delay; and

[00108] 0x0007 - generic data, minimum data rate 96K with 100 ms maximum delay.

[00109] This may be done so that the 3GPP2 terminal 10 can match the range of expected bitrates from the 3GPP party (terminal 16). In this scenario the 3GPP2 terminal 10 has requested the minimum delay because an E2E QoS of less than 750 ms is desired, and at least 500 ms of this timeline may be expected to be consumed by the 3GPP network 14.

[00110] A number of advantages can be realized by the use of various ones of the non-limiting embodiments described above. For example, a mobile party in the 3GPP network 14 (GSM, UMTS) may request network resources using 3GPP -native QoS parameters that will closely match the QoS requirements from the calling 3GPP2 party, thus enabling more efficient network resource allocation. Further, the mobile party in the 3GPP2 network 12 (cdma2000) may request network resources using 3GPP2-native QoS parameters that will closely match the QoS requirements from a calling 3GPP party, thus also enabling more efficient network resource allocation. Further, the mobile parties in both the 3GPP2 and 3GPP networks 12 and 14, upon exchange of the QoS information, may more accurately (e.g., at the application level) calculate the total E2E QoS (delay, guaranteed bitrate, and bitrate variation) parameters, since the primary network

bottlenecks (the RANs) are bounded. Further, the mobile parties in both the 3GPP2 and 3GPP networks 12 and 14, upon exchange of the QoS information, may allocate application level resources (such as jitter buffer resources) more efficiently. Further still, the mobile parties in both the 3GPP2 and 3GPP networks 12 and 14, upon exchange of the QoS information, may adapt to network variations (e.g., bitrate) more appropriately.

[00111] Having thus described several exemplary embodiments of this invention, additional exemplary embodiments will now also be described. These additional exemplary embodiments enable the called party in a 3GPP2 multimedia call to inform the sender party of its negotiated QoS regardless of the nature of the local network, and further enable the use of standardized 3GPP2 QoS mechanisms. These additional exemplary embodiments further enable a party to update other parties during the call of any changes in their component of the QoS.

[00112] This aspect of the invention defines new SDP attributes for the above-mentioned flow_profile_ID(s), and the new SDP attributes are carried in SIP messages. The called party may use these SDP attributes to negotiate (or re-negotiate) QoS parameters with its own wireless network. The associated multimedia applications may use these parameters to set application resources, such as jitter buffers, for audio and video media and feedback (RTCP) accordingly.

[00113] It is once more noted that SDP and SIP are examples of suitable protocols, and that the practice of the embodiments of the invention is not limited for use with only these protocols.

[00114] In accordance with the exemplary embodiments of this invention the sender party of a multimedia session informs the called party of its negotiated QoS parameters for the multimedia session. The called party then negotiates similar QoS attributes with its network and exchanges this value with the sender during the session set up phase. The session set up protocol may be the widely used SEP/SDP signaling protocol for IP session set up, or it may be any other session set up protocol.

[00115] An implementation example is given using the SIP/SDP protocols. The

SIP INVITE message, which is used to set up a session between two clients, uses SDP to describe the session and media information (the SDP information may be sent in the body of other SIP messages such as 200 OK, ACK or UPDATE). SDP describes the transport information (port and IP address) and media information (such as the codec and the associated parameters). Three new user-defined SDP attributes are defined for indicating the QoS parameters in accordance with is aspect of the invention.

[00116] First, an attribute, which may be called "3gpp2~flowprofileid", is defined in SDP to indicate the flow_profile_ID(s) granted to a terminal by its wireless network in a symmetrical fashion (i.e., same for the FL and the RL). The "3gpp2-flowprofileid" is declared in SDP as:

[00117] a=3gpp2-flowprofileid:<list-of- 16-bit-HEX-values-of-granted-flow_profil e_IDs>.

[00118] Second, an attribute, which may be called "3gpp2-flowprofileid-rl", is defined in SDP to indicate the flow_profile_ID(s) granted to a terminal by its wireless network in an asymmetrical fashion for the RL. The "3gpp2-flowprofileid-rl" is declared in SDP as:

[00119] a=3gpp2-flowpiOfileid-rl:<list-of-16-bit-HEX-values-of-gr anted-RL-flow

_profile_IDs>

[00120] Or alternatively, the "3gpp2-flowprofileid" is declared in SDP as:

[00121] a=3gpp2-flowprofileid:<ascii-char-R, list-of- 16-bit-HEX-values-of-granted-RL-flo w_profile_IDs>

[00122] Third, an attribute, which may be called" 3 gpp2-flowprofileid-fr, is defined in SDP that indicates the flow_profile_ID(s) granted to a terminal by its wireless network in an asymmetrical fashion for the FL. The ^M 3gpp2-flowprofileid-fl" is declared in SDP as:

[00123] a=3gpρ2-flowρrofileid-fl:<list-of-16-bit-HEX-values-of- granted-FL-flow_ profile_IDs>.

[00124] Or alternatively, the "3gρp2-flowρrofileid" is declared in SDP as:

[00125] ^■ a=3gpp2-flowprofileid:<ascii-char-F ₅ list-of- 16-bit-HEX-values-of-granted-FL-flow_profile_IDs>

[00126] Two non-limiting example sessions are described below, one with symmetrical-only flow_profile_ID(s) and one with both asymmetrical and symmetrical flow_profile_ID(s). Reference in this regard is made to Fig. 2, which is similar in some respects to Fig. 1. Note, however, that in Fig. 2 both network A and B, and terminals A and B, are shown as being of the same type, e.g., 3GPP2.

[00127] Example 1 : Symmetrical-only flowjprofile_ID(s)

[00128] Assume that Terminal A (sender party, 3 GPP2 terminal 10) desires to set up a PSVT call with 48 Kbps video and 8 Kbps speech media and requests QoS support for this call from network 12. Assume further that network 12 grants Terminal A the following flow_profile_ID(s) in a symmetric fashion:

[00129] 0x0100 - conversational Rate Set 1 Interactive Speech with no frame bundling;

[00130] 0x0301 - conversational Interactive Video 32k;

[00131] 0x0302 - conversational Interactive Video 40k;

[00132] 0x0303 - conversational Interactive Video 48k; and

[00133] 0x0500 - conversational Media Control Signaling.

[00134] Terminal A includes the following attributes in the initial SIP INVITE

message or subsequent SIP UPDATE message (depending on the order of network resource allocation):

[00135] a=3gpp2-flowprofileid: OxOlOO 0x0301 0x0302 0x0303 0x0500,

[00136] as shown in Step G ₁ in the SIP UPDATE message sent to 3GPP2 terminal

16.

[00137] Additionally, Terminal B (called party, Terminal 16) may request similar

QoS support from network 14 using received QoS flow_profile_ID(s) at setup as shown in Step D, or may re-negotiate existing QoS support as shown in Step H.

[00138] Example 2: Symmetrical and Asymmetrical flow_profile_ID(s)

[00139] Assume that Terminal A (sender party, 3 GPP2 terminal 10) desires to set up a "SWIS like" call (regular VoIP with one way video streaming at 48 Kbps) and requests QoS support for this call from network 12. Network 12 grants the 3GPP2 terminal 10 the following flow_profile_ID(s) in a symmetric fashion:

[00140] 0x0100 - conversational Rate Set 1 Interactive Speech with no frame bundling;

[00141] 0x0500 - conversational Media Control Signaling;

[00142] and the following flow_profile_ID(s) in an asymmetric (RL) fashion:

[00143] 0x0301 - conversational Interactive Video 32k;

[00144] 0x0302 - conversational Interactive Video 40k; and

[00145] 0x0303 - conversational Interactive Video 48k.

[00146] 3GPP2 terminal 10 includes the following attributes in the initial SIP

INVITE message or subsequent SIP UPDATE message (depending on the order of network resource allocation):

[00147] a=3gpp2-flowprofileid: 0x0100 0x0500; and

[00148] a=3gρρ2-flowprofileid-rl: 0x0301 0x0302 0x0303 or

[00149] a=3gρp2-flowρrofileid: R 0x0301 0x0302 0x0303

[00150] Additionally, Terminal B (called party, Terminal 16) may request similar

QoS support from network 14 using received QoS flow_profile_Id(s) at setup as shown in Step D ₅ or may re-negotiate existing QoS support as shown in Step H. With the modification that received flowjprofile_ID(s) received as asymmetrical or requested in the opposite direction, i.e. RL QoS from Terminal A are requested on the FL from Network B and FL QoS from Terminal A are requested on the RL from Network B.

[00151] A number of additional advantages can be realized by the use of the further non-limiting embodiments described above. For example, the mobile parties upon exchange of flbwjprofile_ID information may request network resources from a 3GPP2 network (cdma2000) that are closely matched, and that do not exceed actual resources needed to support E2E calls, or similarly the flow_profile_ID(s) may be converted to 3GPP QoS parameters as previously defined and resources requested with equivalent efficiency from a 3GPP network.

[00152] Reference is now made to Fig. 3, in which there is shown as a simplified block diagram an embodiment of a wireless communications system 1 that is suitable for practicing this invention. The wireless communications system 1 includes at least one mobile terminal (MT) 10, it being realized that the terminal 16 in Figs. 1 and 2 may be similarly constructed. Fig. 3 also shows an exemplary network operator 20 having, for example, a node 30 for connecting to a telecommunications network, such as a Public Packet Data Network or PDN, at least one base station controller (BSC) 40 or equivalent apparatus, and a plurality of base transceiver stations (BTS) 50, also referred to as base stations (BSs), that transmit in a forward or downlink direction both physical and logical

channels to the mobile station 10 in accordance with a predetermined air interface standard. A reverse or uplink communication path also exists from the MT 10 to the network operator, which conveys mobile originated access requests and traffic. A cell 3 is associated with each BTS 50, where one cell will at any given time be considered to be a serving cell, while an adjacent cell(s) will be considered to be a neighbor cell. Smaller cells (e.g., picocells) may also be available.

[00153] The air interface standard can conform to any suitable standard or protocol, and may enable both voice and data traffic, such as data traffic enabling Internet 70 access and web page downloads. In the exemplary embodiments of this invention the air interface standard can be compatible with a code division multiple access (CDMA) air interface standard, such as cdma2000 (3GPP2), or it may be compatible with a time division multiple access (TDMA) air interface standard, such as GSM (3 GPP), although these particular air interface standards are not a limitation upon the practice of the exemplary embodiments of this invention.

[00154] The MT 10 typically includes a control unit or control logic, such as a microcontrol unit (MCU) 120 having an output coupled to an input of a display 140 and an input coupled to an output of a user input 160. The MCU 120 is assumed to include or be coupled to some type of a memory 130, including a non- volatile memory for storing an operating program and other information, as well as a volatile memory for temporarily storing required data, scratchpad memory, received packet data, packet data to be transmitted, and the like. At least some of this temporary data can be stored in a data buffer 130A. The operating program is assumed, for the puiposes of this invention, to enable the MCU 120 to execute the software routines, layers and protocols required to implement the methods in accordance with the invention, and may as well provide a suitable user interface (UI), via display 140 and keypad 160, with a user. Although not shown, a microphone and speaker are typically provided for enabling the user to conduct voice calls in a conventional manner.

[00155] The MT 10 also contains a wireless section that includes a digital signal processor (DSP) 180, or equivalent high speed processor or logic, as well as a wireless transceiver that includes a transmitter 200 and a receiver 220, both of which are coupled

to an antenna 240 for communication with the network operator. At least one local oscillator, such as a frequency synthesizer (SYNTH) 260, is provided for tuning the transceiver. Data, such as digitized voice and packet data, is transmitted and received through the antenna 240.

[00156] The MT 10 may be employed to implement the terminals 10 and 16 shown in Figs. 1 and 2, where at least one of the MCU 120 and DSP 180 functions as the DP 1OA, 16A, and where the memory 130 functions as the memory 1OB, 16B. The user input 160 may include one or more of the following: keypad, keyboard, pointing device, touch-sensitive display screen or voice-sensitive input, as non-limiting examples.

[00157] In exemplary embodiments of the invention substantially all SIP/SDP signaling and associated calculations may be performed at the application layer. It is assumed that there exist some application program interface(s) to the lower layers at which the QoS flowjprofile_IDs can be requested or obtained. The flow_piOfile_IDs are negotiated with the network using the QoS_Blob and related procedure described in detail in X.S0011 -004-D. This is done on a per-flow basis and enforced by the network. On the 3GPP side (Fig. 1) the QoS parameters may be obtained as part of the packet data protocol (PDP) context activation. ■ t

[00158] Referring to Fig. 4, a method 400 is shown for practicing the exemplary embodiments of the invention. The method is to enable an initiator of a multimedia call to signal at least one QoS parameter to a called party and includes the following steps. In box 401 , at least one flow_profile_ID is obtained. In box 402, calculations are performed to convert the at least one flow_piOfile_ID to at least one QoS parameter of the called party. In box 403, the at least one QoS parameter is sent to the called party.

[00159] Referring to Fig. 5, a further method 500 is shown for practicing the exemplary embodiments of the invention. The method includes the following steps. In box 501 , a sender party of a multimedia session informs a called party of its negotiated QoS parameters for the multimedia session. In box 502, the called party negotiates similar QoS attributes with its network. In box 503, the called party exchanges the similar QoS attributes with the sender during a session set up phase.

[00160] The Tables 1 and 2 from 3GPP2 Technical Report CRlOOl-E

"Administration of Parameter Value Assignments for cdma2000 Spread Spectrum Standards Release E" that were referred to above are set forth below:

Table 1 - Media Data Flow Profile ID samples from 3GPP2 CRlOOl-E [I].

Note 1 : Maximum Latency will be assigned (along with other parameters) as CRlOOl-E is finalized. The values shown in example 1 above are for illustrative purposes at this time.

Table 2 - Generic Data Flow Profile ID sample from 3OPP2 C RlOOl-E [1]

Note 1 Maximum Latency is defined to be the maximum amount of time allowed from the time that and octet of user data is submitted to the transmitting RLP until the receiving RLP either delivers the octet or aborts its delivery

Note 2 Data loss rate is defined as the ratio of the number of lost data octets to the number of transmitted data octets, measured above RLP

[00161] In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[00162] In addition, the logic flow diagrams of Figs. 4 and 5 may be viewed as method steps, as operations executed by computer program products, or as interconnected

logic blocks for performing the indicated functions.

[00163] Embodiments of the inventions may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for converting a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

[00164] Programs, such as those provided by Synopsys, Inc. of Mountain View,

California and Cadence Design, of San Jose, California automatically route conductors and locate components on a semiconductor chip using well established rules of design as well as libraries of pre-stored design modules. Once the design for a semiconductor circuit has been completed, the resultant design, in a standardized electronic format (e.g., Opus, GDSII, or the like) may be transmitted to a semiconductor fabrication facility or "fab" for fabrication.

[00165] The foregoing description has provided by way of exemplary and non- limiting examples a full and informative description of the best method and apparatus presently contemplated by the inventors for carrying out the invention. However, various modifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. As but some non-limiting examples, the use of other similar or equivalent message protocols, other than SIP and SDP, maybe employed, and the embodiments of the invention may be practiced with other types of QoS parameters if desired. However, all such and similar modifications of the teachings of this invention will still fall within the scope of the non-limiting embodiments of this invention.

[00166] Furthermore, some of the features of the various non-limiting embodiments of this invention may be used to advantage without the corresponding use of other features. As such, the foregoing description should be considered as merely illustrative of the principles, teachings and exemplary embodiments of this invention, and not in limitation thereof.