Does nextEPC supports S1-handover? about open5gs HOT 37 CLOSED

Hi acetcom,

I have asked my small cell provider about this question. After some debugging, they found the reason.

The problem is the Tracking Area Update Accept NAS message (after handover complete) is a plain NAS message and not security protected.
Please see the UE logs below, thanks!

2018 May 21 04:04:29.279 [00] 0x1FEB Extended Debug Message
lte_nas_msg_parse.c 213 H NAS has valid Security context
Drop count = 0

2018 May 21 04:04:29.279 [00] 0x1FEB Extended Debug Message
lte_nas_msg_parse.c 246 E Valid security context is established in NAS, message with MSG_TYPE 73 cannot be a PLAIN NAS message
Drop count = 0

2018 May 21 04:04:29.279 [00] 0x1FEB Extended Debug Message
lte_nas_msg_parse.c 247 E NAS discarding this message

from open5gs.

Hi acetcom,

There is a few progress. However, the s1-handover with TAU doesn't work smoothly.

In the TAUtest1 of the file below, the UE is switched(service request) from .92 eNB to .93 eNB, and 4 TAU request and TAU accepts occurred(why?).
Then the UE is handovered from .93 eNB to .92 eNB, TAU, being released(why?), and do service request with TAU successfully.
Then the UE is handovered from .92 eNB to .93 eNB, TAU, some failure occurred, and then the UE cannot connect to Internet anymore.
I have no idea about TAUtest2.

please help, thanks!
TAUtest.zip

from open5gs.

Hi, wayne43290

Perhaps there seems to be a lot of problems with TAU in NextEPC. We will do our best to support what you are experimenting with.

The reason for repeating 4 times is probably because the TAU accept message of NextEPC is not created properly and the UE rejects it.
We took a close look at the TAU accept message and found that the update result value in TAU accept message did not correctly use the value in the TAU request, and I immediately modified it to github.

One more thing I want to fix is where TAUTest1 Reset occurs. Perhaps we put the process of sending UE Context Release Command to eNodeB(92) before sending the first TAU accept to eNodeB(93).

Thanks for your great work!

from open5gs.

Basically, NextEPC supports S1/X2 handover. This works well with our eNodeB.

However, when we look at the pcap you attached, we found that the feature of ENBConfigurationUpdate is missing.

For your eNodeB, we need to implement handover call-flow with ENBConfigurationUpdate. It may take a while, but we will implement it right away.

Do you have another EPC? If you can capture an S1AP packet with your eNodeB, we will be able to implement it very quickly.

Thank you very much for pointing out.

from open5gs.

Sorry! ENBConfigurationUpdate -> ENBConfigurationTransfer

from open5gs.

Use another EPC to generate the ENBConfigurationTransfer right?
I will check it out, thank you!

from open5gs.

If possible, could you provide all the packet during handover process?
Maybe.. ENBConfigurationTransfer->MMEConfigurationTransfer -> HandoverRequired -> ... Handover Notity.

If you provide the capture file, I'll simulate it using ./test/testepc.

Thanks!

from open5gs.

IMHO, your eNodeB may not create indirect tunnel during S1 handover. I think it is the root cause for HO-failed. Yeah!. eNodeB could skip the creation of indirect tunnel. So, I've fixed the related code.

Let me know if you try to test S1-handover with newly updated source code.

Thanks!

from open5gs.

Hi, the s1-handover works now!
The log from nextEPC said MME configuration transfer is not implemented, but it doesn't affect the handover process.
The pcap and EPC's log is as below:
nextEPC_S1-handover.zip

from open5gs.

Oops! I've added MME configuration transfer.
I'm hoping that handover procedure is also working with this updates.

Thanks for your comment.

from open5gs.

Hi acetcom,

With the latest version of nextEPC, S1-handover works fine, but X2-handover works not smoothly. X2-handover has 50% chance of success between 2 small cells while the unsuccessful X2-handover cause paging/service request.
I have set the small cells with different PCI and cell ID while the Tracking Area Code is the same. Did I miss any configuration?

nextEPC_x2-handover_reconnect.zip

from open5gs.

Umm.. Your configuration seems to be good. This might not be a problem related to X2-handover.

I don't know why eNodeB does send UEContextReleaseComplete after MME sends UEContextReleaseCommand.

So, we've changed the behavior.
If MME cannot find the MME_UE_S1AP_ID or ENB_UE_S1AP_ID, MME will sends ErrorIndication.

Please, re-attach pcapng files after applying new updates.

Thanks!

from open5gs.

Hi,
I have the same problem.
I set the distance between 2 eNBs (called eNB-A, eNB-B) around 2 meters.
And I first open 1 eNB to make sure UE attach to eNB-A.
After that, I turn on eNB-B and move UE between the middle of eNB-A and eNB-B, waiting for UE to trigger handover.
But the log message seems weird.

The following files are:
nextepc.log
handover_failed.pcapng.zip

Thanks a lot~

from open5gs.

Your UE/eNB might not initiate s1 handover. The warning message could be ignored.

Here is your test procedure.

1. UE attached to EPC using eNB1
2. UE moves another eNB2.
3. At that time, S1 handover is not initiated.
4. UE sends Service request using eNB2
5. eNB1 sends UE context release request. However, EPC has already updated MME-UE-S1AP-ID by Service request. So, there is no S1 context in EPC.
6. EPC sends Error-Indication.
7. eNB1 sends Reset.
8. EPC sends Reset-Ack to eNB1

We try to find why UE/eNB does not initiate S1 handover. But we don’t know the reason.

Do you have any other EPC? If it is available, could you send us the packet capture using your EPC.

Thanks a lot!

from open5gs.

I have used openair-cn to connect to Internet,
but openair-cn doesn't implement handover procedure.

Sorry I have nothing to help you.

from open5gs.

Hi acetcom,

With the latest version of nextEPC, I cannot perform S1-handover. It seems that the handover command has some problem, so the eNB response with "semantic-error"
The attachment is the current version pcap which cannot perform s1-handover, and old version of NextEPC (I think it's version at Mar 8) which works fine.

Thanks!

s1-handover_canceled.pcapng.zip
nextEPC_S1-handover.zip

from open5gs.

Hi, wayne43290

This is a NextEPC bug in case of no indirect tunnel.
During moving new S1AP library, we missed this situation.

We've fixed it in github master branch.
Please, Let us know the result if you can test it.

Thanks a lot!

from open5gs.

Hi acetcom,

The handover canceled cause is changed to "tS1relocprep-expiry". As attached:
s1-handover_canceled2.pcapng.zip

By the way, it seems that there is a memory leak:

from open5gs.

It is an environment where I cannot experiment it now.

Without testing, I've fixed it again.
I am so sorry that I cannot confirm and update it.

Thanks!

from open5gs.

Hi acetcom,

The s1-handover works fine now, and the memory leak is solved. Thanks!

On the other hand, can MME maintain different TAI list? If MME can assign different TAI list to UE, then the UE may have to do tracking area update after handover to another eNB. :)

p.s. I found that there is no E-RAB ID in handover command, which should be mandatory which is defined in TS 36.413 clause 9.1.5.2
s1-handover_success1.pcapng.zip

Thanks!

from open5gs.

As I know, if there is no indirect tunnel, MME need not to send E-RABSubjecttoDataForwardingList.
So, E-RAB ID is also not provided from MME. Right?

HandoverCommandIEs S1AP-PROTOCOL-IES ::= {  
    { ID id-MME-UE-S1AP-ID                          CRITICALITY reject  TYPE MME-UE-S1AP-ID                         PRESENCE mandatory}|
    { ID id-eNB-UE-S1AP-ID                          CRITICALITY reject  TYPE ENB-UE-S1AP-ID                         PRESENCE mandatory}|
    { ID id-HandoverType                            CRITICALITY reject  TYPE HandoverType                           PRESENCE mandatory}|
    { ID id-NASSecurityParametersfromE-UTRAN        CRITICALITY reject  TYPE NASSecurityParametersfromE-UTRAN           PRESENCE conditional
    -- This IE shall be present if HandoverType IE is set to value "LTEtoUTRAN" or "LTEtoGERAN" --}|
    { ID id-E-RABSubjecttoDataForwardingList        CRITICALITY ignore  TYPE E-RABSubjecttoDataForwardingList           PRESENCE optional}|
    { ID id-E-RABtoReleaseListHOCmd                 CRITICALITY ignore  TYPE E-RABList                              PRESENCE optional}|
    { ID id-Target-ToSource-TransparentContainer    CRITICALITY reject  TYPE Target-ToSource-TransparentContainer       PRESENCE mandatory}|
    { ID id-Target-ToSource-TransparentContainer-Secondary  CRITICALITY reject  TYPE Target-ToSource-TransparentContainer   PRESENCE optional}|
    { ID id-CriticalityDiagnostics                  CRITICALITY ignore  TYPE CriticalityDiagnostics             PRESENCE optional},
    ...
}

In ASN files, id-E-RABSubjecttoDataForwardingList is an optional.

NextEPC's MME can support different TAI list. From your wireshark file, it seems to use only 1 TAI list in Attach Accept NAS message.

If you want to maintain multiple TAi list, you need to update configuration file.

Refer to the followings.

#
#  o Multiple TAI
#    tai:
#      - plmn_id:
#          mcc: 001
#          mnc: 01
#        tac: [1, 2, 3]
#    tai:
#      - plmn_id:
#          mcc: 002
#          mnc: 02
#        tac: 4
#      - plmn_id:
#          mcc: 003
#          mnc: 03
#        tac: 5
#    tai:
#      - plmn_id:
#          mcc: 004
#          mnc: 04
#        tac: [6, 7]
#      - plmn_id:
#          mcc: 005
#          mnc: 05
#        tac: 8
#      - plmn_id:
#          mcc: 006
#          mnc: 06
#        tac: [9, 10]
#
    tai:
      plmn_id:
        mcc: 001
        mnc: 01
      tac: 12345

Please let me know if I have misunderstanding.

Thanks!

from open5gs.

Hi acetcom,

I have checked the ASN file, and it's true :)

For the TAI list part, a TAI list consists of multiple TACs. MME can keep several TAI lists, and each TAI list describes a tracking area. A UE doesn't have to report its location while moving inside a TAI list. While the UE handover to a eNB that is not in the UE's TAI list, the UE has to perform handover and TAU procedure.
So, I am wondering may the MME keep the TAI information like:

tai:
  plmn_id:
    mcc: 001
    mnc: 01
  tac: [1,2,3], [4,5], [6,7,8]  #then this MME has 3 TAI list

Tell me if I have misunderstanding. Thanks!

from open5gs.

For three TAI list, you need to update configuration file like the followings.

tai:
  plmn_id:
    mcc: 001
    mnc: 01
  tac: [1,2,3]
tai:
  plmn_id:
    mcc: 001
    mnc: 01
  tac: [4,5]
tai:
  plmn_id:
    mcc: 001
    mnc: 01
  tac: [6,7,8]

Then, when the UE enters the TAC (1), it will receive the first TAI list (1,2,3).
After performing the handover, if the UE enters the TAC(4), the UE must transmit a TAU request after handover.

Thanks!

from open5gs.

okay! Thank you very much
I will try it out :)

from open5gs.

Hi acetcom,

I have tried two times, after the S1-handover procedure and TAU, about 10 seconds, the connection break down. Then the UE keeps service request and be released.

TAU_problem.zip

from open5gs.

We believe that your MME configuration is correct. And also, S1-Handover and first TAU is succeeded.

However, UE sends another TAU Request with Initial UE message after the above step. In that case, NextEPC's MME implementations that it sends TAU accept with Initial Context Setup Request. And then, eNodeB sends a Initial Context Setup Failure. Why?

Do you have another EPC which can replay it? Could give us the wireshark pcapng for this scenarios? It must be a very helpful to fix this issue.

If it is not available, we need to study this things from scratch with spec document.

Thanks!

from open5gs.

Hi acetcom,

I am also thinking why does the UE sends TAU request with Initial UE msg. Currently I have no idea.
And I don't have another EPC :"(

Thanks!

from open5gs.

Could you tell me your UE and eNB product name?

Thanks!

from open5gs.

Hi acetcom, good day :)

The eNB is based on Qualcomm FSM9955 chipset with Qualcomm software Release 5.4.2 installed.
The UE is Huawei E3372h LTE USB dongle

from open5gs.

After handover .. After first tracking area update with uplink/downlink NAS transport ..

The initialUEMessage+Tracking Area Update Request means that ENB and UE went to ECM-idle.

If so, eNB should have sent a UE context release request before second Tracking Area Update. Is it Right?

Of course, the spec does not clarify this. But I have never seen the packet capture file like your scenario.

Qualcomm(FSM9955)-based eNB is not available on my desk. So I’m not sure whether your eNB is true or not.

Let me know if I have misunderstanding.

Thanks a lot!

from open5gs.

I am still thinking ...
The UE sends initialUEMessage+TAU Request again after handover and TAU request, does it mean that the first TAU procedure is not complete? The UE cannot change to the new TAC.
I have checked that the TAC of the second TAU request is the original one, which cannot be used at target eNB.

Thanks :)

from open5gs.

I only check the first HO with TAU from TAU_problem.zip. It shows

1. S1 HO
2. TAU sent by UE
3. TAU accept sent by NextEPC

Until here, everything is fine.

4. TAU re-sent by UE with initial UE message (after 20 sec)

It means that #3 is not delivered correctly to the UE from your eNB.
Since it is contained with initial UE message, the UE does not have appropriate bearer at the moment.

So, I believe there are some mis-behavior between the eNodeB and UE after S1 HO and/or HO with TAU. You need to check eNodeB logs if you can, and please check its RRC status too.

Brandon

from open5gs.

okay, I will try.

I have noticed that the UE can surf the Internet before #4. And the UE can surf the Internet after S1 HO without TAU. So I think the problem is TAU.

Thanks!

from open5gs.

We have made a big mistake and have given you a great effort to find this problem.

As soon as we saw the post, we modified a NAS encoding of the TAU accept message to have integrity protection. Please let us know your test result.

Thank you for your great effort.

from open5gs.

I try to connect NextEPC to OAI_eNB but have problem,
in mme terminal was written ,
WARN: S1-setup failure: (s1ap_handler.c:141)
WARN: Cannot find Served TAI. Check 'mme.tai' configuration (s1ap_handler.c:142)
what it means?

from open5gs.

Hi, I'm using a docker-nextepc solution to virtualize a 4G mobile network and I have a problem.
How can I test a handover? The project is this Joanguitar/docker-nextepc

I have created another eNB and another UE (eNB1 -> UE1 y eNB2 -> UE2) and now each UE is conected to one eNB. At this point, I want to test the handover and connect the UE1 to the eNB2.
Anyone can help me to do this? I'm doing my final bachelor degree thesis and I need to do this.

Thanks for your support!

from open5gs.

While analysing UE log.. how could we justify S1 or X2.which handover occurred... Any IE or. TAU request.? Anything.

from open5gs.