- OpenBSC - lists.osmocom.org

Refreshing/Resetting UICC (SysmoISIM-SJA2)

by bryan coxwell

Hi all, I have a SysmoISIM-SJA2 which I believe doesn't have a CAT application and doesn't support the SUSPEND APDU (per the manual). Given that, is there any way to reset/refresh the card through APDU commands (or through any other means)? Would something along the lines of deactivating and then reactivating the USIM application work? Thanks, Bryan

2 years, 4 months

2
4
0 0

lists.osmocom.org migrated to mailman3

by Harald Welte

Dear Osmocom community, today our mailing list server lists.osmocom.org has finally been migrated from mailman2-on-freebsd to mailman3-on-linux. This also included a variety of changes to DNS. I'll spare you the details, but everything _should_ be up and running now. * The List-Id headers should not have changed. * all list subscriptions + user accounts have been converted. * old 'static html' archives are still available (read only) at URLs like https://lists.osmocom.org/pipermail/baseband-devel/ * old List URLs like https://lists.osmocom.org/mailman/listinfo/baseband-devel are redirected to their respective modern counterparts In case you notice any mailing list related problem, please don't hesitate to contact me. Happy hacking, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

those harmonics) must be above: -30 dBm @ 30 kHz span above 1 GHz -36 dBm @ 30 kHz span below 1 GHz In case of UmTRX without an amplifier it's enough to use a ceramic or SAW duplexer to bring harmonics below those levels. For those buying UmTRX's as a lab package of universal UmDESKs, we offer to buy an external ceramic duplexers. These improves coverage and solves the out of band noise issues. For those buying band-specific UmDESK's, we use SAW duplexers, which are even more efficient in reducing out of band noise. >> A calibrated USRP N200 running osmo-trx passes RF spectrum and >> modulation accuracy requirements of 3GPP 05.05 by very large margins >> and is competitive with commercial GSM equipment in this regard. Other >> SDR devices are also capable to varying degrees. > > The policy of FCC vs. European Union is quite different. There are more > norms that apply in Europe. You're obviously more proficient in European norms. Could you point me to a link where we could find these differences between the ETSI published GSM Standard and European harmonized norms? It would be a very good addition to the OpenBSC wiki's "Standards" page. --=20 Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

2 years, 4 months

1
0
0 0

None

by None

cell into=20 operation, but during normal operation?! > -- > Regards, > Alexander Chemeris. > CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E = =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0=B8=D0=BE > http://fairwaves.ru Ralph.

2 years, 4 months

1
0
0 0

None

by None

> Anyway, I thought that the GPRS support is part of the OpenBTS > development, and any hardware that can run OpenBTS is also capable of > doing GPRS, but it is clear, that there are differences in the level > of support, even between SDR like devices. The majority of the code of osmo-pcu has been contributed by or on behalf of sysmocom. If you take a look at the development of the PCU for the last 6 months you will clearly see that sysmocom is doing all the work. Just like with OpenBSC a lot of others benefit from our work though. ;) > I still think that it would be nice, to clarify all this packet data > related stuff on the site.

2 years, 4 months

1
0
0 0

None

by None

* When an external protocol changes, the version number needs to change. I added MNCC protocol versioning as OpenBSC and LCR were out of sync and then funny things happened. This one line change of the version number can save you hours in debugging! * When a new feature is added, ask for a testcase. E.g. specially the E1 bit fiddling as it is so rarely used that it is likely to bitrot. * Check the error paths. Developers tend to only test with a single phone, not run into error paths, not force them to be taken during development (faul injection). * For things like device work-arounds ask if they are really necessary, e.g. I have my doubts for the RTP timestamp handling. * General code hygiene. Don't have the action take place four tabs in in a thousand line code method, don't use magic numbers, don't repeat yourself etc. Code is read a lot more than it is written. Besides smaller methods being easier to write unit tests for, they are easier to understand/review. I have merged two patches from this patchset but they required multiple rounds and my spare time is really limited. cheers holger

2 years, 4 months

1
0
0 0

None

by None

it should return gsm_phys_chan_config? In the implementation we do have: static const enum abis_nm_chan_comb chcomb4pchan[] = { and at the indexes we use values from gsm_phys_chan_config. Do you think the below is correct? holger diff --git a/include/osmocom/gsm/abis_nm.h b/include/osmocom/gsm/abis_nm.h index 4dee012..4682ead 100644 --- a/include/osmocom/gsm/abis_nm.h +++ b/include/osmocom/gsm/abis_nm.h @@ -43,7 +43,7 @@ const char *abis_nm_test_name(uint8_t test); int abis_nm_chcomb4pchan(enum gsm_phys_chan_config pchan); -enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb); +enum gsm_phys_chan_config abis_nm_pchan4chcomb(uint8_t chcomb); /*! @} */ diff --git a/src/gsm/abis_nm.c b/src/gsm/abis_nm.c index bb7008b..2c8f871 100644 --- a/src/gsm/abis_nm.c +++ b/src/gsm/abis_nm.c @@ -407,7 +407,7 @@ const struct value_string abis_nm_adm_state_names[] = { { 0, NULL } }; -static const enum abis_nm_chan_comb chcomb4pchan[] = { +static const enum gsm_phys_chan_config chcomb4pchan[] = { [GSM_PCHAN_NONE] = 0xff, [GSM_PCHAN_CCCH] = NM_CHANC_mainBCCH, [GSM_PCHAN_CCCH_SDCCH4] = NM_CHANC_BCCHComb, @@ -430,7 +430,7 @@ int abis_nm_chcomb4pchan(enum gsm_phys_chan_config pchan) } /*! \brief Obtain physical channel config for OML Channel Combination */ -enum abis_nm_chan_comb abis_nm_pchan4chcomb(uint8_t chcomb) +enum gsm_phys_chan_config abis_nm_pchan4chcomb(uint8_t chcomb) { int i; for (i = 0; i < ARRAY_SIZE(chcomb4pchan); i++) {

2 years, 4 months

1
0
0 0

None

by None

<div><br></div><div>" #if defined(L1_HAS_EFR) && defined(USE_L= 1_RTP_MODE) "</div><div><br></div><div>is why I'm seeing this mess= age logged, but it seems to be #define...</div><div><br></div><div>Any poin= ters, ideas ? This doesn't seem like a configuration thing, but a compi= lation time option?</div> <div>I'd have expected that EFR is fully supported?</div><div><br></div= ><div><br></div><div>osmo-bts.cfg snippet</div><div>-----------------------= -------</div><div><div>bts 0</div><div>=A0band 850</div><div>=A0ipa unit-id= 1801 0</div> <div>=A0oml remote-ip 127.0.0.1</div><div>=A0rtp jitter-buffer 100</div><di= v>=A0paging queue-size 200</div><div>=A0paging lifetime 0</div><div>=A0trx = 0</div><div>=A0 clock-calibration 603</div><div>=A0 trx-calibration-path (n= ull)</div> <div>=A0 clock-source ocxo</div><div>=A0 uplink-power-target -75</div><div>= =A0 min-qual-rach -5</div><div>=A0 min-qual-norm -5</div></div><div><br></d= iv><div><br></div><div><br></div><div>Regards,</div><div>Roelf.</div><div><= br></div> </div> --bcaec51b1b6f7f08e204e11a4392--

2 years, 4 months

1
0
0 0

None

by None

I deduct that " #if defined(L1_HAS_EFR) && defined(USE_L1_RTP_MODE) " is why I'm seeing this message logged, but it seems to be #define... Any pointers, ideas ? This doesn't seem like a configuration thing, but a compilation time option? I'd have expected that EFR is fully supported? osmo-bts.cfg snippet ------------------------------ bts 0 band 850 ipa unit-id 1801 0 oml remote-ip 127.0.0.1 rtp jitter-buffer 100 paging queue-size 200 paging lifetime 0 trx 0 clock-calibration 603 trx-calibration-path (null) clock-source ocxo uplink-power-target -75 min-qual-rach -5 min-qual-norm -5 Regards, Roelf. --bcaec51b1b6f7f08e204e11a4392 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>I have FINALLY gotten to play with my sysmoBTS acquired many months ag= o, and updated to the latest packages using okpg, and am running a NITB.</d= iv><div><br></div><div>GSM850 test setup in open mode A5/0, and I can SMS a= nd call between devices.</div> <div><br></div><div>However, there is no audio, and BTS console logs report= s many repeats of the following during an established call.</div><div><br><= /div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type= EFR is unsupported<div> <0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss=3D0) Rx Payload Type EFR = is unsupported</div><div><0006> tch.c:601 (bts=3D0,trx=3D0,ts=3D7,ss= =3D0) Rx Payload Type EFR is unsupported</div><div><br><div><br></div><div>=

2 years, 4 months

1
0
0 0

None

by None

the script? Libosmocore and install it as part of it? A new repo?

2 years, 4 months

1
0
0 0

None

by None

about it and demonstrate it operating OpenBTS and OsmoBTS. I could talk about our open-source development of OpenBTS, if there would be any interest. Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only few people heard about OsmoBTS, while it provides great capabilities: * it works with off-the-shelf SDR transceivers like UmTRX * it could use VoIP (SIP) soft-switches to connect calls * it connects to MSCs of legacy GSM networks * it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta) * standards compliant L1/L2 layers, so there are no issues with various phone models I love Osmocom approach to development as well - development is open to all contributors, the code is well structured and tested, even build results for all sub-projects are available through a continuous integration suite: http://jenkins.osmocom.org/jenkins/ On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe(a)close-haul.com> wrote: > (Apologies for cross-posting. We wanted to reach everyone who might be > interested in attending. Please respond responsibly.) > > Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robi= n > Coxe (Close-Haul Communications & Analog Devices) invite those interested= in > open GSM hardware and software development to an informal gathering in > Cambridge, MA on Friday 10 May 2013 from 6-8 pm. Alexander will be visit= ing > the Boston area from Moscow. > > If you are interested in participating in any capacity in the Boston-area > open source GSM development community, we look forward to meeting you. O= ur > goal is to identify like-minded people involved in or interested in learn= ing > more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC. > If you have a portable, self-contained demo, feel free to bring it with y= ou. > > When: Friday 10 May 2013, 6-8 pm EDT > Where: Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA > 02142 USA > Photo ID required for building entry. > > Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/ > > > > > > > > --=20 Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

2 years, 4 months

1
0
0 0

None

by None

keep doing the same style. Good food makes a brain work better. > Venue-wise, I would again suggest to hold it in Berlin, as it's > reasonbly well connected, has lots of low-cost flights to it, > accomodation is not too expensive and holger/me/sysmocom can take care > of local organization related activities. Hoewver, if somebody has a > strong opinion against berlin _and_ is willing to organize it, I'm not > completely against another venue. Berlin is perfect. -- Regards, Alexander Chemeris. CEO, Fairwaves LLC / =D0=9E=D0=9E=D0=9E =D0=A3=D0=BC=D0=A0=D0=B0=D0=B4=D0= =B8=D0=BE http://fairwaves.ru

2 years, 4 months

1
0
0 0

None

by None

of what if the msgb is 'borrowed' or 'owned/transferred'. Whenever we reach a _send method we actually transfer the ownership (as the data might be queued or such). The other technical part is to make sure we first establish a rule by 1.) adding doxygen/API documentation to the sendmsg function 2.) maybe look into introducing dummy annotations like __borrow, __takes that we could autocheck in the future (e.g. by extending spaze/smack) The issue with reviewing such a patch is the question if you have catched everything. E.g. I think you missed need to convert (and what it calls): static int gprs_ns_tx(struct gprs_nsvc *nsvc, struct msgb *msg) { ... default: LOGP(DNS, LOGL_ERROR, "unsupported NS linklayer %u\n", nsvc->ll); msgb_free(msg); ret = -EIO; break; } return ret; } > As reported in ticket #55 SGSN can crash due to double free-ing. You > can replace 'can' by 'will' in that last phrase. I had a sift through > the code and tried to solve this by removing the free in gprs_ns.c. > Whenever the calling function created the msgb-struct, I have made the > function free it after its use. If the function got the msgb from a > calling function, there will not be a free (hoping that will be done > on the higher level). > > HTH/F

2 years, 4 months

1
0
0 0

None

by None

If you need higher bitrates, implementing header and payload compression at the SNDCP level in the SGSN is possible. Also, always keep in mind that while you can offer 7 TS with GPRS/EDGE, almost no phone has support for a multislot class that allows for 7 TS in DL. So multiple phones can fill the 7 TS, but it's unlikely one phone can use all of them. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

primitives have to be implemented: * incoming MT-FORWARD-SM.req from external program * positive/negative MT-FORWARD-SM.resp depending on success of transfer * outgoing READY-FOR-SM.req in case a subscriber is coming online and/or we get a SMMA * outgoing MO-FORWARD-SM.req to external program As osmo-nitb at the moment still includes the HLR (which I desparately want to change), it probably should implement the procedures related to SMS delivery: * no need fro SRI-FOR-SM! * incoming REPORT-SM-DELIVER-STATUS.req, noting down that the SMSC has requested to be informed once a subscriber is back online * outgoing ALERT-SERVICE-CENTRE.req to SMSC once the subscriber really is back online. Now the desing questions are: * do you agree that we should align with those primitives? * If yes,is it really worth coding a custom protocol for them, or should we rather already use at least the MAP encoding, but ignore the complex TCAP transaction state machines and SCCP routing? There's already libosmo-asn1-map which should be able to parse and generate the 'real world' data structures. The extra effort is probably limited, and if the messages are then simly sent over a raw TCP (IPA) connection, there is no SS7 complexity. Please let me know what you think. If you think it is worth it, I can think a bit more about the detailed message structure / interfaces, given that I've spent my fair share of writing SCCP, TCAP and MAP code over the last year or so... Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) --AGZzQgpsuUlWC1xT Content-Type: image/png Content-Disposition: attachment; filename="mt_sms_delayed.png" Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA4QAAAUKCAMAAACJ+k+bAAAAeFBMVEX///8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACnp6cAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADf398fHx9/f38/Pz+/v7+fn59fX18AAAAAAAC4 0I+JAAAAAXRSTlMAQObYZgAAIABJREFUeJzsnYma2zbTrJnkS5zNyUmcffkBYonu/w5PNxYS lDT20J7pKXLqfWKKAkAUS2IFIKjE00QIIYQQQgh5ef77778sL0le46Y4DjvbunZY5UO9Xx9Y mWf3nrbpv7g5rUXMlcJKzP4/H+KNhbX8wROIQZroGdQD7zeqhXqi19XRD7aHzyfE66M/bJqQ cgUHeckPhdD7uyH0wn//yeb9vZej76reli9lTs5oc1qrWB6CKiXyZ76yMJQ/dAKtidd4/ece OJt2ZP13wLZaj902Ky3c+C+k9xokZEMbzcJDIbzzrhE/NAy+V/U912j+L92cVhNzy+XvyyA2 a/Gm7VD+AK4kNGrDFt/3pONeCO/NC6QkhccaJGSDXIZlQhXqv83lpU3xUvjPp3G6FaUuDxOq HsJeXg7pB8o1HuJydMr/+TJjbDPFNpFdepQdH/s16mqwxtNaxcJmmiyBzW7bdihfmq0nUKpK 8GQ89OU8hoE+1HE16Sm4VlMQS+tcs578aqVv8rxxGG8/mQ/O3snrRC4TufSibOWyce2aW6++ 9SJzdZq3pnAZnFq5vpbrWt/+V+dsy5Xs9fYr9eIyuVyPbLItCklDsjmtVUyGuJYlvauLdywM 5bVuPIF2ZFpr5+UsS+dBhXILaGwnurjpx0tZunKobd00bYqvPplqmpAbJGhy6c2ylcsm641S rhdR21susqwXcR5XRmoulvI+tct69ZVN7EdnvcD1jm7Wa3gZOvqRTfZqPFpPaxqG3R6GWGIb 5msLQ3m1N57AWrTsqlovURGNUbOz3hNmrXLDUauV9V9SvnwYQ/HVJ8PpKHkAuTLk38+hTr/K IOHqv7zb3nKR+f/K+ohfjmy5WMrXq3bdDJNZbe1iysPQ0Y/ssvUa9XUkHk5rFasnV/dS9nVd dNt2LZ82p7Pcwm5DuHis752E5r8y6R1DGK+PWq0slXNRHIuvPhmGkDyAXBn5P+f9sASx2Rvy dPVMol3VS/mHQ6hr+2FscHvk0MN6WtP9CMkln+u/MLZte/k03Q1hm466uIxXy3Hhv+TD/F+s d6XvC+FiZakM2uum+MofQ0geQK6M9N/cpl/vHwmvLqFlJNwslbwvhG2iuY6E7cjtSNgbrKc1 3QlhCMuFvWk7lE/T3RC2hZm5DVFuvRuVuahEUm8uw4dCuFhZrWrqN8VXnwxDSB5Argy5z2o3 Ru+7Jwzlxsrf3BMu5R8OoSY7rUXLkdt7wj4dXU9rujMdDf8FtzyiGNoO5dN0N4RxfEQRS9tl BG1rUcu/LB4M4WKlV8Z22zcUX30yDCF5gDZviuuo8MDqaKyLhOt11K7qpfwxI2FZLqy3g2E9 crs6OowmS6/3F2b8Gpel7VA+TXdDWFLn28N67Xxw5TXjfkidnuj9kbBZ6ZXzXM99KL76ZKpp Qm5oV1RfblifE853nhP6B54T+vo07EMhdPo4sDxNT2WFZ+lRd/o6aH9EMZ7WnUcUct+3/mxt Y+H2Z2tXISzP79rP1mLtuzcvs4BcWtZCPdF7IVys9Mr6y5xt8faTaaYJwce975F2WLNACHku 8vo0/RrHsYQQA9x/D946ZQ6EhFiQHora+J8yEUIIIYQQQgghhBBCCCGEEEIIIYQQQgghhBBC CCGEEHIe/vnnn/I/b5fXWP66n398QP7v2f79999yvvJaz/fffr4xyH79S4FCnP/1pUxalYb9 WCWg/sVB//d/sb+03fKuAHLS8oH/VT7wv/76q3wP8hrH8oYr79M05b+8vA1t2/8jyu3R48Hy Lf7lX/yvdpIz+ruc0d9//11OVF7jWF5O9O+nOlEJX/nrfkoINYpe/swfPOzF0BDJSy4h1Ch6 +VP+hoS6r/+jdvev/FOip1kcQ6j/p9raASIPhFBPWlL4gie2oKnx8mfWGJXvocZoLa9EX997 JzXy3rdtr98cPR7c9v3LplAz5+XPrCEsJ1pDuJb33ac5UYncP/ISSgh9GRXnUgKKDmXyEkoI fRkVZy1xJYqxlOjfHRRKMnU7hrD82+zff1/6X7QP8EAIy0n/3/8hnLQvA9gskZKwaK5CDeFa XnDy3pVEZaf17q+27aY2Rw8HuxLFWEteDl+Gv/nvvzWEf+uJ1hCu5a4kMdaCT0YGQp2HylZe ypR0/et+EJFxTKMkW3lp+dLzzXV8SzoN1b87aNb3bmg09RAOBWC8J4RDwUvSYpQ1W0H3ZVte /tpcOHOZfcq3Id+EDn/pryzb2DOq7Yejh4NznbCmdvxLUeeeekYyEOq+bMvLUp7/rif6t38K PbkllNlnlG0ZCTd/3Q8icksoo1uUbRkJl/P1/67/56Q6JZXxrkTydiT0xuf8WN47EvoXO60B vV+rJ/ZXy1VuI+HmwlnnnTrlzBLKWLbLlHpz9HCw/+vB//+VJXq3V89IbgllyIuyrSNhL/d/ P+WJ/vNPkpvCWbYSwqiT038C8C2hBCnJGDfLVhIV60LLPG2Gt/J3B5VUal5v7wkf+Jt1X57/ 69y5J8Q46ajzyL/0A//rrySZmmVbllaW8kId2/S8vVR5mXZO+tfZrAnbHD0cvE5YX5Sos9C/ 9Yz+/jvJmDfLVkM4lj/liUr29PP5x5WpqP51P229FBSJlJ7vv3XlRc+3rpcOIax/d9Aspb7M XK9XRzGu5zvUvPm7q6MgJ60feFnalLiUXLUbvaW8UMv+qnd+f0mbIAOi3Cgudznbo9eDQUJY zqgsjErY9ET/djV1Y/kTykn28j/61/20+0FdXf7nH+R7wpj/1fNdsuWyzjzbdFT/HqJQ9/Tp hJ9up6P5iNPRjDEdLbj8V0mP5soPuSnlZa9PR8tdoAyAkq/0V73RK6PjdHt0PbhNR/VbfHHk vq9kL/+tJ7qmrpS36egTnahkL/0zy9inIWx/3c+SR0AkSOlfHeU0Ue18dbctzJRnEu1K+Leu kN5ZHX2JE38E718dfbnzWmkfuERH/kl/zXVIHMtLs74wkzWEciso0YqyzVNfF90cPRzcFmbm F16YaWckwZN/0t9zH/rW8rYwMz/VwkyM//h/5hrCf8pf94P9iCLKANeePITy4L08oojLI4rY bv/n+jyfIXxCwl/lAy+PKKLc7ZUHhnEsL8jMs73/q94vupK+dS1jc/RwcMR4RBH+LmdUHlHE +LcvDwzjWB6f+BGFPplojyfiER7W60OH9uQhDg/r5/6wfm5nL/NRX4+oHCyEFbAQxuFhvT5b 6A8Y1vJNO+/XJ/Xhr/WWcHv0ePAM8bA+Dg/r4/R33cSxXJP4lA/rdQD8p81B3QF+tqYDYE+U 2/xs7d/ys7VlCcOXcN6E0B3jOeE2hA7jOWH7OVp7MhjazHIsH9tludGbpjbHzOMUc3u02/xs 7S+An6259WdrUZ/U9+VQN/5s7e8n+9kaIYQQQgghhBBCCCGEEEIIIYQQQgghhBBCCCGEEEII IYQYc3npE3gi6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED 6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sOg+/vxT/wfyf3rZ8bLj //yz/I/l//S5VN6W1YMKm5a9qO/rX9OyFtaG/X9Q73y6ahTc0HN9M//5p5u2XdeivPzlwhND uAv6wGINoZ9aCOUCd+ViD3/mWf5Md8vKQX5WhlJ5VwqX2np8b+e8NMx/9r+qJfurRvnPsPbc 2kn2y18ZNXRdi9yfw1+OxBDugD6wWEOol7SG0MsFnmRb3tXx5l5ZOchPw04r3RZOf4ahKJfc zC3EmqKrRv7P4dhZW8c/l2T2fnpR6N1ODOEu6AOLJYQ+yIS0hFDmldn7MuqFObpSeVtWD3LK tnQIodSlmu3WrmWsNckyvm4bpX5weXUatfxnDH9uu+5F6c/1b1VkCHdAH1isIdS/eLqEUCaJ 8qfd6ZU7s3tlmqp6kzYPpVPPz1K73inOS4paFsvIum2kf3deObY0bANk6vPOdngvcn+ufw0o Q7gD+sBiDaFc2LmEMP0Z/0x9XhizXOl3y0pmkuCG0qklZaltt5qtXekhDmGato3quFuOnepI KHU5b8bHoejPdWmGIdwBfWAxhFCmeSWEcu3/6TQuXq9xTcK9stTDoyylrae1tsRuc08oo1wb wWoIbxotx+o9YahDZVwOmIYihvDjoA8sxhBKysqM1Jc/Gpkwz76untyU1YPaqudYul2YCX+O 7crqaOiZWhZ6wiaEvWddHa3BTkNqp7WI09GPhD6wGEOoEz3d0XllGZwkVz6k6W5ZOWh9creW bkNYVjivnxOGOoLVhZmlUT9u6VnuMedNsNfGbf7MhZmPgj6weBkf9TZy86DvI+Ajio+EPrB4 UR/Zf8rRfFj/sdAHFi/qw/n04UYPwp+tfSz0gcVl2B4ZhnAH9IFF8XE5vhuGcAf0gYX6uDCE QCIG0AcWl5LBE2D0YZ0C+sDionPRlw7QU2DzYZ0D+sDC6PJ9bhjCPdAHFufIIEO4C/rAgiHc o2IhYgB9YMHp6B4VCxED6AOLsjBzhpUZmw/rHNAHFudI4IUh3AN9YMGH9WgiBtAHFvzZGpqI AfSBBUOIJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIA fWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAH FvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBB H2giBrwuH3/88UeWlySvUd/nP/5IrVwI69/YHrP/w4fYa/4IrrSKd6o3HRr5wIch3MHr8qFx mkr2amZ8fS/l3sv+Hz2FGip9P9ea1mwJ2li97dDIBz4M4Q5elw8d1OQltMxEfb+OcaEmctJw 6vg2S+OloRtCOFZvOrTygQ9DuIPX5UPGLQ2LbEtmsu6kaVqjtrSrs9Xs2l55WYI2Vm86LHUp SDdRSrLmW3Z8fHxEX9f3cQQRA16XDwmGzCGjbEsqSmDWiWb6w7d2csc3x3ZEjaefNiPhWr3p sJRI7eTqfNXpToEhPKqIAa/Lh6ROQjfLVlMhW5fWiaYLZZapxLoaM0/9ntDXzMbb6rHDKlFv EnPd5D+8mzJDeFwRA16XDwmD93IHV2eZMhvVkSota6Dl/rDgUvZl5bNVbEM4Vo8dTksj37Ir O9K9YwiPK2LA6/IhYch/OIlNu8eb22pMHe/yNilOBjDXbx79NIZwrB46nJZGPdXLW4bwqCIG vC4fEob0x1xHsPKgoY1/1yEJoS/HjEs2S6tN9dphl5h0JFxuHzkSHlvEgNflQ8IQ//Dl+V4s zxUK6TaE5en85hHFNIZwrF477BKlhdwTzp73hMcXMeB1+dAw/FE30ZXZaJ2PXockDk/j74Rw W907XCWWFpGro4cXMeB1+WgDYJuX1nWY9Mcft9NFt/4uTWvc9jnhtrp3uEpM9fEgnxOeQcQA +rCAITyuiAH0YQFDeFwRA+jDAobwuCIGnMsHqhuG8LgiBpzKx+X4bo7voMIQ7uBMPi4MIQwM 4Q5O5ONyCl76g3wiGMIdnMfH5XKKGL70B/lEMIQ7OI2Pc1y+53AxMYS7OI2Pcxg5iQ2GcBen 8XEOIyexwRDu4jQ+znH5nsPFxBDu4jw+LudYIH3pD/KJYAh3cCIfLx2fp+GlP8gngiHcwZl8 nOESPr6DCkO4g1P5YAhhYAh3cCofDCEMDOEO6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAP NBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kAT MYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED 6AML+kATMYA+sKAPNBED6AML+kATMeDV+Pj999+zvCR5LX91df7999TKhZCWhjH7332Iveb3 4EqreKd606GRj4PAEO7g1fjQOE0lezUzvr6Xcu9l//eeQg2Vvp9rTWu2BG2s3nZo5OMgMIQ7 eDU+dFCTl9AyE/X9OsaFmshJw6nj2yyNl4ZuCOFYvenQysdBYAh38Gp8yLilYZFtyUzWnTRN a9SWdnW2ml3bKy9L0MbqTYelLgXpJkpJluA6nbjOrpX7ND2GV/N9HEbEgFfjQ4Ihc8go25KZ Eox1opl+962dBie2I2o8/bQZCdfqTYelRGonV+erTie8dTLbbi4flcJX830cRsSAV+NDQiCB mGWrmZGtS+tE04Uyy1RiXY2Zp35P6Gtm42312GGVqDeJuWzKSFoms9KRkxL/JD4OAkO4g1fj QyLhvdzB1VmmzEZ1yErLMFXuDwsuZV9WPlvFNoRj9djhtDTyLbs6Is7R1enopGru5qQ+wsdB YAh38Gp8SELy705i0+7x5rYaU8e7vF1bcTLHdP3m0U9jCMfqocNpadRTPSUN6+/zWv6Y9ZtX 830cRsSAV+NDMpB+n+sIVh40tPHvOhsh9OWYcclmabWpXjvsEpOOhEuHbg5VgiPhcUUMeDU+ JCHxd1+e78XyXKEtltyEsDyd3zyimMYQjtVrh12itJB7wtlnvWOs0eM94ZFFDHg1PjQhv9dN dGWWWOej1yGMw9P4OyHcVvcOV4mlhYp4ro4eX8SAV+OjDYBtXlqnhun3YVml49bfpWmN2z4n 3Fb3DleJqTwn9PqcMAZfd/ic8MgiBtDH87PnJzXIPvbAEO6APp4fhvDIIgbQx/PDEB5ZxAD6 eH72PCFE9rEHhnAH9AHC5VIsHN5HgyHcAX2AcKkpPLyPBkO4g9P4OD6TpvA038dpRAw4iY+X DtBToC7O8n0whHs4iY/LOXxcTuKDIdzFSXyc5eI9iw+GcA8n8XGWi/csPhjCPZzEx0kuXk5H 8UQMOImPl15UeQq4MAMpYsBJfLx0gJ4CPqKAFDGAPkAoMTyBjwZDuAP6AOHCn61hihhAHyBc +ANuTBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML +kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAP NBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kATMYA+sKAPNBED6AML+kAT MeC5ffz2229ZXpK8lr8zOv/2W2rlQkh32/3Wmdam9Y3L/jef41oanPbpxUeQ7STbMMqMzcqO z245t6idhXjnLF8OXldoIgYYhFBTkfvl7et7Kfde9n9L99r5UiebaWla30SNkfyZe2k5SrIj PnyJqde6VWZs1iR9P7U0drY9y5eD1xWaiAEGIdRshHZ5a4p+c6U8Tsu4ddtOG65d9GA4GbDk 4LmOlq0/p8Xx4sqR7kpmbFZ2XUvppEHV0W9WoWv1l4PXFZqIAc8fwqDXtWzL5Z11J01DOO63 ux/CuQ1j0ksvLS8SrEv6LUu82mGLzNis7qZlKOwT5Oxu1LUyBekqhpp73fHRIKK8rtBEDHj+ ENZs5HoBl2s7TNOdRGza3Q9hH8V0YOsp1g7yb/ky/yYHS0zbZLfJTEOzuuvaEKm9+XmJ3Fa9 zF3lGFcnrGWwLTCEj4Qh3MHzhzBJGmbZ6gUsW5dKCurcMJQZ4W27qxAW5jWOmsB2s+dbxi4y bsltYyjj3yozDc3GsbNJ6L3gfEe9jMxTSXfd5N+8mzJD+GgYwh08fwhjyUYduXQe6cpEsS95 urvtrkJY1mXSdQjramcL1kV6zr/JHZ92uMpMQ7PrEE4uZV/XRa/VeyvfIiw7aZocQ/hoGMId GIRQs+HrVV3Gs7AsVdaHDXfaPXo6mut8NkgIswyAbXq7ykxDs+vpaMHltmazUe+Nl6cj/S1D +EgYwh0YhDD9NktC9AJO6/h3fT1v2k2PXphpzWYJYZI3YXnc14fZodn1bWgI45rNRn0dCdtb joQ7YQh3YBBCuWOTkUkv4NDTke6FcG037XlE0VrXxJUp6CBzE8LhEUUoj/DbI4qt+voIRUI9 e94T7oYh3IFBCKf2K5jofqsBCOsThrvt9P3dEG4f1o/POHx/zudKVBeZbQi3D+uvOhvVh+O0 SeTq6F4Ywh1YhDC0waYtWJbFy3shDOuk8YEQ1p+thfX+rPeT22Kmb913mbHZzc/Wtp2N6utp hHYEnxPugyHcAX3sgCF8NAzhDuhjBwzho2EId0AfO2AIHw1DuIPLsD0yDCEWDOEOio/L8d0c 30GFPtBEDFAfF4YQBvpAEzHgUjJIYHjpC+KJYAh3cNG56EtfeGTlpS+IJ4Ih3MFZvvZzuDjD 3XmFIdzBWb71s9g4iQ+GcA9n+dbPYuMkPhjCPXA6CsVJvg2GcBdlYYYrMzi89AXxRDCEO2AC wXjpC+KJYAh3wIf1WNAHmogB/NkaFvSBJmIAQ4gFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAH mogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJ GEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB 9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfewR+VUJ 7qbiV/+JPT+ig6sm66m47H/1ednRojkN9b82lnb80sGgjz0iv/p5zr+Gmwq56D+NR4TwSmM9 lfBrnuXP5HzZ0Z4kfGv9PM/6Zu7t+KWjQR97RMoV7n+dXJBRJsr+7H2SwvJP/tVrUS9TSmEq ifl1mpIvb6RBeZWXMlJJ+7n2oV23tr1ymvKvcXKSJq1fdFtstX3dy0EaptJctmGs7016O37p aNDHHpFfvXMaMB1U9JpOvwZNVAlhK1rKlF/LfiyvpSJIROZaqC9XfdQQatteKcRf9dC51Hdd 7VpOJbaRMMzRrYmTLuexfmr56+34paNBH3tEyr2VjHcpuajXvP/VSUjaSNhi0MuUX8t+7sOS kyHNl1Yxy/HO6Sg39NFGwtq2VCrey/DmSnnXnfqdnqSt3Arq7d86pc1xrJ9an70dv3Q06GOP iEwjkw4mkoSwBOYqhOvUr++HoUyaLAFV0tjHGsJeqUgCfZtfdt1yREoptyYS6l9zrXByfv66 fsmntuOXjgZ97BHpF7MMTlMdCac7I+H0uJFQU5LcAyNhq1Skg19TLe+6U8+Vzjc1oXrXWBMn E96YN/X9TW/HLx0N+tgjsoTw1zn/qssnwz2hb/mY790T6tvtPaGb5f5OA9jb+19z+LWHsFc2 Nd2rAlV3qquj0t2sI2WYpfHcV0ddWUdd66e+JtPa8UtHgz72iPQQJu8lMXFc2VxC2MuUdXW0 HrWsjoa4vPT2MtXMy0i4VJb9Mp6Ve8Ku2yas9bGfZjik9TlhuKof+izt+KWDQR+fLHLnueFm GogHv3Qs6ONTRPKvc8x9CfJOGUP4rNAHFi8TwjIBnB8uYwifFfrAwjCEx//Iju+gQh9Y2IXw cvyP7PgOKvSBhVkILwwhDPSBhVUIL6fA4sMygD6wMArh5XKKGFp8WAbQBxY2ITzH5XsOFxMv XjSMQmih8uycxAYvXjQYwsdzEhu8eNHgdPTxnMPFxIsXDbuFmTOszFh8WAbQBxZ8RLEHiw/L APrAgg/rd3B8BxX6wII/W9vB8R1U6AMLhnAHx3dQoQ8sXvA/6j0e9IEFfaCJGEAfWNAHmogB 9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAf WNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEF faCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGPBUPn755ZcsL0leo77Pv/ySWrkQ 0t12v3SmtWl947L/xee4lganfXopCG0bRpmxWdnx2S3nFrWzEO+c5eNJekD07VSrYiwbV7p8 KnhdoYkY8IQh1FTkfnn7+l7KvZf9X9K9dr7UyWZamtY3UWMkf+ZeWo5KJQK+bedRZmzWJH0/ tTR2tj3LR+PKcWOvcvI1hNLbzkC/D15XaCIGPGEINRuhXd6aol/c1MaLPm7dttOGaxf9YnYy YMnBcx0tW39Oi6Nu6nYjMzYru66ldNLo6FA1q9C1+qPJ5d8it0fVc/G7+novvK7QRAx4uhCG Mj0L9ULNurNet2vUrtrdD+HcLmvppZeWFw1W+iXLth22yIzN6m5aotEnyNndqGtlCtJVDDX3 ZRo8u1bu+/jtilydLKc2t+3TUc300w2FvK7QRAx4uhDWbOR6eZdrOEzTnURs2t0PYR/FdGDr KdYOsoxp8y+xbNtkt8lMQ7O669oQqb35eYncVr3MXeUYVyesrkw425y20FKYltmoT6WFH0M4 P+FdIa8rNBEDni6EeqHOstXLUrYulRTUuWFYLtNtu6sQFuY1jprAdrPne8Zk3PK61XisMtPQ bBw7m4TeC8531MvIPNV066ZEvs1pvWsrQZOOdXPvUlMscYxDCOMTzkd5XaGJGPB0IYwlG3Xk 0nmkK+NIX/J0d9tdhbCsy6TrENbVzhYsXSHJv8gdn3a4ykxDs+sQTi5lX9dFr9V7K98irCPi HF2djg6jqR/mvC6m/MsmhOug++nwukITMeAJQ6jZ8P3anNtqTE1WjvfbPXo62sYkGQAlS+mX Nr1dZaah2fV0tOByW7PZqPfGy9OR5DeDcW825FofU4RtCO8s2Hw0vK7QRAx4whCmX/TmSC/I tI5/19fnpt0yNQkBAAAgAElEQVT06IWZ1kxuBWVMir+E5XFfH2aHZte3oSGMazYb9XUkXM7S zaGe9zgSDiEMPaIM4ftgCHfwhCGUWyO5QOuFuqxr3Anh2m7a84iita6JK9PDQeYmhMMjilAe 4bdHFFv19RGKhHr2uSzAuNt7wmE6qmqJ09EPwRDu4AlDOLVfwUT3Sw1AWJ8w3G2n7++GcPuw fnzG4ftzPleu/UVmG8Ltw/qrzkb14Thtome+PPEfV0eHhZlQO+PCzPthCHfwlCEMbbBpC5Zl 8fJeCMM6aXwghPV5XViner2f3BYzfeu+y4zNbn62tu1sVF9PI9QjYvB1Z/ucMK3PQZwUR99n tHxE8QAM4Q7o4z7bf3m44Tejt/Bh/S0M4Q7o4z5XI3hefvx6C3+2dgeGcAf0cZ+rELrlx6+3 8Afcd2AId0Af97m+l00PJu2p/lOmy7A9PgzhDugDhMulWDi8jwZDuAP6AOFSU3h4Hw2GcAcX gsKkKTzNdXUakefnpS88sqLfxlmuK4ZwB5eT+DjJ93Hh9wEn8vzwS8eC3wecyPPDLx0Lfh9w Is8Pv3QoOB3FE3l+XnoxgqxwYQZS5Pl56QuPrPARBaSIAfQBQonhCXw0GMId0AcIF/5sDVPE APoA4cIfcGOKGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJ GEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB 9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAf WNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGHAaH+/eeXnx797pu/ndOycv75Tgaot3m3cP UroRXPbvfNbDhn6vuuzt+zH36P28t9Hg4zGNDgBDuIPT+HinuXPvalgkM2nS636e87tQW+ib ObzLH+ioZ0ValtabfnuX3m3az+nh/no/DOFBRQw4jY93XnKXZCtv4rsavTaI1RY1BFo++zKW yQD1zmt8ki+vkq93ZaRbm+cwjf324vndPPVu2kiY30WJ6tj5fNWPduzCO9+G0dagNZ+9vNWW p/k+TiNiwGl8vPMy6cu+hEUSEd6VJDiX+gikb+TdLBEK5YKXaaVEIErCgoxVqbyXSj+X5kHe xdLH2u/UMlXTVrtpIYzS8XXnm35Kx/7dPLeRuTZozVM5Fe36NN/HaUQMOI0PGdf8JH80LOWy ntsNnI+1Rb0nzDo0OqcDl84zZczU9xIr34dKX5vrvZze/Y39TuN42rrp94ReR0O3dt66Wfqp aX03u5iGjlpzX05FS07zfZxGxIDT+JAZpSQiaVhk8Mu5hiOl2G/f9E2qSVBSjcG7sExatyFU Yn6Xh36X6jIStm56CCWBPlx1PvZTSmSArjPgJc1rJxNDCCliwGl8yGzzncxBNSyhXtpxm4Tl BtFrGpP7wEioidK0Df0u1eWesHXTQ6j3oWnovEv3fmojmRD74V6xN+dIiCtiwGl8yCXsy586 TslwmO+EMLzTCOVZr/qbe0Jfm9WRKkupVM9rv62XvjraulkeUfjyWGTpvEv3fkrHXo72fj2d 3nzmPSGsiAGn8VFWKHVYa2uX0zK2NdYxTFck473V0am0aAdpKkKa1n5rL+tzwtrNEsK24rJ0 3nVbP6VjJ4N0iOvpLM25OgorYsAr9vG4B3d2MISQIga8Yh8M4TPCEO7gFftgCJ8RhnAH5/Jx fDfHd1BhCHdwKh+X47s5voMKQ7iDM/m4MIQwMIQ7OJGPyyl46Q/yiWAId3AeH5fLKWL40h/k E8EQ7uA0Ps5x+Z7DxcQQ7uI0Ps5h5CQ2GMJdnMbHOYycxAZDuIvT+DjH5XsOFxNDuIvz+Lic Y4H0pT/IJ4Ih3MGJfLx0fJ6Gl/4gnwiGcAdn8nGGS/j4DioM4Q5O5YMhhIEh3MGpfDCEMDCE O6APLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA +sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAP LOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCC PtBEDKAPLOgDTcQA+sCCPtBEDDiZj59/DtPkynYKP+dS8vPPPvdafRPf1085UrrIvhw19tf6 SpvGreaW3sPDLd7n4/AwhDs4mQ9JyTSlHh2vJX6ew89zrZX9uZQ+SIuMBHjOEuKhv3a8/zmO jeeHIt17YAgPLmLAyXz8rBmRMUgu/PnnrHkpGfi5DoVtgJTN7P0sb+tgKe9+DlHfziV0vWUO Y3+t1JX9cnwbCfPPTsTiUhbmTQ/SYww/+/avgVJbW9bS5SQ2Pg4PQ7iDk/n4WQe9kDUBwbs6 EDk395FQ9qOvAc0/S+J0q++CxFBGzhz7OCnBSG7b39RD7PvxLYTp56TJ7mXSy9iD9iiZC3UA LbWtZS3tJ7H1cXgYwh2czIeMKxKMJNFwmh7f7wNdre373jvngwbOtz9RMlnGzPWeUO8e1/6m aRhJ6/H9nlCnrXko2/RQGvnkSiJrbW9ZSvtJbH0cHoZwByfzIWOaDC46ZZRMZZ1L/hxS6vdt ul9GxZ8roUaqzVjHEAouST7W/qZpGAnr4T2EwUcZDNeyTQ9lrJQ8hjWErWUt7Sex9XF4GMId nMyH3Nv9HDQ7ky9Xet6siyz3h94n4T0jYdDbtPDz0F8/vqSmHt9DmCTAY9mmBy2Iy4y4jYSl ZS3lSAguYsDJfGgsSvLK/aBe3bchLPeEs67bXN0TllpfWua+Otr7q8f31dF6fA+h3k2OZZse pnpPmH9Oyxm0lrWU94TgIgaczIdc5KGsmMxlIUTnktchLMNO9j7fro5qRZsZ6lO+eeivHr88 JyzHL88JQ0nYUrbpQXvUddBhfba1rKVcHQUXMeA1+9j3BO+ZuDqJ1/x9YIoY8Jp9MITPB0O4 g9fsgyF8PhjCHdAHCpdhe3wYwh3QBwiXS7FweB8NhnAH9AHCpabw8D4aDOEOTuPj+EyawtN8 H6cRMeAkPl46QE+BujjL98EQ7uEkPi7n8HE5iQ+GcBcn8XGWi/csPhjCPZzEx1ku3rP4YAj3 cBIfJ7l4OR3FEzHgJD5eelHlKeDCDKSIASfx8dIBegr4iAJSxAD6AKHE8AQ+GgzhDugDhAt/ toYpYgB9gHDhD7gxRQygDyzoA03EAPrAgj7QRAygDyzoA03EAPrAgj7QRAygDyzoA03EAPrA gj7QRAygDyzoA03EAPrAgj7QRAygDyzoA03EAPrAgj7QRAygDyzoA03EAPrAgj7QRAygDyzo A03EAPrAgj7QRAygDyzoA03EAPrAgj7QRAygDyzoA03EAPrAgj7QRAygDyzoA03EAPrAgj7Q RAygDyzoA03EgBsfP/30U5aXJK9R3+effkqtXAhpaFcK3MN9tx427X+6bRaz/8mHeEf7U3wc FPpAEzHgXgjDVLJXg+Dreyn3XvZ/Sks7XwrCw31fhdAXblpp5LTj+Vb7U3wcFPpAEzHgXgh1 tAotCFHfu6knKiyhW6ofHgqvQvhArnwZ/WZVvdL+JB8HhT7QRAy4E8KgCZBtCULWnTQNoVva xeUlSpusYUx9YiklXtr+v3Js+smPIXTSus0+U/ipV2Tp4Ep7abIKtH5vI3ra7+OgMIQ7uBPC LDPDKNuflqCEqYeo5Km1q6GU967OJ53OLGWnlhQkM1mDnIcQtrpUZqjSWP7M8a721JssAku/ H/ZxUOgDTcSAOyFMErpZtnqpy9alMuUsb10JVWtX7gl9bCHTjUZIQhVlxzu9tYsltL4Mb5W5 1/ky6E5twvtTmG+0q0q9SVwEWr8f9nFQ6ANNxIA7IYzey22ZK5e6zEZ1+Enr6qZb2hU0hL7l UUIaU4mI1yO0B/njXBk928JMWupcHxxdyr6ui26129lMg8DS74d9HBT6QBMx4F4I809OsvBT Hb/mthpTQ5Tj0G6a+ojWnj5EXS3Vij6VjXJsSmX0vMrV2qrgckvloD02bgLrsR/0cVDoA03E gHshTD/Nkhu91NM6/l1f+cNCje9VoT5nGEZC6SHnbXKuR8IQlhWejfag4q+PZQjRYQh3cC+E 8Scvaarj2E99GeU9ISw3irPX7KSp3M+t927up/ZscDl+vCdsTz3c8ohi0B5UFgHeEx4FhnAH 90I4/dSGJVdmo3U++p4Qxvq4vWTW/1Sjt6xihvormPuro/1J5PKwftW+UqkCXB09CgzhDu6G MLRhKbV1GH29H0LXnxN6fYzn9CleefiuJcv66vpAsTA8J6wLM8PP1lbtUWUR4HPCo8AQ7uDZ fbh7Pxf9NBhCfBjCHTy7j7g8WXwyGEJ8GMIdPLePsP7k+8lgCPFhCHfw3D7a0s4T9zmG8DJs jw99oIkYcHgfl0uxcHgfDfpAEzHg8D4uNYWH99GgDzQRAy7HZ9IUnub7eOkTeCIYwsfz0gF6 CtTFWb4P+oATeX4u5/BxOYmP01xXDOEOznLxnsXHWa4rhnAHZ7l4z+LjLNcVQ7iDk1y8nI6i wRA+npdeVHkKuDADCEP4eF46QE8BH1EAwhDu4PA+SgxP4KNBH2giBhzex4U/W0OEIdzB4X1c +ANuRBjCHdAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAH FvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBB H2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSB JmLA6OPHH3/M8pLktfx91PnHH1MrF0Ia2pUC93C3rYdN+x9vm8Xsf/Qh3tH+FB9Hhj7QRAy4 CmGYSvZqEHx9L+Xey/6PaWnnS0F4uNurEPrCTSuNnHY832p/io8jQx9oIgZchVBHq9CCEPW9 m3qiwhK6pfrhofAqhA/kypfRb1bVK+1P8nFk6ANNxIBtCIMmQLYlCFl30jSEbmkXl5cobbKG MfWJpZR4afv/yrHpRz+G0EnrNvtM4cdekaWDK+2lySLgdOY6u1bul7nxHR9Hhj7QRAzYhjDL zDDK9sclKGHqISp5au1qKOW9q/NJpzNL2aklBQlP1iDnIYStLpUZqjTWWMW72lNvsgj4shOW O8yrFJ7x+zgyDOEOtiFMcpXPstUgyNalMuUsb10JVWtX7gl9bCHTjUZIghJlxzu9tYsltL4M b5W51/ky6E5twvtjmG+0q0q9SawCTsvLDPjHpZOHfBwZ+kATMWAbwui93JaVC15nozoOpXV1 0y3tChpC3/IoIY2pjGJej9Ae5I9zJSttYSYtda4Pji5lX9dFt9rtbKZVQEfEObo6HW2dPOTj yNAHmogBVyHMPzrJwo91/JrbakwNUY5Du2nqI1p7+hB1rqgVfSob5diUyuh5lau1VcHllspB e2zcBJL/sa+jxrHPOz6ODH2giRhwFcL04yy50Ss8rePf9QU/LNT4XhV6PpaRUHrIeRuY65Ew hGWFZ6M9qPghrXOoh3IkxIch3MFVCOOPXtJUx7FlBeQ9ISw3irPPJRrlfm65J5SgtGeDy/Hj PWF76uGWRxSD9qDSBfSOseeX94T4MIQ7uArh9GMbllyZ+tX56HtCGOvj9pJZ/2ONXlsdLQ/9 8tp+2q6O9ieRfp1kdu0rlSKg94RcHT0ODOEOrkMY2rCU2nxPX++H0PXnhL48xtOng+Xhu5Ys 66vrA8XC8JywLswMP1tbtUeVRSAGX3f4nPAIMIQ7eE4f7t7PRT+Z+z+p4feBBUO4g+f0EZcn i08JQ3gEGMIdPKOPcHPj9iQwhEeAIdzBZdg+MW1p5+m7ZQjxYQh3UHxcju/m+A4q9IEmYoD6 uDCEMNAHmogBl5LBE/DSH+QTQR9oIgZcdC760gF6Cl76g3wi6ANNxICTXL7ncDGd6Lo6jYgB J7l6T2LjRNfVaUQMOMnVexIbJ7quTiNiAKejWNAHmogBZWHmDCszL/1BPhH0gSZiwDkSeGEI wWAId8CH9VjQB5qIAfzZGhb0gSZiAEOIBX2giRhAH1jQB5qIAfSBBX2giRhAH1jQB5qIAfSB BX2giRhAH1jQB5qIAfSBBX2giRhAH1jQB5qIAfSBBX2giRhAH1jQB5qIAfSBBX2giRhAH1jQ B5qIAfSBBX2giRhAH1jQB5qIAfSBBX2giRhAH1jQB5qIAfSBBX2giRhAH1jQB5qIAfSBBX2g iRhAH1jQB5qIAfSBBX2giRhAH1jQB5qIAfSBBX2giRhwIh8//PDDLHuzvGqJ/8Hryw+Kz2vL Vi4V7l5HKfzwQ0gP6jx8lH/PUY/nRN/HSUQMOJEPCVuQvVBDGOUlTlqac5ZNb9jL78RJSyTC IdQ03yXnu6X1qHt1D6T2PT5OAUO4gxP5+KGmr71ILkooSghiHRynofyBEHpN6ND8UaQffBWJ t3UM4cFFDDiRDxmNJAVRthoh/0NqmXRl2xv28lqh08hZ95OfS3plT+pS2Qx1WYMrWWuZ1sln XJuEOnLOOY4H/RBc+1dC6WJpXcU3JVHmyPW0TvR9nETEgBP5kEmkhEH+6NWsgfEaqDYS+tZu KS8VMnhlCUuZyaYyac16A5k0YJu60kGW7ttRMvn06+F+GQLHg3w9RjotXSx10zRdldQOGUJI EQNO5ENmg3JBy2ioV7MGpgxf7Z6w3+Qt5SVOQePo9YgeSyep0JWc6zpfpqquHVVGvzQ06VPO tSRObhmJaxe9biqlY0npcGYIIUUMOJEPudz9D5P35eL/ocxMf+iro8tCy1Le7gALqc9ZS5Zc asPbWCcDrNOR7YcWxEJvso6Em4OWTT2g102L1Ka1YwghRQw4kQ+5lLNc0Fmv5vRDv+K3CyNr eUtHVoYQlrvBEtNtnQyy6Yf5KoS9SbsnzHpfNxx0FcJeN03TVYlnCHFFDDiRD7mw5Y7vh6RX s9yyKeXubAzhWt4mljKEJRnjlhD6kie9c9zWSUXomRqmo7XJujq6OegqhL1umqarEk5HgUUM OJEPubDl4i8bV58W1AFtCOFQviyx+L7mqQOTDpUhBx0qt3XlAeLURsthYWZZfqnPCTcHtU2e +mDaWk/TVQkXZoBFDDiRjzqQeU1aate677d0jaG8PaKQA3IfqmatjRqL+vxhrCu9TsODjezW JsPvbMaDymZec7y0nq5LEh9RwIoYQB8o8J4QU8QA+kCBIcQUMYA+UGAIMUUMoA8ULsP2+DCE O6APEC6XYuHwPhoM4Q7oA4RLTeHhfTQYwh2cxsfxmTSFp/k+TiNiwEl8vHSAngJ1cZbvgyHc w0l8XM7h43ISHwzhLk7i4ywX71l8MIR7OImPs1y8Z/HBEO7hJD5OcvFyOoonYsBJfLz0ospT wIUZSBEDTuLjpQP0FPARBaSIAfQBQonhCXw0GMId0AcIF/5sDVPEAPoA4cIfcGOKGEAfWNAH mogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJ GEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB 9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAf WNAHmogB9IEFfaCJGHAyH2/fetn6t2/1zfz2rStlQnC9ZS/1111oicv+rc/3JW6P6O3dbcW9 xo/hZN/HCUQMOJmPt5ow97aGULKYtMzPc34besul9LoLLQlv8yx/7krM6abI+dL+piuGkCHc wcl8vPWSsCRb2Y9va/Ta4NgabkpnX4ZIienbMmDW0hw2NfltlFyH5QifliNzyXPZ1gIZFt/6 OPXOpNveUz27tcBJdqtCrj1ufBwehnAHJ/Px1stkMvsSOQlPeFsuc+fSMjKtpTozDbO+ymx1 ljd+lpEwzNFta+LbWXI9L0d4CWWrX6LdC97KyFjbSWet29pTObuhwL+dZ/23wdvW49bH4WEI d3AyHzKuyPWdSzjkStfs1HtC3y/zpdTr8OicjnM1JP2eUG8gNzXeS3RdO0LG0hz7keukcyjo 4n0Irj11haXl29nFpGfndHS+8nF4GMIdnMyHzOzk+k6aAxn8cq5ZSCn2tZOhtMVT5pJrCJWY ZQY61kgCfRhyNS1H1pHQSe+t4DaEvadFoRXIeFymobVsuWM92fdxAhEDTuZDpp5vZbapOQj1 ao/TOlxNV6Ve4pmSG0KoYdMbwE2N3kamaTsS1vp6Txhk2wrujIStp67QC6LMkbUlR0JwEQNO 5qPcbJV7NVdGlySX9xjCbeksd3D+7RrCJINemOdyuzbW+LfjXaSWt/q+OroUDCFsw2jvqZ3d UuC9CHneE8KLGHAyH2/19i1rDma98SsFYwivSnWhMvZJZl1RkQyHdFOzWU+N6+v6nLAWLCGc F+F+xDRtCpyMyVWBq6PQIgbQxwtz9UDxsD6uYAh3QB8vDEMILmIAfbwwDCG4iAHn8nF8N8d3 UGEId3AqH5fjuzm+gwpDuIMz+bgwhDAwhDs4kY/LKXjpD/KJYAh3cB4fl8spYvjSH+QTwRDu 4DQ+znH5nsPFxBDu4jQ+zmHkJDYYwl2cxsc5jJzEBkO4i9P4OMflew4XE0O4i/P4uJxjgfSl P8gngiHcwYl8vHR8noaX/iCfCIZwB2fycYZL+PgOKgzhDk7lgyGEgSHcwal8MIQwMIQ7oA8s 6ANNxAD6wII+0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANNxAD6wII+ 0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANN xAD6wII+0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANNxAD6wII+0EQMoA8s6ANNxIDX5eP777/P 8pLkNer7/P33qZULIS0NY/bf+xB7zffBlVbxTvWmQyMf+DCEO3hdPjROU8lezYyv76Xce9n/ vqdQQ6Xv51rTmi1BG6u3HRr5wIch3MHr8qGDmryElpmo79cxLtREThpOHd9mabw0dEMIx+pN h1Y+8GEId/C6fMi4pWGRbclM1p00TWvUlnZ1tppd2ysvS9DG6k2HpS4F6SZKSdZ8y46Pj4/o 6/o+jiBiwOvyIcGQOWSUbUlFCcw60Uzf+9ZO7vjm2I6o8fTTZiRcqzcdlhKpnVydrzrdKTCE RxUx4HX5kNRJ6GbZaipk69I60XShzDKVWFdj5qnfE/qa2XhbPXZYJepNYq6b/L13U2YIjyti wOvyIWHwXu7g6ixTZqM6UqVlDbTcHxZcyr6sfLaKbQjH6rHDaWnkW3ZlR7p3DOFxRQx4XT4k DPl7J7Fp93hzW42p413eJsXJAOb6zaOfxhCO1UOH09Kop3p5yxAeVcSA1+VDwpC+n+sIVh40 tPHvOiQh9OWYcclmabWpXjvsEpOOhMvtI0fCY4sY8Lp8SBji974834vluUIh3YawPJ3fPKKY xhCO1WuHXaK0kHvC2fOe8PgiBrwuHxqG7+smujIbrfPR65DE4Wn8nRBuq3uHq8TSInJ19PAi BrwuH20AbPPSug6Tvv/+drro1t+laY3bPifcVvcOV4mpPh7kc8IziBhAHxYwhMcVMYA+LGAI jytiAH1YwBAeV8SAc/lAdcMQHlfEgFP5uBzfzfEdVBjCHZzJx4UhhIEh3MGJfFxOwUt/kE8E Q7iD8/i4XE4Rw5f+IJ8IhnAHp/Fxjsv3HC4mhnAXp/FxDiMnscEQ7uI0Ps5h5CQ2GMJdnMbH OS7fc7iYGMJdnMfH5RwLpC/9QT4RDOEOTuTjpePzNLz0B/lEMIQ7OJOPM1zCx3dQYQh3cCof DCEMDOEOTuWDIYSBIdwBfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAH FvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBB H2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSB JmIAfWBBH2giBrwaH999912WlySv5a+uzt99l1q5ENLSMGb/nQ+x13wXXGkV71RvOjTycRAY wh28Gh8ap6lkr2bG1/dS7r3sf9dTqKHS93Otac2WoI3V2w6NfBwEhnAHr8aHDmryElpmor5f x7hQEzlpOHV8m6Xx0tANIRyrNx1a+TgIDOEOXo0PGbc0LLItmcm6k6ZpjdrSrs5Ws2t75WUJ 2li96bDUpSDdRCnJElynE9fZtXKfpsfwar6Pw4gY8Gp8SDBkDhllWzJTgrFONNN3vrXT4MR2 RI2nnzYj4Vq96bCUSO3k6nzV6YS3TmbbzeWjUvhqvo/DiBjwanxICCQQs2w1M7J1aZ1oulBm mUqsqzHz1O8Jfc1svK0eO6wS9SYxl00ZSctkVjpyUuKfxMdBYAh38Gp8SCS8lzu4OsuU2agO WWkZpsr9YcGl7MvKZ6vYhnCsHjuclka+ZVdHxDm6Oh2dVM3dnNRH+DgIDOEOXo0PSUj+zkls 2j3e3FZj6niXt2srTuaYrt88+mkM4Vg9dDgtjXqqp6Rh/W5eyx+zfvNqvo/DiBjwanxIBtJ3 cx3ByoOGNv5dZyOEvhwzLtksrTbVa4ddYtKRcOnQzaFKcCQ8rogBr8aHJCR+58vzvVieK7TF kpsQllgF1rcAACAASURBVKfzm0cU0xjCsXrtsEuUFnJPOPusd4w1erwnPLKIAa/Ghybku7qJ rswS63z0OoRxeBp/J4Tb6t7hKrG0UBHP1dHjixjwany0AbDNS+vUMH03LKt03Pq7NK1x2+eE 2+re4SoxleeEXp8TxuDrDp8THlnEAPp4fvb8pAbZxx4Ywh3Qx/PDEB5ZxAD6eH4YwiOLGEAf z8+eJ4TIPvbAEO6APkC4XIqFw/toMIQ7oA8QLjWFh/fRYAh3cBofx2fSFJ7m+ziNiAEn8fHS AXoK1MVZvg+GcA8n8XE5h4/LSXwwhLs4iY+zXLxn8cEQ7uEkPs5y8Z7FB0O4h5P4OMnFy+ko nogBJ/Hx0osqTwEXZiBFDDiJj5cO0FPARxSQIgbQBwglhifw0WAId0AfIFz4szVMEQPoA4QL f8CNKWIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBB H2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSB JmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2gi Bjy3j2+//TbLS5LX8ndG52+/Ta1cCOluu28709q0vnHZf+tzXEuD0z69+AiynWQbRpmxWdnx 2S3nFrWzEO+c5cvB6wpNxACDEGoqcr+8fX0v5d7L/rfpXjtf6mQzLU3rm6gxkj9zLy1HSXbE hy8x9Vq3yozNmqTvp5bGzrZn+XLwukITMcAghJqN0C5vTdG3rpTHaRm3bttpw7WLHgwnA5Yc PNfRsvXntDheXDnSXcmMzcquaymdNKg6+s0qdK3+cvC6QhMx4PlDGPS6lm25vLPupGkIx/12 90M4t2FMeuml5UWCdUnfZolXO2yRGZvV3bQMhX2CnN2NulamIF3FUHOvOz4aRJTXFZqIAc8f wpqNXC/gcm2HabqTiE27+yHso5gObD3F2kH+Nl/mb+VgiWmb7DaZaWhWd10bIrU3Py+R26qX uasc4+qEtQy2BYbwkTCEO3j+ECZJwyxbvYBl61JJQZ0bhjIjvG13FcLCvMZRE9hu9nzL2EXG LbltDGX8W2Wmodk4djYJvRec76iXkXkq6a6b/K13U2YIHw1DuIPnD2Es2agjl84jXZko9iVP d7fdVQjLuky6DmFd7WzBukjP+Vu549MOV5lpaHYdwsml7Ou66LV6b+VbhGUnTZNjCB8NQ7gD gxBqNny9qst4Fpalyvqw4U67R09Hc53PBglhlgGwTW9XmWlodj0dLbjc1mw26r3x8nSkv2UI HwlDuAODEKZvZ0mIXsBpHf+ur+dNu+nRCzOt2SwhTPImLI/7+jA7NLu+DQ1hXLPZqK8jYXvL kXAnDOEODEIod2wyMukFHHo60r0Qru2mPY8oWuuauDIFHWRuQjg8ogjlEX57RLFVXx+hSKhn z3vC3TCEOzAI4dR+BRPdtzUAYX3CcLedvr8bwu3D+vEZh+/P+VyJ6iKzDeH2Yf1VZ6P6cJw2 iVwd3QtDuAOLEIY22LQFy7J4eS+EYZ00PhDC+rO1sN6f9X5yW8z0rfsuMza7+dnatrNRfT2N 0I7gc8J9MIQ7oI8dMISPhiHcAX3sgCF8NAzhDuhjBwzho2EId3AZtkeGIcSCIdxB8XE5vpvj O6jQB5qIAerjwhDCQB9oIgZcSgYJDC99QTwRDOEOLjoXfekLj6y89AXxRDCEOzjL134OF2e4 O68whDs4y7d+Fhsn8cEQ7uEs3/pZbJzEB0O4B05HoTjJt8EQ7qIszHBlBoeXviCeCIZwB0wg GC99QTwRDOEO+LAeC/pAEzGAP1vDgj7QRAxgCLGgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pA EzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQR A+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGA PrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgjz0i3yjB 3VR84z+x50d0cNVkPRWX/Tc+LztaNKeh/pvG0o5fOhj0sUfkGz/P+ZtwUyEX/afxiBBeaayn Er7Js/yZnC872pOEb62f51nfzL0dv3Q06GOPSLnC/TeTCzLKRNmfvU9SWP7J33gt6mVKKUwl Md9MU/LljTQor/JSRippP9c+tOvWtldOU/4mTk7SpPWLbouttq97OUjDVJrLNoz1vUlvxy8d DfrYI/KNd04DpoOKXtPpm6CJKiFsRUuZ8k3Zj+W1VASJyFwL9eWqjxpCbdsrhfiNHjqX+q6r XcupxDYShjm6NXHS5TzWTy1/vR2/dDToY49IubeS8S4lF/Wa9984CUkbCVsMepnyTdnPfVhy MqT50ipmOd45HeWGPtpIWNuWSsV7Gd5cKe+6U7/Tk7SVW0G9/VuntDmO9VPrs7fjl44GfewR kWlk0sFEkhCWwFyFcJ369f0wlEmTJaBKGvtYQ9grFUmgb/PLrluOSCnl1kRC/U2uFU7Oz1/X L/nUdvzS0aCPPSL9YpbBaaoj4XRnJJweNxJqSpJ7YCRslYp08E2q5V136rnS+aYmVO8aa+Jk whvzpr6/6e34paNBH3tElhB+M+dvdPlkuCf0LR/zvXtCfbu9J3Sz3N9pAHt7/00O3/QQ9sqm pntVoOpOdXVUupt1pAyzNJ776qgr66hr/dTXZFo7fulo0McekR7C5L0kJo4rm0sIe5myro7W o5bV0RCXl95eppp5GQmXyrJfxrNyT9h124S1PvbTDIe0PicMV/VDn6Udv3Qw6OOTRe48N9xM A/Hgl44FfXyKSP5mjrkvQd4pYwifFfrA4mVCWCaA88NlDOGzQh9YGIbw+B/Z8R1U6AMLuxBe jv+RHd9BhT6wMAvhhSGEgT6wsArh5RRYfFgG0AcWRiG8XE4RQ4sPywD6wMImhOe4fM/hYuLF i4ZRCC1Unp2T2ODFiwZD+HhOYoMXLxqcjj6ec7iYePGiYbcwc4aVGYsPywD6wIKPKPZg8WEZ QB9Y8GH9Do7voEIfWPBnazs4voMKfWDBEO7g+A4q9IHFC/5HvceDPrCgDzQRA+gDC/pAEzGA PrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gD C/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCg DzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pA EzGAPrCgj48V+VoJ/d0cW+ncX9re8iok/7Vf3z2EdPX1A63GcpX3uZ3H1y7IybhpCkt5L7kj yi8dC/r4WJGvc4zRLe+2kZOXXrcGJ8oh89f5QyrDsdeM5ao/f52mGPPXMQYfkw+Ty0t5K7kn yi8dC/r4WJEWrigDTdThR3fS9HXwsq0jYavKQSKhBC+bObvsywgm5cHVrct6rFbM2pUeXlvV 6mnKcqgkSvNZZJp+LD3PX8s7GZNjmlJayltJE33Yx4GhDyxeaDqaJBoyCul4430MEp+vkwxM NYS1SoJYgiApqlHIX6ckQ5Nkaf56rtvs5SiJneynqHVza1WrZU75dXRfl4BVmWmcDmsIs+zL PDas5a3E3xl5+aVjQR8fK9KmozJSzU7HJZeylxDmydUbwq/nWiW7c0lNz4O+yMimU8Sv57r1 JdBaEV27n6ytarWqzenrUlVlpj4d1VvR0r2TJH8dw1BeSxhCfOjjY0X6vV6UMVDfBR3NNiGs VWsIy4CYQw/hXEJYtyXQ90I4N6EcQii7VWZasjnVEOrCkMxt57W8lsxN9GEfB4Y+sHihkVCn e1Fv2GTmGKK/mo6WqjWEbY2kT0eHEGavg5dU6BC2mY72VEWd+pZui8x0PRJKNrXvuJbXksiF GXzo42NFyr2XL08AJB5Bb+/kvm5cmKlVawjb04Ky5OI2IXShLsyUhwlhXZhxSwinkrzSl8o0 /frsQbuX5tJFGMprCR9RHAD6QBMxgD6woA80EQPoAwv6QBMxgD6woA80kWflMmyPD31gwRA+ hsulWDi8jwZ9YMEQPoZLTeHhfTToAwubEB6fSVPILx0L+tihcQLUBb90MOhjh8Y5PqzLSXzw 4kWDIXw8Z/HBixcMhvDxnMUHL14wGMJHw+koGvSxQ+MEcGEGEPrYoXEC+IgCEPpAE3lOSgxP 4KNBH1gwhI/hwp+tIUIfaCLPyYU/4EaEPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCC PtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgD TcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPtBE DKAPLOgDTcQA+sCCPtBEDKAPLOgDTcQA+sCCPj5OxL/xt/Vv3rj3Hf5g9fuO6zIpvPEhvb/x UvWBE+GXjgV9fJRIfPPmTdzU6XX/gXzkvKeiCYX6mt+8CeHNG2n4nsaL/nvaKPzSsaCPjxKR TLzZXuiPCOG+iiaUykt6412Jfnxf4w/0tcAvHQv6+CgR/ya9eTO1y77mT96/eZP8m6A50cnj PLWC0qRUa5B0WilNZpnQZretKMcux1ShuhPezPoy59jUpI2/EppX/aVN6Wf2Pm3yyS8dC/r4 GBEZmDSHQwizjowSqFBuFmXIypKAtaBVO62RaaV3s0RQW1xVvInrMYprr34dAlvka+NRKK2H 9jb9ZKQtQ4gLfXyMSJaBKet8dAlhH3wmpyNk0IBKcDQnbhky9U8Z0qR6DiVBVxVzyVM/Rkht zjtkqB7QGq9Cdc2m6dc2cT0ZjoTI0MfHiLRB6DaEbce/KaTb6iUMKevwdFXh+ty0NwttALwZ CUtjvxW6o1RPxmnHDCEs9PERIulNu/YfCqFMEpX3hDDL9DF9OIS+KbZ7wuzTdeNB6IEQbjq0 +7AMoA8sTEMoN3VKmzvG28s96MCVZncbwj4d1f30wHR0zUx/QDGujl5NRwehB0LI6Sg69LFf xNUnBTofDcuiR19gWVZZdFFkDGGtTm1hRmr7dPRmYWYN4Tx36fU54fXCzCr0QAgTF2bAoY/9 IqmtXfo3yUmg6igzbzKX+gOIXrBU6zMFqYnhTSgD21KxPqJYQ+jX5KRQFkCHxw/1EcUg9EAI VYIjITL0gSbyGDaR+hAxunW5tQDj4xOhDywYwgeRMVeG0fH3PTA+PhH6wIIhfBCXfflVzQqM j0+EPrAwDOHxP7LjO6jQBxZ2Ibwc/yM7voMKfWBhFsILQwgDfWBhFcLLKbD4sAygDyyMQni5 nCKGFh+WAfSBhU0Iz3H5nsPFxIsXDaMQWqg8OyexwYsXDYbw8ZzEBi9eNDgdfTzncDHx4kXD bmHmDCszFh+WAfSBBR9R7MHiwzKAPrDgw/odHN9BhT6w4M/WdnB8BxX6wIIh3MHxHVToA4vX 9Z8yfSL0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9 oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0Aea iAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkY QB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV97BdJ/is/T18JIer7Zc999ZVr77/6anlbjqiF eTjq+rC7R7kgbZzUzdPkZdPer0eXg8Kk9Vo4Zz04+KW8qkav/1z7ODz0gYVhCONXOc5fZdlG H7RA9pL3spNKWKYY81cxLm8Fn7SRHJXWo64Pu3tU8NJGs5Q1nHN/vx6t/UW3hjB+lbRuKa+q k/xLw89XPo4PfWBhGEIZZ6ZJhhy5qPNXWlAipBd/CKVOakv55m2JyVfzetTtYfeOksBFSbDE LelI2N6vRy/p6y9exr2v4jSWyyZ9pf9sfRwf+sDCMIRymStlcujbXn371ZzqVLLEaX0bQg9N XI+6PezOUVnmlLNESmaZWWPf3q9Hl/lmGjInnWTfJrepq0qvyX2Vtj6OD31g8QIhVOpNWUvT /FV0NQ0lTutbmR6O94T1qOnmsDtHTW7OXqPrky+jXn0/rSG8mo5q5PQEe3lVLTVfzVsfx4c+ sLCejuagl/mkt3Kxzyu9XvFaWeO0vv2qpSLUe7h61HRz2J2jdNRzOomVcVCz2d5PD09HJx80 pL2gqjKE0NDHbpG+MLNc022NRMKhqyCasbmsci5v+3R0/mpIwu1hd44KPuk7naL6qSzMpFY7 LsxIoENKyTURP01L+dy75XQUF/rYL9IeUawh/Ko8N5j1Vm6dWF691Z1U7gkfPOzOUU4mn7q0 Orv6HKK9X4/+qg6cm1vAuVXX3KoqF2agoQ8DEefThxs90VH34SMKZOjDQiR5u6PuwYf10NAH mogB9IEFfewWOf5HdnwHFfrAwi6El+N/ZMd3UKEPLMxCeGEIYaAPLKxCeDkFFh+WAfSBhVEI L5dTxNDiwzKAPrCwCeE5Lt9zuJh48aJhFEILlWfnJDZ48aLBED6ek9jgxYsGp6OP5xwuJl68 aNgtzJxhZcbiwzKAPrDgI4o9WHxYBtAHFnxYv4PjO6jQBxb82doOju+gQh9YMIQ7OL6DCn1g wf+UaQf0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9 oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0Aea iAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkYQB9Y0AeaiAH0gQV9oIkY QB9Y0AeaiAH0gQV9oIkYQB9Y0Mc+EZf9lz676UsluF4zf/ll3e/105de3vgvU63P+nYPH2q/ 6ownMr5pp/RlYzxJfulY0McuEYlVnoMk5Es/z/nL0Gv8lzVuS72maM2gvEv3OnyY+f3tR53h ROob74ZTmudZS+fhJPmlg0Efu0RyuYxlW0Yq/2WriF+2HCz1GsKwZrAMRcmXLEom6nEylI0F s5dBLH8ZJyd9lf6XA6qUk9S1YW6js55IeTN/OY+ntIyqawm/dCzoY5fIEjsZblxa5owSnVCm eku9NFgzOOlgNKUvw6xlMmGcaxPZ8RK6WjDL9ksfv9SGcwnOcoCvHfsvZVSrMRp1hhMpr660 WU5pCeFawi8dC/rYJbLErtxn+SiXvKDFqYw/662c1s/LkTVHTgLixz6cDk+tQKp1HPRe0uJu DtDUSYcupqW/OydSi0sIl1NaGq8l/NKxoI9dInUEclEu95RiX/iQkSjnYV4o9VKehqGw3SWW BmsIdadPPdsKSpIE+nB7gHYsA1m/txx0xhNZR8L1lHoIhxJ+6VjQxy6Rei8WvlxnokkINUBx WuvbwkxsrR4zEnrtyumdW7o9oIRQJp5tHrrRWU9kvSdcT6mHcCjhl44FfewS6auSbnyEUG/C ksRprS9XfmwLldPNLV4t7PeEpWCWIzV2vjxIGA+QPoMu7Hg/z74evNVZWFZHh1Pa3CnWEn7p WNDHPpHlOaFfi+tyZLvWx+eE07xZoBwWO1thHgt0dTT2Y8YDoiSurY6WFtONTmd5Tjie0rhm Wvf5pWNBHy8nsvcB/pPBLx0L+ng5EYbwE6EPLBjCHfBLx4I+0ESelcuwPT70gQVD+Bgul2Lh 8D4a9IEFQ/gYLjWFh/fRoA8sbEJ4fCZNIb90LOhjh8YJUBf80sGgjx0a5/iwLifxwYsXDYbw 8ZzFBy9eMBjCx3MWH7x4wWAIHw2no2jQxw6NE8CFGUDoY4fGCeAjCkDoA03kOSkxPIGPBn1g wRA+hgt/toYIfaCJPCcX/oAbEfpAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGA PrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gD C/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCgDzQRA+gDC/pAEzGAPrCg DzQRA+gDC/pAEzGAPrCgj6cRicH/z89umv5XCKlXlLc+u/Y2/+9/aSlWxsJG+l/s9eFOj9sj FmFpF2tNdP/LH+vjUNAHFi8cwqRJk3+cRMF72VtS1d779lZ2Q3mtpd6PhRWnb0pdLb/ucXPE KlxDOJdtLnn8CB/Hgj6weNkQuv/9b5ZBycsIVMejsKSqvHde64Wog1obFWMdBreFkyYo9WEt avl1j+MRg3Bpl2pW3RL6fT4OBn1g8bIhzDUhSa79JT2tqr5PLRXScJ1I9jZjYcnVclh5ue5x PGIQ1nbxfy3s4b1DIb90LOjjKUT8/4Z7wDF0/b1rQ51EZxnSlliNhXpomNaR0N/2OB4xCGvh //rN4Pzeu0J+6VjQx1OI/G8deOr0MywhGIa0cgfnUp969hBuCnUQm6flntDH2x7HIwbhuoDT 3sb3zkf5pWNBH08hsglhxW2r+tJl0EGxjl49hJvCPri1XmoItz2OR1yF0JcVmmkdeXf6OBj0 gQXEdNTF2IawrNnQne10tNyy9alnD+GmsOeqh9ZPNz2ORwzCUpqd79387303hfzSsaCPpxBp 6yPzsjBTKI8Bxzu6tBnUWgjT1Ug3hrA0ue5xPGIQLu2WlRmG8EDQx1OIxOtHFCvjI4rQ05Pa QdNN4TodvRfCynBEvHpE0Z4Tcjp6KOjjSUTm4WH9dQiXh/WuDVNt6llDeFW4Lsw8GMLNEavw 8jxR97kwcyTo42lEogxP7Wdr1yFcfrbWl0Dbaw3hVeH2EYVbnxOubI9YhNdDAh9RHAv6QBNx 41P5j4UP648EfaCJ1J+tfRr82dqhoA80kfoD7k+DP+A+FPSBJlL/U6ZP4uH/lOkybI8PfWBx phA+H5dLsXB4Hw36wIIhfAyXmsLD+2jQBxY2ITw+k6aQXzoW9LFD4wSoC37pYNDHDo1zfFiX k/jgxYsGQ/h4zuKDFy8YDOHjOYsPXrxgMISPhtNRNOhjh8YJ4MIMIPSxQ+ME8BEFIPSBJvKc lBiewEeDPrBgCB/DhT9bQ4Q+0ESekwt/wI0IfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB 9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAf WNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEF faCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogBz+Pjiy++0L+lO8lr+eu+8xdfpFYuhHS33Red aW1a37jsv/A5rqXBaZ9eCkLbXkaZsVnZ8dkt5xa1sxBvznItf0l4XaGJGPBsIQxTCUUNoa/v pdx72f8i3WvnS51spqVpfRM1RvJn7qXlqFQC6tv2MsqMzZqk76eWxs4G9aH8JeF1hSZiwLOF ULMRWgg1RV+4Uh5LcbjfThuuXfRBycmAJQfPdbRs/Tktjrqp28soMzYru84v4fJl9JtVaKM+ lL8kvK7QRAx4rhAGvfZlW9KQdSdNQzjut7sfwrkNY9JLLy0vGqz0RZZtrCFcZMZmdTctQ2Gf IGe3VR/Ka7MU5FxiqP8GKBPi2fUKv0yonxpeV2giBjxXCGs2cr20y4UbpulOIjbt7oewj2I6 sPUUawdZxq75i1i24TLKTEOzuuvaEKm9+TneUR/Ka50U6GG+jK6+7FQLhedKIa8rNBEDniuE Sa7YWbYaAdm6VFJQ54ahzPxu212FsDCvcdQEtps93zMmo5XXbbqMMtPQbBw7m4TeC87X6kN5 bV9vF3PZuNaiWPCuLQo9B7yu0EQMeK4QxpKNOnLpPNKVwaMvebq77a5CWNZl0nUI62pnC5aT nvMXcsfnLqPMNDS7DuHkUvZ1XXSrvpav7X0Ls46Ic3RtOjoOrE8Nrys0EQOeLYSaDV+v5TKe hWWpsj5suNPu0dPRNhDJACiZSV/o9PYyykxDs+vpaMHltmazUe/lq/zynCT5NiwvFc/0LIPX FZqIAc8WwvTFLAnpi/9t/Lu+djftpkcvzLRmcisow1L8Qqe3l1FmbHZ9GxrCuGazqg/l66tf z9fNoXXNkfARMIQ7eLYQyh2bjBzl8u7pSPdCuLab9jyiaK1rLKTnyyhzE8LhEUUoj/DbI4rN WS7lq3y5e5191nvHljzeEz4KhnAHzxbC6YsWGtcegIf1CcPddvr+bgi3D+vHZxy+P+dz02WU 2YZw+7D+qrNFfShf5VuhevBcHd0DQ7iD5wthaINNW7Asi5f3QhjWSeMDIaxP6cJ6L9b7yW0J 04uPUWZsVldohp+tbTtb1d3mZ2v9hEI9NgbfOuFzwkfBEO6APnbybEsyFX4faCIG0MdOGMJH wRDugD52whA+CoZwB/Sxk2d+QsjvA03EAPoA4XIpFg7vo8EQ7oA+QLjUFB7eR4Mh3MGFoDBp Ck9zXZ1G5Pl56QuPrOi3cZbriiHcweUkPk7yfVz4fcCJPD/80rHg9wEn8vzwS8eC3wecyPPD Lx0KTkfxRJ6fl16MICtcmIEUeX5e+sIjK3xEASliAH2AUGJ4Ah8NhnAH9AHChT9bwxQxgD5A 0NR3hgAACFxJREFUuPAH3JgiBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSB JmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2gi BtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIA fWBBH2giBtAHFvSBJmIAfWBBH2giBtAHFvSBJmIAfWBBH/tEXPaf++ymz5Xges38+ed1v9dP n3t54z9PtT7r2z18qP2qM57I+Kad0ueN8ST5pWNBH7tEJFZ5DpKQz/08589Dr/Gf17gt9Zqi NYPyLt3r8GHm97cfdYYTqW+8G05pnmctnYeT5JcOBn3sEsnlMpZtGan8560ift5ysNRrCMOa wTIUJV+yKJmox8lQNhbMXgax/HmcnPRV+l8OqFJOUteGuY3OeiLlzfz5PJ7SMqquJfzSsaCP XSJL7GS4cWmZM0p0QpnqLfXSYM3gpIPRlD4Ps5bJhHGuTWTHS+hqwSzbz338XBvOJTjLAb52 7D+XUa3GaNQZTqS8utJmOaUlhGsJv3Qs6GOXyBK7cp/lo1zyghanMv6st3JaPy9H1hw5CYgf +3A6PLUCqdZx0HtJi7s5QFMnHbqYlv7unEgtLiFcTmlpvJbwS8eCPnaJ1BHIRbncU4p94UNG opyHeaHUS3kahsJ2l1garCHUnT71bCsoSRLow+0B2rEMZP3ectAZT2QdCddT6iEcSvilY0Ef u0TqvVj4fJ2JJiHUAMVprW8LM7G1esxI6LUrp3du6faAEkKZeLZ56EZnPZH1nnA9pR7CoYRf Ohb0sUukr0q68RFCvQlLEqe1vlz5sS1UTje3eLWw3xOWglmO1Nj58iBhPED6DLqw4/08+3rw VmdhWR0dTmlzp1hL+KVjQR/7RJbnhH4trsuR7VofnxNO82aBcljsbIV5LNDV0diPGQ+Ikri2 OlpaTDc6neU54XhK45pp3eeXjgV9vJzI3gf4Twa/dCzo4+VEGMJPhD6wYAh3wC8dC/rYLXL8 j+z4Dir0gYVdCC/H/8iO76BCH1iYhfDCEMJAH1hYhfByCiw+LAPoAwujEF4up4ihxYdlAH1g YRPCc1y+53Ax8eJFwyiEFirPzkls8OJFgyF8PCexwYsXDU5HH885XEy8eNGwW5g5w8qMxYdl AH1gwUcUe7D4sAygDyz4sH4Hx3dQoQ8s+LO1HRzfQYU+sGAId3B8BxX6wOKI/ynTi0EfWNAH mogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJ GEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB 9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAfWNAHmogB9IEFfaCJGEAf WNAHmogB9IEFfaCJGEAfWBQfn30Wdetlx8uO/+yzaXLZf+ZzqbwtqwcJwZX9+bPPXC/6TFv2 ktrSrwqbw6RHn9pRWjTW3el+6L+V5LDx8dyc6ks/AafyUXP2mWZFrm1XLvPwWZ7lz3S3rBzk 5zl/5ks6JKJJXuZ51tJ5LWktV4XNYZKiVtKkSl14qPuh/1biPptHH8/Nqb70E3AqH5KwuWbF y7WdZFsDU0aae2XlIH0zlxTEz3p0aummpKd77iFcDmshqod8FtqeCj3YfWu8lAQ/+nhuTvWl n4BT+fjMB5kufqYhlNlm9r6MemGOZY55p6weNGmKNAv5sxja7LOUbkpaupvCeJg200mod86l Gkfd8e/pvvW/lKQ+3jKEO6APLFoIndegyD8yP5Q/7f6v3JTdK5PUOGk+1QFMj0xtbKulS4k2 rB03hWk4rI169T4v9z0f39N9P7yXuD45Zgh3QB9YtBDKNS03YLKTPoufpTYjnGKWa/xuWUnL /2/XDncTBaIACuObUKXh/d+wzAwDmOiPQXs5kPMl23ZJ5e5p9kaKdvNT1fTk9fub/1qXZDmS b6PkE88TuvVh9bunAcOwfPWoN2henr48YnOkXqe6hA3sYKlLOF3h3fIT1m26zksL16f/3WkJ Xh0b6trkX9ru5bnsUU+1OZK+sbv164RufVi3LGFXnxP78o96f/ryLZsjLuEOdrAsSzhtWd6V Pv9JK3P/+emnJXh1rDxovn1ZntaGcmGYTvV8ZP6dcJ7QPd0dXVfvvl3C96cvJ1qPeDm6hx0s yxKma7z0RbrazLsxbVt/H7qXx/KD6gt589NaPkn5+HRkWcI84fl1wvnGTH1IfcD70+dPmyPe mNnDDpZjO9bX+XbyJYo97GA5uCO9WP8BX6zfxQ6WgzvS29Y+4NvWdrGD5fwd4+ZjyKjzs4Pl 9B3jmBNcwgZ2sJy+Yyxb6BI2sINlPL8ubaFL2MAOlKMX6BtShUvYwg6U8RodY0zHNX5YdsBc ZAmDOi7yw7KDxSVsmhIxJIAdKBdZQi9Hm9iBcvRNlW/wxkwrO1COXqBv8CWKVnawnL4jr6FL 2MQOltN3jL5trZkdLKfvGH0DdzM7WOygDQlgB4sdtCEB7GCxgzYkgB0sdtCGBLCDxQ7akAB2 sNhBGxLADhY7aEMC2MFiB21IADtY7KANCWAHix20IQHsYLGDNiSAHSx20IYEsIPFDtqQAHaw 2EEbEsAOFjtoQwLYwWIHbUgAO1jsoA0JYAeLHbQhAexgsYM2JIAdLHbQhgSwg8UO2pAAdrDY QRsSwA4WO2hDAtjBYockSZIkSZIkSZIkSZIkSZIkSZIkSZIkSZL0D/4A1GLXzQjcenUAAAAA SUVORK5CYII= --AGZzQgpsuUlWC1xT--

2 years, 4 months

1
0
0 0

None

by None

OpenBSC Startup: http://pastebin.com/bXEhizAG moi::states: http://pastebin.com/9MiRRGP0 In the nano startup - the two things that stand out are the complains about flag 3 and the NSE: 27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not setting or set! 27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag 3 not setting or set! 42142:DBG:GBHSS_STACK:bgp_error_reporter() : PROTO_ERR: Msg=3DGPRS_BGP_RL_UL_UNITDATA_REQ, Err=3DGPRS_NSEI_NOT_OPERATIONAL 42142:DBG:GBHSS_STACK:bgp_process_msg failed : msg=3DGPRS_BGP_NM_BVC_RESET_REQ err=3DGPRS_NSEI_NOT_OPERATIONAL Any thoughts or additional data points I should collect? Thanks, Gus

2 years, 4 months

1
0
0 0

None

by None

<a href=3D"http://pastebin.com/qLatWdtB" target=3D"_blank">http://pastebin.= com/qLatWdtB</a><br> <br> OpenBSC Startup:<br> <a href=3D"http://pastebin.com/bXEhizAG" target=3D"_blank">http://pastebin.= com/bXEhizAG</a><br> <br> moi::states:<br> <a href=3D"http://pastebin.com/9MiRRGP0" target=3D"_blank">http://pastebin.= com/9MiRRGP0</a><br> <br> In the nano startup - the two things that stand out are the complains<br> about flag 3 and the NSE:<br> <br> 27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not<br> setting or set!<br> 27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag<br> 3 not setting or set!<br> <br> 42142:DBG:GBHSS_STACK:bgp_error_reporter() : PROTO_ERR:<br> Msg=3DGPRS_BGP_RL_UL_UNITDATA_REQ, Err=3DGPRS_NSEI_NOT_OPERATIONAL<br> 42142:DBG:GBHSS_STACK:bgp_process_msg failed :<br> msg=3DGPRS_BGP_NM_BVC_RESET_REQ err=3DGPRS_NSEI_NOT_OPERATIONAL<br> <br> Any thoughts or additional data points I should collect?<br> <br> Thanks,<br> <font color=3D"#888888">Gus<br> <br> </font></blockquote></div><br> --00163646d380b12b2004ae744714--

2 years, 4 months

1
0
0 0

None

by None

OpenBSC Startup: http://pastebin.com/bXEhizAG moi::states: http://pastebin.com/9MiRRGP0 In the nano startup - the two things that stand out are the complains about flag 3 and the NSE: 27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: BTS:0 flag 3 not setting or set! 27855:DBG:OAM_IM:roleInstanceProcClearContaineeFlags: GPRS NSE:0 flag 3 not setting or set! 42142:DBG:GBHSS_STACK:bgp_error_reporter() : PROTO_ERR: Msg=GPRS_BGP_RL_UL_UNITDATA_REQ, Err=GPRS_NSEI_NOT_OPERATIONAL 42142:DBG:GBHSS_STACK:bgp_process_msg failed : msg=GPRS_BGP_NM_BVC_RESET_REQ err=GPRS_NSEI_NOT_OPERATIONAL Any thoughts or additional data points I should collect? Thanks, Gus

2 years, 4 months

1
0
0 0

None

by None

My init.d script does the following in short: modprobe mISDN_dsp modprobe mISDN_l1loop nchannel=30 interfaces=2 sleep 1 echo 1 > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -s 192.168.253.0/24 -o eth0 -j MASQUERADE screen -S bsc -d -m su gsm -c "osmo-nitb -d DRLL:DCC:DMM:DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c /etc/openbsc/openbsc.cfg -m -P" screen -S lcr -d -m su gsm -c "/usr/sbin/lcr start" I'm using mISDN_l1loop.ko from current mISDN git because it was not included in my kernel. Small patch to make it compile: --- a/drivers/isdn/mISDN/hwchannel.c +++ b/drivers/isdn/mISDN/hwchannel.c @@ -19,6 +19,8 @@ #include <linux/module.h> #include <linux/mISDNhw.h> +bool flush_work_sync (struct work_struct *); + static void dchannel_bh(struct work_struct *ws) { -- Lennart --00504502c5d4681bbb04a8fd3d31 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><div class=3D"gmail_quote">2011/7/26 Konrad Meier <span dir=3D"ltr">&lt= ;<a href=3D"mailto:meierk@informatik.uni-freiburg.de">meierk(a)informatik.uni= -freiburg.de</a>></span><br><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I could solve the above problem by a system restart. The mISDN_l1loop modul= e was loaded but for some reason could not be used by LCR. The LCR error me= ssage was:<br> 000000 ERROR loop port 1 failed to bind socket. (errno 93)<br> <br> <br> By playing with the mISDN_l1loop module I discovered a strange problem. If = I load the module with "modprobe mISDN_l1loop pri=3D1 nchannel=3D30&qu= ot; all system memory is allocated by LCR after some seconds.<br> <br> If I load it with "nchannel=3D20" than everithing works fine.<br> <br> Can someone confirm this problem?<br> <br> Regards<br><font color=3D"#888888"> Konrad<br></font></blockquote><div><br>From my experience, no.<br>My init.d= script does the following in short: <br><br>=A0=A0=A0=A0=A0=A0=A0 modprobe= mISDN_dsp<br>=A0=A0=A0=A0=A0=A0=A0 modprobe mISDN_l1loop nchannel=3D30 int= erfaces=3D2<br>=A0=A0=A0=A0=A0=A0=A0 sleep 1<br> <br>=A0=A0=A0=A0=A0=A0=A0 echo 1 > /proc/sys/net/ipv4/ip_forward<br>=A0= =A0=A0=A0=A0=A0=A0 iptables -t nat -A POSTROUTING -s <a href=3D"http://192.= 168.253.0/24">192.168.253.0/24</a> -o eth0 -j MASQUERADE<br><br>=A0=A0=A0= =A0=A0=A0=A0 screen -S bsc -d -m su gsm -c "osmo-nitb -d DRLL:DCC:DMM:= DRR:DRSL:DNM:DSMS:DMNSMS:DPAG:DMUX -c /etc/openbsc/openbsc.cfg -m -P"<= br> =A0=A0=A0=A0=A0=A0=A0 screen -S lcr -d -m su gsm -c "/usr/sbin/lcr sta= rt"<br>=A0<br>I'm using mISDN_l1loop.ko from current mISDN git bec= ause it was not included in my kernel. Small patch to make it compile:<br><= br>--- a/drivers/isdn/mISDN/hwchannel.c<br> +++ b/drivers/isdn/mISDN/hwchannel.c<br>@@ -19,6 +19,8 @@<br>=A0#include &l= t;linux/module.h><br>=A0#include <linux/mISDNhw.h><br><br>+bool fl= ush_work_sync (struct work_struct *);<br>+<br>=A0static void<br>=A0dchannel= _bh(struct work_struct *ws)<br> =A0{<br><br>-- Lennart<br></div></div> --00504502c5d4681bbb04a8fd3d31--

2 years, 4 months

1
0
0 0

None

by None

systems from the same vendor, as it is assumed that these systems have seen a priori more testing time and are thus more reliable than any multi-vendor combination has seen/would be. Should there be a problem, it is also a lot easier and faster to get support from a vendor, when he can't first try and blame the other vendors box, or the translator in between. Here, again, risk management... While the lock-in is indeed a bad thing, it is still considered the lesser evil, compared to the effort needed to do q/a testing in mixed systems on nation-size scale plus R&D for the translators plus battling for support with N competing vendors, all blaming each other. This is the oh-so-familiar argument on why many companies use exclusively Microsoft, or everything Apple, etc... Just my 0.05 chf on why translators did not happen... (yet?) Cheers, Thomas --=20 Excercise 17: If the human brain was simple enough for us to understand we'd be so simple we couldn't understand. Prove this by induction.

2 years, 4 months

1
0
0 0

None

by None

Sure, it would be a nice addition, but it's not something that I consider extremely important. With regard to 'near future': I would say that in something like six months the osmo-bts (BTS-side A-bis) code will have matured, and is ready for an relaatively painless integration with OpenBTS. I personally think the USRP hardware cost is still way too high, and I would rather want to work on something that puts the financial entrance barrier to private BTS ownership much lower. Most of the people using OpenBSC today either use it commercially (and can afford the nanoBTS units), or they use it private and either with a very cheap second hand nanoBTS, or with a inexpensive BS-11. The recent work on supporting the RBS2308 that can be found for < 1000 USD goes into the same direction. I think whatever hardware will be affordable to hackers will see OpenBSC support - just as well as any hardware where we have a commercial customer will get OpenBSC support. > > This is where I don't get you. All that needs to be removed is the L3-to-SIP > > bridge. It doesn't make the vast majority of OpenBTS code disappear, > > and it does not render that latter part useless. A full-blown GSM network with > > all its components brings a lot of complexity. The stand-alone OpenBTS is > > much more simple. And why would you want all the complexity if you don't > > need to interoperate with legacy GSM? > > Well, because the the osmocom-integrated version will be, before or > later, more full-featured than OpenBTS standalone. > > Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable > only jointly with Osmocom integration but not by the opensource OpenBTS > standalone version. If you use the USRP hardware (or any other SDR hardware), you cannot use GPRS/EDGE whether you use Osmocom + OpenBTS or OpenBTS standalone. As for hand-over, you may be right, but I don't know the OpenBTS plans here. Multi-ARFCN: This is an aspect of the radio-modem. So again, on the same hardware any OpenBTS/OpenBSC integration will not change this. > Obviously the community will then use the OpenBTS/OpenBSC integration > that would reach more features than just OpenBTS in the opensource edition. well, but you loose the important 'simplicity' feature. Right now I doubt there are that many people in our community who understand OpenBSC and the GSM/GPRS network architecture enough to deploy a network (like the burning man or CCC event networks) with it. We have close to zero documentation, and unless you know GSM protocol details, you are lost. VoIP is much better understood in the FOSS and Internet community! > So the integrated code will grow while the "OpenBTS commercial code" > will leave behind with less features and more buggy code (because less > used). you are making assumptions here. Do you have evidence or at least some other indication that bug fixes are not being propagated from the commercial to the free version? > Osmocom and it's possible future changes to the market of GSM > technologies could be defined as "the WikiLeaks of the GSM Industry" :-) I think this is a very bad comparison. We do not leak any proprietary/secret information. We just break the ignorance of the Free Software community to ever implement any of those openly-specified protocols. Not different from Free Software entering any other area of technology. And while we're doing that, we of course also like to challenge the ridiculous claims of hundred-man-year efforts that allegedly went into some proprietary GSM protocol stack implementations, which are often claimed by the existing carrier equipment industry. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

> Meanwhile, Andreas Eversberg has been working on a BTS-side A-bis implementation > for the OsmocomBB-BTS (idea: using 2 heavily modified phones to run a > simplistic BTS), and I have started to split that code out into a separate > repository at http://cgit.osmocom.org/cgit/osmo-bts/ > > This code should eventually be used with the OpenBTS, and potentially other > BTS types, too. That's cool!!!! > >> With that approach the 'GSM-um' interface would be a very simplified >> module of the overall system and osmocom would completely replace >> OpenBTS all-in-one project. > > This is where I don't get you. All that needs to be removed is the L3-to-SIP > bridge. It doesn't make the vast majority of OpenBTS code disappear, > and it does not render that latter part useless. A full-blown GSM network with > all its components brings a lot of complexity. The stand-alone OpenBTS is > much more simple. And why would you want all the complexity if you don't > need to interoperate with legacy GSM? Well, because the the osmocom-integrated version will be, before or later, more full-featured than OpenBTS standalone. Features such as multi-arfcn, handover, maybe GPRS/EDGE will be usable only jointly with Osmocom integration but not by the opensource OpenBTS standalone version. Obviously the community will then use the OpenBTS/OpenBSC integration that would reach more features than just OpenBTS in the opensource edition. That means that in few times only the "integrated code" will works better, because it will attract more user and will start getting used in "production environment". So the integrated code will grow while the "OpenBTS commercial code" will leave behind with less features and more buggy code (because less used). That's why i just think that the destinity of OpenBTS is to integrate (directly or just some piece) with OpenBSC, but doing that it will loose several important value of the "OpenBTS commercial edition" and people will start using what can be used for free instead of paying. That's what usually happen within the opensource environment, before or later. It could reasonably happen also with that opensource gsm environment. My comments was just consideration on this to stimulate the considerations on this by the various project players. I am just an opensource advocacy troll that like telephony stuff and perceive very valuable the achievement of the hacking community in opening a closed technology like GSM. Osmocom and it's possible future changes to the market of GSM technologies could be defined as "the WikiLeaks of the GSM Industry" :-) -naif p.s. i have no commercial interests of any kind in that stuff

2 years, 4 months

1
0
0 0

None

by None

is not in the TLV table and this explains why we end up here. It might be a good opportunity to see what else we are missing. > > BTW, the output of the patch is in git format, so I think that you can > apply it with git am. It's the inner patch (which is contained inside > this patch) that it's in svn format 8-). Yes, I am talking about git am -3 for the inner part as this (wireshark svn) is the place where having a three way merge is going to be the most useful thing to do. :)

2 years, 4 months

1
0
0 0

None

by None

have a similar situation (see how OpenBTS folks managed to get licenses for their burining man tests). > - Is there some part of the official gsm bands that overlaps with local ISM > or other not-so-tightly-regulated frequencies? > (i.e, GSM1900 seems to have a small part that's not used by DECT...) This is a rumour. Only one of the uplink/downlink bands is in there, so you will still need a test license. Also, AFAIK the DECT band is not everywhere unlicensed for any kind of application, but actually restricted to be used with the DECT system. > - Are there any "standard" gsm handsets that could be modified (preferably > in software) to work at 2,4GHz? no. > - Is UMA/GAN (http://en.wikipedia.org/wiki/Generic_Access_Network) something > that could be used with OpenBSC? As far as i understand the specification, > UMA is GSM Layer 3 over an GPRS/IPSEC tunnel to the BSC, so all the > GSM-Goodies should be there. You would have to implemet a UMA gateway and somehow glue that to the layer3 inside OpenBSC. I don't think you can do it cleanly with the current code. Later this year, once the new "real MSC" codebase emerges, this might be easier. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

understand that we only have to configure the Unit-id and Oml Address right and I understand that the firmware is already installed . I have tried the following : ipaccess-config -f FIRMWARE -w and sure it doesn't work :) . And I also read the -w argument options that needs to be used to download the firmware from BTS into debian system it should be used with -f . Is it necessary to download it into our linux box or you need to configure it only as it is already installed into BTS from ipaccess company . Thanks, Omar Atia -----Original Message----- From: openbsc-bounces(a)lists.osmocom.org [mailto:openbsc-bounces@lists.osmocom.org] On Behalf Of Peter Hasse Sent: Wednesday, January 19, 2011 12:14 PM To: openbsc(a)lists.osmocom.org Subject: Re: How to run openbsc on nanoBTS On 19.01.2011 06:16, Ravi Shankar wrote: > Dear sir Hi Ravi > > I am new to openbsc.I have two NanoBTS(165cu).I'm facing some > difficulty which I'm summarizing below > I'm using Ubuntu10.04 > 1) Can we proceed with one nanobts.? Yes, in fact i would recommend to start with one and if you get familar with openbsc you can add more bts. > 2)I've configured bts ip,unit id, oml ip of one bts.But not able to > get the firmware. Check out ipaccess-config util from the openbts source. You can download the firmware out of the bts you have configured. > How to get it and configure for NanoBTS?? nanoBTS is a different project and based on the USRP. checkout openbts.org to get further informations. > > 3)how to run openbsc ?? http://openbsc.osmocom.org/trac/wiki/BscHack > > Please suggest the procedure to run the openbsc. > > Thanks mfg derPeter

2 years, 4 months

1
0
0 0

None

by None

seems weird: > but bts1 tells that: > > LMT LOGON: ACK > > PHASE: 3 Normal MBCCU0: No Load MBCCU1: Load ^^^^^ you have no software in TRX0!! > PLL Set Value=1042, Work Value=1221 this is not good. your clock seems to be very far off, probably you have not been running it in pll standalone mode at some point in the past. However, this is unrelated to your E1 problems. The only consequence of this is that phones might not see your BTS. > SITE MANAGER ATTRIBUTES: > E1 Channel: Port=1 Timeslot=17 (Full Slot) > TEI: 25 This is the weird part. Why would the E1 channel of the site manager run on Port=1? That is the not connected port of this BTS. It must run on Port=0. > BS11 Power Amplifier 0 ATTRIBUTES: > TRX Power: 2W (GSM) I strongly recommend you do your testing with something like 30mW power limits, unless you have a faraday cage and/or 2W-capable termiators. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

Number of symbols in a burst =3D 156.25 symbols, and burst time 156.25 x<br= > 3.69... =3D 576,92=ECs<br> Number of symbols in TDMA frame is 8 x 156.25 =3D 1250 symbols,<br> Number of symbols in Multiframe is 26 x 1250 symbols.<br> <div><div></div><div class=3D"h5"><br> <br> <br> <br> <br> <br> <br> <br> On Fri, Jan 7, 2011 at 8:51 AM, Nataraju A B <<a href=3D"mailto:nataraju= ab.tech(a)gmail.com">natarajuab.tech(a)gmail.com</a>> wrote:<br> ><br> > Hi Andreas,<br> > Thanks for the speedy reply.<br> > The link which sent you is=A0definitely=A0useful. But the very basic q= uestion I wanted to get a clarification was that, what is the drive behind = selection of burst time to be 577us.<br> > For example the audio frequency can range upto 4Khz. The sampling freq= uency should be 8Khz. If each sample is of 8 bit accuracy. This lead to 64K= bits of data. ...... =A0If we explore further on these lines we should be = able to correlate to the time 577us for each burst.<br> > I wanted some more info these lines. What was/were the drives behind s= election of this burst time. Otherwise what are the other end requirements = led to selection of this burst time and in turn TDMA frame hierarchy.<br> > Thanks,<br> > Nataraju A B<br> > On Fri, Jan 7, 2011 at 7:01 PM, Andreas.Eversberg <<a href=3D"mailt= o:Andreas.Eversberg@versatel.de">Andreas.Eversberg(a)versatel.de</a>> wrot= e:<br> >><br> >> in addition:<br> >><br> >> Traffic Multiframe Structures - The 26 traffic multiframe structur= e is<br> >> used to send information on the traffic channel. The 26 traffic<br= > >> multiframe structure is used to combine user data (traffic), slow<= br> >> control signaling (SACCH), and idle time period. The idle time per= iod<br> >> allows a mobile device to perform other necessary operations such = as<br> >> monitoring the radio signal strength level of a beacon channel fro= m<br> >> other cells. The time interval of a 26 frame traffic multiframe is= 6<br> >> blocks of speech coder data (120 msec).<br> >> (<a href=3D"http://www.althos.com/tutorial/GSM-tutorial-frame-stru= cture.html" target=3D"_blank">http://www.althos.com/tutorial/GSM-tutorial-f= rame-structure.html</a>)<br> >><br> >> one encoded speech block lasts 20ms.<br> >><br> >><br> >> =A0 =A0 =A0 =A0576,92307692307692307692307692308us per slot<br> >> =A0 =A0 =A0 =A04615,3846153846153846153846153846 per 8 slots (1 fr= ame)<br> >> =A0 =A0 =A0 =A0120ms per 26 frames (6 speech blocks)<br> >><br> >><br> >><br> ><br> ><br> ><br> > --<br> > Thanks,<br> > Nataraju A B<br> </div></div></blockquote></div><br><br clear=3D"all"><br>-- <br>Thanks,<div= >Nataraju A B</div><br> --00163641691bea689c04996d367c--

2 years, 4 months

1
0
0 0

None

by None

Number of symbols in a burst =3D 156.25 symbols, and burst time 156.25 x 3.69... =3D 576,92=ECs Number of symbols in TDMA frame is 8 x 156.25 =3D 1250 symbols, Number of symbols in Multiframe is 26 x 1250 symbols. On Fri, Jan 7, 2011 at 8:51 AM, Nataraju A B <natarajuab.tech(a)gmail.com> wr= ote: > > Hi Andreas, > Thanks for the speedy reply. > The link which sent you is=A0definitely=A0useful. But the very basic ques= tion I wanted to get a clarification was that, what is the drive behind sel= ection of burst time to be 577us. > For example the audio frequency can range upto 4Khz. The sampling frequen= cy should be 8Khz. If each sample is of 8 bit accuracy. This lead to 64K bi= ts of data. ...... =A0If we explore further on these lines we should be abl= e to correlate to the time 577us for each burst. > I wanted some more info these lines. What was/were the drives behind sele= ction of this burst time. Otherwise what are the other end requirements led= to selection of this burst time and in turn TDMA frame hierarchy. > Thanks, > Nataraju A B > On Fri, Jan 7, 2011 at 7:01 PM, Andreas.Eversberg <Andreas.Eversberg@vers= atel.de> wrote: >> >> in addition: >> >> Traffic Multiframe Structures - The 26 traffic multiframe structure is >> used to send information on the traffic channel. The 26 traffic >> multiframe structure is used to combine user data (traffic), slow >> control signaling (SACCH), and idle time period. The idle time period >> allows a mobile device to perform other necessary operations such as >> monitoring the radio signal strength level of a beacon channel from >> other cells. The time interval of a 26 frame traffic multiframe is 6 >> blocks of speech coder data (120 msec). >> (http://www.althos.com/tutorial/GSM-tutorial-frame-structure.html) >> >> one encoded speech block lasts 20ms. >> >> >> =A0 =A0 =A0 =A0576,92307692307692307692307692308us per slot >> =A0 =A0 =A0 =A04615,3846153846153846153846153846 per 8 slots (1 frame) >> =A0 =A0 =A0 =A0120ms per 26 frames (6 speech blocks) >> >> >> > > > > -- > Thanks, > Nataraju A B

2 years, 4 months

1
0
0 0

None

by None

" Raw mode cfmakeraw() sets the terminal to something like the "raw" mode of the old Version 7 terminal driver: input is available character by charac‐ ter, echoing is disabled, and all special processing of terminal input and output characters is disabled. The terminal attributes are set as follows: termios_p->c_iflag &= ~(IGNBRK | BRKINT | PARMRK | ISTRIP | INLCR | IGNCR | ICRNL | IXON); termios_p->c_oflag &= ~OPOST; termios_p->c_lflag &= ~(ECHO | ECHONL | ICANON | ISIG | IEXTEN); termios_p->c_cflag &= ~(CSIZE | PARENB); termios_p->c_cflag |= CS8; " If that is set on the socket for the telnet interface it does make a difference.

2 years, 4 months

1
0
0 0

None

by None

GSM handset like the Motorola C123 and talk to GSM-R BTSs. Of course you still need to implement the GSM-R specific features on layer 3 like ASCI. In both cases I think the hardware is there for whoever has a serious interest in experimenting with this technology, and who is not afraid to implement the GSM-R specific bits. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

but not the new. But in any case, the OP can fix the sql. The OP seem to have a new/more picky version of sqlite. Before in case of ambiguous column name, it took the one from the first table in the FROM list. (not sql standard but that's why it didn't matter before). > Could you also give us the "old" and "new" git hashes so we can take a > look at what changed? The hash (short) are in the version string, the log is : git log b938..f7a1c Sylvain

2 years, 4 months

1
0
0 0

None

by None

'type' used and the corresponding codec. For GSM FR the RFC specifies PT=3 but for HR/EFR/AMR, they are dynamic and must be chosed in the 96-127 range. AFAIK, we could just use a static mapping in openbsc or load that from the config. Does anyone sees a downside to that ? Sylvain --000325564d6aac09c2047af385f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,<br><br>I have a nanobts unit 139 with a software that somehow only acce= pts GSM FR (and not EFR), unless I also send the RTP payload type IE ( RSL_= IE_IPAC_RTP_PAYLOAD ) in the CRCX and MDCX messages. (and only the "RT= P payload type" IE, the "RTP payload type 2" has no effect I= can see).<br> <br>From the ip.access dissector, I think it's just a mapping between t= he RTP 'type' used and the corresponding codec.<br><br>For GSM FR t= he RFC specifies PT=3D3 but for HR/EFR/AMR, they are dynamic and must be ch= osed in the 96-127 range.<br> AFAIK, we could just use a static mapping in openbsc or load that from the = config. Does anyone sees a downside to that ?<br><br>=C2=A0=C2=A0=C2=A0 Syl= vain<br><br> --000325564d6aac09c2047af385f6--

2 years, 4 months

1
0
0 0

None

by None

messages in 12.21 are simply used to communicate state changes ?!? -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

updating/running the most recent version. > For me now, it's still much easier to debug in windows than in Linux, because > I'm not yet comfortable with gdb in comman-line. There are GUI frontends for gdb, including the old "ddd" as well as modern bloatware like eclipse ;) -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 4 months

1
0
0 0

None

by None

"The requirements yielded by the page mode information element are as follows: a) normal paging: no additional requirements; b) extended paging: the mobile station is required in addition to receive and analyse the next but one message on the PCH; c) paging reorganization: The mobile station shall receive all messages on the CCCH regardless of the BS-AG-BLKS-RES setting. It is required to receive all BCCH messages. When the mobile station receives the next message to its (possibly new) paging subgroup the subsequent action is defined in the page mode information element in that message. d) same as before: No change of page mode from the previous page mode." I think the paging reorganization mode is fine. Does anyone know this mode? I don't know if the mobile phone will answer everytimes if i try to do a paging on it for each successive frame. Or if he will answer the first time and ignore the other paging requests after. In addition, this solution enable the cell phone to listen every frames of the CCCH but I don't know if the BTS is abble to do a paging on the same mobile phone on every frames or if it still needs to follow the BS_PA_MFRMS parameter. I saw that the paging group is calculated from the IMSI. And then the paging block is calculated. Is it calculated in the BTS or in OpenBSC? link of the explanation on the paging : http://etutorials.org/Mobile+devices/gprs+mobile+internet/Chapter+5+Radio+I… Thanks Best regards Eric Cathelinaud 2009/7/15 Eric Cathelinaud <e.cathelinaud(a)googlemail.com> > 2009/7/15 Dieter Spaar <spaar(a)mirider.augusta.de> > > Hello Eric, >> >> On Wed, 15 Jul 2009 11:00:14 +0200, "Eric Cathelinaud" < >> e.cathelinaud(a)googlemail.com> wrote: >> > >> > I was just thinking about performing a recursive paging in order to see >> how >> > much time I have until the battery of a mobile phone run out. >> > Does anyone know if the mobile phone answers at every paging or if it >> > doesn't "listen" all the time? I think it listens periodically. If >> anyone >> > can give me a clue, that would be appreciated. >> >> This is an excerpt from a posting to another mainling list, I just >> quote it because I don't want to repeat what I already wrote: >> >> > - The phone is in "idle" mode (no speech/data traffic) >> > and periodically receives the paging channel (PCH) to >> > find out if its being called. Further the phone measures >> > the signal strength of neighbor cells and every now >> > and then (not that frequent as the above actions) >> > receives the cell information in the broadcast common >> > control channel (BCCH) of the serving cell and of >> > at most six neighbor cells with the strongest signal. >> >> .... >> >> > - The time between receiving the PCH is determined by a >> > parameter of the serving cell (BS_PA_MFRMS, range 2 to 9). >> > Its measured in 51-multiframes until the PCH for the phone >> > repeats (if you want to know the details have a look at >> > the GSM specs ;-) . The length of a 51-multiframe is >> > 235.8 ms, this means the time between receiving the PCH >> > is in the range 471.9 ms to 2122.2 ms. In this time the >> > idle phone most of the time sleeps or receives the BCCH >> > of the serving cell or one of the neighbor cells with >> > the strongest signal (at most six). >> >> Best regards, >> Dieter >> -- >> Dieter Spaar, Germany spaar(a)mirider.augusta.de >> > > Thanks a lot for the explanation. It's a pity that the minimum period is 2 > multiframes. I wish I could realize a paging on a mobile phone every frame > but it seems to be impossible finally. > > Best regards, > Eric Cathelinaud > > --001636499281749655046ed2de53 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,<br><br>Finally I think I find a solution to make the cell phone listeni= ng to every frames of the CCCH.<br><br>From gsm04_08:<br><meta http-equiv= =3D"Content-Type" content=3D"text/html; charset=3Dutf-8"><meta name=3D"Prog= Id" content=3D"Word.Document"><meta name=3D"Generator" content=3D"Microsoft= Word 11"><meta name=3D"Originator" content=3D"Microsoft Word 11"><link rel= =3D"File-List" href=3D"file:///C:%5CTmp%5Cmsohtml1%5C01%5Cclip_filelist.xml= "><style>  </style> <p class=3D"MsoNormal">"The requirements yielded by the page mode info= rmation element are as follows:</p> <p class=3D"B1">a)<span style=3D"">=A0 </span>normal paging: no additional requirements;</p> <p class=3D"B1">b)<span style=3D"">=A0 </span>extended paging: the mobile station is required in addition to receive and analyse the next but = one message on the PCH;</p> <p class=3D"B1">c)<span style=3D"">=A0 </span>paging reorganization: The mobile station shall receive all messages on the CCCH regardless of the BS-AG-BLKS-RES setting. It is required to receive all BCCH messages. When t= he mobile station receives the next message to its (possibly new) paging subgr= oup the subsequent action is defined in the page mode information element in th= at message.</p> <p class=3D"B1">d)<span style=3D"">=A0 </span>same as before: No change of page mode from the previous page mode."</p> <br>I think the paging reorganization mode is fine. Does anyone know this m= ode? I don't know if the mobile phone will answer everytimes if i try t= o do a paging on it for each successive frame. Or if he will answer the fir= st time and ignore the other paging requests after.<br> <br>In addition, this solution enable the cell phone to listen every frames= of the CCCH but I don't know if the BTS is abble to do a paging on the= same mobile phone on every frames or if it still needs to follow the BS_PA= _MFRMS parameter. I saw that the paging group is calculated from the IMSI. = And then the paging block is calculated. Is it calculated in the BTS or in = OpenBSC?<br> link of the explanation on the paging :<br><a href=3D"http://etutorials.org= /Mobile+devices/gprs+mobile+internet/Chapter+5+Radio+Interface+RLC+MAC+Laye= r/Listening+to+MS+Paging+Blocks/">http://etutorials.org/Mobile+devices/gprs= +mobile+internet/Chapter+5+Radio+Interface+RLC+MAC+Layer/Listening+to+MS+Pa= ging+Blocks/</a><br> <br>Thanks<br>Best regards<br><br>Eric Cathelinaud<br><br><div class=3D"gma= il_quote">2009/7/15 Eric Cathelinaud <span dir=3D"ltr"><<a href=3D"mailt= o:e.cathelinaud@googlemail.com">e.cathelinaud(a)googlemail.com</a>></span>= <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class=3D"gma= il_quote">2009/7/15 Dieter Spaar <span dir=3D"ltr"><<a href=3D"mailto:sp= aar(a)mirider.augusta.de" target=3D"_blank">spaar(a)mirider.augusta.de</a>><= /span><div> <div></div><div class=3D"h5"><br><blockquote class=3D"gmail_quote" style=3D= "border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padd= ing-left: 1ex;"> Hello Eric,<br> <div><br> On Wed, 15 Jul 2009 11:00:14 +0200, "Eric Cathelinaud" <<a hre= f=3D"mailto:e.cathelinaud@googlemail.com" target=3D"_blank">e.cathelinaud@g= ooglemail.com</a>> wrote:<br> ><br> > I was just thinking about performing a recursive paging in order to se= e how<br> > much time I have until the battery of a mobile phone run out.<br> > Does anyone know if the mobile phone answers at every paging or if it<= br> > doesn't "listen" all the time? I think it listens period= ically. If anyone<br> > can give me a clue, that would be appreciated.<br> <br> </div>This is an excerpt from a posting to another mainling list, I just<br= > quote it because I don't want to repeat what I already wrote:<br> <br> > =A0- The phone is in "idle" mode (no speech/data traffic)<br= > > =A0 =A0and periodically receives the paging channel (PCH) to<br> > =A0 =A0find out if its being called. Further the phone measures<br> > =A0 =A0the signal strength of neighbor cells and every now<br> > =A0 =A0and then (not that frequent as the above actions)<br> > =A0 =A0receives the cell information in the broadcast common<br> > =A0 =A0control channel (BCCH) of the serving cell and of<br> > =A0 =A0at most six neighbor cells with the strongest signal.<br> <br> ....<br> <br> > =A0- The time between receiving the PCH is determined by a<br> > =A0 =A0parameter of the serving cell (BS_PA_MFRMS, range 2 to 9).<br> > =A0 =A0Its measured in 51-multiframes until the PCH for the phone<br> > =A0 =A0repeats (if you want to know the details have a look at<br> > =A0 =A0the GSM specs =A0;-) . The length of a 51-multiframe is<br> > =A0 =A0235.8 ms, this means the time between receiving the PCH<br> > =A0 =A0is in the range 471.9 ms to 2122.2 ms. In this time the<br> > =A0 =A0idle phone most of the time sleeps or receives the BCCH<br> > =A0 =A0of the serving cell or one of the neighbor cells with<br> > =A0 =A0the strongest signal (at most six).<br> <br> Best regards,<br> =A0Dieter<br> <font color=3D"#888888">--<br> Dieter Spaar, Germany =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 <= a href=3D"mailto:spaar@mirider.augusta.de" target=3D"_blank">spaar(a)mirider.= augusta.de</a><br> </font></blockquote></div></div></div><br>Thanks a lot for the explanation.= It's a pity that the minimum period is 2 multiframes. I wish I could r= ealize a paging on a mobile phone every frame but it seems to be impossible= finally.<br> <br>Best regards,<br><font color=3D"#888888">Eric Cathelinaud<br><br> </font></blockquote></div><br> --001636499281749655046ed2de53--

2 years, 4 months

1
0
0 0

Wanted: pcap file of Iu interface of 3G circuit-switched video call

by Harald Welte

Hi, I'm wondering if anyone has a pcap file containing an Iu (or Iuh) interface protocol trace of a classic 3G circuit-switched video call around? I would be curious particularly in the user plane side, i.e. showing the RTP with IuUP for video calls. But I presume the RAB assignments are also going to be interesting... I know Dieter used to play with 3G CS video with one of his handset testers. Hoewver, I doubt that device would have any Iu interface internally, so this will unlikely provide any help here :/ Thanks in advance, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 5 months

1
0
0 0

OsmoDevCall on Dec 10, 2021: osmo-dev and running TTCN3 test sultes locally + PFCP

by Harald Welte

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at December 10, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "osmo-dev and running Osmocom TTCN3 tests suites locally" by osmith 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 5 months

1
0
0 0

OSMO-MSC External MNCC integration with FeeSwitch

by Justin

Hi Osmocom, I'm trying to integrate the FreeSwitch as my external MNCC in my test lab using split stack. Currently, I'm getting an error message on FreeSwitch SIP/2.0 400 Missing Contact Header. I'm little bit confused with the error and I don't know where to troubleshoot this. I've attached my osmo configurations and pcap trace for your reference. Hoping for your reply. Thank you. Regards, Justin Mark Repollo

2 years, 5 months

5
16
0 0

AGCH Channel via virtual Um

by Ivan Babanov

Hello all! I'm sorry for a stupid question, but I can't find an answer by myself. We are using Osmocom solution in University to demonstrate to students how GSM works. We have and fully virtualized workplaces with osm-bts-virtual and osmocom-bb UE via virtual Um. We are making an IMSI Attach procedure and capturing traces with wireshark. Virtual Um messages are visible in wireshark traces with "gsmtap" filter. According standart description, after RACH request UE should receive channel assignment via AGCH channel. But AGCH is not visible in traces. Am I wrong in my expectations somewhere? I tried to filter out messages, tried to filter gsmtap.chan_type == 4 but still no luck. Thank you Vania

2 years, 5 months

1
0
0 0

"OsmoDevCall" on Nov 25, 2021: Control/User Plane Separation (CUPS) + PFCP

by Harald Welte

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at November 25, 2021 at 20:00 CET (yes, Thursday instead of Friday this time!) at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "Control/User Plane Separation (CUPS) + PFCP" by laforge 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 5 months

2
1
0 0

Osmocom CNI release 202111

by Pau Espin Pedrol

Dear all, I am pleased to announce new tagged releases for Osmocom Cellular Network Infrastructure components. Find more information about the release here [1]. Osmocom "Latest" repositories in OBS [2] should already contain packages for the new versions. OpenEmbedded related meta-layers such as meta-telephony usual stable/testing branch "201705" [3] have also been updated to build recipes for new versions. Regards, Pau [1] https://osmocom.org/news/152 [2] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds [3] https://git.osmocom.org/meta-telephony/log/?h=201705 -- - Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 years, 6 months

2
1
0 0

"OsmoDevCall" on Nov 12, 2021: icE1usb in practice

by Harald Welte

Dear Osmocom community, It's my pleasure to announce the next OsmoDevCall at November 12, 2021 at 20:00 CET at https://meeting4.franken.de/b/har-xbc-bsx-wvs This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation "E1 / TDM / PDH / SDH basics" by laforge 20:30 presentation "icE1usb in practice" by tnt later USSE: unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you on Friday. Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 6 months

1
0
0 0

Anyone still using mISDN for OpenBSC / OsmoBSC / OsmoMGW ?

by Harald Welte

Dear Osmocom users, the Linux kernel developers are considering to remove mISDN from the kernel, as can be seen in posts like https://marc.info/?l=linux-netdev&m=163636911918302&w=2 They are aware that Osmocom still supports mISDN, but it would of course be interesting if anyone is actually still using this approach. I've switched to DAHDI a long time ago (4- and 8-port cards for PCIe available) and only used mISDN very early on with the HFC-E1 in the 2008-2011 timeframe. These days, I'm using both DAHDI and icE1usb. IMHO, mISDN based interface cards are becomming less and less attractive, as the chips only support parallel PCI bus and I've never seen cards with more than two ports. So the point of this post is to find out if anyone still is using [or planning to use] mISDN. If so, please let me, netdev + Anrd Bergmann know about it. Basically it is kind of a "speak now or forever hold your peace" kind of moment, as mISDN would then likely be phased out from mainline Linux. Even in that case I think libosmo-abis should keep mISDN support, as there will be Linux systems on older kernels for many years to come, and the mISDN support doesn't hurt the rest of our code base in any way. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 6 months

3
2
0 0

pysim-shell: export is missing some files

by Riemer, Björn

Hi, i recently noticed that the `export` command from pysim-shell is failing on some basic files like EF.ICCID. However if i manually select the file it can be read. This happens on a generic USIM and on the orange sysmousim-SJS1. see the logs below to illustrate. Cheers Bjoern sysmo usim: <..snip..> ################################################################################ # Export summary # ################################################################################ # total files visited: 165 # bad files: 75 # MF/EF.DIR, string indices must be integers # MF/EF.ICCID, string indices must be integers <...snip...> pySIM-shell (MF)> select EF.ICCID "621e8202412183022fe2a506c00100ca01808a01058b032f06048002000a8800" pySIM-shell (MF/EF.ICCID)> read_binary_decoded { "iccid": "8988211000000169394" } ------- KDDI USIM: Using PC/SC reader interface Waiting for card... ATR: [59, 157, 149, 128, 63, 199, 160, 128, 49, 160, 115, 190, 33, 83, 81, 6, 131, 5, 144, 0, 63] Autodetected card type: Generic-UISIM AIDs on card: USIM: a0000000871002ff81ff108904150001 Welcome to pySim-shell! pySIM-shell (MF)> select EF.ICCID "0000000a2fe204000fffff01020000" pySIM-shell (MF/EF.ICCID)> read_binary_decoded { "iccid": "8981100055906574179" } pySIM-shell (MF/EF.ICCID)> select MF "0000ffff3f0001000000000011b304110400838a838a0000000000000000" pySIM-shell (MF)> export ################################################################################ # MF/EF.DIR # ################################################################################ # directory: MF (3f00) # file: EF.DIR (2f00) # bad file: MF/EF.DIR, string indices must be integers # ################################################################################ # MF/EF.ICCID # ################################################################################ # directory: MF (3f00) # file: EF.ICCID (2fe2) # bad file: MF/EF.ICCID, string indices must be integers #

2 years, 6 months

1
0
0 0

enabling ssh on nano3g s8

by Erich Dachleger

Hi all,Is there some special routine for enabling ssh on nano 3gs8 device?Or is the unit "useless" if the ssh-daemon is not running?(I have no way of seeing whether or not it is running) I can access by telnet to dmi interface, the telnet commands from the wiki are present and have read the docs from accelerate 3g but I think there might be some subtle info I miss regarding starting ssh. Port 22 is blocked is the errror message I get and i also tested the aes-method suggested in the wiki, same error, port 22 blocked also in that case. Could this be the situation where one has to try setting up a tr069 server? Regards /erich

2 years, 6 months

1
0
0 0

USA or Mexico alternative to OsmoDevCon?

by Mychaela Falconia

Hello fellow telecom hackers, Seeing that OsmoDevCon 2022 is being discussed, I would like to propose a more inclusive alternative, to be held in either USA or Mexico. There are two severe lack-of-inclusion problems with OsmoDevCon: 1) Since its very beginning, ODC has been exclusionary, limited only to Osmocom developers specifically, excluding those developers and tinkerers who work on non-Osmocom projects in the "indie" telecom space, "indie" being defined as independent of major commercial vendors and industry. I hold the opinion that all monocultures are bad in principle, and an Osmocom monoculture is no better than, say, a Microsoft monoculture. Osmocom is currently in the dominant position, outweighing all others by some orders of magnitude, but might does not make right, and we need more diversity. We need more players in this niche space than just Osmocom! 2) The recent decision to limit OsmoDevCon only to those who have agreed to put a certain class of pharmaceutical into their bodies, *on top* of the Osmocom-only restriction of the previous paragraph, makes the proposed conference even more exclusionary and therefore of no service to the wider telecom hacker community. Of course it is not my place as a Russian-American to try to tell EU countries whom to allow or not allow within their borders, nor is it my place to tell private individuals like our Fearless Leader Harald whom to allow or not allow in their private spaces. But what I *can* do instead is to step forward and offer to organize and host a more inclusive alternative, and that is what I am doing with this post. Specifically I am offering to organize and host a physical in-person gathering of telecom (all telecom, not just wireless) hackers, enthusiasts and tinkerers, very similar in spirit to OsmoDevCon, but more inclusive: 1) Welcoming everyone who has devoted a major portion of his or her life to *any* project in the indie telecom space, regardless of which domain that project is hosted under, and regardless of whether that project is FOSS or merely PSS. (PSS = Published Source Software, a superset of FOSS.) 2) Welcoming everyone regardless of personal medical choices - what you do with your body is your business, not mine - you don't tell me what I should or shouldn't put in my body, and I won't tell you what you should or shouldn't put into yours. Also no forced testing: if you wish to get yourself tested for this or that before attending, it is your sovereign choice to do so, but no one will *ever* be turned away from an event which I organize and host, neither for refusing to test nor for any other reason. If there is anyone interested in such an inclusive in-person gathering of telecom hackers, I am offering to host one in my part of the world. Where is it geographically? I live in USA, near San Diego, and right next to the border between USA and Mexico. Depending on who is interested in joining and where they will come from, I can host our InclusiveDevCon on either side of the border, i.e., either in USA or in Mexico. It is my understanding that gaining entry into Mexico is much easier than gaining entry into USA, hence for that reason I suggest that we hold our get-together on the Mexican side of the border. If we do choose Mexico as our host country, the specific location will need to be in the northern part of that country, specifically in the Mexican state of Baja California; the candidate cities would be Tijuana or Ensenada, somewhere close to the border with USA. However, if the only people who are interested in joining either already live in USA or can easily enter this lovely country, then holding our Inclusive- DevCon in USA would make more sense - in that case it will be somewhere in San Diego area. Alternatively, if there is anyone in the community who shares my stated values of wider inclusion but cannot or does not wish to travel to USA or Mexico, if you would be willing to host an inclusive event in your part of the world, then I will consider traveling to attend your event - but *only* if your event is open to non-Osmocom PSS developers *and* open to those who refuse injections. Please note, however, that I cannot enter Russia - other parts of the former USSR including Transnistria are potentially accessible to me, but not Russia - I was born there, but I permanently lost the ability to visit my birthplace as a result of having done my gender transition while living in USA, with all steps for legal name and gender change done under the American system, as opposed to Russian. In hacking solidarity, Mother Mychaela of FreeCalypso

2 years, 6 months

3
3
0 0

Catching missing #include of <endian.h>

by Vadim Yanitskiy

Hi list, today I fixed a header file in libosmocore: https://gerrit.osmocom.org/c/libosmocore/+/26044 TL;DR, using OSMO_IS_{LITTLE,BIG}_ENDIAN macros without including the <osmocom/core/endian.h> header leads to empty struct definitions, and thus weird compiler warnings like 'struct `foo` has no member `bar`'. We may want to catch missing #include of the <endian.h> automatically, so I wrote a simple script to check whether it is absent: https://gerrit.osmocom.org/c/osmo-ci/+/26045 Below is an example of using it: $ cd libosmocore/ $ verify_endian_header.sh $(find . -name "*.[hc]") File './include/osmocom/gsm/protocol/gsm_44_004.h' does not #include <osmocom/core/endian.h> What's still missing is the actual integration into the build verification process. I guess there is currently no easy way other than calling this script from 'contrib/jenkins.sh' of each project? P.S. I found out that we also have 'scripts/verify_log_statements.py' in osmo-ci.git, but we don't seem to call it anywhere? Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 years, 6 months

2
1
0 0

GSMTAP messages not generated

by Mario Lucas

Dear All, I am running a GSM stack: osmo-stp smo-msc osmo-hlr osmo-bsc osmo-bts-trx osmo-trx-lms It seems that my transmitter is emitting radio-waves into air (osmo-bts-trx and osmo-trx-lms communicate with each other through ports 5702 / 5802 — pls see attached printscreen), however i could not make GSMTAP tracing. Osmo-bts-trx does not send GSMTAP messages to port 4729. In most recent version of osmo-bts, GSMTAP tracing is arranged through config file: bts 0 gsmtap-remote-host 127.0.0.1 gsmtap-sapi ccch I could not run the GSMTAP tracing even in previous verions of osmo-bts where you have to specify in synopsis when you call a program: /usr/bin/osmo-bts-trx -s -c /etc/osmocom/osmo-bts-trx.cfg --gsmtap-ip 127.0.0.1 I thought may be i am having some issues in stack components behind osmo-bts for example in osmo-bsc or behind and i tried to run virtual bts. When i tried to run osmo-bts-virtual GSMTAP messages were visible in wireshark (please see attached file osmo-bts-virtual), therefore bts-bsc communication is good. However I still could not figure out why my osmo-bts-trx does not send GSMTAP messages. Or would you advise what log might be helpful to see what i am doing wrong …. Thank you for your always helpful assistance -- Mario Lucas ---------------------------------------------------------------------- -- Mario Lucas

2 years, 6 months

1
0
0 0

Osmocom redmine upgrade / Let me know if something broke

by Harald Welte

Dear Osmocom community, today we finally upgraded our redmine installation from the unmaintained 3.4.x to the latest 4.2.3. The upgrade had been overdue for years, but today we (actually, Kevin) finally managed to find out how to make the openid_provider plugin to work with modern rails 5.x. In any case, I'm just informing you in case there is some unexpected fallout. I've verified that at least the following appears working: * logging into redmine * openid authentication from gerrit.osmocom.org (also after logout/relogin) * graphviz rendering * mscgen rendering There could however still be unexpected problems, particularly in features such as * e-mail notifications from redmine * updating redmine issues via e-mail * git integration ("Closes: OS#xxxx") If you run into any troubles, pleas report to https://osmocom.org/projects/osmocom-servers or if that also fails, feel free to send e-mails. Regards, Harald -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 years, 6 months

1
0
0 0

nano3g 237A <apologies if this is a repost>

by Paul Atreides

Not sure if this is a repost, i just joined the list and i don't think i had confirmed my account when i sent it (the confirmation was in my spam). Anyways, not trying to be a bad list member. I just picked up this IPAccess model which supports band 2/5 and has the same housing as the other units on the accelerate3g5 project docs. I've been pouring over docs and trying a lot of network configurations in my home lab. I have the login information for the factory reset and can access the web gui on port 8089 during the reset process, but ssh and telnet DMI seem to be disabled. I've been fuzzing ports and i've tried static as well as DHCP for IP addresses. My thought was that if i point the nano3G to the IP of my osmo-hNodeB machine that it would at least stimulate the device and maybe i'd see some log messages in the HNodeB gateway, but so far i haven't seen anything in the logs. i've also tried abisip-find and that doesn't find anything. Wireshark shows basic 'who has' Layer 2 messages and also DHCP requests sent to 0.0.0.0, both from the nano3g. The nano3g does get an ip from my lab router and i can ping it. The LAN behind that router can also access the 0.ipaccess ntp server, but again no telnet DMI or ssh so i'm unsure where to go from here. Layer 1 seems to show nothing on the uarfcn in the web gui, so it seems that its not crossing all the right bridges. I will admit, i haven't run any other osmo network components for the network, but as far as i was reading the home nodeb gateway and ntp should be the only things necessary to at least start the process. Any insight on what to try next would be very helpful. Does anyone have experience with this model? thanks

2 years, 6 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC