Emulation of ISDN Multi-channel Circuit-mode Bearer Services in Next Generation Networks by TDM Pseudo-Wires

Depósito de Investigación de la Universidad de Sevilla https://idus.us.es/ This is an Accepted Manuscript of an conference paper published by IEEE: J. Muñoz-Calle, A. J. Sierra and J. M. Vozmediano, "Emulation of ISDN multichannel circuit-mode bearer services in next generation networks by TDM pseudo-wires," 2012 Next Generation Networks and Services (NGNS), Faro, Portugal, 2012, pp. 149-156, doi: 10.1109/NGNS.2012.6656094 “© 2012 IEEE. Personal use of this material is permitted. Permission from IEEE must be obtained for all other uses, in any current or future media, including reprinting/republishing this material for advertising or promotional purposes, creating new collective works, for resale or redistribution to servers or lists, or reuse of any copyrighted component of this work in other works.” Emulation of ISDN Multi-channel Circuit-mode Bearer Services in Next Generation Networks by TDM Pseudo-Wires Javier Muñoz-Calle, Antonio J. Sierra, Juan M. Vozmediano Departamento de Ingeniería Telemática Universidad de Sevilla C/ Camino de los descubrimientos s/n. Sevilla {javi,antonio,jvt}@trajano.us.es Abstract— The specifications of the Next Generation Networks 1 (NGN) agree on the need for migration mechanisms that enable 2 the replacement of traditional networks, highlighting the ISDN 3 networks. This requirement has a notable impact on NGN in 4 terms of network design. Recent solutions proposed by ITU-T 5 and ETSI for ISDN migration only include support for a subset 6 of current ISDN services, not covering in detail the multi-channel 7 circuit-mode bearer services. This paper examines the use of 8 TDM pseudowires for NGN emulation of ISDN multi-channel 9 calls between ISDN terminals, proposing new payload types. 10 Keywords-Multi-channel service, ISDN bearer, NGN, Pseudo11 wire 12 I. INTRODUCTION 13 The Next Generation Network Project aims to create a 14 unique packet-switched network that integrates any existing or 15 future service [1]. The progress of the NGN project is being 16 driven by both economic and standardization reasons [2]. Thus, 17 operators will benefit from an efficient and seamless 18 integration between current user equipment and networks [3; 19 4], most notably Integrated Services Digital Network (ISDN) 20 networks. 21 ISDN has been the last step in the evolution of the public 22 switched telephone network. It was originally designed to 23 support any type of voice or data service over a full-digital 24 network. The broad range of services offered by ISDN is 25 supported over three types of bearer services, namely the 26 circuit-mode, frame-mode and packet-mode. These services are 27 also classified into single and multi-channel as used on each 28 call one or more B channels, respectively. The rigidity of the 29 underlying channelized bit-rate structure and the lack of 30 flexibility in building new, complex services have finally made 31 ISDN unsuitable for the fast development and provision of rich 32 multimedia services which conversely, have been rapidly 33 developed on the Internet. 34 For backwards compatibility, the NGN must support 35 potentially every ISDN bearer service (ITU-T I.230 series) 36 with the same o higher QoS [5; 6]. Consequently, both the 37 ITU-T and the ETSI have defined standardized mechanisms for 38 the transparent integration of ISDN terminals (ISDN TEs). 39 This backwards compatibility is also required within the 40 European normative [7]. The European directive on Universal 41 Service [8] states that, at least one operator Electronic 42 Communication Network (ECN) must ensure access to Publicly 43 Available Telephone Service (PATS) at fixed locations such as 44 ISDN, PSTN, X.25, ... Furthermore, the specification [9] 45 highlights the urgent need to articulate the necessary 46 specifications that would meet those obligations. These 47 regulations applied to ISDN require that the operator's network 48 allows access for native ISDN terminals. 49 The solutions offered by ITU-T and ETSI to encapsulate 50 ISDN signalling and user flows across the NGN network use 51 transport or application-layer protocols. The proposal done by 52 ITU-T [5; 10] is limited to ISDN circuit-mode bearer services 53 whereas the ETSI proposal [11] adds partial support for frame 54 and packet-mode services. For ISDN multi-channel circuit55 mode bearer services, the ITU-T [6] recognizes that there are 56 still large residual amount of ISDN user equipment that use 57 these services, and therefore they must be supported. But, 58 concerning these services, NGN specifications made only two 59 comments, related to their transport on the NGN, as described 60 below. On the one hand, the ITU-T [6] indicates that the 61 transport of the "N" channels of the service must be performed 62 on a single IP flow, to ensure equal conditions for all 63 transmission channels. On the other hand, purely facultative, 64 ITU-T Recommendations [5; 12; 13] propose to carry these 65 services by using ITU-T TDMoIP interworking [13; 14], 66 equivalent to UDP/IP-based TDM pseudo-wires (TDMPW) 67 [15], what satisfies indicated by the Recommendation [6]. 68 About these indications, we must make the following 69 assessments. In the first place, ITU-T TDMoIP interworking is 70 only defined for UDP/IP, while IETF defines TDMPWs for 71 different tunneling mechanisms apart from UDP-IP, such as 72 MPLS, L2TPv3/IP or Ethernet. So, TDMPWs are preferred. 73 In the second place, the ITU-T only mentions the use of 74 TDMoIP interworking (or TDMPWs), but it is not detailed 75 how to apply them. It is necessary to determine if each 76 TDMPW must carry one or several ISDN calls, or the 77 TDMPW type and payload more appropriate. After analysis, 78 we conclude that as they are standardized, none of the 79 TDMPWs fits the emulation of these multi-channel calls. It 80 will be necessary to propose new types of TDMPW payload. 81 This paper proposes to transport ISDN multi-channel 82 circuit-mode bearer services [17-21] between two ISDN 83 terminals by AAL2 TDMPWs (UDP/IP-based or any other 84 packet switched network) with new payload types we define. 85 The rest of this paper is organized as follows. Next section 86 provides a shallow introduction to ISDN multi-channels calls, 87 ISDN emulation on NGN and TDM pseudo-wires. Section III 88 addresses an analysis of the TDMPWs to transport ISDN 89 multi-channel services on the NGN. Finally, Section IV 90 concludes the paper. 91 II. BACKGROUND 92 A. ISDN Multi-channel Circuit-mode Bearer Services 93 ISDN transmission capacity is offered in a combination of 94 several types of fixed-rate channels, one of which (B channel) 95 was specially tailored to carry toll-quality digitalized voice. 96 The ISDN also pioneered the concept of splitting user and 97 control data flows, the latter were enclosed in D channels. The 98 broad range of services offered by ISDN is supported over 99 three types of bearer services, namely the circuit-mode, frame100 mode and packet-mode. These services are also classified into 101 single and multi-channel as used on each call one or more B 102 channels, respectively. 103 Multi-channel ISDN services ("N" B-channels) require UDI 104 (Unrestricted Digital Information) transport [22] and TSSI 105 (Time Slot Sequence Integrity) structure. In particular, the 106 service 2x64 [17] also requires RDTD (Restricted Differential 107 Time Delay) structure. 108 With UDI transport, terminals can exchange any 109 information, negotiated between them, transparently to the 110 network. RDTD service structure means that if two samples are 111 transmitted at the same time (for any two different channels of 112 service), they must reach the destination with a delay of no 113 upper than "50 ms". TSSI structure means that information 114 must be delivered to the destination in the same order between 115 channels when it was sent. 116 B. ISDN emulation in NGN 117 The ITU-T aims to define a world-wide network 118 infrastructure capable of supporting current and future 119 telecommunication services and network technology. The Next 120 Generation Network model, as standardized by the ITU-T in 121 [23], is the last step on that direction. Both the ITU-T and the 122 ETSI have cooperated to develop the NGN architecture. 123 The NGN functional architecture exhibits a transport 124 stratum and a service stratum. The transport stratum provides 125 IP connectivity, hiding the core and access networks’ 126 technologies. It also aggregates user traffic to be transported 127 over the core network, controls, allocates network resources 128 and provides support for network control and management. 129 The service stratum resides above the IP layer, containing 130 users’ profiles, auxiliary applications and as many service131 supporting control-functions as needed. These control functions 132 operate the transport stratum to provide the desired service. 133 Among the service-control functional components identified in 134 the Service stratum are: the IPTV, which provides IP-based 135 television services; the IMS, which provides SIP-controlled 136 multimedia services; and the PTSN/ISDN Emulation 137 Subsystem (PES). 138 There are two alternative architectures for implementing 139 PES, depending on Access Gateways (AGW) be implemented 140 either monolithically (Voice Gateway, A-VGW) or in a 141 decomposed way (Gateway controller MGC and Media 142 Gateway A-MGW) [10], as shown in Figure 1. The first one is 143 based on a so-called call server (CS-PES) where a Media 144 Gateway Controller (MGC) terminates the ISDN signaling and 145 accordingly controls the Access Media Gateway via MeGaCo 146 [24]. In the second choice, the ISDN signaling is terminated at 147 an Access Voice Gateway which uses SIP signaling to 148 communicate with the IMS’s Call Session Control Functions 149 (CSC-FE). 150 151 C. TDM Pseudo-wires 152 IETF defines pseudo-wires (PWs) [16; 25] as a mechanism 153 to allow the emulation of telecommunications services over a 154 Packet Switched Network (PSN) through virtual connections 155 that, from the user's point of view, provides the same service 156 than the original circuit or link. The emulation preserves the 157 essential attributes of the original services such as voice 158 quality, delay, timing and signaling features. Each pseudo-wire 159 is established between an ingress and an egress PE (Provider 160 Edge). 161 Depending on the tunneling mechanism, different types of 162 pseudo-wires are defined: UDP/IP, L2TPv3/IP, MPLS, 163 Ethernet. As a matter of fact, the UDP/IP PWs are equivalent to 164 TDM over IP interworking defined by ITU-T [13]. This type of 165 pseudo-wire, albeit simple, lacks of a control plane, able to 166 negotiate connection parameters at connection-setup time, such 167 as the payload type, jitter buffer's size, the timing recovery 168 mechanism or the traffic type. So, other types of pseudo-wires 169 Figure 1. Simplified NGN architecture may be more suitable for a practical implementation. In 170 general, the choice of the type of PWs is dependent on the 171 operator's network. 172 TDM pseudo-wires (TDMPWs) [15] can emulate the main 173 features of a time-division multiplexed link: frame and multi174 frame synchronization (when needed), timing recovery at the 175 output end, complying with the path MTU, and simultaneous 176 transport of several TDM flows. Depending on the format of 177 the payload, jointly defined by IETF and ITU-T, there are two 178 types of TDMPWs (Figure 2). 179 180 The transparent or structure-independent TDMPWs take the 181 TDM signal as a continuous stream of bits (without interpreting 182 any frame structure that it may have) transporting it 183 completely, including overhead and data/signalling channels 184 for channelized circuits, so that each TDMPW emulates a full 185 TDM circuit. Two TDMPWs of this type are defined: SAToP 186 [13; 26] and transparent AAL.1 TDMoIP [14; 27]. 187 In the structure-aware or SDT (Structured Data Transport) 188 TDMPWs, the ingress PE must understand and interpret the 189 frame structure of the TDM signal, and can read/manipulate 190 TDM overheads and signalling, which ensures the alignment 191 and integrity of the TDM frame structure and provides more 192 robustness to PSNs with higher packet loss rate. These 193 TDMPWs are classified in two subtypes: 194  Static: they provide CES (Circuit Emulation Service) 195 [28]. Two TDMPWs of this type are defined: 196 CESoPSN [13; 29] and AAL1 TDMoIP with SDT [14; 197 27]. 198  Dynamic: they provide LES (Loop Emulation Service) 199 [30]. IETF only defines a TDMPW of this type, 200 referred as AAL2 TDMoIP [14; 27; 31]. TDM 201 channels may belong to different trunks, identifying 202 each pair "interface, channel" through a CID (Channel 203 Identifier). The TDMPW payload is filled by an 204 integer number of AAL2 (ATM Adaptation Layer) 205 minicells [32]. Each AAL2 minicell is filled with a 206 SSCS PDU, built it from the bytes of the TDM channel 207 identified by the CID assigned to that minicell. 208 The control plane of the AAL1/2 TDMoIP types has 209 only been fully standardized for MPLS TDMPWs [31]. 210 III. TRANSPORT OF MULTI-CHANNEL CALLS BETWEEN ISDN 211 TERMINALS BY USING TDMPWS 212 ISDN multi-channel services can be transported on the 213 NGN through TDMoIP interworking flows (as proposed by 214 ITU-T) or, preferably, by TDMPWs, defined for several 215 tunnelling mechanisms. This proposal only applies to calls 216 between two ISDN terminals, establishing the TDMPW among 217 their respective AGWs (Figure 3). 218 219 A. Multiplexing of calls on each TDMPW 220 In all standard ISDN multi-channel bearer services (ITU-T 221 I.230 series), various B channels involved in one call, belong to 222 the same ISDN UNI (User-Network Interface). Consequently, 223 the "N" B-channels of a multi-channel call must be transported 224 on the same TDMPW, satisfying indicated by the 225 Recommendation [6] (among different TDMPWs there is no 226 sequencing or timing relationship). 227 Instead of using an independent TDMPW each ISDN call, 228 it is more efficient to concentrate several calls (single or multi229 channel, and permanent or switched) on the same TDMPW 230 (Figure 4). Calls are multiplexed on the same TDMPW until 231 complete its capacity, in which case another TDMPW be 232 established. This provides a lower overhead in the data plane 233 (the same IP and CW Control Word headers for multiple calls) 234 and a lower number of messages in the control plane (fewer 235 TDMPWs). 236 237 Although TDMPWs are designed to be established prior to 238 the establishment of calls (management plane), they can be 239 established in call time (control plane) if it offers a significant 240 advantage. For switched ISDN calls, the establishment of 241 TDMPWs before calls requires the establishment of a mesh of 242 TDMPWs between all the AGWs of operator, which is not 243 feasible for reasons of scalability. Consequently, unless there 244 are permanent calls, the establishment of the TDMPW will be 245 based on the control signaling of switched calls. 246 For the multiplexing of calls, it should be noted that: 247 Figure 2. TDMPW taxonomy TDMPW Transparent SDT Static Dynamic •CEsoPSN •AAL1 TDMoIP withSDT •AAL2 TDMoIP •SAToP •AAL1 TDMoIP withoutSDT TDMPW Transparent SDT Static Dynamic •CEsoPSN •AAL1 TDMoIP withSDT •AAL2 TDMoIP •SAToP •AAL1 TDMoIP withoutSDT Figure 3. Multi-channel call between two ISDN terminals using TDMPWs Figure 4. ISDN circuit-mode calls multiplexed on a TDMPW  Multi-channel or unrestricted single-channel [33] 248 circuit-mode services: they require UDI transport over 249 the IP network, and so RTP PT (Payload Type) 250 CLEARMODE [34] without Voice Activity Detection 251 (VAD). 252  Voice single-channel circuit-mode services: they allow 253 transcoding from G.711 to any other codec, as well as 254 incorporating VAD at any codec. The former should be 255 avoided in most cases, because of the involved 256 transcoding delays [43]. For the latter, more desirable 257 because it saves bandwidth, it is advisable that the 258 egress PE generates comfort noise during silence 259 periods. This requires that the ingress PE sends the 260 proper comfort noise parameters using SID (Silence 261 Insertion Descriptor) frames, identified by the PT 262 Comfort Noise Generation (CNG) [35]. 263 Note that the different calls multiplexed within the 264 TDMPW may use different payload types, so the payload type 265 indicator must travel along the samples. 266 B. Choosing the type of TDMPW 267 When choosing the type of TDMPW, we have to discard 268 the transparent ones, because they only allow to emulate 269 complete interfaces, without identifying their elementary 270 channels. 271 The structure-aware TDMPWs can only carry the “N” B272 channels of a Nx64 multi-channel call. PEs (their Native 273 Service Processors) will need to support the ISDN physical 274 frame format, both primary and basic UNIs V [37] interfaces, 275 according to each operator’s preference. Since the PEs would 276 be located on the AGWs responsible for the terminating ISDN 277 interfaces, it seems reasonable to assume this condition 278 satisfied. 279 Among the different types of structure-aware TDMPWs, 280 the static (CESoPSN and AAL1 TDMoIP with SDT) are not 281 suitable for the following reasons. 282 First, as they have no VAD (Voice Activity Detection) 283 support, they carry even the idle channels, which represents an 284 inefficient use of bandwidth. 285 Secondly, they do not adequately support the concentration 286 of permanent or switched calls: 287  Switched calls are dynamically set up and released, 288 thus modifying the aggregated number of active 289 channels. However, TDMPWs are usually set up at 290 management time, before any call is established, 291 making it impossible to follow the future variyng 292 capacity demanded by the calls. 293  Permanent calls are established in management time, 294 as TDMPW are, however, when adding or deleting a 295 new permanent call, it would be necessary to tear down 296 and re-establish the TDMPW, interrupting the service 297 for the existing calls. 298 As opposed to static TDMPWs, the dynamic structure299 aware TDMPWs (AAL2 TDMoIP) can emulate services with 300 channels from different interfaces, and can dynamically modify 301 the number of carried channels. Moreover, its control plane 302 may negotiate between both PEs the voice processing to apply 303 to the transported channels, such as VAD. 304 From the above analysis, we may conclude that the only 305 suitable way to emulate the ISDN multi-channel calls are the 306 AAL2 TDMoIP TDMPWs 307 C. AAL2 TDMPW payload format 308 According to the defined AAL2 TDMoIP payloads at [27; 309 30], each TDM channel is assigned a unique CID. An Nx64 310 multi-channel call will use “N” CIDs. This payload format is 311 not valid for emulating multi-channel calls, as is discussed 312 below. 313 In a multi-channel call, the ISDN source terminal generates 314 a flow of “Nx64 Kb/s” rate. In the ISDN interface, the flow is 315 conveyed on "N" 1x64 kbps B-channels, so that each TDM 316 frame of the ISDN interface carries "N" samples of that flow 317 (“N” channels virtually behave as a single channel of rate 318 “Nx64”). The 2x64 service, with its distinctive RDTD 319 structure, represents an exception to this rule: this service is 320 designed to support stereo voice calls, so the two channels must 321 be transported to the remote terminal in parallel, and samples 322 from each channel at the source should always be delivered to 323 the same channel at the destination. 324 For the emulation of a multi-channel call to be correct, the 325 destination terminal should be able to reconstruct the same 326 flow as sent by the source terminal. However: 327  To ensure a constant end to end delay, regardless of the 328 bit rate of the emulated service, each AAL2 TDMPW 329 packet includes the number of minicells that allows 330 preserving this delay, depending on the channel 331 activity. Consequently, at a multi-channel call, 332 samples from two of its channels in the same TDM 333 frame can be sent in several TDMPW packets. 334  AAL2 TDMPWs does not provide any way to indicate 335 the egress PE how to sort the samples from different 336 CIDs when they belong to the same multi-channel call 337 (the CW or RTP sequence number only guarantees the 338 sequencing of TDMPW packets). 339 Thus, if a TDMPW packet is lost, the egress PE can 340 misorder the samples, sending to the destination TE TDM 341 frames that differ from those sent by the source TE. Note that 342 the egress PE can still detect the missing TDMPW packet, by 343 inspecting either the CW or RTP sequence numbers, but not 344 which channels (CID) were carried by the minicells within that 345 packet, or how many samples were contained at each minicell. 346 This misordering of the samples could destroy TSSI (Figure 347 5, samples “3” and “8”) and RDTD structures (Figure 5, 348 samples “3” and “4” as “4” is lost and “3” does not, or between 349 samples “10” and “12”, since there is no guarantee that TDM 350 frames TDM2 and TDM3 are delivered to the destination TE 351 spaced no more than 50 ms). 352 353 354 To summarize, the standard AAL2 TDMPW payload 355 format, which assigns a CID to each channel, can not properly 356 carry ISDN multi-channel calls. To support that transport, 357 including multiplexing several calls on the same TDMPW, we 358 propose two options: 359 a) AAL2 TDMPWs with a CID per channel in VoIP 360 mode: VoIP mode [14] proposes to insert a RTP 361 header inside each AAL2 minicell AAL2 (eliminating 362 the RTP header of the TDMPW), which would allow 363 the egrees PE to know the time to play the first sample 364 of each minicell. Thus, after the loss of a TDMPW 365 packet, the egress PE can identify the affected TDM 366 frames, properly placing the samples of the following 367 TDMPW packets. 368 This transport scheme guarantees that the sample 369 order at the ingress is kept at the egress PE, which 370 also ensures TSSI and RDTD structures (Figure 6). 371 Also, the PT field of the RTP header of each minicell 372 allows the egress PE to know the codec applied to 373 each call in the IP network. 374 375 b) AAL2 TDMPWs with a CID per call using basic 376 structures: although the IETF specification [27] only 377 provides for the allocation of a CID to each channel, 378 the definition of AAL2 interworking flows by ITU-T 379 Recommendations [14; 40] is much more general, 380 allowing freedom for the nature of the flows identified 381 by each CID (i.e., multiplexed flows of any kind and, 382 even, RTP flows from any TDM interface). Taking 383 advantage of this flexibility, we propose to associate a 384 CID to each call carried by the TDMPW, either single 385 or multi-channel (same CID to all its channels). 386 387 Samples will be transported by “basic structures” 388 similar to those defined for the CESoPSN TDMPWs 389 under basic Nx64 service [29]. Each basic structure 390 consists of the sample of "N" channels of the call 391 contained in a single TDM frame. The payload of 392 each AAL2 minicell contains an integer number of 393 basic structures (Figure 7). 394 395 This scheme ensures that the flow regenerated at 396 the output of the TDMPW matches the origin, which 397 also ensures the TSSI structure. The RDTD structure 398 is also guaranteed, since the “N = 2” samples from the 399 same TDM frame will share the same minicell, 400 shaping a “basic structure”. 401 Figure 5. 4x64 multi-channel ISDN call on standardized AAL2 TDMoIP PW with a CID per channel Figure 6. 4x64 multi-channel ISDN call on AAL2 TDMoIP PW with a CID per channel and VoIP mode Figure 7. AAL2 TDMoIP payload with a CID per call based on basic structures PayloadCPS-PDU (0, 1, … ALL2 minicells)PayloadCPS-PDU (0, 1, … ALL2 minicells) CPS-PDU (without StartFieldSTF) 8 bits CID=x PDU SSCS IT 1 8 bits IT 2 IT K 8 bits 8xN bits Octet2 OctetNOctet1 Basic structure of the Nx64 call withCID=x … TDM frame IT N … CID=x LI UUICRCBasic structure 1, Basic structure2, … AAL2 minicell header Integer numberof basic structures CID=z LIUUICRCPDU Variable length … AAL2 minicells Header L2 PHY IP/MPLS PW label L2 specific sublayer/CW RTP TDMPW Payload L2 PHY IP/MPLS PW label L2 specific sublayer/CW RTP TDMPW Payload … Integer number At the destination, the egress PE needs to know 402 the type of codec for each call, be it to transcode to 403 the proper output codec or to insert comfort noise 404 should VAD is used. To inform the PE, we propose 405 two alternatives: 406  VoIP mode, with an RTP header in each AAL2 407 minicell (Figure 8): the PT would be included in 408 the RTP header. 409 410  PT in the User-to-User Indication (UUI) of every 411 AAL2 minicell (Figure 9): Annex A of the 412 specification [30] outlines a possible use of UUI 413 field to indicate the encoding of the media. This 414 option has the same headers that AAL2 415 TDMPWs defined by [27], thus keeping the same 416 TDMPW's RTP header. 417 For singlechannel voice calls, with CNG PT, the ingress 418 PE would sends two different AAL2 minicell types: one type 419 for voice samples, and another type for the SID frames with 420 CNG PT. In both cases the payload-type will be indicated in 421 the PT RTP or UUI AAL2 field. The working-out of the noise422 generation interval depends on the alternative: 423  For the VoIP mode, with a CID per channel or call, the 424 egress PE shall use the timestamps from the RTP 425 header. 426  For the PT in the UUI AAL2 field mode there are no 427 timestamps, so the egress PE generates comfort noise 428 until the next voice minicell is received. 429 430 D. Comparison of the proposed TDMPW payload formats 431 The 3 types of proposed AAL2 TDMPW payloads can be 432 compared in terms of bandwidth efficiency, attainable 433 granularity and delay (Table I): 434 a) In the VoIP mode, the inclusion of an RTP header in 435 every minicell wastes bandwidth. Given the great 436 similarity that these headers may show, the problem 437 could alleviated by applying RTP header compression 438 mechanisms [41]. For the two options proposed under 439 this mode, we can consider the following comments: 440  When using one CID per channel samples of a call 441 placed in the same TDM frame at the ingress PE 442 can be sent in several TDMPW packets. The 443 egress PE will have to wait for the arrival of all 444 those packets to successfully build up the TDM 445 frame, which may increase the delay. 446  When using a CID per call all the samples from a 447 call placed in the same TDM frame at the ingress 448 PE are conveyed in the same TDMPW packet. Its 449 disadvantage is a coarser packing granularity, 450 because the payload of the minicells is forced to 451 be a multiple of relatively larger basic structures. 452 This reduces the margin to ensure a constant end 453 to end delay between both PEs. 454 b) A CID per call with the PT in the UUI field: When 455 compared to the VoIP mode, it is more bandwidth456 efficient, as it does not require additional RTP 457 headers. This solution also shows the coarse 458 granularity feature described above. 459 460 Figure 8. 2x64 multi-channel ISDN call on AAL2 TDMoIP PW with a CID per call and VoIP mode Figure 9. 4x64 multi-channel ISDN call on AAL2 TDMoIP PW with a CID per call and PT in UUI field 461 TABLE I. COMPARISON OF THE PROPOSED AAL2 TDMOIP TDMPW PAYLOAD FORMATS TO SUPPORT ISDN MULTICHANNEL CALLS Guarantees TSSI and RDTD structures Support ISDN multichannel calls AAL2 minicells' granularity Transport of the PT of each call Support call multiplexing Determination of the noise-generation period for VAD-enabled single -channel calls Overhead Effect of delayed TDMPW packets AAL2 TDMPW payload format standardized by [27] No No Octects No (it assumes the same codec for all calls) No (it assumes the same codec for all calls) VAD not supported Lower Egress PE should wait to last TDMPW with samples of the same frame TDM VoIP mode CID per channel Yes Yes Octects PT RTP field in AAL2 minicells Yes By using RTP timestamp High (RTP headers in AAL2 minicells) Egress PE should wait to last TDMPW with samples of the same frame TDM CID per call Yes Yes Basic structures PT RTP field in AAL2 minicells Yes By using RTP timestamp High (RTP headers in AAL2 minicells) None (samples travel together in basic structures) CID per call and PT in the UIUI field Yes Yes Basic structures UUI field of AAL2 minicell' header Yes Until the next voice minicell arrives Lower None (samples travel together in basic structures) IV. CONCLUSIONS This paper addresses the transport of ISDN multi-channel circuit-mode bearer services for its NGN emulation. First, we have evaluated the different TDMPWs, concluding that the AAL2 TDMPWs are the best choice, although its standard payload format does not guarantee the TSSI structure. To solve this, we have defined three new types for the TDMPW’s payload format. Two of them are based on the inclusion of a header at the beginning of the RTP payload for each AAL2 minicell (VoIP mode), assigning a CID to every channel or call (in the latter, by organizing the samples from the channels of a call in basic structures.) The third type, which also assigns a CID to each call, uses the minicells’ UUI field to indicate the type of processing applied to the samples, saving bandwidth. REFERENCES [1] ETSI TR 180 001 v1.1.1. "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Release 1; Release definition". (03/06). [2] ITU-T Y.2201. "NGN release 1 requirements". (04/07). [3] ITU-T Y.2000 Suplement 1. "Supplement on NGN release 1 scope". (07/06). [4] ITU-T Y.2006. "Description of capability set 1 of NGN release 1". (02/08). [5] ITU-T Y.2262. "PSTN/ISDN emulation and simulation". (12/06). [6] ETSI ES 282 002. "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional architecture". (1/06). [7] ETSI SR 002 211. "List of standards and/or specifications for electronic communications networks, services and associated facilities and services; in accordance with Article 17 of Directive 2002/21/EC". (2/04). [8] The European Parliament and the council of the European Union. "Directive 2002/22/EC of the European Parliament and of the Council". Directive 2002/22/EC. (03/02). [9] ETSI EG 201 973-2. "Access and Terminals (AT); Public Switched Telephone Network; Support of legacy terminals by Broadband IP networks and equipment; Part 2: Analogue PSTN terminals". (3/05). [10] ITU-T Y.2031. "PSTN/ISDN emulation architecture". (09/06). [11] ETSI ES 283 002 v2.1.0. "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN Emulation Subsystem (PES); NGN Release 2 H.248 Profile Version 2 for controlling Access and Residential Gateways". (03/08). [12] ITU-T Y.2012. "Functional requirements and architecture of next generation networks". (9/06). [13] ITU-T Y.1453. "TDM-IP interworking - User plane interworking". (03/06). [14] ITU-T Y.1452. "Voice trunking over IP networks". (3/06). [15] IETF RFC 4197. "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks". (10/05). [16] IETF RFC 3985. "PseudoWire Emulation Edge-to-Edge (PWE3) Architecture". (03/05). [17] ITU-T I.231.5. “Circuit-mode 2 x 64 kbit/s unrestricted, 8 kHz structured bearer service". (11/88). [18] ITU-T I.231.6. “Circuit-mode 384 kbit/s unrestricted, 8 kHz structured bearer service". (7/96). [19] ITU-T I.231.7. “Circuit-mode 1536 kbit/s unrestricted, 8 kHz structured bearer service". (7/96). [20] ITU-T I.231.8. “Circuit-mode 1920 kbit/s unrestricted, 8 kHz structured bearer service". (7/96). [21] ITU-T I.231.10. “Circuit-mode multiple-rate unrestricted 8 kHz structured bearer service". (8/92). [22] ITU-T I.140. “Attribute technique for the characterization of telecommunication services supported by an ISDN and network capabilities of an ISDN". (3/93). [23] ITU-T Y.2011. "General principles and general reference model for Next Generation Networks". (10/04). [24] ITU-T H.248.1. “Gateway control protocol: Version 3". (9/05). [25] IETF RFC 3916. "Requirements for Pseudo-Wire Emulation Edge-toEdge (PWE 3)". (09/04). [26] IETF RFC 4553. "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)". (6/06). [27] IETF RFC 5087. "Time Division Multiplexing over IP (TDMoIP)". (12/07). [28] Broadband Forum af-vtoa-0078.000. "Circuit Emulation Service (CES) Interoperability. Specification Version 2.0". (1/97). [29] IETF RFC 5086. "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)". (12/07). [30] Broadband Forum af-vmoa-145.001. "Voice and Multimedia Over ATM - Loop Emulation Service (LES) Using AAL2 (Rev 1)". (2/03). [31] IETF RFC 5287. "Control Protocol Extensions for the Setup of TimeDivision Multiplexing (TDM) Pseudowires in MPLS Networks". (8/08). [32] ITU-T I.363.2. "B-ISDN ATM Adaptation Layer specification : Type 2 AAL". (11/00). [33] ITU-T I.231.1. “Circuit-mode 64 kbit/s unrestricted, 8 kHz structured bearer service". (11/88). [34] IETF RFC 4040. "RTP Payload Format for a 64 kbit/s Transparent Call". (4/05). [35] IETF RFC 3389. "Real-time Transport Protocol (RTP) Payload for Comfort Noise (CN)". (9/02). [36] ITU-T G.961. "Digital transmission system on metallic local lines for ISDN basic rate access". (3/93). [37] ITU-T Q.512. "Digital exchange interfaces for subscriber access". (2/95). [38] ITU-T I.430. "Basic user-network interface – Layer 1 specification". (11/95). [39] ITU-T I.431. "Primary rate user-network interface – Layer 1 specification". (3/93). [40] ITU-T Y.1414. “Voice services – MPLS network interworking". (7/04). [41] IETF RFC 2508. "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links". (2/99). [42] IETF RFC 3550. "RTP: A Transport Protocol for Real-Time Applications". (7/03). [43] ETSI TS 183 002 v3.3.1. "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN Emulation Subsystem (PES); H.248 Profile Version 3 for controlling Access and Residential Gateways". (8/09).