New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does nextEPC supports S1-handover? #29

Open
wayne43290 opened this Issue Mar 5, 2018 · 34 comments

Comments

Projects
None yet
4 participants
@wayne43290

wayne43290 commented Mar 5, 2018

Hi!
I am wondering whether nextEPC supports S1-handover or not.
I am testing the handover function with 2 small cell, Huawei LTE dongle and the latest version of nextEPC.
Should I modify any parameters? E.g., different TAC for each small cell.

EPC log when I am testing handover:
ho_canceled
pcapng for S1 interface:
image
nextEPC_handoverCanceled.zip

@acetcom

This comment has been minimized.

Owner

acetcom commented Mar 5, 2018

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.

@acetcom

This comment has been minimized.

Owner

acetcom commented Mar 5, 2018

Sorry! ENBConfigurationUpdate -> ENBConfigurationTransfer

@wayne43290

This comment has been minimized.

wayne43290 commented Mar 6, 2018

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

@acetcom

This comment has been minimized.

Owner

acetcom commented Mar 6, 2018

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!

@acetcom

This comment has been minimized.

Owner

acetcom commented Mar 7, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Mar 8, 2018

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

image

@acetcom

This comment has been minimized.

Owner

acetcom commented Mar 8, 2018

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

Thanks for your comment.

@wayne43290

This comment has been minimized.

wayne43290 commented Mar 14, 2018

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?

image
nextEPC_x2-handover_reconnect.zip

@acetcom

This comment has been minimized.

Owner

acetcom commented Mar 14, 2018

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!

@lsps4111wu

This comment has been minimized.

lsps4111wu commented Mar 31, 2018

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.
image

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

Thanks a lot~

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 2, 2018

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!

@lsps4111wu

This comment has been minimized.

lsps4111wu commented Apr 10, 2018

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

Sorry I have nothing to help you.

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 20, 2018

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

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 20, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 20, 2018

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:
screenshot from 2018-04-20 16-43-15

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 20, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 20, 2018

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!

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 20, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 20, 2018

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!

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 20, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 20, 2018

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

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 23, 2018

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

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 23, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 24, 2018

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!

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 26, 2018

Could you tell me your UE and eNB product name?

Thanks!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 26, 2018

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

@acetcom

This comment has been minimized.

Owner

acetcom commented Apr 26, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 26, 2018

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 :)

@brandonjlee

This comment has been minimized.

Collaborator

brandonjlee commented Apr 26, 2018

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.

  1. 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

@wayne43290

This comment has been minimized.

wayne43290 commented Apr 27, 2018

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!

@wayne43290

This comment has been minimized.

wayne43290 commented May 21, 2018

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

acetcom added a commit that referenced this issue May 21, 2018

Fix the bug in building TAU accept message (#29)
- TAU accept should be integrity protected
@acetcom

This comment has been minimized.

Owner

acetcom commented May 21, 2018

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.

@wayne43290

This comment has been minimized.

wayne43290 commented May 22, 2018

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

@acetcom

This comment has been minimized.

Owner

acetcom commented May 22, 2018

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment