nextepc based LTE network @ CCCamp2019

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/nextepc@lists.osmocom.org/.

Matt Johnson matt9j at cs.washington.edu
Tue Aug 27 17:46:14 UTC 2019


Thanks Harald for the detailed writeup and the work to get a large 
NextEPC network up and running.

Regarding point 2, I think it might be good to consider starting with 
only a programmatic interface (CTRL or some kind of RPC framework 
possibly?) integrated directly into the EPC code, and then providing the 
end UI to users as a client of the programmatic interface. This would 
allow separating out the client UI code from the core EPC components 
more easily, and make it more scalable to add additional interfaces as 
needed (I.E. a web gui and a telnet cli existing in parallel, with 
access to the same underlying functionality).

-Matt J.

On 8/27/19 10:14 AM, Sukchan Lee wrote:
> See inline!
>
> On Tue, Aug 27, 2019 at 11:40 PM Harald Welte <laforge at gnumonks.org 
> <mailto:laforge at gnumonks.org>> wrote:
>
>     Hi Sukchan,
>
>     On Tue, Aug 27, 2019 at 11:20:37PM +0900, Sukchan Lee wrote:
>
>     > I'm really surprising that nextepc can support such a large people.
>
>     What I'm personally quite happy is that I couldn't see any clear
>     memory
>     leaks.  Knowing from experience, this is one of the hardest tasks in
>     development of complex C-language software.
>
>     > 1. ogs_expect()
>     > I think that ogs_expect() is really good starting point to remove
>     > unnecessary ogs_assert().
>     > So, I added my version in ogslib() repository as below.
>     >
>     > #define ogs_expect(expr, fallback) \
>     >     do { \
>     >         if (ogs_likely(expr)) ; \
>     >         else { \
>     >             ogs_error("%s: Expectation `%s' failed.", OGS_FUNC,
>     #expr); \
>     >             fallback; \
>     >         } \
>     >     } while (0)
>     >
>     > Let me know if the above interface has a problem.
>
>     I don't see a problem, other than the code looking - from my point
>     of view
>     "ugly".  having return statements inside a macro argument is
>     highly unusual,
>     AFAICT.
>
>     Also, in your version, how would a "print a message but do nothing
>     else" look like?
>     I think it would be "ogs_expect(ret == OGS_OK, );" where the empty
>     second argument
>     looks completely unlike C code at all...
>
>     I understand your motivation and I was also thinking about
>     something like this
>     originally, but I decided against it.  At least at the moment most
>     of your
>     related functions return 'void' anyway, so my
>     ogs_expect_or_return() worked fine.
>
>     I think as soon as you want to do something else but either
>     nothing or return,
>     then you need to introduce a proper if-clause with error
>     handling.  That's why
>     I introduced only those two versions and not a flexible variant.
>
>
> Ah! Now, I understand your intention. So I did rollback 
> ogs_expect_or_return().
> Thank you for introducing a good interface.
>
>     > 2. VTY/CTRL
>     > I'm happy if nextepc can have such a good VTY/CTL. Indeed, this
>     is actually
>     > needed if someone would like to test nextepc on a large scale.
>
>     As indicated, the question is whether I should simply start adding
>     Osmocom VTY
>     using libosmocore, or if we should spend some more time looking
>     for alternatives
>     or even designing + writing some new, better system and then
>     introduce this to
>     nextepc.  I'm a bit undecided here at this point.  Take the quick
>     route or the long
>     path...
>
>
> Basically, I planned to implement HTTP/JSON for this part(e.g. GET 
> /ue, POST /logging). And also, I'd like to monitor the status in the 
> WebUI. However, to do so, we need to create one process to handle it. 
> IMHO, it will take a long to implement it. I also don't know which one 
> is better for us.
>
>     > 3. Logging
>     > I agree that IMSI, APN context is needed when logging. So, I think
>     > mme_log()/sgw_log()/... needs to be introduced. And also, I saw
>     a fix of
>     > the freeDiameter logging. How about merging it  to master
>     branch. Please
>     > github pull request if you agree.
>
>     It's probably even more like a mme_ue_log() or something like
>     that, because you
>     may have different objects/structs which provide loggign context.
>
>     In Osmocom we have introduced log macros like LOG_MSC_A(),
>     LOG_MNCC_CALL(), lOG_MSUB()
>     where the first argument is typically the 'object' providing
>     context.  Those macros then
>     expand to a call to the generic logging macro/function.
>
>
> I saw your work! LOG macro with context adds the prefix logging. I 
> will refer your work when I improve a logging.
>
>     -- 
>     - Harald Welte <laforge at gnumonks.org
>     <mailto:laforge at gnumonks.org>> http://laforge.gnumonks.org/
>     ============================================================================
>     "Privacy in residential applications is a desirable marketing option."
>                                                       (ETSI EN 300
>     175-7 Ch. A6)
>



More information about the nextepc mailing list