OsmoDevCon2012 Minutes » History » Revision 2
Revision 1 (laforge, 02/19/2016 10:47 PM) → Revision 2/3 (laforge, 02/19/2016 10:48 PM)
{{>toc}} [[PageOutline]] = Meeting minutes of [[OsmoDevCon2012]] h2. [wiki:OsmoDevCon2012] == Day one == Start of day one. h3. === Introduction round h3. === === 11:30 UMTS Phone hacking === laf: complexity is higher than gsm -> therfore no complete implementation of lowerlevel parts use existing low-layer implementation (through reverse engineering) qualcom rev project implemented a software debugger dsp: using jtag could introduce timing problems, software solution make sense laf: QC modem does not use crypto/signing, has multiple firmware images, uses rex (micro?)kernel. Newer ones use L4 as micro-kernel have build adapter board for accessing JTAG dsp: there is an interface for debugging/tracing available laf: attaching to the L2/L3 interface and exporting that via USB would be a likely next step chem: QC works together with sec. researchers / responsible disclosure laf: right now this HW is still easily available, similar conditions to start of osmocom project expects that newer HW will be locked down, so now would be a good time to start working dsc: is also a good investment into the future, some LTE sticks are also QC base and not locked down (they also support UMTS, internal architecture is similar) (50-100€ LTE stick) tracing protocols are similar, too firmware update contains an ELF binary (with debug info) laf: has started to look at MTK 3g/3.5g smartphones, also sold outside china, too use an integrated design (AP/BP in one chip, like QC) the GSM part is similar to the older MTK chipsets we know second sim slot is on the AP side (dual sim standby) maybe possible to access the BP side from AP good CPU performance, 100€ still looking for UART/JTAG, pinout is known work going on to get them to publish linux kernel code the protocol between AP/BP seems to be not a binary one some devkit seems to be coming -> documentation chem: there is work going on to get an LTE/LTEadvanced PHY level stack? burg: the complexity of LTE phys layer is much less than for UMTS (LTE is more similar to wimax) chem: LTE market is much more open than traditional (UMTS) telecom china+india will use LTE-TDD much more popular than (UMTS-TDD) SDR is current very popular in china for custom and niche designs/protocols/crypto (instead of ASICs) burg: is RR mgmt available on the interface/message queues (in QC UMTS modem)? laf: all parts of the stack use the same MQ system 28C3 talk: http://events.ccc.de/congress/2011/4019976347022Fahrplan/events/4735.en.html HW is still easily available, similar conditions to start of osmocom project expects that newer HW will be locked down, so now would be a good time to start working dsc: is also a go burg: RR control in UMTS is the primary difference to 2.5G, the rest is similar, spec alone is hard to use dsp: [[UbiNetics]] UbiNetics TM100 is a UMTS layer 1 "phone", large, dsp-based, gives you acces to L1 data over TCP are very hard to get&expensive, is LTE capable, designed for equipment designer, not enough documentation useful for UMTS L1 debugging, there is nothing comparable available, the QC modem is no replacement (they use HW for some L1 stuff) burg: for UMTS development a good diagnostic tool is a requirement chem: LTE reuses a lot of IETF protocols, looks like UMTS for data for voice calls there are several options: initial LTE was IP data only (like wimax), no notion of voice calls switch back to CS network GSM/UMTS [[VoLGA]]: VoLGA: Voice over LTE Generic Access (unlikely to be widely deployed?) [[VoLTE]]: VoLTE: it is an IMS connection (internet multimedia subsystem, basically SIP with diameter, ...) internet protocols "adapted" by telecom companies -> complex IMS would not be ready for LTE, [[VoLTE]] VoLTE is a subset for voice+sms -> voice signaling is completely outside of the radio stack Initial [[VoLTE]] VoLTE proposal is available, real standard is very similar (real only available to GSMA members) chris: LTE phone have short standby because the need CS net + LTE at the same time laf: contact me icon for jtag debug adapters (new jtag board as a replacement for simcard holder, difficult soldering) vogelchr: can UMTS modulation be done on a PC? burg: yes, on 2.5GHz multicore dsp: also exists for LTE burg/dsp: drawbacks of CDMA (UMTS), bad technology laf: general predictions? UMTS will be switched of before GSM burg: the problem going to LTE is completely changing the core network to IMS (to replace ss7/ (ss7 on ethernet)) chem: we will see many LTE networks, running LTE on 700MHz dsp: 800MHz in germany, he has LTE signal but no GSM/UMTS coverage at home, is intended as a DSL replacement burg: some teco eng. would not trust IMS core network for 1-1.5 years for paying customers laf: theory: GSM for voice (because of large cells) burg: nice for openBTS, plug it into IMS :) laf: Time-Gap filler: have received donation of sagem GSM (MyX6 HW) trace phones (5 support GPRS) comes with windows program and protocol documentation, can do protocol traces steve-m: JTAG pinouts are documented see http://senkron24.se.funpic.de/Test%20points%20/sagem/j-tag/tst%20point/MyX6_X7_V65_V75_TP.jpg phone contains Calypso + TWL3014 laf: we'd need a wireshark decoder dsp: some lectures and code is available for this phone linked from our wiki h3. === 13:xx-14:30 Lunch + Hallway Track === laf: The schedule has changed let's talk about sim cards... we have sysmoSIM cards where we can create arbitrary files, ki, iccid, … for iccid you have to apply at the ITU, complex&expensive process problematic to find this for uSIM, none where we can place arbitrary files, only very expensive we found fully programmable cards instead, without OS, though datasheets are available, but samples not yet it is a CC32RS512, 16kB ram 512kB flash no mask ROM see: http://www.alibaba.com/product-gs/526964999/CC32RS512_Smart_card_with_32_bit.html ARM7TDMI laf wrote a set qemu peripherals -> git.osmocom.org (http://cgit.osmocom.org/cgit/osmo-cos/) no incremental/byte program, page only -> makes FS development harder, laf has some plans here would be good to have another source this die has an additional ISO 7816-3 slave & master chem: difference between SIM and uSIM? laf: uSIM has a completely different protocol (beginning with the class id?), filenames and so on both based on ISO 7816 uSIM has a backwards compatibility mode (so there are two ways to access each information) many different modes for authentication uSIM cards: 2G/3G uses milenage for both 2G and 3G 3G phone, 3G network, 2G sIm => depends on network operator configuration... Today: most likely 3G sim for 3G network, milenage -> this allows authentication even on 2G roaming networks and 2G phones uSIMs also have files for recently used ARFCNs (to speed up startup) discussion: how does mutual auth work in UMTS networks when using a GSM SIM? (unclear) standard is: 33.102 laf: we have an implementation of milenage in libosmocore, a util to generate the data and a python utility to connect to a card reader and run UMTS Auth (osmo-sim-auth) laf: the cards have no ROM bootloader, so for lowlevel bringup the qemu emulator is a good option h3. === 15:00 OSMO GMR === Voice: See slides TDMA Framework Thoughts:No Slides, GNUradio hard to compile, channelization can not be handed to the GPU, demodulation tough (e.g. burst, no constant phase), muller/muller problematic, e.g. not locked at the end of a burst. chem: Upstream works on features for packet radio Framework like the calypso phone works. Define how channels are timed on TDMA, calls for demodulate this frame...., calypso very constraint hardware, we can allocate memory. david: repurpose l1 of [[OpenBTS]]. OpenBTS. E.g. add something to sync, keep virtual frame number, record offset between virtual and decoded frame number... chem: Talk to Thomas, GSM decoding for TI Cx64(??), TDMA code for DSP tnt: Still too tight to GSM, good as example for finding a good architecture. Want to understand how it works, not just taking code from Airprobe|OpenBTS [[MultiRX]]-Tool: MultiRX-Tool: See slides abstraction layer for FCD, UHD, [[OsmoSDR]], OsmoSDR, RTL-SDR, … hardware, generic interface channel config: CXX class, one file containing channel definitions (output sample rate, channel bandwidth, overloaded freq calculation function from ARFCN value) more devices (and cheaper): calculates number of hardware devices required and distributes user requested channels over a bunch of devices, e.g no wideband receiver needed to capture UL & DL simultaneously. Outlook: Discovery mode for automated scanning (think of Wardriving) Integration of available demodulators Demodulator frequency error information used in multirx to allow better signal acquisition. laf: is tool available? ?: work in progress (FIXME) 5 minutes break h3. === laf: Osmo-SDR (no slides, video) === project has been running under the osmocom umbrella the HW ppl wanted to do that anyway for ham radio that's why its a bit diffreent than other project PCB assembly should happen in next weeks have enough components for 100 units samplerate 1M samples, possibly higher in another revision rate limited by serial interface between fpga and sam3u software is usb audio device with 1Ms at 14bit ADC usb audio at this sample rate does not work on OSX/Win32, custom driver needed spectrum looks clean sam3u has many usb endpoints, could be used to have a serial port in addition to usb-audio control could also use usb control messages, is exported via libusb timestamping is not possible in usb-audio, would need a different mode (to detect lost samples on the host) sam3u can do scatter gather dma, so not problem Price EUR 150.00 + vat, clock generator not cheap (USD 20-30), SAM3U, E4000..., WEEE registration is of course open hardware, more expansive than RTL-SDR will be in sysmocom's webshop in 2 weeks both FPGA and SAM3 gpio's are on headers TX board will be designed/created in the common weeks. the E4000 has many software configurable filters, and you can connect external baseband filters could do oversampling in the FPGA VHDL code is available via email from laforge firmware is in git repo, uses cortex m3 toolchain arecord has limit on sample rate… needs oneline patch with the powerful MCU we could frequency hopping onboard PWM for gain control are available, we could add a lot of intelligence can tune in 1MHz steps? SI570 1pps input for GPS sync SWD debug board, Versaloon the only one available, STM develboard quite cheap as well h3. === 16:45 GSMTAPv3 (slides+video) === variable header: Q/statements length in multiple of 32 bits... where to define padding? content might not be multiple of 32 bit len..could be shorter access to payload is not aligned A: variable header mostly for information, len in bytes reduced max size... Q/statments fixed header len? End-Of-Options? 8bit tag/8bit len breaks alignment... but small types fit in 32bit tag: MSB indicates...(like Q931.. ISDN) tag: extension bit... long length field Statement: Tag address space split... change... if we need longer length field we can use some extension for the length field (then we can not skip unknown tags anymore). Manual padding (padding field) Length field: represents real length, but next one will be 32bit aligned Netlink... defines infrastructure for it Q: How is a block defined? Hierachical? A: Flat, A block is what you define for the protocol, e.g. logical channel with channel number, TS Q: Physical block representation? A: Block == Value of TLV Two Datalink types assigned to us... by tcpdump Variable headers... Datatype in the header? changes the meaning of the payload completly. Too much freedom will be hard to specify... laf: Just allow one type, otherwise everyone needs to implement everything. laf: App dev PoV.. easiest to export in the native way, but GSMTAP should specify the format as it allows interop, only one input format needed. chem: 1.) sending APP might be resource constrained 2.) only receiving app is wireshark tnt: Want to change 2nd chris: multi-rx laf: virtual layer1 osmocomBB <-> osmoBTS.. use GSMtap for exchange? multicast UDP chem: care more about sending application, more restricted in resources ... laf: native types, new subtypes chem: openbts on embedded board, wireshark can do any conversion david: raw sample case is corner cases, wireshak does not have software radio support. No raw sample format. laf: Demodulated soft bits? david: questionable, no fec in wireshark tnt: other receivers might be interested API laf: msgb + len? where to start from? tnt: Functions call msgb_put Rename msgb to osmo_msgb? (clash with ortp/str_util.h), possibly there's a workaround, msgb deeply integrated in all osmoX-projects. Q: What about adding n times the same atribute to one frame? laf0rge(?): possibly one TLV with 4xV.. normal code will read the normal value, others the next three as well Migration: tnt will take the notes and come up with a proposal Get things into wireshark, so they sink into distributions... coffee break 17:45-18:00 18:15 dimitry is presenting his hardware old (15 years) ISA board with SS7 implementation. DSP are used (single thread) he added an FPGA to run the netlist E1 output normally second board (6 years old) out of production (ISA also) wants to do a board with 2xE1 outputs (open source software, probably not HW), ~80% done SS7 implementation not readable yet (needs month), but could then be published h3. === 18:30 round table / rectangular table on [[OsmocomBB]] OsmocomBB === TOPICS: "De-Branching" (BTSAP, …) sr-labs, external patches User Interface Statetransitioning in L1 NuttX GPRS Roadmap? mtk port? porting of l2/l3 into the phone.. misc... 1. Branches (SAP) dexter sim so we should remove the branch... jolly-bts is not meant to be merged jolly: jolly-measurement is obsoleted (may still contain some handover parts) jolly-ui? is a hacked ui, will talk about that later laforge/mobile_event? will check....... laforge/neigh_sb? nion/sap: needs to be tested by someone else prom/dietlibc: is a port to dietlibc, we keep it until we need it prom/loader-crc: can be removed prom/simaccess: ??? steve-m/burst_mcsi: merge it into sylvain's branch steve-m/loader_sciphone: has been merged steve-m/mtk_hack: initial effort to support the MTK 223 6227 BBs (contains register offsets) sylvain/burst_ind: contains lots of DSP changes, supports multiple slots, but does not work as a phone anymore. could be merged to master (as compile option) sylvain/testing: one frame dropped when going from high to low band. l1 should be corrected to anticipate that, instead of having the dsp recover vogelchr/battery: is a dead end, will be replaced with the current version (force push current) vogelchr/framebuffer: is merged, has been removed 2. sr-labs, external patches luca/catcher luca/gsmmap ask to rebase/clean on top of master, after sylvain merged it -> laf 3. Statetransitioning in L1 tnt: resynch parameters for the sync part should be changed/read atomically -> state_changed task task concept must be extended (undefined) can we afford to skip one frame in certain cases? using only alignment TS 0/4 should be simpler, but doesn't work so far tnt&laf need to think about this some more 3 1/2. Powersave laf: shouln't be that much work we know the wakeup point from TDMA schedule tnt: implement discont RX first? dieter: deep sleep (disabling main clock) could introduce problems, is not enabled in the original fw (tsm430). several other sleep modes exist (without disabling main clock) 4. User Interface jolly: i've got a branch, still working is a rather hackish framebuffer approach (which is now merged) the UI is in the stack, jolly wants a split between the application and UI, maybe the same with VTY new DLCI for the UI? laf: we've been thinking about apps on the phone some times already message queues between those parts make sense maybe even queue between different parts of the stack, threads? -> requirements on OS? stack <-> ui <-> screen/kb tnt: different ui parts (battery+clock) & primary app laf: semantics: blocking or message queues (with threads)? tnt: tasks: main loop which polls different components? basically a list of tasks to be polled, each one checking its queues and does processing without blocking. Dynamic list rather than hardcoded. not a preemptive multitask (with timer interrupts and such) ??? laf: we should try to come up with a plan to run everything in the phone what should be the primitives? direct framebuffer access? messages to ui component? could handle diffrent screen layouts dieter: this widget stuff should be available somewhere as open source look at rockbox, where an light UI has already been implemented (for simple devices) in the beginning there was the idea of using LUA. how about that? (http://www.eluaproject.net/) ?: access to the GSM stack from a host cpu process instead of telnet? laf: message queues should be a approach for this? devel the UI on the PC (so to debug), then port it to the phone -> serial used laf: summarizing, limited requirements for OS, no fullblown kernel (scheduler preemption) we only need message queues and a way to allocate messages discussion about memory allocators: Deal with != memory types (isram/esram) laf: maybe use gsm stack on internal ram and ui external ram? see how that goes tasks: define abstraction primitives beween app <-> ui ? rockbox investigation define primitives gsm stack <-> app move layer 2 and 3 to phone (is independant of tasks above) primitives can also be developed on the PC before moving them to phone l1ctl is ugly, needs structure, now we know better memory alloc: we don't need arbitrary sizes, something like slab would make sense 5. NuttX laf: it seems we don't need it (yet) according to UI discussion tnt: has not looked at in detail, would be nice to have some of the work done for us but it doesn't seem to do that much? hardware abstraction? has a filesystem l1 is already very self-contained laf: it is posix-like, should make it easier for developers steve: rockbox is also a small OS, could be a better choice? (or source of inspiration) tnt: OS mainly useful for l2/l3 laf: posix semantics would mean copying of messages, would be nice to do without copying could become a problem tnt: we don't see much of the (voice) data at all laf: assuming we could leave the l1 unmodified the burst handling could be done in FIQ? tsaitgaist: could 3G L1 be also as selfcontained as for GSM? laf: application messages would be like: scan for networks place a call ... this would not be much different for 3G laf: summary we could not gain much from nuttx, rockbox could provide use with UI (inspiration)? steve: framebuffer is mosly compatible laf: look at rockbox tonight, discuss tomorrow (general agreement) 6. GPRS Roadmap? tnt: not going to happen dieter: testing could be done on nanobts laf: l1 for gprs too complex, for networkside gprs debugging we don't need osmocombb gprs just send bursts to wireshark 7. mtk port? laf: seems stalled steve: TX works (Marcin's uboot repo) laf: doesn't seem to be that much of a problem, just needs time and an interrested person they don't have a TPU, TDMA timers instead, needs reverse eng. higher level: what do we gain, no shortage of C123, otoh more CPU/better display usb for charging, no special cable needed steve: even cheap ones have USB highspeed laf: has edge, but we don't have gprs, only for sniffing (low interest in this round) laf: better to get current stuff working autonomously marcin would need to push this forward 8. porting of l2/l3 into the phone.. laf: see above... 9. misc... laf: kevin wants to build a bord for connecting and charging the c123 (peter shows his c123 board holder) charging: trickle chare requires calibration, missing documentation for selfcalibration laf: do no trickle charge, simply constant current, then discarge steve: be careful with the [[LiPoly]] LiPoly battery on the FIXME, needs different code vogelchr: do we need something like debugfs? something to get/set debug variables (in l1?) laf: generalize code from osmo-sdr peter: FW sends a list of variables/types then a generic ui is easy laf: osmo-get-setter registering dynamic unix socket channels, like old inetd protocol? laf: steve did multiple channels in osmocon? steve: no, that was prom peter: usb=packets<-/->serial=stream :/ laf: we just need some transport COMMIT EOF End of day one. Start of day two. h2. == Day two h3. == === 10:20 GSM core network (video and slides) h3. === === 15:00 osmo-BTS/sysmoBTS (video, no slides) === === 16:00 femtocells (video and slides) === h3. === 17:30 VTY === zecke: problems with VTY hard to teach to users (flat/nodes) wiki page is outdated/wrong he started to look at generating content from the running code (for documentation) based on XML/XSLT some working code exists, but not finished, are there better ways? ...: we should extend VTY a bit to allow more flexibility - Add a new version of DEFUN to signal when a command is meant to change node so that the code that prints the XML can reconstruct the tree - Add a default vty command that allows to print the xml doc. (easiest way and can be used as vty 'introspect') h3. === 18:20: [[OpenBSC]] OpenBSC todo === better VTY configurability laf: some configurarion options can be run at any time, other only become effective much later -> much confusion on cisco, config changes become active when you leave the node similar approach would make sense, but is very different than how it works now tnt: add VTY hooks to "commit" changes on leaving node? laf: maybe a signal instead? the signal would transport a pointer to the struct corresponding to the node moving media proc out of the main process laf: useful for straceing openbsc when traffic is going through osmo-netif: abstraction of physical layer passing FDs to an external process? mgcp? zecke: mgcp can route audio, has no idea of timeslots (corresponding to ports) laf: can we put that info in MGCP packets? zecke: there are vendor extension mechanisms in MGCP specs we could use ... laf: one way would be to configure TS<->MGCP-port statically zecke: we currently use E1 timeslots SDP description must be available necessary to support multiple different codecs at the same time, so we need a side channel laf: can we not tell the mgcp which codec to use? zecke: no, mgcp offers alternatives (^FIXME^) zecke: it could make sense to let osmo-nitb use mgcp laf: a legacy A interface between BSC and MSC is unlikely to be implemented we use a one to one mapping between MGCP ports and timeslots? DB async access laf: has been discussed in emails and congress peter: want to rewrite db.c to use prepared statements then it should become clearer how to do async one idea is one thread per subscriber while they need DB access laf: would like to see an external HLR first looking at the way a normal VLR and HLR interact, you can have simultaneous transactions how the external HLR is independant the key change in osmo-nitb is that a subscriber resolve is not instantaneous the rest is smaller shows code of mm_rx_id_resp where subscr access is synchronous must be made async, the gsm_subscriber_connection would need a new state peter: looked at how many call paths into the db, they are not that many he fears that it will have large ripple effects tnt: all the code has been written for single thread laf: it's not reasonable to make it multithreaded the loc_update procedure is already async on the mobile side we need a more formal state machine with some more states for waiting on the HLR tnt: need to handle the case when the channel is gone during HLR request laf: we are talking about VLR functionality as a cache for the HLR the API should be the interface to the (internal) VLR, which might in turn need to talk to the HLR much of the subscriber accesses can stay the same one ugly case is SMS handling, we don't store extensions but subscribers in the SMS code peter: inspiration came from SMSC laf: sms should not know about subscriber ids burg: openbts has an SMS based on SIP page mode messaging (not SMQ), IMS uses it too openbts desperately need a replacement for smsqueue because the latter is a ugly hack. The interface currently used is SIP page mode (IMS) which is a version of SIMPLE (Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions, http://en.wikipedia.org/wiki/SIMPLE ), with SMS RPDU payload. laf: the idea for openbsc would be to use the ASN1 encoding for SMS without all the state machines peter->burg: what performance requirements? burg: not a focus? (FIXME) burg: openbts smsc uses and encoded RPDU an SMSC is just and DB of RPDU waiting to be delivered, routing and header rearangement, submit format -> delivery laf: will look at making subscriber query async standalone osmo-msc zecke: we had a need for a standalone msc, extracted code from osmo-nitb we have an internal BSC api now could do the same thing for the MSC api in one version they could call each other directly, but could A link in between for fuzzing it would be good to restart parts individually laf: (draws image of current openbsc structure) .-----------. | osmo-nitb | '-----------'----------. | libmsc | osmo-bsc | .----------------------. | libbsc | '----------------------' laf: can combine libbsc->libmsc->osmo-nitb or libbsc->osmo-bsc proper stacking would be good for test coverage, as more code would be shared between uses cases peter: will meet in berlin with harald for some further discussion zecke: we're still missing exception clause for AGPLv3 (user notification) laf: has a proposal from lawyer original intention is for web services, there it easy to do logical conclusion would be a SMS for each user dieter: use cell broadcast ;) burg: eben moglen considers core network use also as network facing (and openbts has a permissive clause for that) laf: we as authors can make our position clear on the interpretation intrest is not to spam the users, but that the source code is published we can a permissive clause: you can use openbsc without sending sms, by publishing the code (and notifiying) chem: distinguish between availability and user notification user notification has different problems: - sending an SMS to the user would be spam - printing in the manual will not work - roaming subscribers will not be alerted (visiting operator is not allowed to send SMS) - having the operator displaying on its website will not work (or remove in the next web site update) instead of having the operator notifying the users, they would send the code to osmocom, which then makes it public for the users (AGPLv3 additionnal permissive clause) End of day two. h2. == Day Three h3. == === 10:00 Running your own 3g network (no video, slides later) === UMTS needs a 5MHz band, they are all already allocated, none is free (no one can have licences to test UMTS) W-CDMA is used. for the CDMA to work, the phone must not transmit with a too strong signal (so to no destroy the signal of the other) the tansmission power is regulated 1500Hz the coverage of an UMTS cell depends on the number or users the scrambling codes set the max data rate (the spreading, in tree form) channels using scramble codes with high data rate are more error prone no freq hopping in UMTS channel and scrambling code are allocated by the NodeB 3 channel levels: logical, transport, physical laf: UMTS is the ASN.1 for telephony. you can defined how you will phone. but in the end, only one codec is used :p NBAP protocol used to control [[NodeBs]] NodeBs ATM over E1/T1 (IMA) used as Iub interface transceivers are seperate (not inside the nodeB), connected using an 4GBit optical link the protocol to control the remote transceivers is publicly available You need licences (XML file with signature) for every configuration aspect of [[NodeBs]] NodeBs (each channel, CE, transciever, ...). Even for transmit power (pay per Watt! > 20W) and for processing power (pay per MIPS? pay perCE customer element). h3. === 12:00 Smalltalk (slides, no video) === you can (and do) writte code while you run it (and the whole program) (the pad was unavailable during the afternoon, but most talks have been recorded) End of day three. h2. == Day Four h3. == === 10:20 zecke: osmo cellmgr-ng (no video/slides) === The code was started with a commercial interest to connect a circuit based BSC to a IP-based core network. The customer owns a good MTP2 commercial stack, so the software starts from there. Has Wireshark dissector for debuging. Works quite reliable now Can only bridge from MTP3/{SCCP,ISUP} to IP/SCTP (no proper routing). Probably not that useful for the community, because requires a special hardware to run. by decoupling it from the BSC code the BSC api is in a header in openbsc, simply function calls and callbacks, based on gsm 08.08 todo: create an analog interface for MSC first stage directly couple BSC api and MSC api see branch zecke/osmo-msc some parts of our MSC still calls BSC-layer functions, this must be moved to the BSC layer is rather easy, but work on this is stalled for some time this split would also help with dieter UMTS work, as he wouldn't need to implement MM functionality himself but can use the osmo-msc instead (wouldn't be spec compiant RNC/MSC connection) laf: there will be some conflict in moving out the DB and the bsc/msc split zecke: no conflicts, we would remove BSC api useage and replace it with MSC, it could be done in parallel 11:05 pablo: libosmo-netif/abis (slides and video) laf: the osmo-bsc code should not care if the BTS is connected via Abis or IPA same applies to A link, A over E1 or A over IP h3. === 11:40 laf: mo-bis (no video) === http://openbsc.osmocom.org/trac/wiki/Motorola_Horizon_macro h3. === 12:00 regression testing === zecke showed our testing scripts and jenkins h3. === 12:30 kevin: simtrace === http://bb.osmocom.org/trac/wiki/SIMtrace http://bb.osmocom.org/trac/wiki/SIMtrace/Hardware Plans for v2.0 * Fullsize smart card support * Voltages support, 1.8V, 3V, 5V (tried after another, 5V needs to be supported by everyone) * Add 0hm/small resistor to measure current (ufl connection) * [[MicroSD]] MicroSD instead of flash for more flexibility * Connect clock to a timer counter to determine clock of the SIM (TLCK0) * Fix broken power forwarding in v1.0/v1.1 Issues: * NFC and SIMtrace FPC... interference... 13.56 Mhz NFC magnetic coupling -> use copper tape as shielding * Clock forwarding needs to be connected to different GPIO (TI??), highest clock frequency * Switched from kicad to geda for the Schematics/Layout h3. === 13:00 lunch break h3. === === 15:15 Erlang === laforge gives introduction into how you write code in Erlang.
