[srslte-users] Configuring srsEPC to accept MME unknown UEs

J Giovatto jgiovatto at adjacentlink.com
Thu Aug 2 13:19:00 UTC 2018


Hi folks,

Sorry I glanced over the email and missed it...

I'd be glad to help ... in short yes you can run 1 ue, 1 enb and the epc
on a single platform w/o hardware.

The sockrf "device" streams I/Q which can be very IO intensive
especially with nprb > 15.

I'd suggest running with at TIMESCALE of 10 for starters

 cmake -DENABLE_PHY_ADAPTER=y -DTIMESCALE=10 ../ && make

You will need to change the ue/enb config as follows, respectively:

device_name = sockrf
device_args = ue

device_name = sockrf
device_args = enb


Also we like to run each application in an LXC container to provide
network namespace isolation to allow you to use the
tuntap devices as they were expected to be used but this is not
mandatory if you are just looking to get to the attach state.

Running as root is especially helpful as it allows real time pthread
priorities to kick in.

Any questions, please ask ...

Joe


On 08/02/2018 04:09 AM, Andre Puschmann wrote:
> Hey Marek,
>
> On 01/08/18 12:47, Marek Sebera wrote:
>> Hi Andre, and all interested,
>>
>> the important question was buried by other replies, so I post it once more
>>
>> --snip--
>>
>> I'm considering implementing the emergency-attach
>> procedure, however I'm not sure, how to test it while developing.
>>
>> I have only one SDR (USRP B210), so I cannot test srsUE against srsENB
>> using 2 SDRs, what I'd expect be the easiest way to tests/implement.
>>
>> Do you have any idea, how to simulate emergency attach from real device?
>>
>> Or if it's possible to work without SDRs, how to run locally srsUE
>> against srsENB without actually transmitting to the air?
> Yes, I kind of hoped Joe would jump in to promote his excellent sockrf
> patches. As this is not the case, I'll do that now. You'll find them
> here here [1].
>
> Hope that helps
> Andre
>
>
>
> [1] https://github.com/srsLTE/srsLTE/pull/148
>
>
>> --snip--
>>
>> Thank you
>> Marek
>>
>> On 07/30/2018 10:23 AM, Andre Puschmann wrote:
>>> Hey,
>>>
>>> the emergency-attach procedure is not supported right. All the documents
>>> you listed seem to be correct. Needless to say we are happy to review
>>> pull-requests ;-)
>>>
>>> Cheers
>>> Andre
>>>
>>>
>>> On 28/07/18 11:56, Marek Sebera wrote:
>>>> Hello,
>>>>
>>>> i'm investigating possibility of using srsLTE for disaster relief (ie.
>>>> when existing PLMNs are over-loaded or their infrastructure fails) and
>>>> laboratory testing (security testing MEs/UEs without need to change SIM
>>>> within or degrade from LTE to 3G/2G networks)
>>>>
>>>> Reading TS 23.167 (IMS Emergency Sessions) and related parts of 23.401,
>>>> 24.301, 33.401, and others, it seems that Emergency Session shall allow
>>>> unauthenticated / unknown UE to access limited or all services, as per
>>>> network configuration.
>>>>
>>>> TR 23.715 specifies RLOS (Restricted Local Operator Services) to
>>>> Unauthenticated UEs in both IMS and non-IMS attach
>>>> TS 23.401 section 4.3.12.1 specifies (d) "All UEs are allowed"
>>>> TS 33.401 section 5.1.3 and 5.1.4 specifies that if UE cannot be
>>>> authenticated that EIA0 and EEA0 shall be used
>>>> TS 23.167 specifies that while in Emergency Session the IMS (IP
>>>> Multimedia Services) could be available
>>>>
>>>> So I suspect, that we should be able to configure EPC so, that it
>>>> provides services (telephony, sms, PDN) to UEs that cannot be
>>>> authenticated against HSS (user_db.csv).
>>>>
>>>> [++++]
>>>>
>>>> So the question is: Is it possible to allow unknown UE to access network
>>>> services, without being previously known to HSS ? If so, how?
>>>>
>>>> - If it's possible only for Emergency Session, is it possible to enforce
>>>> emergency attach from ENB (ie. convert existing standard attach to
>>>> emergency attach type or let UE know, to repeat attach request in
>>>> emergency mode?)
>>>>
>>>> - If it's possible for normal-style attach, please provide guidance or
>>>> example configuration
>>>>
>>>> [++++]
>>>>
>>>> Obviously we could not provide non-NULL EIA/EEA algorithms, because we
>>>> don't know SIM/USIM Key/OPc and other identifiers
>>>>
>>>> And finally, if I just missed the right 3GPP TS/TR document, just point
>>>> it out, I think, I'm capable of providing implementation within srsLTE,
>>>> if the process is documented already.
>>>>
>>>> Thank you
>>>> Marek Sebera
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> srslte-users mailing list
>>>> srslte-users at lists.softwareradiosystems.com
>>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>>
>>> _______________________________________________
>>> srslte-users mailing list
>>> srslte-users at lists.softwareradiosystems.com
>>> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
>>>
>




More information about the srslte-users mailing list