Project

General

Profile

OsmoDevCon2012 Minutes » History » Version 2

laforge, 02/19/2016 10:48 PM
initial import from etherpad

1 2 laforge
{{>toc}}
2
= Meeting minutes of [[OsmoDevCon2012]]
3 1 laforge
4
5 2 laforge
h2. Day one
6
7
8 1 laforge
Start of day one.
9
10 2 laforge
h3. Introduction round
11
12
13
14
h3. 11:30 UMTS Phone hacking
15
16 1 laforge
laf: complexity is higher than gsm -> therfore no complete implementation of lowerlevel parts
17
  use existing low-layer implementation (through reverse engineering)
18
qualcom rev project implemented a software debugger
19
dsp: using jtag could introduce timing problems, software solution make sense
20
laf: QC modem does not use crypto/signing, has multiple firmware images, uses rex (micro?)kernel. Newer ones use L4 as micro-kernel
21
  have build adapter board for accessing JTAG
22
dsp: there is an interface for debugging/tracing available
23
laf: attaching to the L2/L3 interface and exporting that via USB would be a likely next step
24
chem: QC works together with sec. researchers / responsible disclosure
25
laf: right now this HW is still easily available, similar conditions to start of osmocom project
26
  expects that newer HW will be locked down, so now would be a good time to start working
27
dsc: is also a good investment into the future, some LTE sticks are also QC base and not locked down
28
  (they also support UMTS, internal architecture is similar) (50-100€ LTE stick)
29
  tracing protocols are similar, too
30
  firmware update contains an ELF binary (with debug info)
31
laf: has started to look at MTK 3g/3.5g smartphones, also sold outside china, too
32
  use an integrated design (AP/BP in one chip, like QC)
33
  the GSM part is similar to the older MTK chipsets we know
34
  second sim slot is on the AP side (dual sim standby) maybe possible to access the BP side from AP
35
  good CPU performance, 100€
36
  still looking for UART/JTAG, pinout is known
37
  work going on to get them to publish linux kernel code
38
  the protocol between AP/BP seems to be not a binary one
39
  some devkit seems to be coming -> documentation
40
chem: there is work going on to get an LTE/LTEadvanced PHY level stack?
41
burg: the complexity of LTE phys layer is much less than for UMTS (LTE is more similar to wimax)
42
chem: LTE market is much more open than traditional (UMTS) telecom
43
  china+india will use LTE-TDD much more popular than (UMTS-TDD)
44
  SDR is current very popular in china for custom and niche designs/protocols/crypto (instead of ASICs)
45
burg: is RR mgmt available on the interface/message queues (in QC UMTS modem)?
46
laf: all parts of the stack use the same MQ system
47
28C3 talk: http://events.ccc.de/congress/2011/4019976347022Fahrplan/events/4735.en.html
48
HW is still easily available, similar conditions to start of osmocom project
49
  expects that newer HW will be locked down, so now would be a good time to start working
50
dsc: is also a go
51
burg: RR control in UMTS is the primary difference to 2.5G, the rest is similar, spec alone is hard to use
52 2 laforge
dsp: [[UbiNetics]] TM100 is a UMTS layer 1 "phone", large, dsp-based, gives you acces to L1 data over TCP
53 1 laforge
  are very hard to get&expensive, is LTE capable, designed for equipment designer, not enough documentation
54
  useful for UMTS L1 debugging, there is nothing comparable available, the QC modem is no replacement
55
    (they use HW for some L1 stuff)
56
burg: for UMTS development a good diagnostic tool is a requirement
57
chem: LTE reuses a lot of IETF protocols, looks like UMTS for data
58
  for voice calls there are several options:
59
    initial LTE was IP data only (like wimax), no notion of voice calls
60
    switch back to CS network GSM/UMTS
61 2 laforge
    [[VoLGA]]: Voice over LTE Generic Access (unlikely to be widely deployed?)
62
    [[VoLTE]]: it is an IMS connection (internet multimedia subsystem, basically SIP with diameter, ...)
63 1 laforge
      internet protocols "adapted" by telecom companies -> complex
64 2 laforge
    IMS would not be ready for LTE, [[VoLTE]] is a subset for voice+sms
65 1 laforge
    -> voice signaling is completely outside of the radio stack
66 2 laforge
    Initial [[VoLTE]] proposal is available, real standard is very similar (real only available to GSMA members)
67 1 laforge
chris: LTE phone have short standby because the need CS net + LTE at the same time
68
laf: contact me icon for jtag debug adapters (new jtag board as a replacement for simcard holder, difficult soldering)
69
vogelchr: can UMTS modulation be done on a PC?
70
burg: yes, on 2.5GHz multicore
71
dsp: also exists for LTE
72
burg/dsp: drawbacks of CDMA (UMTS), bad technology
73
laf: general predictions? UMTS will be switched of before GSM
74
burg: the problem going to LTE is completely changing the core network to IMS (to replace ss7/ (ss7 on ethernet))
75
chem: we will see many LTE networks, running LTE on 700MHz
76
dsp: 800MHz in germany, he has LTE signal but no GSM/UMTS coverage at home, is intended as a DSL replacement
77
burg: some teco eng. would not trust IMS core network for 1-1.5 years for paying customers
78
laf: theory: GSM for voice (because of large cells)
79
burg: nice for openBTS, plug it into IMS :)
80
laf: Time-Gap filler: have received donation of sagem GSM (MyX6 HW) trace phones (5 support GPRS)
81
  comes with windows program and protocol documentation, can do protocol traces
82
steve-m: JTAG pinouts are documented
83
  see http://senkron24.se.funpic.de/Test%20points%20/sagem/j-tag/tst%20point/MyX6_X7_V65_V75_TP.jpg
84
  phone contains Calypso + TWL3014
85
laf: we'd need a wireshark decoder
86
dsp: some lectures and code is available for this phone linked from our wiki
87
88 2 laforge
89
h3. 13:xx-14:30 Lunch + Hallway Track
90
91 1 laforge
laf: The schedule has changed
92
  let's talk about sim cards...
93
  we have sysmoSIM cards where we can create arbitrary files, ki, iccid, …
94
  for iccid you have to apply at the ITU, complex&expensive process
95
  problematic to find this for uSIM, none where we can place arbitrary files, only very expensive
96
  we found fully programmable cards instead, without OS, though
97
  datasheets are available, but samples not yet
98
  it is a CC32RS512, 16kB ram 512kB flash no mask ROM
99
    see: http://www.alibaba.com/product-gs/526964999/CC32RS512_Smart_card_with_32_bit.html
100
  ARM7TDMI 
101
  laf wrote a set qemu peripherals -> git.osmocom.org (http://cgit.osmocom.org/cgit/osmo-cos/)
102
  no incremental/byte program, page only -> makes FS development harder, laf has some plans here
103
  would be good to have another source
104
  this die has an additional ISO 7816-3 slave & master
105
chem: difference between SIM and uSIM?
106
laf: uSIM has a completely different protocol (beginning with the class id?), filenames and so on
107
  both based on ISO 7816
108
  uSIM has a backwards compatibility mode (so there are two ways to access each information)
109
  many different modes for authentication
110
  uSIM cards: 2G/3G uses milenage for both 2G and 3G
111
  3G phone, 3G network, 2G sIm => depends on network operator configuration...
112
  Today: most likely 3G sim for 3G network, milenage -> this allows authentication even on 2G roaming networks and 2G phones
113
  uSIMs also have files for recently used ARFCNs (to speed up startup)
114
discussion: how does mutual auth work in UMTS networks when using a GSM SIM? (unclear) standard is: 33.102
115
laf: we have an implementation of milenage in libosmocore, a util to generate the data and a
116
python utility to connect to a card reader and run UMTS Auth (osmo-sim-auth)
117
laf: the cards have no ROM bootloader, so for lowlevel bringup the qemu emulator is a good option
118
119 2 laforge
120
h3. 15:00 OSMO GMR
121
122 1 laforge
Voice: See slides
123
TDMA Framework Thoughts:No Slides, GNUradio hard to compile, channelization can not be
124
handed to the GPU, demodulation tough (e.g. burst, no constant phase), muller/muller problematic,
125
e.g. not locked at the end of a burst.
126
chem: Upstream works on features for packet radio
127
Framework like the calypso phone works. Define how channels are timed on TDMA, calls for
128
demodulate this frame...., calypso very constraint hardware, we can allocate memory.
129 2 laforge
david: repurpose l1 of [[OpenBTS]]. E.g. add something to sync, keep virtual frame number, record
130 1 laforge
offset between virtual and decoded frame number...
131
chem: Talk to Thomas, GSM decoding for TI Cx64(??), TDMA code for DSP
132
tnt: Still too tight to GSM, good as example for finding a good architecture. Want to understand how
133
it works, not just taking code from Airprobe|OpenBTS
134 2 laforge
[[MultiRX]]-Tool: See slides
135
 abstraction layer for FCD, UHD, [[OsmoSDR]], RTL-SDR, … hardware, generic interface
136 1 laforge
 channel config: CXX class, one file containing channel definitions (output sample rate, channel bandwidth, overloaded freq calculation function from ARFCN value)
137
 more devices (and cheaper): calculates number of hardware devices required and distributes user requested channels over a bunch of devices,
138
 e.g no wideband receiver needed to capture UL & DL simultaneously.
139
Outlook:
140
  Discovery mode for automated scanning (think of Wardriving)
141
  Integration of available demodulators
142
  Demodulator frequency error information used in multirx to allow better signal acquisition.
143
laf: is tool available?
144
?: work in progress (FIXME)
145
5 minutes break
146
147 2 laforge
148
h3. laf: Osmo-SDR (no slides, video)
149
 
150 1 laforge
  project has been running under the osmocom umbrella
151
  the HW ppl wanted to do that anyway for ham radio
152
  that's why its a bit diffreent than other project
153
  PCB assembly should happen in next weeks
154
  have enough components for 100 units
155
  samplerate 1M samples, possibly higher in another revision
156
  rate limited by serial interface between fpga and sam3u
157
  software is usb audio device with 1Ms at 14bit ADC
158
  usb audio at this sample rate does not work on OSX/Win32, custom driver needed
159
  spectrum looks clean
160
  sam3u has many usb endpoints, could be used to have a serial port in addition to usb-audio
161
  control could also use usb control messages, is exported via libusb
162
  timestamping is not possible in usb-audio, would need a different mode (to detect lost samples on the host)
163
    sam3u can do scatter gather dma, so not problem
164
  Price EUR 150.00 + vat, clock generator not cheap (USD 20-30), SAM3U, E4000..., WEEE registration
165
  is of course open hardware, more expansive than RTL-SDR
166
  will be in sysmocom's webshop in 2 weeks
167
  both FPGA and SAM3 gpio's are on headers
168
  TX board will be designed/created in the common weeks.
169
  the E4000 has many software configurable filters, and you can connect external baseband filters
170
  could do oversampling in the FPGA
171
  VHDL code is available via email from laforge
172
  firmware is in git repo, uses cortex m3 toolchain
173
  arecord has limit on sample rate… needs oneline patch
174
  with the powerful MCU we could frequency hopping onboard
175
  PWM for gain control are available, we could add a lot of intelligence
176
  can tune in 1MHz steps? SI570
177
  1pps input for GPS sync
178
  SWD debug board, Versaloon the only one available, STM develboard quite cheap as well
179
  
180 2 laforge
181
h3. 16:45 GSMTAPv3 (slides+video)
182
183 1 laforge
variable header:
184
Q/statements
185
 length in multiple of 32 bits... where to define padding? content might not be multiple of 32 bit
186
len..could be shorter
187
access to payload is not aligned
188
A: variable header mostly for information, len in bytes reduced max size...
189
Q/statments
190
fixed header len? End-Of-Options?
191
8bit tag/8bit len breaks alignment... but small types fit in 32bit
192
tag: MSB indicates...(like Q931.. ISDN)
193
tag: extension bit... long length field
194
Statement:
195
Tag address space split... change... if we need longer length field we can use some
196
extension for the length field (then we can not skip unknown tags anymore).
197
Manual padding (padding field)
198
Length field: represents real length, but next one will be 32bit aligned
199
Netlink... defines infrastructure for it
200
Q: How is a block defined? Hierachical?
201
A: Flat, A block is what you define for the protocol, e.g. logical channel with channel number, TS
202
Q: Physical block representation?
203
A: Block == Value of TLV
204
Two Datalink types assigned to us... by tcpdump
205
Variable headers...
206
Datatype in the header? changes the meaning of the payload completly.
207
Too much freedom will be hard to specify... 
208
laf: Just allow one type, otherwise everyone needs to implement everything.
209
laf: App dev PoV.. easiest to export in the native way, but GSMTAP should
210
    specify the format as it allows interop, only one input format needed.
211
chem: 1.) sending APP might be resource constrained 2.) only receiving app is wireshark
212
tnt: Want to change 2nd
213
chris: multi-rx
214
laf: virtual layer1 osmocomBB <-> osmoBTS.. use GSMtap for exchange? multicast UDP
215
chem: care more about sending application, more restricted in resources
216
...
217
laf: native types, new subtypes
218
chem: openbts on embedded board, wireshark can do any conversion
219
david: raw sample case is corner cases, wireshak does not have software radio support. No
220
raw sample format.
221
laf: Demodulated soft bits?
222
david: questionable, no fec in wireshark
223
tnt: other receivers might be interested
224
API
225
laf: msgb + len? where to start from?
226
tnt: Functions call msgb_put
227
Rename msgb to osmo_msgb? (clash with ortp/str_util.h), possibly there's a workaround, msgb deeply integrated in all osmoX-projects.
228
Q: What about adding n times the same atribute to one frame?
229
laf0rge(?): possibly one TLV with 4xV.. normal code will read the normal value, others the next three as well
230
Migration:
231
tnt will take the notes and come up with a proposal
232
Get things into wireshark, so they sink into distributions...
233
coffee break 17:45-18:00
234
18:15 dimitry is presenting his hardware
235
old (15 years) ISA board with SS7 implementation. DSP are used (single thread)
236
he added an FPGA to run the netlist
237
E1 output normally
238
second board (6 years old) out of production (ISA also)
239
wants to do a board with 2xE1 outputs (open source software, probably not HW), ~80% done
240
SS7 implementation not readable yet (needs month), but could then be published
241
242 2 laforge
243
h3. 18:30 round table / rectangular table on [[OsmocomBB]]
244
245 1 laforge
TOPICS:
246
247
    "De-Branching" (BTSAP, …)
248
249
    sr-labs, external patches
250
251
    User Interface
252
253
    Statetransitioning in L1
254
255
    NuttX
256
257
    GPRS Roadmap?
258
259
    mtk port?
260
261
    porting of l2/l3 into the phone..
262
263
    misc...
264
265
1. Branches (SAP)
266
267
    dexter sim so we should remove the branch...
268
269
    jolly-bts is not meant to be merged
270
271
    jolly: jolly-measurement is obsoleted (may still contain some handover parts)
272
273
    jolly-ui? is a hacked ui, will talk about that later
274
275
    laforge/mobile_event? will check.......
276
277
    laforge/neigh_sb? 
278
279
    nion/sap: needs to be tested by someone else
280
281
    prom/dietlibc: is a port to dietlibc, we keep it until we need it
282
283
    prom/loader-crc: can be removed
284
285
    prom/simaccess: ???
286
287
    steve-m/burst_mcsi: merge it into sylvain's branch
288
289
    steve-m/loader_sciphone: has been merged
290
291
    steve-m/mtk_hack: initial effort to support the MTK 223 6227 BBs (contains register offsets)
292
293
    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)
294
295
    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
296
297
    vogelchr/battery: is a dead end, will be replaced with the current version (force push current)
298
299
    vogelchr/framebuffer: is merged, has been removed
300
301
2. sr-labs, external patches
302
303
    luca/catcher
304
305
    luca/gsmmap
306
307
    ask to rebase/clean on top of master, after sylvain merged it -> laf
308
309
3. Statetransitioning in L1
310
tnt: resynch 
311
  parameters for the sync part should be changed/read atomically -> state_changed task
312
  task concept must be extended (undefined)
313
  can we afford to skip one frame in certain cases?
314
  using only alignment TS 0/4 should be simpler, but doesn't work so far
315
  tnt&laf need to think about this some more
316
3 1/2. Powersave
317
laf: shouln't be that much work
318
319
    we know the wakeup point from TDMA schedule
320
321
tnt: implement discont RX first?
322
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)
323
4. User Interface
324
jolly: i've got a branch, still working
325
326
    is a rather hackish framebuffer approach (which is now merged)
327
328
    the UI is in the stack, jolly wants a split between the application and UI, maybe the same with VTY
329
330
    new DLCI for the UI?
331
332
laf: we've been thinking about apps on the phone some times already
333
334
    message queues between those parts make sense
335
336
    maybe even queue between different parts of the stack, threads? -> requirements on OS?
337
338
    stack <-> ui <-> screen/kb
339
340
tnt: different ui parts (battery+clock) & primary app
341
laf: semantics: blocking or message queues (with threads)?
342
tnt: tasks: main loop which polls different components?
343
 basically a list of tasks to be polled, each one checking its queues and does processing without blocking. Dynamic list rather than hardcoded.
344
 not a preemptive multitask (with timer interrupts and such)
345
???
346
laf: we should try to come up with a plan to run everything in the phone
347
348
    what should be the primitives? direct framebuffer access? messages to ui component?
349
350
    could handle diffrent screen layouts
351
352
dieter: this widget stuff should be available somewhere as open source
353
look at rockbox, where an light UI has already been implemented (for simple devices)
354
in the beginning there was the idea of using LUA. how about that? (http://www.eluaproject.net/)
355
?: access to the GSM stack from a host cpu process instead of telnet?
356
laf: message queues should be a approach for this?
357
devel the UI on the PC (so to debug), then port it to the phone -> serial used
358
laf: summarizing, limited requirements for OS, no fullblown kernel (scheduler preemption)
359
360
    we only need message queues and a way to allocate messages
361
362
discussion about memory allocators: Deal with != memory types (isram/esram)
363
laf: maybe use gsm stack on internal ram and ui external ram? see how that goes
364
365
    tasks:
366
367
    define abstraction primitives beween app <-> ui ? rockbox investigation
368
369
    define primitives gsm stack <-> app
370
371
    move layer 2 and 3 to phone (is independant of tasks above)
372
373
    primitives can also be developed on the PC before moving them to phone
374
375
    l1ctl is ugly, needs structure, now we know better
376
377
    memory alloc: we don't need arbitrary sizes, something like slab would make sense
378
379
5. NuttX
380
laf: it seems we don't need it (yet) according to UI discussion
381
tnt: has not looked at in detail, would be nice to have some of the work done for us
382
383
    but it doesn't seem to do that much?
384
385
    hardware abstraction?
386
387
    has a filesystem
388
389
    l1 is already very self-contained
390
391
laf: it is posix-like, should make it easier for developers
392
steve: rockbox is also a small OS, could be a better choice? (or source of inspiration)
393
tnt: OS mainly useful for l2/l3
394
laf: posix semantics would mean copying of messages, would be nice to do without
395
396
    copying could become a problem
397
398
tnt: we don't see much of the (voice) data at all
399
laf: assuming we could leave the l1 unmodified the burst handling could be done in FIQ?
400
tsaitgaist: could 3G L1 be also as selfcontained as for GSM?
401
laf: application messages would be like:
402
403
    scan for networks
404
405
    place a call
406
407
    ...
408
409
    this would not be much different for 3G
410
411
laf: summary we could not gain much from nuttx, rockbox could provide use with UI (inspiration)?
412
steve: framebuffer is mosly compatible
413
laf: look at rockbox tonight, discuss tomorrow
414
(general agreement)
415
6. GPRS Roadmap?
416
tnt: not going to happen
417
dieter: testing could be done on nanobts
418
laf: l1 for gprs too complex, for networkside gprs debugging we don't need osmocombb gprs
419
420
    just send bursts to wireshark
421
422
7. mtk port?
423
laf: seems stalled
424
steve: TX works (Marcin's uboot repo)
425
laf: doesn't seem to be that much of a problem, just needs time and an interrested person
426
427
    they don't have a TPU, TDMA timers instead, needs reverse eng.
428
429
    higher level: what do we gain, no shortage of C123, otoh more CPU/better display
430
431
    usb for charging, no special cable needed
432
433
steve: even cheap ones have USB highspeed
434
laf: has edge, but we don't have gprs, only for sniffing
435
(low interest in this round)
436
laf: better to get current stuff working autonomously
437
438
    marcin would need to push this forward
439
440
8. porting of l2/l3 into the phone..
441
laf: see above...
442
9. misc...
443
laf: kevin wants to build a bord for connecting and charging the c123
444
(peter shows his c123 board holder)
445
charging:
446
447
    trickle chare requires calibration, missing documentation for selfcalibration
448
449
laf: do no trickle charge, simply constant current, then discarge
450 2 laforge
steve: be careful with the [[LiPoly]] battery on the FIXME, needs different code
451 1 laforge
vogelchr: do we need something like debugfs?
452
453
    something to get/set debug variables (in l1?)
454
455
laf: generalize code from osmo-sdr
456
peter: FW sends a list of variables/types
457
458
    then a generic ui is easy
459
460
laf: osmo-get-setter
461
registering dynamic unix socket channels, like old inetd protocol?
462
laf: steve did multiple channels in osmocon?
463
steve: no, that was prom
464
peter: usb=packets<-/->serial=stream :/
465
laf: we just need some transport
466
COMMIT
467
EOF
468
End of day one.
469
Start of day two.
470
471
472 2 laforge
h2. Day two
473 1 laforge
474 2 laforge
475
476
h3. 10:20 GSM core network (video and slides)
477
478
479
480
h3. 15:00 osmo-BTS/sysmoBTS (video, no slides) ===
481
 16:00 femtocells (video and slides) ===
482
483
h3. 17:30 VTY
484
485 1 laforge
zecke: problems with VTY
486
487
    hard to teach to users (flat/nodes)
488
489
    wiki page is outdated/wrong
490
491
    he started to look at generating content from the running code (for documentation) based on XML/XSLT
492
493
    some working code exists, but not finished, are there better ways?
494
495
...: we should extend VTY a bit to allow more flexibility
496
- 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
497
- Add a default vty command that allows to print the xml doc. (easiest way and can be used as vty 'introspect')
498
499
500 2 laforge
h3. 18:20: [[OpenBSC]] todo
501
 
502
503 1 laforge
    better VTY configurability
504
505
laf: some configurarion options can be run at any time, other only become effective much later
506
507
    -> much confusion
508
509
    on cisco, config changes become active when you leave the node
510
511
    similar approach would make sense, but is very different than how it works now
512
513
tnt: add VTY hooks to "commit" changes on leaving node?
514
laf: maybe a signal instead? the signal would transport a pointer to the struct corresponding to the node
515
516
    moving media proc out of the main process
517
518
laf: useful for straceing openbsc when traffic is going through
519
520
    osmo-netif: abstraction of physical layer
521
522
    passing FDs to an external process?
523
524
    mgcp?
525
526
zecke: mgcp can route audio, has no idea of timeslots (corresponding to ports)
527
laf: can we put that info in MGCP packets?
528
zecke: there are vendor extension mechanisms in MGCP specs we could use
529
530
    ...
531
532
laf: one way would be to configure TS<->MGCP-port statically
533
zecke: we currently use E1 timeslots
534
535
    SDP description must be available
536
537
    necessary to support multiple different codecs at the same time, so we need a side channel
538
539
laf: can we not tell the mgcp which codec to use?
540
zecke: no, mgcp offers alternatives
541
542
    (^FIXME^)
543
544
zecke: it could make sense to let osmo-nitb use mgcp
545
laf: a legacy A interface between BSC and MSC is unlikely to be implemented
546
547
    we use a one to one mapping between MGCP ports and timeslots?
548
549
    DB async access
550
551
laf: has been discussed in emails and congress
552
peter: want to rewrite db.c to use prepared statements
553
554
    then it should become clearer how to do async
555
556
    one idea is one thread per subscriber while they need DB access
557
558
laf: would like to see an external HLR first
559
560
    looking at the way a normal VLR and HLR interact, you can have simultaneous transactions
561
562
    how the external HLR is independant
563
564
    the key change in osmo-nitb is that a subscriber resolve is not instantaneous
565
566
    the rest is smaller
567
568
    shows code of mm_rx_id_resp where subscr access is synchronous
569
570
    must be made async, the gsm_subscriber_connection would need a new state
571
572
peter: looked at how many call paths into the db, they are not that many
573
574
    he fears that it will have large ripple effects
575
576
tnt: all the code has been written for single thread
577
laf: it's not reasonable to make it multithreaded
578
579
    the loc_update procedure is already async on the mobile side
580
581
    we need a more formal state machine with some more states for waiting on the HLR
582
583
tnt: need to handle the case when the channel is gone during HLR request
584
laf: we are talking about VLR functionality as a cache for the HLR
585
586
    the API should be the interface to the (internal) VLR, which might in turn need to talk to the HLR
587
588
    much of the subscriber accesses can stay the same
589
590
    one ugly case is SMS handling, we don't store extensions but subscribers in the SMS code
591
592
peter: inspiration came from SMSC
593
laf: sms should not know about subscriber ids
594
burg: openbts has an SMS based on SIP page mode messaging (not SMQ), IMS uses it too
595
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.
596
laf: the idea for openbsc would be to use the ASN1 encoding for SMS without all the state machines
597
peter->burg: what performance requirements?
598
burg: not a focus? (FIXME)
599
burg: openbts smsc uses and encoded RPDU
600
601
    an SMSC is just and DB of RPDU waiting to be delivered, routing
602
603
    and header rearangement, submit format -> delivery
604
605
laf: will look at making subscriber query async
606
607
    standalone osmo-msc
608
609
zecke: we had a need for a standalone msc, extracted code from osmo-nitb
610
611
    we have an internal BSC api now
612
613
    could do the same thing for the MSC api
614
615
    in one version they could call each other directly, but could A link in between
616
617
    for fuzzing it would be good to restart parts individually
618
619
laf: (draws image of current openbsc structure)
620
621
  .-----------.
622
  | osmo-nitb |
623
  '-----------'----------.
624
  | libmsc    | osmo-bsc |
625
  .----------------------.
626
  | libbsc               |
627
  '----------------------'
628
laf: can combine libbsc->libmsc->osmo-nitb or libbsc->osmo-bsc
629
630
    proper stacking would be good for test coverage, as more code would be shared between uses cases
631
632
peter: will meet in berlin with harald for some further discussion
633
zecke: we're still missing exception clause for AGPLv3 (user notification)
634
laf: has a proposal from lawyer
635
636
    original intention is for web services, there it easy to do
637
638
    logical conclusion would be a SMS for each user
639
640
dieter: use cell broadcast ;)
641
burg: eben moglen considers core network use also as network facing (and openbts has a permissive clause for that)
642
laf: we as authors can make our position clear on the interpretation
643
644
    intrest is not to spam the users, but that the source code is published
645
646
    we can a permissive clause: you can use openbsc without sending sms, by publishing the code (and notifiying)
647
648
chem: distinguish between availability and user notification
649
user notification has different problems:
650
- sending an SMS to the user would be spam
651
- printing in the manual will not work
652
- roaming subscribers will not be alerted (visiting operator is not allowed to send SMS)
653
- having the operator displaying on its website will not work (or remove in the next web site update)
654
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)
655
End of day two.
656
657
658 2 laforge
h2. Day Three
659 1 laforge
660 2 laforge
661
662
h3. 10:00 Running your own 3g network (no video, slides later)
663
664
665 1 laforge
UMTS needs a 5MHz band, they are all already allocated, none is free (no one can have licences to test UMTS)
666
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)
667
the tansmission power is regulated 1500Hz
668
the coverage of an UMTS cell depends on the number or users
669
the scrambling codes set the max data rate (the spreading, in tree form)
670
channels using scramble codes with high data rate are more error prone
671
no freq hopping in UMTS
672
channel and scrambling code are allocated by the NodeB
673
3 channel levels: logical, transport, physical
674
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
675 2 laforge
NBAP protocol used to control [[NodeBs]]
676 1 laforge
ATM over E1/T1 (IMA) used as Iub interface
677
transceivers are seperate (not inside the nodeB), connected using an 4GBit optical link
678
679
    the protocol to control the remote transceivers is publicly available
680
681 2 laforge
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).
682 1 laforge
683 2 laforge
684
h3. 12:00 Smalltalk (slides, no video)
685
686 1 laforge
you can (and do) writte code while you run it (and the whole program)
687
(the pad was unavailable during the afternoon, but most talks have been recorded)
688
End of day three.
689
690
691 2 laforge
h2. Day Four
692
693
694
695
h3. 10:20 zecke: osmo cellmgr-ng (no video/slides)
696
697 1 laforge
  The code was started with a commercial interest to connect a circuit based BSC to a IP-based core network.
698
  The customer owns a good MTP2 commercial stack, so the software starts from there.
699
  Has Wireshark dissector for debuging.
700
  Works quite reliable now
701
  Can only bridge from MTP3/{SCCP,ISUP} to IP/SCTP (no proper routing).
702
  Probably not that useful for the community, because requires a special hardware to run.
703
704
    by decoupling it from the BSC code
705
706
the BSC api is in a header in openbsc, simply function calls and callbacks, based on gsm 08.08
707
todo: create an analog interface for MSC
708
709
    first stage directly couple BSC api and MSC api
710
711
see branch zecke/osmo-msc
712
some parts of our MSC still calls BSC-layer functions, this must be moved to the BSC layer
713
714
    is rather easy, but work on this is stalled for some time
715
716
this split would also help with dieter UMTS work, as he wouldn't need to implement MM functionality himself
717
718
    but can use the osmo-msc instead (wouldn't be spec compiant RNC/MSC connection)
719
720
laf: there will be some conflict in moving out the DB and the bsc/msc split
721
zecke: no conflicts, we would remove BSC api useage and replace it with MSC, it could be done in parallel
722
11:05 pablo: libosmo-netif/abis (slides and video)
723
laf: the osmo-bsc code should not care if the BTS is connected via Abis or IPA
724
725
    same applies to A link, A over E1 or A over IP
726
727 2 laforge
728
h3. 11:40 laf: mo-bis (no video)
729
730 1 laforge
http://openbsc.osmocom.org/trac/wiki/Motorola_Horizon_macro
731
732 2 laforge
733
h3. 12:00 regression testing
734
735 1 laforge
zecke showed our testing scripts and jenkins
736
737 2 laforge
738
h3. 12:30 kevin: simtrace
739
740 1 laforge
http://bb.osmocom.org/trac/wiki/SIMtrace
741
http://bb.osmocom.org/trac/wiki/SIMtrace/Hardware
742
Plans for v2.0
743 2 laforge
* Fullsize smart card support
744
* Voltages support, 1.8V, 3V, 5V (tried after another, 5V needs to be supported by everyone)
745
* Add 0hm/small resistor to measure current (ufl connection)
746
* [[MicroSD]] instead of flash for more flexibility
747
* Connect clock to a timer counter to determine clock of the SIM (TLCK0)
748
* Fix broken power forwarding in v1.0/v1.1
749 1 laforge
750
Issues:
751 2 laforge
* NFC and SIMtrace FPC... interference... 13.56 Mhz NFC magnetic coupling -> use copper tape as shielding
752
* Clock forwarding needs to be connected to different GPIO (TI??), highest clock frequency 
753
* Switched from kicad to geda for the Schematics/Layout
754 1 laforge
755
756 2 laforge
h3. 13:00 lunch break
757
758
759
760
h3. 15:15 Erlang
761
762 1 laforge
763
laforge gives introduction into how you write code in Erlang.
Add picture from clipboard (Maximum size: 48.8 MB)