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