Openphone

historical

On Sat, Apr 16, 2016 at 1:36 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Madhu,
>
> On Mon, Apr 11, 2016 at 08:50:17PM +0530, Madhu Macaque Labs wrote:
> > I am the project lead for the SHAKTI open source processor project.
>
> Thanks a lot for introducing yourself, your extremely ambitious project
> and for reaching out to us.  I can hardly grasp the complexity of your
> enormous task, and I think it would still be extremely challenging if
> you would only focus on the cellular side of things, ignoring the
> application processor side.
>

We have in fact decided to split the work into two projects. I have no
option
but to do the AP and other server SoCs since that is the core project. But
we now
have a separate LTE/5G modem effort. Focus will be more on programmability
than the lower power core. The turbo encoder/decoder is tricky. But then
I have a lot of Mater's students at my disposal !

>
> > snapdragon 820 or the Apple A9.  the CPU core is pretty much under
> > control but we are exploring the DSP needed for running the lower levels
> > of the 3G/LTE stack.
>
> I am not aware of anyone having done any free software work on the MS/UE
> side of GPRS, EDGE, UMTS or HSPA, so I think you will have to start from
> scratch there - not only ergarding the DSP performance/capability
> requirements, but also regarding the actual implementation.
>
There seem to be a few openLTE efforts including UE stacks. Looking at
those.
Fortunately we have a full fledged LTE lab on campus with all the necessary
test equipment.

>
> There's the OsmocomBB work that focusses on classic circuit-switched GSM
> only, and there is srsUE (see below) for LTE.  But everything in between
> is a big gap.  You might be able to extend and re-use OsmocomBB Layer3
> for UMTS circuit-switched NAS, but that's just a very small fraction of
> the problem.
>
> Most of the other Osmocom wokr has been focusing on the netwokr side of
> the protocol stacks, so we have GSM, GPRS and partial EDGE support for
> all of the network side (PHY to RAN to CN), and we are working on the
> core-network parts of UMTS/HSPA at this point.  But that's of very
> little use for UE side work, at least on anything beyond message
> encoding/decoding, some definitions.
>
> > Another group does LTE stacks and so we have complete testing equipment
> > available to test for compliance.
>
> I would seriously have a look at the excellent work been done at
> Software Radio Systems on their srsUE implementation of LTE.  They
> implemented a full LTE UE from PHY via AS to NAS as free software under
> AGPLv3.  They are running all of this on an Intel Core i7 CPU, but I'm
> sure you could re-implement the performance criticla SDR part of the PHY
> in your DSP and re-use everything on top.
>
Have looked at it. Trying to figure out how complete it will be.
It is a circular problem. Want to co-design the DSP along with the stack
and not dump a DSP on the SW team. My only problem is that our language
of choice is Bluespec and not everybody has the toolchain for it.
It is a high level HW desgn language (actually a  Haskell derivative).
Would love to have other enhancing our RTL too. Fortunately the tool
is free for open source developers.

>
> FOSS is abut collaboration and not re-inventing the wheel, after all :)
>
> > I am basically looking for co-conspirators who can help identify the
> > components I can use from the osmocom stack and figure out what else
> > we need to develop.
>
> I personally would love to be involved, but I am already working what
> other people would consider two full time jobs and there is absolutely
> no time left to engage in any additional projects without long-term
> scheduling and planning, sorry.  Maybe there are others in Osmocom who'd
> have more time and interest.
>
That is OK. Just spread the work around. The key is to get a completely
open LTE
HW platform that can be the basis for many commercial implementations. I
already have
two major phone OEMs signed up for using our modem (when it arrives !).

> In any case, it would be great if you could keep us posted in some way
> about your progress.
>
> Regards,
>         Harald
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
>
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>

-- 
Regards,
Madhu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20160416/7d8b81af/attachment.htm>