Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 26.114  Word version:  18.5.0

Top   Top   Up   Prev   Next
0…   3…   4…   5…   6…   6.2.3…   6.2.5…   6.2.7…   6.2.10…   7…   7.5…   8…   9…   10…   10.2.1.6…   10.2.2…   10.3…   10.4…   11…   12…   12.3…   12.7…   13a…   16…   16.5…   17…   18…   19…   A…   A.3…   A.4…   A.5…   A.10…   A.14…   A.15…   B…   C…   C.1.3…   C.1.3.5   C.2…   D   E…   E.18…   E.31…   G…   K…   L…   M…   N…   O…   P…   P.3   Q…   R…   S…   T…   U…   V…   W…   X…   Y…   Y.6…   Y.6.4…   Y.6.5…   Y.7… 
W Coverage and Handoff Enhancements using Multimedia Error Robustness (CHEM)  W.1 General  W.2 Adaptation to Packet Losses without application layer redundancy  W.3 Adaptation to Packet Losses using Application Layer Redundancy  W.4 Negotiation of End-to-End and Uplink/Downlink PLR  W.4.1 General  W.4.2 Offering MTSI Client  W.4.3 Answering MTSI Client 
...

 

W (Normative)  Coverage and Handoff Enhancements using Multimedia Error Robustness (CHEM) |R16|  p. 450

W.1  General  p. 450

The robustness of media to packet loss can be affected by the following factors in the MTSI terminal:
  • codec
  • codec mode
  • application layer redundancy
  • packet loss concealment implementation
  • dejitter buffer implementation
The above factors are considered to be part of the codec configuration.
The level of robustness can affect the coverage area of the service in a network. Furthermore, communicating the level of robustness of the media to the network enables the eNB/gNB to use this information to determine a threshold for when the terminal should be handed off to another cell, domain (circuit-switched vs. packet-switched), or radio access technology.
The MTSI terminal may support the coverage and handover enhancements using the multimedia error robustness (CHEM) feature specified in this clause. When CHEM is supported by terminals, the terminals exchange packet loss rate (PLR) information via specified SDP parameters. A PCF/PCRF may use these SDP PLR values to set handover thresholds in their local eNB/gNBs.
In the procedures specified in the rest of this clause, whenever the UE estimates the packet loss rate at the media receiver, the estimate can be measured either pre-dejitter buffer or post-dejitter buffer. When packet loss rate is measured post-dejitter buffer, presentation of partial redundancy information (e.g., in EVS channel aware mode) does not count towards a correctly received packet. Unless specifically configured using the OMA-DM Management Objects, the post-de-jitter buffer PLR estimate shall be used.
The PLR_adapt attribute to be used for this feature is specified using the following ABNF:
Name:
PLR_adapt
Value:
[plr-adapt-value]
Usage Level:
media
Charset Dependent:
no
Syntax: 
plr-adapt-value = %s"ALR" / token
Examples: 
a=PLR_adapt
a=PLR_adapt:ALR
The "ALR" parameter is optional and may be omitted when use of Application-Level Redundancy is not supported.
The semantics of the above attribute and parameter are specified below. Unsupported parameters of the PLR_adapt attribute may be ignored.
The IANA registration information for the PLR_adapt SDP attribute is provided in Annex M.9.
Up

W.2  Adaptation to Packet Losses without application layer redundancy  p. 451

An MTSI terminal supporting the CHEM feature without using application layer redundancy for a media type (e.g., speech or video) shall support the following procedures:
  • when sending an SDP offer, the MTSI client shall include the PLR_adapt attribute in the media description for that media type in the SDP offer
  • when sending an SDP answer, the MTSI client shall include the PLR_adapt attribute in the media description for that media type in the SDP answer regardless of whether the PLR_adapt attribute was received in an SDP offer
  • if, and only if, the MTSI client receives the PLR_adapt attribute in either an SDP offer or SDP answer then,
    • when the MTSI client receiving media detects packet losses higher than tolerable by the current codec mode/configuration in use and a more robust codec mode/configuration is available for the same codec, the MTSI client shall send a CMR request to the media sender to use a more robust codec mode/configuration of the same codec
    • when the MTSI client receiving media detects a packet loss rate low enough to support a codec mode/configuration of the same codec that provides better media quality than the current codec mode/configuration, and switching to the new codec mode/configuration will not cause oscillating between more robust and less robust codec modes/configurations, then the MTSI client should send a CMR request to the media sender to use the codec mode/configuration of the same codec that provides better media quality
Clause X.2.2 provides examples of how the PLR_adapt attribute without application layer redundancy is used in SDP.
Robustness adaptation without application layer redundancy can involve switching to a codec mode/configuration with partial-redundancy (e.g., EVS Channel Aware mode for speech), better error correction, or lower bit rate. In the last scenario this can benefit the resulting media quality if the terminal is near the edge of coverage and the link can better support transport of lower rate codec modes/configurations.
Up

W.3  Adaptation to Packet Losses using Application Layer Redundancy  p. 451

An MTSI terminal supporting the CHEM feature supporting use of application layer redundancy to improve robustness for a media type (e.g., speech or video) shall support the following procedures:
  • when sending an SDP offer, the MTSI client shall include the ALR parameter in the PLR_adapt attribute in the media description for that media type in the SDP offer
  • when sending an SDP answer, the MTSI client shall include the ALR parameter in the PLR attribute in the media description for that media type in the SDP answer only if the ALR parameter in the PLR_adapt attribute was received in an SDP offer
In addition to requesting the media sender to adapt codec mode/configuration as described in clause W.2, the MTSI terminal may request the media sender to use non-zero application layer redundancy to improve robustness to packet loss. clause X.2.3 provides examples of how the PLR_adapt attribute and ALR parameter (i.e., with application layer redundancy) is used in SDP.
When using CMR to request application layer redundancy the following CMR code points shall be used only if the MTSI client receives the ALR parameter in the PLR_adapt attribute in either an SDP offer or SDP answer:
CMR code Application layer redundancy AMR request
9RED 2x4.75
10RED 2x5.15
11RED 2x5.9
12Not used
13Not used
14Not used
CMR code Application layer redundancy AMR-WB request
9RED 2x6.6
10RED 2x8.85
11RED 2x12.65
12Not used
13Not used
14Not used
CMR code Application layer redundancy EVS request
111 0000RED 2x7.2-NB
111 0001RED 2x8-NB
111 0010RED 2x9.6-NB
111 0011RED 2x13.2-NB
111 0100RED 2x7.2-WB
111 0101RED 2x8-WB
111 0110RED 2x9.6-WB
111 0111RED 2x13.2-WB
111 1000RED 2x13.2 CAM WB
111 1001RED 2x13.2 CAM SWB
111 1010RED 2x9.6-SWB
111 1011RED 2x13.2-SWB
111 1100RED 2x6.6-IO
111 1101RED 2x8.85-IO
111 1110RED 2x12.65-IO
To enable use of application layer redundancy the max-red SDP parameter should be selected in the SDP offer and answer to give at least some room for application layer redundancy adaptation and in accordance with clauses 6.2.2.2 and 6.2.2.3. The recommended redundancy offset for application layer redundancy should be 3 frames.
Up

W.4  Negotiation of End-to-End and Uplink/Downlink PLR  p. 452

W.4.1  General  p. 452

In addition to the negotiated codecs and codec modes, the end-to-end quality and robustness to packet loss of a service can depend on the MTSI client implementation of functions such as packet loss concealment (PLC) and de-jitter buffer management (JBM).
A set of end-to-end and link-by-link PLR parameters is specified to provide the following:
  • enable MTSI clients to indicate for each RTP payload type the effective maximum tolerable PLR resulting from the codec, codec mode, packet loss concealment, de-jitter buffer management and other implementation considerations.
  • enable MTSI clients to negotiate with each other and suggest to the PCRF/PCFs how the maximum tolerable end-to-end PLR budget can be distributed across the uplink and downlink in a media transport path. In the absence of any additional negotation or information from the terminals, the PCRF/PCFs may default to distributing the maximum tolerable end-to-end PLR equally (50-50) across the uplink and downlink. The link-specific PLR parameters enable the terminals to suggest to the PCRF/PCFs an unequal distribution, e.g. 60% of the maximum end-to-end PLR allowed on the uplink and 40% allowed on the downlink before the terminals are handed off.
  • indicate to the PCRFs/PCFs what PLR values may be used on the local uplink and downlink to the MTSI clients.
Up

W.4.2  Offering MTSI Client  p. 453

SDP PLR attributes and parameters are defined for use with each payload type. For each RTP payload type, an offering MTSI client supporting the CHEM feature may include the following SDP attribute in its SDP offer:
Name:
MAXimum-e2e-PLR(maximum end-to-end PLR of the media decoder in the MTSI client)
Value:
MAX-e2e-PLR-value
Usage Level:
media
Charset Dependent:
no
Syntax: 
MAX-e2e-PLR-value = payload-type SP maxe2e-PLR [":"maxDL-PLR] ["/"maxUL-PLR]
payload-type = zero-based-integer
maxe2e-PLR = plr-value
maxDL-PLR = plr-value
maxUL-PLR = plr-value
plr-value = integer
; integer taken from RFC 4566
The IANA registration information for the MAXimum-e2e-PLR SDP attribute is provided in Annex M.10.
The maxe2e-PLR represents the maximum end-to-end packet loss rate that can be properly received by the media decoder in the offering MTSI client (including effects of codec mode, packet loss concealment, de-jitter buffering, etc…) indicated by the RTP payload type number payload-type (as used in an "m=" line).
The maxDL-PLR parameter indicates the maximum packet loss rate that the offering MTSI client is able to handle on its local downlink and shall not exceed the maxe2e-PLR value in the SDP offer. If the parameter is not included then the default value from the offering MTSI client is set to ½ of the maxe2e-PLR value included in the SDP offer.
The maxUL-PLR parameter indicates the maximum packet loss rate that the offering MTSI client is able to handle on its local uplink. If the parameter is not included then the default value from the offering MTSI client is set to ½ of maxe2e-PLR value the answering MTSI client will include in its corresponding SDP answer.
If maxe2e-PLR is not included in the SDP answer then its value is set to a recommended value for the codec and mode (e.g., obtain value from Annex Y if available).
The plr-value represents 1/100th of a percent (i.e. 10E-4) of packet loss as an integer.
The following Table W.4.2-1 summarizes the SDP offer parameters.
Parameter Requirement Default Value if not included in SDP offer Limit Limit Condition
maxe2e-PLRIncluded when attribute is supported A recommended value for the codec and mode (e.g., obtain value from Annex X if available)
maxDL-PLROptional½ maxe2e-PLR value in SDP offerNo greater than maxe2e-PLR value in SDP offerAlways
maxUL-PLROptional½ maxe2e-PLR value in SDP answer
Clause X.2.4 provides examples of how the MAXimum-e2e-PLR attribute is used in the SDP offer.
Up

W.4.3  Answering MTSI Client  p. 454

For each RTP payload type, an answering MTSI client supporting the CHEM feature may include the SDP attribute from subclause W.4.2 in its SDP answer with the following semantics of the parameters.
The maxe2e-PLR represents the maximum end-to-end packet loss rate that can be properly received by the media decoder in the answering MTSI client (including effects of codec mode, packet loss concealment, de-jitter buffering, etc…) indicated by the RTP payload type number payload-type (as used in an "m=" line).
If maxe2e-PLR is not included in the SDP offer then its value is set to a recommended value for the codec and mode (e.g., obtain value from Annex Y if available).
The maxDL-PLR parameter included in the SDP answer indicates the maximum packet loss rate that the answering MTSI client is able to handle on its local downlink and shall not exceed the maxe2e-PLR value in the SDP answer.
If the maxUL-PLR value included in the SDP offer is no greater than ½ the maxe2e-PLR value included by the answering MTSI client in the SDP answer, then maxDL-PLR in the SDP answer shall be set to no greater than (maxe2e-PLR value included in the SDP answer minus maxUL-PLR value included in the SDP offer). Otherwise (the maxUL-PLR value included in the SDP offer is greater than ½ the maxe2e-PLR value included in the SDP answer) the maxDL-PLR in the SDP answer should be set to no greater than (maxe2e-PLR value included in the SDP answer minus maxUL-PLR value included in the SDP offer). If the answerer sets the maxDL-PLR in the SDP answer to be greater than (maxe2e-PLR value included in the SDP answer minus maxUL-PLR value included in the SDP offer), the answerer shall not set maxDL-PLR greater than ½ maxe2e-PLR value included in the SDP answer.
If the maxDL-PLR parameter is not included in the SDP answer then the default value from the answering MTSI client is set to ½ of the maxe2e-PLR value included in the SDP answer.
The maxUL-PLR parameter included in the SDP answer indicates the maximum packet loss rate that the answering MTSI client is able to handle on its local uplink and shall not exceed the maxe2e-PLR value in the SDP offer.
If the maxDL-PLR value included in the SDP offer is no greater than ½ the maxe2e-PLR value included by the offering MTSI client in the SDP offer, then maxUL-PLR in the SDP answer shall be set to no greater than (maxe2e-PLR value included in the SDP offer minus maxDL-PLR value included in the SDP offer). Otherwise (if the maxDL-PLR value included in the SDP offer is greater than ½ the maxe2e-PLR value included in the SDP offer), ten maxUL-PLR in the SDP answer should be set to no greater than (maxe2e-PLR value included in the SDP offer minus maxDL-PLR value included in the SDP offer). If the answerer sets the maxUL-PLR in the SDP answer to be greater than (maxe2e-PLR value included in the SDP offer minus maxDL-PLR value included in the SDP offer), the answerer shall not set maxUL-PLR greater than ½ maxe2e-PLR value included in the SDP offer.
If the maxUL-PLR parameter is not included then the default value from the answering MTSI client is set to ½ of the maxe2e-PLR value included in the SDP offer.
The plr-value represents 1/100th of a percent (i.e. 10E-4) of packet loss as an integer.
The Table W.4.3-1 below summarizes the usage of the SDP answer attributes and parameters.
Attribute/ Parameter Requirement Default Value if not included in SDP Answer Limit Condition Limit
maxe2e-PLRIncluded when attribute is supported A recommended value for the codec and mode (e.g., obtain value from Annex X if available)
maxDL-PLROptionalmaxe2e-PLR value included in the SDP answer minus maxUL-PLR value included in the SDP offer.
If maxUL-PLR is not included in the SDP offer then the default value is ½ maxe2e-PLR value in the SDP answer.		maxUL-PLR value included in the SDP offer is no greater than ½ maxe2e-PLR value included in the SDP answermaxe2e-PLR value included in the SDP answer minus maxUL-PLR value included in the SDP offer
maxUL-PLR value included in the SDP offer is greater than ½ maxe2e-PLR value included in the SDP answer½ maxe2e-PLR value in the SDP answer
maxUL-PLROptionalmaxe2e-PLR value included in the SDP offer minus maxDL-PLR value included in the SDP offer.
If maxDL-PLR is not included in the SDP offer then the default value is ½ maxe2e-PLR value in the SDP offer.		maxDL-PLR value included in the SDP offer is no greater than ½ maxe2e-PLR value included in the SDP offermaxe2e-PLR value included in the SDP offer minus maxDL-PLR value included in the SDP offer
maxDL-PLR value included in the SDP offer is greater than ½ maxe2e-PLR value included in the SDP offer½ maxe2e-PLR value in the SDP offer
Clause X.2.4 provides examples of how the MAXimum-e2e-PLR attribute is used in the SDP answer.
Up

Up   Top   ToC