From coxe at close-haul.com  Sat May  4 05:00:09 2013
From: coxe at close-haul.com (Robin Coxe)
Date: Sat, 4 May 2013 01:00:09 -0400
Subject: [EVENT ANNOUNCEMENT] Boston Open GSM Meetup on Friday 10 May 2013
Message-ID: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>

(Apologies for cross-posting.  We wanted to reach everyone who might be
interested in attending.  Please respond responsibly.)

Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robin
Coxe (Close-Haul Communications & Analog Devices) invite those interested
in open GSM hardware and software development to an informal gathering in
Cambridge, MA on Friday 10 May 2013 from 6-8 pm.  Alexander will be
visiting the Boston area from Moscow.

If you are interested in participating in any capacity in the Boston-area
open source GSM development community, we look forward to meeting you.  Our
goal is to identify like-minded people involved in or interested in
learning more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and
OpenBSC.   If you have a portable, self-contained demo, feel free to bring
it with you.

When: Friday 10 May 2013, 6-8 pm EDT
Where:  Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA
02142 USA
Photo ID required for building entry.

Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130504/dd9490b0/attachment.htm>

From alexander.chemeris at gmail.com  Sat May  4 10:02:55 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Sat, 4 May 2013 14:02:55 +0400
Subject: [EVENT ANNOUNCEMENT] Boston Open GSM Meetup on Friday 10 May 2013
In-Reply-To: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
References: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
Message-ID: <CABmJbFWUf3EnrENvTZJ+Te1_7=evWx5JV_Eayw9ur+TCbdAynQ@mail.gmail.com>

Hi all,

It would be great to hear from people using OpenBTS/OsmoBTS/OpenBSC
and learn what do you use it for.


From martin at windycitysdr.com  Sat May  4 12:36:00 2013
From: martin at windycitysdr.com (Martin O'Shield)
Date: Sat, 4 May 2013 07:36:00 -0500
Subject: [EVENT ANNOUNCEMENT] Boston Open GSM Meetup on Friday 10 May 2013
In-Reply-To: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
References: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
Message-ID: <CAMeuOX_8-Y6VZJJ2=O1j1TXd84wWQo5T7-EqO5jJF+ttuDbcKg@mail.gmail.com>

Robin,
Alexander,



Too bad this was mentioned with such short notice as your event is
happening in less than 6 days.

Sincerely,


Martin

On Sat, May 4, 2013 at 12:00 AM, Robin Coxe <coxe at close-haul.com> wrote:

> (Apologies for cross-posting.  We wanted to reach everyone who might be
> interested in attending.  Please respond responsibly.)
>
> Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robin
> Coxe (Close-Haul Communications & Analog Devices) invite those interested
> in open GSM hardware and software development to an informal gathering in
> Cambridge, MA on Friday 10 May 2013 from 6-8 pm.  Alexander will be
> visiting the Boston area from Moscow.
>
> If you are interested in participating in any capacity in the Boston-area
> open source GSM development community, we look forward to meeting you.  Our
> goal is to identify like-minded people involved in or interested in
> learning more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and
> OpenBSC.   If you have a portable, self-contained demo, feel free to bring
> it with you.
>
> When: Friday 10 May 2013, 6-8 pm EDT
> Where:  Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA
> 02142 USA
> Photo ID required for building entry.
>
> Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130504/c2da2cc6/attachment.htm>

From andersbrownworth at gmail.com  Sat May  4 12:48:22 2013
From: andersbrownworth at gmail.com (Anders Brownworth)
Date: Sat, 4 May 2013 08:48:22 -0400
Subject: [EVENT ANNOUNCEMENT] Boston Open GSM Meetup on Friday 10 May 2013
In-Reply-To: <CABmJbFWUf3EnrENvTZJ+Te1_7=evWx5JV_Eayw9ur+TCbdAynQ@mail.gmail.com>
References: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
	<CABmJbFWUf3EnrENvTZJ+Te1_7=evWx5JV_Eayw9ur+TCbdAynQ@mail.gmail.com>
Message-ID: <2798833B-351E-45D5-ABF4-6AC5B42A0E89@gmail.com>

All,

Scott Barstow also of SwitchCoder will be flying in from North Carolina as well.

-a

Sent from my mobile.

On May 4, 2013, at 6:02 AM, Alexander Chemeris <alexander.chemeris at gmail.com> wrote:

> Hi all,
> 
> It would be great to hear from people using OpenBTS/OsmoBTS/OpenBSC
> and learn what do you use it for.
> 
> From my side - I'll bring UmTRX or two and could answer all question
> about it and demonstrate it operating OpenBTS and OsmoBTS. I could
> talk about our open-source development of OpenBTS, if there would be
> any interest.
> 
> Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only
> few people heard about OsmoBTS, while it provides great capabilities:
> * it works with off-the-shelf SDR transceivers like UmTRX
> * it could use VoIP (SIP) soft-switches to connect calls
> * it connects to MSCs of legacy GSM networks
> * it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta)
> * standards compliant L1/L2 layers, so there are no issues with
> various phone models
> 
> I love Osmocom approach to development as well - development is open
> to all contributors, the code is well structured and tested, even
> build results for all sub-projects are available through a continuous
> integration suite:
> http://jenkins.osmocom.org/jenkins/
> 
> On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe at close-haul.com> wrote:
>> (Apologies for cross-posting.  We wanted to reach everyone who might be
>> interested in attending.  Please respond responsibly.)
>> 
>> Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and Robin
>> Coxe (Close-Haul Communications & Analog Devices) invite those interested in
>> open GSM hardware and software development to an informal gathering in
>> Cambridge, MA on Friday 10 May 2013 from 6-8 pm.  Alexander will be visiting
>> the Boston area from Moscow.
>> 
>> If you are interested in participating in any capacity in the Boston-area
>> open source GSM development community, we look forward to meeting you.  Our
>> goal is to identify like-minded people involved in or interested in learning
>> more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC.
>> If you have a portable, self-contained demo, feel free to bring it with you.
>> 
>> When: Friday 10 May 2013, 6-8 pm EDT
>> Where:  Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge, MA
>> 02142 USA
>> Photo ID required for building entry.
>> 
>> Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
> 
> 
> 
> -- 
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ??? ???????
> http://fairwaves.ru



From stephane at shimaore.net  Mon May  6 08:10:58 2013
From: stephane at shimaore.net (stephane at shimaore.net)
Date: Mon, 6 May 2013 10:10:58 +0200
Subject: Umtrx meeting in Paris :)
Message-ID: <20130506081058.GA5796@shimaore.net>

Hello team,

I met in Paris with Jean-Samuel last Friday. We talked among other
things about handover in OpenBTS and I wanted to share some of our ideas
with you.

Note: this is my recollection of things, if I misreported something it's
my fault. :}


# Handling SIP intricacies outside of OpenBTS

We both agreed that it is better/simpler to keep the complexity of SIP
protocol out of OpenBTS. There are already very good platforms that can
hide the intricacies of SIP from OpenBTS (FreeSwitch, Asterisk, OpenSIPS
B2BUA, etc.). The alternative (implementing a complete, compliant B2BUA
SIP stack inside OpenBTS) seems difficult (complete rewrite using e.g.
sofia-sip) and doesn't help with time-to-market.

We also both enjoy the "GSM handset looks like a SIP endpoint" analogy
that is the basis of OpenBTS and would like to keep the OpenBTS
GSM-to-SIP interface as transparent as possible.

From stephane at shimaore.net  Mon May  6 11:21:52 2013
From: stephane at shimaore.net (stephane at shimaore.net)
Date: Mon, 6 May 2013 13:21:52 +0200
Subject: Umtrx meeting in Paris :)
In-Reply-To: <20130506081058.GA5796@shimaore.net>
References: <20130506081058.GA5796@shimaore.net>
Message-ID: <20130506112152.GA11313@shimaore.net>

> In turn this makes the requirements for Measurement Report in OpenBTS
> very simple: OpenBTS only needs to send SIP "UPDATE" messages when
> receiving Measurement Reports messages.

Oops, re-reading my notes this should say "PUBLISH", not "UPDATE".
S.



From alexander.chemeris at gmail.com  Mon May  6 14:54:31 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Mon, 6 May 2013 18:54:31 +0400
Subject: [Openbts-discuss] [EVENT ANNOUNCEMENT] Boston Open GSM Meetup on
	Friday 10 May 2013
In-Reply-To: <661ecae4cbf00586bffa55948b7f8e69.squirrel@webmail.hs-bremen.de>
References: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
	<CABmJbFWUf3EnrENvTZJ+Te1_7=evWx5JV_Eayw9ur+TCbdAynQ@mail.gmail.com>
	<661ecae4cbf00586bffa55948b7f8e69.squirrel@webmail.hs-bremen.de>
Message-ID: <CABmJbFXAMr9Zr-65ZQhZdxME_zxz54-6VXast=kOj56dwLCCKw@mail.gmail.com>

We didn't plan video recording, as is meant to be an informal meeting
without prepared presentations.

Please excuse typos. Written with a touchscreen keyboard.

--
Regards,
Alexander Chemeris
CEO/Founder Fairwaves LLC
http://fairwaves.ru
On May 6, 2013 5:56 PM, "Natalia Vesina" <nvesina at stud.hs-bremen.de> wrote:

> Hello,
>
> It is really a great opportunity and could be very interesting and
> useful.Unfortunately I will not be able to come to this meeting. But may
> be there will be some kinds of materials of this meeting  and it will be
> possible to get somehow them?
>
> Will a video conference  be provided in which it is also possible to take
> part?
>
> Best wishes,
>
> Natalia.
>
>
>
>
>
>  Hi all,
> >
> > It would be great to hear from people using OpenBTS/OsmoBTS/OpenBSC
> > and learn what do you use it for.
> >
> > From my side - I'll bring UmTRX or two and could answer all question
> > about it and demonstrate it operating OpenBTS and OsmoBTS. I could
> > talk about our open-source development of OpenBTS, if there would be
> > any interest.
> >
> > Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only
> > few people heard about OsmoBTS, while it provides great capabilities:
> >  * it works with off-the-shelf SDR transceivers like UmTRX
> >  * it could use VoIP (SIP) soft-switches to connect calls
> >  * it connects to MSCs of legacy GSM networks
> >  * it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta)
> >  * standards compliant L1/L2 layers, so there are no issues with
> > various phone models
> >
> > I love Osmocom approach to development as well - development is open
> > to all contributors, the code is well structured and tested, even
> > build results for all sub-projects are available through a continuous
> > integration suite:
> > http://jenkins.osmocom.org/jenkins/
> >
> > On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe at close-haul.com> wrote:
> >> (Apologies for cross-posting.  We wanted to reach everyone who might be
> >> interested in attending.  Please respond responsibly.)
> >>
> >> Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and
> >> Robin
> >> Coxe (Close-Haul Communications & Analog Devices) invite those
> >> interested in
> >> open GSM hardware and software development to an informal gathering in
> >> Cambridge, MA on Friday 10 May 2013 from 6-8 pm.  Alexander will be
> >> visiting
> >> the Boston area from Moscow.
> >>
> >> If you are interested in participating in any capacity in the
> >> Boston-area
> >> open source GSM development community, we look forward to meeting you.
> >> Our
> >> goal is to identify like-minded people involved in or interested in
> >> learning
> >> more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC.
> >> If you have a portable, self-contained demo, feel free to bring it with
> >> you.
> >>
> >> When: Friday 10 May 2013, 6-8 pm EDT
> >> Where:  Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge,
> >> MA
> >> 02142 USA
> >> Photo ID required for building entry.
> >>
> >> Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
> > --
> > Regards,
> > Alexander Chemeris.
> > CEO, Fairwaves LLC / ??? ???????
> > http://fairwaves.ru
> >
> >
> ------------------------------------------------------------------------------
> > Get 100% visibility into Java/.NET code with AppDynamics Lite
> > It's a free troubleshooting tool designed for production
> > Get down to code-level detail for bottlenecks, with <2% overhead.
> > Download for free and get started troubleshooting in minutes.
> > http://p.sf.net/sfu/appdyn_d2d_ap2
> > _______________________________________________
> > Openbts-discuss mailing list
> > Openbts-discuss at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/openbts-discuss
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130506/43a5528b/attachment.htm>

From nvesina at stud.hs-bremen.de  Mon May  6 13:56:13 2013
From: nvesina at stud.hs-bremen.de (Natalia Vesina)
Date: Mon, 6 May 2013 15:56:13 +0200
Subject: [Openbts-discuss] [EVENT ANNOUNCEMENT] Boston Open GSM Meetup on
	Friday 10 May 2013
In-Reply-To: <CABmJbFWUf3EnrENvTZJ+Te1_7=evWx5JV_Eayw9ur+TCbdAynQ@mail.gmail.com>
References: <CAKJyDkLbvk1qPgtG-diYntKOaE_ubqMr07KA9jBjEy9Nzj6+5A@mail.gmail.com>
	<CABmJbFWUf3EnrENvTZJ+Te1_7=evWx5JV_Eayw9ur+TCbdAynQ@mail.gmail.com>
Message-ID: <661ecae4cbf00586bffa55948b7f8e69.squirrel@webmail.hs-bremen.de>

Hello,

It is really a great opportunity and could be very interesting and
useful.Unfortunately I will not be able to come to this meeting. But may
be there will be some kinds of materials of this meeting  and it will be
possible to get somehow them?

Will a video conference  be provided in which it is also possible to take
part?

Best wishes,

Natalia.





 Hi all,
>
> It would be great to hear from people using OpenBTS/OsmoBTS/OpenBSC
> and learn what do you use it for.
>
> From my side - I'll bring UmTRX or two and could answer all question
> about it and demonstrate it operating OpenBTS and OsmoBTS. I could
> talk about our open-source development of OpenBTS, if there would be
> any interest.
>
> Also I'd love to talk about OsmoBTS/OpenBSC which the new cool. Only
> few people heard about OsmoBTS, while it provides great capabilities:
>  * it works with off-the-shelf SDR transceivers like UmTRX
>  * it could use VoIP (SIP) soft-switches to connect calls
>  * it connects to MSCs of legacy GSM networks
>  * it supports encryption, handover, FR/HR/AMR codecs and GPRS (in beta)
>  * standards compliant L1/L2 layers, so there are no issues with
> various phone models
>
> I love Osmocom approach to development as well - development is open
> to all contributors, the code is well structured and tested, even
> build results for all sub-projects are available through a continuous
> integration suite:
> http://jenkins.osmocom.org/jenkins/
>
> On Sat, May 4, 2013 at 9:00 AM, Robin Coxe <coxe at close-haul.com> wrote:
>> (Apologies for cross-posting.  We wanted to reach everyone who might be
>> interested in attending.  Please respond responsibly.)
>>
>> Anders Brownworth (Switchcoder), Alexander Chemeris (Fairwaves), and
>> Robin
>> Coxe (Close-Haul Communications & Analog Devices) invite those
>> interested in
>> open GSM hardware and software development to an informal gathering in
>> Cambridge, MA on Friday 10 May 2013 from 6-8 pm.  Alexander will be
>> visiting
>> the Boston area from Moscow.
>>
>> If you are interested in participating in any capacity in the
>> Boston-area
>> open source GSM development community, we look forward to meeting you.
>> Our
>> goal is to identify like-minded people involved in or interested in
>> learning
>> more about projects such as OpenBTS, OsmocomBTS, OsmocomBB, and OpenBSC.
>> If you have a portable, self-contained demo, feel free to bring it with
>> you.
>>
>> When: Friday 10 May 2013, 6-8 pm EDT
>> Where:  Cambridge Innovation Center, 1 Broadway, 4th Floor, Cambridge,
>> MA
>> 02142 USA
>> Photo ID required for building entry.
>>
>> Please RSVP on Eventbrite: http://opengsmboston.eventbrite.com/
>>
>>
>>
>>
>>
>>
>>
>>
>
>
>
> --
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ?????? ??????????????
> http://fairwaves.ru
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Openbts-discuss mailing list
> Openbts-discuss at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openbts-discuss
>





From alexander.chemeris at gmail.com  Tue May  7 21:27:24 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Wed, 8 May 2013 01:27:24 +0400
Subject: Umtrx meeting in Paris :)
In-Reply-To: <20130506081058.GA5796@shimaore.net>
References: <20130506081058.GA5796@shimaore.net>
Message-ID: <CABmJbFWuSwqsKXWyH5qfOGs1zA=gqGi60iypC7PnL2n6gTQLbA@mail.gmail.com>

Hi Stephane,

Could you describe the communication between the OpenBTS and the "SIP
entity" in more details? I want to better understand how could we
avoid changes in the OpenBTS by introducing this entry.

On another note, I'm more and more leaning towards using OsmoBTS
instead of OpenBTS. We're looking at the idea of implementing an
OpenBTS-like SIP interface for it to get benefits of both worlds. The
best idea so far is to have a A-interface to SIP converter
application, where SIP part is taken from a high level lib like reSIP.
This is quite similar to your ideas, so I want to better understand
details.

On Mon, May 6, 2013 at 12:10 PM,  <stephane at shimaore.net> wrote:
> Hello team,
>
> I met in Paris with Jean-Samuel last Friday. We talked among other
> things about handover in OpenBTS and I wanted to share some of our ideas
> with you.
>
> Note: this is my recollection of things, if I misreported something it's
> my fault. :}
>
>
> # Handling SIP intricacies outside of OpenBTS
>
> We both agreed that it is better/simpler to keep the complexity of SIP
> protocol out of OpenBTS. There are already very good platforms that can
> hide the intricacies of SIP from OpenBTS (FreeSwitch, Asterisk, OpenSIPS
> B2BUA, etc.). The alternative (implementing a complete, compliant B2BUA
> SIP stack inside OpenBTS) seems difficult (complete rewrite using e.g.
> sofia-sip) and doesn't help with time-to-market.
>
> We also both enjoy the "GSM handset looks like a SIP endpoint" analogy
> that is the basis of OpenBTS and would like to keep the OpenBTS
> GSM-to-SIP interface as transparent as possible.
> From that point of view, handover is seen as a call transfer from one
> SIP endpoint (IMSI X @ cell Y) to another SIP endpoint (IMSI X @ cell Z).
> (Here "cell" can be understood as "OpenBTS instance".) The call transfer
> is managed by the SIP front-end.
>
> Assuming for the purpose of discussion that the "SIP front-end" would be
> FreeSwitch, it could be embeded inside the host that runs OpenBTS
> (FreeSwitch would only use a tiny part of CPU compared to e.g. the
> transceiver), so this would appear like a "black box that does SIP" to
> the outside world even though the functionality are split between two
> components (FreeSwitch and OpenBTS) internally.
>
>
> # Handover decision process outside of OpenBTS
>
> The other aspect we agreed on, was that the decision process of when to
> do handover should be better left outside of OpenBTS so that it can be
> implemented by the carrier rather than a static function inside OpenBTS.
>
> This allows a carrier to implement the call-control functionality either
> as a distributed system (e.g. alongside OpenBTS and FreeSwitch inside
> the "embedded" device) or a centralized system. This also allows them to
> use different sets of data and policies to decide when to switch a
> mobile to/from different bands, etc. (Jean-Samuel makes the point that
> handover is used nowadays to help with frequency management /
> load-balancing, alongside its historical role for geographical handover.)
>
> In turn this makes the requirements for Measurement Report in OpenBTS
> very simple: OpenBTS only needs to send SIP "UPDATE" messages when
> receiving Measurement Reports messages. There's no need to process the
> Measurement Reports inside OpenBTS itself. (I will have to specify the
> content of the UPDATE message separately based on GSM 04.08 section
> 10.5.2.20.)
>
>
> Combining this with the previous section leads to a model where the
> carrier's handover-decision code interfaces on one side with OpenBTS
> (via UPDATE messages) and on the other side with the SIP call-control
> element (FreeSwitch), either via a specific interface (e.g. ESL in
> FreeSwitch) or via regular SIP third-party-call-control. The
> call-control elements then transfers the call from one OpenBTS instance
> to another OpenBTS instance (for example by iniatiting a REFER towards
> the calling SIP element -- but since we split OpenBTS and FreeSwitch, we
> don't have to add support for REFER in OpenBTS!).
>
> In any case this gives a potentially highly-distributed handover
> mechanism that doesn't have the limitations of inter-MSC handover, the
> process is entirely peer-to-peer.
>
>
>
> I'm probably forgetting to mention some other topics, just wanted to put
> this in writing for discussion as early as possible.
> S.
>
> --
> St?phane Alnet. Telecom Artisan. OpenSource Advocate.
> Development and integration for FreeSwitch, OpenSIPS, CouchDB, Node.js.
> Mobile: +33643482771 - http://shimaore.net/ - https://github.com/shimaore/
>



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru



From stephane at shimaore.net  Wed May  8 13:09:58 2013
From: stephane at shimaore.net (stephane at shimaore.net)
Date: Wed, 8 May 2013 15:09:58 +0200
Subject: Umtrx meeting in Paris :)
In-Reply-To: <CABmJbFWuSwqsKXWyH5qfOGs1zA=gqGi60iypC7PnL2n6gTQLbA@mail.gmail.com>
References: <20130506081058.GA5796@shimaore.net>
	<CABmJbFWuSwqsKXWyH5qfOGs1zA=gqGi60iypC7PnL2n6gTQLbA@mail.gmail.com>
Message-ID: <20130508130958.GA20391@shimaore.net>

Hi Alexander,

> Could you describe the communication between the OpenBTS and the "SIP
> entity" in more details? I want to better understand how could we
> avoid changes in the OpenBTS by introducing this entry.

The goal is to minimize changes in OpenBTS, really. The transfer of calls
from one cell to another (=handover) would be handled by the "SIP entity";
the goal is that OpenBTS only has to be able to establish and tear down
a call/channel between the GSM side and the "SIP entity". (This means
OpenBTS stays a BTS-like entity, it doesn't become a call-switching system.)

Call flow in that case could look as follows for a handover (MS is
associated with BTS1 at start of call, handover to BTS2; in the right
column I indicated the equivalent BSSMAP messages):

MS           BTS1           BTS2            "SIP-entity"
|             |             |                     |
|             |             | <- INVITE --        | (Handover Request)
|             |             | -- 180 (TCH,HRef) > | (Hand.Req.Ack.)
|             | <- INFO? (TCH,Handover Ref) --    | (Handover Command)
| <- RR H-Cmd |
| --- RR Handover Accept -> |
|             |             |   -- 200 -->        | (Handover Detected)
| - RR Handover Complete -> |
|             |             |   -- INFO -->       | (Handover Complete)
|             | <- BYE (handover) --------------  | (Clear Command)
|             | -- 200 ------------------------>  | (Clear Complete)

Basically we establish a new "call" (SIP session) with BTS2, notify BTS1
so that it triggers the Handover Command, BTS2 connects the call, and
eventually we disconnect the call on BTS1. After the handover BTS1 is no
longer in the call path at all.

The issues I have are related to "what happens in case of failure" and
how to encode this in SIP; for example in the above call-flow the first
INFO message ("Handover Command") could instead be a BYE message, but I'm
not sure what the behavior of the MS is if the handover fails, so it's
safer to use an INFO message in that case.
Also I'm not sure how things work when the network asks the MS to change
cells outside of a call (if I understand properly this is called handoff):
is this also accomplished using RR Handover messages?
In that case we shouldn't use an INFO or a BYE message, we need to use a
NOTIFY (or PUBLISH) message instead.


The PUBLISH addition for Measurement Reports is a related but separate
idea, this is to externalize the decision-making for handover.
"PUBLISH" SIP messages would be generated when OpenBTS receives a RR
Measurement Report:

MS                              BTS
|                               |               |
| -- RR Measurement Report ->   |               |
|                               | -- PUBLISH -> |

This would require a separate software entity that
handles these messages, implements the decision algorithm, and triggers
handover from an MM and a CM perspectives.


Overall in this approach OpenBTS (or some kind of A-bis-over-IP/SIP
translation system as you mentioned) would exchange:
- REGISTER messages with a registrar network (which plays the role of
  HLR/VLR/EIR);
- INVITE messages with the "SIP entity"; the "SIP entity" deals with
  peer-to-peer communication, in-call handover control, ..;
- PUBLISH messages with some third entity, which deals with resource
  management and uses the "SIP entity" to implement handover.

S.



From yanivshiber at gmail.com  Thu May  9 21:49:20 2013
From: yanivshiber at gmail.com (Yaniv Shiber)
Date: Fri, 10 May 2013 00:49:20 +0300
Subject: SRAM Prpblem
Message-ID: <CAOh6gNCLzhfRsu8ryiEsr0Es_HwrHLsmk+kOD3L8nsNhazHi9w@mail.gmail.com>

Hi to All

I am trying to implement Xilinx microblaze on the umtrx2 with EMC core that
connect to the external SRAM.  I configured the EMC to Synchronous mode and
I used the UCF that is published at the GITHUB. If I am trying to deluge
the MCU without the EMC the MCU seem running, but when I connect the EMC,
the MCU stuck and I cannot download the code through the JTAG.

Please advise how to connect the EMC core to the external SRAM ?

thanks in advance,

Yaniv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130510/9f19fa3d/attachment.htm>

From andrew.karpenkov at gmail.com  Sat May 11 19:30:04 2013
From: andrew.karpenkov at gmail.com (Andrew Karpenkov)
Date: Sat, 11 May 2013 23:30:04 +0400
Subject: SRAM Prpblem
In-Reply-To: <CAOh6gNCLzhfRsu8ryiEsr0Es_HwrHLsmk+kOD3L8nsNhazHi9w@mail.gmail.com>
References: <CAOh6gNCLzhfRsu8ryiEsr0Es_HwrHLsmk+kOD3L8nsNhazHi9w@mail.gmail.com>
Message-ID: <CACy-4bnb24MR2j7_R+dZQY_AAO6=780+fE13w0hmMwr0Oc3mUg@mail.gmail.com>

Hi Yaniv,

I'm not very familiar with Microblaze, but I'll try to help.

There are several possible reasons:

   - SDRAM cannot run at a higher frequency than Microblaze. So you need to
   reduce the SDRAM Clock to 52 MHz or speed up Microblaze core to 104Mhz.
   - Endianess. MicroBlaze is Big endian and SDRAM (IS61NLP25672) follow
   little Endian so need to assign Buses in inverted order. e.g:: address11 to
   address0 and adress10 to adress1 and so on ... also applying this for data,
   bank and DQM busses.
   - Issue of latching edge. SDRAM datasheet says to latch data at positive
   edge.


Regards,
Andrew Karpenkov


2013/5/10 Yaniv Shiber <yanivshiber at gmail.com>

> Hi to All
>
> I am trying to implement Xilinx microblaze on the umtrx2 with EMC core
> that connect to the external SRAM.  I configured the EMC to Synchronous
> mode and I used the UCF that is published at the GITHUB. If I am trying to
> deluge the MCU without the EMC the MCU seem running, but when I connect the
> EMC, the MCU stuck and I cannot download the code through the JTAG.
>
> Please advise how to connect the EMC core to the external SRAM ?
>
> thanks in advance,
>
> Yaniv
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130511/e8f38fa5/attachment.htm>

From yanivshiber at gmail.com  Mon May 20 21:54:47 2013
From: yanivshiber at gmail.com (Yaniv Shiber)
Date: Tue, 21 May 2013 00:54:47 +0300
Subject: UMTRX - SRAM
Message-ID: <CAOh6gNB66WotEdvwrfrZygE8g=9FWL+qch-4JD-oVuHWLGCD1Q@mail.gmail.com>

Hi All,

I wish to work with the Synchronize Sram and to connect it to the FPGA
Microblaze.
Does anyone was able to use and communicate with the SRAM?
If so, can U help with the configuration of the EMC?
I read the EMC datasheet and they describe different way for connecting the
EMC with the SRAM. Maybe U know on a problem when working with SRAM?

thanks in advance,

Yaniv
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130521/d5b5e463/attachment.htm>

From andrew.karpenkov at gmail.com  Tue May 21 07:11:56 2013
From: andrew.karpenkov at gmail.com (Andrew Karpenkov)
Date: Tue, 21 May 2013 11:11:56 +0400
Subject: UMTRX - SRAM
In-Reply-To: <CAOh6gNB66WotEdvwrfrZygE8g=9FWL+qch-4JD-oVuHWLGCD1Q@mail.gmail.com>
References: <CAOh6gNB66WotEdvwrfrZygE8g=9FWL+qch-4JD-oVuHWLGCD1Q@mail.gmail.com>
Message-ID: <CACy-4bnzun6nBEd+jXgtzpw6HOdBNh1K+8PK7+F3C4yzuFcbhg@mail.gmail.com>

Hi Yaniv,

I'm not very familiar with Microblaze, but I'll try to help.

There are several possible reasons:

   - SRAM cannot run at a higher frequency than Microblaze. So you need to
   reduce the SRAM Clock to 52 MHz or speed up Microblaze core to 104Mhz (for
   UmTRX boards).
   - Endianess. MicroBlaze is Big endian and SRAM (IS61NLP25672) follow
   little Endian so need to assign Buses in inverted order. e.g:: address11 to
   address0 and adress10 to adress1 and so on ... also applying this for data,
   bank and DQM busses.
   - Issue of latching edge. SRAM datasheet says to latch data at positive
   edge.


Regards,
Andrew Karpenkov


2013/5/21 Yaniv Shiber <yanivshiber at gmail.com>

> Hi All,
>
> I wish to work with the Synchronize Sram and to connect it to the FPGA
> Microblaze.
> Does anyone was able to use and communicate with the SRAM?
> If so, can U help with the configuration of the EMC?
> I read the EMC datasheet and they describe different way for connecting
> the EMC with the SRAM. Maybe U know on a problem when working with SRAM?
>
> thanks in advance,
>
> Yaniv
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130521/f603faf4/attachment.htm>

From alexander.chemeris at gmail.com  Wed May 22 21:30:58 2013
From: alexander.chemeris at gmail.com (Alexander Chemeris)
Date: Thu, 23 May 2013 01:30:58 +0400
Subject: GSM clock GPS txco help
In-Reply-To: <519BB3E8.9020003@opentechinstitute.org>
References: <519BB3E8.9020003@opentechinstitute.org>
Message-ID: <CABmJbFXuYTbJb+9RcXMBixAQkZUv7-3NXCAqnnWKePHZN2WqgQ@mail.gmail.com>

Hi Will,

Thank you for the good news. Answering to your question, first please
update your UmTRX firmware and host side UHD:
 1. Update your UHD and umtrx_scripts from the git. Build UHD.
 2. Flash attached ZPU firmware to a UmTRX with the following command:
      ./usrp_n2xx_net_burner.py --addr=192.168.10.2 --fw=usrp2p_txrx_uhd.bin
 3. Power cycle UmTRX

Calibrate with GPS:
 1. Take your UmTRX outside to get GPS lock.
 2. When GPS acquires a lock, use 'umtrx_vcxo.py' utility without
parameters to read current VCTCXO DAC value in a loop.
 3. When the value stabilise (couple minutes after GPS acquires the
lock), write this value to EEPROM:
      ./usrp_burn_mb_eeprom --key tcxo-dac --val <YOUR_VAL>
 4. Now i should pickup the value from EEPROM on boot, so GPS is no
required unless you change ambient temperature considerably.

Note, that you should warm up your UmTRX for a while before
calibration, because it depends on the TCXO temperature.

Let me know if something goes wrong - I wasn't able to test
everything, as I don't have my UmTRX with me at the moment.

On Tue, May 21, 2013 at 9:50 PM, Will Hawkins
<hawkinsw at opentechinstitute.org> wrote:
> Hey Alexander!
>
> Yesterday we took our umtrx outside to get the GPS lock for calibrating the
> tcxo voltage. There were some good outcomes and bad outcomes:
>
> The good:
> If you remember correctly, Dan could not associate to the umtrx with his
> Galaxy Nexus. After getting a GPS signal, Dan's phone could associate! So,
> great news.
>
> The bad:
> We attempted to record the calibrated tcxo dac values and had no luck. We
> booted the umtrx board connected via serial console to my laptop. I was able
> to see the boot messages and other output so I know the console was working.
> Once the board got a GPS lock, I assumed that I would see some tcxo DAC
> values printed to the console. Based on what you said last week, I was going
> to wait until those values stabilized and then use that output to flash into
> the eeprom. Unfortunately I did not see any output on the serial console.
> Then I thought that we could poll the umtrx (using UHD probe) for its tcxo
> dac values. Unfortunately it showed the default (2048) every time.
>
> Can you tell me what I'm doing wrong?
>
> Thanks!
> Will
>
> PS: CC'ing Dan since he's working this with me.



-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ??? ???????
http://fairwaves.ru
-------------- next part --------------
A non-text attachment was scrubbed...
Name: usrp2p_txrx_uhd.bin
Type: application/octet-stream
Size: 16383 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/umtrx/attachments/20130523/9e7bb670/attachment.bin>

From hawkinsw at opentechinstitute.org  Wed May 22 21:35:22 2013
From: hawkinsw at opentechinstitute.org (Will Hawkins)
Date: Wed, 22 May 2013 17:35:22 -0400
Subject: GSM clock GPS txco help
In-Reply-To: <CABmJbFXuYTbJb+9RcXMBixAQkZUv7-3NXCAqnnWKePHZN2WqgQ@mail.gmail.com>
References: <519BB3E8.9020003@opentechinstitute.org>
	<CABmJbFXuYTbJb+9RcXMBixAQkZUv7-3NXCAqnnWKePHZN2WqgQ@mail.gmail.com>
Message-ID: <519D3A1A.20005@opentechinstitute.org>

Thanks Alexander,

I will give this a try first thing tomorrow morning and let you know how 
it goes!

Will

On 05/22/2013 05:30 PM, Alexander Chemeris wrote:
> Hi Will,
>
> Thank you for the good news. Answering to your question, first please
> update your UmTRX firmware and host side UHD:
>   1. Update your UHD and umtrx_scripts from the git. Build UHD.
>   2. Flash attached ZPU firmware to a UmTRX with the following command:
>        ./usrp_n2xx_net_burner.py --addr=192.168.10.2 --fw=usrp2p_txrx_uhd.bin
>   3. Power cycle UmTRX
>
> Calibrate with GPS:
>   1. Take your UmTRX outside to get GPS lock.
>   2. When GPS acquires a lock, use 'umtrx_vcxo.py' utility without
> parameters to read current VCTCXO DAC value in a loop.
>   3. When the value stabilise (couple minutes after GPS acquires the
> lock), write this value to EEPROM:
>        ./usrp_burn_mb_eeprom --key tcxo-dac --val <YOUR_VAL>
>   4. Now i should pickup the value from EEPROM on boot, so GPS is no
> required unless you change ambient temperature considerably.
>
> Note, that you should warm up your UmTRX for a while before
> calibration, because it depends on the TCXO temperature.
>
> Let me know if something goes wrong - I wasn't able to test
> everything, as I don't have my UmTRX with me at the moment.
>
> On Tue, May 21, 2013 at 9:50 PM, Will Hawkins
> <hawkinsw at opentechinstitute.org> wrote:
>> Hey Alexander!
>>
>> Yesterday we took our umtrx outside to get the GPS lock for calibrating the
>> tcxo voltage. There were some good outcomes and bad outcomes:
>>
>> The good:
>> If you remember correctly, Dan could not associate to the umtrx with his
>> Galaxy Nexus. After getting a GPS signal, Dan's phone could associate! So,
>> great news.
>>
>> The bad:
>> We attempted to record the calibrated tcxo dac values and had no luck. We
>> booted the umtrx board connected via serial console to my laptop. I was able
>> to see the boot messages and other output so I know the console was working.
>> Once the board got a GPS lock, I assumed that I would see some tcxo DAC
>> values printed to the console. Based on what you said last week, I was going
>> to wait until those values stabilized and then use that output to flash into
>> the eeprom. Unfortunately I did not see any output on the serial console.
>> Then I thought that we could poll the umtrx (using UHD probe) for its tcxo
>> dac values. Unfortunately it showed the default (2048) every time.
>>
>> Can you tell me what I'm doing wrong?
>>
>> Thanks!
>> Will
>>
>> PS: CC'ing Dan since he's working this with me.
>
>
>