- OpenBSC - lists.osmocom.org

SMS RP-Data spec violation. Somebody wants to fix it?
by Holger Hans Peter Freyther 09 Feb '14

09 Feb '14

Hi, I just looked at a trace and saw that the RP-MessageReference we assign is hardcoded to 42. It should be a sequence number going from 0 to 255. It is somehow idiotic as there can only be one SMS per direction and there is the transaction identifier as well. I would propose a patch that does: Change gsm411_send_sms to ask the subscriber connection/transaction code for a message reference. For added bonus also "put" the number so we could verify to not re-use the number too early. anyones wants to come up with a fix? holger

2 5

possible bug in OpenBSC
by Ciaby 07 Feb '14

07 Feb '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi all, we are currently experiencing some issues with OpenBSC paired with a sysmobts-2050. SDCCH channels are getting stick into BROKEN/UNUSABLE state, and they don't get released. This accumulates over time and reaches a point where we have to manually restart osmo-nitb because there are no channels availables and the whole network breaks down. Is it a know issue or only us? :) This is the "show lchan" output: BTS 0, TRX 0, Timeslot 0, Lchan 0: Type SDCCH Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -87 dBm, RXL-SUB-ul: -47 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 1, TRX 0, Timeslot 0, Lchan 2: Type NONE Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 BTS 1, TRX 0, Timeslot 0, Lchan 3: Type NONE Connection: 0, State: BROKEN UNUSABLE BS Power: 37 dBm, MS Power: 39 dBm No Subscriber Bound IP: 0.0.0.0 Port 0 RTP_TYPE2=0 CONN_ID=0 Measurement Report: Flags: DLinval RXL-FULL-ul: -110 dBm, RXL-SUB-ul: -110 dBm RXQ-FULL-ul: 0, RXQ-SUB-ul: 0 Timeslot 0 is configured as CCCH+SDCCH4. Cheers Ciaby -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREKAAYFAlL0A7MACgkQC30ZhxNccpEr7QD/WugVMQo5LW1u2RVNeK6TL6Rx hNl/h7f2UB/3lhedCTIBALcMXoglpdx/CLIo5nrZVQqoVVRCTD8Jd6UzQFtbejx+ =l7KL -----END PGP SIGNATURE-----

2 1

Fwd: [dispatch] SIP and GSM/UMTS with OpenBTS
by Jim Forster 05 Feb '14

05 Feb '14

Dear list members, I posted the following message to the IETF DISPATCH mailing list earlier today. It's got a bit of a lengthy intro, as that community is not familiar with OpenBTS (and probably not OpenBSC either), and in preliminary discussions with them it was clear that it needed a good explanation. I invite you all to join the IETF DISPATCH list, and participate in the discussion. Tim Panton has already raised some good points. See http://trac.tools.ietf.org/wg/dispatch/trac/wiki for info about the DISPATCH group and https://www.ietf.org/mailman/listinfo/dispatch to join the list. -- Jim Range Networks Begin forwarded message: > From: Jim Forster <jim.forster(a)rangenetworks.com> > Subject: [dispatch] SIP and GSM/UMTS with OpenBTS > Date: February 5, 2014 at 12:09:45 PM GMT+5:30 > To: "dispatch(a)ietf.org" <dispatch(a)ietf.org> > > Dear DISPATCH group, > > OpenBTS and OpenBSC are projects are combining GSM phones and SIP in new and interesting ways. I think there is some value to the community in discussing these in the DISPATCH mailing list and having an related meeting at the London IETF. There is both some short-term, relatively straightforward work to be done to agree on the usage of SIP in these existing implementations. There may also be some very interesting work to be done on more advanced approaches. > > First, some background: OpenBTS is an open source project started by the founders of Range Networks to make a 'GSM system in a box', by implementing a system which supports the air interface for GSM phones (Um) using a Software Defined Radio (SDR) for the RF. While the GSM & 3GPP defined air interface to the phones is supported, OpenBTS diverges from these standards by immediately gatewaying the call to SIP. Each GSM or UMTS phone can then appear on the Internet as a SIP endpoint. A local SIP switching decision is made to route the call; Asterix, Freeswitch, Yate have been. The call is then sent to another local connected phone or to some other SIP service point on the Internet. > > With this in place, because the air interface to the phones is supported with no changes, standard GSM/UMTS phones can make calls to other phones on the same OpenBTS system or to any SIP endpoint on the Internet, and thence to the PSTN via any of the many SIP-PSTN gateways in operation. > > A fair question would be "Why do all this? What's wrong with GSM & 3GPP systems?". One reason is that the OpenBTS approach allows very small, stand alone systems, which efficiently connect GSM and UMTS phones to the Internet based SIP systems with a minimum of other systems. Certainly GSM/3GPP based micro cells exist, but are tied to the 3GPP 'Core' which is usually beyond the means of smaller users. OpenBTS aspires to be the simplest way for a GSM/UMTS phone to make phone calls to the SIP & PSTN world. > > At least several hundred, and likely several thousand of these systems are deployed already. Many are in labs, but others are production usage on all continents. Universities find these systems very attractive for teaching and researching: all the code from RF to Signaling is visible and may be changed as desired. > > Furthermore, additional SDRs are popping up all the time. There are 3-4 separate SDR based systems that run OpenBTS and more are coming. Right now they range from $2000 up, but it's easy to see them dropping to $500 or so this year; even Kickstarter campaigns are funding some of them. There's no natural floor below that; adding GSM/UMTS to a home router and making it a micro-cell running SIP to the Internet could conceivably be a $10 HW delta and some more SW. Secondly, there are several countries that have unlicensed GSM band (Sweden, Netherlands, UK?) so some efforts are underway to do exactly that. > > When facing the Internet, OpenBTS is simply a SIP client. However, to assure interoperability, there may be value in standardized behavior, including these issues: > > * Which elements of SIP are needed for this operation? > * Should these be documented in a profile of SIP usage to be OpenBTS Ready? > * Should ICE be recommended or possibly be required for operation behind NATs? > * What about BTS-BTS neighbor discovery > * Use of SIP Re-invite for hand-over when a mobile phone moves from one BTS to a neighbor > * For somewhat different use cases: one could separate signaling from media transport and thus might support WebRTC or other such systems. E.164 addresses are used in phones, but temporary numbers can be assigned as needed (as done in Roaming) and not surfaced to the WebRTC level. > * What Changes required for IPv6? > * Required and recommended security provisions > * Is IETF an appropriate forum for this, or should it be in 3GPP, or Sipforum.org, or a separate industry group formed? > > I look forward to discussion on the mailing list, and hopefully meeting and discussing in London. > > Yours, > > Jim Forster > Range Networks > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

1 0

OsmoDevCon 2014: CFP
by Sylvain Munaut 05 Feb '14

05 Feb '14

Dear all, Time has come to fill out the "Talks/Discussions/Workshop / Hacking" section of the wiki page. If you have something you'd like to present, talk about or hack on, add it there. A simple descriptive title along with an estimated duration is enough. I guess we'll collect those for 2/3 weeks and then start making the schedule. Cheers, Sylvain

1 0

GPRS vs. voice with openbsc
by Ralph A. Schmid, dk5ras 03 Feb '14

03 Feb '14

Hi out there, I am using OpenBTS with an USRP1, so not absolutely on-topic here, but I have here some effects with GPRS that are a bit annoying, and I would like to ask if something similar is known with the openbsc familiy when using GPRS. GPRS works, but with a reduced operating distance. While voice and SMS work over 200m (USRP1, WBX, small omni antennae) GPRS stops after 20-25 m, when downlink level is around -70dBm. Digging a bit deeper showed me that GPRS uses a somehow strange power control model, not a closed loop but a kind of dedicated guess, derived from the downlink RSSI at the ME. Setting the corresponding gamma value has a strong influence, but even with its lowest value I do not reach more than those 25m, and I can reduce the operating range to 2m with it. Playing with rxgain and other parameters did not really improve things. Is similar behavior known with the openbsc familiy GSM systems? I even know similar effects from commercial operators (O2 Germany with EDGE), not knowing if it is the same issue or something completely different. A first glance at some documents showed me that this power level calculation seems to be normal - is there really no closed loop for GPRS available? With best regards Ralph.

3 4

Calls from BTS to PTSN planification doubts
by Diego Fernandez Alonso 03 Feb '14

03 Feb '14

Hello, my name is Diego. I've a configurated sysmoBTS in OpenBSC network-in-the-box (NITB) mode, and the osmo-nitb is working fine, doing and receiving calls and messages between the phones connected to the sysmoBTS network. At this point I would need to call outside the OpenBSC, and I would be very gratefull if someone could help me with some doubts I have. I'm new in this. For the isdn card capable of NT-mode, I've seen the "OpenVox B200P 2-port ISDN BRI PCI" card for buying, but: 1-An "OpenVox B100P ISDN BRI PCI" card, with only one RJ45 female connector, could be used correctly, working together with an already installed PCI Ethernet Controller card? Or, is it better an isdn card with two RJ45 connectors in the same card? One for connecting the BTS to the computer, and the another for connecting the computer to a LAN through a router or switch? I would like to avoid to cut cables as the LCR guide says, http://isdn.eversberg.eu/download/doc-1.4/linux-call-router-1.4_1.pdf, and the problems with the cross over and not crossed cables. 2-The "Howto OpenBSC with Asterisk and LCR" guide, http://openbsc.osmocom.org/trac/wiki/OpenBSC_LCR, indicates that it's necessary compile and install LibOsmocore and OpenBSC, but the OpenBSC/OsmoNITB inside the sysmoBTS is working, so I'm not sure about this step. If the solution is to build, configure and run OpenBSC/OsmoNITB + OsmoSGSN + OpenGGSN on a PC and configure the sysmoBTS to connect to this, should I change the image of the BTS and its whole configuration? 3-Although I don't have the isdn card yet, for testing some configurations in the PC I followed the "Building and Running OpenBSC with Asterisk" Pierre Kim guide, that I believe is newer than the "How to OpenBSC with Asterisk and LCR", and I haven't problems with the installations. So if I run the lcr: # lcr start ** LCR Version 1.14 LCR 1.14 started, waiting for calls... and running the osmo-nitb: # ./osmo-nitb -m -P DB: Database initialized. DB: Database prepared. My question in this point, is it only necessary to connect the BTS to the isdn card with the right OpenBSC to finish the system configuration? Many thanks for your time and for your work. Kindest regards, Diego.

2 1

[PATCH 1/5] mgcp/test: Only include conn_mode into test output
by Jacob Erlbeck 31 Jan '14

31 Jan '14

Currently the conn_mode and the output_enabled flags are printed to stdout. This patch modifies this to print the output_enabled flags to stderr instead. The bits in conn_mode are shown as RECV, SEND, and LOOP. This does not reduce the significance of the test, since there is an assertion already that verifies the values of the output_enabled flags with respect to the conn_mode. Sponsored-by: On-Waves ehf --- openbsc/tests/mgcp/mgcp_test.c | 21 +++++++++++++++------ openbsc/tests/mgcp/mgcp_test.ok | 18 +++++++++--------- 2 files changed, 24 insertions(+), 15 deletions(-) diff --git a/openbsc/tests/mgcp/mgcp_test.c b/openbsc/tests/mgcp/mgcp_test.c index fa68867..5f69072 100644 --- a/openbsc/tests/mgcp/mgcp_test.c +++ b/openbsc/tests/mgcp/mgcp_test.c @@ -399,13 +399,22 @@ static void test_messages(void) else printf("Requested packetization period not set\n"); - if ((endp->conn_mode & CONN_UNMODIFIED) == 0) - printf("Connection mode: %d, " - "BTS output %sabled, NET output %sabled\n", + if ((endp->conn_mode & CONN_UNMODIFIED) == 0) { + printf("Connection mode: %d:%s%s%s%s\n", endp->conn_mode, - endp->bts_end.output_enabled ? "en" : "dis", - endp->net_end.output_enabled ? "en" : "dis"); - else + !endp->conn_mode ? " NONE" : "", + endp->conn_mode & MGCP_CONN_SEND_ONLY ? + " SEND" : "", + endp->conn_mode & MGCP_CONN_RECV_ONLY ? + " RECV" : "", + endp->conn_mode & MGCP_CONN_LOOPBACK & + ~MGCP_CONN_RECV_SEND ? + " LOOP" : ""); + fprintf(stderr, + "BTS output %sabled, NET output %sabled\n", + endp->bts_end.output_enabled ? "en" : "dis", + endp->net_end.output_enabled ? "en" : "dis"); + } else printf("Connection mode not set\n"); OSMO_ASSERT(endp->net_end.output_enabled == diff --git a/openbsc/tests/mgcp/mgcp_test.ok b/openbsc/tests/mgcp/mgcp_test.ok index fbe2566..76806f9 100644 --- a/openbsc/tests/mgcp/mgcp_test.ok +++ b/openbsc/tests/mgcp/mgcp_test.ok @@ -19,7 +19,7 @@ Testing CRCX Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 1, BTS output enabled, NET output disabled +Connection mode: 1: RECV Testing MDCX3 Dummy packets: 1 Packet duration not set @@ -29,35 +29,35 @@ Testing MDCX4 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT1 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-40 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT2 Dummy packets: 1 Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_PT3 Dummy packets: 1 Detected packet duration: 40 Requested packetization period not set -Connection mode: 3, BTS output enabled, NET output enabled +Connection mode: 3: SEND RECV Testing MDCX4_SO Detected packet duration: 40 Requested packetetization period: 20-20 -Connection mode: 2, BTS output disabled, NET output enabled +Connection mode: 2: SEND Testing DLCX Detected packet duration: 20 Requested packetization period not set -Connection mode: 0, BTS output disabled, NET output disabled +Connection mode: 0: NONE Testing CRCX_ZYN Dummy packets: 1 Packet duration not set Requested packetization period not set -Connection mode: 1, BTS output enabled, NET output disabled +Connection mode: 1: RECV Testing EMPTY Testing SHORT1 Testing SHORT2 @@ -68,7 +68,7 @@ Testing RQNT2 Testing DLCX Detected packet duration: 20 Requested packetization period not set -Connection mode: 0, BTS output disabled, NET output disabled +Connection mode: 0: NONE Testing CRCX Re-transmitting CRCX Testing RQNT1 -- 1.7.9.5

2 9

[PATCH 1/9] Complete definitions for all speech traffic frames at MNCC interface
by Andreas Eversberg 31 Jan '14

31 Jan '14

The new definitions are: half rate and AMR Change of definition name for bad frame, because it applies to all types of traffic, not only TCH/F. Increase MNCC interface version to 4. --- openbsc/include/openbsc/mncc.h | 6 ++++-- openbsc/src/libmsc/mncc.c | 6 +++++- openbsc/src/libtrau/trau_mux.c | 2 +- openbsc/tests/trau/trau_test.c | 2 +- 4 files changed, 11 insertions(+), 5 deletions(-) diff --git a/openbsc/include/openbsc/mncc.h b/openbsc/include/openbsc/mncc.h index ffc247b..c61f6b8 100644 --- a/openbsc/include/openbsc/mncc.h +++ b/openbsc/include/openbsc/mncc.h @@ -95,7 +95,9 @@ struct gsm_call { #define GSM_TCHF_FRAME 0x0300 #define GSM_TCHF_FRAME_EFR 0x0301 -#define GSM_TCHF_BAD_FRAME 0x03ff +#define GSM_TCHH_FRAME 0x0302 +#define GSM_TCH_FRAME_AMR 0x0303 +#define GSM_BAD_FRAME 0x03ff #define MNCC_SOCKET_HELLO 0x0400 @@ -161,7 +163,7 @@ struct gsm_data_frame { unsigned char data[0]; }; -#define MNCC_SOCK_VERSION 2 +#define MNCC_SOCK_VERSION 4 struct gsm_mncc_hello { uint32_t msg_type; uint32_t version; diff --git a/openbsc/src/libmsc/mncc.c b/openbsc/src/libmsc/mncc.c index b484772..73db5f0 100644 --- a/openbsc/src/libmsc/mncc.c +++ b/openbsc/src/libmsc/mncc.c @@ -84,7 +84,11 @@ static struct mncc_names { {"MNCC_FRAME_DROP", 0x0202}, {"MNCC_LCHAN_MODIFY", 0x0203}, - {"GSM_TCH_FRAME", 0x0300}, + {"GSM_TCHF_FRAME", 0x0300}, + {"GSM_TCHF_FRAME_EFR", 0x0301}, + {"GSM_TCHH_FRAME", 0x0302}, + {"GSM_TCH_FRAME_AMR", 0x0303}, + {"GSM_BAD_FRAME", 0x03ff}, {NULL, 0} }; diff --git a/openbsc/src/libtrau/trau_mux.c b/openbsc/src/libtrau/trau_mux.c index 7b9bac0..fd1895f 100644 --- a/openbsc/src/libtrau/trau_mux.c +++ b/openbsc/src/libtrau/trau_mux.c @@ -314,7 +314,7 @@ struct msgb *trau_decode_efr(uint32_t callref, return msg; bad_frame: - frame->msg_type = GSM_TCHF_BAD_FRAME; + frame->msg_type = GSM_BAD_FRAME; return msg; } diff --git a/openbsc/tests/trau/trau_test.c b/openbsc/tests/trau/trau_test.c index f8a48db..b95f1e8 100644 --- a/openbsc/tests/trau/trau_test.c +++ b/openbsc/tests/trau/trau_test.c @@ -57,7 +57,7 @@ void test_trau_fr_efr(unsigned char *data) msg = trau_decode_efr(1, &tf); OSMO_ASSERT(msg != NULL); frame = (struct gsm_data_frame *)msg->data; - OSMO_ASSERT(frame->msg_type == GSM_TCHF_BAD_FRAME); + OSMO_ASSERT(frame->msg_type == GSM_BAD_FRAME); msgb_free(msg); } -- 1.8.1.5 --------------060708050209070502020504 Content-Type: text/x-diff; name="0002-Use-helper-function-to-check-if-an-MNCC-frame-is-dat.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0002-Use-helper-function-to-check-if-an-MNCC-frame-is-dat.pa"; filename*1="tch"

1 0

[PATCH] sms/dtap: Add log messages to analyse SMS message loss
by Jacob Erlbeck 30 Jan '14

30 Jan '14

Incoming DTAP messages from MS are discarded during silent calls, which leads to the repeated delivery of SMS since the ACKs are not being processed. This patch adds some log messages that have been helpful to track this down. Sponsored-by: On-Waves ehf --- openbsc/src/libmsc/gsm_04_08.c | 1 + openbsc/src/libmsc/osmo_msc.c | 4 ++++ openbsc/src/libmsc/silent_call.c | 5 +++++ 3 files changed, 10 insertions(+) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index bc4a9c3..cd2a0b5 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -3303,6 +3303,7 @@ int gsm0408_dispatch(struct gsm_subscriber_connection *conn, struct msgb *msg) uint8_t pdisc = gh->proto_discr & 0x0f; int rc = 0; + LOGP(DRLL, LOGL_DEBUG, "Dispatching 04.08 message, pdisc=%d\n", pdisc); if (silent_call_reroute(conn, msg)) return silent_call_rx(conn, msg); diff --git a/openbsc/src/libmsc/osmo_msc.c b/openbsc/src/libmsc/osmo_msc.c index 31b72b9..f3badb7 100644 --- a/openbsc/src/libmsc/osmo_msc.c +++ b/openbsc/src/libmsc/osmo_msc.c @@ -59,6 +59,8 @@ static int msc_compl_l3(struct gsm_subscriber_connection *conn, struct msgb *msg return BSC_API_CONN_POL_ACCEPT; if (trans_has_conn(conn)) return BSC_API_CONN_POL_ACCEPT; + + LOGP(DRR, LOGL_INFO, "MSC Complete L3: Rejecting connection.\n"); return BSC_API_CONN_POL_REJECT; } @@ -71,11 +73,13 @@ static void msc_assign_compl(struct gsm_subscriber_connection *conn, uint8_t rr_cause, uint8_t chosen_channel, uint8_t encr_alg_id, uint8_t speec) { + LOGP(DRR, LOGL_DEBUG, "MSC assign complete (do nothing).\n"); } static void msc_assign_fail(struct gsm_subscriber_connection *conn, uint8_t cause, uint8_t *rr_cause) { + LOGP(DRR, LOGL_DEBUG, "MSC assign failure (do nothing).\n"); } static void msc_classmark_chg(struct gsm_subscriber_connection *conn, diff --git a/openbsc/src/libmsc/silent_call.c b/openbsc/src/libmsc/silent_call.c index cdc82b5..4462dfc 100644 --- a/openbsc/src/libmsc/silent_call.c +++ b/openbsc/src/libmsc/silent_call.c @@ -76,6 +76,7 @@ static int paging_cb_silent(unsigned int hooknum, unsigned int event, int silent_call_rx(struct gsm_subscriber_connection *conn, struct msgb *msg) { /* FIXME: do something like sending it through a UDP port */ + LOGP(DLSMS, LOGL_NOTICE, "Discarding L3 message from a silent call.\n"); return 0; } @@ -109,6 +110,7 @@ int silent_call_reroute(struct gsm_subscriber_connection *conn, struct msgb *msg } /* otherwise, reroute */ + LOGP(DLSMS, LOGL_INFO, "Rerouting L3 message from a silent call.\n"); return 1; } @@ -136,6 +138,9 @@ int gsm_silent_call_stop(struct gsm_subscriber *subscr) if (!conn->silent_call) return -EINVAL; + DEBUGPC(DLSMS, "Stopping silent call using Timeslot %u on ARFCN %u\n", + conn->lchan->ts->nr, conn->lchan->ts->trx->arfcn); + conn->silent_call = 0; msc_release_connection(conn); -- 1.7.9.5

1 0

Re: RF power problems with current master of osmo-trx
by Tom Tsou 30 Jan '14

30 Jan '14

On Sat, Jan 25, 2014 at 2:57 AM, Andreas Eversberg <andreas(a)eversberg.eu> wrote: > so when i stop sending the bursts, the filler table will continue to > transmit bursts. do i understand it correctly: if i send a single idle burst > (frame??) after sending bursts, the filler table is disabled until new > bursts are sent? Sorry, I misspoke about disabling transmission. The filler table resends the last burst in the multiframe, so the idle burst is usually just a dummy burst, which does not actually stop physical transmission. To fully turn off the downlink signal on a particular slot requires disabling the slot by the channel combination. That said, I agree with Alexander that the retransmission portion of the filler table should be turned off because the behavior is incorrect. With a few exceptions (e.g. FCCH), bursts should *not* be retransmitted at L1 and doing so generates an invalid signal. Note that the filler table cannot be completely disabled because it is part of the real-time loop that drives the device I/O. If the upper layer does not send a burst for a particular slot, or that burst arrives late (stale burst), something still must be transmitted. Currently, in that case, the burst comes from the filler table if the slot is active or zeros if the slot is turned off. Again, I do not think the current implementation is entirely correct, but that depends on expectations of the upper layers. -TT

3 10