Media-Component-Number

ordinal number of the position of the "m=" line in the SDP

AF-Application-Identifier

The AF-Application-Identifier AVP may be supplied or omitted, depending on the application.

For IMS, if the AF-Application-Identifier AVP is supplied, its value should not demand application specific bandwidth or QoS class handling unless the IMS application is capable of handling a QoS downgrading.

Media-Type

The Media Type AVP shall be included with the same value as supplied for the media type in the "m=" line.

Flow-Status

IF port in m-line = 0 THEN

Flow-Status:= REMOVED;

ELSE

IF Transport in m-line is "TCP" or "TCP/MSRP" THEN (NOTE 9)

Flow-Status := ENABLED;

ELSE /* UDP or RTP/AVP transport

IF a=rtcp-mux is negotiated THEN

Flow-Status :=ENABLED; (NOTE 12 and 13)

ELSE

IF a=recvonly THEN

IF <SDP direction> = UE originated (NOTE 8) THEN

Flow-Status := ENABLED_DOWNLINK; (NOTE 4)

ELSE /* UE terminated (NOTE 8) */

Flow-Status := ENABLED_UPLINK; (NOTE 4)

ENDIF;

ELSE

IF a=sendonly THEN

IF <SDP direction> = UE originated (NOTE 8) THEN

Flow-Status := ENABLED_UPLINK; (NOTE 4)

ELSE /* UE terminated (NOTE 8) */

Flow-Status := ENABLED_DOWNLINK; (NOTE 4)

ENDIF;

ELSE

IF a=inactive THEN

Flow-Status :=DISABLED;

ELSE /* a=sendrecv or no direction attribute */

Flow-Status := ENABLED (NOTE 4)

ENDIF;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

(NOTE 5)

Max-Requested-Bandwidth-UL

IF <SDP direction> = UE terminated (NOTE 8) THEN

IF Transport in m-line is "TCP" or "TCP/MSRP" THEN (NOTE 9)

IF a=recvonly or a=sendrecv or no direction attribute THEN

IF b=AS:<bandwidth> is present and

( b=TIAS:<Tibandwidth> is not

present or is present but not supported ) THEN

Max-Requested-Bandwidth-UL:= <bandwidth> * 1000; /* Unit bit/s

ELSE

IF b=TIAS:<Tibandwidth> is present and supported THEN

Max-Requested-Bandwidth-UL:= <Transport-dependent bandwidth>

(NOTE 11) /* Unit bit/s

ELSE

Max-Requested–Bandwidth-UL:= <Operator specific setting>;

ENDIF;

ENDIF;

ELSE

Max-Requested–Bandwidth-UL:= <Operator specific setting>,

(NOTE 10)

ENDIF;

ELSE /* UDP or RTP/AVP transport

IF b=AS:<bandwidth> is present and

( b=TIAS:<Tibandwidth> is not

present or is present but not supported ) THEN

IF a=rtcp-mux is negotiated(NOTE 13) THEN

IF b=RR:<rrbandwidth> is present

OR b=RS:<rsbandwidth> is present THEN

Max-Requested-Bandwidth-UL:= <bandwidth> * 1000 +

<rrbandwidth> + <rsbandwidth>; (NOTE 3; NOTE 6)

ELSE

Max-Requested-Bandwidth-UL:= <bandwidth> * 1050;

/* Unit is bit/s

ENDIF

ELSE

Max-Requested-Bandwidth-UL:= <bandwidth> * 1000;

/* Unit is bit/s

ENDIF;

ELSE

IF b=TIAS:<Tibandwidth> is present and supported THEN

IF a=rtcp-mux is negotiated (NOTE 13) THEN

IF b=RR:<rrbandwidth> is present

OR b=RS:<rsbandwidth> is present THEN

Max-Requested-Bandwidth-UL:=
<Transport-dependent bandwidth> (NOTE 11) +

<rrbandwidth> + <rsbandwidth>; (NOTE 3; NOTE 6)

ELSE

Max-Requested-Bandwidth-UL:=
<Transport-dependent bandwidth>

* 1.05 (NOTE 11) /* Unit bit/s

ENDIF

ELSE

Max-Requested-Bandwidth-UL:= <Transport-dependent bandwidth>

(NOTE 11) /* Unit bit/s

ENDIF;

ELSE

Max-Requested–Bandwidth-UL:= <Operator specific setting>,

or AVP not supplied;

ENDIF;

ENDIF;

ENDIF

ELSE

Consider SDP in opposite direction

ENDIF

Max-Requested-Bandwidth-DL

(NOTE 17)

IF <SDP direction> = UE originated (NOTE 8) THEN

IF Transport in m-line is "TCP" or "TCP/MSRP" THEN (NOTE 9)

IF a=recvonly or a=sendrecv or no direction attribute THEN

IF b=AS:<bandwidth> is present and

( b=TIAS:<Tibandwidth> is not present or

is present but not supported ) THEN

Max-Requested-Bandwidth-DL:= <bandwidth> * 1000; /* Unit bit/s

ELSE

IF b=TIAS:<Tibandwidth> is present and supported THEN

Max-Requested-Bandwidth-DL:= <Transport-dependant bandwidth>

/* Unit bit/s (see NOTE 11)

OR Operator specific setting

ELSE

Max-Requested–Bandwidth-DL:= <Operator specific setting>;

ENDIF;

ELSE

Max-Requested–Bandwidth-DL:= <Operator specific setting>,

(NOTE 10)

ENDIF;

ELSE /* UDP or RTP/AVP transport

IF b=AS:<bandwidth> is present and b=TIAS:<Tibandwidth> is not

present THEN

IF a=rtcp-mux is negotiated(NOTE 13) THEN

IF b=RR:<rrbandwidth> is present

OR b=RS:<rsbandwidth> is present THEN

Max-Requested-Bandwidth-DL:= <bandwidth> * 1000 +

<rrbandwidth> + <rsbandwidth>; (NOTE 3; NOTE 6)

ELSE

Max-Requested-Bandwidth-DL:= <bandwidth> * 1050;

/* Unit is bit/s

ENDIF

ELSE

Max-Requested-Bandwidth-DL:= <bandwidth> * 1000

;/* Unit is bit/s

ENDIF;

ELSE

IF b=TIAS:<Tibandwidth> is present THEN

IF a=rtcp-mux is negotiated (NOTE 13) THEN

IF b=RR:<rrbandwidth> is present

OR b=RS:<rsbandwidth> is present THEN

Max-Requested-Bandwidth-DL:=
<Transport-dependent bandwidth> (NOTE 11) +

<rrbandwidth> + <rsbandwidth>; (NOTE 3; NOTE 6)

ELSE

Max-Requested-Bandwidth-DL:=
<Transport-dependent bandwidth>

* 1.05 (NOTE 11) /* Unit bit/s

ENDIF

ELSE

Max-Requested-Bandwidth-DL:= <Transport-dependent bandwidth>
(NOTE 11) /* Unit bit/s

ENDIF;

ELSE

Max-Requested–Bandwidth-DL:= <Operator specific setting>,

or AVP not supplied;

ENDIF;

ENDIF;

ENDIF

ELSE

Consider SDP in opposite direction

ENDIF

Max-Supported-Bandwidth-UL

(NOTE 18)

IF a=bw-info is present and includes MaxSupBw: <bandwidth> and direction: recv (UE terminated) or send (UE originated) or sendrecv (NOTE 14) THEN

Max-Supported-Bandwidth-UL:= [supplied <bandwidth>] * 1000 /Unit bit/s/

(NOTE 16)

ELSE /* a=bw-info is not present or is present but MaxSupBw is not

included or direction is the opposite

AVP not supplied

ENDIF;

(NOTE 15)

Max-Supported-Bandwidth-DL

(NOTE 18)

IF a=bw-info is present and includes MaxSupBw : <bandwidth> and direction: send (UE terminated) or recv (UE originated) or sendrecv (NOTE 14)THEN

Max-Supported-Bandwidth-DL:= [supplied <bandwidth>] * 1000 /Unit bit/s/

(NOTE 16)

ELSE /* a=bw-info is not present or is present but MaxSupBw is not

included or direction is the opposite

AVP not supplied

ENDIF;

(NOTE 15)

Min-Desired-Bandwidth-UL

(NOTE 19)

IF a=bw-info is present and includes MinDesBw : <bandwidth> and direction: recv (UE terminated) or send (UE originated) or sendrecv (NOTE 14) THEN

Min-Desired-Bandwidth-UL:= supplied <bandwidth> * 1000 /Unit bit/s/

(NOTE 16)

ELSE /* a=bw-info is not present or is present but MinDesBw is not

included or direction is the opposite

AVP not supplied

ENDIF;

Min-Desired-Bandwidth-DL

(NOTE 19)

IF a=bw-info is present and includes MinDesBw : <bandwidth> and direction: send (UE terminated) or recv (UE originated) or sendrecv (NOTE 14) THEN

Min-Desired-Bandwidth-DL:= [supplied <bandwidth>] * 1000 /Unit bit/s/

(NOTE 16)

ELSE /* a=bw-info is not present or is present but MinDesBw is not

included or direction is the opposite

AVP not supplied

ENDIF;

RR-Bandwidth

IF b=RR:<bandwidth> is present THEN

RR-Bandwidth:= <bandwidth>;

ELSE

AVP not supplied

ENDIF;

(NOTE 3; NOTE 6)

RS-Bandwidth

IF b=RS:<bandwidth> is present THEN

RS-Bandwidth:= <bandwidth>;

ELSE

AVP not supplied

ENDIF;

(NOTE 3, NOTE 6)

Media-Sub-Component

Supply one AVP for bidirectional combination of two corresponding IP flows, if available, and for each single IP flow without a corresponding IP flow in opposite direction.

If a media component comprises separate IP flows for RTP and RTCP, they are described in two separate Media-Sub-Component AVPs. However, if a=rtcp-mux is negotiated, RTP and RTCP use the same IP flow and shall be described in a single Media-Sub-Component AVP.

The encoding of the AVP is described in Table 6.2.2

Reservation-Priority

The AF may supply or omit this AVP.

Codec-Data

Codec Data AVP(s) are provisioned as specified in clause 5.3.16 of 3GPP TS 29.214 [10], including the codec-related information detailed in clause 5.3.7 of 3GPP TS 29.214 [10].

Max-PLR-DL

IF a= PLR_adapt line is NOT present in both SDP OFFER and ANSWER THEN

/* As UE don’t support CHEM feature, AF should not use packet loss rates

in either the uplink or downlink direction */

Max-PLR-DL AVP not supplied

ELSE

IF P-CSCF serving the OFFERER THEN

FOR each RTP payload type of the same media line

IF MAXimum-e2e-PLR line is present in the SDP OFFER THEN

IF maxUL-PLR is present in the SDP ANSWER

Max-PLR-DL = value of maxe2e-PLR in the SDP OFFER – maxUL-PLR

in the SDP ANSWER

ELSE /* maxUL-PLR is not present in the SDP ANSWER */

Max-PLR-DL = the default value is ½ maxe2e-PLR value present

in the SDP OFFER

ELSE /* MAXimum-e2e-PLR line is not present in the SDP OFFER */

IF maxUL-PLR is present in the SDP ANSWER THEN

Max-PLR-DL = (the default value is end-to-end Maximum

End-to-End Packet Loss Rate for the decoder of

the RTP payload type as recommended in 3GPP

TS 26.114 [29] clause X.1.2 for application

layer redundancy or X.1.1 for partial redundancy)

– maxUL-PLR in the SDP ANSWER

ELSE /* maxUL-PLR is not present in the SDP ANSWER */

Max-PLR-DL = the default value is ½ end-to-end Maximum End-to-End

Packet Loss Rate for the decoder of the RTP payload

type as recommended in 3GPP TS 26.114 [29]

clause X.1.2 for application layer redundancy

or X.1.1 for partial redundancy

ENDIF;

ENDIF;

END FOR LOOP of each RTP payload type of the same media

Max-PLR-DL = maximum value of Max-PLR-DL among all the RTP payload

types

ELSE /* For P-CSCF serving the ANSWERER */

FOR each RTP payload type of the same media line

IF MAXimum-e2e-PLR line is present in the SDP ANSWER THEN

IF maxDL-PLR is present in the SDP ANSWER

Max-PLR-DL = value of maxDL-PLR in the SDP ANSWER

ELSE /* maxDL-PLR is not present in the SDP ANSWER */

Max-PLR-DL = the default value is ½ maxe2e-PLR value present

in the SDP ANSWER

ELSE /* MAXimum-e2e-PLR line is not present in the SDP ANSWER */

Max-PLR-DL = the default value is ½ end-to-end Maximum End-to-End

Packet Loss Rate for the decoder of the RTP payload

type as recommended in 3GPP TS 26.114 [29]

clause X.1.2 for application layer redundancy

or X.1.1 for partial redundancy

ENDIF;

END FOR LOOP of each RTP payload type of the same media

Max-PLR-DL = maximum value of Max-PLR-DL among all the RTP payload

types

ENDIF;

ENDIF;

ENDIF;

Max-PLR-UL

IF a= PLR_adapt line is NOT present in both SDP OFFER and ANSWER THEN

/* As UE don’t support CHEM feature, AF should not use packet loss rates

in either the uplink or downlink direction */

Max-PLR-UL AVP not supplied

ELSE

IF P-CSCF serving the OFFERER THEN

FOR each RTP payload type of the same media line

IF MAXimum-e2e-PLR line is present in the SDP ANSWER THEN

IF maxDL-PLR is present in the SDP ANSWER

Max-PLR-UL = value of maxe2e-PLR in the SDP ANSWER – maxDL-PLR

in the SDP ANSWER

ELSE /* maxDL-PLR is not present in the SDP ANSWER */

Max-PLR-UL = the default value is ½ maxe2e-PLR value present

in the SDP ANSWER

ELSE /* MAXimum-e2e-PLR line is not present in the SDP ANSWER */

Max-PLR-UL = the default value is ½ end-to-end Maximum End-to-End

Packet Loss Rate for the decoder of the RTP payload

type as recommended in 3GPP TS 26.114 [29]

clause X.1.2 for Application layer redundancy

or X.1.1 for partial redundancy

ENDIF;

END FOR LOOP of each RTP payload type of the same media

Max-PLR-UL = maximum value of Max-PLR-UL among all the RTP payload

types

ELSE /* For P-CSCF serving the ANSWERER */

FOR each RTP payload type of the same media line

IF MAXimum-e2e-PLR line is present in the SDP OFFER THEN

IF maxUL-PLR is present in the SDP ANSWER

Max-PLR-UL = value of maxUL-PLR in the SDP ANSWER

ELSE /* maxUL-PLR is not present in the SDP ANSWER */

Max-PLR-UL = the default value is ½ maxe2e-PLR value present

in the SDP OFFER

ELSE /* MAXimum-e2e-PLR line is not present in the SDP OFFER */

Max-PLR-UL = the default value is ½ end-to-end Maximum End-to-End

Packet Loss Rate for the decoder of the RTP payload

type as recommended in 3GPP TS 26.114 [29]

clause X.1.2 for Application layer redundancy

or X.1.1 for partial redundancy

ENDIF;

END FOR LOOP of each RTP payload type of the same media

Max-PLR-UL = maximum value of Max-PLR-UL among all the RTP payload

types

ENDIF;

ENDIF;

ENDIF;

Desired-Max-Latency

IF <SDP direction> = UE originated (NOTE 8) THEN

IF a=3gpp-qos-hint is present and includes a qos-hint-property that indicates "latency"

IF qos-hint-split-value for "local" is not present

Desired-Max-Latency = <qos-hint-end-to-end-value>*0.5

ELSE /* qos-hint-split-value for "local" is present

Desired-Max-Latency = <qos-hint-split-value>

ENDIF

ELSE

AVP not supplied

ENDIF

ELSE /* <SDP direction> = UE terminated (NOTE 8)/

IF a=3gpp-qos-hint is present and includes a qos-hint-property that indicates "latency"

IF qos-hint-split-value for "local" is not present

Desired-Max-Latency = <qos-hint-end-to-end-value>*0.5

ELSE /* qos-hint-split-value for "local" is present/

Desired-Max-Latency = <qos-hint-end-to-end-value> – <qos-hint-split-value>

ENDIF

ELSE

AVP not supplied

ENDIF

ENDIF

Desired-Max-Loss

IF <SDP direction> = UE originated (NOTE 8) THEN

IF a=3gpp-qos-hint is present and includes a qos-hint-property that indicates "loss"

IF qos-hint-split-value for "local" is not present

Desired-Max-Loss = <qos-hint-end-to-end-value>*0.5

ELSE /* qos-hint-split-value for "local" is present/

Desired-Max-Loss = <qos-hint-split-value>

ENDIF

ELSE

AVP not supplied

ENDIF

ELSE /* <SDP direction> = UE terminated (NOTE 8)/

IF a=3gpp-qos-hint is present and includes a qos-hint-property that indicates "loss"

IF qos-hint-split-value for "local" is not present

Desired-Max-Loss = < qos-hint-end-to-end-value>*0.5

ELSE /* qos-hint-split-value for "local" is present/

Desired-Max-Loss = <qos-hint-end-to-end-value> – <qos-hint-split-value>

ENDIF

ELSE

AVP not supplied

ENDIF

ENDIF

NOTE 1: The encoding of the service information is defined in 3GPP TS 29.214 [10].

NOTE 2: The SDP parameters are described in IETF RFC 2327 [11].

NOTE 3: The "b=RS:" and "b=RR:" SDP bandwidth modifiers are defined in IETF RFC 3556 [13].

NOTE 4: As an operator policy to disable forward and/or backward early media, for media with UDP as transport protocol only the Flow-Status AVP may be downgraded by using the gate control procedures defined in the annex A of 3GPP TS 29.214 [10] before a SIP confirmed dialogue is established, i.e. until a 200 (OK) response to an INVITE request is received.

NOTE 5: If the SDP answer is available when the session information is derived, the direction attributes and port number from the SDP answer shall be used to derive the flow status. However, to enable interoperability with SIP clients that do not understand the inactive SDP attribute, if "a=inactive" was supplied in the SDP offer, this shall be used to derive the flow status. If the SDP answer is not available when the session information is derived, the direction attributes from the SDP offer shall be used.

NOTE 6: Information from the SDP answer is applicable, if available.

NOTE 7: The AVPs may be omitted if they have been supplied in previous service information and have not changed, as detailed in 3GPP TS 29.214 [10].

NOTE 8: "Uplink SDP" indicates that the SDP was received from the UE and sent to the network. This is equivalent to <SDP direction> = UE originated.

"Downlink SDP" indicates that the SDP was received from the network and sent to the UE. This is equivalent to <SDP direction> = UE terminated.

NOTE 9: Support for TCP at a P-CSCF acting as AF is only required if services with TCP transport are used in the corresponding IMS system.

As an operator policy to disable forward and/or backward early media, for media with TCP as transport protocol, the Max-Requested-Bandwidth-UL/DL values may be downgraded before a SIP confirmed dialogue is established, i.e. until a 200 (OK) response to an INVITE request is received. Only a small bandwidth in both directions is required in this case in order for TCP control packets to flow.

NOTE 10: TCP uses IP flows in the directionality opposite to the transferred media for feedback. To enable these flows, a small bandwidth in this direction is required.

NOTE 11: TIAS is defined in IETF RFC 3890 [23]. IETF RFC 3890 clause 6.4 provides procedures for converting TIAS to transport-dependant values. This procedure relies on the presence of maxprate (also defined in IETF RFC 3890).

NOTE 12: Multiplexed RTP/RTCP flows need to have Flow-Status set to "ENABLED" in order to always permit the RTCP traffic.

NOTE 13: RTP/RTCP multiplexing is defined in IETF RFC 5761 [39].

NOTE 14: This AVP is derived from the SDP answer information and is omitted if E2EQOSMTSI feature is not supported.

NOTE 15: When both "b =" line and "a=bw-info" including MaxSupBw are present when sending the SDP, it is expected that the values are aligned.

NOTE 16: When the supplied bandwidth does not correspond to the bandwidth applicable to the IP version used by the UE, the AF shall re-compute it considering the IP version used by the UE as defined in 3GPP TS 26.114 [29].

NOTE 17: When the Extended-Max-Requested-BW-NR feature is supported and if the bandwidth values are higher than 2^32-1 bps, Extended-Max-Requested-BW-UL/DL shall be derived instead of Max-Requested-Bandwidth-UL/DL. The same derivation procedure shall apply, with the exception that the units for the derived bandwidth shall be kbit per second instead of bit per second.

NOTE 18: When the Extended-BW-E2EQOSMTSI-NR feature is supported and if the bandwidth values are higher than 2^32-1 bps, Extended-Max-Supported-BW-UL/DL shall be derived instead of Max-Supported-Bandwidth-UL/DL. The same derivation procedure shall apply, with the exception that the units for the derived bandwidth shall be kbit per second instead of bit per second.

NOTE 19: When the Extended-BW-E2EQOSMTSI-NR feature is supported and if the bandwidth values are higher than 2^32-1 bps, Extended-Min-Desired-BW-UL/DL shall be derived instead of Min-Desired-Bandwidth-UL/DL. The same derivation procedure shall apply, with the exception that the units for the derived bandwidth shall be kbit per second instead of bit per second.

Flow-Number

The AF shall assign a number to the media-subcomponent AVP that is unique within the surrounding media component AVP and for the entire lifetime of the AF session. The AF shall select the ordinal number of the IP flow(s) within the "m=" line assigned in the order of increasing downlink destination port numbers, if downlink destination port numbers are available. For uplink or inactive unicast media IP flows, a downlink destination port number is nevertheless available, if SDP offer-answer according to IETF RFC 3264 is used.

The AF shall select the ordinal number of the IP flow(s) within the "m=" line assigned in the order of increasing uplink destination port numbers, if no downlink destination port numbers are available.

Flow-Status

AVP not supplied

Max-Requested-Bandwidth-UL

AVP not supplied

Max-Requested-Bandwidth-DL

AVP not supplied

Flow-Description

For uplink and downlink direction, a Flow-Description AVP shall be provided unless no IP Flows in this direction are described within the media component.

If UDP is used as transport protocol, the SDP direction attribute (NOTE 4) indicates the direction of the media IP flows within the media component as follows:

IF a=recvonly THEN (NOTE 3)

IF <SDP direction> = UE originated (NOTE 7) THEN

Provide only downlink Flow-Description AVP

ELSE /* UE terminated (NOTE 7) */

Provide only uplink Flow-Description AVP

ENDIF;

ELSE

IF a=sendonly THEN (NOTE 3)

IF <SDP direction> = UE originated (NOTE 7) THEN

Provide only uplink Flow-Description AVP

ELSE /* UE terminated (NOTE 7) */

Provide only downlink Flow-Description AVP

ENDIF;

ELSE /* a=sendrecv or a=inactive or no direction attribute */

Provide uplink and downlink Flow-Description AVPs

ENDIF;

ENDIF;

However, for RTCP and RTP/RTCP multiplexed IP flows uplink and downlink Flow-Description AVPs shall be provided irrespective of the SDP direction attribute.

If TCP is used as transport protocol (NOTE 8), IP flows in uplink and downlink direction are described in SDP irrespective of the SDP direction attribute, as TCP uses an IP flow for feedback even if contents are transferred only in the opposite direction. Thus, both uplink and downlink Flow-Description AVPs shall be provided.

The uplink destination address shall be copied from the "c=" line of downlink SDP. (NOTE 6) (NOTE 7)

The uplink destination port shall be derived from the "m=" line of downlink SDP. (NOTE 6) (NOTE 7) However, for TCP transport the uplink destination port shall be wildcarded, if the local UE is the passive endpoint (NOTE 9)

The downlink destination address shall be copied from the "c=" line of uplink SDP. (NOTE 6) However, a P-CSCF acting as AF and applying NAT traversal procedures in Annex C shall derive the downlink destination address using those procedures.

The downlink destination port shall be derived from the "m=" line of uplink SDP. (NOTE 6) (NOTE 7) However, for TCP transport the downlink destination port shall be wildcarded, if the local UE is the active endpoint (NOTE 9). A P-CSCF acting as AF and applying NAT traversal procedures in Annex C shall derive the downlink destination port using those procedures.

For IPv6, uplink and downlink source addresses shall either be derived from the prefix of the destination address or be wildcarded by setting to "any", as specified in 3GPP TS 29.214 [10]. However, a P-CSCF acting as AF and applying NAT traversal procedures in Annex C shall derive the uplink source address using those procedures.

If IPv4 is being utilized, the uplink source address shall either be set to the address contained in the "c=" line of the uplink SDP or be wildcarded, and the downlink source address shall either be set to the address contained in the "c=" line of the downlink SDP or be wildcarded. However, for TCP transport, if the local UE is the passive endpoint (NOTE 9), the uplink source address shall not be wildcarded. If the local UE is the active endpoint (NOTE 9), the downlink source address shall not be wildcarded. A P-CSCF acting as AF and applying NAT traversal procedures in Annex C shall derive the uplink source address using those procedures.

Source ports shall not be supplied. However, for TCP transport, if the local UE is the passive end point (NOTE 9), the uplink source port shall be derived from the "m=" line of the uplink SDP. If the local UE is the active end point (NOTE 9), the downlink source port shall be derived from the "m=" line of the downlink SDP. A P-CSCF acting as AF and applying NAT traversal procedures in Annex C shall derive the downlink source ports using those procedures.

Proto shall be derived from the transport of the "m=" line. For "RTP/AVP" proto is 17(UDP). For "TCP", as defined in IETF RFC 4145 [16], or "TCP/MSRP", as defined in IETF RFC 4975 [17], proto is 6(TCP).

Flow-Usage

The Flow-Usage AVP shall be supplied with value "RTCP" if the IP flow(s) described in the Media-Sub-Component AVP are used to transport RTCP only. Otherwise the Flow-Usage AVP shall not be supplied. IETF RFC 2327 [11] specifies how RTCP flows are described within SDP.

If the IP flows(s) are used to transport signalling the value should be "AF-SIGNALLING".

NOTE 1: The encoding of the service information is defined in 3GPP TS 29.214 [10].

NOTE 2: The SDP parameters are described in IETF RFC 2327 [11].

NOTE 3: If the SDP direction attribute for the media component negotiated in a previous offer-answer exchange was sendrecv, or if no direction attribute was provided, and the new SDP direction attribute sendonly or recvonly is negotiated in a subsequent SDP offer-answer exchange, uplink and downlink Flow-Description AVPs shall be supplied.

NOTE 4: If the SDP answer is available when the session information is derived, the direction attributes from the SDP answer shall be used to derive the flow description. However, to enable interoperability with SIP clients that do not understand the inactive SDP attribute, if "a=inactive" was supplied in the SDP offer, this shall be used. If the SDP answer is not available when the session information is derived, the direction attributes from the SDP offer shall be used.

NOTE 5: The AVPs may be omitted if they have been supplied in previous service information and have not changed, as detailed in 3GPP TS 29.214 [10].

NOTE 6: If the session information is derived from an SDP offer, the required SDP may not yet be available. The corresponding Flow Description AVP shall nevertheless be included and the unavailable fields (possibly all) shall be wildcarded.

NOTE 7: "Uplink SDP" indicates that the SDP was received from the UE and sent to the network. This is equivalent to <SDP direction> = UE originated.

"Downlink SDP" indicates that the SDP was received from the network and sent to the UE. This is equivalent to <SDP direction> = UE terminated.

NOTE 8: Support for TCP at a P-CSCF acting as AF is only required if services with TCP transport are used in the corresponding IMS system.

NOTE 9: For TCP transport, the passive endpoints is derived from the SDP "a=setup" attribute according to the rules in IETF RFC 4145 [16], or, if that attribute is not present, from the rules in IETF RFC 4975 [17].

Maximum Authorized Data Rate DL (Max_DR_DL) and UL (Max_DR_UL)

(NOTE 21)

IF operator special policy exists THEN

Max_DR_UL:= as defined by operator specific algorithm;

Max_DR_DL:= as defined by operator specific algorithm;

ELSE

IF AF-Application-Identifier AVP demands application specific data rate

handling THEN

Max_DR_UL:= as defined by application specific algorithm;

Max_DR_DL:= as defined by application specific algorithm;

ELSE IF Codec-Data AVP provides Codec information for a codec that is

supported by a specific algorithm (NOTE 19,20) THEN

Max_DR_UL:= as defined by specific algorithm;

Max_DR_DL:= as defined by specific algorithm;

ELSE

IF not RTCP flow(s) according to Flow-Usage AVP THEN

IF Flow-Status = REMOVED THEN

Max_DR_UL:= 0;

Max_DR_DL:= 0;

ELSE

IF uplink Flow Description AVP is supplied THEN

IF Max-Supported-Bandwidth-UL is present and supported THEN

Max_DR_UL:= Max-Supported-Bandwidth-UL;

ELSE IF Max-Requested-Bandwidth-UL is present THEN

Max_DR_UL:= Max-Requested-Bandwidth-UL ;

ELSE

Max_DR_UL:= as set by the operator;

ENDIF;

ELSE

Max_DR_UL:= 0;

ENDIF;

IF downlink Flow Description AVPs is supplied THEN

IF Max-Supported-Bandwidth-DL is present and supported THEN

Max_DR_DL:= Max-Supported-Bandwidth-DL;

ELSE IF Max-Requested-Bandwidth-DL is present THEN

Max_DR_DL:= Max-Requested-Bandwidth-DL;

ELSE

Max_DR_DL:= as set by the operator;

ENDIF;

ELSE

Max_DR_DL:= 0;

ENDIF;

ENDIF;

ELSE /* RTCP IP flow(s) */

IF RS-Bandwidth is present and RR-Bandwidth is present THEN
Max_DR_UL:= (RS-Bandwidth + RR-Bandwidth);
Max_DR_DL:= (RS-Bandwidth + RR-Bandwidth);
ELSE
IF Max-Requested-Bandwidth-UL is present THEN

IF RS-Bandwidth is present and RR-Bandwidth is not present THEN

Max_DR_UL:= MAX[0.05 * Max-Requested-Bandwidth-UL,RS-Bandwidth];

ENDIF;

IF RS-Bandwidth is not present and RR-Bandwidth is present THEN

Max_DR_UL:= MAX[0.05 * Max-Requested-Bandwidth-UL,RR-Bandwidth];

ENDIF;

IF RS-Bandwidth and RR-Bandwidth are not present THEN

Max_DR_UL:= 0.05 * Max-Requested-Bandwidth_UL ;

ENDIF;

ELSE

Max_DR_UL:= as set by the operator;

ENDIF;

IF Max-Requested-Bandwidth-DL is present THEN

IF RS-Bandwidth is present and RR-Bandwidth is not present THEN

Max_DR_DL:= MAX[0.05 * Max-Requested-Bandwidth-DL,RS-Bandwidth];

ENDIF;

IF RS-Bandwidth is not present and RR-Bandwidth is present THEN

Max_DR_DL:= MAX[0.05 * Max-Requested-Bandwidth-DL,RR-Bandwidth];

ENDIF;

IF RS-Bandwidth and RR-Bandwidth are not present THEN

Max_DR_DL:= 0.05 * Max-Requested-Bandwidth-DL;
ENDIF;

ELSE

Max_DR_DL:= as set by the operator;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

IF SIP-Forking-Indication AVP indicates SEVERAL_DIALOGUES THEN

Max_DR_UL = MAX[Max_DR_UL, previous Max_DR_UL]

Max_DR_DL = MAX[Max_DR_DL, previous Max_DR_DL]

ENDIF;

Authorized Guaranteed Data Rate DL (Gua_DR_DL) and UL (Gua_DR_UL)

(see NOTE 11, 13, 15, 16. 21)

IF operator special policy exists THEN

Gua_DR_UL:= as defined by operator specific algorithm;

Gua_DR_DL:= as defined by operator specific algorithm;

ELSE

IF AF-Application-Identifier AVP demands application specific data rate

handling THEN

Gua_DR_UL:= as defined by application specific algorithm;

Gua_DR_DL:= as defined by application specific algorithm;

ELSE IF Codec-Data AVP provides Codec information for a codec that is

supported by a specific algorithm (NOTE 5,19,20)THEN

Gua_DR_UL:= as defined by specific algorithm;

Gua_DR_DL:= as defined by specific algorithm;

ELSE

IF uplink Flow-Description AVP is supplied THEN

IF Min-Desired-Bandwidth-UL is present and supported THEN

Gua_DR_UL:= Min-Desired-Bandwidth-UL ;

ELSE IF Min-Requested-Bandwidth-UL is present THEN

Gua_DR_UL:= Min-Requested-Bandwidth-UL ;

ELSE

Gua_DR_UL:= as set by the operator;

ENDIF;

ELSE

Gua_DR_UL:= Max DR UL;

ENDIF;

IF downlink Flow-Description AVP is supplied THEN

IF Min-Desired-Bandwidth-DL is present and supported THEN

Gua_DR_DL:= Min-Desired-Bandwidth-DL

ELSE IF Min-Requested-Bandwidth-DL is present THEN

Gua_DR_DL:= Min-Requested-Bandwidth-DL ;

ELSE

Gua_DR_DL:= as set by the operator;

ENDIF;

ELSE

Gua_DR_DL:= Max DR DL;

ENDIF;

ENDIF;

ENDIF;

IF SIP-Forking-Indication AVP indicates SEVERAL_DIALOGUES THEN

Gua_DR_UL = MAX[Gua_DR_UL, previous Gua_DR_UL]

Gua_DR_DL = MAX[Gua_DR_DL, previous Gua_DR_DL]

ENDIF;

Authorized QoS Class Identifier [QCI]

(see NOTE 1, 2, 7, 12, 14 and 23)

IF an operator special policy exists THEN

QCI:= as defined by operator specific algorithm;

ELSE IF MPS-Identifier AVP demands MPS specific QoS Class handling THEN

QCI:= as defined by MPS specific algorithm (NOTE 18);

ELSE IF GCS-Identifier AVP demands Group Communication specific handling THEN

QCI:= as defined by GCS specific algorithm (NOTE 17);

ELSE IF AF-Application-Identifier AVP demands application specific QoS Class handling THEN

QCI:= as defined by application specific algorithm;

ELSE IF Codec-Data AVP provides Codec information for a codec that is supported by a specific algorithm THEN

QCI:= as defined by specific algorithm; (NOTE 5)

ELSE IF FLUS-Identifier AVP demands specific QoS Class handling THEN

QCI:= as defined by specific algorithm; (NOTE 22)

ELSE

/* The following QCI derivation is an example of how to obtain the QCI

values in a GPRS network */

IF Media-Type is present THEN

/* for GPRS: streaming */

IF (only uplink Flow Description AVPs are supplied for all IP

flows of the AF session, which have media type “audio” or “video”

and no flow usage “RTCP”, or

only downlink Flow Description AVPs are supplied for all IP

flows of the AF session, which have media type “audio” or “video”

and no flow usage “RTCP”) THEN

CASE Media-Type OF

“audio”: MaxClassDerivation := 3 OR 4; (NOTE 9)

“video”: MaxClassDerivation := 4

END;

/* for GPRS: conversational */

ELSE

CASE Media-Type OF

“audio”: MaxClassDerivation:= 1 OR 2; (NOTE 6)

“video”: MaxClassDerivation:= 2

END;

ENDIF;

CASE Media-Type OF

“audio”: QCI := MaxClassDerivation

“video”: QCI := MaxClassDerivation

“application”: QCI := 1 OR 2; (NOTE 6)

/*e.g. for GPRS: conversational*/

“data”: QCI := 6 OR 7 OR 8; (NOTE 8)

/*e.g. for GPRS: interactive with prio 1, 2 AND 3

respectively*/

“control”: QCI := 6;

/*e.g. for GPRS: interactive with priority 1*/

/* NOTE: include new media types here */

OTHERWISE: QCI := 9;

/*e.g. for GPRS: background*/

END;

ENDIF;

ENDIF;

IF SIP-Forking-Indication AVP indicates SEVERAL_DIALOGUES THEN

QCI = MAX[QCI, previous QCI](NOTE 10)

ENDIF ;

NOTE 1: The QCI assigned to a RTCP IP flow is the same as for the corresponding RTP media IP flow.

NOTE 2: When audio or video IP flow(s) are removed from a session, the parameter MaxClassDerivation shall keep the originally assigned value.

NOTE 3: When audio or video IP flow(s) are added to a session, the PCRF shall derive the parameter MaxClassDerivation taking into account the already existing media IP flow(s) within the session.

NOTE 4: The encoding of the service information is defined in 3GPP TS 29.214 [10]. Possible Bandwidth information and Flow-Status information provided within the Media-Sub-Component AVP takes precedence over information within the encapsulating Media-Component-Description AVP as specified in 3GPP TS 29.214 [10]. If AVPs are omitted within a Media-Component-Description AVP or Media-Sub-Component AVP of the service information, the corresponding information from previous service information shall be used, as specified in 3GPP TS 29.214 [10].

NOTE 5: 3GPP TS 26.234 [6], 3GPP TS 26.114 [29], 3GPP2 C.S0046 [18], and 3GPP2 C.S0055 [19] contain examples of QoS parameters for codecs of interest. The support of any codec specific algorithm in the PCRF is optional.

NOTE 6: For GPRS, the final QCI value will depend on the value of SSD (speech/unknown) according to 3GPP TS 23.107 [4] and table A.3 of 3GPP TS 23.203 [2]. If the PCRF is not able to determine the SSD, it should use the QCI value 2 that corresponds to SSD unknown. For UE-init and mixed mode, the PCRF may derive from the requested QoS of an IP CAN bearer which SSD is applicable.

NOTE 7: The numeric value of the QCI are based on 3GPP TS 29.212 [9].

NOTE 8: The QCI value also encodes the traffic handling priority for GPRS. If the PCRF is not able to determine a traffic handling priority, it should choose QCI 8 that corresponds to priority 3. Also, for UE-initiated bearers the PCRF should only use QCI 8 in order to have the same mapping rules in both UE and PCRF.

NOTE 9: For GPRS, the final QCI value will depend on the value of SSD (speech/unknown) according to 3GPP TS 23.107 [4] and table A.3 of 3GPP TS 23.203 [2]. If the PCRF is not able to determine the SSD, it should use the QCI value 4 that corresponds to SSD unknown. For UE-init and mixed mode, the PCRF may derive from the requested QoS of an IP CAN bearer which SSD is applicable.

NOTE 10: The Max function shall use the following precedence order for the QCI values: 2 > 1 > 4 > 3 > 5 > 6 > 7 > 8 > 9

NOTE 11: Authorized Guaranteed Data Rate DL and UL shall not be derived for QCI values 5, 6, 7, 8 and 9.

NOTE 12: Recommended QCI values for standardised QCI characteristics are shown in table 6.1.7 in 3GPP TS 23.203 [2].

NOTE 13: The PCRF may be configured with operator specific preconditions for setting the Authorized Guaranteed Data Rate lower than the corresponding Maximum Authorized Data Rate.

NOTE 14: In a network where SRVCC is enabled, the QCI=1 shall be used for IMS services in accordance to 3GPP TS 23.216 [27]. Non-IMS services using QCI=1 may suffer service interruption and/or inconsistent service experience if SRVCC is triggered. Triggering SRVCC for WebRTC IMS session will cause service interruption and/or inconsistent service experience when using QCI=1. Operator policy (e.g. use of specific AF application identifier) may be used to avoid using QCI 1 for a voice service, e.g. WebRTC IMS session.

NOTE 15: For certain services (e.g. DASH services according to 3GPP TS 26.247 [30]), the AF may also provide a minimum required bandwidth so that the PCRF can derive an Authorized Guaranteed Data Rate lower than the Maximum Authorized Data Rate.

NOTE 16: For GPRS and EPS, the PCRF shall assign an Authorized Guaranteed Data Rate UL/DL value within the limit supported by the serving network.

NOTE 17: The GCS specific algorithm shall consider various inputs, including the received Reservation-Priority AVP, for deriving the QCI.

NOTE 18: The MPS specific algorithm shall consider various inputs, including the received MPS-Identifier AVP and Reservation-Priority AVP, for deriving the QCI.

NOTE 19: When multiple codecs are supported per media stream (e.g. as part of multi-stream multiparty conferencing media handling are negotiated as described in 3GPP TS 26.114 [29]) the codec specific algorithm shall consider the bandwidth related to each codec when calculating the total bandwidth.

NOTE 20: 3GPP TS 26.114 [29] contains examples of how the Authorized Guaranteed Data Rate and Maximum Authorized Data Rate are assumed to be derived for multi-party multimedia conference media handling support. The support of this behaviour is optional.

NOTE 21: For bandwidth values higher than 2^32-1 bps and if the Extended-BW-NR feature is supported over Gx/Gxx interface, Extended-Max_DR_DL/UL and Extended-Gua_DR_DL/UL shall be derived instead of Max_DR_DL/UL and Gua_DR_DL/UL.

NOTE 22: The "live" uplink streaming algorithm may consider various inputs, including the received FLUS-Identifier AVP, Desired-Max-Latency AVP, Desired-Max-Loss AVP, AF-Application-Identifier AVP and Media-Type AVP for deriving the QCI. When Desired-Max-Latency AVP and/or Desired-Max-Loss AVP are present, non-authority QCI mapping may be done according to table 6.1.7-A in 3GPP TS 23.203 [2].

NOTE 23: The algorithm to support applications with specific QoS hints (e.g. loss and/or latency demands) may consider various inputs, including the received Desired-Max-Latency AVP, Desired-Max-Loss AVP and AF-Application-Identifier AVP for deriving the QCI, as shown in table E.0 in 3GPP TS 26.114 [29]. Non-authority QCI mapping may be done according to table 6.1.7-A in 3GPP TS 23.203 [2].

Maximum Authorized Data Rate DL and UL

(see NOTE 6)

Maximum Authorized Data Rate DL/UL is the sum of all Maximum Authorized Data Rate DL/UL for all the IP flows or bidirectional combinations of IP flows (as according to table 6.3.1).

IF Network = GPRS AND Maximum Authorized Data Rate DL/UL > 256 Mbps THEN
Maximum Authorized Data Rate DL/UL = 256 Mbps /* See 3GPP TS 23.107 [4] */
ENDIF;

Guaranteed Authorized Data Rate DL and UL

(see NOTE 3,6)

Guaranteed Authorized Data Rate DL/UL is the sum of all Guaranteed Authorized Data Rate DL/UL for all the IP flows or bidirectional combinations of IP flows (as according to table 6.3.1).

QCI

QCI = MAX [needed QoS parameters per IP flow or bidirectional combination of IP flows (as operator’s defined criteria) among all the IP flows or bidirectional combinations of IP flows.]

ARP

(see NOTE 1)

IF an operator special policy exists THEN

ARP:= as defined by operator specific algorithm;

ELSE IF MPS-Identifier AVP demands MPS specific ARP handling THEN

ARP:= as defined by MPS specific algorithm (NOTE 2);

ELSE IF GCS-Identifier AVP demands Group Communication Service specific ARP handling THEN

ARP:= as defined by GCS specific algorithm (NOTE 4);

ELSE IF MCPTT-Identifier AVP demands MCPTT specific ARP handling THEN

ARP:= as defined by MCPTT specific algorithm (NOTE 5);

ELSE IF MCVideo-Identifier AVP demands MCVideo specific ARP handling THEN

ARP:= as defined by MCVideo specific algorithm (NOTE 7);

ELSE IF AF-Application-Identifier AVP demands application specific ARP

handling THEN

ARP:= as defined by application specific algorithm;

ELSE IF Reservation-Priority AVP demands application specific ARP handling THEN

ARP:= as defined by application specific algorithm;

ENDIF;

NOTE 1: The ARP priority levels 1-8 should only be assigned to resources for services that are authorized to receive prioritized treatment within an operator domain.

NOTE 2: The MPS specific algorithm shall consider various inputs, including the received MPS-Identifier AVP and Reservation-Priority AVP, for deriving the ARP.

NOTE 3: For GPRS and EPS, the PCRF may check that the Guaranteed Authorized Data Rate DL/UL does not exceed the limit supported by the serving network to minimize the risk of rejection of the bearer by the serving network.

NOTE 4: The GCS specific algorithm shall consider various inputs, including the received Reservation-Priority AVP, for deriving the ARP.

NOTE 5: The MCPTT specific algorithm shall consider the value of the MCPTT-Identifier AVP and the value of the Reservation-Priority AVP.

NOTE 6: For bandwidth values higher than 2^32-1 bps and if the Extended-BW-NR feature is supported, Extended Guaranteed Authorized Data Rate DL/UL and Extended Maximum Data Rated DL/UL shall be used instead of Maximum Authorized Data Rate DL/UL and Guaranteed Authorized Data Rate DL/UL.

NOTE 7: The MCVideo specific algorithm shall consider the value of the MCVideo-Identifier AVP and the value of the Reservation-Priority AVP.

Maximum Authorized Bandwidth DL and UL per PDP context

(see NOTE 2)

Maximum Authorized Bandwidth DL/UL per PDP context = Maximum Authorized Data Rate DL/UL

Guaranteed Authorized Data Rate DL and UL per PDP context

Guaranteed Authorized Data Rate DL/UL per PDP context = Guaranteed Authorized Data Rate DL/UL

Maximum Authorized Traffic Class per PDP context

IF QCI = 1 OR 2 THEN
Maximum Authorized Traffic Class = “Conversational”

ELSEIF QCI = 3 OR 4 THEN
Maximum Authorized Traffic Class = “Streaming”

ELSEIF QCI = 5 OR 6 OR 7 OR 8 THEN
Maximum Authorized Traffic Class = “Interactive”;

ELSE Maximum Authorized Traffic Class = “Background”
ENDIF ;

Traffic Handling Priority

IF QCI = 5 OR 6 THEN

Maximum Authorized Traffic Handling Priority = “1”;

ELSE IF QCI = 7 THEN

Maximum Authorized Traffic Handling Priority = “2”;

ELSE IF QCI = 8 THEN

Maximum Authorized Traffic Handling Priority = “3”;

ELSE the GGSN shall not derive Traffic Handling Priority

ENDIF ;

Signalling Indication

IF QCI = 5 THEN

Signalling Indication = “Yes”;

ELSE IF QCI = 6 OR 7 OR 8 THEN

Signalling Indication = “No”;

ELSE the GGSN shall not derive Signalling Indication

ENDIF ;

Source Statistics Descriptor

IF QCI = (1 OR 3) THEN

Source Statistics Descriptor = “speech”;

ELSE IF QCI = 2 OR 4 THEN

Source Statistics Descriptor = “unknown”;

ELSE the GGSN shall not derive Source Statistics Descriptor

ENDIF ;

Evolved Allocation/Retention Priority

(see NOTE 1)

Evolved Allocation/Retention Priority = Allocation-Retention-Priority as follows :

PL := Priority-Level ;

PVI := Pre-emption-Vulnerability ;

PCI := Pre-emption-Capability ;

APN-AMBR UL and DL

For non-GBR PDP Contexts, APN-AMBR DL/UL = APN-Aggregate-Max-Bitrate DL/UL

NOTE 1: Evolved Allocation/Retention Priority is derived only if supported by the SGSN.

NOTE 2: When APN-AMBR is supported in GPRS and the PCEF performs the bearer binding, the MBR for non-GBR

PDP-Contexts is not derived

Maximum Authorized Bandwidth DL and UL per PDP context

(see NOTE 2)

For non-GBR bearers, Maximum Authorized Bandwidth DL/UL per PDP context = APN-Aggregate-Max-Bitrate DL/UL

For GBR bearers, Maximum Authorized Bandwidth DL/UL per PDP context = Sum of Maximum Authorized Data Rate DL/UL for all PCC Rules bound to that bearer

Guaranteed Authorized Data Rate DL and UL per PDP context

Guaranteed Authorized Data Rate DL/UL per PDP context = Sum of Guaranteed Authorized Data Rate DL/UL for all PCC Rules bound to that bearer

Maximum Authorized Traffic Class per PDP context

IF QCI = 1 OR 2 OR 3 THEN
Maximum Authorized Traffic Class = “Conversational”

ELSEIF QCI = 4 THEN
Maximum Authorized Traffic Class = “Streaming”

ELSEIF QCI = 5 OR 6 OR 7 OR 8 THEN
Maximum Authorized Traffic Class = “Interactive”;

ELSE Maximum Authorized Traffic Class = “Background”
ENDIF ;

Traffic Handling Priority

IF QCI = 5 OR 6 THEN

Maximum Authorized Traffic Handling Priority = “1”;

ELSE IF QCI = 7 THEN

Maximum Authorized Traffic Handling Priority = “2”;

ELSE IF QCI = 8 THEN

Maximum Authorized Traffic Handling Priority = “3”;

ELSE the P-GW shall not derive Traffic Handling Priority

ENDIF ;

Signalling Indication

IF QCI = 5 THEN

Signalling Indication = “Yes”;

ELSE IF QCI = 6 OR 7 OR 8 THEN

Signalling Indication = “No”;

ELSE the P-GW shall not derive Signalling Indication

ENDIF ;

Source Statistics Descriptor

IF QCI = 1 THEN

Source Statistics Descriptor = “speech”;

ELSE IF QCI = 2 OR 3 OR 4 THEN

Source Statistics Descriptor = “unknown”;

ELSE the P-GW shall not derive Source Statistics Descriptor

ENDIF ;

APN-AMBR DL and UL

(see NOTE 3)

For non-GBR bearers, APN-AMBR = APN-Aggregate-Max-Bitrate DL/UL

Transfer Delay

(see NOTE 1)

IF QCI = 2 THEN

Transfer Delay = 150 ms

ELSE IF QCI = 3 THEN

Transfer Delay >= 80 ms

ELSE IF QCI = 1 OR 4 the P-GW shall set the Transfer Delay as the Packet Delay Budget for that QCI

ELSE the P-GW shall not derive Transfer Delay.

ENDIF ;

Evolved Allocation/Retention Priority

(see NOTE 4)

Evolved Allocation/Retention Priority = Allocation-Retention-Priority as follows :

PL := Priority-Level ;

PVI := Pre-emption-Vulnerability ;

PCI := Pre-emption-Capability ;

NOTE 1: Recommended Packet Delay Budget values for the different QCI values are defined in subclause 6.1.7,3GPP TS 23.203 [2].

NOTE 2: For non-GBR bearers, applicable only if APN-AMBR is not supported by the SGSN.

NOTE 3: Applicable to all non-GBR PDP-Contexts when supported by the SGSN.

NOTE 4: Evolved Allocation/Retention Priority is derived only if supported by the SGSN.

Maximum Bitrate DL/UL and
Guaranteed Bitrate DL/UL per media component

/* Check if the media use codec(s) */
IF [(<media> = (“audio” or “video”)) and (<transport> = “RTP/AVP”)] THEN

/* Check if Streaming */
IF a= (“sendonly” or “recvonly”) THEN
Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media component as specified in 3GPP TS 26.234 [6] ;
/* Conversational as default !*/
ELSE
Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media component as specified in reference 3GPP TS 26.114 [29] ;
ENDIF ;

/* Check for presence of bandwidth attribute for each media component */
ELSEIF b=AS:<bandwidth-value> is present THEN
IF media stream only downlink THEN

Maximum Bitrate DL = Guaranteed Bitrate DL =<bandwidth-value >;

ELSEIF mediastream only uplink THEN

Maximum Bitrate UL = Guaranteed Bitrate UL =<bandwidth-value >;

ELSEIF mediastreams both downlink and uplink THEN

Maximum Bitrate DL = Guaranteed Bitrate DL =<bandwidth-value >;

Maximum Bitrate UL = Guaranteed Bitrate UL =<bandwidth-value >;

ENDIF;

ELSE

/* SDP does not give any guidance ! */
Maximum Bitrate DL/UL and Guaranteed Bitrate DL/UL per media component as specified by the UE manufacturer;
ENDIF ;

Maximum Authorized Bandwidth DL (Max_BW_DL) and UL (Max_BW_UL)
(see NOTE 5)

IF a=recvonly THEN

IF <SDP direction> = mobile originated THEN

Direction:= downlink;

ELSE /* mobile terminated */

Direction:= uplink;

ENDIF;

ELSE /* a!= recvonly */

IF a=sendonly THEN

IF <SDP direction> = mobile originated THEN

Direction: = uplink;

ELSE /* mobile terminated */

Direction:= downlink;

ENDIF;

ELSE /*sendrecv, inactive or no direction attribute*/

Direction:=both;

ENDIF;

ENDIF;

/* Max_BW_UL and Max_BW_DL */

IF media IP flow(s) THEN

IF b_AS=AS:<bandwidth> is present and

( b_TIAS=TIAS:<Tibandwidth> is not present or

is present but not supported ) THEN

IF Direction=downlink THEN

Max_BW_UL:= 0;

Max_BW_DL:= b_AS;

ELSE

IF Direction=uplink THEN

Max_BW_UL := b_AS ;

Max_BW_DL := 0 ;

ELSE /*Direction=both*/

Max_BW_UL:= b_AS;

Max_BW_DL := b_AS ;

ENDIF ;

ENDIF;

ELSE

IF b_TIAS=TIAS:<Tibandwidth> is present and supported THEN

b_TDBW= b_TIAS + transport-overhead; (NOTE 6)

IF Direction=downlink THEN

Max_BW_UL:= 0;

Max_BW_DL:= b_TDBW; (NOTE 6)

ELSE

IF Direction=uplink THEN

Max_BW_UL:= b_TDBW; (NOTE 6)

Max_BW_DL:= 0;

ELSE /*Direction=both*/

Max_BW_UL:= b_TDBW; (NOTE 6)

Max_BW_DL:= b_TDBW; (NOTE 6)

ENDIF;

ENDIF;

ELSE /* b_TIAS=TIAS:<Tibandwidth> is NOT present or is present but not
supported*/

bw:= as set by the UE manufacturer;

IF Direction=downlink THEN

Max_BW_UL:= 0;

Max_BW_DL:= bw;

ELSE

IF Direction=uplink THEN

Max_BW_UL:= bw;

Max_BW_DL:= 0;

ELSE /*Direction=both*/

Max_BW_UL:= bw;

Max_BW_DL:= bw;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

ELSE /* RTCP IP flow(s) */

IF b_RS=RS:<bandwidth> and b_RR=RR:<bandwidth> is present THEN
Max_BW_UL:= (b_RS + b_RR) / 1000;
Max_BW_DL:= (b_RS + b_RR) / 1000;
ELSE
IF b_AS=AS:<bandwidth> is present and

( b_TIAS=TIAS:<Tibandwidth> is not present or
is present but not supported ) THEN

IF b_RS=RS:<bandwidth> is present and b_RR=RR:<bandwidth> is not present

THEN

Max_BW_UL := MAX[0.05 * b_AS, b_RS / 1000] ;
Max_BW_DL := MAX[0.05 * b_AS, b_RS / 1000] ;

ENDIF;

IF b_RS=RS:<bandwidth> is not present and b_RR=RR:<bandwidth> is present

THEN

Max_BW_UL:= MAX[0.05 * b_AS, b_RR / 1000];
Max_BW_DL:= MAX[0.05 * b_AS, b_RR / 1000];

ENDIF;

IF b_RS=RS:<bandwidth> and b_RR=RR:<bandwidth> is not present THEN

Max_BW_UL := 0.05 * b_AS ;
Max_BW_DL := 0.05 * b_AS ;

ENDIF;

ELSE

IF b_TIAS=TIAS:<Tibandwidth> is present and supported THEN

b_TDBW= b_TIAS + transport-overhead; (NOTE 6)

IF b_RS=RS:<bandwidth> is present and

b_RR=RR:<bandwidth> is not present THEN Max_BW_UL:= MAX[0.05 * b_TDBW, b_RS]/1000;
Max_BW_DL:= MAX[0.05 * b_TDBW, b_RS]/1000;

ENDIF;

IF b_RS=RS:<bandwidth> is not present and

b_RR=RR:<bandwidth> is present THEN

Max_BW_UL:= MAX[0.05 * b_TDBW, b_RR]/1000;
Max_BW_DL:= MAX[0.05 * b_TDBW, b_RR]/1000;

ENDIF;

IF b_RS=RS:<bandwidth> and

b_RR=RR:<bandwidth> is not present THEN

Max_BW_UL:= 0.05 * b_TDBW /1000;
Max_BW_DL:= 0.05 * b_TDBW /1000;

ENDIF;

ELSE

Max_BW_UL:= as set by the UE manufacture;

Max_BW_DL:= as set by the UE manufacture;

ENDIF;

ENDIF;

ENDIF;

ENDIF;

Maximum Authorized Traffic Class [MaxTrafficClass] (see NOTE 1, 2 and3)

IF (all media IP flows of media type “audio” or “video” for the session are

unidirectional and have the same direction) THEN

MaxService:= streaming;

ELSE

MaxService:= conversational;

ENDIF;

CASE <media> OF

“audio”: MaxTrafficClass:= MaxService;

“video”: MaxTrafficClass:= MaxService;

“application”: MaxTrafficClass:=conversational;

“data”: MaxTrafficClass:=interactive with priority 3;

“control”: MaxTrafficClass:=interactive with priority 1;

/*new media type*/

OTHERWISE: MaxTrafficClass:=background;

END;

NOTE 1: The Maximum Authorized Traffic Class for a RTCP IP flow is the same as for the corresponding RTP media IP flow.

NOTE 2: When audio or video IP flow(s) are removed from a session, the parameter MaxService shall keep the originally assigned value.

NOTE 3: When audio or video IP flow(s) are added to a session, the UE shall derive the parameter MaxService taking into account the already existing media IP flows within the session.

NOTE 4: The SDP parameters are described in RFC 2327 [11].

NOTE 5: The ‘b=RS:’ and ‘b=RR:’ SDP bandwidth modifiers are defined in RFC 3556 [13].

NOTE 6: TIAS is defined in IETF RFC 3890 [23]. RFC 3890 clause 6.4 provides procedures for converting TIAS to transport-dependant values. This procedure relies on the presence of maxprate (also defined in RFC 3890).

Maximum Authorized Bandwidth DL and UL per PDP Context

Maximum Authorized Bandwidth DL/UL per PDP Context is the sum of all Maximum
Authorized Bandwidth DL/UL for all the IP flows or bidirectional combinations

of IP flows (as derived according to table 6.5.2.1) associated with that PDP

Context ;

IF Maximum Authorized Bandwidth DL/UL per PDP Context > 256 Mbps THEN
Maximum Authorized Bandwidth DL/UL per PDP Context = 256 Mbps

/* See 3GPP TS 23.107 [4] */
END;

Maximum Authorized Traffic Class per PDP Context

Maximum Authorised Traffic Class per PDP Context = MAX [Maximum Authorized QoS Class per IP flow or bidirectional combination of IP flows (as derived according to table 6.5.2.1) among all the IP flows or bidirectional combinations of IP flows associated with that PDP Context] ;

(The MAX function ranks the possible Maximum Authorised Traffic Class values as follows: Conversational > Streaming > Interactive with priority 1 > Interactive with priority 2 > Interactive with priority 3 > Background)