Cellular Network Infrastructure » Core Network (CN) » OsmoSGSN

dobby wrote:

More precisely, I investigated a bit and found :
- A first GMM ATTACH REQUEST is received by the SGSN
- Some stuff is happening with the HLR to get crypto params and dealing with subsciber data up to the UpdateLocation Result message
- Meanwhile, some SecurityModeCommand is sent to the femto
- However, the femto answers with a SecurityModeReject message, and after that, the SGSN does not respond to the GMM ATTACH REQUEST
- Then, the SGSN receives a new GMM ATTACH REQUEST every 15 seconds and does not respond to theses as well (4 attach requests in total)
- Finally, after some time, a Iu-ReleaseRequest is received and it triggers a PurgeMS with the HLR.
- After that, a new GMM ATTACH REQUEST is received and is treated sucessfully by the SGSN (no SecurityModeReject and an ATTACH ACCEPT is sent)
- In total, it took around 1minute and 40seconds to get 3G data on the phone

I tried to reboot everything, re-regsiter the SIM info in HLR etc... But I suspect the SecurityModeReject that maybe is an issue with the femtocell ?

Do you have an idea of what is happening ?

AFAICS, the UE is doing the MM Location Updating and GMM Attach simultaneously:

• Not sure if the UE is using the same radio/physical channel, but at the core network those are separate RANAP connections.
• Both MSC and SGSN do send the SecurityModeCommand:
  • MSC suggests: UEA1, UEA2 / UIA1, UIA2
  • SGSN suggests: UIA1, UIA2 (no encryption!)
• UE responds with SecurityModeComplete to the MSC:
  • Chosen algorithms: UEA1 / UIA1
• UE responds with SecurityModeReject to the SGSN:
  • The reject cause is "conflict-with-already-existing-integrity-protection-and-or-ciphering-information (13)"

Looks like the nano3g does not like something about the encryption and/or integrity protection:

• As I already mentioned, SGSN requires no encryption, but only the integrity protection (unlike the MSC).
  • You can try enabling the encryption in osmo-sgsn.cfg, maybe this will do the trick.
• The integrity protection keys are different for the CS (MSC) and PS (SGSN) domains.
  • It might be that nano3g does not support using different keys for CS and PS domains.

Another problem I see here is that the SGSN does not seem to handle the SecurityModeReject correctly:

• The Iu/RANAP connection remains alive for more than 72 seconds.
• The UE re-tries GMM Attach several times, but gets no answer before the connection is closed.

P.S. I have nearly 0 experience with nano3g, just sharing some ideas...

fixeria wrote in #note-2:

dobby wrote:

More precisely, I investigated a bit and found :
- A first GMM ATTACH REQUEST is received by the SGSN
- Some stuff is happening with the HLR to get crypto params and dealing with subsciber data up to the UpdateLocation Result message
- Meanwhile, some SecurityModeCommand is sent to the femto
- However, the femto answers with a SecurityModeReject message, and after that, the SGSN does not respond to the GMM ATTACH REQUEST
- Then, the SGSN receives a new GMM ATTACH REQUEST every 15 seconds and does not respond to theses as well (4 attach requests in total)
- Finally, after some time, a Iu-ReleaseRequest is received and it triggers a PurgeMS with the HLR.
- After that, a new GMM ATTACH REQUEST is received and is treated sucessfully by the SGSN (no SecurityModeReject and an ATTACH ACCEPT is sent)
- In total, it took around 1minute and 40seconds to get 3G data on the phone

I tried to reboot everything, re-regsiter the SIM info in HLR etc... But I suspect the SecurityModeReject that maybe is an issue with the femtocell ?

Do you have an idea of what is happening ?

AFAICS, the UE is doing the MM Location Updating and GMM Attach simultaneously:

• Not sure if the UE is using the same radio/physical channel, but at the core network those are separate RANAP connections.
• Both MSC and SGSN do send the SecurityModeCommand:
  • MSC suggests: UEA1, UEA2 / UIA1, UIA2
  • SGSN suggests: UIA1, UIA2 (no encryption!)
• UE responds with SecurityModeComplete to the MSC:
  • Chosen algorithms: UEA1 / UIA1
• UE responds with SecurityModeReject to the SGSN:
  • The reject cause is "conflict-with-already-existing-integrity-protection-and-or-ciphering-information (13)"

Looks like the nano3g does not like something about the encryption and/or integrity protection:

• As I already mentioned, SGSN requires no encryption, but only the integrity protection (unlike the MSC).
  • You can try enabling the encryption in osmo-sgsn.cfg, maybe this will do the trick.
• The integrity protection keys are different for the CS (MSC) and PS (SGSN) domains.
  • It might be that nano3g does not support using different keys for CS and PS domains.

Another problem I see here is that the SGSN does not seem to handle the SecurityModeReject correctly:

• The Iu/RANAP connection remains alive for more than 72 seconds.
• The UE re-tries GMM Attach several times, but gets no answer before the connection is closed.

P.S. I have nearly 0 experience with nano3g, just sharing some ideas...

Hello, thanks a lot for your reply!

I must have read the wireshark capture too fast because I didn't catch the difference between the SecurityModeCommand from SGSN and MSC, I was convinced they were both sending the same suggestions.
Indeed, SGSN only suggests integrity algorithms by default while MSC suggests both encryption and integrity.

I added the following in the SGSN config so the algorithm suggestions from the SGSN match the ones from the MSC :

sgsn
  ...
  encryption uea 1 2 

So indeed, enabling encryption in osmo-sgsn.cfg did the trick, thanks again !