Project

General

Profile

OsmoDevCon2012 Minutes » History » Version 1

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

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