Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 1 | [[osmux]] |
| 2 | = OSmux: reduce of SAT uplink costs by protocol optimizations |
| 3 | |
| 4 | == Problem |
| 5 | |
| 6 | In case of satellite based GSM systems, the transmission cost on the back-haul |
| 7 | is relatively expensive. The billing for such SAT uplink is usually done in a |
| 8 | pay-per-byte basis. Thus, reducing the amount of bytes transfered would |
| 9 | significantly reduce the cost of such uplinks. In such environment, even |
| 10 | seemingly small protocol optimizations, eg. message batching and trunking, can |
| 11 | result in significant cost reduction. |
| 12 | |
| 13 | This is true not only for speech codec frames, but also for the constant |
| 14 | background load caused by the signalling link (A protocol). Optimizations in |
| 15 | this protocol are applicable to both VSAT back-haul (best-effort background IP) |
| 16 | as well as Inmarsat based links (QoS with guaranteed bandwidth). |
| 17 | |
| 18 | == Proposed solution |
| 19 | |
| 20 | In order to reduce the bandwidth consumption, this document proposes to develop |
| 21 | a multiplex protocol that will be used to proxy voice and signalling traffic |
| 22 | through the SAT links. |
| 23 | |
| 24 | === Voice |
| 25 | |
| 26 | For the voice case, we propose a protocol that provides: |
| 27 | |
| 28 | * Batching: that consists of putting multiple codec frames on the sender side |
| 29 | into one single packet to reduce the protocol header overhead. This batch |
| 30 | is then sent as one RTP/UDP/IP packet at the same time. Currently, AMR 5.9 |
| 31 | codec frames are transported in a RTP/UDP/IP protocol stacking. This means |
| 32 | there are 15 bytes of speech codec frame, plus a 2 byte RTP payload header, |
| 33 | plus the RTP (12 bytes), UDP (8 bytes) and IP (20 bytes) overhead. This means |
| 34 | we have 40 byte overhead for 17 byte payload. |
| 35 | |
| 36 | * Trunking: in case of multiple concurrent voice calls, each of them will |
| 37 | generate one speech codec frame every 20ms. Instead of sending only codec |
| 38 | frames of one voice call in a given IP packet, we can 'interleave' or trunk |
| 39 | the codec frames of multiple calls into one IP. This further increases the |
| 40 | IP packet size and thus improves the payload/overhead ratio. |
| 41 | |
| 42 | Both techniques should be applied without noticeable impact in terms of user |
| 43 | experience. As the satellite back-haul has very high round trip time (several |
| 44 | hundred milliseconds), adding some more delay is not going to make things |
| 45 | significantly worse. |
| 46 | |
| 47 | For the batching, the idea consists of batching multiple codec frames on the |
| 48 | sender side, A batching factor (B) of '4' means that we will send 4 codec |
| 49 | frames in one underlying protocol packet. The additional delay of the batching |
| 50 | can be computed as (B-1)*20ms as 20ms is the duration of one codec frame. |
| 51 | Existing experimentation has shown that a batching factor of 4 to 8 (causing a |
| 52 | delay of 60ms to 140ms) is acceptable and does not cause significant quality |
| 53 | degradation. |
| 54 | |
| 55 | The main requirements for such voice RTP proxy are: |
| 56 | |
| 57 | * Always batch codec frames of multiple simultaneous calls into single UDP |
| 58 | message. |
| 59 | |
| 60 | * Batch configurable number codec frames of the same call into one UDP |
| 61 | message. |
| 62 | |
| 63 | * Make sure to properly reconstruct timing at receiver (non-bursty but |
| 64 | one codec frame every 20ms). |
| 65 | |
| 66 | * Implementation in libosmo-netif to make sure it can be used |
| 67 | in osmo-bts (towards osmo-bsc), osmo-bsc (towards osmo-bts and |
| 68 | osmo-bsc_nat) and osmo-bsc_nat (towards osmo-bsc) |
| 69 | |
| 70 | * Primary application will be with osmo-bsc connected via satellite link to |
| 71 | osmo-bsc_nat. |
| 72 | |
| 73 | * Make sure to properly deal with SID (silence detection) frames in case |
| 74 | of DTX. |
| 75 | |
| 76 | * Make sure to transmit and properly re-construct the M (marker) bit of |
| 77 | the RTP header, as it is used in AMR. |
| 78 | |
| 79 | * Primary use case for AMR codec, probably not worth to waste extra |
| 80 | payload byte on indicating codec type (amr/hr/fr/efr). If we can add |
| 81 | the codec type somewhere without growing the packet, we'll do it. |
| 82 | Otherwise, we'll skip this. |
| 83 | |
| 84 | === Signalling |
| 85 | |
| 86 | Signalling uses SCCP/IPA/TCP/IP stacking. Considering SCCP as payload, this |
| 87 | adds 3 (IPA) + 20 (TCP) + 20 (IP) = 43 bytes overhead for every signalling |
| 88 | message, plus of course the 40-byte-sized TCP ACK sent in the opposite |
| 89 | direction. |
| 90 | |
| 91 | While trying to look for alternatives, we consider that none of the standard IP |
| 92 | layer 4 protocols are suitable for this application. We detail the reasons |
| 93 | why: |
| 94 | |
| 95 | * TCP is a streaming protocol aimed at maximizing the throughput of a stream |
| 96 | withing the constraints of the underlying transport layer. This feature is |
| 97 | not really required for the low-bandwidth and low-pps GSM signalling. |
| 98 | Moreover, TCP is stream oriented and does not conserve message boundaries. |
| 99 | As such, the IPA header has to serve as a boundary between messages in the |
| 100 | stream. Moreover, assuming a generally quite idle signalling link, the |
| 101 | assumption of a pure TCP ACK (without any data segment) is very likely to |
| 102 | happen. |
| 103 | |
| 104 | * Raw IP or UDP as alternative is not a real option, as it does not recover |
| 105 | lost packets. |
| 106 | |
| 107 | * SCTP preserves message boundaries and allows for multiple streams |
| 108 | (multiplexing) within one connection, but it has too much overhead. |
| 109 | |
| 110 | For that reason, we propose the use of LAPD for this task. This protocol was |
| 111 | originally specified to be used on top of E1 links for the A interface, who |
| 112 | do not expose any kind of noticeable latency. LAPD resolves (albeit not as |
| 113 | good as TCP does) packet loss and copes with packet re-ordering. |
| 114 | |
| 115 | LAPD has a very small header (3-5 octets) compared to TCPs 20 bytes. Even if |
| 116 | LAPD is put inside UDP, the combination of 11 to 13 octets still saves a |
| 117 | noticable number of bytes per packet. Moreover, LAPD has been modified for less |
| 118 | reliable interfaces such as the GSM Um interface (LAPDm), as well as for the |
| 119 | use in satellite systems (LAPsat in ETSI GMR). |
| 120 | |
| 121 | == OSmux protocol |
| 122 | |
| 123 | The OSmux protocol is the core of our proposed solution. This protocol operates |
| 124 | over UDP or, alternatively, over raw IP. The designated default UDP port number |
| 125 | and IP protocol type have not been yet decided. |
| 126 | |
| 127 | Every OSmux message starts with a control octet. The control octet contains a |
| 128 | 2-bit Field Type (FT) and its location starts on the 2nd bit for backward |
| 129 | compatibility with older versions (used to be 3 bits). The FT defines the |
| 130 | structure of the remaining header as well as the payload. |
| 131 | |
| 132 | The following FT values are assigned: |
| 133 | |
| 134 | * FT == 0: LAPD Signalling |
| 135 | * FT == 1: AMR Codec |
| 136 | * FT == 2: Dummy |
| 137 | * FT == 3: Reserved for Fture Use |
| 138 | |
| 139 | There can be any number of OSmux messages batched up in one underlaying packet. |
| 140 | In this case, the multiple OSmux messages are simply concatenated, i.e. the |
| 141 | OSmux header control octet directly follows the last octet of the payload of the |
| 142 | previous OSmux message. |
| 143 | |
| 144 | |
| 145 | === LAPD Signalling (0) |
| 146 | |
Pau Espin Pedrol | ac70cf9 | 2017-07-18 18:56:22 +0200 | [diff] [blame] | 147 | [packetdiag] |
| 148 | ---- |
| 149 | { |
| 150 | colwidth = 32 |
| 151 | node_height = 40 |
| 152 | |
| 153 | 0: - |
| 154 | 1-2: FT |
| 155 | 3-7: ---- |
| 156 | 8-15: PL-LENGTH |
| 157 | 16-31: LAPD header + payload |
| 158 | } |
| 159 | ---- |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 160 | |
| 161 | Field Type (FT): 2 bits:: |
Pau Espin Pedrol | 1293ee1 | 2017-08-11 15:04:40 +0200 | [diff] [blame] | 162 | The Field Type allocated for LAPD Signalling frames is "0". |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 163 | |
| 164 | This frame type is not yet supported inside OsmoCom and may be subject to |
| 165 | change in future versions of the protocol. |
| 166 | |
| 167 | |
| 168 | === AMR Codec (1) |
| 169 | |
| 170 | This OSmux packet header is used to transport one or more RTP-AMR packets for a |
| 171 | specific RTP stream identified by the Circuit ID field. |
| 172 | |
Pau Espin Pedrol | ac70cf9 | 2017-07-18 18:56:22 +0200 | [diff] [blame] | 173 | [packetdiag] |
| 174 | ---- |
| 175 | { |
| 176 | colwidth = 32 |
| 177 | node_height = 40 |
| 178 | |
| 179 | 0: M |
| 180 | 1-2: FT |
| 181 | 3-5: CTR |
| 182 | 6: F |
| 183 | 7: Q |
| 184 | 8-15: Red. TS/SeqNR |
| 185 | 16-23: Circuit ID |
| 186 | 24-27: AMR FT |
| 187 | 28-31: AMR CMR |
| 188 | } |
| 189 | ---- |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 190 | |
| 191 | Marker (M): 1 bit:: |
| 192 | This is a 1:1 mapping from the RTP Marker (M) bit as specified in RFC3550 |
| 193 | Section 5.1 (RTP) as well as RFC3267 Section 4.1 (RTP-AMR). In AMR, the Marker |
| 194 | is used to indicate the beginning of a talk-spurt, i.e. the end of a silence |
| 195 | period. In case more than one AMR frame from the specific stream is batched into |
| 196 | this OSmux header, it is guaranteed that the first AMR frame is the first in the |
| 197 | talkspurt. |
| 198 | |
| 199 | Field Type (FT): 2 bits:: |
Pau Espin Pedrol | 1293ee1 | 2017-08-11 15:04:40 +0200 | [diff] [blame] | 200 | The Field Type allocated for AMR Codec frames is "1". |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 201 | |
| 202 | Frame Counter (CTR): 2 bits:: |
| 203 | Provides the number of batched AMR payloads (starting 0) after the header. For |
| 204 | instance, if there are 2 AMR payloads batched, CTR will be "1". |
| 205 | |
| 206 | AMR-F (F): 1 bit:: |
| 207 | This is a 1:1 mapping from the AMR F field in RFC3267 Section 4.3.2. In case |
| 208 | there are multiple AMR codec frames with different F bit batched together, we |
| 209 | only use the last F and ignore any previous F. |
| 210 | |
| 211 | AMR-Q (Q): 1 bit:: |
| 212 | This is a 1:1 mapping from the AMR Q field (Frame quality indicator) in RFC3267 |
| 213 | Section 4.3.2. In case there are multiple AMR codec frames with different Q bit |
| 214 | batched together, we only use the last Q and ignore any previous Q. |
| 215 | |
| 216 | Circuit ID Code (CIC): 8 bits:: |
| 217 | Identifies the Circuit (Voice call), which in RTP is identified by {srcip, |
| 218 | srcport, dstip, dstport, ssrc}. |
| 219 | |
| 220 | Reduced/Combined Timestamp and Sequence Number (RCTS): 8 bits:: |
| 221 | Resembles a combination of the RTP timestamp and sequence number. In the GSM |
| 222 | system, speech codec frames are generated at a rate of 20ms. Thus, there is no |
| 223 | need to have independent timestamp and sequence numbers (related to a 8kHz |
| 224 | clock) as specified in AMR-RTP. |
| 225 | |
| 226 | AMR Codec Mode Request (AMR-FT): 4 bits:: |
| 227 | This is a mapping from te AMR FT field (Frame type index) in RFC3267 Section |
| 228 | 4.3.2. The length of each codec frame needs to be determined from this field. It |
| 229 | is thus guaranteed that all frames for a specific stream in an OSmux batch are |
| 230 | of the same AMR type. |
| 231 | |
| 232 | AMR Codec Mode Request (AMR-CMR): 4 bits:: |
| 233 | The RTP AMR payload header as specified in RFC3267 contains a 4-bit CMR field. |
| 234 | Rather than transporting it in a separate octet, we squeeze it in the lower four |
| 235 | bits of the clast octet. In case there are multiple AMR codec frames with |
| 236 | different CMR, we only use the last CMR and ignore any previous CMR. |
| 237 | |
| 238 | ==== Additional considerations |
| 239 | |
| 240 | * It can be assumed that all OSmux frames of type AMR Codec contain at least 1 |
| 241 | AMR frame. |
| 242 | * Given a batch factor of N frames (N>1), it can not be assumed that the amount |
| 243 | of AMR frames in any OSmux frame will always be N, due to some restrictions |
| 244 | mentioned above. For instance, a sender can decide to send before queueing the |
| 245 | expected N frames due to timing issues, or to conform with the restriction |
| 246 | that the first AMR frame in the batch must be the first in the talkspurt |
| 247 | (Marker M bit). |
| 248 | |
| 249 | |
| 250 | === Dummy (2) |
| 251 | |
| 252 | This kind of frame is used for NAT traversal. If a peer is behind a NAT, its |
| 253 | source port specified in SDP will be a private port not accessible from the |
| 254 | outside. Before other peers are able to send any packet to it, they require the |
| 255 | mapping between the private and the public port to be set by the firewall, |
| 256 | otherwise the firewall will most probably drop the incoming messages or send it |
| 257 | to a wrong destination. The firewall in most cases won't create a mapping until |
| 258 | the peer behind the NAT sends a packet to the peer residing outside. |
| 259 | |
| 260 | In this scenario, if the peer behind the nat is expecting to receive but never |
| 261 | transmit audio, no packets will ever reach him. To solve this, the peer sends |
| 262 | dummy packets to let the firewall create the port mapping. When the other peers |
| 263 | receive this dummy packet, they can infer the relation between the original |
| 264 | private port and the public port and start sending packets to it. |
| 265 | |
| 266 | When opening a connection, the peer is expected to send dummy packets until it |
| 267 | starts sending real audio, at which point dummy packets are not needed anymore. |
| 268 | |
Pau Espin Pedrol | ac70cf9 | 2017-07-18 18:56:22 +0200 | [diff] [blame] | 269 | [packetdiag] |
| 270 | ---- |
| 271 | { |
| 272 | colwidth = 32 |
| 273 | node_height = 40 |
| 274 | |
| 275 | 0: - |
| 276 | 1-2: FT |
| 277 | 3-5: CTR |
| 278 | 6-7: -- |
| 279 | 8-15: ---- |
| 280 | 16-23: Circuit ID |
| 281 | 24-27: AMR FT |
| 282 | 28-31: ---- |
| 283 | } |
| 284 | ---- |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 285 | |
| 286 | Field Type (FT): 2 bits:: |
Pau Espin Pedrol | 1293ee1 | 2017-08-11 15:04:40 +0200 | [diff] [blame] | 287 | The Field Type allocated for Dummy frames is "2". |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 288 | |
| 289 | Frame Counter (CTR): 2 bits:: |
| 290 | Provides the number of dummy batched AMR payloads (starting 0) after the header. |
| 291 | For instance, if there are 2 AMR payloads batched, CTR will be "1". |
| 292 | |
| 293 | Circuit ID Code (CIC): 8 bits:: |
| 294 | Identifies the Circuit (Voice call), which in RTP is identified by {srcip, |
| 295 | srcport, dstip, dstport, ssrc}. |
| 296 | |
| 297 | AMR Codec Mode Request (AMR-FT): 4 bits:: |
| 298 | This field must contain any valid value described in the AMR FT field (Frame |
| 299 | type index) in RFC3267 Section 4.3.2. |
| 300 | |
| 301 | ==== Additional considerations |
| 302 | |
| 303 | * After the header, additional padding needs to be allocated to conform with CTR |
| 304 | and AMR FT fields. For instance, if CTR is 0 and AMR FT is AMR 6.9, a padding |
| 305 | of 17 bytes is to be allocated after the header. |
| 306 | |
| 307 | * On receival of this kind of OSmux frame, it's usually enough for the reader to |
| 308 | discard the header plus the calculated padding and keep operating. |
| 309 | |
Pau Espin Pedrol | 1ce6c62 | 2017-07-19 13:21:25 +0200 | [diff] [blame] | 310 | == Sequence Charts |
| 311 | |
| 312 | === Trunking |
| 313 | |
| 314 | Following chart shows how trunking works for 3 concurrent calls from different |
| 315 | MS on a given BTS. In this case only uplink data is shown, but downlink follows |
| 316 | the same idea. Batching factor is set to 1 to easily illustrate trunking mechanism. |
| 317 | |
| 318 | It can be seen how 3 RTP packets from 3 different Ms (a, b, and c) arrive to the |
| 319 | BSC from the BTS. The BSC generates 3 OSmux frames and stores and sends them |
| 320 | together in one UDP packet to the BSC-NAT. The BSC-NAT decodes the three OSmux |
| 321 | frames, identifies each of them through CID values and transform them back to |
| 322 | RTP before sending them to the MGW. |
| 323 | |
| 324 | ["mscgen"] |
| 325 | ---- |
| 326 | msc { |
| 327 | hscale = 2; |
| 328 | bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; |
| 329 | |
| 330 | ...; |
| 331 | --- [label="3 Regular RTP-AMR calls using OSmux (has been ongoing for some time)"]; |
| 332 | |
| 333 | bts => bsc [label="RTP-AMR[seq=y,ssrc=MSa]"]; |
| 334 | bts => bsc [label="RTP-AMR[seq=x,ssrc=MSb]"]; |
| 335 | bts => bsc [label="RTP-AMR[seq=z,ssrc=MSc]"]; |
| 336 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(y)],Osmux[ft=2,cid=i+1,seq=n,AMR(x)],Osmux[ft=2,cid=i+2,seq=l,AMR(z)]]"]; |
| 337 | bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=y,ssrc=MSa)"]; |
| 338 | bscnat => mgw [label="RTP-AMR[seq=p,ssrc=s] (originally seq=x,ssrc=MSb)"]; |
| 339 | bscnat => mgw [label="RTP-AMR[seq=q,ssrc=t] (originally seq=z,ssrc=MSc)"]; |
| 340 | bts => bsc [label="RTP-AMR[seq=y+1,ssrc=MSa]"]; |
| 341 | bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSb]"]; |
| 342 | bts => bsc [label="RTP-AMR[seq=z+1,ssrc=MSc]"]; |
| 343 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(y+1)],Osmux[ft=2,cid=i+1,seq=n+1,AMR(x+1)],Osmux[ft=2,cid=i+2,seq=l+1,AMR(z+1)]]"]; |
| 344 | bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=y+1,ssrc=MSa)"]; |
| 345 | bscnat => mgw [label="RTP-AMR[seq=p+1,ssrc=s] (originally seq=x+1,ssrc=MSb)"]; |
| 346 | bscnat => mgw [label="RTP-AMR[seq=q+1,ssrc=t] (originally seq=z+1,ssrc=MSc)"]; |
| 347 | bts => bsc [label="RTP-AMR[seq=y+2,ssrc=MSa]"]; |
| 348 | bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSb]"]; |
| 349 | bts => bsc [label="RTP-AMR[seq=z+2,ssrc=MSc]"]; |
| 350 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+2,AMR(y+2)],Osmux[ft=2,cid=i+1,seq=n+2,AMR(x+2)],Osmux[ft=2,cid=i+2,seq=l+2,AMR(z+2)]]"]; |
| 351 | bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=y+2,ssrc=MSa)"]; |
| 352 | bscnat => mgw [label="RTP-AMR[seq=p+2,ssrc=s] (originally seq=x+2,ssrc=MSb)"]; |
| 353 | bscnat => mgw [label="RTP-AMR[seq=q+2,ssrc=t] (originally seq=z+2,ssrc=MSc)"]; |
| 354 | } |
| 355 | ---- |
| 356 | |
| 357 | === Batching |
| 358 | |
| 359 | Following chart shows how batching with a factor of 3 works. To easilly |
| 360 | illustrate batching, only uplink and one concurrent call is considered. |
| 361 | |
| 362 | It can be seen how 3 RTP packets from MSa arrive to the BSC from the BTS. The |
| 363 | BSC queues the 3 RTP packets and once the batchfactor is reached, an OSmux frame |
| 364 | is generated and sent to the BSC-NAT. The BSC-NAT decodes the OSmux frames, |
| 365 | transforms each AMR payload into an RTP packet and each RTP packet is scheduled |
| 366 | for delivery according to expected proportional time delay (and timestamp field |
| 367 | is set accordingly). |
| 368 | |
| 369 | ["mscgen"] |
| 370 | ---- |
| 371 | msc { |
| 372 | hscale = 2; |
| 373 | bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; |
| 374 | |
| 375 | ...; |
| 376 | --- [label="Regular RTP-AMR call using OSmux with batch factor 3 (has been ongoing for some time)"]; |
| 377 | |
| 378 | bts => bsc [label="RTP-AMR[seq=x,ssrc=MSa]"]; |
| 379 | bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSa]"]; |
| 380 | bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSa]"]; |
| 381 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(x),AMR(x+1),AMR(x+2)]]"]; |
| 382 | bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=x,ssrc=MSa)"]; |
| 383 | bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=x+1,ssrc=MSa)"]; |
| 384 | bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=x+2,ssrc=MSa)"]; |
| 385 | bts => bsc [label="RTP-AMR[seq=x+3,ssrc=MSa]"]; |
| 386 | bts => bsc [label="RTP-AMR[seq=x+4,ssrc=MSa]"]; |
| 387 | bts => bsc [label="RTP-AMR[seq=x+5,ssrc=MSa]"]; |
| 388 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(x+3),AMR(x+4),AMR(x+5)]]"]; |
| 389 | bscnat => mgw [label="RTP-AMR[seq=o+3,ssrc=r] (originally seq=x+3,ssrc=MSa)"]; |
| 390 | bscnat => mgw [label="RTP-AMR[seq=o+4,ssrc=r] (originally seq=x+4,ssrc=MSa)"]; |
| 391 | bscnat => mgw [label="RTP-AMR[seq=o+5,ssrc=r] (originally seq=x+5,ssrc=MSa)"]; |
| 392 | bts => bsc [label="RTP-AMR[seq=x+6,ssrc=MSa]"]; |
| 393 | bts => bsc [label="RTP-AMR[seq=x+7,ssrc=MSa]"]; |
| 394 | bts => bsc [label="RTP-AMR[seq=x+8,ssrc=MSa]"]; |
| 395 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+2,AMR(x+6),AMR(x+7),AMR(x+8)]]"]; |
| 396 | bscnat => mgw [label="RTP-AMR[seq=o+6,ssrc=r] (originally seq=x+6,ssrc=MSa)"]; |
| 397 | bscnat => mgw [label="RTP-AMR[seq=o+7,ssrc=r] (originally seq=x+7,ssrc=MSa)"]; |
| 398 | bscnat => mgw [label="RTP-AMR[seq=o+8,ssrc=r] (originally seq=x+8,ssrc=MSa)"]; |
| 399 | } |
| 400 | ---- |
| 401 | |
| 402 | === Trunking and Batching |
| 403 | |
| 404 | Following chart shows how trunking and batching work together. The chart shows 2 |
| 405 | concurrent calls from different MS on a given BTS, and BSC is configured with a |
| 406 | batch factor of 3. Again only uplink data is shown, but downlink follows the |
| 407 | same idea. Batching factor is set to 1 to easily illustrate trunking mechanism. |
| 408 | |
| 409 | ["mscgen"] |
| 410 | ---- |
| 411 | msc { |
| 412 | hscale = 2; |
| 413 | bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; |
| 414 | |
| 415 | ...; |
| 416 | --- [label="2 Regular RTP-AMR call using OSmux with batch factor 3 (has been ongoing for some time)"]; |
| 417 | |
| 418 | bts => bsc [label="RTP-AMR[seq=x,ssrc=MSa]"]; |
| 419 | bts => bsc [label="RTP-AMR[seq=y,ssrc=MSb]"]; |
| 420 | bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSa]"]; |
| 421 | bts => bsc [label="RTP-AMR[seq=y+1,ssrc=MSb]"]; |
| 422 | bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSa]"]; |
| 423 | bts => bsc [label="RTP-AMR[seq=y+2,ssrc=MSb]"]; |
| 424 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(x),AMR(x+1),AMR(x+2)],Osmux[ft=2,cid=i+1,seq=n,AMR(y),AMR(y+1),AMR(y+2)]]"]; |
| 425 | bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=x,ssrc=MSa)"]; |
| 426 | bscnat => mgw [label="RTP-AMR[seq=p,ssrc=s] (originally seq=y,ssrc=MSb)"]; |
| 427 | bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=x+1,ssrc=MSa)"]; |
| 428 | bscnat => mgw [label="RTP-AMR[seq=p+1,ssrc=s] (originally seq=y+1,ssrc=MSb)"]; |
| 429 | bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=x+2,ssrc=MSa)"]; |
| 430 | bscnat => mgw [label="RTP-AMR[seq=p+2,ssrc=s] (originally seq=y+2,ssrc=MSb)"]; |
| 431 | bts => bsc [label="RTP-AMR[seq=x+3,ssrc=MSa]"]; |
| 432 | bts => bsc [label="RTP-AMR[seq=y+3,ssrc=MSb]"]; |
| 433 | bts => bsc [label="RTP-AMR[seq=x+4,ssrc=MSa]"]; |
| 434 | bts => bsc [label="RTP-AMR[seq=y+4,ssrc=MSb]"]; |
| 435 | bts => bsc [label="RTP-AMR[seq=x+5,ssrc=MSa]"]; |
| 436 | bts => bsc [label="RTP-AMR[seq=y+5,ssrc=MSb]"]; |
| 437 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(x+3),AMR(x+4),AMR(x+5)],Osmux[ft=2,cid=i+1,seq=n+1,AMR(y+3),AMR(y+4),AMR(y+5)]]"]; |
| 438 | bscnat => mgw [label="RTP-AMR[seq=o+3,ssrc=r] (originally seq=x+3,ssrc=MSa)"]; |
| 439 | bscnat => mgw [label="RTP-AMR[seq=p+3,ssrc=s] (originally seq=y+3,ssrc=MSb)"]; |
| 440 | bscnat => mgw [label="RTP-AMR[seq=o+4,ssrc=r] (originally seq=x+4,ssrc=MSa)"]; |
| 441 | bscnat => mgw [label="RTP-AMR[seq=p+4,ssrc=s] (originally seq=y+4,ssrc=MSb)"]; |
| 442 | bscnat => mgw [label="RTP-AMR[seq=o+5,ssrc=r] (originally seq=x+5,ssrc=MSa)"]; |
| 443 | bscnat => mgw [label="RTP-AMR[seq=p+5,ssrc=s] (originally seq=y+5,ssrc=MSb)"]; |
| 444 | } |
| 445 | ---- |
| 446 | |
| 447 | === Marker bit |
| 448 | |
| 449 | As described earlier, the Marker bit is always expected to relate to the first |
| 450 | AMR payload of an OSmux frame. Thus, special considerations may be followed when |
| 451 | the OSmux encoder receives an RTP packet with a marker bit. For instance, |
| 452 | previously enqueued RTP packets may be sent even if the configured batch factor |
| 453 | is not reached. |
| 454 | |
| 455 | We again use the scenario with 2 concurrent calls and a batch factor of 3. |
| 456 | |
| 457 | ["mscgen"] |
| 458 | ---- |
| 459 | msc { |
| 460 | hscale = 2; |
| 461 | bts [label="BTS"], bsc [label="BSC"], bscnat [label="BSC-NAT"], mgw [label="MGW"]; |
| 462 | |
| 463 | ...; |
| 464 | --- [label="2 Regular RTP-AMR call using OSmux with batch factor 3 (has been ongoing for some time)"]; |
| 465 | |
| 466 | bts => bsc [label="RTP-AMR[seq=x,ssrc=MSa]"]; |
| 467 | bts => bsc [label="RTP-AMR[seq=y,ssrc=MSb]"]; |
| 468 | bts => bsc [label="RTP-AMR[seq=x+1,ssrc=MSa]"]; |
| 469 | bts => bsc [label="RTP-AMR[seq=y+1,ssrc=MSb]"]; |
| 470 | bts => bsc [label="RTP-AMR[seq=x+2,ssrc=MSa]"]; |
| 471 | bts => bsc [label="RTP-AMR[seq=y+2,ssrc=MSb]"]; |
| 472 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m,AMR(x),AMR(x+1),AMR(x+2)],Osmux[ft=2,cid=i+1,seq=n,AMR(y),AMR(y+1),AMR(y+2)]]"]; |
| 473 | bscnat => mgw [label="RTP-AMR[seq=o,ssrc=r] (originally seq=x,ssrc=MSa)"]; |
| 474 | bscnat => mgw [label="RTP-AMR[seq=p,ssrc=r] (originally seq=y,ssrc=MSb)"]; |
| 475 | bscnat => mgw [label="RTP-AMR[seq=o+1,ssrc=r] (originally seq=x+1,ssrc=MSa)"]; |
| 476 | bscnat => mgw [label="RTP-AMR[seq=p+1,ssrc=s] (originally seq=y+1,ssrc=MSb)"]; |
| 477 | bscnat => mgw [label="RTP-AMR[seq=o+2,ssrc=r] (originally seq=x+2,ssrc=MSa)"]; |
| 478 | bscnat => mgw [label="RTP-AMR[seq=p+2,ssrc=s] (originally seq=y+2,ssrc=MSb)"]; |
| 479 | bts => bsc [label="RTP-AMR[seq=x+3,ssrc=MSa]"]; |
| 480 | bts => bsc [label="RTP-AMR[seq=y+3,ssrc=MSb]"]; |
| 481 | bts => bsc [label="RTP-AMR[seq=x+4,ssrc=MSa]"]; |
| 482 | bts => bsc [label="RTP-AMR[seq=y+4,ssrc=MSb] with Marker bit set M=1"]; |
| 483 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+1,AMR(x+3),AMR(x+4)],Osmux[ft=2,cid=i+1,seq=n+1,AMR(y+3)]]"]; |
| 484 | bscnat => mgw [label="RTP-AMR[seq=o+3,ssrc=r] (originally seq=x+3,ssrc=MSa)"]; |
| 485 | bscnat => mgw [label="RTP-AMR[seq=p+3,ssrc=s] (originally seq=y+3,ssrc=MSb)"]; |
| 486 | bscnat => mgw [label="RTP-AMR[seq=o+4,ssrc=r] (originally seq=x+4,ssrc=MSa)"]; |
| 487 | bts => bsc [label="RTP-AMR[seq=x+5,ssrc=MSa]"]; |
| 488 | bts => bsc [label="RTP-AMR[seq=y+5,ssrc=MSb]"]; |
| 489 | bts => bsc [label="RTP-AMR[seq=x+6,ssrc=MSa]"]; |
| 490 | bts => bsc [label="RTP-AMR[seq=y+6,ssrc=MSb]"]; |
| 491 | bsc => bscnat [label="UDP[Osmux[ft=2,cid=i,seq=m+2,AMR(x+5),AMR(x+6)],Osmux[ft=2,cid=i+1,seq=n+2,AMR(y+4),AMR(y+5),AMR(y+6)]]"]; |
| 492 | bscnat => mgw [label="RTP-AMR[seq=p+4,ssrc=s] (originally seq=y+4,ssrc=MSb)"]; |
| 493 | bscnat => mgw [label="RTP-AMR[seq=o+5,ssrc=r] (originally seq=x+5,ssrc=MSa)"]; |
| 494 | bscnat => mgw [label="RTP-AMR[seq=p+5,ssrc=s] (originally seq=y+5,ssrc=MSb)"]; |
| 495 | bscnat => mgw [label="RTP-AMR[seq=o+6,ssrc=r] (originally seq=x+6,ssrc=MSa)"]; |
| 496 | bscnat => mgw [label="RTP-AMR[seq=p+6,ssrc=s] (originally seq=y+6,ssrc=MSb)"]; |
| 497 | } |
| 498 | ---- |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 499 | |
| 500 | == Evaluation: Expected traffic savings |
| 501 | |
Pau Espin Pedrol | 53ce68f | 2017-07-19 15:31:55 +0200 | [diff] [blame] | 502 | The following figure shows the growth in traffic saving (in %) depending on the |
| 503 | number of concurrent numbers of callings for a given set of batching factor |
| 504 | values: |
| 505 | |
| 506 | ["python2"] |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 507 | ---- |
Pau Espin Pedrol | 53ce68f | 2017-07-19 15:31:55 +0200 | [diff] [blame] | 508 | from pychart import * |
| 509 | theme.get_options() |
| 510 | theme.scale_factor = 5 |
| 511 | theme.use_color = 1 |
| 512 | theme.reinitialize() |
| 513 | |
| 514 | IP_HEADER=20 |
| 515 | UDP_HEADER=8 |
| 516 | RTP_HEADER=12 |
| 517 | OSMUX_HEADER=4 |
| 518 | AMR59_PAYLOAD=17 |
| 519 | |
| 520 | def osmux_get_size(calls, payloads): |
| 521 | return IP_HEADER + UDP_HEADER + (OSMUX_HEADER + AMR59_PAYLOAD * payloads) * calls |
| 522 | |
| 523 | def rtp_get_size(calls, payloads): |
| 524 | return calls * payloads * (IP_HEADER + UDP_HEADER + RTP_HEADER + AMR59_PAYLOAD) |
| 525 | |
| 526 | def calc_traffic_saving(calls, payloads): |
| 527 | return 100 - 100.0 * osmux_get_size(calls, payloads) / rtp_get_size(calls, payloads) |
| 528 | |
| 529 | # The first value in each tuple is the X value, and subsequent values are Y values for different lines. |
| 530 | def gen_table(): |
| 531 | data = [] |
| 532 | for calls in range(1, 9): |
| 533 | col = (calls,) |
| 534 | for factor in range(1, 9): |
| 535 | col += (calc_traffic_saving(calls, factor),) |
| 536 | data.append(col) |
| 537 | return data |
| 538 | |
| 539 | def do_plot(data): |
| 540 | xaxis = axis.X(format="/hL%d", tic_interval = 1, label="Concurrent calls") |
| 541 | yaxis = axis.Y(format="%d%%", tic_interval = 10, label="Traffic Saving") |
| 542 | ar = area.T(x_axis=xaxis, y_axis=yaxis, y_range=(None,None), x_grid_interval=1, x_grid_style=line_style.gray70_dash3) |
| 543 | for y in range(1, len(data[0])): |
| 544 | plot = line_plot.T(label="bfactor "+str(y), data=data, ycol=y, tick_mark=tick_mark.circle1) |
| 545 | ar.add_plot(plot) |
| 546 | ar.draw() |
| 547 | |
| 548 | data = gen_table() |
| 549 | do_plot(data) |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 550 | ---- |
| 551 | |
Pau Espin Pedrol | 53ce68f | 2017-07-19 15:31:55 +0200 | [diff] [blame] | 552 | The results show a saving of 15.79% with only one concurrent call and with |
| 553 | batching disabled (bfactor 1), that quickly improves with more concurrent calls |
| 554 | (due to trunking). |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 555 | |
Pau Espin Pedrol | 53ce68f | 2017-07-19 15:31:55 +0200 | [diff] [blame] | 556 | By increasing the batching of messages to 4, the results show a saving of 56.68% |
| 557 | with only one concurrent call. Trunking slightly improves the situation with |
| 558 | more concurrent calls. |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 559 | |
Pau Espin Pedrol | 53ce68f | 2017-07-19 15:31:55 +0200 | [diff] [blame] | 560 | A batching factor of 8 provides very little improvement with regards to batching |
| 561 | 4 messages. Still, we risk to degrade user experience. Thus, we consider a |
| 562 | batching factor of 3 and 4 is adecuate. |
Pau Espin Pedrol | b120272 | 2017-05-03 12:38:05 +0200 | [diff] [blame] | 563 | |
| 564 | == Other proposed follow-up works |
| 565 | |
| 566 | The following sections describe features that can be considered in the mid-run |
| 567 | to be included in the OSmux infrastructure. They will be considered for future |
| 568 | proposals as extensions to this work. Therefore, they are NOT included in |
| 569 | this proposal. |
| 570 | |
| 571 | === Encryption |
| 572 | |
| 573 | Voice streams within OSmux can be encrypted in a similar manner to SRTP |
| 574 | (RFC3711). The only potential problem is the use of a reduced sequence number, |
| 575 | as it wraps in (20ms * 2^256 * B), i.e. 5.12s to 40.96s. However, as the |
| 576 | receiver knows at which rate the codec frames are generated at the sender, he |
| 577 | should be able to compute how much time has passed using his own timebase. |
| 578 | |
| 579 | Another alternative can be the use of DTLS (RFC 6347) that can be used to |
| 580 | secure datagram traffic using TLS facilities (libraries like openssl and |
| 581 | gnutls already support this). |
| 582 | |
| 583 | === Multiple OSmux messages in one packet |
| 584 | |
| 585 | In case there is already at least one active voice call, there will be |
| 586 | regular transmissions of voice codec frames. Depending on the batching |
| 587 | factor, they will be sent every 70ms to 140ms. The size even of a |
| 588 | batched (and/or trunked) codec message is still much lower than the MTU. |
| 589 | |
| 590 | Thus, any signalling (related or unrelated to the call causing the codec |
| 591 | stream) can just be piggy-backed to the packets containing the voice |
| 592 | codec frames. |