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

Marek Sebera marek.sebera at gmail.com
Thu Aug 2 10:49:54 UTC 2018


Thank you Andre,

this seems like a nice work, only the commits shall be squashed in my
opinion.

Why didn't this get merged yet?

Cheers
Marek

On 08/02/2018 10: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