Meeting minutes of OsmoDevCon2012

Day one

Start of day one.

Introduction round

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:
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]] 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]]: Voice over LTE Generic Access (unlikely to be widely deployed?)
    [[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]] is a subset for voice+sms
    -> voice signaling is completely outside of the radio stack
    Initial [[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
  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

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
  laf wrote a set qemu peripherals -> (
  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

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]]. 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: See slides
 abstraction layer for FCD, UHD, [[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.
  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

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

16:45 GSMTAPv3 (slides+video)

variable header:
 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...
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
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
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
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

18:30 round table / rectangular table on OsmocomBB


    "De-Branching" (BTSAP, …)

    sr-labs, external patches

    User Interface

    Statetransitioning in L1


    GPRS Roadmap?

    mtk port?

    porting of l2/l3 into the phone..


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.......


    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



    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? (
?: 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


    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)

    trickle chare requires calibration, missing documentation for selfcalibration

laf: do no trickle charge, simply constant current, then discarge
steve: be careful with the [[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
End of day one.
Start of day two.

Day two

10:20 GSM core network (video and slides)

15:00 osmo-BTS/sysmoBTS (video, no slides)

16:00 femtocells (video and slides

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')

18:20: 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?


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


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, ), 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.

Day Three

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]]
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]] (each channel, CE, transciever, ...). Even for transmit power (pay per Watt! > 20W) and for processing power (pay per MIPS? pay perCE customer element).

12:00 Smalltalk (slides, no video)

you can (and do) write 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.

Day Four

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

11:40 laf: mo-bis (no video)

12:00 regression testing

zecke showed our testing scripts and jenkins

12:30 kevin: simtrace

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 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
  • 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

13:00 lunch break

15:15 Erlang

laforge gives introduction into how you write code in Erlang.