- OpenBSC - lists.osmocom.org

patch: 14_DMM
by Andreas.Eversberg 23 May '09

23 May '09

a minor fix of DMM debugging. now MM debugging is shown, if given by debug option, not only by default debugging. the color of DNM debugging changes to cyan as it is supposed to be.

1 0

patch: 15_paging_lac
by Andreas.Eversberg 23 May '09

23 May '09

This patch will resolve all BTS with the LAC of the subscriber and page every BTS with this LAC. If the subscriber is not currently attached, the LAC is not set, so the caller will get cleared with cause 27 (MO out of order). This patch must be applied AFTER patch 12 (application interface) has been applied.

1 0

patch: 16_subscr_lac
by Andreas.Eversberg 23 May '09

23 May '09

The patch will store the current LAC in the HLC when the subscriber successfully attaches. If the subscriber detaches, the LAC will be set to 0. This patch is required to make patch 15 (paging) work. This patch does not depend on any other patch i made.

1 0

patch: 11_trau
by Andreas.Eversberg 23 May '09

23 May '09

I improved trau_mux.c. Now it supports not just bridging only. A new function "trau_recv_lchan" is used to link a channel to a call reference of a transaction. (Transactions are used in later patches.) TRAU frames will then be forwarded to the application with the given call reference (in later patches). Also the application can send TRAU frames by using "trau_send_lchan". A new list is introduced in trau_mux.c. (upqueue_entry) All subslots that must be sent to application are listed here. Received TRAU frames are written in the upqueue of application interface, if a call reference is found in the upqueue-list. If an entry is found the ss_entry list, the TRAU frames are bridged as before. The frames have a message type (msg_type), a call reference (callref) and a trau frame (data). The length of trau frame is defined by the content of the c-bits inside the frame. There is no support for ip-access yet. Harald must add this in order to use application interface with ip-access. The bridging with ip-access works as before.

2 1

AW: patch: 8_paging
by Andreas.Eversberg 23 May '09

23 May '09

i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached) i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also. -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Samstag, 23. Mai 2009 08:30 An: Andreas.Eversberg Cc: openbsc(a)lists.gnumonks.org Betreff: Re: patch: 8_paging Hi again, On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote: > On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote: > > Paging refers to a BTS. To page a mobile phone, the current location > > is required. If paging succeeds or expires, the BTS structure is > > also given to the callback function (cbfn). > > > > Because paging refers to a BTS, the cbfn (callback function) must > > include a pointer to bts. > > The paging response includes a lchan pointer, which can be resolved to > the physical channel / timeslot and to the trx and finally to the BTS. > Is this not sufficient? Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL. Still, when you call paging_request() you actually pass on a number of parameters, including: 1) the BTS on which you want to page (whcih, indeed, is currently the BTS of the calling party rather than the called party). So this parameter is likely to get removed soon. 2) The subscriber that was called. This should be used by paging_request() to resolve the BTS that this subscriber was last seen/registered to. 3) a reference to the call, which is treated as an opaque pointer that is passed back as a reference when calling the call-back function. So if the bts of the calling or called party needs to be known, it should probably be referenced from that data structure. Or am I missing something? -- - 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)

2 2

AW: patch: 6_datalink
by Andreas.Eversberg 23 May '09

23 May '09

i don't know if it works with the latest mISDN. have you tested it? if it doesn't work, we need to fix it. do you have any idea why it does not work with mISDN? -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Samstag, 23. Mai 2009 07:43 An: Andreas.Eversberg Cc: openbsc(a)lists.gnumonks.org Betreff: Re: patch: 6_datalink On Thu, May 21, 2009 at 02:27:35PM +0200, Andreas.Eversberg wrote: > This patch corrects the handling of data link status change. thanks, applied - with the exception of the last hunk removing the 'kernel doesnt support sapi' comment. As far as I know, we still need to claim that we use SAPI0, despite in reality using a different one, since the kernel will refuse any non-sapi-0 request from userspace. Regards, -- - 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)

2 1

AW: patch: 8_paging
by Andreas.Eversberg 23 May '09

23 May '09

here is the problem: we don't know about the called bts, if - the subscriber detaches after paging was started and the current_bts pointer inside subscriber is NULL. - the lchan is not set because paging expires. we can use the network pointer instead of the bts pointer for paging callback function. the gsm_network is required when paging result is received. all transactions (call instances) are linked in a list in gsm_network. (see patch 13) even if paging expires, the transactions in this list with the same subscriber must be released. (MO out of order) but it is more complex: the subscriber will not be NULL, because it is "used" by the transactions. the use-counter of subscriber is increased for every transaction created and decreased on release of that transaction. if there is a call process for the paged subscriber, the subscr is set when paging response is received. we need at least a pointer to the network to access the transactions. we can keep paging callback function without bts (or network) pointer, but then we need a network pointer in gsm_subscriber to process the network's paging result. -----Ursprüngliche Nachricht----- Von: openbsc-bounces(a)lists.gnumonks.org [mailto:openbsc-bounces@lists.gnumonks.org] Im Auftrag von Andreas.Eversberg Gesendet: Samstag, 23. Mai 2009 09:47 An: Harald Welte Cc: openbsc(a)lists.gnumonks.org Betreff: AW: patch: 8_paging i use the calling party's BTS, because the subscriber database does not contain the current BTS number of the subscriber last seen. (or detached) i agree that the subscriber gives us information about the paged bts and we can resolve the gsm_network from that also. -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Samstag, 23. Mai 2009 08:30 An: Andreas.Eversberg Cc: openbsc(a)lists.gnumonks.org Betreff: Re: patch: 8_paging Hi again, On Sat, May 23, 2009 at 02:23:11PM +0800, Harald Welte wrote: > On Thu, May 21, 2009 at 02:27:36PM +0200, Andreas.Eversberg wrote: > > Paging refers to a BTS. To page a mobile phone, the current location > > is required. If paging succeeds or expires, the BTS structure is > > also given to the callback function (cbfn). > > > > Because paging refers to a BTS, the cbfn (callback function) must > > include a pointer to bts. > > The paging response includes a lchan pointer, which can be resolved to > the physical channel / timeslot and to the trx and finally to the BTS. > Is this not sufficient? Ah, ok, in the case we do not successfully allocate a lchan, then that's obviously NULL. Still, when you call paging_request() you actually pass on a number of parameters, including: 1) the BTS on which you want to page (whcih, indeed, is currently the BTS of the calling party rather than the called party). So this parameter is likely to get removed soon. 2) The subscriber that was called. This should be used by paging_request() to resolve the BTS that this subscriber was last seen/registered to. 3) a reference to the call, which is treated as an opaque pointer that is passed back as a reference when calling the call-back function. So if the bts of the calling or called party needs to be known, it should probably be referenced from that data structure. Or am I missing something? -- - 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)

1 0

AW: patch: 2_misdn
by Andreas.Eversberg 23 May '09

23 May '09

you can copy compat_af_isdn.h from mISDNuser package, as you did with mISDNif.h. (socket branch) then you don't need the user package. i think i forgot to copy it to the include/openbsc/ directory. -----Ursprüngliche Nachricht----- Von: Harald Welte [mailto:laforge@gnumonks.org] Gesendet: Samstag, 23. Mai 2009 07:24 An: Andreas.Eversberg Cc: openbsc(a)lists.gnumonks.org Betreff: Re: patch: 2_misdn On Thu, May 21, 2009 at 02:27:34PM +0200, Andreas.Eversberg wrote: > This patch corrects the inclusion of mISDN headers. Also the mISDNif.h > is updated. compat_af_isdn.h is not in our source tree. As the current socket-based mISDN headers cannot yet be expected to be present on most linux distributions, I would rather not create any additional external dependencies. I have no problem with updating our header files, but they should not create additional dependencies. -- - 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)

1 0

patch: 10_debug
by Andreas.Eversberg 23 May '09

23 May '09

A new debug flag is introduced: "DMNCC". MNCC is the Mobile Network Call Control. This is required for later patches, that extract the call control from gsm_04_08.c

2 1

patch: 9_tlv
by Andreas.Eversberg 23 May '09

23 May '09

Some messages have one or two length-value information elements. The is no IE type included in the message. These information elements are mandatory, so their actual IE type is known. The improved parse_tlv() function allows to parse zero, one, or two length-value elements.

2 1