jSS7 Simulator: additional MAP operations for Location Services Management (LSM)

[FerUy]

Add MAP SRIforLCS, MAP PSL and MAP SLR to jSS7 simulator.
For more information, see RestComm/gmlc#10

[deruelle]

@f-alonso-vendrell just assigned this issue to you ;)

[f-alonso-vendrell]

Adding support for SRIforLCS in SS7 Simulator, need to do:

• Creation of 2 new "Testing Task", MAP_LOCATION_TEST_CLIENT, MAP_LOCATION_TEST_SERVER (visual part)
• Add the 3 operations (each request / response), e.g. taking as reference: SendRoutingInfoForLCSRequest (integration with existing implementation)
• Integration with simulator stack to actually send/receive messages.

[FerUy]

Nice @f-alonso-vendrell

Maybe we could put LCS instead of LOCATION (i.e. MAP_LCS_TEST_CLIENT/SERVER). What do you think? I leave it up to you.

[f-alonso-vendrell]

sure, I was trying to set up a clear todo list for my team and myself so if some concept is wrong or the approach is not ok, it can be exposed before advancing in the wrong direction. BTW how is documentation generated? I am currenly reading directly the ascii-doc but if it already generated or I can generate with a mvn command it would be of great help for my eyes.

[f-alonso-vendrell]

just discovered that at: jss7\docs\userguide\sources-asciidoc\target\generated-docs\html-book the documentation is generated.
Also it is needed to use profile doc in maven or go to docs and do mvn clean install there

[FerUy]

Great @f-alonso-vendrell

[FerUy]

One question, are you able to access RestComm/gmlc#10 ?
I'm asking as they are tightly coupled.

[f-alonso-vendrell]

yes. I am reading information from there to get a picture.

[FerUy]

Great!

[vetss]

Hello @FerUy @f-alonso-vendrell

yes we need two "Testing tasks", one is GMLC server (I guess "Client") side and another - HLR / MSC / SGSN sides ("server").

For tasks names - please check the list of MAP operations there: https://github.com/RestComm/jss7/blob/master/map/MAPMessagesImplemented.ods
I think better to give a name of a service - "Location Service Management Services" == "LSM"

MAP_LSM_TEST_CLIENT
MAP_LSM_TEST_SERVER

Please also check, which messages which side sends (GMLC and HLR/MSC/SGSN sides I mean)

Fernando, do you know which is a proper messageflow ? Is is just sending a request / responsing or the messageflow may be more complicated ?

[FerUy]

Hi @vetss

The message flow is portrayed here: RestComm/gmlc#10 (same diagram here)

Regarding the acronym, LCS is used by 3GPP/LTE and other related organizations for referring to Location Services. For example, 3GPP TS 23.271 is titled "Functional stage 2 description of Location Services (LCS)".

"Location Service Management Services" is used in 3GPP TS 29.002 (MAP spec) as the section title for these location services operations:
MAP-SEND-ROUTING-INFO-FOR-LCS (MAP SRIforLCS)
MAP-PROVIDE-SUBSCRIBER-LOCATION (MAP PSL)

Another acronym largely used and known in the industry is LBS (Location Based Services), which is more commercial than technical.

So, although I'd rather stay with LCS, what about?
MAP_LCSM_TEST_CLIENT
MAP_LCSM_TEST_SERVER

[vetss]

Thanks @FerUy for your info,

There is one more operation - "subscriberLocationReport - 86" that is sent TO GMLC (not from as for two others). I am not sure we need to have it. Just for your info.

As for a name of the service - go ahead in this topic and select that you like more.

[FerUy]

Hi @vetss , We will need "subscriberLocationReport - 86" for some use cases involving deferred type of location information (Notification type of Geolocation in Restcomm Geolocation API -geofencing-), but for now let's focus on SRIforLCS and PSL (Immediate type of Geolocation in Restcomm Geolocation API).

I choose LCS for the name of the service then :)
So, @f-alonso-vendrell , unless you have any objection, let's go with:
MAP_LCS_TEST_CLIENT
MAP_LCS_TEST_SERVER

[f-alonso-vendrell]

Ok, I am going with the MAP_LCS_TEST_CLIENT, created following:

new file: core/src/main/java/org/mobicents/protocols/ss7/tools/simulator/tests/map/TestMapLcsClientMan.java
new file: core/src/main/java/org/mobicents/protocols/ss7/tools/simulator/tests/map/TestMapLcsClientManMBean.java
new file: gui/src/main/java/org/mobicents/protocols/ss7/tools/simulatorgui/tests/map/TestMapLcsClientForm.java

and modified corresponding

modified: core/src/main/java/org/mobicents/protocols/ss7/tools/simulator/management/Instance_TestTask.java
modified: core/src/main/java/org/mobicents/protocols/ss7/tools/simulator/management/TesterHost.java
modified: gui/src/main/java/org/mobicents/protocols/ss7/tools/simulatorgui/ConnectionForm.java
modified: gui/src/main/java/org/mobicents/protocols/ss7/tools/simulatorgui/SimulatorGuiForm.java

As the moment of this comment I have been able to show "sendRoutingInfoForLCSRequest not implemented yet" when clicking the button.

As I plan to:

1. hardcode operation parameters on SRIforLCS, test end2end (so I would need also SERVER Part), then pull request
2. Make parameters on SRIforLCS configurable, test end2end, then pull request
3. Move forward with the other operations

Let me know at what level of viability you would like to do pull request (e.g. is it ok to publish the SRIforLCS with parameters hardcoded or should they be configurable before publishing)

After some testing I would like to request a feature on the Simulator, that would be a "Load Default Values for Side A/B" at top level, so once you have selected Layer 1, Layer 2, Layer 3 and TestTask you click that button and all layers get populated at once.

[FerUy]

@f-alonso-vendrell agreed with the plan. It's OK to go first with 1 (publish the SRIforLCS with hardcoded parameters ) and make pull request, then go to 2 and so on.

[f-alonso-vendrell]

Hello I just got to a point in which I run 2 simulators, the first one with MAP_LCS_TEST_CLIENT and the second one with SMS_TEST_SERVER (as I haven't done the server part yet). In the client part I am able to send SRIforLCS request (at least I think so). This is what I am sending:

98114 [AWT-EventQueue-0] DEBUG org.mobicents.protocols.ss7.tools.simulator.tests.map.TestMapLcsClientMan - MAPDialogLsm Crea
ted
98129 [AWT-EventQueue-0] DEBUG org.mobicents.protocols.ss7.tools.simulator.tests.map.TestMapLcsClientMan - Added SendRouting
InfoForLCSRequest
98145 [AWT-EventQueue-0] DEBUG org.mobicents.protocols.ss7.sccp.impl.SccpRoutingControl - Tx : SCCP Message=Sccp Msg [Type=-
1 networkId=0 sls=1 incomingOpc=-1 incomingDpc=-1 outgoingDpc=-1 CallingAddress(pc=1,ssn=8,AI=67,gt=null) CalledParty(pc=2,ss
n=8,AI=67,gt=null) DataLen=68]
98145 [Thread-3] DEBUG org.mobicents.protocols.sctp.AssociationImpl - Tx : Ass=Ass_main PayloadData [dataLength=124, complet
e=true, unordered=false, payloadProtocolId=3, streamNumber=0, data=
Start: 0 (0x00) End: 123 (0x7B) Length: 124 (0x7C)
00: 01 00 01 01 00 00 00 7C 02 00 00 08 00 00 00 66 | .......| .......f
10: 00 06 00 08 00 00 00 65 02 10 00 64 00 00 00 01 | .......e ...d....
20: 00 00 00 02 03 02 00 01 09 01 03 07 0B 04 43 02 | ........ ......C.
30: 00 08 04 43 01 00 08 44 62 42 48 04 00 00 00 01 | ...C...D bBH.....
40: 6B 1E 28 1C 06 07 00 11 86 05 01 01 01 A0 11 60 | k.(..... .......`
50: 0F 80 02 07 80 A1 09 06 07 04 00 00 01 00 25 03 | ........ ......%.
60: 6C 1A A1 18 02 01 00 02 01 55 30 10 80 05 91 11 | l....... .U0.....
70: 11 22 22 A1 07 80 05 55 55 45 44 44 -- -- -- -- | .""....U UEDD
]

On the server part (not implemented yet LCS) I get a message which says:

00:03:15,726 WARN [MAPStackImpl-Simulator] ApplicationContextName of non activated MAPService is received. Will send back TCAP Abort : 0, 4, 0, 0, 1, 0, 37, 3,
80550 [pool-10-thread-1] WARN org.mobicents.protocols.ss7.map.MAPStackImpl-Simulator - ApplicationContextName of non activated MAPService is received. Will send back TCAP Abort : 0, 4, 0, 0, 1, 0, 37, 3,

which I guess makes sense since MAPServiceLsm is not active on that side.

I would like to do a PR so you can check the code, how should I proceed?

[vetss]

ApplicationContextName of non activated MAPService is received

check an example in org.mobicents.protocols.ss7.tools.simulator.tests.sms.TestSmsClientMan
line: 547

[f-alonso-vendrell]

Hello Vetss, so should I also do the counter part (MAP_LCS_TEST_SERVER) before PR? the client part which you are referring is working fine (I think so), the error is coming in the server part for which I haven't done anything. I will edit my previous post so that is clear.

[vetss]

Hello @f-alonso-vendrell

what do you mean "counter part" ?

Yes, you need to provide both CLIENT and SERVER parts. Else it is impossible to check how well they are implemented. If both Simulator parts work fine then we can start to test of interconnecting of Simulator with some server.

[f-alonso-vendrell]

ok, proceeding...

[f-alonso-vendrell]

Server part completed, thanks @vetss for pointing out code for reference. I have pushed it into my fork. Ready to do PR.

[vetss]

Hello @f-alonso-vendrell ,

I have just checked your pull request, thanks for your work.
I can not commit your work sofar because it is not completed. My remarks are here:

1. let's rename your new package
   org.mobicents.protocols.ss7.tools.simulator.tests.map ->
   org.mobicents.protocols.ss7.tools.simulator.tests.lcs
   We need it because for MAP stack we have several tasks and we make names depending of test task

2. no configurable parameters. At least we need to for a client size configurable mlcNumber and targetMS. We need GUI form for updating and parameters files like TestAtiClientConfigurationData. I do not know if we need any configurable parameters at server side (ask Fernando). Possibly we need to have an opportunity to send MAP error messages But even if not we need an empty form anyway. Also we can make that server part will auto response to incoming messages (without pressing of a button in the form).

3. Response is not implemented. At least I get TC-ABORT message.

4. no information is not displayed in task forms. Please see how it is implemented in other tasks. We need at least log sent / received messages including error messages and also some reports of if a dialog is opened or not, how many messages were sent / received, etc.

5. we need to provide also access via JMX and HTTP. For this we need to have TestAtiClientStandardManMBean and register beans. Check how it is made in other tests.

6. we do not add code into master branch more because weh have just released it. We use now netty-2 branch, please take it into account. We will rename soon netty-2 to master, but now please synch with netty-2 branch

[f-alonso-vendrell]

Hello @vetss

1. ok

2. I thought that first PR would be with hardcoded params, ok, I guess this was the next step

3. I also thought that PR would be by message, so no need to the response, as item 2, I guess this was also the next step so ok

4. Yes, I forgot to review that part. I will put messages

5. ok, wasn't aware, but I guess that is the gui connecting to a core part

6. ok

   The order of resolution will be: 1(Easy), 5(good to learn), 3(good to learn), 4, 2, 6 Let me know if once done 1,5,and 3 I can make a new PR or should I complete the whole set.

[vetss]

Hello @f-alonso-vendrell

2. I thought that first PR would be with hardcoded params, ok, I guess this was the next step

If we are saying of work steps we can do it step by step for sure. But the final version must contain parameters editing forms / storing of parameters into some configs. Even we have as for now an empty set of configurable parameters those forms must be present so all implementation follow the same standard and furter code update will be simple

3. I also thought that PR would be by message, so no need to the response,
   as item 2, I guess this was also the next step so ok

I do not understand your fully. We need to have both client a nd server parts workable and test interconnections between two simulators (client - server) to be sure all is properly implemented before we will start of testing of interconnection of SS7 Simulator with some server like GMLC or other SS7 equipment.

5. ok, wasn't aware, but I guess that is the gui connecting to a core part

We need to test JMX / HTTP accesses before we can say that the implementation is finished. This is of cause possible when both client and server parts are implemented. If you need some extra info for this part feel free to ask it.

[f-alonso-vendrell]

simulator is not working for me on netty-2 branch, added a comment on: https://gitter.im/RestComm/jss7
Found the issue and solved in my code (missing ref in descriptor.xml)

[vetss]

@f-alonso-vendrell

I have added your update #169
I have not made moer tests. I will try to find time for tests in short time.

[f-alonso-vendrell]

Hello @FerUy I am coding geranPositioningData, utranPositioningData for PSL Response, and in order to build it it requires a byte[], for what I have seen it requires a minimum of 2 and a max of 10. How should that be presented in the Params GUI? As a String with only HexValues e.g. "F3F2F1"?

[FerUy]

Hi @f-alonso-vendrell. I faced the same issue for LTE positioning (where Diameter is used).
I believe a String with Hex values is OK (unfortunately we don't have a trace of that yet).

[vetss]

@FerUy - is this issue fixed ?
Can we close it or we need to postpone to the next release (8.1) ?

[FerUy]

No @vetss, let's postpone it for next release 8.1.

[FerUy]

Reopening.