Osmocom Conferences (OsmoDevCon, OsmoCon, OsmoDevCall)

{{>toc}}

h1. Meeting minutes of [[OsmoDevCon2012]]

h2. Day one

Start of day one.

h3. Introduction round

h3. 11:30 UMTS Phone hacking

<pre>

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

  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

</pre>

h3. 13:xx-14:30 Lunch + Hallway Track

<pre>

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

</pre>

h3. 15:00 OSMO GMR

<pre>

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.

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

</pre>

h3. laf: Osmo-SDR (no slides, video)

<pre>

  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

</pre>

h3. 16:45 GSMTAPv3 (slides+video)

<pre>

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

</pre>

h3. 18:30 round table / rectangular table on [[OsmocomBB]]

<pre>

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

</pre>

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

<pre>

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

</pre>

h3. 18:20: [[OpenBSC]] todo

<pre>

    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.

</pre>

h2. Day Three

h3. 10:00 Running your own 3g network (no video, slides later)

<pre>

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

</pre>

h3. 12:00 Smalltalk (slides, no video)

<pre>

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.

</pre>

h2. Day Four

h3. 10:20 zecke: osmo cellmgr-ng (no video/slides)

<pre>

  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

</pre>

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