idnits 2.17.1 draft-ietf-avt-uxp-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 138 has weird spacing: '...ressive media...' == Line 162 has weird spacing: '... of the prog...' == Line 169 has weird spacing: '...tes the bitst...' == Line 713 has weird spacing: '...ed into one s...' == Line 878 has weird spacing: '...=10. We reser...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2733 (ref. '1') (Obsoleted by RFC 5109) -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Liebl 3 Internet Draft LNT, Munich Univ. of 4 Technology 5 Document: draft-ietf-avt-uxp-04.txt 6 November 2002 M. Wagner, J. Pandel, 7 W. Weng 8 Expires: May 2003 Siemens AG, Munich 10 An RTP Payload Format for Erasure-Resilient Transmission of 11 Progressive Multimedia Streams 12 Status of this Memo 13 This document is an Internet-Draft and is in full conformance 14 with all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum 19 of six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as "work 22 in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 29 This document specifies an efficient way to ensure erasure- 30 resilient transmission of progressively encoded multimedia 31 sources via RTP using Reed-Solomon (RS) codes together with 32 interleaving. The level of erasure protection can be explicitly 33 adapted to the importance of the respective parts in the source 34 stream, thus allowing a graceful degradation of application 35 quality with increasing packet loss rate on the network. Hence, 36 this type of unequal erasure protection (UXP) schemes is intended 37 to cope with the rapidly varying channel conditions on wireless 38 access links to the Internet backbone. Nevertheless, backward 39 compatibility to currently standardized non-progressive 40 multimedia codecs is ensured, since equal erasure protection 41 (EXP) represents a subset of generic UXP. By applying 42 interleaving and RS codes a payload format is defined, which can 43 be easily integrated into the existing framework for RTP. 44 1. Introduction 46 Due to the increasing popularity of high-quality multimedia 47 applications over the Internet and the high level of public 48 acceptance of existing mobile communication systems, there is a 49 strong demand for a future combination of these two techniques: 50 One possible scenario consists of an integrated communication 51 environment, where users can set up multimedia connections 52 anytime and anywhere via radio access links to the Internet. 54 Liebl,Wagner,Pandel,Weng [Page1] 55 For this reason, several packet-oriented transmission modes have 56 been proposed for next generation wireless standards like EGPRS 57 (Enhanced General Packet Radio Service) or UMTS (Universal Mobile 58 Telecommunications System), which are mostly based on the same 59 principle: Long message blocks, i.e. IP packets, that enter the 60 wireless part of the network are split up into segments of 61 desired length, which can be multiplexed onto link layer packets 62 of fixed size. The latter are then transmitted sequentially over 63 the wireless link, reassembled, and passed on to the next network 64 element. 65 However, compared to the rather benign channel characteristics on 66 today's fixed networks, wireless links suffer from severe fading, 67 noise, and interference conditions in general, thus resulting in 68 a comparably high residual bit error rate after detection and 69 decoding. By use of efficient CRC-mechanisms, these bit errors 70 are usually detected with very high probability, and every 71 corrupted segment, i.e. which contains at least one erroneous 72 bit, is discarded to prevent error propagation through the 73 network. But if only one single segment is missing at the 74 reassemble stage, the upper layer IP packet cannot be 75 reconstructed anymore. The result is a significant increase in 76 packet loss rate at IP level. 77 Since most multimedia applications can only recover from a very 78 limited number of lost message blocks, it is vitally necessary to 79 keep packet loss at IP level within a certain acceptable range 80 depending on the individual quality-of-service requirements. 81 However, due to the delay constraints typically imposed by most 82 audio or video codecs, the use of ARQ-schemes is often prohibited 83 both at link level and at transport level. In addition, 84 retransmission strategies cannot be applied to any broadcast or 85 multicast scenarios. Thus, forward erasure correction strategies 86 have to be considered, which provide a simple means to 87 reconstruct the content of lost packets at the receiver from the 88 redundancy that has been spread out over a certain number of 89 subsequent packets. 90 There already exist some previous studies and proposals regarding 91 erasure-resilient packet transmission[1,8]. Since most of them 92 are based on the assumption that all parts in a message block are 93 equally important to the receiver, i.e. the respective 94 application cannot operate on partly complete blocks, they were 95 optimized with respect to assigning equal erasure protection over 96 the whole message block. However, recent developments both in 97 audio and video coding have introduced the notion of 98 progressively encoded media streams, for which unequal erasure 99 protection strategies seem to be more promising, as it will be 100 explained in more detail below. Although the scheme defined in 101 [1] is in principle capable of supporting some kind of unequal 102 erasure protection, possible implementations seem to be quite 103 complex with respect to the gain in performance. Finally, in [1] 104 it is assumed that consecutive RTP packets can have variable 105 length, which would cause significant segmentation overhead at 106 the link layer of almost all wireless systems. 108 This document defines a payload format for RTP, such that 109 different elements in a progressively encoded multimedia stream 110 can be protected against packet erasures according to their 111 respective quality-of-service requirement. The general principle, 112 including the use of Reed-Solomon codes together with an 113 appropriate interleaving scheme for adding redundancy, follows 114 the ideas already presented in [2], but allows for finer 115 granularity in the structure of the progressive media stream. The 116 proposed scheme is generic in the way that it (1) is independent 117 of the type of media stream, be it audio or video, and (2) can be 118 adapted to varying transmission quality very quickly by use of 119 inband-signaling. 120 2. Conventions used in this Document 122 The following terms are used throughout this document: 123 1.) Segment: denotes a link layer transport unit. 124 2.) Segmentation/Reassembly Process: If the size of the 125 transport units at the link layer is smaller than that at 126 the upper layers, message blocks have to be split up into 127 several parts, i.e. segments, which are then transmitted 128 subsequently over the link. If nothing is lost, the original 129 message block can be restored at the receiving entity 130 (reassembly). 131 3.) Codec: denotes a functional pair consisting of a source 132 encoding unit at the sender and a corresponding source 133 decoding unit at the receiver; usually standardized for 134 different media applications like audio or video. 135 4.) Media stream: A bitstream. which results at the output of an 136 encoder for a specific media type, e.g. H.263, MPEG-4 137 Visual. 138 5.) Progressive media stream: A media stream which can be 139 divided into successive elements. The distinct elements are 140 of different importance to the decoding process and are 141 commonly ordered from highest to least importance, where the 142 latter elements depend on the previous. 143 6.) Progressive source coding: results in a progressive media 144 stream. 145 7.) Reed-Solomon (RS) code: belongs to the class of linear 146 nonbinary block codes, and is uniquely specified by the 147 block length n, the number of parity symbols t, and the 148 symbol alphabet. 149 8.) n: is a variable, which denotes both the block length of a 150 RS codeword, and the number of columns in a TB (see 19). 151 9.) k: is a variable, which denotes the number of information 152 symbols in an RS codeword. 153 10.) t: is a variable, which denotes the number of parity symbols 154 in an RS codeword. 155 11.) Erasure: When a packet is lost during transmission, an 156 erasure is said to have happened. Since the position of the 157 erased packet in a sequence is usually known, a 158 corresponding erasure marker can be set at the receiving 159 entity. 161 12.) Base layer: comprises the first and most important elements 162 of the progressive media stream, without which all 163 subsequent information is useless. 164 13.) Enhancement layer: comprises one or more sets of the less 165 important subsequent elements of the progressive media 166 stream. A specific enhancement layer can be decoded, if and 167 only if the base layer and all previous enhancement layer 168 data (of higher importance) are available. 169 14.) Info stream: denotes the bitstream which has to be 170 protected by the UXP scheme. It usually consists of the 171 media stream (progressively source encoded or not), which is 172 arranged according to a desired syntax (e.g. to achieve an 173 appropriate framing, see Sect. 6.3 ). In any case, it is 174 assumed that every info stream is already octet-aligned 175 according to the standard procedures defined in the context 176 of the used syntax specifications. 177 15.) Info octet: Denotes one element of the info stream. 178 16.) Transmission block (TB): denotes a memory array of L rows 179 and n columns. Each row of a TB represents a RS codeword, 180 whereas each column, together with the respective UXP header 181 (see 36) in front, forms the payload of a single RTP packet. 182 Each TB consists of at least two distinct transmission sub 183 blocks (TSB, see20): The first L_s rows belong to the 184 signaling TSB, whereas the last L_d=(L-L_s) rows belong to 185 one or more data TSB. 186 17.) Transmission sub block (TSB): denotes a memory array of 187 0 277 +-+-+-+-+-+-+-+-+-+ 278 |&|&|&|&|&|&|&|*|*| 279 +-+-+-+-+-+-+-+-+-+ 280 <------------><---> 281 k=n-t t 282 (&:info) (*:parity) 284 Fig. 1: Structure of a systematic RS codeword 286 4. Progressive Source Coding 288 The output of an encoder for a specific media type, e.g. H.263 or 289 MPEG-4 Visual is said to be a media stream. If the media stream 290 consists of several distinct elements, which are of different 291 importance with respect to the quality of the decoding process at 292 the receiver, then the media stream is progressive. The 293 progressive media stream is often organized in separate layers. 294 Hence, there exists at least one layer, often called base layer, 295 without which decoding fails at all, whereas all the other 296 layers, often called enhancement layers, just help to continually 297 improve the quality. Consequently, the different layers are 298 usually contained in the (source-)encoded media stream in 299 decreasing order of importance, i.e. the base layer data is 300 followed by the various enhancement layers. 301 An example can be found in the fine granular scalability modes 302 which have been proposed to various standardization bodies like 303 MPEG, where the resolution of the scaling process in the 304 progressive source encoder is as low as one symbol in the 305 enhancement layer [4]. Another example is given by data 306 partitioning which can be applied to the ITU/MPEG H.26L standard 308 [5], MPEG-4, and H.263++. Also, the existence of I,P, and B 309 frames in streams which comply with standards like MPEG-2 can be 310 interpreted as progressive. 311 From the above definition, it is quite obvious that the most 312 important base layer data must be protected as strongly as 313 possible against packet loss during transmission. However, the 314 protection of the enhancement layers can be continually lowered, 315 since a loss at these stages has only minor consequences for the 316 decoding process. Thus, by using a suitable unequal erasure 317 protection strategy across a progressive media stream, the 318 overhead due to redundancy is reduced. Furthermore, if channel 319 conditions get worse during transmission, only more and more 320 enhancement layers are lost, i.e. a graceful degradation in 321 application quality at the receiver is achieved [6]. 322 Nevertheless, it should be mentioned that the specific structure 323 of the media stream strongly depends on the actual media codec in 324 use and does not always provide suitable mechanisms for transport 325 over data networks, like framing (see also Sect. 6.3 ). In order 326 to keep the description of the unequal erasure protection 327 strategy in Sect. 5 as general as possible, the final bitstream 328 which has to be protected by the proposed UXP scheme will be 329 called "info stream" in the following. Furthermore, it is assumed 330 that every info stream is already octet-aligned according to the 331 standard procedures defined in the context of the used syntax 332 specifications. 334 5. General Structure of UXP Schemes 336 In this section, the principle features of the proposed UXP 337 scheme are described with a special focus on the protection and 338 reconstruction procedure which is applied to the info stream. In 339 addition, the behavior of the sender and receiver is specified as 340 far as it concerns the reconstruction of the info stream. 341 However, the complete UXP payload structure, including the 342 additional UXP header, is described in Sect. 6. 343 The reason for using the term "info stream" as well as the 344 details of the construction are described in Sect. 6.3 . For now, 345 we assume that we have an info stream which has to be protected. 347 Fig. 1 already illustrated the structure of a systematic RS 348 codeword, which shall be represented by a single row with n 349 successive symbols that contain the information and the parity 350 octets. This structure shall now be extended by forming a 351 transmission block (TB) consisting of L codewords of length n 352 octets each, which amounts to a total of L rows and n columns 353 [7]: Each column, together with the respective UXP header in 354 front, shall represent the payload of an RTP packet, i.e. the 355 whole data of a TB is transmitted via a sequence of n RTP packets 356 all carrying a payload of length (L+2) octets (UXP header 357 included). 358 Each TB usually consists of two or more horizontal sub blocks, 359 the so-called transmission sub blocks (TSB), as can be seen in 360 Fig. 2: The first L_s rows always belong to the signaling TSB, 361 which is used to convey the actual redundancy profile in the data 362 part to the receiver (see 6.4.). The following L_d=(L-L_s) rows 363 belong to one or more data TSBs, which contain the interleaved 364 and RS encoded info stream, as will be described below. 366 Transmission Block (TB) 368 /\ +-+-+-+-+-+-+-+-+-+ /\ 369 | | signaling TSB | | L_s octets 370 | +-+-+-+-+-+-+-+-+-+ \/ 371 | | | /\ /\ 372 | + data TSB #1 + | L_d(1) octets | 373 | | | | | 374 | +-+-+-+-+-+-+-+-+-+ \/ | 375 L octets | | | /\ | 376 payload | + data TSB #2 + | L_d(2) octets | 377 per packet | + | | | L_d oct. 378 | +-+-+-+-+-+-+-+-+-+ \/ | 379 | | . | . | 380 | + . + . | 381 | | . | . | 382 | +-+-+-+-+-+-+-+-+-+ /\ | 383 | | data TSB #z | | L_d(z) octets | 384 \/ +-+-+-+-+-+-+-+-+-+ \/ \/ 385 <-----------------> 386 n packets 388 Fig. 2: General structure of a TB 389 Since the UXP procedure is mainly applied to the data TSBs, it 390 will be described next, whereas the content and syntax of the 391 signaling TSB will be defined in section 6.4. 392 For means of simplification, only one single data TSB will be 393 assumed throughout the following explanation of the encoding and 394 decoding procedure. However, an extension to more than one data 395 TSB per TB is straightforward, and will be shown in section 6.5. 396 As depicted in Fig. 3, the rows of a transmission sub block shall 397 be partitioned into T+1 different classes EPC_i, where i=0...T, 398 such that each class contains exactly R_i=|EPC_i| consecutive 399 rows of the matrix, where the R_i have to satisfy the following 400 relationship: 401 R_0+R_1+...+R_T=L_d 403 Data Transmission Sub Block (data TSB) 404 T 405 <-------> 406 /\ +-+-+-+-+-+-+-+-+-+ /\ 407 | |&|&|&|&|&|*|*|*|*| | 408 | +-+-+-+-+-+-+-+-+-+ | R_T=3 409 | |&|&|&|&|&|*|*|*|*| | 410 | +-+-+-+-+-+-+-+-+-+ | 411 L_d octets | |&|&|&|&|&|*|*|*|*| \/ 412 per packet | +-+-+-+-+-+-+-+-+-+ /\ 413 | |%|%|%|%|%|%|*|*|*| | R_(T-1)=1 414 | +-+-+-+-+-+-+-+-+-+ \/ 415 | |$|$|$|$|$|$|$|*|*| . 416 | +-+-+-+-+-+-+-+-+-+ . 417 | |!|!|!|!|!|!|!|!|*| . 418 | +-+-+-+-+-+-+-+-+-+ /\ 419 | |#|#|#|#|#|#|#|#|#| | R_0=1 420 \/ +-+-+-+-+-+-+-+-+-+ \/ 421 <-----------------> 422 n packets 423 &,%,$,!,# : info octets belonging to a certain info stream in 424 decreasing order of importance 425 * : parity octets gained from Reed-Solomon coding 426 Fig. 3: General structure for coding with unequal erasure 427 protection 428 Furthermore, all rows in a particular class EPC_i shall contain 429 exactly the same number of parity octets, which is equal to the 430 index i of the class. For each row in a certain class EPC_i, the 431 same (n,n-i) RS code shall be applied. 432 As can be observed from Fig. 3, class EPC_T contains the largest 433 number of parity octets per row, i.e. offers the highest erasure 434 protection capability in the block. Consequently, the most 435 important element in the info stream must be assigned to class 436 EPC_T, where the value of T should be chosen according to the 437 desired outage threshold of the application given a certain 438 packet erasure rate on the link. 439 All other classes EPC_(T-1)...EPC_0 shall be sequentially filled 440 with the remaining elements of the info stream in decreasing 441 order of importance, where the optimal choice for the size of 442 each class (0 or more rows), i.e. the structure of the redundancy 443 profile, should depend on the quality-of-service requirements for 444 the various (progressively-encoded) layers. 445 The following set of rules contains a compact description of all 446 the operations that must be performed for each transmission 447 block: 448 1.) The total number of columns n of the TB shall be chosen 449 according to the actual delay constraints of the application. 450 2.) Next, the expected number of rows reserved for the signaling 451 TSB has to selected, which limits the data TSB to L_d=(L-L_s) 452 rows. 453 3.) The maximum erasure correction capability T in the data TSB 454 should be chosen according to the desired outage threshold of the 455 application given the actual packet erasure rate on the link. 456 4.) The redundancy profile for the rest of the data TSB should 457 depend on the size and number of the various layers in the info 458 stream, as well as the desired probability of successful decoding 459 for each of them (quality-of-service requirement). 460 5.) Any suitable optimization algorithm may be used for deriving 461 an adequate redundancy profile. However, the result has to 462 satisfy the following constraints: 463 a) All available info octet positions in the data TSB have to be 464 completely filled. If the info stream is too short for a desired 465 profile, media stuffing may be applied to the empty info octet 466 positions at the end of the data TSB by appending a sufficient 467 number of octets (with arbitrary value, e.g. 0x00). The actual 468 number of stuffing symbols per data TSB is then signaled via the 469 respective stuffing indicator (see Sect. 6.4.). However, before 470 resorting to any stuffing, it should be checked whether it is 471 possible to strengthen the protection of certain rows instead, 472 thus improving the overall robustness of the decoding process. 473 b) The info stream should be fully contained within the data TSB 474 (unless cutting it off at a specific point is explicitly allowed 475 by the properties of the used media codec). 476 c) The number of required descriptors and stuffing indicators 477 (see section 6.4.) to signal the profile shall not exceed the 478 space initially reserved for them in the signaling TSB. 480 Constraints a) and b) should be already incorporated in the 481 optimization algorithm. However, if constraint c) is not met, the 482 data TSB has to be reduced by one row in favor of the signaling 483 TSB to accommodate more space for the descriptors and stuffing 484 indicators, i.e. steps 2-5 have to be repeated until a valid 485 redundancy profile has been obtained. 486 6.) For each nonempty class EPC_i, i=T...0, in the data TSB, the 487 following steps have to be performed: 488 a) All rows of this specific class shall be filled from left to 489 right and top to bottom with data octets of the info stream. 490 b) For each row in the class, the required i parity-check octets 491 are computed from the same set of codewords of an (n,n-i) RS 492 code, and filled in the empty positions at the end of each row. 493 Thus, every row in the class constitutes a valid codeword of the 494 chosen RS code. 496 7.) After having filled the whole data TSB with information and 497 parity octets, the redundancy profile is mapped to the signaling 498 TSB as described in section 6.4. 499 8.) Each column of the resulting TB is now read out octet-wise 500 from top to bottom and, together with the respective UXP header 501 (see section 6.2.) in front, is mapped onto the payload section 502 of one and only one RTP packet. 503 9.) The n resulting RTP packets shall be transmitted 504 consecutively to the remote host, starting with the leftmost one. 505 10.) At the corresponding protocol entity at the remote host, the 506 payload (without the UXP header) of all successfully received RTP 507 packets belonging to the same sending TB shall be filled into a 508 similar receiving TB column-wise from top to bottom and left to 509 right. 510 11.) For every erased packet of a received TB, the respective 511 column in the TB shall be filled with a suitable erasure marker. 512 12.) Before any other operations can be performed, the redundancy 513 profile has to be restored from the signaling TSB according to 514 the procedure defined in Sect. 6.4.. If the attempt fails because 515 of too many lost packets, the whole TB shall be discarded and the 516 receiving entity should wait for the next incoming TB. 517 13.) If the attempt to recover the redundancy profile has been 518 successful, a decoding operation shall be performed for each row 519 of the data TSB by applying any suitable algorithm for erasure 520 decoding. 521 14.) For all rows of the data TSB for which the decoding 522 operation has been successful, the reconstructed data octets are 523 read out from left to right and top to bottom, and appended to 524 the reconstructed version of the info stream. 526 One can easily realize that the above rules describe an 527 interleaver, i.e. at the sender a single codeword of a TB is 528 spread out over n successive packets. Thus, each codeword of a 529 transmitted TB experiences the same number of erasures at exactly 530 the same positions. 531 Two important conclusions can be drawn from this: 533 a) Since the same RS code is applied to all rows contained in a 534 specific class, either all of them can be correctly decoded or 535 none. Hence, there exist no partly decodable classes at the 536 receiver. 537 b) If decoding is successful for a certain class EPC_i, all the 538 classes EPC_(i+1)...EPC_T can also be decoded, since they are 539 protected by at least one more parity octet per row. Together 540 with rule 6, it is therefore always ensured, that in case a 541 decodable enhancement layer exists, all other layers it depends 542 on can also be reconstructed! 544 Given the maximum erasure protection value T, the redundancy 545 profile for a data TSB of size (L_d x n) shall be denoted by a 546 so-called erasure protection vector EPV of length (T+1), where 547 EPV:=(R_0,R_1,...,R_(T-1),R_T) 548 From the above definition, it is easy to realize that the trivial 549 cases of no erasure protection and EXP are a subset of UXP: 550 a) no erasure protection at all: all application data is mapped 551 onto 552 class EPC_0, i.e. EPV=(L_d,0,0,...,0). 553 b) EXP: all application data is mapped onto class EPC_T, i.e. 554 EPV=(0,0,...,0,R_T=L_d). 555 Hence, backward compatibility to currently standardized non- 556 progressive multimedia codecs is definitely achieved. 558 6. RTP payload structure 560 This section is organized as follows. First, the specific 561 settings in the RTP header are shown. Next, the RTP payload 562 header for UXP (the so-called UXP header) is specified. After 563 that, the structure of the bitstream which is protected by UXP, 564 the so-called info stream, is discussed. Finally, the in-band 565 signaling of the erasure protection vector is introduced. 566 For every packet, the UXP payload is formed by reading out a 567 column of the TB and prefixing it with the UXP header. Thus, an 568 UXP-compliant RTP packet looks as follows: 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 571 |RTP Header| UXP Header| one column of the TB | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 574 6.1 Specific Settings in the RTP Header 576 The timestamp of each RTP packet is set to the sampling time of 577 the first octet of the progressive media stream in the 578 corresponding TB. If several data TSBs are included in one TB, 579 the sampling time of data TSB #1 is relevant. This results in the 580 TS value being the same for all RTP packets belonging to a 581 specific TB. 583 The payload type is of dynamic type, and obtained through out-of- 584 band signaling similar to [1]. End systems, which cannot 585 recognize a payload type, must discard it. 586 The marker bit is set to 1 in the last packet of a TB; otherwise, 587 its value is 0. 588 All other fields in the RTP header are set to those values 589 proposed for regular multimedia transmission using the RTP-format 590 of the media stream which is protected by UXP, e.g for MPEG-4 591 Visual as specified in RFC 3016. 593 6.2. Structure of the UXP Header 595 The UXP header shall consist of 2 octets, and is shown in Fig. 4: 597 0 1 1 1 1 1 1 598 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 |X| block PT | block length n| 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Fig. 4: Proposed UXP header 604 The fields in the UXP header are defined as follows: 605 - X (bit 0): extension bit, reserved for future enhancements, 606 currently not in use -> default value: 0 607 - block PT (bits 1-7): regular RTP payload type to indicate the 608 media type contained in the info stream 609 - block length n (bits 8-15): indicates total number of RTP 610 - packets 611 resulting from one TB (which equals 612 the number of columns of the TB) 613 The syntax of the info stream which is protected by UXP is 614 specified by the RTP payload type field contained in the UXP 615 header. The details of the info stream are described in Sec. 6.3 616 For example, payload type H.263 means that the info stream 617 conforms to the specifications of the RTP profile for H.263 and 618 does not represent the "raw" H.263 media stream produced by an 619 H.263 encoder. 620 However, UXP can also be applied to the "raw" media stream (in 621 case it is already octet-aligned), if this can be signaled to the 622 receiver via other means, e.g. by use of H.245 or SDP. 623 Based on the RTP sequence number, the marker bit, and the 624 repetition of the block length n in each UXP header, the 625 receiving entity is able to recognize both TB boundaries and the 626 actual position of packets (both received and lost ones) in the 627 TB. 628 6.3 Framing and Timing Mechanism in UXP: The Info Stream 629 As described in Sect. 5, UXP creates its own packetization scheme 630 by interleaving. The regular framing and timing structure of RTP 631 is therefore destroyed. This section describes which kind of 632 problems arise with interleaving and how they can be solved. This 633 finally leads to the specification of the info stream. 634 The timestamp of an RTP packet usually describes the sampling 635 time of the first octet included in the RTP data packet. This is 636 in principle also true for UXP RTP packets. According to the time 637 stamp definition in Sect. 6.1 every packet contains the 638 timestamp of the sampling time of the first octet in the 639 corresponding TB. Therefore, all packets which belong to one TB 640 contain the same timestamp. This can lead to problems since due 641 to the theoretical size limit of a TB (the limit for the number 642 of columns is 256, and the limit for the number of rows is the 643 maximum packet size), it can contain data from different sampling 644 time instances, e.g. several video frames. Then the timing 645 information of the later frames has to be determined from the 646 media stream itself and not from the RTP timestamp. 647 A second problem arising with interleaving is that the framing 648 mechanism of RTP is not supported. Consider a media encoder, 649 which does not create a fully decodable bitstream, e.g. H.26L 650 with the video coding layer (VCL) and network adaptation layer 651 (NAL) concept [9]. In this concept the VCL creates slices which 652 are prepared for transmission over several networks at the NAL. 653 Consequently, in case of RTP transmission, header information 654 which allows to decode the slices is included only in the RTP 655 packets. Thus, to fill an UXP TB with the "raw" media stream from 656 the VCL can lead, even without packet losses, to a non-decodable 657 stream. 658 The framing problem can be solved in two ways: 659 One solution could be to use the RTP payload specification of a 660 given media stream to create a bitstream with an appropriate 661 framing, resulting in the so-called info stream. For example, to 662 create an H.263 info stream, the following steps are necessary: 663 1.) Generate an H.263-compliant media stream, i.e. take a slice 664 or a video frame directly from the H.263 encoder. 665 2.) Apply the H.263 payload specification (e.g. RFC 2429) to 666 create the RTP payload for only one packet. 667 3.) Insert the latter row by row into one data TSB. 668 It is possible to apply the procedure mentioned above several 669 times for different data TSBs (see Sect. 6.5.). Due to the in- 670 band signaling, it is possible to determine the beginning and end 671 of every TSB without parsing the whole TB. This allows a fast 672 decomposition of the TB into the different TSBs. 673 Another solution of the framing problem would be to rely on the 674 framing mechanism of the media stream. This is, for example, 675 possible for media streams which contain start codes. 676 The timing problem can be solved in two ways. 677 One solution is to comply with the RTP payload specification of 678 the media stream. If the specification allows to put into one 679 packet octets which belong to different sampling times, this 680 should also be allowed for a TB. 681 The second solution for the timing problem is to rely on the 682 timing information contained in the media stream itself, if 683 available. 684 Therefore, there are two different modes for framing: 685 1.) RTP payload framing (if an RTP payload specification exists 686 for the media stream), 687 2.) pure media stream framing (if framing is contained in the 688 media stream), 690 and two different modes for timing: 691 1.) timing rules of the RTP payload specification for the media 692 stream, 693 2.) timing information within the media stream. 695 All combinations of timing and framing modes are possible, but 696 framing mode 1 and timing mode 1 represent the default mode of 697 operation for UXP. The use of other timing and framing modes has 698 to be signaled by non RTP means. 699 The info stream is thus defined by the media stream together with 700 framing and timing rules. 701 In the following, some examples will be given: 702 1.) The info stream for MPEG-4 Visual according to RFC 3016 is 703 the pure MPEG-4 compliant media stream, since RFC 3016 704 specifies (in case of video) to take the MPEG-4 compliant 705 video stream as payload. 706 2.) The info stream for H.263+ can be created according to RFC 707 2429 as follows: 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 709 |H.263+ payload| H.263+ compliant stream (possibly changed with| 710 |header | respect to RFC 2429) containing a slice/frame | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 713 This info stream is inserted into one single data TSB. 714 If necessary, for example, if the slices are too short to achieve 715 a reasonable TB size, several info streams can be inserted in one 716 TB by concatenating several data TSBs to a single TB (see Sect. 717 6.5.). 719 6.4. In-band Signaling of the Structure of the Redundancy Profile 721 To enable a dynamic adaptation to varying link conditions, the 722 actual redundancy profile used in the data TSB as well as the 723 beginning and end of a TSB must be signaled to the receiving 724 entity. Since out-of-band signaling either results in excessive 725 additional control traffic, or prevents quick changes of the 726 profile between successive TBs, an in-band signaling procedure is 727 desired. 728 Since without knowledge of the correct redundancy profile, the 729 decoding process cannot be applied to any of the erasure 730 protection classes, the redundancy profile has to be protected at 731 least as strongly as the most important element in the info 732 stream. Therefore, an additional class EPC_P is used in the 733 signaling TSB, where the number of parity symbols is by default 734 set to the following value: 735 P=ceil(n/2) 736 Hence, up to 50% of the RTP packets can be lost, before the 737 redundancy profile cannot be recovered anymore. This seems to be 738 a reasonable value for the lowest point of operation over a lossy 739 link. Alternatively, P may be explicitly signaled during session 740 setup by means of SDP or H.245 protocol. 741 Consequently, since all other classes must have equal or less 742 erasure protection capability, the maximum allowable value for 743 class EPC_T in the data TSB is now limited to T<=P. 744 The signaling of the erasure protection vector is accomplished by 745 means of descriptors. In the following we describe an efficient 746 encoding scheme for the descriptors. 747 For each class EPC_i with R_i>0, there is a descriptor DP_i 748 providing information about the size of class EPC_i (i.e. the 749 value of R_i) and establishing a relationship between the erasure 750 protection of class EPC_i and that of the class EPC_(i+j), where 751 j>0 and j is the smallest value for which R_(i+j)>0 is true. A 752 descriptor DP_i is mapped onto one octet, which is sub-divided 753 into two half-octets (i.e. the higher and the lower four bits). 754 The first half-octet is of type unsigned and contains the 4-bit 755 representation of the decimal value R_i. The second half-octet is 756 of type signed and contains the difference in erasure protection 757 between class EPC_i and class EPC_(i+j), i.e. the signed 4-bit 758 representation of the decimal value (-j) (where the MSB denotes 759 the sign, and the lower three bits the absolute value). Note that 760 the erasure protection P of class EPC_p is fixed, whereas the 761 size R_P may vary. 762 Thus, the data to be filled into class EPC_P shall consist of a 763 sequence of descriptors separated by stuffing indicators (see 764 below), where the number of descriptors is primarily given by the 765 number of protection classes EPC_i, 0<=i<=T, in the data TSB with 766 R_i>0. 767 Without a-priori knowledge, the initial value for the size of the 768 signaling TSB, R_P, should be set to one (row). When the number 769 of necessary descriptors and stuffing indicators exceeds the (n- 770 P) information positions, one or more additional rows have to be 771 reserved. This is usually done by increasing the value for L_s to 772 R_P>1, i.e. the data TSB is reduced to (L-R_P) rows. Hence, in 773 order to indicate the actual size of the signaling TSB, an 774 additional descriptor is inserted at the very beginning, which 775 takes on the value 0xq0, where q denotes the (octal) four bit 776 representation of the decimal value R_P. 778 Furthermore, the end of each data TSB is signaled by the 779 otherwise unused descriptor value 0x00, followed by exactly one 780 stuffing indicator (SI). The latter is mapped onto an octet, 781 which is of type unsigned and contains the 8-bit representation 782 of the decimal value of the number of media stuffing symbols used 783 at the end of the respective data TSB. 784 The (extended) sequence of descriptors and stuffing indicators is 785 then mapped to the octet positions in the R_P rows of the 786 signaling TSB from left to right and top to bottom. Each row is 787 then encoded with the same (n,n-P) RS code. 788 If the number of descriptors and stuffing indicators is less than 789 the available octet positions, however, empty positions in class 790 EPC_P may be filled up with the otherwise unused descriptor 0x00. 791 At the receiving entity, the sequence of descriptors shall be 792 recovered by performing erasure decoding on the first row of the 793 TB (which definitely belongs to the signaling TSB) using the same 794 algorithm as later for the data TSB. If successful, the very 795 first descriptor now indicates the number of rows of the 796 signaling TSB, and the next (R_P-1) rows are decoded to 797 reconstruct the redundancy profile for the data TSB(s), together 798 with the number of media stuffing symbols denoted by the 799 respective SI(s). 800 The complete structure of the TB is now depicted in Fig. 5. 802 Transmission Block (TB) 803 P 804 <---------> 805 /\ +-+-+-+-+-+-+-+-+-+ /\ 806 | |?|?|?|?|*|*|*|*|*| | R_P=1 807 | +-+-+-+-+-+-+-+-+-+ \/ 808 | |&|&|&|&|&|*|*|*|*| /\ 809 | +-+-+-+-+-+-+-+-+-+ | R_T=3 810 | |&|&|&|&|&|*|*|*|*| | 811 | +-+-+-+-+-+-+-+-+-+ | 812 L octets | |&|&|&|&|&|*|*|*|*| \/ 813 payload | +-+-+-+-+-+-+-+-+-+ /\ 814 per packet | |%|%|%|%|%|%|*|*|*| | R_(T-1)=1 815 | +-+-+-+-+-+-+-+-+-+ \/ 816 | |$|$|$|$|$|$|$|*|*| . 817 | +-+-+-+-+-+-+-+-+-+ . 818 | |!|!|!|!|!|!|!|!|*| . 819 | +-+-+-+-+-+-+-+-+-+ /\ 820 | |#|#|#|#|#|#|#|#|#| | R_0=1 821 \/ +-+-+-+-+-+-+-+-+-+ \/ 822 <-----------------> 823 n packets 824 ? : descriptors and stuffing indicators for in-band 825 signaling of the redundancy profile 827 &,%,$,!,# : info octets belonging to a certain element of the 828 info stream in decreasing order of importance 830 * : parity octets gained from Reed-Solomon coding 832 Fig. 5: General structure for UXP with in-band signaling of the 833 redundancy profile 834 The following simple example is meant to illustrate the idea 835 behind using descriptors: Let an erasure protection vector of 836 length T+1=7 be given as follows: 837 EPV=(R_0,R_1,...,R_5,R_6)=(7,0,2,2,0,3,10) 838 Hence, the length L of the TB (including one row for the 839 signaling TSB) is equal to 7+2+2+3+10+1=25 (rows/octets). If the 840 width is assumed to be equal to 20 (columns/packets), then the 841 erasure protection of the descriptors is P=10. 842 The corresponding sequence of descriptors can be written as 843 DP=(DP_6,DP_5,DP_3,DP_2,DP_0)=(0xAC,0x39,0x2A,0x29,0x7A), 844 where the values of the descriptors are given in hexadecimal 845 notation. Next, the descriptor indicating the length of the 846 signaling TSB has to be inserted, the end of the data TSB has to 847 be marked by 0x00, and the SI has to be appended. If the number 848 of media stuffing symbols is assumed to be 3, the 10 info octets 849 in the signaling TSB take on the following values (descriptor 850 stuffing included): 851 (0x10,0xAC,0x39,0x2A,0x29,0x7A,0x00,0x03,0x00,0x00) 852 6.5. Optional Concatenation of Transmission Sub Blocks 854 The following procedure may be applied if a single info stream 855 would be too short to achieve an efficient mapping to a 856 transmission block with respect to the fixed payload length L and 857 the desired number of packets n. For example, intra-coded video 858 frames (I-frames) are usually much larger than the following 859 predicted ones (P-frames). In this case, a certain number z of 860 successive small info streams should be each mapped to a 861 transmission sub block with length L_d(y) and width n, such that 862 L_d(1)+L_d(2)+...+L_d(z)=L_d. 863 The resulting transmission sub blocks can then be easily 864 concatenated to form a TB of size L x n having one common 865 signaling TSB (see Fig. 2): Since the second half-octet of the 866 descriptors is of type signed (cf. Sect. 6.4.), we are able to 867 signal both decreasing and increasing erasure protection 868 profiles. 869 Again, we will give a simple example to illustrate this idea: Let 870 the erasure protection vectors for two concatenated data TSBs be 871 given as follows: 873 EPV1=(R1_0,R1_1,...,R1_5,R1_6)=(0,0,2,2,0,3,10), 874 EPV2=(R2_0,R2_1,...,R2_5,R2_6)=(0,0,2,2,0,3,10). 875 Hence, two single identical data TSBs will be concatenated to 876 form a TB of length L=2*(2+2+3+10)+2=36 (rows/octets). If the 877 width is again assumed to be equal to 20 (columns/packets), then 878 the erasure protection of the descriptors is P=10. We reserve a 879 total of two rows for the signaling TSB. The corresponding 880 sequence of descriptors can now be written as 881 DP=(0xAC,0x39,0x2A,0x29,0xA4,0x39,0x2A,0x29), where the values of 882 the descriptors are given in hexadecimal notation. The values of 883 the first four descriptors are taken from the descriptor of EPV1 884 as described in Sect. 6.4. (without the SI). The last four 885 descriptors are taken from the descriptor of EPV2 (without SI) 886 with one exception. The fifth descriptor of DP (i.e. 0xA4) is 887 created as follows: The first half-octed is created according to 888 Sect. 6.4. However, the second half-octed describes no longer the 889 difference between R_P and R2_6. It rather describes the 890 difference between R1_2 and R2_6, i.e. R1_2-R2_6, which can be a 891 positive or negative number. If the number of media stuffing 892 symbols is assumed to be 3 for each data TSB, the 20 info octet 893 positions in the signaling TSB are filled with the following 894 values (descriptor stuffing included): 895 (0x20,0xAC,0x39,0x2A,0x29,0x00,0x03,0xA4,0x39,0x2A,0x29,0x00,0x03 896 , 897 0x00,0x00,0x00,0x00,0x00,0x00,0x00) 898 Therefore from the example above, the following general rule MUST 899 be used to create the resulting descriptors for concatenated data 900 TSB #u and data TSB #v, where v=u+1: 901 Let EPVu=(Au_0,Au_1,...) and EPVv=(Av_0, Av_1,...) be the 902 corresponding erasure protection vectors and DPu and DPv the 903 corresponding descriptors created according to Sect. 6.4. (with 904 stuffing). Let w be the smallest index for which Au_w >0. Let x 905 be the largest index for which Av_x >0. The resulting descriptor 906 can be created by concatenation of DPu and DPv where the first 907 descriptor of DPv should be changed as follows: 908 The second half byte is defined by Au_w-Av_x. 910 7. Security Considerations 911 The payload of the RTP-packets consists of an interleaved media 912 and parity stream. Therefore, it is reasonable to encrypt the 913 resulting stream with one key rather than using different keys 914 for media and parity data. It should also be noted that 915 encryption of the media data without encryption of the parity 916 data could enable known-plaintext attacks. 917 The overall proportion between parity octets and info octets 918 should be chosen carefully if the packet loss is due to network 919 congestion. If the proportion of parity octets per TB is 920 increased in this case, it could lead to increasing network 921 congestion. Therefore, the proportion between parity octets and 922 info octets per TB MUST NOT be increased as packet loss increases 923 due to network congestion. 924 The overall ratio between parity and info octets MUST NOT be 925 higher than 1:1, i.e. the absolute bitrate spent for redundancy 926 must not be larger than the bitrate required for transmission of 927 multimedia data itself. 929 8. Application Statement 930 There are currently two different schemes proposed for unequal 931 error protection in the IETF-AVT: Unequal Level Protection (ULP) 932 and Unequal Erasure Protection (UXP). 933 Although both methods seem to address the same problem, the 934 proposed solutions differ in many respects. This section tries to 935 describe possible application scenarios and to show the strengths 936 and weaknesses of both approaches. 937 The main difference between both approaches is that while ULP 938 preserves the structure of the packets which have to be protected 939 and provides the redundancy in extra packets, UXP interleaves the 940 info stream which has to be protected, inserts the redundancy 941 information, and thus creates a totally new packet structure. 942 Another difference concerns multicast compatibility: It cannot be 943 assumed that all future terminals will be able to apply UXP/ULP. 944 Therefore, backward compatibility could be an issue in some 945 cases. Since ULP does not change the original packet structure, 946 but only adds some extra packets, it is possible for terminals 947 which do not 948 support ULP to discard the extra packets. In case of UXP, 949 however, two separate streams with and without erasure protection 950 have to be sent, which increases the overall data rate. 951 Next, both approaches offer different mechanisms to adjust packet 952 sizes, if necessary: UXP allows to adjust the packet sizes 953 arbitrarily. This is an advantage in case the loss probability is 954 dependent on the packet length, which happens, for example, if 955 the end-to-end connection contains wireless links. In this case 956 proper adjustment of the packet size is one essential network 957 adaptation technique. In addition, if a preencoded stream is sent 958 over the network, the packet size can be adjusted independently 959 of slice structures. 960 Since ULP does not change the existing packetization scheme, this 961 flexibility does not exist. 962 The ability of UXP to adjust the packet size arbitrarily can be 963 especially exploited in a streaming scenario, if a delay of 964 several hundred milliseconds is acceptable. It is then possible 965 to fill several video frames into a single TB of desired size, 966 e.g. a group of pictures consisting of I-frame, P-frames and B- 967 frames. The redundancy scheme can thus be selected in such a way 968 as to guarantee the following property: In case of packet loss, 969 the P-frames are only recoverable if the I-frame on which the 970 decoding of P-frames depends is recoverable. The same is true for 971 B-frames, which can only be decoded if the respective P-frames 972 are recoverable. This prevents situations in which, for example, 973 the B-frames have been received correctly, but the P-frames have 974 been lost, i.e. assures a gradual decrease in application quality 975 also on the frame level. Of course, a similar encoding is 976 possible with ULP. But in this case one might have to send 977 several frames within one packet which leads to large packet 978 sizes. 979 Furthermore, decoding delay is also a crucial issue in 980 communications. Again, both approaches have different delay 981 properties: UXP introduces a decoding delay because a reasonable 982 amount of correctly received packets are necessary to start 983 decoding of a TB. The delay in general depends on the dimensions 984 of the interleaver. This should be considered for any system 985 design which includes UXP. 986 With ULP, every correctly received media packet can be decoded 987 right away. However, a significant delay is introduced, if 988 packets are corrupted, because in this case one has to wait for 989 several redundancy packets. Thus, the delay is in general 990 dependent on the actual ULP-FEC-packet scheme and cannot be 991 considered in advance during the system design phase. 992 Finally, we want to point out that UXP uses RS codes which are 993 known 994 to be the most efficient type of block codes in terms of erasure 995 correction capability. 997 9. Intellectual Property Considerations 998 Siemens AG has filed patent applications that might possibly have 999 technical relations to this contribution. 1000 On IPR related issues, Siemens AG refers to the Siemens Statement 1001 on Patent Licensing, see http://www.ietf.org/ietf/IPR/SIEMENS- 1002 General. 1004 10. References 1005 [1] J. Rosenberg and H. Schulzrinne, "An RTP Payload Format for 1006 Generic Forward Error Correction", Request for Comments 2733, 1007 Internet Engineering Task Force, Dec. 1999. 1008 [2] A. Albanese, J. Bloemer, J. Edmonds, M. Luby, and M. Sudan, 1009 "Priority encoding transmission", IEEE Trans. Inform. Theory, 1010 vol. 42, no. 6, pp. 1737-1744, Nov. 1996. 1011 [3] Shu Lin and Daniel J. Costello, Error Control Coding: 1012 Fundamentals and Applications, Prentice-Hall, Inc., Englewood 1013 Cliffs, N.J., 1983. 1014 [4] W. Li: "Streaming video profile in MPEG-4", IEEE Trans. on 1015 Circuits and Systems for Video Technology, Vol. 11, no. 3, 301- 1016 317, March 2001. 1017 [5] G. Blaettermann, G. Heising, and D. Marpe: "A Quality 1018 Scalable Mode for H.26L", ITU-T SG16, Q.15, Q15-J24, Osaka, May 1019 2000. 1021 [6] F. Burkert, T. Stockhammer, and J. Pandel, "Progressive A/V 1022 coding for lossy packet networks - a principle approach", Tech. 1023 Rep., ITU-T SG16, Q.15, Q15-I36, Red Bank, N.J., Oct. 1999. 1024 [7] Guenther Liebl, "Modeling, theoretical analysis, and coding 1025 for wireless packet erasure channels", Diploma Thesis, Inst. for 1026 Communications Engineering, Munich University of Technology, 1027 1999. 1028 [8] U. Horn, K. Stuhlmuller, M. Link, and B. Girod, "Robust 1029 Internet video transmission based on scalable coding and unequal 1030 error protection", Image Com., vol. 15, no. 1-2, pp. 77-94, Sep. 1031 1999. 1032 [9] S. Wenger, "H.26L over IP: The IP-Network Adaptation Layer", 1033 Packet Video 2002, Pittsburgh, Pennsylvania, USA, April 24- 1034 26,2002. 1035 11. Acknowledgments 1036 Many thanks to Philippe Gentric, Stephen Casner, and Hermann 1037 Hellwagner for helpful comments and improvements. The authors 1038 would like to thank Thomas Stockhammer who came up with the 1039 original idea of UXP. Also, the help of Gero Baese, Frank 1040 Burkert, and Minh Ha Nguyen for the development of UXP is well 1041 acknowledged. 1043 12. Author's Addresses 1044 Guenther Liebl 1045 Institute for Communications Engineering (LNT) 1046 Munich University of Technology 1047 D-80290 Munich 1048 Germany 1049 Email: {liebl}@lnt.e-technik.tu-muenchen.de 1051 Marcel Wagner, Juergen Pandel, Wenrong Weng 1052 Siemens AG - Corporate Technology CT IC 2 1053 D-81730 Munich 1054 Germany 1055 Email: 1056 {marcel.wagner,juergen.pandel,wenrong.weng}@mchp.siemens.de 1058 Full Copyright Statement 1059 "Copyright (C) The Internet Society (date). All Rights Reserved. 1060 This document and translations of it may be copied and furnished 1061 to others, and derivative works that comment on or otherwise 1062 explain it or assist in its implementation may be prepared, 1063 copied, published and distributed, in whole or in part, without 1064 restriction of any kind, provided that the above copyright notice 1065 and this paragraph are included on all such copies and derivative 1066 works. However, this document itself may not be modified in any 1067 way, such as by removing the copyright notice or references to 1068 the Internet Society or other Internet organizations, except as 1069 needed for the purpose of developing Internet standards in which 1070 case the procedures for copyrights defined in the Internet 1071 Standards process must be followed, or as required to translate 1072 it into languages other than English. 1073 The limited permissions granted above are perpetual and will not 1074 be revoked by the Internet Society or its successors or assigns. 1075 This document and the information contained herein is provided on 1076 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 1077 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES; EXPRESS OR 1078 IMPLIED; INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1079 OF INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1080 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1081 PURPOSE.