baseband-devel

baseband-devel@lists.osmocom.org

2022 discussions

assignment command / status of RR
by Andreas.Eversberg 02 Sep '10

02 Sep '10

hi, as you can see in the git log, i checked in the "ASSIGNMENT COMMAND" processing. it modifies timeslot, subslot, and hopping sequence. this is required when the network assigns an SDCCH before the actual TCH is allocated: after receiving the "ASSIGNMENT COMMAND", the layer2 is release locally (without sending anything), the dedicated mode is released and established with a new parameters (e.g. TCH/F), and the layer2 is established again, finally the "ASSIGNMENT COMPLETE" is sent to the network. this process is incomplete, but it should work in most cases. (no "starting time" processing). in my local copy of the git, i already completed the assignment process. additionally "FREQUENCY REDEFINITION" is completed, "IMMEDIATE ASSIGNMENT" supports "starting time", MDL-error processing is added, and "HANDOVER COMMAND" parsing is done. the handover process is not completed, because it depends on unimplemented layer1 features, like RX-only channels or "4 successive HANDOVER ACCESS bursts on DCCH". except the handover process, the RR protocol for basic phone calls is complete now. before i can check it in, it depends on two things. first, there are additional messages to be defined in osmocore: "[osmocore] Adding handover and frequency redefiniton message headers" http://home.eversberg.eu/osmocore.patch second, it depends on "starting time" support for layer1: http://home.eversberg.eu/modify.patch it adds a L1CTL message to store modified frequency allocations (ma, ma_len, HSN, MAIO, TSC) for hopping and a "starting time". this starting time is the frame number at which the modified frequencies are used. if the frame number lies in the past, the new modified frequencies are used after the L1CTL message is received. sylvain already noted, that the event of "starting time" should be triggered by the scheduler. since i don't know how the scheduler exactly works, i would ask someone to change my patch. note that the dedicated mode can be released before the "starting time" elapses. as soon as both things above are in the master branch, i will commit my latest work on RR. regards, andreas

2 1

Hi all, why osmocombb need Ti Calypso/Iota/Rita GSM baseband chipset
by John Wu 01 Sep '10

01 Sep '10

Hi all, from what i learned, osmocombb provide gsm protocol stack and dsp signal process code. So why need to use Ti Calypso/Iota/Rita. Is it possible to run on other common arm7+dsp chipset?

3 4

Re: SIM client
by Dieter Spaar 30 Aug '10

30 Aug '10

Hello Sebastien, On Mon, 30 Aug 2010 07:27:19 +0200, "=?UTF-8?Q?S=C3=A9bastien_Lorquet?=" <squalyl(a)gmail.com> wrote: > > For example, i don't remember what does a SIM says when it has to reply > data, but javacards reply 61XX and not something that starts with 9YXX. For GSM its 9Fxx (GSM11.11, 9.4. contains a list of all status codes). Not sure if this trace here is usefull (at the same site there is also one for an USIM): http://www.wrankl.de/UThings/SIM-ME-Communication.pdf Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

Re: SIM client
by Dieter Spaar 30 Aug '10

30 Aug '10

Hello Andreas, On Sun, 29 Aug 2010 13:29:06 +0200, "Andreas.Eversberg" <Andreas.Eversberg(a)versatel.de> wrote: > > - add crpyto-key request to layer 1 and l1-l2 interface (dieter ?) I can take care of Encryption support in Layer-1. However I will probably not find time for it before next weekend. Best regards, Dieter -- Dieter Spaar, Germany spaar(a)mirider.augusta.de

2 1

SIM client
by Andreas.Eversberg 29 Aug '10

29 Aug '10

hi, i committed the SIM client process for layer23. it turns reading and writing jobs (from and to SIM files) into APDUs. because the SIM reader is not yet finished, it cannot be tested yet. after attaching the SIM card, a process in mobile/subscriber.c will request all required files form that card before starting the network selection process. (untested, as noted above) the mobility management is now cleaned up: TODO comments in the source code are replaced by SIM update commands to the SIM client. in order to make mobile application work with public networks, we need to perform the following steps: - finish the SIM reader and interface in layer 1 - add BTSAP interface to layer23 - add measurement reports to both TCH and SDCCH4/8 (*) - send updates for measurement report from layer23 via l23 api of layer 1 - add crpyto-key request to layer 1 and l1-l2 interface (dieter ?) * tests showed that the measurement report on SDCCH4/8 is requred. if not sent, the network releases a call (cleanly) after the mobile stays for a some seconds on an SDCCH4/8 (probably waiting for measurements, before completing the call). sending some dummy measurements completed the call successfully. beside that, the following issues need to be solved soon, in order to make the layer 1 firmware usable and stable: - additional structures for the libosmocore, see http://home.eversberg.eu/osmocore.patch <http://home.eversberg.eu/osmocore.patch> - freeze of layer 1 after about 40-60 data messages, see http://home.eversberg.eu/data.patch <http://home.eversberg.eu/data.patch> for testing. after a few location updates firmware freezes. (the location update will fail, because the patch disturbs location updating process, but the bug show up.) - syncing problem - clock drifts away after sync - subchannels 4..8 of SDCCH/8 and maybe - tch mode l1ctl message to select signalling only / speech codec of TCH/F / TCH/H. (including bearer capability processing in layer23) regards, andreas

1 0

Wanted: Osmocom logo
by Harald Welte 24 Aug '10

24 Aug '10

Hi! It's about time that we find some kind of graphical project logo for the Osmocom project. Osmocom is intended as an umbrella project for software like OpenBSC, OsmoSGSN, OsmocomBB and others. So it might even be interesting to have some kind of 'family' of logos that all have the same general theme.... At least the bigger projects like OpenBSC and OsmocomBB definitely deserve their own incarnation within that family. If you want to contribute to our project but are not a die-hard C developer, this is your option to contribute! The logo must be under a license that permits use+modification for the Osmocom project itself. Editability for the general public is not important. With regard to formats, I would prefer something as SVG that we can then render into pngs of various sizes whenever there is demand for it. If you have a proposal, simply send it (or a link to a URL) to the openbsc(a)lists.gnumonks.org mailing list. Thanks in advance for any submissions! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

5 5

using BTSAP from layer23
by Andreas.Eversberg 23 Aug '10

23 Aug '10

hi, i am current writing the sim client for layer23. this client transforms the read and update requests from layer 3 (imsi read, location update) into several APDUs to be transferred via BTSAP interface. (interface to layer 1) here are two questions: how do i interface to this BTSAP? i see that there is another unix socket for that. do i need to expand main.c of layer23? i think that i cannot just start sending APDUs after starting layer23. there might be something like an initialization sequence before: - power on - reset - get atr - ... - send APDU - receive APDU - ... is there a defined sequence or flow chart for that? regards, andreas

2 1

AW: sim client
by Andreas.Eversberg 19 Aug '10

19 Aug '10

hi sebastien, thanx for you advice. i will have job names like SIM_JOB_READ, SIM_JOB_UPDATE, SIM_JOB_GSMALGO,... i am a bit unsure about the path array. i always thought that each EF has a unique ID. the DF where it is located, can be determined by the first byte of the EF ID. but if it is possible to have a sim with multiple DFgsm, then a path is required of course. for PIN handling, i will use result codes that gives cause of an error. if a PIN is required (to read the IMSI for example), the error code would show that. then the sim reading process prompts for PIN. the SIM can be unlocked ("enabled") by a message like SIM_JOB_ENABLE_CHV1. outgoing data (UPDATE) is located behind the header. incomming data is also located behind the header when the job returns (callback fn is called). but the READ job must be triggered. when my code must deal with record types, i will expand the header. i will create the API step by step. regards andreas

3 3

sim client
by Andreas.Eversberg 18 Aug '10

18 Aug '10

hi, i like to write the sim client protocol. i do not mean the code of the "sim reader" which is part of layer1 inside the phone. before i start, i would like to know what you think about my api idea. the api is not the low-level api between layer1 and the mobile application (APDU layer). it describes a higher layer for application or protocol processes which need to request IMSI, do key generation, or store location area information. one important thing is that different processes must be able request "read", "write", or other operations like key generation simultaniously. in order to handle multiple requests after each other, a queue inside sim client must exist. afterwar processing each request, the result must be sent only to the requesting process (if it still exists). a state machine watches over the current DF (current selected file area of the sim) and changes current "DF" if required, before processing read or write job. also it triggers the next job in the queue, if finished with the current one. int handle = sim_open(void (*cb)(...)) will add a new user instance. cb is the function to be called for response, handle is a unique id of the process (not a memory pointer, unique at all times after starting phone). void sim_job(struct msgb *msg) struct sim_job_hdr { int handle; uint8_t job_type; uint16_t file; }; will add a new job. the type defines the job type. examples are "READ" "WRITE" or "GSMKEY" requests. the handle is used to assign the read/write job to an instance. the file is used to select the correct data file of the sim. the data and len represent the data to be written. void cb(struct msgb *msg) is called back by the sim client when job is done. the handle is given, so multiple user instances may use the same callback. void sim_close(int handle) will remove user instance. outstanding jobs will finish, but no result is given, because cb is now unregistered. the coding and decoding of SIM files must be done by the application or protocol layer that use the sim client. andreas

2 1

layer1: crash after receiving TX data
by Andreas.Eversberg 16 Aug '10

16 Aug '10

hi, me and maybe some of you experiences sudden freeze of the layer1 firmware. it happens sometimes when sending L1CTL_DATA_REQ from layer2 to layer1. i found a way to reproduce it. see http://home.eversberg.eu/data.patch for testing it. just apply this patch and uncomment the "´#define" line. this patch will transmit idle frames, if there is no frame in the tx-queue of lapdm. (DCCH) even if there is a frame to be sent, the lapdm process will wait until the data is confirmed by layer1 until sendig the next frame. this confirm is sent when the data has been transmitted by layer1 (i think). this is why the queue inside layer1 cannot overflow. this patch does not work correctly somehow. when sending the idle frame, the location update seems not to work. the lapdm fails. but this doesn't matter for the crash-test. until then, more than 20 frames are transmitted. if the mobile application is restarted, more frames will be transmitted. between 45 and 60 frames later the layer1 freezes. the display gets a little darker also. andreas

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

baseband-devel